直接答案： AI 编程工具的采用率已接近普及，但关于生产力的严谨证据结论不一。METR 在 2025 年进行的一项随机对照试验发现，经验丰富的开源开发者在使用 AI 时反而慢了约 19%——而他们自己却相信变快了。Stack Overflow 的 2025 年调查显示，大多数开发者已在使用 AI，却不信任它的准确性；Google 的 DORA 2024 研究则发现，更高的 AI 采用率与交付吞吐量和交付稳定性的小幅下滑相关。结论不是 AI 没用，而是：与其相信一条标题或一则轶事，不如在你自己的环境中测量实际被验收的产出。
「AI 让开发者更快」已经成为工具营销和董事会幻灯片里的默认假设。而最有分量的近期证据比这谨慎得多。三个相互独立、可信度高的来源——一项随机试验、一份大规模开发者调查、一个多年期 DevOps 研究项目——各自从不同角度给这一主张加上了限定。
它们没有一个说 AI 编程工具毫无价值。合在一起，它们说出了那句诚实的话：生产力效应的大小、甚至方向，取决于测的是谁、测的是什么、怎么测。
采用率很高，信心却不高
Stack Overflow 的 2025 年开发者调查报告称，大约 84% 的开发者正在使用或计划使用 AI 工具，高于前一年的 76%。用不用，已经不是有意思的问题了。
信不信才是。在同一份调查中，46% 的开发者表示不信任 AI 工具的准确性，只有 33% 表示信任，而报告「高度」信任其输出的仅约 3%。普遍采用与对正确性的普遍怀疑并存——这种格局本身就足以让任何单一的生产力数字变得可疑。
一项随机试验测出了出人意料的减速
多数生产力主张依赖自我报告或基准测试。非营利研究机构 METR 做了一件更少见的事：一项随机对照试验。
METR 招募了 16 名经验丰富的开源开发者，他们在自己长期维护的代码仓库（平均 22k+ star、超过一百万行代码）上工作，并从日常工作中提供了 246 个真实 issue。每个 issue 被随机分配为允许或禁止使用 AI。允许使用时，开发者用的是当时的前沿工具——主要是搭配 Claude 3.5/3.7 Sonnet 的 Cursor Pro。
结果与预期相反：允许使用 AI 时，开发者完成 issue 的时间多了约 19%。更引人注目的是感知落差：开发者事先预测 AI 能带来 24% 的提速，而即使做完任务之后，他们仍然相信 AI 让自己快了约 20%。
METR 罕见地明确列出了这项研究不能证明的事情，值得复述：
- 它没有证明 AI 无法让大多数开发者提速；这项研究只覆盖一个特定人群；
- 它只研究软件开发，且限于质量门槛很高的成熟代码仓库；
- 它无法排除超出几十小时工具使用之后的学习曲线效应；
- METR 后来发布了 2026 年的后续研究，并将 2025 年初的数字标记为已过时。
请把这个 19% 当作一个针对高要求场景的严谨数据点——而不是一份普适裁决。
个体速度与系统交付是两回事
即使个体感觉更快，交付系统也可能朝反方向移动。Google 的 DORA 2024 报告发现，AI 的采用提升了个体生产力、心流和工作满意度——但估计 AI 采用率每提高 25%，交付吞吐量约下降 1.5%，交付稳定性约下降 7.2%。
这种组合——更满意、自感更快的个体，加上略微变差的交付稳定性——恰恰是任何单一自报指标都会漏掉的那类效应。
| 证据来源 | 测量对象 | 核心发现 | 单独不能证明 |
|---|---|---|---|
| METR 随机对照试验（2025） | 资深开发者处理真实 issue 的任务耗时 | 使用 AI 慢约 19%，尽管本人相信提速了 | AI 会拖慢所有开发者或所有场景 |
| Stack Overflow 2025 | 自报的采用率与信任度 | 约 84% 使用 AI；46% 不信任其准确性 | 对产出质量或速度的实际影响 |
| DORA 2024 | 团队交付吞吐量与稳定性 | 更高的 AI 采用率与小幅下滑相关 | 适用于每个团队的普适因果规律 |
感知与现实为何背离
有几种机制可以解释一个工具为何用起来感觉更快、测起来却更慢：
- 自我报告偏差。 花在审查和修正输出上的工夫很容易被遗忘，而生成的那一刻感觉极有产出。
- 基准测试不等于你的代码仓库。 在范围明确、自动打分的任务上得高分，并不能迁移到必须通过代码风格、测试和文档评审的代码上。
- 验证开销。 阅读、测试、修补生成的代码，代价可能超过它省下的时间——尤其是在开发者本就烂熟于心的代码里。
- 上下文切换。 写提示词、等待、评估建议，会打断资深开发者赖以工作的心流。
该测什么
务实的应对既不是禁用 AI，也不是盲目采用，而是去测量真正重要的结果：你自己环境中经过评审、实际被验收的变更，以及它们的真实成本。
要做一次公平的评估，请固定代码仓库基线和验收标准，并记录：
- 验收产出与尝试次数之比，以及事后的返工或代码翻修；
- 每个验收变更消耗的评审者实际分钟数；
- 随时间变化的交付吞吐量与稳定性，而不只是任务级速度；
- 每个验收变更的总成本，包括模型、算力和评审。
这正是本站试点研究方法论背后的纪律，也是 AI 编程试点评分卡中可靠性与安全性硬性门槛的由来。这也是为什么一个能记录任务、环境和评审证据的托管平台——即 MonkeyCode 所描述的模式——比各自为战的笔记本用法更便于测量。
结论
AI 编程工具已被广泛采用，在许多场景下也确实有用。但目前最好的证据——一项随机对照试验、一份大规模调查、一个多年期 DevOps 研究——都在警告：不要把「AI 让我们更快」当成既定事实。采用率高、信任度低、个体感知不可靠，而且即便个体自感更快，团队交付也可能倒退。
在把一个论断放大成一笔预算之前，先在你自己的代码仓库里、用你自己的评审者，把这项测量做一遍。
来源边界： 19% 的减速、事前预测与事后认知等数字，均为 METR 报告的、针对 2025 年初工具在资深开源开发者中的研究发现；METR 已将其标记为历史数据，并发布了 2026 年的更新。采用率与信任度百分比来自 Stack Overflow 2025 年开发者调查。吞吐量与稳定性的估计值来自 Google 的 DORA 2024 报告。所有来源核验于 2026 年 7 月 20 日，描述的是特定人群与特定方法，而非普适规律。