AI 产品 PRD

AI 产品 PRD：从需求到可开发的文档

需求评审会上，开发问你："这个功能做到什么程度算好？"传统 PRD 可以回答"点击按钮出现结果"；AI 产品却答不上来——模型输出是概率性的，同一问题今天答对、明天答错，什么才算"好结果"？AI 产品 PRD 的特殊性在于：评测标准、失败路径、成本预算必须写进文档，否则上线就是开盲盒。

PRD（Product Requirements Document）是 PM 的核心交付物：把判断与设计落成开发照做的文档。在 AI 产品里，它尤其重要——需求分析解决"做什么"（见需求分析），产品设计解决"怎么用"（见产品设计与原型），而 PRD 解决的是"怎么把判断写清楚，让开发照做、让验收有据"。

本文给你可直接套用的 10 节模板、一份写得到位的示例节选、一张评审自查清单——照模板写，评审会少吵一半。写作前提是理解 AI 产品的运行节奏：上线只是 CC/CD 生命周期 里校准循环的开始，PRD 要为每一轮校准留下可更新的接口。

一、AI 产品 PRD 与传统 PRD 的差异

核心变化一句话：PRD 从"描述功能"变成"定义什么是好"。

具体到三个必须写进文档的东西：

• 评测标准：AI 功能没有"对错"只有"好坏"，好坏必须定义成可度量的数字——评测集、指标、抽检，缺一不可
• 失败路径：模型必然出错，出错时产品怎么表现必须提前设计；"随机应变"在 AI 产品里约等于"随机崩溃"
• 成本预算：每次调用都在花钱，上线即亏损的 AI 功能屡见不鲜；成本写进文档，开发才会把 token 当钱看

为什么不能"传统 PRD 加一段 AI 说明"了事：传统 PRD 的粒度是"每条路径都写清"，AI 产品写不清所有路径（输入开放式），写了也测不完；传统 PRD 的验收是"断言等于预期"，AI 只能"评测好坏程度"。所以不是补一段，而是把文档的骨架从"功能规格"换成"能力契约"——这是结构差异，不是篇幅差异。

PRD 在文档体系中的位置

PRD 不是孤立的文档，而是文档族的枢纽。每个 AI 功能从立项到上线，至少涉及这八类文档，各回答一个问题：

Traceability（可追溯）是硬要求：PRD 里的每条需求要有唯一 ID（如 REQ-001），技术方案按 ID 实现、测试用例按 ID 验收、评测脚本按 ID 断言——评审时一句话能问到底：这条需求，方案在哪、用例在哪、评测在哪。

PRD 类型

不是所有 AI 变更都值得写一份完整 PRD。按变更类型裁剪，评审标准也不同：

spike 的评审尤其容易踩坑：评审会要求"顺手把功能也做了"。规则是 spike 只验收学习成果（证据与结论），功能另立 PRD。

二、PRD 结构模板

下面 10 节，每节写明"写什么"与"为什么"。背景、能力边界、评测标准、失败路径是 AI 产品 PRD 的命门，其余是常规项但缺一不可。

写作原则

动笔前先立规矩，全文遵守这六条：

• 单一事实源：指标基线、阈值、口径只写一处，其他文档引用而非复制，避免"两个版本打架"
• 可测试语句：每句话都能被验收——"响应要快"不算，"p95 延迟 < 3 秒"算
• 显式非目标：写清"本期不做"清单，防止开发按"全能"设计、也防止评审发散
• 版本变更记录：文档头部放 changelog（日期、版本、变更、原因），谁改了什么都可追溯
• 术语表：领域术语（工单、SOP、拒答）统一定义，跨角色评审时减少鸡同鸭讲
• 决策与 open questions 分离：已定结论（DEC）与待定问题（OPEN）分开列，OPEN 必须有 owner 和 deadline，否则评审会开成追认会

1. 背景与目标

• 写什么：解决什么真实问题（用需求分析的判断法验证过）；目标要可量化——指标 + 当前基线 + 目标值
• 例如："工单平均处理时长从 6 小时降至 4 小时（基线：当前 6 小时；目标：上线后 3 个月内达标）"
• 为什么：AI 产品"方向对但差一点"与"方向错了"的成本差异巨大，先证明值得做；目标不量化，验收时开发说"做到了"、你说"没做到"，评审变吵架

加深——业务结果、反指标与停止条件：

• 业务结果：目标写业务结果而非功能输出。"路由准确率 95%"是手段，"处理时长下降、客服人效提升"才是目标；只写模型指标，评测达标了业务没动，等于没做
• 反指标：写明"不许恶化"的指标（转人工率、投诉率、客服满意度）。AI 功能的典型死法是核心指标涨、体验崩——没有反指标，团队会拿体验换分数
• 停止条件：什么情况下项目叫停（指标未动 / 反指标恶化 / 成本超预算 1.5 倍持续两周）。写清停止条件不是丧气话，是给决策者一个体面止损的依据

2. 用户与场景

• 写什么：谁、什么场景、多高频、现在怎么解决的（方法见用户研究）
• 例如："一线客服，日均 500 张工单，目前靠标题人工判断部门"
• 为什么：AI 能力边界与场景强相关，"给客服提建议"和"自动回复用户"是完全不同的产品；高频场景才值得投入推理成本

加深——角色链路、频次、现状替代品、容忍度：

• 角色链路：谁发起、谁审批、谁日常使用、谁为结果负责。客服场景里主管是验收人、一线客服是日常用户，两者的诉求常冲突（主管要效率、客服要省事），写清各角色的验收口径
• 频次：日均与峰值调用量——决定成本量级、缓存策略和并发设计（估算方法见 LLM 成本估算）
• 现状替代品：用户现在怎么解决（人工、旧工具、规则引擎），替代成本是多少——这是"AI 必须显著优于现状"的对照基准
• 容忍度：用户等多久会放弃、多少错误会流失。写清容忍度，延迟预算和通过线的松紧就有依据

3. 能力边界（重点）

• 写什么：能做什么、不能做什么、什么情况拒绝回答；模型做不到时怎么办（降级、人工接管、还是不做）；约束性说明（输入限制、支持范围、术语表）
• 例如："能判断退款/物流/投诉/咨询四类；不能承诺赔付；信息不足时输出'建议转人工'"
• 为什么：AI 从来不是"全知"的（见模型能力与边界）。不写清边界，开发按"全能"设计，上线必翻车；明确"拒绝回答"比模糊尝试更保护体验与信任

加深——输入类型、支持语言/格式、拒绝策略、置信度阈值：

• 输入类型：文本/语音/图片、最大长度、单条还是多轮对话、是否携带附件
• 支持语言与格式：仅中文？中英混杂？方言？Markdown 输出还是纯文本？——每多一种都是评测样本的负担
• 拒绝策略：何时拒绝（信息不足、超范围、敏感内容）、拒绝话术模板、拒绝后引导路径（转人工 / 补充信息）
• 置信度阈值：低于阈值做什么（转人工、不展示建议）。阈值本身是调参项，PRD 里写明"初始值 + 由评测调整 + 调整走变更记录"，别把阈值写死成不可改的圣旨

4. 功能需求

• 写什么：主流程 + 交互要点（见产品设计与原型）；每项功能标注优先级（P0-P3，分级规则见需求分析）
• 例如："P0：路由建议 + 一键改路由；P1：置信度展示；P2：错误反馈入口"
• 为什么：AI 功能往往是一个输入框加一个按钮，容易漏掉分支细节；优先级让开发在资源不足时知道先砍什么

加深——状态机、接口语义、埋点、权限、文案、异常分支：

• 状态机：请求生命周期（提交 → 处理中 → 出建议 → 采纳/修改/拒绝 → 结束），每个状态能否回退、超时落在哪个状态、用户取消怎么处理——AI 请求是可失败的异步过程，状态机必须显式建模
• 接口语义：入参出参、超时时间、重试规则、幂等性（用户点了两次会不会发两次）；Agent/工具调用场景还要写清每步的确认点（见 Agent 产品）
• 埋点：事件与属性清单（见第 8 节），写清采集时机
• 权限：谁能看到 AI 建议、谁能修改、谁能一键关闭功能——降级开关的权限要低到"值班人够得着"
• 文案：拒绝话术、降级提示、AI 生成标识（合规要求，见第 10 节）
• 异常分支：上游限流、解析失败、空结果、并发超限，每条给默认行为

5. 评测标准（重点）

• 写什么：本功能的"好"如何度量——评测集（20-100 条种子，覆盖典型/边界/对抗，构建方法见评估与评测）+ 线上指标（采纳率、改路由率等行为信号）+ 人工抽检方式（谁抽、抽多少、怎么复核）
• 例如："路由准确率 ≥ 90%，对抗集 ≥ 80%，人工改路由率 ≤ 5/万单"
• 为什么：AI 功能的"好"无法靠开发自测证明；没有评测标准，"感觉还行"无法复现、无法对比、无法改进

加深——数据集构成、指标公式、通过线、统计解释、人工抽检、红队：

• 数据集构成：来源（历史日志/人工构造）、规模、场景分布、标注协议（谁标注、指南在哪、一致性要求）——评测集也是需要治理的资产（schema 见 CC/CD 生命周期 的参考数据集一节）
• 指标公式：每个指标写清分子分母与观测周期（如"改路由率 = 被改建议数 ÷ 展示建议总数，按周聚合"），公式表可直接复用生命周期页
• 通过线：分层设线——总集一条线、对抗集一条线、各场景子集一条线，防止"平均分过关、弱势场景崩盘"
• 统计解释：样本量与置信区间——20 条样本得出"准确率 90%"没有统计意义；小样本结论必须注明不确定性
• 人工抽检：谁抽、抽多少、多久一次、复核流程——抽检不是可选项，是评测集的活水来源
• 红队：越狱、提示注入、有害内容诱导的用例谁出、何时跑、失败后怎么办（沉淀为回归项）

6. 失败路径与兜底（重点）

• 写什么：幻觉、超时、成本超限、误解用户——各写应对（重试、兜底话术、人工接管）；人工接管就是 CC/CD 框架 里的控制交接：出错时人类能否无缝接手
• 例如："3 秒未返回 → 直接转人工；日成本超预算 1.5 倍 → 触发降级"
• 为什么：模型必然犯错，PRD 不写兜底，出错时用户面对的是报错页，而不是一个可恢复的产品

加深——每条失败路径都有检测、响应、责任人和恢复方式：

"转人工"三个字不算兜底——要写清转给谁、多久响应、接不住怎么办。兜底没人接的 PRD，上线后兜底就是一句空话。

7. 成本预算

• 写什么：单次调用成本估算（输入/输出 token × 单价）、按业务量折算的月成本、成本护栏（超限怎么办，如降级到小模型或直接关停）
• 例如："单次约 0.02 元，月 300 万次调用 ≈ 6 万元；护栏：日成本超 2500 元自动降级"
• 为什么：成本是 AI 产品的"跑冒滴漏"，一次调用几分钱、一天百万次就是巨款——算账方法见 LLM 成本估算

加深——token 公式、峰值假设、缓存策略、单位经济、预算熔断：

• token 公式：单次成本 = 输入 token ÷ 1,000,000 × 输入单价 + 输出 token ÷ 1,000,000 × 输出单价；输入要算上系统提示与检索片段，输出按 max_tokens 上限估
• 峰值假设：日调用峰值（DAU × 人均次数 × 单功能请求数）与并发峰值，峰值档的成本可能数倍于均值档
• 缓存策略：prompt 缓存命中率假设（固定前缀吃折扣）、结果缓存（相同请求复用）——写清假设，成本预估才可复核
• 单位经济：单次解决成本 vs 人工处理成本——AI 客服单次 0.02 元没意义，对比的是"解决一张工单的总成本 vs 客服处理一张工单的人力成本"
• 预算熔断：日/月上限、触发动作（降级/限流/关停）、由谁触发、熔断后怎么恢复

8. 数据与反馈

• 写什么：埋点（系统看到什么、返回什么、用户怎么改）、用户反馈回流（踩、纠错、转人工）、评测集回填方案（真实错误定期补进评测集，方法见数据与标注）
• 例如："记录输入、输出、置信度、是否被人工修改；每周回填 20 条真实错误进评测集"
• 为什么：没有数据就没有校准；评测集不是一次建成的，随真实错误迭代才有生命力

加深——事件 schema、采样、纠错回流、删除/更正请求：

• 事件 schema：事件名、属性、采集时机一次写清——至少覆盖 request_started（输入、渠道）、suggestion_shown（建议、置信度）、suggestion_modified（改前改后）、suggestion_rejected、transferred_to_human、cost_exceeded（熔断）
• 采样：全量还是抽样（低置信度全量、高置信度抽样）、脱敏规则（PII 在写入日志前去除）
• 纠错回流：用户纠错 → 每周回填评测集的流程与责任人；纠错样本是评测集最真实的扩充来源
• 删除/更正请求：用户要求删除数据、更正错误输出的响应流程与时限（PIPL/GDPR 要求，见 出海与合规）

9. 灰度与上线

• 写什么：灰度范围（哪些用户、多少流量）、监控指标（准确率代理指标、延迟、成本）、回滚条件与责任人（谁在什么指标下有权一键回滚）
• 例如："先给 10% 工单开'路由建议'（不自动转派）；改路由率超 5% 或延迟超 3 秒即回滚，责任人：客服主管"
• 为什么：AI 上线是"校准的开始"而非交付完成（见 CC/CD 框架），没有回滚预案就相当于放弃观察窗口

加深——人群、指标、观测期、升级/停止/回滚责任人：

10. 合规与风控

• 写什么：内容安全（敏感内容过滤）、隐私（用户数据如何处理）、出海合规检查项（见出海与合规）
• 例如："客户信息脱敏后才可进日志与评测集；命中敏感内容直接转人工"
• 为什么：生成式内容自带合规风险，事后补救的成本远高于事前检查

加深——数据用途、保留期、地区差异、内容安全、审计要求：

• 数据用途：输入/输出数据用于什么（日志、评测、微调），用途声明与最小化原则
• 保留期：日志、评测集、用户数据的保留时长与删除机制——写"永久保留"等于埋雷
• 地区差异：目标市场法规差异（PIPL / GDPR / 欧盟 AI Act / 美国各州），数据本地化要求
• 内容安全：模型侧 + 平台侧 + 人工的三层过滤链路，命中后的行为（拒绝/转人工/标识）
• 审计要求：模型版本、prompt 版本、阈值、数据集的变更留痕——"谁在何时改了什么"要能回答

三、示例片段：AI 客服工单助手 PRD 节选

只摘能力边界、评测标准、失败路径三节，看看"怎么写才算到位"（v1 只做工单路由，不做自动回复）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

## 3. 能力边界

-   **能做**：根据用户描述判断工单类型（退款/物流/投诉/咨询），建议路由部门，附置信度与推荐理由
-   **不能做**（v1 不做）：直接回复用户、承诺赔付、跨部门转派
-   **拒绝回答**：无法判断类型或信息不足时，输出"建议转人工"，不猜
-   **模型做不到时**：置信度低于 0.6 或命中敏感内容，直接转人工，不展示建议

## 5. 评测标准

-   **评测集**：50 条种子（30 典型 + 10 边界 + 10 对抗，如"退款"说成"退钱"、中英混杂、辱骂内容），由客服主管标注"应路由部门"
-   **通过标准**：路由准确率 ≥ 90%（对抗集 ≥ 80%）才允许灰度
-   **线上指标**：人工改路由率（每万单 ≤ 5%）、平均处理时长、用户投诉率
-   **人工抽检**：每周抽 30 条低置信度工单，客服主管复核，错误回填评测集

## 6. 失败路径与兜底

| 失败 | 表现 | 兜底 |
| --- | --- | --- |
| 幻觉 | 编造部门信息 | 只输出结构化"部门 + 置信度"，文案全部模板化 |
| 超时 | 3 秒未返回 | 直接转人工，不计为失败，记日志 |
| 成本超限 | 日成本超预算 1.5 倍 | 触发降级：低置信度请求直接转人工，暂停调用 |
| 误解用户 | 把"投诉"路由到"咨询" | 客服一键改路由，修正写回日志，作为评测数据 |

注意三处"到位"的写法：

• 边界写清"不做"：不做的、拒绝回答的、模型做不到的，全部白纸黑字——开发不会按"全能"设计，也不会做出来才发现范围错
• "好"变成数字：评测集构成、通过标准、线上指标、抽检方式都量化——评审时直接拍板，不用争论"感觉"
• 兜底可执行：每条失败路径都有人、有动作、有触发条件，而不是"加强监控"这种空话

示例升级一：目标与反指标

节选里缺了目标层，补上之后，评审才能回答"为什么做"：

1
2
3
4
5

## 1. 背景与目标

-   **业务结果**：工单平均处理时长从 6 小时降至 4 小时（基线：6 小时；目标：上线后 3 个月内达标）
-   **反指标**：用户投诉率不上升；转人工率不超过 20%；客服满意度不下降
-   **停止条件**：3 个月处理时长未降，或成本超预算 1.5 倍持续两周 → 项目叫停并复盘

示例升级二：事件埋点

把"记录输入输出"展开成可落地的埋点清单，开发和数据同学直接照做：

1
2
3
4
5
6
7
8
9

## 8. 数据与反馈（节选）

-   request_started：输入、渠道、会话 ID（脱敏后）
-   suggestion_shown：路由建议、置信度、模型版本、prompt 版本
-   suggestion_modified：改前部门、改后部门（控制交接的核心事件）
-   suggestion_rejected：建议被直接忽略
-   transferred_to_human：转人工原因（超时/低置信/敏感/用户要求）
-   cost_exceeded：熔断事件，附当日累计成本
-   每周五回填 20 条 suggestion_modified 样本进评测集，责任人：客服主管

示例升级三：成本公式

把"单次约 0.02 元"展开成可复核的公式：

1
2
3
4
5
6
7

## 7. 成本预算（节选）

-   单次成本 = 输入 1,500 token ÷ 1M × 输入单价 + 输出 200 token ÷ 1M × 输出单价
-   日调用峰值假设：500 张工单 × 1 次路由 + 20% 重试 ≈ 600 次；并发峰值 < 50
-   缓存策略：系统提示固定为 prompt 前缀，缓存命中率假设 60%，命中部分按折扣计费
-   单位经济：单张工单 AI 成本 ≈ 0.02 元；对照基准：客服人工处理一张工单 ≈ 2 元
-   熔断：日成本超 2,500 元自动降级（低置信度全部转人工），值班 PM 确认恢复

示例升级四：灰度升级表与回滚条件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

## 9. 灰度与上线（节选）

| 阶段 | 人群 | 观测期 | 通过条件 | 责任人 |
| --- | --- | --- | --- | --- |
| 内部 | 客服团队自用 | 1 周 | 改路由率 ≤ 10/万单 | PM |
| 白名单 | 3 家客户 | 1 周 | 无 P0 投诉，改路由率 ≤ 7/万单 | 客服主管 |
| 10% 放量 | 随机工单 | 2 周 | 改路由率 ≤ 5/万单，投诉率不升 | 客服主管 |
| 全量 | 全部工单 | — | 10% 档连续两周达标 | 灰度负责人 |

-   停止条件：改路由率 > 5/万单或延迟 p95 > 3 秒 → 暂停放量，低置信度转人工（15 分钟内）
-   回滚条件：P0 事故或成本熔断 → 一键切回人工路由（5 分钟内），责任人：值班负责人

示例升级五：从示例到评审

写到位 PRD 的标志是工程师能提出实现问题、测试人员能写出验收用例：

• 工程师会问：suggestion_modified 的"改前/改后"是审计留痕还是可覆盖？超时后重试会不会重复转人工？熔断后请求是排队还是直接拒绝？——PRD 里没有答案的，评审当场定，记入决议记录
• 测试会写：对抗集用例（"退钱"、中英混杂、辱骂）、超时用例（3 秒边界）、并发用例（50 并发下熔断是否正确触发）、幂等用例（双击提交只产生一条工单）

四、评审与检查清单

评审与协作

评审前的预读与角色分工决定评审质量。一次典型评审的时间线：

评审的两类极端都要避免：评审变追认会（大家没预读，现场演读一遍）与评审变吵架（无决议记录，同一问题下周再吵一遍）——预读 + 决议记录是两剂解药。

• 评审角色：

• 决议记录：评审纪要按 DEC/OPEN 编号记录——DEC（已定结论）写进 PRD 冻结区；OPEN（待定问题）必须带 owner 和 deadline，下次评审先对账：

• 常见反对意见与对策：反对意见几乎都能映射回 PRD 章节——"边界太宽"→ 能力边界；"评测不可行"→ 评测标准；"成本没算"→ 成本预算；"兜底谁接"→ 失败路径责任人；"灰度谁负责"→ 灰度与上线
• Traceability 核对：评审最后一步，抽查 3 条需求 ID——技术方案、测试用例、评测脚本各有一处对应才算闭环

评审前的自查比评审本身更重要。提交评审前，逐条过这 11 条：

1. 需求是否真实、目标是否量化（指标 + 基线 + 目标值）？
2. 是否写清反指标与停止条件？
3. 评测集是否已有 20 条以上，且覆盖典型/边界/对抗三类？
4. 能力边界是否写清"不能做什么"与"何时拒绝回答"？
5. 失败路径是否每条都有兜底，兜底是否有人执行、有明确责任人？
6. 成本是否按月折算过，成本护栏是否可触发、由谁触发？
7. 灰度范围、监控指标、回滚条件是否都有人负责？
8. 埋点与反馈回流是否可落地，评测集回填谁来做？
9. 合规检查项是否过完（内容安全/隐私/出海）？
10. 需求 ID 是否与技术方案、测试用例、评测脚本建立对应（traceability）？
11. 废弃条件是否定义（指标长期不达标如何下架）？

如果某条答不上来，说明 PRD 还没写完——先补，再约评审会。

上线后维护

评审通过 ≠ 文档完成。把 PRD 分成两个区维护：

• 冻结区：能力边界、评测通过线、成本预算——变更必须走评审，防止"悄悄改规格"
• 活文档区：指标趋势、错误模式、已知问题、评测集版本——每轮 CC/CD 校准 后更新
• 版本对齐：文档头部记录当前评测集版本与模型版本，模型升级时（见生命周期页"模型与供应商变更"）同步更新 PRD 的能力边界与成本预算。版本变更记录（changelog）示例：

反模式清单

见过太多 AI 功能翻车，问题几乎都出在这六条反模式上：

相关链接

本站相关内容，按写作顺序排列：

• 需求分析：判断需求值不值得做
• 用户研究：搞清楚用户与场景
• 产品设计与原型：主流程与交互
• 模型能力与边界：模型做得到与做不到
• 评估与评测：评测集怎么建、怎么用
• AI 产品开发生命周期（CC/CD）：从能力范围到评测修复的完整循环
• Agent 产品：代理权、人工接管与失败恢复设计
• LLM 成本估算：调用成本怎么算
• 数据与标注：埋点、标注与反馈回流
• 出海与合规：合规检查项

PRD 的终点不是评审通过，而是上线后评测达标。 文档里每多一个可度量的数字，上线后就少一分开盲盒的风险。

下一次写 AI 功能的需求文档，你能先回答"怎么算好、错了怎么办、一个月烧多少钱"这三个问题吗？

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用