# AI都能写代码了，《人月神话》该进博物馆了吗？ - URL: https://davidyin.dev/writing/200-20260715-brooks-law-ai-coding/ - 作者: David Yin - 发布: 2026-07-15 - 标签: 人月神话、布鲁克斯定律、AI 编程、软件工程、智能体 - 摘要: AI都能写代码了，《人月神话》该进博物馆吗？作者的答案：布鲁克斯50年前的定律没被推翻，反而被放大——AI压掉的只是样板代码这类偶然复杂性，本质复杂性（造什么、边界画在哪）换什么工具都绕不开；把「人」换成「AI助手」，协调成本只是换了战场，还多出「智能体焦油坑」。一个人干活省下的是打字时间，判断那道关还得自己站住。 这一年多，我几乎每天都在用AI写代码，脑子里一直转着同一个问题：AI都能写代码了，《人月神话》是不是该进博物馆了。 我把这半年看到的说法翻来覆去想了一遍，发现大家吵错了地方——这本书从来不是教你怎么写代码的，它讲的是一群人凑在一起干活会出什么问题。AI进场之后，这个问题没有消失，只是换了个更难缠的版本。 先说结论——布鲁克斯那条50年前的定律，没被AI打进历史，反而被它放大了。 ## AI压下去的，是样板代码和低风险调试 布鲁克斯在《人月神话》里把软件开发的难度分成两半。 一半叫偶然复杂性——写增删改查、配环境、找语法错误、补单元测试，这些活儿麻烦，但不是问题本身带来的，是工具和流程带来的额外负担。理论上，换一套更好的工具就能把它压下去。 另一半叫本质复杂性——要造出一个什么样的东西，边界画在哪，给谁用，牺牲什么换什么，这是问题本身自带的难度，换什么工具都绕不开。 AI这一年多干的事，几乎全在第一半里。写一段增删改查、改几行报错、跑一遍测试用例，AI比大部分工程师又快又稳。网上说人月神话过时了的声音，举的例子也几乎全是这些——沟通成本降了，写代码的时间省了，调试的痛苦少了。 这些说法都是真的。但它们证明的，只是偶然复杂性被压缩了——**没有一条证据碰到本质复杂性头上**。 ## 人多添乱，AI多也添乱 布鲁克斯那条定律的原话是：给一个进度已经落后的项目增加人手，只会让它更落后。 原因很直白——沟通成本涨得比人手还快，人手本身够用。一个团队加一个人，新人要花时间学，老人要花时间教，团队里每加一个人，两两之间要对齐的沟通路径就多一截。5个人两两对齐是10条线，加到10个人，直接涨到45条——人数没翻几倍，要对齐的线却翻了好几倍。 把"人"换成"AI助手"，这条账没有消失，只是换了个记法。团队里塞进几个AI助手，产出的代码量确实上去了，但每一段代码都要有人看、有人判断该不该合并进主干、有人对它可能带来的隐患负责。代码库比人手写的时候更庞大，评审的工作量、需要拍板的判断，一样没少，甚至更多——多出来的这部分，业内有人管它叫"智能体焦油坑"：AI越写越快，人越审越累，工作量从"写"转移到了"看"。 沟通不再只发生在人和人之间，也发生在人和AI之间，还多了一层"这段AI写的代码要不要被信任"的判断。**协调成本没降，是换了个战场。** ## 没有银弹，AI也不是 布鲁克斯还写过一篇更狠的文章，叫《没有银弹》。里面有句话，放到今天照样成立：不存在一种单一的技术或管理手段，能让软件开发的效率在十年内提高十倍——因为拖时间的那部分难度，来自问题本身，不来自工具。 这句话是1986年写的，那会儿还没有AI。但它精准踩中了这场争论的死角：大家在吵AI有没有用，吵的是一个从一开始就问错了的问题。AI当然有用，它把偶然复杂性削掉了一大块，这已经很值钱。但如果指望它顺带把"要造什么、造多大、给谁用"这些判断也一起解决，那是在等一颗从没存在过的银弹。 这场争论里吵得最凶的两派声音，说的都是同一件事的两面：一边在说AI省下了大把重复劳动的时间，这是真的；一边在说项目该怎么设计AI还是帮不上忙，这也是真的。他们不是在反驳对方，是各自站在偶然复杂性和本质复杂性两块地上喊话。 ## 一个人干活，是AI时代甩过来的新问题 布鲁克斯那条定律算的是人和人之间的协调成本——几个人凑在一起，两两对齐的沟通线随人数往上窜，这套账从两个人才开始成立。我一个人干活，没有团队，没有"两两对齐"这道账要算，那条公式在我这儿本来就用不上。 但用不上不等于没事——一个人剩下的，是另一种账：不是协调成本，而是判断带宽。这是两个完全不同的问题，只是AI进场之后，两个问题一起冒出来了。 我自己是这场变化里泡得比较深的那批人——一个人干活，没有团队分担，AI用得比谁都勤。 先说大实话：活儿是真快了。原来搭一个功能模块，写代码、跑测试、改bug要两天，现在两三个小时能出一版能跑的。这一年多省下来的时间，大概能顶半个助理。 但我一点没觉得轻松，反而更累了。 原来一个团队里，判断这件事是分着扛的。要不要用这个技术方案、这个接口设计合不合理、边界条件考虑周全没有，资深同事把一道关，产品经理挡一道关，测试挡一道关。现在AI把写代码的活儿接过去了，判断的活儿一点没少，反而全压到我一个人身上——要不要接受它写的这段代码，这个设计选型对不对，边界该怎么划，没人替我兜底。 这几个月我常常撞见同一个场景：AI写出的方案能跑，测试也全绿，我却要盯着看好一会儿，才想明白问题不在代码对不对，在这个方案换个数据量、换个场景还成不成立。AI不会替我把这个问题想一遍——它没理由想，它只负责把我要求的东西实现出来，判断这事从来不在它的活儿范围里。 省下来的，只是打字的时间。**判断这道关，还是得靠人自己站住。** 这场争论到现在也没吵出赢家，两边说的其实是同一件事的两半——AI是真的把写代码这件事变简单了，布鲁克斯那套"人多不一定好办事"的账，也是真的没被抹平，只是从团队记账，改成我一个人在记。这本书从一开始讲的就不是代码怎么写，而是人在干活的时候怎么扛住判断——AI接过去的只是其中一半，剩下那一半，还得靠我们自己扛。 --- 你如果也天天用AI写代码，不妨自己回想一个具体场景：AI写出的方案能跑、测试也全绿，你后来才发现问题根本不在代码本身——是哪一次，你怎么看出来的？ --- **信息来源**： - 弗雷德·布鲁克斯：《人月神话》（The Mythical Man-Month，1975年初版） - 弗雷德·布鲁克斯：《没有银弹——软件工程中的根本和次要困难》（No Silver Bullet, 1986）