微软刚发了一份研究报告：给几万名工程师部署 Claude Code 和 Copilot CLI 四个月后，每人每天多合并了 24% 的 PR。管理层都在转发。但我把它和另外几份数据放在一起看完之后——坐不住了。

24% 的效率提升，听起来很美

先说微软这份报告的核心数据：

• 研究对象：数万名微软工程师
• 部署工具：Claude Code + GitHub Copilot CLI
• 时间跨度：2026 年初，四个月
• 核心结论：每人每天合并的 PR 增加了 24%（置信区间 14.5%-33.7%）

24% 的提升确实不小。如果一个团队以前一天能合并 10 个 PR，现在能合并 12-13 个。管理层看到这个数字，第一反应是"全员推广"。

但 PR 数量增加 = 生产力提升吗？

这份报告在 Hacker News 的讨论帖里，点赞最高的评论说了一句话：

Lines of code isn't productivity, and neither is CLs landed.（代码行数不是生产力，合并的 PR 数也不是。）

效率涨了 24%，但另一组数据没人提

把微软报告和其他几份最近的研究放在一起，画风完全不同了：

数据一：AI 代码的 bug 率高 70%

Shiplight 对数千个 PR 的分析显示，AI 生成的代码比人写的多 1.7 倍 bug，逻辑错误多 75%，可读性问题多 3 倍。

PR 是多了 24%，但每个 PR 里藏的 bug 也多了 70%。

数据二：96% 的开发者不完整审查 AI 代码

Sonar 的调查显示，96% 的开发者不会完整审查 AI 生成的代码。AI 写完了，扫一眼，能跑就合，下一个。

24% 更多的 PR + 每个 PR bug 多 70% + 96% 没人仔细看 = ？

数据三：开发者对 AI 代码的信任度降至 33%

2026 年的调查数据显示，只有 33% 的开发者信任 AI 生成的代码质量。但信不信是一回事，用不用是另一回事——工期在那摆着，老板在催，不用 AI 就是效率低。

数据四：有人靠清理 AI 代码月入 4 万美元

三个工程师辞职创办了 Slopfix，专门帮企业清理 AI 生成的代码，收费每周 1 万美元。生意好到接不完。

Forbes 上周的标题更直接：AI Coding Is Starting To Feel Like A Gamble（AI 编程开始像赌博了）。

真正的代价是什么

效率涨 24% 很好。但代价是什么？我整理了五个"报告里没写"的隐性成本。

代价一：技术债加速积累

AI 写代码快，但它不会考虑架构一致性。一个 10 人团队里 10 个人都用 AI，每个人生成的代码风格、错误处理方式、状态管理策略都不一样。

三个月后，代码库变成缝合怪。以前技术债线性增长，现在 AI 让代码产出翻倍，技术债也翻倍，但还的速度没变。

代价二：Code Review 变成新瓶颈

PR 增加了 24%——谁来 Review？

AI 可以替你写代码，但不能替你 Review 别人的代码。PR 多了 24%，Review 的工作量也多了 24%。而且 AI 代码的 Review 比人写的更难——因为你不知道"为什么"这样写，只能看到"是什么"。

结果：要么 Review 质量下降（96% 的人已经在这么做了），要么 Review 成为整个团队的瓶颈。

代价三：初级开发者不成长了

AI 写代码最大的受益者是初级工程师——产出"看起来"和高级差不多。但"看起来差不多"和"真的差不多"是两回事。

初级工程师用 AI 绕过了"自己思考解决方案"的过程，产出有了，能力没涨。一年后：公司账面上有一批"高产出"的初级工程师，但没人能 debug AI 写的代码，也没人能做架构决策。

代价四：安全漏洞乘数效应

安全研究显示，AI 生成的代码安全漏洞率是人写代码的 2.74 倍。

以前一天 100 行代码，可能 2 个安全漏洞。现在一天 300 行，漏洞可能有 16 个。产出涨 3 倍，漏洞涨 8 倍。而且 AI 的安全漏洞更难发现——代码"看起来"很标准，就是在某个边界条件上漏了一个验证。

代价五：调试成本不降反升

AI 代码最讽刺的地方：写得快，修得慢。

你没有亲手写过，不知道设计意图，不知道为什么选了这个方案。出了 bug，面对的是"别人写的代码"——只不过这个"别人"是 AI，你连问都没法问。

Slopfix 每周 1 万美元帮人清理 AI 代码，不是因为 AI 代码特别烂——是因为没有人知道它是怎么回事，只能推倒重来。

速查表：你的 AI 代码有没有踩这些坑

风险信号	检查方法	严重程度
AI 代码合并后从不回头看	查最近 10 个 AI PR 的后续修改记录	🔴 高
Review 时只看"能不能跑"	能说出这段代码为什么这样写吗？	🔴 高
团队没有 AI 代码审查标准	有没有专门的 AI 代码 checklist？	🟡 中
初级成员产出突然和高级持平	对比 debug 能力和架构讨论参与度	🟡 中
代码风格越来越不一致	翻最近一个月的提交看格式/命名	🟡 中
从没跑过安全扫描	对 AI 代码做一次安全扫描	🔴 高
线上 bug 修复时间变长	对比引入 AI 前后的修复时长	🔴 高

收藏这张表。下次做月度回顾的时候，对着查一遍。

不是不该用 AI，是不该盲目用

微软的 24% 效率提升是真的。AI 编程确实有价值。

但"写得快"和"写得好"是两件事。微软的报告衡量的是前者，我们日常承受的是后者的后果。

正确的用法：

1. AI 写代码 → 但必须有人类 Review（不是扫一眼）
2. 用 AI 加速 → 省出来的时间做 Code Review 和测试
3. 初级可以用 AI → 但必须能解释 AI 生成的每一行代码
4. 衡量效率 → 同时衡量 bug 率、安全漏洞数、技术债增速

PR 涨了 24%，如果 bug 也涨了 70%，净效果是正的还是负的？

这道算术题，每个技术负责人都应该自己算一遍。

你的团队用 AI 编程后，代码质量有变化吗？评论区说说你的观察。

---

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。