grill

name	grill
description	针对 PRD 需求中的不确定点逐条提问对齐。在 dev-flow 流程的第 2 步自动加载。
version	2.1.0

grill me · 提问方法论

你的任务

针对 PRD 需求中模糊、缺失、有歧义的部分，沿着决策树逐条向用户提问，直到所有关键不确定点都对齐。

核心方法：决策树遍历

不要按维度平铺提问，而是把 PRD 看作一棵决策树：

PRD
├── 决策 A：数据存在哪？
│   ├── 决策 A1：用新表还是复用旧表？
│   └── 决策 A2：字段如何设计？
├── 决策 B：接口怎么暴露？
│   ├── 决策 B1：新增接口还是扩展现有接口？
│   └── 决策 B2：参数格式？
└── 决策 C：UI 如何呈现？
    └── 决策 C1：字段顺序和默认值？

遍历规则：

1. 先识别所有决策分支：读完 PRD 后，列出所有需要做出的决策
2. 按依赖关系排序：先解决前置决策（被其他决策依赖的节点）
3. 逐个向下走：每次只问一个问题，等用户回答后再问下一个
4. 回答可能揭示新分支：用户的回答可能引出新的决策节点，动态加入树中

提问原则

1. 先推荐，再确认：每个问题先给出你的推荐答案和理由，再让用户确认或修改

   我的建议：用新表 `user_preferences` 存储，理由是...
   你觉得这样可以吗？还是有其他考虑？
   

2. 一次只问一个问题：并行抛出多个问题会让用户混乱。问完一个，等回答，再问下一个。

3. 先查答案来源，再问用户：能查到答案的问题不要问用户。

   • 视觉规格问题（列归属/合并、按钮文案、所在页签、筛选位置、字段顺序）先回 PRD 内嵌截图/原型逐元素核对——图里已标注的按图定死，不当问题问、也不自拟。
   • 实现问题（字段/数据是否已存在等）先用 Glob/Grep/Read 查代码库，查到就直接用。

4. 给出判断依据：推荐答案要说明为什么，不要只说"我建议 X"，要说"我建议 X，因为 Y"。

5. 标记缺口：仅当 PRD 正文和截图/原型都未给出时才算真缺口——标为「缺口」、说明临时方案、继续推进。PRD 图里已标注的位置/文案不是缺口，直接按图定稿（与 tech-plan「图已定 vs 真待确认」一致）。

提问维度（辅助参考）

决策树遍历是主方法，以下维度帮助你在遍历中发现遗漏的决策节点：

维度	典型决策点
边界条件	空值怎么处理？最大/最小值？超限怎么办？
依赖关系	依赖哪个表/接口/其他任务？先后顺序？
存储结构	数据存在哪？新表还是复用？字段设计？
UI 细节	字段折进已有列还是独立列？按钮/入口文案是否与 PRD 图逐字一致？入口挂哪个已有页签（是否误建新页签）？筛选放哪、与谁并列？字段顺序？默认值？交互方式？空状态？
异常处理	失败怎么提示？重试？回滚？
数据迁移	有存量数据吗？需要迁移吗？
性能	数据量多大？需要分页？有并发问题？
兼容性	需要兼容旧版本吗？接口变更？

提问方式

使用 AskUserQuestion 工具：

问题：<具体决策问题>
选项 A：<你的推荐方案>（附理由）
选项 B：<备选方案 1>
选项 C：<备选方案 2>

提问流程

1. 读完 PRD 后，画出决策树（列出所有决策节点和依赖关系）
   ↓
2. 从根节点开始（最不依赖其他决策的节点）
   ↓
3. 每个节点：先推荐 → 问用户 → 记录回答
   ↓
4. 回答可能揭示新节点 → 动态加入决策树
   ↓
5. 所有节点遍历完毕 → 检查是否有遗漏维度
   ↓
完成 → 进入步骤 3（问答记录）

与领域建模协同

在提问过程中，同步构建领域词汇表。这是 grill 的伴随纪律，不是独立步骤。

术语挑战

当用户使用的术语与已有定义冲突时，立即指出：

你说"取消订单"，但术语表里"取消"的定义是"用户主动撤销未支付的订单"。
你现在说的是"退款"（已支付订单的逆向操作），还是真正的"取消"？

锐化模糊用语

当用户使用模糊或 overloaded 的术语时，追问精确含义：

你说"账户"——这里指的是 Customer（客户实体，包含基本信息）
还是 User（登录账户，包含凭证信息）？这两个在系统里是不同的东西。

场景压力测试

当领域关系被讨论时，用具体场景验证边界：

如果订单已经发货，用户还能"取消"吗？
如果"取消"不行，那叫"退货"？退货和取消在系统里是同一个操作还是不同操作？

术语表输出

grill 完成后，将所有记录的术语输出到 <session_dir>/术语表.md：

# 术语表

> 记录日期：<日期>
> 范围：<本次涉及的任务列表>

## 术语定义

| 术语 | 定义 | 相关术语 | 备注 |
|------|------|---------|------|
| Customer | 客户实体，包含姓名、手机号等基本信息 | User, Order | 一个 Customer 可以有多个 User |
| User | 登录账户，包含账号、密码、状态 | Customer | 与 Customer 一对一关联 |

## 已解决歧义

- "账户"统一指 User（登录账户），Customer 不用"账户"称呼
- "取消"只用于未支付订单，已支付订单的逆向操作叫"退货"

## 待确认

- <暂时无法确定的术语定义>

注意：术语表不含实现细节（不写文件路径、字段名、表结构），只记录 grill 过程中真正讨论过的术语。

注意事项

• 如果用户说「你自己判断」，给出你的建议方案并记录，不反复追问
• 不要纠结于小问题，先确保大方向正确
• 如果需求文档已经足够清晰，可以快速过一遍确认，不需要强行提问
• 用户的回答可能推翻之前的理解，及时调整决策树