让 Codex 审 Claude Code 的提交：合并前必查的 7 条清单

Claude Code 写代码、Codex 只读审查、再由一道 gate 决定能否合并，这套双引擎流程的关键不在提示词，而在几条硬性约束。作者把信任这个循环之前要确认的 7 个点列成清单，每条都能从 diff 或测试里验证。

审查端先锁成只读

• Codex 用 codex exec -s read-only --color never --output-last-message <file> - 运行，prompt 从 stdin 传入。
• 审查者可以读文件、跑 git diff，但不能写文件，也不能回传补丁，避免它顺手改代码。
• 结论只从 --output-last-message 指定的文件里读，不解析终端输出。

结论格式与保存位置

• 只认两种结论行：Verdict: ACCEPT 或 Verdict: CHANGES REQUIRED。
• 结论按 commit hash 存档，合并时校验的是这个具体 commit 有没有对应的 ACCEPT。
• 进程崩溃、输出为空、出现两行 Verdict，都视为没有结论，该 commit 不能合并。

先写验收标准，再写代码

• "Done means" 下面每一条都必须是审查者能从 diff 或测试中确认的事实。
• 写"带逗号的客户邮箱被正确转义"，不要写"导出功能正常"这类无法验证的描述。
• 模糊的验收标准会让审查退化成风格争论。

新测试必须在基线 commit 上失败

• 写代码的引擎往往也顺手写测试，自己测自己等于没测。
• 把新测试放到改动前的 commit 上跑，如果本来就通过，它证明不了这次改动。
• 测试通过只是必要条件，不能替代审查：同一 commit 里被削弱的测试，测试本身发现不了。

规则文件放在两个引擎都读得到的地方

• Claude Code 读 CLAUDE.md，Codex 读 AGENTS.md，项目规则两边都要有。
• AGENTS.md 部分要短：多个指令文件合计大小达到 project_doc_max_bytes（默认 32 KiB）后，Codex 就不再追加。
• 规则写太长会被截断，后面的约束等于没写。

逐条回应与轮次上限

• 审查者要对验收标准每一条给出答复：满足的附 file:line，不满足的说明缺什么，无法验证的说明需要什么证据。
• 超出验收范围的发现必须给出具体失败场景，个人风格偏好不算 finding。
• 审查轮次设硬上限，后续轮次只提阻塞合并的问题；最后一轮仍是 CHANGES REQUIRED，就锁住合并，交给人决定。