如何在实际研发中合理选择与匹配 Superpowers 技能

一、先明确核心选型原则

1. 按研发阶段自动锚定基础技能 Superpowers 本身具备阶段式自动触发，优先遵循原生工作流；仅在复杂、高风险、定制化场景下手动追加指定技能，避免过度启用冗余能力。
2. 按代码风险等级收紧约束型技能 核心业务、支付、鉴权、中间件逻辑：强制绑定 test-driven-development、requesting-code-review、verification-before-completion； 工具类、配置类、边缘脚本：可适度简化流程，仅保留核心必备技能。
3. 按任务耦合度选择执行调度技能 强依赖、串行流程 → 选用 executing-plans / subagent-driven-development； 完全解耦、多任务并行 → 选用 dispatching-parallel-agents。
4. 按问题类型匹配专项技能 新增需求用设计类技能、Bug 排查用调试类技能、代码合并用分支收尾类技能，杜绝技能错配。

二、按研发场景分类：技能选型标准+示例

1. 需求分析 & 方案设计阶段

适用阶段：需求模糊、架构选型、模块设计、改造方案评估 必选核心技能

• brainstorming：所有自定义需求、模糊需求、架构设计必选 可选补充技能
• writing-plans：方案确认后，提前做任务拆解，用于预估工作量与变更范围 禁用/无需使用 调试类、子智能体调度、分支收尾类技能 选型示例

需求：改造项目缓存架构，替换本地缓存为 Redis 分布式缓存 选型：仅启用 brainstorming，完成缓存淘汰策略、序列化、过期策略、集群兼容、降级方案调研；确认方案后再启用 writing-plans 拆解改造任务。

2. 全新功能开发场景

适用阶段：新接口、新模块、新业务域从零开发 基础标准组合（通用） brainstorming → using-git-worktrees → writing-plans 执行模式二选一

• 小型简单功能、需要人工步步卡点：搭配 executing-plans
• 中大型功能、长流程低干预：搭配 subagent-driven-development 质量强制约束 全程绑定 test-driven-development，收尾叠加 requesting-code-review + verification-before-completion 选型判断逻辑
• 代码改动少、文件单一：使用 executing-plans 串行可控执行
• 多文件、多类、多接口联动：使用 subagent-driven-development 子智能体自治开发 选型示例

需求：新增 JWT 鉴权模块，包含签发、解析、刷新、黑名单管控 选型：brainstorming + using-git-worktrees + writing-plans + subagent-driven-development + TDD + 双评审校验。

3. 批量工具/通用组件开发

适用阶段：工具类、枚举、常量、通用 util、独立配置项等无耦合任务 核心选型

• 基础：brainstorming + writing-plans
• 调度核心：dispatching-parallel-agents
• 质量兜底：test-driven-development + requesting-code-review 选型逻辑 任务之间无依赖、互不调用、独立可运行，直接启用并行子智能体，缩短批量编码周期。

4. Bug 修复 & 问题排查

适用阶段：测试报错、线上异常、环境问题、依赖冲突、偶发故障 核心必选技能

• systematic-debugging：所有异常、报错、非预期行为唯一指定调试技能 配套组合
• 分支隔离：using-git-worktrees（线上问题热修复必用）
• 修复加固：test-driven-development（为 Bug 补充固化测试用例）
• 结果校验：verification-before-completion 选型逻辑 禁止直接修改代码做临时修复，只要存在报错、异常、逻辑错误，优先启用系统化调试流程。 选型示例

现象：Kafka 消费者重复消费、offset 提交异常 选型：using-git-worktrees + systematic-debugging 定位根因 + TDD 编写复现用例 + 回归验证。

5. 代码重构 & 旧系统改造

适用阶段：代码结构优化、逻辑梳理、技术栈升级、无业务变更改造 核心技能组合 brainstorming（划定改造边界）+ test-driven-development（存量行为锁死）+ systematic-debugging（解决重构兼容问题）+ requesting-code-review 选型关键 重构类场景TDD 优先级最高，通过存量测试保证业务逻辑无变更，避免隐性风险。

6. 代码评审 & MR/PR 整改

适用阶段：提交评审后、收到评审意见、规范整改、漏洞修复 专属技能

• receiving-code-review：接收外部评审意见时专用 搭配补充 整改涉及逻辑变更、边界补充时，叠加 test-driven-development 补充测试；整改完成后使用 verification-before-completion 回归校验。

7. 分支管理 & 交付收尾

适用阶段：开发完成、测试通过、准备合并主干、清理临时分支 唯一收尾技能

• finishing-a-development-branch 使用时机 所有编码、测试、评审全部结束后统一启用，不穿插在开发中途。

8. 团队定制 & 私有规则扩展

适用阶段：需要统一团队编码规范、自定义检查项、企业级约束 专属技能

• writing-skills 选型场景 仅在需要二次开发 Superpowers 自定义技能、修改内置规则、增加团队校验标准时使用，日常业务开发无需启用。

三、快速选型决策表

四、避坑：技能选型常见错误

1. 过度启用并行技能 有依赖、强时序的任务强行使用 dispatching-parallel-agents，会导致上下文缺失、逻辑错乱。
2. 跳过 brainstorming 直接编码 需求未澄清就开始开发，会放大 AI 主观臆断问题，造成大量返工。
3. 修复 Bug 不使用 systematic-debugging 仅做表面热修复，无法根除根因，引发重复问题。
4. 重构场景省略 TDD 无测试兜底的重构，极易引发隐性业务逻辑变更。
5. 提前执行收尾技能 未完成测试、评审就执行 finishing-a-development-branch，导致脏代码流入主干。

五、总结

1. 常规业务开发，优先依赖 Superpowers 原生自动触发链路，无需手动干预技能；
2. 按「设计→开发→调试→评审→交付」五个阶段分段选型，每个阶段只启用对应域的技能；
3. 高风险代码强绑定 TDD、评审、验证三类约束技能；
4. 任务形态决定调度策略：串行用 executing / subagent，解耦并行用 dispatching-parallel-agents；
5. 专项问题专项匹配：调试只用 systematic-debugging、评审整改只用 receiving-code-review、收尾只用 finishing-a-development-branch。