我在 LLM 生成的代码审查中经常看到这个模式。

LLM 看到一个正常工作的函数，建议”这可以简化”。它将逻辑重写为更短更整洁的版本。测试仍然通过。diff 看起来很棒。PR 被批准了。

但在被删除的代码中，隐藏着测试套件未覆盖的真实边界情况处理。也许是对供应商 API 特性的变通方案，也许是对仅在负载下才会触发的竞态条件的防护。原作者知道这些。LLM 不知道。

代码没有错。它承载着测试套件中没有表达的知识。

我开始应用一条规则：在删除或简化任何代码之前，你必须能够回答两个问题：

1. 这段代码解决了什么具体问题？
2. 如果这段代码是错的，什么测试会失败？

如果你两个都答不上来，你还没有理解到足以修改它的程度。正确的做法是先写缺失的测试，然后再重构。

这对 AI 生成的代码审查尤其重要，因为 LLM 非常擅长模式匹配”这看起来是多余的”，却不理解”这看起来是多余的，是因为三年前支付处理器悄悄改变了超时行为，而这个 sleep 语句是防止级联故障的唯一屏障”。

代码承载的信息不止其逻辑。它还承载其历史。尊重它。