有一个星期，《纽约时报》一直在测试一段不是自己写的软件。这段软件负责给报社新的在线资料库「信息银行」更新数据，共 12029 行代码，时报对照 171 项独立功能逐项检查。IBM 关于这个项目的报告，只用一句话交代结果：「一个错误也没有发现。」
做这套系统的团队人不多，样子也怪。一位首席程序员设计系统、写下核心；一名后备在旁边并肩干活；一名资料管理员把每个程序、每次测试运行都整理归档；还有几名程序员，在密切监督下写剩下的部分。IBM 说，这种安排「概念上类似外科手术团队」。完整经过见案例。
一个人动刀
一个人主刀设计和编写核心，其余人都为这个人打下手。
弗雷德·布鲁克斯管过 IBM System/360 的软件开发。1975 年，他在《人月神话》里专门写了一章，叫「外科手术队伍」。他从一个两难说起。程序员之间差距极大：在他引用的一项研究里，一群有经验的程序员当中，最好的和最差的，生产率平均差了约十倍。而每多一个人，就多一份沟通。所以，为了效率，也为了他说的「概念完整性」，布鲁克斯写道，「人们更愿意让少数几个好头脑来做设计和构建」。可是做真正的大系统，小团队又太慢：OS/360 高峰时有一千多人在干。
他找到的出路，来自 IBM 的哈伦·米尔斯。大工程的每一块交给一个团队，团队要「像外科手术团队那样组织」，别像屠宰场里那样大家一起下刀。换句话说，「一个人动刀，其他人全力支持他」。
布鲁克斯接着勾画了一支完整的队伍，大约十个人：
- 主刀：也就是米尔斯说的首席程序员，自己写规格、做设计、写代码、做测试、写文档。
- 副手：熟悉全部代码，是主刀商量想法的对象，也是出事时的保险，但不对任何一部分代码负责。
- 一名行政和一名编辑：让主刀几乎不用在钱、人和打磨文档上花时间。
- 一名程序文员：把每次运行、每个版本都存进一个共享的库。
- 一名工具匠、一名测试员和一名语言专家：主刀随时可以找的专门人手。
十个人一起干，但用布鲁克斯的话说，系统是「一个头脑的产物」，最多两个。
为什么行得通
布鲁克斯拿主刀加副手，去和两个分工合作的程序员比。一是活不拆开：主刀和副手都了解全部设计、全部代码。二是分歧不用谈判，主刀说了算。队里其他人各有专长，布鲁克斯认为，这让沟通线路简单得多：大多数人只和主刀打交道，彼此不必来回协调。
布鲁克斯说，米尔斯这套想法里有一点「绝对关键」：让编程「从私人手艺变成公开的实践」，每次运行全队都看得见，每个程序都算团队的财产。这是程序文员的活，在时报项目里由资料管理员来做。首席的工作，从来不只存在首席一个人的脑子里。
做更大的系统，布鲁克斯的办法是拆头脑，不拆代码。把 200 人编成若干支手术队伍，需要互相协调的就只剩 20 位主刀，再由一位架构师设计整体。
哪里会出问题
这套模式成败全系于主刀。报告时报项目的特里·贝克说得很直白：这支团队「相对有经验」，「表现高于平均水平」。布鲁克斯称之为「一次小规模的单项测试」。多年后米尔斯写道，这个想法流传开以后，各式各样的首席程序员都冒了出来，「从难伺候的大牌」到「办事员式的管理者」，挑人时都绕开了这个想法赖以成立的「创造力和智力上的掌控」。「难怪」这样的团队「并不总是顺利，有些酿成了真正的灾难」。
设想一家三个人的设计工作室：创始人审每一稿、写每一封给客户的邮件，两位新人负责找文件、改图片尺寸。创始人的眼光也许能把作品撑住。可创始人只要离开一周，可能就什么都交不出去，两位新人也可能一直学不会自己带项目。没有真正的副手、也没有人人都能读的共享资料库的手术队伍，就带着这种风险。
AI 时代的外科手术队伍
写代码的 AI 智能体，也走到了相似的形状。在 Claude Code 里，主智能体可以把旁支任务交给子智能体。每个子智能体「在自己的上下文窗口里运行」，只交回一份摘要，主对话就不会被搜索结果和日志塞满。这很像布鲁克斯的支持人员：测试员、工具匠、文员，干主刀需要有人干、自己却不必记着的活。
那些告诫也一样适用。Anthropic 介绍自己的多智能体研究系统时说，这类系统消耗的 token 大约是普通对话的 15 倍，而且「大多数编程任务里，真正能并行的部分比研究任务少」。开发编程智能体 Devin 的 Cognition 公司在 2025 年提出，「行动带有隐含的决定，相互冲突的决定会带来糟糕的结果」，并建议默认只用一个掌握全部上下文的智能体。它举的例子正是 Claude Code：截至 2025 年 6 月，它的子智能体「通常只负责回答一个问题，不写任何代码」。
这样看，设计上要的仍是一个掌握全局的头脑，如今常常是一个模型，再配上帮它搜索、测试、总结的帮手。这个头脑够不够好，正是米尔斯在 1970 年代面对的问题。
在时报，首席和后备写的程序，按贝克的统计，「大约每一人年的工作出一个错误」。两个人把整套系统装在心里，其余的人让这件事成为可能。