20%的工程师写了80%的代码，AI让团队差距更大了

一家金融数据公司的内部调查显示，大约80%的工程师每天都在使用AI智能体。这个数字听起来像是效率革命的胜利，但真正让工程管理者头疼的问题，出现在团队层面。

过去几个月，我花了不少时间与各类工程组织做调研沟通，对象从16人的软件代理公司，到电信运营商、游戏工作室，再到拥有数千名开发者的咨询机构。几乎没有人还在纠结"要不要用AI智能体"这个问题。但当我把听到的反馈按三个层级——个人开发者、团队、组织——重新梳理时，一个模式浮现了出来。

个人开发者确实能借助智能体跑得更快，但提速并不均匀。组织层面关心的是可见性、成本和控制力。而团队层面，恰恰是收益停滞的地方。少数人变得极快，但即便是那些正在重新设计工作流的团队，也很难把"更快的实现"转化为"更快的交付"。

每个人都在用，但没人共享配置

当我问开发者是否共享提示词、规则或指令文件时，得到的诚实回答往往类似于一家IT服务公司架构师的说法："我们还没到那一步，目前只是在早上喝咖啡时交流一下心得。"

即便有些团队已经开始把实践规范化，传播方式也基本靠"渗透"。一家法律科技公司的工程负责人说："没有什么标准。我们会在AI团队的仓库里设定规则，然后它慢慢渗透到那些老的.NET项目里，靠的就是分享什么有效。"

而那些真正系统化共享的团队，做法也很脆弱。一家移动出行公司的平台负责人管理着超过一百个代码仓库，他把基础规则放在一个仓库里，再复制到每个服务中。他解释说："如果我们更新了基础规则，就需要更新所有仓库，但人们可能已经做了自定义修改。"

一位咨询公司的解决方案架构师观察了五十多个客户团队，他补充说，共享配置很多时候只是"表演"：人们热情地创建智能体、技能、CLAUDE.md文件，各种东西。但他们可能会发现，这些实际上让质量变得更差。有些根本就没起作用。

结果是团队内部出现了一道越来越宽的鸿沟。一家地图公司的工程经理举例说："20%的工程师生成了80%的代码，或者说消耗了80%的token。我们并不真正清楚另外那80%的人是更聪明、只是没用好，还是需要培训。"

那位金融数据公司的资深工程师说："熟练度差距很大。如果你写了一个糟糕的提示词，代码库会被读取三遍。"

一家云咨询公司的CEO问出了所有这些问题背后的核心："我的团队里有一个超级明星开发者，他比任何人都强10倍。我怎样才能捕捉他的行为模式，并把它推广到整个团队？"

关于如何与智能体协作的知识，散落在个人配置、Slack讨论串和wiki里。智能体每次任务都从零开始；每个人都要重新解释同样的约定，输出质量取决于"谁在写提示词"，而不是"团队决定了什么"。正如一家大型咨询公司的资深工程师所说："没有人是成熟的。这东西太新了，成熟不起来。"

实现变便宜了，评审没有

"随着我们做得越来越多，我们看到瓶颈转移到了代码评审和规划阶段。实现现在相当快。"那位法律科技公司的工程负责人说。他们已经在人工查看拉取请求之前，运行了一道AI评审关卡。

地图公司对此做了测量："如果只看纯数字，PR时间实际上增加了。可能是人在环路中，或者对质量信心不足，导致人们要检查所有东西。但我们还不知道答案。"

一家大型网络设备商的平台团队，所有人每天都在使用智能体，他们发现了同样的天花板："我们基本上是在把非智能体的流程，套用到变化极其快速的工作上。你能构建100个东西，不代表你应该这么做。人们消费不了那么多。"

一家游戏公司的首席工程师总结了演示与团队真实工作流之间的距离："做实验是一回事，但把东西投入生产——带着所有的流程、好的坏的、评审，以及人们在2026年必须应对的所有事情——那是另一回事。"

瓶颈也会向上游移动。当每五六个开发者配一名产品经理时，开发者完成工作的速度太快，以至于把待办事项整理到"人或智能体可以接手"的状态，本身就成了挑战。

评审流程是为人类节奏的变化设计的。如果验证产出的成本超过了它带来的节省，团队实际上是退步了。

自动化无聊工作，带来新的运维负担

团队非常清楚他们想把什么交给智能体。一家游戏公司的工程负责人分享说："每次有人创建合并请求，我们都想运行特定的检查。每天晚上，我们运行一个文档更新器，遍历所有仓库，确保一切对齐。"

他清单上的下一项是什么？"升级库、升级框架，以更自主的方式处理已识别的安全漏洞。"然而对许多团队来说，仅仅让这些后台自动化跑起来，就仍然是一个障碍，原因是缺乏时间和专门的基础设施。

有些团队已经手工验证了可行性。一家代理公司拿到一张模糊的客户工单，在10分钟内就准备好了拉取请求。现在他们希望这个循环能在无人值守的情况下运行，设想是："当我们结束工作日，第二天回来时，它已经完成了我们要求的所有任务。"

对于那些成功构建了运维流水线的团队来说，阻止他们扩展的不是想法，而是自动化在哪里运行、谁拥有它，以及它如何触达每一个项目。一位咨询公司的资深工程师就构建了这样的东西——一个运行在虚拟机Docker容器里的智能体，对工作流做出反应。

从个人提速到团队交付提速，中间隔着的不是更聪明的模型，而是共享配置、评审流程和运维归属这些"人的问题"。智能体让写代码变快了，但让代码真正交付出去，仍然需要团队自己找到答案。