刚刚，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提升效率」报告还有多少可信度？
