好代码需要两个人：为什么两人组队才是最优解

两人组队的古老智慧

作者观看罗马 Manuballista（人力 torsion 抛石机）的历史复原视频时注意到一个模式：太重单人操作，两人刚好——移动、瞄准、装填、射击、转移，在敌人反应过来之前完成打击。这个模式在历史上反复独立出现：二战机枪组，两人；现代狙击手对，两人（精确射手 + 观察手）。跨越大几千年、完全不同的技术，军队不约而同落在"两人"这个配置上。

原因藏在数学里。两人之间的通信渠道只有一条。三人是三条，四人是六条，五人是十条。公式 n(n-1)/2 由 Fred Brooks 在《人月神话》（1975）中提出，五十年来大多数组织并未真正内化这个成本。

两人保持着个体的机动性，同时获得了系统的能力——不需要协调协议，不需要流程审批。

Holmes & Watson 模型

这个模式不只存在于军事领域。Batman & Robin、Butch & Sundance、Bud Spencer & Terence Hill——一旦注意到，到处都是。但对软件团队来说，最贴切的类比是 Holmes & Watson。

多数人以为 Watson 只是陪衬，是负责叙事的次要角色。实际上，Holmes 一半的突破是因为 Watson 迫使他把直觉说出来。初级开发者不断追问：为什么要这样做？这个失败了怎么办？不能直接……吗？这些问题看似简单，恰恰是 senior 在自动驾驶模式下最不愿面对的反思。初级不是拖累，初级是 senior 的思维外部化。

为什么这对软件有效

Senior 的价值：承载架构。能识别尚未变成技术债务的设计错误，知道哪些角落可以投机、哪些六个月后会让你后悔。

但更重要的是：Senior 因为 junior 而变得更好。教学相长——把决策说出来的过程，本身就是在验证和精炼自己的思考。作者坦承：独自做管理决策时更容易偷懒，有人不断问"为什么"既烦人又无价。

Junior 的价值：学习速度远超任何 onboarding 流程。不是从文档学，不是从没人更新的 wiki 学，而是观察 senior 实际如何思考问题——考虑什么、忽略什么、对什么感到不安。这些无法写下来，只能身临其境吸收。

附带效应

Bus Factor 自动解决——不是靠流程、不是靠强制文档冲刺，而是从第一天开始就是两个人。
Code Review 实时化——不是 48 小时后在 PR 里收到反馈，而是当下就完成。
上下文共享——不需要事后重建。

大团队是一种组织焦虑

五人或六人团队需要站会、对齐会、任务分解会、PR 审批流程。两人团队——直接说话。没有流程要处理，因为本来就没有什么要处理的东西。

每当你看到五六人的团队，里面至少有两对人想要分开。会议上观察谁在真正投入——永远不是全部六人。

当然有例外：分布式系统、有太多移动部件的问题、两人确实扛不动的工作量。但这类情况比想象中少。我们默认组成六人团队，不是因为工作需要，而是因为不信任两个人能 handle 得了——这是组织焦虑，不是技术约束。

组织扩展靠的是学徒制

当 junior 成长——在好的配对中会很快——他们变成 senior，去带自己的 junior。

这就是几百年来行会的运作方式。Master 与 Apprentice。学徒变成 Journeyman，再变成有自己的学徒的 Master。软件行业重新发明了这些，叫它"导师计划"——但计划永远没有两个人一起解决问题来得有效。

每个 senior 都曾经是某个人的 junior，他们传承的不只是知识，还有工作的方式。组织靠学徒制扩展，而非靠拼命招聘 senior。

结论

两人组队天然适配 AI 编程时代。两人产品工程师、互补技能集——刚好。罗马人在两千年前用弩炮想明白了这个问题。如果最优团队本来就是两人，我们围绕软件团队建立的一切——站会、冲刺规划、对齐会议、复杂的 PR 工作流——都是因为先把团队搞太大而产生的浪费。

原文核心公式：n(n-1)/2 通信渠道。两人临界，四人翻倍，五人失控。