跳转到内容
Superpowers 学习指南

使用超能力 (using-superpowers)

使用超能力（using-superpowers）

Section titled “使用超能力（using-superpowers）”

概述

Section titled “概述”

using-superpowers 是整套 Superpowers 系统的入口 Skill。它解决的不是某一个具体编程问题，而是一个更底层的问题：你是否在正确的时机使用正确的 Skill。

如果把 Superpowers 看成一套“AI 工程工作流操作系统”，那么 using-superpowers 就是它的启动引导器。它要求 AI 在任何任务、任何回复、甚至任何澄清问题之前，先判断：这里有没有相关 Skill 应该被调用？

这条规则听起来很严格，但它的价值非常现实：没有这条约束，AI 很容易在“感觉自己知道该怎么做”的情况下直接开始行动，最后跳过 brainstorm、跳过计划、跳过 TDD、跳过验证，进入一种表面高效、实际不可控的状态。

工作流程

Section titled “工作流程”

下面这张图可以把原文的核心流程翻译成一句话：

先判断有没有 Skill，调用后再决定怎么做；没有 Skill 时，才进入普通响应。

graph TD
  A[收到用户消息] --> B{是否可能有 Skill 适用？}
  B -->|是，即使只有 1%| C[调用对应 Skill]
  B -->|确定没有| H[直接响应或继续澄清]
  C --> D[说明正在使用哪个 Skill 做什么]
  D --> E{Skill 是否包含检查清单？}
  E -->|是| F[按清单创建任务追踪]
  E -->|否| G[严格遵循 Skill 执行]
  F --> G
  G --> H

步骤 1：先做 Skill 判断

Section titled “步骤 1：先做 Skill 判断”

任何任务开始前，先判断：

  • 这是一个需要 brainstorm 的任务吗？
  • 这是一个需要写计划的任务吗？
  • 这是一个需要调试、测试或验证的任务吗？
  • 这是一个需要代码审查或工作树隔离的任务吗？

步骤 2：如果可能适用，就先调用

Section titled “步骤 2：如果可能适用，就先调用”

这里最反直觉的点是：

  • 不是“很适合才用”
  • 而是“只要可能适用，就先调用看看”

调用之后，如果发现不合适，再退出都可以； 但不允许因为主观判断“好像没必要”就直接跳过。

步骤 3：说明自己在用什么 Skill

Section titled “步骤 3：说明自己在用什么 Skill”

原文强调一个很好的实践： 在进入 Skill 后，应该明确说明：

  • 正在使用哪个 Skill
  • 为什么使用
  • 接下来会怎么执行

这能让协作方更清楚当前工作流状态，也能让 AI 自己更不容易脱轨。

步骤 4：如果 Skill 带有 checklist，就把它外显化

Section titled “步骤 4：如果 Skill 带有 checklist，就把它外显化”

像计划、验证、调试这类 Skill，经常有明确步骤。 把这些步骤写成任务清单的好处是：

  • 不漏项
  • 更容易审查
  • 更容易中途恢复上下文

步骤 5：按 Skill 执行，而不是按感觉执行

Section titled “步骤 5：按 Skill 执行，而不是按感觉执行”

这是整个 Skill 最重要的落地点：

一旦确定 Skill 适用，就不是“参考一下”，而是要真正遵循它。

速查卡片

Section titled “速查卡片”

何时使用

  • 每次新任务开始时
  • 收到需求但还没动手前
  • 想先问澄清问题之前
  • 准备直接写代码之前

何时不用

  • 明确确定没有任何相关 Skill 时
  • 被作为子代理派去执行明确单点任务，且原文显式说可跳过时

关键要点

  • Skill 判断先于一切动作
  • 1% 可能适用也要先调用
  • 用户指令优先于 Skill
  • 调用后应真正遵循 Skill

常见错误

  • 先探索代码再想 Skill
  • 先问问题再想 Skill
  • 凭记忆跳过 Skill
  • 把 Skill 当成“可选建议”

关键概念

Section titled “关键概念”
英文术语中文翻译解释
Skill技能 / 工作流技能一段可复用的结构化工作方法，告诉 AI 应该如何处理某类任务。
Skill invocation调用 Skill在真正执行前，先加载并进入对应工作流。
Instruction Priority指令优先级用户要求高于 Skill，Skill 高于默认系统行为。
Rigid skill刚性 Skill必须严格遵守的 Skill，例如 TDD、调试类。
Flexible skill灵活 Skill可以按上下文适配的 Skill，但核心原则仍要保留。
Red flag红旗信号代表你正在“合理化跳过流程”的危险想法。

常见错误与红旗

Section titled “常见错误与红旗”
错误行为为什么是错的正确做法
“这只是个简单问题，先答了再说”简单问题也可能对应现成工作流先判断 Skill，再回复
“我先看下代码，再决定要不要 Skill”这会让你先行动、后补流程先做 Skill 判断，再探索
“我需要更多上下文，所以先问几个问题”原文明确说澄清前也要先检查 Skill先检查 Skill，再决定如何提问
“我记得这个 Skill 内容，大概差不多”Skill 会演化，记忆可能过时以当前版本为准
“这个 Skill 太正式了，有点 overkill”这是典型的自我合理化只要相关就先调用

深度解读

Section titled “深度解读”

原文的设计哲学

Section titled “原文的设计哲学”

这份 Skill 的设计哲学非常强硬，几乎可以概括成：

流程纪律比即时反应更重要。

作者显然在和一种常见失控模式作斗争：AI 一拿到任务就开始“看起来很聪明地行动”，但没有进入正确工作流，最后质量、可验证性、协作性全都下降。

所以这个 Skill 故意把规则写得很“过度”，比如：

  • 1% 可能适用也要先调用
  • 连澄清问题之前都要先检查
  • 不能凭记忆跳过

它的目的不是让流程更官僚，而是为了对抗 AI 和人类都会出现的那种： “我大概知道该怎么做，先开始再说” 的冲动。

与日常开发的关联

Section titled “与日常开发的关联”

如果你是程序员，你会发现这和很多真实工程事故高度相似：

  • 觉得 bug 很简单，结果修成了新的 bug
  • 觉得不用写测试，结果回归了别的逻辑
  • 觉得不用写计划，结果中途越做越偏
  • 觉得不用 review，结果漏掉了边界条件

using-superpowers 本质上是在说：

不要在还没选好工作模式之前就开工。

这在 AI 协作时代尤其重要，因为 AI 太擅长“快速生成动作”，却不天然擅长“稳定选择正确流程”。

实际使用场景举例

Section titled “实际使用场景举例”

场景 1：用户说“帮我加一个登录功能”

Section titled “场景 1：用户说“帮我加一个登录功能””

错误做法：

  • 直接开始写登录页面和接口

正确做法：

  • 先判断：是否应先用 brainstorming？
  • 然后判断：是否需要 writing-plans？
  • 再根据实现方式进入 TDD 或执行计划

场景 2：用户说“这个测试挂了，帮我修一下”

Section titled “场景 2：用户说“这个测试挂了，帮我修一下””

错误做法：

  • 直接改代码

正确做法：

  • 先判断：这是不是 systematic-debugging 的场景？
  • 如果是，先进入调试工作流
  • 再决定怎么复现、定位、验证

场景 3：用户问“这个方案你怎么看？”

Section titled “场景 3：用户问“这个方案你怎么看？””

错误做法：

  • 立刻给结论

正确做法：

  • 先判断：是不是 brainstorming 或 writing-plans 更适合？
  • 这样才能把回答从“随口建议”提升到“结构化分析”

关联 Skill

Section titled “关联 Skill”
  • 前置：无。它本身就是所有 Skill 的总入口。
  • 后续：brainstorming、writing-plans、systematic-debugging 等几乎所有 Skill。
  • 互补：它不解决具体任务，但决定你是否能进入正确的具体 Skill。

附属文档

Section titled “附属文档”

核心作用

Section titled “核心作用”

这份文档说明：如果 Skill 原文是按 Claude Code 写的，在 Codex 环境里应该如何映射到对应工具。

关键对照

Section titled “关键对照”
  • Task → spawn_agent
  • 多个 Task → 多次 spawn_agent
  • TodoWrite → update_plan
  • Skill → 直接按原生技能机制执行
  • Read / Write / Edit / Bash → 使用平台原生文件与 shell 工具

这份文档的价值

Section titled “这份文档的价值”

它说明 Superpowers 的思想并不绑定 Claude Code 本身。真正重要的是：

  • 工作流的结构
  • 决策顺序
  • 任务拆分原则
  • 验证与执行纪律

工具名称只是平台适配层。