## `superpowers`：重点使用 `brainstorming` 与 `test-driven-development` `superpowers` 不是一个单独技能，而是一组可组合的方法库。 这本书只保留两个最适合通用开发协作的子技能： - `brainstorming` - `test-driven-development` 不展开完整技能目录，只讲这两个子技能在研发协作里的位置。 开源仓库：[`obra/superpowers`](https://github.com/obra/superpowers) ```text 这次不要把 `superpowers` 当成一个大而全的技能包。 只使用两个子技能： 1. 需要比较多条路线时，用 `brainstorming` 2. 进入实现和回归时，用 `test-driven-development` ``` ### `superpowers` 应该怎么理解 `superpowers` 更像一个方法库，而不是一个应该整包无差别挂到每个 Agent 身上的默认技能。 这套能力的真正价值，不在于“什么都能做一点”，而在于把其中少数真正高频、且能提升研发稳定性的做法抽出来，放到正确的阶段使用。 在这本书里，最值得保留的就是： - 方案发散阶段的 `brainstorming` - 实现与回归阶段的 `test-driven-development` ### 方案发散阶段：`brainstorming` `brainstorming` 更适合放在需求理解、原型和方案设计阶段。 它的价值不是直接给出最终答案，而是铺开多个备选路线，帮助团队比较： - 哪条路线实现成本更低 - 哪条路线风险更小 - 哪条路线和当前上下文更匹配 - 哪条路线最适合当前团队能力与时间窗口 这一步的产物不应该直接被当成定案，而应该作为下一步 spec、plan 或人工决策的输入。 ### 实现与回归阶段：`test-driven-development` `test-driven-development` 更适合放在实现、修复和回归阶段。 它的作用是： - 先明确行为和预期 - 再写验证 - 然后落实现 - 最后用测试保护既有行为 从协作角度看，它的价值不仅是保证代码质量，也能把实现与验收之间的关系变得更明确。团队不会只讨论“代码写完没有”，而会讨论“行为是否被验证覆盖”。 ### 如果已经有 Planner / Worker 分工 如果团队已经采用 Planner 和 Worker 分工： - Planner 更适合使用 `brainstorming` - Worker 更适合使用 `test-driven-development` 这是因为两者面对的问题本来就不同： - Planner 需要展开和比较路线 - Worker 需要把确定路线落成可验证实现 ### 为什么不能把它写成泛泛的大包能力 如果把 `superpowers` 写成泛泛的“研究、搜索、证据收集能力”，页面会失焦，也不利于团队默认接入。 真正需要强调的是： - 什么时候用 `brainstorming` - 什么时候用 `test-driven-development` - 它们分别服务于哪个阶段、哪类角色和哪种交付目标 只有把阶段和职责绑定清楚，这组方法才会真正进入团队默认工作流。 | 子技能 | 更适合的阶段 | 主要作用 | | --- | --- | --- | | `brainstorming` | 需求、原型、方案设计 | 展开备选方案，帮助选择方向 | | `test-driven-development` | 实现、修复、回归 | 用测试约束实现，用验证保护旧行为 | 如果当前项目缺少基本测试基础设施，`test-driven-development` 的收益会受限；这时团队应先补最小测试闭环，而不是只把名称写进流程里。 `brainstorming` 产生的是候选方案，不是最终定案；高影响路线仍然需要人工拍板。 `test-driven-development` 能否发挥作用，取决于当前仓库是否具备可运行的测试基础设施。 读完本章后，读者应该能明确区分：`brainstorming` 用于方案发散，`test-driven-development` 用于实现与回归，它们不应被混写成一个泛化的大包能力。