# Product Acceptance

> Generate, execute, and document product feature acceptance tests from requirement materials such as PRDs, links, screenshots, and notes. Use when a product manager needs an adaptive test framework, browser or prototype acceptance, a test checklist, a failed/blocked issue list, or office-suite-ready acceptance outputs such as CSV, DingTalk, Feishu, or WPS tables.

- Skill: `wangjiayi0124-joy/product-acceptance` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add wangjiayi0124-joy/product-acceptance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wangjiayi0124-joy/product-acceptance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: wangjiayi0124-joy (https://skillmd.com/u/wangjiayi0124-joy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/wangjiayi0124-joy/product-acceptance

---


# 产品功能验收

将所有用户提供的 PRD、原型、网页链接、截图、会议记录、聊天说明和补充规则视为**需求证据**。先基于证据建立本次验收框架，再执行；不要把某个项目的角色、入口、端形态或变更记录固化为通用前提。

## 工作流

### 1. 建立需求与范围

1. 列出每份需求证据及其可验证的规则、流程、限制和待确认点。
2. 发现来源互相冲突、信息过期或预期效果不明确时，标记冲突并向用户询问；不要擅自选择某份材料为最高优先级。
3. 明确本轮范围：验收对象、端/设备、测试环境、是否需要登录、可用身份和数据、是否允许外部跳转，以及不得触碰的操作。
4. 将可验证需求拆成 `一级模块 → 二级模块 → 功能/规则/链路 → 用例`。层级服务于理解，不为凑三级而拆分。

### 2. 生成并确认测试框架

在操作页面前，先向用户提供用例框架和覆盖范围，等待确认后再测试。用例字段以以下基底灵活增减：

| 用例 ID | 一级板块 | 二级板块 | 三级功能/链路 | 条件/前置 | 优先级/严重级 | 复现步骤 | 预期效果 | 实际结果 | 状态 | 问题描述 | 证据 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

只有需求确实存在特殊属性时，再增加字段，例如：身份、平台/设备、测试数据、版本、埋点、性能指标、接口结果、风险归属。

根据本次需求选择测试维度，不要默认全测。选择依据见 [覆盖与交付规范](references/coverage-and-delivery.md)：权限身份、入口与路由、数据状态、业务规则、异常恢复、外部依赖与跳转、兼容与迁移、可重复性等。

### 3. 安全地执行测试

1. 先做主路径，再做高风险规则、边界与异常路径；每个结论均记录触发条件和可复核证据。
2. 用户自己完成登录、验证码、账号切换和任何凭证输入。不要索取、保存或转述密码、Cookie、验证码或敏感配置。
3. 可正常浏览和操作验收对象；但点击会离开目标域/打开第三方应用的跳转前，说明去向并询问用户。涉及创建、提交、发布、支付、删除、改权限、发消息、下载敏感数据等副作用前，也必须先确认。
4. 测试中发现新的分支、状态或隐藏规则时，补充用例并说明其来源；将新用例纳入同一层级，不静默漏测。
5. 遇到需求不清、环境异常、缺账号/数据、或无法安全执行时暂停：说明已观察到的事实、缺失条件、可选下一步和对交付的影响，交由用户决定。

### 4. 判断状态与问题

使用四种状态：

- **通过**：在已满足前置条件下，实际结果符合明确预期。
- **不通过**：前置条件可满足，且实际结果与明确需求或验收预期不符。
- **阻塞**：无法判断是否符合预期，例如缺少账号、权限、测试数据、环境能力、外部依赖或副作用授权。写明“阻塞原因”和需要谁提供什么。
- **待定**：用例已规划但本轮未执行，或用户主动暂停/延期。写明“待补测”的范围。

不要因页面无响应就直接判为不通过：先排除未满足前置、加载、账号或环境问题。反之，已验证的功能缺失、错误路由、权限错配、规则不一致等，不能以“阻塞”淡化。

问题描述保持可读和可复现：用 `问题描述：`、`阻塞原因：` 或 `待补测：` 起首；一段只表达一个事实。将“实际现象、影响、缺失条件”分句或分段，避免整段堆叠。预期效果与问题描述不要互相重复。

### 5. 交付与校验

交付三部分：

1. **验收测试清单**：全部用例及其当前状态。
2. **未通过/阻塞清单**：筛出不通过和阻塞项；待定项单列“待补测”，不伪装成已发现缺陷。
3. **可导入办公表格的 CSV**：字段顺序与清单一致，保留完整文本和有效转义；适用于钉钉、飞书、金山等支持 CSV 导入的表格工具。

若用户要求直接创建办公文档或在线表格，按其指定的目标（如钉钉、飞书或金山）使用对应的原生表格能力，不以 Markdown 竖线文本代替；按 [覆盖与交付规范](references/coverage-and-delivery.md) 设置列宽和顶端对齐，并在写入后读回或预览核验。CSV 不携带列宽样式，因此要同时保证文本本身短句、分段、可扫读。

最终汇报：覆盖范围、用例与状态数量、不通过项、阻塞项、待补测项，以及继续验收所需的最小条件。不要把未验证推断写成测试结论。