不只是 Prompt：用 Superpowers Skill 给 AI 编程装上工程化工作流

很多人第一次用 AI 编程工具时，都会有一种"开挂"的感觉。

无论你使用的是 Claude Code、Cursor、Codex CLI、OpenCode，还是基于 GPT、Claude、Gemini、DeepSeek、Qwen 等模型搭建的智能体系统，AI 都能非常快地生成代码、解释报错、补测试、写文档。

但用久之后，另一个问题也会越来越明显：

AI 写代码很快，但不一定稳。

它可能会：

需求还没问清楚就开始写代码；
一边写一边改方向；
改一个小功能却影响一大片文件；
测试补得不完整，甚至完全不写测试；
上下文一长就前后矛盾；
修 Bug 时靠猜，越修越乱；
代码能跑，但长期维护成本很高。

这就是典型的 Vibe Coding：凭感觉 coding。

AI 本身很聪明，但如果没有流程约束，它就像一个反应很快、但缺少工程纪律的开发者。

而 Superpowers Skill 要解决的，正是这个问题。

它不是简单的一组 Prompt 模板，而是一套面向 AI 编程智能体的 Agentic Skills Framework。它把成熟软件工程中的需求澄清、计划制定、测试驱动开发、子任务拆分、代码审查、系统化调试、Git 隔离等方法，封装成一个个可调用的 Skill，让 AI 按照工程流程做事。

一句话总结：

Superpowers Skill 的核心价值，不是让 AI 更会"生成代码"，而是让 AI 更会"交付代码"。

一、Superpowers Skill 是什么？

Superpowers 是一套可组合的 AI 编程技能框架。

你可以把它理解为：

把资深工程师、架构师、测试工程师和代码审查者的工作方法，拆成一组 AI 可以执行的 Skill。

每个 Skill 通常会定义：

什么时候应该使用；
使用前需要确认什么；
具体执行步骤是什么；
哪些地方必须暂停确认；
哪些行为是反模式；
如何验证结果；
如何进行 Review；
如何完成收尾。

它的理念可以概括为一句话：

Process over Prompt：流程大于提示词。

传统 AI 编程更多依赖 Prompt。

比如你告诉 AI：

请你像一个资深工程师一样实现这个功能。

但问题是，这种约束很容易随着上下文变长而失效。

Superpowers 的思路不同。它不是只让你写一句"请认真点"，而是把"认真工作"的过程拆成明确步骤：

rust 复制代码

Brainstorm
  ↓
Write Plan
  ↓
Execute Plan
  ↓
TDD
  ↓
Debug / Review
  ↓
Finish Branch

这样，AI 不再是想到哪写到哪，而是像一个小型开发团队一样工作。

二、为什么 Superpowers 不应该只被理解为某个工具的插件？

很多人是通过 Claude Code 接触 Superpowers 的，因为 Claude Code 对插件、Slash Command 和 Agentic Workflow 的支持比较完整，体验也很顺。

但从本质上说，Superpowers 的价值不只属于 Claude。

它真正重要的是 Skill 思想。

只要你的 AI 编程工具或智能体系统具备以下能力，就可以借鉴或使用类似 Superpowers 的工作流：

能读取项目文档或 Skill 文件；
能根据任务选择合适流程；
能编辑代码；
能运行测试和命令；
能调用 Git；
能拆分任务；
能进行代码审查；
能在关键节点等待人类确认。

因此，它可以被应用在：

Claude Code；
Cursor；
Codex CLI；
OpenCode；
Aider 类工具；
企业内部 Dev Agent；
基于 LangChain、AutoGen、CrewAI、Dify、Coze 等搭建的智能体；
自研 AI 编程平台。

也就是说，Superpowers 不只是"某个模型的外挂"，而是一套 AI 编程工程化方法。

三、Superpowers 的核心 Skill 总览

Superpowers 提供了多个 Skill，不同版本可能会持续更新，具体名称和数量以官方仓库为准。下面按照功能类型，把常见核心 Skill 系统介绍一遍。

可以大致分为六类：

markdown 复制代码

1. 元技能
   - using-superpowers
   - writing-skills

2. 需求与规划技能
   - brainstorming
   - writing-plans

3. 执行与任务拆分技能
   - executing-plans
   - subagent-driven-development
   - dispatching-parallel-agents
   - using-git-worktrees

4. 质量保障技能
   - test-driven-development
   - requesting-code-review
   - receiving-code-review

5. 调试与可靠性技能
   - systematic-debugging
   - root-cause-tracing
   - defense-in-depth

6. 收尾与协作技能
   - finishing-a-development-branch
   - collaboration / team workflow 类技能

下面逐个展开。

四、元技能：让 AI 学会"如何使用技能"

1. using-superpowers：技能调度入口

这是 Superpowers 体系中的基础技能。

它的作用不是直接写代码，而是告诉 AI：

遇到任务时，先判断是否应该调用某个 Skill，而不是直接动手。

这点非常关键。

很多 AI 编程失控，都是因为 AI 太快进入编码状态。

而 using-superpowers 会让 AI 先停下来思考：

这个任务是否需要需求澄清？
是否需要写计划？
是否涉及测试？
是否需要子代理？
是否需要 Git 隔离？
是否需要 Code Review？
是否是调试任务？

例如你说：

帮我实现一个用户登录功能。

普通 AI 可能直接开始写代码。

启用 Superpowers 后，它更可能先判断：

需求还不清楚，应该先 brainstorming；
登录功能涉及安全，应该写 plan；
核心逻辑需要 TDD；
完成后需要 code review。

所以这个技能可以理解为 Superpowers 的"技能路由器"。

2. writing-skills：创建你自己的 Skill

这是 Superpowers 里最有想象力的技能。

它让 AI 不只是使用已有 Skill，还能帮你创建新的 Skill。

比如你可以说：

创建一个适用于我们团队的 Next.js 性能优化 Skill，要求包含 Core Web Vitals 检查、图片优化、组件懒加载、动态导入、Lighthouse 验证和上线前 checklist。

AI 会生成一个结构化的 Skill 文档，通常包括：

什么时候使用；
输入要求；
执行步骤；
检查清单；
验证命令；
反模式；
示例；
完成标准。

这意味着你可以把团队内部经验沉淀成 AI 可执行的流程。

例如：

前端组件开发 Skill；
数据库迁移 Skill；
API 设计 Skill；
安全审查 Skill；
教育平台题库生成 Skill；
教学评价分析 Skill；
论文格式检查 Skill；
线上故障复盘 Skill。

它的价值在于：

把个人或团队的工程经验，变成可复用、可传承、可自动执行的 AI 工作流。

五、需求与规划技能：先想清楚，再动手写

3. brainstorming：需求澄清技能

Brainstorming 是 Superpowers 工作流的第一步。

它的核心目标是：

把模糊需求变成清晰规格。

很多时候，我们给 AI 的需求其实很模糊。

比如：

我想做一个 AI 辅助备课系统。

普通 AI 可能马上开始设计页面和接口。

但 brainstorming 会先追问：

目标用户是谁？中小学教师、大学教师，还是教培机构？
核心场景是什么？生成教案、生成课件、布置作业，还是学情分析？
是否需要支持不同学段、学科、教材版本？
是否需要对齐课程标准？
是否要导出 Word、PPT、PDF？
是否需要学生端？
是否有隐私和数据合规要求？
MVP 阶段最重要的功能是什么？

经过这一轮澄清后，AI 会输出更清晰的内容：

用户画像；
使用场景；
用户故事；
功能边界；
MVP 范围；
页面流程；
数据模型草案；
风险点。

这一步看起来会花时间，但它能减少后期大量返工。

尤其是业务系统、教育平台、金融系统、权限系统、订单系统这类复杂项目，需求澄清比直接写代码更重要。

4. writing-plans：实施计划技能

当需求清楚后，下一步不是马上写代码，而是写计划。

writing-plans 会把需求转化成可执行的工程计划。

一个好的计划通常包括：

背景和目标；
技术方案；
文件级别的修改范围；
数据结构变化；
API 设计；
测试策略；
风险点；
验证命令；
人工确认点；
回滚方案。

例如要实现"课程资源上传功能"，计划可能是：

markdown 复制代码

## 目标

支持教师上传课程资源，包括 PDF、PPT、Word 和视频文件。

## 修改文件

- src/features/resources/api/uploadResource.ts
- src/features/resources/components/UploadResourceDialog.tsx
- src/features/resources/types.ts
- src/features/resources/__tests__/uploadResource.test.ts

## 实现步骤

1. 新增资源类型定义
2. 实现上传 API 封装
3. 增加文件类型和大小校验
4. 实现上传弹窗组件
5. 添加上传进度和错误状态
6. 编写单元测试
7. 运行 lint、test、build

## 风险

- 大文件上传失败重试
- 文件类型伪造
- 存储服务异常
- 权限校验遗漏

计划的价值在于：

人类可以先审查方案，再让 AI 执行。

这样可以避免 AI 一上来就改代码，也能减少"需求理解错了但已经改了一堆"的情况。

六、执行与任务拆分技能：让 AI 像团队一样工作

5. executing-plans：严格按计划执行

executing-plans 负责把 writing-plans 生成的计划落地。

它的重点是：

按计划执行，不自由发挥。

执行过程中，AI 会：

按任务逐项推进；
每一步只做计划内的事情；
修改文件前确认意图；
完成后运行对应验证；
遇到偏差及时报告；
在关键决策点暂停询问。

例如计划中写了：

修改 src/features/auth/login.ts，增加二次验证码校验。

AI 就不应该顺手重构整个 auth 模块，除非计划中明确要求。

这个 Skill 能显著降低 AI 编程中的"范围蔓延"。

6. subagent-driven-development：子代理驱动开发

当任务变复杂时，一个 AI 在同一个上下文里从头做到尾，容易出问题。

subagent-driven-development 的思路是：

把复杂任务拆成多个小任务，交给多个子代理处理。

比如要开发一个"在线考试系统"，可以拆成：

子代理 A：设计考试数据模型；
子代理 B：实现试卷创建 API；
子代理 C：实现学生答题页面；
子代理 D：实现自动判分逻辑；
子代理 E：编写测试；
子代理 F：做代码审查。

每个子代理只处理一个较小的任务，拥有更干净的上下文。

这样可以减少：

上下文污染；
任务混淆；
长对话遗忘；
重复实现；
前后矛盾。

这很接近真实团队协作：

不是一个人把所有事情从头写到尾，而是任务拆分、并行开发、统一整合。

7. dispatching-parallel-agents：并行代理派发

subagent-driven-development 解决的是"拆任务"。

dispatching-parallel-agents 进一步解决"并行执行"。

适合那些相互独立、可以同时推进的任务。

例如要实现一个"教师工作台"功能，可以并行拆成：

Agent A：实现课程列表组件；
Agent B：实现待批改作业模块；
Agent C：实现课堂数据统计卡片；
Agent D：编写 mock 数据和测试；
Agent E：检查 UI 一致性。

并行代理的优势是：

提高复杂任务推进效率；
每个代理上下文更短；
不同模块可以独立验证；
主代理最终统一合并和审查。

但并行也有风险，所以通常需要搭配 Git worktree 或明确的文件边界，避免多个 Agent 同时修改同一文件造成冲突。

8. using-git-worktrees：用 Git Worktree 隔离工作区

AI 改代码太快，这是优点，也是风险。

如果没有隔离环境，AI 很容易把当前工作区改乱。

using-git-worktrees 的作用是为不同任务创建独立的 Git 工作区。

例如：

css 复制代码

主工作区：稳定开发分支
worktree-a：实现权限模块
worktree-b：修复线上 Bug
worktree-c：尝试性能优化
worktree-d：实验性重构

这样每个任务都在独立目录中进行。

如果某个实验失败，可以直接丢弃，不污染主分支。

它特别适合：

大型重构；
多代理并行开发；
高风险实验；
修复线上 Bug；
同时开发多个功能；
需要保留稳定主工作区的场景。

对 AI 编程来说，worktree 是非常重要的安全网。

七、质量保障技能：让代码不仅能跑，还能长期维护

9. test-driven-development：测试驱动开发

TDD 是 Superpowers 中最重要的质量保障技能之一。

它要求 AI 遵循：

复制代码

RED → GREEN → REFACTOR

也就是：

先写测试；
运行测试，确认失败；
再写最小实现；
让测试通过；
最后重构。

这和很多 AI 默认行为正好相反。

普通 AI 经常是先写实现，再补测试。

甚至有时候测试只是为了"证明代码能过"，而不是真正验证需求。

TDD 技能会强制 AI 先证明测试能捕捉到未实现状态，再开始写业务代码。

例如实现"学生成绩等级换算"：

规则：

90 分以上为 A；
80-89 为 B；
70-79 为 C；
60-69 为 D；
60 以下为 E；
缺考为 Absent；
分数非法时抛出错误。

TDD 流程会先写测试：

正常分数；
边界分数；
小数分数；
缺考；
负数；
超过满分；
null / undefined；
字符串输入。

确认测试失败后，再写实现。

这对于下面这些场景尤其有价值：

金额计算；
权限判断；
订单状态机；
支付回调；
成绩计算；
自动批改；
题目推荐规则；
数据转换；
API 合约。

10. requesting-code-review：发起代码审查

当 AI 完成功能后，不应该直接结束。

requesting-code-review 会让 AI 主动发起代码审查。

它会要求审查者关注：

是否符合需求；
是否符合实施计划；
是否有安全漏洞；
是否有边界遗漏；
是否有重复代码；
是否有隐藏副作用；
是否有性能问题；
是否有测试覆盖；
是否有不必要的改动；
是否破坏兼容性。

这一步相当于让 AI 自己进入"提交 PR 后等待 Review"的状态。

11. receiving-code-review：处理代码审查意见

requesting-code-review 是"发起审查"，receiving-code-review 是"处理审查"。

它要求 AI 不要敷衍 Review 意见，而是逐条处理。

常见 Review 结果会分级：

复制代码

Critical：必须修复，否则不能合并
Warning：建议修复
Info：可选优化

例如：

diff 复制代码

Critical:
- API 缺少权限校验，普通学生可能访问教师资源。

Warning:
- 当前函数同时处理校验、上传和状态更新，建议拆分。

Info:
- 可以增加上传进度埋点，便于后续分析。

receiving-code-review 会让 AI：

逐条确认问题；
修改代码；
增加测试；
重新运行验证；
说明哪些已修复；
对不采纳的建议给出理由。

这能显著减少"AI 写完就算完成"的问题。

八、调试与可靠性技能：不要靠猜修 Bug

12. systematic-debugging：系统化调试

AI 修 Bug 时最危险的行为是：

看到报错就猜，然后直接改。

systematic-debugging 会强制 AI 使用更可靠的调试流程：

markdown 复制代码

1. 收集现象
2. 构建假设
3. 设计实验
4. 验证假设
5. 定位根因
6. 修复问题
7. 增加回归测试
8. 防止复发

例如系统出现：

学生已经提交作业，但教师端偶尔显示"未提交"。

普通 AI 可能直接改前端状态。

系统化调试会先问：

是前端缓存问题吗？
是接口返回延迟吗？
是数据库事务未提交吗？
是消息队列消费失败吗？
是提交状态被后续操作覆盖了吗？
是多端同步问题吗？
是否只发生在特定浏览器或网络环境？
日志中有没有相同 submissionId 的状态变化？

然后它会设计验证方法：

增加日志；
写复现脚本；
检查数据库记录；
构造并发提交；
模拟网络重试；
增加回归测试。

这种方式比"凭感觉修 Bug"可靠得多。

13. root-cause-tracing：根因追踪

root-cause-tracing 可以理解为 systematic-debugging 的进一步深化。

它强调：

不要只修表面症状，要追到真正根因。

例如线上出现"订单重复扣款"。

表面修复可能是：

如果发现重复订单，就跳过。

但根因追踪会继续问：

为什么会出现重复请求？
支付回调是否会重试？
幂等键是否正确使用？
数据库唯一约束是否存在？
分布式锁是否可能过期？
状态机是否允许重复流转？
日志是否能串起完整链路？

最终修复可能包括：

增加幂等表；
增加唯一约束；
修复事务边界；
优化锁超时时间；
增加回归测试；
增加监控告警。

它的价值是避免"修了一个现象，但根因还在"。

14. defense-in-depth：纵深防御

defense-in-depth 的思想来自安全工程：

不要只依赖一道防线，而是建立多层保护。

在 AI 编程中，这个技能非常重要。

比如实现"教师删除课程资源"功能，不能只在前端隐藏按钮。

需要多层防御：

前端控制按钮显示；
API 层校验用户身份；
Service 层校验资源归属；
数据库层限制操作范围；
审计日志记录删除行为；
软删除或回收站机制；
测试覆盖越权删除场景。

这样即使某一层出错，其他层也能兜底。

适合使用 defense-in-depth 的场景包括：

权限系统；
文件上传；
支付；
数据删除；
用户隐私；
教育数据安全；
管理后台；
多租户系统。

九、收尾与协作技能：把功能真正交付出去

15. finishing-a-development-branch：完成开发分支

很多 AI 编程工具的问题是：

代码写完了，但交付没完成。

finishing-a-development-branch 负责最后收尾。

它通常会做这些事：

运行完整测试；
运行 lint；
运行 build；
检查 Git diff；
确认是否有临时文件；
检查是否有调试日志；
总结本次改动；
列出验证结果；
提示是否合并、创建 PR 或保留分支；
清理 worktree。

一个良好的收尾总结可能是：

markdown 复制代码

## 本次完成内容

- 新增课程资源上传 API
- 新增上传弹窗组件
- 增加文件类型和大小校验
- 添加上传失败提示
- 补充单元测试

## 验证结果

- npm run test ✅
- npm run lint ✅
- npm run build ✅

## 风险说明

- 大文件断点续传暂未实现
- 视频转码仍依赖后端异步任务

## 建议下一步

- 增加上传进度埋点
- 支持资源预览

这一步非常接近真实开发中的 PR 总结。

16. collaboration / team workflow：协作类技能

有些版本或扩展中会包含协作相关 Skill。

这类 Skill 的目标是让 AI 更适合团队环境，而不只是单人写代码。

它通常关注：

如何与人类开发者确认需求；
如何在关键节点暂停；
如何给出清晰变更说明；
如何处理 Review 意见；
如何避免破坏团队约定；
如何生成便于团队理解的提交说明；
如何保持代码风格一致。

对于团队使用 AI 编程来说，这类 Skill 很有价值。

因为真实项目中，代码不是"能跑就行"，还要让团队其他人能看懂、能维护、能接着迭代。

十、推荐的完整工作流

如果你想完整体验 Superpowers 的价值，可以按照下面流程使用：

markdown 复制代码

1. using-superpowers
   先让 AI 判断应该使用哪些 Skill。

2. brainstorming
   澄清需求，确定范围。

3. writing-plans
   生成实施计划。

4. 人工审查计划
   确认方向，避免 AI 理解偏差。

5. using-git-worktrees
   为复杂任务创建隔离工作区。

6. executing-plans
   按计划逐步实现。

7. subagent-driven-development
   复杂任务拆给子代理。

8. dispatching-parallel-agents
   独立任务并行执行。

9. test-driven-development
   核心逻辑先写测试，再写实现。

10. systematic-debugging
    遇到 Bug 时按根因分析处理。

11. requesting-code-review
    完成后主动发起代码审查。

12. receiving-code-review
    根据 Review 意见修复问题。

13. defense-in-depth
    对安全和关键业务增加多层保护。

14. finishing-a-development-branch
    运行测试、总结变更、准备合并。

你可以直接对 AI 说：

复制代码

请按照 Superpowers 风格执行这个任务：
先判断需要使用哪些 Skill；
然后进行需求澄清；
再生成实施计划；
计划确认后使用 TDD 实现；
完成后进行代码审查和收尾。

如果是小任务，也可以使用轻量模式：

复制代码

这是一个小任务，请使用轻量 Superpowers 流程：
给出简短计划，完成实现，运行基本验证，最后做简短 Review。

十一、一个完整示例：开发"教师作业批改功能"

假设我们要开发一个教育平台功能：

教师可以查看学生提交的作业，进行批改、打分和评语反馈。

用 Superpowers 风格，可以这样推进。

1. Brainstorming

AI 先澄清需求：

支持哪些作业类型？
是文本作业、附件作业，还是选择题？
是否需要自动批改？
分数范围是多少？
是否支持评语模板？
学生是否能看到批改历史？
是否支持重新提交？
教师是否能批量批改？
是否需要导出成绩？

输出用户故事：

复制代码

作为教师，我希望查看班级所有学生的作业提交状态。
作为教师，我希望给每份作业打分并写评语。
作为学生，我希望查看教师反馈和得分。

2. Writing Plans

AI 生成计划：

diff 复制代码

修改模块：
- assignment submission API
- grading service
- teacher grading page
- student feedback page
- grading tests

风险：
- 权限校验
- 重复批改
- 分数范围校验
- 学生隐私
- 批改状态同步

3. TDD

先写测试：

教师能批改自己班级学生作业；
教师不能批改其他班级作业；
分数不能超过最大值；
空评语允许或不允许；
重复批改更新记录；
学生能看到反馈；
未批改作业不显示分数。

4. Execute Plan

AI 按计划实现：

数据模型；
API；
Service；
页面；
测试；
错误处理。

5. Code Review

审查发现：

diff 复制代码

Critical:
- 批改接口缺少教师与班级关系校验。

Warning:
- grading service 中包含过多页面展示逻辑。

Info:
- 可以增加评语模板功能作为后续优化。

6. Receiving Review

AI 修复 Critical：

增加权限校验；
增加越权测试；
重新运行测试。

7. Finish Branch

最终输出：

diff 复制代码

完成：
- 教师作业批改 API
- 教师批改页面
- 学生反馈展示
- 权限校验
- 单元测试和集成测试

验证：
- test passed
- lint passed
- build passed

这就是 AI 编程从"生成代码"到"交付功能"的完整过程。

十二、什么时候适合使用 Superpowers Skill？

适合场景

Superpowers 特别适合：

中大型功能开发；
长期维护项目；
多人协作项目；
企业内部系统；
教育平台；
业务规则复杂的系统；
权限、支付、订单、成绩、计费等关键模块；
遗留系统重构；
需要测试覆盖和代码审查的项目；
多 Agent 协作开发。

不太适合场景

如果只是：

一次性脚本；
临时 Demo；
小工具；
几行代码的修复；
不需要维护的实验；

完整流程可能会显得有点重。

这时可以只使用其中部分 Skill，比如：

只用 brainstorming；
只用 writing-plans；
只用 code-review；
只用 systematic-debugging。

Superpowers 的重点不是让所有任务都复杂化，而是让复杂任务不失控。

十三、Superpowers 带来的真正变化

Superpowers Skill 带来的最大变化，不是让 AI 写代码更快。

AI 本来就快。

真正的变化是：

AI 开始按照工程流程工作。

过去的 AI 编程像是：

复制代码

用户：帮我实现这个功能。
AI：好的，我直接开始写。

Superpowers 风格是：

复制代码

用户：帮我实现这个功能。
AI：我先澄清需求。
AI：然后写实施计划。
AI：请你确认计划。
AI：我会先写测试。
AI：测试失败后再实现。
AI：完成后运行验证。
AI：最后进行代码审查和分支收尾。

这两种体验差别非常大。

前者是 Vibe Coding。

后者是 Engineering Coding。

结语：AI 编程的下一阶段，是流程化和工程化

过去大家讨论 AI 编程，重点常常是：

哪个模型更强；
哪个工具补全更快；
哪个上下文更长；
哪个 Agent 更自动化。

这些当然重要。

但当 AI 真正进入生产项目后，你会发现另一个问题更关键：

没有工程流程的 AI，越强大，越容易把项目改乱。

Superpowers Skill 的价值就在这里。

它把软件工程中的优秀实践变成可执行的 Skill，让 AI 不只是会写代码，还能：

澄清需求；
制定计划；
拆分任务；
编写测试；
系统调试；
主动 Review；
隔离分支；
完成交付。

它不是某个模型专属的技巧，而是一套适用于多模型、多工具、多智能体系统的 AI 编程方法论。

一句话总结：

Superpowers Skill 不是让 AI 更会"炫技"，而是让 AI 更会"工程化交付"。