PRD 从零写一份：AI 功能需求文档怎么搭
掌握一份 AI 功能 PRD 的标准骨架，以及 AI 产品特有的三节，学会把一句话需求推到一页可验收的文档
- 说清一份 PRD 的九大标准骨架分别解决什么问题
- 掌握 AI 产品 PRD 特有的三节：模型兜底、禁答清单、预期管理
- 学会把验收标准写到“可测、可判定”的程度
- 判断原型画到什么程度够用，不盲目追求高保真
写 PRD 到底在写什么
把 PRD 想成两份东西合在一起：一份菜谱（告诉研发做什么、按什么顺序做），加一张验收单（告诉测试和自己，做成什么样才算数）。菜谱管“怎么做出来”，验收单管“做对没有”。初中写 if/else 分支时要把每个分支和边界都想清楚，画业务流程图同理——主流程走通，异常分支一个都不能漏。
PRD 的九大标准骨架
一份能直接开干的 PRD，通常按下面九块往下写，缺一块，后面就会返工一次。
背景与问题：现在遇到什么痛点、为什么现在要做。
量化目标：做完之后哪个数字变好、变好多少（示例口径，上线前需对齐真实基线）。
用户故事：作为谁，我想做什么，以便得到什么价值。
功能清单：这个版本到底做哪几件事、不做哪几件事。
业务流程：主流程一步步怎么走，配一张流程图。
异常流：模型挂了、超时、没网、用户乱输，分别怎么办。
边界 case：极端输入、超长文本、敏感词、空内容怎么处理。
验收标准：一条条可测、可判定的“做到这样算过”。
埋点需求：在哪些节点埋什么数据，上线后靠什么数字判断成败。
举例：老板说“给智能客服加个自动回复”。先补背景（人工客服夜间排队久、重复问题多），再补目标（夜间自助解决率从 30% 提到 60%），再拆用户故事和功能清单，画“用户提问→模型理解→置信度判断→回答或转人工”的流程，最后写清每条验收标准和埋点。一句话就长成了一页能执行的 PRD。
AI 产品 PRD 特有的三节
传统 PRD 写到上面九块基本够了，AI 产品必须再多写三节，因为模型输出是概率性的，不能假设它永远答对。
写清置信度低于多少阈值时不硬答、转人工或给固定话术。比如“当模型对用户问题的置信度低于 0.6 时，不生成答案，直接提示并转人工客服”。阈值不是拍的，要先拿一批真实问题实测，在准确率和兜底率之间取平衡。
明确列黑名单：退款金额承诺、医疗诊断、法律结论、账户密码操作、涉及具体金额的赔付，这类问题模型只能引导到人工或官方渠道，绝不能自由发挥。这张清单是合规红线，必须写死。
在界面上明示“以下内容由 AI 生成，仅供参考”，把用户预期从“这是官方标准答案”降到“这是 AI 的建议”。预期管理做好了，即使偶发错误，用户的不满也会小很多。
验收标准怎么写才算数
验收标准的唯一标准是“可测、可判定”：任何人拿着它，都能判断这一条到底过没过，不需要再开会讨论。
反面（没法判定）：“回复要尽量准确、友好。”——什么叫准确？吵起来。正面（可测）：“抽检 200 条真实会话，回答与知识库一致的比例不低于 90%；用户点‘未解决’的比例不高于 15%；转人工后无需重复描述问题的比例不低于 95%。”
原型画到什么程度够用
很多人纠结用 Figma 还是墨刀、要不要高保真，其实对 PRD 阶段来说，低保真就够：把页面有哪些区块、按钮点了跳到哪、异常态长什么样画清楚即可。交互流程是重点，视觉细节不是。把时间花在把流程和异常想明白上，比把按钮圆角画多大多小值钱得多。
PRD 常见误区：写了没人看、需求蔓延
第一个误区：写了没人看。PRD 写成 30 页大文档，研发只看前两页就开干，异常流和边界 case 全靠口头补。解法：把「这版必须做的事」压缩到一页开头，研发先看这一页，后面的细节是参考。第二个误区：需求蔓延（scope creep）。写着写着加个导出 Excel、加个深色模式、加个分享到微信，版本越滚越大，上线日期一拖再拖。解法：PRD 末尾明确写「本版不做」清单，每个新需求先问「它在这版的目标里吗」，不在就进下版。
评审会上有人说「顺手把 XX 也做了吧」开发中途加需求没人走变更流程版本快上线了还在加新功能出现任何一个，立刻拉回去：新需求进需求池，不进这版。
验收标准怎么写才可测试：Given-When-Then
前面讲了「尽量准确」没法判定，教你一个可复用的句式：Given-When-Then（given 前置条件 → when 用户做了什么 → then 系统应该怎样）。每条验收标准都套这个模板，任何人一看就知道怎么测。举例：Given 用户问「怎么退款」，When 模型置信度 ≥ 0.7，Then 模型给出知识库中的退款步骤并标注来源；When 置信度 < 0.6，Then 不生成答案，直接转人工。
Given（前置条件）：用户是谁、处于什么状态When（触发动作）：用户做了什么 / 系统收到什么输入Then（可测结果）：系统应该输出什么、达到什么数字每条都要能写成一个测试用例，写不成测试用例的验收标准就是废话。
PRD 评审会怎么开
评审会不是朗读会。会前：PRD 提前 24 小时发给研发和测试，让他们先看。会上：PM 只讲 5 分钟背景和核心流程，剩下时间全部用来挑刺——异常流想全了吗？验收标准能不能测？边界 case 覆盖了吗？会后：把会上争出的结论写回 PRD，别只存在会议室里。最怕的是会上没人说话、开发做到一半才说「这我没想过」。
下面哪一项是 AI 产品 PRD 相对传统 PRD 必须额外写的？
下面这段 PRD 验收标准「AI 客服回复要尽量准确、友好」最大的问题是什么？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
先建成本模型：单用户每月调用次数 × 平均 token × 单价，再叠加缓存命中率、模型分级带来的折扣，得到边际成本；定价（订阅/按次/积分）必须让客单价稳定覆盖它并留出毛利。很多 AI 产品死于「重度用户把额度用穿」——因此要设计用量上限、公平使用策略和高价值功能的分层，把成本增长曲线握在自己手里。