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理解需求
更要命的是，只有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提升效率」报告还有多少可信度？
网友热议
这份研究引发了开发者社区的激烈讨论。
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的场景
不适合使用AI的场景
使用技巧
- 用语音输入描述需求，AI理解自然语言的能力很强，不必字斟句酌
- 将大任务拆分成小的、独立的部分，减少AI的理解负担
另外，还需要意识到的是，AI的价值不只在于加速我们已经会做的事，而在于让我们能做以前做不到的事。
如Mike Frager(@fragermk)所说：
我认为这需要时间来适应。AI正在实现以前根本不可能的开发任务。比如，让开发者在没有专家级知识的情况下应用高级加密技术。
就像开车一样，GPS的出现不是为了让老司机开得更快，而是让所有人都能到达陌生的目的地。
当我们停止追求「AI让我快了多少」，转而思考「AI让我能做什么新事情」时，也许才是真正理解这个工具的开始。
工具永远只是工具，关键在于使用它的人。
粤ICP备14082021号
免费POC，
零成本试错
