Superpowers 编程纪律
Superpowers 编程纪律
核心定位与理念
Superpowers 是一套面向 AI 辅助编程的强制纪律（skills / 工作流框架），核心理念可以概括为：流程优先于直觉编码，追求「更稳」而不是盲求「更快」。
它在 GitHub 上体量很大（常见公开叙述里有十几万 Star、短期暴涨之类说法；具体数字会随时间变化，不必死记）。
随机选模型、直接让 AI「从零写到尾」，最容易出现三类事故：需求漂移、不可测的改动面、没有测试与审查兜底的合并。Superpowers 试图用可重复的步骤把这些坑在前面挡住；本质上是在用「工程化流水线」约束 LLM 的跳跃式输出。
七步工作流程（展开理解）
1. 头脑风暴 → 设计文档
先谈清「做什么、不做什么、验收大概长什么样」，并落成设计文档。目的不是写八股文，而是：把隐含假设摊开，减少后面实现阶段 AI（和人）自行发挥的空间。没有这一步，后面的拆分往往是在给错误方向分工。
2. 工作区隔离 → 独立分支 / worktree
在独立分支（不少实践还会强调 git worktree 一类隔离）里干活，避免与主线杂糅。AI 改代码往往又快又碎，隔离能降低「顺手改坏主线」的概率，也方便整体丢弃或 cherry-pick。
3. 实施计划 → 拆成 2～5 分钟的自包含小任务
把设计拆成极小的、单点可完成的任务单元（常见说法是 2～5 分钟量级）。要点是：任务彼此边界清晰，便于指派给子代理或人类逐一核销；过大任务会把审查与测试又拖回「一团浆糊」。
4. 多代理开发 → 每任务派代理 + 两轮审查
为任务分配代理执行，并经过两轮审查。直觉上是为了降低单次模型的盲区与幻觉：第一轮抓明显错误与设计偏离，第二轮抓边界情况与一致性。具体形态取决于工具链（例如 Claude Code 的子代理模型）。
5. 测试驱动开发（TDD）
强调先写测试再写实现（红—绿—重构一类节奏）。对 AI 编程尤其有意义：测试先把「可验证的行为契约」钉死，减少「代码看起来能跑但并不符合意图」的情况；回归时也有一份自动化防线。
6. 代码审查 → 三级处理问题
按三个级别处理问题（例如：必须阻断合并的严重问题 / 应在本分支解决的中等问题 / 可记账跟进的小问题——具体分级以所用技能文档为准）。核心是：不是所有问题都等价，避免要么全放行要么无限拖延两种极端。
7. 完成分支 → 四种分支处理选项
收尾时给出四种分支处理方式（例如合并策略、是否 squash、是否保留实验分支、是否拆 PR 等——以官方说明为准）。目的是：合并不是只有一种姿势，让收尾也有纪律，而不是「能 push 就行」。
起源与技能体系（摘要）
框架由 Jesse Vincent（obra/superpowers 等公开仓库相关叙事）推动，出发点之一是对 AI 编程随机性 的不满——与其赌单次对话质量，不如把高质量团队的默认习惯编码成流程。
据称整套包含 14 个技能，大致可归为 测试、协作、元技能 等类别；每个技能通常约定：
- 触发条件（什么场景必须启用）；
- 不可跳过步骤（防止「口头答应、实操省略」）。
使用时不必一次啃完所有技能，可按项目类型先启用与 TDD、分支隔离、审查 强相关的几条。
平台安装与验证
支持 Claude Code、Cursor 等多种环境（公开材料里常列举多条安装路径）；各平台对应一条安装或插件命令即可接入。
验证是否生效可以试三件事：
- 让 AI 做一个小功能，看它是否会先文档/计划再动手；
- 故意给一个暧昧需求，看它是否追问边界而不是直接写；
- 直接问「当前启用了哪些 Superpowers 技能 / 下一步强制步骤是什么」。
若始终「一步到位糊代码」，多半是技能未加载或被会话指令覆盖。
个人消化：适用边界
- 收益：协作人多、生命周期长的代码库；对回归成本敏感的业务逻辑。
- 成本：小脚本、一次性试验可能被流程绊脚——可按粒度裁剪，但别把「省事」当成丢弃测试与审查的理由。
- 本质：Superpowers 不是魔法 prompt，而是把可重复的工程习惯外挂到 AI 工作流上；团队契约仍要人来守。