AI 产品经理如何判断一个 AI 功能能不能上线？

很多 AI 功能在演示时都很惊艳。

输入一段文字，它能生成一份像模像样的报告；上传一份文件，它能自动总结重点；提出一个问题，它能迅速给出答案。团队试玩几次，觉得效果不错，于是很容易得出结论：可以上线了。

但上线以后，真实用户带来的输入往往完全不同：资料缺失、表达模糊、格式混乱、上下文互相冲突，甚至包含系统从未考虑过的边界条件。

Demo 中表现流畅的功能，到了真实环境里可能开始答非所问、编造事实、泄露不该展示的信息，或者在失败时让用户无路可走。

问题通常不在于 Prompt 写得不够长，而在于团队从来没有回答清楚一件事：

什么样的结果，才算这个 AI 功能真的可以交付？

一、模型分数高，不等于产品可以上线

产品团队选择模型时，常常会先看各类 Benchmark：推理、编码、数学、长文本、工具调用。分数一目了然，似乎很容易比较。

但 Benchmark 回答的是“模型在某套测试题上表现如何”，而产品需要回答的是“它能不能在我的用户、数据和业务约束下完成任务”。这两个问题有关，却不是同一个问题。

在 LLM 基准测试中，一个分数要有参考价值，至少要满足三个条件：测试任务贴近真实场景、测试数据没有被污染、测试本身仍有区分度。

很多传统基准已经接近饱和，几个模型之间的微小分差，可能还没有统计噪声大。

即使模型在公开测试中领先，也不能直接推导出它适合你的产品。一个企业知识助手真正关心的，可能不是模型能否答对博士级物理题，而是：

• 能否只依据企业内部资料回答，而不是凭空补充；
• 能否在资料互相冲突时明确表达不确定；
• 能否正确处理权限，不把 A 部门的内容展示给 B 部门；
• 能否在规定时间和成本内稳定返回结果；
• 出错以后，用户能否继续完成任务。

因此，模型评测解决的是“能力选型”，产品验收解决的是“交付边界”。前者可以帮助我们缩小候选范围，后者才决定发布按钮能不能按下去。

二、先定义任务，再讨论准确率

AI 产品最容易出现的错误，是团队还没有定义清楚“用户到底要完成什么”，就开始讨论模型、Prompt 和准确率。

宝玉对 Claude Code 产品负责人 Cat Wu 访谈的整理里有一个很重要的判断：优秀的 AI 产品经理，要能够缩短想法到用户拿到产品的时间，同时定义产品必须在哪些任务上开箱即用。

后半句经常被忽略。

“回答得更好”“总结得更专业”“像一个专家”，都不是可以验收的任务。一个可验收的任务，至少需要说清楚五件事：

1. 谁在什么场景下使用；
2. 用户会提供什么输入；
3. 系统需要完成什么动作；
4. 什么结果算成功；
5. 哪些错误绝对不能发生。

例如，与其把需求写成“做一个智能客服”，不如写成：

当已登录用户询问退款进度时，系统需要识别订单，依据当前退款规则解释状态；资料不足时主动补问信息；涉及人工审批或异常订单时转交客服；不得编造退款日期，不得展示其他用户的订单信息。

到了这一步，我们才真正拥有了测试对象。否则所谓评测，只是在给几段看起来不错的回答打印象分。

三、测试集应该来自真实工作流，而不是几条顺手写的 Prompt

不少团队的测试方式是：产品经理临时想十个问题，模型回答得不错，就认为效果过关。

这种测试只能证明模型会做团队已经想到的事情，却无法说明它能否应对真实用户。

一个能支持上线判断的测试集，至少应该覆盖四类任务。

1. 主路径任务

这是产品最核心、最高频的使用场景。用户提供完整信息，系统按照预期流程完成任务。

主路径必须稳定通过，因为它定义了产品最基本的价值。如果最常见的任务还需要用户反复重试，其他能力再惊艳也没有意义。

2. 边界任务

输入不完整、表述模糊、格式异常、资料过长、信息互相冲突，都是现实中必然出现的情况。

边界任务不是故意刁难模型，而是在验证系统是否知道自己什么时候“不知道”。很多严重事故，不是因为模型完全不会，而是因为它在不确定时仍然给出了非常确定的答案。

3. 高风险任务

涉及隐私、付款、删除、权限、健康、法律或对外发送的操作，不能只看回答质量，还要检查授权、确认、审计和回退机制。

一个高风险任务即使九十九次正确，只要有一次绕过权限，平均分也没有意义。上线标准必须包含“一票否决项”。

4. 运行环境任务

产品不是一段孤立的模型输出。超时、限流、工具调用失败、知识库没有命中、上游接口返回异常，都属于产品必须处理的真实状态。

模型能回答，不代表系统能交付。延迟、成本、失败恢复和可观测性，也应该进入验收范围。

测试集不需要一开始就非常庞大。更重要的是先覆盖关键场景，并且为每条案例保留输入、期望、风险等级和判断依据。随着用户反馈不断补充，它会逐渐成为产品自己的能力基线。

四、一次成功，不代表稳定可用

传统软件在同样的输入和状态下，通常会给出相同结果；生成式 AI 却可能因为采样、上下文、模型版本和工具状态的变化，产生不同输出。

所以，AI 产品不能只测“有没有成功过”，还要测“重复运行时有多稳定”。

同一条关键任务可以多次执行，并记录：

• 任务完成率：用户要做的事是否真正完成；
• 严重错误率：是否出现编造、越权或不可恢复的错误；
• 结果一致性：关键事实和结论是否发生漂移；
• 响应时间：用户是否等得起；
• 单次成本：规模扩大后是否还能承受。

这里最容易犯的错误，是用平均分掩盖严重问题。

假设十次测试中九次得分很高，一次泄露了其他用户信息，平均质量可能仍然很好，但这个功能显然不能上线。因此，评估结果至少要区分两类指标：

• 门槛指标：触发一次就阻止上线，例如越权、敏感信息泄露、不可逆误操作；
• 质量指标：允许在一定范围内波动，例如语言表达、结构完整度、风格一致性。

平均质量决定产品好不好用，底线是否守住决定产品能不能发布。

五、不要迷信一种评分方式

AI 输出往往同时包含可验证部分和主观部分。只用人工评审，成本太高，也容易因人而异；只让另一个模型评分，又可能把判断权交给一个同样会犯错的系统。

更可靠的方式，是建立三层评估。

第一层：确定性规则

凡是可以用程序判断的，就不要交给感觉。

例如字段是否齐全、引用链接是否存在、金额是否一致、输出格式是否合法、权限是否正确、工具是否真实执行。这一层速度快、成本低，适合每次变更后自动回归。

第二层：模型评审

对于相关性、完整度、表达质量、是否遵循复杂指令等难以完全规则化的指标，可以让评审模型按照明确量表评分。

但评审模型不能只收到一句“请判断好不好”。它需要评分维度、正反例、扣分条件和无法判断时的处理规则。评审本身也要通过一批人工标注样本校准，否则只是把一个模糊判断交给另一个模型。

第三层：人工黑盒测试

宝玉在 AI 原生开发流程的复盘中提出了一个很实用的做法：先让 Agent 自己运行测试、发现问题并修复，再由人把自己当成普通用户进行黑盒测试。

这两层不能互相替代。自动验证适合高频回归，人类则更擅长发现“虽然没报错，但就是不好用”的问题，例如提示不清楚、交互反直觉、失败以后不知道下一步做什么。

至于人工检查要做到多深，应该由风险决定。普通内容工具可以在自动测试后重点做用户体验验证；涉及资金、隐私和核心业务规则的功能，还需要更严格的代码、安全和业务审查。

六、上线标准不是一个总分，而是一组发布门槛

真正能指导决策的评估，不应该最后只留下一个“综合得分 87 分”。团队需要的是一组清晰的发布门槛。

这里还有一个重要原则：阈值必须尽量在测试前确定。

如果看到结果以后再决定多少分算通过，团队很容易为了赶进度不断降低标准。对于暂时无法达到正式标准的能力，可以采用灰度、白名单或研究预览，但要同步降低承诺、限制使用范围，并让用户知道它仍处于试验阶段。

“先发布再迭代”不是取消标准，而是让发布范围与当前证据相匹配。

七、上线不是评估结束，而是评估开始拥有真实数据

离线测试只能覆盖团队能够提前想到的场景。产品上线后，用户会不断带来新的表达方式、任务组合和失败模式。

姚金刚在总结自己的 AI 使用方法时写过一句很准确的话：模型越强，评估越重要。他进一步把团队 AI 能力拆成工具层、Skill 层、上下文层和评估层；其中评估层负责质量标准、反馈机制与迭代体系。

这意味着线上反馈不能只停留在“用户点了赞还是踩”。团队还需要回答：

• 用户在哪一步离开或转人工？
• 哪类输入最容易失败？
• 是模型能力不足，还是上下文、工具或流程出了问题？
• 新版本修复旧问题时，有没有让其他场景退化？
• 哪些线上失败应该补进固定测试集？

每一次真实失败，都应该尽可能沉淀为一条可复现案例。下一次更换模型、修改 Prompt、调整知识库或重构流程时，重新跑一遍，确认旧问题没有回来。

这才是评估真正的价值：它不只是发布前的一场考试，而是产品持续迭代的记忆。

八、AI 产品经理真正要负责的，是“可以交付”的定义

随着模型越来越强，做出一个能运行的 Demo 会越来越容易。真正稀缺的能力，会从“能不能做出来”转向：

• 能不能找到值得解决的真实任务；
• 能不能把模糊期待变成可验收标准；
• 能不能识别哪些失败可以接受，哪些绝对不行；
• 能不能建立自动验证与人工判断的分工；
• 能不能在速度、质量、成本和风险之间做出取舍；
• 能不能让每次线上失败变成下一轮迭代的测试资产。

Prompt 仍然重要，模型选择也仍然重要。但它们只是系统的一部分。

AI 产品验收，不是为了证明模型偶尔能完成任务，而是确定它在什么条件下，能够以什么质量稳定交付。

当它做不到时，产品是否知道如何停下来、解释清楚，并把用户带到下一条可行路径。

当这些问题有了明确答案，一个 AI 功能才真正从“看起来能用”，走向“可以上线”。

未来的差距不只在于谁会调用工具，更在于谁能发现问题、构建解决方案，并对结果负责。