Superpowers Skills 使用指南：新手必备技巧与评测

什么是 Superpowers Skills

先聊一个核心问题：在日常开发中，我们与 AI 助手的配合，是不是总感觉少了点章法？要么是 AI 天马行空给出答案，要么是我们事无巨细地往 prompt 里塞规则。Superpowers Skills 正是为了解决这个痛点而生——它是一套智能开发工作流系统，通过一系列可组合的“技能”（Skills），让 AI 助手能更系统化、更高效地完成开发任务。说白了，就是给 AI 立规矩、定流程，而不是让它自由发挥。

核心理念

• 测试驱动开发 (TDD) - 始终先写测试，这是底线不是选项。
• 系统化方法 - 流程优先于猜测，别靠蒙。
• 复杂度降低 - 简单性是第一目标，别把事情搞复杂。
• 证据优先 - 在宣布成功之前，先拿测试结果说话。

Skills 系统特点

• 自动触发 - AI 在遇到相关任务时，会自行启用合适的 skill，不需要你每次都手动指定。
• 强制规范 - 这不是建议，是必须遵守的工作流。没有商量的余地。
• 可组合 - 多个 skills 可以配合使用，像搭积木一样。
• 持续更新 - Skills 会不断演进和迭代，不是一成不变的。

如何使用 Skills

基本规则

有一条黄金法则你必须记住：但凡你认为有 1% 的可能性某个 skill 适用，就一定要用。别犹豫，哪怕只是感觉“可能有用”，也得用。

它的工作流程可以简化为：用户发来消息 → AI 检查是否有适用的 skill → 调用 skill → 严格遵循 skill 的指导来执行。

Skill 使用流程

1. 识别任务类型 - 分析用户请求，判断需要哪个 skill。
2. 调用 Skill 工具 - 加载对应的 skill 内容。
3. 创建待办事项 - 如果 skill 里有检查清单，那就生成相应的待办列表。
4. 严格遵循 - 按照 skill 的指导一步步来，别跳步骤。

Skill 优先级

当多个 skills 都可能适用时，优先级是这样的：

1. 流程类 skills（如 brainstorming、debugging）先行——它们决定了如何接近任务。
2. 然后是实施类 skills（如 frontend-design、mcp-builder）——负责具体的执行。

举个例子：“让我们构建 X” → 先走 brainstorming，再走实施类 skills；“修复这个 bug” → 先走 debugging，再走领域特定 skills。

常见误区（Red Flags）

核心 Skills 详解

1. brainstorming（设计头脑风暴）

何时使用：在任何创造性的工作之前——创建新功能、构建组件、添加新行为或修改已有功能。

目的：通过自然对话，把模糊的想法转化成完整的设计方案和规格说明。

使用流程

1. 理解想法：先检查当前项目状态（文件、文档、最近的提交），然后一次只问一个问题来细化想法。优先用多选题提问，当然开放式问题也可以。核心是搞明白：目的是什么？约束条件有哪些？成功的标准是什么？

2. 探索方法：提出 2-3 种不同的实现方案，同时分析各自的权衡。以对话的方式呈现，给出推荐选项并说明理由。

3. 呈现设计：把设计方案拆成 200-300 字的小章节，每讲完一章就询问用户“这一步对吗？”。内容涵盖：架构、组件、数据流、错误处理、测试方案。

示例对话

用户: "我想创建一个用户登录功能"
AI: [使用 brainstorming skill] 让我先了解一下你的项目背景...
问题 1: 你希望使用什么认证方式？
A) 用户名/密码
B) 邮箱/密码
C) OAuth (Google/GitHub)
D) 多种方式支持
用户: "B) 邮箱/密码"
AI: 问题 2: 是否需要记住登录状态？
A) 是，使用 session
B) 是，使用 JWT token
C) 否，每次都需要登录
用户: "A) 使用 session"
AI: 好的，基于你的选择，我推荐以下设计：
[设计章节 1: 架构概述]...这个设计看起来对吗？

输出

最终的设计文档会保存到 docs/plans/YYYY-MM-DD--design.md。

2. writing-plans（编写计划）

何时使用：当你已经有了规格说明或需求的多步骤任务时，在接触代码之前。

目的：创建一份详尽的实施计划，假设工程师对代码库零上下文。

计划结构

每份计划必须包含以下内容：

# [功能名称] 实施计划
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
**Goal:** [一句话描述构建什么]
**Architecture:** [2-3句话关于方法]
**Tech Stack:** [关键技术/库]
---
### Task N: [组件名称]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Step 1: Write the failing test**
[完整测试代码]
**Step 2: Run test to verify it fails**
[命令和预期输出]
**Step 3: Write minimal implementation**
[最小实现代码]
**Step 4: Run test to verify it passes**
[命令和预期输出]
**Step 5: Commit**
[提交信息]

任务粒度

每个步骤应该是一个具体的动作（2-5 分钟能完成的那种）：

• ✅ "写失败的测试" - 一个步骤
• ✅ "运行它确保失败" - 一个步骤
• ✅ "实现最小代码使测试通过" - 一个步骤
• ❌ "实现登录功能" - 太宽泛了，需要拆解

示例计划片段

### Task 1: User Model
**Files:**
- Create: `app/models/user.py`
- Test: `tests/models/test_user.py`
**Step 1: Write the failing test**
```python
def test_user_creation():
user = User(email="test@example.com", password="password123")
assert user.email == "test@example.com"
assert user.check_password("password123")
```

Step 2: Run test to verify it fails
Run: `pytest tests/models/test_user.py::test_user_creation -v`
Expected: FAIL with "User not defined"

Step 3: Write minimal implementation
```python
class User:
def __init__(self, email, password):
self.email = email
self._password = password

def check_password(self, password):
return self._password == password
```

Step 4: Run test to verify it passes
Run: `pytest tests/models/test_user.py::test_user_creation -v`
Expected: PASS

Step 5: Commit
Commit message: "Add User model with email and password"
---

3. test-driven-development（测试驱动开发）

何时使用：在实现任何功能或修复 bug 时，在编写实现代码之前。

核心原则：如果你没有看到测试失败，你就不知道它是否测试了正确的东西。

铁律

没有失败的测试，就没有生产代码。 如果先写了代码？删除它。重新开始。

Red-Green-Refactor 循环

RED (写失败测试)
    ↓
验证失败正确
    ↓
GREEN (最小实现)
    ↓
验证通过
    ↓
REFACTOR (清理代码)
    ↓
保持绿色
    ↓
下一个功能

示例：实现计算器加法功能

Step 1: RED - 写失败测试

```python
def test_add_two_numbers():
calculator = Calculator()
result = calculator.add(2, 3)
assert result == 5
```

Step 2: 验证测试失败
`pytest tests/test_calculator.py::test_add_two_numbers -v`
Expected: FAIL - Calculator not defined

Step 3: GREEN - 最小实现
```python
class Calculator:
def add(self, a, b):
return 5 # 硬编码，最小实现
```

Step 4: 验证测试通过
`pytest tests/test_calculator.py::test_add_two_numbers -v`
Expected: PASS

Step 5: 添加更多测试，然后重构
```python
def test_add_negative_numbers():
calculator = Calculator()
result = calculator.add(-1, -2)
assert result == -3

# 现在实现真正的逻辑
class Calculator:
def add(self, a, b):
return a + b
```

常见错误

❌ 错误：先写实现，后写测试
✅ 正确：先写测试，看到失败，再写最小实现

4. executing-plans（执行计划）

何时使用：当你已经有了实施计划时，按任务逐个执行。

目的：系统化地执行计划，每个任务完成后进行审查。

执行流程

1. 读取计划 - 加载计划文档。
2. 逐个任务执行 - 一次只做一个任务。
3. 验证步骤 - 确保每个步骤都完成。
4. 检查点 - 在关键节点暂停，等待用户确认。
5. 更新计划 - 标记已完成的任务。

示例执行

计划: docs/plans/2025-01-27-login-feature.md
执行 Task 1: User Model
✓ Step 1: 写失败测试
✓ Step 2: 验证失败
✓ Step 3: 最小实现
✓ Step 4: 验证通过
✓ Step 5: 提交
[检查点] Task 1 完成，继续 Task 2？
执行 Task 2: Login Route
...

5. systematic-debugging（系统化调试）

何时使用：当遇到 bug 或问题时。

目的：通过 4 阶段流程找到根本原因。

4 阶段调试流程

1. 重现问题 - 确保能稳定复现。
2. 缩小范围 - 找到最小复现案例。
3. 假设和测试 - 提出假设，逐个验证。
4. 修复和验证 - 修复后确保问题不再出现。

示例：调试登录失败问题

阶段 1: 重现问题
问题: 用户无法登录。重现步骤: 访问 /login → 输入邮箱和密码 → 点击登录 → 看到 "Invalid credentials"。

阶段 2: 缩小范围
测试 1: 检查数据库连接 → 正常
测试 2: 检查用户是否存在 → 用户存在
测试 3: 检查密码验证 → 发现问题：密码哈希比较失败

阶段 3: 假设和测试
假设: 密码哈希算法不匹配
测试: 比较新旧哈希算法
结果: 确认——使用了不同的哈希算法

阶段 4: 修复和验证
修复: 统一使用 bcrypt 哈希算法
验证: 旧密码仍可登录（迁移），新密码使用新算法，测试通过。

6. requesting-code-review（请求代码审查）

何时使用：在任务之间、提交代码之前。

目的：确保代码质量，发现潜在问题。

审查清单

• 代码符合计划
• 所有测试通过
• 没有明显的 bug
• 代码风格一致
• 没有安全漏洞
• 性能可接受

审查报告格式

## Code Review: [功能名称]
### ✅ 通过项
- 所有测试通过
- 代码符合计划
- 没有语法错误
### ⚠️ 建议改进
- 函数过长，建议拆分
- 缺少错误处理
### ? 阻塞问题
- 安全漏洞：SQL 注入风险
- 必须修复后才能合并

7. using-git-worktrees（使用 Git 工作树）

何时使用：设计批准后，开始实施之前。

目的：创建隔离的工作空间，不影响主分支。

工作流程

1. 创建 worktree - 在新分支上创建独立目录。
2. 运行项目设置 - 安装依赖，构建项目。
3. 验证基线 - 运行测试确保干净的基线。
4. 报告位置 - 告知 worktree 位置。

示例

# AI 自动执行
git worktree add .worktrees/feature-login -b feature/login
cd .worktrees/feature-login
npm install
npm test
# 验证基线测试通过
# 报告
Worktree ready at .worktrees/feature-login
Tests passing (42 tests, 0 failures)
Ready to implement login feature

实际场景示例

场景 1: 创建新功能

用户请求："我想添加一个评论功能到博客系统"

Step 1: Brainstorming

AI: [使用 brainstorming skill] 让我先了解一下你的需求...
问题 1: 评论是否需要审核？
A) 是，需要管理员审核
B) 否，直接显示
C) 仅首次评论需要审核
问题 2: 评论支持什么功能？
A) 纯文本
B) Markdown 格式
C) 回复其他评论（嵌套）
...

Step 2: Writing Plans

AI: [使用 writing-plans skill] 基于设计，创建实施计划：
# 评论功能实施计划
**Goal:** 为博客系统添加评论功能，支持嵌套回复和审核
**Architecture:** - 使用数据库存储评论
- RESTful API 处理评论 CRUD
- 前端组件显示评论树
**Tech Stack:** - Backend: Node.js + Express
- Database: PostgreSQL
- Frontend: React
### Task 1: Comment Model
...

Step 3: Executing Plans

AI: [使用 executing-plans skill] 开始执行计划...
Task 1: Comment Model
Step 1: 写失败测试 ✓
Step 2: 验证失败 ✓
Step 3: 最小实现 ✓
Step 4: 验证通过 ✓
Step 5: 提交 ✓
[检查点] Task 1 完成，继续？

Step 4: Code Review

AI: [使用 requesting-code-review skill]
## Code Review: 评论功能
### ✅ 通过项
- 所有测试通过
- 代码符合计划
### ⚠️ 建议改进
- 添加输入验证
- 优化数据库查询

场景 2: 修复 Bug

用户报告："用户登录后，会话立即过期"

Step 1: Systematic Debugging

AI: [使用 systematic-debugging skill]
阶段 1: 重现问题
- 登录系统
- 检查会话状态
- 确认问题：会话在 1 秒后过期
阶段 2: 缩小范围
- 检查会话配置
- 检查服务器时间
- 发现问题：会话过期时间设置为 1 秒（应该是 3600 秒）
阶段 3: 假设和测试
假设: 配置错误
测试: 检查配置文件
结果: 确认 - session.maxAge 设置为 1
阶段 4: 修复和验证
修复: 将 maxAge 改为 3600000
验证: 登录后会话持续 1 小时

Step 2: Test-Driven Development

AI: [使用 test-driven-development skill]
Step 1: RED - 写失败测试
def test_session_expires_after_one_hour():
user = login_user()
assert session_valid(user)
# 实际上测试配置
assert session.maxAge == 3600000
Step 2: 验证失败
Step 3: GREEN - 修复配置
Step 4: 验证通过

场景 3: 重构代码

用户请求："重构这个巨大的函数，它太长了"

Step 1: Brainstorming

AI: [使用 brainstorming skill] 让我先分析这个函数...
问题: 你希望如何拆分？
A) 按功能拆分（验证、处理、响应）
B) 按数据流拆分（输入、转换、输出）
C) 提取为类方法...

Step 2: Writing Plans

AI: [使用 writing-plans skill]
# 重构大型函数实施计划
### Task 1: 提取验证逻辑
### Task 2: 提取处理逻辑
### Task 3: 提取响应逻辑
### Task 4: 重构主函数
### Task 5: 更新测试

Step 3: Test-Driven Refactoring

AI: [使用 test-driven-development skill] 重要：重构前确保有完整测试覆盖！
Step 1: 确保现有测试通过
Step 2: 提取函数（不改变行为）
Step 3: 运行测试确保仍然通过
Step 4: 继续提取下一个函数...

最佳实践

1. 始终遵循技能流程

❌ 错误："这个任务太简单，跳过 brainstorming"
✅ 正确：即使简单任务也使用相应的 skill

2. 不要跳过测试

❌ 错误："先写代码，测试后面补"
✅ 正确：先写测试，看到失败，再写代码

3. 任务粒度要小

❌ 错误："实现整个登录功能"
✅ 正确："写用户模型的失败测试" → "实现用户模型" → "写登录路由的失败测试" → …

4. 频繁提交

✅ 每个小任务完成后立即提交
✅ 提交信息清晰描述做了什么
✅ 保持提交历史干净

5. 使用检查点

✅ 在关键里程碑暂停
✅ 等待用户确认再继续
✅ 及时发现问题

6. 文档化设计

✅ 设计文档保存到 docs/plans/
✅ 计划文档保存到 docs/plans/
✅ 提交到版本控制

技能组合使用示例

完整开发流程

1. brainstorming ↓
2. using-git-worktrees ↓
3. writing-plans ↓
4. executing-plans
├─ test-driven-development (每个任务)
├─ requesting-code-review (任务之间)
└─ systematic-debugging (如遇问题)
5. finishing-a-development-branch

调试流程

1. systematic-debugging ↓
2. test-driven-development (写回归测试) ↓
3. verification-before-completion

总结

Superpowers Skills 系统不是一堆可有可无的「建议」，而是一套强制性的工作流。它通过结构化的流程，保证了四件事：质量（TDD 从源头确保正确性）、系统化（流程驱动而不是猜测）、可维护性（小任务、频繁提交、清晰文档）和可扩展性（技能之间自由组合）。

最后再强调一次：如果你认为有 1% 的可能性某个 skill 适用，你就必须用它——因为正是这一次次的「小确幸」，造就了代码质量的质变。

快速参考表

技能选择指南

技能触发条件

常用命令

在 Cursor 中，可以直接使用这些命令来触发 skills：

• /brainstorm - 启动设计头脑风暴
• /write-plan - 创建实施计划
• /execute-plan - 执行计划

常见问题 (FAQ)

Q: 如果我不确定使用哪个 skill 怎么办？

A: 使用 using-superpowers skill 来帮你识别。或者，按照那条黄金法则：觉得有 1% 的可能性，就直接用。

Q: 可以跳过某个 skill 的步骤吗？

A: 对于严格类 skills（如 TDD、debugging），不可以。对于灵活类 skills（如 patterns），可以根据上下文调整，但 skill 本身会告诉你怎么做。

Q: 如果 skill 的指导不适合我的情况怎么办？

A: 先尝试遵循 skill 的指导。如果确实不合适，skill 本身会告诉你如何处理。不要没试就跳过。

Q: 如何知道 skill 是否更新了？

A: Skills 会持续演进。即便你「记得」某个 skill，也要在使用时重新读取最新版本。

Q: 多个 skills 可以同时使用吗？

A: 可以组合使用，但要注意优先级：流程类 skills 优先于实施类 skills。