Superpowers 实战指南：装好了 CC 插件，然后呢？

小当家.1052026-06-20 19:33

Superpowers 实战指南：装好了 CC 插件，然后呢？

装完 Superpowers，/find-skills 一看，14 个 skill 整整齐齐。然后......就不知道该干嘛了。

目录

装好了，然后呢？

前两天在 Claude Code 里装了 Superpowers 插件。安装很简单，重启会话后输入 /find-skills，14 个 skill 列出来了。看起来很厉害------brainstorming、writing-plans、test-driven-development、systematic-debugging，每个名字都认识。

但问题是：我知道有这些工具，但不知道什么时候该用哪个。

就像你买了一套瑞士军刀，里面有钳子、螺丝刀、开瓶器、锯子。你知道每个工具的名字，但遇到一个具体问题时------比如这个螺丝该用十字还是六角------你还是得想一下。

这篇文章要解决的就是这个问题。不是 Superpowers 的功能清单，而是什么场景用什么 skill 的实战地图。每个 skill 配一个真实的开发场景，告诉你它什么时候该上场。

一句话定位：Superpowers 把软件工程的最佳实践固化成 AI 可遵循的工作流，核心理念是 Process over Prompt------流程大于提示词。你不需要每次都从零写 prompt，而是直接调用已验证的工作流。

Superpowers 是什么

Superpowers 是 Claude Code 的一个插件，内置 14+ 个结构化 skill，覆盖从需求分析到代码提交的完整开发生命周期。

安装方式：

复制代码 
/plugin install superpowers@claude-plugins-official

重启会话后，输入 /find-skills 验证安装成功。

调用方式有两种：

  • 带命名空间 ：/superpowers:brainstorm、/superpowers:executing-plans
  • 设为默认后直接调用 ：在插件设置里把 Superpowers 设为默认技能集，就可以直接用 /brainstorm

跟 spec-kit 的区别：spec-kit 是流水线------必须按立宪→定规→计划→拆解→执行的顺序走，跳过一步就报错。Superpowers 是工具箱------你想用哪个就用哪个，没有严格的先后顺序。写代码写到一半觉得该写测试了，随时调 /superpowers:test-driven-development，不用等前面的步骤。

14 个 Skill 全景图

按功能分为四大类：

分类 Skill 一句话用途
思考规划 brainstorming 将模糊想法转化为清晰的设计文档
思考规划 writing-plans 将设计文档拆解为可执行的任务计划
执行加速 executing-plans 按计划分步执行，每步完成后停下来确认
执行加速 subagent-driven-development 为独立子任务派发子代理，用独立上下文并行工作
执行加速 dispatching-parallel-agents 一次性派发多个子代理，实现真正并行
质量保障 test-driven-development 强制先写测试，再写代码的 TDD 工作流
质量保障 systematic-debugging 用系统化方法定位 bug 根因
质量保障 requesting-code-review 以多个 Agent 角色并行审查代码
质量保障 receiving-code-review 帮你理解和处理代码审查意见
质量保障 verification-before-completion 宣布完成前，执行最后一轮检查清单
收尾协作 finishing-a-development-branch 自动化完成合并、清理、提交等收尾工作
收尾协作 using-git-worktrees 通过 Git Worktree 实现分支环境隔离
收尾协作 using-superpowers 全家桶说明书，不确定用哪个时先问它
元技能 writing-skills 按规范创建全新的技能文件，实现无限扩展

接下来按分类逐个展开，每个 skill 配一个实战场景。

思考与规划类

brainstorming --- 动手前先想清楚

什么时候用： 需求模糊、方案不确定、技术选型犹豫。你脑子里有个大概想法，但还没想清楚具体怎么做。

实战场景： 做 AIGrader 课设的时候，最初的描述就是一句话------做一个 AI 批改系统。这个需求太模糊了：批改什么类型的题目？谁来出题？学生怎么提交？批改结果怎么展示？用什么 AI 模型？

直接让 AI 写代码的话，它会按自己的理解一通乱写，大概率跟你想要的不一样。正确做法是先调 brainstorming：

复制代码 
/superpowers:brainstorm

我想做一个 AI 作业批改系统，面向中小学教师和学生。
教师布置作业，学生提交，AI 自动批改并生成评语。

它会通过一系列提问帮你理清：批改哪些题型（选择题、填空题、主观题）？三种角色（教师、学生、管理员）各需要什么功能？用哪个 AI 模型？数据库怎么设计？

最终输出一份设计文档，包含功能清单、技术架构、数据库设计。这才是正确的起点------先想清楚，再动手。

writing-plans --- 把设计变成任务清单

什么时候用： 设计文档有了，需要拆成可执行的开发任务。不能直接把设计文档丢给 AI 说照着做------太大的任务 AI 会顾此失彼。

实战场景： AIGrader 的设计文档写完后，涉及 9 张数据库表、3 种角色权限、AI 批改引擎、前端 14 个页面。这个规模直接开发一定会乱。

复制代码 
/superpowers:writing-plans

以下是 AIGrader 的设计文档：[粘贴设计文档]
请拆解为可执行的开发任务。

它会输出一份带依赖关系和验收条件的任务清单。比如：

  • Task 1：建用户表和角色表（验收：能注册登录，角色隔离生效）
  • Task 2：实现 JWT 认证（验收：Token 签发/校验/黑名单全流程通过）
  • Task 3：实现 AI 批改引擎（验收：三种题型各有对应的评分策略，测试全绿）

每个任务有明确的输入和验收标准，不会出现做完了不知道对不对的情况。

执行与加速类

executing-plans --- 带检查点的流水线

什么时候用： 任务清单有了，需要一步步执行。和直接让 AI 写代码的区别在于：每步完成后会停下来等你确认，不会一口气跑完所有任务然后发现第三步就跑偏了。

实战场景： 做 NVC Practice 项目的一个功能模块------用户提交练习后 AI 评分并生成反馈。这个流程涉及数据库建表、后端 API、前端组件、AI 调用四个步骤。

复制代码 
/superpowers:executing-plans

按照以下任务计划执行：
1. 建 practice_records 表
2. 实现 POST /api/practice/submit 接口
3. 实现前端提交组件
4. 集成 AI 评分调用

它会先执行第 1 步，完成后停下来：建表 SQL 如下，确认执行吗？你说确认，它再进第 2 步。这样每一步你都有机会检查方向对不对，不会到最后才发现第二步的接口设计有问题。

subagent-driven-development --- 独立上下文并行

什么时候用： 子任务之间相互独立，可以并行处理。比如后端 API 和前端页面没有代码依赖，各写各的就行。

Claude Code 本身没有原生的子代理功能（不像 Codex 的 spawn_agent），这个 skill 补上了这个能力------为每个独立子任务派发一个全新的子代理，用独立的上下文窗口工作，不会被长对话的历史信息干扰。

实战场景： AIGrader 需要同时开发两个模块：评分策略模块（后端 Service + 策略模式实现）和成绩统计页面（前端 React + Recharts 图表）。这两个模块互不依赖。

复制代码 
/superpowers:subagent-driven-development

并行开发以下两个独立模块：
1. 评分策略模块：GradingStrategy 接口 + ChoiceGradingStrategy 实现
2. 成绩统计页面：ClassStats 组件 + Recharts 图表

dispatching-parallel-agents --- 批量派发

什么时候用： 更多并行任务，一次派多个 agent。适合大规模重构时，需要同时改多个模块的接口签名。

和 subagent-driven-development 的区别：后者是为 2-3 个独立子任务各派一个 agent，前者是批量派发，任务数量更多。

质量保障类

这是 Superpowers 里最实用的一类 skill，也是跟直接让 AI 写代码差距最大的地方。

test-driven-development --- 先写测试再写代码

什么时候用： 写核心业务逻辑时。不是所有代码都需要 TDD------CRUD 不用，但评分算法、数据校验、状态机流转这些关键逻辑，先写测试能避免很多后续 bug。

实战场景： AIGrader 的选择题评分策略。如果直接写实现，你可能忘了处理未作答的情况。用 TDD，先写测试用例：

复制代码 
/superpowers:test-driven-development

实现选择题评分策略 ChoiceGradingStrategy，要求：
- 学生答案与标准答案一致 -> 满分
- 学生答案与标准答案不一致 -> 0 分
- 学生未作答 -> 0 分，评语提示未作答
- 答案为空字符串 -> 按未作答处理

它会先写测试（红灯），再写实现让测试变绿（绿灯），最后重构优化。四个测试用例覆盖了正常、错误、未作答、边界值四种情况。如果直接写实现，最后那个空字符串的边界值大概率会漏掉。

systematic-debugging --- 别玄学调试了

什么时候用： 遇到 bug 但不知道根因，AI 也在瞎猜。你告诉它报错了，它猜一个原因改了代码，还是报错，它再猜------这就是玄学调试。

systematic-debugging 的方法论：假设->验证->缩小范围->找到根因。不是凭感觉改代码，而是系统化排查。

实战场景： 之前用 CCX 接小米 Mimo 模型，所有请求都返回 500 错误。如果直接问 AI，它可能猜是网络问题、API Key 过期、模型不支持等等，改一个试一个。

用 systematic-debugging 的思路：

复制代码 
/superpowers:systematic-debugging

CCX 代理所有请求返回 500，日志显示连接成功但首字生成阶段失败。

它会按步骤排查：

  1. 先验证 API 本身是否可用（直接 curl 测试 Mimo API）-> 可用
  2. 再验证 CCX 转发层（对比原始请求和转发请求的参数差异）-> 发现多了 OpenAI 标准参数
  3. 定位根因：Mimo API 参数校验严格，不支持 stream_options、tools 等参数，收到就 500
  4. 解决：在 CCX 配置里加 stripParams 过滤不支持的参数

四步到位，每步有假设、有验证、有结论。比玄学调试高效得多。

requesting-code-review --- 多角色审查

什么时候用： 写完一个模块，想找人 review 但没同事。一个人写代码最大的问题是盲区------你觉得没问题的逻辑，换个角度可能全是漏洞。

实战场景： 写完 JWT 认证模块（Token 签发、校验、双 Token 刷新），想找人审查安全性和性能。

复制代码 
/superpowers:requesting-code-review

请以安全工程师和性能工程师两个角色，审查 JWT 认证模块的代码。

它会以不同角色并行审查：安全工程师关注 Token 泄露防御、算法混淆攻击、黑名单完整性；性能工程师关注 Redis 调用频率、Token 校验的热路径开销。两个视角的审查意见同时返回，比单角色 review 覆盖面更广。

receiving-code-review --- 处理审查意见

什么时候用： 收到 review 意见后，需要理解每条意见的意图，判断哪些该改、哪些可以不改。这个 skill 帮你逐条分析审查意见，给出修改建议和优先级排序。

verification-before-completion --- 宣布完成前再查一遍

什么时候用： 准备 commit 之前。你觉得自己写完了，但真的写完了吗？测试跑了吗？文档更新了吗？类型检查过了吗？

复制代码 
/superpowers:verification-before-completion

它会执行最后一轮检查清单：测试通过、类型检查、lint 通过、文档同步、无 TODO 遗留。过了才允许你宣布完成。

收尾协作类

finishing-a-development-branch --- 自动化收尾

功能开发完成，需要合并、清理、提交。这个 skill 自动化这些收尾工作：检查分支状态、合并到主分支、清理临时文件、生成 commit message。

using-git-worktrees --- 分支环境隔离

需要同时在多个分支上开发时，用 Git Worktree 为每个分支创建独立的工作目录，避免频繁切换分支带来的冲突。

using-superpowers --- 全家桶说明书

不确定该用哪个 skill 时，先调这个。它会根据你当前的开发状态，推荐最合适的 skill。就像你不知道该用哪个工具时，先翻一下说明书。

writing-skills --- 最强元技能

什么时候用： 发现自己在重复某个工作流，想把它封装成可复用的 skill。

实战场景： 我写博客有一套固定流程------content-writer 写初稿、humanizer 去 AI 味、meta-tags-optimizer 优化 SEO。每次都要手动调三个 skill。用 writing-skills 可以把这个流程封装成一个自定义 skill：

复制代码 
/superpowers:writing-skills

我想创建一个博客写作 skill，流程是：
1. content-writer 写初稿
2. humanizer-zh 去 AI 味
3. meta-tags-optimizer 优化 SEO 标签

它会按规范生成 SKILL.md 文件，以后一句话就能触发整套流程。

总结：什么时候用什么

一张决策表，覆盖开发全流程：

开发阶段 推荐 Skill 触发时机
需求分析 brainstorming 需求模糊、方案不确定
任务拆解 writing-plans 设计文档有了，需要拆任务
编码执行 executing-plans + test-driven-development 按计划分步写代码，核心逻辑先写测试
并行开发 subagent-driven-development 子任务独立，需要并行处理
Bug 修复 systematic-debugging 遇到 bug 不知道根因
代码审查 requesting-code-review 写完模块想找人 review
完成确认 verification-before-completion 准备 commit 之前
收尾发布 finishing-a-development-branch 功能开发完成，准备合并

Superpowers 的价值不是让 AI 写得更快，是让 AI 写得更对。 没有它，你也能用 Claude Code 写代码。有了它，AI 写代码的过程更可控、结果更可靠。就像你不需要瑞士军刀也能开瓶盖，但有了开瓶器会省力很多。

不确定从哪里开始？先调 /superpowers:brainstorm 试试。把你的下一个需求丢进去，看看它会帮你理清什么。

热门推荐
012026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？022026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？03【AI】2026 年具身智能模型和世界模型总结042026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf05GitHub 镜像站点06AI科技热点日报 | 2026年6月1日07AI一周事件 · 2026-06-03 至 2026-06-0908Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析09上线仅72小时被强制下架：Claude Fable 5 的短命102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？