obra/superpowers 深度实战:20 万星 AI 编程技能框架——从「实习生乱写代码」到「专家级工程师工作流」的完全指南(2026)
一个只有几百行 Markdown 的小项目,凭什么在 GitHub 上狂揽 20 万颗 Star,成为 2026 年 AI Agent 基础设施领域最火爆的明星?
引言:AI 编程的「实习生困境」
2026 年,AI 编程助手已经无处不在:Claude Code、Cursor、Copilot、Trae、Windsurf……你随便打开一个,对着它说「帮我写一个 REST API」,30 秒后代码就出来了。看起来很美好对吧?
但用过的人都知道,真实的体验远没有这么丝滑。
你让它写一个功能,它确实能写,但往往:
- 没问清楚需求就开工,写出来的东西跟你想要的不一样
- 不写测试,或者写了测试但不跑
- 改了 A 就破坏了 B,完全没有全局意识
- 你让它「重构这个模块」,它咔咔改了 20 个文件,然后编译都过不了
- 不同人用同一个工具,产出质量天差地别——因为提示词水平不同
问题的本质是什么?不是 AI 不够聪明,而是 AI 缺乏「工程方法论」。
想象你招了一个绝顶聪明但没有工程经验的实习生:代码能力一流,但不知道要先写测试、不知道要 git branch 隔离、不知道要按模块拆分任务、不知道写完要 code review。让他直接上项目,大概率是灾难。
obra/superpowers 解决的正是这个问题。
它不是又一个新的 AI 编程工具,而是一个可复用的「技能框架」——给 Claude Code、Cursor、Copilot 这些 AI 编程助手装上「职业技能」,让它们在写下第一行代码之前,先像资深工程师一样思考、规划和验证。
这个项目由 Jesse Vincent(Perl RT 系统的创建者、Prime Radiant 公司创始人)开发,从 2025 年底的一个几百行 Markdown 小项目,到 2026 年 6 月突破 20 万 Star,单日新增超过 1,400 颗 Star——贡献了近期所有 AI Agent 项目中几乎最凶猛的单日增量。
本文将从架构设计、核心技能、实战演练到生产级集成,一次性讲透 superpowers 的完整世界观。
一、Superpowers 是什么:重新定义「AI 编程助手」的工作方式
1.1 核心理念:Skills = Agent 的职业技能
Superpowers 的核心理念极其简洁:为 AI 编程 Agent 预定义一套可组合的「技能文件」(Skills),让 Agent 的行为从「想到哪写到哪」变成「遵循结构化的专业工程流程」。
每个 Skill 本质上是一个 Markdown 文件,包含:
- 触发条件:什么时候激活这个技能
- 工作流程:具体的步骤和检查点
- 输出规范:期望的产出格式和质量标准
听起来简单,但这个设计的精妙之处在于:它不是提示词工程,而是方法论工程。
提示词工程解决的是「怎么跟 AI 说」的问题,而 Superpowers 解决的是「AI 应该怎么工作」的问题。它把软件工程的 best practices——TDD、git worktree、code review、YAGNI、DRY——变成了 Agent 可以自动执行的工作流。
1.2 架构哲学:组合优于继承,流程优于直觉
Superpowers 的架构遵循几个关键设计原则:
原则一:技能可组合(Composable Skills)
每个 Skill 是独立的、可插拔的模块。你不需要全盘接受,可以按需启用:
brainstorming → using-git-worktrees → writing-plans → subagent-driven-development
这是一条典型的技能链:先头脑风暴梳理需求 → 创建隔离分支 → 写实施计划 → 分派子 Agent 执行。
原则二:自动触发(Automatic Activation)
Skills 不是需要手动调用的工具,而是 Agent 在执行任务时自动匹配和激活的工作流。当 Agent 检测到你开始一个新功能的开发,它会自动走完整条技能链,不需要你每次都提醒它。
原则三:强制执行(Mandatory Workflows)
这些是工作流,不是建议。Superpowers 强制 Agent 遵循特定流程,比如必须先写测试才能写实现代码,必须有 code review 环节,必须在 worktree 隔离环境中工作。
原则四:跨平台兼容(Cross-Platform)
Superpowers 支持 Claude Code、Codex CLI、Codex App、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI 等主流 AI 编程 Agent,通过各自的插件市场安装,本质上是同一套方法论在不同平台上的映射。
1.3 与其他方案的对比
| 维度 | 直接使用 Claude Code | Cursor Rules | Superpowers |
|---|---|---|---|
| 设计阶段 | 无引导,直接写代码 | 可自定义规则 | 自动触发 brainstorming |
| 测试要求 | 取决于提示词 | 可配置 | 强制 TDD(RED-GREEN-REFACTOR) |
| 工程隔离 | 用户自行管理 | 项目级配置 | 自动 git worktree |
| 任务拆分 | 用户手动引导 | 无内置支持 | 自动 writing-plans |
| 质量检查 | 依赖用户检查 | 依赖用户检查 | 自动 requesting-code-review |
| 可复用性 | 每次重复提示词 | 项目绑定 | 跨项目、跨平台复用 |
一句话总结:Superpowers 把「好工程师怎么做」变成了「AI Agent 自动怎么做」。
二、核心技能体系深度拆解
Superpowers 的技能分为四个大类:设计类、实现类、调试类 和 协作类。我们来逐一深入拆解。
2.1 设计类技能:brainstorming —— 不写代码的「代码前工序」
这是 Superpowers 与所有其他 AI 编程方案的最大区别。
当你告诉 Agent「我想做一个用户认证系统」,Superpowers 的第一个技能 brainstorming 会被自动激活。它做的事情不是直接写代码,而是:
第一步:通过苏格拉底式提问澄清需求
Agent 会问一系列问题,而不是自己假设:
- 你用的是什么认证协议?OAuth2、JWT、还是 Session-based?
- 需要支持多因子认证吗?
- 用户数据存在哪里?MySQL、PostgreSQL、还是 Redis?
- 需要跟哪些第三方服务集成?微信登录、Google 登录?
- 并发量预期多少?有没有性能要求?
第二步:探索替代方案
Agent 不会只给你一个方案,而是主动比较多个方案的优劣:
- 方案 A:JWT + Redis 黑名单(适合高并发,但 token 撤销需要额外处理)
- 方案 B:Session + 数据库存储(适合中小规模,状态管理简单)
- 方案 C:OAuth2 + 第三方代理(免密码登录,但依赖第三方可用性)
第三步:分段展示设计
Agent 不会一次性丢给你一个巨大的设计文档,而是分区块展示,每个区块足够短,你可以真正读完并消化:
- 先展示数据模型设计
- 你确认后,展示 API 接口设计
- 确认后,展示安全策略
这种「分块确认」的设计非常重要——它解决了 AI Agent 长文本输出的「注意力衰减」问题。
第四步:保存设计文档
最终确认的设计会被保存为项目中的设计文档,作为后续所有实施步骤的基准(spec baseline)。
2.2 工程隔离:using-git-worktrees —— 安全的并行开发
设计确认后,using-git-worktrees 技能自动激活,它的职责是:
# 创建隔离的 git worktree
git worktree add feature/user-auth main
# 切换到隔离环境
cd feature/user-auth
# 运行项目设置,确保环境可用
npm install / pip install / cargo build
# 验证现有测试全部通过(建立基线)
npm test # 所有测试必须 GREEN
为什么这很重要?
在传统 AI 编程中,Agent 直接在你的主分支上操作,写了一半的代码可能污染你的工作区。而 Superpowers 强制每个功能开发都在独立的 git worktree 中进行,这意味着:
- 主分支永远干净
- 可以同时开发多个功能(每个 Agent 一个 worktree)
- 出了问题直接删除 worktree,零风险
2.3 任务规划:writing-plans —— 把大需求拆成小任务
writing-plans 是 Superpowers 的精髓之一。它的目标是将设计文档转化为极其精确的实施计划,精确到什么程度?
每个任务控制在 2-5 分钟的执行粒度。
一个典型的计划条目:
## Task 3: Create User model with email uniqueness constraint
- Files to modify: `src/models/user.py`, `src/models/__init__.py`
- Depends on: Task 2 (database connection setup)
- Steps:
1. Create `User` model with fields: id, email, password_hash, created_at, updated_at
2. Add unique constraint on email field
3. Write test: `test_create_user_with_duplicate_email_fails()`
4. Verify test fails (RED)
5. Implement model
6. Verify test passes (GREEN)
7. Commit with message: "feat: add User model with email uniqueness"
注意每个任务都包含:
- 精确的文件路径(不是模糊的「创建用户模型」)
- 依赖关系(Task 3 依赖 Task 2)
- 完整的验证步骤(TDD 流程)
- 清晰的提交信息
为什么每个任务只要 2-5 分钟?
Jesse Vincent 的洞察是:AI Agent 的注意力窗口有限。如果你让它「实现用户认证系统」,它大概率会在后半段开始「自由发挥」,偏离计划。但如果你让它「在 src/models/user.py 中创建 User 模型,添加 email 唯一约束」,它几乎不会出错。
小任务 = 高质量。这是 Superpowers 的核心信条。
2.4 实现类技能:subagent-driven-development —— 子 Agent 并行开发
计划写好后,subagent-driven-development 技能接管执行。它的执行模式极其优雅:
两阶段审查机制(Two-Stage Review):
每个子 Agent 完成任务后,会经过两个审查阶段:
子Agent执行Task 3
→ 阶段1: 规格符合性审查(Spec Compliance Review)
- 实现是否完全匹配计划中的描述?
- 所有文件是否都已修改/创建?
- 测试是否覆盖了计划中的场景?
→ 阶段2: 代码质量审查(Code Quality Review)
- 代码是否遵循 DRY 原则?
- 命名是否清晰一致?
- 有没有潜在的性能问题?
- 错误处理是否完善?
如果阶段 1 发现偏差(比如计划说要加 email 唯一约束但没加),子 Agent 会被要求重做。只有两个阶段都通过,才会进入下一个任务。
这种设计确保了 AI Agent 不会在执行过程中「跑偏」——每一步都被严格验证。
2.5 测试类技能:test-driven-development —— 强制 TDD
test-driven-development 技能是最严格的。它强制执行经典的 RED-GREEN-REFACTOR 循环:
1. RED:先写测试,运行测试,确认测试失败
2. GREEN:写最小化的实现代码,运行测试,确认测试通过
3. REFACTOR:在测试保护下重构代码
4. COMMIT:提交(测试 + 实现一起提交)
最狠的一条规则:如果发现子 Agent 在测试之前写了实现代码,这个代码会被直接删除。
这不是玩笑。Superpowers 的 SKILL 文件中明确写了:
"If implementation code was written before its test, the implementation code should be deleted."
这意味着如果你让 Agent 去实现一个功能,而它跳过了测试直接写了实现代码,Superpowers 会命令 Agent 删掉那段代码,重新先写测试。
这条规则初看起来很严格,但它解决了一个核心问题:AI Agent 天然倾向于「先写代码后补测试」,这种模式下的测试质量往往很差——测试只覆盖了「已经写好的代码能跑通」,而不是「代码应该满足什么行为规范」。先写测试才能真正定义「正确行为」是什么。
2.6 调试类技能:systematic-debugging —— 系统化排障
当出现 Bug 时,systematic-debugging 技能会自动激活,它推行四阶段根因分析:
阶段 1: 复现问题(Reproduce)
- 在隔离环境中精确复现 Bug
- 记录复现步骤和条件
阶段 2: 缩小范围(Isolate)
- 二分法定位问题范围
- 使用 root-cause-tracing 技术追踪调用链
阶段 3: 修复(Fix)
- 在理解根因后再修复,而非「试改法」
- 每个修复都有对应的回归测试
阶段 4: 验证(Verify)
- 确认 Bug 已修复
- 确认没有引入新 Bug
- 运行完整测试套件
配套的还有 verification-before-completion 技能:在声明任务完成之前,必须运行相关测试并确认全部通过。 这杜绝了 Agent 经典的「我改好了」但实际上没测试的问题。
三、实战演练:用 Superpowers 开发一个真实项目
理论说了这么多,我们来跑一遍完整的实战流程。
3.1 场景:开发一个 URL 短链服务
假设我们要用 Claude Code + Superpowers 开发一个短链服务,核心功能:
- 生成短链
- 重定向到原始 URL
- 基础的访问统计
- 过期机制
第一步:安装 Superpowers
# Claude Code
/plugin install superpowers@claude-plugins-official
# 或通过 GitHub marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
安装完成后,Superpowers 的所有技能文件会被加载到 Agent 的上下文中。
第二步:启动开发
# 在项目目录中启动 Claude Code
claude
我输入:「帮我做一个 URL 短链服务,支持生成短链、重定向、访问统计和过期机制,用 Go 语言。」
第三步:brainstorming 自动触发
Agent 不会直接写代码,而是开始提问:
I'd like to understand your requirements better before we start:
1. 存储方案:你倾向于用 PostgreSQL、Redis 还是 SQLite?性能要求?
2. 短链格式:6位随机码、自定义别名、还是支持两者?
3. 过期机制:基于时间过期(比如30天后失效),还是基于访问次数?
4. 访问统计:只需要计数,还是需要记录访问时间、IP、User-Agent?
5. API 风格:REST API?需要前端页面吗?
6. 部署环境:Docker?直接运行?预期 QPS?
我回答后,Agent 会整理设计方案,分段展示:
## 数据模型设计
### URL 表
| 字段 | 类型 | 说明 |
|------|------|------|
| id | BIGSERIAL | 主键 |
| short_code | VARCHAR(10) UNIQUE | 短链码 |
| original_url | TEXT | 原始 URL |
| created_at | TIMESTAMP | 创建时间 |
| expires_at | TIMESTAMP | 过期时间(可 NULL 表示永不过期)|
| access_count | INTEGER DEFAULT 0 | 访问计数 |
| user_id | INTEGER | 创建者(预留)|
请确认这个数据模型是否符合你的预期,我将继续展示 API 设计。
第四步:using-git-worktrees 自动触发
设计确认后:
✅ Design approved. Creating isolated worktree...
$ git worktree add feature/url-shortener main
$ cd feature/url-shortener
$ go mod init url-shortener
$ go build ./...
$ go test ./...
All tests pass. Baseline established. Starting implementation plan...
第五步:writing-plans 自动触发
Agent 自动生成精确的实施计划:
## Implementation Plan: URL Shortener Service
### Task 1: Database connection and schema setup (3 min)
- Files: `internal/db/db.go`, `migrations/001_init.sql`
- Create PostgreSQL connection pool
- Define schema migration for `urls` table
- Test: verify connection and table creation
### Task 2: Short code generation utility (2 min)
- Files: `internal/shortener/code.go`, `internal/shortener/code_test.go`
- Generate 6-character URL-safe random codes
- Test: verify uniqueness in 10000 iterations
### Task 3: URL model and repository (4 min)
- Files: `internal/model/url.go`, `internal/repository/url_repo.go`, `internal/repository/url_repo_test.go`
- CRUD operations for URL records
- Test: create, read, update access count, delete
### Task 4: POST /api/shorten endpoint (3 min)
- Files: `internal/handler/shorten.go`, `internal/handler/shorten_test.go`
- Accept original_url, optional custom_code, optional ttl
- Validate URL format, check duplicates
- Test: valid URL, invalid URL, duplicate code, expired TTL
### Task 5: GET /:code redirect endpoint (2 min)
- Files: `internal/handler/redirect.go`, `internal/handler/redirect_test.go`
- Lookup short code, increment counter, redirect
- Handle expired URLs (410 Gone), not found (404)
- Test: valid redirect, expired URL, not found
### Task 6: GET /api/stats/:code endpoint (2 min)
- Files: `internal/handler/stats.go`, `internal/handler/stats_test.go`
- Return access count and creation info
- Test: existing code, not found
### Task 7: Expiration cleanup job (3 min)
- Files: `internal/cron/cleanup.go`, `internal/cron/cleanup_test.go`
- Background goroutine to delete expired URLs
- Configurable interval
- Test: cleanup runs, skips non-expired
### Task 8: HTTP server setup and middleware (3 min)
- Files: `cmd/server/main.go`, `internal/middleware/logger.go`
- Chi router, logging middleware, CORS
- Graceful shutdown
- Test: server starts, middleware logs requests
Estimated total: 22 minutes
第六步:subagent-driven-development 自动执行
Agent 开始按计划逐个执行任务,每个任务由一个子 Agent 处理,完成后经过两阶段审查。
🔧 Executing Task 1: Database connection and schema setup
📝 Creating internal/db/db.go
📝 Creating migrations/001_init.sql
📝 Writing tests...
✅ RED phase: tests fail as expected
✅ GREEN phase: implementation passes all tests
🔍 Review Stage 1: Spec compliance ✅
🔍 Review Stage 2: Code quality ✅
📦 Committed: feat: add database connection and schema setup
🔧 Executing Task 2: Short code generation utility
... (same pattern for each task)
第七步:requesting-code-review 自动触发
所有任务完成后,Agent 自动生成代码审查报告:
## Code Review Summary
### All Tasks Completed: 8/8 ✅
### Critical Issues: 0
### Major Issues: 0
### Minor Issues: 2
- Task 3: Consider using prepared statements for all queries
- Task 8: Add rate limiting middleware for production use
### Suggestions: 3
- Consider adding a health check endpoint
- Config extraction to environment variables
- Add OpenAPI/Swagger documentation
No blockers detected. Proceeding to branch finalization...
第八步:finishing-a-development-branch 自动触发
## Branch Finalization
✅ All tests pass: 24/24
✅ No linting errors
✅ Code review passed
Options:
1. Create Pull Request
2. Merge to main
3. Keep branch for further work
4. Discard changes
What would you like to do?
从开始到结束,整个流程完全自动化,Agent 可以自主工作数小时而不偏离计划。这就是 Superpowers 的魔力所在。
四、Subagent 驱动开发的深度解析
Superpowers 的 subagent-driven-development 模式是其最具创新性的设计。我们来深入分析它的工作机制。
4.1 为什么需要 Subagent 模式?
直接让一个 Agent 执行所有任务有个致命问题:上下文漂移(Context Drift)。
当一个 Agent 连续执行 Task 1 到 Task 8,到后面的任务时,它对初始设计的记忆已经开始模糊,可能忘记 Task 2 中定义的数据结构,导致 Task 7 的代码与 Task 3 的接口不匹配。
Subagent 模式的解决方案是:每个任务由一个全新的子 Agent 执行,子 Agent 只看到当前任务和相关的上下文片段。
这保证了:
- 专注性:子 Agent 只关注当前任务,不会被其他任务的细节干扰
- 一致性:每个任务都严格遵循计划描述,不会因为「记住」了其他任务而产生偏差
- 可恢复性:如果某个子 Agent 出了问题,只需要重试该任务,不需要从头开始
4.2 两阶段审查的精妙设计
传统的代码审查是一次性的:「这段代码好不好?」但 Superpowers 的两阶段审查解决的是两个不同的问题:
阶段 1:规格符合性(Did you build what was asked?)
- 这不是主观判断,而是客观检查
- 实现是否与计划中的描述完全一致?
- 所有提到的文件、函数、接口是否都存在?
- 测试是否覆盖了计划中的所有场景?
阶段 2:代码质量(Is the implementation good?)
- 这才有主观判断的空间
- 代码风格是否一致?
- 有没有安全隐患?
- 性能是否可接受?
- 是否遵循了 DRY 和 YAGNI?
先验证「做对没」,再评价「做的好不好」。 这个顺序不能反——如果阶段 1 就没通过,阶段 2 的质量评判毫无意义。
4.3 并行执行模式:dispatching-parallel-agents
对于无依赖关系的任务,Superpowers 还支持并行子 Agent 分派:
Task 3 (URL model) ← 无依赖,可并行
Task 4 (short code generation) ← 无依赖,可并行
Task 5 (middleware) ← 无依赖,可并行
┌─ SubAgent A → Task 3 → Review ✅
├─ SubAgent B → Task 4 → Review ✅
└─ SubAgent C → Task 5 → Review ✅
Task 6 (POST endpoint) ← 依赖 Task 3 + Task 4
Task 7 (GET endpoint) ← 依赖 Task 3
在 git worktree 的隔离下,这些并行任务互不干扰,完成后合并即可。
五、测试驱动开发(TDD)的强制执行
5.1 为什么 AI Agent 尤其需要 TDD?
人类程序员写代码的 Bug 模式是已知的:边界条件、空指针、并发竞争……但 AI Agent 的 Bug 模式完全不同:
- 幻觉式 Bug:Agent 可能生成看似合理但实际不存在的 API 调用
- 不一致式 Bug:前面定义了 A 接口,后面调用时变成了 B
- 过度工程式 Bug:Agent 倾向于「多写一些代码」,导致不必要的复杂度
- 测试盲区:Agent 天然倾向写正向测试,忽略边界和异常场景
这些问题无法通过人工审查完全解决,唯一可靠的方法是:先定义期望行为(测试),再实现代码。
5.2 Superpowers 的 TDD 强制机制
Superpowers 对 TDD 的强制执行达到了近乎苛刻的程度:
Agent writes test → Test MUST fail (RED)
→ If test doesn't fail → Agent identifies why and fixes the test
Agent writes minimal implementation → Test MUST pass (GREEN)
→ If test doesn't pass → Agent debugs, doesn't skip
Agent refactors → Test MUST still pass (REFACTOR)
Agent commits → Both test and implementation together
关键细节:如果 Agent 发现测试写错了(比如写了一个永远通过的测试),它必须先修复测试本身,让测试真正能失败,再继续实现。
这种「先定义正确行为」的方式还有一个重要副作用:它迫使 Agent 在写实现之前真正理解需求。 如果一个 Agent 不能写出一个描述期望行为的测试,说明它没有真正理解要实现什么——这比事后检查有效得多。
5.3 测试反模式参考
Superpowers 的 TDD 技能还包含一份「测试反模式」参考清单,帮助 Agent 避免常见的测试陷阱:
## Testing Anti-Patterns to Avoid
❌ 不写测试直接实现
❌ 先实现后补测试
❌ 测试只覆盖 happy path
❌ Mock 了被测单元本身
❌ 测试之间有隐式依赖
❌ 测试依赖外部状态(网络、时间、随机数)
❌ 一个测试覆盖多个行为
❌ 测试名称不描述行为
✅ 先写测试,确认失败,再实现
✅ 每个测试只验证一个行为
✅ 测试名称描述期望行为
✅ 使用 Test Table 模式覆盖边界条件
✅ Mock 外部依赖,不 mock 被测单元
六、在不同 AI Agent 平台上使用 Superpowers
6.1 Claude Code(官方推荐)
Claude Code 是 Superpowers 的「原生平台」,体验最完整:
# 通过 Anthropic 官方插件市场安装
/plugin install superpowers@claude-plugins-official
# 或通过 GitHub marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
Claude Code 的优势在于其强大的子 Agent 分派能力,可以真正实现 subagent-driven-development 的并行执行模式。
6.2 Cursor
# 在 Cursor Agent chat 中安装
/add-plugin superpowers
Cursor 用户需要注意:Cursor 的 Agent 模式与 Claude Code 有差异,部分技能(如 git worktree 自动创建)可能需要手动辅助。但核心的 brainstorming → planning → TDD 流程完全可用。
6.3 GitHub Copilot CLI
# 注册 marketplace
copilot plugin marketplace add obra/superpowers-marketplace
# 安装
copilot plugin install superpowers@superpowers-marketplace
Copilot CLI 的优势在于与 GitHub 生态的深度集成,自动创建 PR、关联 Issue 等。
6.4 Codex CLI / Codex App
# 通过 OpenAI 官方插件市场安装
/plugins → 搜索 superpowers → Install
6.5 Gemini CLI
# 安装扩展
gemini extensions install https://github.com/obra/superpowers
# 更新
gemini extensions update superpowers
6.6 OpenCode
# 告诉 OpenCode 获取安装指令
Fetch and follow instructions from
https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md
平台间的差异主要在子 Agent 分派能力上。 Claude Code 和 Codex App 支持原生子 Agent,可以真正并行执行任务;其他平台通过 executing-plans 技能实现串行执行,带有人工检查点(human checkpoints),虽然速度稍慢,但质量控制同样严格。
七、进阶用法:自定义 Skills 和工作流
7.1 使用 writing-skills 创建新技能
Superpowers 不只是预定义技能的集合,它本身就是一个「技能创建框架」。writing-skills 技能教你如何创建新的技能文件:
# skills/my-custom-skill/SKILL.md
---
name: my-custom-skill
---
# Custom Skill: API Versioning Workflow
## When to activate
- Before modifying any API endpoint
- When adding new API endpoints
## Workflow
1. Check current API version in codebase
2. If modifying existing endpoint:
- Verify backward compatibility
- Add version header check
- Write test for old version behavior
- Write test for new version behavior
3. If adding new endpoint:
- Follow existing URL naming convention
- Add to OpenAPI spec
- Write integration test
4. Verify all existing API tests still pass
## Output
- API version compatibility report
- List of modified/added endpoints
7.2 技能组合的最佳实践
Superpowers 的技能可以自由组合,以下是几种常见的工作流配置:
轻量级模式(快速原型):nbrainstorming → writing-plans → test-driven-development → finishing-a-development-branch
跳过 git worktree 和 code review,适合快速验证想法。
团队协作模式:
``brainstorming → using-git-worktrees → writing-plans → subagent-driven-development → requesting-code-review → receiving-code-review → finishing-a-development-branch```
完整链路,每个环节都有验证,适合正式项目的团队协作。
调试修复模式:
``systematic-debugging → verification-before-completion → requesting-code-review```
专注于 Bug 修复的精简链路。
7.3 为团队建立共享技能库
对于团队场景,你可以建立一个私有的技能仓库,团队成员统一使用:
# 团队技能仓库结构
team-skills/
skills/
api-versioning/SKILL.md
security-review/SKILL.md
deployment-checklist/SKILL.md
.superpowers.json # 团队配置
这样,团队中所有成员的 AI Agent 都会遵循统一的工程规范,不需要每个人单独配置。
八、Superpowers 的局限性和适用场景
8.1 局限性
1. 学习成本
Superpowers 的工作流对开发者也有要求。如果你不熟悉 TDD、git worktree 等工程实践,可能需要先理解这些概念才能充分利用 Superpowers。它不是「零门槛」的解决方案。
2. 不适合探索性编程
当你还在探索阶段,不确定要做什么,Superpowers 的「先设计再编码」流程可能显得笨重。这时候你可能更适合直接用 Claude Code 的自由模式。
3. 平台兼容性差异
不同 AI Agent 平台对插件系统的支持程度不同。Claude Code 的体验最完整,但在其他平台上部分功能可能受限。
4. 小任务的过度工程
如果你只是改个 CSS 颜色或修个 typo,走完整套 brainstorming → planning → TDD 流程就太重了。Superpowers 在这类场景下会自动简化,但仍需要一定的启动开销。
8.2 最佳适用场景
✅ 新功能开发(特别是中大型功能)
✅ Bug 修复需要系统性分析的场景
✅ 多人协作的项目(统一工程规范)
✅ 需要高代码质量的正式项目
✅ AI Agent 长时间自主工作的场景(不跑偏的关键)
❌ 探索性的原型实验
❌ 单行代码修改或配置调整
❌ 对工程流程不熟悉的初学者
九、从 20 万 Star 看AI Agent 基础设施的新战场
Superpowers 的成功不是孤立的。它背后反映了一个更大的趋势:AI Agent 的竞争正在从「谁的模型更聪明」转向「谁的工程流程更可靠」。
9.1 三层架构的演变
AI 编程生态正在形成三层架构:
第一层:模型层(Foundation Models)
- Claude、GPT-4o、Gemini、DeepSeek
- 提供「原始智能」
第二层:Agent 框架层(Agent Harness)
- Claude Code、Cursor、Copilot、Trae
- 提供「交互方式和工具调用」
第三层:方法论层(Methodology / Skills)
- Superpowers、自定义 Rules、工作流模板
- 提供「工程规范和质量保证」
Superpowers 占据的是第三层——方法论层。这一层的价值不在于「让 AI 更聪明」,而在于「让 AI 更可靠」。
随着模型能力的趋同,方法论层的差异化价值会越来越大。 当所有 AI Agent 都能写出「差不多」的代码时,谁能保证代码质量、工程规范、可维护性,谁就赢得了开发者的信任。
9.2 「反 AI 赌局」的哲学
Superpowers 的成功还揭示了一个有趣的悖论:一个用纯 Markdown 文件写成的项目(没有一行代码),帮助 AI 写出了更好的代码。
这就像一个资深工程师的「内功心法」——它不教你写代码的具体技巧,而是教你「在写代码之前应该怎么思考」。正是这种「方法论胜过工具」的哲学,让 Superpowers 在 AI 编程工具井喷的 2026 年,反而成为了最独特的存在。
9.3 对开发者的启示
Superpowers 给我们的启示是:
提示词工程的天花板已经可见。 单靠优化提示词,AI Agent 的产出质量上限是固定的。要突破这个上限,需要系统化的方法论。
工程实践不能因为用了 AI 就放弃。 TDD、code review、模块化设计——这些原则在 AI 编程时代不仅没有过时,反而更加重要。
AI 编程的未来是「人 + 方法论 + AI」,不是「人 + AI」。 方法论是连接人类工程经验和 AI 执行能力的桥梁。
开源方法论可能比开源模型更有长期价值。 模型会迭代,但好的工程方法论是经得起时间考验的。
十、总结
obra/superpowers 用一个看似简单的想法——把软件工程 best practices 变成 AI Agent 的自动执行工作流——解决了 2026 年 AI 编程领域最核心的问题:AI 有能力写代码,但缺乏「像工程师一样思考」的能力。
它的核心价值在于:
- 设计先行:brainstorming 技能确保在写代码之前真正理解需求
- 精确规划:writing-plans 技能把大需求拆成 2-5 分钟的小任务
- 强制质量:TDD 和两阶段审查确保每个任务都高质量完成
- 系统化流程:systematic-debugging 确保问题被正确诊断和修复
- 工程隔离:git worktree 确保并行开发的安全性
这些不是新概念,它们是软件工程几十年来积累的智慧。Superpowers 的贡献在于:把这些智慧变成了 AI Agent 可以自动执行的、跨平台复用的、可组合的工作流。
20 万颗 Star 不是给一个工具的,是给一种理念的:在 AI 时代,方法论的价值不是在下降,而是在急剧上升。
如果你在使用 Claude Code、Cursor 或任何 AI 编程助手,还没有试过 Superpowers,强烈建议花 10 分钟安装体验一下。它可能会彻底改变你对「AI 编程」这件事的预期。
参考资源
- GitHub 仓库:https://github.com/obra/superpowers
- 官方博客:https://blog.fsck.com/2025/10/09/superpowers/
- Prime Radiant 公司:https://primeradiant.com
- Discord 社区:https://discord.gg/35wsABTejz
- 更新订阅:https://primeradiant.com/superpowers/