Claude Code 用得越深，我越明显感到一个问题：额度不够用。
不是完全不能用，也不是非得立刻升级到更高套餐，而是那种很尴尬的状态——差一口就能吃饱，但每次刚进入工作状态没多久，就撞上 5 小时额度上限。
如果只是偶尔写几段代码、问几个问题，这个限制不算严重。但我现在的使用方式已经不是「问答」了，而是把 Claude Code 当成一个长期工作台：读项目、拆任务、写文档、改代码、复盘流程、沉淀规则。它参与的环节越多，额度消耗就越快。
直接升级 Claude Code 更高阶套餐，当然是最简单的办法。但我当时的判断是：还没到那个阶段。不是用不上 Claude，而是还没有用到必须花更多钱买大额度的程度。真正的痛点不是「完全不够」，而是「核心判断想留给 Claude，机械执行也在消耗 Claude」。
于是我开始找一个补位工具。
最后补进来的，是 Codex CLI。
我为什么装 Codex CLI？
原因很简单：它符合我的工作场景。
我本来就习惯在 CLI 里工作。项目在本地，Obsidian、终端、Git、脚本、AI 助手都围绕文件系统转。相比再开一个网页工具，Codex CLI 更容易嵌进现有流程里。
更重要的是，Codex 有自己的额度。对我来说，它不是要替代 Claude Code，而是给 Claude Code 分担一部分消耗：那些不太需要深度判断、但需要模型去读文件、改文件、跑命令、整理结果的活，可以先交给 Codex。
一开始我的想法很朴素：Claude Code 额度不够，就装个 Codex CLI 将就一下。
真正用起来以后，我对它的定位反而更清楚了：Codex 不是我的第二个大脑，而是我给 Claude Code 装上的一只机械臂。
大脑负责判断，机械臂负责干活。
Codex CLI 的体验：不是不好，而是不能乱用
先说结论：我目前不会把 Codex 当成 Claude Code 的平替。
它当然能回答问题，也能写代码、读项目、执行任务。但在我的使用感受里，它和 Claude Code 的气质不一样。
第一，Codex 的判断感弱一些
我对 Codex 最明显的感受是：它更容易顺着用户说。
这件事在无关紧要的问题上没什么影响。比如让它整理文件、补一段说明、按规则改格式，它答得肯定一点，甚至还会让人感觉执行很顺。
但如果问题本身需要判断，比如：
- 这个方案值不值得做？
- 现在是不是该重构？
- 这个工作流是不是过度设计？
- 某个产品定位是否跑偏？
- 我自己的判断里有没有盲区？
这类问题，我更愿意找 Claude Code，而不是 Codex。
因为我需要的不是一个一直说「对，你说得有道理」的助手，而是一个能帮我拆开问题、指出风险、反驳我、逼我把前提讲清楚的合作者。
所以我现在对 Codex 的回答，默认会多一层质疑。无关紧要的问题可以问它，重要的思考和讨论，我还是只和 Claude 聊。
第二，Codex 对复杂问题和任务响应体感更慢
另一个直观感受是慢，这里的慢是针对复杂问题和任务而言的。 日常小问题codex回答起来比Claude实际上快很多的。
同样一个稍微深一点的问题和任务，分别丢给 Claude Code 和 Codex，Codex 的回答体感会慢不少。这个我没有做严格基准测试，因为意义不大。工具都会迭代，速度后面肯定会变。
但作为日常工作流的一部分，体感速度本身就很重要。
如果一个工具慢，但判断力强，我可以等。如果一个工具慢，同时判断还需要我反复校验，那它就不适合被放在「核心讨论」位置。
这也是我后面形成分工的原因：Codex 不负责替我想清楚问题，它负责在问题已经被 Claude Code 拆清楚以后，去执行。
那为什么不直接申请两个 Claude Code 账号？
这也是我当时想过的方案。
如果一个 Claude Code 账号额度不够，那是不是再开一个账号就好了？Claude 官方层面并不是完全不能这么做，但实际使用会遇到一个问题：切换账号。
对轻度使用者来说，手动切换可能没什么。但我现在的工作流里，AI 助手不是孤立工具，而是跟本地项目、全局规则、会话上下文、CLI 环境、插件配置都绑在一起。
两个 Claude Code 账号来回切，我会担心几件事：
- 哪个账号加载了哪套规则？
- 哪个会话承接了哪个项目上下文？
- 本地配置会不会被我自己搞混？
- 数据、记忆、插件状态会不会出现不一致？
这些不一定真的会出问题，但只要存在这种可能，我就不想把它放进主工作流里。
相比之下，Codex CLI 更像一个清晰的外部执行器。它有自己的环境、自己的额度、自己的职责。边界越清楚，协作越稳定。
真正让我继续用 Codex 的，是 Claude Code 插件
单独使用 Codex CLI 后，我其实没有特别兴奋。
它能用，但没有到「从此我转向 Codex」的程度。真正让我觉得这件事值得继续折腾的，是 OpenAI 的 codex-plugin-cc。
这个插件的思路很直接：让 Claude Code 用户可以在原来的工作流里调用 Codex。也就是说，你不用完全切到 Codex，而是可以让 Claude Code 把一部分任务委派给 Codex。
这个瞬间，我对 Codex 的理解变了。
以前它是另一个工具；装上插件以后，它更像是 Claude Code 的外挂机械臂。
我并不是花钱买了一个新主脑，而是花钱给 Claude Code 加了一条执行手臂：Claude 继续负责出方案、做判断、复审结果；Codex 负责接任务、跑流程、产出交付物。
从这个角度看，给 Codex 充值就不再像「又订阅了一个工具」，而像是「加强了 Claude Code 的执行层」。
这就是我为什么明明觉得 Codex 体验不如 Claude Code，却还继续用它，甚至愿意充值。
但我没有把插件直调作为主流程
听起来，Claude Code 能直接调用 Codex，是不是就完美了？
理论上很美。
Claude 在当前会话里判断任务，然后自动派给 Codex；Codex 在后台执行，完成后把结果返回；Claude 再继续总结或复审。整个过程像多 Agent 协作，用户只需要等结果。
但真用到自己的项目上，我反而把它收了起来。
原因只有一个：黑箱。
插件直调的问题不在于它不能用，而在于中间过程太顺了。Claude 把活甩过去，Codex 闷头做完，再返回一个结果。方便是方便，但我很难看清楚：
- Claude 到底把任务描述成了什么？
- Codex 是否理解了任务边界？
- 它动了哪些文件？
- 它有没有做超出范围的改动？
- 它的自验是不是可靠？
- 如果结果不对，我该从哪里回溯？
对成熟、低风险、边界清楚的任务来说，这些问题不大。
但我的很多项目都还在早期阶段。早期项目最大的问题不是「执行速度不够快」，而是「方向和边界还不够稳」。这时候让一个黑箱自动跑起来，一旦跑偏，后面改错的成本可能比省下的时间还高。
所以我最后采用了一个更原始、也更稳定的方法：文件交接法。
什么是文件交接法？
文件交接法的核心逻辑很简单，只有三步：
- Claude Code 生成任务文件
tasks.md； - Codex 读取
tasks.md执行任务，完成后生成交付文件report.md； - Claude Code 读取
report.md，按原任务要求审核确认。
看起来很笨，但它解决了我最在意的问题：可见、可查、可复审。
在这个流程里，Claude Code 不再是随口把任务丢给 Codex，而是先把任务写成一份清楚的工单。工单里至少要写明：
- 背景：为什么要做这件事；
- 目标：最终要达成什么；
- 范围：哪些能动，哪些不能动；
- 验收标准：做到什么程度算完成；
- 自验方式：Codex 做完后要怎么检查；
- 交付格式：最终 report.md 里要写什么。
Codex 拿到的不是一句模糊的「帮我改一下」，而是一份边界清楚的任务书。
完成后，Codex 也不能只说「我做好了」。它要写 report.md，说明：
- 实际做了什么；
- 改了哪些文件；
- 如何对齐任务要求；
- 做了哪些验证；
- 还有哪些风险或未处理事项。
然后 Claude Code 再拿这份交付报告，回到最初的任务标准里复审。
这才是我想要的多 Agent 协作：不是两个模型在黑箱里互相说话，而是一个模型出工单，一个模型交报告，最后再按工单验收。
为什么我执意用文件交接？
因为文件是最稳定的协作界面。
插件、MCP、会话、上下文、后台任务，这些东西都很强，但也都更复杂。复杂系统一旦出问题，排查成本就会上升。
文件不一样。
tasks.md 写在磁盘上，谁都能读；report.md 写在磁盘上，谁都能查。今天用 Claude Code + Codex 可以跑，明天换别的 Agent 也可以跑。新项目能跑，老项目也能跑。改代码能跑，写文档也能跑。
这套方法牺牲了一点自动化，但换来了几个确定性：
第一，任务边界更清楚。
Claude Code 必须先把事情讲明白，才能交给 Codex。这个动作本身就会逼我和 Claude 一起澄清任务。很多时候，真正有价值的不是 Codex 后面执行了什么，而是 Claude 在写 tasks.md 时把目标、范围和验收标准整理清楚了。
第二，中间过程可回溯。
如果结果不对，我可以回头看：是任务本身没写清楚，还是 Codex 执行跑偏了，还是验收标准缺失。问题能定位，就能改流程。
第三，责任分工更稳定。
Claude Code 负责判断，Codex 负责执行，用户负责拍板。三个角色不混在一起，协作就不容易乱。
第四，它不依赖某个特定插件。
插件直调很好，但它是加速通道，不应该成为唯一通道。只要我的主流程建立在文件交接上，即使插件临时不可用，整个协作也不会瘫痪。
自动分工不是自动放权
这里有个容易误解的点：我不是反对自动化，也不是反对多 Agent 调度。
我反对的是，在任务还没讲清楚的时候，就把控制权交给自动调度。
很多人一听「Claude 调 Codex」，第一反应是：太好了，以后 Claude 自动分工，Codex 自动执行，我不用管了。
但我的实际感受正好相反。越是多 Agent，越要把规则写死。否则两个模型都很努力，但努力方向可能不一致。
自动分工的关键，不是让模型自由发挥，而是把分工规则写清楚：
- 什么任务必须留给 Claude Code 判断；
- 什么任务可以交给 Codex 执行；
- 交给 Codex 前必须生成什么工单；
- Codex 完成后必须交付什么报告；
- Claude Code 如何复审；
- 哪些情况下必须停下来问用户。
这些规则可以写进 Claude Code 的全局规则，也可以写进项目规则。Codex 侧则用 AGENTS.md 约束它在项目里的行为。
我现在的原则是：先用文件交接把流程跑稳，再考虑插件直调提速。
插件直调适合什么时候用？
虽然我主流程不用插件直调，但我并不否定它。
相反，我觉得它很适合做「快线」。
比如：
- 让 Codex 做一次只读 review；
- 对某个方案做反向审查；
- 把一个边界非常清楚的小任务丢给 Codex；
- 在项目已经稳定后，让 Codex 后台跑一段机械执行；
- Claude Code 已经写好详细计划，只需要 Codex 按计划实现。
这些场景下，插件直调的优势就出来了：快、顺、少切换。
但它不适合一上来就接管主流程。尤其是在项目早期、任务边界模糊、你自己也还没想清楚的时候，插件越顺，风险越大。
所以我的排序是：
先文件交接，后插件直调。
先白纸黑字，后自动提速。
先让协作可靠，再让协作变快。
如果你也想照着做
最简单的路径是三步。
第一，装 Codex CLI，并登录你的 ChatGPT 或 OpenAI API 账号。
npm install -g @openai/codex
codex login
第二，在 Claude Code 里安装 codex-plugin-cc。官方 README 给出的路径是：先添加 marketplace，再安装插件，重载插件，最后运行 setup。
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
第三，不要急着全自动派活。先让 Claude Code 帮你写一条全局协作规则：以后凡是需要 Codex 执行的任务，先生成 tasks.md；Codex 执行完必须生成 report.md；Claude Code 再按任务要求复审。
也就是说，真正关键的不是安装命令，而是分工规则。
没有规则，插件只是一个更快的黑箱。
有了规则，Codex 才会变成 Claude Code 的机械臂。
结尾：我不是在换工具，而是在重组工作流
这次折腾 Codex CLI 和 codex-plugin-cc，我最大的收获不是「发现了一个更便宜的替代品」。
恰恰相反，我更加确认：Claude Code 仍然是我的主工作台。
它负责和我一起想清楚问题，拆出方案，判断轻重缓急，最后复审交付。Codex 的价值不在于替代它，而在于把一部分执行消耗接过去。
以前我把所有事情都丢给 Claude Code：讨论、判断、改文件、跑命令、写报告。这样当然顺，但也会快速消耗额度。
现在我更愿意把工作拆成两层：
- Claude Code 做判断层；
- Codex 做执行层。
中间用 tasks.md 和 report.md 交接。
这套方法看起来没那么炫，但它符合我现在对 AI 工作流的理解：真正重要的不是让 Agent 越来越自动，而是让每一次自动化都有边界、有记录、能复审。
只有这样，AI 才不是一个会随机扩大影响面的黑箱，而是一套可以长期接进项目里的工作系统。
Codex 不是我的第二个大脑。
它只是我给 Claude Code 装上的一条机械臂。
大脑继续思考，机械臂负责干活。