一项由美国METR研究所进行的严格实验研究，揭示了AI编程工具在实际应用中的真实效果。研究发现，经验丰富的开源开发者在使用AI编程工具时，平均任务完成时间反而增加了19%，远超他们预期的效率提升。开发者们普遍认为AI能提速，但实验数据表明，AI并没有真正提高核心产出效率，而是重新分配了注意力和劳动方式。开发者花费更多时间在提示设计、AI产出审查、等待响应以及理解生成内容上，工作流程变得碎片化，这导致了“快感错觉”，即感觉自己在忙碌但实际进展缓慢。研究还指出，现有的AI评估基准测试存在严重偏差，未能反映真实项目开发的复杂性。AI工具的真正价值可能在于改造工作流程而非直接提升效率。

📊 **AI工具的效率悖论**：一项严谨的随机对照实验发现，使用AI编程工具的开发者完成任务的时间平均增加了19%，这与开发者普遍认为AI能提升效率的预期（预测提速24%）形成鲜明对比。这表明AI并未如预期般在核心产出环节提升效率，反而可能导致“看似飞快，实则拖慢”的现象。

🔄 **工作流程与注意力的重塑**：AI编程工具的引入并非简单加速编码过程，而是改变了开发者的劳动方式和注意力分配。开发者将更多时间用于提示设计、审查AI生成的代码、等待响应以及理解AI输出，这种“与AI沟通如何写代码”的模式，虽然看起来充实，但实际产出效率并未提高，工作流程变得更加碎片化。

⚠️ **“快感错觉”与感知偏差**：研究指出，AI工具的使用可能源于一种“快感错觉”，即开发者在频繁切换任务和进行各种“小动作”时，主观上认为自己效率很高，但客观数据却显示进展有限。这种主观感受与客观现实的偏差，是衡量AI工具真实价值时需要重点关注的方面。

🏢 **成熟项目中的AI负担**：对于开源社区中常见的、结构复杂、规则隐含且质量要求高的成熟大型项目，AI工具反而可能成为一种负担。它需要开发者投入大量额外精力进行补充说明、频繁审查，甚至需要处理AI引发的语义误解，使得开发者从解决问题转向了“解释问题、矫正AI”。

📉 **现有评估体系的局限性**：研究对当前主流AI评估基准测试（如SWE-Bench, RE-Bench）提出了质疑，认为这些测试通常基于小型、孤立的任务，未能充分反映真实项目开发的复杂性、上下文关联和协作需求。这导致AI在理想化测试中的强大表现，可能与其实际应用效果存在较大差距。

2025-07-15 12:03 浙江

AI并没有真正提升核心产出环节的效率，只是重新分配了注意力和劳动方式。

大数据文摘出品

美国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

作者长期关注 AI 产业与学术，欢迎对这些方向感兴趣的朋友添加微信 Q1yezi，共同交流行业动态与技术趋势！