Appearance
跨模型工作流将 Claude Code 和 Codex CLI 在同一个代码库上协作：Claude Code Opus 在 Plan Mode 生成分阶段实现计划，Codex CLI 审查计划并插入补充阶段，Claude Code 按计划实现，Codex 最终验证。两个模型互为 QA，弥补各自的盲点。
跨模型工作流：Claude Code + Codex 协作的完整实践
为什么需要跨模型工作流
单一模型在大型功能开发中存在一个固有盲点：规划者和实现者是同一个模型，它不会质疑自己的计划，也不会从"陌生视角"发现遗漏的边界情况。
引入第二个独立模型（Codex CLI）作为 QA 审查员，可以：
- 用不同的训练数据和推理方式审视计划
- 发现原模型可能忽略的边界情况
- 在不与原计划冲突的前提下添加补充内容
四阶段工作流
┌──────────────────────────────────────────────────────────┐
│ CROSS-MODEL WORKFLOW │
│ Claude Code + Codex CLI │
├──────────────────────────────────────────────────────────┤
│ │
│ STEP 1: PLAN Claude Code │
│ 在 Plan Mode 中开启 Claude Code Opus 4.6 │
│ Claude 通过 AskUserQuestion 采访你 Plan Mode │
│ 生成带测试门控的分阶段计划 │
│ → 输出: plans/{feature-name}.md │
│ │
│ ▼ │
│ │
│ STEP 2: QA REVIEW Codex CLI │
│ 在第二个终端打开 Codex CLI GPT-5.4 │
│ Codex 对照真实代码库审查计划 │
│ 插入中间阶段（"Phase 2.5"） │
│ 标注为 "Codex Finding" │
│ 只添加，不改写原有阶段 │
│ → 输出: plans/{feature-name}.md（更新） │
│ │
│ ▼ │
│ │
│ STEP 3: IMPLEMENT Claude Code │
│ 新建 Claude Code 会话（终端 1） Opus 4.6 │
│ 按阶段实现，每个阶段通过测试门控 │
│ │
│ ▼ │
│ │
│ STEP 4: VERIFY Codex CLI │
│ 新建 Codex CLI 会话（终端 2） GPT-5.4 │
│ Codex 对照计划验证实现 │
│ │
└──────────────────────────────────────────────────────────┘各阶段详解
阶段 1：Plan（Claude Code + Opus + Plan Mode）
工具：Claude Code，切换到 Opus，启用 Plan Mode
操作：
Shift+Tab切换到 Plan Mode（或--permission-mode plan）- 描述你要实现的功能，Claude 会主动提问澄清需求
- Claude 生成带测试门控的分阶段实现计划
输出格式：plans/{feature-name}.md，包含：
- 每个阶段的目标和完成标准
- 每个阶段结束后的测试门控
- 风险和注意事项
阶段 2：QA Review（Codex CLI + GPT-5.4）
工具：Codex CLI（codex），在独立终端中打开
关键行为：
- Codex 读取计划文件，并扫描实际代码库
- 发现潜在问题时，插入 "Phase X.5" 中间阶段
- 用 "Codex Finding" 标题标注所有补充内容
- 原则：只添加，不改写原有阶段（保留 Claude 的规划意图）
这一步利用 Codex 对代码库的独立扫描，捕捉 Claude 在规划时可能忽略的：
- 依赖关系和副作用
- 已有代码中的冲突
- 缺失的迁移或数据处理步骤
阶段 3：Implement（Claude Code + Opus）
工具：新建 Claude Code 会话
操作：
- 切换回 default 或 acceptEdits 模式
- 按更新后的计划逐阶段实现
- 每个阶段完成后运行测试门控，通过后再继续下一阶段
阶段 4：Verify（Codex CLI）
工具：新建 Codex CLI 会话
操作：提供计划文件和已完成的代码，让 Codex 验证：
- 实现是否覆盖了计划的所有要点
- 测试是否通过
- 是否有遗漏的边界情况
为什么这个工作流有效
规划者 ≠ 验证者：Claude 规划后由 Codex 审查，Codex 审查后由 Claude 实现，Claude 实现后由 Codex 验证。两个模型互为对方的盲点审视员。
Plan Mode 的价值：Claude Code 的 Plan Mode 强制只读模式，Claude 不能执行任何操作，只能探索和规划。这确保规划阶段的思考深度，而不是立即开始写代码。
测试门控：每个阶段结束都有明确的测试通过标准，防止"建立在失败基础上的实现"——如果阶段 2 的测试没通过就开始阶段 3，最终的错误会更难诊断。
实践注意事项
不需要总是用四阶段：对于小功能，直接 Claude Code 实现就够了。这个工作流针对的是：复杂的、影响面大的、有多个依赖的功能。
模型选择：规划阶段用 Opus（最深推理），实现阶段根据任务复杂度选 Sonnet 或 Opus。Codex 的 GPT-5.4 提供不同厂商的独立视角。
终端组织：两个终端（Terminal 1 = Claude Code，Terminal 2 = Codex CLI）在同一代码库下工作，通过计划文件传递信息。
FAQ
Q: 这个工作流对所有功能都值得用吗？ A: 不是。对于简单的 bug 修复或小型功能，这四个阶段的开销大于收益。推荐用于：影响多个模块的大功能、有数据迁移需求的修改、团队协作的关键路径功能。
Q: 如果没有 Codex CLI，可以用别的工具替代 QA 阶段吗？ A: 可以用任何其他能读代码库的 AI 工具（如 Cursor、GitHub Copilot Chat）来做 QA 审查，核心是"第二个独立的眼睛"。即使用同一个 Claude，在新会话中作为审查者（而非规划者）也比完全不审查好。
Q: Codex 的 "只添加，不改写" 原则怎么强制执行？ A: 这是在给 Codex 的提示词中明确的约束。提示词示例："审查这个计划文件，如果发现问题，插入 Phase X.5 标注 Codex Finding，不要修改原有阶段内容。"