https://codexer.com/tags/%E7%BC%96%E7%A8%8B%E4%BB%A3%E7%90%86/Recent content in 编程代理 on CodexerHugozh-cnMon, 02 Nov 2026 06:50:00 +0800https://codexer.com/posts/2026-11-02-codex-same-prompt-two-seconds-apart/Mon, 02 Nov 2026 06:50:00 +0800https://codexer.com/posts/2026-11-02-codex-same-prompt-two-seconds-apart/<p>一个 14 万行 C++ 的项目，两套本地 clone，两个终端窗口并排。同一条 prompt，相隔两秒送到 Codex（GPT-6 Astra）和 Claude Code，两边都是 xhigh 推理。</p> <p>任务是把一份双方都签过字的 review 结论修掉。没有换 prompt，没有换代码库，没有一边多喂上下文。两秒之后两台机器分头走，六小时后收工，出来的东西不一样。</p> <p>做这个实验的人叫 gctwnl，从四月起用 LLM 从零写一个可视化建模应用，自己一行代码没写。到现在这个项目有 14 万行 C++、约 1.5 万行稳定文档，另有 3 万行用过就归档的临时文档。他算过账：实际付出去大约 €600，按 token 原价折算接近 €26,269。他写这个数字的意思是，这种玩法撑不久。</p> <h2 id="那道题本身">那道题本身</h2> <p>review 里最严重的正确性问题是：对文档的改动可以绕过 undo 历史。</p> <p>具体场景不复杂。移动一个带正交走线的元素，关系线跟着重新路由，换了 bendpoint，这是对的。撤销一步，元素回到原位，bendpoint 没回来，这就是 bug。</p> <p>但作者之前的分析已经写了：这段代码太容易犯这类漏，光补这个 bug 不够，得从结构上改。所以这题的分量在架构上。</p> <h2 id="前两分钟">前两分钟</h2> <p>Claude 在两分钟内回来了，带着问题。它问的核心是：这个洞怎么堵。</p> <p>它先给了一个 guard 方案。任何改数据的函数都要报告这次改动有没有被接受，被拒就拦住。然后它自己点出这个方案的弱点：保护只是约定，每个函数都得记得调用 guard，少写一行洞就还在。</p> <p>作者接着问了一句：将来多个用户并发使用的时候，哪个方案更合适。这个问题把判断推向了另一个方向。Claude 改口，推荐从根上改：每个存储的值都包进一个类型，只能通过唯一一条受保护的路径修改，保护跟着类型走，不再依赖谁记得住。undo 历史只记录发生变化的字段。</p> <p>它写了九阶段的计划，作者批准，它开始干。</p> <h2 id="六小时之后的-codex">六小时之后的 Codex</h2> <p>Codex 没问。它直接开工。</p> <p>一小时后，它交出来的东西大致相当于 Claude 那三个选项里最便宜的一个：加了 guard，把两类数据封起来不让直接访问。但大部分函数仍然不报告被拒的改动，保护依然靠自觉。</p> <p>三点五小时左右，Codex 自己发现还有两个问题没关掉。其中一个挺要命：被拒的改动被静默丢弃，操作剩下的部分继续拿着半套数据往下走。然后它调头，转向那个根本方案，把存储的值也包了起来。</p> <p>六小时，一次跑完，也没等谁批准任何一步。</p> <h2 id="两份代码的距离">两份代码的距离</h2> <p>都封了一层 wrapper，里面装的东西不一样。</p> <p>Codex 的 wrapper 护的是原有的 undo 历史，那份历史存的是整条记录改动前后的副本。Claude 把这份历史换掉了，改存变化过的字段，由一张字段清单驱动，保存、复制粘贴、撤销三条路径读同一张表。</p>