AI 审查反复冒出问题，如何设定收尾规则

Codex 每审一轮就冒出新问题，不一定是上一轮白审了。修复会改变 diff，单轮审查也未必找全所有问题；有些后来出现的发现，其实第一轮就已经存在。

原文的核心判断是：要让「修改、复审、再修改」收敛，不能只靠模型更认真，还要约定审查门槛、完成条件、触发时机和停止规则。对正在用 AI 写代码、审 PR 的程序员，这比继续追加一句「再仔细检查」更有用。文中产品信息截至 2026 年 10 月 21 日。

每轮冒出的新问题，究竟从哪里来

第一种来源很直接：代码变了。

Codex 的 /review 可以审基础分支差异、未提交修改或某次提交。修复之后，下一轮读到的 diff 已经包含新增改动。它的审查规则要求问题由本次提交引入，因此修复代码也进入了审查范围。改对原来的问题，并不保证没有引入另一个问题。

第二种来源是漏检，以及单轮报告的筛选门槛。

Codex 的审查提示同时要求：输出作者知道后会修复的问题；没有明确值得修的问题就不输出；不要找到第一个合格问题就停止。这些要求强调发现的价值，却不能保证一次列全。

2026 年 1 月 7 日，openai/codex 的 issue #4710 关闭评论称，/review 被设计为每轮只报告少量 bug。但上述提示当时已经存在，两者不能解释成先后两版规则。作者也没有在相关文档中找到固定数量上限；允许配置问题数量的请求 #5547，截至 10 月 21 日仍处于开放状态。GitHub 场景还有「只报告 P0、P1」这样的严重程度门槛。

因此，不能从一次只报几条，推导出剩余代码已经没有问题。

第三种来源最容易让人误判：问题后来才被发现，代码却早就在。

Anthropic 的 Claude Code 团队在 2026 年 10 月 15 日披露，一个 CLI PR 曾在一夜间经历超过 50 轮审查和修复，最后由作者叫停。他们用 git blame 追查持续被标记的代码，约 59% 从第一轮审查时就已经存在。

「新发现」和「新引入」是两回事。

不过，59% 来自 Claude Code 团队对自家审查器、自家代码的分析。原文没有找到 Codex 的同类测量，不能直接把这个比例套过去。

开一个独立审查会话，为什么还不够

把代码生成和代码审查分开，是有意义的。CodeRabbit 给出的理由是，审查者应该提供不同于代码作者的视角。

Codex 也提供了几种分离方式：CLI 启动专门的 reviewer；应用中的 Review with Codex 按钮可在新聊天中启动审查；IDE 设置 chatgpt.reviewDelivery 为 detached 会打开独立审查聊天；review_model 可以为审查指定模型。

但视角分开之后，还有另一个问题：下一轮如何处理上一轮的发现？

CLI 的审查结果会作为一轮消息保留在 transcript 中，应用和 IDE 也有当前聊天内的审查路径。记录还在，并不能证明下一轮一定会逐条核对、去重和关闭。作者在 Codex 相关文档中没有找到明确的历史问题处理机制或停止规则，找到的是「根据反馈修复，再运行 /review 确认」这条循环。

其他产品把这部分写得更具体。Claude Code Review 会在判定修复后关闭旧线程，后续自动审查关注上次以来的变化，但 @claude review 会重新覆盖整个 PR。

Copilot 在 2026 年 9 月 11 日公布复审时自动解决已修复评论的能力；9 月 18 日又加入「Previously missed」，区分已有改动里后来才发现的问题。不过，其文档仍提醒，手动解决或点踩过的评论可能再次出现。

作者公司的封闭测试产品 Sigma 也区分两条路径：Automatic reviewer 在推送后先完整审查新 head，再复查此前未关闭及暂缓处理的发现；On request reviewer 不会因推送启动完整审查，也就没有后续跟进。它运行于 Claude Code 和 OpenAI 模型之上，但原文未提供与其他产品的效果对照。

这些差异说明，审查质量还取决于产品如何保存和处理历史状态。单独换个聊天窗口，解决不了全部问题。

想让审查停下来，需要提前写好四件事

第一件事是审查门槛。

Codex 在 GitHub 中读取 AGENTS.md 的 ## Code Review Rules。OpenAI 建议缩小或删除产生噪声的指导。Claude Code Review 读取 REVIEW.md，其中可以约定最多报告 5 条细枝末节的问题；Copilot 使用 .github/copilot-instructions.md 等自定义指令，Bugbot 读取 .cursor/BUGBOT.md，CodeRabbit 也支持审查指令。

这里要约定的是哪些问题值得打断交付。Anthropic 的 /code-review 另有 --max-findings，可以指定报告数量或报告全部发现，但它只是控制输出数量，不能证明审查覆盖完整。

第二件事是完成条件。

「修好了」需要能验证。原行为是否改变，原 bug 是否还会复现，相关测试是否通过，都比审查器这一轮没有意见更明确。尤其当新问题落在修复代码里，优先补齐验收条件，往往比继续催模型检查更有针对性。

第三件事是运行时机。

Codex 在 GitHub 有 Review trigger，Copilot 有 Review new pushes，CodeRabbit 有审查 5 次提交后暂停的机制，Bugbot 提供 oncePerPr。Claude Code Review 有三种模式，其中 After every push 会随每次推送运行，成本也随推送次数增加。

小步提交有利于开发，并不代表每次提交都需要完整 AI 审查。

第四件事是停止规则。

Claude Code 团队给出的内部做法包括：经过 3 轮后要求作者退一步重新考虑方案；前几轮之后只复审 diff；指出一类 bug，让作者修复所有实例；不重复报告已发布的发现。

调整后，其内部 PR 在一轮审查和修复后通过的比例，从 65% 升至 78%。这是他们组合采用多项改动后的内部结果，原文没有提供足够信息来拆分各项措施的贡献。

另外两个相近机制要分清：Codex Security 的深度扫描用 stop_after_no_new 控制连续多少次完成扫描无新发现后停止，它属于另一个产品；Bugbot Autofix 向已有分支提交时，每个 PR 最多尝试 3 次。都不能当作 Codex /review 已有的停止配置。

我的判断

我认可原文先分类、再调整流程的思路。同样是复审又报错，原因可能是修复引入风险，也可能是旧问题漏检。前者需要更清楚的验收和测试，后者需要控制范围、归并同类问题。处理方向不同。

和反复要求模型「全面检查」相比，书面门槛与停止条件更容易执行，也更方便团队解释为什么接受或拒绝一条建议。但缩小范围也有代价：只看新增 diff，可能遗漏跨文件影响；设定轮次上限，也不会让尚未解决的严重问题自动消失。

停止规则约束的是循环，验收条件决定的是能否交付。

原文没有给出 Codex 多轮审查的对照实验，也没有证明换审查模型优于换规则。59% 和 65% 到 78% 可以作为调查线索，不能作为一般团队的效果承诺。作者同时经营 Sigma，文中的产品机制可以参考，效果判断仍需独立验证。

能拿来做什么

• 在同一份 diff 上连续运行两次 /review，中间不改代码。第二次新增的发现至少可以排除「由两轮之间的修复引入」这一来源，再检查它是否确实成立。
• 给每轮新增发现标注来源：修复改动涉及的代码、首轮已存在的代码、diff 之外的代码。结合 git blame 和实际改动核对，并记录多少轮才得到一次无发现的结果。
• 在 GitHub 使用 Codex 时，把团队认可的审查范围写进 AGENTS.md 的 ## Code Review Rules；给修复任务同时写明复现步骤和通过条件，让 Node 接口或前端交互的行为有据可验。
• 为连续复审约定轮次上限和升级处理方式。达到上限后，集中检查剩余问题及整体方案；遇到同类缺陷，要求一次检查所有实例，减少逐行修补带来的重复循环。