夜雨聆风前两天刷 Reddit，一条帖子底下六七十个回复，主题就一个词，uninstall。
卸载 superpowers。
理由也很统一，「流程太重了」「模型都这么强了还搞这套仪式感」「每次问个简单问题它先给我加载一堆技能文本」。
我看完那些评论，第一反应是，嗯，说的都对。
第二反应是，等等，你们卸错东西了。
我自己用 superpowers 大半年。那种「重」我太熟悉了。明明就想改个变量名，它非要先 brainstorming 一轮，然后问你要不要进 writing-plans，再逐段让你批准。改个 typo 走完全套流程，人都麻了。
但仔细想，让人烦的到底是什么？
是 brainstorming 这个技能本身吗？不是。brainstorming 在复杂需求面前挺好用的，帮你把模糊的想法掰开揉碎。
是 writing-plans 吗？也不是。多文件大改动写个计划，天才模型也该写，那产物是给人看的。
让人烦的是那层强制。
每次简单问题也要走一遍仪式。
我专门去翻了 superpowers 的源码，想搞清楚这层「重」到底是怎么来的。
结果找到一条规则，原文写的是「not negotiable / you cannot rationalize your way out」。翻译过来就是，哪怕 1% 的可能性跟某个技能相关，你也必须调用它。不可商量，不可绕过。
你品品这措辞。not negotiable。
这条规则的效果是什么呢？你问模型「帮我把这个函数名从 getUserName 改成 getUsername」，它也要先加载一堆技能文本，走一遍判断流程，然后才开始干活。
白白吃掉上下文不说，延迟也上去了。用户体感就是，什么都要走一遍流程，慢且啰嗦。
但这还不是最要命的。
最要命的是技能之间的硬链。
我在源码里看到 brainstorming 技能的终止条件写着一句话，「The terminal state is invoking writing-plans... The ONLY skill you invoke after brainstorming is writing-plans.」
这是一条强制状态机转移。brainstorming 跑完，不给模型选择权，直接钉死下一步必须是 writing-plans。writing-plans 跑完又指向 executing-plans。executing-plans 指向 verification。
一条链子，环环相扣，中间还插满「等用户逐段批准」。
brainstorming → writing-plans → executing-plans → verification，每一环都是强制的。
你想想这是什么场景。你手里拿着一把瑞士军刀，你只想用里面的开瓶器开个啤酒，但这把刀的设计是，你必须先把螺丝刀抽出来，再把剪刀打开，确认你不需要它们，逐个收回去，最后才能碰到开瓶器。
这套设计的隐含假设是什么？
模型会偷懒跳步。
所以要用状态机逼它走完。这是防弱模型摸鱼的。早期的 GPT-4 确实会跳步、幻觉、走捷径，用外部流程强制它一步步来，是合理的。
但现在是 GPT-5.6 的时代了。
强模型的问题恰恰相反。它有能力判断「这个改动值得先写 plan，那个不值得」，它有能力在复杂任务时自己选择 brainstorming，简单任务时直接动手。
硬链却不让它判断。
等于用防作弊的机制去管一个本来能自我调度的对象。就像你雇了一个十年经验的高级工程师，然后要求他每天上班先打卡、写日报、填工时系统、每写一行代码要截图发群里等组长批准。
他能干吗？能。他烦吗？烦死了。他的产出会因为这套流程变好吗？不会，只会变慢。
所以社区的怒气我理解。那种「被流程绑架」的体感是真实的。
但「卸载」这个动作，我觉得是矫枉过正了。
打个比方。你住的小区物业太烦了，天天查你快递、登记你访客、进出要刷三次卡。你受不了了，合理。但你的解决方案是搬出这个小区，连 24 小时安保和免费健身房一起放弃了。
superpowers 里面有些东西是真值钱的。
verification-before-completion，这个技能专门在模型说「搞定了」之前再验一遍。再强的模型也会幻觉 API、误读需求、漏掉边界条件。这玩意抓的是真错。你因为「模型强了」就把它丢了？模型强了照样会幻觉，只是频率低了，但一次幻觉的代价没变。
systematic-debugging，这个技能的价值在于防止模型瞎猜。没有它，模型遇到 bug 会倾向于改一行试试、不行再改一行。有了它，模型会先建假设树、逐个排除。这跟模型 IQ 无关，跟方法论有关。
还有 plan 和 spec 这些产物。它们不是给模型看的，是给人看的。评审、协作、三个月后你自己回来翻代码，都需要。你卸了 superpowers，这些产物的生成能力也一起没了。
坦率的讲，流程的价值不只来自模型智商。
脚手架的边际价值随模型变强确实在下降，这个判断没问题。但下降不等于归零。 它从「必需品」变成了「按需品」，不代表变成了「废品」。
整个卸载这个动作，等于为了摆脱一个烦人的开关，把一整箱能按需用的好工具一起扔了。
那正确的做法是什么？
我自己的做法是，关掉那个自动加载、强制先调技能的元层，让模型自己判断何时该用流程。
具体来说就三件事。
第一，把那条「1% 就必须调用」的规则干掉。简单问答、小改动，模型直接做，不套流程。问个「这个 error 是啥意思」不需要先 brainstorming。
第二，保留 brainstorming、writing-plans 这些技能，但改成按需触发。复杂需求、长周期项目、多文件重构的时候，我手动调。模型也可以建议「这个任务要不要先 brainstorm 一下」，但不是强制。
第三，把技能之间的硬链拆掉。brainstorming 跑完不一定要接 writing-plans，有时候 brainstorm 完我就知道怎么做了，直接动手。有时候需求已经很清楚，直接进 writing-plans 跳过 brainstorming。
这样改完，体感完全不一样了。快的时候极快，该慢下来的时候有工具可用。
其实我现在日常用的开发工作流更进一步，是这么一条线。
从需求文档开始，先 grilling，就是让 AI 对着文档逼问你模糊的地方，把含糊的需求逼成精确的 spec。然后落 spec，拆 ticket，逐张实现。
每一环的产物是给人评审的，不是给模型防偷懒的。
这是关键区别。
superpowers 的流程，隐含假设是「模型不可信，所以要流程兜底」。我的流程，假设是「模型可信，但人需要检查点」。前者是防作弊，后者是协作。
而且任何一步都能跳过或手动接管。需求已经清楚就直接落 spec，不用 grilling。只想快速 POC 就跳过 ticket 直接写。没有哪一步是 not negotiable 的。
回到最开始那个 Reddit 帖子。
那些卸载 superpowers 的人，他们感受到的痛是真的。模型变强之后被强制流程拖慢，这个体验确实糟糕。
但他们的归因错了。
问题不在「流程」，在「强制」。
plan 有没有价值？有。verification 有没有价值？有。brainstorming 有没有价值？在合适的场景下有。
它们的问题从来不是存在本身，而是被绑定在一条不可跳过的链条上，被一条「not negotiable」的规则变成了每次交互的固定税。
你烦的不是工具。你烦的是工具不让你选择不用它。
这其实是个挺经典的设计哲学问题。
Unix 哲学里有句老话，make each program do one thing well，让每个程序只做好一件事。然后通过管道组合。用户决定组合方式，不是程序决定。
superpowers 的设计走了反方向。它把多个程序焊死在一条管道里，用户没法拆开单独用，也没法跳过中间某一节。
这在弱模型时代是务实的选择。因为弱模型如果你不焊死它，它真的会跳步、会摸鱼、会给你一个半成品说「搞定了」。焊死是当时条件下的最优解。
但工具应该随着使用者能力的变化而变化。
模型变强了，对应的设计应该从「强制链」进化到「可选菜单」。从状态机进化到工具箱。从 not negotiable 进化到 use when it helps。
有些工具的作者已经在做这件事了。比如 Cursor 的 rules 是 always-on 的但你可以随时关，比如 Claude Code 的 CLAUDE.md 是建议而不是强制。
反而 superpowers 因为它的 not negotiable 设计，在模型升级的浪潮里变成了反面教材。不是因为它的技能不好，是因为它的元规则太死。
所以我的结论很简单。
别卸载，拆改。
关掉强制，保留按需。把状态机打散成工具箱。让模型自己判断什么时候该慢下来走流程，什么时候该直接干。
工具的价值不在于它永远在场。
在于你需要的时候它在。
