第 7 章 · 为什么巴比伦塔会失败

题记直接引了《创世纪》11:1–8 的原文。这一段之所以被放在这一章，是因为作者要把它当作一个工程项目来复盘。

这一章讲了什么

作者称巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，也是第一个彻底失败的工程。他逐条检查这个项目的先决条件：

五个条件全都满足，项目还是失败了。作者说他们缺两样东西：交流，以及交流的结果——组织。无法相互交谈，就无法合作；合作无法进行，工作就停顿。而在史书的字里行间能看出来：交流的缺乏导致争辩、沮丧和群体猜忌，部落开始分裂——大家选择了孤立，而不是互相争吵。

现实完全对应得上。左手不知道右手在做什么，于是进度缓慢、功能不合理、系统缺陷一一出现。作者举了一个极具体的例子：程序覆盖功能的实现者发现应用程序很少用到这个功能，于是降低了它的速度；与此同时，队伍里其他人正在设计在很大程度上依赖覆盖速度的监控程序——覆盖速度的变化于是成了主要的规格变更。这类变更必须从系统角度衡量，并且公开、广泛地发布。

那么团队靠什么交流？他给了三条途径：非正式途径（清晰定义小组内部关系、充分利用电话，形成对所写文档的共同理解）、会议（常规项目会议，各团队轮流做简要技术陈述，能澄清成百上千的细小误解），以及工作手册。

“项目工作手册"是本章篇幅最大的一节。作者先纠正一个误解：它不是一篇独立文档，而是对项目必须产出的一系列文档进行组织的结构——目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录，全部必须归属于这个结构。

为什么需要一个结构？一是技术说明几乎必不可少，而结构保证文档规范而不是杂乱无章，后来的文字能找到它该在的位置；二是控制信息发布——“控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中”。做法是先给所有备忘录编号，更好的是用树状索引结构，并让子树维护各自的发布列表。作者点出规模效应：10 人的项目简单编号就够，100 人的项目若干线性索引常常够用，到了 1000 人且分散在多地，结构化手册的必要性和规模要求都陡增。

OS/360 的实践细节很值得看。他们决定每个编程人员都要了解所有材料，因此每间办公室保留一份工作手册拷贝；用活页夹替换变更页来实现实时更新，靠计算机文本编辑把周转时间压到一天以内。变更页要满足两种追问：第一次收到时要知道"修改了什么”，事后咨询时要知道"现在的定义是什么"。所以变更页上要用页边竖线标记发生变动的行，并附一段简短的独立说明，记录变更的重要性与批注。

这套机制稳定运行了六个月，然后被自己的重量压垮：手册厚达五英尺，一百份叠起来比 Time-Life 大厦还高；每天分发的变更页约两英寸厚，归档约 150 页，日常维护占据每个工作日的大量时间。他们改用微缩胶片，体积减少 18 倍，省下大量金钱。但作者没有把微缩胶片当万能药，他诚实地列出代价：正是因为文字归档笨拙，才确保了所有变更都被阅读，而微缩胶片让维护过于省事，除非变更说明与变更胶片一起分发；而且读者无法在胶片上做标记和批注。他的结论是：微缩胶片是好方法，但应作为文字工作手册的补充。至于未来的方向，他提到了可直接访问的文件——从显示终端查阅、修订日期与变更标识条、每日小结按后进先出保存，并点名 Engelbart 等人在 ARPA 网络项目中的实践，以及 Parnas 提出的更彻底的方案。

最后是"大型编程项目的组织架构"。他先算了一笔交流账：n 个工作人员之间有 (n²−n)/2 个相互交流接口，还有将近 2n 个必须合作的潜在团队。团队组织的目的是减少所需的交流与合作的数量，手段是人力划分与限定职责范围——树状管理结构之所以出现，是因为管理角色不可重复，它本质上是权力和责任的结构。但作者提醒：交流的结构并不受树状约束，交流是通过网状结构进行的。

他给了每棵子树必须具备的六个要素：任务、产品负责人、技术主管（结构师）、进度、人力的划分、各部分之间的接口定义。其中两个角色需要分清：

• 产品负责人：组建团队、划分工作、制定进度表，争取并保证资源；主要工作是向上的沟通和水平的沟通；建立团队内部的沟通与报告方式；确保进度目标实现，并根据环境变化调整资源与团队架构。
• 技术主管：构思设计、识别子系统、指明外部样貌、勾画内部结构；提供设计的一致性与概念完整性；控制系统复杂程度；解决技术问题或调整设计。他的沟通在团队中是首要的，工作几乎完全是技术性的——作者借用一句谚语，称他为"攻坚小组中的独行侠"。

两者的关系有三种，作者说三种在实践里都成功过。第一种是同一个人兼任，适合 3–6 人的小队；大型项目里很难，因为兼具两种技能的人极稀缺（“思考者很少，实干家更少，既是思考者又是实干家的太少了”），而且两个角色在大项目里都要全职甚至加班。第二种是产品负责人当总指挥、技术主管当左右手：难点在于技术主管不参与管理时如何建立技术权威；所以产品负责人必须预先声明其技术权威、在绝大多数测试用例上支持他的技术决定，两人还要在基本技术理论上观点相近、在主要技术问题出现前先私下讨论。作者甚至提到要用办公室大小、地毯、装修、复印机这类微妙的状态特征去暗示技术主管的威信——“尽管他身在管理团队之外，但他是决策的根源”。这种组合很有效，却很少被采用，好处是能用上不擅长管理的技术天才。第三种是技术主管当总指挥、产品负责人当左右手，作者引了海因莱因《出售月球的人》里的一段：Harriman 把总工程师 Coster 从卡车合同和客户电话里隔离出来，给他换办公室、加沙发，再配一个"除了建造飞船的微妙细节外什么都不用你担心"的下属。

他的结论是分场景的：对小团队，第三种最好（这正是第 3 章的外科手术队伍）；对真正大型项目中的一些开发队伍，产品负责人作为管理者更合适。全章收在一句话上——巴比伦塔可能是第一个工程上的彻底失败，但不会是最后一个：交流，以及交流的结果——组织，是成功的关键；积累这方面的经验和能力，同提高软件技术本身一样重要。

我的判断

• 这一章与第 6 章构成一对：第 6 章讲决策如何向下贯彻（手册、会议、日志），本章讲信息如何在横向流动（工作手册、组织架构）。两章合起来才是"交流"的完整问题，作者把它们分开处理是对的。
• 最锋利的是那个"降低覆盖速度"式的例子：局部最优的调整，在系统层面造成规格变更。它揭示的不是某个人粗心，而是缺少一个制度动作——变更必须被系统性地评估与发布。这一点至今仍是最常见的工程事故来源。
• “控制信息发布不是限制信息，而是确保信息到达需要它的人"这句话，我完全认同，且值得当作文档系统的设计目标。它解释了为什么"把所有东西都放进一个共享盘"并不等于信息通畅：没有结构，等于没有发布。
• 作者对微缩胶片的评价是我判断他诚实的证据：他既承认它省了钱和体积，也承认笨拙本身就是一种保障，微缩胶片让维护太容易，反而可能没人读变更说明。这种"改进会削弱原有隐式约束"的观察，比结论本身更有价值。
• 我保留的是"三种关系都成功过"的说法。它可能意味着三种都能用，也可能意味着成功的样本被事后解释成了某种关系；作者没有给出判断依据。我个人更认同他最后的分场景结论，而不是"都可以”。
• 六个基本要素里，最容易被漏掉的是接口定义。任务、负责人、结构师、进度、分工这五样在项目启动时几乎总会被写上，接口定义却常被默认成"以后自然会对齐"，而它恰恰是巴比伦塔真正缺的那一块。

和我手上的工作有什么关系

• 我自己最常犯的错，正好对应本章开头那个先决条件表：目标清晰、时间够、技术可行、工具齐备，于是默认"当然能做成"。少数几次翻车都不是技术问题，而是我和昨天、上周的自己失联——也就是左手不知道右手在做什么，只不过两只手都是我。
• 工作手册的思路，直接解释了我为什么坚持维护 AGENTS.md 与 docs/sessions/：前者是索引结构（相当于树状索引），后者是变更页与归档。这一章还给了两条可操作的改进：给每次变更标记"改了什么"，以及随时能回答"现在的定义是什么"。
• “每个编程人员应了解所有材料”，在小规模协作里的等价物是让每个参与者都能拿到全部上下文，而不是按角色切分信息。这一条我打算在站点里继续贯彻：约定文档公开可读，会话记录可追溯。
• 产品负责人与技术主管的组合分析，对"我 + Agent"这种编队有直接映射：我兼任两者，属于作者说的第一种安排——他只推荐给 3–6 人的小队，这正好是小规模配合 AI 的团队规模。超过这个规模，就该有人专职做概念、有人专职做交付。
• 接口定义这条我准备马上用起来：给这个站点补一份"约定清单"，把页面结构、front matter 字段、锚点规则、构建入口全部写明。以前这些散在几次对话里，正是"以后自然会对齐"的典型形态。

一句话记住

目标、人力、材料、时间、技术全都齐备的工程照样会失败——缺的是交流，以及交流产生出来的组织；而组织的第一份产物，就是把一切文档结构化的工作手册。