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

之前我写过一篇文章 OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流，记录了我当时把 OpenSpec 和 Superpowers 组合成一套工作流的尝试。

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

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

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 还做了一轮 Native 和 Classic 的官方对齐实验。两种模式处理相同的 16 个业务任务，每个任务各跑 3 次，每种模式 48 次，总共 96 次运行。

完成质量有没有下降

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

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

执行成本降低了多少

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

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

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

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

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

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

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

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

上一篇文章 OpenSpec + Superpowers，SDD+TDD 双驱动 AI 编程工作流 里，我说用上 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，往往包含三类东西：

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

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

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

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

小结

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

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

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

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

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