夜雨聆风随着GPT-5.6的深度使用，我发现越来越多的人开始呼吁卸载 Superpowers。
反对的理由很集中：容易误触，费 Token，耗时变长，还经常小题大作。只是改一处配置，Agent 也可能拉起 brainstorming等一套流程，把一个十分钟的小需求做成完整工程。
所有在 Codex 中安装了 superpowers 插件的现在请一键卸载现在几乎每次对话的都会调用，因为其规则中明确写了「每次新对话都应该优先使用」这个插件超级耗费token，而且现在也没啥大用处，不如直接使用 plan mode 模式或者推荐下载另外一个 skill：/grill-with-docs但支持者说的也有道理。Superpowers 很适合长程任务。Spec 加验证标准写清楚后，不担心 Agent 跑很久。多花的 Token 和时间，换来的是更稳定的执行过程。
我个人不觉得superpowers 很重，它的每个 Skills 都很好用。我这几天就用Test Driven 这个 Skills，即使是跑上一晚上，写出2W+4W-也不怕我围观了一会，就发现这场争论的关键并不是 Superpowers 好不好，而是：流程应该由 Skill 全程接管，还是由开发者、模型与 Harness 动态决定？
我的选择是后者：卸载 Superpowers，切到 grill-me ，也就是 matt 这类轻量化的 Skill 体系，给 Harness 最大的自由。
Superpowers 的本质
Superpowers 解决的是早期 Coding Agent 最让人头疼的问题：需求不清就开始写，过程不断跑偏，测试能省就省，最后没验证也敢宣布完成。
它的办法，是把成熟开发者脑子里的工程纪律写进 Skill，再让 Agent 强制执行。它的官方说明甚至强调，Skill 会自动触发，长任务可以在很长时间里沿着既定计划自主运行。
所以，我认为，Superpowers 是在 Harness 还不够成熟的时候，用 Skill 补出的一套软性 Harness。
这解释了它为什么可靠，也解释了它为什么越来越显得重。
当模型变强，流程税就开始变贵
Superpowers 对简单任务和复杂任务都倾向于启用完整流程。流程越完整，过程方差越小，但每个任务都要缴纳同一笔“流程税”。
过去这笔税很划算。模型不会主动澄清，不擅长规划，也缺少稳定的工具使用能力，多几轮监督能明显减少返工。
现在情况变了。随着模型能力越来越强，再配合 Harness 工程的进步，Coding Agent 已经越来越“聪明”。项目本身通常还有类型检查、CI、测试和构建命令提供反馈。
此时再叠加一套自动触发的强工作流，就容易出现重复规划、上下文膨胀和控制冲突。
这也是为什么呼吁卸载的人，大多是经验较多的开发者。他们不是不需要 SDD 和 TDD，而是相信模型的能力已经足够强大，加上自己可以在关键节点做出决策，使用哪些工具来纠偏。
Matt Skills 代表的是另一代 Skill
沿着这个思路，就可以发现 Matt 这套就是其中的代表。
这些 Skill 被拆成小而独立的组件。需要时主动调用，用完就退出，不会默认占领后续流程。Matt 也把用户主动调用的编排型 Skill 与模型可以自动调用的纪律型 Skill 分开，让触发权和工作流边界更加清楚。
Superpowers 与 Matt Skills 背后其实是两种时代假设。
Superpowers 默认模型需要被持续监督，所以用 Skill 主持整个开发过程。Matt Skills 默认模型和 Harness 已经具备较强能力，Skill 只需要在关键位置补一个认知缺口。
上一代 Skill 试图替模型安排流程，下一代 Skill 只在关键节点提升决策质量，根据模型反馈决定是否动用工具纠偏。
再聊一下 Superpowers 擅长的长程任务
长程任务最容易出问题的地方，是上下文不断发生变化，容易导致 Agent 注意力发生漂移，看起来仍然在执行，但是方向却早就歪了。
所以长程任务真正的核心能力，是让模型在上下文不断变化时仍然不跑偏。托住这件事的力量可以分成三层：
一是模型本身变强，窗口更大，也更擅长从残缺的材料里还原出原始目标和当前状态；二是模型之外的 Harness 工程手段，通过动态规划工作流，加上优秀的上下文管理，控制模型在长程任务里不发生偏离；三是 Superpowers 这类强力 Skill 提供的软性工程约束。前两层不够强的时候，第三层就显得很重要。而当模型和 Harness 一起变强，这部分过程治理，就不必继续全部压在 Skill 里了。
前两层的快速发展，正在压缩第三层的空间。但模型还不能完全可控，所以还需要留有手段来纠正。
这就是我也认同卸载 Superpowers 而转向轻量 Skill 的底层逻辑。
卸载以后，流程由谁接管
卸载 Superpowers，不是删掉插件后彻底放飞模型，而是开发者接回工作流路由权。
但接回路由权，不等于退回到没有工具的原始状态。更准确的做法是：先放手让模型自己跑，同时把 SDD、TDD 这些轻量 Skill 备在手边，等它需求跑偏或风险升高时，再手动把对应的工具拉起来鞭策它。工程纪律没有消失，只是从默认全程执行，变成了按需触发的备用手段。
顺着这个逻辑往下推，随着模型能力继续变强，需要手动拉起这些工程约束类 Skill 的次数只会越来越少，Skill 本身也会越写越薄。
这场卸载讨论背后所映射出来的信息是：工程约束正在从重型 Skill 移交给 Harness。
