第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
AI产品经理实战训练营 · 章节 33/44 · 60 学时
33.1 AI产品的PRD和传统产品PRD有什么不同？
PRD（Product Requirements Document，产品需求文档）是产品经理的核心产出，是连接产品需求和技术实现的桥梁。传统产品的PRD已经有成熟的方法论，但AI产品的PRD有很大不同——如果用传统PRD的方式写AI产品需求，技术团队会无从下手，做出来的效果也会和预期差很远。
33.1.1 传统PRD的核心假设
传统产品PRD建立在几个假设之上：
- 功能确定性：需求是确定的，"做什么功能"是明确的，技术团队只要按需求实现就行
- 效果可预期：功能做出来后效果是可预期的，"点击按钮就跳转页面"、"提交表单就保存数据"，不会有意外
- 验收标准明确：功能有没有做出来，测试用例一跑就知道，标准明确
- 数据是副产品：数据是用户使用产品产生的，不是产品功能的前提条件
- 技术可行性可判断：技术团队能比较准确地判断"能不能做"、"多久能做"、"成本多少"
33.1.2 AI产品PRD的特殊挑战
AI产品打破了传统PRD的所有假设：
1. 功能不确定，效果更不确定
传统产品说"做一个搜索功能"，技术团队知道怎么做。但AI产品说"做一个智能客服，能自动回答用户问题"，技术团队面临很多不确定：
- 用什么模型？通用大模型还是微调？效果能到多少？
- 需要什么数据？知识库怎么建？数据从哪来？质量如何？
- 准确率能到多少？80%？90%？用户能接受吗？
- 回答不好怎么办？有没有兜底？人工怎么介入？
2. 验收标准不明确
传统功能的验收标准很明确："点击按钮跳转到列表页，列表显示10条数据，分页正常"。但AI功能的验收标准很难定义：
- "回答准确"——什么叫准确？100个问题答对多少个算准确？
- "用户满意"——怎么衡量满意度？多少分算满意？
- "响应快"——多快算快？2秒？5秒？
- "体验好"——什么叫体验好？怎么量化？
3. 数据是前提，不是副产品
传统产品的数据是用户使用后产生的，AI产品的数据是功能的前提——没有训练数据、没有知识库、没有测试集，AI功能根本做不出来，或者效果很差。
但很多PRD不写数据需求，技术团队开发到一半才发现"没有数据"，项目卡住，或者临时找数据凑数，效果一塌糊涂。
4. 技术可行性难判断
传统功能的技术可行性比较好判断（"做一个支付功能"，技术团队知道能不能做、多久能做）。但AI功能的技术可行性很难判断：
- "AI能自动写代码"——能写到什么程度？简单的可以，复杂的不行？边界在哪？
- "AI能诊断疾病"——准确率能到多少？能不能商用？有没有合规风险？
- "AI能做视频生成"——效果怎么样？成本多高？实时性如何？
5. 需要持续迭代，不是一次性交付
传统功能开发完成上线后，基本就稳定了，后续只是修bug和小优化。但AI功能上线只是开始：
- 需要持续收集用户反馈，优化Prompt和模型
- 需要持续积累数据，微调模型，提升效果
- 需要持续监控效果，发现bad case，持续优化
- 模型会升级，技术会变化，需要持续跟进
33.2 AI产品PRD的核心结构
一份完整的AI产品PRD应该包含以下部分：
33.2.1 背景与目标
为什么做这个需求？
- 业务背景：当前业务遇到什么问题？为什么需要AI来解决？（如"客服成本高、响应慢、夜间无人值守"）
- 用户痛点：用户遇到什么问题？（如"用户咨询等待时间长、简单问题也要等人工、夜间咨询无人响应"）
- 市场机会：AI技术发展带来了什么新机会？竞品在做什么？（如"大模型技术成熟，能自动回答常见问题，竞品已经上线AI客服"）
- 战略对齐：这个需求和公司/产品的战略目标一致吗？（如"降本增效是公司今年的核心战略，AI客服能降低30%客服成本"）
目标是什么？
- 业务目标：这个需求要达成什么业务结果？（如"降低客服人力成本30%、提升首次响应速度到10秒内、覆盖夜间咨询100%响应"）
- 用户目标：用户体验提升到什么程度？（如"用户满意度提升到85%、常见问题自动解决率达到60%、平均等待时间从5分钟降到10秒"）
- 效果目标：AI功能的效果指标是什么？（如"常见问题回答准确率≥90%、用户点'有帮助'比例≥80%、转人工率≤40%"）
- 目标要SMART：具体（Specific）、可衡量（Measurable）、可实现（Achievable）、相关（Relevant）、有时限（Time-bound）
33.2.2 用户场景与用户故事
目标用户是谁？
- 用户角色：谁会使用这个功能？（如"电商平台的消费者、客服人员、客服主管"）
- 用户特征：每个角色的特征、需求、痛点是什么？
- 使用场景：在什么情况下使用？（如"用户下单后想查物流、用户收到货后想退换货、夜间用户有紧急问题"）
用户故事：
格式：作为【用户角色】，我希望【功能/能力】，以便【价值/目的】。
验收标准：Given（当...条件下），When（用户做了...），Then（系统应该...）。
示例：
作为【电商消费者】，我希望【咨询常见问题时AI能立刻回答】，以便【不用等待人工客服，快速解决问题】。
验收标准：
- Given 用户问的是知识库中有明确答案的常见问题，When 用户发送问题，Then AI应该在3秒内给出准确回答，回答准确率≥90%
- Given AI回答后，When 用户点"有帮助/没帮助"，Then 系统记录反馈，用于后续优化
- Given 用户连续2次点"没帮助"或明确要求转人工，When 用户操作，Then 系统应该在30秒内转接人工客服，并把对话历史同步给人工
33.2.3 功能需求与交互流程
功能清单：
- 核心功能：必须有的功能，决定产品价值（如"AI自动回答、智能转人工、知识库管理、效果统计"）
- 辅助功能：提升体验的功能（如"对话历史、消息推送、多语言、移动端适配"）
- 未来功能：本期不做但规划中的功能（如"主动外呼、情感识别、多轮复杂对话"）
交互流程：
- 用户入口：用户从哪里进入AI功能？（APP内客服入口、网页悬浮窗、小程序、API）
- 主流程：用户使用AI功能的完整流程（发起对话→AI回答→用户反馈→解决/转人工→结束）
- 分支流程：各种异常情况的处理（AI回答不好、用户要求转人工、网络异常、系统故障）
- 界面原型：关键页面的原型图，标注交互细节
功能优先级：
- P0（必须做）：核心功能，没有就不叫这个产品
- P1（应该做）：重要功能，提升产品价值和体验
- P2（可以做）：锦上添花的功能，时间充裕就做
- 本期不做：明确不做的功能，避免范围蔓延
33.2.4 技术可行性评估（AI特有，核心）
这是AI产品PRD最重要的部分之一，必须在需求阶段就评估清楚，不能等开发时才发现做不到。
模型能力评估：
- 这个需求需要什么AI能力？（文本生成/理解、图像识别/生成、语音识别/合成、多模态、推理、Agent）
- 当前主流模型能做到什么程度？（用最好的模型测试，看效果如何）
- 我们计划用什么模型？（自研/第三方API/开源模型？为什么选这个？）
- 模型的能力边界是什么？（什么能做好，什么做不好，什么完全做不到？）
- 有没有技术预研或PoC（概念验证）结果？（建议PRD前先做小范围验证）
技术方案选型：
- 技术路线：纯大模型？大模型+RAG？大模型+微调？大模型+Agent？大模型+规则？
- 为什么选这个方案？（效果、成本、可控性、迭代难度）
- 替代方案是什么？（如果首选方案不行，有什么备选？）
- 技术风险：有什么技术风险？（效果不达标、成本超支、延迟过高、模型升级影响）怎么应对？
效果预期：
- 第一版能达到什么效果？（如"常见问题准确率85%，自动解决率50%"）
- 后续迭代目标是什么？（如"3个月后准确率提升到90%，自动解决率60%"）
- 效果的上限和下限是什么？（最好能到多少，最差能接受多少）
- 效果不达预期怎么办？（降级方案、人工兜底、延期上线）
33.2.5 数据需求（AI特有，核心）
AI产品的效果取决于数据，PRD必须明确写清楚数据需求。
需要什么数据：
- 训练/微调数据：如果需要微调模型，需要什么训练数据？（如"10000条客服对话标注数据，包含问题、分类、标准答案"）
- 知识库数据：如果用RAG，需要什么知识库内容？（如"500条FAQ、产品手册、退换货政策、物流说明"）
- 测试/评估数据：用什么数据评估效果？（如"1000条标注测试集，覆盖各类常见问题和边界情况"）
- 用户行为数据：上线后需要收集什么用户行为数据用于优化？（如"用户问题、AI回答、用户反馈、转人工记录"）
数据从哪来：
- 现有业务数据：公司已有的数据（历史客服对话、产品文档、FAQ）
- 公开数据集：行业公开数据集（如客服对话数据集）
- 第三方采购：从数据供应商采购
- 数据标注：需要人工标注的数据（标注什么、标注标准、标注量）
- 用户生成：上线后用户使用产生的数据
- 合成数据：用大模型生成的合成数据（用于冷启动）
数据质量要求：
- 数据准确性：数据的准确率要求（如知识库内容准确率≥99%）
- 数据完整性：数据覆盖范围（如覆盖80%以上的常见问题）
- 数据时效性：数据更新频率（如知识库每周更新，政策变更后24小时内更新）
- 数据格式：数据的格式要求（如FAQ用Q&A格式、文档用Markdown/PDF）
数据成本与周期：
- 数据采集成本：获取数据需要多少钱、多少时间
- 数据标注成本：标注需要多少钱（每条标注成本×标注量）、多少时间、多少人力
- 数据清洗成本：数据清洗、去重、格式化的成本
- 数据维护成本：数据持续更新、维护的成本
- 数据准备周期：数据准备需要多长时间，是否影响项目排期
数据合规：
- 数据来源合法吗？有没有版权问题？
- 数据包含用户隐私吗？有没有脱敏？符合个人信息保护法吗？
- 数据可以用于训练模型吗？用户同意了吗？
- 数据可以商用吗？有没有使用限制？
- 数据安全怎么保障？（加密存储、访问控制、审计日志）
33.2.6 评估指标与验收标准（AI特有，核心）
AI功能必须有明确的评估指标和验收标准，否则项目结束时无法判断是否成功。
效果指标：
- 准确率：AI回答正确的比例（如"常见问题回答准确率≥90%"）
- 召回率：AI能回答的问题占所有问题的比例（如"能覆盖80%的用户咨询"）
- 自动解决率：不需要转人工，AI独立解决的问题比例（如"≥50%"）
- 用户满意度：用户对AI回答的满意度（如"用户点'有帮助'比例≥80%，CSAT≥4分/5分"）
- 转人工率：用户转人工的比例（如"≤40%"，越低说明AI解决能力越强）
- 幻觉率：AI编造信息的比例（如"≤5%"，越低越好）
性能指标：
- 响应时间：AI回答的响应速度（如"首字响应≤2秒，完整回答≤5秒"）
- 并发能力：系统能同时处理多少用户请求（如"支持1000并发"）
- 可用性：系统可用性（如"≥99.9%"）
- 成本：单次调用成本（如"单次问答成本≤0.01元"）
业务指标：
- 成本降低：客服人力成本降低比例（如"降低30%"）
- 效率提升：首次响应时间、平均解决时间的改善（如"首次响应从5分钟降到10秒"）
- 用户留存：使用AI客服的用户留存率是否提升
- 收入影响：对转化率、复购率的影响（如"咨询后转化率提升5%"）
验收标准：
- 上线前验收：用测试集评估，效果指标达到目标（如"测试集准确率≥90%"）
- 灰度验收：小流量灰度运行1-2周，在线指标达到目标（如"灰度期间自动解决率≥50%，用户满意度≥80%"）
- 全量验收：全量上线后1个月，业务指标达到目标（如"客服成本降低25%，用户满意度提升"）
- 验收不通过怎么办：延期上线、继续优化、降级方案、调整目标
33.2.7 兜底策略与人工介入机制（AI特有）
AI不可能100%准确，必须设计兜底策略，确保AI做不好的时候用户体验不崩。
什么时候需要兜底/人工介入：
- AI置信度低（模型不确定答案是否正确）
- 用户明确要求转人工
- 用户连续多次反馈"没帮助"
- 问题类型是AI不擅长的（如投诉、情绪激动、复杂订单异常）
- 涉及高风险操作（如退款、赔偿、修改订单）
- AI回答触发安全过滤（敏感内容、违规内容）
- 系统异常（模型调用失败、超时）
兜底方式：
- 规则兜底：用预设的规则和模板回答（如"这个问题比较复杂，正在为您转接人工客服"）
- 检索兜底：AI生成不好时，直接返回知识库中最相关的答案
- 人工介入：转接人工客服，把对话历史和AI的分析同步给人工
- 用户确认：高风险操作前让用户确认（如"您确定要退款吗？确认后将为您提交退款申请"）
- 降级处理：AI效果不好时，降级为更简单的模式（如只提供FAQ列表，不生成自由回答）
- 明确告知：告诉用户这是AI回答，可能不准确，重要信息请核实
人工介入流程：
- 转人工时展示排队信息和预计等待时间
- 把AI对话历史、用户信息、问题分类同步给人工客服
- 人工客服可以看到AI之前的回答和用户反馈
- 人工处理完后，可以标记AI回答是否正确，用于优化
33.2.8 灰度发布与迭代计划（AI特有）
AI功能效果不确定，不能一上来就全量上线，必须有灰度发布和持续迭代计划。
灰度发布计划：
- 第一阶段：内部测试（1-2周）：公司内部员工使用，发现明显问题
- 第二阶段：小流量灰度（1-2周）：5%-10%的用户使用，监控效果指标，收集反馈
- 第三阶段：中流量灰度（1-2周）：30%-50%的用户使用，验证稳定性和效果
- 第四阶段：全量上线：效果指标达标后全量发布
- 每个阶段的准入标准：效果指标达到什么标准才能进入下一阶段（如"灰度期间准确率≥90%，用户满意度≥80%，无严重事故"）
- 回滚机制：如果灰度期间出现严重问题，怎么快速回滚到旧版本
迭代计划：
- 上线后第1个月：重点监控效果，收集bad case，优化Prompt和知识库，快速迭代
- 第2-3个月：积累数据，评估是否需要微调模型，优化转人工策略，提升自动解决率
- 第4-6个月
- 长期：持续优化，跟踪模型升级，探索新功能（如主动服务、情感识别、预测性客服）
- 迭代节奏：每周小版本优化（Prompt、知识库），每月大版本迭代（功能、模型）
33.2.9 项目排期与资源需求
- 里程碑：项目的关键时间节点（需求评审、技术预研完成、数据准备完成、开发完成、测试完成、灰度上线、全量上线）
- 排期：每个阶段的时间安排，考虑数据准备、技术预研、开发、测试、灰度的时间
- 资源需求：需要哪些角色（产品经理、前端、后端、算法工程师、数据标注、测试、设计、运营），各多少人，投入多少时间
- 依赖项：项目依赖什么（数据准备、第三方API、其他团队配合、模型选型确认）
- 风险与应对：项目有什么风险（技术风险、数据风险、进度风险、合规风险），怎么应对
33.3 实战：撰写一个AI客服产品的PRD（核心部分）
让我们通过一个AI客服的例子，看看怎么写一份AI产品PRD的核心部分。
33.3.1 背景与目标
项目名称：智能客服AI助手
背景：
某电商平台有500万注册用户，日均咨询量2万次。当前客服团队100人，月人力成本80万元。存在以下问题：
- 响应慢：平均首次响应时间5分钟，高峰期15分钟，用户投诉多
- 成本高：客服人力成本逐年上涨，大促期间需要大量临时客服
- 夜间无人：22:00-次日8:00无人工客服，夜间咨询只能第二天回复，用户体验差
- 重复问题多：60%的咨询是常见问题（物流查询、退换货政策、发票），客服每天重复回答
目标：
上线后3个月内达成：
- 业务目标：客服人力成本降低30%（月省24万），夜间咨询100%响应，首次响应时间从5分钟降到10秒内
- 用户目标：常见问题自动解决率≥60%，用户满意度≥85%，转人工率≤40%
- 效果目标：常见问题回答准确率≥90%，幻觉率≤5%，用户点"有帮助"比例≥80%
33.3.2 用户场景与用户故事
用户角色：
- 消费者：使用AI客服咨询问题的用户
- 客服人员：处理AI转接的复杂问题，审核AI回答
- 客服主管：监控AI效果，管理知识库，查看统计报表
核心用户故事：
故事1：常见问题自动回答
作为【消费者】，我希望【咨询常见问题时AI能立刻回答】，以便【不用等待人工，快速解决问题】。
验收标准：
- Given 用户问的是知识库中有明确答案的常见问题（物流、退换货、发票等），When 用户发送问题，Then AI在3秒内给出准确回答，测试集准确率≥90%
- Given AI回答后，When 用户查看回答，Then 回答下方显示"有帮助/没帮助"按钮，用户点击后记录反馈
- Given 回答末尾，When 用户需要更多帮助，Then 显示"没有解决？转人工客服"按钮
故事2：智能转人工
作为【消费者】，我希望【问题复杂或AI回答不好时能快速转人工】，以便【问题能得到满意解决】。
验收标准：
- Given 用户点击"转人工"或连续2次点"没帮助"，When 触发转人工，Then 系统显示排队信息和预计等待时间，工作时间30秒内接入人工
- Given 转人工时，When 人工客服接入，Then 系统把AI对话历史、用户信息、问题分类同步给人工客服
- Given 夜间（22:00-8:00）转人工，When 用户触发，Then 系统提示"当前为非工作时间，已���录您的问题，工作时间后客服将优先联系您"，并记录问题
故事3：知识库管理
作为【客服主管】，我希望【能方便地管理AI的知识库】，以便【AI能回答最新、最准确的问题】。
验收标准：
- Given 客服主管登录管理后台，When 进入知识库管理，Then 可以查看、添加、编辑、删除FAQ和文档
- Given 知识库内容更新，When 保存发布，Then 系统在1小时内更新向量索引，AI回答使用最新内容
- Given 知识库有内容，When 查看，Then 显示每条内容的命中次数、用户反馈、准确率，帮助主管优化内容
33.3.3 技术可行性评估
技术预研结论（已完成PoC验证）：
模型选型：
- 首选：通义千问4.0（中文效果好、成本低、国内访问快、合规性好）
- 备选：GPT-4o（效果更好但成本高、国内访问有合规风险）
- PoC测试结果：用1000条历史客服问题测试，通义千问4.0+RAG准确率达88%，GPT-4o+RAG准确率达91%。考虑成本和合规，首选通义千问，目标通过优化达到90%+
技术方案：
- 方案：大模型 + RAG（检索增强生成）+ 规则兜底 + 人工介入
- RAG：知识库向量化，用户问题检索相关内容，大模型基于检索内容生成回答
- 分类器：先用分类器判断问题类型（常见问题/复杂问题/投诉/高风险），常见问题用AI回答，复杂问题直接转人工
- Prompt工程：精心设计System Prompt，包含角色定义、回答规范、安全限制、输出格式
- 不做微调：第一版不微调模型，用RAG+Prompt达到目标，后续根据数据积累评估是否需要微调
效果预期：
- 第一版（上线时）：常见问题准确率≥88%，自动解决率≥50%
- 上线1个月：通过Prompt和知识库优化，准确率≥90%，自动解决率≥55%
- 上线3个月：通过数据积累和策略优化，准确率≥92%，自动解决率≥60%
- 下限：如果准确率低于85%或自动解决率低于40%，不全量上线，继续优化或调整方案
技术风险与应对：
- 风险1：大模型幻觉，编造答案 → 应对：RAG限制回答基于知识库内容，Prompt要求"不知道就说不知道，不要编造"，设置幻觉率监控，高风险问题不使用AI
- 风险2：模型API不稳定 → 应对：多模型备份（通义千问+文心一言），失败自动切换，设置降级方案（返回FAQ列表）
- 风险3：成本超预期 → 应对：设置单次成本上限，优化Prompt减少token，缓存常见问题答案，监控成本指标
- 风险4：用户不接受AI回答 → 应对：明确告知是AI回答，提供便捷转人工，持续优化提升效果
33.3.4 数据需求
知识库数据：
- 内容：FAQ 500条（物流、退换货、发票、支付、账户、商品等）、产品手册20份、政策文件10份、帮助中心文章100篇
- 来源：现有帮助中心、客服知识库、产品文档、政策文件
- 质量要求：内容准确率≥99%，覆盖80%以上常见问题，格式统一（Q&A或Markdown）
- 准备工作：整理现有内容、去重、格式化、补充缺失内容，预计2周完成，由客服团队负责
- 更新机制：政策变更24小时内更新，每周定期审核，每月全面更新
测试评估数据：
- 测试集：1000条标注测试问题，覆盖各类常见问题（600条）、边界情况（200条）、复杂问题（200条）
- 来源：从历史客服对话中抽样，人工标注标准答案和问题分类
- 标注成本：每条标注成本2元，1000条共2000元，预计1周完成
- 用途：上线前评估准确率，上线后回归测试，持续优化
用户行为数据（上线后收集）：
- 收集内容：用户问题、AI回答、检索到的知识库内容、用户反馈（有帮助/没帮助）、是否转人工、转人工原因
- 用途：优化Prompt、更新知识库、发现bad case、评估效果、训练分类器
- 存储：脱敏存储（去除用户个人信息），保留6个月，用于模型优化
- 合规：用户协议中告知数据用途，用户可选择不参与数据优化
数据合规：
- 知识库内容为公司自有内容，无版权问题
- 用户对话数据脱敏后使用，符合个人信息保护法
- 数据存储在国内服务器，符合数据出境规定
- 用户可申请删除个人数据
33.3.5 评估指标与验收标准
| 指标类别 | 指标 | 目标值 | 测量方式 |
|---|---|---|---|
| 效果指标 | 常见问题回答准确率 | ≥90% | 测试集人工评估，每周抽检100条 |
| 自动解决率 | ≥60% | AI回答后未转人工且用户点"有帮助"的比例 | |
| 用户满意度 | ≥85% | 用户满意度评分（5分制），"有帮助"比例 | |
| 幻觉率 | ≤5% | 人工抽检中AI编造信息的比例 | |
| 性能指标 | 首字响应时间 | ≤3秒 | 系统监控，P95≤5秒 |
| 系统可用性 | ≥99.9% | 系统监控 | |
| 单次问答成本 | ≤0.015元 | API费用统计，月度平均 | |
| 业务指标 | 客服人力成本降低 | ≥30% | 上线3个月后对比，月人力成本从80万降到≤56万 |
| 首次响应时间 | ≤10秒 | 从5分钟降到10秒内 | |
| 夜间咨询响应率 | 100% | 夜间咨询都有AI响应 |
验收标准：
- 上线前验收：测试集准确率≥90%，幻觉率≤5%，系统性能达标，无严重bug
- 灰度验收（2周）：10%流量灰度，自动解决率≥50%，用户满意度≥80%，无严重事故，成本可控
- 全量验收（1个月）：全量上线1个月，自动解决率≥55%，用户满意度≥83%，客服成本降低≥20%，趋势向好
- 最终验收（3个月）：达到全部目标（自动解决率≥60%，满意度≥85%，成本降低≥30%）
- 验收不通过：延期全量、继续优化、调整目标或方案
33.3.6 兜底策略与灰度计划
兜底策略：
- 问题分类：常见问题（60%）→ AI回答；复杂问题（25%）→ AI辅助+人工；投诉/高风险（15%）→ 直接转人工
- AI置信度低（<0.7）→ 不直接回答，返回相关FAQ列表，用户可选择具体问题
- 用户连续2次点"没帮助"→ 自动提示转人工
- 涉及退款、赔偿、修改订单等高风险操作 → AI不直接处理，提示转人工
- 模型调用失败/超时 → 降级返回"系统繁忙，正在为您转接人工"，30秒内接入人工
- 所有AI回答末尾标注"以上由AI助手生成，仅供参考，如有疑问请转人工客服"
灰度发布计划：
- 第1周：内部测试（公司员工使用，发现明显问题）
- 第2周：5%流量灰度（随机用户，监控效果，收集bad case）
- 第3周：20%流量灰度（扩大范围，验证稳定性）
- 第4周：50%流量灰度（半量，验证业务指标）
- 第5周：全量上线（效果达标后全量）
- 准入标准：每阶段准确率≥90%、自动解决率≥阶段目标、无P0/P1事故、成本在预算内
- 回滚机制：灰度期间出现严重问题，10分钟内可回滚到纯人工模式
33.3.7 项目排期与资源
| 阶段 | 时间 | 主要工作 | 负责人 |
|---|---|---|---|
| 需求与技术预研 | 第1-2周 | 需求评审、模型选型PoC、技术方案确认 | 产品+算法 |
| 数据准备 | 第2-3周 | 知识库整理、测试集标注、数据清洗 | 客服+运营 |
| 开发 | 第3-6周 | 前端对话界面、后端服务、RAG引擎、知识库管理后台、人工客服系统集成 | 前端+后端+算法 |
| 测试 | 第6-7周 | 功能测试、效果测试（测试集评估）、性能测试、安全测试 | 测试+产品 |
| 灰度上线 | 第8-11周 | 5%→20%→50%灰度，监控效果，快速迭代优化 | 全体 |
| 全量上线 | 第12周 | 全量发布，持续监控，运营推广 | 全体 |
资源需求：产品经理1人、前端工程师1人、后端工程师2人、算法工程师1人、测试工程师1人、设计师0.5人、客服运营2人（数据准备+知识库维护）、数据标注（外包，1000条）
预算：人力成本约30万（3个月）、模型API费用约5万/月（全量后）、数据标注0.2万、其他2万，首年总成本约100万。预计上线后年节省客服成本约290万，ROI为正。
33.4 PRD评审要点
AI产品PRD写完后，需要组织评审。不同角色关注的重点不同：
34.4.1 算法/技术团队关注什么
- 技术可行性：需求的效果目标在技术上能达到吗？有没有做过PoC？模型选型合理吗？
- 数据需求：需要什么数据？数据从哪来？数据量够吗？质量如何？标注成本和周期可接受吗？
- 效果指标：评估指标定义清晰吗？怎么测量？验收标准合理吗？（不要要求100%准确率）
- 技术方案：技术路线合理吗？有没有替代方案？风险识别全面吗？
- 性能要求：响应时间、并发量、成本要求合理吗？技术上能实现吗？
- 兜底方案：AI做不好的时候怎么办？降级方案可行吗？人工介入流程清晰吗？
- 排期：开发时间够吗？数据准备时间预留了吗？测试和灰度时间充足吗？
33.4.2 设计团队关注什么
- 交互流程：用户和AI交互的流程清晰吗？对话式交互设计合理吗？
- 异常处理：AI回答不好、转人工、系统异常时的交互设计
- 反馈机制：用户怎么给AI回答反馈？反馈后有什么响应？
- 透明性：用户知道这是AI回答吗？知道AI的能力边界吗？
- 可控性：用户能控制AI的回答吗？能停止、重试、转人工吗？
- 移动端体验：移动端对话界面好用吗？输入方便吗？
33.4.3 业务/运营团队关注什么
- 业务价值：这个需求能带来什么业务价值？成本降低多少？效率提升多少？收入增加多少？
- 目标合理性：业务目标 realistic 吗？时间节点合理吗？
- 运营方案：上线后怎么运营？怎么引导用户使用？怎么收集反馈？怎么持续优化？
- 知识库维护：谁来维护知识库？更新频率？质量怎么保障？
- 人工客服影响：AI上线后对人工客服有什么影响？需要调整客服团队吗？客服怎么和AI协作？
- 合规风险：有没有合规风险？（数据隐私、内容安全、消费者权益）
33.4.4 测试团队关注什么
- 验收标准：验收标准明确吗？可测量吗？怎么测试？
- 测试数据：有测试集吗？测试集覆盖全面吗？标注准确吗？
- 效果测试：怎么评估AI效果？准确率怎么测？用户满意度怎么测？
- 异常测试：各种异常情况（模型失败、超时、网络异常、用户恶意输入）测试了吗？
- 性能测试：并发量、响应时间、稳定性测试方案
- 灰度测试：灰度期间怎么监控？怎么判断能不能进入下一阶段？
33.5 常见误区
误区1：只写功能，不写效果目标
很多AI产品PRD只写"做一个AI客服，能自动回答问题"，但不写"回答准确率要到多少、自动解决率要到多少、用户满意度要到多少"。结果开发完成后，产品经理觉得效果不好，技术团队觉得功能都实现了，扯皮不断。
正确做法：PRD必须明确写效果目标，而且要可测量、可验收。
误区2：忽视数据需求，开发时才发现没数据
很多PRD不写数据需求，技术团队开发到一半才发现"没有知识库"、"没有测试集"、"没有训练数据"，项目卡住，或者临时找数据凑数，效果一塌糊涂。
正确做法：PRD必须明确写数据需求——需要什么数据、从哪来、多少量、质量要求、标注成本、准备周期、合规性。数据准备要和开发并行，甚至提前启动。
误区3：评估指标模糊，无法验收
"用户体验好"、"回答准确"、"响应快"——这些都是模糊的指标，无法测量，无法验收。
正确做法：把模糊指标量化——"用户满意度≥85%（5分制）"、"常见问题回答准确率≥90%（测试集评估）"、"首字响应时间≤3秒（P95≤5秒）"。
误区4：技术方案不切实际，过度承诺
产品经理不懂技术，凭想象写需求——"AI能自动处理所有客服问题"、"准确率100%"、"零成本"。技术团队一看就知道做不到，但又不好直接反驳，最后要么做出来效果差，要么项目延期。
正确做法：PRD前先做技术预研（PoC），和算法团队一起评估技术可行性，设定合理的效果目标（不要追求100%），明确能力边界和兜底方案。
误区5：没有兜底方案，AI出错就完蛋
以为AI效果会很好，没有设计兜底方案。结果AI一出错，用户不知道怎么办，人工也接不上，用户体验崩了，投诉暴增。
正确做法：任何AI功能都要有兜底方案——AI做不好的时候怎么办？转人工？规则兜底？降级处理？用户确认？要设计完整的异常处理流程。
误区6：一次性交付思维，没有迭代计划
传统功能开发完上线就完事了，但AI功能上线只是开始——需要持续收集反馈、优化Prompt、更新知识库、积累数据、微调模型。如果PRD只写"上线交付"，没有迭代计划，AI效果会越来越差。
正确做法：PRD要写灰度发布计划和持续迭代计划——怎么灰度、灰度多久、每个阶段的准入标准、上线后怎么持续优化、迭代节奏是什么。
误区7：范围蔓延，什么都想做
AI产品很容易范围蔓延——"既然做了AI客服，再加个情感识别吧"、"再加个主动外呼吧"、"再加个多轮复杂对话吧"。结果什么都做，什么都做不好，项目延期，效果差。
正确做法：明确本期做什么、不做什么，聚焦核心功能，把核心功能的效果做到足够好，再逐步扩展。AI功能的效果比功能数量更重要。
误区8：不写成本要求，最后成本爆表
AI功能的成本（模型API调用费）很容易被忽视。PRD只写效果目标，不写成本要求，结果上线后调用量一大，成本爆表，商���模式不成立。
正确做法：PRD要写成本指标——单次调用成本上限、月度成本预算、成本优化策略。在效果和成本之间找平衡。
33.6 产品经理视角：怎么写一份让技术团队愿意执行的PRD
1. 先做技术预研，再写PRD
不要坐在办公室凭想象写需求。写PRD前，先和算法团队一起做技术预研——用真实数据测试模型效果，评估技术可行性，搞清楚"能做到什么程度、需要什么数据、成本多少、风险在哪"。基于预研结果写PRD，这样的PRD技术团队才信服，才愿意执行。
2. 效果目标要合理，不要拍脑袋
效果目标要基于技术预研结果和行业基准，不要拍脑袋定"100%准确率"。要和技术团队一起讨论，设定有挑战但可实现的目标。同时要分阶段——第一版达到什么程度，3个月后达到什么程度，不要一上来就要求最终效果。
3. 数据需求要写清楚，责任到人
数据是AI产品的生命线。PRD要写清楚需要什么数据、从哪来、谁负责准备、什么时候准备好、质量标准是什么、成本多少。数据准备要纳入项目排期，和开发并行推进。不要等开发完了才说"还没数据"。
4. 验收标准要可测量，不要模糊
每个功能、每个效果指标都要有明确的验收标准——怎么测、用什么数据测、达到什么数值算通过。不要写"用户体验好"、"回答准确"这种模糊的话。验收标准是项目结束时判断成功与否的依据，必须清晰、可测量、双方达成共识。
5. 兜底方案要设计好，让技术团队有安全感
技术团队最怕的是"AI效果不好怎么办"。PRD要设计完善的兜底方案——AI做不好的时候怎么降级、怎么转人工、怎么保证用户体验不崩。有了兜底方案，技术团队才有安全感，敢上线，敢迭代。
6. 灰度和迭代计划要写，不要一次性交付
让技术团队知道这不是一次性交付，而是持续迭代的过程。写清楚灰度发布计划（怎么灰度、灰度多久、准入标准）、迭代计划（上线后怎么优化、迭代节奏、长期目标）。这样技术团队不会有"上线就完事"的心态，会为持续迭代做好架构设计。
7. 风险要识别全，应对方案要具体
AI项目风险多（技术风险、数据风险、成本风险、合规风险、用户接受度风险）。PRD要识别主要风险，并有具体的应对方案。不要只写"有技术风险"，要写"风险：模型幻觉率高；应对：RAG限制回答基于知识库，设置幻觉率监控，高风险问题不使用AI，人工兜底"。
8. 和技术团队共同创作，不要单向输出
最好的PRD不是产品经理一个人写出来的，而是和技术团队、算法团队、设计团队、业务团队共同讨论出来的。写PRD前多和技术团队沟通，写的过程中多征求意见，评审时充分讨论，达成共识。这样的PRD技术团队有参与感，才愿意执行，执行过程中也会更主动。
9. PRD是活文档，不是写完就锁起来
AI产品变化快，PRD不是写完就不变的。技术预研有新发现、数据准备有变化、灰度效果不达预期、用户反馈新需求——都要及时更新PRD。PRD是项目的"活地图"，要随着项目进展持续更新，保持和实际一致。
33.7 本章小结
PRD是产品经理的核心产出，AI产品的PRD和传统产品有很大不同——传统PRD回答"做什么功能"，AI产品PRD还要回答"效果能到什么程度、需要什么数据、怎么评估效果、技术上可不可行、效果不好怎么办、上线后怎么持续优化"。
AI产品PRD的核心结构：
- 背景与目标：为什么做、业务目标、用户目标、效果目标（SMART）
- 用户场景与用户故事：目标用户、使用场景、用户故事+验收标准（Given-When-Then）
- 功能需求与交互流程：功能清单、主流程/分支流程、优先级（P0/P1/P2）
- 技术可行性评估（AI特有，核心）：模型能力评估、技术方案选型、效果预期、技术风险与应对
- 数据需求（AI特有，核心）：需要什么数据、从哪来、质量要求、成本与周期、数据合规
- 评估指标与验收标准（AI特有，核心）：效果指标（准确率/自动解决率/满意度/幻觉率）、性能指标（响应时间/并发/成本）、业务指标（成本降低/效率提升）、分阶段验收标准
- 兜底策略与人工介入机制（AI特有）：什么时候兜底、兜底方式、人工介入流程
- 灰度发布与迭代计划（AI特有）：分阶段灰度、准入标准、回滚机制、持续迭代计划
- 项目排期与资源需求：里程碑、排期、资源、依赖、风险
实战案例：通过AI客服的完整PRD示例，展示了怎么写背景目标、用户故事、技术可行性评估、数据需求、评估指标、兜底策略、灰度计划、排期资源。
评审要点：算法团队关注技术可行性和数据，设计团队关注交互和异常处理，业务团队关注业务价值和运营，测试团队关注验收标准和测试方案。
常见误区：只写功能不写效果、忽视数据需求、评估指标模糊、技术方案不切实际、没有兜底方案、一次性交付思维、范围蔓延、不写成本要求。
产品经理视角：先做技术预研再写PRD、效果目标要合理、数据需求责任到人、验收标准可测量、兜底方案让技术团队有安全感、灰度和迭代计划要写、风险识别全应对具体、和技术团队共同创作、PRD是活文档持续更新。
一份好的AI产品PRD，能让技术团队清楚知道"做什么、做到什么程度、怎么算成功、做不好怎么办"，减少沟通成本和扯皮，提高项目成功率。掌握AI产品PRD的撰写方法，是AI产品经理从"功能产品经理"升级为"AI产品经理"的关键一步。下一章我们会讲AI产品原型设计——怎么设计对话流、状态机、异常处理，把PRD变成可交互的原型。
📝 本章练习（5题）
答案与解析请在 互动学习看板 中作答查看。
📚 AI产品经理实战训练营 课程目录（44 章）
- 第1章 AI产品经理是做什么的？和传统PM有什么区别？
- 第2章 2026年AI产品经理就业市场：哪些行业在招？薪资多少？
- 第3章 零经验转行AI产品经理的3条路径
- 第4章 AI产品全景图：从聊天机器人到Agent，一文搞懂
- 第5章 AI产品经理能力模型：你需要掌握哪些技能？
- 第6章 实战：拆解3个你每天在用的AI产品
- 第7章 大模型是什么？用大白话讲清楚
- 第8章 主流大模型对比：GPT-4o、Claude、DeepSeek、豆包、Kimi怎么选？
- 第9章 Prompt入门：写好提示词的5个原则
- 第10章 Prompt进阶：System Prompt、COT思维链、Few-shot示例
- 第11章 结构化输出：让大模型返回JSON、表格、代码
- 第12章 Prompt优化实战：从垃圾Prompt到高质量Prompt
- 第13章 大模型的"幻觉"问题：产品经理怎么应对？
- 第14章 实战：为一个智能客服设计完整Prompt体系
- 第15章 RAG是什么？为什么企业都在做知识库？
- 第16章 RAG工作原理：文档→分块→向量→检索→生成
- 第17章 向量数据库选型：Milvus、Pinecone、Chroma、pgvector怎么选？
- 第18章 Embedding模型选型：OpenAI、BGE、M3E、GTE对比
- 第19章 Reranker重排序：让检索结果更精准
- 第20章 查询改写与混合检索：提升召回率的实战技巧
- 第21章 知识库运营：文档治理、更新机制、效果监控
- 第22章 实战：从零搭建一个企业知识库（完整流程）
- 第23章 Agent是什么？和聊天机器人有什么区别？
- 第24章 Agent核心能力：感知、规划、工具调用、记忆
- 第25章 主流Agent框架与协议：Agent Harness、MCP、A2A全解析
- 第26章 工具调用（Function Calling）原理与实战
- 第27章 Agent记忆系统：短期记忆、长期记忆、向量记忆
- 第28章 多Agent协作：多个智能体怎么分工配合？
- 第29章 Agent评估体系：成功率、成本、延迟怎么监控？
- 第30章 实战：设计一个制造业生产异常处理Agent
- 第31章 AI产品需求分析：怎么识别真需求还是伪需求？
- 第32章 AI产品竞品分析：怎么调研和拆解竞品？
- 第33章 AI产品PRD撰写：技术可行性、数据需求、评估指标
- 第34章 AI产品原型设计：对话流、状态机、异常处理
- 第35章 AI产品数据指标体系：从DAU到模型准确率，全面监控
- 第36章 AI项目管理：从需求到上线的全流程管控
- 第37章 实战项目1：从零搭建制造业AI智能质检系统
- 第38章 实战项目2：从零搭建企业级AI知识库（RAG系统）
- 第39章 AI产品经理简历优化：让HR一眼看中你
- 第40章 项目经验包装：把普通项目讲成亮眼案例
- 第41章 AI产品经理面试常见问题：提前准备，从容应对
- 第42章 案例分析面试：用结构化思维征服面试官
- 第43章 薪资谈判：拿到你应得的报酬
- 第44章 入职前3个月：快速站稳脚跟，建立信任