如何在实际研发中合理选择与匹配 Superpowers 技能
一、先明确核心选型原则
- 按研发阶段自动锚定基础技能
Superpowers 本身具备阶段式自动触发，优先遵循原生工作流；仅在复杂、高风险、定制化场景下手动追加指定技能，避免过度启用冗余能力。 - 按代码风险等级收紧约束型技能
核心业务、支付、鉴权、中间件逻辑：强制绑定test-driven-development、requesting-code-review、verification-before-completion；
工具类、配置类、边缘脚本：可适度简化流程，仅保留核心必备技能。 - 按任务耦合度选择执行调度技能
强依赖、串行流程 → 选用executing-plans/subagent-driven-development；
完全解耦、多任务并行 → 选用dispatching-parallel-agents。 - 按问题类型匹配专项技能
新增需求用设计类技能、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 自定义技能、修改内置规则、增加团队校验标准时使用，日常业务开发无需启用。
三、快速选型决策表
| 工作场景 | 核心首选技能 | 备选/配套技能 |
|---|---|---|
| 模糊需求/架构设计 | brainstorming | writing-plans |
| 串行小功能开发 | executing-plans | TDD、代码评审 |
| 大型复杂功能 | subagent-driven-development | git-worktrees、全流程校验 |
| 批量独立组件 | dispatching-parallel-agents | TDD、并行任务拆分 |
| Bug/异常/线上问题 | systematic-debugging | git-worktrees、验证校验 |
| 代码重构/逻辑优化 | test-driven-development | systematic-debugging |
| PR 评审意见整改 | receiving-code-review | 回归验证 |
| 开发交付 & 分支合并 | finishing-a-development-branch | 全量测试 |
四、避坑：技能选型常见错误
- 过度启用并行技能
有依赖、强时序的任务强行使用dispatching-parallel-agents，会导致上下文缺失、逻辑错乱。 - 跳过 brainstorming 直接编码
需求未澄清就开始开发，会放大 AI 主观臆断问题，造成大量返工。 - 修复 Bug 不使用 systematic-debugging
仅做表面热修复，无法根除根因，引发重复问题。 - 重构场景省略 TDD
无测试兜底的重构，极易引发隐性业务逻辑变更。 - 提前执行收尾技能
未完成测试、评审就执行finishing-a-development-branch，导致脏代码流入主干。
五、总结
- 常规业务开发，优先依赖 Superpowers 原生自动触发链路，无需手动干预技能；
- 按「设计→开发→调试→评审→交付」五个阶段分段选型，每个阶段只启用对应域的技能；
- 高风险代码强绑定 TDD、评审、验证三类约束技能；
- 任务形态决定调度策略：串行用 executing / subagent，解耦并行用 dispatching-parallel-agents；
- 专项问题专项匹配：调试只用 systematic-debugging、评审整改只用 receiving-code-review、收尾只用 finishing-a-development-branch。
浙公网安备 33010602011771号