ARTICLE · 1202519
重读《人月神话》:AI 就是那个「加了一百个人」的项目
「拆书精进」· 拆书 04。这个栏目只拆读完能改做法的那部分，不写读书笔记。
1975 年，Fred Brooks 在《人月神话》里写下一句被引用了五十年的话：向一个已经延期的项目里增加人手，只会让它更延期。
他给过一笔账：n 个人之间要维护的沟通路径是 n(n-1)/2 条。人数翻一倍，路径变成四倍。
五十年后，我们干的是同一件事——给每个项目加了一堆不要工资、不用开会、也不会抱怨的「人」。
那这次能成吗？
这是拆书系列的第 4 篇。前三篇分别是《Google 软件测试之道》《探索式软件测试》《持续交付》。想按顺序拿走这几篇里的清单，文末有关键词。
沟通没有消失，它换了个名字
Brooks 说的沟通成本，今天换了个名字叫「上下文」。
你跟同事说一句「这个接口上周改了」，他记在心里。你跟 AI 说一次，它只记得这一次对话。明天开一个新窗口，它不知道上周发生过什么。
AI 省不掉你的沟通，它只是把沟通时间换成了上下文次数。次数不会因为对方不抱怨而变少。
所以真正该问的不是「AI 快不快」，而是「这件事我要说多少遍」。
假设你上午跟它确认过判定标准，下午开个新窗口继续，它按自己的理解又给了一套，和上午那套正好相反。这不是它变笨了，是它压根不知道上午发生过什么。
一件事如果需要你反复解释三遍以上，它就不该交给一次对话去解决。
「没有银弹」这句话要拆开看
Brooks 在 1986 年写过一篇《没有银弹》，后来才收进《人月神话》的二十周年纪念版。他在里面把复杂度分成了两种。
一种是附属复杂度：把想法写成代码、把重复的活再干一遍、把结果整理成报告。
一种是本质复杂度：这个功能到底该不该这么做、什么结果才算对。
AI 拿下的是前一种，后一种它一点没碰。
AI 干掉的是打字，不是判断。
这句话解释了一个我没想通的矛盾：工具一年比一年强，交付却没见变快。因为卡住交付的那部分，从来不是打字。
测试里最难的那部分，它一直没碰
把这两个词放进测试工作里，边界很清楚。
写用例、造数据、把结果整理成报告，是附属复杂度，这些活 AI 做得又快又稳。
「这个改动会不会影响支付链路」「这条断言为什么该写在这儿」「今天这批结果我能不能签字」，是本质复杂度。
后面这三件事，恰好是一次线上事故里真正会被追责的部分。
最好的队伍结构，五十年没变
书里有一章叫「外科手术队伍」，结论出人意料：产能最高的结构不是「很多人分工」，而是「一个主刀医生加少量助手」。
理由还是沟通成本。十个人一起写代码，光对齐就吃掉大半时间。
那支队伍的分工是这样的：主刀医生负责全部产出，助手各管一件事——有人管工具，有人管文档，有人专门去验证。所有人围绕一个人的判断转，而不是十个人各自下判断。
这套结构放到今天的意思很明确：AI 应该被放在助手那些位置上，不该被放在主刀的位置上。
换句话说，一个测试 + 一套固定流程 + AI，比五个人 + 五个 AI 工具快。
AI 不是一支团队，它是一个人。你不会给一个新人同时派五件不相干的事，也不该这么对 AI。
本周可以试的一件事：把你交给 AI 的任务全列出来，标一下哪几件需要它「记得住上文」。超过两件的，拆成独立任务，每次只喂这件事需要的上下文。
为什么有人快了很多，有人反而更乱
区别不在用了哪个模型，在把 AI 放在队伍的哪个位置上。
放在助手的位置上，它接走的是那些不需要判断的活，你反而腾出了想事情的时间。
放在主刀的位置上，它会按自己的理解替你做决定，你就得花更多时间去发现和纠正这些决定。
第二种情况下，AI 越快，你补得越累。
一个人 + AI 的协作清单
· 一件任务一个窗口，做完就关，别让它背着上一件事的包袱
· 每次开头重述一遍「这件事做到什么程度算完」
· 先让它复述一遍它理解的任务，确认无误再让它动手
· 产物必须落到文件或清单上，只停在对话里的结果等于没做
· 定期让它把「它以为的规则」写出来，你审一遍
后台回复「银弹」，领这份清单。
《人月神话》讲的是六十年代的软件项目。书里那些因为人多了而失效的东西，今天一个都没少——这也是我把它排在拆书第 4 本的原因。
下一篇拆哪本，你在评论区报书名，票数最高的我下周读。明天这个号会写一篇更贴身的：AI 正在把测试岗拆成三种，你在哪一种里。
来源与说明：《人月神话》（The Mythical Man-Month，Fred Brooks，1975）与《没有银弹》（No Silver Bullet，1986，后收入该书二十周年纪念版）为本文引述来源；「沟通路径 n(n-1)/2」「外科手术队伍」「本质复杂度与附属复杂度」均为原书观点。「AI 干掉的是打字不是判断」「AI 是一个人不是一支团队」，以及文末那份协作清单，是作者结合自身工作后的个人整理。
