超能力是什么?
从一句"帮我做个 Todo App"开始,看看 Superpowers 如何改变 AI 编程助手的行为方式
你有没有遇到过这种情况?
你对 AI 编程助手说:"帮我做一个待办事项应用"。它立刻开始写代码——文件一个接一个地涌出,几百行代码出现在屏幕上。然后你发现:它完全猜错了你的需求。
这是 AI 编程助手 的默认行为:收到请求就行动,没有停下来问"你真正想要的是什么?"
给 AI 助手装上一套「技能库」,让它在对的时机自动触发对的行为——而不是每次都需要你手动提醒它"先别写代码,先讨论需求"。
装上 Superpowers 之后,同样这句话会发生什么
你说:"帮我做一个待办事项应用"。这次,AI 助手不会立刻写代码。它会先触发 brainstorming(头脑风暴)技能,问你:
个人使用还是团队协作?桌面还是手机?
是截止日期提醒、标签分类,还是和日历同步?
为什么不用 Notion 或者苹果自带的提醒事项?
拿到你的确认后,才进入实现计划阶段
什么是"技能"(Skill)?
把 AI 编程助手想象成一个刚加入团队的新人。他很聪明,但不了解你们团队的工作规范——什么时候写测试、怎么做代码审查、遇到 Bug 先查什么。
技能(Skill)就是这份操作手册。每个技能文件描述一个具体的工作场景和对应的操作流程。
brainstorming
写代码前先理清需求,通过提问把模糊想法变成清晰设计
test-driven-development
先写测试,再写代码。确保每行代码都经过验证
systematic-debugging
遇到 Bug 时用系统化的 4 阶段方法找到根本原因
requesting-code-review
任务完成后按清单审查,确保质量符合标准再提交
为什么这对你很重要?
如果你用自然语言指挥 AI 工具来构建软件,你可能遇到过这些困境:
Superpowers 的 systematic-debugging 技能让 AI 用系统化方法追查根本原因,而不是随机猜测
verification-before-completion 技能强制 AI 在说"完成了"之前先自己验证
subagent-driven-development 技能让 AI 把大任务分解给多个子 Agent 并行执行,无需你每步确认
最聪明的开发者不是写代码最快的,而是在错误方向上浪费最少时间的。Superpowers 的每个技能都是一道「防止走错路」的护栏。
快速检验:你理解了吗?
一位朋友问你"Superpowers 是什么",下面哪个回答最准确?
你想添加一个「用户可以给待办事项设置优先级」的功能,AI 助手立刻开始改数据库结构和前端代码。这时候应该触发哪个技能,让 AI 先停下来想清楚?
技能体系架构
认识 Superpowers 的主要组成部分——它们各自是谁,负责什么,住在哪里
认识主要角色
想象一下一家运转良好的公司:有人写规章制度,有人负责入职培训,有人在需要时自动发出提醒。Superpowers 也是这样分工的。
一个技能文件长什么样?
每个技能文件是一个 Markdown 文档,包含三个关键部分。我们来看 brainstorming 技能的开头:
---
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 的完整架构图。点击任意组件,了解它的作用。
🚀 会话入口层
🧠 核心技能层
🤖 执行与协作层
架构理解测验
Superpowers 技能是如何「自动」对 AI 生效的?不需要你每次手动告诉 AI"请使用 Superpowers"。
一个技能文件(SKILL.md)包含哪两个主要部分?
技能如何被触发
从你说出第一个字,到 AI 决定调用哪个技能——这中间发生了什么?
AI 助手的内心决策流程
当你发送一条消息时,装了 Superpowers 的 AI 助手不会直接回答。它先走一遍内部决策流程:
收到你的消息
有没有 1% 的可能某个技能适用?
如果有,调用 Skill 工具
读取技能内容,按照指令行动
最终回复你
using-superpowers 明确规定:只要有 1% 的可能某个技能适用,就必须调用它。这个严格的门槛防止 AI 用「这次太简单了,不需要」来跳过本应执行的流程。
一次技能调用的全过程(对话演示)
想象你说了一句"我想给 App 加一个深色模式"。下面是 AI 内部"对话"的展开过程:
技能如何知道「这次该用我」?
每个技能文件顶部的 description 字段就是匹配的钥匙。
AI 助手在决策时,会把你的消息与每个技能的 description 做语义匹配。description 写得越精准,触发越准确。
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 的规则,这个判断是否正确?
Agent 调度模式
当任务太大,一个 AI 做不完——Superpowers 怎么把工作分发给多个 Agent?
像邮政系统一样分发任务
想象一家大型快递公司的分拣中心。每个包裹到达后,中心不会让同一个工人从头跑到尾——它把包裹按目的地分类,分发给不同的快递员同时派送。
子 Agent 就是这些快递员:接到精确指令,执行一个任务,完成后汇报。
subagent-driven-development 技能明确说明:子 Agent 不应继承主 Agent 的历史上下文。一个带着 100 条对话历史的 Agent 更容易被「记忆」干扰,做出错误决定。干净的上下文 = 更准确的执行。
subagent-driven-development 的执行流程
点击「下一步」,跟随一个任务从计划到完成的完整旅程:
(协调者)
(执行者)
(质量守门)
两阶段代码审查:为什么要分两次?
subagent-driven-development 的核心设计:完成每个任务后,总是经过两次独立审查,而不是一次。
## 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 会话中并行执行。
问自己:任务 B 需要等待任务 A 完成吗?如果是 → subagent-driven-development。如果否 → dispatching-parallel-agents,速度更快。
Agent 调度模式测验
你有一个功能待办列表:① 添加用户头像上传 ② 实现邮件通知 ③ 添加数据导出功能。这三个功能互相独立,都不依赖对方完成。
对于这三个相互独立的功能,哪种执行策略最优?
为什么 subagent-driven-development 坚持「两阶段」审查,而不是用一个 Agent 做所有审查?
钩子与会话启动
Superpowers 是如何在你什么都不做的情况下「自动激活」的?揭秘 SessionStart Hook
钩子(Hook)是什么?
把钩子想象成门铃感应器:你一进门,感应器自动触发,灯就亮了。你不需要手动开灯——它在你行动的那一刻自动响应。
Hook(钩子)就是这种「事件触发自动运行」的机制。
{
"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 脚本悄悄完成了这几件事:
把技能系统的引导手册全文读入内存
把引号、换行符等字符转义,确保内容能嵌入 JSON 而不破坏格式
Claude Code、Cursor、Copilot CLI 的接口格式不同,脚本会自动适配
以 additionalContext 格式返回内容,AI 在第一次回复前就已读到技能规则
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。这算真正集成吗?
真实工作流实战
把所有模块串起来:一个完整功能从想法到合并,Superpowers 全程是怎么工作的?
完整工作流的 7 个阶段
Superpowers 的 README 描述了一个完整的开发工作流。我们用「给电商 App 添加购物车功能」来走一遍全程:
「我想加购物车」→ AI 开始提问:支持多商品吗?需要持久化吗?与库存系统联动?
在新的 git branch 上创建 worktree,运行项目初始化,验证测试基线干净
把设计文档拆成 2-5 分钟的微任务,每个任务有文件路径、代码片段、验证步骤
逐任务派子 Agent 执行,每个任务两阶段审查后才进下一个
每行新代码之前都有失败的测试,没有测试就没有代码。铁律。
所有任务完成后,对比原始计划检查遗漏,生成审查报告
验证测试、选择合并方式(合并/PR/暂存/丢弃),清理 worktree
TDD 技能的核心:铁律
TDD 的哲学不复杂,但执行要求非常严格。test-driven-development 技能里有一段「铁律」:
## 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 的价值在于:先定义「正确」,再写代码去达到它。顺序反了,整个意义就没了。
动手练习:组装一个技能文件
现在你理解了技能的结构,来试试把一个技能文件的各个部分对应到正确的区域:
YAML 头部 — 技能的唯一标识符
YAML 头部 — AI 决定是否触发技能的依据
技能正文 — 硬性禁止区(在条件满足前不得执行)
技能正文 — 具体操作步骤(AI 逐步执行的清单)
理解 Superpowers 让你成为更好的 AI 指挥官
学完这门课,你获得了什么?不只是「Superpowers 是什么」的知识,而是在实际使用中能用上的技能:
你现在知道「先用 brainstorming 技能,然后 writing-plans」比「帮我做 XX 功能」能得到好 10 倍的结果
当 AI 说「这太简单了不需要流程」,你知道这是 Red Flag,可以纠正它
你理解了 SKILL.md 的结构,可以为自己的项目写自定义技能(YAML 头 + 正文 + 清单)
遇到 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 在明确规范下能自主工作多久,而不需要你随时盯着。