一、日常开发的痛点
大家好，我是卡卡。
相信很多人现在用 AI 写代码已经很日常了。Cursor、Claude Code、Copilot，工具换了又换，模型也越来越强------Claude4.6、GPT-5.4，写代码的能力确实没得说。随便扔个需求过去，它能给你吐出一整段甚至整个项目的代码，看起来挺像厉害的哈。
可能这里面也有我们使用的模型的原因，最新的模型确实聪明，能理解复杂的上下文，也能写出质量不错的代码。甚至在某些场景下，比我们自己写得还要规范、还要快。
但是不可否认的是，大多数人用 AI 编程的方式，其实跟几年前没啥区别------就是"提需求，等结果"。
比如我们说一句"帮我加个登录功能"，AI 给我们一段代码。我们看看觉得还行，复制粘贴进去。跑一下，报错了。再让 AI 改。改完又报错，或者功能跟我们要的不一样。来回折腾好几轮，最后发现 AI 根本没理解我们真正想要什么。
甚至更惨的是，AI 写完的代码看似能跑，但没写测试、没考虑边界情况、没留文档。等我们过段时间再回头看，根本不知道当时写了啥、为啥这么写。后面接手的人更是一头雾水。
其实问题不在 AI 不够强，而是我们跟 AI的合作方式从一开始就有问题。我们把它当成一个干活的人，扔个需求就等结果。但软件开发不是这么简单的事------需求要理清楚、方案要设计、测试要先写、写完还要验证。这些环节我们以前靠自己自觉去做，现在指望 AI，但 AI并不会主动帮我们走完这些流程。
于是就变成了：AI 写代码很快，但返工更频繁。我们看似效率提升了，实际产出质量并没有真正提高。
二、Skills 和 MCP 能带来什么
那有没有办法让 AI 不只是"写代码"，而是按照一套靠谱的流程来帮我们做事？
这就要提到目前很火的Skills 和 MCP 了。
简单来说，Skills 就是一套预设好的"工作流程模板"，MCP 则是让 AI 能连上更多外部工具和数据源。这两样东西配合起来，AI 就不只是"写代码的机器"，而是能按照我们设定的流程一步步做事------先理解需求、再写计划、再实现、再验证。
我们前面提到的那些问题------需求理解偏差、没写测试、边界情况没考虑、文档缺失、返工成本高------这些其实都是"流程缺失"导致的。有了 Skills，这些环节就不是忘了的问题了，而是 AI 会主动提醒我们、甚至强制走完这些步骤。
比如有的 Skill 会在我们说"写个功能"的时候，先停下来问清楚需求细节；有的 Skill 会强制我们先写测试再写实现；有的 Skill 会在我们声称完成了之后，强制跑一遍检查，确保真的完成了。
所以 Skills 和 MCP 的价值，本质上不是让 AI 变聪明，而是让 AI 变靠谱。聪明是模型的事，靠谱是流程的事。模型再聪明，流程不对，结果也是一团糟。流程对了，模型哪怕没那么强，产出也更稳定、更可控。
三、Superpowers 技能介绍
既然 Skills 能帮我们把开发流程变得更靠谱，那具体要装哪个？有没有一套现成的框架，把常用的 Skill 都整合好，装完就能用？
那这里我就要提到 Superpowers 了。
Superpowers 是目前 Claude Code 社区里最火的 Skills 框架之一，专门用来强化 AI 的开发流程。它内置了好几个Skill，覆盖了从需求理解到代码验证的整个开发周期。我们前面说的那些问题------需求没理清楚、测试没写、写完不验证------Superpowers 都有对应的 Skill 来解决。
相信很多同学在写代码提效方面都听过或者安装过 Superpowers。但具体要怎么用，可能还是不太清楚。
但是很多同学装完之后，每天写代码还是原来的对话模式------"帮我写个功能"、"帮我改下这段代码"。Skills 放在那儿，什么时候该用哪个、怎么触发、触发后是什么样子，一头雾水。甚至很多人以为这些 Skill是自动生效的，装完就不用管了，结果发现写代码的方式一点都没变。
今天这篇文章，我们就来聊聊 Superpowers 的每个 Skill：什么时候用、怎么触发、触发后是什么样子、能解决什么问题。
四、Superpowers 详细介绍
那 Superpowers 具体是怎么工作的？我们先来建立一个整体认知。
其实 Superpowers 的核心理念很简单，就是四个步骤：设计 → 计划 → 测试 → 质量。
简单来说就是代码之前，我们先想清楚要做什么（设计）；想清楚了之后，我们把任务拆成一步步的计划（计划）；动手写代码的时候，先写测试再写实现（测试）；最后说"完成"之前，必须跑验证确认没问题（质量）。
这套流程不是可选的，而是强制执行的。AI 每走完一个阶段都会停下来，等我们确认了才继续下一步，不会自己偷偷跳过去。这样我们始终能把控关键节点，而不是让 AI 一路跑到底再回头看。
我们来对比一下，没有 Superpowers 和有了 Superpowers 之后，我们写代码的方式有什么区别：
| 维度 | 没有 Superpowers | 有 Superpowers |
|---|---|---|
| 需求处理 | 直接写代码，理解偏差高 | 先 brainstorming 问清楚需求 |
| 实施方式 | 想到哪写到哪 | 按 writing-plans 写好的步骤走 |
| 测试策略 | 写完补测试，覆盖率低 | TDD 先写测试再实现 |
| Bug 处理 | 看到报错就改，改了再说 | systematic-debugging 先定位再修复 |
| 完成验证 | AI 说完成就算完成 | verification-before-completion 强制验证 |
| 代码审查 | 凭自己判断 | requesting-code-review 有审查流程 |
| 工作隔离 | 同一个分支混着改 | using-git-worktrees 隔离环境 |
| 多任务处理 | 一个一个串行做 | dispatching-parallel-agents 并行处理 |
GitHub地址放在这儿，有兴趣可以自己去看看源码哈：
Superpowers 内置的 Skill 可以分成两类：自动触发和手动触发。
自动触发，是指 AI 检测到特定场景后会自己调用，不需要我们主动输入命令。比如：
- brainstorming：检测到我们要做新功能开发，自动停下来问清楚需求
- systematic-debugging：检测到 bug 或测试失败，自动进入调试流程
- test-driven-development：开始实现功能时，自动要求先写测试
- verification-before-completion：我们说"完成了"，自动跑验证检查
而手动触发，是指需要我们主动输入命令或者明确告诉 AI 用哪个 Skill。比如：
- writing-plans：输入 /superpowers:write-plan 触发
- using-git-worktrees：输入 /superpowers:using-git-worktrees 触发
- dispatching-parallel-agents：输入 /superpowers:dispatching-parallel-agents 触发
- requesting-code-review：输入 /superpowers:requesting-code-review 触发
整体的执行流程是这样的：
每个阶段其实都是一个关卡，AI走到这儿会停下来等我们确认或决策。我们始终把控着关键节点，而不是让 AI 一路跑到终点再回头看。
五、技能详解
Superpowers 内置了 13 个 Skill，每个都有特定的用途。但对于初学者来说，我们先掌握核心流程就够了。
核心流程其实就是我们从需求开始到工作完成的完整主线，一共 6 个技能：
- brainstorming ------ 需求理解，写代码前先想清楚要做什么
- writing-plans ------ 计划编写，把任务拆成清晰的步骤
- subagent-driven-development ------ 用子代理并行执行计划（推荐方式）
- executing-plans ------ 一步步顺序执行计划（备选方式）
- verification-before-completion ------ 完成验证，说完成之前必须跑检查
- finishing-a-development-branch ------ 工作收尾，完成后决定合并还是保留
其中 subagent-driven-development 和 executing-plans 都是用来执行计划的，只是方式不同：前者用子代理并行处理，后者一步步顺序执行。我们选一个就行，大多数情况推荐用前者。
学会这 6 个，日常开发就能用 Superpowers 的方式来做事了：先理解需求，再写计划，再按计划执行，执行完验证，验证完集成。每一步都有章法，不再是"提需求 → 等代码"的原始模式。
Superpowers 还有其他技能，在特定场景下会派上用场。我们用一张表格简要介绍：
| 技能 | 用途 | 触发方式 |
|---|---|---|
| test-driven-development | 实现过程中先写测试再写代码 | 自动 |
| systematic-debugging | 遇到 bug 或测试失败时，系统化定位问题 | 自动 |
| using-git-worktrees | 需要隔离开发环境，避免互相干扰 | 手动 |
| dispatching-parallel-agents | 多个独立任务并行处理 | 手动 |
| subagent-driven-development | 在当前会话中执行有独立任务的计划 | 手动 |
| requesting-code-review | 完成后请求代码审查 | 手动 |
| receiving-code-review | 收到代码审查反馈时处理 | 手动 |
| writing-skills | 创建或编辑新技能时使用 | 手动 |
这些技能我们先了解用途，遇到对应场景就知道该怎么用了。
下面我们就把核心流程的 6 个 Skill 拆开详细讲讲：什么时候用、怎么触发、触发后是什么样子、能解决什么问题。
六、核心技能详解
6.1 brainstorming ------ 先搞清楚要做什么
我们每次想做新功能、新模块、新组件的时候，先别急着让 AI 写代码。这时候 brainstorming 会自动触发，帮我们把需求理清楚。
比如我在 Claude Code 终端里说一句"我想设计一个广告回传功能"，AI 不会直接写代码，而是先触发 brainstorming 技能，然后一步步问清楚需求。
这个技能是自动触发的。当 AI 检测到我们要做新功能开发时，会自己进入 brainstorming 流程。触发后会看到这样的提示：
Skill(superpowers:brainstorming) Successfully loaded skill
这时候AI 会先搜索一下项目里相关的逻辑，了解一下上下文，然后开始提问。
提问的方式是一步步问，不是一次性甩一堆问题过来。比如我要做广告回传功能，AI 可能会这样问：
就这样一步步问，直到把需求细节都搞清楚。问完之后，AI 会说：
我已经收集了足够的信息，现在让我提出设计方案。
然后它会给我们一个设计方案，包含架构思路、关键模块、数据流程等。
最后 AI 会问：
这个设计看起来是否合适？如果没问题我将写入设计文档。
我们确认后，AI 就会把设计整理成文档保存下来，整个 brainstorming 流程就完成了。
这样我们使用这个技能就能解决这些问题：
6.2 writing-plans ------ 把任务拆成清晰的步骤
brainstorming 完成后，需求理清楚了，接下来就要写实施计划。这时候我们用 writing-plans，把任务拆成一个个小步骤，每一步都写得清清楚楚。
这个技能需要我们手动触发。我们可以直接说"帮我写个实施计划"，或者输入命令：
bash
/superpowers:writing-plans。触发后，AI 会先在项目目录下创建两个文件夹：
- docs/superpowers/specs/ ← 存放设计文档（brainstorming 产出的设计方案）
- docs/superpowers/plans/ ← 存放执行计划（writing-plans 产出的实施步骤）
这两个文件夹是 Superpowers 的标准目录结构：
- specs 文件夹：记录我们之前 brainstorming 阶段确认的设计方案，方便以后回顾"当初为什么这么设计"
- plans 文件夹：记录具体的实施步骤，每一步该做什么、怎么验证，执行的时候照着做就行
然后 AI 会根据设计方案生成一个详细的计划文档，把整个任务拆成多个小任务，每个任务又拆成多个小步骤。
计划写好后，AI 会保存到 docs/superpowers/plans/ 目录，然后给我们推荐执行方式：
计划已保存到 docs/superpowers/plans/YYYY-MM-DD-xxx.md
推荐执行方式：
- 使用 superpowers:subagent-driven-development（在当前会话中执行，推荐）
- 使用 superpowers:executing-plans（在独立会话中执行）
两种方式的区别：
- subagent-driven-development：在当前对话里继续执行，适合小项目或想实时监控的情况
- executing-plans：在独立会话里执行，适合大项目或需要隔离环境的情况
这里可能有些同学会觉得，自己设计功能心里有数就行，干嘛还要写文档。
其实这一步很有必要。文档不是给我们当下看的，是给以后的自己、还有接手项目的人看的：
6.3 执行计划 ------ 选择适合的执行方式
writing-plans 完成后，计划写好了，接下来就是执行。AI 会给我们两个执行方式让我们选。
这个触发方式是自动衔接的。当我们完成 writing-plans 后，AI 会直接问我们：
推荐执行方式：
- 使用 superpowers:subagent-driven-development（在当前会话中执行，推荐）
- 使用 superpowers:executing-plans（在独立会话中执行）
这两种执行方式的区别如下：
大多数情况我们选第一种就行，除非有特殊需求（比如想隔离环境、想手动控制每一步）。
当我们选择好计划执行方案后AI就会调用superpowers:subagent-driven-development来实现计划。
然后它会创建多个子代理，每个子代理负责执行一部分任务。子代理可以并行工作，不用等上一个做完才做下一个，效率更高。
这样的话以前我们没有执行计划的时候，AI 一口气输出一堆代码，改了好几个文件，我们来不及看就过去了。等发现问题的时候，不知道哪一步错了，只能从头排查，返工要改一堆。
有了执行计划之后，AI 按计划一步步来，做完一步汇报一次。我们每一步都能检查，发现问题立刻修正，不用等到最后才发现。
6.4 verification-before-completion ------ 说完成不代表真完成
这里我们先来解释一下为什么需要这个技能。
很多时候，AI 说"功能做好了"、"bug 修复了"、"测试通过了"，我们就信了，直接提交代码。结果上线才发现测试没跑、lint 有报错、边界情况没考虑。我们习惯了说一句"应该没问题吧"就提交，实际上问题一大堆。
这个技能就是为了阻止这种情况。当 AI 要声称完成的时候，它会强制介入，必须跑验证、拿出证据，才能说完成。不是我们请求验证时触发，而是 AI 想声称完成时才会自动触发。
而且这个技能是自动触发的，AI 没法绕过去。为什么强制执行？因为太多时候 AI 说完成了，但实际上测试没跑、lint 有报错、构建失败。这个技能就是为了阻止这种自欺欺人的情况------你说完成，那就拿出证据来证明真的完成了。
不只是验证语法，而是全面验证：
| 声称的内容 | 需要验证什么 | 前端验证命令 | 后端验证命令 |
|---|---|---|---|
| 测试通过 | 跑完整测试，确认 0 failures | npm test | pytest / go test ./... / cargo test |
| Lint 通过 | 跑代码检查，确认 0 errors | npm lint | flake8 / golangci-lint / cargo clippy |
| 构建成功 | 跑构建/编译，确认成功 | npm build | cargo build / go build / mvn compile |
| Bug 修复了 | 跑原来失败的测试 | 同上 | 同上 |
| 需求满足 | 逐项对照需求清单检查 | 手动验证 | 手动验证 / 接口测试 |
核心原则：证据优先于声明
不能说"测试应该通过" → 必须跑测试看到 0 failures
不能说"lint 应该没问题" → 必须跑 lint 看到 0 errors
不能说"bug 应该修复了" → 必须跑原来失败的测试确认通过
触发方式我使用以来认为是有两种的：
首先是自动触发：AI 说"完成"、"修复"、"通过"这类词时，技能会介入阻止它直接声称完成，强制先跑验证。
或者是手动触发：
bash
/superpowers:verification-before-completion简单说，这个技能就是让证据比声明靠谱。我们来看一下对比：
6.5 finishing-a-development-branch ------ 工作做完了怎么收尾
当我们功能开发完了，验证通过了，接下来就要决定怎么把代码合并到主分支。这时候 finishing-a-development-branch 会自动触发，给我们几个选项让我们来选。
AI 会给我们 4 个选项，其中一个是"保留分支，我自己处理"------选这个就相当于跳过自动收尾，我们自己决定后续怎么操作。
有时候可以自动触发：subagent-driven-development 或 executing-plans 完成后，会自动调用这个技能。
也可以手动触发：
bash
/superpowers:finishing-a-development-branch执行后AI 会先确认测试确实通过，然后给我们4 个选项：
这样的话，在以前我们改完代码，不知道怎么合并，要么直接推送，要么手动操作，分支乱七八糟。有了这个技能之后，它会先确认测试通过，然后给我们清晰的选项。想合并就合并，想创建 PR 就创建PR，不想合并就选保留分支，不用着急在这一步做决定。整个过程有流程、有清理，不用我们自己操心怎么收尾。
七、其他技能简介
核心流程的 6 个技能讲完了，Superpowers 还有其他技能，在特定场景下会派上用场。我们用一张表格简要介绍：
| 技能 | 用途 | 触发方式 | 什么时候用 |
|---|---|---|---|
| test-driven-development | 实现过程中先写测试再写代码 | 自动 | 开始实现功能或修复 bug 时 |
| systematic-debugging | 遇到 bug 或测试失败时，系统化定位问题 | 自动 | 报错了别瞎改代码，先用这个 |
| using-git-worktrees | 创建隔离的开发环境 | 手动 | 同时开发多个功能，不想互相干扰 |
| dispatching-parallel-agents | 多个独立任务并行处理 | 手动 | 有 2+ 个任务可以同时做 |
| requesting-code-review | 完成后请求代码审查 | 手动 | 想让 AI 或别人审查代码 |
| receiving-code-review | 收到代码审查反馈时处理 | 手动 | 收到反馈别直接改，先理解问题 |
| writing-skills | 创建或编辑新技能 | 手动 | 自己想写一个新技能 |
八、写在最后
Claude Code 能用的技能其实挺多的，官方插件市场里有一大堆，社区也有人做了不少。但今天我单独写这篇文章来讲 Superpowers，是因为它跟别的技能不太一样。
别的技能大多是针对某个具体场景的，比如帮我们写 API 文档、帮我们优化数据库、帮我们跑测试覆盖率。Superpowers不一样，它是一套完整的开发流程框架。从需求理解到计划编写、从执行到验证、从验证到收尾，整个过程都覆盖了。它不是一个单独的工具，而是把我们整个开发工作流都串联起来。
这篇文章把 Superpowers 的核心技能都讲了一遍，就是想让大家知道，这套流程是怎么运转的、每个技能该怎么用。
其实 Superpowers 做的事情很简单：把"我说需求 → AI 写代码"变成"我说需求 → 先理解 → 再计划 → 再执行 → 再验证 → 再收尾"。每个技能就是一个关卡，AI 走到这儿会停下来等我们确认或决策。我们始终把控着关键节点，而不是让 AI一路跑到终点再回头看。
至于为什么我要提倡大家多学习用 Superpowers是因为跟我们之前只会简单对话的方式相比，其实有好几方面好处的：
最直观的好处就是返工少了。
以前我们说一句"帮我加个功能"，AI 直接写代码。写完我们一看，方向不对，让 AI 改。改完又有问题，再改。来回折腾好几轮，最后发现 AI 根本没理解我们想要什么。时间浪费在反复沟通和返工上。
用了 Superpowers 之后，AI 会先停下来问清楚需求，把细节都确认了才开始动手。方向一开始就定对，后面就不用来回改了。
第二个好处就是我们每一步都知道改了啥。
以前 AI 一口气输出一堆代码，改了好几个文件，我们来不及看就过去了。等出问题的时候，不知道哪一步错了，只能从头排查。
但是用了 Superpowers 之后，先写计划，每一步要做什么、改哪个文件、怎么验证，都写得清清楚楚。执行的时候也是一步步来，做完一步汇报一次。出问题直接看计划就知道哪一步错了，定位快了很多。
第三个好处就是代码质量有保障。
以前我们习惯了说一句"应该没问题吧"就提交代码，结果上线才发现 bug。测试没跑、lint 有报错、边界情况没考虑，这些都等到上线才暴露。
用了 Superpowers 之后，验证是强制的。AI 说"完成"之前必须跑测试、跑检查，有证据才能说没问题。代码质量不是靠自觉，而是靠流程保障。
第四个好处则是以后维护省心。
以前改完代码，过段时间回头看，忘了当初为什么这么设计。接手的人更是一头雾水，只能重新问一遍。
用了 Superpowers 之后，specs 和 plans 文档都保存着。当初怎么设计的、为什么这么设计、每一步做了什么，打开文档一看就明白。以后维护或者换人接手，沟通成本低了很多。
简单来说，Superpowers 帮我们省的是这些时间：省返工、省沟通、省排查、省维护。一开始可能会觉得流程多、步骤慢，但少折腾几轮，总体时间反而更短。更重要的是，代码写得更靠谱，以后也更省心。
核心流程记住这三个就够日常使用了：
brainstorming → writing-plans → executing-plans
先理解需求，再写计划，再按计划执行。其他技能遇到了再用就行。
有兴趣也可以去看看源码，每个技能的 SKILL.md 里都有详细的流程说明哈