AI 没有杀死人月神话，只杀死了半个
AI 没有杀死人月神话，只杀死了半个
Fen9Pi，把复杂东西拆明白。本文 8 分钟，带你拆一个 50 年没死的老问题，在 AI Agent 时代被判了个什么刑。
先摆两个事实，你感受一下温差。
2025 年 2 月，Karpathy 造了个新词：vibe coding——「完全交给感觉，拥抱指数增长，忘掉代码的存在」。同年 1 月达沃斯，Anthropic CEO Dario Amodei 说：到 2026 年底，AI 会写掉绝大部分代码。一个亲自掌管全球最强编程模型的人，说自己的模型一年后接管编码——这听起来像终局。
而 1975 年，一个叫 Frederick Brooks 的 IBM 经理出版了《人月神话》。他刚带队做完操作系统史上著名的焦油坑项目 OS/360，写书复盘「软件为什么难」。1986 年他追加了一篇论文《没有银弹》，把当时最被看好的九种技术——Ada、面向对象、人工智能、专家系统、自动编程、图形化编程、程序验证、开发环境、工作站——逐个拖出去，判了死刑。理由只有一条：它们都打不中软件困难的要害。
现在 AI Agent 来了。写代码、跑测试、改 bug、自我规划任务，全链路都沾。所以问题很具体：人月神话里诊断出的那些病，AI 到底治好了几个？
我的答案在标题里：它杀死了半个。而且另外半个里，有三个病不但没好，还被 AI 喂着恶化了。
这不是我拍脑袋。下面一条一条验，证据全部带出处。
第一步：把「人月神话的问题」先分成两堆
不分类就开始吹或黑，都是耍流氓。Brooks 在《没有银弹》里给过一个分类法，这是全书最锋利的一刀，也是我们今天验尸的手术台：
软件开发的所有活动，分成两类。根本任务（essence）：打造由抽象软件实体构成的复杂概念结构——想清楚要造什么。次要任务（accident）：用编程语言把这些结构表达出来、映射成机器码——把它写出来。
注意「次要」不是「偶然」，Brooks 特意澄清这是亚里士多德的用法，意为「附带的」。在此基础上，他给了那个著名的算术论证：除非次要任务占到全部工作的九成，否则就算把它的时间压缩到零，也换不来数量级的提升。而 1995 年他自己交了实底：次要部分「已经下降到整个工作的一半或一半以下」。
围绕根本任务，他列出软件的四个固有属性：复杂度、一致性、可变性、不可见性。再加上管理学三坑：人月不可互换（Brooks 法则：向进度落后的项目加人只会更落后）、第二系统效应、概念完整性。这就是《人月神话》开出的完整病历。
表达、编码、文档
测试用例、脚手架、迁移
Brooks 1995：占工作量已不到一半根本问题：决定说什么
复杂度 · 一致性 · 可变性 · 不可见性
人月互换 · 第二系统 · 概念完整性
四属性是「软件的固有属性」
GitHub Copilot、Cursor、Claude Code
全在这里面攻城略地AI 的战绩：一个没杀死
三个还在恶化：
复杂度 ↑ 不可见性 ↑ 第二系统 ↑
这个分法为什么重要？因为它让「AI 有没有用」和「AI 是不是银弹」变成两个独立的问题。AI 可以同时是「史上最强的生产力工具」和「不是银弹」——就像电梯是史上最强的垂直交通工具，但没让楼变矮。
好，上证据。
被杀死的半个：次要问题，解决得很彻底
编码本身的体力活，AI 确实快了。最有名的数字来自 GitHub 官方 2022 年的对照实验：95 名职业开发者写同一个 HTTP 服务器，用 Copilot 的组平均 71 分钟完成，不用的组 161 分钟——快 55%。注意条件：单一任务、陌生小项目、Upwork 招募。换到真实世界，MIT 2025 年在微软、埃森哲等三家公司做的随机对照试验（约 4800 名开发者）里，提速缩水到约 26%。
实验室 55%，现实 26%——打折，但真金白银。
文档和测试这两件 Brooks 时代最没人爱干的次要活，AI 干得比人好。注释、README、单测脚手架、API 迁移，这些「表达层」工作是 LLM 的降维打击。说个你自己五秒能验证的：让任何一个模型给十年前的老函数补注释，五秒钟的产出质量超过多数工程师五分钟的。
更狠的是，Brooks 在 1986 年给根本问题开的四条出路，AI 竟然直接兑现了三条半：
- 「购买而非建造」——他说大众市场软件包是最深远的方向。今天 SaaS + AI 定制，把「不开发软件」推到了极致：连胶水代码都不用写，说需求就行。
- 「快速原型」——他说客户不知道自己要什么，只能靠原型逼出来。vibe coding 就是原型自由：一个下午出可点的 demo，需求会议直接变成体验会议。
- 「增量成长，而非一次搭建」——这是最妙的一条。Brooks 1975 年说「为舍弃而计划」，1995 年自己修正说这话「太简单」。而 AI 生成把丢弃成本打到接近零：生成、看一眼、扔掉、重来，一天几十个来回。1975 年没人舍得扔代码，2025 年没人舍不得。Brooks 修正的方向，AI 免费发放给了所有人。
- 半条：「培养卓越设计师」——AI 把顶尖程序员的习惯（先写测试、命名规范、防御式写法）蒸馏进了补全建议，等于给每个新手配了个高级工程师坐旁边。这半条为什么只算半，下一节说。
所以第一个结论站得住：次要问题这一堆，AI 不但解决了，部分项目还超额兑现。「如何说」这个层面，Brooks 判过的九颗银弹全没做到的事，AI 做到了。
但是。Brooks 的算术论证在那儿等着呢：这部分占不到一半工作量。一半清零，整体最多翻倍——数量级的门都没摸到。
真正的问题在另一半。
没死的半个：三个病还在恶化
病一：复杂度——生成速度超过了消化速度
Brooks 的原话：「软件的复杂度是必要属性，不是次要因素。」
AI 不生产复杂度，但它让复杂度的净流入变快了：代码的生成速度是人的十倍，而对代码的理解速度，还是人的旧速度。多出来的部分堆在哪儿？堆在仓库里。
GitClear 分析了数亿行代码的纵向数据，2025 年报告的标题就很直白：AI 时代的代码质量。三个硬发现：重复代码块数量涨到约四倍；2024 年成为有记录以来第一次「复制粘贴的行数超过移动（重构）的行数」的年份——行业最佳实践发生了肉眼可见的逆转；短期翻修率持续上升，说明大量代码写完不久就被推倒重来。2026 年的后续报告进一步给出：单次提交内的复制粘贴增加 41%，代码块重复增加 81%，错误掩盖型结构（比如把异常吞掉的写法）增加 47%。
用人话说：AI 生成的代码正在变成新的祖传代码，而且繁殖速度是自然状态的数倍。Brooks 第 1 章那个焦油坑比喻——「很多大型和强壮的动物在其中剧烈的挣扎」——现在坑里进来的动物，是自己繁殖的。
病二：不可见性——代码越多，系统越看不见
「软件的客观存在不具有空间的形体特征。」Brooks 把不可见性列为四大固有属性之一，1986 年他就说图形化编程救不了它，「就像盲人摸象一样」。
AI 时代这个病有了新病灶：上下文窗口。一个资深工程师对系统的全貌把握，受限于他能装进脑子（和装进模型上下文）的代码量。代码量涨十倍，能看全的人从「少数」变成「没有」。vibe coding 之所以叫 vibe——「忘掉代码的存在」——一半是潇洒，一半是真的看不见。你 review 不了一份你没读过的代码，你只是习惯了它存在。
病三：Brooks 法则换了宿主——Agent 也要沟通预算
「向进度落后的项目中增加人手，只会使进度更加落后。」为什么？沟通成本按 n(n-1)/2 增长，加人先加沟通，再吃进度。
第一眼看，AI 队员完美绕过这条法则：它不参加站会、不需要 onboarding、不和你吵架。加 Agent 不加沟通边——图论上成立的诱惑。
但 2025 年 6 月 Anthropic 自己的工程博客泼了盆冷水：他们复盘自家的多 Agent 系统，发现 Agent 的 token 消耗约为普通对话的 4 倍，多 Agent 系统约为 15 倍。多出来的部分花在哪儿？任务分解、结果汇总、Agent 之间的信息对齐——这不就是站会吗。沟通开销没有消失，它换了个计价单位，从「人时」变成了「token」。n(n-1)/2 的那个 2，如今按 API 账单结算。
而单一开发者的版本更扎心。METR（一家专门评估 AI 能力的研究机构）2025 年 7 月发了篇随机对照试验：16 位资深开源开发者，在自己维护了多年的成熟仓库上做 246 个真实任务，一半任务用 Cursor + Claude，一半不用。结果：用 AI 反而慢了 19%。而开发者自己事前预测会快 24%。
预期 +24%，实际 -19%。这中间 43 个百分点的落差，就是「次要问题的提速被根本问题的摩擦吃掉」的直接测量：在复杂系统里，验证 AI 产出、对齐上下文、纠正跑偏的成本，超过了生成省下的时间。Brooks 的账本没有过时，只是换了记账人。
病四（附赠）：第二系统效应，AI 是最好的放大器
「第二个系统是设计师们所设计的最危险的系统」——第一次做系统的人克制，把野心都攒给下一次，于是第二个系统功能过剩。OS/360 就是这么肿的。
AI 时代这个心理病被结构性放大了：生成一个功能的成本趋近于零，「要不要这个功能」的决策纪律就崩了。反正让 Agent 加一个也就五分钟——于是 prompt 越说越长，需求越垒越高，每个用 vibe coding 做出来的 v2 都带着 OS/360 的体脂率。功能膨胀不需要野心家了，只需要一个不会说「不」的执行者。
判决书：史上最强的铜弹
证据链摆完了，现在用 Brooks 自家的验收标准来宣判。他 1986 年给每颗候选银弹两个问题，我们原样问 AI Agent：
第一问：你打的是根本困难还是次要困难？
「如何说」——全灭。历史上没有任何技术做到这个程度的次要困难清剿。但「决定说什么」——测试顾问、需求判断、系统概念结构——AI 仍在外面敲门。它写的 prompt 越长，越印证 Brooks 引用的 Parnas 那句批评（当年打在「自动编程」身上）：「大多数情况下所给出的技术说明本质上是问题的解决方法，而不是问题自身。」你给 Agent 的 prompt，从来都是方案，不是问题。
第二问：次要部分占够九成了吗？
Brooks 自己 1995 年就交了底：不到一半。三十年过去，AI 把这不到一半压得更低——但这道算术题的结论反而更硬了：分母里那另外一大半，纹丝没动。
所以判词是：AI 是有史以来最强的一颗铜弹。这个量刑有出处——Brooks 1995 年复盘面向对象时就用的这个词：实质性贡献，但非数量级。OOP 是铜弹，AI 是含铜量更高的铜弹。差异在于：OOP 加速的是第九年（Coggins 说产品族第五个项目才异乎寻常地快），AI 加速的是第一天。
但有两个「但是」，判完必须说，不然不公平：
但是一：Brooks 当年给专家系统留过活口。九颗银弹里判词最温和的就是它：「专家系统最强有力的贡献是给缺乏经验的开发人员提供服务，用最优秀开发者的经验和知识积累为他们提供了指导。」——四十年后看，这句话描述的就是 LLM 的预训练。他预言的最优秀实践的传播，真的发生了。这是老书里最准的一枪。
但是二：Agent 确实第一次摸到了「决定说什么」的边缘。自己拆任务、自己规划步骤、自己回头改——这超出了 1986 年的框架。我会盯着这条线：哪天 AI 稳定地做对了「问题是什么」而不是「方案怎么写」，本文的判词作废重审。目前，还没过线。
2025 MIT 三公司 4800 人 RCT 提速 26%
2025-01 Amodei：2026 年底 AI 写绝大部分代码
2025-02 Karpathy：vibe coding 成型
2026 GitClear：错误掩盖型结构 +47%
2025-07 METR：资深开发者 246 任务 RCT 慢 19%
2025-06 Anthropic：多 Agent token 消耗 15 倍
收个尾
回到标题的问题：AI Agent 时代，人月神话的问题都解决了吗？
解决了一半——被解决的那一半，是 Brooks 早就判了「即使清零也不够」的那一半。另一半（复杂度、一致性、可变性、不可见性，加上人月、第二系统、概念完整性）一个没死，其中三个还在 AI 的喂养下加速生长。
这不是 AI 的失败，是软件的宿命。生成越容易，世界对软件的要求就越多越怪——高速公路没有消灭通勤，电梯没有让楼变矮，Word 没有让写作变快。供给每上一个台阶，需求就吃掉一个台阶，剩下的难度原地涨价。Brooks 1986 年那句「软件开发上的困难是决定说什么，而不是如何说」，四十年了，还是这个行业的判词。
所以真正值得焦虑的不是「AI 会不会写代码」，是 Brooks 第 4 章那个老问题在 AI 时代的变形：当实现变得免费，概念完整性就成了唯一的贵东西。十个工程师带十个 Agent 各写各的，系统的概念向谁收敛？
这是下一期要拆的：AI 时代的结构师——当刀免费了，掌刀的人怎么当。
适用与不适用
这篇的判断适用于：中大型软件系统、多人协作、长生命周期的产品开发——人月神话的主战场。
不适用于：一次性脚本、个人小工具、验证型 demo——这类场景 AI 确实是接近银弹的存在，因为它们整个儿都活在「次要问题」那半边，造完即扔，不进入维护。拿 demo 的爽感反驳本文，等于拿食堂大锅饭反驳米其林后厨的复杂度。
另外，METR 那个 -19% 是「资深开发者 × 熟悉的成熟代码库」场景；新手或陌生代码库上 AI 多半仍是正收益。证据要用在它量过的地方。
聊两句
你项目里现在 AI 生成的代码占多少？
扣 1：基本没有，还是手写为主 扣 2：一半以上，review 时心里其实没底 扣 3：全 AI 生成为主，我已经不看代码了（勇士，请留个项目名……不对，请保重）
数据和出处都在文中：想核对，书是《人月神话》二十周年纪念版第 16、17 章，研究是 METR 2025、GitClear 2025/2026、MIT 2025，都搜得到。哪条证据你觉得我量错了，评论区拍过来。