五份都对的方案
一家软件公司的项目组接到一个任务：为一个老客户重做报表模块，三周交付。组里五个人，每人都配了公司买的编程助手和文档助手。第一周结束，五个人各自交来一份方案，每一份都写得很完整——架构图、接口定义、迁移计划、测试方案——每一份单独看都对，放在一起却合不起来：三份用了不同的数据模型，两份对"旧报表要不要保留"给出了相反的判断，没有一份提到另外四份的存在。项目经理花了第二周把五份合成一份，第三周开发，第四周还在返工，因为合成那一份里有两处接口，谁也说不清是谁定的、凭什么定的。
事后复盘，五个人说的是同一句话：我的那份没问题。这句话没错。问题不在任何一份里，在五份之间。
这本书是为这件事写的：当每个人都有了一个能把方案写完整的助手，团队为什么反而更容易做不成事？做不成的那一段到底在哪里，能不能数出来？
五十年的账：组织是一台信息处理机
组织理论对"为什么要有组织"有一个经典答案。加尔布雷斯一九七四年在《界面》上那篇论文把它说成一句话：任务的不确定性越高，执行过程中决策者之间必须处理的信息就越多；组织设计就是在调节这个量。他给出四类策略——用规则和程序减少需要处理的信息、创造自足的任务单元、投资纵向信息系统、建立横向关系——每一类都是在回答同一个问题：信息怎样在需要它的人之间流动。
五十年来这个画像一直准确。项目组之所以要开会、写文档、走流程，就是因为五个人各掌握一部分，谁也不掌握全部；组织的全部结构，从汇报线到周会，都是在让信息流到该去的地方。
按这个画像，给每个人配一个助手，应该让组织更好：每个人处理信息的能力上去了，需要流动的信息就少了。事实不是这样。
那一层已经被占了
先看能核的数据。
哈佛商学院、微软与代码托管平台的研究者做了一项自然实验：平台向排名靠前的开源项目维护者免费开放编程助手，恰好在门槛上下的人只差一点排名，于是可以比较。样本是十八万七千四百八十九位开发者，二〇二二年七月到二〇二四年七月的逐周记录。结果是：拿到助手的人，编码活动增加五点四个百分点，相当于百分之十二点三七；项目管理活动减少十个百分点，相当于百分之二十四点九三。机制有两条：从协作转向自主，从利用转向探索。还有一个细节：他们从高成本的互动（写评论）转向了低成本的互动（发表情符号）。研究者在结尾写道，这可能会压平组织的层级。
这项研究常被读成好消息：助手让人更能专注核心工作，少开会、少扯皮。本书读到的是另一件事。评论变成表情符号，正是交接记录消失的样子。评论是一个人告诉另一个人"我改了什么、为什么改、你接下去要注意什么"；表情符号是"看到了"。从前者到后者，协作摩擦确实少了——因为交接被绕过去了，不是被完成了。五份都对的方案就是这么来的：每个人都更能单干了，于是每个人都单干了。
为什么是现在
组织不是第一次遇到工具变革。电子邮件、即时通讯、项目管理软件，每一次都让"处理信息"更容易，组织每一次都调整，然后稳定下来。这一次为什么不一样？
第一，方案不再稀缺。一份完整的架构图、接口定义、迁移计划，成本趋近于零，人手一份。围绕"谁能把方案写完整"设计的一切——资深与初级的分工、评审的层级——都失去了定价对象。
第二，价值结算的地方挪了。从前一个项目的价值在"谁把方案做对了"这一格结算；现在这一格人人都能占，价值只能往别处走——往"五份之间怎么接、接错了谁认"那一格走。考核还在按个人交付打分，项目已经在为交接失败付返工。
第三，工具从条件变成了变量。项目管理软件是条件，大家用的差不多，比的是人；生成助手是变量，每个人的助手看过的材料不一样、上下文不一样，五个人的助手各记各的账。当工具本身成了协作里最不稳定的一项，"方案对"就不再能归功于写方案的人。
三条合起来：不是工具更强了，是它把"做出一份对的方案"整个从个人手里拿走了，而组织还在按这件事考核。
死的是什么，没死的是什么
死的不是组织，不是团队，是一个位置："我做出了对的方案"这个位置。
它死得其所。助手生成那份架构图时，它做的不是从需求文档里把"正确方案"取出来——正确方案不是躺在那里的东西，一份方案之所以"对"，是因为它接得上别人的那一份。助手把每一份都做对了，唯独做不了"接得上"，因为"接得上"不在任何一份里，在两份之间。五个人从前也是各做各的，只不过从前做得慢，中间有大量的问、等、改，交接在这些问和等里被完成了；助手把问和等省掉了，交接也跟着没了。
那么没死的是什么？是助手没做、也做不了的那一件：什么算交清了，谁认下了上一轮。接口是谁定的？为什么这么定？改的时候通知谁？这三个问题的答案不在任何人的助手里——每个人的助手只记得自己主人的上下文，团队没有一本共同的账。
有一门行当把"交接"本身做成了对象，并且测出了效果。二〇一四年《新英格兰医学杂志》发表了一项多中心研究：九家儿科住院医师培训项目，一万零七百四十例住院，实施一套标准化的交接班规程——病情严重度、病人概要、待办清单、情境与应变、接收方复述——之后，医疗差错从每百例二十四点五降到十八点八，下降百分之二十三；可预防的不良事件从四点七降到三点三，下降百分之三十。而每位病人的口头交接时间从二点四分钟到二点五分钟，几乎没变；住院医师的工作流没有受影响。医学早就知道，交接不是"通知一下"，是一件可以被结构化、被计数、被改善的事，而且改善它不需要多花时间。
但这套规程里最要紧的一项——接收方复述——解决的是"信息传到了没有"；五份方案的问题在再往上一层：谁认下了。传到了和认下了是两件事，助手可以保证前者，保证不了后者。
最强的反方
本书必须正面回答一个反方，它有一本五十年不衰的书撑着。
《人月神话》说：往一个已经延期的项目里加人，只会让它更延期，因为沟通成本随人数平方增长。这一派的结论是：协作本身是净成本，最好的团队是小到不需要交接的团队。按这个思路，助手让每个人都能单干，正是好事——把团队缩小到一个人加一个助手，交接问题就消失了。
这个反方对本书的一半是对的：助手确实让"小到不需要交接"的团队规模上移了，从前五个人的活现在两个人做。它错在另一半：交接可以被推迟、被压缩，但不能被取消。五份方案之间的那两处接口，不会因为团队变小而消失，它会以返工的形式回来——第四周的返工就是被绕过去的交接回来讨债。本书的赌注在这里：如果同等复杂度的任务下，零交接的一人加一助手的小队在两年内的返工率不高于有交接协议的团队，本书作废。
往上走的四级台阶
本书把团队里每个人的工作分成四层。
第零层：写出一份对的方案。架构、接口、计划、测试。这一层已经被助手占了，占得更完整。谁把自己的价值放在这一层，谁的意义随这一层一起没了。
第一层：把五份方案合并成一份。很多项目经理现在做的就是这个。这一层正在跟着死：助手合并五份文档比人快，而合并仍是在这五份里打转，它没有生产任何新的东西——尤其没有生产"谁认下了"。
第二层：定什么算交清，谁认上一轮。两份方案的数据模型不一样，谁改？改完谁签？签了之后另外三份要不要跟着改？这一层的活是粗粒度的：不再管每一份方案对不对，管的是这五份之间的接口落在谁名下。助手给出差异清单、给出合并建议，但"就按这个接、由我认"由人定——不是助手能力不够，是它不在这个位置上：它不需要在第四周的复盘会上解释那两处接口是谁定的。
第三层：立一本团队共同的账，并为它认账。这一层的人不再回答"哪份方案对"，而是回答"在我们组，上一轮谁改了什么、凭什么改、谁认的，记在哪里，由谁维护，记错了谁改"。这是团队里能站的最高一层，也是助手绝对到不了的一层，因为每个人的助手只为自己的主人记账，而这本账必须属于所有人又不属于任何一个人的助手。
在第二、三层上，助手是必要的：没有它把第零层穷尽，第二层不存在——你不可能在两份手写的草案之间做"粗粒度"的接口判断，只有面对五份被穷尽的完整方案，接口才成为问题。人也是必要的：没有人认下接口，五份方案就是五份方案，永远合不成一份。少一样都不成。本书把团队与助手在第二、三层上的搭配叫作人机协同的交接单元——在第零层助手只是工具，到第二层它是这个单元不可拆的一半。
回到那个项目组。他们后来做的事是这样的：第五周起，每一份方案在提交之前必须回答三个问题——我改了别人定的哪一条、我定了哪一条别人以后要接、这两条记在哪。他们把这三个问题的答案放进一份所有人都能看、任何一个人的助手都不能单独改写的文档里。第六周，五个人的助手各自读了这份文档之后再出方案，接口冲突从两处降到零。不是助手变聪明了，是团队第一次有了一本共同的账。这两步，就是第二层和第三层。
一把尺：一项任务里断了几次
主张说完了，得给一把尺。
本书提出的尺叫交接断点数：一项任务从起到止，发生了多少次没有被任何人确认接收的交接——每次记录：交了什么、该谁接、什么算交清。它是项目管理里"返工工时"的上游量：断点在前，返工在后。取值材料是版本记录、评审记录、复盘纪要，一次取值约一周。
举一个数法。翻那个报表模块的版本记录。第一周，五份方案各自提交，彼此之间零引用——五份之间任意两份的接口都没有人确认接收，按两两组合记十处潜在交接，全部未确认，断点记十。第二周，项目经理合并，合并稿里两处接口的来源无法追溯到任何一份原方案，也没有任何一位作者确认"这是我定的"，断点记二。第三周开发，一位开发者按合并稿改了数据模型，另一位没有收到通知继续按旧模型写，断点记一。第四周返工四十六个工时。这项任务的交接断点数记十三，返工工时记四十六。第六周之后的那项任务，有了共同账本，版本记录里每一次接口变更都能追到定它的人和接它的人，断点记零，返工工时记三。本书要问的是：把一批项目排开，断点数与返工工时是不是一起动。这个问题此前没有人这样问过，因为此前"交接"从来没有被当成一件可以逐次计数的事。
有了尺，就能写下这本书什么时候算错。如果在一个可以取值的样本里，交接断点数与返工工时无关，那么本书第三卷作废。
还有一个更硬的检验，本书没做，但把设计写出来了：一项多人接力的任务，三个组各自完成——第一组只有助手串联，第二组只有人且不给助手，第三组是协同单元、带共同账本——计返工工时。本书的主张成立，当且仅当前两组都不如第三组。它还没有被任何人做过，本书作者在内。全书的尺都是取法与设计，没有一个是取过的值。
这把尺会怎样被做假
交接断点数一旦进了考核，团队会做什么，一目了然：每一次交接都留痕，评论刷满，确认按钮人人点，断点数降到零，返工一点不少。本书事先写了升级条款：只认"接收方改写了什么"——接收之后没有任何改写的确认，不算接收；若断点数下降而返工工时不降，这把尺已被驯化，尺子那一节须重写。
一本主张"交接不能被绕过"的书，若自己立的尺被人绕过去了，它就把自己批评的病带回了家。
本书不做什么
本书不讲谁出局、谁被淘汰的账，本社此前有专书。本书不讲人与机器之间的价值在哪一层结算——那是另一本书的题目，本书只借它一个说法：结算发生在协作者之间。本书不讲经理：本丛书另有一本《管理》，问的是"经理还有没有用"，本书问的是"没有经理，团队行不行"，两本各答各的。本书也不讲对陌生人的信任，那是又一本书；本书只管一个团队之内、同事之间。
各卷概览
第一卷 列一张表：岗位说明书、流程图、责任分配矩阵——组织设计里历代被当作"现成的匹配"的东西，逐条写明它是被谁、在什么时候、用什么方式当场造出来过一次。
第二卷 是实证：十八万开发者的两年、九家医院的交接规程、五十年的信息处理理论、人月神话。
第三卷 写四级台阶与交接单元：交接的三个问题，共同账本长什么样，机器供什么、人供什么。
第四卷 写制度：交接协议怎么写，共同账本怎么维护，冲突按谁认下来处理、不按职级处理，附三种团队的协议样本。
第五卷 写尺与判据：交接断点数的取法、三组对照的设计、作废条件。
第六卷 写这本书自己的死法。
给读者的话
有三种人该读这本书。第一种是那五个人，他们需要知道"我的那份没问题"这句话没错，但它说明的恰恰是问题在哪。第二种是项目经理和组织设计者，他们手里握着"按什么考核"的开关，第四卷为他们而写。第三种是正在做"团队 AI 助手"的人，他们需要知道自己的产品在第零层是解放，在第二层是必要件——而在第三层，若它只为一个人记账，它就是问题本身。
作者对本书的态度写在第五卷：它可能是错的，错的条件已经写明。若有一天有人拿着一批项目的版本记录告诉我，交接断点数与返工工时无关，那一天本书的使命就到头了——它被一次可复核的复盘推翻了，而那正是它主张组织该有的样子。