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