AI 写代码飞快，修 Bug 修到崩溃

摘要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 生成代码和人工代码的缺陷密度。来源CodeRabbit1.7 倍听着还行换个更直观的数字。360 AI 安全研究院的测试数据显示纯 AI 代码的千行缺陷率是 18.7 个而人工代码是 2.3 个/千行——差距超过 8 倍。来源360 AI 安全研究院8 倍是什么概念一个中等规模的模块人工写可能有 5 个 BugAI 写就是 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 年报告, VentureBeatGitClear 追踪了大量代码仓库的修改历史发现了一个叫代码翻新率的指标——两周内被修改或回退的代码比例。基线是 3.3%而 AI 辅助编写的代码翻新率是 5.7% 到 7.1%。来源GitClear差不多翻了一倍。注意不是AI 写的功能坏了而是AI 改代码的时候把旁边没问题的功能搞坏了。这种副作用式 Bug排查起来最折磨人——你盯着自己最近改的几行代码看了半天最后发现是 AI 在另一个文件里默默少写了一个 import导致整个模块加载失败。讲一个真实的翻车现场。2026 年 3 月Amazon 经历了两次大规模宕机。事后排查发现AI 辅助生成的代码未经人工审批直接部署到了生产环境。结果——640 万张订单丢失。来源VentureBeat640 万单。这不是实验室里的 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 拓展到全栈的工程师。