当前位置：首页 > news >正文

你还在纠结用 Claude Code 还是 Codex？我已经把它们都用上了

news 2026/8/24 9:08:11

你还在纠结用 Claude Code 还是 Codex？我已经把它们都用上了

我同时开着两个终端，一个跑 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就知道从哪里接手，不需要我重新解释任何背景。

一句话总结：