用 AI 写代码掉进“无限审查”陷阱？这就教你几招及时止损

最近在搞开发的时候，发现一个挺有意思的现象，估计很多用 AI 辅助编程的兄弟也遇到过：

作者头像

刚开始上手的时候，让 AI 写点小修小补的代码，那叫一个丝滑，直接上没问题。但一旦涉及到那些复杂的业务逻辑，事情就开始变得魔幻起来了。

AI 写复杂代码时，开启另一个 AI 进行审查虽然能发现 Bug，但往往陷入死循环。

F4A1 陷入“完美”的陷阱

我们通常的流程是这样的： 1. 生成阶段：先把需求丢给大模型，让它哐哐一顿输出。 2. 审查阶段：开启一个新的对话窗口（或者换个提示词），专门充当“代码审查员”的角色。

这时候，AI 审查员确实给力，总能挑出一些诸如“变量命名不规范”、“这里有潜在的异常处理缺失”、“算法效率可以再优化”之类的毛病。看起来非常专业，对吧？

F914 为什么永远审不完？

问题就在于，当你根据审查意见改完代码，再丢回去进行第二轮审查时，它往往又能挑出新的毛病。

有时候是为了修复上一个 Bug 引入了新的逻辑漏洞；有时候纯粹是因为 AI 的“随机温度”导致的——它每次都在努力生成“看起来更好”的建议，哪怕之前的代码其实已经跑得很稳了。

这就导致了一个很尴尬的局面：你越改越心虚，生怕改着改着把原本好用的逻辑给改崩了；但不改吧，看着 AI 扔出的一堆 Warning 又强迫症发作。

F6E1
F3FF 实战：如何打破死循环？\n面对这种“无限套娃”的代码审查，咱们得立点规矩，不能让 AI 牵着鼻子走。这里分享几个我总结的“止损策略”：

1. 设定明确的“停止信号” 不要问 AI “这段代码有什么问题？”，这是在找不痛快。你可以改成：

• “请检查这段代码是否存在致命错误（会导致崩溃或严重安全漏洞）。”
• “如果没有致命错误，请回复 'PASS' 并停止。”
• 限定审查轮次，比如“只审查一轮，不要过度优化非关键路径。”

2. 区分“能用”与“完美” 对于核心业务逻辑，确实需要严谨审查。但对于胶水代码、工具脚本，只要测试通过，功能符合预期，跑起来就行。代码洁症在 AI 时代是效率的大敌。

3. 用测试用例说话 别光让 AI 瞎看代码，把你的测试用例（或者预期的输入输出）丢给它。告诉它：“只要确保在这个输入下能得到那个输出即可。”用结果倒推，比纯看代码逻辑讨论要靠谱得多。

4. 相信第一直觉，小步快跑 如果 AI 第一次生成的代码能跑通，哪怕不够优雅，建议先 commit 上去。过度追求代码的艺术性，往往会陷入为了改而改的陷阱。先把功能做出来，重构那是后面的事。

F44D 总结

AI 是个强大的副驾驶，但它不会刹车。作为掌握方向盘的开发者，我们必须学会什么时候该踩油门，什么时候该踩刹车。

下次当你发现 AI 还在喋喋不休地建议你修改第 N 版代码时，不妨停下来想一想：这个改动真的有必要吗？还是说，这只是 AI 在凑字数？

有时候，“跑起来就行”才是最高效的开发智慧。