标签
# 当 AI 能一夜之间生成可运行代码——重读 Brooks 的《人月神话》 *一篇在 AI 时代重新审视经典之作的反思文章：AI 或许能迅速生成可运行的代码，但真正的瓶颈，正在从「人的协调」转移到「大规模软件系统的规格定义与验证」。* --- ## 一、一本被反复引用、却很少被真正消化的书 1975 年，Frederick P. Brooks 发表了《The Mythical Man-Month》，其中最著名的论断莫过于 Brooks's Law：**向一个已经延期的项目增加人手，只会让它更加延期**。这句话几乎出现在每一场工程管理的讨论里，也几乎总是被当作一个关于「沟通开销随人数平方增长」的注脚。 但如果今天重新翻开这本书，你会发现 Brooks 谈的其实远不止于此。他谈论的是**概念完整性（conceptual integrity）**，是一个软件系统应该像一部小说那样拥有「一个头脑、一种愿景」；他谈论的是外科手术团队式的组织方式；他谈论的是「第二个系统效应」，以及为什么最危险的系统往往不是第一个，而是紧随其后的那个。 在 AI 能够生成可运行代码的今天，这些观点不仅没有过时，反而变得更难被绕过。 ## 二、AI 确实改变了什么 必须诚实地承认 AI 带来的变化。过去需要一名工程师数周才能完成的胶水代码、数据清洗脚本、测试桩和样板工程，现在往往在几分钟内就有了第一版可运行的结果。软件的**产出速度**——严格来说，是「初版代码」的产出速度——已经不再是瓶颈。 这意味着 Brooks 时代里许多与「人力吞吐量」有关的论断，在表层上被削弱了。你不再需要为「缺人写代码」而焦虑，也不再需要在招聘、外包和多团队并行之间反复权衡。 然而，代码只是软件的表层形态。软件真正的本质，是**在一个约束条件下解决问题，并且长期可靠地解决它**。当表层的产出速度被无限拉高，瓶颈只会向更深处移动。 ## 三、真正的瓶颈一：规格（Specification） Brooks 在书中反复强调：软件开发最大的困难不是实现，而是**决定该做什么**。他引用了 Dijkstra 的名言，并指出软件工程师的工作可以粗略分为「想清楚」和「写出来」两部分——而前者才是稀缺且昂贵的。 AI 加速了后者，却丝毫没有降低前者。 一个大型软件系统里最难的部分从来不是「把一个函数写对」，而是： - **需求的边界在哪里**？哪些约束是真实的，哪些只是历史遗留？ - **各个组件之间的契约如何定义**？当两个子系统各自演化时，谁有权决定语义？ - **性能、可靠性、安全性的隐含假设是什么**？这些假设是否被所有人共同理解？ 在这些层面，AI 能够做的是把你已经模糊想清楚的东西快速具体化——但它同样擅长把「你以为想清楚了、其实并没有」的东西写成一份看起来无懈可击的文档。**它不降低规格的难度，它只是提高了错误规格的产出速度**。 ## 四、真正的瓶颈二：验证（Verification） 如果说规格是「决定做什么」，验证就是「确认做出来的东西确实是那个东西」。 这里存在一个容易被忽视的不对称：**生成代码的成本正在趋近于零，但验证代码的正确性并没有**。甚至在某些维度上，验证变得更难了——因为代码可能来自一个你自己无法逐行审阅其推理过程的来源。 在大规模系统中，验证从来不等于「单元测试通过」。它包括： - 不变式（invariants）在跨服务边界时是否仍然成立； - 数据迁移是否真的保持了语义一致性； - 故障场景下的行为是否符合预期； - 以及最困难的一点：**系统是否在它被要求解决的问题上长期有效**。 Brooks 把软件工程类比为医学：他要求工程师像医生一样，既尊重严谨的诊断流程，又保留人性化的判断。当验证的压力从「人力不足」转为「验证成本远高于生成成本」时，这个类比比以往任何时候都更贴切。 ## 五、人的协调问题并没有消失，只是换了一副面孔 需要特别澄清的是：Brooks's Law 并没有失效。它只是换了一个表现形式。 AI 可以同时给多个团队、多个代码库、多个产品线生成方案。当这些方案彼此之间存在隐含的、未被明示的冲突时，协调成本会以平方级增长——与 Brooks 在 1975 年描述的现象完全一致，只是冲突发生的层级从「谁去写这段代码」上移到了「谁来决定系统的行为契约」。 概念完整性仍然是稀缺品。AI 能让每个团队都「跑得很快」，但它无法替整个组织决定：**这个系统在五年后应该长成什么样**。 ## 六、一些可能的回应 如果要从这篇反思中提炼出实践层面的建议，大概会是这几条： 1. **把规格当作一等公民**。在引入 AI 加速之前，先花大力气把约束、不变式和契约写清楚。AI 是放大器，它会同样地放大精确与含混。 2. **把验证能力当作投资**，而不是成本。当生成变得廉价，能够「证明某件事是对的」的那部分能力就是核心竞争力。 3. **保护概念完整性**。仍然需要少数人、以接近外科手术团队的方式，对系统的整体形态保持持续的、集中的关注。 4. **重新理解 Brooks's Law**。它讨论的从来不只是沟通开销，而是**决策集中化与规模化之间的张力**——这一点在多 agent 并行生成的场景下只会更加尖锐。 ## 七、结语 五十年后，Brooks 仍在描述着软件工程的真实形状。AI 没有推翻这本书，它只是把书中的问题从「人手够不够」推进到了「我们知道到底要什么、以及怎么证明我们做到了」。 生成会越来越快，这几乎可以确定。但软件工程的天花板，始终悬在规格与验证那一侧——而那里，仍然需要清醒的人类判断。 --- *本文为重新阅读 Frederick P. Brooks《The Mythical Man-Month》后的个人反思，不构成对任何特定 AI 编码工具的评价。*