方案头脑风暴

目标：和用户把模糊需求聊到双方理解一致，写成用户批准的 Spec，再交给 plan。这里不写生产代码，也不写执行计划。

提问

把需求看成一棵决策树：每个决策下面挂着依赖它的决策。前置已经定了、现在就能回答的决策，是这一轮要问的全部问题。

• 每轮把这些问题编号，在一条消息里问完，每题附 ➡️ 推荐答案，措辞让用户答「同意」就等于采纳推荐。一次问完让用户在同一个上下文里权衡，比逐题拉锯省时间。
• 依赖本轮其他问题答案的题留到下一轮。用户答复后重算还没定的决策，再问下一轮；新答案推翻了之前的判断时，照实重开受影响的分支。
• 事实自己查，需要时派子代理去查，不问用户；查证进行中时只有依赖它的题等待，其余照常问。偏好、取舍、范围和验证力度是决策，提出来并等用户答复——替用户定决策，Spec 记录的就成了你的选择而不是用户的。
• 先问方案。候选方案之间要有机制、边界或数据形态上的真实差异，各写清取舍；成功标准和验证方式取决于选了哪个方案，方案定了再问。
• 要看到东西才能答的问题（形态、手感、布局）不硬谈：做一个一次性 spike（单文件 demo、线框、脚本）只回答这一题，看完即弃，结论一句话带回对话。
• 用户用词和项目已有术语冲突时当场指出并统一；项目有词汇表（如 CONTEXT.md）时把定下的术语写进去。只有难以逆转、没上下文的人会意外、且确有取舍的决定，才提议写 ADR。
• 用户要求一次一题时改为逐题问，决策树照常维护。

每个分支都要落定：用户答过、用户明确豁免，或能从仓库证实。常识默认、业界惯例或「以后再说」不算落定，它们正是静默假设藏身的地方。

深度

深度由用户说，没说就用中档，用户随时可以改。首轮提问时顺带说明当前用的是哪一档，方便用户改。档位只改变方案空间的宽度和追问的力度，不设轮数。

• 低档：推荐方案加一个备选，少打扰，但每个决策仍等用户确认。
• 中档：2–3 个有结构差异的方案；只有一条明显路径时改成确认题，并记下考虑过的备选。
• 高档：用于卡在瓶颈或需要创新时。先问清突破后要到哪里、试过什么、各自为何失败；候选里至少有一个非显然或跨领域的方案；候选素材先查证；每个落选方案写明落选理由。

Spec

还没定的决策清空、用户确认双方理解一致后，按 references/spec-drafting.md 写 Spec：中文用户用 templates/spec.zh-CN.md，其他用 templates/spec.md，默认路径 docs/specs/YYYY-MM-DD--<topic>.md。Spec 只记录对话里已定的方案和落选理由，不替用户做没聊过的选择。写完按 references/spec-review-checklist.md 自审，再请用户批准。

沉默或「听起来不错」不等于批准，没有明确批准不进入 plan。批准后交给 plan；用户放弃时删掉未批准的 Spec 草稿并结束。