AI 写 PRD：先写验收标准，再写功能

更新于 2026-10-28 · 约 6 分钟读完

PRD 被研发挑毛病，八成不是因为功能漏了，而是因为“做完算什么”说不清。评审会上一句“这个需求验收标准是什么”，能把写了两千字的功能描述全部推翻。

所以顺序要倒过来：先写验收标准，再写功能。AI 在这件事上很有用——它不厌其烦，能把每一条需求都逼出可验证的判据。

四段结构

1. 要解决什么问题：谁、在什么场景、现在怎么凑合、代价是什么
2. 做成什么样：验收标准（可测），不是功能清单
3. 边界在哪：明确不做什么，以及异常怎么处理
4. 怎么衡量：上线后看哪个数，多久看一次

提示词一：逼出验收标准

帮我把这个需求转成可验证的验收标准。

需求：（一句话，例如：让用户能在列表页批量导出）
使用者：（角色）
现状：（现在怎么做的，有什么代价）

要求：
1. 每条标准都要能被测试，写成「给定……当……则……」的形式；
2. 覆盖四类：正常流程、边界值、异常情况、权限；
3. 标出哪些标准需要产品和技术一起确认；
4. 不要写「用户体验良好」这类无法验证的描述。

提示词二：写完整 PRD

基于上面的验收标准，帮我写 PRD。

结构：
1. 背景与问题（三段以内，只写事实）
2. 目标与验收标准（引用上面确认过的）
3. 功能说明（每个功能：做什么、触发条件、异常处理）
4. 不做什么（明确列出本期排除项，避免范围蔓延）
5. 数据埋点与衡量方式

要求：
- 不编造数据、接口名、字段名，缺的标「（待确认）」；
- 每个功能都要写清异常态怎么处理；
- 不写「提高用户体验」，写具体的可观测变化。

提示词三：评审前自检

拿去找研发之前，先让它当一次最难搞的评审。

假设你是这个需求的技术负责人，你最关心工期和返工。看这份 PRD：

1. 哪一条需求在技术上有歧义，会导致两种实现？
2. 哪个异常态没写，上线后必然出问题？
3. 哪条验收标准无法测试？
4. 如果砍掉一半范围，你会砍哪些，为什么？
5. 这个需求有没有更简单的做法，能解决 80% 的问题？

每条给具体句子，不要说「建议补充完善」。

评审时最容易被推翻的三处

• 边界没写。“支持批量导出”里，批量是多少条？超过怎么办？这些问题在评审会上会变成“回去再想想”。
• 异常态没写。网络失败、权限不足、数据为空，这三类不写，研发只能自己拍，上线后就是你背锅。
• 成功标准没写。没有衡量方式的需求，做完无法判断值不值得，下一期预算就会被砍。

两个常见错误

• 用截图代替描述。截图能说明长什么样，说不清交互逻辑。图配文，不是图代替文。
• 把方案当需求。写“加一个下拉框”是方案，写“用户能快速找到目标分类”才是需求。前者被推翻时你无话可说。