14. 当 AI 进入团队：协同重排

一个十个人的小组，从年初开始全员开了 Cursor，有人换了 Claude Code，有人配了自己的 Skill 库。每个人的体感都很真实，写得更快了，样板代码不用自己敲了，陌生模块上手也比以前轻松。月度复盘的时候，每个人都说提效在三成上下。

季度过去，看交付节奏。需求列表里完成的工单数量比上一个季度多了一点，但远没有多到三成，连一成都不太到。延期的项目还是延期，救火的次数没少，跨组联调依然要排会拉齐。每个人都说自己快了三成，加起来落到团队层只剩一成不到。中间那两成，去哪里了？

每个人的本地循环都是真的变快了，这件事在工位前是看得见的。问题出在更上一层，个人变快和团队变快并不是简单的递进关系。把这两件事混为一谈，是 AI 编程进入团队之后第一个错觉。

14.1 各不相同的高效

回到那个十人小组。把镜头推近一点，看每个工程师本地是怎么用 AI 的。

A 工程师写得最快，他给 Agent 的指令短到只有几个词，因为他对代码库太熟，他知道 Agent 看一眼周边代码就能猜对意图。他几乎不写完整 Prompt，他的 Prompt 都在他脑子里。B 工程师比较谨慎，每次都让 Agent 先列计划，自己看一遍再让它执行，过程慢一点，但产出的代码他敢直接合并。C 工程师走的是另一条路，他攒了一套自己的 Skill，处理这个项目里反复出现的几类任务，每次任务来了就加载对应的skill，新人看他的 Agent 输出会觉得这家伙是不是有外挂。D 工程师习惯让 Agent 一口气写一大段，然后自己 review，他相信自己的眼力胜过 Agent 的小心。

上述的四种用法，每一种都让用的人变快了。但这四种用法的产出物拼到一起，就开始出现奇怪的事。A 写的代码读起来跳，因为他的 Agent 是顺着他的脑子写的，他自己读没问题，别人接手要先猜他当时在想什么。B 写的代码工整，但风格和 A 对不上，合到一起就有明显的风格差异。C 用的 Skill 别人不知道存在，新人接他的代码还是要从代码着手。D 一口气产出的大段代码经常埋着一两处他自己没看出的问题，要等下一次 review 才能被别人捞出来。

四个人都在自己的工作流里达到了三成的提效，这个数字不是吹的。但当代码合到主干、需求跨人流转、新人加入项目的时候，他们之间的拼接成本一下就上来了。

要看清楚这个拼接成本，得看一下原来有哪些写作末餐。A 改的接口 B 不知道、B 写的测试 C 看不懂、D 留的坑要等下一次 review 才能发现，这些事二十年前的项目里就有，跟 AI 没关系。前 AI 时代每个人一周提两三个 PR，拼接事件本身是稀疏的，组织有充裕的时间消化，这种摩擦的绝对值在那里，但被生产节奏压住了，显不出来。

AI 真正变了什么？一个是密度。生产侧的速率被抬高一个量级，A 一天可以让 Agent 改三次接口，B 一天能写八个测试，C 一周攒五个 Skill。每一次拼接的成本没变，但拼接事件的频次乘上去之后，累计的对齐时间被乘上同样的倍数。原本一周才会撞一次的小冲突，现在一天撞三次。前 AI 时代藏在水面下的那部分摩擦，现在被生产节奏抽干了水位，全部露了出来。

另一个更要紧，AI 引入了几类前 AI 时代没有对应物的拼接成本。最锐利的一类是 Agent 上下文之间的不对齐。A 的 Cursor 里加载着他对项目的理解，包括他的 Skill、他攒的 Prompt、他的私人记忆；B 的 Cursor 里加载着另一份。两个人坐在一起对齐了这个接口要这样改，但他们各自的 Agent 没对齐，下一次 A 让 Agent 动这个接口、B 让 Agent 写测试，两个 Agent 是在两个不同的世界模型里工作。前 AI 时代两个工程师对齐了就是对齐了，他们脑袋里的认知是直接通的；AI 时代要对齐两次，人对齐一次，他们各自的 Agent 上下文还要对齐一次，后一次几乎从来没人做。

前 AI 时代 C 攒的工具脚本要么是 shell 别名，私人的，没人指望共享；要么进了仓库脚本目录，公共的，大家都能用。AI 时代 C 攒的 Skill 处在一个新的中间地带，它对 C 的 Agent 极其有用，但因为带着 C 的判断坐标系，没办法直接共享给 B。这是一种新的、传统资产体系里没有对应物的私有资产，它越积越多，越积越对一个人有用，对团队的边际收益却在递减。

每一次拼接都要花时间对齐，每一次对齐都在吃掉个人那三成的红利。最后落到团队层，只剩一成不到。

每个人都按自己最顺手的方式高效，这件事在个人尺度上是最优的，到团队尺度未必。局部最优的和不等于全局最优，有时候甚至是负的。

14.2 个人闭环和团队闭环不是同一件事

一个人本地用 AI 用得流畅，靠的是什么？不是工具本身。Cursor 装上不会自动让你提效，Claude Code 配好不会自动让你写得快。真正让你快起来的是你脑子里那张图，你知道这个项目的代码长什么样，你知道这一段改下去会牵动哪几个文件，你知道 Agent 写出某种风格的代码意味着它没看懂你的意图。这些东西都在你脑子里，不出现在 Prompt 里，也不出现在 Skill 里，是你和 Agent 配合的隐性底盘。

这就是个人提效的真相，个人用 AI 能跑流畅，靠的是隐性认知：对代码库的熟悉、对意图的把握、对 Agent 的预期、出事时知道怎么收拾。这些东西不需要写下来，因为你自己用，你不用解释给自己听。

但团队不一样。团队里另一个人接你的代码、读你的 Spec、用你的 Skill，他没有你脑子里那张图。他需要的不是你的隐性认知，是一份别人不需要你解释就能接得住的显性契约。代码要让别人读得懂，Spec 要让别人改得动，Skill 要让别人调得对。

隐性认知和显性公共契约之间，横着一道翻译的鸿沟。这道鸿沟在传统时代也存在，但传统时代有一种东西在替你翻译，那就是写代码的过程本身。你写一段代码慢慢推敲，推敲的过程逼着你把脑子里的隐性认知一点点变成显式的代码、注释、命名和抽象。等你写完，这段代码不光是给你自己用，已经初步是给别人看的了，写得慢，反而帮着做了翻译。

AI 时代这道翻译被跳过了。你想清楚意图，告诉 Agent 几个词，它生成一段代码。这段代码对你来说够用，因为你的隐性认知能补上 Agent 没填上的那部分。但对其他人，这段代码是裸的，它把你脑子里那张图省略掉了，而那张图本来是要在写代码的过程里慢慢沉淀进代码本身的。

这件事和之前谈的规范驱动是一脉相承的，规范驱动讲的是把约束从会话搬到仓库，把那些一次次重复说给 Agent 听的话沉淀成项目里能被读到的 Spec。本章推到团队尺度，把个体使用 AI 的隐性经验沉淀成团队的公共契约，是同一种动作的更大半径。一个人用 AI 用得流畅，他大可以不写 Spec、不维护 Skill、不留下文档，因为他自己脑子里都装得下。但一个团队要让 AI 用出红利，这就绕不过去，因为缺乏一个统一集中的大脑来补齐这些隐性差异。

公共契约在团队里有几种具体的形态。最浅一层是项目级的 AGENTS.md 和编码规范，回答的是这个项目里 Agent 该按什么风格写代码。再往里一层是共享的 Skill 库和 Prompt 模板，回答的是反复出现的任务用什么稳定的姿势处理。最里面一层是评估集和测试用例，回答的是什么样的代码算交付完成。这三层共同构成一个团队的显性底盘，每一层都是把某个人脑子里的隐性认知翻译出来，放到所有人都能读到、改到、用到的地方。

不做这个翻译会怎样？会出现一个非常具体的现象，团队里 AI 用得最好的那个人，反而成了瓶颈。因为他个人提效三成，大家依赖他，他被请去写关键模块、被请去帮别人调 Agent、被请去解释他的 Skill 怎么用。他的隐性认知没翻译成公共契约，所以他必须亲自在场，他成了那座只能靠他本人维持的桥。他越能干，桥越关键，团队对他的依赖越深，团队的整体节奏反而被锁死在他个人的节奏上。

这正是个人提效和团队提效的本质差异。一个不向外打开的高效个体，对团队来说不是资产，是依赖。

14.3 康威定律不再是长期规律，是当下瓶颈

康威定律在1968 年提出来：系统的结构反映组织的沟通结构。这话讲了五十多年，在传统软件工程里它的位置是一条结构性长期规律。意思是说，你的组织怎么分工、谁向谁汇报，长期来看会反映在你写出来的系统架构里。微服务架构往往出现在按业务线切分的公司，大单体常常出现在职能型组织，这些观察都对，但都是长时间维度里的。一个组织调整一次结构，系统架构跟着变，中间隔着的时间通常以季度为单位。

这条规律在 AI 时代变了味。它没失效，反而被放大，但它的时间常数从年压缩到了周。康威定律从一条结构性长期规律，变成了一条当下瓶颈。

要看清楚这点，先算一笔粗账。传统时代一个工程师产出一个 PR 要小半天，十个人一周大概产出几十个 PR，这些 PR 之间需要的协调，在交付总时间里大概占两三成，剩下七八成是真正写代码的时间。AI 时代生产侧成本被压到几分钟一个 PR，十个人一周可以产出几百个 PR。可协调成本没动，一个会议还是 30 分钟，一次跨组对齐还是要排日程，一次代码合并冲突的解决还是要拉人。生产侧成本降低了一个量级，沟通侧站在原地，沟通成本在交付总时间里的占比也跟着翻了上去。

这件事在很多团队里已经看得见了：每个人都很快，但需求在团队这一层还是慢；Agent 写得飞快，但 PR 在 review 队列里堆成停车场；并行的工作流多得管不过来，大家天天在协调，真正写代码的时间反而少了。

这直接推出一个反直觉的判断：组织设计的优化收益，第一次盖过了技术选型的优化收益。传统时代讨论技术选型很热闹，换语言、换框架、换 IDE，这些选择能影响个人产出几个百分点。AI 时代你换一个更好的模型，个人产出可能再涨一截，但团队产出未必动得了，因为瓶颈早就不在生产侧了。反过来，把组织结构调对了，沟通成本从大头压回到合理水位，团队产出能直接翻倍。调组织拿到的红利，远超调工具拿到的红利。这件事在传统话语里几乎是不存在的，是 AI 把生产侧塌方之后才暴露出来的。

沟通的成本还和团队的规模有关。把团队画成一张图，每个人是一个节点，每两个人之间的对齐就是一条边，这张图的边数会随着人数的平方增长，三个人三条边，十个人四十五条边，三十个人四百多条边，这本来就是几十年前软件工程教科书里的老结论。传统时代生产侧的成本足够高，大团队的协调低效被生产成本盖住了。AI 时代生产成本下来了，沟通成本被赤裸裸地暴露，大团队里的协调损耗变得非常显眼。最优组织形态向小、向自治、向闭环收敛。小是为了压住这张图的平方爆炸，自治是为了减少跨组协调，闭环是为了让一个完整的业务能力在一个小组内能从需求走到上线。这些原则在传统编程时代也存在，但传统时代它们是 nice to have，AI 时代变成了必须，因为不这么做的代价被乘了一个量级。

传统康威定律说的是组织结构决定系统结构：你的组织怎么分，系统就长成什么样。这个方向之所以成立，是因为传统时代生产能力是个稀缺资源，一个小团队没法独立交付一个大系统，大系统必须由大组织分工协作完成，所以系统不得不长成组织的形状。AI 时代这个前提变了。一个三五人的小团队带着 Agent，产能足以独立交付过去需要二十人才能完成的系统。生产能力不再是必须按组织规模分摊的稀缺资源，它跟着 Agent 跑，几个能用 AI 的人就能把活干完。

这意味着一件反常识的事：系统结构开始反过来倒逼组织结构。一个组想要按一种新的系统形态去交付，它就可以小、可以自治、可以闭环，因为它不需要大组织的分工协作来弥补产能。组织不再被设计成系统的形状，它可以设计成它想要的形状，只要这个形状能匹配它要交付的系统，康威的箭头换了方向。

判断一个团队的 AI 红利能不能落下来，不要看他们用了什么模型，看他们的沟通图有多稠密。模型的差异是几个百分点的事，组织设计的差异可以是一两倍的事。这和工具流派之争无关，和谁追新模型追得最勤无关，只和组织本身的结构有关。

14.4 一群 Agent 之间的对齐

哪怕团队已经够小，人和人之间沟通的方式本身也变了。

传统时代团队成员之间的沟通是人和人在沟通。我跟你同步一下背景，你跟我对齐一下进度，我们一起讨论一个设计。沟通成本主要花在让另一个人理解我此刻知道什么、我接下来打算做什么、我需要他做什么。这件事虽然慢，但有一个隐性的好处，两个人在同步背景的过程里，顺手就把双方接下来的工作上下文也对齐了。我跟你说我在改用户登录模块，你脑子里就有了一张图，知道我接下来动哪些文件、需要避开哪些冲突、什么时候你能在我的基础上往下做。

AI 时代这件事变了。每个工程师都带着一个 Agent，每个 Agent 都有自己的状态，它读过哪些文件、它的上下文窗口里现在装着什么、它沿用着哪一套 Skill、它继承着工程师之前给它的哪些约束。两个工程师之间的沟通，实质上变成了两个 Agent 上下文之间的对齐。

举一个具体的场景。A 工程师让自己的 Agent 改了用户表的一个字段，把 user_name 改成了 username，顺手让 Agent 把项目里所有引用都改了一遍，扫描、修改、跑测试，一切顺利，提交合并。B 工程师在另一台机器上，他的 Agent 还停留在旧的上下文里，读到的代码里那个字段还是旧名字，它生成的新代码自然按旧名字写。B 跑了一下，失败，他以为是自己的环境问题，排查了一阵才发现是字段名变了。

这段排查时间在传统时代是不存在的。传统时代 A 改了字段，B 在合主干代码的时候大概率会看到这次提交，即使没看到，B 自己写新代码的时候也是按记忆写的，他大概率会想到字段名是不是变了。但 B 现在不是自己写，是让 Agent 写，Agent 没有他那种上次改过的记忆，它只看它的上下文。A 和 B 之间的认知没对齐，最终以 B 的 Agent 写出错代码的形态暴露出来。

这种失败比传统沟通失败更隐蔽。传统沟通失败有显性信号，B 会在某个时刻意识到自己没听 A 说过这件事，他会主动去问。Agent 上下文不一致没有这种信号，B 的 Agent 写出错代码的时候，它的语气和它写对代码的时候一模一样自信。它不会说我不知道这个字段最近是不是改过，它会按它知道的版本写下去。一群 Agent 上下文之间的不一致，和一群人之间的认知不一致本质相同，只是它不会自己发声，更难察觉。

这件事之前讲的上下文工程是道理相近的，单个 Agent 内部上下文窗口的管理，把它当成系统总线、当成仲裁中心，处理的是一个 Agent 自己不糊涂。这里把它推到团队尺度，要让一群 Agent 不糊涂，本质上是组织级的认知一致性问题。

落到工程上，这会推出几个非常具体的动作。团队级的共享 Skill 库，价值不在于复用能省工作量，那是次要的。它真正的作用是充当团队的共享上下文锚点，反复出现的某类任务，所有人的 Agent 都按同一个 Skill 处理，产出的代码自然就是一致的形态，合到一起不会打架。一份进 Git 的项目级规范不是为了好看，是为了让每个人的 Agent 在生成代码时都从同一份基础上下文出发。

这在 AI 团队里它们是协同的物理底座，没有它们，Agent 之间的上下文就是各跑各的，沟通成本不光不会降，反而会以一种新的、更难察觉的形态膨胀。

14.5 技能壁垒消失之后

AI 还在另一个方向上重塑组织：它正在抹掉技术能力这道传统的分组依据。

一个后端工程师带着 Agent 写前端，以前要花三个月学框架、学样式、学浏览器兼容，现在配合 Agent 一周就能上手交付一个像样的页面。一个写后端的人带着 Agent 写 SQL、写运维脚本、改前端样式，门槛低到几乎可以忽略。技能曲线没消失，但它的爬升时间被压缩了一个量级。

这导致的后果非常直观，全栈的成本变低了。传统组织把工程师分成前端、后端、移动、测试、运维，这种分法的隐含前提是技能壁垒本身构成成本，一个人不可能样样精通，按技能切团队是合理的。这个前提在 AI 时代被抽掉了一半。一个人样样精通仍然不现实，但样样能上手已经现实了，这中间的距离就是 AI 替你跨过的那部分技能曲线。

站在组织的角度上看，会得到一个更尖锐的判断：按职能切团队的合理性少了一半。传统组织里前端组和后端组分开，一个功能要在两个组之间转一圈，前端组等后端组的接口，后端组等前端组的需求。这种分工在传统时代是合理的，因为两边的技能差异大到值得为它支付协调成本。AI 时代两边的技能差异在缩小，协调成本反而成了主要的负担。一个三人小组里一个人主前端、一个人主后端、一个人主测试，他们都能用 Agent 帮自己跨界，这个三人小组的产出大概率高于两个组各两个人加上中间一道协调墙。

全栈门槛低了只是表层，再往下想，会遇到上一个更深的问题。

分工从来不是为了让擅长的人做擅长的事，那只是它的好看说法。分工的真正机制是让不擅长的事被外部化：我不擅长前端，所以我把前端交给前端工程师，这就不再是我的问题。我的工作流被简化，我可以专注在自己擅长的部分。分工的本质是让每个人都能在一个被简化过的、可控范围里工作。

AI 时代情况变了。Agent 帮你把不擅长的部分内部消化掉了，你不需要再把它外部化给别人。前端的活，Agent 替你做大部分，你只需要做判断和兜底。所以分工的合理性被抽掉的不是某个具体的边界（前端 vs 后端），是分工的底层逻辑（把不擅长的事外部化）本身被部分接管了。

那剩下来真正稀缺的能力是什么？不是技能，是判断力。要不要做这件事、做到什么程度、用什么方式做、什么时候停下来、什么时候推翻重来。这些判断 Agent 替不了。它能替你写代码，替不了你决定该不该写；能替你重构，替不了你判断这次重构是不是值得；能给你一个技术方案，替不了你权衡这个方案在你这个项目、你这个团队、你这个阶段是不是合适。

这些判断在传统时代由资深工程师、架构师、技术负责人做，他们用经验和直觉做这些判断。它们在传统时代被分工掩盖了一部分，因为不同岗位的判断范围被切开了，前端工程师不需要操心后端的判断。AI 时代分工的边界模糊，这些判断重新回到每一个工程师的桌面上，而且分量比以前重得多。

T 型人才评估方式在失效，T 字一横代表广度、一竖代表深度，这个模型在传统话语里之所以成立，是因为深度难得，大多数人只能在一两个方向上有真深度，所以只能要广度补齐。AI 时代多个深度并存的成本被压低了，人的价值不再来自我会做什么，而来自我能判断什么该做、做到什么程度、什么时候停。这是一个非常具体的角色位移，从执行端往判断端移。

落到组织上，这推出一个具体的动作：组织重排不是改名字。把前端组改成全栈组、把后端组改成业务组，名字换了一圈，但每个组的人手、汇报关系、考核口径没动，这种改法没用。组织重排是重新分配资源，把团队的重心从按技能集中转向按问题闭环，从前端的所有人在一起做前端，转向完成某个业务能力的所有人在一起做这件业务。前者优化的是技能复用，后者优化的是问题解决。AI 时代后者的红利远大于前者。

14.6 一个反模式：成立独立的 AI 团队

很多公司决定拥抱 AI 编程的第一个动作，是抽调几个人成立一个 AI 团队，负责制定规范、搭建工具链、培训其他团队、推动 AI 落地。这个动作在传统组织行为里非常自然，重要的事专人负责，是过去几十年组织管理的标准答案。

但这个动作放到 AI 编程上，几乎注定会出问题。它不是某个公司执行不到位才会失败，是在结构上就会失败。

要看清楚原因，要看 AI 团队这个设置实际带来了什么。

第一个浮上来的问题，业务团队会把 AI 当成外包能力。既然有专门的 AI 团队，业务团队遇到 AI 相关的问题就会去找他们，Agent 老是写错代码找他们，Skill 不会写找他们，Prompt 没效果找他们。AI 团队成了一个新的服务台，业务团队成了它的客户。AI 这件事和业务团队的本职工作之间，被人为隔出了一道墙。

接着是 AI 团队会逐渐远离真实的业务场景。一个独立的 AI 团队，他们的考核指标会很自然地变成 AI 工具普及率、Agent 任务成功率、接入团队数这些 AI 视角的数字。这些数字和业务团队的真实痛点之间隔着一层雾，AI 团队在自己的视角里是在认真做事，做的事和业务团队真正需要的东西未必匹配。他们搭出来的规范、Skill、工具链经常出现这种症状：看上去面面俱到，业务团队用起来全是不顺手。

更深一层的影响是业务团队的 AI 使用长不出来肌肉。AI 用得好的核心能力，是工程师在自己的工作流里反复试错、慢慢摸出适合自己业务的姿势。这个过程没法外包，因为最懂自己业务的人才知道哪种姿势对、哪种姿势错。一个团队习惯了把 AI 相关的事都交给隔壁的 AI 团队，他们自己就无法习得这种能力，长期看这个团队会被会用 AI 又懂业务这件事抛在后面。

到这里问题就清楚了，成立独立的 AI 团队，是组织在试图用旧逻辑解决新问题。旧逻辑是重要的事专人负责，这条逻辑过去管用，因为过去的重要的事通常是某种专业技能，需要专人长期投入才能掌握。AI 编程不是这样的，它不是某种局部专业技能，而是一种能力底座的下沉，它要重塑的是每一个工程师的工作方式。重塑必须发生在每一个业务团队的内部，没法被外包到一个专门的部门里去。

正确的做法不是把 AI 集中，而是把它嵌进去。每一个业务团队自己长出 AI 的使用习惯，自己摸自己业务里 Agent 该怎么用，自己沉淀适合自己场景的 Skill 和规范。平台团队可以提供底座，模型接入、配额管理、安全审计、共享工具链，这些是组织级的基础设施，集中维护是合理的。但使用现场必须留在业务团队，不能被剥离。

14.7 协同红利的真正来源

回到本章开头的场景，三成的红利在拼接处蒸发，在沟通成本里消失，在认知错位里被吃掉。但这些消失的地方，反过来也是重建的入口。

把个体的隐性认知翻译成团队的显性公共契约，红利才有机会跨过拼接的鸿沟。把组织设计的优化提到技术选型之上，沟通成本才有机会回到合理水位。把一群 Agent 之间的上下文对齐当成组织级的认知一致性问题来处理，共享 Skill、共享规范、共享评估集才会从可有可无变成必须的物理底座。把按职能切团队的旧合理性松开一半，组织的资源才能流向真正稀缺的判断力。

这些动作背后是同一个道理：AI 时代团队的优势，不是谁先用上 AI，而是先把个体红利翻译成协同红利。工具问题三个月就能拉平，组织问题会拉开真正的差距。