PRD 不是把想做的功能列成清单。它需要说明谁在什么场景遇到什么问题、为什么值得解决、系统应该怎样响应，以及完成后如何验收。AI 可以帮助整理访谈、会议和业务资料，但不能替产品经理决定需求优先级或编造用户证据。
写PRD前先收集三类证据
- 用户证据：访谈原话、行为记录、工单或使用数据。
- 业务目标：要改善的指标、成本、效率或风险。
- 现状限制：已有流程、权限、系统依赖和本期资源。
访谈资料可以先用AI整理用户访谈记录的方法建立证据链；零散群聊和会议内容可参考聊天记录转待办清单提示词。
可直接复制的PRD生成提示词
你是一名产品需求文档助理。请根据我提供的用户证据、业务目标和系统现状，整理一份可评审、可开发、可验收的 PRD。不要编造用户需求、数据或技术方案。
产品背景：[填写产品和当前流程]
业务目标：[填写要改善的指标或问题]
目标用户：[填写角色和使用阶段]
用户证据：[粘贴访谈原话、工单、行为或数据]
现状与限制：[权限、依赖、时间和资源]
请输出：
1. 背景与目标：现状、问题、目标指标
2. 用户场景：角色、触发条件、当前行为、困难和期望结果
3. 功能需求：用户动作、系统响应、前置条件和结果
4. 业务规则：状态、权限、异常、数据范围和优先级
5. 验收标准：使用“前提—动作—可观察结果”格式
6. 非目标：本期明确不做的内容
7. 待确认问题：证据不足或需要技术、设计、业务确认的事项
规则：
- 每个需求必须能回到用户证据或业务目标
- 不把解决方案偏好写成用户需求
- 不编造接口、数据库或工期
- 验收标准必须可测试，避免“体验更好”等模糊描述
- 需求冲突时分别列出，不自行决定优先级
- 输出后检查功能、规则和验收标准是否一一对应示例：把模糊需求改成可验收需求
模糊说法：用户希望导出报表更方便。
用户场景：运营人员每月底需要按部门和日期导出报表，目前每次重新设置筛选条件，容易遗漏日期。
功能需求：允许用户保存并复用常用的部门与日期筛选组合。
验收标准：当用户已保存筛选组合时，在报表页面选择该组合，系统应自动填充部门和日期；用户在 3 个主要操作步骤内完成导出，原有权限规则不变。
PRD常见错误
- 把“增加按钮”当成需求，没有说明用户问题。
- 只写正常流程，不写权限、空数据和失败状态。
- 验收标准只写“功能正常”，无法测试。
- 把 AI 推测的原因当作真实用户结论。
功能确定后，可以参考AI产品使用说明书提示词编写用户文档。需要比较竞品方案时，可使用AI竞品分析提示词，但不要用竞品功能替代真实用户证据。