requirement-clarify · diff
git:20261013.be4849d to git:20261013.447718f
48 added, 0 removed. Audit A to A.
---
name: requirement-clarify
description: 在写 PRD 之前，用采访的方式把一句模糊需求补成可以落笔的完整输入。逐个问清目标角色、触发场景、范围、明确不做的部分和已知约束，产出 docs/prd/<feature-name>/clarify.md。适用于需求还停留在口头、聊天记录或一句话描述，或需求来源方只讲了「要什么」没讲「边界在哪」的情况；不用于评审已成文的 PRD（那一步用 grill-with-prd）。
---
# 需求澄清
把「一句话需求」采访成可以写 PRD 的输入。需求不完整时，AI 不会停下来问，它会按自己的理解补全——所以缺口必须在落笔前问出来。
## 使用边界
- **适用**：需求还停留在口头、聊天记录或一句话描述；需求来源方（老板、业务方、客户）讲清了「要什么」，但没讲边界在哪。
- **不适用**：需求已经完全明确，直接落文档 → 用 `prd-write`；已有充分上下文，不需要采访 → 用 `context-to-prd`。
### 与 `grill-with-prd` 的区别（重要，两者不重复）
| | 本 Skill | `grill-with-prd` |
|---|---|---|
| 时点 | PRD **成文之前** | PRD **成文之后** |
| 方式 | **建设式**采访——把缺的信息补齐 | **对抗式**压测——逐条质疑已有文档 |
| 产出 | `clarify.md`（喂给写 PRD 的那一步） | 直接写回 `prd.md` |
两者不能互相替代：没有 `clarify.md` 就打不出有质量的 PRD；没有 `grill-with-prd`，写出来的 PRD 边界仍然是虚的。
## 开始前
1. 确定功能名，使用短横线格式的 `<feature-name>`；目标目录 `docs/prd/<feature-name>/`。
2. **先查代码库，再问人**。能从现有代码、已有 PRD、`docs/product/` 下的体验基线里查到答案的，不要拿去问用户——问已知的事会消耗掉对方的耐心。
3. 把用户已经说过的内容整理成一份「已知」清单，采访从「已知」之外的地方开始。
## 采访规则
- **一次只问一个问题**，等用户回答后再问下一个。不要一次抛出一串问题。
- 每个问题都给出**你推测的默认答案**，让用户确认或纠正。这比开放式提问快得多，也更容易问出真实边界。
- 用户答不上来时，记为 `[UNKNOWN]` 并标注需要谁来决定，**不要替他编**。
+ - **发现两个答案打架时，新开一题专门收口，不要回炉改已答的题。** 回炉会把「这里曾经有过分歧」
+ 这个信息抹掉——而那往往比最终答案更值得记。
+ - **用选项式提问时，「未勾选」一律记为待定，不得当作已承诺。** 并在文档里显式声明这条口径——
+ 执行者理解成「要做」的话，会凭空多出一块范围。
## 要问清的五类信息
| 类别 | 要问出什么 | 典型追问 |
|---|---|---|
| **目标角色** | 谁用、有几个角色、权限差别在哪 | 「用户」→ 是运营还是管理员？两者看到的入口一样吗 |
| **触发场景** | 什么时候会用到、从哪进入 | 「需要一个导出功能」→ 从列表页还是详情页导出？导当前筛选结果还是全量 |
| **范围** | 这一期做什么、做到什么程度 | 「支持批量操作」→ 批量上限多少？部分失败怎么办 |
| **明确不做** | 哪些看似相关但这一期不做 | 用户通常会漏掉，**必须主动追问**——这一条直接决定 AI 会不会自己补全 |
| **已知约束** | 时间、合规、依赖的上下游系统 | 「月底要上」→ 依赖的 XX 服务什么时候能给接口 |
## 产物
写入 `docs/prd/<feature-name>/clarify.md`：
- 已知事实（来源可追溯）
- 目标角色与权限差异
- 触发场景与入口
- 范围 / **明确不做**
- 已知约束
- 待决问题
+ - **修订记录**（见下）
沿用仓库的证据标注约定：事实标来源，合理推断标 `[INFERRED]`，无法确认的标 `[UNKNOWN]` 并写明归属人。
+ ### 修订记录（不是可选项）
+
+ 需求在采访过程中被推翻是常事——用户中途改主意、业务方向调整。**问题不在反转，在反转没地方留痕。**
+
+ 模板固定留一节：
+
+ ```markdown
+ ## 修订记录
+
+ | 版本 | 日期 | 变更 | 触发 | 推翻 |
+ |---|---|---|---|---|
+ | v1 | 2026-10-13 | 初稿 | 首次采访 | — |
+ | v2 | 2026-10-13 | 目标角色由「自助用户」改为「企业采购决策者」 | 用户确认改为纯销售导向 | 推翻 v1 的「目标角色」「页面终点」 |
+ ```
+
+ 三条硬规矩：
+
+ 1. **推翻已确认的结论时，新增一条记录，不要删掉重写。** 直接覆盖会让下游
+ （`prd.md`、`design.md` 都引用本文件）无从判断哪一版为准，也看不出这是有意反转还是笔误。
+ 2. **「推翻」列必须点名被推翻的是哪一条**，不能只写「需求有调整」。
+ 3. 下游引用本文件时，**若本文件有修订记录，引用处要说明以哪一版为准**。
+
## 结束条件
五类信息每一类都有明确答案，或已作为 `[UNKNOWN]` 记录在案并指明归属人，即可结束。**不要追求问完**——把「还不知道」显式留下来，比当场编一个答案有价值。
+ **但收工前必须补一步：跨题一致性检查。**
+
+ 五类信息是一类一类问的，**矛盾只会出现在类与类之间**，逐类自查永远发现不了。
+ 把答案横着摆一遍，专门找这三类打架：
+
+ | 找什么 | 真实的例子 |
+ | --- | --- |
+ | **范围与计价模型打架** | 勾了「报价估算器」，但计价是一口价 → 根本不需要估算器 |
+ | **转化形态与入口打架** | 转化路径含「产品内升级」，但入口又排除了登录态 |
+ | **承诺与资源打架** | 要一张全功能对比表，但功能矩阵不存在，工期只剩 2.5 周 |
+
+ 冲突写进 `clarify.md`，**没有冲突就显式写「无」**——留白和「查过了没有」在下游眼里是两回事。
+
## 没有人在旁边回答时（自答模式）
做演示、做回归，或者用户明确说「你自己先过一遍」时，可以走自答模式：
- 仍然**一次处理一个问题**，但每个问题由你自己给出默认答案，并在 `clarify.md` 里把结论标成
`[自答]`，不要写成像是用户说过的话。
- 两条底线不能破：
- **涉及业务决策的**（价格、权益、优先级、上线范围）——即使自答也要落成 `[UNKNOWN]`
并写明归属人。那不是你能替人拍的板。
- **能从代码库或已有 PRD 查到的**——仍然先查，不要自答。
- 交付时把三类分开讲清楚：用户确认的、自答的、仍为 `[UNKNOWN]` 的。
**三者混在一起是本模式最大的风险**——用户会以为自答的结论他已经点过头了。
## 不做什么
- 不写 PRD 正文（那是 `prd-write` / `context-to-prd` 的活）。
- 不替用户拍板业务决策；只负责把选项和后果摆清楚。
- 不一次性抛出所有问题。
- 不重复问代码库里查得到的事。
+ - 不在推翻结论时静默覆盖——见「修订记录」。
+
+ ## 交付前检查
+
+ - [ ] 五类信息每类都有答案，或已作为 `[UNKNOWN]` 记录并写明归属人
+ - [ ] 跨题一致性检查做过，冲突已列出（无冲突则显式写「无」）
+ - [ ] 若发生过反转，「修订记录」里能查到这个反转推翻了哪一条
+ - [ ] 写完扫一遍中文乱码：`grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/`
## 下一步
把 `clarify.md` 交给 [`prd-write`](../prd-write/) 写新 PRD；若上下文已经足够充分，也可以直接进 [`context-to-prd`](../context-to-prd/) 成文。