一个 14 万行 C++ 的项目，两套本地 clone，两个终端窗口并排。同一条 prompt，相隔两秒送到 Codex（GPT-6 Astra）和 Claude Code，两边都是 xhigh 推理。

任务是把一份双方都签过字的 review 结论修掉。没有换 prompt，没有换代码库，没有一边多喂上下文。两秒之后两台机器分头走，六小时后收工，出来的东西不一样。

做这个实验的人叫 gctwnl，从四月起用 LLM 从零写一个可视化建模应用，自己一行代码没写。到现在这个项目有 14 万行 C++、约 1.5 万行稳定文档，另有 3 万行用过就归档的临时文档。他算过账：实际付出去大约 €600，按 token 原价折算接近 €26,269。他写这个数字的意思是，这种玩法撑不久。

那道题本身#

review 里最严重的正确性问题是：对文档的改动可以绕过 undo 历史。

具体场景不复杂。移动一个带正交走线的元素，关系线跟着重新路由，换了 bendpoint，这是对的。撤销一步，元素回到原位，bendpoint 没回来，这就是 bug。

但作者之前的分析已经写了：这段代码太容易犯这类漏，光补这个 bug 不够，得从结构上改。所以这题的分量在架构上。

前两分钟#

Claude 在两分钟内回来了，带着问题。它问的核心是：这个洞怎么堵。

它先给了一个 guard 方案。任何改数据的函数都要报告这次改动有没有被接受，被拒就拦住。然后它自己点出这个方案的弱点：保护只是约定，每个函数都得记得调用 guard，少写一行洞就还在。

作者接着问了一句：将来多个用户并发使用的时候，哪个方案更合适。这个问题把判断推向了另一个方向。Claude 改口，推荐从根上改：每个存储的值都包进一个类型，只能通过唯一一条受保护的路径修改，保护跟着类型走，不再依赖谁记得住。undo 历史只记录发生变化的字段。

它写了九阶段的计划，作者批准，它开始干。

六小时之后的 Codex#

Codex 没问。它直接开工。

一小时后，它交出来的东西大致相当于 Claude 那三个选项里最便宜的一个：加了 guard，把两类数据封起来不让直接访问。但大部分函数仍然不报告被拒的改动，保护依然靠自觉。

三点五小时左右，Codex 自己发现还有两个问题没关掉。其中一个挺要命：被拒的改动被静默丢弃，操作剩下的部分继续拿着半套数据往下走。然后它调头，转向那个根本方案，把存储的值也包了起来。

六小时，一次跑完，也没等谁批准任何一步。

两份代码的距离#

都封了一层 wrapper，里面装的东西不一样。

Codex 的 wrapper 护的是原有的 undo 历史，那份历史存的是整条记录改动前后的副本。Claude 把这份历史换掉了，改存变化过的字段，由一张字段清单驱动，保存、复制粘贴、撤销三条路径读同一张表。

关于谁有写权限，Claude 只留了一条规则：活文档和正在构建的副本之间划一条线。Codex 也划了这条线，旁边还挂了一个独立的豁免。

两边都把「找记录的 owner」换成了直接指针。更快，也更脆，指针会失效。

让没写这份代码的人来评#

两份都跑完，作者让 Codex 去比。值得看的是 Codex 怎么评自己，结论反倒次要：它的方案 as it stands 更适合直接采用，Claude 的方向更强但有严重缺口。

它给 Claude 那边找了三个反例。导入时给标识符重新编号，仍然绕过 undo 历史；后台算好的布局，可能在视图已经变了之后才被应用；文件格式做了不兼容的改动，却没升版本号。作者回代码里核对，三个都存在。

Codex 也列了自己方案的问题。然后它坚持「直接采用」那条判断，补了一句：作为继续往下建的地基，它条件性地更看好 Claude 的。

最后作者选了 Claude 的。

先泼一盆冷水#

这只是一次实验。

作者自己写了：把一个 LLM 从完全相同的状态再跑一遍，几乎保证结果不一样。差异可能很小，也可能很大。他举的例子是 Claude 从 guard 方案跳到架构方案，起因是回答了一个技术上关系不大的问题。

能下的结论只到这里：这一次它没问，而没问本身有代价。至于 Codex 是不是总不问，这次实验说明不了。

六小时对两天，谁快#

账面上 Codex 赢得很干脆：一次跑完六小时。Claude 花了九阶段、跨两天，中间还因为撞到用量上限停过。

但该问的是：这六小时交出来的，是不是能留下的。

从时间线上看，那六小时里大约三个半小时用来追回一个本该在开头就问出来的问题。它不是不懂得更根本的做法，它是把便宜方案做完才发现便宜方案不够。顺序上的这个差别，代价是返工。

另一件事我觉得更值得记：Codex 自己回过头发现了漏洞，而且改了方向。一个不问就干的工具，如果干完还能自己看出没干对，它还救得回来。真正麻烦的是不问、也不回头。

我不认为这说明 Codex 不行#

作者退掉了那个 €100 的 OpenAI 订阅。他给的理由里，可靠性是一半，撑不住项目规模是另一半：Codex 的默认上下文大约是 Claude 那 100 万 token 的四分之一，拉到顶能到四分之三。

14 万行代码加两万行文档，手上三分之一的内容是文档不是代码。这个体量下，上下文就是硬约束，改 prompt 补不上。

但同一篇文章里也有反向的证据。作者说，他聊过的人里不少对 Codex 满意，共同点是他们手上的代码库背后有多年高质量的人工工程史，模型是在一个扎实的地基上找 bug、加功能。Codex 在这类项目里表现好，不是偶然。

所以「Codex 不行」这个结论只在一种前提下成立：项目足够大，文档和代码缠得足够深，而你又没打算在开头花时间把问题替它问清楚。

用 Codex 时，把该问的问题替它问掉#

Claude 这次赢的那一点，是它逼着作者在动手前把「将来要支持多用户」摆到台面上。这条信息作者脑子里有，文档里也写着，就是没进 prompt。

Codex 不会替你去挖。你给它一条任务，它按最合理的理解做到看起来完成，然后停。边界清楚的任务上这是优点，一句话概括不了的任务上这就是账单。

能做的很土：把「完成」的定义写出来，写清楚哪些模块不许碰，写清楚这次改动要为将来的什么需求让路。或者干脆要求它先出方案再动代码，别指望它会在中途停下来问你。

参考来源：