GPT-5.6 Sol 还需要 Superpowers 吗？27 次运行后的答案

• 为什么要做这个实验
• 实验是怎么做的
• 最终结果
• 不同任务上的表现
• Full 为什么没有带来更高质量
• Completion 为零，是否意味着实验无效
• 我现在会怎么使用 Superpowers
• 对 SDD 流程的反思
• 对 Skill 设计的反思
• 实验的成本与限制
• 总结

为什么要做这个实验

过去在 Codex 中使用 Superpowers 时，我有一个很直观的感受：它能让流程变得更完整，但也会让一次原本简单的开发任务出现更多计划、确认和收尾步骤。

这种变化在能力较弱的模型上可能是必要的。结构化工作流可以提醒模型先理解需求、补测试、验证结果，减少它直接冲进代码后返工。但 GPT-5.6 Sol 本身已经具备很强的代码理解和执行能力，那么同样的流程约束究竟还在提高质量，还是已经变成额外负担？

只凭几次使用体验很难回答这个问题。一次任务做得好，可能只是任务简单；某个方案消耗更多 token，也可能真的换来了更可靠的实现。因此我把问题拆成三个对照组，做了一次固定基准实验：

1. Full：完整使用 Superpowers 工作流。
2. None：完全不使用 Superpowers。
3. Selective：只使用预先选定、理论上更有价值的部分能力。

我真正想知道的不是“Superpowers 好不好”，而是一个更具体的问题：在 GPT-5.6 Sol 上，流程约束带来的收益，是否足以覆盖它增加的时间和 token 成本？

实验是怎么做的

实验使用 gpt-5.6-sol，推理强度固定为 medium。任务、输入、运行顺序、评测和预算都由同一个控制器管理，三个方案面对相同类型的任务。

我选择了三个侧重点不同的 TypeScript 任务：

任务	主要考察内容
async-cache	异步缓存、并发合并、过期与异常行为
retry-scheduler	重试调度、指数退避、取消和边界条件
pricing-refactor	既有业务逻辑重构、兼容性和回归控制

每个任务在 Full、None、Selective 三个方案下各运行 3 次，总计：

3 个任务 × 3 个方案 × 3 次重复 = 27 个正式样本

正式运行前，每个方案还各执行了一个 canary，用来确认模型、沙箱、技能路径和结果采集链路能够正常工作。三个 canary 全部通过，并且不计入正式结果。

代码质量不是由模型自己评价。每个正式样本都会经过隐藏测试、回归与范围检查，再进入匿名盲评。盲评包不会暴露它来自 Full、None 还是 Selective，尽量避免审阅者因为工作流名称产生先入为主的判断。

除了质量分，我还记录了开发 token、墙钟时间、轮次和协议完成状态。这样可以把“代码写得怎么样”和“为了写出这些代码付出了多少流程成本”分开看。

最终结果

结果和我实验前的直觉并不完全一致。

方案	平均质量	平均开发 token	平均耗时	质量 / 10 万 token
Full	64.11	3,973,232	0.18 小时	1.61
None	72.56	1,111,707	0.08 小时	6.53
Selective	67.78	2,149,756	0.11 小时	3.15

在这组固定任务中，None 不只是最便宜，也是平均质量最高的方案。

与 None 相比：

• Full 的平均质量低 8.44 分，却使用了约 3.57 倍 token 和 2.13 倍时间。
• Selective 的平均质量低 4.78 分，使用了约 1.93 倍 token 和 1.35 倍时间。
• None 的 token 质量效率约为 Selective 的 2.07 倍、Full 的 4.05 倍。

如果分别绘制“质量—token”和“质量—时间”两张 Pareto 图，None 都是唯一未被支配的方案。换句话说，在这次实验里，不存在“多花一点成本就能获得更高总体质量”的交换关系：Full 和 Selective 都同时更贵、平均质量更低。

不同任务上的表现

总体平均值可能掩盖任务差异，所以我也按任务拆开看：

任务	Full	None	Selective
async-cache	74.00	82.00	80.00
retry-scheduler	42.33	57.00	44.00
pricing-refactor	76.00	78.67	79.33

None 赢得了 async-cache 和 retry-scheduler。Selective 只在 pricing-refactor 上领先 None 0.66 分，但为了这 0.66 分，平均使用了约 2.26 倍 token 和 1.35 倍时间。

这个结果至少说明了一点：即使某种选择性流程在重构任务上可能有帮助，也不能因此推导出它适合默认加载到所有任务中。任务类型和触发时机比“是否安装了一个完整工作流”更重要。

Full 为什么没有带来更高质量

从运行记录看，Full 的主要问题不是完全不会写代码，而是流程占用了过多注意力和执行机会。

部分运行会先创建规格、计划和检查清单，再等待阶段确认；有些运行已经产出不错的代码，却在收尾阶段继续处理分支选项和流程状态；还有样本在轮次耗尽时只留下文档，没有真正进入实现。

这些步骤单独看都合理。问题在于，当模型本身已经能理解任务、定位代码并主动验证时，把每个步骤都设为必经流程，可能会产生三类成本：

1. 上下文成本：技能说明、计划和阶段状态持续占用输入。
2. 机会成本：有限轮次被用于讨论流程，而不是修改和验证代码。
3. 终止成本：实现已经足够，但模型继续执行收尾协议，反而更容易触及轮次上限。

Full 的平均轮次是 5.33，None 是 4.33。轮次差距看起来不大，但 Full 的平均 token 达到 None 的 3.57 倍，说明成本不仅来自多一次交互，也来自每轮携带和生成了更多流程内容。

Selective 确实比 Full 更轻，但这次预设的选择方式仍然不够窄。它减少了部分仪式，却没有在总体质量上超过 None。

Completion 为零，是否意味着实验无效

这次报告里有一个看起来很奇怪的数据：Full、None 和 Selective 的协议 completion 都是 0%。27 个正式样本中，23 个以 model-failure 状态结束，4 个到达 turn limit。

这里的 completion 表示控制器是否观察到了规定的终止协议，而不是“有没有代码”或“代码能不能工作”。不少运行虽然没有完成最后的流程信号，但已经留下可以通过隐藏评测和盲评的实现。因此这些样本的质量不是按零分处理，而是按照最终产物实际评分。

这也暴露了本次基准的一个不足：终止协议对三组都过于严格，导致 completion 失去了区分能力。所以最终建议主要依据隐藏评测后的质量、token、时间和 Pareto 结果，而不是 completion。

如果以后继续做下一轮实验，我会先修改终止判定，让“实现完成”和“完整执行工作流收尾”成为两个独立指标。

我现在会怎么使用 Superpowers

这次实验之后，我不会再把 Superpowers 作为 GPT-5.6 Sol 的默认工作流。更合适的策略是：

默认 None，出现明确事件时，再调用一个足够窄的能力。

例如：

• 普通功能开发和小型重构：直接让 GPT-5.6 Sol 阅读代码、实现并验证。
• 遇到真实 bug、测试失败或难以复现的问题：单独使用系统化调试。
• 修改并发、缓存、金额计算等高风险行为：按需使用测试驱动开发。
• 准备宣称“已经完成”之前：执行一次验证检查。
• 需求确实模糊、存在多个产品方向时：再进行 brainstorming，而不是所有任务都先讨论。

这套策略甚至比实验中的 Selective 更窄。实验能够证明的是“预设 Selective 组合没有胜过 None”，不能证明每一个单项能力都没有价值。真正值得保留的，不是一个总是开启的流程包，而是需要时能够准确触发的工具箱。

对 SDD 流程的反思

这次实验也让我重新审视了 SDD（Spec-Driven Development，规格驱动开发）。需要先说明：本实验直接比较的是 Superpowers 的三种使用方式，并没有单独设置“有 SDD”和“无 SDD”的对照组，所以它不能证明 SDD 本身有效或无效。

但 Full 方案暴露出来的流程问题，和我实际使用 SDD 时遇到的摩擦很相似：如果每个任务都必须完整经历需求讨论、Spec、Plan、阶段确认、实现、Review 和 Ship，那么流程很容易从风险控制变成固定仪式。

我仍然认为 SDD 有价值，尤其适合下面这些情况：

• 需求存在多种解释，需要先固化边界和验收标准。
• 修改横跨多个模块、客户端或服务端，口头上下文很容易丢失。
• 任务会跨越多天或多人协作，需要可追溯的决策与交接材料。
• 涉及数据迁移、兼容性、安全、计费等不可轻易回滚的行为。
• 需要把产品需求、实现计划、测试证据和长期架构决策连接起来。

这些场景中，Spec 不是为了证明“我认真规划过”，而是在降低不同参与者对同一需求理解不一致的风险。Plan 也不应该复述 Spec，而应该记录实现顺序、依赖、验证方法和可恢复点。

问题出现在 SDD 被无差别地应用到所有任务时。一个文案修改、局部样式修复或边界清晰的小函数重构，如果也要创建完整 Spec 和 Plan，文档成本很可能高于变更本身。更糟糕的是，模型可能把“完成文档”误认为“完成任务”，最终留下结构漂亮的计划，却没有交付可运行的代码。

所以我现在更倾向于把 SDD 设计成一个按风险升级的分层流程：

任务级别	建议流程
小型、可逆、边界清楚	直接实现，说明改动范围并做聚焦验证
中等复杂度或存在行为变化	写轻量 Spec，明确验收条件后直接实现
跨模块、高风险、长期任务	完整 Spec、Plan、检查点、验证记录和交接材料

这里的关键不是用文件数量判断流程是否完整，而是让流程成本和失败成本匹配。SDD 应该提供升级路径，而不是把最高等级的治理默认施加到每一次修改上。

对 Skill 设计的反思

Skill 和 SDD 也不应该被混为一谈。SDD 是项目如何管理需求、决策和证据的规则；Skill 是模型在某类任务中可以调用的一组操作说明。前者解决长期一致性，后者解决当下执行质量。

如果 Skill 被写成“只要开始任务就必须调用”，它会天然趋向常驻流程。多个 Skill 同时声明强制使用后，还可能出现调用链叠加：先 brainstorming，再 writing-plans，再 executing-plans，最后 verification 和 finishing。每个 Skill 单独看都有合理性，但组合起来会重复读取规则、生成相似文档、增加确认节点，并把模型的注意力从产物转移到流程状态。

对 GPT-5.6 Sol 这样的强模型，我认为更合适的 Skill 应该具备下面几个特点：

1. 条件触发，而不是会话触发：出现测试失败才进入系统化调试，出现高风险行为变化才升级到 TDD。
2. 先判断任务规模：允许小任务走短路径，不强迫所有任务创建 Spec、Plan 或 worktree。
3. 只补一个能力缺口：一个 Skill 应解决一个清晰问题，避免同时接管需求、实现、Git 和交付全过程。
4. 以证据为退出条件：测试结果、构建结果、设备证据或差异检查完成后即可退出，不要求继续完成与当前目标无关的仪式。
5. 减少重复上下文：项目事实放在 AGENTS.md、架构文档和 Feature Spec 中，Skill 只引用需要的入口，不重复复制整套项目说明。
6. 允许模型跳过并说明原因：如果当前任务不满足触发条件，Skill 应允许记录一次简短判断后直接继续，而不是为了“使用 Skill”制造额外工作。

这次实验中的 Selective 仍然是预先绑定的技能组合，而不是根据运行时风险动态触发。因此它没有胜过 None，并不代表“选择性使用”这个方向错误，更可能说明选择还不够动态、粒度还不够细。

理想状态下，Skill 应该像工程工具箱里的扭矩扳手：在需要精确控制的地方使用，而不是因为工具存在，就要求拧每一颗螺丝前都先走一遍完整流程。

实验的成本与限制

这不是一次廉价测试。

• 27 个正式开发样本共使用 65,112,250 tokens。
• 27 个匿名盲评共使用 4,769,334 tokens。
• 盲评一共发起 28 次尝试，其中一次在调用模型前因环境问题失败，消耗为 0 token。

同时，这个结果必须带着几个限制阅读：

1. 样本只有 3 个任务，每个任务—方案组合重复 3 次，属于小规模固定基准。
2. 任务都是 TypeScript 编码题，不能直接外推到大型跨端工程、开放式产品设计或长期维护任务。
3. bootstrap 区间描述的是这组固定样本的波动，不代表普遍因果结论。
4. CPU 和 RSS 指标有较多缺失，没有用于最终推荐。
5. 配置锁定后，评测控制器暴露出能力门、盲评包、审阅命令和进程指标读取问题。修复通过可审计的运行时加载器完成，没有修改 27 个付费开发提交和原始运行记录，但这仍然意味着本次结果只能标记为 exploratory。

因此更准确的表述不是“Superpowers 已经没用了”，而是：

在这次针对 GPT-5.6 Sol 的 3×3×3 固定编码基准中，默认不使用 Superpowers 同时获得了更高平均质量和更低成本；常驻 Full 和预设 Selective 都没有证明净收益。

总结

工作流的价值取决于它弥补了什么能力缺口。

当模型容易遗漏测试、缺少计划或不会主动验证时，强流程可以把表现下限抬高。但当模型已经具备较完整的工程能力后，同一套约束也可能从“脚手架”变成“摩擦力”。

随着 AI 不断迭代，越来越多曾被视为“最佳实践”的范式，已经不再主要约束 AI，而是在约束人。人需要先把一个模型本来能够理解的目标翻译成固定模板，再维护 Spec、Plan 和任务状态，逐个确认模型已经能够自主判断的步骤，最后还要负责把流程产生的文档重新同步回真实代码。

这种现象很容易被误认为“人掌握了更多控制权”。但如果一个确认不会改变后续决策，一份文档没有成为长期事实，一个检查点也没有拦截真实风险，那么它增加的只是人的操作负担，并没有增加治理能力。流程看起来更完整，不代表系统更可控。

这并不意味着人应该退出开发流程。恰恰相反，模型能力越强，人的责任越应该集中在真正重要的位置：确定目标和优先级、划定权限与成本边界、判断不可逆风险、定义验收标准，并对最终后果负责。至于搜索代码、比较方案、实施修改和执行常规验证，可以给 AI 更大的自主空间。

因此，下一代 AI 开发范式不应该继续规定 AI 每一步“必须怎么想”，而应该更清楚地声明：

• 哪些边界不能越过；
• 哪些证据必须交付；
• 哪些风险必须由人确认；
• 哪些普通步骤可以由 AI 自主完成。

衡量一个流程是否先进，也不该看它拥有多少阶段、文档和 Skill，而应该看它是否减少了整个系统的不确定性。如果流程只是把模型的工作转化成人工确认，它约束的就不是 AI 的错误，而是人的效率。

这次实验给我的最大启发并不是应该永远关闭某个插件，而是不要把流程完整度等同于代码质量。对 GPT-5.6 Sol 来说，先让模型在明确边界内直接完成任务，再在真实风险出现时调用具体能力，比一开始就套上完整流程更有效。

所以我现在的默认答案是：关闭 Superpowers；需要时，精确地使用其中某一个能力。让 AI 在边界内自主，让人在边界和后果上负责。