四个没人审过的提交混进了合并队列：我的 Claude Code + Codex 双引擎规则是这样被逼出来的

作者发现自己项目里有四个从未被审查的测试提交，其中一个已经合并，由此把所有规则从'记在脑子里'改成写进脚本。文章给出 Claude Code 写码、Codex 只读审查、按 commit hash 存放 verdict 文件、本地测试门禁等一整套可照搬的流程，还附了模型分工的实测数据。

为什么一个引擎不能给自己的代码签字

• 写代码的那个会话最不适合判断改动是否完成，因为它天然认为自己已经做完了
• 分工：Claude Code 写代码，Codex 以只读沙箱身份审查；审查者选不同公司的模型，盲区不同
• 审查者必须只读——能自己动手修的审查者就是第二个作者，而没人审查这个作者
• 一次真实 PR 审查中 Codex 给出 2 个 blocker 和 8 个 should-fix，这套流程因此保留下来

第二个引擎抓到了什么

• CI 步骤把截图报错写进报告却不算失败，超时也能全绿通过
• 发布脚本的安全守卫只读一个 shell 变量，通过环境文件选目标就能绕过
• 媒体链接豁免规则跑在 scheme/host 检查之前，本地 dev server 和 ftp 链接混过了审计
• 新的严格校验在 API 响应一个坏字段上直接崩溃，中断了整个审计运行

verdict 变成文件：按 commit hash 命名

• 审查脚本把 Codex 结论存成以被审 commit 命名的文件，新 commit 没有结论就不能靠旧 ACCEPT 蒙混
• 只认审查者最终消息里的单行 Verdict:；退出码非 0、审查期间 checkout 变动、出现两行 Verdict 都视为无结论
• 开启 REQUIRE_REVIEW=1 后，合并脚本拒绝任何没有自己 ACCEPT 文件的提交

CI 账单把检查搬回本地

• 一个私有仓库前五天烧掉约 2100 分钟 GitHub Actions，而免费额度是每月 2000 分钟
• 本地门禁在 Codex 审查的同一 commit 上跑测试，且要求运行前后工作树都干净，否则不记录通过
• 合并脚本没有对应通过记录就拒绝推送，再用 GitHub 的 sha 参数合并，分支头变动会被拒绝
• 作者的 40-43 项检查串行要 35-40 分钟，拆成五条并行 lane 后约 11 分钟

一次对测改变了模型分工

• 10 月 12 日让两个引擎各跑三次 Tetris（44 个隐藏测试）：Claude Code（Opus 5.5, xhigh）与 Codex（GPT-6.1-Sol, xhigh）都三次 44/44
• 中位耗时 21:17 对 18:13，但 Opus 成本是 8.9 倍
• 分工原则按出错代价：边界清晰的实现给 Sonnet，搜索/提取/列表这类错误容易发现的给 Haiku，xhigh/max 留给设计重的切片、PR 首审和难调的 bug

这套流程防不住什么，以及怎么搬走

• 如果 Claude Code 在破坏代码的同一提交里顺手削弱测试，测试门禁会放行，只能靠审查者按'新测试必须在旧行为上失败'的规则去查
• 错误的 ACCEPT 和正确的看起来一样，所以 ACCEPT 只解锁 PR，合并仍由人手动执行
• 落地六步：两引擎共用一份规则文件（CLAUDE.md 用 @ 引入，脚本生成 AGENTS.md）；Claude Code 在独立 git worktree 里跑；Codex 只读沙箱且最终消息带单行 Verdict；verdict 按 commit hash 存文件；同一 commit 干净树上全量通过才记录；脚本缺文件就拒绝合并