美国METR研究所完成了一项针对AI编程工具影响的实验研究。他们发现，经验丰富的开源开发者在使用AI编程工具时，完成任务的时间平均增长了19%。
图片
这与开发者自己的感知完全相反。毕竟，参与研究的开发者普遍都相信，AI将提升他们的效率。
在任务开始前，他们预测AI能让自己提速24%。可现实数据冷冷地指出：AI让他们“看似飞快，实则拖慢”。
图片
图注：当研究参与者可以使用像 Cursor Pro 这样的AI工具时，任务实际上耗时增加了19%。
研究团队通过随机对照实验（RCT），在真实环境中测试AI工具的使用效果。值得一提的是，这是目前公认的衡量因果关系最严格的方法。
实验如何进行？
图片
图注：实验设计。在分配条件前定义任务，通过屏幕录制验证执行情况，并利用专家与开发者的预测衡量预期与实际结果的差距。
实验共追踪了16名高级开发者，这些开发者在各自的开源项目中完成了246个实际任务，任务涵盖复杂模块的开发与修复，工作负载真实而具体。
每个任务被随机分配到两个组：一组使用AI工具，另一组不使用。
AI组开发者主要使用的是Cursor Pro，集成了Claude 3.5和Claude 3.7 Sonnet等主流大模型。
开发者在整个过程中录屏，并记录完成每个任务所花费的时间。为了剔除任务难度差异的干扰，研究人员采用了统计方法，引入开发者对任务时间的预估值作为参考。
换句话说，他们不仅测量“花了多长时间”，还测量“比预期多了多少”。
图片
最终结果显示：AI用户完成任务的平均用时比非AI用户长出19%。
讽刺的是，哪怕在任务完成后，那些用过AI的开发者仍然坚信，自己“节省了20%的时间”。
即便现实已经反转，他们依然觉得自己在加速。
研究者指出，这种“快感错觉”可能来自AI协助下的新型流程分布。研究结果表明，AI并没有真正提升核心产出环节的效率，只是重新分配了注意力和劳动方式。
具体来说，当AI工具被启用后，开发者在“主动编码”上的时间反而减少了。
他们花了更多时间在提示设计、AI产出审查、等待响应、闲置，以及理解生成内容上。
研究显示，开发者不是在写代码，而是在“与AI沟通如何写代码”。这种交互过程看起来很“充实”，但最终产出并不一定更快。
图片
图注：在使用AI的情况下，开发者减少了编码和查找信息的时间，更多时间用于与AI交互和等待
对新项目或快速原型开发，AI确实能提供帮助。但在面对成熟的大型项目，特别是开源社区中常见的、结构复杂、规则隐含、质量要求高的工程时，AI反而成为新的负担。
它需要大量的补充说明、更频繁的审查，甚至还会引发语义误解。
开发者不再是在解决问题，而是在解释问题、矫正AI、并试图相信AI有帮助。
此外，开发者的“心理节奏”也发生了变化。他们频繁切换任务：提示生成、回顾产出、人工修正、重复尝试，这种流程非常碎片化。
当一个人忙于各种小动作时，他自然会觉得自己很“快”。但数据不会说谎：他只是“动了很多”，并没有“前进很远”。
还有哪些发现？
METR的研究不仅揭示了AI工具在实际工作中的真实效率，还对目前主流AI评估体系提出了质疑。
他们指出，当前业界广泛采用的基准测试，如SWE-Bench和RE-Bench，存在严重偏差。这些测试通常是人工设置的小型题目，情境孤立，完全不反映真实项目的复杂性。
开发者在其中只需解决一小段代码问题，不用考虑上下文、不用和团队协作，也没有历史遗留负担。
这种测试环境高度理想化，与开源项目、企业代码库、或大型框架开发的日常工作完全不同。
于是，我们就得到了一个错误的结论：AI表现得非常强大。
而METR的随机对照实验，则是在现实中运行、在项目中嵌入、在流程中测量。研究人员将AI直接部署到开发者的真实任务中，不干预流程，只记录结果。
这是对“AI助力”的最直接检验。
而且，这种实验还能揭示“感知偏差”：即人们在使用AI之后，对效果的主观判断如何偏离客观现实。这才是真正有价值的测试方法。
所以，如果AI让人“觉得自己更快”，却“实际上更慢”，那么其价值评估将被全面高估。
企业、教育机构、平台服务商，乃至政策制定者，都可能被误导。
研究还暗示，AI工具的价值可能不是“提高效率”，而是“改造流程”。它改变了工作的节奏、重构了问题表达方式、干扰了注意力分配。
地址：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
