AI 写 PRD 前，先补齐这 6 项
AI 适合把已经明确的事实整理成 PRD 初稿，不适合替团队猜业务决策。生成前先写下这 6 项，评审时更容易发现缺口：
| 要确认什么 | 最小写法 |
| --- | --- |
| 问题与目标 | 谁在什么场景遇到什么问题；本次希望看到什么可验证变化 |
| 用户与权限 | 哪些角色可以看、改、提交或审批 |
| 主流程 | 从触发到完成的 3 至 7 个步骤 |
| 数据与依赖 | 必填字段、数据来源、已有系统或第三方依赖 |
| 边界 | 本次明确不做的场景，以及异常时由谁处理 |
| 验收条件 | 每个关键流程可观察的输入、结果和失败提示 |
这些信息不足时，可以先生成问题清单，不要直接把猜测写成需求结论。
可直接使用的 PRD 初稿指令
把方括号替换成已确认的信息：
你是产品需求整理助手。请基于以下已确认信息写 PRD 初稿：
目标：[目标与问题]
用户与权限：[角色及权限]
主流程：[触发、步骤、完成条件]
数据与依赖：[字段、来源、外部依赖]
本次不做：[范围边界]
验收条件：[可观察的输入与结果]
输出固定为：背景、目标、非目标、用户角色、流程、功能清单、数据与权限、异常处理、验收清单、待确认问题。
不要补充未提供的业务规则；信息不足处统一写“待确认”。
评审前再做一次 60 秒检查
生成初稿后，不要只看措辞。按下面顺序快速核对：
涉及价格、账号权限、个人信息、合同义务或对外承诺时，必须由对应负责人确认；AI 初稿不能替代评审或合规判断。
从聊天记录到可评审 PRD
当输入只是聊天记录、会议纪要或一句需求时，先标出“已确认”“假设”“待确认”。只把已确认内容放进初稿，把另外两类保留在待确认问题中。这样能减少把临时讨论误写成上线承诺的风险。
需要把材料整理为可继续编辑的 PRD 时，可在 AIPRD 中生成初稿，再按团队实际流程补充并评审。
常见问题
AI 生成的 PRD 能直接进入开发吗？
不能。它可以作为结构化初稿；业务规则、权限、数据处理和验收条件仍需要负责人确认。
需求还没有想清楚，应该怎么开始？
先只写目标、用户、主流程和不做什么，再让 AI 列出待确认问题。答案明确后再生成完整初稿。
怎样避免 PRD 越写越长？
把本次范围和验收条件写具体。不能在本次验收的事项，放进后续问题列表，而不是混入当前功能。