---
name: acceptance-checklist
description: 基于 PRD 和交付包生成结构化验收清单，产出 docs/prd/<feature-name>/acceptance.md。按核心流程、边界与异常、UI 还原度、数据埋点四个维度拆解，每条标 P0/P1/P2 优先级并注明依据出处（引用 PRD 的需求编号）。适用于研发提测后的产品走查、上线前的功能验收；不用于写测试代码、执行自动化测试或判定代码质量。
---

# 验收清单

研发提测后、上线前，产品要能拿着一条条清单走查，而不是凭印象点几下就签字。本 Skill 把 PRD 和交付包拆成可勾选的验收项。

## 使用边界

- **适用**：研发提测后的产品走查（Sanity Check）、上线前的功能验收、视觉与交互还原度核对。
- **不适用**：写测试代码或跑自动化测试（那是测试的活）；审查代码质量；判定版本能否发布。
- 本 Skill 产出的是**产品验收**清单，不是测试用例——两者的粒度不同：测试用例覆盖实现分支，验收清单覆盖**用户可感知的结果**。

## 开始前

1. 确定功能名 `<feature-name>`，定位 `docs/prd/<feature-name>/`。
2. 读取 `prd.md`（**必需**）；`delivery.md`、`prototype.html`、`demo.md` 有则读。
   - 没有 `prd.md` 时不要凭原型硬编清单——提示用户先补 PRD，或明确标记本次验收无需求依据。
3. 提取 PRD 中的需求编号（`R1`、`R2`…）、验收标准、范围外清单，以及交付包里的状态与异常清点。

## 拆解维度

| 维度 | 覆盖什么 | 默认优先级 |
|---|---|---|
| **核心流程** | 主线路径是否走得通：进入入口 → 执行动作 → 结果正确 → 状态更新 → 可查看 | P0 |
| **边界与异常** | 网络异常、超时、无权限、次数用尽、不合规输入、并发提交 | P0 / P1 |
| **UI 还原度** | 关键页面的布局、文案、加载态、空态、交互反馈是否与 PRD 和原型一致 | P1 / P2 |
| **数据埋点** | 核心转化漏斗的埋点是否触发（有条件验收时才做） | P2 |

不写「体验良好」「符合预期」这类无法判定的条目。每条都要是**第三方独立可验证**的。

## 产物

写入 `docs/prd/<feature-name>/acceptance.md`：

```markdown
## <维度>
### 需求 R1 · <需求名>

- [ ] **<可验证的行为描述>**  `P0`
      - 预期：<看到什么算通过>
      - 依据：`prd.md` R1 验收标准第 2 条
      - 结果：☐ 通过  ☐ 未通过  ☐ 跳过
```

每条必须包含三样：**可验证的描述**、**预期结果**、**依据出处**（指回 PRD 的哪条编号）。
依据出处是这份清单的价值所在——没通过时，能直接定位是需求没写清还是实现没做到。

### 需要浏览器里点着走查时

默认产出 markdown。如果要在浏览器里逐条打勾、看通过率进度，让 AI 依据 `acceptance.md` 生成一份**单文件 HTML** 清单即可；本 Skill 不预置也不依赖任何前端框架或本地服务。

## 交付前检查

- [ ] 每条验收项都能被第三方独立验证，没有主观表述。
- [ ] 每条都有依据出处，且指向的 PRD 条目真实存在。
- [ ] 优先级已标，P0 项覆盖了主流程和主要异常。
- [ ] `prd.md` 的「范围外」内容没有被误列进清单。
- [ ] 明确标注了本次未能覆盖的维度（例如没有埋点数据时）。

## 不做什么

- 不写测试代码，不替代测试。
- 不执行测试，也不判定版本能否发布。
- 不凭原型反推需求并当成验收依据。
- 不引入外部框架或需要常驻进程的本地服务。

## 下一步

走查完成后，把未通过项按归属人整理成缺陷清单；若未通过项暴露出需求本身的缺口，回到 [`grill-with-prd`](../grill-with-prd/) 或 [`prd-write`](../prd-write/) 补齐，而不是在验收阶段现场改口径。