AI 让资深程序员慢了 19%，但他们自己觉得快了 20%——这个悖论每个人都该知道

💬 Aaron点评

这篇论文是Aaron 2025 年读到的最重要的 AI 研究之一。它做了一件极其罕见的事：用严谨的随机对照试验去检验一个所有人都当真理的假设——AI 让程序员更快。 结果不仅打了脸，还揭示了一个更深层的问题：我们对 AI 的感知和 AI 的实际效果之间，存在一条巨大的鸿沟。 ——Aaron

🎯 这份报告说了什么

METR 让 16 位在知名开源项目上平均贡献了 5 年的资深开发者完成 246 个真实任务，每个任务随机分配为「可以用 AI」和「不能用 AI」，然后严格测量完成时间。

核心信息：在资深开发者 + 大型成熟代码库这个特定但重要的场景下，AI 不仅没帮上忙，还因为感知偏差导致了系统性的过度使用。

💡 为什么这很重要：这是第一项同时满足「前沿模型 + 真实任务 + 资深开发者 + 固定结果指标」的随机对照试验。它揭示了一个可能影响整个行业的认知偏差——「感觉有用」和「实际有用」之间可能隔着一道深渊。

📌 一、为什么这项研究与众不同

Aaron读 AI 提效研究一直有一个困扰：绝大多数研究都在「理想环境」里测。让新手写个 HTTP 服务器，Copilot 当然帮得上。但这代表真实工作吗？

METR 是第一项同时满足四个条件的研究——前沿模型、真实任务、资深开发者、固定结果指标。 缺任何一个，结论就可能有偏差。

这就好比之前的实验让运动员跑平地，METR 第一次让他们跑真正的越野赛道。结果发现 GPS 导航在越野赛道上不仅没帮忙，反而让人绕了远路。

📌 二、19% 减速背后的五个真正原因

原因一：过度乐观，停不下来

开发者全程在认知泡沫里——觉得 AI 有用所以持续使用，即使它实际在拖后腿。省力和省时间是两回事。 AI 接管了部分脑力劳动让你感觉「轻松」，但审查、修改、等待的时间悄悄吃掉了你省下的编码时间。

原因二：你太熟了，AI 反而帮不了你

开发者平均在仓库上贡献了 5 年、1500 次提交。专家已经把最优路径内化了，他们的「肌肉记忆」比 AI 的搜索更快更准。 在最熟悉的任务上，减速反而更严重。

原因三：代码库太大太复杂

这些仓库平均 10 年历史、110 万行代码。AI 的上下文窗口装不下整个代码库，对项目架构的理解是碎片化的。一位开发者说：「它在代码的其他部分做了一些奇怪的修改，让我花时间去查找和删除。」

原因四：可靠性太低，审查成本太高

光是「和 AI 打交道」就占了 13% 的时间，这些在不用 AI 时根本不存在。

原因五：AI 不懂你的潜规则

软件开发中有大量隐性知识——哪些边界情况要处理、哪段老代码不能动。AI 像一个「总是表现得很自信的新人」，不会说「我不确定」，直接给你一个看起来合理但违反项目潜规则的实现。

📌 三、时间都去哪了——屏幕录像揭示的真相

研究团队手动标注了 143 小时屏幕录像，这是最有操作价值的部分。

AI 确实减少了编码和搜索的时间，但新增了三种不存在于传统工作流的活动——提示、等待、审查。三者的总和超过了 AI 节省的时间。

Aaron把这叫做「AI 协作税」。每次把任务交给 AI 都要交三种税：提示税（翻译需求）、等待税（等生成）、审查税（逐行检查）。在简单任务上这些税值得交，但在资深开发者的日常维护任务上，手写 10 分钟的事交完税反而花了 15 分钟。

更隐蔽的是，这三种税是分散支付的。你只记得 AI 秒出了一段代码的「哇」瞬间，不会记得自己花了 3 分钟写提示、等了 1 分钟、又花了 5 分钟修改。人类记忆对戏剧性时刻敏感，对分散的琐碎消耗不敏感——这正是感知偏差的认知根源。

📌 四、如果真没用，为什么 69% 的人不放弃？

实验结束后，69% 的开发者继续使用 Cursor。三种可能的解释：

以速度换轻松

AI 没让你更快，但让你更舒服。对按小时付费的开发者来说，用更少脑力完成相同工作——即使慢一点——可能是划算的。

认知失调

当你已经投入时间学习工具、建立了「AI 有用」的信念，承认「它让我变慢了」需要推翻自己。大多数人不会这么做。

AI 确实在某些任务上有用

在开发者预测高提速的任务上，AI 确实没拖后腿。问题出在那些以为有用但其实没用的任务上——而他们分不出来。

Aaron的判断：AI 的问题不是「有没有用」，而是「你知不知道什么时候该用」。 资深开发者判断任务难度很准，但判断「AI 能否帮上忙」时完全失灵。这是一种新型元认知盲区。

📌 五、这不意味着 AI 没用——但叙事需要修正

报告作者专门列了防误读指南：

AI 编程辅助的「有效区间」假说

💎 精华提炼

第一，「感觉有用」和「实际有用」之间可能隔着一道深渊。 这适用于所有 AI 工具。你觉得 ChatGPT 帮你写邮件更快了，你测过吗？人类对 AI 效果的感知可能系统性偏高——因为 AI 减少的是认知负荷（让你感觉轻松），但不一定减少总时间。

第二，AI 在你不熟悉的领域帮助最大，在你最擅长的领域帮助最少甚至有害。 十年经验的 Python 工程师让 AI 帮他写维护了五年的代码，和让 AI 帮他写不熟悉的前端代码——是完全不同的两件事。

第三，我们需要从「AI 有没有用」升级到「在什么条件下有用」。 Aaron自己在用 Claude Code 时也有类似感受：搭建新项目、写不熟悉的语言时 AI 是加速器，但修改维护两年的核心逻辑时，向 AI 解释上下文的时间比自己直接写还多。这份报告第一次用数据证明了这个直觉。

如果你是每天用 Cursor 的资深开发者，不需要恐慌。你需要做的不是放弃 AI，而是开始有意识地追踪——哪些任务用 AI 确实快了，哪些只是觉得快了。真正的高手不是盲目信任工具的人，是知道什么时候该放下工具的人。

🌟 对 AI 学习者的启示

这一段是Aaron读完整份报告后，专门写给正在学 AI、用 AI 的你。

认知刷新：你可能以为 AI 编程工具一定让你更快，但 METR 用随机对照实验证明：资深开发者用 AI 后平均慢了 19%，而他们自己觉得快了 20%。「感觉有用」和「实际有用」之间可能隔着一道深渊。

实操建议：从今天开始有意识地追踪——哪些任务用 AI 确实快了，哪些只是觉得快了。一个简单方法：偶尔故意不用 AI 完成一个任务，跟上次用 AI 的时间做对比。真正的高手是知道什么时候该放下工具的人。

趋势判断：Aaron认为 AI 编程工具在 6-12 个月内会经历一次大分化——对新手和不熟悉代码库的人提效显著，对资深维护者可能仍然拖后腿。工具厂商会开始根据「用户经验」和「代码库熟悉度」做智能路由，而不是一刀切的全场景覆盖。

📋 文档信息

资源

📎 20250710-METR-AI-Developer-Productivity-翻译版.md

📎 20250710-METR-AI-Developer-Productivity-原版.md

📊 本页表格（7 张，从原数据库还原）

数据	Aaron解读	维度
AI 会快 24%	信念：AI 当然有用	开发者事前预测
AI 快了 20%	用完还是觉得有用！	开发者事后估计
慢 19%	所有人的预测方向都错了	实际测量结果
<44%	超过一半被拒绝	Cursor 生成接受率
100%	没有一个人能直接用	需修改 AI 代码的开发者
经历了减速	不是个别现象	75% 的开发者

研究	结果	资深开发者？	真实任务？	前沿模型？
Peng 等	快 56%	否	否	否
Weber 等	快 65%	否	否	否
METR	慢 19%	是	是	是

指标	数据
AI 生成接受率	<44%
逐行阅读 AI 代码	75% 的开发者
审查/清理占总时间	~9%
等待 AI 生成	~4%

活动	变化	允许 AI	禁止 AI
主动编码	AI 替代了一部分	较少	较多
提示 AI	新增活动	有	无
等待 AI	新增活动	~4%	无
审查 AI	新增活动	~9%	无

报告没有证明	正确的理解
AI 对大多数程序员没用	只研究了资深开发者 + 大型仓库
未来 AI 不会更快	模型进步以月计，几个月就可能翻盘
没有更好的使用方式	更好的提示、更多 token 可能改变结果

AI 可能拖后腿	条件	AI 可能提速
核心维护者	开发者经验	对目标代码库不熟悉
百万行成熟项目	项目规模	小型项目
深度维护、复杂重构	任务类型	探索性、原型搭建
高（大量潜规则）	隐性知识量	低（文档完善）

内容	项目
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity	报告名称
METR（Model Evaluation & Threat Research）	发布机构
Joel Becker, Nate Rush, Beth Barnes, David Rein	作者
2025 年 7 月	发布日期
16 位资深开源开发者，跨 15 个仓库的 246 个任务，143 小时标注屏幕录像	数据来源
Aaron	教程撰写
教程版（Aaron视角深度解读）	文档类型