最近浏览技术资讯时，我注意到了几个反复出现的数据：
- 微软报告：数万名工程师使用 Claude Code 和 Copilot 四个月后，每人每天合并的 PR 增加了 24%。
- 埃森哲 RCT 实验：使用 Copilot 的开发者完成 HTTP 服务器任务平均快 55%。
- CodeRabbit 报告：AI 生成的代码逻辑错误比人类高出 75%，问题总量是人类的 1.7 倍。
- METR 研究：16 名经验丰富的开源开发者在实际项目中用 AI，结果反而慢了 19%。
效率涨了 24%，错了多了 75%，实际还慢了 19%。这些数据放在一起时，画风和单独看任何一个都完全不同。作为一个每天写代码的程序员，我想算一笔账：AI 编程到底省了什么、多了什么，以及这些"隐性成本"藏在哪里。
1. 效率数据的三个版本
先把这几个关键数据摆在一起看。
| 研究 | 样本 | 结论 |
|---|---|---|
| 微软内部报告 | 数万名工程师，4 个月 | PR 合并量 +24% |
| GitHub Copilot 研究 | 4800 名开发者，HTTP 服务器任务 | 平均快 55% |
| 埃森哲 RCT | 受控实验 | 代码提交 +8.69%，构建成功率 +84% |
| METR 研究 | 16 名资深开源开发者，246 个任务 | 实际慢了 19% |
看起来互相矛盾？其实不矛盾。区别在于任务类型。
前三个研究测量的任务偏向短小、明确、模式化——"写一个 HTTP 服务器""补全一个函数"。这正是 AI 最擅长的：模式匹配。GitHub 上数亿个仓库的训练数据里，HTTP 服务器的写法高度一致，AI 只需要"续写"最常见的模式。
METR 研究测量的是真实开源项目中的实际任务——涉及多文件改动、复杂业务逻辑、长期维护的上下文。这里 AI 的优势被隐性成本抵消了。
2. 五个隐性成本
2.1 技术债的加速度
AI 写代码快，但它不理解"整个项目的架构风格"。一个 10 人团队，每个人都用 AI，每个人提示词不同、上下文不同，生成的代码风格、错误处理方式、状态管理策略各不相同。
三个月后，代码库变成"缝合怪"——每个文件单独看都能跑，放在一起就是一团乱麻。
以前技术债是线性增长的：人写多少代码，就欠多少债。AI 让代码产出翻倍，技术债也翻倍，但还债的速度没变。
2.2 Code Review 的瓶颈
微软报告说 PR 增加了 24%。但谁来 Review 这些多出来的 PR？
AI 可以替你写代码，但不能替你 Review 别人的代码。而且 Review AI 代码比 Review 人写的代码更难——因为你不知道这段代码"为什么"这样写，只能看到"是什么"。
更严重的是，Sonar 调查显示 96% 的开发者不会完整审查 AI 生成的代码。代码能跑就合，下一个。
24% 更多的 PR + 70% 更多的 bug + 96% 不仔细看 = 技术债的滚雪球。
2.3 安全漏洞的乘数效应
研究显示 AI 生成代码的安全漏洞率是人类的 2.74 倍。
以前一个团队一天写 100 行代码，可能有 2 个安全漏洞。现在一天写 300 行，漏洞可能变成 16 个——产出涨 3 倍，漏洞涨 8 倍。
而且 AI 生成的安全漏洞比人写的更难发现，因为代码"看起来"很标准，模式都对，就是在某个边界条件上漏了一个验证。
2.4 初级开发者的成长陷阱
AI 编程最大的受益者不是高级工程师，而是初级工程师——AI 让他们的产出"看起来"和高级差不多。
但"看起来差不多"和"真的差不多"是两回事。初级工程师用 AI 绕过了"自己思考解决方案"的过程。产出有了，能力没涨。
一年后：账面上有一批"高产出"的初级工程师，但没有人能 debug 那些 AI 写的代码，也没有人能做架构决策。
斯坦福数字经济实验室的数据显示：2022 年以来，30 岁以下年轻程序员的就业率下降了约 6%，而 30 岁以上反而增长了 6-13%。入门级岗位在收缩，"能驾驭 AI"的岗位在增加。
2.5 调试成本不降反升
AI 代码最讽刺的地方：写得快，但修得慢。
AI 生成的代码你没有亲手写过，你不知道它的设计意图，不知道它为什么选了这个方案而不是那个。出了 bug，你面对的是一段"别人写的代码"——只不过这个"别人"是 AI，你连问都没法问。
Hacker News 上最近火了一个帖子：三个工程师创办了 Slopfix，专门帮企业清理 AI 生成的代码，收费每周 1 万美元。生意好到接不完。
3. 从 Dijkstra 到 Karpathy 的共识
1978 年，计算机科学祖师爷 Edsger Dijkstra 在论文《论"自然语言编程"的愚蠢》中写道：
自然语言的本质，是允许人类轻松说出连自己都未察觉的模糊、歧义与矛盾。
用自然语言驱动 AI 写代码，本质上是用"模糊"的语言去约束一个"极其确定"的结果。当你的约束严谨到足以让 AI 不犯错时，你的提示词已经变成了一套极其臃肿、低效的"新编程语言"。
有趣的是，Karpathy 本人也经历了从鼓吹到反思的转变。他最早提出 Vibe Coding 概念时说"用来随手做点周末项目还不错"，后来直接放弃了这个方向，转向更务实的 Agentic Engineering。
连发明这个词的人都放弃了，值得认真对待。
4. 自测清单：你的 AI 代码踩坑了吗？
| 风险信号 | 检查方法 | 严重程度 |
|---|---|---|
| AI 代码合并后从不回头看 | 查最近 10 个 AI PR 的后续修改记录 | 🔴 高 |
| Review 时只看"能不能跑" | 问自己：能说出这段代码为什么这样写吗？ | 🔴 高 |
| 团队没有 AI 代码审查标准 | 有没有专门针对 AI 代码的 checklist？ | 🟡 中 |
| 初级成员产出突然和高级持平 | 对比 debug 能力和架构讨论参与度 | 🟡 中 |
| 代码风格越来越不一致 | 翻最近一个月的提交，看格式/命名/错误处理 | 🟡 中 |
| 从没跑过安全扫描 | 对 AI 生成的代码做一次 SonarQube/Snyk 扫描 | 🔴 高 |
| 没人能解释某个模块的设计意图 | 随机挑一个 AI 写的模块，让作者讲逻辑 | 🟡 中 |
| 线上 bug 修复时间变长 | 对比引入 AI 前后的平均 bug 修复时长 | 🔴 高 |
5. 正确的用法
不是说不能用 AI 编程。而是应该知道代价在哪里，然后主动管理它。
适合交给 AI 的：
- 原型开发和快速验证——想法不确定时，让 AI 先出一个粗糙版本
- 学习新语言和新框架——AI 给你的是可运行的具体例子，比翻文档快
- 重复性样板代码——数据库连接、接口定义、配置文件，模式极其明确
- 修 bug 和理解报错——AI 见过无数"错误-原因-解法"的模式对
仍然需要人做的：
- 架构设计——没有两个项目的架构完全相同，模式匹配在这里力不从心
- 业务逻辑判断——AI 不知道你的用户是谁、他们怎么使用产品
- 代码审查——CodeRabbit 报告：AI 代码中安全漏洞是人类代码的 1.5 倍
- 性能优化——AI 倾向于用最简单直白的方式写代码，不是最高效的方式
四个底线：
- AI 写代码 → 但必须有人类 Review（不是扫一眼）
- 用 AI 加速 → 但省出来的时间拿来做 Code Review 和测试
- 初级工程师可以用 AI → 但必须能解释 AI 生成的每一行代码
- 衡量效率 → 但同时衡量 bug 率、安全漏洞数、技术债增长速度
PR 涨了 24%，如果 bug 也涨了 75%，净效果是正的还是负的？
这道算术题，每个技术负责人都应该自己算一遍。
版权声明：如无特殊说明，文章均为本站原创，转载请注明出处
本文链接：https://tendcode.com/subject/article/ai-coding-hidden-costs/
许可协议：署名-非商业性使用 4.0 国际许可协议