企业官网建设流程全解析

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在这三块留白，结果就是需求评审时大家点头，交付时集体沉默。

2.3 能力边界怎么写才不空洞

“能力边界”这四个字很容易写成空话。我建议用**“能做/不做/有条件做”三段式**来写，每一条都落到具体场景。

举个例子，假设你在做一个“智能客服问答”功能。能力边界可以这样写：

• 能做：回答产品使用类问题，覆盖帮助中心已有文档范围；支持多轮追问，单次会话不超过5轮；对无法回答的问题明确告知并转人工。
• 不做：不处理订单退款、账号安全等涉及资金和隐私的操作类请求；不对竞品做评价；不提供法律、医疗等专业建议。
• 有条件做：对模糊问题先做澄清追问，澄清后仍无法匹配则转人工；对超出知识库但语义相近的问题，允许给出“可能相关”的参考回答并标注不确定性。

这种写法的好处是，研发和算法一看就知道边界在哪，测试同学也知道该测哪些“不该发生的事”。边界不是限制产品，而是保护交付。你不写，别人就会替你假设，而假设往往是错的。

3. 效果指标：AI功能PRD里最容易被写废的部分

3.1 指标不是越多越好，要分层

很多PM一写AI指标就堆一堆：准确率、召回率、F1、BLEU、ROUGE、时延、吞吐……写了一大页，研发看完不知道重点在哪。我的经验是指标分三层：业务指标、效果指标、工程指标。三层各司其职，不要混在一起。

• 业务指标：回答“这个功能对业务有没有用”。比如客服场景的转人工率下降多少、自助解决率提升多少、用户满意度变化。这类指标是给业务方看的，决定功能值不值得继续投入。
• 效果指标：回答“模型输出质量够不够”。比如问答准确率、意图识别准确率、回答相关性、幻觉率。这类指标是给算法和产品共同看的，决定模型要不要继续调。
• 工程指标：回答“系统扛不扛得住”。比如P95响应时延、并发承载、可用性。这类指标是给研发看的，决定上线节奏。

三层指标的关系是：工程指标保底线，效果指标保质量，业务指标保价值。PRD里三层都要有，但重点篇幅应该放在效果指标上，因为这是AI功能特有的部分。

3.2 效果指标怎么定才可执行

定效果指标最容易犯的错是“拍脑袋写个95%”。95%准确率意味着什么？在什么数据集上测？谁来标注？样本怎么抽？这些不写清楚，95%就是个数字游戏。

我一般按这个顺序定指标：

1. 先定评测集。没有评测集就没有指标。评测集要说明来源（真实日志抽样/人工构造/公开数据集）、规模（至少几百条起步）、标注规范（谁来标、标几轮、分歧怎么处理）。
2. 再定指标口径。准确率是“完全正确”还是“语义正确即可”？相关性是二分类还是分级打分？口径不同，数字差很多。
3. 然后定目标值。目标值要有依据：可以参考行业基线、竞品表现、历史版本、人工基线。我特别推荐人工基线——先让真人做同样的任务，看人能做到多少，AI目标值定在人工基线的合理比例上，比拍脑袋靠谱得多。
4. 最后定评测频率。是一次性评测还是持续评测？每次模型更新是否重跑？这些要写进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秒。评测流程：算法自测→产品抽测→联合评审。验收标准：所有指标达标且负向指标不超标，方可上线；任一负向指标超标，需修复后重测。

验收清单我习惯做成表格，逐项打勾，避免遗漏：

这张表看着简单，但它把“验收”从一句口号变成了可执行的动作。我强烈建议每份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，涉及工具调用和任务编排，能力边界和失败路径会更复杂。有机会再单独展开聊。