弗雷德·布鲁克斯要离开 IBM 的时候，公司掌门人小托马斯·沃森问了他一个问题：你管过 System/360 的硬件，也管过它的软件，这两样到底有什么不同？
这个问题问得很准。硬件后来成了 IBM 最成功的大型机。软件就是另一回事了。操作系统 OS/360 很难写，而且晚了。布鲁克斯接手的时候，已经有一千多个程序员扑在上面。
布鲁克斯说，这个问题太难，没法当场回答，他得好好想想。
后来他交出的答案是一本书。
最顺手的救法
上线日期眼看要拖。活是实打实的，期限也是实打实的，团队已经很累了。于是你去要人，上面调来两个能干的人帮忙。
这看上去是最负责任的做法，也是最常见的做法。软件作家史蒂夫·麦康奈尔引过一项英国的研究：项目严重失控的经理里，大约一半想靠加人把它拉回来。
接下来的两周是这样过的：团队里最能干的那个人，每天上午都在讲代码、讲客户、讲每一个奇怪决定背后的来龙去脉。周会越开越长，因为要听的进展多了。新来的两个人聪明又上心，谁也没偷懒。
日期又拖了。
九个女人，一个月
布鲁克斯最早在 1974 年 12 月的《Datamation》杂志上写下这条规律，第二年又写进《人月神话》：给已经晚了的软件项目加人，只会让它更晚。
他还打了个让人过目不忘的比方：「生一个孩子要九个月，派多少个女人去都一样。」
书名点破的就是这个误会。「人月」是经理们估算工作量的单位：一个人干一个月。这个单位悄悄假设了人和月可以互换。一件活是 12 人月，那 4 个人就该 3 个月干完，12 个人 1 个月干完。摘棉花确实是这样，十个人就是比一个人快十倍。布鲁克斯想说的是，大多数项目更像生孩子。
三笔账
两个厨师做饭比一个快。十个厨师挤在一间小厨房，一晚上都在喊「借过」。
一个已经晚了的项目，每加一个人，就要多付三笔账。
有些活拆不开。 必须一步接一步做的事，人再多也快不了。布鲁克斯举的例子是调试，在软件里它往往就是一步接一步的。
新人要学。 总得有人教他们这个项目怎么回事。教的人只能是少数几个已经懂行的人，而一个晚了的项目，最缺的恰恰就是这几个人的时间。
所有人都要对齐。 每两个需要配合的人之间，就是一条沟通线。如果人人都要和别人协调，3 个人有 3 条，10 个人有 45 条。人是一个一个加的，要说的话却多得快得多。
你那两周的救火，三笔账一笔都没少付。计划里只数了人手，忘了把人连起来的成本。
定律也有弯的时候
布鲁克斯自己也知道这是简化。二十年后，他仍然说这条定律是「最好的零阶近似」。
麦康奈尔在 1999 年唱了反调。他说，大多数晚了的项目，比经理以为的晚得多，不是还差三周，而是还差半年。有这么长的时间，新人来得及上手。可连麦康奈尔也承认，每个项目都会走到一个点，过了这个点，加人只会更慢。两人争的是这个点在哪，答案取决于两件事：活能不能干净地拆开，新人要老人教多久。
所以，能从坑里爬出来的团队，改的往往不是人数。有的砍范围，让必须经过老人之手的活少一些。有的早早挪日期，并且明说。还有的把新人放到一块能整个交出去的活上，有自己的输入、自己的终点。
十秒钟，十个 AI
帮手变了。十个 AI 智能体几秒钟就能开起来，谁也不用花几个月熟悉代码，看上去天生就能破这条定律。可每一个都得先拿到项目的背景、工具和规矩，才干得了正事。上手的账换了个样子，并没有消失。
沟通的账也还在。2025 年 12 月，谷歌的研究者发表了一项研究，测了 180 种智能体、模型和任务的组合。有一项财务分析，能拆成互不相干的几块：收入归一个，成本归一个，竞争对手归一个。这时候一个有协调者的 AI 团队，比单个 AI 强 80.9%。
接着他们换了一项规划任务，每一步都取决于上一步。他们试过的每一种多智能体组合都变差了，差了 39% 到 70%。研究者的解释听起来就像布鲁克斯：智能体把太多力气花在互相沟通上，推理本身被切碎了。几个 AI 各干各的、到最后才把结果汇总时，错误放大到了 17.2 倍；有一个协调者中途把关，就降到 4.4 倍。
在那项拆不开的任务上，一个 AI 单干，赢了研究者搭起来的每一支 AI 团队。