一家承接科研合同的公司，有八个程序员、两份活：一个 COBOL 编译器，一个 ALGOL 编译器，都是当年的编程语言。
经理们估了估工作量，把人分开：五个人做 COBOL，三个人做 ALGOL。
做出来的 COBOL 编译器分五个阶段运行，ALGOL 编译器分三个。
没有谁刻意这么设计。程序员梅尔文·康威把这个例子写进了 1967 年的一篇论文，旁边还放了另一个：两个军种奉命合作开发一套能满足双方需要的武器系统。康威写道：「费了好大力气，他们做出来的，是一份自己组织架构图的复制品。」
藏在倒数第三段的论点
康威把这篇《委员会是怎么发明东西的？》投给了《哈佛商业评论》，被退了稿。按他自己的说法，理由是他「没有证明」自己的论点。
他转投当时最主要的计算机杂志《Datamation》，1968 年 4 月登了出来。几十年后他自嘲，这篇文章最了不起的地方，是「论点藏在倒数第三段」居然也发表了。论点是这样的：设计系统的组织，做出来的设计，注定是这个组织沟通结构的复制品。
道理很实际。做任何大东西，都得决定一块在哪结束、下一块从哪开始。坐在一起、天天说话的人，可以越过这条线一起干。分在不同组、要通过经理和会议才能对上话的人，就需要这条线干净利落，好各干各的。于是产品的接缝，落在人和人不再天天说话的地方。
几年后，弗雷德·布鲁克斯在《人月神话》里引了这个想法，叫它「康威定律」，名字就这么叫开了。成体系的证据，来得要晚得多。
四十年后，在哈佛
2000 年代，哈佛商学院的艾伦·麦科马克、约翰·鲁斯纳克和卡丽斯·鲍德温，决定检验他们所说的「镜像假说」。他们找来一对对功能相近的软件：每一对里，一个出自公司内部联系紧密的团队，另一个出自松散分布的群体，比如开源项目。
然后他们测量：改动一个文件，可能波及系统的多大一片。Sun 的 Solaris 操作系统，这个数字超过 22%，平均改一个文件，可能牵动两千四百多个别的文件。由一个松散社区共同开发的 Linux，大约是 7%。
研究者写道：「我们考察的每一对里」，松散组织做出来的产品「都明显更模块化」。差距最大到了八倍。
这是一对对配好的比较，说明的是一个很强的规律，不是放之四海皆准的定律。规律正是康威描述的那个：没法隔着桌子探身过去说话的团队，做出来的软件，各块之间也不怎么互相探身。
把定律倒过来用
既然产品照着组织长，那就可以先把组织排好，再让产品长成想要的样子。按一位前员工的说法，2002 年前后，杰夫·贝索斯在亚马逊大致就是这么干的：命令每个团队只能通过公开的服务接口和别的团队打交道，不照办就开除。亚马逊的软件后来被拆成一个个独立的服务，每块由一支小团队负责。
一支由 AI 组成的团队
做 AI 系统的人，现在也开始画组织架构图了。MetaGPT 是一个研究用的编程智能体框架，它在「我们的软件公司」里设了五个角色：产品经理、架构师、项目经理、工程师、测试工程师，活在他们之间按作者所说的「流水线模式」传下去。团队结构是照着人的公司刻意抄过来的。
把康威的想法搬到智能体身上，是一个合理的推测，还不是检验过的结论。不过它给了一个值得问的问题：角色之间每交接一次，就可能留下一道接缝。这些接缝，是你想要产品长出来的样子吗？
客户走的路
再设想一家从没把定律倒过来用的银行。活期账户在一个 App 里，信用卡在另一个 App 里、还要单独登录，房贷那边只接电话。客户要在三者之间挪钱，就得跨过经理们之间的那几道线。每个团队都把自己的活干得很好，客户却像在组织架构图里穿行。