Claude与Codex双CLI协作实战
单一AI写稿容易角色混乱、技术描述失真。本文介绍一种 Claude 与 Codex 跨CLI协作架构，用文件桥接完成任务流转，帮助开发者构建可追溯、可复用的AI内容流水线。
在 AI 内容创作与代码开发场景中，很多开发者习惯使用单一 AI CLI 完成从构思、生成、自查到修改的完整流程。短期来看，这种方式足够方便；但在长周期、高频次、批量化任务中，问题会逐渐暴露：同一个 AI 既要负责内容产出，又要扮演严苛审稿人，角色边界很容易混乱。
它可能在写作时追求表达流畅，却在自查时忽略事实校验；也可能在代码生成时快速推进功能，却跳过边界条件、测试用例和文件变更范围检查。尤其是在技术内容生产中，单模型全流程处理常见的问题包括：内容范围跑偏、技术描述不够严谨、论据缺少支撑、行文风格前后不统一，甚至出现“看起来专业但实际不准确”的表述。
为了解决这类问题，本文采用了一套 Claude CLI 主写 + Codex CLI 专职审查 的跨 CLI 协作架构，通过本地文件完成两个独立模型之间的任务交接。整套流程落地后，成功支撑了 22 篇系列技术文稿的批量生产，并显著降低了人工复查成本。
一、为什么要拆分双 CLI 分工？
单一 AI 工具最大的问题，不是不会写，而是很难稳定地“既写得好，又审得狠”。在长上下文对话中，AI 容易延续前文判断，导致自查阶段缺乏足够的独立性。它会倾向于修饰已有内容，而不是从外部审稿人的角度重新检查逻辑漏洞。
因此，本文的核心思路是“岗位拆分”：Claude CLI 负责内容生成、初稿撰写和根据反馈迭代版本；Codex CLI 负责质量审查、问题标注和合格判断。这样做的本质，是把 AI 工作流拆成“创作者”和“评审者”两个角色，让两个模型在不同上下文中独立工作。
在批量内容生产中，这种分工尤其重要。Claude 更适合承担长文组织、结构搭建和自然语言表达；Codex 则更适合站在规则审查、技术准确性和执行约束的角度，对文稿进行阻塞式评审。
如果这套流程后续延伸到 API 调用层，尤其是需要在不同模型之间做批量任务分配、成本控制和调用稳定性优化，也可以接入 koalaapi 这类大模型 API 聚合平台作为补充。它可以帮助开发者更方便地聚合多模型接口，减少多 Key 管理成本，并根据任务类型灵活选择模型，让本地文件桥接负责流程落地，API 聚合层负责模型调用效率，两者形成更完整的工程化闭环。
二、三种跨 CLI 通信方案对比
要让两个独立 CLI 形成协作，首先要解决通信问题。本文先后对比了 Socket、Pipe/TTY、本地文件三种方案。
| 方式 | 适用场景 | 选型结论 |
|---|---|---|
| Socket | 长期驻留的多 Agent 控制台、实时双向通信 | 实时性强，但需要额外维护服务，对轻量内容生产场景偏重 |
| Pipe/TTY | 父子进程、一次性命令链路 | 适合预设管道，但不适合两个已独立启动的 CLI 稳定协作 |
| File 本地文件 | 长周期创作、人工把控节奏、需要全量留痕 | 无需服务、可审计、可回溯，最终采用 |
Socket 方案适合复杂控制台系统，但对于文章生产、代码审查这类轻量任务而言，额外维护服务会增加复杂度。Pipe/TTY 更适合由同一个父进程统一拉起的短链路任务，一旦两个 CLI 已经独立运行，稳定对接就不够灵活。
最终选择本地文件桥接，核心原因很简单：不需要额外部署服务，不依赖进程生命周期，即使会话中断、电脑重启，历史任务和评审结果也不会丢失。更重要的是，所有交接文件天然形成审计记录，非常适合长系列内容生产和代码评审场景。
项目根目录中创建统一的 .agent-bridge 目录：
.agent-bridge/
codex-inbox/ # Claude 写入任务，Codex 读取
claude-inbox/ # Codex 写入反馈，Claude 读取
shared/ # 公共资料、ACK 回执、参考文档
status.md # 全局任务状态，记录进度与阻塞点
这里遵循一个简单规则：谁收件，谁读取。例如 codex-inbox 是 Codex 的收件箱，Claude 负责往里面写评审请求；claude-inbox 是 Claude 的收件箱，Codex 负责写入审查反馈。这个命名规则非常重要，可以避免后续多人协作或多轮任务中目录读写混乱。
三、Draft → Review → Revise → Ready 的闭环流程
整套协作流程可以拆成四个阶段：Draft、Review、Revise、Ready。
第一步是 Draft。Claude CLI 根据选题、资料和写作要求生成初稿，并将文稿保存为带日期和版本号的 Markdown 文件。例如：
2026-05-18-article-01-draft-v1.md
第二步是 Review。Claude 将评审请求写入 codex-inbox，明确要求 Codex 只做审查，不直接重写全文。Codex 的任务是指出阻塞问题、技术不严谨之处、缺少依据的表达，以及需要修改的具体位置。
第三步是 Revise。Claude 读取 Codex 写入 claude-inbox 的评审反馈，只针对被标记的问题进行修改，避免无意义重写导致文章风格漂移。
第四步是 Ready。Codex 进行终审，并输出固定结论：ready、not ready 或 tiny cleanup。其中 ready 代表可以进入发布环节；not ready 代表仍有阻塞问题；tiny cleanup 表示只需轻微调整措辞、格式或标题。
这种闭环流程在 22 篇系列文稿中表现稳定，包括 8 篇上下文成本系列、8 篇 Agent 工作流系列、6 篇 Skill 教程。相比人工反复复制粘贴给同一个 AI 自查，双 CLI 分工让评审意见更客观，也更容易形成统一质量标准。
四、结构化评审模板：不要让审查变成泛泛点评
为了避免 Codex 给出“整体不错、建议优化表达”这类无效反馈，本文为评审阶段固定了结构化模板。示例格式如下：
Review Result: not ready
Blocking Issues:
1. “一半 token 都在浪费”缺少权威数据佐证，建议改为更客观的描述。
2. “三个工具对接同一模型”表述不严谨，应改为“同类 API 共享预算或调用额度”。
3. 第三节缺少实际落地步骤，建议补充文件目录和任务流转方式。
Required Next Output:
请只修改指定文档，不要重写全文；重点处理上述三个问题。
这个模板有三个好处：
第一，问题必须具体到句子或段落，不能只说“这里不够好”；第二，必须说明为什么有问题，避免评审意见变成主观感受；第三，必须给出下一轮输出要求，让 Claude 能够直接根据反馈完成定向修改。
同样的逻辑也可以迁移到代码开发中。一个 CLI 负责编码、运行基础验证，另一个 CLI 负责检查文件变更范围、边界条件、异常处理和测试结果，最终判断代码是否允许合并。
五、落地收益：从“AI 对话”变成“AI 流水线”
这套方案最大的收益，是把 AI 使用方式从一次性对话升级成了可复用流水线。
首先，角色边界更加清晰。Claude 不需要同时扮演作者和审稿人，Codex 也不需要从零创作，只专注于发现问题。这更接近真实团队中的“作者 + 编辑”“开发 + Code Review”模式。
其次，全流程留痕可追溯。每一次初稿、评审、修改和终审都保存在本地文件中，任务中断后可以通过 status.md 快速恢复上下文。对于系列文章或长期项目来说，这一点非常关键。
第三，质量门禁更明确。Codex 固定输出 ready/not ready/tiny cleanup 三类结论，避免“差不多可以了”的模糊判断。只有通过终审的内容，才进入发布或合并环节。
第四，系列内容风格更统一。对于长系列文章，统一的评审模板和状态文件能减少重复内容、口径冲突和标题风格混乱，后续发布校对成本也会明显下降。
六、常见踩坑与优化方案
第一个坑是双模型并发修改同一个文件。解决方式是在 .agent-bridge 下增加 lock 文件，例如：
article-01.lock
owner: claude
status: editing
当文件处于 Claude 编辑状态时，Codex 只能读取，不能写入修改建议之外的内容。这样可以避免两个 CLI 同时改动同一份文稿，导致版本覆盖或内容冲突。
第二个坑是 status.md 长期不更新。解决方式是要求每次任务流转都同步更新状态，包括当前阶段、负责人、待处理问题和下一步动作。例如：
# Task Status
## article-01
- stage: revise
- owner: claude
- blocker: 缺少数据来源说明
- next: 根据 Codex 反馈修改第二节
第三个坑是评审反馈过于笼统。解决方式是强制使用结构化模板，并要求每条问题包含“位置、原因、修改方向”。如果评审意见无法直接指导下一轮修改，就不算合格反馈。
七、后续自动化方向
目前这套方案仍偏手动，后续可以通过轻量脚本继续提效。例如：
agent-bridge request --to codex --task article-review --file xxx.md
脚本可以自动生成带版本号的评审请求文件，扫描 inbox 目录，汇总 status.md，统计哪些任务已经 Ready，哪些还在 Revise 阶段。
进一步还可以拆分文章评审、代码 Diff 审查、SEO 检查、事实校验等多套模板，让任务发起时直接绑定规则，减少重复提示词编写。
对于代码开发场景，也可以增加 Diff 审查模板：
Review Scope:
- 检查本次修改是否超出需求范围
- 检查是否存在未处理异常
- 检查是否补充必要测试
- 检查是否引入硬编码配置
Final Decision:
ready / not ready / tiny cleanup
这样一来，文件桥接方案不仅能用于内容生产，也能扩展到代码审查、文档整理、测试补全和项目复盘等更多场景。
结语
Claude CLI + Codex CLI 文件桥接协作的价值，不是简单叠加两个 AI 工具，而是通过角色拆分、文件留痕和质量门禁，重构 AI 内容生产与代码开发流程。对于中小团队和独立开发者来说，这套方案几乎没有额外部署成本，却能显著提升批量内容生产、技术文稿审查和代码 Review 的稳定性。
真正高效的 AI 工作流，不是让一个模型包办所有事情，而是让不同模型在清晰边界中各自发挥优势。只要流程设计合理，本地文件桥接也能成为一套轻量、稳定、可审计的 AI 协作系统。
