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
本文来自微信公众号“大数据文摘”，36氪经授权发布。
本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。
免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com