我同时开着两个终端，一个跑 Claude Code，一个跑 Codex。
不是在做评测，是在干活。
我在一个 20 多个 Spring Boot 微服务的供应链系统里干活，历史债务一堆，业务逻辑层层包袱。用了几周之后我的结论是：
它们不是竞争关系，是分工关系。
我怎么分工的
一句话版本：
Claude Code 负责"读懂"，Codex 负责"跑量"。
复杂 bug 定位、Code Review——我用 Claude Code。它在理解业务上下文这件事上明显更稳，给出的分析更有逻辑链。
并行跑多个子任务、批量补文档和注释——我用 Codex。开多个窗口同时跑，速度快，适合不需要深度理解业务的重复性工作。
但我不是一开始就想清楚这个分工的，是被一个线上问题逼出来的。
一个让我想清楚这件事的案例
前段时间线上出了一个异常，是典型的历史包袱问题——业务逻辑经过多次迭代，某个边界条件的处理早就不对了，但一直没爆，直到某个新流程走到那里。
我当时把异常描述、相关接口逻辑、加上日志，同时喂给 Claude Code 和 Codex 对比分析。
结果差距很明显。
Claude Code 把整个调用链梳理了一遍，指出了几个可疑点，并且解释了为什么历史上的某个写法在当前场景会出问题——是带推理过程的分析，不是猜。
Codex 也给了方向，但逻辑链没那么完整，定位到的位置偏浅。
最终用 Claude Code 的分析找到根因。修完之后，左边窗口 Claude Code 还在收尾，右边 Codex 已经开始并行跑各模块的单元测试了。
这个画面让我意识到：它们根本不是在竞争同一件事。
两个 agent 同时跑，最容易踩的坑
想清楚分工之后，我开始认真配置两个 agent 的协作方式。
第一个坑很隐蔽：很多人会把项目信息全写进 CLAUDE.md，然后让两个 agent 都去读。
这会出问题。
Codex 有自己的官方配置文件，叫 AGENTS.md，它不读 CLAUDE.md。两个 agent 如果共用一套规则，要么产生冲突，要么重复执行。
正确的做法是分开写：
project/
├── CLAUDE.md ← Claude Code 专属，项目上下文 + 行为规则
├── AGENTS.md ← Codex 专属，Codex CLI 官方约定的配置文件
└── CHANGES.log ← 两个 agent 共享的任务状态总线
两个 agent 各读各的规则，内容基本一致，只是行为规则独立维护，互不干扰。
CHANGES.log：两个 agent 之间的通信总线
这是整套方案里我花时间最多的设计，也是最关键的一环。
我这边网络不稳定，随时可能需要从 Claude Code 切换到 Codex，或者反过来。如果没有交接记录，每次切换都要重新解释背景，成本极高。
CHANGES.log 解决的就是这个问题——它记录的不是代码变更，而是任务状态。
格式大概是这样的：
[2026-03-18 14:23] [CLAUDE_CODE] BUG-02
Status: PARTIAL
已完成：定位到 OrderService.java 中库存扣减的边界条件异常
根因：历史逻辑在并发场景下未加分布式锁，导致超卖
Files modified: order-service/src/main/java/com/xxx/OrderService.java
未完成：InventoryClient.java 的幂等校验还未补
Remaining: 需在 InventoryClient 的 deduct() 方法入口加幂等拦截
Next agent: 直接接手 InventoryClient.java，背景已完整
[2026-03-18 15:01] [CODEX] BUG-02 (pickup)
Status: COMPLETE
Files modified: inventory-service/src/main/java/com/xxx/InventoryClient.java
Tests: PASS — OrderServiceTest 5 passed, InventoryClientTest 3 passed
网络断了换哪个 agent，它读一遍 CHANGES.log 就知道从哪里接手，不需要我重新解释任何背景。
一句话总结：
CLAUDE.md给 Claude Code，AGENTS.md给 Codex，CHANGES.log是两个 agent 之间的通信总线，网络切换时靠它无缝接力。
并行处理时，我怎么拆任务
配置稳定之后，并行跑任务的方式也逐渐固定下来。
我通常的做法是：把一个需求拆成两个不互相依赖的子任务，分别交给两个 agent 同时跑。
比如一个接口改造需求：
- Claude Code：理解旧接口的业务逻辑，找出改动边界，完成核心实现
- Codex：同步跑单元测试补充、接口文档更新、相关注释生成
有依赖的部分，通过 CHANGES.log 传递状态，等一个完成了另一个再接手。
两个 agent 给出不同结论时，我不会直接选一个，而是两个推理过程都看，自己判断哪个更合理。这个对比过程本身，往往会让你对问题理解得更深。
遗留代码的真实成本
在有历史债务的项目里用 AI，有一件事要提前想清楚：成本比你想象的高。
两个工具都需要大量背景上下文才能真正理解代码在干什么。随便丢一段进去，给出的结果基本是通用废话。
我现在的原则是：每次只喂最必要的上下文——相关接口、核心日志、异常描述，不超过这个范围。这不只是省 token，更重要的是分析质量更高，噪音少了模型反而更准。
订阅怎么选
如果你不是重度使用者，每周大概用 5 小时左右——
Codex $20/月的 OpenAI 订阅目前是性价比最高的起点。现阶段 OpenAI 给了很大的使用余量，基本不会触碰上限，日常编码任务够用。
Claude Code 可以先用免费额度感受一下，真正需要深度分析复杂业务代码的时候再考虑升级。两个都重度用是进阶玩法，先把 Codex 用熟更实际。
最后
我知道很多人还在纠结选哪个。
但说实话：还在纠结的时间，已经够你把两个都跑熟了。
Claude Code 更适合需要真正读懂代码的任务，Codex 更适合并行执行、跑量、批量处理。真正的效率提升，在于把两个工具的边界想清楚，以及设计好它们之间怎么交接。
工具不是关键，你怎么用才是。
更多深度内容与完整文章，欢迎关注我的微信公众号：SamLai 效率研习社
主要分享：
AI 编程与开发效率
技术趋势与工程思考
实用工具与工作流
