摘要：AI 编程让开发速度提升了，但 Bug 也在同步暴涨——AI 生成代码的千行缺陷率是人工的 8 倍以上，44% 的 AI Token 消耗被用于修复 AI 自己生成的错误。本文用数据拆解"加速的代价"，聊聊 AI 为什么写不好健壮代码，以及什么时候该信 AI、什么时候该自己写。
一、那个熟悉的崩溃时刻
用 AI 写一个新功能的 CRUD 接口。
AI 秒出了完整代码。语法正确，编译通过，主流程跑了一遍——增删改查都正常。这种效率，换我以前得写半小时。
但上线前例行测了下边界情况。传空列表进去，直接 500。AI 在遍历之前没做空判断。
把报错贴回去，让它修。AI 加了判空逻辑，看着没问题。一编译——报错。但没 import 那个包。行吧，把报错贴回去，继续让它修。补上 import，跑通了。
然后发现另一个问题：它加的判空返回了 null，调用方没处理，另一个接口又崩了。
来回改了五六轮。代码从最初的一个边界问题，变成了三个不同层面的故障纠缠在一起——导包缺失、方法签名不匹配、连带改动破坏旧逻辑。AI 的修改越来越发散，每修一个地方就碰坏另一个地方。
我放弃了。重开了一个会话，把需求重新交代清楚，从头生成。十分钟搞定。之前折腾了一个半小时。
这种感觉你大概率也有过。AI 写代码像坐了火箭，Debug 的时候那支火箭就一头栽进沟里。
这不是个体感。数据比直觉更残酷。
二、加速的代价
先说代码质量。
AI 生成代码的 Bug 率是人工代码的 1.7 倍。这个数据来自代码审查平台 CodeRabbit，他们对比了 470 个开源仓库中 AI 生成代码和人工代码的缺陷密度。（来源：CodeRabbit）
1.7 倍听着还行？换个更直观的数字。
360 AI 安全研究院的测试数据显示：纯 AI 代码的千行缺陷率是 18.7 个，而人工代码是 2.3 个/千行——差距超过 8 倍。（来源：360 AI 安全研究院）
8 倍是什么概念？一个中等规模的模块，人工写可能有 5 个 Bug，AI 写就是 40 个。这 40 个 Bug 不会自己消失，每一个都得你去找、去修、去验证。
更细的维度上，AI 代码在特定类型的缺陷上表现尤其糟糕：
- 边界条件缺陷密度是人工的 4 倍
- 异常处理缺失是人工的 5.6 倍
- 并发/竞态问题是人工的 7 倍
（来源：头条综合报道, 2026.06）
安全方面同样不乐观。Veracode 的分析报告指出，45% 的 AI 生成代码无法通过 OWASP Top 10 的安全检查。（来源：Veracode）
代码跑不跑得通是一回事，跑得安不安全是另一回事。
但最让我震惊的是修复成本。
你花在让 AI 修 Bug 上的 Token，快赶上让它写新代码的 Token 了。如果按 API 调用费用算，你将近一半的钱是在给 AI 擦屁股。
Lightrun 2026 年的报告补充了更细的维度：43% 的 AI 生成代码即使通过了 QA 测试，上线后仍然需要人工调试。更狠的是，88% 的企业需要 2-3 轮重新部署才能确认 AI 的修复真的有效。0% 的工程负责人对 AI 代码"非常有信心"——是 0%，不是个位数。（来源：Lightrun 2026 年报告, VentureBeat）
GitClear 追踪了大量代码仓库的修改历史，发现了一个叫"代码翻新率"的指标——两周内被修改或回退的代码比例。基线是 3.3%，而 AI 辅助编写的代码翻新率是 5.7% 到 7.1%。（来源：GitClear）
差不多翻了一倍。
注意，不是"AI 写的功能坏了"，而是"AI 改代码的时候，把旁边没问题的功能搞坏了"。这种"副作用式 Bug"排查起来最折磨人——你盯着自己最近改的几行代码看了半天，最后发现是 AI 在另一个文件里默默少写了一个 import，导致整个模块加载失败。
讲一个真实的翻车现场。
2026 年 3 月，Amazon 经历了两次大规模宕机。事后排查发现：AI 辅助生成的代码未经人工审批，直接部署到了生产环境。结果——640 万张订单丢失。（来源：VentureBeat）
640 万单。这不是实验室里的 Benchmark，是实实在在的线上事故。
三、AI 为什么写不好健壮代码？
数据看完了，问题是：为什么？
语法能写对，编译一般能过，主流程能跑通，为什么一到边界情况、异常处理、并发场景就拉胯？
微软和 CMU 的联合研究给出了一个精准的概括：AI 写的代码具有"表层正确性"，但缺乏"深层健壮性"。（来源：微软+CMU 联合研究）
翻译成大白话：AI 能写出"看着对的代码"，但写不出"真的对的代码"。
拆开来看，有三层原因。
第一层：AI 只理解"快乐路径"。
AI 模型的核心能力是模式匹配——它见过海量的代码示例，知道一个"增删改查"大概长什么样。但它不理解为什么这么写。
举个例子。AI 知道 list.stream().map() 能遍历并转换数组，所以它会在任何需要遍历的地方用 .stream()。但它不会主动想：这个 list 可能为空吗？需要先判空吗？如果 list 里有一百万个元素会怎样？
这些是"快乐路径之外的世界"——但在生产环境中，用户输入为空、网络超时、并发写入、数据格式异常，这些才是日常。
这也是为什么 AI 代码的边界条件缺陷是人工的 4 倍，异常处理缺失是 5.6 倍。不是 AI 不想写，是它不知道"这儿需要处理异常"。
更准确地说，AI 写代码的逻辑是"在训练数据里见过的模式中，选一个概率最高的"。它不会问自己"如果这个输入是 null 会怎样"——因为训练数据里的代码示例，大部分都是正常输入下的正确写法。异常处理的代码占比本来就低，AI 自然学不到。
第二层：多轮对话让上下文蒸发。
AI 编程的典型流程是：写代码→发现边界问题→贴回去修→引入了新问题→再修→问题漂移→越来越歪。
每一轮对话，AI 都在重新理解你的项目上下文。第一轮它可能还记着你的项目用的是 Spring Boot 3.x 和 MyBatis-Plus，到第五轮的时候，上下文窗口已经被报错信息和修补指令塞满了，它开始"瞎猜"——引一个不存在的类名、调一个参数类型对不上的方法、甚至把之前修好的逻辑又改了。
我开头那个故事就是典型：修边界问题引入了导包缺失，修导包又带出了方法签名不匹配，再修签名的时候顺手改了不相干的日志配置。这不是 AI "笨"，是对话式编程的固有缺陷——你用聊天的方式修代码，就像隔着电话指挥一个人修水管，说得越多越乱。
这也是为什么 88% 的企业需要 2-3 轮重新部署才能确认修复有效。第一轮修了 A，第二轮发现 A 修好了但 B 坏了，第三轮修 B 的时候可能又把 A 弄回去了。
第三层：AI 没有业务理解。
AI 看代码，看到的是语法树和控制流。你看代码，看到的是"这段是创建订单，那段是扣库存，中间那个 if 是在判断用户有没有权限"。
所以 AI 可能在"扣库存"和"创建订单"之间改了一行，它觉得改得很漂亮，但它不知道"扣库存必须在创建订单之前"这条业务规则。结果呢？超卖了。
AI 在"修"的时候，不知道哪些东西是不能动的。
头条上有一篇报道的标题总结得特别好：AI 编程仅用 2 天写出第一版，修 Bug 却要 2 个月。
四、知道边界在哪，比"不用"更重要
说了这么多，不是要让你把 AI 编程工具卸载。
AI 写代码的速度优势是真实的。问题不在于"用不用"，而在于"怎么用"——知道 AI 的边界在哪，哪些活给它干、哪些活必须自己上。
下面是我自己踩了无数坑之后总结的几条实用策略。
第一，AI 适合写"有标准答案"的代码。
什么叫有标准答案？CRUD 接口、单元测试、数据转换、配置文件、正则表达式。这些玩意儿的模式高度固定，AI 见过的样本足够多，出错的概率低。
什么叫没有标准答案？架构设计、状态机、并发控制、性能优化。这些高度依赖场景和业务理解的东西，AI 生成的基本是"看起来像那么回事但实际跑不通"。
一条简单的判断标准：如果你能一句话把需求说清楚且不需要补充上下文，那就丢给 AI。如果需要解释"为什么这么设计"或者"这个业务规则是这样的"，那就自己写。
第二，AI 写完的代码，不要直接跑。
先读一遍。不是跑马观花地扫一眼，是一行一行读。
重点看三样东西：判空、异常处理、边界条件。这三样是 AI 系统性缺失的。如果你发现 AI 写了 50 行代码，一个 try-catch 都没有，一个 null check 都没有——那它大概率漏了。
有人会觉得"手动 Review 不如让 AI 直接修"。但问题是，让 AI 修一次可能引入两个新 Bug。GitClear 的翻新率数据已经证明了这一点。
第三，如果三轮修不好，果断重开。
这是我个人最重要的一条经验。
AI 多轮修复的边际效益是递减的。第一轮修复成功率可能 60%，第二轮 30%，到第四五轮，AI 的上下文已经被之前的错误信息污染了，它开始"随机试"——试一个方案，不行，再试另一个，越试越远。
我的规则是：三轮。三轮修不好，重开一个会话，把需求和项目规范重新交代清楚，从头生成。这比重蹈 Amazon 640 万单的覆辙强。
第四，把关键规则写进 prompt。
不要指望 AI 自己想起来"要判空"、"要处理异常"、"要 import 对应的包"。把它写进 prompt。
我的项目 Rules 文件里有这么一条：
所有方法调用前检查参数是否为空；所有外部 API 调用必须有 try-catch 和超时设置；生成代码时必须包含完整的 import 语句；禁止使用
var声明变量，必须显式写类型。
把规范前置，比事后修 Bug 省太多 Token 了——别忘了那 44% 的数据。
五、最后说两句
AI 编程工具不会消失，它只会越来越强。
但在它真正学会"理解业务"之前——如果那一天真的会来的话——程序员不会失业。只是工作的重心从"写代码"变成了"审代码"+"修 Bug"+"喊停"。
这不是降级。这是角色升级。
从"打字员"变成"把关人"。你的价值不再是你敲了多少行代码，而是你知道哪些代码能上线、哪些不能。
知道边界在哪，才能站在边界之内，用好边界之外的东西。
说到底，AI 是锤子，不是建筑师。锤子能让你敲钉子更快，但它不知道这面墙该不该敲。
作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。
