AI 功能写进 PRD 这件事我见过太多团队栽在同一个坑里需求评审会上产品经理讲得眉飞色舞开发听完一脸茫然测试问“这个准确率怎么验”运营问“上线后看什么指标”最后文档一合谁也没记住到底要做个什么东西。传统功能的需求文档有成熟的套路——输入、输出、边界、异常照着填就行可一旦沾上模型、推理、生成、识别这些词很多人就不知道笔该往哪儿落了。要么写成技术方案把 prompt 和模型参数全塞进去开发看了觉得你在教他做事要么写成玄学描述“要智能”“要准确”“体验要好”落地时全靠猜。这篇东西就是想把这件事讲透。AI 功能如何写进 PRD核心不在于你懂多少算法而在于你能不能把“一个概率性的、有不确定性的能力”翻译成“可开发、可测试、可验收、可运营的产品需求”。我会从文档结构怎么搭、指标怎么定、边界怎么写、案例怎么拆这几个角度把我自己踩过的坑和总结出来的写法摊开讲。适合正在做 AI 产品、准备把模型能力接进业务的功能型 PM也适合那些被“智能需求”折磨过的开发和测试同学看完至少能在评审会上少吵两小时。1. 为什么 AI 功能一进 PRD 就容易写崩1.1 传统需求文档的假设在 AI 面前全部失效传统 PRD 的底层假设是确定性同样的输入系统永远给出同样的输出。你写“点击提交按钮订单状态变为已支付”开发照着做测试照着验天经地义。可 AI 功能的第一性原理是概率性——同一个问题问两遍模型可能给你两个不同的答案而且两个都不算错。这个根本差异会让传统文档里那些看似完备的章节瞬间失灵。我举个具体的。你写“用户输入问题系统返回答案”这句话在传统功能里是完整的在 AI 功能里等于什么都没说。返回什么长度的答案答不上来的时候是拒答还是硬编答案里带了不该带的内容怎么办响应时间是按首字算还是按整段算这些问题不写清楚开发只能自己拍脑袋拍出来的东西跟你脑子里的画面大概率对不上。更麻烦的是测试同学拿着这份文档根本没法设计用例——他没法验证“答案对不对”只能验证“有没有返回”这等于没测。所以写 AI 功能的 PRD第一件事是换脑子你不是在描述一个开关你是在描述一个“有脾气、有能力边界、会犯错”的协作对象。文档的每一节都要回答“当它不按预期工作时产品怎么兜底”。1.2 三类典型翻车现场几乎每个团队都遇到过我把见过的翻车归成三类你对号入座一下。第一类是技术越位。产品经理为了显得专业把模型选型、温度参数、prompt 模板全写进 PRD甚至连向量库用哪个都定了。结果开发一看就火了——这些是我的决策空间你定死了我还怎么优化更糟的是产品定的技术方案往往是拍脑袋的真跑起来效果不行锅还得开发背。PRD 该管的是“要什么效果”不是“用什么手段”。第二类是描述悬空。“智能推荐相关内容”“自动识别用户意图”“生成高质量的文案”这些词在评审会上人人点头散会后人人理解不同。什么叫高质量多长算合适识别错了算谁的没有可量化的锚点这些需求就是空中楼阁。我见过一个团队为了“生成文案要自然”这句话吵了三次会最后发现大家对“自然”的定义压根不一样。第三类是边界缺失。只写了正常路径没写异常路径。模型超时了怎么办返回内容触发了安全策略怎么办用户输入超出能力范围怎么办这些在传统功能里属于“异常处理”章节在 AI 功能里却是主路径的一部分——因为 AI 出错不是小概率事件是常态。你不写开发就默认“报错弹个 toast”用户体验直接崩。1.3 写清楚 AI 需求本质是在管理“不确定性”想明白一件事AI 功能 PRD 的核心价值不是“描述功能”而是“约定不确定性的处理方式”。模型一定会犯错问题不是消灭错误而是定义“错到什么程度可以接受、错了之后产品怎么表现、谁来兜底”。这个视角一转文档结构就清晰了。你需要约定能力的适用范围什么能做什么不能做、质量水位做到什么程度算达标、失败姿态做不好时怎么优雅地退、演进节奏第一版做到哪后面怎么迭代。这四件事写明白了开发和测试就有了共同语言评审会也就从“互相说服”变成了“对齐参数”。提示评审 AI 需求时如果文档里找不到“失败时怎么办”的段落基本可以判定这份 PRD 没写完。这是我最常用的一个快速判断标准。2. 一份能落地的 AI 功能 PRD 该长什么样2.1 结构骨架在传统 PRD 上做加减法我不建议另起炉灶搞一套“AI 专用模板”团队已有的 PRD 结构能复用就复用认知成本最低。要做的是加两节、改一节。加的第一节叫能力说明放在功能概述后面。用大白话讲清楚这个 AI 能力是什么、基于什么原理不用深一句话、擅长什么、不擅长什么。比如“基于语义匹配做相似内容召回擅长处理同义表达但对专业术语缩写识别较弱”。这一节是给开发和测试建立心理预期的让他们知道这东西的脾气。加的第二节叫质量与边界这是 AI PRD 的灵魂后面单独展开讲。改的那一节是交互流程——传统流程是线性的AI 流程要画成“分支树”正常返回是一条路低置信度是一条路拒答是一条路超时是一条路每条路都要有明确的界面表现。至于技术方案、模型参数这些统统不写进 PRD 正文最多在附录里放一句“技术实现由研发团队决策产品只约束输入输出契约”。这句话看着简单其实是给双方划清责任田能省掉大量扯皮。2.2 输入输出契约把“感觉”翻译成“字段”AI 功能最容易含糊的地方就是输入输出。用户到底能输入什么、系统到底吐出什么结构必须像 API 文档一样精确。我习惯用一个表格把契约钉死维度要写清楚的内容反例输入类型纯文本/图片/语音/结构化表单“用户输入内容”输入长度字符数上下限、超限如何处理“支持长文本”输入约束敏感词、格式、必填项无输出结构字段名、类型、是否可空“返回结果”输出长度字数范围、截断策略“简洁回答”输出格式纯文本/Markdown/JSON/卡片无这张表填完开发和测试心里就有底了。特别强调输出结构这一行——如果 AI 返回的内容要驱动下游逻辑比如抽取字段填表、分类打标签那输出必须是结构化的而且要在 PRD 里给出字段定义和示例。我见过太多项目在这里偷懒写一句“返回识别结果”结果开发返回一段自然语言下游根本没法用返工重来。2.3 交互流程要画成“分支树”而不是“直线”传统流程图是一条线走到底AI 流程图必须分叉。我通常要求至少画出四条分支高置信正常返回、低置信降级返回、拒答/无法处理、系统异常超时、限流。每条分支都要写清楚界面长什么样、给用户什么操作选项、日志记什么。拿一个“智能问答”功能举例。高置信时直接给答案并附来源低置信时给“我可能理解得不对你是想问这几个中的一个吗”并列出候选拒答时明确说“这个问题超出我的能力范围”并引导到人工或搜索超时时给“正在努力请稍候”并在 N 秒后转兜底。这四条路写清楚开发和设计就能并行开工不用反复来问“这种情况怎么办”。注意分支树里每一条“非正常路径”都要指定一个兜底动作。兜底不是“报错”是“用户还能继续完成任务”。这个区别决定了产品是可用还是不可用。3. 指标怎么写才不是自欺欺人3.1 效果指标和业务指标必须分开写这是我最想强调的一点。很多 PRD 把“准确率 90%”和“转化率提升 5%”混在一起写结果谁也说不清上线后到底该看哪个。效果指标衡量的是 AI 能力本身好不好比如准确率、召回率、相关性评分、人工评分业务指标衡量的是这个能力对业务有没有用比如任务完成率、采纳率、留存、转化。两者之间隔着一条河效果指标好不代表业务指标好反之亦然。PRD 里要分别列出这两组指标并且明确谁是验收指标、谁是观察指标。效果指标通常是验收指标达不到不能上线业务指标通常是观察指标上线后持续看。这个区分能避免一个常见悲剧效果指标达标了业务没起色团队却不知道该优化模型还是优化产品。3.2 效果指标怎么定从“可测”倒推“可写”定效果指标的正确姿势是先想怎么测再想怎么写。你写“回答要准确”测试同学没法测你写“在 500 条标注测试集上答案与标准答案语义一致的比例不低于 85%”这就可测了。所以每个效果指标都要配三样东西测试集怎么来、判定标准是什么、达标线定多少。测试集的来源要写清楚是历史真实数据抽样还是人工构造还是两者混合规模多大覆盖哪些场景判定标准要写清楚是人工逐条判还是用规则自动判还是模型辅助判多人判定时一致性怎么保证达标线要写清楚为什么是 85% 不是 90%这个数字背后要有依据——要么参考了同类功能的行业水位要么做了小样本预实验。我个人的经验是第一版功能的达标线宁可定低一点、定准一点也别定一个漂亮但达不到的数字。定 85% 能稳定达到比定 95% 天天救火强得多。达标线是承诺不是愿望。3.3 别忽略“体验指标”它才是用户真正感知到的效果指标是给团队看的体验指标是给用户感受的。同样准确率 90% 的两个功能一个响应 1 秒、一个响应 8 秒用户评价天差地别。所以 PRD 里必须有一组体验指标首字延迟、完整响应时长、超时率、重试率、用户主动中断率。首字延迟尤其重要。生成类功能里用户等的是“第一个字出来”的那一刻只要首字够快后面慢慢吐字用户是能接受的。我一般会把首字延迟压到 1 秒以内作为硬指标完整响应按内容长度分档给上限。超时率要单独盯因为它直接对应“用户白等了一场”的挫败感。指标类型示例指标典型达标线谁来盯效果指标语义一致率≥85%算法产品效果指标结构化字段抽取准确率≥92%算法体验指标首字延迟≤1s开发体验指标超时率≤2%开发运维业务指标结果采纳率观察项产品运营这张表建议直接放进 PRD评审时逐行过谁负责哪行当场认领比会后扯皮高效得多。4. 边界与失败姿态AI 功能 PRD 的良心所在4.1 能力边界要写成“正面清单负面清单”只写“能做什么”是不够的必须同时写“不做什么”。正面清单告诉开发要覆盖哪些场景负面清单告诉测试要重点验证哪些“不该发生的事”。比如一个文档摘要功能正面清单是“支持中英文、支持 5 万字以内、支持结构化输出”负面清单是“不处理扫描件 OCR、不做跨文档对比、不保证专业术语的翻译准确性”。负面清单的价值在于提前管理预期。用户拿着扫描件来用发现不行如果有负面清单这是“已知限制”如果没有这就是“产品缺陷”。一字之差客诉量差十倍。我习惯在 PRD 里单开一节叫“明确不支持的能力”写得越具体越好甚至配上“遇到这类输入时的提示文案”。4.2 失败姿态设计让“做不好”也体面AI 功能一定会遇到做不好的时候关键是做不好时产品怎么表现。我把失败姿态分成四档PRD 里要针对每一档给出明确的界面和文案完全不会明确告知能力边界给出替代路径搜索、人工、相关推荐。不确定坦诚表达不确定给出候选或追问澄清而不是硬编一个答案。部分正确标注哪些部分可信、哪些需要用户核对把判断权交还用户。系统故障超时、限流、服务不可用时给等待预期和兜底入口。这四档里“不确定”这一档最容易被忽略也最能体现产品功力。模型内部有置信度产品要决定“置信度低于多少就不硬答”。这个阈值要在 PRD 里写清楚并且说明依据。硬答的代价是用户信任的崩塌——一次明显的胡说八道可能让用户再也不信这个功能。4.3 安全与合规边界写进需求而不是事后补内容安全这块PRD 里必须有独立章节。要写清楚输入侧做哪些过滤敏感词、格式校验、长度限制输出侧做哪些校验内容审核、格式校验、事实性抽检命中策略后怎么处理拦截、改写、降级、转人工。这些不是“技术细节”是产品需求因为每一条都直接影响用户体验和业务风险。我特别提醒一点输出侧的安全校验要有“兜底不通过”的预案。校验本身也可能误判把正常内容拦了。所以要设计“用户申诉”或“人工复核”的通道不能让用户卡死在“内容不合规”的提示上无路可走。这个通道在 PRD 里哪怕只写两行上线后能救大命。5. 一个完整案例把“智能工单分类”写进 PRD5.1 需求背景与能力说明怎么写假设我们要做一个工单自动分类功能把用户提交的工单自动打上业务分类标签减少人工分拣。PRD 的能力说明这样写基于文本语义做多分类擅长处理描述清晰的工单对含大量错别字、口语化严重、跨多个业务域的工单识别较弱单条工单只输出一个主分类和一个置信度不做多标签。这段话说清了三件事原理语义多分类、强项、弱项。开发和测试看完就知道测试集要重点覆盖“错别字多”“跨域”这两类难例而不是平均用力。5.2 输入输出契约与分支流程输入契约工单标题必填5-100 字 正文必填10-2000 字 可选的历史交互记录。超长截断策略写明“保留前 2000 字”。输出契约category枚举值来自固定分类表、confidence0-1 浮点、fallback_reason可空拒答时填。分类表要在 PRD 附录里列全每个分类给两条示例工单。分支流程四条置信度 ≥0.8 直接落分类0.5-0.8 落分类但标记“待人工确认”0.5 不落分类进“待分拣池”由人工处理系统异常时全部进待分拣池并告警。每条分支的界面表现、日志字段、通知对象都写清楚。5.3 指标与验收标准效果指标在 1000 条历史工单测试集上主分类准确率 ≥88%其中高置信≥0.8部分的准确率 ≥95%。体验指标单条分类耗时 ≤500ms超时率 ≤1%。业务指标观察项人工分拣工作量下降比例、待确认队列的二次修正率。验收方式写明白测试集由历史数据分层抽样构成人工标注双人交叉校验分歧由第三人裁决。达标线 88% 的依据是“当前人工分拣准确率约 90%AI 辅助后允许略低但需人工兜底”。这个依据写进 PRD评审时没人会问“为什么是 88%”。6. 评审与迭代文档写完只是开始6.1 评审会上必须对齐的四件事PRD 写完不等于落地评审会才是真正的对齐场。我建议在会上强制对齐四件事能力边界认不认、指标口径认不认、失败姿态认不认、验收方式认不认。这四件事逐条过每条都要有明确的负责人点头不能含糊过去。特别提醒指标口径。同一个“准确率”算法理解的是“模型输出与标注一致”产品理解的是“用户觉得对”测试理解的是“用例通过率”。三个口径能差出十几个点。评审会上必须把口径定义念一遍让所有人用同一把尺子。6.2 上线后的迭代节奏怎么在 PRD 里预留AI 功能不是一次交付是持续调优。PRD 里要预留迭代节奏第一版做到什么程度、观察多久、根据什么数据决定下一版方向。我通常写一个“演进规划”小节列出 V1 的能力范围和达标线、V1.1 计划补的难例场景、V2 可能扩展的能力。这不是画饼是给团队一个“知道往哪走”的路线图也方便运营提前准备话术。最后分享一个我自己的习惯每份 AI 功能 PRD 的最后一页我会留一个“已知风险清单”把“模型可能在这几种情况下出错”明明白白列出来附上缓解措施。这一页在评审时往往最受开发欢迎——它证明产品是真的想过失败而不是只画了成功的饼。文档写得好不好不看正常路径多漂亮看异常路径多周全。