一个任务烧掉 5 亿 token：GPT-5.6-Sol 失控复盘
GPT-5.6 发布之后，好多人都说 token 消耗巨快，还没怎么用，5 小时限额就刷完了。
恰好我最近也经历了一次任务失控、token 异常消耗，复盘后，总结出了以下几个方法：
- 非必要不开 Ultra 模式
- 卸载 superpowers、gstack 等重型 skill
- 给评审任务设置明确的终止条件
接下来，跟大家分享下这次任务失控的经历。
任务失控过程回顾
这个任务的背景是有个项目即将上线，希望在上线之前进行一次全面的审查，包含注册、登录、重置、计费、API 的数据面和控制面、部署流程、容灾机制等方面。
任务基本数据
为什么说这是一个失控的任务？看下 Codex 的统计数据就知道了：
| 指标 | 数据 |
|---|---|
| 总耗时 | 30 小时 22 分钟 |
| 实际耗时 | 9 小时 13 分钟 |
| 并行开发 worktree | 3 个 |
| 子 agent 数 | 36 次 |
| 三个开发分支提交 | 65 个 |
| 累计消耗 token | 5 亿 |
| 最长单项完整评审 | 5 轮 |
| Task 15 设计及 RED 迭代 | 至少 8 轮，仍未通过 |
| 初始全面审查发现 | 24 项：7 Blocker、15 Major、2 Minor |
| 发布计划终止进度 | Task 1–14 完成；Task 15 未实现；Task 16–20 未开始 |
这个任务经历了 2 次官方重置，额外使用了 1 次重置次数，仍然多次达到 5 小时限额的情况。在觉察到任务失控的迹象后，手动终止了任务。
补充一句，我开的是 Pro 20x 会员（200 美元/月），由此可见这个任务 token 消耗有多夸张。
任务复盘
虽然这个任务不算小，但是以 GPT-5.6-Sol 的能力，不应该出现失控。我和 Codex 针对该任务进行了详细的复盘，发现了 3 个原因。
原因一：GPT-5.6 模型特性
任务使用的模型是 GPT-5.6-Sol，推理等级是 Ultra。
1、GPT-5.6-Sol 写代码太严谨
在 Gert Labs 的 GBENCH one-shot coding 榜单中，相近得分下，Sol 的平均提交体积约为 Fable 5 的 2.1 倍。
体积差在哪？GPT-5.6 喜欢写防御性代码——给各种边界条件甚至不可能发生的情况写类型检查、层层包裹的错误处理、毫无必要的间接层等。
也许有人会问：代码写得严谨难道不是好事吗？
还真不一定。
举个例子，大家在工作中肯定都遇到过一种场景，就是在讨论一些事情的时候，总有一些“杠精”，各种假设，各种质疑，无限扩展。你说“杠精”说得对吗？也对；能照做吗？当然不能。
因为所有事情都需要考虑成本。
2、推理等级使用 Ultra
下面是官方对 Max 和 Ultra 的介绍：
| 模式 | 官方定义 | 适用场景 |
|---|---|---|
Max | 让一个 agent 用更多时间深入推理 | 单个极难问题、复杂状态机、竞态、关键架构决策 |
Ultra | 最大推理，同时可以主动把任务委派给子 agent | 能清晰拆成多个独立部分的复杂任务 |
Ultra 相比 Max，思考预算并没增加，增加的是人头，官方发布页写它默认并行协调 4 个 agent。
GPT-5.6-Sol 叠加 Ultra 模式，直接开启“杠精”模式，还是多人的那种。
原因二：skill 内置的评审流程被多 agent 放大
这个原因有点反直觉——强大的 skill（superpowers 和 gstack）反而加速了失控。
失控主要发生在开发阶段，我的要求是这么写的：
好，现在基于三份设计，拆分三个分支（worktree），并行进入开发阶段，开发阶段采取开发-评审迭代循环方式，直至达成一致。开发过程使用 superpowers 和 gstack 相关 skills 进行。先说这两个 skill 是什么。superpowers 是一整套强制性的开发框架，内置了 TDD、spec 合规检查、代码质量评审等环节，而且评审是循环的——发现问题 → 修复 → 再评审，直到通过。gstack 类似，包含 31 个 skill，覆盖架构评审、QA 评审等，同样内置了多层评审。
在普通模型上，这些约束能起到”矫枉”的作用。但 GPT-5.6-Sol + Ultra 模式下，Ultra 会同时启动多个 agent，每个 agent 都独立触发 skill 内置的评审流程。多个 agent 并行做对抗评审，越抠越细，”矫枉”直接变成了”过正”。
X 和 LINUX DO 上有大量用户反馈了同样的问题：GPT-5.6-Sol 下使用 superpowers，token 消耗速度异常快，卸载后立刻恢复正常。
原因三：提示词没有明确评审任务终止条件
在上面的任务要求中，我写了这么一句 “开发阶段采取开发-评审迭代循环方式，直至达成一致”——要求多个“杠精”达成一致，但没有给出明确的终止条件。
于是出现“评审棘轮”：每轮都能找到新的理论边缘情况，新问题只增加、不减少，最终从“上线前修复现有问题”滑向“证明系统在所有异常情况下都形式化正确”。
这个任务中，子任务 Task 15 对抗式开发-评审 8 轮，在一行功能代码都没写的情况下，先写出了 6000 行测试代码。如果不是手动终止，天知道最终会迭代多少轮、写多少测试代码。
所以，最终结论就是：
严谨的 GPT-5.6-Sol + Ultra 多 agent 模式 + skill 内置评审循环 + 无终止条件 = 任务失控 + token 消耗灾难。
开头的三个方法——关 Ultra、卸 skill、加终止条件——分别对应这三个原因。
最后
这次失控，归根结底是给模型加了太多东西——Ultra 模式、superpowers、gstack、开放式评审要求——每一个单独看都合理，叠在一起就是灾难。
模型能力到了 GPT-5.6-Sol 这个级别，很多活已经不需要”外行“（外部 skill、用户）来指导了。与其花时间约束模型怎么干活，不如把精力放在说清楚需求上。