Codex与Claude Code双AI协作：一写一审的工程化实践

当我们同时拥有 OpenAI Codex CLI 和 Claude Code 两个 AI 编程工具时，最大的诱惑是让它们同时写代码，但这恰恰是最危险的做法。本文将系统介绍一套经过实践验证的双工具协作方法论——一写一审模式，让两个 AI 像真正的工程团队一样高效分工。

核心理念：两个不同风格的AI工程师

把 Codex 和 Claude Code 看作两个风格迥异的工程师：Codex 擅长快速实现和验证，它是本地终端 Coding Agent，能读、改、运行代码，还有 Web Search 功能；Claude Code 擅长架构分析和审查，拥有强大的长上下文探索能力，适合理解复杂代码库。

这两个工具的互补性源于底层技术的根本差异。OpenAI Codex CLI 基于 codex-1 模型——一个经过强化学习专门优化代码任务的 o4-mini 变体，能够在本地沙箱环境中读取、修改和执行代码，并支持联网搜索，侧重于快速迭代和工具调用。Claude Code 则基于 Anthropic 的 Claude Sonnet/Opus 系列模型，以超长上下文窗口（最高支持 200K token）著称，能够一次性理解大型代码库的全貌，侧重于深度推理和长文本理解。正是这种模型架构和训练策略上的显著差异，构成了双工具协作的技术基础。

最核心的原则只有一条：永远不要让它们同时修改同一个工作区。协作的桥梁不是对话，而是 Git Diff、任务文档和检查脚本。

典型的错误做法

很多人会让 Claude Code 改到一半，又让 Codex 去改同一批文件。结果两个 AI 互相覆盖，修改越来越偏离目标，最终难以恢复。这种"双写"模式是协作的大忌。

正确的协同流程

正确的流程是一个清晰的接力赛：

Claude Code 只读分析，输出方案到文档，不修改任何文件
你确认或微调目标和方案
Codex 实现最小可行修改，运行 Build 和 Test
Claude Code 审查 Git Diff，找出边界条件、隐藏 Bug
Codex 根据审查意见修复
你做最终判断和合并

这里值得注意的是，第 4 步中 Git Diff 作为协作桥梁的选择并非偶然。Git Diff 以统一差异格式（Unified Diff Format）精确记录每一行的增删改，在传统软件工程中，Code Review 的核心载体就是 Diff——审查者不需要阅读整个代码库，只需关注变更部分及其上下文。相比让两个 AI 通过自然语言对话传递信息，Diff 是结构化的、精确的、可回溯的，完全消除了自然语言的歧义性。

这种"一写一审"的价值远大于两个工具都写代码。因为 AI 写代码最容易出现的问题不是写不出来，而是越改越偏。引入反向审查机制，能让代码保持在可控轨道上。

项目结构：文件化一切协作信息

要实现高效协同，需要在每个项目里建立统一的任务目录结构：

project/
├── AGENTS.md          # Codex 启动时读取的项目规范
├── CLAUDE.md          # Claude Code 启动时读取的项目规范
├── scripts/
│   └── check.sh       # 统一验证脚本（安全带）
└── .ai/
    ├── brief.md       # 任务目标
    ├── plan.md        # 设计方案
    ├── review.md      # 审查意见
    ├── backlog.md     # 待处理问题积累
    └── decision-log.md # 决策原因记录

其中 AGENTS.md 和 CLAUDE.md 的设计值得深入理解。AGENTS.md 是 Codex CLI 的项目级指令文件，Codex 在启动时会自动读取项目根目录下的该文件，将其内容作为系统级上下文注入对话。CLAUDE.md 是 Claude Code 的等效配置文件（也称为 CLAUDE.md memory），Claude Code 启动时同样会自动加载。这两个文件的设计灵感来源于 .editorconfig、.eslintrc 等开发者工具的约定优于配置（Convention over Configuration）理念——通过在项目根目录放置声明式文件，让工具自动获取项目规范，无需每次手动重复说明。在双工具协作场景中，可以分别针对各自工具的特性定制指令，例如在 AGENTS.md 中强调"每次修改后必须运行 scripts/check.sh"，在 CLAUDE.md 中强调"仅做只读分析，不修改任何文件"。

这样设计的关键意义在于：所有协作信息都文件化，不再依赖对话记忆。当你把任务从 Claude Code 切到 Codex 时，Codex 只要读 plan.md 就知道该做什么，彻底告别"我刚才跟另一个 AI 说过"这种不可靠的依赖。

项目结构与流水线设计

check.sh：防止AI跑偏的安全绳

scripts/check.sh 是整个协作流程中重中之重的存在。Claude Code 官方文档明确指出：如果不给 Agent 一个能运行的验证命令，它就只能在"看起来完成了"的时候停下来，而这时很可能还有问题。

这一设计背后蕴含着持续集成（Continuous Integration, CI）的核心思想。传统 CI 系统（如 Jenkins、GitHub Actions）在代码推送后自动触发构建、运行测试套件、执行静态分析，确保每次变更不会破坏已有功能。check.sh 本质上是将 CI 的验证环节前置到了 AI 编码过程中——不是等代码推送到远端才发现问题，而是让 AI 在本地每次修改后立即验证。这种"改代码→跑检查→看结果→修问题→再跑检查"的闭环，在 CI/CD 领域被称为快速反馈循环（Fast Feedback Loop），是提高代码质量的关键机制。

不同类型的项目，check.sh 的内容不同但思路一致：

嵌入式 C/C++ 项目：CMake 构建 + CTest 测试，确保编译和功能正常
Python 项目：pytest 单元测试 + ruff 代码风格 + mypy 类型检查
前端项目：pnpm lint + test + build

统一检查脚本示例

无论哪个工具在操作，改完后都跑同一个脚本，验证标准完全一致。这相当于给 AI 绑了安全绳——它必须通过你的质量检查才能继续，不能靠"看起来完成了"蒙混过关。

四条硬规则：双AI协作的底线

从各种实践场景中，可以总结出四条必须遵守的硬规则：

规则一：单一写权限

任何时候，只能给一个工具修改文件的权限。没有写权限的工具可以做只读分析、审查 Diff、输出建议，但绝对禁止写操作。违反这条规则的后果很直接：两个 AI 会互相打架，一个刚写好的代码马上被另一个覆盖。

规则二：文件驱动而非对话驱动

所有协作必须通过 .ai/ 目录下的文件和 Git 来传递，不要指望你对 Claude Code 说的话 Codex 能知道——它们没有共享记忆。以文件内容为唯一协作依据。这一点在技术上很好理解：Codex CLI 和 Claude Code 运行在完全独立的进程中，各自维护独立的对话上下文，没有任何进程间通信机制。文件系统和 Git 仓库是它们唯一的共享状态空间。

规则三：单一职责提示

每次只让 AI 集中在一个角色上。如果你说"帮我分析、设计、实现、测试、优化一下这个项目"，AI 很容易迷失方向。正确的做法是给出明确的单一职责提示，比如"只做架构分析，不要修改文件"，或者"只修复 P0 和 P1 问题，P2 不要碰"。

这条规则的理论根基是计算机科学中最重要的设计原则之一——关注点分离（Separation of Concerns, SoC），由 Edsger Dijkstra 在 1974 年提出。其核心思想是将复杂系统分解为多个独立部分，每个部分只负责一个明确的职责，部分之间通过定义良好的接口通信。在本文的协作模型中：Claude Code 只负责分析和审查（不写代码），Codex 只负责实现和验证（不做架构决策），人类只负责最终判断和合并。这种分离不仅降低了每个角色的认知负荷，更重要的是建立了制衡机制——写代码的 AI 不能自己审查自己，审查的 AI 不能绕过审查直接修改，这与现代软件工程中"提交者不能批准自己的 PR"的规则一脉相承。

规则文件配置示例

规则四：统一验证入口

每次代码改动后，必须运行 scripts/check.sh，不要让 AI 自己决定跑什么命令。这让 AI 进入一个闭环：改代码→跑检查→看结果→修问题→再跑检查。这正是持续集成的精髓。

实战场景：嵌入式Debug的三角色法

AI Debug 时最常见的问题是"越改越糟"。一个非常有效的解决方案是把任务拆成三个角色：

Claude Code 担任诊断医生：只读代码，定位 Bug 根因，把分析写入文档，坚决不改文件
Codex 扮演外科医生：只做精准修复，最小改动，绝不顺手重构
Claude Code 回来复查：审查 Diff，找出潜在风险

这里有一条铁律：坚决不要在修复一个 Bug 时顺手重构其他代码。一旦打开这个口子，改动范围就会超出审查能力，很容易引入新坑。这在软件工程中被称为"散弹枪手术"（Shotgun Surgery）的反模式——一次变更涉及过多不相关的修改点，导致变更的影响面难以评估和测试。如果发现额外问题，记录到 .ai/backlog.md，留给下一次专门解决。

高级技巧：Git Worktree实现真正并行

如果任务特别复杂，可以用 Git Worktree 实现两个工具的真正并行工作：

git worktree add ../proj-claude  # Claude Code 专用：分析和设计
git worktree add ../proj-codex   # Codex 专用：实现和测试

Git Worktree 是 Git 2.5 版本引入的一项功能，允许从同一个仓库检出多个工作目录，每个工作目录对应不同的分支，但共享同一个 .git 对象数据库。与传统的 git clone 多份副本不同，Worktree 不会复制整个仓库历史，磁盘占用极小且分支状态实时同步。在双 AI 协作场景中，Worktree 的价值在于提供了物理隔离的工作空间：两个 AI 工具分别在不同的目录中操作，即使同时运行也不会产生文件系统级别的冲突。

Git Worktree 并行工作

两个工具在完全独立的目录下运行，不用担心文件冲突。完成后通过 git diff 查看变更，用 cherry-pick 挑选提交或直接 merge 合入主线。整个过程完全在版本控制的管理之下，每一步变更都有迹可循。