TL;DR: 在165次Claude Code会话和27次Codex CLI会话后，我发现了一个清晰的模式：早上使用Claude来处理需要头脑风暴的互动型任务，下午让Codex完成可自动执行的具体任务。这不是哪个更好的问题，而是何时使用哪一个的问题。数据显示，两者结合远胜于单独使用任何一个。

早上九点，手握一杯咖啡，我脑中只有一个模糊的点子，准备重新构建一个模块。我不知道确切该怎么做，只是确信当前的模式并不理想。

于是我启动了Claude Code。

并不是因为它是“最好的”选择——而是因为我需要一种“自言自语”的方式，一个能理解上下文的助手。我告诉Claude：“这个服务的职责太多了，帮我拆分它。”随即，一场对话开始了。它提出一种分离方案，我讨论修改它，我让它探索另一种可能性，它在动手之前还会展示diff。这是一种协作的过程。

三个小时后，模块被成功拆分，测试通过，设计也有所改进。但这是我的Claude配额的40%。而我还列了一堆机械性任务，比如更新集成测试、清理无用的import、重整目录结构。

然后我打开了Codex。

我给它任务，设置为全自动模式，然后悠闲地去吃午饭。

数据揭示的模式

几个月来，我使用一款菜单栏应用监控自己的使用情况，这款工具记录了会话、token用量及耗时。以下是统计数据：

Claude Code: 165次会话，160,893条消息，28,052次工具调用。使用模型：Opus 4.5和Opus 4.6。从缓存中读取了56亿token。

Codex CLI: 27次会话。使用模型：GPT-5.4。模式：danger-full-access，审批策略：never。

令我意外的首先是Claude Code的使用时间分布：

09:00    1 ▏
10:00    5 ██
11:00   10 ████▌
12:00   14 ██████▎
13:00    7 ███
14:00   16 ███████▏
15:00   21 █████████▍
16:00   15 ██████▋
17:00   18 ████████
18:00   13 █████▊
19:00   14 ██████▎
20:00    9 ████
21:00   10 ████▌
22:00    8 ███▌

我70%的Claude Code会话发生在下午，仅22%在上午。

初看这些数据，我还以为自己“清晨用Claude”的理论行不通。但深入分析每个时间段的任务类型后，一切都渐渐清晰。

上午用于探索，下午用于执行

Claude Code的上午会话少但时长较长。这些会话属于设计阶段：“这部分功能应该如何运作？”、“帮我审阅这个计划”、“能不能提供一些其他选项”。这些是一次又一次的讨论，需要反复修改观点，最终达成决定。

而下午的会话则更多但较短。专注于落实早晨的决策、修复bug、调整测试。这是执行层面的任务，方向已经非常明确。

这就是Codex登场的时候。

为什么选择Codex处理自动化任务

Codex CLI使用GPT-5.4模型，运行模式是approval_policy = "never"，意即它不会向你寻求许可。它能读取你的代码库、执行命令、修改文件。没有额外对话。

如果用它进行设计工作，这种模式会显得很吓人——因为它不会提醒你“确定要这么做吗？”。但对于定义明确的任务来说，这种方式正中下怀：

  • “为这个模块的所有公共方法添加单元测试。”
  • “根据ARCHITECTURE.md描述的结构重整这些文件。”
  • “审阅这个plan.md，找出潜在问题。”

关键是，任务必须明确且可检验。如果你只是简单地说“优化性能”，它确实会采取一些行动，但可能与预期大相径庭。然而，如果你明确要求“将这条查询从200ms减少到50ms以下，并添加基准测试验证”，你就可以安心去吃午饭了。

下午：委派和放手

最近几周，我的实际工作流程：

  1. 9:00–13:00 — 使用Claude Code进行互动式任务。设计、探索和架构决策。就像找一个能陪伴思考的助手。我花费Claude配额的30%-50%在这里。

  2. 13:00–14:00 — 休息时间，同时记录早上产生的机械性任务。

  3. 14:00–15:00 — 启动Codex处理中午整理出的任务。全自动模式。这个时候，我要么处理其他工作，要么继续用Claude Code（因为这时Claude配额已开始缓慢恢复）。

  4. 15:00以后 — 审阅Codex的输出。如果需要迭代，我会用Claude进行代码审查，因为它的反馈质感更好。剩下的任务由Claude辅以快速对话完成。

注意：并不是说Codex不适合上午，也不是说Claude不适合下午。而是每天任务的类型不同，每种情况都有最合适的工具。

基准测试的数据（以及尚未体现的）

公开对比表明，Codex在Terminal-Bench 2.0中表现领先（77.3% vs 65.4%的Claude Code）。但在盲测代码质量时，开发者有67%偏爱Claude生成的代码。

换句话说：Codex擅长在终端执行任务，而Claude更擅长生成优雅实用的代码。两者并非竞争关系，而是互为补充。

最让我意外的数据是：Claude Code平均每个任务消耗的token是Codex的四倍。在Anthropic的最高订阅下，这意味着配额会更快耗尽。因此，将Claude用于质量需求较高的任务而将Codex用于需要处理较多token的任务，本质上是一种资源优化策略。

我的使用原则

每次使用这两个助手之前，我都会问自己一个问题：

“这项任务中途是否会改变方向？”

  • 如果答案是会 → 选择Claude Code。需要对话、反馈与反复尝试。
  • 如果答案是不会 → 使用Codex。任务边界清晰、验收标准明确，可以放心交给它执行。

这和与人协作很像。想征求意见时，会去找有深度的同事；而对于一项明确完成的任务，会找快速可靠的同事。同样，不应将规划交给执行者，也不应将执行交给规划者。

配额：共享且独立的资源

使用两个代理一个意外的好处是：两者的配额是独立的。当Claude的配额经过一个繁忙的上午后出现紧张时，Codex可以继续工作而不占用Anthropic的token。反之亦然。

以我的日常工作量为例——每天约4,500条Claude消息——如果上午特别高效，配额通常下午两点左右会告急。而Codex作为辅助代理解决了这一问题，使得这一限制变得几乎不存在。

这并不是在钻漏洞，而是站在“多云架构”或“多数据库供应商”的立场上进行分散管理。

尚未优化的部分

在两者之间切换时，任务移交依旧是手动的。我需要手动打开终端、启动Codex，并复制Claude的上下文。目前并没有一个标准协议可以用来直接把Claude的任务转交Codex。

此外，两者的记忆也是独立的。例如，Claude了解的项目细节（通过CLAUDE.md、memory/、skills），需要在Codex的AGENTS.md或运行指令中重复配置。等于维护了两套真相源，增加了不必要的同步成本。

最后，由于Codex默认权限较高，有时会显得过于“激进”，可能会对项目进行超出预期的改动。而Claude凭借对话式的操作流程，不太会出现此类问题。

意料之外的结论

起初，我认为这只是个时间安排的问题。早上用Claude，下午用Codex。而数据告诉我，不——这本质上是一个工作模式的问题。

创造性及迭代性的工作需要一个会话型助手；而机械性、定义清晰的任务适合一个全自动化助手。上午偏创意，下午偏执行，这更多取决于人的工作节奏，而不是工具的时段表现。

如果你只用一个助手，那就像用螺丝刀去敲钉子一样——也许可以完成任务，但并不高效。在经历了三个月的双代理组合体验后，我再也回不去“单助手”模式了。

最好的助手并非Claude或Codex，而是清楚地知道何时使用哪一个。

本文原文为西班牙语，借助AI翻译。