康威定律：你的系统架构，是团队结构的镜像

康威定律 / Conway’s Law
中文：任何设计系统的组织，最后造出的系统结构，都会长成这个组织沟通结构的翻版。
EN: Any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure.

我们来聊一件做 AI 的人天天撞见、却很少往深里想的事：你的系统会长成你团队的形状——不是因为那样设计最好，而是因为你的团队只造得出他们能沟通出来的东西。

为什么要问这个问题

先说一个你大概率亲历过的场景。

你在查一个 RAG 系统为什么答得不好。查到最后，问题卡在检索和生成的交界处：检索团队说”我 recall@k 很漂亮”，生成团队说”给我什么我就答什么”。两个团队按各自的指标都没错，可”这个问题到底该检索哪几段”这件真正决定质量的事，恰好掉在他俩中间那道缝里，谁都不为它负责。半年过去，那道缝变成了一个没人敢动的 API。

然后你打开架构图，忽然发现一件更好笑的事：图上的框，数量刚好等于组织里团队的数量。检索服务、生成服务、评测服务——一个团队一个。你以为你在看一张系统设计图，其实你在看一张组织架构图，只不过它换了身衣服。

这两件事是同一件事：系统的接口，长在团队的边界上。 你没有设计这些缝，是你的组织结构替你设计的。

这事不新鲜，也根本不是 AI 独有的。一个程序员在 1967 年就把它讲透了，讲的还不是软件，是”委员会为什么会那样发明东西”。

它从哪来

1967 年，梅尔文·康威把一篇论文投给《哈佛商业评论》，标题叫《委员会是如何发明的》。HBR 拒了。第二年，这篇文章发在了《Datamation》上，里面那句话后来被反复引用：

任何设计系统的组织，产出的设计结构，都是这个组织沟通结构的翻版。

康威自己举的例子特别损：你派四个小组去写一个编译器，你最后会拿到一个四趟（four-pass）的编译器。 不是因为四趟是对的，是因为你有四个组。

这句话一开始没人当回事，直到 Fred Brooks 在《人月神话》里把它拎出来、正式叫它”康威定律”，它才火了。Brooks 是过来人——他在 IBM 带过 System/360 那种巨型项目，太清楚组织怎么把自己的形状盖在产品上了。

后来还有人给它做了实证。哈佛商学院一组人对比了紧耦合的商业团队和松散的开源社区做出来的软件，结论很干脆：产品的模块化程度，几乎就是组织耦合程度的镜像。 松散协作的组织，造出来的软件也松、模块清晰；紧绑在一起的组织，造出来的代码也纠缠成一团。

核心直觉

康威定律的核心，一句话能说清：两块软件要在接口上达成一致，背后是两拨人要沟通达成一致；而沟通在团队内部很便宜，跨团队很贵。

顺着这句往下推就全通了：

• 一个团队内部，大家天天说话、共享上下文，改个函数签名喊一嗓子就行。于是同一个团队写的代码，倾向于缠在一起——耦合、共享状态、随时重构，因为沟通几乎不要钱。
• 两个团队之间，沟通要开会、要对齐、要排期，贵得多。于是跨团队的代码，会本能地收敛成一条尽量窄、尽量稳、尽量少变的接口——因为每次改接口都得再付一次昂贵的沟通。

结果就是：你的系统会在”组织不说话的地方”裂开。 团队边界在哪，系统的接缝就在哪。接口不是架构师在白板上理性画出来的，它是沟通成本的化石——哪里的人常年不怎么说话，代码就在哪里冻成一道硬邦邦的缝。

graph LR
  A[组织的沟通结构] --> B[团队内沟通便宜 代码缠在一起]
  A --> C[跨团队沟通昂贵 只留一条硬接口]
  B --> D[系统结构成为组织结构的镜像]
  C --> D
  D -.硬接口反过来固化团队边界.-> A

注意最后那条虚线：这不是单向的。 一旦那条硬接口定下来，它会反过来加固团队的边界——接口成了两个团队之间的”合同”，谁也不愿意动，于是组织沿着这条缝越分越清楚。架构和组织，是一对会互相锁死的东西。

记住这把钥匙，后面反复用它：系统会在组织不说话的地方裂开。

现实中的例子

最经典的一版，你每天都在用。

一个公司有前端团队、后端团队、DBA 团队，它做出来的系统，几乎一定是”前端 / 后端 / 数据库”三层架构。不是因为三层最优，是因为它有三个团队。你把团队数一遍，就能猜出它架构图上有几个大框，八九不离十。

还有个流传很广的故事：某公司两个组分处两栋楼，中间隔着一段路。他们合作的那个系统，最难受、最别扭的接口，恰好就落在两栋楼中间——两拨人懒得走那段路，沟通一少，接口就烂。楼与楼之间的物理距离，被一比一地印进了软件的接口里。

反过来的例子更说明问题。为什么很多公司想上微服务，上着上着就散了？因为微服务要的是”小、自治、边界清晰”的服务，可如果组织还是几个大团队、什么都要跨团队对齐，那这些”微服务”最后还是会沿着团队边界抱成几个大块——你改了代码的名字，没改组织的形状，康威定律照样赢。

映射到 AI：你怎么切团队，就会怎么切管线

AI 系统今天是康威定律的重灾区，因为我们这行边界特别多、又特别爱按能力分工：检索、生成、训练、评测、平台、安全……每一刀切下去，都是一条未来会冻进系统里的缝。

RAG 与 Agent 的管线接缝。 回到开头那个场景。你要是把团队切成”检索组”和”生成组”，你的 RAG 系统就一定会有一条又硬又深的”检索→生成”接口，而且没人做端到端优化：检索组冲 recall@k，生成组冲”给定上下文下的回答质量”，可真正要紧的”为了答好这个问题该检索什么”跨在缝上，两边都不背。你的组织分工，被一字不差地编译进了管线的接缝里。

Agent 的 planner / executor 切分。 同理，如果规划和执行是两个团队，你会得到一个 planner 和 executor 之间接口僵硬的 Agent——而且 planner 学不到执行的教训，因为那条反馈回路要跨团队才能闭合。Agent 的架构，是你组织架构的一张快照。

ML 平台团队 vs 产品团队。 平台团队握着训练和推理基建，产品团队握着应用。两者之间那道 API 边界，长得和组织边界一模一样。摩擦也随之而来：产品团队想换个模型、调个 prompt，本该是几分钟的事，可模型归平台团队管，于是一个小改动要走跨团队排期。组织的边界，变成了 API 的边界，最后变成了迭代速度的税。

Monorepo 还是 polyrepo，其实是个组织决定。 一人一个 repo、一队一个 repo，是在用工具把团队边界硬化成部署边界；monorepo 则让代码更容易越过团队线流动。这个看起来是技术选型的事，本质是”你想让团队之间贴多紧”的组织问题。

为什么三个团队几乎永远做不出五个服务的系统。 你能独立演进的大组件数量，大致等于你有几个能独立负责它的团队。让三个团队去做五个服务，结果通常是两个服务没人真正养，或者五个名义服务实际上还是照着三个团队抱成三坨。架构的粒度，被团队的数量兜死了。

所以开头那两个困惑，到这儿答案就一句话：你以为你在做架构设计，其实你在把组织结构翻译成代码——你怎么切团队，管线就怎么裂。

工程师视角：逆康威动作

道理讲完，落到能做的事情上。这里最有用的一招，叫逆康威动作（Inverse Conway Maneuver）：既然组织形状会决定系统形状，那就反过来——先定你想要的架构，再照着它去搭团队。

想要端到端优化的 RAG？别设检索组和生成组，设一个对”最终答对没答对”负责、独占整条 query→answer 链路的团队。想要边界干净的微服务？就配小而自治、能独立上线的小团队。你想让系统在哪断开，就让组织在哪自然分组；你不想让它断开的地方，就别在那儿画团队的线。

几个更具体的动作：

• 画架构前先画组织。 新系统开工前，先问”这活儿由几拨人、按什么边界来干”。那张人员图，就是你架构图的第一版草稿，早点看见它，比事后骂架构烂有用得多。
• 想改架构，先改沟通路径。 光在代码里搬边界没用，组织不动，缝会长回来。真要改架构，得先改谁跟谁坐一起、谁跟谁对同一个指标。
• 警惕”随手一切”的团队划分。 按现成的人头、职级、地理位置切团队，等于随手给系统定了架构。这一刀往往比任何一次技术选型都更决定产品的最终形状，值得慎重。
• 别过度切分。 团队切得越碎，系统里的硬接缝就越多，跨团队协调的成本会飙上去（这正是布鲁克斯定律的地盘）。三个团队就老实做三坨清晰的东西，别硬凹五个。

一句话总结这一节的姿势：架构问题，很多时候是伪装成技术问题的组织问题。改代码之前，先看看是不是该改组织。

投资 / 组织视角：组织形状是架构的先行指标

把视角拉到公司层面，康威定律是一把很少人用、但极准的尺子。

看一家公司的组织，就能提前猜到它产品的样子和它的盲区。一家把”模型团队”和”产品团队”分得泾渭分明的 AI 公司，它的产品十有八九会在”模型能力”和”用户体验”的交界处别扭——因为那道缝，就是它组织里最深的那道缝。一家安全团队独立在外、只做事后审查的公司，它的安全大概率是贴上去的一层，而不是长在产品里的。组织图，是产品架构的先行指标——你能在它出问题之前，就从组织形状里读出它会在哪出问题。

绕回到我们做 AI 这件事，这条给工程师的启示很直接：当你要评估、加入、或者押注一个 AI 团队时，别只看它的技术栈，去看它怎么分组、谁跟谁对指标、哪两拨人从不说话。 那张组织图会告诉你，这个系统未来会在哪裂开、哪块能力会长期没人真正负责。技术债你能还，组织缝焊进架构里，是最贵、最难还的那种债。

常见误解

最常见的跑偏，是把康威定律读成”所以组织不重要，牛人能突破它”。正好相反。 它说的恰恰是组织极其重要——重要到能决定你技术上做得成做不成。越是想忽略它、硬靠个人英雄主义去顶的团队，被它拗得越狠。

第二个误解：以为这是在骂”官僚””大公司病”。不是。它是中性的，是重力，不是缺陷。 沟通就是有成本，这个成本就是会塑造系统。你没法取消重力，只能顺着它设计。懂它的人，用逆康威动作借它的力；不懂的人，被它绊倒还不知道自己被什么绊的。

第三个：以为它只讲静态结构。其实它更狠的是动态那一面——组织变一次，系统就跟着扭一次。每次重组、每次团队合并拆分，都在悄悄重写你的架构，哪怕没人动一行代码。

什么时候不成立

知道一个模型什么时候失效，比记住它本身更值钱。康威定律要成立，靠的是”接口需要沟通、沟通有成本、成本沿组织边界分布”。把这几条动一动，就是它松动的地方：

团队足够小、沟通足够便宜的时候。 一个几人的小团队，人人都能碰全部代码，没有跨团队的缝，康威定律基本没有着力点——这也是小团队常常架构更干净的原因之一。

刻意用工具把沟通成本抹平的时候。 monorepo、共享的设计评审、强制的跨团队轮岗、AI 结对……这些都是在人为压低跨边界的沟通成本。压得越低，组织边界对架构的塑造力就越弱。

组织被架构反向重塑之后。 逆康威动作成功时，因果是反过来的——是你想要的架构在决定组织，而不是组织在决定架构。这时候你看到的”组织=架构”，是你故意造出来的，不是命运。

判断方法还是那把钥匙，反过来用：**”我这个系统真正难改的接缝，是不是刚好落在两拨很少说话的人中间？”** 是 → 康威定律正在起作用，别指望纯技术手段修好它；不是 → 你可能真碰到了一个纯技术问题。AI 团队里，大多数”跨团队的接口烂”，答案都是响亮的”是”。

相关模型

康威定律不是孤岛，它挂在一张网里。下面这些是同一张网上的邻居（这些文章我会陆续补上）：

• 委托代理问题 / Principal-Agent Problem：康威讲组织的沟通结构怎么塑造系统结构，委托代理讲组织的激励结构怎么塑造人的行为——两者是”组织如何盖在产出上”的一体两面。
• 激励 / Incentive：团队之间说不说话、往哪对齐，归根到底由激励决定。想用逆康威动作改组织，先得把激励改对。
• 布鲁克斯定律 / Brooks’ Law：往晚了的项目加人只会更晚，因为沟通成本随人数暴涨。康威定律说这个成本塑造了架构，布鲁克斯定律说它还会拖垮进度——同一个”沟通成本”的两个后果。
• 古德哈特定律 / Goodhart’s Law：当检索组只被 recall@k 考核、生成组只被”给定上下文的质量”考核，端到端的目标就在组织缝里被 Goodhart 掉了——这两条定律常常在同一道团队边界上一起咬你。

一句话记住

中文：你不是在设计系统，你是在把组织结构翻译成代码。想换个架构，先换掉”谁跟谁说话”。
EN: You’re not designing a system; you’re translating your org chart into code. Want a different architecture? First change who talks to whom.