AI 产品 PRD 怎么写:与传统 PRD 的核心差异
一句话核心差异
传统 PRD 回答的问题是"做什么、什么时候上线、交互长什么样";
AI 产品的 PRD 除了这些,还必须回答一个传统 PRD 从不需要回答的问题——"效果好到什么程度才算做完"。
这是因为传统功能是确定性的(按钮点了就跳转,规则命中就执行),而 AI 功能是概率性的(同一个问题,模型今天答对,明天可能答错)。
这个本质差异,决定了 AI PRD 必须新增几个传统 PRD 里没有的章节。
传统 PRD vs AI PRD:多出来的章节
#KfVlDnkCWlJN text { white-space: pre; }#KfVlDnkCWlJN .fb0 { stroke: var(--N900-FG, 0.15); }#KfVlDnkCWlJN .fb0 {stroke: rgba(31,35,41, 0.15)}#KfVlDnkCWlJN .fx0 { stroke-miterlimit: 10; }#KfVlDnkCWlJN .fx0 {stroke-miterlimit: 10}#KfVlDnkCWlJN .fa1 { fill: rgb(187, 191, 196); }#KfVlDnkCWlJN .fa1 {fill: rgb(187, 191, 196)}#KfVlDnkCWlJN .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#KfVlDnkCWlJN .fx1 {font-style: normal}#KfVlDnkCWlJN .fx2 { text-anchor: middle; }#KfVlDnkCWlJN .fx2 {text-anchor: middle}#KfVlDnkCWlJN .fx3 { dominant-baseline: central; }#KfVlDnkCWlJN .fx3 {dominant-baseline: central}#KfVlDnkCWlJN .fx4 { stroke: none; }#KfVlDnkCWlJN .fx4 {stroke: none}#KfVlDnkCWlJN .fc0 { fill: var(--text-caption); }#KfVlDnkCWlJN .fc0 {fill: #646a73}#KfVlDnkCWlJN .fa2 { fill: var(--text-link-disabled); }#KfVlDnkCWlJN .fa2 {fill: rgb(187, 191, 196)}#KfVlDnkCWlJN .fx5 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#KfVlDnkCWlJN .fx5 {font-style: normal}#KfVlDnkCWlJN .fx6 { text-anchor: start; }#KfVlDnkCWlJN .fx6 {text-anchor: start}#KfVlDnkCWlJN .fx7 { dominant-baseline: alphabetic; }#KfVlDnkCWlJN .fx7 {dominant-baseline: alphabetic}#KfVlDnkCWlJN .fc1 { fill: rgb(31, 35, 40); }#KfVlDnkCWlJN .fc1 {fill: rgb(31, 35, 40)}#KfVlDnkCWlJN .fb1 { fill: var(--N900-FG, 0.15); }#KfVlDnkCWlJN .fb1 {fill: rgba(31,35,41, 0.15)}#KfVlDnkCWlJN .fb2 { fill: rgb(209, 217, 224); }#KfVlDnkCWlJN .fb2 {fill: rgb(209, 217, 224)}#KfVlDnkCWlJN .fa3 { fill: var(--bg-body); }#KfVlDnkCWlJN .fa3 {fill: #fff}ABC123456789传统 PRD 章节需求背景与目标用户故事 / 交互流程功能规格(字段、状态、边界条件)验收标准上线计划埋点与数据指标——AI PRD 是否需要需要,不变需要,但要加"AI 判断失败时怎么办"的分支需要,但边界条件从"参数校验"变成"能力边界"传统 PRD 是"功能跑通即验收";AI PRD 不能这样验收需要需要,但要新增模型层指标—Agent / 工具型功能额外需要AI PRD 额外新增—兜底交互流程能力边界与不承诺清单效果定义章节(核心新增)数据需求与回流设计、成本预算章节评测集与及格线Prompt Spec + Eval Spec(把效果定义落成可执行规格)Agent 行为边界(可调用什么、何时必须停)
可以看到,AI PRD 不是把传统 PRD 推倒重来,而是在原有骨架上,把"验收标准"从一句话("功能正常可用")展开成效果定义、能力边界、数据回流、成本等章节;对生成式 / Agent 功能,还要把效果定义进一步落成 Prompt Spec + Eval Spec,并把有副作用的自主行为写成可验收的边界。
下面先拆解基础新增章节,再写规格落地与文档协作
一、效果定义章节:怎么写
这是 AI PRD 与传统 PRD 最大的分野。
传统功能的验收是二元的(能用/不能用),AI 功能的验收是一个分布——你要先定义"够好"是什么样子,再证明模型/系统达到了这个水位。
一个完整的效果定义章节,至少要包含三块:
目标指标(要分层,不能只写一个"准确率")
#PTqDWLPmPfPQ text { white-space: pre; }#PTqDWLPmPfPQ .fb0 { stroke: var(--N900-FG, 0.15); }#PTqDWLPmPfPQ .fb0 {stroke: rgba(31,35,41, 0.15)}#PTqDWLPmPfPQ .fx0 { stroke-miterlimit: 10; }#PTqDWLPmPfPQ .fx0 {stroke-miterlimit: 10}#PTqDWLPmPfPQ .fa1 { fill: rgb(187, 191, 196); }#PTqDWLPmPfPQ .fa1 {fill: rgb(187, 191, 196)}#PTqDWLPmPfPQ .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#PTqDWLPmPfPQ .fx1 {font-style: normal}#PTqDWLPmPfPQ .fx2 { text-anchor: middle; }#PTqDWLPmPfPQ .fx2 {text-anchor: middle}#PTqDWLPmPfPQ .fx3 { dominant-baseline: central; }#PTqDWLPmPfPQ .fx3 {dominant-baseline: central}#PTqDWLPmPfPQ .fx4 { stroke: none; }#PTqDWLPmPfPQ .fx4 {stroke: none}#PTqDWLPmPfPQ .fc0 { fill: var(--text-caption); }#PTqDWLPmPfPQ .fc0 {fill: #646a73}#PTqDWLPmPfPQ .fa2 { fill: var(--text-link-disabled); }#PTqDWLPmPfPQ .fa2 {fill: rgb(187, 191, 196)}#PTqDWLPmPfPQ .fx5 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#PTqDWLPmPfPQ .fx5 {font-style: normal}#PTqDWLPmPfPQ .fx6 { text-anchor: start; }#PTqDWLPmPfPQ .fx6 {text-anchor: start}#PTqDWLPmPfPQ .fx7 { dominant-baseline: alphabetic; }#PTqDWLPmPfPQ .fx7 {dominant-baseline: alphabetic}#PTqDWLPmPfPQ .fc1 { fill: rgb(0, 0, 0); }#PTqDWLPmPfPQ .fc1 {fill: rgb(0, 0, 0)}#PTqDWLPmPfPQ .fb1 { fill: var(--N900-FG, 0.15); }#PTqDWLPmPfPQ .fb1 {fill: rgba(31,35,41, 0.15)}#PTqDWLPmPfPQ .fb2 { fill: rgb(209, 217, 224); }#PTqDWLPmPfPQ .fb2 {fill: rgb(209, 217, 224)}#PTqDWLPmPfPQ .fa3 { fill: var(--bg-body); }#PTqDWLPmPfPQ .fa3 {fill: #fff}ABC1234指标层级模型层指标产品层指标业务层指标举例准确率、召回率、BLEU/ROUGE、幻觉率任务完成率、人工介入率、用户采纳率(是否直接使用 AI 输出而不修改)留存、转化、人效节省、投诉率谁来看算法团队日常调优PM 判断功能是否达标老板判断这个功能值不值得做
三层指标要写清楚因果链条假设,例如:"模型准确率从 85% 提到 92% → 人工复核率从 40% 下降到 15% → 客服人效提升 20%"。这条链条本身就是需要在效果定义章节里明确写出、后续验证的假设,而不是想当然。
评测集(测试集从哪来、怎么维护)
•
来源:历史真实数据(优先)、人工构造的边界 case、竞品/业界公开 benchmark(仅作参考,不能替代业务数据)
•
规模与代表性:至少覆盖高频场景 + 长尾困难场景 + 已知的历史 bad case;避免"测试集全是简单题"导致的虚假高分
•
标注标准:谁来定"这个回答算对";主观任务(如文案生成)要写清打分维度和评分细则,而不是"看着还行"
•
更新机制:评测集不是一次性交付物,业务变化、新 bad case 出现后要迭代;写清楚"谁负责评测集的持续维护"
及格线(Pass Bar):上线前必须明确的数字
及格线要写成可验证的具体数字,而不是"效果要好"这种无法验收的话。例如:
•
核心场景准确率 ≥ 90%,且 P0 高风险场景(如涉及金额、合规)准确率 ≥ 99%
•
幻觉率(编造事实的比例)≤ 2%
•
人工介入率(转人工/拒答比例)首月 ≤ 30%,并有季度下降计划
•
P95 响应延迟 ≤ 3 秒
及格线要区分"上线线"和"目标线":上线线是不达标就不能上线的红线,目标线是长期优化方向。两条线混为一谈,是很多 AI 项目"效果不够也硬上"的根源——这也是 AI 产品如何判断 PMF、如何冷启动、兜底策略怎么设计? 里提到的典型踩坑场景。
二、能力边界与不承诺清单
传统 PRD 的"功能边界"写的是参数范围(如"最多上传 10 张图");AI PRD 的"能力边界"写的是这个功能不擅长、甚至不该用来做什么。这一节最容易被忽略,却是防止用户预期跑偏、防止业务方"既要又要"的关键武器。
建议按下面的结构写:
这一节本质上是在做"提前透露局限性",避免上线后被用户投诉"说好的智能客服怎么这都不会"。这个思路可以直接类比 Anthropic、OpenAI 发布模型时的 System Card(系统卡)——下文详细展开。
三、数据需求与回流设计
AI 功能上线不是终点,而是"数据飞轮"的起点。这一节要写清楚三件事:
冷启动数据从哪来:历史日志、人工标注、专家写的种子数据、第三方数据采购——分别写明来源、数量级、质量把控方式。
线上数据怎么回流:用户的每一次点赞/点踩/编辑/转人工,都是潜在的训练/评测信号,要在 PRD 里明确"这些行为数据流向哪个系统、多久处理一次、谁负责看 bad case"。
数据合规红线:哪些用户数据可以用于模型迭代,是否需要脱敏,是否需要用户授权——这条不写清楚,后期极易埋雷。
四、成本预算章节
传统 SaaS 功能上线后,多一个用户的边际成本趋近于零;AI 功能不同,每一次用户请求都在真金白银地花钱(token 消耗)。这一节至少要写清楚:
五、把效果定义落成 Prompt Spec + Eval Spec
前面的效果定义回答的是"好到什么程度才算做完"(指标、评测集来源、及格线)。落到工程协作时,还差一层:这些要求如何变成研发每天能跑、能回归的规格? 行业里常把这两份配套规格叫做 Prompt Spec 与 Eval Spec——它们不是替代背景、用户故事、数据与成本等章节,而是把"概率性验收"从形容词改成可执行合同。
事实:Anthropic 平台文档把"先定义成功标准、再建评测"作为模型迭代闭环的起点;其工程文章指出,早期把产品要求写成评测任务,能检验需求是否足够具体,远比事后从线上系统反推成功标准便宜,并建议把评测当作与单元测试同级的常规产品工件。见文末参考资料。
两份规格各自回答什么
两者必须成对出现:没有 Eval Spec 的 Prompt Spec 只是愿望清单;没有 Prompt Spec 约束的 Eval Spec 容易测到"碰巧好看"的偶然输出。评测集怎么建、rubric 怎么写,方法论见 从零建设评测集;Prompt 如何版本化、改一词如何强制回归,见 系统提示词设计与 Prompt 工程化。本节只约定 PRD 里要交付什么字段。
和「效果定义」怎么衔接(避免写两遍)
写的时候用链接引用上一节的指标表,不要在 Prompt Spec 里再抄一遍"留存提升 XX%"这类业务叙事。
最小可交付字段清单
Prompt Spec(最小集)
•
场景与用户目标(一句话)
•
系统层身份、语气、能力边界(指向能力边界清单)
•
输入:允许的字段 / 上下文来源;禁止或需脱敏的内容
•
输出:格式、必含字段、长度或结构约束;失败时的固定话术
•
正反例各若干条(足以校准"好/坏",不必上百)
•
变更规则:谁可改、改后必跑哪份 Eval、灰度与回滚入口
Eval Spec(最小集)
•
用例分层:典型 / 边界 / 高风险(比例按业务风险调,方法见评测集正课)
•
每条用例的判定方式与及格定义
•
与产品层指标的映射(例如"采纳率"对应哪些隐式信号,离线测什么代理指标)
•
门禁:上线红线、一票否决(安全/合规)、目标线
•
回归策略:何种变更触发全量 / 冒烟;失败时阻断合并还是仅告警
Agent 类任务还要在 Eval Spec 里区分最终结果与轨迹(是否越权调用工具、是否跳过确认)——评测设计细节见 Agent 评测与可观测性,PRD 侧至少要写明"轨迹类失败是否一票否决"。
六、Agent 行为边界怎么写进 PRD
能力边界管的是"答什么 / 不答什么";Agent 行为边界管的是"可以动什么、动到哪必须停"。有工具调用、会改工单/邮件/配置/资金时,缺这一节等于把授权范围交给模型临场发挥。
生产化侧的任务卡、工具契约、状态机、风险分级,正课已写在 Agent 产品生产化;交互侧的确认、进度、可撤销见 Agentic UX 与信任校准。PRD 不需要重复整份状态机,但必须把团队共同认可的授权合同写进可验收条目。
PRD 里建议固定的六块
写法对照(抽象 vs 可验收)
和 Prompt Spec / Eval Spec 的咬合
•
Prompt Spec:用自然语言重申"不得绕过确认、不得扩大工具范围",但真正的硬边界在工具服务端鉴权与产品状态机,不能只写在 Prompt 里。
•
Eval Spec:准备"诱导越权 / 跳过确认 / 预算耗尽"类用例;轨迹违规可设为一票否决。
•
能力边界清单:继续写清对用户承诺的场景范围;行为边界写清对系统动作的授权——两张表并存。
七、PRD 里该不该写 Prompt?
结论先说:该写"行为合同",不必把线上最终 Prompt 全文钉死在 PRD 里;写了也不等于研发不用做设计。
分工建议
因此:PRD 里写了 Prompt Spec,不取消交互设计,也不取消工程上的 Context / 工具设计——它只是把"系统在目标场景下应如何表现"写成可评测的说明书。版本管理、灰度、回归流程仍按 Prompt 工程化 执行;PRD 负责点名这些门禁存在,而不是替代工具链。
八、AI 需求文档该写到多细?
粒度的目标不是"越细越好",而是:开发按文档做出来的行为分布,能被同一份 Eval Spec 判定为通过或失败。写粗了,团队用直觉填洞;写细到实现细节,PM 变成影子工程师,且跟不上每周的 Prompt 迭代。
粒度标尺
正式排期的 AI 功能,PRD 至少稳在 L2–L3;L4 放进版本库,用链接引用。
写粗了会乱做时,补这四样(而不是补成长篇小说)
补正反例:比再写三段形容词更有效——各 5–10 条真实或构造 case,标明期望动作(答 / 拒 / 转人工 / 先确认)。
补一票否决:安全、合规、越权、不可逆误操作——写进 Eval Spec 门禁。
补完成证据:尤其 Agent,"完成"依赖工具回执还是人审,写死。
补变更门禁:谁能改 Prompt / 工具权限;改完必须跑哪份回归。
若上述四样齐全而实现仍漂移,问题多半在所有权与门禁未执行,而不是文档字数不够。
和模板的关系
下文模板把 Prompt Spec、Eval Spec、Agent 行为边界收成独立小节,便于评审勾选;小功能可把 Prompt Spec 嵌在效果定义下,但Eval 门禁与高风险行为边界不要省略。
类比:向 Model Card / System Card 学"效果怎么披露"
Anthropic 和 OpenAI 每次发布新模型,都会同步发布一份 System Card(系统卡,早期也叫 Model Card)。以 2026 年 Anthropic 发布的 Claude Sonnet 5 System Card、Claude Opus 4.6/4.8 System Card,以及 OpenAI 的 GPT-5 系列 System Card 为例,它们的公开结构通常包含:能力评测结果(在哪些 benchmark 和"生产场景真实困难案例"上的表现)、安全评估(红队测试、滥用风险测试)、已知局限性、以及负责任部署决策(在什么条件下才允许开放什么能力)。
这套披露逻辑,和 AI PRD 里"效果定义 + 能力边界"两节想解决的问题几乎一模一样:不是等用户发现模型不会什么,而是主动、具体地讲清楚模型能做什么、不能做什么、在什么水位上是可信的。区别在于系统卡面向的是外部世界和监管,AI PRD 面向的是内部团队和验收流程,但"用具体数字和具体场景说话,而不是用形容词"这条原则是相通的。写效果定义章节卡壳时,不妨反问自己:如果要把这个功能的效果写成一份对外的"系统卡",你有没有底气写出具体的评测结果和边界说明?写不出来,往往说明效果定义还不够扎实。
AI PRD 章节模板(可直接套用)