用 AI 把 PRD 拆成 20 条带优先级验收点，附完整提示词

一句话结论

让 AI 通读 PRD 抽出业务规则，再按可验证行为切成 20 条验收点，最后按影响面和不可逆性打优先级，半小时内出清单。

这篇解决什么问题

需求评审过了，PRD 也定稿了，真正难的是从几十页文档里捞出「到底哪些点必须验」。漏一条，上线后就是一次返工，而且往往漏在权限和并发这种不显眼的地方。

适用：PRD 结构基本完整、有明确业务规则的中小型需求，尤其是要同时给研发和测试对齐口径的时候。不适用：需求还在讨论要不要做的阶段，或者纯视觉改版这类几乎没有行为逻辑的活。

开始前要准备什么

• 一个长上下文模型就行，DeepSeek、Claude 都能跑，日常免费额度够处理一个中型需求
• PRD 全文，流程图和原型上的文字先转成纯文本，否则模型读不到关键分支
• 一份上个版本的历史验收清单，用来对齐字段和颗粒度
• 预留半小时，其中一半时间其实是花在校对上，不是生成上

具体怎么做

第 1 步 · 先让 AI 复述，把歧义顶出来

我一般不让它一上来就列验收点。先看它有没有读懂——复述歪了，后面二十条全是错的。这一步还能顺手把 PRD 里那些「默认大家都懂」的地方逼出来。

你是资深产品验收负责人。下面给你一份 PRD 全文，你只做复述和找歧义两件事，不要提改进建议，不要评价文档写得好不好。
输出三部分：
一、用 5 条以内说明这个需求解决谁的什么问题。
二、列出 PRD 里明确写死的业务规则，编号 R1、R2，每条一句话。只写文档里有的，不要补充你的推测。
三、列出 PRD 没写清、会让研发和测试理解不一致的地方，最多 8 条。每条按「原文说法 → 可能的两种理解 → 需要谁拍板」的格式写。
PRD 全文如下：
【在此粘贴 PRD 全文】

预期产出：一份 5 行以内的需求概述，加一份歧义清单。我实测过几个需求，通常能挖出 5 到 8 条歧义，其中两三条是真会导致返工的。

第 2 步 · 生成验收点池，先铺到 30 条以上

20 条是压缩后的结果，不是起点。一开始就要它往多了铺，把边界、权限、数据一致性这些容易漏的类别单独点名，不然模型只会写主流程。

你是测试架构师。基于上面复述过的 PRD，生成一份验收点候选池，数量不少于 30 条，宁多勿少。
每条用表格输出，字段为：
编号 | 验收点（一句话，只描述一个可观察的结果）| 触发条件 | 预期结果 | 判断方式（界面上看什么，或查哪张表、哪个字段）| 所属模块
必须覆盖下面五类，哪一类覆盖不到要单独说明原因：
1. 正常主流程
2. 边界值（数量、金额、时间、字符长度）
3. 权限与角色差异
4. 数据一致性（前后台、上下游、缓存与数据库）
5. 异常与回退（超时、失败重试、重复提交）
禁止写「体验良好」「响应及时」这类无法判断真假的描述。

预期产出：30 到 40 条带触发条件和判断方式的候选点。数量超出预期是正常的，重复也正常，下一步专门处理。

第 3 步 · 合并去重，压到 20 条

这一步最难的不是删，是判断哪两条其实是同一件事。我的经验是让模型自己把「合并了哪几条编号」写出来，人工扫一眼就能发现它有没有乱并。

你是验收清单的主编。下面这份候选池超过 30 条，请压缩到正好 20 条。
压缩规则：
1. 一条验收点只能描述一个可观察结果。如果一个条目里包含两个断言，拆开或删掉弱的那个。
2. 同一业务规则下的多条合并成一条，在「覆盖范围」列写清合并了哪几个原编号。
3. 无法判断真假的条目直接删掉，并在删除清单里说明原因。
4. 终稿里至少保留 2 条权限类、2 条数据一致性类、2 条异常回退类。
输出两部分：20 条终稿，编号 V1 到 V20，字段为编号、验收点、判断方式、覆盖范围；以及一张删除与合并对照表。
候选池如下：
【在此粘贴上一步的表格】

预期产出：正好 20 条，每条只描述一个可观察结果。实测下来，模型这一步会删掉几条我原本觉得挺重要的，回头看多数删得对。

第 4 步 · 按影响面和不可逆性定优先级

我不太用「重要 / 一般」这种词，模型会全部标成重要。改成分档加判定理由，逼它指向具体标准，人再复核就快得多。

给这 20 条验收点定优先级，只分 P0、P1、P2 三档，不要出现其他档位。
判定标准：
P0：涉及资金、越权、数据丢失或不可逆操作，一旦出问题必须回滚。
P1：主流程阻断，用户走不完这条路径。
P2：体验、文案、展示顺序这类，可以留到下个版本修。
输出表格，字段为：编号 | 验收点 | 优先级 | 判定理由（一句话，必须指向上面的哪条标准）| 建议由谁验（研发自测 / 测试 / 产品）。
约束：P0 控制在 7 条以内。如果超过 7 条，说明标准用松了，请重新判定并说明调整了哪几条。

预期产出：带优先级和建议验证方的清单。P0 通常落在 4 到 7 条，这个数量在评审时正好能逐条过一遍，再多就没人认真听了。

第 5 步 · 换个模型做反向挑刺

同一个模型自查基本不挑自己毛病，它会告诉你「以上内容已覆盖」。换一个模型，明确指定它站在测试的立场找茬，效果好得多。

你现在是这次需求的测试负责人，立场是挑刺。下面是产品给的 20 条验收点，请只找问题，不要任何肯定性评价。
逐条检查四件事：
1. 这一条能不能写出一条具体的测试用例？写不出的单独标出来。
2. 这一条是否超出了 PRD 写明的范围，属于自己加戏。
3. 这一条和别的条目是否还存在重复或包含关系。
4. 有没有明显该有却漏掉的验收点，重点看权限、并发、金额精度、空数据四种情况。
输出：问题清单（编号 + 问题类型 + 一句话说明），以及建议补充的验收点，最多 5 条。

预期产出：一份挑刺报告。我遇到的典型情况是它指出某两条写不成测试用例，因为描述的是内部实现而不是外部可观察的行为，这时候得退回第 3 步重写。

实测记录

手工做这件事，一个中等需求我以前要花小半天，从 PRD 一路抠到表格，还常常漏掉权限和并发两类。现在变的是时间分配：写的时间少了，校对的时间多了，总时长压到半小时上下。

失败也遇到过。有次 PRD 只写了主流程，附件里的接口文档没一起给它，结果第 2 步生成的池子里数据一致性类全是空的，第 5 步才被挑出来，等于白跑一轮。

最容易错的 3 个地方

1. 一上来就要 20 条，AI 后半段全靠凑数。改成先铺 30 条池子再压缩。
2. 验收点写成「体验流畅」这种没法判断的话。检验标准只有一条：能不能写出测试用例。
3. 让同一个模型自查，它几乎不挑自己毛病。换一个模型，指定它扮演测试。

可复用的东西

这五段提示词我留了一份底稿，顺序固定为：复述找歧义、铺候选池、压缩到 20 条、定优先级、换模型挑刺。换需求时只改最后粘贴的 PRD 和里面的化名，前面的指令一个字不用动。

如果团队多人协作，可以在第 3 步后加一句「按模块分组输出」，评审时按模块过，比按编号顺序过效率高。还有一点得说清楚：AI 给的是候选池，砍到 20 条这个决定不能外包出去。

这套流程保证不了零遗漏，但能让「漏在哪一步」变得可追溯。你平时拆验收点，是边看 PRD 边记，还是先出一版再回头删？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接