为什么 Eval Design 会成为 AI PM 的核心能力？

前面三篇，我一直在讲一个问题：

AI coding / vibe coding 让 demo 变容易了。但 demo 做出来以后，怎么判断它真的能用？

第一篇讲的是：做出来，不等于成为产品。第二篇讲的是：Eval Design 不是给 AI 打分，而是定义什么叫做对。第三篇用 Asterline 做了一个真实实践案例：一个 AI feedback demo，怎么通过 Golden Set、Rubric、Review Log、Failure Types 和 Iteration History，把“看起来能用”的输出变得可检查。

写到这里，我更确定：Eval Design 不是 AI 产品里的边缘评估环节，而是 AI PM 管理质量的一部分。

因为 AI PM 要处理的，不只是：

这个功能有没有做出来？

还要处理：

这个 AI 在什么情况下算做对？错了会造成什么后果？哪些错误可以接受？哪些错误必须拦住？什么时候要交给人？下一版怎么证明真的变好了？

这些问题，正是 Eval Design 在回答的。

一、AI PM 面对的新问题：产品输出变得不确定

传统软件当然也有复杂度，也会有 bug 和边界情况。

但很多传统产品的输出，大体由确定规则产生：按钮、表单、筛选结果，都会按预设逻辑执行。

AI 产品多了一层不确定性。

因为产品输出不再完全由确定规则产生，而是由模型根据上下文生成。

同一个功能，换一批输入，表现可能完全不同。同一个 prompt，前 20 条样本看起来不错，第 21 条突然开始胡说。同一个 agent workflow，前几步都对，最后一步可能越权、误判、过度承诺。

所以 AI PM 不能只问：

功能有没有上线？流程有没有跑通？页面有没有做好？

还要问：

它在哪些输入下可靠？哪些输入下容易错？错了以后用户会不会发现？系统有没有办法拦住？团队怎么知道下一版真的变好了？

AI 产品的难点，不只是“把 AI 接进来”。

而是接进来之后，如何管理它的不确定性。

二、AI PM 不只定义功能，还要定义“什么叫做对”

很多 AI 功能，刚听起来都很简单。

客服机器人：回答用户问题。文档问答：基于文档回答。AI feedback 工具：整理用户反馈。Agent workflow：帮用户完成任务。

但真正做成产品时，“做对”并不显而易见。

客服机器人不是只要语气友好。

它不能乱承诺退款。不能违反政策。不能在用户愤怒时只甩规则。不能把应该转人工的投诉继续自动处理。

文档问答不是只要回答流畅。

它要引用正确来源。不能把多个文档的信息混在一起。不知道时要承认不知道。不能用一个自信的答案掩盖证据不足。

AI feedback 工具不是只要总结漂亮。

它要保留原始证据。要区分用户原话和产品推断。要知道哪些反馈只是情绪，哪些可能是 bug，哪些是模糊需求。不能把“页面很难找”直接翻译成“用户需要全局搜索”。

Agent workflow 也不是只要能跑完步骤。

它要选对工具。要按正确顺序执行。关键操作前要确认。权限不够时要停下来。失败后要知道恢复，而不是继续往下编。

这些判断都不是纯技术问题。

它们涉及用户场景、业务规则、风险边界、产品责任和用户预期。

所以“什么叫做对”，本来就是产品定义的一部分。

AI PM 如果只定义功能，不定义质量边界，很容易得到一个看起来能跑、但没人敢放心用的 AI 功能。

三、Eval Design 是 AI PM 的质量语言

我现在更愿意把 Eval Design 理解成一种质量语言。

它让团队不再只说：

这个 AI 效果不错。这个回答不太行。这个 agent 有点不稳定。这个版本感觉比上一版好。

这些话都太模糊。

真正能推动产品迭代的，是更具体的表达：

它错在分类。它错在引用来源。它漏掉了关键业务影响。它把用户没说过的话推断成需求。它在高风险场景没有触发人工审核。它生成了无法兑现的承诺。它不是 prompt 问题，而是 workflow 看不到必要上下文。

Eval Design 的价值，是把“AI 靠不靠谱”拆成一组可讨论的问题：

什么叫做对。什么叫做错。哪些错误可以接受。哪些错误必须拦住。哪些输出必须有证据。哪些场景必须人审。下一版如何证明真的变好了。

没有这套语言，团队很容易在两个极端之间摇摆。

一种是凭感觉乐观：

“这个 demo 看起来已经不错了。”

另一种是凭感觉悲观：

“AI 还是不太靠谱。”

但产品化的说法应该是：

在哪些场景下不错？哪些场景不靠谱？不靠谱是哪一种不靠谱？这种错误的代价是什么？该改 prompt、补 retrieval、加 checker、改 UX，还是加入 human review？

AI PM 不一定要亲自训练模型。

但 AI PM 必须参与定义这套质量语言。

因为模型可以生成答案，但产品要决定什么答案可以进入真实使用。

四、Eval Design 会改变 AI PM 的四个工作环节

Eval Design 不是一个独立环节。

它会影响产品定义、上线验收、风险控制和版本迭代。

1. 产品定义：不只写需求，还要写成功标准

传统 PRD 里，我们常写：

用户要完成什么任务。这个功能有哪些流程。有哪些状态和异常。上线后看什么指标。

AI 产品还要多写一层：

AI 在这个任务里，什么叫做对？

比如做文档问答，不只是写：

用户可以上传文档并提问。

还要定义：

回答必须基于文档。需要引用来源。多个文档冲突时要说明。找不到依据时不能编。用户问超出文档范围的问题时，要承认不知道。

这些不应该等到评估阶段才补。

否则工程做完以后，大家才开始争论“这个回答到底算不算好”，已经太晚了。

2. 上线验收：不只看 demo 能不能跑，还要看边界 case

AI demo 很容易在理想输入下表现不错。

输入清楚。上下文完整。用户意图明确。问题刚好在模型擅长范围内。

但真实用户不会这么配合。

他们会表达模糊。会把多个问题混在一起。会省略关键信息。会问超出系统能力的问题。会在情绪很强的时候使用产品。

所以 AI PM 做上线验收时，不能只看几个漂亮 demo case。

还要看：

典型场景能不能过。边界场景会怎么失败。高风险场景有没有被拦住。证据不足时会不会承认不知道。用户输入很乱时，系统是继续硬答，还是停下来追问。

这就是 eval cases / golden set 的价值。

它不是为了做一套考试题，而是为了让团队不要只用最顺的输入，证明自己已经做对了。

3. 风险控制：不只追求自动化，还要设计边界

AI 产品很容易让人想继续自动化。

能不能自动总结？能不能自动回复？能不能自动创建任务？能不能自动执行操作？能不能自动完成整个 workflow？

这些方向当然有价值。

但 AI PM 还要问另一组问题：

哪里不应该自动化？哪里必须有证据？哪里必须确认？哪里需要人审？哪里要让用户知道这是草稿，不是最终决定？

Human review 不是补丁。

它应该是 workflow 的一部分。

比如：

AI 可以整理用户反馈，但涉及金额、政策、时间承诺的客户回复必须人审。AI 可以生成产品建议，但不能自动进入 roadmap。AI 可以推荐下一步操作，但高风险操作前必须确认。AI 可以回答文档问题，但没有证据时必须说不知道。

好的 AI workflow，不只是能多做事。

它也要知道哪些事不能自己做。

这个边界不是模型自己会长出来的。

它需要产品定义。

4. 版本迭代：不只凭感觉调 prompt，还要看 failure types 和 regression

AI 产品迭代很容易变成：

再改改 prompt。换个模型试试。多加几个 examples。让输出更自然一点。让语气更专业一点。

这些都可能有用。

但如果没有 eval，团队很容易被“感觉变好了”骗到。

一个 prompt 改动可能让某些 case 变好，同时让另一些 case 变差。一个更复杂的规则可能听起来更完整，但实际引入新的误判。一个更自然的回复可能更像真人，却开始过度承诺。一个更积极的 agent 可能更有效率，却更容易越权。

所以 AI PM 需要看 failure types：

到底是分类错？引用错？漏信息？过度推断？没有触发人审？生成了不存在的流程？还是 workflow 本身缺上下文？

也要看 regression：

这一版是不是真的更好？还是只是某几个样本更好看？有没有把原本做对的 case 又弄错？如果变差，能不能撤回？

这就是 Eval Design 带来的迭代纪律。

它让 AI 产品迭代不只靠感觉，而是有比较对象、有失败分类、有回退依据。

五、这不是工程师单独能决定的事

很多人会觉得，eval 是技术团队的事情。

当然，技术团队很重要。

自动化检查、数据集管理、模型评估、日志监控、实验框架，这些都需要工程能力。

但 Eval Design 不能只交给工程师。

因为最关键的问题不是：

模型分数多少？

而是：

这个任务里什么叫做对？

这个问题本身需要产品判断。

客服机器人能不能承诺退款，不只是模型问题，是政策和责任问题。文档问答要不要回答超出资料范围的问题，不只是检索问题，是信任边界问题。AI feedback 工具能不能把模糊抱怨总结成明确需求，不只是总结能力问题，是 PM 工作流问题。Agent 能不能自动执行某个操作，不只是 tool calling 问题，是权限、确认和风险问题。

工程师可以帮你实现检查。

但 PM 必须参与定义检查什么。

否则很容易出现一种情况：

技术指标看起来不错。模型回答也很流畅。但产品风险没有被定义，用户场景没有被覆盖，责任边界没有被写清楚。

AI PM 的价值，就在这里。

不是替工程师做模型评估。而是把用户、业务、风险和系统能力放在一起，定义一套可以落地的质量标准。

六、所以，为什么 Eval Design 会成为 AI PM 的核心能力？

因为 AI PM 的核心挑战，不只是把 AI 功能做出来。

而是把 AI 的不确定性放回一个可管理的产品系统里。

这个系统里有模型、数据、上下文、工具、权限、检查、人工介入、用户预期，也有业务风险。

Eval Design 让 AI PM 能说清楚：

AI 在具体场景里什么叫做对。错了怎么发现。错在哪里。哪些错可以接受。哪些错必须拦住。哪些输出需要证据。哪些操作需要确认。哪些场景要交给人。下一版怎么证明真的变好了。

这不是 AI PM 的全部。

AI PM 仍然要懂用户、懂需求、懂业务、懂协作、懂取舍。

但只要产品里有模型生成、有 agent 调工具、有 AI 参与判断，就一定会遇到不确定性。

而 Eval Design，就是 AI PM 管理这种不确定性的核心方法之一。

七、一个现实落点：demo 之外，还要展示质量判断

这不是这篇的主线，只是一个现实落点。

如果 Eval Design 真的是 AI PM 能力的一部分，那么在展示 AI 项目时，只展示 demo 可能还不够。

Demo 证明的是：

这个想法可以跑起来。

但它不一定证明：

你知道它哪里可靠。你知道它哪里不可靠。你知道它错了该怎么诊断。你知道哪些风险要人审。你知道下一版是不是真的变好。

更有说服力的 AI PM proof-of-work，应该展示一点背后的质量判断：

任务边界是什么。eval criteria 是什么。failure types 是什么。human review 怎么设计。哪些版本变差了，为什么撤回。哪些问题不是 prompt 能解决的。

这不是包装技巧。

这是 AI PM 能力本身的一部分。

因为真实工作里，AI PM 也要持续回答这些问题。

最后

写完这几篇，我对 AI PM 的理解也变得更具体。

它不是会说很多 AI 名词。不是会写几个 prompt。也不是做出一个 demo 就够了。

更重要的是：

能不能定义 AI 在具体场景里什么叫做对。能不能发现它错在哪里。能不能判断哪些错误值得修，哪些错误必须拦。能不能设计 human review 和系统边界。能不能证明下一版真的变好了。

AI PM 的核心能力，不是把 AI 接进产品。

而是知道 AI 在哪里靠得住，在哪里靠不住，以及如何让它一版一版变得更可靠。