AI产品经理与传统PM的本质区别

上一篇文章探讨了传统软件与AI应用在技术层面的不同之处。本文将聚焦于大家日常工作中更为熟悉的环节——如何撰写需求文档、如何评估产品质量以及如何进行产品迭代。

对于传统产品经理而言，这些任务或许轻车熟路。然而，在AI应用领域，AI产品经理在处理这三项核心工作时，其方法已发生了根本性的转变。

本文旨在通过对比这三种核心工作的差异，帮助您清晰认识到：若要转向AI产品经理岗位，您需要弥补哪些方面的知识和技能。

首先，请您思考一个问题：您当前编写的产品需求文档（PRD）主要关注的是什么内容？

大多数传统PRD的重心在于描述流程：用户执行某个操作后，系统应如何响应，以及在何种情况下会发生错误。其核心在于逻辑清晰、路径明确，以便研发团队能够据此进行实现。

在AI应用场景下，这种模式在一定程度上已不再适用。

您之所以能够清晰地描述每一个步骤，是因为在传统流程中，每一步都是确定的。

那么，对于一个类似“智能邮件摘要”的AI功能，其需求文档应该如何撰写呢？

您是否看到了其中的区别？

传统的PRD侧重于描述流程，研发团队根据文档进行实现，最终产出是确定的结果。而AI功能的需求文档则侧重于描述标准、反例和示例。研发团队同样根据文档实现，但输出的结果是概率性的——模型每次生成的内容都会略有差异。您需要依靠这些标准来判断“本次输出是否达标”。

这本质上更像是编写测试用例，而非绘制流程图。

撰写AI功能的需求文档时，您最需要的并非绘制流程图的能力，而是：

这些能力与撰写传统PRD所需的“逻辑拆解”能力有所不同，但并没有您想象的那么困难——本质上，这与您已在进行的工作类似，只是侧重点有所转移。

传统产品经理通常如何判断一个功能是否“开发完成”？

通常的流程是这样的：

质量保证（QA）团队会给出一个确定的答案：通过或不通过。功能符合需求即通过，不符合则不通过。

AI应用则无法享受这种“奢侈”。

您可能想要验证“邮件摘要功能”的准确性——但模型对同一封邮件每次生成的摘要都可能不同，您不可能穷尽所有可能的邮件进行测试。

因此，传统的QA方法在AI应用中基本失效，您需要引入Evals（评估体系）。

简而言之，Evals是一种利用机器来替代人工QA的评估方法。

其具体步骤如下：

第一步：建立测试集

收集一批具有代表性的真实邮件，作为基准样本。例如，收集50封邮件，涵盖不同长度、不同类型（商务/私人/营销）以及不同语言的邮件。

第二步：定义评估维度

为每个维度设定相应的评分规则：

第三步：执行批量评估

使用这50封邮件对模型进行批量测试，并将模型的输出结果提交给评估规则进行评分。同时，进行20%的人工抽检，以确保评估规则本身的准确性。

第四步：设定通过阈值

所有四个维度均达到预设标准后，该功能方可上线。

设计Evals是AI产品经理的核心新技能之一。您可能不需要亲自编写代码来构建评估系统（这通常由工程师完成），但您必须能够清晰地回答以下问题：

您设计Evals的能力，将直接决定您产品的质量底线。

最后一个显著的差异体现在：迭代速度。

传统产品经理提出一项需求变更，其流程通常是这样的：

在AI应用中，如果您只是调整提示词（Prompt）或评估标准，流程将变为：

这一变化听起来令人兴奋，但背后存在两个您必须深刻理解的影响。

在传统应用中，修改一个按钮的文案，研发人员可能只需花费5分钟修改代码，您几乎感觉不到这种时间的差异。

而在AI应用中，修改一句话的提示词，其效果可能产生天壤之别。

举一个真实的例子：

两个提示词之间的差异，不仅仅是用户体验上的差异，更是“可用”与“不可用”之间的鸿沟。

因此，提示词的设计成为了AI产品经理的核心输出物，而非像传统应用中那样“功能逻辑主要由工程师负责实现”。

提示词的快速修改，意味着您可以在短时间内验证大量想法——但同时也要求您拥有一套能够更快判断“这次修改是改进还是退步”的机制。

答案便是Evals。缺乏Evals支持的快速迭代，无异于盲目试错；而有了Evals的支撑，您才能真正实现“快速收敛”。

说了这么多，具体需要补充哪些技能？这里为您提供一份清单。

传统产品经理的核心能力在于：将用户需求转化为研发团队能够实现的流程逻辑。

AI产品经理的核心能力在于：将用户需求转化为模型能够理解的约束性描述，并建立相应的评估体系以确保其执行到位。

实现转化的工具发生了变化——从流程图转变为提示词和Evals——但转化的本质并未改变。

您已经在做的事情，只需融入一些新工具，便能胜任AI产品经理的角色。

本系列第三篇文章：《AI应用开发：为何说“这和以前完全不一样”？》