三周前我还在推荐大家更新 Superpowers 6.0。当时确实觉得它的思路有道理：Agent 写代码越来越快，需求没问清就动手，改完不测，最后只留一句“已完成”，迟早会出问题。Superpowers 用 brainstorm、计划、TDD 和 Review 卡住这些步骤，当时我认为很有必要。
GPT-5.6 Sol 发布后，我的判断变了。这几天我一直在看 X、V2EX、Linux DO、Reddit 上的使用反馈，也翻了 Superpowers 自己的 Issues。看完之后，我不会再给出“装上就对了”的建议。原因很直接：Sol 自己已经会规划、开子 Agent，也能持续跑长任务。外面再套一层完整流程，经常是在重复调度。
我现在不会把 Superpowers 放进默认配置。小任务用 Terra 或 Luna；复杂任务先让 Sol 走 Codex 原生 /plan 或 /goal；碰到支付、权限、数据迁移这类高风险任务，再把 TDD 和独立 Review 加回来。
我改主意，是因为“小任务被做成了大项目”
最先让我停下来想这件事的，是 X 用户 Skillabs 发的一组对照：同一句任务，关掉 Superpowers 后 35 秒完成，打开后用了 3 分 47 秒，中间还停下来确认了 3 次。
我没有把这个测试直接当成“Superpowers 慢 6 倍”的证据。原帖没有公开完整任务，也没有给出两次结果的质量对比。35 秒交付，未必和 3 分 47 秒交付的是同一个质量。
这组数字之所以让我有共鸣，是因为我也烦过这种流程：只是想改一个边界很清楚的小问题，Agent 却先问一轮需求，再写设计文档，然后建 Worktree、补测试、开 Reviewer。每一步单独看都有道理，放在一起就比任务本身还重。
V2EX 上也有人遇到类似情况：代码只改几行，前后跑了约 20 分钟，留下 200 多行文档。Linux DO 的反馈更夸张，有人一个任务拆出 15 个 Task，每个 Task 再做两轮 Review，最后开了 30 多个子 Agent。任务还没推进多少，额度先没了。
以前我会把这些当作严格流程必须付的成本。现在我更愿意先算一笔账：几百行过程材料，究竟替我挡住了什么风险？如果只是改几行代码，答案往往不值这段等待时间。
Superpowers 的方法没有突然失效，问题是它默认希望每个任务都认真走完整套流程。我现在不想这么用了。
Sol 已经会自己推进，我不想再叠一套调度
OpenAI 给 GPT-5.6 三个模型的分工很明确：Sol 负责复杂分析、编程和长任务；Terra 是日常默认；Luna 适合轻量、高频和成本敏感的场景。
这也提醒了我一件事：很多人讨论 Superpowers 浪不浪费 Token 时，前面已经选错模型了。
改配置、查报错、做单文件修改，我不会先开 Sol。Terra 或 Luna 足够。真正需要 Sol 的，是跨模块修改、复杂问题排查，以及要连续推进很久的任务。
我更关注 Sol 自己推进任务的能力。Theo 在 X 上提到，他使用 Sol 时没有开启 /goal，模型仍会主动拆任务、调用子 Agent，并继续往下推进。这也是我开始觉得外层调度有些重复的地方：过去我要靠 Superpowers 提醒 Agent 规划和分工，现在 Codex 原生已经能完成其中一部分。
Codex 先规划一次，Superpowers 再规划一次；Codex 准备调子 Agent，Superpowers 的 SDD 也要拆任务。两边偶尔能互补，更多时候只是把链路拉长。我付出了更多 Token 和等待时间，却不一定得到更好的代码。
当然，Sol 的原生调度也没成熟到可以闭眼用。Theo 后来提到，Sol Ultra 派出的子 Agent 会继承 Ultra，暂时不能单独降到 Medium，额度掉得很快。Superpowers Issue #1960 里也有人报告子 Agent 不能按任务选模型，不过那个案例实际用的是 Terra High，而且维护者明确说，不装 Superpowers 也会遇到。
我不会把这些现象解释成“Sol 和 Superpowers 冲突”。现阶段，我只是不愿意把两套都很重、又都在快速变化的调度叠起来。先跑原生流程，哪里不够再补哪里，对我更省事。
我最先找的是开关，可它并不想被临时关闭
我原本想保留 Superpowers，平时关掉，遇到高风险任务再打开。实际操作没有这么顺。
Superpowers Issue #951 从 3 月起就在请求增加开关。现在想在轻量模式和完整模式之间切换，Codex CLI 用户要手动处理 ~/.agents/skills/superpowers 链接，然后重启。有人提交 PR #1006，希望用 SUPERPOWERS_SKIP_SESSION_CONTEXT=true 跳过启动注入，同时保留手动调用 Skill 的能力。
维护者拒绝了。理由也很明确：bootstrap 就是 Superpowers 生效的方式，跳过它，整套方法论也会被绕开。
看到这里，我反而想明白了。Superpowers 本来就不是几个随手点开的命令，它想从会话开始接管工作方式。需要完整方法论的人可以继续保留。像我这样只想偶尔借用某一步的人，继续装着就得不断提醒它“这次别走全流程”。
我也不建议为了省事去抄一个没有合并的环境变量。真想保留两种模式，可以准备两套 Codex 配置，或者手动管理链接。要是每次切换都嫌麻烦，直接卸载，换成几个边界清楚的独立 Skill，反而干净。
我现在按出错代价选流程，不按任务名字选
我现在不会先问“这个任务要不要 Superpowers”。我先看做错了会怎样。
单文件修改、配置调整、报错解释，做错了容易发现，也容易回滚。我会用 Terra 或 Luna，配一份写清边界的 AGENTS.md，直接做，跑完最小验证。
跨文件功能和中型重构，我会切到 Sol，先走 Codex 原生 /plan 或 /goal。我只要求计划里写清验收标准、影响范围和不能碰的地方。原生流程跑得稳，就不继续加步骤。
支付、权限、计费、数据迁移，我会明显保守。一个判断错了，后果很难靠回滚补救。到了这里，我仍然会要求先写规格、先做失败测试，再找一个独立 Reviewer 检查。
这套选择没有“一键全自动”那么爽，但更符合我的实际使用。简单任务，我不想花十分钟证明自己会改三行代码；高风险任务，我也不会因为 Sol 更强，就省掉本该有的验证。
如果一个团队已经把 Superpowers 跑顺了，计划、测试和 Review 都能稳定产出，我不会劝他们因为几篇帖子就卸载。可如果你每天都在对 Agent 说“这次别 brainstorm”“不要写文档”“别再开子 Agent”，那你其实已经做出了选择。
我留下 4 个小 Skill，需要哪一步就补哪一步
我又看了一遍 mattpocock/skills。这个仓库 现在大约 16.7 万 Star，但我看中的是它可以拆着用，不需要把整套流程一起接管进来。
需求确实没想清楚时，我会手动调用 /grill-with-docs。它会追问，也会把术语和决策写进 CONTEXT.md、ADR。等需求清楚了，我就停在这里，不会自动进入一条很长的开发流水线。
难复现的 Bug，我会保留 /diagnosing-bugs。它最有用的规矩是：先做出一个能稳定变红的反馈循环，再开始猜原因。这比 Agent 看见第一个可疑文件就动手靠谱。
支付、权限和计费逻辑，我会用 /tdd。功能做完，再按需调用 /code-review，把项目规范和需求符合度分开检查。
这 4 个已经覆盖了我最容易翻车的环节：需求不清、Bug 乱修、核心逻辑裸改，以及完成后没人认真检查。
这里有个细节要注意。diagnosing-bugs、tdd 和 code-review 都属于模型可自动调用的 Skill，并非装完以后只能手动触发。我的做法是只装需要的，并把触发条件改得更窄。否则换了一个仓库，最后还是会回到流程自动膨胀的问题。
安装命令是：
npx skills@latest add mattpocock/skills
第一次使用前，仓库建议运行 /setup-matt-pocock-skills。另外我会提前改掉 /implement 里的自动 commit。代码可以让 Agent 写，什么时候提交，我还是想自己决定。
写完这篇，我并不觉得 Superpowers 没用了。它仍然适合那些愿意整套采用这套方法的人，只是不再适合我的每一个任务。
GPT-5.6 Sol 让我重新算了一遍流程成本。以前模型容易抢跑，我需要规则拦着它。现在模型自己会规划、会调度，我开始逐条检查这些规则还有没有必要。
所以这就是我现在的配置：Superpowers 不再默认安装，小任务直接做，复杂任务先用原生流程，到了高风险环节，再单独补 Skill。少走几步不是偷懒，最后该跑的测试和验证，我一样会跑。
发表于 前天 21:43
|
查看: 0|
回复: 0
