关于 AI 编码助手提升开发效率，2026 年流传着两个截然不同的数字：GitHub 的任务研究说开发者完成同一任务快了 55%；而 METR 在 2025 年做的随机对照试验发现，16 名资深开发者在 246 个任务上的完成时间反而增加了 19%。
两个数字都是真实的，都出自可信的英文原始研究，中间隔着不到一年。它们测量的不是同一件事——这就是全网争论不休的原因。
更有意思的是第三组数据：DORA 2025 报告显示 90% 的技术从业者已在使用 AI 工具，80% 以上的人认为自己被提效了，但同时有 30% 的人对 AI 生成的代码几乎不信任。80% 自我感觉提效，和 30% 几乎不信任，这两个数字同时成立，本身就是一个值得研究的信号。
这篇文章要把所有方法论差异摊开，然后告诉你哪些数字可以用来做决策。
一、三组核心数据的正面交锋
| 研究 | 方法 | 样本 | 结果 |
|---|---|---|---|
| METR 2025 | 随机对照试验（RCT），严格随机分配任务 | 16 名资深开发者，246 个任务 | 完成时间增加 19%（变慢） |
| GitHub 任务研究 | 受控任务计时 | GitHub 平台任务 | 快 55% |
| DORA 2025 | 大规模从业者调查（自陈） | 技术从业者 | 90% 在用，80%+ 自认提效，30% 对 AI 代码几乎无信任 |
METR 的 −19% 和 GitHub 的 +55% 之间，差了 74 个百分点。这不是"谁在撒谎"，是方法论差异导致的必然结果。METR 用的是随机对照试验——把任务随机分配给"允许用 AI"和"不允许用 AI"两组，然后计时；GitHub 的任务研究是让开发者在特定任务上对比。RCT 是因果推断的黄金标准，它排除了自选择偏差。而调查必然带着自陈偏差：觉得自己快了的人会说自己快了。
二、METR 那份 −19% 为什么可信度最高
METR 那份研究值得展开讲，因为它是目前唯一一份方法论上无懈可击的 AI 编程效率研究。
| 设计要素 | METR 的做法 | 为什么这提高了可信度 |
|---|---|---|
| 分配方式 | 随机分配任务到 AI 组与非 AI 组 | 消除了"愿意用 AI 的人本来就更快"这个混淆变量 |
| 开发者 | 16 名资深开发者 | 样本小，但每一人都熟悉自己的代码库——这恰恰是最不利的条件 |
| 任务 | 246 个真实任务 | 不是玩具题，是仓库里的真实 issue |
| 测量 | 完成时间，客观可测 | 不依赖自陈，不依赖观感 |
结果是 19% 的时间增加。METR 随后对成因做了分析，指向三个机制：
- 代码库越大越慢。AI 在陌生的大型代码库里容易生成表面合理、但需要开发者反复纠正的代码
- 提示与审查消耗的时间超过省下的编写时间，尤其是资深开发者——他们本来写得就快，边际收益最低
- 接受率是调节变量。Copilot 的接受率长期在 27%–30% 区间，剩下 70% 以上的建议被丢弃，但丢弃本身也要花时间
三、GitHub 那边的 +55% 和 +40% 又是什么
GitHub 作为工具厂商，发布的数据有明显的立场，但它也有可核查的部分。
| GitHub 数据 | 数值 | 口径 |
|---|---|---|
| 单任务时间对比 | 快 55% | 特定受控任务，通常是较封闭的编写任务 |
| 自动补全（编辑器内） | 编码活动 +40% | 10 万+ 开发者研究，衡量的是活动量不是交付量 |
| 累计效应 | +140% | 同上研究的累计口径 |
| 叠加异步 Agent 后 | +180% | 同上，引入 Agent 后的累计口径 |
| PR 合并周期（纵向研究） | 9.6 天 → 2.4 天 | 纵向观察，衡量的是 PR 生命周期 |
+40%、+140%、+180% 这三个数必须放在一起看，因为它们是嵌套的：+40% 是编辑器内自动补全带来的编码活动增量，累计到工具链上是 +140%，再叠加上异步 Agent 才是 +180%。把它们当成三个独立的效果相加，是最常见的误读。而 +40% 到 +180% 全部衡量的是"编码活动量"，不是"交付量"——活动涨了三倍不等于交付涨了三倍。
PR 周期 9.6 天 → 2.4 天这条纵向数据是所有 GitHub 数据里最接近交付的指标，但也有陷阱：PR 周期缩短可能来自"拆得更细"，而不是"做得更快"。拆小 PR 是另一个层面的变化，用它证明效率提升时必须标注这一点。
另外一组可核查的厂商侧数据：Microsoft 与 Accenture 的联合研究显示，AI 编程工具平均带来 26% 的生产力提升。26% 这个数字比 55% 保守得多，但它是大样本、由非工具厂商主导的联合研究，在方案里的可信度反而更高。
四、DORA 2025 的三组数字为什么能同时成立
DORA 报告是 DevOps 领域最权威的年度调查，2025 年的版本提出了一个概念：验证税（verification tax）。
| DORA 2025 数字 | 含义 | 与另外两个数字的关系 |
|---|---|---|
| 90% 技术从业者使用 AI 工具 | 采用率接近饱和 | 解释了为什么"效率数据"到处都是——基数太大了 |
| 80%+ 自认为被提效 | 主观感受 | 与 30% 几乎无信任并存——说明"用它写"和"信它写的"是两件事 |
| 30% 对 AI 代码几乎不信任 | 信任缺口 | 这就是验证税：写代码省了时间，验代码花了时间 |
验证税这个概念是这三组数据唯一自洽的解释。用 AI 写代码确实更快了，但你必须验证它写的代码。写的时间省下来了，验的时间花出去了。净效果取决于「省下的时间」和「花掉的验证时间」孰大孰小——而这个比例对不同人、不同任务、不同代码库完全不同。
这正好解释了 METR 与 GitHub 的分歧：METR 的参与者是资深开发者，在自己熟悉的大型代码库里做真实 issue，验证税最高；GitHub 的任务研究是较封闭的编写任务，验证税最低。同一个工具，净效应可以从 +55% 摆到 −19%。
五、另一条更冷的数据：应用商店
GitHub 自己的纵向数据里藏着一组非常值得注意的对照：自 2025 年初以来，应用商店上的新应用数量明显增加，但下载量和评论数并未同步增长。
这条数据的说服力在于它不受任何自陈偏差影响——应用商店的数字是硬数据。它的含义很直接：
- 产出侧确实增加了（更多 AI 辅助的应用被做出来并上架）
- 但这些新增应用的被消费意愿没有增加——既没有更多下载，也没有更多评价
这是全篇最值得警惕的一条数据。如果 AI 真的在交付端持续提效，最直接的可观察后果应该是「更多被使用的软件」。而实际观察到的是「更多存在但不被使用的软件」。产出增加而消费未增加，说明瓶颈已经从生产端转移到了需求端——这是所有"效率提升"数据都没有覆盖的维度。
一个旁证：2026 年 Google 关停了浏览器智能体实验项目 Project Mariner，能力并入更大产品体系；同月还关停了 AI 评测平台 Yupp.ai（融资 3300 万美元、用户超百万）。用户百万级的产品被关停，说明"能做出来"和"能被持续用下去"之间的差距，比想象中大得多。
六、怎么用这份信息：五条实践建议
第一，引用效率数据时必须带上方法论标签。RCT（METR −19%）、受控任务（GitHub +55%）、自陈调查（DORA 80%）、活动量指标（+40%/+140%/+180%）——这四类数字放在同一份报告里而不加标注，是效率数据领域最普遍的问题。写方案时至少要写清是哪一类，这一处能挡住大部分质疑。
第二，用 METR 的样本条件去检验工具是否适合你。它的 −19% 是在「资深开发者 + 熟悉的大型代码库 + 真实 issue」这个条件下得到的。如果你的团队符合这三条，预期收益可能是负的；如果你是新人做绿地项目，预期收益会明显更高。这两个场景的结论完全相反，用一个数字覆盖两者是错的。
第三，把验证税当成一项显性成本纳入排期。AI 写的代码要过 code review、要跑测试、要理解它到底做了什么。建议在团队里设一条硬规则：AI 生成的代码 review 强度不低于人工代码——这句话在 DORA 2025 的语境下不是保守，是必要。
第四，把成本预算按每人每月 150–250 美元来做。Claude Code 在企业部署中的平均成本就是这个量级，约合每个活跃日 13 美元。对比开发者年薪 15–30 万元，这个支出的绝对值很小；但如果它只带来 10% 的效率提升，ROI 仍然是数量级的正回报——前提是你按正确的指标验收了效果。
第五，评估工具时优先看 PR 周期和返工率，不要看编码活动量。GitHub 的 +40%/+140%/+180% 全部是活动量，PR 周期 9.6 天 → 2.4 天是交付指标，而返工率（AI 生成的代码有多少需要推倒重来）是直接抵消收益的指标。第三个才是那个能让你看清真相的数——如果返工率超过 30%，前面所有的提效数字都不成立。
七、结语
把所有数据放在一起，AI 编码助手在 2026 年的真实状态是这样的：
采用已经饱和（90%），主观感受是正面的（80%+），但在方法论最严格的研究里，资深开发者在真实任务上变慢了 19%。这三句话同时为真，因为它们测的是三件不同的事。
真正的产出侧证据目前只有一条：应用商店上新数量增加，但下载和评论没增加。这意味着生产效率的提升还没有兑现成被使用的软件。
所以对要不要买、要不要推这件事，答案取决于一个具体问题：你的代码库是陌生的大型遗留系统，还是自己熟悉的小型项目。前者按 METR 的 −19% 做心理准备并把验证成本算进去，后者按 GitHub 的 +55% 乐观估算并盯紧返工率。把这两个数字混成一个"AI 提效 30%"的通用结论，是所有关于 AI 编程效率的讨论最终失效的地方。
