1996 年 6 月 4 日上午，第一枚阿丽亚娜 5 型火箭从法属圭亚那的库鲁升空。它载着四颗「星簇」科学卫星，这项任务 1982 年 11 月就提出了。头半分钟左右，一切正常。
主发动机点火指令发出后第 36.7 秒，测量火箭姿态和运动的备用惯性基准系统停止工作。大约 0.05 秒后，正在工作的那一台也停了，原因一模一样，还往主计算机发了一串诊断用的比特。主计算机把它当成飞行数据，把喷管一下子摆到了极限位置。第 39 秒前后，火箭开始解体。
出事的装置并不新。调查委员会发现，它的设计和阿丽亚娜 4 型上正在用的那台「几乎一样」，「软件尤其如此」。在 4 型上，它从没这样出过事。沿用它，图的就是这一点。
用惯了的装置，没见过的航线
出错的那段程序，是发射前给惯性平台做校准用的。在 5 型上，火箭一离地它就没用了，却还要接着跑大约 40 秒，这是 4 型留下的要求，为了「通用性」保留着。5 型在头 40 秒里，水平速度涨得比 4 型快五倍。一个跟这个速度挂钩的数大到装不进 16 位整数，装置便按规格书的要求，把自己关掉了。
没人给这台装置看过新火箭的航线。委员会写道，各方「共同商定」，不把 5 型的飞行轨迹写进这台装置的需求和规格书；它的供应商「只是在执行交给它的规格书」。1992 年，项目又决定在全系统闭环仿真里用模拟件顶替真装置，理由之一是真装置「应被视为在设备一级已完全鉴定合格」。委员会说，只要在地面给它灌一遍 5 型的预计飞行数据，毛病就会暴露。
报告的最后一条建议，讲的是合作各方自己：「需要紧密的工程合作，权责分明，才能实现系统的一致；合作伙伴之间的接口要简单、清楚。」
紧密合作和简单接口，听上去像是两码事。2019 年，两位写软件团队的作者给它们各起了名字。
和另一个团队打交道的三种方式
马修·斯凯尔顿和曼努埃尔·派斯在《团队拓扑》里说，团队之间打交道基本就三种方式。一是协作：两个团队「在一段限定的时间里」紧密配合，「去发现新东西」。二是 X 即服务：「一个团队提供、一个团队消费」，按服务来用。三是促进：「一个团队帮助、辅导另一个团队」。
团队可以一起干、按服务用，或一个带一个，各适合不同的活。
团队拓扑的网站说，协作「带宽高、成本高」，服务「成本低、边界清楚」。东西稳定时，当服务用最划算；活是新的，边界却按旧活划，就容易出事。团队拓扑的通讯说，好的服务往往要借助别的模式「浮现或演化出来」，比如「和潜在用户协作，弄清他们真正需要什么」。
照这个说法，阿丽亚娜 5 型对惯性装置用的是纯粹的服务模式：一台装置，一份规格书，测试里拿模拟件顶替。对一台已在 4 型上飞着的装置，这很合理。可关于新火箭，它最需要知道的那件事恰恰被接口漏掉了。委员会那句话其实两种模式都要：先合作把边界找准，再在边界上搭一个简单的接口。
三年后，美国航天局的火星气候探测器丢在了类似的接缝上：丹佛和帕萨迪纳靠一个文件和一份接口规格书往来，调查委员会事后要求下一个火星任务多安排当面沟通。
贴对标签也不够
选对了模式，也补不上缺的那条信息。阿丽亚娜 5 型上有三个有风险的变量没加保护，这个决定本身就是「各合同层级的项目伙伴共同做出的」。坐在一起，也得有人把新航线带上桌。委员会还点了几处与交互模式无关的毛病，比如任何软件异常都让处理器停机的规定。
模式也会僵成习惯。团队拓扑的通讯说，对协作最常见的误解是让它没完没了：「混合团队」「联合工作组」一直不散，它管这叫「未定义的交互」。
看板回答的是另一个问题
假设一位数据分析师每周给门店经理做一张销售看板。这是服务模式：经理们看，她维护，平时很少说话。后来市场部拿看板上的「回头客」数字评估新推出的会员计划，可这个数是按到店次数算的。会员计划的事，没人跟她提过。
她要是继续只当服务，看板答的还是老问题，市场部却把它当成自己问题的答案。她也可以跟市场部坐两周，把定义谈清楚，再回去当服务；或者手把手教市场部的分析员查数据，等他会了就撤。继续只当服务，在季度复盘之前一分钱也不用花。
要答案、找搭档，还是请教练
聊天助手这三种模式都能用。2025 年 4 月，Anthropic 发表一项分析，对象是绑定高校邮箱的 Claude.ai 账号里，经筛选与课业和学术研究相关的 574,740 段对话。约 47% 属于「直接型」，学生「以最少的投入来要答案或内容」。这项研究只覆盖一个 18 天的窗口，样本可能偏向早期用户，也没测学生学会了多少。
六天前，Anthropic 刚推出「学习模式」：它会问「你打算怎么解这道题？」，而不是马上给出解法。用团队拓扑的话说，这就是促进；那份通讯衡量促进的标准，是对方多快能自己搞定。
想学会一样东西，就让模型向你提问，别让它替你解。然后关掉对话，自己做下一道同类题。要是又卡在同一步，多半说明这一轮教练还没当完。