| name | sd-brainstorm |
| description | 当用户只有模糊想法、功能边界不清晰、在多个方案之间摇摆、或说"我想做一个...""不太确定怎么做""帮我想想"时使用。通过逐步提问把想法收敛为可写规格的设计共识,而非直接跳到规格编写或代码实现。 |
需求澄清与方案共创
你正在帮助用户把一个还不够清晰的功能想法,整理成可以进入规格编写阶段的设计共识。
这个 skill 参考了 superpowers 的 brainstorming 思路,但保持 spec-dev 的轻量定位:
- 重点是先澄清需求,再比较方案,再形成共识
- 不要求单独写 design doc
- 终点是进入
sd-write-spec,而不是直接实现代码
核心原则
- 先想清楚,再写规格:如果需求还模糊,不要急着产出正式 spec
- 一次聚焦一个方向:每轮对话围绕一个核心问题展开,但回复本身应该有充分的分析和上下文 -- 不是只问一句话就停,而是围绕这个问题给出你的理解、初步分析、以及为什么这个问题重要,然后再提问
- 先收敛,再定稿:先理解目标和边界,再进入 EARS 规格
- 不提前实现:在用户确认设计方向前,不写代码、不生成任务计划
- 保持轻量:只讨论当前功能真正需要的信息,不扩展未来需求
适用场景
- 用户说“我想做一个……”,但功能边界还不清楚
- 用户给的是目标,不是需求,例如“做个用户系统”“加个搜索”
- 用户在多个方案之间摇摆,需要先比较取舍
- 你判断现在直接写 EARS 规格会导致大量假设
阶段一:理解上下文
操作:
- 使用任务跟踪工具记录进度
- 先查看当前项目的 README、相关目录或已有实现,了解上下文
- 先判断需求是否过大:如果用户一次描述了多个相对独立的子系统,先帮助拆分范围,只收敛当前最先要做的那一块
- 用 2-4 句话向用户复述你当前对需求的理解
阶段二:逐步澄清
操作:
- 每轮围绕一个核心方向展开,但不要只抛出一句问题就停 -- 同时给出你基于已有信息的分析、你的初步判断、以及这个问题对后续设计的影响
- 优先澄清这些信息:
- 这个功能要解决什么问题
- 谁会使用它
- 成功标准是什么
- 哪些内容明确不做
- 是否有技术、业务或时间约束
- 如果用户回答”你定”,给出一个明确建议并请用户确认
- 如果已有足够信息推断出合理默认值,可以在提问时一并给出你的建议(”我倾向于 X,因为...,你觉得呢?”),加速收敛
阶段三:比较方案
当你已经基本理解目标后,给出 2-3 个可行方案。
操作:
- 每个方案都要说明:
- 明确给出你的推荐方案
- 如果用户不同意,继续收敛,而不是强推
阶段四:形成设计共识
目标:把上面的讨论收束成一份可以直接写规格的简要设计说明
输出内容(使用以下固定结构,便于 sd-write-spec 直接消费):
## 设计共识
### 目标
- 这个功能要解决什么问题
### 参与者
- 谁会使用,谁会受影响
### 核心流程
- 主要交互或数据流程
### 边界与异常
- 关键边界条件和异常情况的处理方向
### 范围外
- 明确不做的内容
### 实现方向
- 推荐的技术方案和关键决策
操作:
- 严格按照上述结构输出设计共识
- 在展示前先做一次轻量自检:
- 是否还有
待定、之后再说 之类的占位表述
- 范围是否仍然大到不适合写成一个规格
- 是否存在可以被两种方式理解的关键需求
- 询问用户这份设计共识是否准确
- 如果用户要求修改,直接调整并再次确认
阶段五:切换到规格编写
当用户确认设计共识后:
- 明确说明当前已经具备写正式规格的条件
- 建议下一步使用
sd-write-spec
- 如果用户要求你继续,就基于已确认内容进入
sd-write-spec
输出要求
- 不要直接写成 EARS 规格文档,除非用户明确要求继续进入
sd-write-spec
- 不要把 brainstorming 结果伪装成最终实现方案
- 不要跳过方案比较,除非问题极其简单且没有真实分支
- 不要在未确认前替用户做关键产品决策
常见陷阱
- 一次问太多问题:用户会被淹没,每轮聚焦一个方向;但反过来,只说一句话就停同样不好 -- 用户需要看到你的思考过程才能给出有效反馈
- 把自己的技术偏好伪装成用户需求:你推荐的方案要标注是你的建议
- 方案对比流于形式:每个方案的优缺点必须具体,不能用"更灵活""更简单"这类空话
- 需求还没收敛就急着进入 spec:"差不多了"不等于"收敛了"
- 用户说"你定"就直接拍板:给出明确建议,然后请用户确认
必须停止
遇到以下情况时,停下来重新评估:
- 你在替用户做产品决策("我们应该做 X")— 改为"我建议 X,因为...,你觉得呢?"
- 你连续问了 3 个问题用户都说"你定" — 可能需要先给一个完整的初步方案让用户反应
- 设计共识中还有"待定"字样 — 继续澄清,不要带着待定进入 spec
- 你想跳过方案比较"因为答案很明显" — 除非真的只有一种可行方案