引言：流程大于提示词
Superpowers 并非简单地赋予 AI 更强大的编码能力，而是一套将软件工程最佳实践固化进 AI 行为 的方法论体系。它的核心信条是：流程大于提示词（Process over Prompt）。通过一套强制性的工程流程，Superpowers 将 AI 从随性的"代码生成器"转变为遵守纪律的"协作伙伴"。
但关键问题随之而来：面对协作型、实现型、开发型等不同流程，系统如何决定执行哪一个？什么情况下该启动完整流程，什么情况下又该跳过？本文将从控制机制与适用边界两个维度，为你系统拆解 Superpowers 的流程调度逻辑。
第一部分：双路径调度机制------自然语言与斜杠命令
Superpowers 的流程调度不依赖用户手动选择流程类型，而是通过自然语言意图识别 与斜杠命令显式触发两条路径自动完成。
路径一：自然语言意图识别（自动触发）
每个 Skill（技能）本质上是一份 Markdown 方法论描述，其中 description 字段专门用于说明何时应该触发该技能，而非描述它做什么。当用户向 Claude 描述任务时，系统会自动检查当前任务与哪个 Skill 的触发条件匹配，命中后自动加载并按步骤执行。
例如，当你说"帮我给这个项目加一个用户登录功能"时，系统会自动识别出这是一个需要需求澄清的复杂任务，于是触发 brainstorming 技能，而不是直接开始写代码。
路径二：斜杠命令显式触发（手动锁定）
当你清楚自己处于工作流的哪个阶段，不想让系统去猜测意图时，可以直接使用斜杠命令锁定执行节点：
/superpowers:brainstorm------ 强制进入需求澄清阶段，产出设计文档/superpowers:plan------ 将已批准的设计拆解为 2-5 分钟粒度的小任务/superpowers:execute-plan------ 按计划执行编码，必要时启动子代理/superpowers:review------ 单独触发代码审查子代理/superpowers:tdd------ 强制按 TDD 红绿重构循环执行/superpowers:debug------ 进入系统性调试流程
指令优先级
当多种触发方式同时生效时，系统遵循明确的优先级规则：
用户显式指令 > Superpowers 技能匹配 > 默认系统提示
这意味着，如果你明确说了"跳过 brainstorm，直接改这个小配置"，系统会尊重你的判断，退化为普通的 Claude Code 行为。
第二部分：六大自动化控制层的深度解析
Superpowers 的流程控制并非简单的 if-else 逻辑，而是由 6 层自动化机制 协同工作，根据输入内容和项目上下文自动完成流程判断与调度。
| 控制层 | 核心作用 |
|---|---|
| 强制触发层 | using-superpowers 规定：即使只有 1% 概率适用，也必须调用对应技能 |
| 触发条件匹配层 | 每个 SKILL.md 的 description 只写"何时触发"，不写"做什么" |
| 指令优先级层 | 用户显式指令 > Superpowers 技能 > 默认系统提示 |
| 多技能排序层 | 冲突时先执行流程技能（brainstorming/debugging），再执行实现技能 |
| 刚性/弹性分类层 | TDD 等刚性技能不可削弱；头脑风暴等弹性技能可适度调整 |
| 会话钩子层 | 启动时自动注入全局上下文，让 Agent 持续检查触发条件 |
多技能冲突时的排序逻辑
当多个技能同时被触发时，系统会按照先规划、后执行的原则排序：
- 流程/协作型技能优先 ：如
brainstorming、writing-plans、systematic-debugging - 实现/开发型技能随后 ：如
executing-plans、test-driven-development
这一设计的底层逻辑是：想清楚再动手，而不是边想边做。
刚性技能与弹性技能的区分
并非所有技能都同等严格。Superpowers 将技能分为两类：
- 刚性技能（不可削弱） ：如
test-driven-development，必须严格遵守红绿重构循环，没有妥协空间。 - 弹性技能（可适度调整） ：如
brainstorming，可以根据任务复杂度适当缩减问答轮次。
这种分类确保了质量底线不被突破 ，同时避免过度流程化。
第三部分：两种流程类型的定位与对比
Superpowers 的技能库可以清晰地分为两条主线，对应你所说的"协作型"和"实现型"两大流程。
| 维度 | 协作/流程型 | 实现/开发型 |
|---|---|---|
| 核心技能 | brainstorming、writing-plans、requesting/receiving-code-review、using-git-worktrees、finishing-a-development-branch | test-driven-development、systematic-debugging、verification-before-completion、executing-plans |
| 触发方式 | /superpowers:brainstorm、/superpowers:plan、/superpowers:review |
/superpowers:execute-plan、/superpowers:tdd、/superpowers:debug |
| 前置条件 | 仅需口头/文字需求，越模糊越适用 | 通常需要设计文档 + 任务清单 |
| 典型输出 | 设计文档、实施计划、代码审查报告 | 测试先行代码、修复补丁、审查通过的提交 |
| 人工介入点 | 苏格拉底式问答、分段确认设计、批准计划 | 任务级 checkpoint、两道评审门 |
协作型流程的核心价值
协作型流程确保"做正确的事"。它通过强制性的前置思考，防止 AI（和人类）在需求不清晰时贸然动手。其典型路径为：
Brainstorming（需求澄清） → Writing Plans（任务拆解） → Code Review（质量审查）实现型流程的核心价值
实现型流程确保"正确地做事"。它通过 TDD、调试流程和评审门禁，保证每一行代码都经过验证。其典型路径为：
Executing Plans（按计划编码） → TDD（测试驱动） → Verification（完成验证）两者关系：串联而非对立
在完整的项目开发中，这两类流程通常是串联执行的：
Brainstorming (协作) → Writing Plans (协作) → Subagent-Driven Development (实现) → Code Review (协作)而小任务可以只挑其中一两个 Skill 单点使用，不必全开。
第四部分：三种典型场景的自动流程映射
Superpowers 并非一刀切地执行完整流程，而是根据任务类型自动映射不同的流程路径：
| 场景类型 | 自动映射流程 | 包含技能 |
|---|---|---|
| 新项目/加功能 | 完整 7 步流程 | 头脑风暴 → 计划 → 子代理开发 → TDD → 审查 → 验证 → 合并 |
| 修 Bug | 精简 3 步流程 | systematic-debugging → TDD → verification-before-completion |
| 多个独立任务 | 并行派发 | dispatching-parallel-agents（每个子任务独立子代理） |
这种差异化映射确保：复杂任务不被草率对待，简单任务不被流程压垮。
第五部分：适用边界------什么时候该用，什么时候不该用
✅ 适合使用 Superpowers 的场景
判断核心标准：这个任务做错了，重做代价大不大？需不需要留档和审查？
- 多步复杂任务：跨多文件的新功能开发、涉及前后端联调的改动，需要先拆任务再动手
- 需要架构设计评审：方案有多个可选路径（如鉴权用 OAuth vs. JWT vs. Session），需要对比确认
- 多人协作/需要留档：设计文档和计划以 Markdown 落盘，便于团队 review 和后续接手
- 长期维护项目：TDD 强制保证测试覆盖率，减少回归成本（社区实测返工时间可降 70%+）
- 易出 Bug 的调试任务：systematic-debugging 的四阶段根因流程避免"猜补丁"循环
- 需要子代理并行执行：配合 git worktree 隔离实验环境，避免污染主分支
❌ 不适合使用 Superpowers 的场景
判断核心标准：流程成本是否高于任务本身价值？
- 一次性脚本、Demo、原型验证：完整流程的成本可能超过写代码本身
- 简单 Bug 修复 / 单行改动：被强制走 brainstorm + plan + TDD 严重拖慢节奏
- 需要快速响应的临时变更：线上 hotfix、临时数据修复，没时间做需求澄清
- 纯探索性/学习性代码：目的只是试 API 或理解概念，不需要设计文档
- 与 Claude Code Plan Mode 冲突时：Plan Mode 会覆盖 Superpowers 的 Skill 调度，需先关闭
- Token 极度受限场景：多轮问答和两阶段评审会显著增加 token 消耗
⚠️ 自动触发可能失败的情况
需要特别注意的是，自动触发机制有时会误判或失效：
- Plan Mode 冲突：Claude Code 自带的 Plan Mode 会覆盖 Superpowers 的技能调度，导致技能完全不被调用
- 模糊意图：任务描述不够清晰时，系统可能无法准确匹配对应技能
解决方案：在 prompt 中加入锚定短语来强化触发，例如：
- "先按 brainstorming 流程澄清需求，不要直接写代码"
- "按 TDD 红绿重构循环执行，先写测试"
- "进入 systematic-debugging 四阶段根因流程"
第六部分：快速决策清单
面对一个具体任务时，你可以通过三个问题快速判断应该走哪条路径：
问题一：这个任务做错了，重做代价大吗？
- 大 → 走完整流程型（brainstorm → plan → review）
- 小 → 直接实现型，或不用框架
问题二：我是否已经清楚要改成什么样？
- 清楚 → 跳过 brainstorming，直接进 plan 或实现
- 不清楚 → 必须先 brainstorm
问题三：这段代码将来会被维护/审查吗？
- 会 → 走完整流程
- 不会 → 轻量执行即可
一句话总结决策逻辑
协作型流程管"想清楚再动手"，实现型流程管"动手时不出错"------前者靠命令和确认门控制节点，后者靠 TDD 和评审门控制质量。大多数完整项目是两条流程的串联，而小任务可以只挑其中一两个 Skill 单点使用，不必全开。
结语：按需启用，而非全部启用
Superpowers 是一套强大但并非万能的工具。其设计哲学是通过结构性流程替代随意对话，从而将 AI 的编码行为从"不可预测"变为"可管理"。
最佳实践是按需启用：
- 面对正式、复杂的项目时，让 Superpowers 发挥"流程引擎"的完整优势
- 面对简单、探索性、一次性的任务时，灵活跳过，避免过度设计
理解其双路径调度机制和六层自动化控制，你就能在"流程保障"与"敏捷响应"之间找到最佳平衡点。这套系统的真正价值不在于强制执行，而在于让你在需要时可以有章可循，在不需要时也可以轻松绕过------流程服务于人，而非人服务于流程。