requirement-clarify · diff
git:20261013.60e8978 to git:20261013.be4849d
13 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]` 并写明归属人。
## 结束条件
五类信息每一类都有明确答案，或已作为 `[UNKNOWN]` 记录在案并指明归属人，即可结束。**不要追求问完**——把「还不知道」显式留下来，比当场编一个答案有价值。
+ ## 没有人在旁边回答时（自答模式）
+
+ 做演示、做回归，或者用户明确说「你自己先过一遍」时，可以走自答模式：
+
+ - 仍然**一次处理一个问题**，但每个问题由你自己给出默认答案，并在 `clarify.md` 里把结论标成
+ `[自答]`，不要写成像是用户说过的话。
+ - 两条底线不能破：
+ - **涉及业务决策的**（价格、权益、优先级、上线范围）——即使自答也要落成 `[UNKNOWN]`
+ 并写明归属人。那不是你能替人拍的板。
+ - **能从代码库或已有 PRD 查到的**——仍然先查，不要自答。
+ - 交付时把三类分开讲清楚：用户确认的、自答的、仍为 `[UNKNOWN]` 的。
+ **三者混在一起是本模式最大的风险**——用户会以为自答的结论他已经点过头了。
+
## 不做什么
- 不写 PRD 正文（那是 `prd-write` / `context-to-prd` 的活）。
- 不替用户拍板业务决策；只负责把选项和后果摆清楚。
- 不一次性抛出所有问题。
- 不重复问代码库里查得到的事。
## 下一步
把 `clarify.md` 交给 [`prd-write`](../prd-write/) 写新 PRD；若上下文已经足够充分，也可以直接进 [`context-to-prd`](../context-to-prd/) 成文。