衡量真实的 AI 编程生产力：能在 90 天滞后期中幸存的指标

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。

90 天分歧

相关研究非常一致，足以将其称为一种模式。对数百个工程团队的分析显示，代码流失率（Code Churn，即代码编写后两周内被修改的比例）自 AI 普及以来增加了一倍多，从 2021 年的约 3.3% 上升到近年来的 5.7–7.1%。在 AI 采用率高的环境中，变更失败率跃升了 30%。即使 PR 数量激增，每个 PR 的事故率也上升了 23.5%。

为什么会有滞后？前 30 天看起来不错，是因为 AI 消除了打字阶段的摩擦。编写代码变快了。开发者感到生产力很高。但交付过程在代码写完后还要持续很久：审查、集成、生产环境调试，以及最终的维护 —— 在所有这些活动中，AI 生成的代码是在制造摩擦，而不是消除摩擦。

AI 编写的代码追求的是外观而非正确性。它逻辑连贯、可以编译、能通过 Linter 检查。但它通常缺乏对更广泛系统的理解所带来的判断力：为什么某个特定边缘案例很重要，数据模型是如何演进的，六个月后触碰这个模块会发生什么。这种判断力体现在审查评论、生产事故以及新工程师理解他们所看到的内容所需的时间中。

捕捉这种失效模式的指标直到代码发布 60–90 天后才会显现。

具有误导性的速率指标

代码行数在多年前就失去了意义。当 AI 可以在开发者写 50 行代码的时间内生成 1 万行代码时，统计行数几乎毫无意义。它既不能说明正确性，也不能说明可维护性，甚至不能说明问题是否值得解决。

PR 吞吐量更具诱惑力，因为它感觉像是真实的产出。一项针对 1,255 个工程团队的研究发现，高 AI 采用率团队的每个开发者合并的 PR 数量增加了 98%。但与此同时，PR 审查时间增加了 91% —— 瓶颈从编写转向了审查，而没有人衡量审查者的时间成本。

故事点速率也面临类似的问题。交付更多功能的团队并不一定交付了更多价值。当 AI 生成的代码包含逻辑错误的概率高出 1.75 倍，且包含的提权路径比人类编写的代码多 322% 时，如果审查质量没有成比例提高，那么高速度实际上是具有风险的。

深入了解代码库的资深开发者往往能发现这些问题。忙碌或在非专业领域工作的开发者则倾向于更快地接受 AI 代码。关于“自动化偏见”的研究很明确：人类接受错误的自动化建议的比例比接受同等错误的人类建议高出 26%。AI 生成的代码带有一种含蓄的权威感，让审查者不太愿意提出质疑。

揭示真相的滞后指标

真正揭示 AI 编程 ROI 的指标需要时间来积累，但它们衡量的是正确的东西。

变更失败率 (Change Failure Rate) 是最重要的单一数字。它是指需要补救（回滚、热修复或紧急补丁）的部署百分比。CFR 捕捉到了速率指标系统性隐藏的代码质量失效。在重度使用 AI 的环境中，它是质量问题的最早聚合信号。建议以 90 天为滚动窗口进行监控，并尽可能按提交来源进行细分。

代码流失率 (Code Churn)（代码编写后两周内被修改的比例）已成为该类别中关键的先行指标。第 30 天上升的流失率能够可靠地预测第 90 天的事故率飙升。AI 采用率高的团队会出现重复重写相同文件的提交模式 —— 这是一个信号，表明 AI 代码在审查期间不明显的方面存在错误。按作者或工具采用人群跟踪流失率，可以及早发现这一信号并采取行动。

每个 PR 的事故率将发布决策与生产结果联系起来。随着 PR 量的增加，这一比率需要保持平稳或下降。当它上升时，无论速率数字如何，采用 AI 的账面收益都会变得不划算。

审查负担在大多数公司都缺乏量化。资深工程师审查 AI 生成的 PR 所花费的时间，比审查人类编写的代码更多 —— PR 规模更大（平均大约 18%），包含更细微的错误，并且需要更多的验证工作。如果资深工程师审查 AI 代码的总时间超过了团队使用 AI 工具节省的时间，那么投资回报率（ROI）绝对是负数。

维护断崖前的领先指标

滞后指标是确定的，但它们来得太晚。一些信号在 4–8 周时就会出现，并提供足够的缓冲时间来纠正方向。

评审队列深度的增长速度快于 PR 数量是最早的信号之一。这意味着评审人员正在成为瓶颈，这通常表明代码质量正迫使评审更加谨慎——要么是自觉的，要么是因为评审人员发现了需要返工的问题。

每行代码的评审评论数上升意味着代码变得越来越难理解。这与评审人员变得更加彻底是不同的：如果评论率在评审人员行为没有变化的情况下上升，说明代码本身已经变得更加晦涩。

修改现有代码的时间与编写新代码的时间发生背离是一个理解债信号。AI 工具显著加速了纯新代码的编写。它们对修改现有的 AI 生成代码没有帮助（而且通常会减慢速度）。当这两个指标分开时，团队积累的代码中，他们理解得越来越少。

静态分析警告趋势是质量的机械代理指标。安全扫描器在 AI 生成的代码中发现的漏洞比人工编写的代码多 2.74 倍。静态分析警告数量增加 4.94 倍——即使测试通过——也是对这一差距的直接衡量。

DORA 框架缺失了什么

DORA 指标（部署频率、变更提前期、平均恢复时间、变更失败率）对于 AI 时代的开发是必要但不充分的。前三个指标通常会随着 AI 的采用而提高。变更失败率是捕捉质量偏离的 DORA 信号，这就是为什么值得将其余指标隔离开来。

SPACE 框架增加了开发者满意度、沟通和效率信号，但它并不是为了 AI 编程工具降低产出的特定路径而设计的。这两个框架都需要补充。

它们留下的空白围绕着理解。开发者可以在不深入理解的情况下编写、交付甚至维护代码——特别是使用能按需生成看似合理的解决方案的 AI 工具。传统框架衡量产出了什么以及有多快。它们不衡量团队是否理解他们正在维护的内容。

理解债是存在于仓库中但不被需要更改它的人所理解的代码的累积成本。它表现为事件响应变慢、调试时间变长、现有功能（相对于新代码）的变更失败率更高，以及在初始提升后入职速度变差。这些是可衡量的。大多数团队只是没有衡量它们。

早期发现问题的仪表盘

建立有效的 AI 编程测量需要跨越三个时间维度：

即时信号（每日或按 PR 更新）：

• PR 大小分布——将任何超过 400 行的标记为评审质量风险
• AI 建议采纳率——采纳率下降是相关性下降的早期信号
• 评审周期时间——合并前评审时间的上升

每周信号：

• 按阶段或文件区域划分的代码变动率 (Code churn rate)
• 评审负担时长（评审人员在 AI 生成 vs 人工生成 PR 上花费的总时间）
• 静态分析警告计数的增量

每月信号（需要足够的数据才有意义）：

• 按代码来源细分的变更失败率
• 每个 PR 的事故率
• 新工程师的入职速度（到第一次有意义贡献的时间）
• 资深工程师在编写、评审和调试之间的时间分配

值得注意的一个发现：入职速度确实随 AI 的采用而提高，自广泛采用以来，达到第十个 PR 的时间下降了约 50%。这是一个真正的胜利。AI 工具擅长减少对不熟悉代码库的摩擦——生成模板代码、解释约定、寻找相关示例。问题不在于 AI 编程工具不产生价值；而在于价值体现在速度指标上，而成本体现在质量指标上，而大多数团队只衡量前者。

正确的问题

对于工程经理来说，有效的问题不是“我们的团队使用 AI 工具后变快了吗？”而是“我们的团队使用 AI 工具交付的代码，其持有成本是比以前更高还是更低？”

这个问题需要衡量变更失败率、代码变动率、评审负担和理解指标——而不是 PR 吞吐量。它需要耐心，因为真正的信号需要 90 天才能积累。它还需要组织意愿去查看那些可能会使“AI 工具是毫无疑问的胜利”这一叙事变得复杂的数字。

在部署 AI 工具之前建立质量基准、从一开始就配置正确的指标、并将代码理解视为一级工程关注点的团队，将能够诚实地回答这个问题。那些衡量速度并将其称为生产力的团队将以艰难的方式发现维护断崖——通常是在一名资深工程师离开，而没有其他人能解释为什么代码库会执行当前的操作时。

工具确实有用。测量必须跟上。