最近和团队其他深度使用AI的同事聊到一个很有意思的问题。
AI 生了一段代码，大部分能跑，但有几个 bug。这时候你怎么选——手工修掉？继续写 prompt 让 AI 改？还是直接把这段代码回滚，重新生成？
每个人反应都不太一样。有的人习惯手工修，有的人第一反应是追问 AI，有的人直接回滚重来。
用了大半年 AI Coding 之后，我慢慢摸索出一套自己的判断标准。核心就一件事：先判问题大小，再决定怎么动手。
我把问题分成三层。
第一层：小问题，手工修
什么叫小问题？空指针没判、标签没闭合、变量名写错了——这种一眼能看穿的。
这类 bug 我从不写 prompt。为什么？因为写 prompt 描述问题的功夫，你已经修完了。
你想想这个过程：你得把 bug 现象描述清楚 → 等 AI 生成 → 看改没改对 → 可能还得再调一轮。一个空指针，手动改 5 秒。走一轮 prompt，至少两分钟。这笔账太好算了。
小问题的判断标准很简单：你一眼就知道哪里错了，而且你知道怎么改。
这种情况还去写 prompt，不是用好 AI，是被 AI 绑架。时间浪费了，token 也白烧。
第二层：中等问题，看熟悉度
这是最纠结的一层。
比如边界条件没处理、并发逻辑有问题、异常路径没覆盖——不是一眼能看穿的 bug，但也不是架构级的硬伤。
遇到这种，我的判断标准是两条：
第一，这块代码我熟不熟？ 熟的话，大概率手工修。因为我知道改哪里、怎么改、改完会影响什么。不熟的话，可以尝试一两轮 prompt。
第二，是不是核心链路？ 如果是支付、鉴权这种高危模块，我更倾向于手工修——出了问题你没法跟领导说"这是 AI 写的"。如果是边缘功能，让 AI 改一两轮问题不大。
但这里有个坑，我重点说一下。
最大的坑：追问死循环
中等问题上，最容易犯的错是无底线追问。
修了 A，AI 给你冒出 B。修了 B，冒出 C。修完 C 回头一看，A 又坏了。
为什么？因为 AI 在迭代修改时会继承错误的上下文。你每追问一轮，prompt 里就多一层历史包袱。改到第三四轮的时候，AI 已经在垃圾堆上盖房子了。
这时候有一个办法可以试：换模型。
不同模型擅长的领域真的不一样。我自己的体感，DeepSeek V4 Pro 在处理一些逻辑推理和数据处理类的代码上很灵光，但遇到复杂架构设计或者需要深度理解业务上下文的任务，就容易跑偏。反过来，MiniMax-M3 在某些领域很稳，但换到 DeepSeek 擅长的那类问题，表现又不太够看。
这不是玄学。每个模型训练时喂的数据不一样，推理的路数也不一样，舒适区天然不同。你在这个模型上追了 3 轮还转不出来，不一定是你 prompt 的问题，可能就是这个模型不擅长这类任务。换个模型，同样的 prompt，一遍就过了。
所以遇到追问两三轮还没搞定的时候，别死磕。切到另一个模型试试，有时候比改 prompt 更管用。
如果换了模型还不对，那问题大概率不在模型上。我的止损线很明确：追 3 轮还不对，立刻回滚，重新写 prompt 生成整个功能。
这话说起来简单，做起来难。因为人都有沉没成本心理——"我已经花了半小时修了，现在回滚不是白费了？"
但实际情况是，你继续追下去，可能再花一小时，最后还是得回滚。
我见过最典型的案例：一个同事修了一下午的 AI 代码，来回追了七八轮，最后烦了，回滚重写 prompt，10 分钟搞定。前面那三小时，全是"不舍得"的代价。
第三层：大问题，果断回滚
代码分层不对、整体设计方向跑偏、或者 AI 理解错了需求——这种叫大问题。
大问题不要修，不要追，直接回滚。因为根是歪的，修再多枝叶都没用。
重新生成之前，把 prompt 里的歧义清掉。很多时候 AI 写偏了，不是它不行，是你没说清楚。把需求拆细、把约束写明、给一两个正反例——第二次出来的东西通常好很多。
判断问题大小，本身就是能力
这套三层判断法说起来不复杂，但执行起来有个前提：你得能快速判断一个 bug 属于哪一层。
这个判断力不是天生的。你得对你用的语言、框架、业务逻辑有一定熟悉度，才能在一两分钟内做出判断。
有些同学一看到 bug 就开始追着 AI 改，改到一半才发现是个大问题。等反应过来，时间已经烧掉了。有这个时间，自己修早完事了。
这就是 AI Coding 里很微妙的一点：AI 省的是"写"的时间，不是"判"的时间。 判断还得靠人。
练多了之后，你会形成一种直觉——看到 bug 的第一反应不是"让 AI 修"，而是"这是哪类问题"。到这个状态，人机协同的效率才算真正上来了。
最后
我们团队近期达成了个共识：AI 能不能搞定一个项目，不看项目复杂度，不看代码量，看验证成本。
什么叫验证成本？就是 AI 生成完代码之后，你验证它对不对要花多少时间。验证成本低的（比如跑个测试就完事），AI 可以放开用。验证成本高的（比如核心支付逻辑，错了就是事故），人必须盯紧。
所以回到最开始的问题：AI 生成的代码有 bug，修还是重来？
答案不是绝对的。但它取决于你的判断，不取决于 bug 本身。人机协同，人判机写。判在前，写在后面。
- 作者:Yibin
- 链接:https://yibin.dev/article/37860b50-99a4-801d-aba4-c846cacf36bf
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
