AI 产品需求文档模板：14 个部分与完整填写案例

先分清：用 AI 写需求，还是为 AI 产品写需求

产品需求文档，也就是 PRD，是为某次决策解释产品问题、预期结果、所需行为和范围边界的材料。Atlassian 的模板将目标、假设、需求、相关设计与开放问题放在一起，提醒我们 PRD 不只是一份功能清单。本文的十四部分是编辑组织方式，不是行业强制格式。Atlassian 产品需求模板

AI 辅助起草指助手整理已获准使用的资料。要开发的功能可以完全不涉及 AI，例如新增一种导出格式。产品负责人仍须处理缺失信息与相互冲突的请求。文档读起来顺畅，不代表客户访谈真的发生过，也不代表工程实现已经确认可行。

为 AI 功能定义需求还要覆盖输出质量、评估数据、失败恢复、人机交互，以及模型和知识源变更。提示词只是实现输入之一，不是完整产品约定。模型在精选样本上表现良好，也不能证明外围权限、界面和运维流程正常。

本文贯穿案例是内部客服回复草稿工具：根据客服有权限读取的当前知识文章，生成供人工查看的建议回复。它不发送消息、不退款、不修改账户，也不决定公司政策。这个边界必须同时对开发者和使用者可见。微软 HAX 指南强调说明系统支持的任务与领域；能力说明还必须与实际行为一致。微软 HAX 能力边界指南

下笔之前，分开证据、需求与决策

为重要陈述标明类型并分配稳定编号。否则，“某位客服希望回复更快”可能不知不觉变成“所有客户都要求两秒内回复”，再变成已经承诺的工程目标。

证据登记表应包括来源编号、日期、版本、访问范围，以及它究竟支持哪一句主张。只有读者能够查看相关内容，链接才有追溯价值。一个资料编号真实存在，并不意味着它支持助手生成的所有句子。

需求要写到结果可以检查。NASA 的需求编写清单强调清晰、唯一引用、可追溯和可验证。可以借用这些纪律，不必把航空航天流程当成 SaaS 的强制要求。“快速”“安全”“准确”需要条件与评估方法，不需要换成更强烈的形容词。NASA 需求编写检查清单

AI 产品需求文档模板的十四个部分

1. 文档状态、负责人和本次请求的批准

记录 PRD 编号、版本、文档维护人、产品责任人、所需审核角色，以及本次要做出的决定。区分草稿、审核中、已批准用于某一用途、已被替代和已撤回。可以写下一次决策日期，但不要凭空填写团队没有承诺的发布日期。

案例编号为 P077，版本 0.3，状态为草稿。它请求讨论一个范围受限的客服回复概念，以及尚未解决的依赖问题。产品负责人同意“不自动发送”，不等于批准了整份文档。批准记录需要包含版本和用途，后续修改不能自动继承此前的授权。

2. 执行摘要：问题与拟实现的结果

说明谁遇到了什么阻碍、正在完成什么任务、拟做什么改变，以及为何现在需要决策。即使实现方式从助手换成更好的搜索或维护完善的常用回复库，这段摘要也应该说得通。

虚构案例中的客服需要一份可核对、关联当前获准资料的回复草稿。拟议方案把草稿与依据放在现有编辑器旁，仍由客服负责发送。本次讨论的是是否继续解决权限、评估与运维问题，为受限试点做准备，而不是立即发布。

3. 问题、支持证据和反证

使用获准的调研或业务记录说明当前流程，区分受访者陈述、实际观察与编辑推断。写明哪些人没有被覆盖，还有哪些替代解释。如果没有现有写作耗时的基线，就明确缺失，不要编造效率提高百分比。

案例包中的来源片段和交互记录是为教学创作的，不是真实需求调研。在实际 PRD 中，应附上获准使用的访谈记录或数据摘录，逐项解释其支持的结论。“客服打开了多篇文章”不自动证明“生成式回复是最佳方案”。

4. 目标用户、任务与不适用的情境

明确主要角色、任务、工作环境、语言和访问条件。分清直接使用工具的人与受到输出影响的人：客服操作草稿工具，客户可能收到人工修改后的内容，两者的需要有关联，但不相同。

写清首期语言和产品范围，确定助理、临时员工、外包人员是否在内。不应编造用户画像，也不要假定每个人都使用鼠标。若流程涉及屏幕阅读器或纯键盘操作，应从起点纳入相应需求和审核计划。

5. 目标、指标及每个指标支持的决定

每项指标写明事件定义、分子、分母、人群范围、时间窗口、数据源、负责人和决策用途。使用量、输出质量、延迟、成本和潜在损害不能混成一个“效果分”。客服原样接受文字是一种行为信号，不等于文字事实正确或客户满意。

示例提出三个探索性目标：范围内请求至少 85% 生成预览；已审阅草稿至少 70% 被原样接受；仅成功预览的最近秩法 p95 延迟不超过八秒。这些是需要验证的虚构规划选择，不是行业基准。没有基线或成本证据的部分继续保持未决，不能写成节省承诺。

6. 非目标及重新讨论的条件

明确列出本次有意排除的相邻能力。案例工具不自动发送、不批准退款、不编辑客户账户，也不能使用超出操作者权限的内部材料。若实际实现仍能执行向外发送动作，仅贴一个“草稿”标签并不能形成有效边界。

重要排除项应写明理由和重新考虑的条件。自动发送需要另一套风险评估、运维设计、证据与明确授权，不能通过修改提示词悄悄进入上线范围。非目标是实际范围决定，不是暂时忘记写的功能。

7. 范围与具有唯一编号的需求

为每项需求分配稳定编号，记录所需结果、理由、优先级、依赖和验收链接。将行为要求与审核人的工作分开。几个行为可能分别失败时，应拆成独立需求，或提供清楚分开的验收场景。

除非确实受到约束，否则不要先规定必须用某个模型或数据库。“展示的每个事实必须由当前可访问来源支持”描述了所需结果；“始终使用模型 X”没有解释结果为何重要。若实现方式无法可靠满足前者，应缩小功能或不展示无依据文本，而不是把要求写成已满足。

8. 用户体验、失败状态与恢复

写清入口、加载、预览、无结果、拒绝访问、超时、修改和退出状态。案例中生成失败必须保留客服已经输入的文字，并允许继续人工处理。不能用错误页替换一个原本可以工作的编辑器，让基础任务也无法完成。

Google 的 People + AI Guidebook 讨论如何定义错误、定位原因并帮助用户在失败后继续任务。应把这个思路用于产品，而不只是模型接口：技术上格式正确、实际却答非所问，仍是用户遇到的问题。Google PAIR 错误与恢复指南

对于不移动焦点的状态通知，说明辅助技术如何获得信息。W3C 对 WCAG 2.2 第 4.1.3 条的解释涵盖可通过程序识别的状态消息，并非要求每段新文字都变成打断用户的播报。把无障碍要求写进文档后，仍需用合适工具和审核人员实际检查。W3C 状态消息说明

9. 数据、系统连接与 AI 配置边界

列出获准输入、权威记录系统、输出字段、资料版本、更新规则、标识符和失败行为。区分当前知识与已失效材料，确定检索为空、文章冲突或返回操作者无权查看的资料时如何处理。

AI 功能还应记录所选模型或候选模型、提示词版本、检索配置、评估集版本及重要生成设置。只有确实计划训练或微调时，才需要训练数据要求。虚构 PRD 尚未选定生产模型和系统连接，因而不能声称权限过滤或来源追溯已经可以运行。

10. 安全、隐私与必须进行的专业审核

写出信息流向和负责审核的角色，覆盖请求时及展示时的权限、日志中的敏感资料、保留与删除，以及权限变化的后果。假名账户编号或一个“私有”开关，都不能单独证明所有要求已满足。

案例特别提出：检索后、展示前，客服失去文章访问权限怎么办？虚构记录尚未运行这一检查，因此仍阻止上线。真实环境中的隐私、安全和法律决定，需要对应领域的合格责任人处理；生成的 PRD 不能提供合规认证或替代专业审核。

11. 依赖、约束与替代路径

列出上线依赖的系统、团队、数据、供应商安排和运维资源。每个重要依赖应有责任人、已有证据、未解决条件与延期影响。分清不能改变的约束和可以调整的偏好。

案例依赖按权限检索、获准知识集合，以及稳定的人工编辑器。如果检索不可用，替代路径是现有人工流程，而不是不受限制地搜索全部公司文件。没有成本数据时，商业论证应保持暂定状态，不能用编造的 token 单价确定预算。

12. 风险、触发条件与尚待承担的决定

描述哪里可能出错、如何发现、谁来响应，以及继续使用前必须满足什么条件。风险包括无依据的政策陈述、过期来源、越权披露、过度依赖和客服任务中断。创建了风险处理工单，不代表风险已经消失。

NIST AI 风险管理框架是自愿使用的参考，用于考虑 AI 设计、开发、使用和评估过程中的风险。官方概述也说明 AI RMF 1.0 正在修订。记录查阅版本；引用 NIST 既不是认证，也不能证明你的控制措施有效。NIST AI RMF 概述

13. 验收证据、发布条件与回退

把需求与实际检查、被检查的构建或配置、结果和未解决缺陷连接起来。测试标题不是测试结果；区分“检查了文档”和“执行了测试”，明确保留未运行状态，不能将它当成通过。

写清谁可以批准受限试点及之后扩大范围，并列出停用条件、关闭方式、支持责任和回到人工流程的路径。关闭功能不一定能撤回已发送消息或已经泄露的信息，因此响应计划要处理外部后果，不能假定功能开关可以撤销一切。

14. 开放问题与决策记录

每个开放问题需要责任人、所缺证据、截止日期和阻塞影响。除了集中记录，还应在对应正文位置保留未决状态，避免读者把看似完整的一段话误认成已经定案。

决定变化时，记录旧选择、新选择、原因、批准者，以及受到影响的需求、测试和说明。如果八秒目标变了，应同步指标定义并说明原因，不能为了让今天的结果“通过”而悄悄改掉昨天的目标。保留被替代版本，团队才能还原决策过程。

完整案例：PRD 填好了，结论仍然是暂不上线

从来源追到需求，再追到验收证据

填写案例包含七项需求和八条虚构检查记录。这是刻意限定范围的教学材料，不是客服产品的完整验证方案，也不是在 OpenMax 上实际执行的测试。

KB-01 只说工作区管理员能修改账单邮箱，并未承诺 24 小时内完成。T03 的建议回复引用 KB-01，却承诺了 24 小时完成。链接存在，主张仍然没有依据。若检查器只验证来源编号有效，就会漏掉这个问题。

八条记录中五条通过、一条失败、两条未运行。只有 RQ-01、RQ-03、RQ-04、RQ-05 的全部已列检查通过，即七项需求中的四项。这只是小型矩阵的覆盖情况，不表示这些需求在真实系统中已经被穷尽验证。

重算交互指标，不把失败请求藏在分母之外

另有一份独立的虚构交互日志，包含二十次请求：十四次生成预览、四次超时、两次因权限被阻止。十四份预览中，十二份有人工处理结果：八份原样接受、三份修改、一份拒绝；两份尚未审阅。这份日志与 T01–T08 是不同数据集，不应混用分母。

虚构日志支持“约三分之二的已审阅草稿被原样接受”，不支持“约三分之二的请求已成功自动化”。原样接受不证明正确，而且只生成草稿的产品并未自动发送或解决客户问题。

十四次成功预览耗时依次为 2、3、3、4、4、4、5、5、6、6、7、8、9、12 秒。按声明的最近秩法，将数值排序并选取向上取整的 p×n 位置：p50 是第七个数，即五秒；p95 是第十四个数，即十二秒。这是仅成功预览的延迟。四次超时各等待二十秒，必须单独保留；不能把十二秒重新标成全部请求的 p95。

按真实条件作出发布决定

这些目标是虚构的规划选择，不是所有客服团队都应采用的默认值。关键在于决策纪律：精美文档和若干通过项不能抵消阻塞性缺陷。本例保持 HOLD，暂不上线，不据此推断真实产品的可发布性或性能。

如何用助手逐部分起草并审阅 PRD

1. 准备证据包。 收集获准来源和既有决定，为其分配稳定编号，明确助手可用范围。缺少调研就记录缺口，不让它制造研究证据。
2. 一次起草一个部分。 提供该部分需要回答的问题、允许使用的资料集及输出格式，要求保留证据编号和不确定性。空白项有负责人，往往比假答案更有帮助。
3. 按角色提出质疑。 产品检查问题与范围，设计检查体验，工程检查可行性，数据及相关专业人员检查评估与信息处理。这些是真实责任，不是让 AI 扮演角色后模拟批准。
4. 双向重走证据链。 选一项需求，向前追到需要或决定，向后追到验收证据。既查正常路径，也查失败和未运行项；分清“链接有效”与“主张受到支持”。
5. 固定本次决策版本。 记录谁批准了什么、适用于哪个用途。模型、知识集合、权限规则或关键需求改变时，找出受影响证据并重新请求必要审核。

需要更具体的行为表述，可参考用户故事验收标准指南；未解决风险可配合项目风险登记表模板。它们支持 PRD，不替代决策负责人。

选择能维护证据的最轻量流程

人工文档与审阅： 改动小、资料少时通常就够了。重点是解决含义，不是填满十四个标题。即使文档很短，也保留决策日期和需求编号。

现有协作工具： 使用团队已经具备的评论、历史版本和问题链接，核实批准覆盖什么、附件更新后是否仍可追溯。一个共享页面地址本身不等于针对特定版本的批准记录。

脚本或无代码检查： 可以找出重复需求编号、缺少引用、失效链接和必填项遗漏，但不能判断产品是否值得做，也不能裁决政策解释是否正确。

智能体辅助起草： 当获准材料分散、整理初稿可以减少事务性工作时更有价值。候选需求、假设和决定应始终区分；不能仅为写一份文档就授予修改来源、联系客户或发布功能的权限。

持续产品运营： 规模扩大后加入输入版本管理、评估责任、变更通知和复审触发条件。关键配置变化后，要检查旧验收证据是否仍适用。文档数量变多不代表决策变好。

OpenMax 能帮助哪一步，哪些能力仍需核实

官方文档实际支持的说法

OpenMax 的 AI 产品经理文档提供 PRD 生成提示示例，请求输出问题证据、用户故事、AI 特定验收标准、系统输入输出、评估数据、上线条件和开放问题，也把利益相关方签字清单列为请求的输出。因此它可以作为起草参考；这不能证明你的环境已经强制审批、维护版本历史，或把每项需求自动关联到测试。OpenMax AI 产品经理文档

先做来源受限的草稿，不声称已经获得批准

先用虚构资料包，请助手整理证据表、七项需求和未解决的上线条件，再写摘要。将结果与案例核对：如果它从 KB-01 编出 24 小时时限，或者把未运行检查改成通过，就暂停并修正流程。

仅根据提供的证据和决定起草指定 PRD 部分。保留来源编号、版本和限制，分开事实、拟议需求、假设及开放问题。不要编造访谈、估算、批准或测试结果。指出无依据陈述与规则冲突。只生成供审阅的草稿；不要修改来源系统、联系客户、批准范围或发布功能。

正式使用前，由责任人确认工具权限、数据处理和连接系统的实际行为。限制性提示词不能代替已实现的访问控制。任务范围先保持最小，直到输出可以对照实际来源检查。

什么情况下更简单的方法反而合适

证据已经清楚、改动很短时，直接在现有文档中写即可。如果瓶颈是团队意见不一致，再生成一份稿子可能只是把分歧表达得更漂亮。缺少专业批准或基线时，下一步是获得证据，不是要求助手让 PRD 看起来已经完成。

先用填写完整的 PRD 案例统一审阅方式，再将空白模板用于一个真实、获准处理的产品决定。在必要责任人作出决定前，保留草稿状态。

文档写完后，仍须保留的限制

模板不能证明需求存在、技术可行或符合规定。十四个部分都填完，也可能是在解决错误的问题。本例二十次交互与八条检查记录都是虚构教学输入，不足以证明真实人群表现、因果改善、成本节约或真实上线结论。

模型输出会随输入、配置和来源更新而变化。要求生成内容逐字等于某一句标准答案可能太窄；仅凭“看起来不错”又太松。应明确哪些事实和行为必须成立、如何评估、失败后怎么办。人工审阅也有能力与差错限制，写上审核人姓名不证明每次输出都会得到认真阅读。

真实隐私、安全、无障碍和法律问题需要合适的专业人员及实际证据。不要为了显得权威加入虚构审核人履历、模拟团队批准或想象的客户评价。必要审核尚未进行，就明示这一点及其阻塞影响。

常见问题

这是用 AI 写文档的模板，还是 AI 产品的需求模板？

两种情况都适用，但要分清。任何 PRD 都可以用 AI 整理获准证据；功能本身使用 AI 时，还要补充模型行为、评估、数据和失败要求。只调用现有模型的产品，不必添加不相关的训练章节。

PRD 应该写多长？

长度应足以支持具体决策、追溯需求和评估结果。小改动可以写短，复杂或后果重大的功能需要关联证据与专业细节。页数和字数不是质量闸门。

助手能补上缺少的指标和估算吗？

可以提出明确标记的讨论选项，但不能把缺失的基线、成本、调研或工程估算变成事实。用这些内容作出承诺前，应给未知项分配负责人和解决计划。

PRD 获批，就代表功能可以上线吗？

不一定。批准可能只针对某个版本的调研或开发。上线还需要规定的证据、阻塞项解决、运维准备与授权决定。虚构案例的正确发布状态仍是暂不上线。

PRD 必须永久选定某个模型和提示词吗？

不必。PRD 应定义所需行为和真实约束，同时记录当前证据对应的实现配置。模型、提示词、检索数据或权限行为改变后，可能需要重新评估，不能自动沿用旧结论。

来源、修订方法与下一步

官方来源核查日期为 2026 年 9 月 4 日。本次修订区分 AI 辅助写作与 AI 功能，补充可逐条查看的虚构 PRD、来源—需求—检查关系，以及不同交互指标的分母。十四部分组织方式与教学案例为原创编辑材料；不声称进行过真实客户研究、OpenMax 执行、系统连接测试或专业批准。

下一份 PRD 先选定一个产品决定，固定可用证据，再填写影响“是否继续”的部分。润色摘要之前，先读无依据、失败和未运行的项目。好的 PRD 让下一步责任更清楚，即使结论是等待证据，而不是上线。