design-grill

name	design-grill
description	用于把尚未清晰的想法、新需求、产品/交互/技术方案、实现计划等收敛成可执行设计。适用于从零到一或尚未定型的讨论、需求澄清、方案取舍和设计记录草拟等

Design Grill

目标

把模糊请求推进成清晰、可执行、可记录的设计决策。默认先理解上下文并提出候选方案，再只询问会实质改变方向的问题。

决策树原则

Design Grill 把计划视为一棵决策树，而不是一份扁平的问题清单。

• 每个未决的设计选择都是一个 decision node。
• 有些节点是父节点：它的答案决定了哪些子决策相关。会话必须先解决父决策，再展开依赖它的子决策，避免过早讨论被父决策否决的细节。
• 目标不是"尽快达成一致"，而是把每一个隐式决策（implicit call）显式化——任何重要取舍都不能被悄悄假设或默认。
• 一条分支只有处于以下状态之一时才算处理完毕：
  • confirmed（已确认）
  • rejected（已否决，含理由）
  • deferred（明确延期，含延期到什么时机）
  • irrelevant（被更早的决策排除，含被哪个决策排除）

工作流

1. 扫描上下文

提问前检查可用上下文：

• 读取相关 README、docs、spec、issue、设计稿、代码等。
• 避免询问能从上下文中直接发现的事实；能自己读出来的，去读，不要问。

2. 判断规模

• Small：单个决策、单个组件、简单流程或内容边界。必要时问少量问题，然后给出建议。允许一次抛出 2-3 个轻量问题。
• Medium：一个完整功能或一组相关取舍。默认一轮一个关键决策节点，等待回答后再继续。
• Large：多角色、多模块、多流程、多系统或高风险上线。先给决策树地图，再逐节点收敛。

复杂度不明时，先按 Medium 处理，并在用户回答后调整。当规模与"一轮一个节点"冲突时，偏向后者——宁可多轮，也不要一次抛出一批让人眼花的问题。

3. 构建决策树

为 Medium 及以上设计构建轻量决策树：

Proposed decision tree:
- Root decision: <最基础、会改变一切下游的取舍>
  Status: open / confirmed / rejected / deferred / irrelevant
  Recommended answer: ...
  Why it matters: ...
  Child decisions unlocked if confirmed:
    - <子决策 1>
    - <子决策 2>
- Cross-cutting decision: <与根决策无关、横切的取舍>
- Deferred decision: <可等到实现细节需要时再定的>

构建时：

• 找出根决策——那个一旦定下就会锁定或排除一大批下游选项的取舍。
• 标注父子依赖：哪些子决策只有在某个父决策被确认后才相关。
• 选定能降低依赖风险的遍历顺序：父决策优先。

4. 遍历决策树（一轮一个节点）

按依赖顺序逐节点推进。默认行为：

• 一个决策节点一次：抛出当前最关键的未决节点，等待用户回答，再继续。
• 每个问题都带 agent 自己的推荐答案——用户是对默认建议做反应，而不是从空白处思考。
• 用户回答后，立即更新决策树：标注 confirmed / rejected / deferred / irrelevant，并展开新解锁的子决策。
• 当某个父决策被否决或排除时，主动把它下游的 irrelevant 分支一起剪掉，不要逐个再问。

每个决策节点的问题应包含：

• Context：问题的背景，携带足够上下文方便用户理解。
• Impact：答案会改变设计的哪一部分 / 解锁或排除哪些子决策。
• Options：2-4 个具体选项，并说明取舍。
• Recommendation：如果有清晰默认值，标明推荐项及理由。
• Free-form escape hatch：允许用户混合选项或提出自己的答案；作为菜单展示时要包含明确的自定义输入选项。

有帮助时使用回答代码，例如 1A, 2C, 3B，方便用户快速回复。

问题模板：

1. **决策节点主题**
   Context: We need to decide this because...
   Impact: Your answer determines...
   Options:
   A. Option one - best when...
   B. Option two - best when...
   C. Option three - best when...
   D. 自定义输入 - 如果以上都不合适，可以混合想法或提出自己的方案
   Recommendation: B, because...

5. 压力测试与剪枝

用户回答后，识别：

• 已确认的决策（标注 confirmed）。
• 仍需明确的假设。
• 回答之间的冲突。
• 范围膨胀、隐藏成本、边界情况和失败路径。
• 被排除的分支（标注 irrelevant 并注明被哪个决策排除）。
• 应延期或明确不做的内容（标注 deferred 并注明延期时机）。

每轮结束后回写决策树状态，不要让任何分支停留在"差不多清楚了"。

6. 维护运行中的决策树状态

中型、大型、多轮或高风险讨论中，定期维护状态：

Current decision tree state:
- Confirmed:
  - <决策节点>: <结论>
- Rejected:
  - <决策节点>: <被否决，因为...>
- Deferred:
  - <决策节点>: <延期到...>
- Irrelevant:
  - <决策节点>: <被 <某决策> 排除>
- Open:
  - <决策节点>: <待定，推荐答案...>
- Current node: <当前正在收敛的节点>
- Recommended next step: <下一个要展开的节点>

小型讨论可以只给简短总结。

退出标准

停止提问的判据不是"剩余未知不会显著改变设计"，而是：

• 关键决策树已遍历：根决策与所有重要分支都已被访问。
• 剩余分支已明确处置：每一条都已标注为 confirmed / rejected / deferred / irrelevant，没有悬而未决的隐式假设。
• 满足上述两点后，用显式假设继续，并把假设与延期项写进状态。

最终设计记录

只有在以下情况才写或更新设计记录：

• 用户明确要求生成文档。
• 讨论已经多轮，且需要交接或后续执行。
• 设计影响较大、风险较高，或涉及发布/迁移/跨团队协作。
• 优先遵循仓库已有文档规范。没有约定时使用：docs/designs/YYYY-MM-DD--topic.md

设计记录必须区分：

• 已确认决策（confirmed）。
• 当前假设。
• 被拒绝方案及原因（rejected）。
• 延期项及延期时机（deferred）。
• 开放问题（open）。
• 推荐下一步。