Superpowers Dev Workflow

核心用法

Superpowers 是一套面向复杂软件开发的强制性工作流引擎，采用子代理驱动架构实现从需求到交付的完整管道。用户通过自然语言触发构建意图后，系统自动进入五阶段管道：Brainstorm（需求探索与设计文档化）→ Writing Plans（任务级实施计划拆解）→ Subagent-Driven Build（TDD 子代理执行与双重审查）→ Systematic Debugging（根因驱动的故障修复）→ Finish Branch（测试验证与分支收尾）。

执行模式上，系统优先推荐 subagent-driven 模式：主代理通过 sessions_spawn 启动实现者子代理完成单任务（2-5 分钟粒度），随即调度规范审查子代理与代码质量审查子代理进行两阶段验证，形成「执行-审查-修复」闭环。TDD 为强制约束：每个任务必须先写失败测试，再实现功能，测试通过后立即提交。

显著优点

1. 流程刚性保障质量：通过「HARD GATE」设计（如无设计审批不写代码、无根因分析不修 bug）杜绝跳过关键步骤的冲动，在时间压力下维持工程纪律。
2. 子代理分工专业化：规范审查与质量审查分离，降低单点认知负荷，提升代码一致性。
3. 极小任务粒度：2-5 分钟任务单元降低认知负荷，配合频繁提交形成可回滚的安全网。
4. 故障处理系统化：四阶段调试流程（根因调查→模式分析→假设验证→修复确认）避免"试试这个"式的低效修复。

潜在缺点与局限性

• 启动成本高昂：简单功能（如单文件修改）强制走完整五阶段，产生显著流程税，官方明确排除"one-liner fixes"场景但仍需人工判断边界。
• 依赖子代理基础设施：需要 exec 工具与 sessions_spawn 支持，环境兼容性受限。
• 同步阻塞开销：两阶段审查串行执行，可能拉长反馈周期；子代理调度失败时主流程停滞。
• 计划刚性：YAGNI 与 DRY 原则虽被强调，但过度拆分可能导致微观管理，抑制探索式编程。

适合人群

• 中大型功能开发（>30 分钟编码量）或需要多人协作对齐的复杂需求
• 对代码质量有硬性要求、愿意用流程换确定性的团队
• 需系统性根因分析的生产故障排查场景

常规风险

1. 子代理失控：任务描述模糊可能导致子代理实现偏离意图，需严格遵循 OpenClaw Dispatch Pattern 提供完整上下文。
2. 测试维护负担：强制 TDD 在快速原型阶段可能产生大量需同步更新的测试代码。
3. 文档债务累积：docs/plans/ 目录的设计文档与实施计划若缺乏治理，将成为弃档。
4. 用户决策疲劳：Brainstorm 阶段"一次一问"与分段审批虽提升质量，但高频交互可能消耗用户耐心。

核心用法

Superpowers 是一套强制执行的软件开发生命周期工作流，由资深开发者 obra 设计，源自其拥有 178k+ stars 的同名开源项目。它将任何编码任务分解为五个严格阶段：

1. Brainstorming（设计） — 探索上下文、一次性提问、提出 2-3 种方案、分节获取批准、输出设计文档
2. Writing Plans（规划） — 将设计拆分为 2-5 分钟可完成的原子任务，明确 TDD 步骤
3. Subagent-Driven Build（开发） — 通过 sessions_spawn 派发实现子代理，强制双阶段审查（spec-reviewer + code-quality reviewer）
4. Systematic Debugging（调试） — 根因调查 → 模式分析 → 假设验证 → 修复验证，禁止无根因的 symptomatic fix
5. Finishing Branch（收尾） — 全量测试通过、提供 merge/PR/keep/discard 四种选项

触发条件明确：新功能、bug 调试、用户说"build/plan/fix"、功能分支收尾。明确排除单行修复、纯读代码、非编码任务。

显著优点

• 工业级方法论背书：obra 为 2009 年注册 GitHub 资深开发者（5483 followers），项目社区认可度极高
• 强制质量门禁：TDD 为硬性要求（先写失败测试，再实现，测试通过才提交），双审查子代理杜绝自我验证偏差
• 防范围蔓延（YAGNI/DRY）：设计阶段即剔除不必要功能，约束字段明确禁止 scope creep
• 时间压力下的系统性：强调"尤其 under time pressure 更要 follow the process"，对抗 hack-and-rush 本能
• 零依赖零攻击面：纯 Markdown 文档（T-MD 分类），无可执行代码、无第三方依赖、无网络 API 调用

潜在局限

• 启动成本较高：2-5 分钟原子任务粒度 + 双审查流程，对极简单功能（如变量重命名）可能显得笨重；虽然文档说明排除"one-liner fixes"，但边界判断依赖用户自律
• 子代理调度开销：需要 exec 和 sessions_spawn 工具支持，在资源受限环境或工具链未配置时无法生效
• 流程刚性："HARD GATE" 设计（如无批准不写代码、无根因不修 bug）可能与紧急 hotfix 场景冲突
• 中文本地化缺失：原始文档和审查标准均为英文，非英语团队需自行适配

适合人群

• 追求代码质量的专业开发团队，尤其是采用 AI 辅助编程但担心"幻觉代码"的工程师
• 技术负责人/架构师：需要将团队从 ad-hoc 开发转向系统化流程的管理者
• 复杂功能开发：任何涉及多文件协调、测试策略设计、需要长期维护的中大型功能
• 开源项目维护者：obra 自身的项目验证了这一流程在协作场景的有效性

常规风险

• 流程形式主义风险：团队可能机械执行阶段文档而忽视实质质量，需配合 code review 文化
• 子代理循环延迟：网络或模型响应不稳定时，per-task 的双审查循环可能显著拉长开发周期
• 与现有工作流冲突：若团队已使用敏捷/Scrum 或特定 Git Flow，五阶段流程需要刻意整合

安全层面已通过 CLS S 级认证，唯一发现为 "Verify:" 关键词误报的 CI 检测模式，确认为文档描述无害。