simple

趣味头脑风暴

一个结构化但轻量级的头脑风暴技能，旨在快速从想法过渡到可执行的方向。它保留了协作设计的严谨性——探索意图、评估权衡、验证决策——同时消除了不适合中小型任务的过程开销。

目标很简单：理解用户想要什么，一起思考选项，选择一个方向，然后开始行动。没有多阶段仪式，没有强制设计文档，没有无休止的澄清轮次。只有足够做出好决策的结构，仅此而已。

基本规则

在用户明确批准方向之前，不要编写任何代码、搭建任何文件或采取任何实现行动。即使任务看似显而易见，也要遵守。头脑风暴的全部意义在于在构建之前暂停并思考。请尊重这一界限。

流程

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

    Discover -> Propose
    Propose -> Converge
    Converge -> Approved [label="是"]
    Converge -> Propose [label="否（最多2次）"]
    Approved [shape=diamond]
    Approved -> Capture
    Capture -> Implement
}

• 发现 — 评估项目上下文——代码库、约定、现有模式。提出最多3个聚焦的问题（优先选择题）以澄清意图、约束和成功标准。将相关问题合并提问。如果请求已经明确，直接跳到提议。

• 提议 — 提出2种方法并说明权衡。先给出你的推荐并说明原因。每个选项保持简短段落。根据任务调整细节——简单工作几句话，复杂决策更多推理。

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

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

原则

• 速度优先于仪式 — 头脑风暴的价值在于思考，而不是产生的工件。在不能增加实际价值的地方省略形式。能带来好决策的快速对话胜过延迟决策的精美文档。

• YAGNI — 只为当前需要而设计。不要为尚不存在的需求引入抽象、扩展点或灵活性。如果以后出现，到时候再处理。投机设计带来的问题比解决的问题多。

• 偏向行动 — 当两个选项质量相近时，直接选一个并继续。花额外时间试图找到理论上最优的选择几乎不会带来回报。行动创造清晰。从构建中学到的比从深思中更多。

• 批量发现 — 将你的澄清问题一起提出，而不是在多个消息中逐个提出。拖沓的发现会浪费用户的时间并打断他们的思路。一轮获取所需信息，然后继续前进。

• 比例深度 — 让过程的重量与任务的重量相匹配。一个小错误修复或配置更改可能在一个消息中完成步骤1和2。一个新子系统需要在步骤2中进行更彻底的探索。让工作的复杂性引导对话的复杂性。