Brainstorming 是一个面向设计阶段的协作式技能，用于在实现开始之前把想法转化为详细的设计规格。它通过苏格拉底式提问与迭代细化，帮助团队建立共识，防止代价高昂的返工。
快速开始
- 理解背景 — 先检查项目，提出澄清性问题
- 探索方案 — 提出 2-3 种方案并说明权衡
- 细化设计 — 逐节验证（每节 200-300 字）
- 文档化 — 把设计写入带时间戳的文件
- 规划 — 可选地创建实现计划
适用场景
- 启动新功能或新项目
- 澄清模糊的需求
- 评估架构决策
- 设计 API 或接口
- 规划复杂实现
- 编写任何重要代码之前
Brainstorming 流程
阶段一：理解
目标：建立对问题空间的完整认识。
做法：
- 先检查项目背景
- 一次只问一个问题
- 条件允许时使用多选题式提问
- 聚焦于目的、约束和成功指标
关键问题：我们在解决什么问题？用户是谁？有哪些约束？如何衡量成功？已经存在什么？
阶段二：探索
目标：识别并评估解决方案思路。
做法：
- 提出 2-3 种不同方案
- 呈现每种方案的权衡
- 给出有依据的推荐
- 保持对话式，而不是命令式
方案模板：
选项 A：[名称]
- 方式：[描述]
- 优点：[收益]
- 缺点：[不利之处]
- 最适合：[场景]
阶段三：设计呈现
目标：形成经过验证的设计规格。
做法：
- 拆分成 200-300 字的段落
- 在继续之前先验证每一节
- 覆盖：架构、组件、数据流、错误处理、测试
- 允许回顾早前的决策
节清单：架构概述（详见子技能获取完整细节）。
关键原则
YAGNI（你不需要它）：严格应用——只设计当前需要的内容，避免推测性功能，质疑每一个“锦上添花”的想法，在必要时才引入复杂度。
每条消息只问一个问题：避免让利益相关者不堪重负，确保每个点都得到处理，保持对话流畅，并允许及时纠偏。
增量验证：逐节验证，获得明确确认，允许反转，在已确认的基础上继续构建。
问题模板
澄清类：
- “为澄清一下：[理解的摘要]。这样对吗？”
- “你说的[术语]是指 (a) [选项1]、(b) [选项2]，还是 (c) 其他？”
权衡探索类：
- “我们可以选择 [A] 或 [B]。[A] 带来 [收益] 但有 [缺点]。[B] 带来 [收益] 但有 [缺点]。对这个项目来说哪个更重要？”
优先级评估类：
- “哪一个更重要：[质量 A] 还是 [质量 B]？”
- “如果必须在 [选项1] 和 [选项2] 之间选择，你更倾向哪个？”
验证类：
- “以下是我对[某节]的理解。这符合你的预期吗？”
- “在继续之前，让我确认一下：[摘要]”
设计之后的动作
验证之后：
文档化
- 把设计写入带时间戳的文件
- 包含所有决策及其理由
- 记录任何推迟的决策
规划（可选）
- 使用 writing-plans 技能进行实现规划
- 把设计拆解为任务
- 估算并排定优先级
评审（可选）
- 与利益相关者分享
- 收集更多反馈
- 纳入修改
相关技能
- writing-plans — 创建实现计划
- sparc-workflow — 开发方法论
- product-roadmap — 产品规划
版本历史
1.0.0（2026-01-19）：首次发布，改编自 obra/superpowers
子技能
最佳实践、错误处理、指标（详见子技能）。