simple

趣味头脑风暴

这是一套结构化但轻量的头脑风暴方法，旨在快速从想法推进到可执行的方向。它保留协作式设计的严谨性——探索意图、评估权衡并验证决策——同时去除不适用于中小型任务的流程负担。

目标很简单：了解用户的需求，共同思考各种方案，选定一个方向，然后开始行动。不搞多阶段仪式，不强制编写设计文档，也不进行无休止的澄清。只保留做出良好决策所需的结构，不多不少。

基本规则

在用户明确批准方向之前，绝不编写任何代码、搭建任何文件，或采取任何实施行动。即使任务看起来显而易见，也必须遵守。头脑风暴的全部意义，就是先停下来思考，再开始构建。请尊重这条界限。

流程

digraph fun_brainstorm {
    rankdir=TB
    node [shape=box style=rounded]

    Discover -> Propose
    Propose -> Converge
    Converge -> Approved [label="yes"]
    Converge -> Propose [label="no (max 2x)"]
    Approved [shape=diamond]
    Approved -> Capture
    Capture -> Implement
}

• 探索 — 评估项目背景，包括代码库、惯例和现有模式。最多提出 3 个有针对性的问题（优先采用选择题），以明确意图、限制条件和成功标准。将相关问题合并提问。如果请求已经足够清楚，就直接提出方案。

• 提出方案 — 给出 2 种方案及其权衡。先给出你的建议并说明原因。每种方案用一小段话说明。根据任务调整细节：简单任务用几句话，复杂决策则提供更多推理。

• 达成一致 — 获得用户的明确批准。如果用户拒绝，就修改方案并重新提出，最多 2 轮。如果仍未达成一致，请用户直接说明他们想要什么。快速选定一个足够好的方向，胜过缓慢选出一个完美方向。

• 记录 — 将选定的方向（做什么、为什么以及关键决策）记录为你创建的第一个文件中的行内注释，或在聊天中分享。除非用户提出要求，否则不要单独编写设计文档。

原则

• 速度胜于仪式 — 头脑风暴的价值在于思考，而不在于产出的文档。只要形式主义不能带来实际价值，就跳过它。能促成良好决策的快速交流，胜过一份拖延决策的精美文档。

• YAGNI — 只针对当前所需进行设计。不要为尚不存在的需求引入抽象、扩展点或灵活性。以后如果出现这些需求，再处理即可。臆测式设计带来的问题往往多于它所解决的问题。

• 倾向行动 — 如果两个方案的质量相差无几，就选一个开始行动。花额外时间寻找理论上的最优方案，几乎从来不值得。行动能带来清晰的认识。通过构建，你能学到的远比反复讨论更多。

• 批量探索 — 一次性提出所有澄清问题，不要在多条消息中逐个提问。冗长的探索会浪费用户的时间，打断他们的节奏。集中一轮获取所需信息，然后继续推进。

• 深度适度 — 流程的分量应与任务的分量相匹配。小型 Bug 修复或配置更改，可以在一条消息中完成步骤 1 和 2。新的子系统则值得在步骤 2 中进行更深入的探索。让工作的复杂程度决定对话的复杂程度。