先说结论：
- 错误双开：Claude 在右边说，Codex 在左边等，人负责复制粘贴。
- 可用协作：Claude 的输出能被 Codex 直接读到，Codex 再继续执行和验证。
区别不在于开了几个窗口，而在于信息能不能交接。
这次踩坑点很具体：我把协作入口想错了。
我一开始把 Claude Code 开在 Codex 右侧终端里，想让它帮我做第二意见。界面上看起来很合理：左边 Codex 负责当前任务，右边 Claude Code 负责评审。
但跑起来后很别扭。
Claude 在终端界面里输出了什么、有没有卡在确认步骤、上下文滚到了哪里，Codex 这边并不能稳定接住。最后还是要人盯着右侧终端，把 Claude 的结论复制出来，再喂回 Codex。
最明显的一次，就是我让 Claude Code 复审这篇文章。
右侧终端里 Claude 还在跑，Codex 这边拿不到稳定的审稿结论。我只能中断那次会话，改成把文章正文通过 stdin 喂给 claude --print --tools=""，让它输出完就退出。
这里用 --tools=""，是因为我只是在审一段已经给出的文章文本，不需要 Claude 再去读仓库文件。
后面那条 --tools "Read,Grep,Glob" 是另一种场景：让 Claude 只读当前仓库，帮我查架构风险、测试缺口和方案问题，所以只开放读文件和搜索文件的工具。
这样 Codex 才能读到完整结果，再继续判断要不要改。
如果中间还要人来回搬运，这就不叫多 AI 协作。
这只是两个 AI 并排打开。
后来我把方式改掉：不再共享 Claude Code 的 TUI，而是让 Codex 直接调用 Claude Code 的非交互模式。
Claude Code 只负责思考和评审。
Codex 负责调度、改文件、跑测试和汇报。
这条链路闭合以后，Claude 的建议才能被 Codex 读取、判断和继续执行。
先判断一件事：主控能不能读到输出
多 AI 编程最容易误判的地方，是把“同时打开”当成“已经协作”。
我现在会先看一个更底层的问题：
主控方能不能拿到参谋方的完整输出，并把它接进下一步动作里？
如果 Codex 不知道 Claude Code 看到了什么、判断了什么、建议了什么，它就没法把 Claude 的判断纳入后续执行。人会被夹在中间，既要传话，又要判断，还要处理两个工具可能造成的冲突。
所以共享 Claude Code 的终端界面不是一个好入口。
它有两个实际问题：
- Codex 读不到 Claude Code 终端界面里的完整上下文。
- 两个 Agent 如果都能改同一个工作区，风险会变大。
一个 AI 刚改完，另一个 AI 也在改。最后谁的改动更合理、谁覆盖了谁、测试失败到底是谁造成的，都会变成新的维护成本。
我的分工：Codex 主控，Claude 只读参谋
这套分工必须硬一点。
Codex 先读当前 repo 状态，明确任务目标和风险边界。
Claude Code 不直接改文件，只输出评审建议。
Codex 再判断哪些建议有价值，自己落地修改、跑验证、整理结果。
这里不要纠结哪个模型更强，先把角色分清楚：
- Codex 是主控，负责目标、边界、执行和验证。
- Claude 是参谋，负责第二意见、风险提示和盲区补充。
- 人负责授权高风险动作，以及最终发布判断。
只要 Claude 的建议没有被 Codex 稳定读取和处理，这条链路就还没闭合。
什么时候才值得调用 Claude Code
我不会默认让 Claude Code 参与所有任务。
单文件小 bug、样式微调、明确的测试失败，Codex 直接处理就够了。
我只在这些场景调用 Claude Code：
- 审一个比较大的 diff。
- 比较两种架构方案。
- 重构前看影响范围。
- 找测试缺口和隐藏风险。
- 发布前做一次只读复核。
- 让另一个模型从不同角度挑问题。
这时候 Claude Code 不该被当成“多一个工人”。
它更像审稿人。审稿人可以挑错、补盲区、提醒风险，但最后改稿的人还是主编。
5 步 SOP：我现在这样跑
-
Codex 先查现场
看
git status、最近提交、项目规则、目标文件和测试入口。不要上来就调 Claude，因为 Claude 的输入质量决定了它的建议质量。 -
Codex 写清楚评审问题
不要让 Claude 泛泛地“看看这个项目”。要告诉它只读、不要改文件、重点找架构风险、遗漏测试，还是方案取舍。
-
Claude Code 用非交互模式输出
让 Claude 输出结果后退出。非交互模式会把结果输出到当前命令流里，Codex 可以完整读取建议，而不是盯着另一个终端界面猜它发生了什么。
-
Codex 只采纳有价值的部分
Claude 的建议不是命令。它可能看得更细，也可能误判。最终仍然由 Codex 结合当前代码和任务目标决定怎么改。
-
Codex 自己落地和验证
改文件、跑测试、检查 diff、说明结果，都由主控完成。这样责任链是清楚的：Claude 的输出只是评审材料，不是执行指令。
可以直接复制的只读评审命令
核心命令是这个：
claude -p --permission-mode plan --tools "Read,Grep,Glob" \
"请只读评审当前项目，不要改文件。重点找架构风险、遗漏测试和更优实现方案。"
这条命令的重点有三个：
-p：让 Claude Code 输出结果后退出，不进入共享终端界面。
--permission-mode plan：把它限制在规划和评审状态。
--tools "Read,Grep,Glob"：只给它读文件和搜索文件的能力，不给写文件能力。
如果真要让 Claude Code 改代码怎么办
可以，但不要让它和 Codex 同时改同一个工作区。
更稳的方式是单独开 worktree 或分支：
claude --worktree claude-experiment
或者由 Codex 先建一个独立 worktree，再让 Claude Code 在里面做实验。
最后仍然由 Codex review diff、跑测试、判断要不要合并。
这个边界很重要。
多 AI 协作最怕的是多个工具同时在同一份代码上动手。最后系统状态为什么变成现在这样，没人说得清。
风险边界：敏感项目不要随便交给第二个 AI
还有一个容易忽略的点：
如果你的 Claude Code 配的是第三方 API 网关，claude -p 会消耗那个第三方额度，并且上下文会经过那个服务。
这意味着，敏感项目不要这样跑。
包括：
客户未公开代码。
内部商业策略。
密钥、token、cookie、账号信息。
生产数据和用户隐私。
还没发布的核心产品方案。
这类项目宁可只用当前受控环境，也不要为了多一个模型，把上下文交给不该交的地方。
这套能力可以沉淀成什么
这条命令本身不复杂。
更值得沉淀的是一套多 AI 编程协作能力：
- 写代码前做方案评审。
- 提交前做 diff 审查。
- 重构前做影响范围判断。
- 发布前做风险检查。
- 内容生产前做反向质检。
有价值的 AI 工作流，不是把所有工具都打开，而是每个工具只做它最适合的那一段。
这也是我现在更看重“桥接”的原因。
一个能被主控读取的输出，比一个看起来很热闹的双开界面更重要。
一条清楚的交接记录，比两个 Agent 同时在同一份代码上动手更重要。
我的结论
我现在会先问一个问题：
Codex 能不能直接读到 Claude Code 的完整输出，并继续执行下一步？
如果答案是不确定，我就不会把它当成协作。
如果答案是可以，那就按这套分工跑：
Claude Code 来思考和评审。
Codex 来调度、执行和验证。
其他时候，Codex 自己完成就够了。