译者按: 本文是 Joel Becker, Nate Rush, Beth Barnes, David Rein (METR) 于 2025-07-10 发表的《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer》的中文校对翻译。原文出处: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/。读原文时深受启发, 特将全文译出与中文读者分享, 感谢原作者的点醒与提携。译文仅供学习交流, 版权归原作者所有, 如有出入以原文为准。
[!note] 版权说明 本文为编译精写版: 按原文结构与要点用中文重新表述, 并非逐句翻译, 直接引句仅保留极少量短句。原研究报告与完整论文见 source_url。
核心结论
METR (Model Evaluation & Threat Research) 做了一个随机对照实验 (RCT), 结果出乎所有人意料: 当资深开源开发者被允许使用 AI 编程工具时, 他们完成任务的时间反而多了 19%。
更扎心的是感知与现实的落差。实验前, 开发者预期 AI 能让自己快 24%; 实验结束后, 即便实际数据显示他们变慢了, 他们仍然相信 AI 让自己快了 20%。经济学专家和机器学习专家的事前预测也全都押错了方向, 都以为会提速。
实验设计
这项研究的分量在于方法, 用的是药物临床试验级别的随机对照:
- 招募 16 名资深开源开发者, 他们长期维护的仓库平均超过 22,000 star、100 万行代码, 对代码库极为熟悉
- 收集 246 个真实任务 (bug 修复、新功能、重构), 平均每个约两小时工作量
- 每个任务随机分配"允许用 AI"或"禁止用 AI"两种条件
- 允许组主要使用 Cursor Pro 搭配 Claude 3.5/3.7 Sonnet
- 开发者按 150 美元/小时获得报酬, 全程屏幕录制, 并自报完成时间
为什么会变慢
研究者从 20 个候选因素中筛出了几个最可能的贡献因素:
- 花在辅助环节的时间变多: 写提示词、等待 AI 生成、审查输出
- 上下文切换的开销: 在"自己写"和"看 AI 写"之间来回跳
- 调试 AI 生成代码的成本: AI 的产出在这些高标准、高上下文要求的仓库里经常不达标, 开发者要花大量时间修改或干脆重写
- 对超大代码库的隐性知识, AI 拿不到, 而这恰恰是这批开发者的核心优势
一个关键细节: 这批开发者对自己的代码库太熟了。他们本人就是"基准线", AI 很难在他们最熟悉的地盘上帮到他们。
研究者自己划的边界
METR 在原文里花了很大篇幅强调这项研究不能说明什么:
- 不能推广为"AI 对多数开发者都无效", 样本是特定人群 (顶级仓库的资深维护者) 加特定场景
- 不能说明 AI 在软件开发之外的领域无效
- 不能说明未来的 AI 在同样场景下还会这么慢
- 不能排除存在更好的用法, 比如针对仓库做微调、优化提示词工程、更长时间的工具适应期
三种解释框架
面对"基准测试和轶事都说 AI 很强, RCT 却测出变慢"的矛盾, 原文给出三种可能:
- RCT 低估了 AI 能力 (方法本身有未知问题)
- 基准测试和轶事高估了 AI 能力 (那些测量方式有水分)
- 两边测的本来就是不同的任务子集, 互为补充而非互相矛盾
作者的态度很克制: “没有任何测量方法是完美的”, 他们把这个结果视为"2025 年初 AI 能力在一个相关场景下的快照", 并计划持续用同样方法追踪。
后续
METR 于 2026 年 2 月发布更新, 公布了 late-2025 AI 工具的新数据并调整了实验设计, 说明这个结果确实只是一个时间切片 (详见 7-补充视角)。
原文出处: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer 原作者: Joel Becker, Nate Rush, Beth Barnes, David Rein (METR) 原文发表: 2025-07-10
本文收录于「X深度阅读」栏目: 精选全球 X/Twitter 与博客上最值得精读的 AI 长文, 逐篇校对翻译成中文。