用途
Brainstorming 是一个在实现功能、构建组件或做出改动之前使用的技能，提供有效头脑风暴会议的详细流程知识，用于在深入“如何构建”之前先厘清“要构建什么”。
何时使用
以下情况适合使用头脑风暴：
- 需求不清晰或存在歧义
- 多个方案都能解决该问题
- 需要与用户探讨权衡取舍
- 用户尚未完整表达想要什么
- 功能范围需要细化
以下情况可以跳过头脑风暴：
- 需求明确且详细
- 用户清楚知道自己想要什么
- 任务只是直接的缺陷修复或定义清晰的改动
核心流程
阶段 0：评估需求清晰度
在开始提问前，先评估是否需要进行头脑风暴。
需求清晰的信号：
- 用户提供了具体的验收标准
- 用户引用了可遵循的现有模式
- 用户描述了预期的确切行为
- 范围受限且定义明确
需要头脑风暴的信号：
- 用户使用了模糊措辞（如“让它更好”“加点类似的东西”）
- 存在多种合理解读
- 尚未讨论权衡取舍
- 用户似乎对方案不确定
如果需求清晰，可建议：“你的需求似乎已经清晰，可以考虑直接进入规划或实现。”
阶段 1：理解想法
一次只问一个问题来理解用户意图，避免用多个问题造成负担。
提问技巧：
- 有自然选项时优先使用多选题。例如：“通知应该是：(a) 仅邮件，(b) 仅应用内，还是 (c) 两者都要？”避免问：“用户应该如何被通知？”
- 先宽后窄：先问核心目的是什么，再问用户是谁，最后问存在哪些约束。
- 明确验证假设：“我假设用户会处于登录状态，对吗？”
- 尽早询问成功标准：“你如何判断这个功能运行良好？”
需要探索的关键主题：
| 主题 | 示例问题 |
|---|---|
| 目的 | 这解决什么问题？动机是什么？ |
| 用户 | 谁使用它？他们的使用场景是什么？ |
| 约束 | 有技术限制吗？时间线？依赖项？ |
| 成功 | 如何衡量成功？理想路径是什么？ |
| 边界情况 | 什么不应该发生？需要考虑哪些错误状态？ |
| 现有模式 | 代码库中有类似功能可以遵循吗？ |
退出条件：持续到想法清晰，或用户说“继续”或“我们往下走”。
阶段 2：探索方案
理解想法后，提出 2-3 个具体方案。
每个方案的结构：
方案 A：[名称]
[2-3 句描述]
优点：
- [优点 1]
- [优点 2]
缺点：
- [缺点 1]
- [缺点 2]
最适合： [该方案发挥优势的情形]
指导原则：
- 先给出推荐并解释原因
- 诚实说明权衡取舍
- 考虑 YAGNI——更简单通常更好
- 在相关时引用代码库模式
阶段 3：记录设计
以结构化格式总结关键决策。
设计文档结构：
date: YYYY-MM-DD topic: <kebab-case-topic>
<Topic Title>
What We're Building
[简洁描述——最多 1-2 段]
Why This Approach
[简要说明考虑过的方案以及为何选择此方案]
Key Decisions
- [决策 1]：[理由]
- [决策 2]：[理由]
Open Questions
- [规划阶段尚未解决的问题]
Next Steps
→ /ce:plan 获取实现细节
输出位置：docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
阶段 4：交接
给出清晰的后续选项：
- 进入规划 → 运行 /ce:plan
- 继续细化 → 继续探索设计
- 暂时结束 → 用户稍后再回来
YAGNI 原则
在头脑风暴中主动抵制复杂度：
- 不为假设的未来需求做设计
- 选择能解决所述问题的最简单方案
- 优先使用无聊、经过验证的模式，而非聪明的方案
- 复杂度出现时问“我们真的需要这个吗？”
- 推迟那些现在不必做的决策
增量验证
保持每节简短——最多 200-300 字。每节输出后暂停以验证理解：
- “这符合你原本的想法吗？”
- “继续之前需要调整吗？”
- “这是你想走的方向吗？”
这可以避免在方向不一致的设计上浪费精力。
应避免的反模式
| 反模式 | 更好的做法 |
|---|---|
| 一次问 5 个问题 | 一次问一个 |
| 跳到实现细节 | 聚焦于“要什么”，而非“怎么做” |
| 提出过于复杂的方案 | 从简单开始，仅在需要时增加复杂度 |
| 忽略现有代码库模式 | 先研究已有内容 |
| 未经验证就做假设 | 明确陈述假设并确认 |
| 创建冗长的设计文档 | 保持简洁——细节放到规划中 |
与规划的集成
头脑风暴回答“要构建什么”：
- 需求与验收标准
- 选定的方案与理由
- 关键决策与权衡
规划回答“如何构建”：
- 实现步骤与文件改动
- 技术细节与代码模式
- 测试策略与验证
当头脑风暴输出存在时，/ce:plan 应检测到它并将其作为输入，跳过自身想法细化阶段。