一、第一性原则：AI 编程真正的问题不是“不聪明”，而是“不稳定”

很多人用 AI 写代码时，都会遇到一种熟悉的崩溃：

一开始，它看起来很强。能读代码、能改文件、能跑命令、能解释架构。

但只要任务稍微变长，它就开始出现几类问题：

第一，它会跳步骤。本来应该先理解需求、再设计、再写测试、再实现，它可能直接开改。

第二，它会自我合理化。比如“这个改动很简单，不需要测试”“我先快速看一下代码”“我先修一下再说”。这些话听起来很像一个赶工期的初级工程师。

第三，它会上下文漂移。前面说好的约束，后面忘了；前面设计过的边界，后面改着改着又偏了。

第四，它会把完成感误认为完成。代码写了，测试没跑；问题看似修了，根因没验证；功能能跑一次，但边界条件没覆盖。

所以第一性原则不是“如何让模型更聪明”，而是：

如何让一个概率型 Agent，在长流程任务里持续遵守确定性工程纪律。

Superpowers 的价值就在这里。

它不是简单地增强模型能力，而是把工程流程拆成一组可复用的 Skill：头脑风暴、写计划、使用 git worktree、测试驱动开发、系统性调试、代码审查、接收 review、完成分支等。Superpowers 官方 README 里也把它的基本流程写得很清楚：从 brainstorming，到 writing-plans，再到 subagent-driven-development / executing-plans、test-driven-development、requesting-code-review、finishing-a-development-branch。它的底层哲学是 TDD、系统化优先、降低复杂度、证据胜过声明。

这就是我对 Superpowers 的理解：

**Superpowers 不是“让 AI 更会写代码”的工具，而是“让 AI 更像一个遵守工程流程的团队”的约束系统。 *

二、Superpowers 真正强的地方：不是自动化，而是降低工程熵

我觉得 Superpowers 最强的地方有三个。

1. 它逼 Agent 先想清楚，再动手

brainstorming的作用不是“多聊几句”，而是让 Agent 在写代码前先澄清目标、边界、替代方案和风险。

这一步对复杂需求非常重要。因为 AI 写代码的问题，往往不是语法不会，而是需求还没被压缩成可执行设计。

人类工程师也一样。需求不清楚时，写代码越快，返工越快。

2. 它把“计划”变成可执行工单

writing-plans的关键，不只是生成一个漂亮计划，而是把任务拆成足够细的执行单元：文件路径、具体改动、验证步骤、预期结果。

这让 Agent 不再凭感觉游走，而是围绕一个计划推进。

这也是 Superpowers 和普通“帮我写个实现计划”的差别：普通计划是文档，Superpowers 里的计划更像 Agent 的任务队列。

3. 它用 TDD 和 Review 对抗模型幻觉

Superpowers 强调 RED-GREEN-REFACTOR：先写失败测试，确认失败，再写最小实现，再确认通过。README 中甚至明确描述test-driven-development会执行“写失败测试、看它失败、写最小代码、看它通过、提交”的循环。

这背后有一个朴素但重要的判断：

**不要相信 Agent 说它完成了，要相信可重复验证的证据。 *

三、但 Superpowers 不是银弹：它最大的副作用是“流程过重”

如果只讲优点，也没必要写这篇文章了。

Superpowers 的问题也很明显：它可能把小任务复杂化。

官方仓库 Issues 里，已经有不少用户反馈类似问题。

有人反馈安装后 Claude Code 响应明显变慢，怀疑 Superpowers 的上下文占用了太多空间。

也有人反馈，一个简单任务让 Claude 在 5 分钟内把 quota 用完，表现为“开始 overthink，做了很多以前不会做的事，比如写文档”。

还有一个很典型的 Issue 提到：Superpowers 当前像是 “all-or-nothing” 体验，会对每个 prompt 触发完整工程流程，哪怕只是修一个 typo 或改一个 UI 颜色；用户希望有/fast、/direct、!sp、/simple-mode之类的机制来按需开启或绕过。

这说明什么？

说明 Superpowers 的核心矛盾是：

流程纪律能降低错误率，但流程本身也有成本。

这在软件工程里很正常。你不会为了改一个按钮文案开一次完整架构评审，也不会为了改一个 README 拼写错误走完整 TDD。

所以：

**Superpowers 应该按风险启用，而不是按习惯启用。 *

四、哪些场景适合 Superpowers？哪些场景不适合？

第一类：强烈适合 Superpowers

这类任务通常具备几个特征：需求有歧义、改动跨多个文件、需要保持架构一致性、失败成本高、需要测试和 review。

例如：

• 从 0 到 1 做一个功能模块

• 重构核心业务逻辑

• 修一个复现不稳定的 bug

• 接入支付、鉴权、权限、数据迁移

• 多 Agent 并行开发一个较大需求

• 需要先出设计方案，再分阶段执行

这类任务里，Superpowers 的流程成本是值得的。

第二类：可以使用轻量 Superpowers

这类任务有一定复杂度，但不一定需要完整链路。

例如：

• 修一个中等复杂 bug

• 给已有功能补测试

• 小范围重构

• 生成一个 PR review checklist

这时可以只显式调用某个具体 Skill，而不是让 Superpowers 全套流程启动。

比如：

/superpowers:systematic-debugging 这个接口偶发 500，帮我按根因排查

或者：

/superpowers:test-driven-development 给这个函数补边界测试

第三类：不建议使用 Superpowers

这些任务更适合 direct mode：

• 改 typo

• 改一个颜色值

• 改一句文案

• 问一个概念

• 让 AI 解释某个命令

• 快速生成一个小脚本草稿

• 临时做一次不进入主分支的实验

对这类任务，Superpowers 的完整流程很可能是负收益。

五、常见的几个坑，以及我的解决办法

坑 1：Skill 自动触发不稳定

Anthropic 文档说，codex、Claude 会在相关时使用 Skill，也可以用/skill-name直接调用。 但社区测试表明，自动触发并不总是可靠。

Scott Spence 做过一个关于 Claude Code Skills 激活率的测试。他的结论是：无钩子或简单提示时，Skill 激活像“掷硬币”；他后来通过 forced eval hook 和 LLM eval hook 把激活率提升到 80% 到 84%，但也承认并不完美。

另一个 Medium 文章也做了 650 次测试，指出普通描述下自动激活表现不稳定，而更强指令式描述能显著提高触发率；不过这类文章属于社区实验，不能等同官方结论。

关键任务不要赌自动触发。

要么显式 Slash 调用：

/superpowers:brainstorming 我想做一个本地 AI 视频口播工具，先别写代码，先帮我拆需求和方案

要么在 prompt 里明确说：

请显式使用 superpowers:brainstorming，不要直接进入实现。

但最稳的方式仍然是 Slash Command，因为它比自然语言提醒更接近“命令”。

坑 2：过度思考，烧 token，拖慢速度

Superpowers 的流程会引入 brainstorming、planning、review、subagent 等额外步骤。对复杂任务这是护栏，对简单任务就是阻力。

官方 v6.1.0 其实已经开始处理这个问题：最新版重点是降低每个 session 的 token 成本，压缩using-superpowersbootstrap，删掉冗余的工具映射参考，同时不移除关键行为约束。

但即便 v6.1.0 降低了成本，也不代表所有场景都该启用。

我的解决办法是做“三档模式”：

Fast Path：小改动，直接做，不启用 Superpowers。 Skill Path：中等任务，只调用一个明确 Skill。 Full Superpowers：复杂任务，走 brainstorming → plan → TDD → review。

你可以在项目的 Agent 规范里写：

默认使用 Fast Path。 只有当我显式输入 /sp、/superpowers 或具体 /superpowers:xxx 时，才启用 Superpowers。 对于 typo、样式微调、单文件机械改动，不要自动进入 brainstorming / writing-plans / subagent-driven-development。

这不是削弱 Superpowers，而是让它从“默认反射”变成“高风险任务的工程模式”。

坑 3：子 Agent 可能没有继承完整 discipline context

Superpowers 很依赖“先检查技能、不要跳过流程”的纪律。但一些测试发现：主会话能看到using-superpowers的 Red Flags 表，子 Agent 却看不到；子 Agent 虽然能看到 Skill 列表，但在没有纪律提示时会跳过 TDD，而在明确提示后才遵守。该 Issue 的判断是：问题不是 Skill 工具不可用，而是子 Agent 缺少 discipline context。

这类问题说明，多 Agent 流程不只是“多开几个 Agent”这么简单。每个子 Agent 都是一个新的上下文岛。如果纪律没有传进去，它就会回到默认模型行为。

分发子任务时，把流程要求写进任务本身。

不要只写：

实现 Task 3。

而要写：

实现 Task 3。必须先检查适用 Skill；如果涉及代码实现，使用 TDD；完成后说明测试证据；不要跳过验证。

坑 4：计划文件可能变成 token 黑洞

有用户在 Issue 里指出，writing-plans会生成单一的大计划文件，反复读取会贵；讨论中也承认，计划文件本身是已知低效点，真正的缓解来自 subagent 只读取自己的任务切片，以及任务列表作为压缩后仍能保留的索引。

不要迷信“一个巨型计划文档”。

更好的做法是：

docs/plans/xxx/ overview.md task-1.md task-2.md task-3.md

让主 Agent 只读 overview，让子 Agent 只读自己的 task 文件。
这符合工程里的模块化原则，也符合 Agent 上下文管理的第一性原则：**少读、精读、按需读。 *

坑 5：简单任务也走两阶段 review，可能成本过高

subagent-driven-development对完全机械的任务也会触发“实现 → spec review → 修复 → code quality review → 再修复”的链条，导致 token 和时间螺旋上升，但输出质量未必提升。作者建议按任务复杂度分类：机械任务轻量检查，集成任务完整 review，设计任务完整 review 并升级处理。

因为工程流程不是宗教。
流程的目的不是“显得专业”，而是降低风险。

对机械任务，最好的 review 可能不是两个冷启动 Agent 反复审，而是一个 deterministic diff check、lint、test 或 snapshot 校验。

六、如何让用户显式调用 Superpowers，而不是让它主动触发？

添加限制，一个手动调用型 Skill 可以这样写：

--- name: superpowers-manual description: Manual entrypoint for Superpowers workflow. Use only when the user explicitly invokes this skill. disable-model-invocation: true --- 当用户显式调用本 Skill 时： 1. 先询问任务目标、边界、成功标准 2. 判断任务属于 Fast / Skill / Full Superpowers 哪一档 3. 只有复杂任务才进入完整 brainstorming → plan → TDD → review 4. 简单任务直接建议使用 Fast Path

然后用户通过 Slash 调用：

/superpowers-manual 帮我设计一个本地 AI 口播工具的 V1 版本

所以对 Superpowers 这种插件型工作流，我更推荐三种方式：

第一，保留官方插件，但在使用习惯上显式调用具体 Skill。比如：

/superpowers:brainstorming 先帮我拆方案 /superpowers:systematic-debugging 按根因排查这个问题 /superpowers:test-driven-development 用 TDD 实现这个函数

第二，**为自己的项目做一层“手动入口 Skill”**，把它作为/sp或/superpowers-manual，让它决定是否进入完整流程。

第三，**如果你强烈需要 opt-in 模式，可以 fork 一份 Superpowers 或只复制需要的 Skills 到项目目录，然后给它们加disable-model-invocation: true**。这样比在 prompt 里反复说“不要自动触发”更可靠。

**想要显式调用，就不要只靠提示词；要在 Skill frontmatter、权限、插件管理、项目规范四层同时收口。 *

七、写在最后

如果你已经在用 Claude Code / Codex / Cursor，并且想把 Superpowers 用得更稳，以下是一些小的建议。

1. 建立任务分级规则

放在你的项目规范里：

Task Mode Policy: Fast Path: - typo - 文案 - 单文件小改 - 无业务风险的样式调整 直接完成，不启用 Superpowers。 Skill Path: - debugging - test - code review - 小范围重构 显式调用对应 Superpowers Skill。 Full Superpowers: - 新功能 - 架构调整 - 多文件改动 - 高风险逻辑 - 需要设计确认的需求 必须先 brainstorming，再 writing-plans，再执行。

2. 使用显式命令，而不是期待自动触发

/superpowers:brainstorming 先不要写代码，帮我梳理这个需求 /superpowers:writing-plans 基于刚才确认的方案写执行计划 /superpowers:executing-plans 执行这个计划，每一步完成后给验证证据 /superpowers:systematic-debugging 按根因分析这个 bug

3. 给子 Agent 的任务里重复纪律

你是子 Agent。执行本任务前必须检查适用 Skill。 如果涉及代码，必须 TDD。 完成后必须提供验证证据。 不要因为任务看起来简单而跳过测试和 review。

4. 对简单任务明确禁止过度流程

这是 Fast Path 任务。不要 brainstorming，不要 writing-plans，不要启动 subagent。只做最小修改，并说明改了哪里。

当任务足够复杂时，让 Agent 拥有 Superpowers。
当任务只是改一个 typo 时，让它闭嘴，直接改。

这才是效率和质量之间真正的平衡。