01

超能力是什么?

从一句"帮我做个 Todo App"开始,看看 Superpowers 如何改变 AI 编程助手的行为方式

你有没有遇到过这种情况?

你对 AI 编程助手说:"帮我做一个待办事项应用"。它立刻开始写代码——文件一个接一个地涌出,几百行代码出现在屏幕上。然后你发现:它完全猜错了你的需求。

这是 AI 编程助手 的默认行为:收到请求就行动,没有停下来问"你真正想要的是什么?"

Superpowers 的核心思路

给 AI 助手装上一套「技能库」,让它在对的时机自动触发对的行为——而不是每次都需要你手动提醒它"先别写代码,先讨论需求"。

装上 Superpowers 之后,同样这句话会发生什么

你说:"帮我做一个待办事项应用"。这次,AI 助手不会立刻写代码。它会先触发 brainstorming(头脑风暴)技能,问你:

1
这个 App 是给谁用的?

个人使用还是团队协作?桌面还是手机?

2
最重要的功能是什么?

是截止日期提醒、标签分类,还是和日历同步?

3
你有没有在用什么现成的工具?

为什么不用 Notion 或者苹果自带的提醒事项?

4
设计好了才开始写代码

拿到你的确认后,才进入实现计划阶段

什么是"技能"(Skill)?

把 AI 编程助手想象成一个刚加入团队的新人。他很聪明,但不了解你们团队的工作规范——什么时候写测试、怎么做代码审查、遇到 Bug 先查什么。

技能(Skill)就是这份操作手册。每个技能文件描述一个具体的工作场景和对应的操作流程。

🧠

brainstorming

写代码前先理清需求,通过提问把模糊想法变成清晰设计

🧪

test-driven-development

先写测试,再写代码。确保每行代码都经过验证

🔍

systematic-debugging

遇到 Bug 时用系统化的 4 阶段方法找到根本原因

🤝

requesting-code-review

任务完成后按清单审查,确保质量符合标准再提交

为什么这对你很重要?

如果你用自然语言指挥 AI 工具来构建软件,你可能遇到过这些困境:

😤
AI 反复出错,绕不出 Bug 死循环

Superpowers 的 systematic-debugging 技能让 AI 用系统化方法追查根本原因,而不是随机猜测

🧩
不知道 AI 写的代码对不对

verification-before-completion 技能强制 AI 在说"完成了"之前先自己验证

🚀
想要 AI 自主工作更长时间

subagent-driven-development 技能让 AI 把大任务分解给多个子 Agent 并行执行,无需你每步确认

💡
软件工程的核心洞见

最聪明的开发者不是写代码最快的,而是在错误方向上浪费最少时间的。Superpowers 的每个技能都是一道「防止走错路」的护栏。

快速检验:你理解了吗?

一位朋友问你"Superpowers 是什么",下面哪个回答最准确?

你想添加一个「用户可以给待办事项设置优先级」的功能,AI 助手立刻开始改数据库结构和前端代码。这时候应该触发哪个技能,让 AI 先停下来想清楚?

02

技能体系架构

认识 Superpowers 的主要组成部分——它们各自是谁,负责什么,住在哪里

认识主要角色

想象一下一家运转良好的公司:有人写规章制度,有人负责入职培训,有人在需要时自动发出提醒。Superpowers 也是这样分工的。

superpowers/ 整个技能体系的根目录
skills/ 所有技能文件的存放地 — 这是核心
brainstorming/SKILL.md 需求探索技能
test-driven-development/SKILL.md TDD 技能
using-superpowers/SKILL.md 系统入口技能(最先被加载)
hooks/ 自动触发机制 — 会话开始时运行
agents/ 子 Agent 定义文件

一个技能文件长什么样?

每个技能文件是一个 Markdown 文档,包含三个关键部分。我们来看 brainstorming 技能的开头:

SKILL.md
---
name: brainstorming
description: "You MUST use this before
 any creative work - creating
 features, building components..."
---

# Brainstorming Ideas Into Designs

<HARD-GATE>
Do NOT invoke any implementation
skill, write any code, scaffold
any project, or take any action
until design is approved.
</HARD-GATE>
逐行解读

这是技能的「身份证」区域,用 --- 包围

技能的名字:brainstorming

触发条件描述:AI 助手看到这段话,就知道什么时候该用这个技能

(description 字段会被 AI 用来判断是否匹配当前情景)

身份证区域结束

正文开始:技能的名称和说明

HARD-GATE 是一个硬性禁止区域

在设计被用户批准之前,绝对禁止写任何代码

这是「禁令」,不是「建议」

点击查看各组件的职责

下面是 Superpowers 的完整架构图。点击任意组件,了解它的作用。

🚀 会话入口层

🔗
SessionStart Hook
📋
using-superpowers

🧠 核心技能层

💡
brainstorming
📝
writing-plans
🧪
test-driven-dev
🔍
systematic-debugging

🤖 执行与协作层

🤖
subagent-driven-dev
dispatching-parallel
👁️
code-review
点击任意组件查看详细说明

架构理解测验

Superpowers 技能是如何「自动」对 AI 生效的?不需要你每次手动告诉 AI"请使用 Superpowers"。

一个技能文件(SKILL.md)包含哪两个主要部分?

03

技能如何被触发

从你说出第一个字,到 AI 决定调用哪个技能——这中间发生了什么?

AI 助手的内心决策流程

当你发送一条消息时,装了 Superpowers 的 AI 助手不会直接回答。它先走一遍内部决策流程:

1

收到你的消息

2

有没有 1% 的可能某个技能适用?

3

如果有,调用 Skill 工具

4

读取技能内容,按照指令行动

5

最终回复你

🔑
关键规则:1% 原则

using-superpowers 明确规定:只要有 1% 的可能某个技能适用,就必须调用它。这个严格的门槛防止 AI 用「这次太简单了,不需要」来跳过本应执行的流程。

一次技能调用的全过程(对话演示)

想象你说了一句"我想给 App 加一个深色模式"。下面是 AI 内部"对话"的展开过程:

技能如何知道「这次该用我」?

每个技能文件顶部的 description 字段就是匹配的钥匙。

AI 助手在决策时,会把你的消息与每个技能的 description 做语义匹配。description 写得越精准,触发越准确。

brainstorming SKILL.md
description: "You MUST use this
 before any creative work -
 creating features, building
 components, adding functionality,
 or modifying behavior. Explores
 user intent, requirements and
 design before implementation."
为什么这样写

「You MUST」是强制性语气,告诉 AI 这不是建议

「before any creative work」定义了时机:所有创造性工作之前

列举具体场景:创建功能、搭建组件……

这些关键词让 AI 更容易匹配「我想加个功能」这类请求

最后说明目的:在实现之前探索需求

防止 AI 偷懒的「红旗清单」

using-superpowers 技能里有一张特别有意思的表格——「Red Flags(红旗)」。它列出了 AI 最常见的自我欺骗借口,以及这些借口背后的真相:

「这只是个简单问题」 真相:问题也是任务。检查技能。
「我需要先收集更多信息」 真相:技能检查要在收集信息之前,不是之后。
「技能用在这里太小题大做了」 真相:简单的事情会变复杂。使用技能。
「我记得这个技能的内容」 真相:技能会更新。读当前版本,不要凭记忆。
「让我先快速做这件小事」 真相:在做任何事之前先检查技能。
🧠
这为什么对你有用?

这张表格解释了为什么 AI 有时候会跳过本该执行的流程——它在「合理化」跳过的理由。理解这一点,当 AI 跳过流程时你就知道该如何纠正它。

技能触发机制测验

你想创建一个自定义技能「every-time-i-push-code」,希望每次有代码推送时自动触发。哪个部分最关键?

你的 AI 助手说:「这个 Bug 很小,我直接改就好,不需要走 systematic-debugging 流程」。根据 using-superpowers 的规则,这个判断是否正确?

04

Agent 调度模式

当任务太大,一个 AI 做不完——Superpowers 怎么把工作分发给多个 Agent?

像邮政系统一样分发任务

想象一家大型快递公司的分拣中心。每个包裹到达后,中心不会让同一个工人从头跑到尾——它把包裹按目的地分类,分发给不同的快递员同时派送。

子 Agent 就是这些快递员:接到精确指令,执行一个任务,完成后汇报。

💡
为什么要用「新鲜」的子 Agent?

subagent-driven-development 技能明确说明:子 Agent 不应继承主 Agent 的历史上下文。一个带着 100 条对话历史的 Agent 更容易被「记忆」干扰,做出错误决定。干净的上下文 = 更准确的执行。

subagent-driven-development 的执行流程

点击「下一步」,跟随一个任务从计划到完成的完整旅程:

🎯
主 Agent
(协调者)
🔨
实现子 Agent
(执行者)
👁️
审查子 Agent
(质量守门)
点击「下一步」开始

两阶段代码审查:为什么要分两次?

subagent-driven-development 的核心设计:完成每个任务后,总是经过两次独立审查,而不是一次。

SKILL.md 节选
## Two-Stage Review

Stage 1: Spec Compliance Review
- Does code match the spec?
- Are all requirements met?
- Missing functionality?

Stage 2: Code Quality Review
- Is the code clean?
- Error handling correct?
- Test coverage adequate?
为什么分两次审查

两个审查关注不同维度,不能合并

第一轮:对照设计文档检查功能完整性

「你实现了规格要求的所有功能吗?」

这个问题与代码风格无关

第二轮:独立于功能,审查代码本身质量

「代码写得好不好?维护性如何?」

这个问题与是否满足规格无关

并行执行 vs 顺序执行

Superpowers 有两种执行模式,选哪个取决于任务之间是否相互依赖:

dispatching-parallel-agents

多个任务同时进行。像同时发出多封快递,而不是等第一封送达再发第二封。适用于互不依赖的任务。

📋

subagent-driven-development

一次一个任务,完成→审查→再下一个。像流水线作业。当后面的任务依赖前面任务的输出时使用。

🎛️

executing-plans

批次执行并在关键检查点暂停等待人工确认。在多个 Claude Code 会话中并行执行。

🔧
如何帮 AI 选对执行模式?

问自己:任务 B 需要等待任务 A 完成吗?如果是 → subagent-driven-development。如果否 → dispatching-parallel-agents,速度更快。

Agent 调度模式测验

场景

你有一个功能待办列表:① 添加用户头像上传 ② 实现邮件通知 ③ 添加数据导出功能。这三个功能互相独立,都不依赖对方完成。

对于这三个相互独立的功能,哪种执行策略最优?

为什么 subagent-driven-development 坚持「两阶段」审查,而不是用一个 Agent 做所有审查?

05

钩子与会话启动

Superpowers 是如何在你什么都不做的情况下「自动激活」的?揭秘 SessionStart Hook

钩子(Hook)是什么?

把钩子想象成门铃感应器:你一进门,感应器自动触发,灯就亮了。你不需要手动开灯——它在你行动的那一刻自动响应。

Hook(钩子)就是这种「事件触发自动运行」的机制。

hooks/hooks.json
{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|clear|compact",
        "hooks": [{
          "type": "command",
          "command": "run-hook.cmd session-start",
          "async": false
        }]
      }
    ]
  }
}
逐行解读

这是一个 JSON 配置文件

hooks 下面定义了各种钩子

SessionStart:会话开始这个事件

matcher:匹配「startup/clear/compact」等开始信号

满足条件就执行下面的 hooks 列表

类型是命令(运行一个脚本)

要运行的脚本:session-start

async: false 表示同步执行(要等它完成才继续)

session-start 脚本做了什么?

当你打开 AI 编程工具时,session-start 脚本悄悄完成了这几件事:

1
读取 using-superpowers/SKILL.md

把技能系统的引导手册全文读入内存

2
处理特殊字符(JSON 转义)

把引号、换行符等字符转义,确保内容能嵌入 JSON 而不破坏格式

3
判断当前 AI 平台

Claude Code、Cursor、Copilot CLI 的接口格式不同,脚本会自动适配

4
注入技能内容到 AI 上下文

以 additionalContext 格式返回内容,AI 在第一次回复前就已读到技能规则

session-start 脚本的核心逻辑

这是脚本里最重要的部分——平台适配逻辑:

hooks/session-start(节选)
if [ -n "${CURSOR_PLUGIN_ROOT:-}" ]; then
  printf '{"additional_context":"%s"}' \
    "$session_context"
elif [ -n "${CLAUDE_PLUGIN_ROOT:-}" ] \
  && [ -z "${COPILOT_CLI:-}" ]; then
  printf '{"hookSpecificOutput":
    {"additionalContext":"%s"}}' \
    "$session_context"
else
  printf '{"additionalContext":"%s"}' \
    "$session_context"
fi
逐行解读

如果 Cursor 环境变量存在,说明在 Cursor 里运行

Cursor 期待的格式是 additional_context(下划线)

把技能内容填入这个格式

如果有 CLAUDE_PLUGIN_ROOT 但没有 COPILOT_CLI

说明在 Claude Code 里运行

Claude Code 期待嵌套格式:hookSpecificOutput.additionalContext

把技能内容填入 Claude Code 的格式

其他所有平台(Copilot CLI 等)

用标准 SDK 格式:顶层 additionalContext

🔧
为什么要适配多个平台?

Superpowers 支持 Claude Code、Cursor、Copilot CLI、Gemini CLI 等多个工具。每个平台读取附加上下文的 API 格式都稍有不同。这段脚本就是「翻译层」——确保技能内容在任何平台上都能被正确注入。

如果没有 Hook,技能还能用吗?

CLAUDE.md 明确指出:「没有 using-superpowers bootstrap 的集成不是真正的集成」。让我们看看有没有 Hook 的区别:

钩子机制测验

session-start 脚本如何知道自己运行在 Cursor 还是 Claude Code 里?

你在为一个新的 IDE 添加 Superpowers 支持。你把所有 skills/ 文件复制过去了,但没有配置 SessionStart Hook。这算真正集成吗?

06

真实工作流实战

把所有模块串起来:一个完整功能从想法到合并,Superpowers 全程是怎么工作的?

完整工作流的 7 个阶段

Superpowers 的 README 描述了一个完整的开发工作流。我们用「给电商 App 添加购物车功能」来走一遍全程:

1
brainstorming — 需求探索

「我想加购物车」→ AI 开始提问:支持多商品吗?需要持久化吗?与库存系统联动?

2
using-git-worktrees — 创建隔离工作区

在新的 git branch 上创建 worktree,运行项目初始化,验证测试基线干净

3
writing-plans — 制定实现计划

把设计文档拆成 2-5 分钟的微任务,每个任务有文件路径、代码片段、验证步骤

4
subagent-driven-development — 执行

逐任务派子 Agent 执行,每个任务两阶段审查后才进下一个

5
test-driven-development — 全程 TDD

每行新代码之前都有失败的测试,没有测试就没有代码。铁律。

6
requesting-code-review — 最终审查

所有任务完成后,对比原始计划检查遗漏,生成审查报告

7
finishing-a-development-branch — 收尾

验证测试、选择合并方式(合并/PR/暂存/丢弃),清理 worktree

TDD 技能的核心:铁律

TDD 的哲学不复杂,但执行要求非常严格。test-driven-development 技能里有一段「铁律」:

test-driven-development/SKILL.md
## The Iron Law

NO PRODUCTION CODE
WITHOUT A FAILING TEST FIRST

Write code before the test? Delete it.
Start over.

## No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete
为什么这么严格

「铁律」意味着没有例外,没有协商

没有失败的测试,就不能写任何生产代码

先写了代码再写测试?结果:

把代码删掉,重新开始

不能留着当「参考」再慢慢写测试

不能边「适配」测试边保留代码

不能偷看已写代码再补测试

删除就是彻底删除,没有回头路

⚠️
为什么要这么严格?

如果你在写代码之后才写测试,你潜意识里会让测试「配合」代码通过,而不是真正验证需求。TDD 的价值在于:先定义「正确」,再写代码去达到它。顺序反了,整个意义就没了。

动手练习:组装一个技能文件

现在你理解了技能的结构,来试试把一个技能文件的各个部分对应到正确的区域:

name: deploy-checker
description: "Use before any deployment..."
<HARD-GATE>...</HARD-GATE>
## Checklist: - [ ] Step 1...

YAML 头部 — 技能的唯一标识符

拖放到这里

YAML 头部 — AI 决定是否触发技能的依据

拖放到这里

技能正文 — 硬性禁止区(在条件满足前不得执行)

拖放到这里

技能正文 — 具体操作步骤(AI 逐步执行的清单)

拖放到这里

理解 Superpowers 让你成为更好的 AI 指挥官

学完这门课,你获得了什么?不只是「Superpowers 是什么」的知识,而是在实际使用中能用上的技能:

🎯
精确下指令

你现在知道「先用 brainstorming 技能,然后 writing-plans」比「帮我做 XX 功能」能得到好 10 倍的结果

🔎
识别 AI 在偷懒

当 AI 说「这太简单了不需要流程」,你知道这是 Red Flag,可以纠正它

🔧
扩展技能体系

你理解了 SKILL.md 的结构,可以为自己的项目写自定义技能(YAML 头 + 正文 + 清单)

🐛
脱离 Bug 死循环

遇到 AI 反复出错,你会说「用 systematic-debugging 技能,从第一阶段开始」而不是无脑重试

综合测验:你能指挥 Superpowers 了吗?

综合场景

你正在用 Claude Code + Superpowers 构建一个 SaaS 产品。你想今天完成:① 用户注册/登录 ② 上传头像 ③ 修复一个已知的邮件发送 Bug。

你应该先用哪个技能开始今天的工作?

brainstorming 结束、writing-plans 写完计划后,准备执行两个新功能。注册和头像上传互不依赖。选哪个执行策略?

子 Agent 完成了注册功能的代码,但说「测试还没写,等功能完善了再补」。这个行为符合 TDD 铁律吗?

你现在掌握了什么?

🎓
课程总结

你学会了 Superpowers 的本质(给 AI 装操作手册)、架构(skills + hooks + agents)、触发机制(SessionStart Hook + 1% 原则)、Agent 调度模式(串行/并行/两阶段审查)、以及完整的 7 阶段开发工作流。

🚀
下一步

安装 Superpowers,在你的下一个项目里用一次完整的 brainstorming → writing-plans → subagent-driven-development 工作流。感受 AI 在明确规范下能自主工作多久,而不需要你随时盯着。