产品会上最怕听到的一句是“需求很简单，加个按钮就行”。加在哪、给谁用、点了之后发生什么、怎么算完成，全都没说。PRD 的职责，就是把这句话拆成“谁在什么场景遇到什么问题、系统怎么响应、完成后怎么验收”。AI 能帮你整理访谈、会议和业务资料，但不能替产品经理决定优先级，也不能编造用户证据。
写 PRD 前，先收集三类证据
- 用户证据：访谈原话、行为记录、工单或使用数据。
- 业务目标：要改善的指标、成本、效率或风险。
- 现状限制：已有流程、权限、系统依赖和本期资源。
访谈资料可以先按AI 整理用户访谈记录的方法建立证据链；零散群聊和会议内容，用聊天记录转待办清单先捞一遍。证据齐了，AI 才有东西可用。
可直接复制的 PRD 生成提示词
你是一名产品需求文档助理。请根据我提供的用户证据、业务目标和系统现状，整理一份可评审、可开发、可验收的 PRD。不要编造用户需求、数据或技术方案。 产品背景：[填写产品和当前流程] 业务目标：[填写要改善的指标或问题] 目标用户：[填写角色和使用阶段] 用户证据：[粘贴访谈原话、工单、行为或数据] 现状与限制：[权限、依赖、时间和资源] 请输出： 1. 背景与目标：现状、问题、目标指标 2. 用户场景：角色、触发条件、当前行为、困难和期望结果 3. 功能需求：用户动作、系统响应、前置条件和结果 4. 业务规则：状态、权限、异常、数据范围和优先级 5. 验收标准：使用“前提—动作—可观察结果”格式 6. 非目标：本期明确不做的内容 7. 待确认问题：证据不足或需要技术、设计、业务确认的事项 规则： - 每个需求必须能回到用户证据或业务目标 - 不把解决方案偏好写成用户需求 - 不编造接口、数据库或工期 - 验收标准必须可测试，避免“体验更好”等模糊描述 - 需求冲突时分别列出，不自行决定优先级 - 输出后检查功能、规则和验收标准是否一一对应
示例：把模糊需求改成可验收需求
模糊说法：“用户希望导出报表更方便。”
用户场景：运营人员每月底需要按部门和日期导出报表，目前每次都要重新设置筛选条件，容易漏选日期导致数据不全。
功能需求：允许用户保存并复用常用的“部门 + 日期”筛选组合。
验收标准：当用户已保存筛选组合时，在报表页面选择该组合，系统应自动填充部门和日期；用户能在 3 个主要操作步骤内完成导出，原有权限规则不变。
对比一下差别：模糊说法谁都没法开发，验收标准却能让开发和测试直接照着写用例。
| 维度 | 模糊写法 | 可验收写法 |
|---|---|---|
| 场景 | 用户想方便一点 | 运营月底按部门+日期导出，常漏选日期 |
| 功能 | 加个保存按钮 | 保存并复用常用筛选组合 |
| 验收 | 功能正常 | 3 步内完成导出、权限规则不变 |
用户场景的四个要素
一个合格的用户场景，至少要写清角色、触发条件、当前困难、期望结果。上面运营导出的例子就是标准模板：角色是运营人员，触发条件是每月底导出报表，困难是重复设置筛选且易漏，期望是保存组合、几步内完成。场景写不出来的需求，优先级本身就存疑。
验收标准怎么才算可测试
- 写清前提：什么状态下进入测试。
- 写清动作：用户具体做了什么。
- 写清可观察结果：界面、数据、状态怎么变化。
- 把“体验更好、更快、更顺”这类词全部翻译成数字或具体行为。
翻译不出来，说明这个需求还没想清楚，应该退回上一阶段，而不是硬写进 PRD。
PRD 常见错误
- 把“增加按钮”当成需求，没说明用户问题。
- 只写正常流程，不写权限、空数据和失败状态。
- 验收标准只写“功能正常”，无法测试。
- 把 AI 推测的原因当成真实用户结论。
第 4 条最容易犯：AI 看到几条用户抱怨就总结出“用户想要 X”，这个 X 很可能是推测。只有回到访谈原话或行为数据，才能确认。
需求来自四面八方时，先归拢再写
当需求同时来自客户聊天、销售转述、工单和访谈，别把内容直接拼成 PRD。先用客户需求整理提示词合并重复反馈、保留原始证据、区分需求候选与解决方案；完成优先级和范围确认的条目，才进入本期 PRD。想对比竞品怎么做的，看AI 竞品分析提示词，但别用竞品功能替代真实用户证据。
非目标：PRD 里最容易漏的一段
“本期不做什么”和“本期做什么”一样重要。明确写清非目标，能挡住开发途中不断冒出来的“顺手加一个”。提示词输出里已经有“非目标”这一节，别删掉，也别让它替你决定哪些不做——那是产品经理的职责。
需求定稿之后
功能确定后，可以参考AI 产品使用说明书提示词编写用户文档，把验收标准里的“可观察结果”直接变成操作步骤里的“操作后应看到什么”。还不太会用 AI 做这类事的，先读AI 新手入门和提示词写法。
用交付结果倒推需要的信息
例如，需求只写增加导出功能，开发完成后业务说想要的是定时邮件报表。这类任务的难点通常不在“让AI写一段话”，而在于先把事实、边界和交付对象理顺。开始前应单独列出已有材料、尚未确认的信息和不能由模型替你决定的事项。没有依据的数字、承诺、人员安排和专业结论一律标记待确认，不用看似完整的句子掩盖信息缺口。
处理时重点抓住这些要素：用户场景、范围、业务规则、权限、异常、数据口径和验收标准。先用一小段材料跑通，再扩大到完整任务，能更早发现字段缺失和理解偏差。涉及多人协作时，最好让下一位执行者复述一遍：他从文档里看到了什么、准备先做哪一步、遇到什么情况需要停下。复述不一致，说明文档仍需修改。
从错误版本反推检查点
一个常见的失败版本是：直接让AI补全未确认需求，把解决方案当用户问题，遗漏不做什么。它往往表面整齐，实际无法执行。修正时不要只让AI“更专业”，而要指出哪一项事实缺失、哪句话无法验证、哪一步没有责任人或判断条件。每轮只改一类问题，并保留修改前后的差异，后续才能沉淀出稳定做法。
- 事实核对：人名、日期、金额、指标、文件版本和业务规则回到原始材料逐项确认。
- 边界核对：区分已经决定、正在讨论、个人建议和模型推断，不能把四者混写。
- 执行核对：动作写到具体对象、负责人、时间和可观察结果，删掉“持续关注”“及时处理”这类空话。
- 风险核对：敏感数据先脱敏，合同、财务、法律、安全、医疗等结论交给相应专业人员。
交付前用一个简单标准验收：产品、研发和测试对同一条需求理解一致，验收可用客观条件执行。再安排一次反例检查，故意输入一条缺日期、缺负责人或相互冲突的材料，看结果是否会明确提示缺口，而不是自行补全。能在正常情况和异常情况下都给出可核对结果，这套做法才算真正可复用。
最后保留三样东西：原始材料、采用的版本和人工确认记录。下一次遇到相似任务，可以复用字段和检查表，但仍要替换当次事实。模板的价值是减少遗漏，不是让所有场景得到同一答案；只要任务目标、读者或约束变化，就应重新检查输入和验收条件。