AI Coding 研效度量：编码快了 5x，团队为什么没快
每隔几天，我都会在朋友圈刷到这类截图：「用 Cursor / Claude Code 之后，我的编码速度提升了 5x」「以前一周的活，现在一下午搞定」。
但只要你随便挑一个 EM、TL 问一句：你们团队这季度的交付节奏，相比去年快了 5x 吗？ 大概率得到的是沉默或者尬笑。
这中间的落差，就是 AI Coding 研效度量当前最大的问题——度量错了对象。所有人都在量"编码速度"，但"编码速度"根本不是"交付速度"。
主流的度量指标正在反向激励工程师
跟几家一线大厂的同行交流下来，目前主流的 AI Coding 研效指标长这样：
- AI 生成代码占比（行数 / 总代码行数）
- 单次任务从启动到产出代码的耗时
- PR 数量、commit 数量
- Copilot / Cursor 使用频次
这套指标有一个共同毛病：只盯了"编码"这一段，看不到全链路。就像只看时速表却不看导航——开得飞快，但不知道有没有到目的地。
更糟糕的是，这类指标会反向激励工程师：
- 为了拉高 "AI 生成代码占比"，写大量本不必要的代码
- 为了拉高 "PR 数量"，把一个完整改动切成 5 个 PR
- 为了拉高 "使用频次"，连 1 行的修改也走一遍 AI
数字全在涨，但团队真实交付节奏在变慢——因为下游的 Review、测试、回归、问题排查全都被压力堆积。
把研发拆成 6 段，重新算账
合理的度量必须基于完整 SDLC。把研发分成 6 个阶段，每段的 AI 提效区间和质量风险完全不同：
| 阶段 | AI 提效区间 | 主要质量风险 | 真正该看的指标 |
|---|---|---|---|
| 需求理解 | 20-30% | 需求被高效地误解 | 需求返工率 |
| 方案设计 | 40-60% | 过度设计、加抽象 | 方案到落地的变更次数 |
| 代码编写 | 3-5x | 风格漂移、隐性 bug | AI 代码一次通过率 |
| 代码 Review | -30%（反向） | 看不过来、走过场 | Review 周转时长 + 回滚率 |
| 测试验证 | 50% | 实现与测试同源同盲 | 上线缺陷率（不是覆盖率） |
| 部署运维 | 30% | 故障定位变慢 | MTTR |
注意 Review 是负数——AI 代码量爆炸之后，人工 Review 的总时长反而是上升的。这是被绝大多数研效报告刻意掩盖的事实。
用 Amdahl 公式给老板算笔账
假设传统团队的时间分布是这样：
传统团队 100% 基线
─────────────────────────────
需求理解 ███ 15%
方案设计 ███ 15%
代码编写 ██████ 30% ← AI 主攻区
代码 Review ██ 10%
测试验证 ████ 20%
部署运维 ██ 10%
即使编码提效 5x（30% → 6%），其他不变，总时间从 100% 降到 76%——只省 24%。
但实际上，Review 和测试会因为 AI 产出代码量增加而变长：
AI 化团队 ≈80% 基线
─────────────────────────────
需求理解 ███ 15%
方案设计 ██ 12%
代码编写 █ 6% ← 5x 提效
代码 Review ███ 15% ← 代码量大，Review 变多
测试验证 ████ 22% ← 盲点放大，复测变多
部署运维 ██ 10%
─────────────────────────────
合计 80% （净省 20%）
20%，不是 5x。这才是大多数团队拿了 Cursor / Claude Code 之后该看到的真实数字。如果你的团队报告写着"AI Coding 提效 300%"，要么是只测了编码段，要么是数字造假。
瓶颈不是消失，是搬家了
更要命的是：AI Coding 没有"消除"瓶颈，它把瓶颈搬到了别的位置。
传统瓶颈：
[需求]→[设计]→[编码]→[Review]→[测试]→[部署]
▲▲▲▲▲▲
卡点：人写代码慢
AI 化之后：
[需求]→[设计]→[编码]→[Review]→[测试]→[部署]
▲▲▲▲▲▲▲ ▲▲▲▲▲▲
新卡点 1 新卡点 2
新瓶颈具体长什么样：
Review 队列堆积：AI 一晚上产出 3 个 PR，资深工程师早上花一上午也看不完。结果要么积压、要么走过场点 approve，潜在的线上 bug 等于直接放过去。
测试同源盲点：AI 写实现 + AI 写测试，两者共享对需求的同一份（可能错误的）理解。覆盖率数字漂亮，但漏掉的边界条件，实现里和测试里漏在同一个地方。我们团队复盘过一次线上事故——AI 写的代码自测全过，上线即翻车，根因是 spec 模糊导致 AI 把"用户不存在"理解成了"用户存在但字段为 null"。
故障定位变慢：AI 代码没有原作者完整理解。出问题时工程师要先"读懂"一份本来不是自己写的、风格可能还不一致的代码——MTTR 显著上升。海外团队的公开复盘里已经出现这类原话：「this code was AI-generated and the original author can't fully explain why it does X」。
我们团队是怎么改度量指标的
承接上一篇讲的 harness 工程——我们团队在系统性推 AI Coding 时，把度量指标从"AI 生成代码占比"彻底改成了 4 个：
1. AI 代码一次通过率
agent 产出的代码，完全无人工修改进入主干的比例。这个指标比"生成行数"诚实得多——一个被人改了 30 行的 PR，根本不该被算成"AI 写的"。
2. 全链路周期时长（需求待开发 → 上线验证）
不看"编码用了多久"，看"需求进入待开发 → 线上验证完成"的全链路时长。AI Coding 真正起作用时，这个数字应该下降。它没动，"提效 5x" 就是错觉。
3. 上线后回滚率 / Hotfix 比例
提效不能以质量为代价。一个团队如果 PR 合并速度翻倍、但 hotfix 率也翻倍，净收益是负的——一次线上回滚的代价比省下来的开发时间高一个量级。
4. Review 投入时长
度量 reviewer 在 AI 代码上的人均周耗时。这个数字如果失控上涨，意味着 AI 把成本从"编码者"转嫁到了"reviewer"，团队总成本没变、甚至变高。
这 4 个指标合起来，才能回答真正重要的那个问题：团队是变快了，还是只是写代码的人变爽了？
给 3 类人的具体动作
工程师：别再发 "AI 帮我写了 X 行" 截图了
那个指标除了让你 KPI 好看，对团队没意义。盯你自己的 PR 一次通过率——这才是你正在以可持续方式利用 AI、还是在制造 Review 债务的真实信号。
如果你一次通过率长期低于 60%，意味着你提的 PR 一半以上要 reviewer 帮你擦屁股。短期你的"产出"看起来高，长期你在团队信誉里持续掉分。
TL / EM：抛弃 "AI 生成代码占比" 这个 KPI
这个指标不仅没用，还会反向激励。改成"全链路周期时长 + 回滚率"两个数字一起看。
向上汇报时也别再讲"我们团队 AI 渗透率 80%"——老板听不出区别，但你的资深工程师都知道这是在凑数。讲"我们交付周期从 12 天降到 10 天，同时回滚率从 8% 降到 5%"才是真正的研效。
老板 / 一号位：别被 "5x 提效" 忽悠
下次有人汇报"AI Coding 提效 300%"，问三个问题：
- 这是"编码段提效"还是"全链路提效"？
- 同期质量数据（hotfix、回滚、线上 bug）是什么趋势？
- Review 投入有没有失控上涨？
90% 的"提效报告"在第一个问题就崩了。剩下 10%，才是真在做 AI 研效的团队。
收尾：下一波研效杠杆在哪
AI Coding 不会让团队整体提效 5x——这一点从 Amdahl 公式里就能算出来。真实区间是 15-30%，而且必须配套科学的度量体系才能拿到。
更重要的是：下一波研效提升不在"编码更快"——那里已经接近天花板。下一波杠杆在全链路的两端和中间的新瓶颈：
- 前置：把需求和 spec 结构化，让 AI 真正理解业务约束（消灭"需求被高效误解"的灾难）
- 中段：AI Review 从挑错别字升级到挑架构腐烂（疏通新瓶颈）
- 后置：可观测性驱动的自愈——异常 → AI 定位 → 提 PR（缩短 MTTR）
这是 2026 年技术管理的核心命题。谁先建立科学的研效度量体系，谁就能把 AI Coding 从"个人玩具"变成"团队稳定产能"。
至于那些还在朋友圈晒 "Cursor 帮我写了 800 行" 截图的工程师——他们正在精确地度量错误的东西。