今天有个叫 METR (加州柏克莱模型评估与威胁研究) 的机构刷了一波存在感，因其发布了一份名为《2025上半年关于AI对资深开源开发者生产力的影响》的报告。
AI让开发者效率不升反降
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower. We view this result as a snapshot of early-2025 AI capabilities in one relevant setting; as these systems continue to rapidly evolve, we plan on continuing to use this methodology to help estimate AI acceleration from AI R&D automation.
该报告指出AI编程工具并未提升开发者的工作效率，反而导致他们的效率下降了19%。这项研究并非简单的实验室测试，而是基于16位资深开源开发者在自己维护的项目中完成的246个真实任务的结果。这些项目的平均星标超过22,000个，代码行数更是突破了100万。令人讽刺的是，开发者在测试前普遍预期AI能让他们的工作速度提升24%，而测试后仍然认为自己快了20%。然而，事实的真相是，实际的工作效率却下降了19%。
研究方法
这份报告的结果确实让我感到有些意外。就我个人体验而言，AI工具确实大幅提升了我的工作效率。因此，我仔细看了一下他们的实验方法。发现在研究设计上，METR实验方法还是挺严谨的。参与者都是在各自项目中贡献了平均5年经验和1500次提交的核心开发者。每位开发者提供了他们日常工作中的真实任务，如bug修复、新功能开发和代码重构，这些任务被随机分配到使用AI和不使用AI两组。允许使用AI时，开发者主要使用CursorPro与Claude3.5/3.7等前沿模型进行配合，每个任务的平均耗时为2小时，并要求开发者录屏记录完成时间。为了激励参与者，研究团队提供了高达150美元的时薪。
实验设计：
-
参与者：16名有中等AI经验的资深开源开发者（平均5年项目经验，累计提交1,500次代码）。
-
任务来源：
- 从GitHub热门仓库（如stdlib-js/stdlib、scikit-learn）中选取真实Issue（Bug修复、功能开发等）。
- 任务平均耗时2小时，开发者需自行拆分复杂任务以满足时长限制。
-
分组逻辑：
- 任务随机分配至AI允许组（可使用Cursor Pro + Claude 3.5/3.7）或AI禁用组（禁止使用任何生成式AI工具）。
- 开发者可自主选择是否在AI允许组中使用特定工具。
数据收集
-
主观数据：开发者预估任务时间（任务前）和事后复盘时间。
-
客观数据：
- 屏幕录像（143小时，覆盖29%任务时间），用于分析开发行为（如编码、调试、审查AI输出）。
- 提交记录与PR审查时间（用于计算总耗时）。
-
退出访谈：开发者分享AI使用体验、效率瓶颈及改进建议。
减速原因分析
那么，AI的效率损失究竟在哪里呢？研究团队发现，虽然开发者在编码和搜索信息的时间上有所减少，但节省下来的时间却被以下几个因素所消耗：
- 提示词编写：开发者需要反复调整提示，以便让AI更好地理解需求（这个花不了多少时间，反复写则不同）。
- 等待AI响应：生成代码的过程是有时间成本的。
- 审查AI输出：开发者需要仔细检查AI生成的代码，确保其质量。
- 思考如何更好地使用AI：在等待AI的同时，开发者可能会花时间思考如何有效利用这些工具。
更为惊人的是，研究显示，开发者仅有44%的AI生成代码被保留，其余的要么被完全丢弃，要么需要大幅度重写。屏幕录像显示，约9%的活跃时间用于清理AI生成的代码，4%的时间则是在等待AI的响应。不同的模型（如Claude3.5、3.7、GPT-4o）和不同任务中都存在这一效率损失现象。
!
以上是直接原因，研究团队进一步分析了导致这种效率损失的深层原因，归纳为以下几个方面：
一、直接生产力损失类因素
1. 对AI有用性的过度乐观（C.1.1）
开发者普遍高估AI的加速效果——任务前预测AI可减少24%时间，任务后仍认为AI减少了20%时间（与实际减速19%矛盾）。即使开发者意识到AI生成代码效率低（如需要大量修改），仍因主观预期选择继续使用AI工具，而非回归纯人工开发。这种“过度依赖”导致无效的时间投入。（AI就是好，死不悔改）
数据支持：开发者接受AI生成代码的比例仅44%，但9%的工作时间用于清理/修改AI输出，直接增加了任务耗时。
2. AI可靠性低（C.1.4）
AI生成的代码质量不足，需开发者频繁干预。低可靠性迫使开发者投入额外时间审查、调试和修正AI输出。
数据支持：开发者平均每接受1小时AI生成代码，需额外花费0.22小时（约9%）进行修正（通过总工时与AI使用时间的比例推算）。
二、开发者与任务特性类因素
3. 开发者对仓库的高熟悉度（C.1.2）
开发者平均拥有5年项目经验、1,500次提交记录，对仓库的代码结构、规范和隐含逻辑非常熟悉。而这种高熟悉度降低了AI的“辅助价值”——开发者无需AI即可高效完成任务，而AI生成的代码可能不符合其习惯（如命名规范、模块划分），反而需要额外时间调整。
数据支持：开发者对越熟悉的仓库，减速效应越显著（相关系数0.72）；部分开发者明确表示“AI的建议对我帮助不大”。
4. 大型复杂仓库的限制（C.1.3）
研究对象为平均110万行代码、存在10年历史的成熟仓库（如pandas、scikit-learn）。复杂代码库的隐含上下文（如未显式注释的业务逻辑、跨模块依赖）超出AI的理解能力，导致其生成代码与项目规范脱节。
数据支持：开发者报告“AI在大型复杂环境中表现更差”的比例达80%；AI生成的代码中，35%因不符合项目规范被拒绝（需重新生成或手动修改）。
三、AI与任务上下文脱节类因素
5. 隐含仓库上下文的缺失（C.1.5）
AI无法利用开发者对项目的隐性知识（如未文档化的“潜规则”、团队协作习惯）。AI生成代码可能忽略项目特有的约束（如性能优化要求、遗留系统兼容性），导致开发者需重新设计或调整代码逻辑。
数据支持：80%的开发者认为“AI未利用重要的隐性知识”是减速主因之一；典型案例中，AI生成的数据库查询语句因未考虑旧版本索引规则，导致执行效率低下，需开发者重写。
其他潜在关联因素（证据不明确但可能加剧减速）
- 实验驱动的AI过度使用（C.2.1）：部分开发者因实验要求强制使用AI，即使人工更快，仍选择“先让AI生成初稿”，导致时间浪费。
- AI扩大任务范围（C.2.3）：AI可能建议开发者完成更多功能（如“顺便优化相关模块”），导致实际工作量增加（47%的AI允许任务代码量比预期多）。
个人观点
这篇报告最终得到结论：AI在复杂、成熟项目中的能力边界与开发者需求不匹配，叠加开发者对AI的高估和自身经验优势，最终导致“工具使用成本超过其带来的效率提升”。
虽然这个研究设计上很合理，但结论也不可尽信。
报告强调这个“效率下降”的现象主要发生在资深、经验丰富的开源开发者身上。而我作为比较初级的开发者，可能就不属于这个受影响的人群。所以不符合我的直观感受。
另外，效率=任务数量/时间，即单位时间完成的工作量，不能根据时间就判断效率高低。其实AI工具出现之后，程序员代码量和任务数都大幅提升了。
学习AI工具的时间成本其实并不高，一次学会，后续都能受益。
AI生成的代码很多时候都会被大幅修改或重写，这也是正常的。也会倒逼我们修改更准确的提示词，这也是理清思路的一种路径。因为它生成的成本很低，所以我们删除或重写，也没有什么心理负担。
AI生成代码会消耗一定的时间，这个算不上效率损失。相反，是件好事。一来可以让程序员休息放松一下，最起码可以避免“键盘手”、“鼠标手”；二来可以让程序员有更多的时间思考和优化代码。你家里的扫地机器人、洗碗机干活都挺慢的，要那么快干吗？又不是你干，你只要想，指挥就行了。
最后我为该实验提供一种测试方式，能较好的衡量开发者的效率，就是敲键盘的次数。次数越少，效率越高。这个比较直观，也比较好量化。
