速度幻象：为什么 AI 团队提交了更多 PR，但价值交付却变慢了

你的仪表盘从未如此好看。合并的 Pull Request (PR) 数量几乎翻倍。每个工程师的提交次数正在攀升。代码行数源源不断。每一个活动图表都呈现上升趋势，你在六个月前引入的 AI 编程工具看起来是公司今年最划算的一笔支出。

然后，你检查了一个没人会放在幻灯片里的数字：客户从提出需求到实际拿到东西需要多长时间。这个数字纹丝未动。在某些季度，它甚至变得更糟。团队正在产出更多的一切，除了业务真正买单的东西。

这就是“速度幻象”。容易统计的指标上升了，而真正重要的结果却在悄然下滑。这是目前工程领域最昂贵的衡量失败之一，因为它看起来完全像是成功。

幻象并非虚构。当 Faros AI 分析了来自 1,255 个企业团队、超过 10,000 名开发者的遥测数据时，发现 AI 使用率最高的团队合并的 PR 数量增加了 98% —— 但他们的 PR 审查时间也随之膨胀了 91%。卡内基梅隆大学对 807 个采用 Cursor 的仓库进行的一项研究发现，代码行数在第一个月激增了 281%，但到第六个月时这一优势几乎消失，同时代码复杂度上升了 41%，静态分析警告增加了 30% 且从未下降。吞吐量是真实的，但价值并没有随之而来。

为什么活动与结果脱节了

在软件开发的大部分历史中，活动是产出的一个不错的替代指标。编写代码是瓶颈，所以编写更多代码的团队通常交付得更多。统计提交数和 PR 数虽然偷懒，但它与你关心的事物相关，而且这种相关性强到足以让人不至于栽跟头。

AI 打破了这种相关性。当生成代码变得几乎免费时，代码量就不再能说明交付价值的任何信息。你可以在一个下午生成一个 4,000 行的 PR。这个数字说明不了功能是否正常、是否有人能审查它、下周是否需要重写，或者客户是否真的想要它。

实际发生的是瓶颈转移了。它过去位于代码编写环节，现在则转移到了下游 —— 审查、集成、测试，以及安全交付所需的人类理解力。更快地生成代码并不能缓解这个瓶颈，反而是在喂饱它。AI 每多生成一行代码，人类在凌晨 3 点被呼叫时仍需理解、审查并负责。活动指标衡量的是变廉价的部分。结果指标衡量的是没有变廉价的部分。

这就是为什么“PR 合并数”已成为一个虚荣指标。它只统计了流水线中容易的那一半，而忽略了现在决定交付速度的另一半。

掩盖减速的指标

速度幻象的危险之处在于，那些误导性的指标本身并没有错 —— 它们只是准确地衡量了错误的东西。以下是每个指标如何让你误入歧途：

• 提交数和合并的 PR 数上升是因为编写成本变低了。它们告诉你键盘有多忙，而不是有多少价值跨越了终点线。
• 代码行数在 AI 时代甚至比没用更糟。GitClear 对超过 2 亿行变更代码的分析发现，2024 年复制粘贴的代码首次超过了重构的代码，且代码流失 (Code Churn) —— 即两周内被重写或还原的代码 —— 从 3.1% 翻倍至 5.7%。代码行数增加越来越多地意味着更多的重复和更多的返工，而不是更多的能力。
• 单个 PR 的周期时间甚至可能缩短，因为每个 PR 写起来都很快。但端到端的交付周期 (Lead Time) —— 从“客户要求”到“客户拥有”的时钟时间 —— 却随着这些 PR 在无人能跟上进度的审查队列中堆积而拉长。

2024 年 DORA 报告精准地量化了这个陷阱。随着 AI 采用率的提高，研究人员估计，每增加一次显著的依赖，交付吞吐量就会下降 1.5%，交付稳定性就会降低 7.2%。开发者觉得生产力更高了，个人产出也更多了。系统交付得更少，且崩溃更频繁。两者之间的差距就是被量化后的幻象。

加载中…