装了 Superpowers 之后，Claude Code 终于像个正经工程师了

袁振

307人浏览 · 2026-05-19 11:27:15

袁振 · 2026-05-19 11:27:15 发布

title: “装了 Superpowers 之后，Claude Code 终于像个正经工程师了”
tags:

Claude Code
Superpowers
AI编程
效率工具
TDD
categories:
AI工具
description: “Claude Code 安装 Superpowers 插件后的真实使用体验，从安装配置到 brainstorm → write-plan → execute-plan 全流程实录，附踩坑经验和适用场景分析。”

导读：用了三个月 Claude Code，最开始是直接让它写代码——快是真快，但经常写完发现需求理解偏了、没写测试、边界情况没处理。后来装了 Superpowers 插件，Claude Code 变了个人：先问清楚需求、再写计划、然后 TDD 式开发、最后自动 Code Review。本文先介绍 Superpowers 是什么、解决了什么问题，再记录完整的使用过程和踩坑经验。

先搞清楚 Superpowers 是什么

它要解决什么问题

用 Claude Code 写代码，你一定遇到过这些情况：

说一句"加个登录功能"，它立刻开始撸代码，30 秒后告诉你"搞定了"——密码明文存储、没做输入校验、没写测试
复杂功能做到一半，AI 忘了最初的架构约定，代码风格开始混乱
团队里每个人"调教 AI"的方式不一样，写出来的代码风格千奇百怪
AI 声称"完成了"，实际上没跑测试、没处理边界情况、没更新文档

这些问题不是 AI 模型能力不够，而是缺乏工程纪律。原生 Claude Code 是"代码生成器"——你让它干啥它就干啥，不会多想。真正的开发流程应该是先想清楚、再规划、后动手、必验证。

Superpowers 的定位

Superpowers 是由 Jesse Vincent（GitHub ID: obra）开源的一个 AI 编程工作流框架，2025 年 10 月开源，2026 年初进入 Anthropic 官方插件市场后迅速爆发，目前在 GitHub 上有 180K+ Star，安装量近 60 万次。

它也支持 Cursor、Codex、OpenCode、Gemini CLI 等工具，但本文以 Claude Code 为主。

它的核心理念叫 Process over Prompt（流程大于提示词）——不是让 AI 变得更聪明，而是让 AI 必须遵守软件工程的纪律。你可以把它理解成"给 AI 配了一个资深 Tech Lead"——在关键决策点拦住它，强制走正确的流程。

核心概念：Skills（技能）

Superpowers 的核心是技能（Skills）。每个 Skill 本质上是一个 Markdown 文件，定义了特定开发场景下 AI 必须遵守的规则和流程。这些规则是强制的——AI 违反就算错误。

装上 Superpowers 后，Claude Code 会自动获得 14+ 个 Skills，覆盖完整的开发生命周期：

类别	Skill	干什么的
需求与规划	brainstorming	苏格拉底式问答，理清需求和设计
需求与规划	writing-plans	把需求拆成 2-5 分钟的小任务
执行	executing-plans	按计划逐步执行
执行	test-driven-development	强制 TDD：先写测试再写实现
执行	subagent-driven-development	每个任务用独立子 Agent 执行，避免上下文污染
调试	systematic-debugging	4 阶段调试：复现 → 定位 → 修复 → 验证
质量保障	requesting-code-review	自动发起代码审查
质量保障	verification-before-completion	完成前强制跑测试，禁止"我觉得没问题"
分支管理	using-git-worktrees	自动创建隔离分支，保护主分支

完整工作流一览

一个功能从需求到代码，Superpowers 的标准流程：

[1] brainstorming — AI 先跟你讨论，把需求问清楚，提出 2-3 种方案
     ↓
[2] writing-plans — 把确认的方案拆成 2-5 分钟的小任务，保存到 docs/plans/
     ↓
[3] using-git-worktrees — 创建隔离的 feature 分支，坏了直接丢弃
     ↓
[4] executing-plans — 逐个任务执行，每个任务遵循 TDD（红 → 绿 → 重构）
     ↓
[5] code-review — 任务间自动 Code Review，严重问题阻塞推进
     ↓
[6] verification — 跑全部测试，确认无回归
     ↓
[7] finish-branch — 提供合并 / 创建 PR / 丢弃选项

💡 这个流程不是每次都要走完。改一行 CSS 就不需要 brainstorm。Superpowers 会根据任务复杂度自动判断走哪些步骤。

安装：一条命令的事

前提条件

Claude Code 已安装（2025 年 12 月之后的版本，支持插件系统）
终端能正常访问外网（安装时需要下载 Skill 文件）

安装步骤

在 Claude Code 终端里执行：

# 方式一：Anthropic 官方市场（最简单，推荐）
/plugin install superpowers@claude-plugins-official

# 方式二：Superpowers 自己的 marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

安装完重启 Claude Code（输入 /quit 退出，再重新运行 claude），你会看到类似这样的提示：

✓ Superpowers skills loaded: 14 skills available

验证安装

# 查看所有可用命令
/help
# 应该能看到以 superpowers: 开头的命令：
# /superpowers:brainstorm - 交互式设计精炼
# /superpowers:write-plan - 创建实施计划
# /superpowers:execute-plan - 批量执行计划

更新插件

Superpowers 更新挺频繁的，建议定期更新：

/plugin update superpowers

适用版本：

Claude Code：2025 年 12 月之后的版本
Superpowers：v4.3.0+（2026 年 2 月之后）

三种使用方式

装好之后，你有三种方式来触发 Superpowers 的 Skills：

方式	怎么用	我的建议
自动触发	直接用自然语言描述需求，AI 自动匹配 Skill	大多数情况用这个就行
斜杠命令	`/superpowers:brainstorm`、`/superpowers:write-plan` 等	需要明确走某个步骤时用
技能名触发	对话中提到"用 TDD 方式"、“系统化调试”	特定方法论场景用

我的习惯是：新功能用 /superpowers:brainstorm 显式触发，修 bug 和小改动让 AI 自动判断。

完整流程实录：从需求到代码

下面我用一个真实的项目来演示完整流程。任务：给一个已有的 Spring Boot 项目加一个"用户反馈"功能。

第 1 步：Brainstorm — 先把需求聊清楚

/superpowers:brainstorm 我想给项目加一个用户反馈功能，
用户可以提交文字反馈，管理员可以在后台查看和回复

Claude 的反应跟没装 Superpowers 时完全不同——它没有直接写代码，而是开始问我问题：

Claude: 我先问几个问题来理清需求：

1. 反馈需要分类吗？比如 Bug 反馈、功能建议、其他？
   → 需要分三类：Bug、建议、其他

2. 用户需要登录才能提交吗？还是匿名也可以？
   → 需要登录，跟现有的用户体系打通

3. 管理员回复后，用户需要收到通知吗？
   → 暂时不需要，后续版本再加

4. 反馈需要支持图片附件吗？
   → 第一版先支持纯文字

5. 管理员后台是新建页面还是加到现有管理后台？
   → 加到现有的管理后台

这一轮问答大概花了 3 分钟。但如果没有这 3 分钟，我可能直接让 AI 开干了，写到一半发现"需要跟用户体系打通"、“需要分类”，又得推倒重来。

问答结束后，Claude 给出了两种架构方案：

方案	描述	优点	缺点
A：单表设计	一张 feedback 表搞定	简单，开发快	回复和反馈混在一起，扩展性差
B：主从表设计	feedback + feedback_reply 两张表	结构清晰，方便后续加功能	多一张表，查询略复杂

Claude 推荐方案 B，我也觉得 B 更合理（后续要加通知、加附件都方便）。确认后，设计文档自动保存到了 docs/plans/ 目录。

💡 不要跳过 brainstorm 环节。即使你觉得需求很清楚，让 AI 问完之后，经常会发现自己漏想了什么。我踩过最大的坑就是跳过这步，写了 200 行代码才发现需求理解偏了。

第 2 步：Write Plan — 把任务拆细

/superpowers:write-plan

Claude 基于刚才确认的方案，自动生成了一份详细的实现计划：

📋 开发计划：用户反馈功能

步骤 1：数据库迁移
- 文件：src/main/resources/db/migration/V003__create_feedback_tables.sql
- 内容：创建 feedback 和 feedback_reply 两张表
- 验收：mvn flyway:migrate 成功

步骤 2：实体类和 Repository
- 文件：entity/Feedback.java, entity/FeedbackReply.java
- 文件：repository/FeedbackRepository.java, repository/FeedbackReplyRepository.java
- 验收：mvn compile 通过

步骤 3：用户提交反馈 API
- 文件：controller/FeedbackController.java, service/FeedbackService.java
- 端点：POST /api/feedback
- 验收：测试用例通过，返回 201

步骤 4：管理员查询列表 API
- 端点：GET /api/admin/feedbacks（支持分页和分类筛选）
- 验收：测试用例通过，返回正确分页数据

步骤 5：管理员回复 API
- 端点：POST /api/admin/feedbacks/{id}/reply
- 验收：测试用例通过，回复正确关联到反馈

步骤 6：单元测试
- 文件：test/FeedbackServiceTest.java
- 覆盖：正常提交、空内容校验、未登录校验、分页边界
- 验收：mvn test 全部通过

每个步骤都是 2-5 分钟能完成的小任务，包含精确的文件路径、验收标准。

⚠️ 计划必须你确认后 AI 才会动手写代码。这是 Superpowers 最重要的"护栏"——你可以修改、调整顺序、删减步骤，确认了再往下走。

第 3 步：Execute Plan — TDD 式执行

/superpowers:execute-plan

这一步 Superpowers 会做几件事：

自动创建 Git Worktree：在一个隔离的分支上开发，主分支不受影响
逐个任务执行：每个任务遵循 TDD 流程（先写测试 → 再写实现 → 重构）
任务间 Code Review：每完成一个任务，自动发起审查
关键问题阻塞：遇到严重问题会停下来等你确认

TDD 的执行过程大概长这样：

步骤 3：用户提交反馈 API
  [RED]   写测试：testSubmitFeedback_Success → 测试失败 ✗（实现还没写）
  [GREEN] 写实现：FeedbackController.submit + FeedbackService.create → 测试通过 ✓
  [REFACTOR] 检查代码质量，提取校验逻辑到独立方法 → 测试仍然通过 ✓
  [REVIEW] 自动 Code Review → 无问题，继续下一步

我特别喜欢 TDD 这一步。以前让 AI 写代码，测试是事后补的（很多时候干脆不写）。现在测试先写，AI 必须看到测试失败才写实现——这保证了测试真的在验证业务逻辑，而不是"凑覆盖率"。

第 4 步：验证和收尾

所有任务执行完后，Superpowers 会：

自动跑一遍全部测试：确认没有回归
发起最终 Code Review：检查安全、性能、代码风格
提供合并选项：合并到主分支 / 创建 PR / 丢弃

如果测试没通过，它不会说"搞定了"，而是老老实实告诉你哪里有问题，怎么修。

跟原版 Claude Code 的对比

用一个表格说清楚装前装后的区别：

环节	原版 Claude Code	+ Superpowers
收到需求	直接开始写代码	先问清楚需求再动手
实现过程	写到哪算哪	按 TDD 红-绿-重构走
测试	事后补（或者不写）	先写测试再写实现
代码质量	靠你事后 Review	自动 Code Review
异常处理	经常遗漏	brainstorm 阶段就列出了边界情况
Git 管理	直接改主分支	自动创建隔离分支
复杂任务	容易跑偏、遗漏	拆成小任务逐步执行
Token 消耗	少（但可能要多次返工）	多 10-20%（但一次做对）

什么时候该用，什么时候别用

适合用的场景

新功能开发（50 行代码以上的）
复杂 Bug 修复（需要定位根因的）
重构老代码
团队项目（需要统一的开发规范）
你对需求还不太清晰的时候

不适合的场景

改一行 CSS、修一个 typo——直接说就行，别走完整流程
快速原型验证——如果你 10 分钟就想看到 Demo，Superpowers 的规范流程会让你觉得啰嗦
简单的脚本工具——写个 Python 小脚本没必要走 TDD

💡 我的经验：日常开发中大概 60% 的任务会触发 Superpowers 的某个 Skill，40% 的简单操作直接跟 Claude 说就行。不用强求每个任务都走完整流程。

我踩过的坑

1. 把 Superpowers 当成万能药

装了 Superpowers 不等于代码就不会出问题了。它能帮你规范流程，但如果需求本身就有问题（比如你自己都没想清楚要做什么），brainstorm 问出来的答案也不会靠谱。想清楚需求永远是第一步，Superpowers 只是帮你把这个过程结构化。

2. 过度依赖自动触发

有时候我只想快速验证一个想法，但 Superpowers 自动触发了 brainstorming，开始问一堆问题。这种时候直接说"不用 brainstorm，直接帮我看看这段代码"就行，它会跳过。

3. TDD 在前端组件上有时候太重了

写一个按钮组件的 TDD 测试，有时候比写组件本身还费劲。我的做法是：核心业务逻辑（Service 层、数据层）严格 TDD，UI 组件用视觉验证 + 关键交互测试，不强制每个按钮都走 TDD。

4. 长会话的 Token 消耗

Superpowers 的 brainstorm + plan + execute 全走下来，一个中等功能的 Token 消耗大概比原版多 20-30%。短期看是多了，但考虑到减少了返工次数，长期算下来其实是省的。

5. 没及时更新插件

Superpowers 更新挺频繁的，新版本会修复 Skill 的逻辑问题。有一次我用的旧版本，brainstorm 技能在处理中文需求时偶尔会"跳步"——更新到最新版就好了。

# 更新命令
/plugin update superpowers

常用命令速查

命令	作用
`/superpowers:brainstorm`	苏格拉底式问答，理清需求
`/superpowers:write-plan`	生成详细的实现计划
`/superpowers:execute-plan`	按计划 TDD 式执行
`/plugin install superpowers@claude-plugins-official`	安装插件
`/plugin update superpowers`	更新插件
`/help`	查看所有可用命令
`/reload-plugins`	重新加载插件