很多传统产品经理转AI产品时，第一反应还是写需求、画流程、推开发。但AI产品上线后最容易翻车的地方，往往不是“有没有功能”，而是“效果到底有没有变好”。我做金融投研Agent项目后，一个很深的感受是：AI产品经理一定要会搭评测闭环，否则你根本不知道问题出在模型、提示词、检索召回，还是Agent链路。

我以前也容易把AI产品当成“传统产品 + 大模型能力”来理解。

传统产品里，产品经理把需求说清楚，PRD写完整，交互流程画明白，再配合开发上线，后面看用户反馈、数据埋点、A/B测试，基本就能跑起来。

但AI产品不太一样。

你写完PRD，只是把“要做什么”说清楚了；真正难的是上线后怎么判断“做得好不好”。

同一个需求，大模型可能今天答得好，明天因为prompt改了一句就变差；同一个知识库，检索召回可能在普通问题上很好，但一遇到边界问题就漏；同一个Agent链路，单步工具都没问题，串起来却可能卡在意图识别、工具调用、最终总结任何一个环节。

所以AI产品经理不能只会写PRD，还要会设计评测体系。

说直白点：PRD决定产品能不能被开发出来，评测体系决定产品能不能持续变好。

第一个误区：把“用户反馈”当成唯一验证方式

很多人做传统产品时，习惯上线后看用户反馈。

用户觉得好不好用？有没有投诉？转化率有没有涨？留存有没有变好？这些当然重要。

但AI产品如果只等用户反馈，问题会来得太晚。

因为AI能力的错误经常是“局部坏掉”的。

比如一个RAG问答产品，80%的常规问题都答得不错，但偏偏在某类专业问题上召回不到原文；比如一个Agent系统，大多数单轮问题能处理，但一遇到复合query就把意图拆错；再比如一个金融投研助手，事件解读看起来很顺，但最后总结节点引用的不是原文级数据，而是模型加工过的中间内容。

这些问题，用户不一定能准确描述。

用户只会说：“感觉不准”“答得怪怪的”“不太敢信”。

但产品经理不能停在这里。

你要能继续往下拆：到底是不准、不全、不相关、不合规，还是响应太慢？

我做金融投研多智能体矩阵时，就遇到过类似问题。早期十多个意图看起来都合理，但放到真实query里会互相打架。后来我们把大量query摊开看，才发现问题不在用户表达，而在意图体系本身拆得太细、边界不清。

如果只看用户反馈，很可能最后只得到一句“这个Agent不好用”。

但如果有评测集和指标体系，你就能知道：是哪类query误触发，哪条链路不稳定，哪个Agent输出质量下降。

这就是评测的价值：让问题可量化。

第二个误区：只看业务指标，不看AI能力指标

传统产品常见指标大家都熟：PV、UV、DAU、MAU、留存率、转化率、付费率、NPS、满意度。

这些指标仍然有用，但不够。

AI产品还要看一层“能力指标”。

比如：

• 意图识别准确率；
• 回答相关性；
• 任务完成率；
• 多轮对话完成率；
• 幻觉率；
• 转人工率；
• AIGC采纳率；
• 响应时间；
• 检索召回率；
• 工具调用成功率。

这些指标不是为了让报表更复杂，而是为了定位问题。

举个例子，一个AI客服产品留存下降了，传统产品经理可能会去看入口、交互、文案、用户路径。但AI产品经理还要继续问：

• 是用户问题没有被识别出来？
• 是识别出来了但知识库没召回？
• 是召回了但大模型总结错了？
• 是答案对了但响应太慢？
• 是单轮能答，多轮就断？

如果你没有能力指标，最后所有问题都会被归因成“模型不行”。

这其实是很粗糙的。

我在金融投研Agent项目里最明显的感受就是：AI产品的效率提升，不一定只来自模型能力，也来自产品结构的减法。我们把十多个意图收敛成2类需求范式，把链路固定成4条标准执行路径，系统就不用在一堆分支里来回犹豫。后面响应时间从10几秒压到7秒内，关键问答准确率做到约95%，这里面既有技术优化，也有产品结构收敛带来的收益。

所以AI产品指标体系不能只盯业务结果，还要能拆到能力层。

第三个误区：评测集随便凑一批问题就完事

很多团队说自己有评测集，其实只是凑了一批常见问题。

这不够。

评测集本质上是给AI产品出卷子。卷子出得不对，分数再高也没意义。

我比较推荐的评测集来源是四类：

真实用户日志一定要占大头，因为它最接近真实使用场景。用户怎么问，系统就应该怎么被测试，而不是只用产品经理脑补出来的“标准问法”。

历史错例也很重要。AI产品迭代最怕什么？最怕上一个版本刚修好的问题，下一个版本又冒出来。所以历史错例应该进入回归测试，每次版本更新都要重新跑。

边界样本是专门测系统底线的，比如模糊意图、复合问题、超长输入、无工具支撑的问题、敏感表达、合规风险场景。

AI生成样本可以用，但只能做冷启动补充，不能完全信任。因为AI生成的问题往往太规整，和真实用户的混乱表达不是一回事。

说到底，评测集不是为了证明系统很强，而是为了尽早暴露系统哪里弱。

第四个误区：只打分，不归因

很多评测报告最常见的问题是：有分数，没结论；有结论，没归因。

比如准确率85%，相关性90%，平均响应时间7秒。

看起来很完整，但产品经理拿到后还是不知道下一步该改什么。

因为评测真正有价值的地方，不是告诉你“分数是多少”，而是告诉你“为什么扣分”。

一个AI产品的badcase，大概率会落到这几类原因里：

• 模型能力问题：模型本身推理、理解、生成不稳定；
• prompt问题：约束不清、角色不明、输出格式不稳；
• 检索召回问题：RAG没有召回正确知识块，或者召回内容噪声太多；
• 数据问题：知识库过旧、清洗不干净、分块不合理；
• Agent链路问题：意图识别错、工具选错、步骤顺序错；
• 产品边界问题：需求本来就没有工具支撑，却硬让系统回答。

如果不做归因，所有问题最后都会变成一句话：“让算法再优化一下。”

这对算法和工程都不公平，也不利于产品迭代。

产品经理要做的是把问题拆清楚：哪些是模型要调，哪些是prompt要改，哪些是知识库要补，哪些是产品边界要收敛。

在金融投研场景里，这一点尤其关键。比如系统不能为了显得聪明，直接生成无来源的投资观点；如果检索不到原文依据，就应该提示信息不足，而不是强行编一个看起来很专业的答案。

克制有时候不是保守，而是上线能力的一部分。

我现在会用的AI产品评测闭环

如果把这套方法压缩成一个可执行流程，我会用五步：

第一步，定指标。

先说清楚什么叫好。不同AI产品的好不一样：对话助手看准确率、相关性、多轮完成率；RAG产品看召回率、引用准确性、幻觉率；Agent产品看任务完成率、工具调用成功率、链路稳定性；AIGC产品看采纳率、生成质量、编辑成本。

第二步，选方法。

不是所有问题都适合人工评测，也不是所有问题都适合LLM评分。格式校验、字段完整性、响应时间可以用自动脚本；专业度、表达质量、用户满意度适合人工评测或LLM评分；关键合规场景最好人工复核。

第三步，造评测集。

不要只凑常见问题。真实日志、历史错例、边界样本、AI生成样本都要有，而且要按业务场景分层。

第四步，跑评测。

每次版本迭代都要跑同一批核心评测集，保留版本对比。否则你只知道新版本“感觉更好”，不知道到底好在哪里。

第五步，做归因。

评测不是为了给模型打个分，而是为了形成闭环：评测 → 发现问题 → badcase归因 → 反馈算法和工程 → 回归测试。

这一步才是AI产品经理真正该参与的地方。

这件事怎么落到PRD里

很多人会问：评测体系是不是单独写一份文档就行？

我的建议是：可以单独写评测文档，但PRD里也必须提前埋进去。

因为评测不是上线后的补充动作，而是需求设计的一部分。

写AI产品PRD时，除了传统的需求背景、用户场景、功能流程、交互说明，我会额外补四块：

第一，能力边界。

明确这个版本能回答什么，不能回答什么；哪些问题必须兜底，哪些问题不能强答。

第二，效果指标。

不只写业务指标，也要写AI能力指标。比如准确率、召回率、响应时间、工具调用成功率、幻觉率。

第三，评测集设计。

说明评测集来源、覆盖场景、样本分层、历史错例是否进入回归测试。

第四，badcase归因机制。

说明线上问题怎么收集，怎么分类，怎么流转给算法、工程、运营，怎么做回归验证。

这样写PRD，开发和算法才知道你要的不只是“做一个功能”，而是“做一个能被持续验证的系统”。

这也是AI产品和传统产品很不一样的地方。

经验沉淀

1. AI产品不是上线即结束，而是上线后才开始暴露真实问题

传统产品上线后看用户行为，AI产品上线后还要看能力稳定性。因为模型、检索、prompt、Agent链路都可能成为质量波动源。

2. 业务指标告诉你结果，能力指标告诉你原因

留存下降、满意度下降只是结果。意图识别、召回率、幻觉率、工具调用成功率，才是帮你定位问题的抓手。

3. 评测集不要只收集标准问题，要故意收集难题

真实用户不会按标准句式提问。历史错例、边界样本、模糊意图、异常链路，才最能测出系统上线后的抗压能力。

4.产品经理不要把所有问题都甩给算法

有些问题是模型问题，有些是prompt问题，有些是知识库问题，还有些是产品边界设计问题。产品经理必须参与归因，否则迭代会越来越乱。

5. 能被评测的AI能力，才有持续迭代的可能

如果一个能力无法被定义、无法被评测、无法被归因，它就很难被稳定优化。AI产品经理要做的不是迷信模型，而是把模型能力放进可验证的产品闭环里。

结尾

如果说传统产品经理的基本功是“把需求讲清楚”，那AI产品经理的新基本功，就是“把效果评清楚”。

不要只会写PRD，不要只会说模型很强，也不要只等用户反馈来告诉你哪里坏了。

AI产品真正能持续变好，靠的是一套评测闭环：定指标、选方法、造评测集、跑评测、做归因。

最后浓缩成一句话：

AI产品经理的价值，不是把大模型接进产品里，而是让每一次模型输出都能被定义、被评测、被改进。

欢迎评论区交流，如果你也在做AI产品评测、RAG问答或Agent系统，特别想听听你们是怎么搭评测集和归因机制的。