AI 时代的 DORA 指标：当部署频率开始“撒谎”

这里有一个应该让你感到不安的数字：根据《2025 年 DORA AI 辅助软件开发现状报告》，人均合并的开发者 PR 增长了 98%，而每个 PR 导致的事件增长了 242.7%。部署频率看起来处于“精英”水平。但系统的单位变更故障率比 DORA 测量过的任何时期都要高。

你的仪表盘是一片绿色。你的值班工程师却精疲力竭。测量尺度出了问题。

DORA 指标——部署频率 (deployment frequency)、变更前置时间 (lead time for changes)、变更失败率 (change failure rate)、平均恢复时间 (mean time to restore)——旨在区分高绩效和低绩效的工程组织。十年来，这一框架一直行之有效。频繁发布通常与纪律性相关。极短的前置时间反映了紧密的反馈循环。但这种相关性从未具有因果关系；它是一个由于人类能力限制了吞吐量而成立的代理指标。AI 工具已将这一代理指标与其所测量的底层现实脱钩。

部署频率：数量陷阱

DORA 的基础洞察是：精英团队之所以频繁部署，是因为他们让部署变得细小、安全且常规。因果链条是从能力导向频率。AI 颠倒了这一点：它生成了独立于能力的数量，而数量直接增加了分子。

一个有据可查的案例：一个团队在采用 AI 工具后，每周部署量从 5 次增加到 20 次。在这 15 次新增部署中，只有一次是新功能。其余都是 AI 生成的测试、配置脚手架和样板代码——这些是有效的提交、真实的合并，但完全没有能力信号。在生态系统规模上，仅 Claude Code 就占所有 GitHub 公开提交的 4.5%。AI 智能体生成的 PR 从 2024 年 9 月的 400 万激增至 2025 年 3 月的 1700 万。这些数量现在已经渗透进工程领域的每一个仪表盘。

结构性问题不在于 AI 生成了糟糕的代码，而在于它生成代码的速度超过了人类理解的速度。LinearB 的数据显示，AI PR 的拒绝率为 67.3%，而人工代码仅为 15.6%。大多数虚增部署频率指标的内容根本就不应该被合并，而被合并的内容中，有相当一部分是在由于数量压力而恶化的评审条件下获得批准的。

前置时间：瓶颈只是转移了

变更前置时间测量的是从第一次提交到生产环境所经过的时间。AI 极大地压缩了编码阶段——以前需要数天的包含测试和文档的完整 PR，现在只需几分钟。指标好转了。但实际情况是瓶颈发生了转移。

Faros AI 对 1,255 个工程团队的追踪发现，随着 AI 采用率的提高，PR 评审时间增长了 441%（中位数）。在 AI 高采用率的团队中，评审现在占总前置时间的 50% 以上，而此前约为 20%。记分牌上的前置时间看起来更漂亮，是因为分母中包含了那些从未经过实质性评审的 AI 生成合并。与 AI 出现前的基准相比，中位组织现在合并的未经人工评审的 PR 增加了 31%。

这直接影响到 MTTR：当评审不再是真正的理解检查点，而变成对 AI 输出的橡皮图章时，值班工程师在发生事故时所依赖的组织知识就无法建立。更快的前置时间和对所得系统更浅的理解是同一枚硬币的两面。

变更失败率：持平的百分比，上升的绝对痛苦

变更失败率衡量的是导致生产故障的部署比例。在这里，AI 的影响尤其具有欺骗性，因为该指标是一个比率：如果 AI 让你的部署翻倍，同时也让你的故障翻倍，CFR 保持不变，但你的事故工作量却翻了一番。

GitClear 对 2.11 亿行变更代码的分析更清晰地揭示了这一点。代码流转 (code churn)——即在编写后两周内被重写或撤销的代码行——从 2020 年的 3.1% 翻倍至 2024 年的 5.7%–7.1%。重构（“移动”）的代码占总变更的比例从 24.1% 暴跌至 9.5%。复制粘贴的代码从 8.3% 上升到 12.3%，其中重复代码块增加了 8 倍。大部分这类流转不会立即触发生产故障，因此在代码库积累沉默债务时，CFR 看起来依然稳定。

在确实产生故障的地方，模式非常明显。CodeRabbit 对 470 个开源 PR 的分析发现，AI 协同编写的 PR 总体产生的 issue 多出 1.7 倍，逻辑错误多出 75%，可读性问题多出 3 倍。Uplevel 对 800 名开发者进行了为期三个月的对照研究，发现采用 Copilot 后，PR 中的 Bug 增加了 41%，而周期时间和吞吐量均未改善。变更失败率的分母增长得足够快，足以吸收这些增量，直到最后难以为继。

理解债务与 MTTR 定时炸弹

平均恢复时间 (MTTR) 是 AI 生成代码的累积成本到期兑现的地方。MTTR 取决于事故期间的三种能力：构建故障系统的心智模型、在压力下阅读陌生代码，以及快速进行假设测试。AI 生成的代码削弱了这三者。

Addy Osmani 曾写过“理解债务” (comprehension debt)——即代码量与团队对代码理解程度之间的差距。与技术债务不同，它是无形的。代码库可以编译，测试可以通过，CI 是绿色的。但在凌晨 3 点功能退化时，没有人能解释为什么支付服务会那样运行。

这种机制已有详尽记录。AI 颠倒了编写代码和阅读代码之间历史悠久的速度不对称性。从历史上看，产生变更集比审计变更集要慢，这意味着评审可以作为真正的理解检查点。当一名初级工程师生成代码的速度超过高级工程师批判性评估代码的速度时，该检查点就会崩溃。Anthropic 的一项内部研究发现，使用 AI 进行代码委托的开发者在理解力测试中的得分低了 17%——分别为 50% 和 67%——尽管他们在类似的时间框架内完成了任务。调试理解力显示出最剧烈的下降：而这正是驱动 MTTR 的核心技能。

2025 年发布的 METR 随机对照试验增加了另一个维度。使用 AI 工具（带有 Claude Sonnet 的 Cursor Pro）的资深开源贡献者在处理真实代码库任务时，比不使用 AI 的人多花了 19% 的时间。感知差距非常显著：参与者自我报告速度快了 20%。他们变慢了，自己却不知道，而且到研究结束时，他们在无辅助理解方面的练习也变少了。

当事故发生时，值班工程师发现自己盯着一个涉及 47 个文件的差异对比，其中包含一个引入故障的 3 行 AI 生成变更。没有人认领它。批准该 PR 的工程师只是草草扫了一眼，因为那周有 30 个类似的 PR 提交。MTTR 之所以激增，不是因为修复困难，而是因为诊断困难。

应该衡量什么

DORA 并没有错 —— 它在新的环境下是不完整的。2024 年和 2025 年的 DORA 报告本身也承认了这一点：2025 年的报告正式将返工率（Rework Rate）作为第五项指标，并提升了开发者体验信号 —— 认知负荷、评审负担、对工具的信任 —— 作为领先指标。

当 AI 编写了你大部分代码库时，最重要的辅助指标有：

AI 代码归属与流失率（Churn Rate）。 按 AI 参与程度为 PR 贴标签。追踪最近编写的 AI 代码中有多少百分比在两周内被删除或重写。GitClear 目前测得全行业这一比例为 5.7%–7.1% 且正在上升。团队相对于该基准的流失率是评审质量的一个领先指标。

人工评审覆盖率。 已合并的 PR 中有多少比例经过了实质性的人工评审？这不是一个二元问题 —— 在一个 500 行的 AI PR 上进行 90 秒的批准并不等同于真正的评审。目前中型组织中有 11% 的 PR 在零评审的情况下合并，这是事故风险的底线；而且这个数字正在上升。

资深工程师的评审负担。 在 AI 密集的代码库中，资深工程师是进行有意义评审的瓶颈。这些工程师面临的评审压力预示着评审质量的下降，就像被忽略的警报预示着生产事故一样。Oobeya 将其描述为未来缺陷逃逸（Escaped Defects）最强有力的领先指标之一。

事故期间形成首个假设的时间。 在值班工程师提出关于故障原因的有效假设之前需要多长时间？这比 MTTR 更难量化，但它是对理解质量的真实衡量。一个在 10 分钟 MTTR 的情况下始终需要 40 分钟才能形成假设的团队，消耗的是认知，而非真正的能力。

返工率。 现在已成为 DORA 的正式标准：用于解决用户可见的生产故障的非计划部署比例。它捕捉到了当 AI 生成的代码变更未立即触发事故时 CFR（变更失败率）所遗漏的部分 —— 即数周后出现的反应式救火负担。

DX Core 4 框架由 DORA、SPACE 和 DevEx 的原作者开发，它连贯地涵盖了这些维度：结合评审时间背景的速度、衡量功能开发与 AI 输出修正的有效性、按 AI 与人工代码细分缺陷密度的质量，以及将交付与业务成果联系起来的影响力。使用该框架的组织报告称，新功能研发时间比维护时间多出 14% —— 这才是隐藏在部署频率下的真实指标。

仪表板问题本质上是信任问题

即使在数据可用的组织中，这种情况依然存在是有原因的：DORA 指标很容易向高管展示，而且目前看起来数据很不错。部署频率上升了。交付周期缩短了。很少有工程主管愿意在季度回顾中说：“实际上这些指标具有误导性，我们真实的交付健康状况并不明确。”

但 2024 年的 DORA 报告发现了一些对于管理 AI 辅助团队的人来说应该感到警惕的事情：“高性能”集群的组织比例从 31% 缩减至 22%，而“低性能”集群则从 17% 增长至 25%。总体指标改善了。分布情况恶化了。团队向两极集聚，而不是全面提升。这看起来不像是真正的能力提升 —— 而是指标通胀。

任何采用了 AI 工具的工程组织面临的核心问题不是“我们部署的频率是多少？”，而是“如果 AI 工具不可用，这个团队中有多少工程师能在凌晨 3 点诊断出代码库中的事故？”如果诚实的答案是比两年前更少了，那么部署频率就是在对你撒谎。

DORA 指标从来不是为了被优化而设计的；它们被旨在作为更深层东西的证据。在一个 AI 可以同时虚增每个分子的时代，这种纪律在于找回那层深层意义 —— 并且当证据不再支撑仪表板所讲述的故事时，保持诚实。