AI 编程提速后交付没变快？用 DORA 四指标定位研发效能瓶颈

定义框：AI 生产力悖论是指团队引入编码智能体后，个人编码效率显著提升、合并请求数量增长，但部署频率与变更前置时间等组织级交付指标并未同步改善的现象。其成因不是工具失效，而是交付链路的约束环节从编码位移到了评审、构建与发布环节。

为什么个人变快了，团队却没变快

过去两年，编码智能体把"写代码"这件事压缩得很厉害。函数实现、样板代码、陌生语言的语法、单测骨架，这些过去要花时间的部分，现在几分钟就能拿到第一版。一线工程师的体感很一致：确实快了。

但很多团队在统计组织级指标时发现一个尴尬的结果——个人产出涨了，合并请求涨了，部署频率和变更前置时间却基本持平。有的团队变更失败率甚至还上升了：代码产出变快，缺陷也以同样的速度被生产出来。

原因不复杂。交付是一条链，链的速度由最慢的一环决定，而不是最快的一环。

在引入 AI 之前，编码本身就是最慢的环节。评审慢一点、流水线堵一点、环境少一点，都被"反正大家都在等代码写完"掩盖了。当 AI 把编码时间压下来，这些次要矛盾立刻升格为主要矛盾——瓶颈没有转移，它一直都在，只是以前看不见。

这在排队论里是典型现象：上游产出速率突然翻倍、下游吞吐不变，积压会全部堆在最窄的那个口子上。对个人来说，等待只是从"写代码时"挪到了"等评审时"，总量没变，体感反而更差。

如何用四个指标定位真正的瓶颈

判断瓶颈不能靠感觉。行业里通行的四个指标依然是最可靠的诊断标尺：

四个必须一起测。只测部署频率最容易，也最容易骗人——部署频率上升的同时变更失败率同步上升，那不是提效，是灾难提速。

第一步：区分排队时长与处理时长

这是最关键也最容易做错的一步。一次构建跑了 8 分钟，是处理时长；这个构建在队列里等了 40 分钟才被调度，是等待时长。绝大多数团队优化的是前者，但对吞吐影响更大的是后者。

沿交付链路逐环节统计"等待时长 / 处理时长"的比值，比值最大的那一环就是当前最窄的口子。

第二步：把数据取出来算一遍

流水线与合并请求的数据都可以通过 API 取出。以合并请求的评审等待为例：

export GITLAB_HOST="https://gitlab.cn"
export TOKEN="your-access-token"
export PROJECT_ID="123"

curl -s -H "PRIVATE-TOKEN: $TOKEN" \
  "$GITLAB_HOST/api/v4/projects/$PROJECT_ID/merge_requests?state=merged&per_page=100" \
  -o mrs.json

import json
from datetime import datetime

mrs = json.load(open('mrs.json'))
waits = []
for m in mrs:
    created = datetime.fromisoformat(m['created_at'].replace('Z', '+00:00'))
    merged  = datetime.fromisoformat(m['merged_at'].replace('Z', '+00:00'))
    waits.append((merged - created).total_seconds() / 3600)

waits.sort()
n = len(waits)
print(f"样本数: {n}  中位数: {waits[n//2]:.1f} 小时  P95: {waits[int(n*0.95)]:.1f} 小时")

看中位数，不看平均值。 平均值会被一两个挂了很久的合并请求拉爆，中位数才反映常态。

第三步：只改最窄的那一环

找到瓶颈后，一次只改一个环节，改完重新测，确认指标真的动了再进下一个。同时改五个环节的团队，通常一个都改不好——因为无法归因。

如果瓶颈是构建排队，有效的动作是分层与按变更触发，而不是加机器：

# 改前：任何提交都跑全量
test:
  script: npm run test:all
  rules:
    - when: always

# 改后：快的先跑，重的按需跑
test-unit:
  script: npm run test:unit
  rules:
    - when: always

test-e2e:
  script: npm run test:e2e
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - src/**/*
      when: always
    - when: never

三个容易踩的坑

把提交到合并、合并到生产混在一起算前置时间。 这两段的瓶颈完全不同——前者通常是人和流程，后者通常是机器和环境。必须拆开测，否则会把评审问题误判成流水线问题，然后花两个月优化根本不是瓶颈的地方。

用活动指标冒充结果指标。 提交数、合并数、AI 代码采纳率这些都在涨，但它们涨不代表价值涨。真正重要的是变更前置时间与变更失败率，两者同时改善才算真的提效。

忽略测试稳定性。 偶发失败在低频提交时是可容忍的噪声，在高频提交时会摧毁流水线的信号价值。一旦团队养成"红了就重跑"的习惯，后面所有指标都是脏的。重跑即通过的比例超过 10%，先治理测试，别去动性能。

什么时候不该上平台工程

瓶颈定位之后，很多团队会直接跳到"建内部开发者平台"。这里有个边界要讲清楚：平台工程的收益来自协调成本的降低，不是工具数量的增加。

团队只有十几个人、沟通本来就顺畅的时候上全套平台，大概率会得到一个只有建设者自己看得懂的系统。判断标准很朴素——当你的协调成本已经明显超过平台的建设与维护成本时，才应该启动，而不是因为别人都在做。

常见问题

Q1：我们团队不到十个人，这套度量值得做吗？

值得，但可以极简。四个指标里先只测变更前置时间和变更失败率，用一次性的脚本跑一遍就有结论。完整平台化不必做，但"先测量再改动"这个顺序在十人团队同样成立——它避免的是买错工具这种最贵的错误。

Q2：引入 AI 之后变更失败率上升了，是工具的问题吗？

通常不是工具问题，是评审环节被削弱了。AI 生成的代码形式规范、注释完整，容易让评审者产生"应该没问题"的错觉。表现为失败率上升而不是速度下降，所以容易被误判成质量问题。应对方式是明确评审责任人与拆分合并请求粒度，而不是降低对 AI 产出的审查标准。

Q3：度量做完了，瓶颈改不动怎么办？

先看瓶颈属于技术还是流程。技术类（构建排队、环境供给）通常有明确的工程解法；流程类（发布审批、跨部门协调）需要从组织侧推动，把优化项绑定到一个具体的业务指标上再提，比单纯讲效率更容易获得支持。强监管行业的人工审批属于合规要求，正确做法是把审批前移到需求阶段，而不是绕过它。

真正决定交付速度的，永远是链上最慢的那一环。 把最快的一环再加速两倍，对整体没有帮助——它只会让积压变得更长。

想把你自己的交付链路跑一遍？ 先从四个指标的基线测起，别急着买工具。你可以先了解极狐GitLab 的流水线与研发效能能力（https://gitlab.cn），或直接从官方文档中心（https://docs.gitlab.cn）查阅流水线配置与 API 用法。