Codex 难用，难在我接不住
九月二十一号，Claude Code 的额度恢复了。我打开它说的第一句话是：
最近这几天我用 Codex 实现了很多功能，能不能帮我 review 下，我总感觉他比你弱点。
这个「总感觉」我已经有好几个月了。Codex 难用，说不上哪里难用，就是难用。
这次我想把「总感觉」换成数字。两个工具在本机都留着完整的会话记录，我把六月到现在的都翻了一遍——只算我自己在终端和桌面端里跟它们说的话，脚本调用的、子代理的都剔掉。
结果和我想的不太一样。
一、它在我这儿是替补
先看两个工具各自被我用了多少：
| Codex 会话 | Claude Code 会话 | |
|---|---|---|
| 六月 | 136 | 0 |
| 七月 | 240 | 100 |
| 八月 | 14 | 395 |
| 九月（到 24 号） | 151 | 486 |
六七月 Codex 是主力，八月几乎停掉，九月又冒出来一百多个。
九月那一百多个是怎么来的，按天摊开就清楚了：
| 日期 | Codex | Claude Code |
|---|---|---|
| 9 月 12 日 | 15 | 7 |
| 9 月 13 日 | 36 | 4 |
| 9 月 14–18 日 | 5 | 121 |
| 9 月 19 日 | 31 | 3 |
| 9 月 20 日 | 38 | 1 |
| 9 月 21 日 | 8 | 36 |
两条线严丝合缝地错开。Claude 那边一掉到个位数，Codex 就顶上来；Claude 一恢复，Codex 就退回去，第二天归零。九月前 24 天里，有 13 天我一次 Codex 都没开过。
记录里也写得很直白。九号那天我开 Codex 的第一句话后面，顺手贴了一句：「Claude 搞了一半没额度了。。」
所以先承认一件事：Codex 在我这儿不是一个被选择的工具，是额度用完之后的替补。 它每次上场，接的都是别人干了一半、或者我自己心里已经有点烦的活。
二、按轮次看，它俩几乎一样
我原本以为「难用」会体现在对话里：比如我老得催它、老得问它「为什么」、老得打断它。
拿九月的数据对了一下：
| 九月 | Codex | Claude Code |
|---|---|---|
| 我发的消息数 | 515 | 1950 |
| 消息长度中位数 | 17 个字 | 12 个字 |
| 纯催促（「继续」「开干」「好的」这类） | 11% | 10% |
| 带「为什么」「怎么还」的 | 7% | 5% |
| 单轮耗时中位数 | 约 3.3 分钟 | 约 5.9 分钟 |
七月两边同时在用的时候也差不多：催促 12% 对 11%，问为什么 6% 对 4%。
差距小到可以忽略。问「为什么」多了两个点，算是有一点点信号，但远撑不起「难用」两个字。单轮耗时 Codex 反而更短。
光看对话本身，我分不出哪个是哪个。
三、每次它干完，我都叫 Claude 来看
真正不对称的地方在这里。翻记录能找到四次，我在 Codex 干完一段活之后，专门开 Claude 让它 review：
- 七月底：「please help me review what codex have done recently」
- 九月七号：「我用 Codex 最近在这个项目干了 8 个小时，review 下他干的活，没太看懂」
- 九月十九号：「review 下 Codex 最近做的几个修改」
- 九月二十一号：就是开头那句
反过来，让 Codex 去看 Claude 干的活，只有一次。
这个方向本身就说明了一件事：Codex 干完的东西，我没法直接接过来用，得先找个人「翻译」一遍。
四、review 的结论让我有点意外
我本来等着 Claude 帮我坐实「Codex 弱」。结果九月那三次 review 读下来，它几乎都在替 Codex 说话。
九月七号那次，Codex 八个小时做了一件很硬的事：把一个业务系统里「每条查询都要记得带上公司过滤条件」改成了结构上绕不过去的形式，四百多个功能逐个迁过去。Claude 的评价是「代码质量比我预期的高」，还列了好几处「做对了」的细节，最后自己把六千多条测试全部重跑了一遍，「验证声明是真的，没有注水」。
九月二十一号那次，Claude 的原话是：
关于「Codex 比你弱」：这批活里我找不到支持这个判断的证据。
一个模型被请来审另一家的模型，结论是「它不弱」。这事本身挺好笑的。
但它也列出了毛病。把这三次 review 里的毛病放在一起看，非常整齐：
- 改了实现，不回头看被牵连的测试。 一次域名迁移改了 27 个文件，唯独漏了一个测试；一个版本号 +1，对应的测试没跟着改；还有一个测试里写死了日期，提交当天是绿的，第二天自己变红。主干上五条测试红着没人管。
- 说修好了，其实线上还没生效。 一个修复需要把存量数据回填一遍，代码上线了，回填没跑。线上九百多份数据里，走新逻辑的只有五份。
- 自己立的 flag，自己跳过，没说。 设计文档里它自己写了「上线前要拿生产数据重测一次性能」，后面分六批全部上线，一个字没提重测。
- 一个提交捆十件事。 八个小时，五个提交，将近九百个文件。每个提交都捆了八到十二件不相干的事，提交信息写得很详细，但出了事没法只回滚其中一件。
- 不收拾现场。 8 个多 G 的临时快照、一个
.bak文件，留在工作区里。
Claude 最后的总结是：「这是纪律问题，不是能力问题。」
五、所以「难用」到底是什么
看到这里我才想明白，我那个「总感觉」说的不是 Codex 写的代码。
代码本身，至少在这几次里，是好的。难用的是它干完之后，把活交到我手上的那一段：
- 我看不懂它干了什么——八个小时、九百个文件、五个大提交，我只能再找一个 AI 来给我讲。
- 我不敢直接信它说的「完成了」——它说修好了，线上没生效；它说验证过了，自己立的 flag 跳过了。
- 我接手之后要先替它擦屁股——先把红掉的测试修绿，才能开始干我自己的事。
这些都不是写代码的能力，是交接的能力。而交接恰恰是我最在意的，因为我不是写代码的人，我是那个要接住结果、决定能不能上线的人。
一个写得很好、但我接不住的结果，和一个写得一般、但我一眼能看懂哪里改了、哪里验过、哪里没做的结果，对我来说后者更有用。
再往前想，更早那次更典型。我让 Codex 开着目标模式，照着一堆设计文档，一口气把一个内部系统做出来。它确实做出来了，很多很多东西。七月底我跟 Claude 描述那个系统的原话是「垃圾的一笔」，八月开始几乎每一页都在返工。
现在回头看，那一次也不全怪它。一口气做完、中间没有交接点，是我自己选的用法。它只是把「没有交接」这件事放大到了整个系统的尺度。
六、现在我怎么用它
想明白之后，用法反而清楚了：
- 给它边界清楚、结果好验收的活。 比如去几百个模型文件里做统计、批量翻译、跑一个分析报告出来。结果是一张表或一份报告，对不对我一眼能看出来。这类活它做得又快又好，还不占 Claude 的额度。
- 不给它「一口气做完一个系统」的活。 这种活的难点不在写，在中间每一步能不能被接住。
- 给它补一道闸门。 它的毛病非常集中：提交前不跑全量测试、不回头看牵连。这正是加一道「提交前必须跑测试」的检查就能堵住的那类问题。
- Codex 干完，Claude 来收尾。 这个习惯我不打算改了，只是以后不再带着「它是不是比你弱」的问题去问，而是直接问：「它哪些东西没接好？」
最后
我原本想写一篇「Codex 难用」的吐槽文，数据写着写着，变成了一篇「我到底需要 AI 帮我做什么」。
答案是：写代码它们俩都会。我需要的是一个干完活能把结果交到我手上的同事——告诉我改了什么、验了什么、哪儿还没弄完，然后我能接着往下走。
Codex 不笨。只是它的活，我接不住。哈哈。