brainstorming

用途

Brainstorming 是一个在实现功能、构建组件或进行修改之前使用的技能，目标是在进入“如何做”（HOW）之前，先澄清“要做什么”（WHAT）。它通过结构化的流程，帮助梳理用户意图、可能方案与设计取舍。

何时使用

该技能在以下情况有价值：

需求不清晰或含糊
同一问题存在多种可行方案
需要与用户一起探索取舍
用户尚未完整表达想要什么
功能范围需要细化

以下情况可跳过：

需求明确且详细
用户清楚知道自己想要什么
任务只是简单的缺陷修复或定义清晰的改动

核心流程

阶段 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

→ /workflows:plan 获取实现细节

输出位置：docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

阶段 4：交接

呈现下一步的明确选项：

进入规划 → 运行 /workflows:plan
继续细化 → 继续探索设计
暂时结束 → 用户之后会回来

YAGNI 原则

在头脑风暴期间，主动抵制复杂度：

不为假设的未来需求做设计
选择能解决既定问题的最简单方案
优先选择无聊、经过验证的模式，而不是聪明的解法
当复杂度出现时问“我们真的需要这个吗？”
推迟不需要现在做出的决定

增量验证

保持每节简短——最多 200-300 字。每输出一节后暂停以验证理解：

“这符合你的想法吗？”
“继续之前有什么要调整的吗？”
“这是你想走的方向吗？”

这可以避免在方向不一致的设计上浪费精力。

应避免的反模式

反模式	更好的做法
一次问 5 个问题	一次问一个
跳到实现细节	专注于 WHAT，而不是 HOW
提出过于复杂的方案	从简单开始，只在需要时增加复杂度
忽略现有代码库模式	先研究已有内容
未验证就做假设	明确说明假设并确认
创建冗长的设计文档	保持简洁——细节留在计划中

与规划阶段的集成

头脑风暴回答要构建什么：

需求与验收标准
选定的方案与理由
关键决策与取舍

规划回答如何构建：

实现步骤与文件改动
技术细节与代码模式
测试策略与验证

当头脑风暴输出存在时，/workflows:plan 应能检测到并将其作为输入，跳过自身的想法细化阶段。