Requirement Clarify

---
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. **确定功能名**——小写英文短横线（`pricing-page`），目标目录 `docs/prd/<feature-name>/`。
   用户给的常常是中文描述而不是名字，那就由你译一个，但这三条不能省：

   - **有歧义就列 2~3 个候选让用户选**（「会员中心」可能是 `user-center` 也可能是
     `member-center`），**不要自己定**
   - **把最终取的名字回给用户**——它会变成目录名，后面每一步都靠它衔接，静默决定等于埋雷
   - 只确定这一次。后面 `prd-write`、`grill-with-prd` 等直接看目录就能推断，不用再传

   完整命名规则（长度、去修饰词、写入前自检）见 [`../product-prd-extract/`](../product-prd-extract/)。
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/) 成文。