更快的开发者并不等于更快的团队

工程团队对与 AI 智能体协作的看法。本系列第 1 部分。

过去几个月，我花了很多时间与各类工程组织进行需求发现电话沟通，从一家拥有 16 名开发者的软件代理公司，到电信公司、游戏工作室，以及拥有数千名开发者的咨询公司。几乎没有人还在问要不要使用 AI 智能体。在一家金融数据提供商，一项调查显示，大约 80% 的工程师每天都使用它们。

当我把听到的内容分成三个层面——个人开发者、团队和组织——时，一个模式浮现出来。个人开发者现在借助智能体可以快得多，但收益并不均衡。组织层面关乎可见性、成本和控制。团队层面则是收益停滞的地方。少数人变得快了很多，但即使是正在重新设计工作流的团队，也很难把更快的实现转化为更快的交付。

以下是我最常听到的三种情况。

1. 每个人都有智能体。没有人共享配置。

当我问开发者是否共享提示词、规则或指令文件时，诚实的回答通常都类似于一家 IT 服务公司的架构师告诉我的那样：“我们还没到那一步。我们只是在早上喝咖啡时分享知识。”

即使有些团队已经开始把实践规范化，它也是靠渗透式传播。一家法律科技公司的工程负责人说：“没有标准。我们会在 AI 团队的仓库里设定它，然后只是通过分享有效做法，它慢慢也会渗入那些更老的 .NET 仓库。”

在共享已成体系的地方，它也很脆弱。一家拥有超过一百个仓库的出行公司的平台负责人，把基础规则放在一个仓库里，再复制到每个服务中，他解释道：“如果我们更新基础规则，就需要更新所有仓库，而其中一些可能已经被人定制过了。”

一家咨询公司的解决方案架构师观察着五十多个客户团队，他补充说，共享配置往往只是做样子：

“人们热衷于创建智能体、技能、CLAUDE.md 文件，什么都做。但他们可能会发现，这实际上让质量更差了。有些根本不起作用。”

结果是团队内部差距不断扩大。一家地图公司的工程经理举例说：“20% 的工程师生成了 80% 的代码，或者说消耗了 80% 的 token。我们并不真正知道另外 80% 的人是更聪明、只是没用好，还是需要培训。”

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

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

关于如何与智能体协作的知识，存在于个人配置、Slack 讨论串和 wiki 中。智能体每次开始任务时都是冷启动；每个人都要重新解释同样的约定，输出质量取决于谁在写提示词，而不是团队决定了什么。正如一家大型咨询公司的一位高级工程师所说：“没有谁是成熟的。这东西太新了，还成熟不了。”

2. 实现变便宜了。评审并没有。

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

那家地图公司对此做了测量：“如果只看纯粹的数字，PR 时间实际上增加了。这可能是由于人工介入，或者对质量信心不足，导致人们要检查一切。但我们还不知道答案。”

一家大型网络厂商的平台团队里，每个人每天都使用智能体，他们也发现了同样的天花板：“我们基本上是在把非智能体驱动的流程，应用到变化非常、非常快的工作上。

“能构建 100 样东西，并不意味着你就应该这么做。人们消化不了那么多。”

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

瓶颈也会向上游移动。每五到六名开发者才配一名产品经理，开发者完成工作的速度太快，以至于要让待办事项进入可被人或智能体接手的就绪状态，变得很有挑战。

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

3. 自动化枯燥工作会带来新的运维负担。

团队很清楚自己会把什么交给智能体。一家游戏公司的工程负责人分享道：“每次有人创建 MR（合并请求）时，我们都想运行特定的事情。每天晚上，我们会运行一个文档更新器，遍历所有仓库，确保一切保持一致。”

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

有些团队已经手工验证过这一点。一家代理机构拿到一张含糊的客户工单，在 10 分钟内就准备好了拉取请求。现在他们希望这个循环能在没有他们的情况下运行，设想“当我们结束工作日，第二天回来时，它已经完成我们要求它做的所有任务。”

对于那些确实设法构建了运维流水线的团队来说，阻止他们扩展的不是想法，而是自动化在哪里运行、由谁拥有，以及它如何触达每个项目。一家咨询公司的一位高级工程师就构建了这样的东西——一个运行在 VM 上的 Docker 容器中的智能体，对 webhook 做出反应——然后撞了墙：

“主要问题是我们必须维护它。如果我们在一个客户那里部署了，我们还必须弄清楚如何把更新分发到另一个项目。”

与此同时，平台负责人变成了一个人肉 API；而当每个团队各自搞自动化时，协调就会崩溃。来自那家出行公司的说法是：“今天，后端团队问，‘你能给我们一个 GitHub 里 CI 用的密钥，以及一个用于自动生成测试的 secret 吗？’”而当每个团队都各自搞自动化时，协调就会崩溃。那家游戏公司则有过：“一场非常激烈的讨论，关于如何控制人人都想创建智能体、而我们又没有办法治理它的局面。”

这些情况的共同点

给每个开发者一个能力很强的智能体，本身并不能解决这些问题。有些团队缺少共享基础设施，而另一些团队已经在构建它，并发现维护它需要持续投入。我们正在围绕这一缺口构建 Air Teams。

在接下来的文章中，我会逐一讨论这三种情况——共享上下文与技能、为智能体产出而构建的评审，以及由团队共同拥有的自动化。基于真实的客户故事，我会展示共享意图、决策、影响和验证结果，如何帮助下一个人独立理解变更，并减少评审工作量。

敬请关注。