摘要
1) 一句话总结 尽管AI智能体极大地提升了代码生成速度并降低了软件开发的偶然复杂性，但《人月神话》中的核心挑战依然存在，人类专家的系统设计、范围把控与品味仍是决定复杂软件项目成败的关键约束。
2) 关键要点
- 人类专家在环不可或缺：目前仍需人类专家指导智能体，作者通过开发
roborev等工具对智能体任务进行严格监督和审查，而非依赖随意的“氛围编程（vibe coding）”。 - 生产力数据：作者目前每月在 Claude、Codex 和 Gemini 上消耗超过 100 亿个 Token，甚至能使用从未手写过的 Go 语言产出海量代码。
- 验证了“没有银弹”理论：智能体极擅长解决“偶然复杂性”（如重构、写测试），但在面对没有先例的“本质复杂性”（核心设计问题）时无能为力。
- 1/9 法则依然适用：智能体让获取“能运行的程序”变得极易，但这仅占成为真正“编程产品”所需工作量的 1/9，后续的测试、文档和边缘情况处理仍需大量投入。
- 核心瓶颈转移：软件构建的瓶颈不再是敲击键盘的速度（打字速度可提升 10-100 倍），而是概念完整性、产品范围界定以及人类开发者的设计品味。
- 行业影响分化：普通的 CRUD（增删改查）外包公司可能面临淘汰，但处于分布曲线前 1% 的复杂开发工作（如 OpenAI 专家利用 AI 解决物理难题）仍将高度依赖人类专家。
3) 风险与隐患
- 智能体焦油坑与技术债务：智能体生成的代码库注定比人类手写的更庞大、更过度设计，正以机器速度积累前所未有规模的技术债务。
- 生成新的偶然复杂性：智能体倾向于引入不必要的复杂性，生成大量在实际应用中极少需要的防御性样板代码。
- 上下文过载（棕地障碍）：当代码量逼近 10 万行（如
roborev项目）或达到百万行级别（如 Positron 项目）时，智能体会因上下文过载而原地打转，难以在自己生成的臃肿代码中进行修改。 - 协调与架构冲突：缺乏持久记忆和共识的智能体团队会生成相互矛盾的计划，导致架构偏移，仍需人类去调和这些矛盾。
- 严重的范围蔓延（Scope Creep）：代码生成成本趋近于零，极易诱发无节制的功能添加，这些看似免费的新功能会成为未来的维护负担和 Bug 载体。
- 破坏开源生态：开源项目正被大量长达 3000 行、由未读过代码的提交者通过 AI 生成的 PR（拉取请求）淹没，导致设计决策无人负责。
正文
和许多人一样，我发现 AI 严重影响了我的作息。过去，我可能会在凌晨 4 点醒来喝口水，然后继续入睡；但现在，一旦我在清晨 5 点脑海中浮现出要喂给 AI 编程智能体（Agents）的新想法，我就会辗转反侧，最终干脆起床开始新的一天。我的睡眠时间从曾经的 7-8 小时锐减到了勉强 6 小时，但我已经基本放弃了抵抗。
在我的工程师和数据科学家朋友圈里，大家都在热烈讨论：人类的竞争优势还能保持多久？ 当智能体开始产生更好的想法时，人类拥有好想法还重要吗？目前来看，“人类专家在环（human-expert-in-the-loop）”对于从智能体那里获得好结果仍然至关重要，但这种状态还能持续多久？我们最终是会愉快地交出控制权，还是会面临其他局面？
就目前而言，我依然觉得自己是被需要的。我并不把现在的工作方式称为“氛围编程（vibe coding）”——这个词听起来像是一种只需“随便写写提示词然后躺平”的贬义词，往往会产出劣质的 AI 软件项目。相反，我一直在开发像 roborev 这样的工具，以便为并行的智能体任务引入严谨性与持续监督，并严格审查它们的工作。
面对这种激进的全新工作方式，我开始重新思考软件工程的未来。我职业生涯中引用最多的书大概是 Fred Brooks 的《人月神话》（The Mythical Man-Month）。著名的“布鲁克斯定律”指出：“为延期的软件项目增加人力，只会让它更加延期。” 最近我常问自己：这本书的经验是否适用于这个全新的智能体开发时代？一个优秀的开发者指挥一群 AI 智能体，真的能更快更好地构建复杂软件吗？短期的生产力提升会带来长期的项目成功吗？还是说，我们将再次撞上困扰了软件团队数十年的老瓶颈——范围蔓延、架构偏移以及协调开销？
重温《人月神话》与“智能体焦油坑”
Brooks 的一个核心论点是：由少数精英组成的小团队（以一名“首席外科医生”为核心，辅以专家）要优于平庸的大团队。这种模式能带来高度的系统设计“概念完整性”，仿佛“即使由许多人构建，也出自同一个大脑的设计”。
然而，智能体工程似乎放大了这些问题。现在，软件的质量完全取决于“在环”的人类：他们需要策划和完善规格说明，决定功能的去留，并驯服不必要的代码与架构复杂性。
《人月神话》中有一个著名的“焦油坑”比喻：所有的猛兽都在其中挣扎，看似谁都能轻易挣脱，但焦油却将它们死死困住。如今，我们面临着一个全新的**“智能体焦油坑”**：我们并行的 Claude Code 会话和 Git 工作树，正在与虚拟同事生成的代码膨胀和附带复杂性进行着殊死搏斗。你可以系统性地重构，但智能体生成的代码库注定会比人类手写的代码更庞大、更过度设计。这是一种以前所未有的规模、以机器速度积累的技术债务。
Brooks 还观察到，一个能运行的程序，距离成为一个真正的“编程产品”只完成了 1/9 的工作。产品还需要测试、文档、边缘情况处理，并且能被作者以外的人维护。智能体让获取“能运行的程序”变得极其容易，但这让许多新晋的 AI 程序员严重低估了从原型走向生产环境所需的工作量。
当结合“康威定律”（软件架构往往反映了组织的沟通结构）时，这些问题会进一步恶化。如果一个虚拟的智能体“团队”没有持久的记忆，对正在构建的系统也没有共识，它们构建出的架构会是什么样？
此外，随着团队规模扩大，协调问题（n(n-1)/2）依然存在。在智能体工程中，参与的人类变少了，但协调问题并没有消失，只是改变了形态：不同的智能体可能会生成相互矛盾的计划，而人类必须去调和这些矛盾。
没有银弹：本质复杂性与偶然复杂性
“在技术或管理方法上，没有任何一项单一的发展，能够承诺在十年内让生产力、可靠性或简洁性获得哪怕一个数量级的提升。” ——《没有银弹》（1986）
在《人月神话》的后续文章中，Brooks 通过“本质复杂性（Essential complexity）”和“偶然复杂性（Accidental complexity）”的视角来审视软件设计：
- 本质复杂性：实现目标所必须的复杂性。如果系统再简单一点，就无法解决问题。
- 偶然复杂性：由工具和流程（编程语言、工具、为了让工程师理解而加的设计和文档）强加的复杂性。
编程智能体可能是人类创造出的解决“偶然复杂性”的最强大工具。 试想一下：我现在基本不亲手写代码了，但我却用 Go 语言（一种我从未手写过的语言）产出了海量代码。我每个月在 Claude、Codex 和 Gemini 上消耗超过 100 亿个 Token，生产力的提升是巨大的。
但 Brooks 的“没有银弹”论断准确预测了我目前在智能体工程中遇到的困境：偶然复杂性不再是问题，但剩下的本质复杂性依然困难，而智能体无法可靠地区分这两者。
大语言模型（LLM）是卓越的模式匹配器，它们在全人类的开源软件上训练而成。因此，它们在处理偶然复杂性（重构代码、写测试、清理混乱）时才华横溢，但在面对没有先例可循的微妙本质设计问题时却显得力不从心。它们还倾向于引入不必要的复杂性，生成大量在实际应用中极少需要的防御性样板代码。
换句话说，智能体在消除偶然复杂性方面太出色了，以至于它们生成了新的偶然复杂性，反而阻碍了你试图构建的本质结构。
在我的新项目（roborev 和 msgvault）中，当代码量逼近 10 万行（100 KLOC）时，我已经开始面临这个问题。我眼看着智能体开始原地打转，在它们自己生成的臃肿代码库中因上下文过载而窒息。当代码量继续增加时，事情开始崩溃：每一次新修改都必须在之前智能体创造的“代码丛林”中艰难开路。我们可以称之为**“棕地障碍（brownfield barrier）”**。在 Posit 公司，我们看到智能体在百万行级别的代码库（如 Positron，一个 VSCode 分支）中挣扎得更加厉害。这似乎印证了 Brooks 关于复杂性扩展的论点。
弄清楚“到底要构建什么”在 LLM 出现之前就是最难的部分，我不认为一个完美无瑕的编程智能体能改变这一点。
智能体带来的范围蔓延（Scope Creep）
当生成代码变得免费时，知道何时说“不”是你最后的防线。
随着代码生成成本趋近于零，几乎没有什么能阻止智能体及其人类指挥官去尝试以前因成本或时间限制而放弃的所有方向。整天输入“你能不能顺便再加个……”的诱惑是压倒性的。
然而，任何新生成的功能或子系统，虽然创建成本低廉，但在未来的维护、测试、调试和逻辑梳理上绝非零成本。现在看似免费的东西，会成为未来智能体会话的上下文负担；每一个新添的花哨功能，都可能成为导致系统脆弱或伤害用户的新 Bug 载体。
从这个角度看，构建伟大的软件项目从来就不是比拼打字速度。借助智能体，我们的“打字”速度可以提升 10 倍甚至 100 倍，但我们仍然需要做出优秀的设计决策，拒绝大多数产品想法，保持概念完整性，并知道什么时候该“收手”。智能体加速了“简单的部分”，却矛盾地让“困难的部分”变得更加困难。
这种智能体带来的范围蔓延似乎也在破坏开源软件世界。现在贡献代码的门槛降到了历史最低点，开源项目正被大量长达 3000 行、添加新功能的“热心” PR（拉取请求）淹没。当开发者越来越脱离设计和规划过程时，智能体失控的范围蔓延会迅速恶化。如果提交 PR 的人自己都没有写过甚至没有完整读过其中的代码，那么很可能没有人真正对这些设计决策负责。
设计与品味：人类最后的立足点
Brooks 认为，设计天赋和好品味是最稀缺的资源。现在，既然智能体包揽了所有编码体力活，我认为这些技能比以往任何时候都更重要。
瓶颈从来不在于敲击键盘的双手。在这个全新的“神话般的智能体人月”时代，我们可以合理地得出结论：设计、产品范围界定和品味，仍然是交付高质量软件的实际约束。
在这个新时代茁壮成长的开发者，不会是那些运行最多并行会话或消耗最多 Token 的人。他们将是那些能够在脑海中掌控项目概念模型、精明地决定构建什么和舍弃什么，并对海量输出行使“品味”的人。
《人月神话》出版于 50 多年前。半个世纪以来，硬件性能、编程语言、开发环境、云计算以及现在的大语言模型都取得了巨大进步。工具变了，但约束依然存在。
也许我只是在为自己继续存在的价值找借口，但现实远比这复杂。并非所有软件生来平等：普通的 CRUD（增删改查）业务应用与数据库等关键系统软件截然不同。我认为普通的软件外包公司可能要完蛋了。但我的论点更多是针对处于分布曲线前 1% 的开发工作——那些大多数工程师无法触及的难题。这部分工作将继续需要人类专家在环，即使他们不再进行任何手动编码。
例如，我的朋友、OpenAI 的 Alex Lupsasca 和他世界级的物理学家合作者们，能够在 AI 的帮助下对一个物理难题进行公式化并得出解决方案。如果没有这些专家在环，LLM 能否提出正确的问题并得出解决方案是非常值得怀疑的。
就目前而言，在可预见的未来，我可能还是会每天凌晨 5 点起床，去喂养和驯服我的智能体。现在的编程变得更简单了，老实说也更有趣了。我可以把时间花在思考“构建什么”上，而不是在工程流程周围的工具和系统里痛苦挣扎。