AI功能写进PRD：产品经理的新分水岭与可复用模板

1. 为什么“AI功能写进PRD”成了产品经理的新分水岭这两年做产品的同行应该都有同感需求文档里不带点AI好像就落伍了。但真到落笔的时候问题全来了——模型输出不稳定怎么描述准确率写多少算合格验收标准怎么写才不会被研发和算法团队来回踢皮球我见过太多PRD里写着“智能推荐相关内容”“自动识别用户意图”这种话看着挺唬人实际上研发看完一脸问号算法同学更是直接反问“你到底要我做到什么程度”这就是当前AI功能写进PRD最核心的痛点传统PRD的确定性思维和AI功能的不确定性本质之间存在结构性冲突。传统功能是“输入A必然得到B”PRD里写清楚规则、边界、异常分支就够了AI功能是“输入A大概率得到B但B的质量取决于模型、数据、阈值、上下文”你如果还按老套路写交付时必然扯皮。这篇内容我想聊的就是这件事把AI功能写进PRD到底该怎么组织结构、怎么定指标、怎么描述交互、怎么写验收。适合正在做AI产品落地的PM、想转AI方向的产品同学以及需要和产品对齐需求的算法、研发同学。我会从文档结构、指标设计、案例拆解、避坑经验几个层面展开尽量给到可以直接抄作业的模板和写法。先说一个我自己的判断AI功能进PRD本质不是“加一段功能描述”而是“重新定义需求的可验证性”。你写的每一句话都要能回答一个问题——交付时怎么判断它做没做到回答不了这段需求就是无效需求。2. AI功能PRD的整体结构与写法拆解2.1 传统PRD结构为什么不够用传统PRD的骨架大家都很熟背景目标、用户场景、功能描述、交互流程、异常处理、数据埋点、验收标准。这套结构对付确定性功能没问题但套到AI功能上会立刻暴露三个缺口。第一个缺口是能力边界缺失。传统功能里“能做什么”是产品定义的AI功能里“能做什么”很大程度是模型和数据决定的。你不写清楚能力边界研发会默认“什么都能做”最后交付一个“大部分情况还行、边缘情况稀碎”的东西验收时双方都难受。第二个缺口是质量维度缺失。传统功能验收看“功能是否可用”AI功能验收必须看“效果是否达标”。准确率、召回率、响应时延、幻觉率、拒答率这些指标不写进PRD等于把质量定义权完全交给了算法团队产品在验收时没有任何话语权。第三个缺口是失败路径缺失。AI功能一定会失败这不是悲观是客观规律。模型会答错、会答偏、会答不出来。传统PRD的异常处理写的是“网络断了怎么办”AI功能PRD的异常处理要写“模型置信度低怎么办、输出不合规怎么办、用户连续追问超出能力范围怎么办”。这块不写上线后就是线上事故。我一般会在传统结构基础上做三处改造在功能描述前加能力说明与边界在验收标准里加效果指标与评测方案在异常处理里加降级与兜底策略。这三块是AI功能PRD和传统PRD最本质的区别。2.2 一份可复用的AI功能PRD骨架下面这个骨架是我自己反复用过的可以直接拿去改。它不追求大而全追求的是“每一节都能回答一个交付问题”。章节核心要回答的问题与传统PRD的差异功能背景与目标为什么要做AI不用AI行不行需说明AI的必要性与替代方案对比能力说明与边界这个AI能做什么、不能做什么新增必须明确能力范围用户场景与输入输出用户怎么用、输入什么、期望输出什么需覆盖输入多样性效果指标定义做到什么程度算合格新增量化质量交互与失败路径效果不好时用户看到什么需设计降级体验评测与验收方案怎么测、谁来测、测多少新增可执行评测数据与迭代机制上线后怎么持续变好新增闭环设计这张表里能力说明与边界、效果指标定义、评测与验收方案这三行是重中之重。我见过太多PRD在这三块留白结果就是需求评审时大家点头交付时集体沉默。2.3 能力边界怎么写才不空洞“能力边界”这四个字很容易写成空话。我建议用**“能做/不做/有条件做”三段式**来写每一条都落到具体场景。举个例子假设你在做一个“智能客服问答”功能。能力边界可以这样写能做回答产品使用类问题覆盖帮助中心已有文档范围支持多轮追问单次会话不超过5轮对无法回答的问题明确告知并转人工。不做不处理订单退款、账号安全等涉及资金和隐私的操作类请求不对竞品做评价不提供法律、医疗等专业建议。有条件做对模糊问题先做澄清追问澄清后仍无法匹配则转人工对超出知识库但语义相近的问题允许给出“可能相关”的参考回答并标注不确定性。这种写法的好处是研发和算法一看就知道边界在哪测试同学也知道该测哪些“不该发生的事”。边界不是限制产品而是保护交付。你不写别人就会替你假设而假设往往是错的。3. 效果指标AI功能PRD里最容易被写废的部分3.1 指标不是越多越好要分层很多PM一写AI指标就堆一堆准确率、召回率、F1、BLEU、ROUGE、时延、吞吐……写了一大页研发看完不知道重点在哪。我的经验是指标分三层业务指标、效果指标、工程指标。三层各司其职不要混在一起。业务指标回答“这个功能对业务有没有用”。比如客服场景的转人工率下降多少、自助解决率提升多少、用户满意度变化。这类指标是给业务方看的决定功能值不值得继续投入。效果指标回答“模型输出质量够不够”。比如问答准确率、意图识别准确率、回答相关性、幻觉率。这类指标是给算法和产品共同看的决定模型要不要继续调。工程指标回答“系统扛不扛得住”。比如P95响应时延、并发承载、可用性。这类指标是给研发看的决定上线节奏。三层指标的关系是工程指标保底线效果指标保质量业务指标保价值。PRD里三层都要有但重点篇幅应该放在效果指标上因为这是AI功能特有的部分。3.2 效果指标怎么定才可执行定效果指标最容易犯的错是“拍脑袋写个95%”。95%准确率意味着什么在什么数据集上测谁来标注样本怎么抽这些不写清楚95%就是个数字游戏。我一般按这个顺序定指标先定评测集。没有评测集就没有指标。评测集要说明来源真实日志抽样/人工构造/公开数据集、规模至少几百条起步、标注规范谁来标、标几轮、分歧怎么处理。再定指标口径。准确率是“完全正确”还是“语义正确即可”相关性是二分类还是分级打分口径不同数字差很多。然后定目标值。目标值要有依据可以参考行业基线、竞品表现、历史版本、人工基线。我特别推荐人工基线——先让真人做同样的任务看人能做到多少AI目标值定在人工基线的合理比例上比拍脑袋靠谱得多。最后定评测频率。是一次性评测还是持续评测每次模型更新是否重跑这些要写进PRD的迭代机制里。举个具体写法“问答准确率目标≥85%评测集为近30天真实用户问题抽样500条由两名标注同学独立标注分歧样本由第三人仲裁准确率口径为‘回答核心信息正确且无事实性错误’上线前完成首轮评测模型每次重大更新后重跑。”这段话看着啰嗦但它把“85%”这个数字变得可验证、可复现、可追责。指标的可执行性比指标的数字大小重要得多。3.3 别忽略“负向指标”大部分PRD只写正向指标比如准确率要高、时延要低。AI功能还必须写负向指标也就是“不能发生什么”。这类指标往往比正向指标更能保护用户体验。常见的负向指标包括幻觉率编造事实的比例、有害输出率、拒答率上限拒答太多用户体验差、超范围回答率问了不该答的却答了。这些指标要设上限而不是只设下限。我踩过一个坑早期做知识问答只盯准确率结果模型为了“答对”开始编造准确率看着还行但幻觉率很高用户投诉“一本正经胡说八道”。后来在PRD里加了“幻觉率≤3%”的硬约束算法团队才开始认真做拒答和不确定性标注。负向指标是AI功能的刹车没有刹车的车没人敢开。4. 从案例看完整写法一个智能问答功能的PRD拆解4.1 案例背景与需求定义假设我们要做一个“产品帮助中心智能问答”功能用户在产品内提问系统基于帮助文档给出回答答不了转人工。这个案例足够典型覆盖了AI功能PRD的大部分关键点。需求定义部分要写清楚三件事用户问题是什么、现有方案为什么不够、AI方案的价值在哪。现有方案是关键词搜索帮助文档问题是用户不会用关键词、搜索结果需要自己翻、多轮问题无法处理。AI方案的价值是自然语言理解、直接给答案、支持追问。这段不是走过场它决定了后面所有指标的方向——既然价值是“直接给答案”那准确率和相关性就是核心指标既然要“支持追问”那多轮上下文保持就是必须写的能力。4.2 能力边界与交互设计的具体写法能力边界按前面说的三段式写。交互设计这块AI功能有个特殊要求必须设计“不确定态”的呈现。传统功能要么成功要么失败AI功能有中间态——模型有点把握但不太确定。这个状态怎么呈现给用户是PRD必须定义的。我的写法是定义三档置信度对应三种交互高置信直接给答案附来源文档链接。中置信给答案但加“仅供参考”提示同时展示相关文档列表供用户自行判断。低置信/无匹配不给答案直接展示“没找到确切答案是否转人工”并提供相关文档入口。这三档的阈值怎么定PRD里不写死具体数值但要写“阈值由算法团队基于评测集调优确定产品参与评审”。这样既尊重了算法专业性又保留了产品的把关权。阈值是算法参数但阈值对应的用户体验是产品责任这个分工要在PRD里说清楚。4.3 评测方案与验收清单评测方案是AI功能PRD的收尾重头戏。我一般写四块评测集、评测指标、评测流程、验收标准。评测集真实问题抽样500条人工构造边界问题100条覆盖多轮、模糊、超范围、有害等类型。评测指标准确率≥85%、相关性达标率≥90%、幻觉率≤3%、拒答合理率≥90%、P95时延≤2秒。评测流程算法自测→产品抽测→联合评审。验收标准所有指标达标且负向指标不超标方可上线任一负向指标超标需修复后重测。验收清单我习惯做成表格逐项打勾避免遗漏验收项标准责任人结果准确率≥85%算法待测幻觉率≤3%算法待测拒答合理率≥90%产品待测降级体验三档置信交互正常研发待测转人工链路低置信可一键转人工研发待测这张表看着简单但它把“验收”从一句口号变成了可执行的动作。我强烈建议每份AI功能PRD都附一张这样的清单。5. 实操避坑那些文档里不会写的经验5.1 需求评审时最容易被挑战的三个点第一个是“为什么不用规则做”。评审时一定有人问这个。你要提前准备好对比规则方案覆盖多少场景、维护成本多高、遇到长尾问题怎么办。AI不是万能但在这类自然语言场景里规则的维护成本会随场景增长指数上升这是你要讲清楚的逻辑。第二个是“效果达不到怎么办”。这个问题必须有预案。我的回答模板是分阶段上线先小流量验证核心指标达标后扩量同时保留规则兜底和人工兜底确保效果不达标时用户体验不崩。AI功能上线不是开关是旋钮这个认知要在评审时同步给所有人。第三个是“数据从哪来”。AI功能强依赖数据评测集、训练数据、日志回流这些在PRD里要有交代。没有数据计划的AI功能PRD是不完整的。5.2 和算法团队对齐的实用技巧和算法同学协作最忌讳PM单方面定指标。我的做法是指标共创PM提出业务目标和初步指标算法评估可行性并给出技术约束双方一起定最终指标。这个过程要写进PRD的“指标定义”章节注明“指标经产品与算法联合评审确定”。另外PRD里要留一个**“模型依赖说明”**小节写清楚这个功能依赖什么模型能力、模型更新是否影响功能、模型不可用时怎么降级。这块很多PM会漏但它直接关系到线上稳定性。5.3 上线后的迭代闭环怎么设计AI功能上线不是终点。PRD里要写清楚数据回流和迭代机制用户反馈怎么收集点赞点踩、转人工记录、badcase怎么归集、多久复盘一次、模型多久更新一次。我一般建议设一个“效果监控看板”核心指标周度跟踪负向指标实时告警。还有一个容易被忽略的点PRD要写“功能下线或收缩的条件”。如果上线后业务指标长期不达标是继续投入还是收缩提前写好退出条件比事后扯皮体面得多。这不是悲观是负责任。6. 写在最后的一点个人体会做AI产品这两年我最大的感受是PRD写得好不好不看你描述得多智能看你能不能让“智能”变得可交付。AI功能的不确定性是客观存在的PM的价值不是消除不确定性而是把不确定性框定在可管理、可验证、可兜底的范围内。能力边界、效果指标、评测方案、降级策略这四样东西写扎实了一份AI功能PRD就立住了。另外分享一个小习惯我写完AI功能PRD后会自己扮演三个角色读一遍——研发读一遍看能不能开工测试读一遍看能不能写用例业务方读一遍看能不能理解价值。三个角色都能顺畅读下来这份文档才算过关。这个自检动作花不了多少时间但能挡掉大部分评审时的尴尬。这个框架后续还可以往两个方向扩展一是多模态功能图像、语音的PRD写法指标体系和评测方案会有差异二是Agent类功能的PRD涉及工具调用和任务编排能力边界和失败路径会更复杂。有机会再单独展开聊。