产品需求文档最怕两种情况：一是写得像宣传稿，所有功能都“提升效率、优化体验”；二是写得像聊天记录，问题很多，但没有人能判断开发完成后到底算不算交付。AI 很擅长把零散材料整理成文档，但如果直接让它“帮我写一个 PRD”，它往往会补出一堆看似完整、实际无法验收的内容。
更稳的做法，是把 AI 当成“需求整理员”和“验收标准检查员”，先把用户反馈压缩成问题，再把问题改写成边界清楚的需求，最后生成可以测试的验收标准。这样写出来的 PRD 不一定华丽，但产品、设计、研发和测试都能围着同一张表讨论。
不要从功能名开始，从原始反馈开始
很多需求一开始就被命名成“智能推荐”“一键生成”“批量管理”，这会让团队过早进入方案讨论。更好的起点是原始反馈。比如：
- 用户说：“每次上传文件都不知道有没有成功，只能刷新页面看。”
- 销售说：“客户经常问能不能批量导入，但我们说不清导入失败时怎么处理。”
- 客服说：“最近一周有 18 个用户反馈导入后数据少了几行。”
这些话还不是需求，但它们包含了真实问题。可以先让 ChatGPT、Claude 或 Notion AI 做第一轮整理：按场景、用户角色、影响范围、证据来源分类，而不是马上写解决方案。
请把下面的用户反馈整理成需求分析表，不要新增事实。
输出列：
1. 原始反馈摘要
2. 用户角色
3. 发生场景
4. 用户真正想完成的任务
5. 当前阻塞点
6. 证据强度（高/中/低，并说明原因）
7. 暂时不要写解决方案
材料：
[粘贴客服记录、访谈纪要、销售反馈、数据截图说明]这里最关键的一句是“不要新增事实”。AI 很容易把一个用户抱怨扩展成完整功能，如果你没有限制，它会自己脑补优先级、目标用户和商业价值。
把“想做什么”改成“用户为什么卡住”
需求评审里最常见的争论，是方案还没讲清楚，大家已经在讨论按钮放左边还是右边。为了避免这种情况，可以先写问题定义。
| 不推荐写法 | 更适合评审的写法 |
|---|---|
| 增加批量导入功能 | 运营人员需要一次导入 100 条以上数据，但当前只能逐条创建，导致录入时间过长且容易漏项。 |
| 优化上传体验 | 用户上传文件后缺少明确状态反馈，失败原因不可见，导致重复上传和客服咨询增加。 |
| 做一个智能推荐 | 新用户不知道下一步该配置什么，首次完成关键设置的比例偏低，需要基于当前状态给出下一步建议。 |
这种写法看起来没那么“产品化”，但更容易判断是否值得做，也更容易给研发和测试留下明确边界。
让 AI 生成 PRD 草稿前，先给它固定结构
AI 写 PRD 最大的问题不是漏标题，而是把不确定内容写成确定内容。建议给它一个偏克制的结构，要求它标出假设和待确认项。
基于上面的需求分析表，生成 PRD 草稿。
要求：
- 不要编造数据、用户访谈和技术限制。
- 每个需求都必须对应至少一条原始反馈或证据。
- 对不确定的信息标记为【待确认】。
- 输出结构：
1. 背景与问题
2. 目标用户和使用场景
3. 本次范围
4. 不做什么
5. 用户流程
6. 功能需求
7. 状态和异常场景
8. 验收标准
9. 数据埋点建议
10. 待确认问题“不做什么”这一项很重要。小团队的需求经常失控，不是因为少写了功能，而是没有写清楚本次不处理哪些边界。比如批量导入可以先不做自动字段映射、不做历史数据回滚、不支持所有文件格式，只支持 CSV 模板。把这些写出来，后面的排期会现实很多。
验收标准要能被测试，不要写成愿望
“体验流畅”“结果准确”“页面清晰”都不是好的验收标准。测试同事无法根据这些话判断通过或失败。可以让 AI 把每条需求改写成 Given / When / Then，或者更简单的“前置条件—操作—预期结果”。
| 需求 | 可测试验收标准 |
|---|---|
| 用户可以批量导入客户数据 | 当用户上传符合模板的 CSV 文件且字段完整时，系统应创建对应客户记录，并在完成页显示成功数量。 |
| 导入失败要有提示 | 当 CSV 中第 12 行缺少必填邮箱字段时，系统不应导入该行，并在错误报告中标出行号、字段名和失败原因。 |
| 避免重复导入 | 当文件中存在已注册邮箱时，系统应跳过重复记录，并在结果页单独显示跳过数量。 |
这里可以用 Claude 或 ChatGPT 做“挑刺”：让它扮演测试负责人，专门找不可测试、缺少异常场景、口径含糊的条目。
请以测试负责人视角审查下面的验收标准。
重点找：
1. 是否能明确判断通过/失败
2. 是否缺少异常场景
3. 是否存在“快速、准确、友好”等无法量化词
4. 是否有权限、空状态、重复数据、网络失败、并发操作等遗漏
请输出问题列表和修改建议，不要重写整篇 PRD。用 AI 补异常场景，但不要让它替你决定范围
AI 很适合枚举异常场景。以批量导入为例，它可能提醒你：文件为空、格式错误、字段缺失、编码问题、重复数据、部分成功、超出大小限制、导入中断、权限不足、模板版本不一致。这些都值得检查。
但异常场景不等于都要做。产品负责人需要把它们分成三类：
- 本期必须处理：会造成数据错误、用户无法继续、客服量明显上升的问题。
- 本期给出提示：发生概率低，但可以通过错误文案引导用户自助修复。
- 暂不支持：成本高、收益低、可以在文档中明确限制的情况。
如果不做这一步，AI 会把 PRD 写得很完整，但研发排期会被异常场景拖垮。
把 PRD 拆给不同工具处理
不建议整个流程只依赖一个工具。不同阶段可以这样分工：
- ChatGPT / Claude：整理反馈、生成草稿、审查逻辑、补异常场景。
- Notion AI：把会议纪要、讨论结论和 PRD 版本沉淀到团队文档里，方便后续追踪。
- Cursor / GitHub Copilot：当 PRD 进入开发阶段后，用来辅助阅读旧代码、生成测试样例或检查实现是否覆盖关键路径。
- n8n / Zapier：如果反馈来源分散，可以把客服工单、表单、销售备注定期汇总到需求池。
工具越多，越要有一个主文档。AI 可以帮你生成多个版本，但最终团队只能认一个 PRD 地址、一个需求状态和一套验收标准。
发布前的 PRD 自检清单
- 每个需求是否能追溯到真实反馈、数据或明确业务判断？
- 是否写清楚本期不做什么？
- 是否包含空状态、失败状态、权限不足、重复数据等异常场景？
- 验收标准是否能直接变成测试用例？
- 是否把“待确认问题”留在文档里，而不是假装已经确认？
- 是否明确上线后看哪些指标，而不是只写“提升体验”？
AI 写 PRD 的价值，不是让产品经理少思考，而是把散乱输入更快变成可讨论、可验证的材料。真正决定文档质量的，仍然是你有没有保留证据、划清边界、写出能测试的验收标准。只要这三件事做对，哪怕 PRD 文字不漂亮，项目推进也会顺很多。