通用方法 · 熟练
AI 写得更多，为什么项目没更快？
你量的是吞吐量，交付是另一根轴
一份覆盖 718 家公司的研究给出了一个很干净的对照：引入 AI 编程代理后，代码行数涨了 30%、提交涨 20%、拉取请求涨 23% —— 而「已解决的需求」和「完成的功能」没有统计上可察觉的变化。多出来的代码去哪了？去到了评审那一环：拉取请求从提交到合并的平均时长多了 3.45 天（相当于 +49%），被退回修改的比例近乎翻倍，评审者留下的评论多了 35%。这一页讲三件事：① 你的度量表里哪一列是「吞吐量」、哪一列是「交付」② 为什么这两列会分叉（评审是那条没被加速的管道）③ 把评审从「质检关口」改成「共享理解」之后，要盯的是哪三个数。
方法 · 一图看懂
1
先分清两根轴 — 代码行 / 提交 / 拉取请求是「产出了多少」，已解决的需求与完成的功能是「交付了多少」；拿前一根轴的增长去证明后一根轴的增长，是本页要治的那个错
2
找到那条没被加速的管道 — 评审要人读、人要批，它有下限速度；上游写得越快，队列就越压在它前面（本批实测：评审时长 +49%，退回比例近乎翻倍）
3
别用「加了几个评审员」当解法 — 研究里做评审的人占比确实涨了 14%，产出仍然没动；说明瓶颈是流程结构，不是人头数量
4
换掉盯的三个数 — 改成盯：改动等评审等了多久 · 被退回的比例 · 真正上线的是什么；这三个数直接对应「更快写作有没有变成更快交付」
原理 · 为什么有效
「产出更多」和「交付更多」在一条流水线上并不是同一件事 —— 只要中间有一道必须由人把关的工序，上游供给增加只会把那道工序前面堆得更长。AI 改变的恰好是最容易加速的那一段（写），而没改变最难加速的那一段（判断）。这不是 AI 不行，是「度量轴选错了就会自我欺骗」：行数、提交数、工单关闭数都是你这边发生了多少动作，而交付是外部世界因此变了多少。前者对你可见、可实时统计，后者要等客户用到才算数 —— 于是组织很自然地开始报前者。判据一句话：如果一个指标可以在没人使用产品的情况下继续上涨，它就不是交付指标。
适用场景
适用：① 你要为一个「引入 AI 工具」的决定做复盘，需要一套不被吞吐量骗到的判据 ② 你在给团队定 AI 使用后的效率口径 ③ 你正处在「AI 写得很爽、但发版节奏没变」的状态，想找出卡在哪一环。⛔ 不适用：① 需求本身还没定清楚（先定需求，度量是第二步）② 单人或极小团队的探索期（还没到会被度量误导的规模）③ 拿本页去论证「AI 没用」（研究的结论是瓶颈在评审，不是否定 AI）。
自测 · 6 问
我的效率报表里，「交付」那一列不是行数 / 提交数 / 关闭工单数
我能说出自己团队里那道「必须由人把关」的工序是哪一道，以及它现在的排队时长
我知道「被退回修改的比例」这个数，而不只是「平均处理时长」
我不会用「增加了评审人手」当作解法 —— 要么上限来自结构，要么先改结构
我能指出最近一次「AI 让我更快」的改动，最终上线用了多久（含等评审的时间）
我知道这个结论来自哪一批数据（哪家公司、哪段时间），不把它当成对 AI 的整体评判
怎么上手 · 验证步骤
① 打开你现在的效率报表，把每一列标成「吞吐量」或「交付」，标不出来的就单列成「不明」——「不明」那一列通常就是你一直被汇报给上面的东西。② 挑最近三个已经上线的改动，分别记两个数：从提交到合并等了多久、合并到真正被用户用到隔了多久。③ 如果第二段明显比第一段长，说明瓶颈不在写作；如果第一段在引入 AI 后变长了，说明瓶颈就是评审。④ 按「等评审时长 / 退回比例 / 实际上线了什么」三个数，建一页新的周报，把旧的三列留在旁边做对照。⑤ 一个月后回看：旧三列大概率都涨了，新三列涨没涨才是这次决定成不成立的答案。
自检动作：找出你最近一次向上汇报的效率数据，问自己一句「这组数在客户完全不用我们产品的情况下，还能不能全涨」。如果能，那你汇报的是自己的动作，不是交付 —— 这句话不需要别人同意就已经成立。