我原本以为，这场对比没什么意思：同一份性能优化提示词，同一个 Minimax M3 模型，换两个编码工具跑一跑而已。结果差别大到让我没法再把它当成一次普通的工具切换。

这不是工具排行榜。我没有多轮、可公开复现的基准，只能记录昨天这个现场：Claude Code 把我交代的活落到了地上；Codex 则运行了一个多小时，到我停止时，没有产出值得保留的优化。

我给它们的规矩只有四步

性能优化最怕改动越堆越多，最后既不知道哪一刀有效，也没法干净地退回来。所以这次我把规则卡得很死：一次只做一个小改动，立刻验证，对照性能数据；有效就留下，无效就回退。

模型用的是 Minimax M3。我知道它未必能一下找到什么大招，所以我更在乎它会不会守住这四步。这里的“性能数据”是我在任务里用来决定保留还是回退的结果；具体代码、指标数值和基准细节不在本文公开，因此这不是可复现的性能测评。

我对齐了提示词、模型和任务目标；工具自身的上下文、命令调用、默认工作流，以及运行环境和版本等变量，并没有被做成严格控制。本文要记录的，是这一次工作流体验和交付过程的不同，不是严格的工具横评。

让我服气的不是二十分钟

Claude Code 大约二十分钟完成。这里的“完成”，是指它给出了经本次验证后我选择保留的改动；这个时长也只是我对这一次执行的观察，并不是它的稳定耗时承诺。

真正让我改观的不是时间数字，而是后来翻任务文档时看到的过程。文档把每一轮的尝试方向、改动后的结果，以及保留或回退的决定排在一起。我能顺着它接手：知道哪个方向继续，哪个方向到此为止。

这件事在性能优化里很值钱。哪怕某一轮没有结果，也不等于白烧时间——它至少留下了一个被排除的方向。更重要的是，我写进提示词里的规则没有停在提示词里，而是变成了实际工作节奏。

反过来看 Codex 那次，它未必什么都没做，但最终没有留下我能核对的“改动—数据—决定”链条，也没有产生我愿意保留的优化。性能任务里，跑得久不等于多做了事；没有证据把改动和结果扣起来，久有时只是更贵的迷路。

我当然不会用一次任务给产品判死刑，更不会宣布谁全面领先。这次差异也可能来自任务拆解、工具调用、上下文管理、验证循环、默认权限或运行环境等因素。至于我听到的 Claude Code 受限消息，我没有核验，本文不据此推断任何厂商动机。

但在这个具体现场里，我确实佩服 Claude Code 的落地能力。对我来说，能力受限的模型只要被放进“小改、验证、记账、回退”的流程里，也能一步步把结果挪出来；没有这套约束，屏幕上再多改动，也不等于留下了一次可用的性能优化。

“适配更好”只是下一轮要验证的猜测

我的第一个猜测是：Minimax M3 在 Claude Code 里，是否更容易被带进这种节奏？这只是猜测，不是结论。也可能根本不是模型适配，而是 Claude Code 在任务拆解、执行约束和验证闭环上，更能把同一个模型推着往前走。

要把这个问题说得更硬，需要同一份代码、同一套基准、相近的环境和更多轮次；还要把各自的改动、数据、回退和最终验收条件都留下来。否则，我最多只能说：昨天这一单，体验差距非常明显。

OpenCode 还没测，正好可以放进下一轮。我会继续沿用这套约束，记录每次改动、数据和回退。最后比的不是谁说得漂亮，而是谁留下了我能继续接手的结果。

参考资料

本文基于作者亲历记录，未引用外部资料。

写作附记

原始提示词

$blog-writer 阿里云发新闻禁用了 claude code，市场都知道他家喜欢搞小动作，但是昨天的开发任务，让我佩服他的落地能力，一样的提示词，都是做性能优化，对接一样的模型，都是 Minimax M3 模型，由于模型能力比较弱，我指定了每次小改，逐步验证，对比性能数据，有效果保留，没效果就回退。codex 跑了一个多小时，什么有用的都没折腾出来，claude code，二十分钟做完了，翻看文档记录，清楚的记录了每轮的尝试方向，迭代以后的效果。我可以说是 Minimax 就是对 claude code 适配更好，确实他家有先发优势，各家都要适配他的 claude code，但是这个差距也太明显了。opencode 还没去测试，空了再去试试。