在 GPT 5.6 刚发布的时候，我曾经觉得它搭配 Codex 的使用体验非常出色。主要原因是当时 GPT 5.6 的 FAST 模式速度极快，而且写文案的表达能力比起之前的 GPT 5.5 有了明显飞跃。GPT 5.5 以前的语言组织常常显得生硬，而 GPT 5.6 改善了许多。不过，如果真要让 5.6 Sol High 去写长篇复杂的文案，依然会让人觉得有些费劲，文字风格偏晦涩。

随着最近在真实复杂项目里使用越来越深，我对 GPT 5.6 的困扰也越来越多，主要集中在额度消耗、文档偏离、测试形式主义以及上下文的过度防御上。

用量与额度机制的收紧

最直接的问题是用量根本不够用。

GPT 5.6 划分了三个档位：5.6 Sol、5.6 Terra 和 5.6 Luna。在实际开发中，真正能胜任复杂任务的其实只有 5.6 Sol。如果在复杂逻辑里使用 Terra 或 Luna，产出质量比 Sol 差得非常明显。虽然它们是阶梯定价、调用成本低很多，但在我的复杂项目里，Terra 和 Luna 目前只适合分配给子 Agent 去处理极其明确的局部任务。

而 5.6 Sol 本身的价格非常高昂。在 GPT 5.5 时期，即便购买 200 美元的 Pro 订阅，全力使用也很难耗尽那个 5 小时的动态额度。但现在的 GPT 5.6 把 Pro 订阅调整成了按周计费的限额模式，取消了原来的 5 小时限额机制。如果我们开启 FAST 模式，可能只要集中高强度使用一天，就会把整整一周的配额全部耗尽。

面对额度紧张，目前主要有几种应对手段：调低模型的思考深度、主动关闭 FAST 模式，或者把清晰的任务交给低成本的子 Agent。比如我平时会使用自己开源的 codex-team-mode Skill，在里面配置几个基于 Luna 模型的子 Agent，专门负责代码库探索或执行边界极窄的单项任务，以此节省主模型的额度。

臃肿的文档与形式主义测试

除了额度吃紧，GPT 5.6 最近在处理具体需求时，很容易出现过度发挥的问题。它写出来的方案文档往往极其冗长，阅读成本很高。

这并不是单纯的风格偏好。我平时也频繁使用 Grok 和 GLM 等其他模型，它们给出的技术方案结构清晰、条理分明，一眼就能看清可以落地的步骤。但 Codex 搭配 GPT 5.6 编写的文档，会花大量篇幅罗列各种极端边缘情况，在主流程里加入许多我们根本没有提及的防范要求，属于典型的过度防御。

这就带来了一个实际困扰：如果不花时间逐行仔细审查它的方案，很难看清它到底夹带了哪些不相关的设计；更关键的是，它对真实业务逻辑本身的描述反而被稀释了，精力全部消耗在了钻牛角尖上。

到了实际编写代码的阶段，代码交付的质量同样容易受到这种思路的影响。它非常喜欢耗费大量 token 去编写一堆形式主义的测试用例。无论前端还是后端，很多测试更像是在完成一种自我证明的流程。比如一个极其简单的业务判断（类似「1 + 1 = 2」），它也要单独写一套测试去断言「1 + 1 = 2」。这种测试不仅白白浪费 token，还会导致后续哪怕只是微调一下业务代码，就不得不跟着修改大段前后端测试，维护负担非常重。

上下文膨胀与过度防御

前面提到的过度防御，在处理上下文时表现得更加严重。目前的 Codex 显得过于谨慎，哪怕我们只是让它改动一个非常小的局部逻辑，它也会主动去读取海量的项目代码，甚至试图把工作区里所有的开发规范文档从头到尾读一遍。

在小型代码仓库里，这种严谨性其实是优势，因为它能更精准地理解上下文、触发对应的 Skill 并遵循规范。但在稍大一点的代码库或者包含多个子项目的 Monorepo 里，它很容易把大量无关的配置和规范一股脑全部塞进上下文。

Codex 默认的上下文窗口是 20 万 tokens。随便读两个完整的规范文档，可能就会占用十几万额度。读完文档再去读业务代码，往往还没真正开始分析，就直接触发了上下文压缩。

一旦触发压缩，之前读取过的具体代码和 Skill 逻辑就会被压缩成摘要总结。为了准确修改，它又不得不重新从磁盘里去读取一遍业务代码。在终端前等它来回折腾，五六分钟过去了，一行有效代码都还没写出来。如果在赶时间处理紧急任务，这种停滞会让人非常难受。

虽然最近的 Codex 允许用户手动配置上下文上限，可以把最大上下文调到 100 万 tokens、压缩阈值调到 90 万 tokens，但正如前面所说，用量原本就极其紧张。一旦上下文超过 20 多万 tokens，超出部分全部会按双倍额度计费。在这种过度防御的读取模式下，如果真开启 100 万上下文，200 美元的 Pro 订阅很难支撑一整天的持续开发。

另外，前两周 Codex 确实存在比较明显的缓存 bug，导致额度消耗异常迅速。好在最近团队已经把这个问题修复了。在出 bug 的那段时间里，多亏 Codex 负责人 Tibo 在后台反复帮我们手动重置额度，才能勉强维持日常使用。

结合 Grok 的模型取舍

不过从整体来看，现阶段 Codex 的 Agent 工程架构依然足够成熟，在执行复杂且长链条的自动化任务时，GPT 模型的综合稳定性依然是首选。而且相比 Claude 严格的风控，GPT 的订阅开通门槛更低，获取更方便，所以在不少核心场景下依然是不可或缺的工具。

但在日常的很多实际开发任务中，我已经把不少工作交给了 Grok。Grok 4.6 搭配相应的 CLI 工具，体验非常轻快。它没有那种过度防御和过度缜密的包袱，推进速度极快，产出的代码质量也很扎实。

把 Grok 和 GPT 结合起来：用 Grok 快速完成清晰直接的代码实现，把复杂的多步编排留给 Codex 和 GPT，现阶段反而是效率更高、额度压力更小的工作方式。