Claude 写代码、Codex 审查的协作方案

同时用 Claude Code 和 Codex，难点不只是给谁分配任务，还包括规则如何同步、审查是否对应最新提交、测试通过后代码有没有变化。Two Engines Kit 把这些问题收进了一套脚本：作者让 Claude Code 写代码、Codex 审查，再用绑定提交的记录控制推送和合并。

这套方案值得看的地方，是它把「已经检查过」变成了可核验的凭据。不过，文中的费用、速度和清理数据都来自作者自己的项目，适合拿来设计流程，不能直接当作团队收益承诺。

双模型怎么分工，才不会只增加开销

作者的流程里，Claude Code 的编排会话负责规划、写任务说明、启动独立 git worktree 中的 worker、检查差异、运行本地检查并合并。worker 不负责推送。每个准备好的 PR，再交给只读沙箱里的 Codex 审查，并要求它给出明确结论。

选择另一家公司的模型，是作者希望利用不同的盲区。某次 Codex 首轮审查发现了 2 个阻塞问题和 8 个建议修复项，但作者也承认，这只是一个样本，并不能证明跨模型审查一定更好。

模型分配则参考了一个小实验：10 月 12 日，作者让两个引擎完成同一个俄罗斯方块任务，对照 44 个隐藏测试，各运行三次。在 Claude Code 的 high effort 下，Opus 5.5 和 Sonnet 5.5 每次都通过 44/44，Haiku 5.5 三次通过两次；费用中位数分别为 $1.61、$0.72、$0.19。

原文还给出「同分，Opus 贵 8.9 倍」的结论，但没有列全跨引擎的对照明细。这个倍数不能从上面三个费用直接算出，不宜混用。

作者据此按出错成本分配任务：边界明确的实现交给 Sonnet，搜索、提取和列举交给 Haiku；设计较重的任务、PR 首轮审查和困难调试使用 xhigh 或 max effort。路由写在 config/efforts.md，模型名都是可编辑的纯文本。

规则共用还不够，审查必须认准提交

两份规则文件最容易出现的问题，是修改只同步了一边。Kit 把源文件集中到 rules/RULES.md：Claude Code 通过 ~/.claude/CLAUDE.md 的 @ 导入读取，Codex 则由 sync.sh 生成 ~/.codex/AGENTS.md。

规则冲突时，优先级是当前用户消息、项目规则、全局规则、记忆笔记。安装器还会关闭 Claude Code 的提交和 PR 署名，并把 Codex 的 project_doc_max_bytes 提高到 64 KiB，避免较长的 AGENTS.md 尾部被截断。这些是作者的配置选择，不是所有团队都该照搬的默认值。

更关键的是审查凭据。cross-review.sh 会拒绝存在未提交或未跟踪文件的工作区；只有 Codex 退出码为 0、检查期间工作区未变，而且最终消息恰好包含一行 Verdict:，才写入以被审查提交命名的结论文件。崩溃、回答被截断或检出状态变化，都会以退出码 1 结束，不生成凭据。

审查通过应该属于某个确定的提交，而不是属于整个分支。

作者是在发现四个仅含测试改动的提交漏审后补上这层控制的：其中一个已经合并，三个还在队列。设置 REQUIRE_REVIEW=1 后，merge-pr.sh 会拒绝没有对应提交 ACCEPT 文件的合并。

本地检查省下什么，又增加了什么责任

作者的一个私有仓库在启用托管 CI 的前五天，就消耗了约 2,100 分钟 GitHub Actions 配额，超过每月 2,000 分钟的免费额度。此后，他们改为本地检查全部通过后再推送。

workflow/bin/local-ci.example.sh 是待填入项目测试命令的骨架：用整机锁避免两个检查流程争抢 CPU 和端口，清理环境以避免残留 .env 干扰，在干净工作树上完整通过后，写入按提交命名的通过记录。

merge-pr.sh 推送前检查记录是否对应当前提交和 tree，推送后调用 GitHub 合并接口时传入 sha 参数，防止分支头在中间发生变化。DRY_RUN=1 会执行本地检查，只打印推送和 API 调用，方便先验证流程。

作者自己的检查共 40 至 43 项，串行需要 35 至 40 分钟，拆成五条并行通道后约 11 分钟。但 Kit 提供的骨架没有这些并行通道，安装不会自动复现这个速度。

资源管理也被写进规则：最多同时运行三个 agent，审查会话和 worker 启动的 helper 都计入。作者曾看到列表显示三个、实际运行四个，因此后来直接禁止 worker 启动 helper。

清理同样有现实成本。10 月 7 日清掉了 29 个已合并 worktree，占 24 GB，另有 31.2 GB Docker 构建缓存；10 月 17 日又清掉 69 个 worktree 和 88 个已合并分支，磁盘占用从 184 GB 降至 76 GB。

可选记忆模块则依赖用户自备 MCP memory server。Stop hook 会在做了实际工作却未存笔记的回合提醒一次；每周由一个 Claude Code 会话提出修正，另一个对照原笔记核验。9 月 22 日首次运行提出 9 项、应用 8 项、驳回 1 项，召回测试前后都是 18/18。这能说明审核拦下了一项修正，不能说明记忆效果已经提升。

我的判断

我更认可它对流程状态的约束：审查认提交，测试认提交和 tree，合并再检查 sha。相比人工记住「这个 PR 看过了」，它能明确拦住检查后又改代码的情况。

但双模型效果、任务路由和费用结论仍属于作者的小样本经验。原文没有提供与单模型审查、人工审查或其他路由策略的系统对照。俄罗斯方块的测试成绩，也不足以推导复杂前端项目的完成质量。

本地检查能控制托管 CI 用量，却把机器环境维护交给了使用者。清理环境变量只是其中一环，依赖、系统和运行时差异仍要项目自己处理。

兼容性也要看清：要求 bash 4+、python3 3.9+、git，以及已登录的 Claude Code 和 Codex CLI；只有合并及串联脚本需要 gh。作者实测的是 WSL2 上的 Ubuntu 24.04，Linux、macOS 属于设计支持但未测试，原生 Windows 不支持。

能拿来做什么

• 先用免费、MIT 许可的 two-engines-gate 验证流程，运行 bash demo.sh 看替身审查器如何完成一轮检查。先确认团队需要的是哪些约束，再考虑付费 Kit v1.0.2 的共享规则、hooks、记忆和完整脚本。
• 给日常 AI 编程建立明确分工，把边界清楚、验收方便的实现交给成本较低的模型，把高成本错误集中到设计和审查环节；用自己项目的结果调整 config/efforts.md，不要照抄模型排名。
• 将前端或 Node 项目的现有测试命令填入本地检查骨架，先用 DRY_RUN=1 核对执行结果，并验证追加提交后旧审查和旧测试记录确实失效。
• 采用安装器前核对现有规则的加载结果。bash install.sh 会逐步预览并询问 y/N，保留原规则生效，为新建或替换文件建立私有备份；uninstall.sh 可按字节恢复。没有自备记忆服务器时，安装器会跳过记忆模块。