--- title: "AI 代码审查停不下来，先改掉那句“帮我找 bug” | 行开心的颠倒世界" description: "AI 代码审查、Claude Code、Codex：一个 PR 一夜审了五十多轮，反复标出的问题约 59% 在第一轮就已存在。问题常出在“帮我找 bug”这句话本身。可以把提问改中性，要求先报问题数量，再给审查轮数设上限。" canonical: "https://xingkaixin.me/posts/ai-review-find-bug-prompt/" language: "zh-CN" --- # AI 代码审查停不下来，先改掉那句“帮我找 bug” AI 代码审查、Claude Code、Codex：一个 PR 一夜审了五十多轮，反复标出的问题约 59% 在第一轮就已存在。问题常出在“帮我找 bug”这句话本身。可以把提问改中性，要求先报问题数量，再给审查轮数设上限。 2026年11月4日·1,058 字·3 分钟 [代码审查](https://xingkaixin.me/tags/%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5/)[AI编程](https://xingkaixin.me/tags/AI%E7%BC%96%E7%A8%8B/)[Claude Code](https://xingkaixin.me/tags/Claude%20Code/)[Codex](https://xingkaixin.me/tags/Codex/) ![AI 代码审查停不下来，先改掉那句“帮我找 bug”](https://xingkaixin.me/cover/ai-review-find-bug-prompt.webp) 3 月 28 日上午，我让 Codex 审一个自己写的 Python CLI，从 7:49 审到 10:18，一共 10 轮。每轮用的都是同一句 prompt：`review代码,模块拆分不合理,单体大文件,圈复杂度高`。 第 4 轮时我问它，为什么每轮都能找到新问题。它说每次重构都重新划了模块边界，新接缝会暴露旧问题。我当时接受了这个解释，后来写《我让 AI 审了自己的代码，审了 10 轮》也是这么写的。 10 月 15 日，Claude Code 团队在 claude.dev 博客上讲了他们怎么做代码审查。一个 CLI 的 PR 审了改、改了审，一夜跑了五十多轮，最后是作者叫停的。他们对 reviewer 反复标出的东西跑了 git blame，约 59% 落在 reviewer 第一次看时就已经在的代码上。他们的结论是 reviewer 很少找到新 bug，每轮都在旧代码里又多翻出几个。 我回去翻那 10 轮的记录。第 7 轮拆的 `config_store.py`，前 6 轮没碰过。第 8 轮发现三个 formatter 各写了一遍查询摘要，当时我在那篇里写的原因是前几轮只盯着大文件，没看跨文件的重复。这两处用“结构在演化”都解释不通：一个文件没人动过，一处重复是没往那儿看。 再看那句 prompt。“模块拆分不合理，单体大文件，圈复杂度高”，三个结论我先替它下了，它要做的只是把证据找出来。拆到第 9 轮，它报的是 `where`/`cond` 解析在 command 层和 service 层各写了一份。照这句 prompt 的标准，仓库里总能挑出一个比别处大一点、绕一点的地方。 systematicls 3 月发过一篇讲 agentic engineering 的长文，在讲 sycophancy（讨好用户）的那节里写：你说 “Find me a bug”，它就会给你找一个，哪怕得自己造。我那句 prompt 是同一种问法，只是把“bug”换成了“拆分不合理”。 PR 作者也是 agent 的话，麻烦更大。Claude Code 团队那篇写，人看到一条 nit 几秒就放过去，agent 会去改，改完多一个 commit，又触发一轮审查。我那 10 轮里改代码的也是 Codex。第 1 轮它为了兼容测试写了个时区钩子，第 2 轮拆文件时踩上去，210 个测试挂了 1 个，报 `RecursionError`，又得先修它。 Claude Code 团队后来给重审加了几条规则，我最想照搬的是第一条：审到第三轮，reviewer 停下来，请作者退一步重新考虑方案。另外几条是前几轮之后只看新 diff，同类问题一次标完，贴过的不再贴。 规则上线前后，内部 PR 平均审几次能通过，从 2.08 降到 1.32，要审五轮及以上的 PR 从 8.9% 降到 1.5%。这组数在文中一张图里，没给统计时间段和样本量，我只把它当方向看。文中写明的优先级是先抓真 bug，再减轮数，还会把 reviewer 放到已知没问题的 PR 上跑，数它有多少次会让人去做有害的修改。 我打算把派活那句换成 systematicls 给的中性写法：沿着每个组件的逻辑走一遍，报告所有发现。按那篇的说法，这样问出来的东西有时是 bug，有时只是一段代码怎么运行的说明。 Claude Code 团队还提到，写得好的 REVIEW.md 会要求总结先写数量，没东西可修就直说，每条问题给文件和行号做证据。我会在 prompt 末尾加一行：**第一行写发现了几个问题，没有就写 0，再逐条列出文件和行号。** ![审查需要结束条件](https://xingkaixin.me/posts/images/ai-review-find-bug-prompt/ai-review-find-bug-prompt-01.webp) 轮数我还没想清楚该卡在哪。他们定的是三轮，zhu327 在 Pi 上做 loop 时也规定单次循环最多 3 轮聚焦修复，超过就暂停报告。我打算先按三轮来，第三轮后把剩下的问题分成两堆：这几轮改动带出来的，和第一轮就在的。第一轮就在的那堆不再让它接着修，回去改 prompt 重审。 这套改法我还没拿那个 CLI 重跑过，10 轮能压到几轮，现在说不准。 ## 版权声明 作者 XingKaiXin 标题 AI 代码审查停不下来，先改掉那句“帮我找 bug” 发布时间 2026年11月4日 文章链接 [https://xingkaixin.me/posts/ai-review-find-bug-prompt/](https://xingkaixin.me/posts/ai-review-find-bug-prompt/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 XingKaiXin