2017 年 8 月 21 日天亮前，驱逐舰「约翰·S·麦凯恩」号正在新加坡海峡超越几艘慢船。舵位上只有一名水兵，操舵和两个螺旋桨的转速都归他管。5 点 20 分左右，舰长担心在拥挤的航道里，舵手「可能会应付不过来」，就命令另一名水兵接管螺旋桨。
这次拆分要在触摸屏上操作，两个螺旋桨一个一个转。没过多久，舵手报告舵失灵了。其实舵没坏：舵的控制权被误转到了另一个岗位，操作控制台的三名水兵谁也没看出来。美国国家运输安全委员会（NTSB）后来发现，船员对这套系统「普遍缺乏了解」。第一次报告舵失灵大约三分钟后，一艘油轮撞上了驱逐舰，10 名水兵遇难。其余经过见案例。
一个团队能装下多少
团队心里装得下的东西有限，再往上加，出错和拖延就容易变多。
这个想法最早说的是个人的脑子。1988 年，教育心理学家约翰·斯威勒提出，人们解题的常用办法，是一步步缩小眼下和目标之间的差距，这要占用「相当多的认知加工能力」，留给学会这类题目门道的余力就不多了。
马修·斯凯尔顿和曼努埃尔·派斯在 2019 年的《团队拓扑》一书里，把这个想法搬到了团队身上。他们的网站说得很直白：「交给团队的每一样新工具、新职责、新领域，都在消耗他们的脑力带宽」；领导只管往团队盘子里加、从不拿走，能干的团队也会变得不中用。咨询公司 Thoughtworks 2021 年把「团队认知负荷」放进了技术雷达，用一份依据这本书的思路做的评估模板，看团队觉得自己负责的东西开发、测试、维护起来有多难。
负荷取决于你懂多少
麦凯恩号说明了，同一份活，为什么对一个团队很轻，对另一个团队却很重。把操舵和推进拆开，本来是为了减轻舵手的负担。可在这艘船上，拆分本身就是一项任务：要在触摸屏上转移控制权，两个螺旋桨分开转；而按当时用的操舵模式，任何岗位都能把舵抢过去，舵位那边什么也不用做。NTSB 说，这样分轴转移油门「没必要地复杂」。接手的那名水兵，是从一艘没有这套系统的巡洋舰临时调来的，他对调查人员说，根本不知道舵可以被转到自己的岗位上。
疲劳也会让人装得更少。事发前一天，麦凯恩号舰桥上 14 个人平均只休息了 4.9 小时多一点。负荷也不是一天堆起来的：碰撞两周后，美国政府问责局向国会报告，驻日本的巡洋舰和驱逐舰船员，37% 的作战资质认证已经过期；而在整个海军，有些水兵每周工作超过 100 小时。
所以，负荷不只是数一数团队管着多少样东西。还要看这些东西大家熟不熟、设计得好不好、人累不累。
这个想法的薄弱处
斯威勒研究的是个人学习，把它用到整个团队身上，是斯凯尔顿和派斯的延伸，1988 年那篇论文并没有检验过。Thoughtworks 用的评估模板，是团队给自己填的问卷，看得出团队觉得自己有多重的负担，看不出离出事还有多远。而且，从一个团队的盘子里拿走的东西，往往会落到另一个团队的盘子里。
设想一家小公司的四人 IT 团队，管着工资系统、公司网站、办公网络，外加 20 样别的工具。每个请求都落进这一大堆里。单拿出来，每件事都不难，可团队仍可能回得很慢，因为每接一个电话，都得先想起那套系统是怎么回事。
给智能体的工具
AI 智能体一次能接收的东西有硬上限，也就是它的上下文窗口。Anthropic 2025 年一篇讲怎么给智能体写工具的文章提醒：「工具多，不一定效果好」，「工具太多或彼此重叠，也会让智能体偏离高效的做法」。它建议每个工具都有「清楚、明确的用途」，有时把几步操作合进一个工具，让占用智能体上下文的工具说明和中间结果少一些。这家公司写道，这样能「降低智能体出错的整体风险」。
NTSB 给海军的建议，指向同一个方向：复杂系统要按一套要求操作简单的标准来设计。在麦凯恩号上，一个本想减轻一名水兵负担的改动，反倒加了一项舰桥上没几个人真正弄懂的任务。