AI 工具让资深开发者效率降低了19%，而不是提升。
刚刚，METR发布了一份关于AI 编程的研究报告，像一记重拳打在了整个AI编程工具行业的脸上。
这不是什么小打小闹的实验室测试，而是16位资深开源开发者在他们自己维护的项目上进行的246个真实任务测试。
这些项目平均拥有22,000+星标和超过100万行代码。
最讽刺的是什么？
开发者们在测试前预期AI能让他们快24%，测试后仍然觉得自己快了20%。
但秒表不会说谎：
他们实际上慢了19%。
上图完美展示了「期望」与「现实」的残酷对比。
左边是各方的预测：经济学专家认为AI能提速40%，机器学习专家猜35%，开发者自己估计25-30%。右边那个刺眼的红点，是实测结果：慢了约20%。
测试是怎么进行的
METR的实验设计可算是十分严谨。
他们找来的不是新手，而是在各自项目上平均贡献了5年时间和1500次提交的核心维护者。
每个开发者提供他们日常工作中的真实任务：bug修复、新功能开发、代码重构。
这些任务被随机分配到「允许使用AI」或「禁止使用AI」两组。允许使用AI时，开发者主要选择Cursor Pro配合Claude 3.5/3.7 Sonnet（当时的前沿模型）。
平均每个任务耗时2小时，开发者需要录屏并报告完成时间。
为了确保参与积极性，每小时报酬高达150美元。
AI 到底慢在哪里
研究团队深入分析了开发者的工作模式，发现了一个有趣的现象：
使用AI时，开发者编码和搜索信息的时间确实减少了。
但这些节省的时间都去哪了？研究显示：
编写提示词：反复调整prompt，试图让AI理解需求 等待AI响应：生成代码需要时间 审查AI输出：仔细检查生成的代码 空闲时间：可能是在思考如何更好地使用AI
更要命的是，只有44%的AI生成代码被保留，其余的要么被完全丢弃，要么需要大幅重写。
屏幕录像显示，约9%的活跃时间用于清理AI代码，4%纯粹在等待。
这种效率损失在不同的模型（Claude 3.5、3.7、GPT-4o）和不同时期的任务中都存在。
为什么会这样
研究团队调查了20个可能的因素，确定了5个主要原因：
深度仓库特性
每个维护者对项目的理解远超AI的上下文窗口。他们知道那些没写在文档里的潜规则、性能要求和兼容性习惯。
规模带来的混乱
平均110万行代码的项目，AI经常改错文件或忽略隐藏的依赖关系。
过度自信循环
因为AI工具「感觉」很有帮助，开发者持续使用它们，即使实际在拖慢进度。
提示词开销
与AI交互本身就是成本。当你花10分钟解释一个5分钟就能自己写完的功能时，效率从何谈起？
此外，研究还发出了8个混合/不明确的因素：
这意味着什么
METR团队很谨慎地指出了他们不想传达的信息：
这不代表AI对所有开发者都没用 这不意味着未来的模型不会更好 这不表示没有更有效的使用方法
但他们确实证明了一点：在某些重要场景下，当前的AI工具确实会降低生产力。
更重要的发现是：开发者的自我感知极不可靠。
如果连使用者自己都分不清是在提速还是减速，那些基于调查问卷的「AI提升效率」报告还有多少可信度？
网友热议
这份研究引发了开发者社区的激烈讨论。
Rohan Paul(@rohanpaul_ai)分享研究后表示：
这与我的经验完全不符
JustInEchoes(@JustInEchoes)也回应：
这完全不符合我的体验。这里肯定有什么问题。
λthugg-huh?(@jerzydejm) 则指出：
资深开发者在他们自己的代码库里，我觉得这是关键。大多数人无法开发出能够保持多年意义的大型代码库。
他还补充道：
大多数开发者都是空降到他们半懂不懂的代码丛林里的。
但Cornelis van der Bent(@meaning_matters)却有不同看法：
我的体验类似。我多次掉进AI陷阱，每个提示都让进展变得极其缓慢，浪费大量时间。
他还分享了同事Guillaume Binet的观点，称之为「AI黑天鹅」现象——看似有用的AI建议可能导致开发者陷入时间黑洞。
Vasile Mihali(@mihali_vasile)也有类似体验：
这也是我的感受。当我尝试使用Copilot、Claude或类似工具时，它们总是以各种方式产生幻觉，让我损失的时间比获得的更多。而直接查找官方文档和方法反而有效。
研究结果也引发了方法论上的争论。
Engineering Randomness(@EERandomness)认为研究问了错误的问题：
正确的问题应该是：「普通人（非程序员）使用AI写软件能快多少？」英语将成为编写软件的下一种语言。
但michael(@michael)立即反驳：
那实际上是完全不同的问题。
SaaS CTO, Ph.D.(@saasy_cto)进一步解释：
使用编程语言的意义在于强迫你明确地指定想要的确切行为。试图用英语做这件事效率更低，更容易出错。
Asdfastan Nanistar(@asdfastan)则称：
更好的问题是「一个配备AI工具的非程序员在超过100万行代码的项目中失败需要多快」。当涉及到比MVC稍微复杂一点的架构时，LLM相当糟糕。
对于样本量的质疑，Austin S. Lin(@austinslin)认为：
在这种情况下，16个样本毫无意义。
不过david rein(@idavidrein)立刻用数据回应了质疑，展示了每个开发者的详细统计和速度变化分布。
而Rezo(@rezo)则质疑到：
感觉我们错过了主要问题：我们在测量什么？「完成任务的时间」=生产力？如果AI为你节省了十小时的后续调试时间，RCT永远不会捕捉到这一点。
也有开发者对研究的局限性提出了不同意见。
Kyle Wild(@kylewild)建议：
现在试试：盲目进入这个React/Rails代码库，实现这10个客户功能。当Claude Code完成任务时，他们还在浏览文档和StackOverflow。
Yixiong Hao(@Yixiong_Hao)提出了一个有趣的测量建议：
另一个有趣的测量是这些开发者提示AI和检查/验证其代码需要多长时间，以及这是否会随着模型能力的提高而改变。我认为一旦上述图表与这条线相交，我们将在生产力上有一个跃升。
Logan(@loganmhb)指出了最关键的发现：
最值得注意的发现不是绝对的减速，而是事后速度提升估计与观察到的减速之间的差异——这不仅仅是AI工具在大型/复杂仓库上难以使用，而是即使在事后也很容易高估其好处。
那么，如何正确使用AI编程工具？
看完这份研究，我想：问题可能不在于AI本身，而在于我们还没学会在正确的场景使用正确的工具。
让我们从时间维度拆解一下使用AI编程的真实成本：
需求沟通时长
把需求讲清楚本身就是技术活。如果一个功能你需要花15分钟才能让AI理解，而自己写只要10分钟，那显然不该用AI。但如果是创建一个标准的登录页面，几句话就能说清，AI反而更高效。
AI执行时长
等待AI生成代码的时间不可忽视。GosuCoder(@gosucoder)提出了一个有趣的观点：
有经验的开发者不应该坐等AI完成，而应该同时处理其他任务，30分钟后再回来检查。
验证修改时长
研究显示56%的AI代码需要重写或丢弃。这意味着你不仅要review代码，还要修复它带来的问题。对于关键业务逻辑，这个成本可能高得吓人。
上下文切换成本
如果采用多任务并行来减少等待，频繁的上下文切换会带来额外的认知负担。正如Tharaxis(@tharaxis)指出的：
上下文切换会造成显著开销，导致对特定解决方案失去专注。它会直接导致代码质量下降。
长期维护成本
这是最容易被忽视的，AI生成的代码往往缺乏统一的风格和清晰的架构思路。
Vibe Coding 有多爽，Vibe debug 时就有多不爽。且随着项目增长，技术债会像滚雪球一样越来越大。
我总结了一些使用建议（并用AI 做了整理）：
适合使用AI的场景
Landing page、营销页面等一次性项目 原型开发和概念验证 标准化的CRUD操作 独立的工具函数和算法实现 需要大量样板代码的新项目初始化 不熟悉的技术栈的快速上手
不适合使用AI的场景
大型项目中只需修改几行代码的小改动 仅仅是文案或配置的调整 复杂业务逻辑，解释需求的时间超过实现时间 需要深度理解现有代码库架构的功能 对代码质量和可维护性要求极高的核心模块 团队有严格代码规范和特定模式的项目
使用技巧
用语音输入描述需求，AI理解自然语言的能力很强，不必字斟句酌 将大任务拆分成小的、独立的部分，减少AI的理解负担 保持合理预期，把AI当作初级助手而非高级工程师 建立自己的prompt模板库，针对不同场景优化 定期评估AI的实际效果，不要被主观感受蒙蔽
另外，还需要意识到的是，AI的价值不只在于加速我们已经会做的事，而在于让我们能做以前做不到的事。
如Mike Frager(@fragermk)所说：
我认为这需要时间来适应。AI正在实现以前根本不可能的开发任务。比如，让开发者在没有专家级知识的情况下应用高级加密技术。
就像开车一样，GPS的出现不是为了让老司机开得更快，而是让所有人都能到达陌生的目的地。
当我们停止追求「AI让我快了多少」，转而思考「AI让我能做什么新事情」时，也许才是真正理解这个工具的开始。
工具永远只是工具，关键在于使用它的人。
