# GPT-5.6 之后，Superpowers 可以卸载了


![GPT-5.6 之后，Superpowers 可以卸载了](https://img.lixueduan.com/ai/cover/gpt56-superpowers-skill.jpg)

之前我写过一篇文章 **[OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流](https://www.lixueduan.com/posts/ai/21-openspec+superpowers/)**，记录了我当时把 **`OpenSpec`** 和 **`Superpowers`** 组合成一套工作流的尝试。

那时候我觉得这两个东西搭在一起还挺顺，OpenSpec 负责需求和 Spec 对齐，Superpowers 负责计划、TDD、子 Agent 实现和代码审查。

后来，我发现社区里很多人也在用这套工作流，先写需求和设计，拆任务，再实现和验证，大家都在试图给 Agent 加一套更稳定的工作方法。

<!--more-->

## GPT-5.6 之后，Superpowers 还需要吗

这件事本来挺美好的，直到 GPT-5.6 出现。

我用 GPT-5.6 Sol 做一个很简单的需求，本来以为读一下代码、改完、跑个测试就结束了，结果任务跑了很久。

看执行过程发现 Codex 并不是卡住了，而是 Superpowers 把头脑风暴、计划、子 Agent 实现、TDD 和代码审查一层层串了起来，一个简单需求就被升级成了一套完整的软件工程流程。

而在社区里，我也看到了很多类似的使用反馈，大致可以分成两类：

* **卸载后的体感更轻。** Agent 思考的时间短了一些，做出来的结果却大差不差。
* **通用流程出现重复。** Superpowers 会串起头脑风暴、计划、子 Agent、TDD 和代码审查，但 Codex 自己也在规划和验证，MCP 与本地 Skills 里还可能有另一套规则。

当然，这里也不能把变慢全部归到 Superpowers 身上。

> 从使用体感看，GPT-5.6 Sol 本身就比 GPT-5.5 慢。再叠加头脑风暴、计划和 Review 等完整流程，等待时间和额度消耗又被进一步放大。

所有讨论最后都落到了同一个问题上：**GPT-5.6 Sol 模型能力已经这么强了，还要不要继续使用 Superpowers 这类 Skill？**


## Comet Native 工作流：放松过程，收紧结果

只靠使用体感，很难回答前面的问题，或者说可信度不够。

恰好 Comet 最近做了一次很有参考价值的调整，新增了 Native 模式。

### Native 到底改了什么

`0.4.0-beta.7` 新增了面向强模型的 Native 模式。

原来的 Classic 模式会串联 OpenSpec 和 Superpowers，依次经过 Open、Design、Build、Verify、Archive。

Native 不再依赖这两个外部 Skill，只保留 Shape、Build、Verify、Archive 四个阶段：
* Shape 阶段先和人讨论需求，把目标、范围、不做什么、验收示例和风险边界写清楚。
* 进入 Build 之后，怎么规划、要不要写计划、测试做到多深、怎么调试和审查，都交给模型自己决定。
* Verify 再拿前面定义的验收条件逐项核对，失败就带着未满足项返回 Build，通过后才进入 Archive。

它的思路很直接：**过程放松，结果收紧。**

Native 没有去掉验证，只是不再强制模型按照固定的方法完成任务。外层工作流负责锁住验收规则、验证证据和风险边界，具体怎么实现则交给模型决定。

**具体如何完成任务交给模型自由发挥，我们要做的就是完成后验证任务是否真的完成**。

![Comet Classic 与 Native 工作流对比](https://img.lixueduan.com/ai/comet/comet-native-classic-workflow.jpg)

Comet 还做了一轮 [`Native` 和 `Classic` 的官方对齐实验](https://docs.comet.rpamis.com/zh/eval/comet-native-vs-040-experiment)。两种模式处理相同的 16 个业务任务，每个任务各跑 3 次，每种模式 48 次，总共 96 次运行。

### 完成质量有没有下降

![Comet Native 与 Classic 完成质量对比](https://img.lixueduan.com/ai/comet/comet-native-quality-comparison.svg)


* `pass@1` 单次运行的成功率，反映模型不依赖重试、一次完成任务的能力。
* `pass@3` 是三次里至少成功一次，代表这个任务能不能做。
* `pass^3` 更严格，要求三次全部成功，看的则是能不能稳定地做。

两种模式的 `pass@3` 都是 100%，说明去掉 OpenSpec 和 Superpowers 之后，Native 没有丢掉这 16 个任务的覆盖能力。反而在单次严格通过率和三次连续成功率上更高。

### 执行成本降低了多少

为了避免「任务提前失败，所以看起来更省」这种误差，官方报告这里只统计 Native 和 Classic 都严格通过的 41 组配对样本。

![Comet Native 相对 Classic 的执行资源降幅](https://img.lixueduan.com/ai/comet/comet-native-efficiency-reduction.svg)

> *效率图将 Classic 归一化为 100%；数据只统计两种模式都通过的 41 组配对样本，表中均为单个成功样本的平均值。*

最明显的是，总 Token 下降了 76.8%，模型成本下降了 75.1%，Agent 轮次和工具调用也减少了一半以上。

**在这组实验里，流程变轻之后，任务覆盖没有下降，执行成本却明显降低了。**

> 当然，这只是 Comet 的第一方实验，不能直接外推到所有模型和任务。  
> 但至少在这 16 个任务里，去掉固定方法论后，完成质量没有下降，执行成本却明显降低了。

## 通用能力正在被模型和 Runtime 内化

但数据只能告诉我们发生了什么，解释不了为什么。

我倒不觉得是 Superpowers 突然没用了。

上一篇文章  **[OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流](https://www.lixueduan.com/posts/ai/21-openspec+superpowers/)** 里，我说用上 Superpowers 之后，代码质量比让模型直接动手好不少。这个判断放在当时依然成立。模型容易跳过设计、忘记测试，Superpowers 就用一套完整的需求讨论、计划、TDD 和 Review 流程把这些缺口补上。

但现在，大人，时代变了。😏

**Superpowers 没变，变的是模型。**

对强模型来说，能力瓶颈已经不在「会不会写代码」，而在「能不能被信任地完成任务」。

GPT-5.6 已经会主动理解需求、调查代码、形成方案，再根据改动风险选择测试和验证方式。很多过去需要 Superpowers 反复提醒的工作习惯，模型自己已经学会了。

这时再套上 Superpowers，一个简单需求就可能重新经历 brainstorming、计划、TDD 和独立 Review。两套流程未必会得出相反结论，但每多一个 Agent、每多一次 Review，都要重新读取上下文并调用模型。如果没有发现新的问题，增加的就只有 Token 和时间。

**问题不是模型和 Skill 在打架，而是通用 Skill 的边际收益正在下降。**

为什么会这样？我觉得有两层变化。

**一部分能力，被模型学会了。**

规划、调试、测试和自我检查都是通用方法，还能通过代码、测试与评测反复验证。使用轨迹积累得足够多，后续模型自然有机会把这些习惯吸收进去。

**另一部分能力，被 Agent Runtime 接管了。**

任务状态、子 Agent 调度、工具调用、上下文压缩和结果验证，已经逐渐成为 Codex、Claude Code 这类产品的原生能力。过去需要 Skill 串起来的执行循环，现在 Runtime 自己就能跑。

所以 Superpowers 不是变差了。它原本负责解决的问题，一部分进入了模型，另一部分进入了 Runtime。

## 什么样的 Skill 会被长期保留下来

**我的答案很直接，垂直 Skill。**

这里说的垂直，不只是某个行业专用的 Skill，而是那些带着具体团队、具体项目和真实业务环境的 Skill。

**越接近通用方法论，Skill 的生命周期反而越短**。

因为它可以在大量任务里反复运行和评测，有效的方法最终可能进入模型训练，或者直接成为 Codex、Claude Code 这类 Agent Runtime 的原生能力。

就像一个特别好用的第三方插件，如果它解决的是所有用户都会遇到的问题，最后很可能被官方直接集成。能力还在，只是大家不再需要单独安装它。

Skill 也是一样。今天还要额外挂载的规划、测试和审查流程，明天可能就会成为默认能力。

**但有些东西，通用模型不会预先知道。**

真正会被长期保留下来的 Skill，往往包含三类东西：

* **模型不知道的私有知识。** 团队怎么协作、文档放在哪里、项目有哪些特殊约定。
* **模型拿不到的执行能力。** 内部系统、专用工具、账号与权限。
* **模型不能擅自决定的边界。** 什么结果才算完成，发布前需要谁确认，出了问题由谁负责。

![强模型时代长期保留的 Skill](https://img.lixueduan.com/ai/skill/skill-value-boundaries.jpg)

这些信息敏感、零散，还会随着业务不断变化，很难进入通用模型的训练数据，却决定了 Agent 能不能在真实环境里完成工作。

> **真正会留下来的 Skill，解决的是模型不知道、拿不到，也不能擅自决定的问题。**

这类 Skill 往往更简单，也更轻。它不负责教 Agent 怎么思考，只负责告诉它，在这里工作需要知道什么、可以调用什么，以及做到什么才算完成。

## 小结

**回到开头的问题，GPT-5.6 Sol 还需要 Superpowers 吗？**

答案很明确：对于 Fable 5、GPT-5.6 这类已经能自主规划和验证的强模型，我更倾向于**先移除 Superpowers，直接运行一段时间，再根据真实缺口补回必要的约束**。

Comet Native 的实验也提供了一个参考：在这 16 个任务里，去掉固定方法论之后，完成质量没有下降，Token、耗时和成本却明显减少。

现在的趋势是，通用 Skill 会逐渐被模型和 Runtime 吸收。真正长期留下来的，是模型不知道的私有知识、拿不到的执行能力，以及不能擅自决定的业务边界。

**Skill 不会消失，它只是会回到自己原本该在的位置。**


---

> 作者: [意琦行](https://github.com/lixd)  
> URL: https://www.lixueduan.com/posts/ai/25-skill-return-to-its-place/