AI产品经理：输出质量的终身守护者

过去几个月，我一直被一个问题困扰：我们交付AI功能时，真的在系统性地评估质量吗？

这不是凭空而来的疑问。目前已有大量关于评估、基准测试、LLM-as-a-Judge的严肃研究。Hamel Husain、Shreya Shankar，以及Aakash Gupta与他们的对话都展示了AI输出质量评估的严谨方法。最好的AI产品团队已从凭感觉检查转向评估驱动工程。

但我在现有材料中始终找不到一个关键问题的答案：什么时候评估？在生命周期的每个阶段，谁负责？

评估不只发生在上线时。它发生在上线前——当你探索模型但还没上路线图时；发生在上线中——当你迭代提示词系统时；发生在上线后——当真实用户用你没想到的方式使用功能时。

这三个时刻完全不同，需要不同工具、不同问题、不同负责人。

我管理两款成熟度不同的AI产品。这种不对称迫使我去思考：在整个生命周期里，AI质量的结构化方法到底是什么样的？不只是决定何时上线。这篇文章是我尝试把想法体系化。不是一套成熟方案，而是我正在落实的一些信念。

核心信念

构建AI功能与构建普通功能有本质区别。原因简单但意义深远：输入和输出都是非确定性的。你无法完全预测模型会生成什么——这改变了发现、构建、上线、迭代的一切。

但大多数团队仍在用可预测输出的方式评估。几个手工测试、一种“它好像能工作”的感觉、上线后的一些反馈。我们称之为质量管理。这不是。

没有工具、方法论和数据的守护，只是披着流程外衣的直觉。

我的信念是：产品经理必须成为输出质量的守护者——不只是功能的所有者。但这个角色只有在整个生命周期系统化时才有意义。以下是我的思考。

五阶段AI功能生命周期

这个结构最打动我的是：大部分阶段的主责都在PM身上。在输出评估自动化之前（后面会讲），必须有人定义“好”的标准——这个人需要最接近用户需求和产品愿景。在我看来，这个人就是PM。

第一阶段 🔍 模型直觉检验

在路线图承诺前评估模型的潜力

直觉检验是主动的、创新驱动的活动——完全独立于已确认的路线图。目的是让团队紧跟技术进展，定期发现新的可能。

实践方式：

短期、有时间框的探索，不是深度研究
只测试少量用例和变体
在专用工具中运行，不在生产环境
最少甚至没有提示词工程
定期仪式，不是一次性事件

关键信念：这应该是一个定期仪式，指定负责人，而不是只有功能进入路线图才触发。这样才能保持领先，在竞争对手之前发现机会。

现实中，我常见的情况是：直觉检验存在，但它是临时、被动触发的，没有明确负责人。结果：团队很晚才发现模型能力，通常是在竞品已经上线后。

负责人：技术负责人 + PM 搭配

第二阶段 🗺️ 范围界定

定义行动边界——我们希望AI功能在哪些方面做得好

这个阶段只在功能确认上路线图后才启动。直接集成到产品发现过程的解决方案界定步骤。

**为什么重要：**用户输入不可预测。我们在这里定义的边界在上线后总会与现实部分偏离——这不是失败，而是AI产品的本质。但没有清晰的初始边界，就没有基线来写系统提示词或后续测量。此外，它帮助相关方对齐功能目的。这是三重收获。

包含内容：

定义价值主张——这个功能为用户完成什么任务？
用例完整列表——用MoSCoW格式（必须/应该/可以/不做）
每个用例的具体例子——这将成为未来测试的基础数据集
期望输出示例——包括内容（什么）和形式（如何）
评估标准——完整列表，也用MoSCoW分类，附说明

将初始范围想象成一个有界空间，包含你想象的用例，每个用例都有具体数据点。这个数据集成为未来所有评估的基础——无论是上线前测试还是上线后分析。

我常见的情况：没有这个阶段的团队，提示词系统是在没有达成一致的目标下写的，导致无法客观评估进展——也无法知道什么时候真的可以上线。

负责人：PM，QC提供支持

第三阶段 ✍️ 提示词系统

关键交付阶段——迭代系统提示词直到质量门槛达标

这是当前所有AI功能的第一大瓶颈。花时间最多，工具缺口最痛苦。

**为什么PM主导：**PM是输出质量的守护者。在通过LLM-as-Judge实现评估自动化之前，必须由人来判断“好”的标准——这个人需要最接近用户需求和产品愿景。有些情况下，这意味着让其他部门的人参与评估。

**测试聚会：**在提示词迭代的关键里程碑，我主张进行结构化的大规模评估：

覆盖所有用例和变体的完整数据集
在支持批量分析、可追溯性和版本对比的工具中评估输出
MoSCoW分类指导继续迭代或停止的决策

质量门槛：
成功率门槛取决于标准的重要性：
必须类 ≥ 80% / 应该类 ≥ 50% 等。

如果达不到，继续迭代。如果达到，可以上线。这些数字准不准？这还是个开放问题。是否总能达到？另一个好问题。但有明确的、达成一致的门槛——而不是一种“感觉差不多了”——已经是本质上的不同严谨程度。即使达不到，至少在上线时我们知道自己的位置。

**关于LLM-as-Judge：**用强大的模型自动评分，取代人工评估，是理想终态。会大幅减少人工工作。但这是中期目标——在自动化评分之前，需要先定义好标准。

负责人：PM写提示词，QC负责测试环节

第四阶段 📊 生产评估与范围重构

上线后，现实揭示真实边界

这是一个我很少看到被认真实施的阶段——包括在我自己的团队。

当真实用户使用功能时，实际操作边界就会浮现——它会与阶段二设想的不同。用户会做你没想到的事。有些产生优秀结果。有些则悄无声息地降低产品感知质量——而没有人知道。

包含内容：

启用用户反馈——用户在产品内直接评分和留言
分析生产环境中的用户输入——了解实际用例与初始边界的差异
按用例测量满意度——不仅看总体满意度，还要分用例看

分析后的决策树：
**路径A——无需调整：**初始边界匹配实际使用且质量达标。这种情况非常不可能。

**路径B——调整范围和/或改进提示词：**用户以你没想到的方式使用功能，结果不佳→扩展边界和/或重新进入提示词迭代循环。

路径C——在界面中澄清超出范围的使用（可选，取决于功能重要性）：

“此功能未为这种用法优化”→管理客户期望，提前告知他们可能会得到一般结果，但不要阻止用户。
“此功能不支持这种用法”→完全阻止该用例，因为糟糕的输出会损害产品感知价值。

这会系统性地改变感知质量吗？我深信如此。但我还没有数字证明。我确信的是，没有它就是在盲目航行——团队需要更好的指南针。

负责人：PM

第五阶段 🔄 功能迭代与模型更新

5a——功能迭代
当上线后要扩展或改进功能时，重新进入发现过程——但这次有真实数据：

重新定义用例，从实际生产数据构建数据集，而不是设想的场景
重新运行提示词迭代循环和大规模评估
应用相同的MoSCoW质量门槛

与阶段二的关键区别：我们不再假设。我们知道用户实际做什么。

5b——模型更新
当模型发布新版本，或新玩家以更好性能或价格进入市场时：

先从相同提示词下的模型替换开始——只换模型不改提示词系统
运行生产数据集——用真实数据和现有评估作为基准
评估差异并行动：

质量高于当前：保持提示词（或可选地进一步优化）
质量低于当前：评估是否真的需要这个改变。如果需要，重新进入MoSCoW驱动的提示词迭代循环

我常见的情况：模型更新被当作直觉检验处理。新模型在几个例子上测试，感觉更好，然后部署。没有生产数据集和结构化评估，就没有真实基准——只是又一轮直觉。

负责人：技术团队为主，PM配合

为什么这是领导力问题，不只是流程问题

纵观五个阶段，有一点很明显：PM几乎是每个阶段的核心角色。

这不是巧合。它反映了AI产品质量的真正需求——需要一个掌握全局、从用户角度理解“好”的标准、并在发现、交付和上线后保持连续性的人。

我所倡导的转变，是PM——以及领导他们的团队——如何看待这个角色。不只是作为功能所有者，交给工程和QC。而是作为AI功能整个生命周期的质量守护者：负责定义好、建立衡量工具和数据集、推动迭代直到现实符合意图。

这需要新技能。提示词工程素养。评估设计。数据分析。跨职能的评估仪式组织。

如果我们想构建真正随时间改进的AI功能——而不是那些上线一次、做几个上线后调整、然后随着模型演进而默默沦为一团糟的功能——这些都不是可选项。

能构建出最好AI产品的团队，不会只是上线最快的。而是学习最快的。而不测量，就无法学习。

我的立场说明

这里描述的一切都是我们正在努力的方向——不是成熟方案。有些阶段已落地，有些还在构建，有些仍是明显的缺口。

我分享这些，不是“你应该这么做”，而是“我是这么想的，而且我相信它重要”。如果你也在构建AI功能并面临同样问题，我很想听听你的团队是怎么做的。

如果这篇文章有共鸣，欢迎联系。我会持续分享关于AI产品质量和PM角色的更多思考。