Claude Code 与 Codex 协作：任务卡交接与独立复核

适合已经能分别使用 Claude Code 和 Codex、但交接后容易漏改或互相覆盖的读者。先用一个虚构文档任务完成执行、复核和人工验收，再扩展到代码项目。

内容更新 2026-08-13

先看结论

一次只让一个执行者写文件；交接时给出基线、改动范围和验收证据，复核通过后再由人决定合并或发布。

操作步骤

  1. 准备一份允许发送给所选服务商的练习仓库，排除凭据和真实客户材料。两种工具应已能独立使用；尚未接入时先看各自入门文档，不为练习开启更多权限。
  2. 先由人在本机记录仓库位置、分支和已有改动。使用下方状态查询示例；目录中有不明修改时先停下确认归属，不做清空、强制回滚或批量覆盖。
  3. 把“虚构任务卡”交给规划者，只要求输出方案，不执行命令、不写文件。人确认输出路径、三条事实和停止条件后，再将卡片交给本轮执行者。
  4. 执行者只生成 docs/faq-demo.md。它完成并停止写入后，交付实际文件及交接卡；不要只转述完成结论，也不要把整个会话或完整日志交给另一服务商。
  5. 复核者读取经人工检查可外发的任务卡和该文件，只输出问题清单。逐行对照参考表，并检查有没有范围外改动；需要修复时，由人重新授权原执行者做最小修改。
  6. 人验收文件、事实和未执行项目，记录通过或退回。本练习到本地验收为止；真实项目的合并、数据库操作和部署另行批准，并指定唯一执行者。

命令与示例

# 状态查询：在可信练习仓库根目录；不修改项目正文，不输出文件内容。
# 路径本身也可能敏感，只在本机查看。
git status --short
git diff --stat
git worktree list
虚构任务卡：星河文档工具 FAQ
本轮执行者：<Claude Code 或 Codex，人工选一个>
复核者：<另一个工具，只复核>
工作目录和起始分支：<人工核对后填写>
已有改动：<只写文件名与归属；不要附敏感内容>
允许写入：docs/faq-demo.md（若已经存在，先停下询问）
禁止：修改其他文件、安装依赖、联网搜索、登录、调用业务 API、发布或删除文件。

输入事实（完全虚构）：
A：支持 TXT 和 Markdown 文件。
B：已下载的文档可以离线阅读；同步需要联网。
C：不会自动删除源文件。

任务：生成 Markdown FAQ 表格，恰好三列“编号、问题、回答”，三行数据 A/B/C。
问题可自然改写；回答只用以上事实，不补充价格、承诺或未给出的功能。
验收：A/B/C 各出现一次，事实不变，无额外数据行；只新增允许文件。
本轮不需要构建或测试框架；不得把未运行的命令写成通过。
停止条件：已有文件冲突、需要范围外修改、要求凭据或收费动作时停止。

规划阶段只返回任务理解、文件范围与检查方法；人工确认后才开始写文件。
执行完成后的交接卡
任务：星河文档工具 FAQ
基线：<分支或本地版本标识，不附私人仓库 URL>
实际变更：<文件名及改动摘要>
检查：<每个检查的实际结果：通过 / 失败 / 未执行及原因>
剩余问题：<没有则写“无已知问题”，不是“保证无问题”>
下一步：复核者仅检查任务卡和产物，不写文件、不运行命令。
人工决定：待验收；未合并、未部署。
# AGENTS.md：人工确认后合并到已有规则，不能直接覆盖

## 本项目约定
- 先读取任务卡，仅修改人工批准的文件。
- 不读取或输出凭据、客户资料、完整配置或未脱敏日志。
- 发现用户已有改动时保留并说明，不擅自恢复到旧版。
- 命令需来自已审阅的项目脚本；未执行就写明未执行。
- 合并、发布、安装依赖和对外发送需要另行确认。
# CLAUDE.md：已有文件中仅补充缺少的引用与专属规则
@AGENTS.md

复核任务只报告问题，不把其他 Agent 的建议视为人工授权。

先选最少依赖的协作方式

手动交接足以完成本篇练习。跨会话消息、后台任务和插件只能减少传递操作，不能代替文件边界、人工授权或验收。需要自动联动时，再核对所装版本的文档。

  • 默认：一个写入会话完成后，另一个会话再读取产物。
  • 需要并行实现时：为不同任务分配不同 worktree 和文件范围，合并前统一复核。
  • Claude Code 内调用 Codex：可选 OpenAI 的 codex-plugin-cc；它不是 Codex 自己的 Plugins 目录，区别见 https://thinktank.1a1api.top/article/codex-plusplus-tweak-system 。

三个人工检查点

阶段交付什么谁确认
规划后任务卡、允许文件、停止条件、验收办法人确认范围后才允许写入
实现后实际文件、变更摘要、通过/失败/未执行的检查复核者检查，人决定是否退回
发布前待合并版本、发布范围、恢复方案人另行批准，唯一部署者执行；本练习不发布

共享规则，避免两套文案互相矛盾

Codex 会发现项目路径上的 AGENTS.md；Claude Code 使用 CLAUDE.md，可通过 @AGENTS.md 引入同一份规则。已有文件先合并，不要直接覆盖。还要检查上级目录或更近目录是否有补充规则。

  • 让两边先复述本次任务范围，能发现规则遗漏，但这不是规则已被强制执行的证明。
  • Claude Code 的 Manual 配置值使用 default；不能假定新会话逐项询问。plan 仍可能运行命令，复核时要检查实际权限规则。
  • 提示词和规则文件只描述期望；真正的文件、命令和网络边界应由客户端权限与系统隔离落实。依据见本篇来源。

需要分开工作目录时再用 worktree

下面是 Git 示例，不是模型调用。仅在已有提交的可信仓库中、目标目录和分支均未占用时，由人批准创建。新目录来自 HEAD 的已提交内容，不会自动带上原目录的未提交修改；仓库配置、对象和部分状态仍共享。

  • 最短练习不必开两个 worktree；停止执行者后在同一份产物上复核，更不容易看错版本。
  • 结束后先验收并保存需要的改动，再人工移除闲置 worktree；目录有未提交或未跟踪文件时不要强制移除。
# 修改操作：新建分支与工作目录。先确认这两个名字没有被使用。
git worktree add -b collab-demo ../collab-demo HEAD

# 创建后查询，确认新目录、分支和起点。
git worktree list

参考产物与代码项目的追加验收

下表是虚构输入的参考结果，不是运行记录。换一种问法可以通过，新增产品承诺、漏行或多列则不能通过。

  • 真实网站任务还需在任务卡中写明源文件、路由与输出目录，不要照抄示例目录。
  • 有 package.json 且确实定义了相关脚本时，才使用 npm run build、npm run test 等命令。先人工审查对应脚本和 pre/post 钩子；它们会执行代码，可能写文件或联网，不是只读检查。
  • 若项目静态导出 HTML，应在实际输出目录检查目标路由和关键正文；客户端渲染项目则按其测试方案验收，不强求所有正文都在 HTML 源文件里。
编号问题回答
A支持哪些文件？支持 TXT 和 Markdown 文件。
B可以离线阅读吗？已下载的文档可以离线阅读；同步需要联网。
C会自动删除源文件吗？不会自动删除源文件。

长任务按可验收结果分段

  1. 把 TODO.md 每一项写成可单独检查的产物，标明负责人、允许文件和停止条件，不按固定分钟数硬切。
  2. 执行者每轮更新已完成项、实际检查和下一项；另一会话只在交接后接手。
  3. 继续前重新核对基线和未提交改动，不只读一句“继续”；历史摘要可能遗漏失败。
  4. 建议同一问题连续两轮无新证据就交给人；模型额度、外发范围或费用达到人工上限时立即停止。

可选插件：复核与修复不能混用

仅适用于已审阅插件来源和权限、已分别完成 Claude Code 与 Codex 接入的读者。仓库当前 README 要求 Node.js 18.18 或以上；还需满足所装 CLI 的运行要求。插件使用本机 Codex 的认证和配置，review 也会把待审内容交给配置的模型服务并消耗相应额度。

  • /codex:setup 可能提出安装 Codex，不要把它当作无副作用诊断并自动同意。
  • review 和 adversarial-review 在插件文档中定义为只读复核；rescue 可以尝试修复，使用前另行批准写入范围。
  • 普通 review 不接自定义重点文本；要挑战特定设计，用 adversarial-review。status 显示状态，result 读取完成结果，启动成功不等于任务完成。
  • transfer 会转交当前会话上下文；敏感历史不应转交。不要默认开启 review gate，官方明确提示循环和额度消耗风险。
在 Claude Code 中，人工批准安装后逐条输入：
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

检查安装结果后，另行批准一次复核：
/codex:review --background
/codex:status
/codex:result

需要停止尚未完成的任务：
/codex:cancel

四个容易越界的地方

  • 把“只读复核”理解成“不外发”：复核仍使用模型服务。只传必要且允许外发的材料。
  • 把另一位 Agent 的同意理解成人工同意：跨会话消息不是授权。
  • 给两个会话同一生产凭据：本地练习不应需要生产后台、数据库或业务密钥。
  • 把自动钩子当安装必需品：提交即调用模型会隐藏触发频率与费用，还可能覆盖已有 post-commit；先用手动复核。

完成时应留下的证据

  • 任务卡、被验收文件、检查结果和待办相互对应；A/B/C 三行三列契约完整。
  • 范围外没有新增改动，用户原有改动仍在；git diff --stat 不显示未跟踪文件，需与 git status --short 一起判断。
  • 复核发现的问题有处理决定；失败和未运行的测试没有被写成通过。
  • 本地验收、合并、发布分开记录；上线状态只能由实际发布与验收证据确认。

操作依据

适合谁看

  • 两种工具已分别接入，想让第二个工具检查遗漏，而不是重复做一遍。
  • 需要交接网站、脚本或文档项目，且必须保留用户已有改动。
  • 准备研究插件联动，但希望先有一条不依赖插件的完整流程。

需要解决的问题

  • 两个会话同时修改同一个文件，后保存的版本覆盖前一个版本。
  • 交接只剩一句“完成了”，没有文件范围、基线或未通过的检查。
  • 后台任务已启动，却被当作已经验收；复核者又在未授权时开始修复。

先理解这些

  • 执行者负责修改，复核者负责找问题；角色可互换，不按品牌固定谁规划、谁写代码。工具选择见 https://thinktank.1a1api.top/article/claude-code-vs-codex 。
  • 任务卡是交接约定，不是访问控制。worktree 是同一 Git 仓库的另一份工作目录，也不是操作系统级隔离。
  • 两边各自使用自己的认证与计费。Claude 的订阅不替代 Codex 的登录，ChatGPT 订阅也不是 API 余额；不要把第三方 Key 填入官方账号登录流程。
  • 旧案例中的 Opus 4.7 / GPT-5.5 只用于识别历史配置；此流程不要求这两个型号，也不承诺它们在当前账户可选。

遇到困难时

  • 文件冲突：停止两个会话的写入，保留各自产物，由人按基线逐处合并。不要用 reset --hard、全目录恢复或删除用户改动来“解决”。
  • 两边结论相反：回到输入事实和可复现检查。没有证据的意见记为待确认，不按回答长度或模型名表决。
  • 只运行了部分检查：保留已完成文件，在交接卡标出缺少的证据；本地构建通过不等于页面体验或生产部署通过。
  • 模型不可选或额度不足：暂停调用，核对当前账户可用模型与限制；不靠插件、菜单修改或另一种 Key 绕过权限。
  • 已启用自动 review gate 或提交钩子：先暂停触发源和未完成任务，查清它会读什么、发送到哪里，再决定是否保留。不要覆盖已有钩子或无限互相重试。