夜雨聆风V2EX上有个帖子标题很扎眼："用Cursor写了两个月代码，今天review发现一半要重写"——1.8万人浏览，300多条回复。
评论区的画风很割裂。一半人说"AI让我效率翻倍"，另一半说"翻倍的是bug数量"。
2026年5月31日，IT之家转载了一篇来自知名AI研究实验室METR的最新报告。报告的核心结论很反直觉：AI编程工具确实让代码生成速度更快了，但开发者的总体效率可能反而在下降。
这个结论听起来违反常识。但当你把METR、CodeRabbit、Entelligence AI、Lightrun四家机构的数据放在一起看，一个令人不安的模式就浮现了。
METR研究：AI让开发者慢了19%
METR（Model Evaluation & Threat Research）在2025年做了一项随机对照实验（RCT），研究对象是16名经验丰富的开源开发者，他们在自己熟悉的大型开源项目上完成真实开发任务。
实验设计很简单：一半任务允许使用AI工具，一半不允许。然后比较完成时间。
结果出乎所有人预料：使用AI工具的任务，完成时间反而增加了19%。
更讽刺的是，实验前邀请了经济学专家和AI领域专家预测结果。专家们预测AI会让开发者快39%。实际数据是慢了19%——偏差高达58个百分点。
为什么开发者自己觉得快了，但实际慢了？METR的分析指出三个原因：
- 排查成本：AI生成的代码需要花大量时间排查潜在问题，即使表面上能运行
- 引导成本：花在写prompt、纠正AI方向、等待AI完成任务的时间，比直接写代码更长
- 修复成本：AI生成的代码bug更隐蔽，修复时间往往超过从头写
"代码生成速度"和"开发效率"是两回事。前者是生产环节，后者是全流程。
CodeRabbit报告：AI代码的bug是人工的1.7倍
CodeRabbit在2025年12月发布了一份大规模代码质量分析报告，对比了470个开源项目的Pull Request——其中320个有AI参与编写，150个是纯人工编写。
数据很清晰：
| 指标 | AI代码 | 人工代码 | 差距 |
|---|---|---|---|
| 每100个PR的问题数 | 10.83个 | 6.45个 | 1.7倍 |
| 逻辑错误 | 显著更高 | 基准 | +75% |
| 安全漏洞 | 显著更高 | 基准 | +274% |
| 可读性/规范问题 | 显著更高 | 基准 | +200% |
最值得注意的是安全漏洞——AI代码比人工代码多了近3倍。常见问题包括硬编码密码、不安全的对象引用、缺失的输入验证。这些不是"代码风格"问题，是会出事的。
CodeRabbit分析了原因：AI缺乏全局视野，倾向于生成语法正确但忽略边界检查的代码；选择最简单的实现路径，可能牺牲安全性。
82%的AI编程支出花在了修bug上
如果CodeRabbit的数据是"代码质量问题"，Entelligence AI的数据就是"钱的问题"。
Entelligence AI对2,444家企业做了调查，发现一个惊人的数字：每投入1美元用于AI编程，其中82美分花在了善后工作上。
具体拆解：每1美元AI支出中，0.44美元用于修复AI自己写的漏洞，0.27美元用于重写AI生成的代码，0.11美元消耗在审核与合并延迟上。只有0.18美元真正用于"新增价值"。
Lightrun在2026年4月发布的《State of AI-Powered Engineering》报告印证了这一点。他们调查了200名美国、英国和欧盟的大型企业SRE和DevOps负责人，发现：
- 43%的AI生成代码在通过QA和预发布测试后，仍需在生产环境中手动调试
- 88%的组织需要2-3次重新部署循环来验证一个AI建议的修复
- 0%的工程领导者对AI代码在生产环境中能正确运行"非常有信心"
零信任。没有一个人。
更扎心的数据：开发者平均每周38%的工作时间——差不多两个全天——花在调试、验证和环境问题排查上。AI省下的写代码时间，被这些善后工作吃掉了。
Uber四个月烧光全年预算，亚马逊关停AI排行榜
企业层面的案例更触目惊心。
2026年4月15日，Uber CTO Praveen Neppalli Naga公开表示，公司2026年全年的AI预算已经在四个月内烧完。Uber 2026年研发总预算34亿美元，同比增长9%。95%的工程师每月使用AI工具，70%的提交代码由AI生成，每周1,800个AI生成的代码变更进入生产环境。
烧钱速度远超预期的原因很简单：Claude Code按token计费，企业级代码库的上下文窗口消耗巨大，重度用户人均月消费500-2000美元，是宣传价的25-100倍。
Naga的原话是："I'm back to the drawing board, because the budget I thought I would need is blown away already."（我又回到了白板前，因为我以为够用的预算已经花光了。）
更荒诞的是亚马逊的案例。2026年5月29日，亚马逊宣布关停内部AI使用排行榜"Kirorank"。这个排行榜原本用来激励员工多用AI，结果员工为了刷排名刻意大量消耗token，导致算力成本激增。
使用AI不等于有效使用AI。当"用多少token"变成KPI，结果就是大家比赛烧钱。
Google DORA报告：90%在用，但只有25%信任
Google Cloud在2025年9月发布的DORA报告（调查了近5,000名技术专业人士）提供了一个更宏观的视角。
数据很矛盾：
- 90%的技术人员在工作中使用AI（同比增长14%）
- 80%表示生产力有所提高
- 但只有25%对AI输出报以"很多"或"极大"的信任
- 30%承认"不太"或"完全不"信任AI生成的代码
90%在用，但只有25%信任。这个数据本身就说明问题：大多数开发者在用一种自己并不完全信任的工具写代码。
DORA报告还发现，AI的采用与代码不稳定性增加相关。AI提高了吞吐量（发货更快更频繁），但也引入了新的不稳定性（变更失败率上升、返工增加）。
那该怎么办？
读到这里，你可能觉得我在说"AI编程没用"。不是。AI编程工具确实有价值，但前提是你要用对方式。
基于以上数据，三个具体建议：
第一，把AI当"初稿生成器"，不当"终稿交付器"。
CodeRabbit的数据表明，AI代码的安全漏洞是人工的3.7倍。这意味着AI生成的每一行代码都需要人工review，尤其是涉及认证、权限、数据处理的部分。省下写代码的时间，花在review上——这才是正确的效率公式。
第二，建立"AI代码成本"意识。
Entelligence AI的数据显示82%的AI支出花在善后工作上。对个人开发者来说，这意味着每月$20的订阅费背后还有隐性的时间成本。对团队来说，预算规划应该按宣传价的2-3倍估算。
第三，关注Google DORA报告的结论：AI是放大器，不是解药。
DORA报告的原话是：AI会放大一个组织已有的优势和劣势。如果你的团队本身代码review流程扎实、测试覆盖率高，AI会加速你们。如果流程混乱、测试缺失，AI只会加速产出更多的bug。
工具本身是中性的。决定效率的是你使用它的方式。
回到开头那个V2EX帖子。评论区最靠谱的一条回复写的是："AI让我写代码快了3倍，review AI代码慢了2倍，算下来总体快了50%——前提是review够认真。"
50%的效率提升是真实存在的。但前提是"review够认真"这四个字。跳过review直接提交，效率提升就变成了负数——METR的19%拖慢，就是这样来的。
AI编程工具不是"用了就高效"的魔法棒。它是一把双刃剑——用好了是生产力倍增器，用不好是bug制造机。
觉得这篇分析帮你少踩了一个坑？点个赞让更多人看到。关注「AI上效率」，每天一篇AI工具实测和数据拆解。