如果只记一个数字，记这个：10%~20%。这是过去两年里，方法上说得过去的研究在真实项目上跑出的净提效区间。厂商口径是 40%~55%。

第二个数字更值得警惕：开发者自己报告的提效幅度，比实际测出来的高 20 到 40 个百分点。

三个被引用最多的数字，互相打架

METR 的随机对照试验是目前设计最干净的一个。2025 年 7 月发布：16 名资深开源开发者，都在自己有多年提交记录的仓库里干活（平均 2.2 万 star、百万行以上代码），246 个真实工单随机分两组，一组可以用 AI（绝大多数选 Cursor Pro 配 Claude 3.5/3.7 Sonnet），一组不许用。

用 AI 的那组平均慢了 19%。而事前，这些人预测 AI 能让自己快 24%；干完之后，自感快了 20%。

细节比结论更有价值：他们对 AI 建议的接受率不到 44%，75% 的人说自己逐行读了 AI 的输出，56% 需要对 AI 写的代码做大改才算完。

反方向的证据同样硬。微软、埃森哲等公司的 4800 名开发者数据里，用 Copilot 的人完成任务数多 26%；另一个受控实验里，同一个 HTTP 服务器任务，Copilot 组 1 小时 11 分，对照组 2 小时 41 分，快了 55.8%。

两组数据都不假。冲突来自任务本身。

把任务拆开，矛盾就消失了

把上面几份研究的任务类型拉平对齐，规律相当清楚：

同一个工具，在你的老仓库里改一个你闭着眼都知道在哪的 bug，是负担；让它写一遍你已经想清楚的样板代码，是净赚。METR 那批 2.2 万 star 的成熟项目，恰好把第一行拉到了极致。

这就是为什么"AI 提效"这个问法本身有问题——不限定任务类型，这个数字没有意义。

2026 年的数据，把账记到了审查环节

Faros AI 在 2026 年 4 月发布的遥测报告，覆盖 2.2 万名开发者、4000 多个团队、两年纵向数据，不是问卷。

产出侧很好看：人均任务吞吐 +33.7%，人均完成的 epic +66.2%，AI 代码无改动接受率一年内从 20% 涨到 60%。

下游侧是账单：人均 bug 数 +54%，每个 PR 对应的事故率 +242.7%，PR 审查中位耗时 +441.5%，两周内被重写的代码量 +861%，零审查直接合入的 PR +31.3%。

LinearB 用 810 万个 PR 补上了机制：75 分位下，AI 参与的 PR 超过 400 行，人工 PR 是 157 行；AI PR 等到第一个审查人要 16 小时以上，人工 PR 约 200 分钟；30 天内合并率 32.7%，人工 PR 是 84.5%。

生成变快了，验证没变快。团队层面看，瓶颈只是换了个位置——从"谁来写"挪到了"谁来读"。

最反直觉的一份：提交量根本没动

挪威劳工福利局（NAV IT）的研究，2026 年 1 月发在 HICSS-59：26317 个非合并提交，703 个仓库，跟踪两年，25 名 Copilot 用户对 14 名非用户，外加 13 场访谈。

结论是：采用 Copilot 之后，基于提交的客观活动指标没有出现统计显著的变化。更值得注意的是另一句——用 Copilot 的人在被引入工具之前，本来就比不用的人更活跃。

Stack Overflow 2025 年那份 9 万多名开发者的调查可以对照着看：认为大幅提升效率的 16.3%，有所提升的 42.3%，几乎没有影响或没有影响的 41.4%。

两边并不冲突。体感变轻是真的，写代码的摩擦确实少了；但摩擦减少不等于产出增加，中间的差额去了审查、调试和返工。

这笔账该怎么算

三条判断：

提效是真的，量级在 10%~20%

。DX 对 8.5 万名开发者的调查给出的是每周节省 3.6 小时，但这是自报口径。真正能落到交付指标上的数字，比它小。

分布极不均匀

。提效集中在你已经知道正确答案、只是懒得敲的任务上。在你还没想清楚的任务上，它接近零甚至为负——省下的打字时间，会在逐行读它写了什么的时候还回去。

净收益取决于审查能力，不是生成能力

。同一套工具，测试和类型强的团队留下大部分收益；没有的团队只是更快地制造 bug。

所以别问"AI 让我快了多少"。这个问题问不出可靠答案，METR 里开发者自估和实测差着近 40 个百分点。

改问一个更具体、也能自己测的：我这周花在审查和返工上的时间是多少小时。

这个数在涨，说明省下来的时间又被交回去了；这个数持平或下降，才是真的快了。

留个问题：你团队上个月的 PR 平均多少行？如果比半年前大了一倍，先修这个，再谈提效。