AI时代需求定义新范式：从评估视角重塑产品思维

评估不仅是业务层面的议题，更涉及组织协调，达成一致的过程往往比结果本身更值得关注。

AI 产品经理手册 · 第一章

— 第一节 —

PRD 已成过去式，Eval 重塑需求边界

区别于传统软件时代在确定性环境下的增删改查操作，

大模型时代让一切都演变为概率驱动的输出模式。

我们无法再用一份 PRD 完整描述一个 AI 产品的所有表现；

需求定义，几乎进入了样本定义时代。

这不难理解：算法研发依赖的是训练素材与评估样本，

而非一份仅阐述规则的规格文档。

区别于第零章对理念和工具的引入，从这一节开始，我们正式进入实战环节。后续每一节都会涉及一些从业务角度看相对复杂的概念——我会尽可能剥离与业务无关的技术细节，用产品经理易于理解的方式进行阐述。

接下来要解答的问题是：当产品从确定性操作转变为概率驱动输出时，需求应如何被定义？

先回顾传统软件时代的产品形态。

在相当长的时间里，我们所做的产品，本质上都是定义一组确定性的操作：增、删、改、查，加上权限、流程、状态机和异常处理。

这些需求当然也会复杂，但它们有一个共同前提：输入、流程和输出都相对确定，可以被规则枚举和代码实现。

所以 PRD 在这个时代非常有效。它不需要描述世界上所有可能发生的结果，只要把关键流程、边界条件、业务规则和价值判断阐述清楚，工程团队就能将其落地为软件系统。

传统软件时代，PRD 的核心作用是：把需求的含义与价值，转化为工程团队可以实现的确定性规则。

它适合描述的是：流程、字段、状态、权限、异常、页面与交互。

但大模型产品不是这样。

同一个用户问题，模型会生成不同的答案；同一个任务，模型会走出不同的推理路径；同一个 Agent，在不同 context 下会调用不同的工具、走出不同的中间状态。

这不是 bug，而是大模型产品的基本形态：它提供的不是确定性操作，而是概率驱动输出。

也就是说，一个 AI 产品真正交付给用户的，不是某个固定页面、某个固定按钮、某条固定规则，而是在给定 context 下，模型对答案、计划、建议、动作路径的一次概率采样。

这时，传统 PRD 的局限就出现了。

你可以在 PRD 里写：

AI 应该给出专业、安全、个性化、可执行的运动建议。

但这句话无法穷尽描述产品的所有效果。什么叫专业？什么叫安全？个性化到什么程度？可执行的标准是什么？在高温高湿、用户疲劳、心率异常、训练目标冲突的场景下，哪一个优先级最高？

这些问题不能靠一句需求描述解决。它们必须被拆成一组带 context 的样本，以及围绕这些样本定义的判断标准。

所以，大模型时代并不意味着 PRD 没用了。

PRD 依然有价值：它负责说明背景、用户问题、业务目标、约束条件和产品边界。但如果我们要定义一个 AI 产品的实际效果，仅靠 PRD 已经不够了。

因为算法开发真正需要的，不是一段"希望模型怎么表现"的文字，而是：

换句话说，需求定义正在从"写规则"转向"给样本"。这里的 sample，不是一句孤立的 query，而是一条带完整 context 的业务场景：谁，在什么状态下，带着什么目标，提出了什么问题。

Sample 是原子，Dataset 是分布。

单条 sample 让需求变具体，一组 dataset 才让需求具备覆盖面。

所以在 AI 时代，一份可被执行的需求，必须至少包含三件事：Dataset（Samples + Context）+ Rubric + Metric。

需求没有消失，PRD 也没有彻底失效。

真正发生变化的是：

传统软件的需求，可以主要写成规则；

AI 产品的需求，必须进一步写成样本 + 标准。

这就是为什么我说：评测即需求，评测即产品。

而 Eval 内部的结构，恰好和产品经理对"需求"的经典定义一一对应。下面，我们就把这层对应关系拆开来看。

主流认知里，评测是一种相对狭义的存在——它是模型 / Agent 项目的收尾动作，是上线前的离线效果验收，是发布前的最后一道守门员。

这个定位本身没错，但它丢掉了 90% 的价值——它把评测的位置摆在链路最末端，把它的意义压缩成了"合格 / 不合格"的二元判断。

让我们重新拆解：一份评测里到底包含什么？

还记得我们之前讲过的，产品经理对"需求"的核心定义：需求 = 理想 − 现状。把这个定义和评测结构对应起来：

两边一一对应：评测的本质，就是用产品语言把需求"写"了一遍。

▲ 图 1 · 评测的三要素和产品经理的需求模型一一对应

所以——

评测，是需求和产品能力的形式化抽象——Dataset 把"现状"抽成可枚举的输入分布，Rubric + Metric 把"理想"抽成可衡量的输出标准。

一句话：评测即需求，评测即产品。

它不是上线前的守门员，而应该出现在需求被定义的那一刻——甚至可以说，它本身就是 AI 时代里真正能被工程团队消费的那一份需求。

抽象的概念到这里说完了，给一个最小化的具体例子，让"评测即需求"这件事可以在你脑子里立刻动起来：

场景：运动健康类 AI 助手。

Dataset（现状）

一条 dataset case 远不是一句 query 这么简单——它必须带上足够还原"用户处境"的 context：

同一句"心率 170"，对一个跑步新手与一位有 2 年跑龄的跑者来说，合理答案完全不同——所以 context 不是"附加信息"，它就是 Dataset 本身的一部分。

Rubric（理想）

Metric（量化）

把上面三件事写下来——从「带 context 的 Dataset」到「分层 Rubric」再到「可量化的 Metric」——需求才算真正被定义了。

反过来：如果你只能写出一句"我希望它能回答好运动问题"，那它根本不是一个需求，只是一句一厢情愿的「想法」。

前面我们说"评测即需求"。

但你可能会问一个尖锐的问题：评测从来都重要——为什么偏偏到 AI 时代，它才被推到"需求的载体"这个位置？

答案藏在更底层的一件事里——机器学习的"监督信号"，正在从 label 迁移到 data。而当监督信号变了，定义"什么算好"这件事，就被从模型团队的工具箱里拿了出来，交回到了产品团队的手里。

下面我们分两个时代来看清这件事。

评测并不是什么新概念。我们对任务效果的评估，长期以来都被分成几个环节：

这套逻辑在大模型时代依然适用——搜推时代有句行业玩笑话："评测属于人工智能"（这里的"人工智能" =人工 + 测试，是个谐音梗）。当年沉淀下来的方法（比如 GSB、SBS 这类两两对比评测），今天依然有不少应用场景。

但搜推时代的评测有一个非常独特的便利条件——主导监督信号来自用户行为。

点击、停留、转化、负反馈……人工标注当然也存在（相关性等级、广告质量、风控样本），但更多是辅助。最妙的是——"好"几乎可以让用户行为自己说出来。

搜推时代的内容供给发生在前，而且是确定的——候选池由内容运营、专家审核与库存策略提前定义好，本身就是一个传统的 CRUD 环节。

真正交给用户行为回答的，是后一步：在这批已经确定的候选里，哪一条更好。

所以 PM 不需要先回答"什么是好的搜索结果"——只要把候选送到用户面前，他点不点击会替你回答。

这就是为什么过去十几年，绝大多数 PM 都没有"亲手定义评测"这件事——因为线上的用户，每天都在替你定义。

但大模型时代不一样。

从基模预训练到后训练，模型学习的对象不再是"行为打过的标签"，而是数据本身——不是 label，是 data；不是"用户点了什么"，是"专家做了什么演示"。

这意味着：

而最关键的一个变化是："什么算好"再也不能让用户行为自动告诉你了。为什么？

搜推时代，模型在向"用户的行为"学习；

大模型时代，模型在向"人类提供的样本"学习。

当学习的对象从 label 变成 data，定义"什么算好"这件事，就不再是模型自己的任务，而是产品的任务。

这正是评测被推到"需求载体"位置的根本原因——不是大家突然觉得评测重要了，而是除了评测之外，没有其他载体能装下这件事了。

这种新的学习模式也带来了一些非常严重的问题——两个最直接的痛点，今天每个做大模型业务的团队都在头疼：

这两个痛点目前并没有标准答案，行业还在持续摸索。我个人的一种思路是——

用线上用户的真实 feedback（点赞、点踩、追问、修改、采纳、留存等隐式信号），训练一个专门用来打分的小模型，让"什么算好"直接和线上端到端的用户感受对齐。

这只是我自己的一种构思，不是行业里已经验证过的最佳实践。但背后的判断是清晰的：当人和人之间打分一致率长期停留在 75% 左右时，单纯依赖更多人力，或者继续加厚一份静态 rubric，都很难真正解决离线评测和线上效果之间的偏差。更有价值的方向，可能是从真实线上行为里反向学习"什么算好"。

不管这个具体方案最终是否成立，有一点是确定的：这个方向上做的任何尝试，本质上仍然是"一份评测"。它只是把"谁来打分"从人换成了 LLM 或小模型而已。评测 = 需求这件事的本质并没有变，变的只是评测自己的实现方式。

这里需要特别强调一下：搜推 / 广告不是一个可以轻描淡写带过的"例外"。

恰恰相反，过去十几年，对人类社会发挥最大规模影响的 AI 产品，很大程度上就是搜推和广告系统——Google、Facebook、抖音、TikTok、淘宝、YouTube，这些产品都建立在同一个底层逻辑上：用海量用户行为，持续优化信息分发。

搜推时代的特殊性在于，它面对的是一个天然适合规模化学习的问题：候选内容很多，用户行为极其密集，点击、停留、转化、划走、负反馈每天都在产生。当行为规模足够大时，"什么是好"可以被用户行为近似表达出来。

搜推时代，PM 仍然要定义目标：是优化点击、停留、转化，还是长期留存。

但一旦目标确定，系统就可以从海量行为里自动学习——用户每天都在用自己的行为给模型打分。

大模型时代的难点正好相反。模型提供的是生成式、概率型供给：一段回答、一份计划、一次推理路径、一次工具调用链。这些输出的好坏很难被一个简单的点击或停留直接解释。用户可能没有追问，不代表回答正确；用户点了赞，也不代表专业、安全、合规都满足；用户留存，也无法告诉你某一次回答里的错误到底发生在哪个维度。

所以，大模型时代不是没有 feedback，而是feedback 太稀疏、太滞后、太难归因，无法像搜推时代那样直接承担主监督信号。这就是为什么 AI 产品需要把需求重新写成Sample + Rubric + Metric：先由人定义一批典型场景和判断标准，再用线上 feedback 持续校准。

▲ 表 1 · 搜推时代与大模型时代的核心区别

所以这两个时代最大的区别，不是"有没有 AI"，而是好坏标准能不能主要从线上行为里自动长出来。搜推时代可以，大模型时代大多数场景不行。形式变了，产品经理的核心工作也就变了：不再只是定义功能和漏斗，而是要亲手定义样本、标准与指标。

到这里，"为什么评测重要"这件事已经讲清楚了。接下来是更接地气的三个问题：

下面我们一个个回答。

很多公司都设有专门的评测团队。我的观点是——评测团队作为「独立打分组织」的存在合理性，正在快速消失。

逻辑很简单：

需要补充一句：在高合规领域（医疗、法律、金融、教育、运动健康），人工 / 专家评测仍然是合规和信任的硬性要求——这部分不会消失，只会变得更"专"、更"贵"，不再是大公司里十几人规模的"评测团队"形态。

所以更准确的说法是：评测团队不会一夜消失，但它的组织形态正在被重构——独立打分组织会快速退场，评测的能力会被重新嵌回业务团队内部。

未来更可能的分工是：业务的产品经理定义评测、LLM Judge承担规模化打分、研发与算法维护评测流水线、专家只在最难的合规与价值判断上出现。

如果我们承认"评测即需求"，那合理的流程其实顺理成章——但在开始之前，有一件事需要先澄清：

benchmark 不是流程上的"第一步"。

它是任务边界 + Dataset + Rubric + Metric这几件事合起来的产物——是产品经理交付给研发团队的「需求形式化合约」。

理解了这一点，整个流程其实是两个阶段：

阶段一：构建 Benchmark（PM 主导）

三者合起来 = 一份完整的 benchmark

↓

阶段二：研发同步

评测与代码一起长出来

数据集和目标标准，是和需求一起被定义的——不是等开发完了再补一个评测出来。

▲ 图 2 · 阶段一三件事合起来就是 benchmark，阶段二的研发与评测要同步进行

具体来说：

阶段一：产品经理构建 benchmark

以上三件事合在一起，就是这个产品的 benchmark。benchmark 不是流程上的"第一步"，它是这三步加在一起的产物。

阶段二：研发与评测同步进行

数据集和目标标准要和需求一起被定义出来——否则后续所有研发动作，都没有真正的指向和目标。

更值得长期投入的是另一件事：评测标准与线上用户指标的一致性——这是一个会持续很多年的命题。

把上面提到的几个概念再向下展开一层，一份完整的评测设计，至少需要回答下面这六个问题：

▲ 表 2 · 评测设计的六要素：从"评什么"到"怎么评"的完整骨架

最后还有一个不能不提的趋势——随着 Agent 越来越复杂，评测的难度还在指数级上升。

在传统问答场景里，评测是eval answer：模型给出一个最终回答，评分人 / Judge 看这个答案对不对就够了。

但 Agent 的世界完全不同——模型不是只输出一个答案，而是输出一整条决策链路：

所以评测的对象，从一个"答案"变成了一条"轨迹"——不再是 eval answer，而是 eval trace。这意味着Dataset / Rubric / Metric / Judge这四件事，都要在"轨迹级别"被重新设计——关于 Agent 评测，我们会在专门的一节里展开。

回到文章开头那个问题：当产品从确定性操作变成概率型供给，需求该如何被定义？走到这里，答案应该已经清楚了。

PRD 是传统软件时代的重要载体，Sample / Eval 是 AI 时代的新语言。

不会写 PRD 的人，做不出软件产品；

不会写 Eval 的人，做不出 AI 产品。

你的Dataset决定了你看到的世界有多丰满；

你的Rubric决定了你定义的"好"有多锋利；

你的Metric决定了你的迭代有没有方向。

行业里有一句名言——评测就是护城河。这句话基本对，但需要补一句限定：

而最重要的一点是——

评测从来不是一锤定音。

它既是起点的定义（前置时定义需求），

也是终点的校准（上线后跟着 feedback 继续校准）。

评测跟着产品一起活——你的产品成熟到哪里，评测就该长到哪里。

第零章我们讲过 AI PM 的能力模型与工具箱——那是打基础的部分。

而从这里开始，我们进入"真正的工作"：所有 AI 产品的迭代节奏、成本结构、商业天花板，都要从一件事开始：先学会衡量，再谈做产品。

到这里，我们只完成了一件事：把评测从"上线前测试"，重新放回"需求定义"的位置。至于 Dataset 怎么构建、Rubric 怎么写、Metric 怎么量化、Judge 怎么校准、Agent trace 怎么评，每一个环节都有自己的难点，也都值得单独拆开讲。读到这里，你只需要先记住一个总判断：AI 产品的需求，不再只写在 PRD 里，而是写在 Sample、Rubric 和 Metric 里。

— 第一章第一节 完 —

历史内容：

AI产品经理手册：第零章-第一节：生成式 AI 可能是人类信息革命的终局

AI产品手册：第零章第二节 模型即产品，重新理解PM的角色：未来只有AI产品经理

AI产品手册第零章第三节：产品Agent化，软件形态正在发生什么变化

AI产品手册：第零章第四节：AIPM的能力模型，一个有战斗力的AIPM长什么样

AI产品手册：第零章第五节：AIPM的工具箱:以产出倒逼工具，让AI把你变成超级人类