【2026 AI效率神器】Superpowers：场景应用

一条闲鱼_mytube

261人浏览 · 2026-05-09 17:59:55

一条闲鱼_mytube · 2026-05-09 17:59:55 发布

【2026 AI效率神器】Superpowers：场景应用

一、Superpowers是什么？

1.1 核心数据

指标	数据
GitHub Star	36.6K
协议	MIT
版本	v5.0.7（2026-03-31）
创建者	Jesse Vincent（GitHub: obra）

1.2 支持平台

✅ Claude Code    ✅ Cursor          ✅ Codex
✅ OpenCode       ✅ Gemini CLI      ✅ GitHub Copilot CLI

1.3 解决了什么问题？

痛点场景	没有Superpowers	有Superpowers
AI写代码	上来就写，写完发现方向错了	先设计，再动手
上下文管理	做着做着就忘了需求	每个任务都是全新的开始
测试覆盖	代码写完再说，测试能省则省	先写测试，再写代码
代码质量	靠感觉，“应该没问题”	独立审查，有证据才能说完成
分支管理	主分支直接改，改崩了没法回	隔离工作区，搞砸了删掉重来

核心理念：不是让AI更聪明，而是让AI更守规矩。

二、14个Skills全景图

Superpowers由14个可组合的Skills构成，分四大类：

┌─────────────────────────────────────────────────────────────────────────┐
│                         🚦 Superpowers 14 Skills                         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  【协作类 - 9个】                                                         │
│  brainstorming | writing-plans | executing-plans |                     │
│  subagent-driven-development | dispatching-parallel-agents |           │
│  requesting-code-review | receiving-code-review |                      │
│  using-git-worktrees | finishing-a-development-branch                   │
│                                                                         │
│  【测试类 - 1个】                                                         │
│  test-driven-development                                                │
│                                                                         │
│  【调试类 - 2个】                                                         │
│  systematic-debugging | verification-before-completion                   │
│                                                                         │
│  【元类 - 2个】                                                           │
│  writing-skills | using-superpowers                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

2.1 强制触发机制（核心设计）

这套流程能跑起来的关键在于强制触发：如果存在适用的技能，Agent必须使用，没有选择的余地。

这靠的是 Robert Cialdini 的说服学原理：

原理	应用方式
权威性	提示词里写"技能是强制性的"
承诺	让Agent主动宣布使用技能
社会证明	描述"始终"会发生什么

三、三大场景：三套流程适配不同需求

场景	工作流	步骤数
从零开始新项目	完整7步流程	7步
老项目加新功能	完整流程（brainstorming侧重已有代码）	7步
修复bug	精简流程	3步

3.1 场景一：从零开始新项目（完整7步）

新项目的风险不在写不出来，而在写偏了。

Superpowers的brainstorming技能有一条硬性门槛：不展示设计并获得用户批准前，绝不启动任何实现。

7步流程

brainstorming → using-git-worktrees → writing-plans →
subagent-driven-development → test-driven-development →
requesting-code-review → finishing-a-development-branch

步骤	名称	核心作用	一句话比喻
1	头脑风暴	需求澄清，设计确认	盖房子前先画图纸
2	Git Worktree隔离	保护主分支，安全试错	练车去驾校，不在公路上练
3	编写计划	任务拆分，可控执行	把大象切成小块吃
4	子代理开发	避免上下文漂移	每道菜换一个新厨师
5	TDD	测试先行，质量保证	先立规矩再干活
6	代码审查	独立检查，破除盲区	别人帮你挑刺
7	分支收尾	规范合并，清理现场	做完饭要收拾厨房

避坑要点

⚠️ brainstorming阶段别急，多花点时间在需求澄清上，后面省的时间远比这里多
⚠️ writing-plans阶段重点检查任务粒度，太大或太小都影响子代理效率
⚠️ worktree创建后先跑一遍测试基线，确认环境没问题再开始开发

3.2 场景二：老项目加新功能（7步，侧重点不同）

老项目有历史包袱。现有的代码模式、架构风格、依赖版本都是约束条件。

Superpowers在brainstorming技能中有一个专门的指导：Working in existing codebases。

核心原则三条：

1. 遵循现有代码模式和架构
2. 不提议无关的重构
3. 新代码要和项目风格一致

说白了就是入乡随俗。

一个容易忽略的步骤

在老项目里用Superpowers，别跳过using-git-worktrees。

worktree的价值不仅是隔离代码，更关键的是给你一个可以随时丢弃的沙箱——改坏了直接删worktree，主分支毫发无损。

3.3 场景三：发现并修复BUG（精简3步）

这个场景和前两个有本质区别——不需要完整工作流，只需要精准打击。

系统化调试四阶段

┌──────────────────────────────────────────────────────────────┐
│                    🔍 系统化调试四阶段                        │
│                                                              │
│  【阶段一：根因调查】                                         │
│  不做任何修改，只做信息收集                                   │
│  目标：找到bug的真正原因，而不是表象                           │
│                          ↓                                   │
│  【阶段二：模式分析】                                         │
│  - 偶发的还是必现的？                                         │
│  - 和特定输入相关还是和环境相关？                             │
│                          ↓                                   │
│  【阶段三：假设与测试】                                       │
│  形成修复假设，用测试验证——写一个能复现bug的自动化测试        │
│                          ↓                                   │
│  【阶段四：实施修复】                                         │
│  确认假设正确后，才真正动手改代码                              │
└──────────────────────────────────────────────────────────────┘

实战举例：用户反馈"点击导出按钮没反应"

表象：按钮失效
根因：API返回500错误，前端没有处理错误状态

如果你只修前端按钮的样式，问题还在。

四、三条铁律：为什么管得这么严

Superpowers把它们叫做 Iron Laws（铁律），不是建议，是硬性约束。

4.1 铁律一：没有失败测试就不写生产代码

<IRON LAW>
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
</IRON LAW>

逻辑链：如果你写不出一个能失败的测试，说明你还没想清楚要实现什么。

TDD的三个具体好处：

好处	具体表现
迫使你思考接口设计	写代码前先想清楚API长什么样
提供即时反馈	写完马上就能验证
形成安全网	后续改动不怕引入回归

4.2 铁律二：不做根因调查就不修bug

没有根因分析的修复，本质上是在碰运气。改了一行代码，bug消失了，但不确定为什么。

但根因调查慢在前面，修一次就彻底解决。不查根因快在前面，同一个bug反复出现，总时间反而更多。

4.3 铁律三：没有新鲜验证证据就不做完成声明

这条铁律对抗的是一种心理倾向——改完代码后急着宣布"搞定了"。

Superpowers要求的验证证据包括：

□ 测试全部通过
□ 手动验证确认
□ 相关功能无回归

三条都满足才算完成。

"新鲜"这个词很关键。 不是"昨天跑过了"，不是"之前没问题"，是"刚刚验证过"。

4.4 三条铁律的本质

┌──────────────────────────────────────────────────────────────┐
│              三条铁律对抗的是三种典型的偷懒行为              │
│                                                              │
│  ❌ 不写测试        →  没有失败测试就不写生产代码             │
│  ❌ 不查根因        →  不做根因调查就不修bug                  │
│  ❌ 不验证就收工    →  没有新鲜验证证据就不做完成声明         │
│                                                              │
│  Superpowers不是在教你怎么做事，而是在阻止你偷懒。           │
└──────────────────────────────────────────────────────────────┘

五、七步工作流详解

5.1 第一步：头脑风暴（HARD-GATE）

<HARD-GATE>
在呈现设计方案并获得你批准之前，绝对不能：
1. 调用任何实现技能
2. 写任何代码
3. 搭建任何项目结构
4. 做任何和实现相关的动作
</HARD-GATE>

9步标准化设计流程：

步骤	内容	关键动作
1️⃣	探索项目上下文	AI自动扫描现有代码和架构
2️⃣	可选：视觉伴侣	涉及UI时提供可视化工具
3️⃣	苏格拉底式提问	一次问一个问题，逐个澄清需求
4️⃣	提出2-3个方案	每个方案都有权衡分析
5️⃣	分段展示设计	按复杂度分段，逐段确认
6️⃣	编写设计文档	自动保存到 `docs/superpowers/specs/`
7️⃣	规范自检	检查有没有TBD、TODO等占位符
8️⃣	等待你审查	只有你确认了才会往下走
9️⃣	调用写计划技能	唯一合法的下一步

5.2 第二步：Git工作区隔离（FORBIDDEN）

<FORBIDDEN>
1. 绝对不能在主分支直接做开发改动
2. 工作区目录必须被Git忽略
3. 开发前必须先验证基线测试
</FORBIDDEN>

隔离工作区架构：

主分支 (main) - 永远干净
    │
    ├── .worktrees/feature-login/    ← 登录功能开发区
    ├── .worktrees/feature-payment/  ← 支付功能开发区
    └── .worktrees/bugfix-crash/     ← Bug修复区

5.3 第三步：编写计划（禁止占位符）

<FORBIDDEN>
1. TBD / To Be Determined：待确定
2. TODO：待完成
3. 下一步：... / 接下来：...
4. 后续会实现... / 之后会添加...
</FORBIDDEN>

关键原则：每个任务2-5分钟可完成，避免子代理"失忆"。

任务的三要素：

要素	说明
精确的文件路径	告诉子代理要改哪个文件
完整的代码	禁止TBD、TODO占位符
验证步骤	确保改动真的有效

5.4 第四步：多代理开发（上下文隔离）

<FORBIDDEN>
1. 绝对不能用同一个代理做多个任务
2. 审查必须先规格审查，再质量审查
3. 子代理遇到问题必须主动求助
</FORBIDDEN>

两轮复查机制：

轮次	审查内容	核心问题
第一轮	规格合规性	我们有没有做对的事情？
第二轮	代码质量	我们有没有把事情做好？

5.5 第五步：TDD测试驱动

<IRON LAW>
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
</IRON LAW>

RED-GREEN-REFACTOR循环：

【RED】写测试 → 看着它失败
         ↓
【GREEN】写最少的代码让测试通过
         ↓
【REFACTOR】优化代码质量，保持测试绿色

5.6 第六步：代码审查

<IRON LAW>
1. 代码审查必须由独立代理执行
2. Critical级别必须立即修复
3. 没有完成验证，不许宣称完成
</IRON LAW>

三级审查标准：

级别	说明	处理方式
Critical	安全漏洞、数据泄露、权限缺失	必须立刻修
Important	边界条件漏了、逻辑错误、缺少日志	必须修完才能进入下一个任务
Minor	变量名不好、注释不够清楚	记录下来，后续再处理

5.7 第七步：完成分支

<IRON LAW>
1. 收尾之前必须先跑完整测试
2. 高风险操作必须二次确认
3. 自定义技能也要用TDD
</IRON LAW>

四个标准化收尾选项：

选项	适用场景	执行流程
本地合并	个人项目、小功能	切回主分支 → 合并 → 测试 → 删除分支
创建PR	团队协作、需要审查	推送 → 创建PR → 保留分支待改
保留分支	开发到一半，要做别的事	保留分支和worktree，继续开发
丢弃分支	做砸了，要删掉重来	输入discard确认 → 删除所有内容

六、实战建议

6.1 怎么选工作流

做新东西（新项目或新功能）→ 走完整7步
修bug → 走3步精简版（调试 → TDD → 验证）
有多个不相关的独立任务 → dispatching-parallel-agents并行处理

6.2 安装方式

Claude Code用户：

/plugin install superpowers@claude-plugins-official

Cursor用户：

/add-plugin superpowers

6.3 什么时候用，什么时候不必

适合场景：有一定复杂度的开发任务、多文件改动、需要测试保护、需要代码审查

不必用场景：改个配置文件、写个简单脚本（用Superpowers反而重了）

6.4 常见问题

Q1：Superpowers会拖慢开发速度吗？

前期确实会慢。但这个时间花在设计阶段，能减少后期的返工。

用官方文档的话说：流程优于猜测（Systematic over ad-hoc）

Q2：可以只用部分Skills吗？

Skills是可组合的，不需要每次走完整流程。修bug就是个例子——只用3个Skills。

Q3：对什么编程语言有效？

Superpowers约束的是开发流程，不是代码实现，理论上不限语言。

不过TDD在不同语言中的体验差异比较大：Python、JavaScript这类动态语言写测试比较轻快，C++、Java这类编译型语言测试周期会长一些。

七、总结

不是让AI更聪明，而是让AI更守规矩。

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  Superpowers解决的不是"AI不会写代码"的问题                   │
│                  而是"AI写代码不够靠谱"的问题                 │
│                                                              │
│  14个Skills覆盖从需求梳理到代码审查的完整流程                │
│  3条铁律对抗开发中三种典型的偷懒行为                          │
│  子代理驱动开发解决多任务场景下的上下文污染问题               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

与传统CI/CD的关系

维度	CI/CD	Superpowers
规范对象	构建→测试→部署等后期自动化活动	需求分析→设计→编码→初级审查等前期创造性活动
关系	互补而非竞争	共同构成从"想法"到"上线"的完整自动化链条

资源	链接
GitHub仓库	https://github.com/obra/superpowers
当前版本	v5.0.7（2026-03-31）
支持平台	Claude Code、Cursor、Codex、OpenCode、Gemini CLI、GitHub Copilot CLI

附录：工作流速查表

┌──────────────────────────────────────────────────────────────┐
│                      场景 → 工作流速查                        │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  【新项目】完整7步                                             │
│  brainstorming → using-git-worktrees → writing-plans →       │
│  subagent-driven-development → test-driven-development →     │
│  requesting-code-review → finishing-a-development-branch     │
│                                                              │
│  【修BUG】精简3步                                             │
│  systematic-debugging → test-driven-development →            │
│  verification-before-completion                               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

推荐指数：⭐⭐⭐⭐⭐

如果你觉得这篇文章有帮助，欢迎点赞、评论、转发！有问题可以在评论区交流。

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

主题12：蓝牙家族——从替代线缆到Mesh组网

摘要：蓝牙技术的演进揭示了四个可迁移的思维模型核心矛盾迁移：蓝牙从BR/EDR（解决物理线缆束缚）到BLE（优化能耗）再到Mesh（应对系统复杂度），呈现了从“点”到“体”的层级跃迁。设计减法哲学：每代技术通过放弃某些特性（如BLE放弃持续连接）换取主场景的极致（低功耗）。资源再平衡：在能量、带宽、算力间动态调配，例如Mesh用市电节点的算力缓解电池节点的能耗压力。分层自治：从中心化控制转