AI 编码让资深程序员“掉速”19%！OpenAI 前研究员实锤：别再交“AI 工具智商税”了，谷歌大佬力挺！

关于 AI 编程工具的讨论热度居高不下。据报道，初创企业已经在组织小型工程团队，非程序员们以“氛围编程”方式开发软件，新手程序员的就业市场也由此走向崩溃。

研究显示：AI 编码工具会让开发效率降低 19%

但最近，情况似乎有点不一样了。根据 METR 于 2025 年春季进行的一项实验，AI 工具带来的助益似乎与人们的感受大相径庭。

METR（Model Evaluation & Threat Research）是一家专注于人工智能模型评估与威胁研究的非营利性组织，成立于 2023 年，由 OpenAI 前对齐研究员 Beth Barnes 创立，致力于通过科学实验和数据分析，客观评估 AI 技术在实际应用中的表现和潜在影响。该组织以严谨的实证研究方法著称，尤其关注 AI 工具在真实工作场景中的生产力影响，而非仅依赖实验室环境下的基准测试。

METR 开展了一项严谨的研究，旨在衡量 AI 工具到底能为具备丰富从业经验的开发者们带来多大的生产力提升。结果令人惊讶：生产力反而下降了 19%。甚至连研究参与者们自己也感到惊讶：在体感上，他们认为 AI 让自己的生产力提高了 20%。因此单纯从这项研究中提取结论，那我们可以得出：AI 带来的所谓降本增效感受，很可能是种幻觉。

那么，具体而言，他们是如何进行这项研究的？

在 2025 年 2 月至 6 月间，METR 从大型开源项目库（平均超过 2.2 万颗星和超过 100 万行代码）招募了 16 位经验丰富的开发者，他们多年来一直为这些项目做出贡献。这 16 位开发者平均拥有 5 年编程经验，达到中等 AI 使用水平，在其成熟项目中完成了 246 项任务，包括错误修复、功能和重构，这些通常是他们日常工作的一部分。

这个研究旨在评估前沿 AI 工具对实际软件开发效率的影响。每项任务被随机分配为两个组：一组“允许使用 AI 工具”（主要依赖 Cursor Pro 代码编辑器和 Claude 3.5/3.7 Sonnet 模型），另一组“禁止使用 AI 工具”。

开发者开始工作，同时录制屏幕操作以供后续分析。完成每项任务后，他们会上报所花费的时间。对于允许使用 AI 的任务，他们还估算了 AI 工具为他们节约了多少时间，也就是期待的加速比。

任务开始前，开发者普遍预测 AI 工具可缩短 24%的任务时间，而实际使用后，其主观评估仍认为效率提升了 20%。然而，客观数据显示，允许使用 AI 的组别完成任务时间比对照组多出 19%，这一结果与经济学专家（预测效率提升 39%）及机器学习专家（预测提升 38%）的乐观预估形成鲜明对比。

研究团队通过分析 20 项潜在干扰因素（如项目规模、质量标准及开发者 AI 经验）验证结论的可靠性。尽管无法完全排除实验环境的影响，但效率下降现象在不同分析中均表现稳定，表明其并非由实验设计缺陷导致。

到这项研究就是完全无缺陷的吗？

这项研究设计中唯一不符合严谨科学标准之处，就是未采用双盲法：即在工作开始后，参与者和研究人员都知道是否允许使用 AI 工具。但这又是不可避免的，毕竟目前还没有合理方法能够提供“安慰剂”式的编程助手。为此，研究人员还专门收集了一系列解释性证据，尽可能支撑这次非双盲试验的可信度。因此就本次研究中开展的工作类型而言，允许开发者使用 AI 工具确实会降低他们的工作效率。

开发者辩论：AI 编码工具到底好不好用

这一研究结果披露后迅速在 Hacker News、Reddit、X 等平台上引发热议。

在 Reddit 上，有用户表示，终于有观点证实自己的判断是正确的——AI 编程工具的确会拉低开发效率。

“谢天谢地，原来不止我一个人这么觉得！这篇论文中的观点太有说服力了。这些 AI 工具在生成嵌入 SQL 查询的函数方面确实非常有用，光是这一点就让我受益匪浅。但除此之外，它们的其他建议几乎从来不符合我的需求。我曾经在不同的文件里写了 4～5 遍本质上相同的代码，直到第 4 个文件之后，Copilot 才真正开始复制我的风格。每次让它生成代码后，我都得花时间清理——重命名变量、添加文档注释、调整代码风格以符合我的标准……”

但也有 Reddit 用户认为，AI 编码工具能够帮助开发者提高工作效率。例如，一位 ID 名为 jeremya 的用户就使用 Claude Sonnet 4 完成了一些小项目的开发，并认为 Claude Sonnet 4 的成果远超她的预期——不仅功能完整，而且代码专业。

“目标要定得低一些，这样失败时就不会太失望。这条准则对大多数项目都很适用，但它也揭示了一个事实：项目越小，失败的可能性就越低。

 

在 AI 的帮助下，我成功完成了一些短小精悍的程序和功能有限的项目。最近的一个例子是一个处理 eBay 交易数据的应用——它能将数据录入数据库，并自动打印发票和地址标签。我用的 Claude Sonnet 4，配合 Vibe Coding。

 

我先给它提供了一些 eBay 报告样本，让它为 SQLite 生成数据库结构，并用 Python 写一个数据导入程序。它一次就搞定了。接着，我输入了发票打印机的说明书和杯子标签的规格，包括网址、标签尺寸等细节。基本上，这就是我需要的全部输入。AI 自动设计了发票的样式，还修正了地址标签的格式（在我提醒它去掉 eBay 的无用信息后）。结果又一次完美无缺。

 

后来，Claude Sonnet 4 甚至主动判断我需要一个数据处理流程，于是它生成了一个配置系统、三个独立的应用（分别负责数据采集和打印），以及一个协调流程来采集、归档和打印最近的交易记录。它还为所有子模块生成了使用说明文档。

 

整个过程中，它只犯了三个错误，而在我指出后，它立刻修正了。完成所有功能后，它甚至把整个项目打包成了一个结构清晰的 Git 仓库。最终，Claude Sonnet 4 的成果远超我的预期——不仅功能完整，而且代码专业。整个项目只花了大约两小时，包括调整发票格式和添加地址清洗功能。这效率，比我手动开发高太多了。”

在 X 上，也有开发者表示，AI 编码工具好不好用，在于你掌握的技能是否能支撑你更好地使用它。

“AI 工具不会神奇地加速你的开发，只有当你知道如何使用它们时，它们才能给你带来优势。良好的提示、调试输出并将其融入你的工作流程本身就是一门技能。所以，学习曲线确实存在。对于精通它的开发者来说，回报是巨大的。”

也有人呼吁，应该正确看待 AI 编码工作的价值，它们只是一套工具，任何编码工具都会有优缺点，不可过于依赖它们。一位长期使用 Cursor 的用户强调，在 AI 编码工具飞速崛起的时代，人来开发者的竞争优势不在于和 AI 较劲，而在于使用 AI 工具的人会比那些不愿学习如何用 AI 优化工作流程的人走得更快。

“AI 只是另一套工具而已。我一直在用 Cursor，它有优点也有缺点。

 

这些都是新兴工具，人们仍在探索它们的运作方式，以及开发者需要如何调整工作流程才能更好地利用它们。这需要时间沉淀。

 

对我来说，这有点像互联网泡沫初期的感觉——当时人人都能建个电商网站赚钱，但几年后那些粗制滥造的东西就被淘汰了。GitHub Copilot 现在也面临着更优秀产品的竞争（我在 Visual Studio 和 IntelliJ 中都用过 Copilot，体验都很糟糕，而且问题各不相同）。但使用 Cursor 一个月后，我已经能清晰判断哪些功能对我真正有用，并能预判什么时候会陷入无谓的折腾。

 

抱怨这些 AI 工具，就像当年有人抱怨代码自动补全功能，或者坚持用记事本写代码而拒绝 IDE 一样。没错，Visual Studio 确实臃肿，占用内存大，还带着无数我用不到的功能——但用它我就是比其他工具更高效。AI 编程也是同样的道理。我真正的竞争优势不在于和 AI 较劲，而在于比那些不愿学习如何用 AI 优化工作流程的人走得更快。”

谷歌技术大佬为研究结论站台

这个结果似乎“糟糕得难以置信”，也因此激起不少质疑之声。

业界也有一众技术大佬对该结果发表了观点，其中 Writely（又名 Google Docs）联合创始人 Steve Newman（史蒂夫·纽曼）甚至写了一篇长文表达对这个研究结论的支持。

Newman 认为这项研究的真实性是相当靠谱的。他表示：

“从细节来看，这项研究无疑经过了精心设计，其真实性也相当靠谱。当然，我们也不能因此否定关于生产力大幅提升的判断和感受。毕竟这项研究从未认定 AI 编程工具属于骗局，只是在提醒我们，这类工具仍存在严肃的局限性（至少目前如此）。”

Newman 详细分析了这项研究是怎么进行的，借此判断它的结论是否可信。

起初，Newman 也对实验结果持怀疑态度，毕竟 AI 编码工具太火了，几乎所有开发者都在使用各种各样的 AI 工具。

因此他最初阅读完论文后，认为实验可能存在混淆或无效的情况。但他反复琢磨了半天后，觉得是自己想象力不够丰富，因为论文作者们对可能造成结果偏差的可能性一一作了解释：

• 约翰·亨利效应：也许开发者存在“打败机器”的动机，在不允许使用 AI 的任务中加倍努力。但如果真是这样，那么这种效应应该在研究过程中逐渐减弱，因为兴奋感和新鲜感会逐渐消退——毕竟受试者们平均执行了 15 项任务、每项任务一般持续 1 到 2 小时。但试验中并未观察到这种逐渐消退的现象。

• 对 AI 使用不足：或许开发者即使在允许的情况下也没有使用 AI 工具。然而，这只能解释生产力提升不足，而无法解释为何生产力反而下降。试后访谈和截屏录像分析显示，参与者们确实大量使用了 AI 工具（在允许使用 AI 的任务录屏中，至少有 84%的比例涉及 AI 工具使用）。

• 作弊：或许开发者在禁止使用 AI 的任务中，还是偷偷使用了 AI 工具？但同样的，这最多只会让两种情形下的生产力水平相当，而非允许使用 AI 时更低。通过分析试后访谈和截屏录像，研究人员只发现了极少量的作弊行为。

• 估算时间过于乐观：开发者们最大的老毛病，就是总会把完成一项任务所需要的时间估算得过短。然而，由于开发者是在使用 AI 工具之前就完成了任务时间估算，所以哪怕有错误也不会影响最终结果。

• 任务定义不准确：如果开发者对于允许使用 AI 和不允许使用的定义存在理解差异，也可能会影响结果。然而这种可能性也被排除了，因为任务是由开发者自行指定，并将其拆分成能在两个小时内完成的任务块。之后，这些任务会被随机分配为允许使用 AI 和不允许使用两个类别之下。

• 辍学效应：假设某些不允许使用 AI 的任务，在缺少 AI 辅助时会变得极难完成，那就可能导致开发者在研究期间内压根没能做完。他们的结果没有被记录下来，自然就形成了怪异的结果。然而，开发者未能完成的任务只有 13 个，而实际完成的任务多达 246 个，且未完成的这些任务也同时涉及允许用 AI 和不允许用 AI 两个类别。

• 工具过时：AI 能力一直在快速发展，也许是工具过时影响了试验结果？但开发者主要使用的是 Cursor Pro 和 Claude 3.5/3.7 Sonnet，这已经是研究期间（2025 年 2 月至 6 月）最先进的编程工具了。

• 时间报告不准确：统计数据基于开发者上报他们完成每项任务的时间，包括 PR 审核前后。确实，但哪怕仅使用审核前的时间或截屏录像时长进行分析，得出的结论也不会改变。

以上提出的所有问题似乎都没有影响试验结果。下面，就要看看研究人员推测的可能导致生产力下降的因素。

• 过度使用 AI：论文提到，“开发者被要求以他们认为最高效的方式使用 AI”。但部分受试者似乎表现过度，而这可能是导致生产力下降的原因之一。在试后访谈中，受试者将自己的 AI 使用情况大致分为“正常使用 AI”（涉及 70 项任务）、“尝试使用 AI”（119 项任务）和“尽可能多地使用 AI”（57 项任务）。自称属于第一类的受试者受 AI 影响较小（但他们的速度也仍然没有更快）。

• 缺乏 AI 工具使用经验。如果开发者缺乏 AI 工具使用经验，可能会因使用不当而拉低效率。结果显示，93%的参与者之前已经使用过 ChatGPT 等工具，44%的参与者曾经使用过 Cursor（目前最流行的 AI 编程专用工具）。由此看来参与者们对 AI 编程工具的掌握确实参差不齐，随着开发者们积累下更多 AI 工具使用经验，也许能够从中受益更多。然而，所有开发者在研究期间肯定会积累下一定的 AI 工具使用经验，但从研究开始到结束都未出现任何明显的效率改进（另外，所有参与者在研究开始时均接受了现场 Cursor 基础培训）。

• 还有一个潜在问题，即部分研究参与者在受试期间，从自己熟悉的开发环境转向通过 Cursor 来处理允许使用 AI 的任务。但“总体而言，开发者们表示，与自己的正常工作流程相比，这些差异并没有带来显著的不便或者效率影响”。

由此看来经验不足似乎并非主要问题，但相信更擅长运用 AI 工具的开发者也许能取得更好的结果。

范围蔓延差异：也许使用 AI 工具的开发者会不自觉扩大任务范围，例如编写代码来处理更多极端情况、添加额外功能，或者更全面地测试或记录代码。作为潜在证据，开发者在允许使用 AI 的任务中，相较不允许使用 AI 的任务多添加了 47%的代码行数（按预测任务规模计算）。然而研究者们认为，这类证据的说服力不强。在私下交流中，他们列举了站此立场的一些原因：

• 不同任务间的代码行数差异过大（有时是因为自动生成的文件更大），因此这项量化指标中存在大量“噪音”。将两个噪音数字（允许使用 AI 和不允许使用 AI 的任务的代码行数）直接比较，会产生非常嘈杂的结果。由此得到的差异性结果“不具备明确的统计学意义”。

• 研究者们考察了大量不同指标，其中少数指标出现偏差甚至指向相反结论并不稀奇。

• 在人工审核中，研究者们几乎没有发现允许使用 AI 的任务在实质上优于不允许使用 AI 的证据。虽然测试和注释量略有增加，但同样在合理的浮动范围之内。

而范围蔓延不太可能是导致速度变慢原因的最有力证据在于，对于开发者未上报范围蔓延的任务中，允许使用 AI 的任务的耗时增幅反而更大：

如果真的是因为范围蔓延导致允许使用 AI 的任务耗时更长，那结果应该相反才对。

除了代码行数上的差异，研究者们也想到了其他一些潜在的负面解释，例如代码臃肿、重复代码增加、不必要的花哨功能等。当然，好的可能也是有的。

更多时间并不代表更高强度。哪怕开发者在使用 AI 工具时耗费了更长时间，但实际工作强度可能有所下降。一般来说，审查/修改代码往往（注意，只是往往、并不一定）比从头开始编写更容易，而且等待 AI 输出的时间可以用来放松或者做点其他工作。

综上所述，Newman 认为 AI 工具的影响似乎并没有直观结论上那么糟糕。测得这 19%的生产力下降，部分原因可能是开发者工作更细致、精力消耗更低，也有部分原因可能是受试者过度使用 AI、过于专注这项研究的考核本身。但无论如何，AI 工具的帮助似乎不大，甚至在实际上降低了生产力……这可能吗？

从论文数据来分析，研究者确定了几条导致生产力下降的关键因素。最大的问题在于，AI 工具生成的代码往往达不到这些开源项目提出的高标准。开发者们需要耗费大量时间审查 AI 输出，而且这个过程往往需要反复进行：提示 AI、等待其生成代码、审查代码、发现致使缺陷并直接丢弃，之后再次提示 AI。（论文指出，Cursor 生成的代码中只有 39%可以采用；请注意，这还只是实际被采用的代码，开发者也可能最终放弃、选择自己重写）。

就是说在多数情况下，开发者白白浪费了时间，最终被迫选择亲自编写代码。

根据论文结论，开发者的时间分配如下所示：

请注意，上图反映了提任务完成时间占总时间的百分比，可以看到允许使用 AI 的任务平均完成时间更长，因此在高度相同的情况下，绿条表示的时间其实比紫条更长。很明显，对于允许使用 AI 的任务，开发者在研究和编写代码上耗费的时间更少（但受规模影响，这种差异并不明显）。

调整规模之后，他们在“测试及调试”与“git 和环境”上花费的时间大致相同，但空闲时间明显更长——这可能是因为等待 AI 工具会导致开发者失去“心流状态”。无论如何，在研究和编写代码上节约的少量时间，不仅彻底被提示 AI、等待其生成代码以及审查输出所耗费的时间抵消，甚至还有亏欠。

既然结果如此悲观，我们该如何理解那些 AI 编程工具不断冲上热搜的情况？

AI 工具好与坏分级严重，未来只会更甚

去年 12 月，Newman 就曾在文章中探讨过当前 AI 工具严重偏科的问题，而且擅长与糟糕之间的分界线参差度极大。这条参差不齐的分界线，蜿蜒穿过“软件开发”这个学科下的诸多事务。

在另一篇讨论文章中，作者写道：

通常情况下，大规模生产力提升只发生在体量不大、定义明确的绿地项目中，或者工程师刚刚开始接触一门新语言或 API 时。对于其他工作，现有工具能够带来的收益往往要小得多，而且很可能被审查、调试、集成和管理 AI 幻觉等完成抵消。

此番研究从多个方面凸显出当前 AI 编程工具的弱点。

首先，研究对象是拥有庞大代码库的成熟项目，其平均存续时间超过 10 年、包含百万余行代码，因此完全不符合“绿地”项目的定义。也就是说，执行一项任务可能需要理解大量过往代码库内容，而这正是当前 AI 工具的最大短板。（也许问题的根源并非 AI 大模型，而是某些编程工具的设计特性，例如限制发送给模型的「上下文」数量，从而控制成本以加快响应速度）。此外，研究还涉及编辑大型文件，而这些文件对于多数 AI 模型来说可能“超出了分布范围”，即没有接触过足够多的大型文件。文章还引用了来自开发者的评论，同样能在一定程度上支持这个观点：

“在软件开发中，开发人员往往依赖自身多年积累的代码库知识来辅助设计并实现决策。在我们的研究中，开发者经常提到 AI 缺乏这种隐性的代码库知识，并导致 AI 输出结果的实用性较差。一位开发者指出，AI 的表现其实很像刚刚参与项目的新贡献者，而且“AI 不知道如何选择正确的位置进行编辑”。另一位开发者则提到，“我们知晓代码后续将处理怎样的数据，但模型不知道。它不知道后续将面对哪些奇怪的向下兼容性问题，因此无法理解我们为什么要坚持保留某些代码。而这些都是很难简单以「上下文」形式提供的知识。”

因此可以合理假设，代码库的规模越大、成熟度越高，对于开发者的经验——也就是完成工作时所须具备的隐性知识数量将提出更高要求。因为 AI 系统可能无法访问这些知识，因此往往更难在此类问题上为经验丰富的开发者提供帮助。

其次，大多数开源项目都有严格的代码风格要求。研究中经验丰富的开发者已经习惯于按照项目指南进行编程，但 AI 工具却不行——这就导致开发者耗费大量时间来审查并修复 AI 的输出结果。

第三，参与此项研究的开发者们拥有多年项目经验，意味着他们本身的工作效率就已经极高——相当于是给 AI 找了一批顶级水平的竞争对手。

目前已有其他研究探讨 AI 工具在现实环境中对生产力的影响。2024 年的一项研究发现，“完成的任务数量增加了 26%。”而且当时受试者们使用的还是较为陈旧的工具，未能享受到 AI 编程工具在过去一年中的显著改进。虽然此前这项研究的方法论不那么严谨，但效率的提升很可能源自参与者多为经验不足的开发者，涉及的项目类型也更为广泛。该项研究指出，“经验不足的开发者表现出更高的 AI 输出采用率和更显著的生产力提升”，这也与 METR 最新研究中认为当前 AI 工具对于经验丰富的开发老鸟作用较小的观点一致。

而观察到的这 19%生产效率下降，与 AI 在编程基准测试中的得分也形成了鲜明对比。在编程竞赛中，AI 排名大多与人类顶尖选手相当。问题在于，编程竞赛提出的问题往往规模小、定义明确、孤立且从头开始（不依托于现有代码库），因此更能直接发挥 AI 的优势。

关于 AI 工具能节约时间的传闻，也大多来自大型 AI 实验室内部。这可能在一定程度上解释了感受与现实间的错位——大家应该还记得，此次研究的参与者们自己都感觉 AI 工具提高了开发速度，只是实际结果恰恰相反。而 AI 实验室中的很多工作确实更适合 AI 工具，包括编写小型训练实验、为聊天机器人添加 UI 元素等等。（需要注意的是，并非所有实验室内部人员都认同 AI 编程工具具有显著价值，具体可能视工作范围而定。）另外，AI 实验室的工程师可能在使用自有工具方面更有经验，而且能够与同事分享技巧来进一步释放 AI 潜力。

人们不断报告 AI 为生产力带来巨大提升，不少行业中的受控实验也认为这种提升真实存在，但大多数企业并没有感受到显著的效果。原因在于，释放 AI 助益需要组织结构层面的创新。

写在最后

这项研究从 2025 年初延续至年中。相信未来 AI 模型只会越来越强，基于这些模型构建的编程应用程序（例如 Cursor）也将不断改进，能够更好地利用模型能力。开发者也将越来越善于高效使用这些应用程序——提出正确任务，并为工具提供充足的上下文，确保其能够正确执行所需操作。所以本次研究的结论可能会迅速过时，毕竟回想起来，基于大模型的现代编程工具才刚刚出现几年。

AI 工具的功能也将持续扩展，帮助软件开发者分担更多工作内容，包括审查其他开发者编写的代码、执行测试，甚至审查并测试其他 AI 编写的代码。

研究提出的效率下降 19%这一结论乍看之下令人沮丧，但指向的却是 AI 工具最不擅长的复杂场景（经验丰富的开发者在质量要求极高的复杂代码库中工作），这可能是因为开发者想要放慢速度来节约精力、也可能是想让 AI 把工作做得更全面。

这个结果一定会随时间推移而有所改善。

最后，Newman 着重强调，他撰写本文绝不是要“戳破”AI 编程工具的泡沫，只是表明 AI 发展中的反馈循环可能比很多人的预期要漫长，目前的 AI 编程工具仍更适合那些小规模、一次性项目。与此同时，随着 AI 编写的代码越来越多，内容臃肿等问题是否会加剧也仍有待观察。

或许最重要的结论在于，即使开发者在使用 AI 时任务完成速度下降了 19%，但他们自己却认为速度提升了 20%。不少 AI 影响评估都是源自这种纯主观的表达和感受，而从此次研究提供的确凿数据来看，此类结果往往具有极大的误导性。

参考链接：

https://www.theregister.com/2025/07/11/ai_code_tools_slow_down/

https://forums.theregister.com/forum/all/2025/07/11/ai_code_tools_slow_down/

https://x.com/METR_Evals/status/1943360399220388093

论文地址：

https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf