把 Claude Code 跟 Codex CLI 并用三个礼拜当生产线跑：spec 在 Claude Code 这边抓着，程序全部派给 Codex CLI 写。
听起来很干净，实际做下去缝隙到处都是。
第一个礼拜会以为是手生，第二个礼拜就会发现同一种坑反复撞。Anthropic 的官方文档讲 Claude Code，OpenAI 的官方文档讲 Codex CLI，各自都很完整。两个放在一起怎么跑这件事，住在用户的 terminal 记录里，没人写过。
下面整理累积的笔记，把最关键的六件事说清楚。已经在用 Claude Code 开分身、想把 Codex CLI 加进来当执行手的人，可以省下一两个下午。文章不放具体命令（两家工具的命令参数会随版本变动），只讲概念。要照做的时候，配当下版本的官方文档对齐细节最稳。
为什么这个分工值得做
先讲结论：让 Claude Code 当指挥、Codex CLI 当执行手，是两个工具最舒服的用法。
Claude Code 的强项在规划、审查、把住 spec 不偏掉、决定什么叫「做完了」。它的反应风格适合这层工作，加上能开分身去看别的东西，很适合当决策层。
Codex CLI 的强项在执行：写程序、refactor、长时间连续编辑、跑测试。它的沙盒设计也让人能放心让它自己跑。
把两者叠起来：Claude Code 在上面拿着 spec，把工作切成一片一片派给 Codex CLI。Codex 写完 → Claude 开分身做 cross-family review → 通过再 merge。这个回路比让任一工具自己包办稳很多。
下面六件事，是这三周里学最久的。
一、「自动模式」不等于「完全不问」
第一次叫 Codex 自动跑一个无人值守的任务，跑回来常常会看到完全没动。
进 log 才看到，它停在「要修这个档，要不要批准？」的询问界面那里，没人按，卡了二十分钟。
很多自动化工具都有类似的设计：所谓的「自动模式」其实是「需要时还是会问你」，遇到敏感操作（修改文件、写入特定路径）会跳出询问。真正的无人值守要再加一层『不要问、直接做』的设置。
安全边界靠沙盒守，不要靠询问挡。询问挡一卡就整个 session 卡住、半个下午没动，比较不划算。
二、沙盒默认没有网络
第二个坑：写一份命令叫 Codex 去装一个新包，跑半天告诉你装不起来。
真正的原因跟包管理器无关，Codex 沙盒默认网络是关的。
理由很单纯，安全。但日常开发很多任务都需要网络：装包、git push、打第三方 API。要开网要显式打开，不是 default 给你用。
关沙盒整个跑（让它拥有完整系统权限）也能绕过去，但那等于把护栏拔了。稳定的习惯是每个任务开头先想一秒「这个任务要不要连网」，要连就开该开的旗标、不要就保留 default。多一秒思考比拔护栏安全得多。
三、判断成功要看多个讯号，不是 stdout 最后一行
看 Codex 跑完只看 stdout 最后一行：「OK looks good」就 merge，吃过几次闷亏之后，会学到要看多个讯号交叉。
至少包括：
- 退出代码是 0（程序正常结束）
- 执行记录里有「整轮完成」事件（不是中途断掉）
- 预期该写出去的文件真的落地在磁碟上
任何一个没到，都不算成功。Stdout 最后一行可能在输出中间就被缓冲切掉了，看起来像「结束时的消息」其实只是「最后一段被挤出来的字」。
具体要怎么接这些讯号，每家工具的旗标都不一样，照当下版本的官方文档查。重点在概念：讯号要交叉、不能单看一条。
四、单次任务有时间上限，超过就死掉
这条学最痛。
派一个大重构给 Codex，命令写得很细，预估它要跑四十分钟。回来 session 死了，log 写着「压缩任务超时」。
当对话累积到接近上限，Codex 会自动触发内部压缩机制：把已经处理过的部分压成摘要，腾出空间给新的回合。问题是压缩本身会吃时间，一旦超时、整个 session 就死了。连 resume 都救不回。下次接回来，会拿到一个卡死的 session。
可靠的铁律：单次任务不要拖太久。实测 25 分钟以内是甜蜜点，更长就拆段。每段跑完写一份小总结（「做了 X、剩下 Y、下一步从 Z 开始」），下一段用这份总结当开头、开新 session 接续，死掉的那个直接放掉。
切段的副作用是好的：每段时间短，token 消耗也比较好估、出错也好定位。
五、Code review 一定要交给另一家
让 Codex 写完 code、再让 Codex 自己审，会抓到一些东西，但漏掉的也多。
写程序的模型跟审程序的模型同源，思考底子一模一样，它对自己刚写过的东西容忍度比审别人高很多。看起来在 review，实际上在橡皮图章。
这就是为什么这套架构长成「Claude Code 在上、Codex 在下」：Codex 写完之后，diff 不交给 Codex 自己审，交给 Claude 开的分身 审。不同的模型家族、不同的错误模式、不同的盲点。Cross-family review 抓到的东西比 self-review 多得多。
稳定流程是：Codex 写完 → Claude Code 拉出 diff → 开 Claude 分身 review → 有问题回 Codex 修、没问题 merge。这层额外的 review 经常能抓到肉眼扫过去看不出来的 silent bug。
六、三个并行是甜蜜点，第四个会撞墙
最后一条跟付费方案的额度有关。
Codex 的付费方案有一个滚动式的额度窗口（rolling credit window），每段时间给你一定的计算量。并行跑多个 worktree（每个 worktree 开一个独立的 Codex session），额度消耗是叠加的。
跑四个并行，理论上应该很快，实际上跑到一半额度撞墙，所有 session 同时降速、最后一个直接被挡下来。
三个是甜蜜点。三个并行在付费方案下大致能撑 30-50 分钟的冲刺，再多就要等额度补回来。派任务之前先问自己：「这个任务真的需要四条并行吗？」多半答案是不需要，三条 + 一条依序排队就够用。
把这套整理成自己的 playbook
这六件事整理进了一份自用的笔记库：把每个踩过的坑写成一条「什么时候会遇到、为什么会发生、概念上怎么绕过去」，再配几份模板（任务派发格式、跨家审查流程、长任务切段记录等）让自己未来不必每次重新想。
两种方式可以用它：
- 照抄概念：找一个正在卡的问题，跳到对应段落，照着做。
- 照抄结构：把整份笔记库当成 starter kit，clone 一份放进自己的工作目录，依自己的工具版本微调。
之后也会把这份内容陆续整理成更系统的指南，跟同样在做两家工具并用的人一起累积踩坑经验。
结语
Anthropic 跟 OpenAI 不会帮用户写「两家工具一起用」的教程，这层永远是用户自己摸出来的。摸出来的东西可以分享，不用每个人各自摔一次。
延伸阅读
小企鹅的经验
主力工作流是 Claude Code（在上）+ Codex CLI（在下）+ 开 Claude 分身做 cross-family review。实战下来最有感的两条：第一是 Codex 沙盒网络 default 是关的，每次想派需要连网的任务都要记得开；第二是长任务真的会被内部压缩机制超时杀掉，乖乖切段反而是最快的路。OpenClaw 上的多 agent 架构就是依这条分工跑的。
常见问题
Q: Claude Code 跟 Codex CLI 为什么要一起用？挑一个就好吗？
可以挑一个，但分工的甜蜜点明显。Claude Code 擅长规划、审查、把需求 spec 抓在手上；Codex CLI 擅长写程序、refactor、长时间连续编辑。一个在上层做决策、一个在下层执行，比让一个工具同时做两件事顺很多。
Q: Codex 跑长任务真的会死掉吗？
会。当对话累积太长，Codex 会自动触发内部压缩机制把旧内容收敛；这个压缩本身会吃时间，一旦超时整个 session 会死，连 resume 都救不回。实践中单次任务切在 25 分钟以内最稳。
Q: 为什么还要再让另一个 AI 审 code？
让 Codex 自己审自己写的 code，盲点会被它的 priors 盖过去；换另一家模型（例如 Claude）来审，不同的训练底子会抓到不同的问题，这层 cross-family review 抓到的 silent bug 比 self-review 多得多。
整理：Penna｜小企鹅 Penchan