grill-with-prd · diff
git:20261013.60e8978 to git:20261013.be4849d
9 added, 0 removed. Audit A to A.
---
name: grill-with-prd
description: 针对 PRD 文档的逐项审查会话,挑战需求的完整性、一致性和可实现性,并将确认的决策同步回 docs/prd/{feature-name}/prd.md。适用于用户想在开始实现前压测 PRD 的场景。
---
<要做什么>
逐一追问 PRD 中的每个需求和决策,直到双方对功能边界、实现路径和验收标准达成共识。每个问题等用户回答后再继续,不一次性抛出所有问题。
如果某个问题可以通过探索代码库来回答,先探索代码库,不要把它抛给用户。
</要做什么>
<支撑信息>
## PRD 文档位置
PRD 文件路径:`docs/prd/{feature-name}/prd.md`
开始前先读取对应的 PRD 文件。如果用户没有指定 feature-name,询问后再继续。
## 审查会话中的行为
### 挑战模糊需求
遇到含糊的用户故事或需求描述时,要求精确化。
> "你说'用户可以管理订单'——管理包含哪些操作?创建、编辑、取消、删除都有吗?"
### 追问边界条件
对每个核心功能,主动构造边界场景来压测需求是否完整。
> "支付失败时,订单状态如何变化?用户能重试吗?重试次数有限制吗?"
### 发现需求冲突
当 PRD 中不同部分存在矛盾时,立刻指出。
> "用户故事第 3 条说用户可以删除草稿,但实现决策里说所有操作都需要审计日志——删除操作也要记录吗?"
### 对照代码库验证
当用户描述某个功能的工作方式时,检查代码库是否与之一致。发现矛盾时明确指出。
> "你说用户登录后会话有效期是 7 天,但代码里的 token 过期时间是 24 小时——以哪个为准?"
### 追问范围外的内容
PRD 的"范围外"部分如果过于简略,追问是否遗漏了重要的排除项。
> "范围外只写了'不支持批量操作',权限管理呢?这个功能需要区分角色吗?"
### 确认验收标准
对每个用户故事,确认是否有明确的验收标准,否则无法判断实现是否完成。
> "这条用户故事没有验收标准——成功的定义是什么?有性能要求吗?"
## 同步更新 PRD
当某个决策在审查中被确认或修正时,立刻更新 PRD 文件,不要攒到最后批量写。
更新范围包括:
- 补充遗漏的用户故事
- 精确化模糊的需求描述
- 补充边界条件的处理方式
- 修正前后矛盾的内容
- 更新实现决策
- 补充或修正范围外的内容
每次更新后告知用户修改了哪里。
+ ## 没有人在旁边回答时(自答模式)
+
+ 做演示或回归时,可以自己扮演回答方走完一轮:
+
+ - 每个问题自己给出结论,但回写 `prd.md` 时标注该结论是**自答**的,不要伪装成用户确认。
+ - **矛盾、冲突、缺失的验收标准这三类照常报出来**——那正是要压测的东西。自答不等于放行。
+ - 需要业务拍板的(范围取舍、优先级、价格、对外口径)即使自答也要留在「待决问题」里,写明归属人。
+ - 交付时把「自答」的部分单独列一遍,让用户一眼看出哪些结论还没经过真人确认。
+
## 审查结束
当所有主要分支都已追问完毕,且 PRD 已更新到位时,总结本次审查的主要变更,并告知用户 PRD 已可以交付实现。
</支撑信息>