修 AI 的代码还是重写，我用两个模块试过

2026-09-12 AI编程,代码重构,技术决策

烧烤店那个小程序交付的时候，我手写的代码不到 20 行，其余都是 AI 出的。交付完回头整理，我手上有两个模块同样乱：一个我选择继续打补丁，另一个直接重写。修 AI 的代码要不要重写一遍，答案不在代码有多乱，在这模块有没有人依赖它。

两个模块的结果差别很大，我把判断依据摊开说。

修 AI 的代码还是重写：先看有没有人在用

| 维度 | 继续修（打补丁） | 推倒重写 |

|---|---|---|

| 对现有行为的影响 | 基本不变，风险可控 | 全部重来，要重新验证 |

| 前期投入 | 小，可以边用边改 | 大，中途没有可用版本 |

| 你对代码的理解 | 边改边建立，比较扎实 | 得先读完再动手，更慢 |

| 出问题是何时暴露 | 改完立刻知道 | 上线后才可能暴露 |

| 适合的信号 | 有人在用、有数据、逻辑正确只是乱 | 没人用、逻辑本身就错、改动成本高于重写 |

| 最大代价 | 补丁越叠越多，最后改不动 | 重写时漏掉原来看不见的边界行为 |

这张表里我个人最看重的是第一行和最后一行。有没有人在用，决定你能不能承担重写期间的空白期。

继续修适合这种情况：模块已经在跑，有真实数据在里面，业务逻辑本身没错，只是结构乱、命名乱、重复多。

这种模块重写的风险被严重低估了。你看不见的行为都藏在代码里，重写时漏掉一处，可能几周后才从数据上发现。

推倒重写适合这种情况：模块还没上线，或者虽然上线了但根本没人用，而且它的核心逻辑本身就有问题。

逻辑错了的代码，补丁叠得越多，修补成本涨得越快。这时候重写反而更快。

两个模块我最后是这么定的。

在跑的那个，我选择修。 理由很实在：它连着数据，重写期间业务是断的，而我没有第二个人能顶上来。我用的是先冻结行为、再按调用关系逐步整理的路子，具体顺序写在AI 写的代码太乱，我的 4 步重构顺序里。

没人用的那个，我直接重写。 因为重写的时候我才发现自己根本没完全理解它，那种情况下继续打补丁就是在给一个我不懂的东西加固。

判断卡住的时候，我会问自己一个问题：改完之后，我能不能说清这个模块的行为？ 答案是能，就修；答案是不能，重写反而更省。

其实不是只有两个选择。还有一个做法是只重写其中一个函数，把最乱、被调用最多、逻辑最独立的那部分抽出来单独重做，其余保持不动。

我在那个在跑的模块上用的就是这招。范围小，出问题影响面可控，而且重写那一小块的收益立刻能感受到。

Q：修 AI 的代码要不要重写一遍，怎么快速判断？

A：先看有没有人在用和有没有数据。有真实数据、业务逻辑正确的，优先修；没上线、逻辑本身就错的，重写更快。这两个条件基本能定八成的情况。

Q：重写会不会把原来藏着的功能弄丢？

A：会，这是重写最大的风险。规避办法是重写前先把原代码的行为逐条记下来，尤其是异常分支和边界处理。这一步省不得。

Q：让 AI 来重写是不是比让它修补丁更靠谱？

A：重写的效果通常比修更好，因为它不受旧结构的约束。但重写前你得先提供清楚的结构和约束，否则出来的还是一个新版本的乱。给约束比给代码重要。