superpowers-学习总结.md 5.9 KB
Superpowers 学习总结（面向 Cursor/多代理开发）
来源：开源项目 obra/superpowers（方法论 + 可组合 skills）。本仓库已存在一套对齐 Superpowers 写法的产物示例：bx/docs/superpowers/specs/* 与 bx/docs/superpowers/plans/*（可直接对照理解“设计稿/实现计划”的期望形态）。
1. Superpowers 解决什么问题
Superpowers 的核心目标是让“代码代理”更像一支受纪律约束的工程团队，而不是一个即兴写代码的聊天机器人：
- 先澄清目标与边界，再动手实现，减少返工。
- 把隐性思考外显为文档（spec / plan），便于审阅与协作。
- 强调可验证性：用测试/构建/检查等证据，替代“我觉得完成了”的主观判断。
- 将工程流程模块化：通过“skills”把不同阶段的工作方式固化为可复用的流程单元。
2. 典型工作流（从想法到交付）
Superpowers 推荐的端到端流程大致如下（名称以仓库 README 的 workflow 为主）：
- Brainstorming（需求澄清 → 设计）
- 先理解“要做什么/不做什么/怎么验收”。
- 给出 2-3 种方案与取舍，形成推荐方案。
- 输出 设计文档（spec / design），并让人审阅。
- Using git worktrees（隔离开发环境）
- 用独立分支/工作区做变更，避免污染主线。
- Writing plans（把设计落到可执行任务）
- 把工作拆成可连续执行的小任务。
- 每个任务包含：修改文件路径、步骤、验收/验证命令、预期结果。
- Subagent-driven development / Executing plans（按计划执行）
- 每个任务由“独立子代理”执行，减少上下文污染。
- 执行过程中对齐 spec/plan，并进行阶段性自检/复核。
- Test-driven development（强流程：先测试后实现）
- 强制 RED→GREEN→REFACTOR，避免无验证的实现堆积。
- Requesting code review（阶段性审查）
- 从“是否符合计划/设计”与“代码质量”两层检查。
- Finishing a development branch（收尾）
- 复跑测试/构建，决定 PR/合并/保留分支/清理工作区。
要点：skill 不是建议，而是“硬流程”。当 skill 写了 hard-gate（例如“未获得设计批准不允许实现”），它期望你把它当成团队的流程约束来执行。
3. Skills 体系：把“怎么做”固化下来
Superpowers 把工程活动拆成一组可组合 skills（不同 skill 关注不同阶段）。常见分类：
3.1 过程类（Process skills）
这类 skill 决定“方法论与节奏”，通常更“刚性”：
- brainstorming
- 在写代码/做实现前先输出设计与边界。
- 强调：一次一个问题、给多个方案、设计分段确认、写 spec 落盘。
- using-git-worktrees
- 用隔离工作区降低风险，便于并行与回滚。
- writing-plans
- 把设计转成“可执行 checklist”，让执行者不需要大量上下文也能推进。
- subagent-driven-development / executing-plans
- 用子代理逐任务推进，并有两阶段复核（对齐 spec + 代码质量）。
- verification-before-completion
- 在宣称“完成/修复/可用”之前，必须跑验证并展示证据。
- systematic-debugging
- 遇到失败/异常时，遵循结构化定位：现象→假设→验证→修复→回归。
3.2 实现类（Implementation skills）
这类 skill 更关注“如何写出可维护代码”，但仍受过程类约束（先设计/计划，再实现）。
4. 文档产物形态：spec 与 plan 长什么样
在本仓库 bx/docs/superpowers/ 已经有一套非常贴近 Superpowers 的范例，可直接模仿：
- Spec（设计稿）示例：
bx/docs/superpowers/specs/2026-04-29-bx-mobile-align-web-design.md- 结构特征：
- 目标/边界（Goal & Non-goals）
- 已确认约束
- 对齐策略/实现原则
- 数据流、错误处理、验收口径、风险与缓解
- 明确“下一步进入 writing-plans”
- Plan（实现计划）示例：
bx/docs/superpowers/plans/2026-04-29-bx-mobile-align-web-implementation.md- 结构特征：
- 明确 Goal / Architecture / Tech Stack
- 责任映射（文件与职责）
- 验收 checklist 模板（可复用）
- 任务拆分为可勾选 checklist（
- [ ]），每个任务包含：- 需要修改/新增的文件列表
- 操作步骤
- 验证命令与预期结果
- 建议的提交粒度（可选）
经验规则：
- spec 回答“做什么/不做什么/为什么”
- plan 回答“怎么做/改哪里/如何验证”
5. 在 Cursor 场景的落地建议（简化版执行清单）
当你要让代理“像 Superpowers 一样工作”，可以按下面节奏组织：
- 先产出 spec（哪怕很短）
- 目标、非目标、约束、验收标准必须明确。
- 再产出 plan（任务化）
- 每个任务都要能在 2–10 分钟内推进，并带验证命令。
- 实现阶段按 plan 逐项推进
- 优先小步提交、小步验证。
- 每次宣称完成前都跑验证
- 构建、lint、单测、关键链路手测等，至少一种“硬证据”。
6. 与本仓库现有“skills/规范”的关系
本仓库本身也有一套“强制技能流程”与工程规范（例如：先用 brainstorming 做设计门禁、再写 plan、再执行；以及各子系统的目录结构/编码规范）。
建议策略：
- 以“用户明确指令”为最高优先级：如果用户要求直接产出某个文档/代码，流程可以压缩，但尽量保留最小可行的 spec/plan 骨架，避免后续返工。
- 尽量复用仓库既有的文档形态：例如
bx/docs/superpowers/specs/*、bx/docs/superpowers/plans/*这类结构，便于团队快速识别与复用。