研究显示：AI 并没有提升编程效率，它反而让你变慢了19%

先看关键结论：METR刚刚发布的一份AI编程研究报告，像一记重拳打在了整个AI编程工具行业的脸上。这不是什么小打小闹的实验室测试，而是

在他们自己维护的项目上进行的测试。这些项目平均拥有和。

最讽刺的是什么？开发者们在测试前预期AI能让他们快24%，测试后仍然觉得自己快了20%。但秒表不会说谎：

。

上图完美展示了「期望」与「现实」的残酷对比。左边是各方的预测：经济学专家认为AI能提速40%，机器学习专家猜35%，开发者自己估计25-30%。右边那个刺眼的红点，是实测结果：

。

测试是怎么进行的

METR的实验设计相当严谨。他们找来的不是新手，而是在各自项目上平均贡献了

和的核心维护者。

每个开发者提供他们日常工作中的真实任务：

。这些任务被随机分配到「允许使用AI」或「禁止使用AI」两组。允许使用AI时，开发者主要选择Cursor Pro配合Claude 3.5/3.7 Sonnet（当时的前沿模型）。

平均每个任务耗时2小时，开发者需要录屏并报告完成时间。为了确保参与积极性，

。

AI 到底慢在哪里

研究团队深入分析了开发者的工作模式，发现了一个有趣的现象：使用AI时，开发者

。

但这些节省的时间都去哪了？研究显示：

• 编写提示词
  ：反复调整prompt，试图让AI理解需求

• 等待AI响应
  ：生成代码需要时间

• 审查AI输出
  ：仔细检查生成的代码

• 空闲时间
  ：可能是在思考如何更好地使用AI

更要命的是，

，其余的要么被完全丢弃，要么需要大幅重写。屏幕录像显示，约9%的活跃时间用于清理AI代码，4%纯粹在等待。这种效率损失在不同的模型（Claude 3.5、3.7、GPT-4o）和不同时期的任务中都存在。

为什么会这样

研究团队调查了20个可能的因素，确定了5个主要原因：

：每个维护者对项目的理解远超AI的上下文窗口。他们知道那些没写在文档里的潜规则、性能要求和兼容性习惯。

：平均110万行代码的项目，AI经常改错文件或忽略隐藏的依赖关系。

：因为AI工具「感觉」很有帮助，开发者持续使用它们，即使实际在拖慢进度。

：与AI交互本身就是成本。当你花10分钟解释一个5分钟就能自己写完的功能时，效率从何谈起？

此外，研究还发现了8个混合/不明确的因素。

这意味着什么

METR团队很谨慎地指出了他们

传达的信息：这不代表AI对所有开发者都没用，不意味着未来的模型不会更好，也不表示没有更有效的使用方法。但他们确实证明了一点：。

更重要的发现是：

。如果连使用者自己都分不清是在提速还是减速，那些基于调查问卷的「AI提升效率」报告还有多少可信度？

网友热议

这份研究引发了开发者社区的激烈讨论。

Rohan Paul分享研究后表示：「这与我的经验完全不符。」JustInEchoes也回应：「这完全不符合我的体验。这里肯定有什么问题。」

λthugg-huh?则指出：「资深开发者在他们自己的代码库里，我觉得这是关键。大多数人无法开发出能够保持多年意义的大型代码库。」他还补充道：「大多数开发者都是空降到他们半懂半懂的代码丛林里的。」

但Cornelis van der Bent却有不同看法：「我的体验类似。我多次掉进AI陷阱，每个提示都让进展变得极其缓慢，浪费大量时间。」他还分享了同事Guillaume Binet的观点，称之为「

」现象——看似有用的AI建议可能导致开发者陷入时间黑洞。

Vasile Mihali也有类似体验：「这也是我的感受。当我尝试使用Copilot、Claude或类似工具时，它们总是以各种方式产生幻觉，让我损失的时间比获得的更多。而直接查找官方文档和方法反而有效。」

研究结果也引发了方法论上的争论。Engineering Randomness认为研究问了错误的问题：「正确的问题应该是：'普通人（非程序员）使用AI写软件能快多少？'英语将成为编写软件的下一种语言。」但michael立即反驳：「那实际上是完全不同的问题。」

SaaS CTO进一步解释：「使用编程语言的意义在于强迫你明确地指定想要的确切行为。试图用英语做这件事效率更低，更容易出错。」

Asdfastan Nanistar则称：「更好的问题是'一个配备AI工具的非程序员在超过100万行代码的项目中失败需要多快'。当涉及到比MVC稍微复杂一点的架构时，LLM相当糟糕。」

对于样本量的质疑，Austin S. Lin认为：「在这种情况下，16个样本毫无意义。」不过da vid rein立刻用数据回应了质疑，展示了每个开发者的详细统计和速度变化分布。

而Rezo则质疑：「感觉我们错过了主要问题：我们在测量什么？'完成任务的时间'=生产力？如果AI为你节省了十小时的后续调试时间，RCT永远不会捕捉到这一点。」

也有开发者对研究的局限性提出了不同意见。Kyle Wild建议：「现在试试：盲目进入这个React/Rails代码库，实现这10个客户功能。当Claude Code完成任务时，他们还在浏览文档和StackOverflow。」

Yixiong Hao提出了一个有趣的测量建议：「另一个有趣的测量是这些开发者提示AI和检查/验证其代码需要多长时间，以及这是否会随着模型能力的提高而改变。我认为一旦上述图表与这条线相交，我们将在生产力上有一个跃升。」

Logan指出了最关键的发现：「最值得注意的发现不是绝对的减速，而是事后速度提升估计与观察到的减速之间的差异——这不仅仅是AI工具在大型/复杂仓库上难以使用，而是即使在事后也很容易高估其好处。」

那么，如何正确使用AI编程工具？

看完这份研究，问题可能不在于AI本身，而在于

。

让我们从时间维度拆解一下使用AI编程的真实成本：

：把需求讲清楚本身就是技术活。如果一个功能你需要花15分钟才能让AI理解，而自己写只要10分钟，那显然不该用AI。但如果是创建一个标准的登录页面，几句话就能说清，AI反而更高效。

：等待AI生成代码的时间不可忽视。GosuCoder提出了一个有趣的观点：「有经验的开发者不应该坐等AI完成，而应该同时处理其他任务，30分钟后再回来检查。」

：研究显示56%的AI代码需要重写或丢弃。这意味着你不仅要review代码，还要修复它带来的问题。对于关键业务逻辑，这个成本可能高得吓人。

：如果采用多任务并行来减少等待，频繁的上下文切换会带来额外的认知负担。正如Tharaxis指出的：「上下文切换会造成显著开销，导致对特定解决方案失去专注。它会直接导致代码质量下降。」

：这是最容易被忽视的，AI生成的代码往往缺乏统一的风格和清晰的架构思路。Vibe Coding 有多爽，Vibe debug 时就有多不爽。且随着项目增长，技术债会像滚雪球一样越来越大。

总结了一些使用建议：

• Landing page、营销页面等一次性项目
• 原型开发和概念验证
• 标准化的CRUD操作
• 独立的工具函数和算法实现
• 需要大量样板代码的新项目初始化
• 不熟悉的技术栈的快速上手

• 大型项目中只需修改几行代码的小改动
• 仅仅是文案或配置的调整
• 复杂业务逻辑，解释需求的时间超过实现时间
• 需要深度理解现有代码库架构的功能
• 对代码质量和可维护性要求极高的核心模块
• 团队有严格代码规范和特定模式的项目

• 用语音输入描述需求，AI理解自然语言的能力很强，不必字斟句酌
• 将大任务拆分成小的、独立的部分，减少AI的理解负担
• 保持合理预期，把AI当作初级助手而非高级工程师
• 建立自己的prompt模板库，针对不同场景优化
• 定期评估AI的实际效果，不要被主观感受蒙蔽

另外，还需要意识到的是，

。如Mike Frager所说：「我认为这需要时间来适应。AI正在实现以前根本不可能的开发任务。比如，让开发者在没有专家级知识的情况下应用高级加密技术。」

就像开车一样，GPS的出现不是为了让老司机开得更快，而是让所有人都能到达陌生的目的地。当我们停止追求「AI让我快了多少」，转而思考「AI让我能做什么新事情」时，也许才是真正理解这个工具的开始。工具永远只是工具，关键在于使用它的人。