AI时代的PM核心竞争力正在被重新定义——Eval（评估体系）成为产品经理的新战场。本文深度整合OpenAI、Anthropic、Meta等顶尖AI公司的最佳实践，揭秘如何构建有效的AI评估系统，从Dataset设计到三种评分器的选择策略，手把手教你将模糊的产品需求转化为可量化的质量指标。

OpenAI 的 CPO Kevin Weil 和 Anthropic 的 CPO Mike Krieger，两家最顶尖 AI 公司的产品负责人，说过几乎一模一样的话：写 Eval 是 AI 时代 PM 最重要的能力。

作为一个技术背景有限的产品经理，我的第一反应是三个问题：Eval 到底是什么？别人是怎么做的？轮到我的 AI 项目，该怎么从零开始建？

在找答案的过程中，我读了不少材料，其中几份质量很高，值得单独拎出来说：

Anthropic 今年 1 月发了一篇《Demystifying Evals for AI Agents》，可能是目前关于 AI Agent 评测最完整的一份工程实践指南。里面不光有方法论，还有大量他们在 Claude Code 等产品上踩过的真实坑。

Meta 的 PM Daniel McKinnon 写了一篇《Show, Don’t Tell》，从 Llama 团队内部的视角讲了一个 PM 怎么动手写 Eval，非常接地气。他有一句话让我印象很深：别给建模团队发 PRD 了，直接给他们一个 Eval。

Braintrust 连发了两篇——《Evals Are the New PRD》和《Evals for PMs》，把”Eval 取代 PRD”这件事讲得很系统，还给出了一个 PM 可以直接参考的每周工作节奏。

Hamel Husain 教过 700 多名工程师和 PM 做 Eval，他把学员们问得最多的问题整理成了一份 FAQ，很多观点很犀利——比如”如果你的 Eval 通过率 100%，说明你的 Eval 太简单了”。

此外还参考了 OpenAI 的官方评测文档和 arXiv 上关于 Agent-as-Judge 的论文。

我把这些材料里和产品经理最相关的部分提炼了出来，按照一个刚接触 Eval 的 PM 会自然产生的问题串起来，写成了这篇文章。全文围绕十个问题展开：

1. Eval 是什么？
2. 这事跟 PM 有什么关系？
3. 一个 Eval 由什么组成？
4. 三种评分器怎么选？
5. 拿到一个 AI 产品，怎么从 0 到 1 建Eval？
6. Eval 建好了，然后呢？
7. 不同类型的 AI 产品，Eval 有什么不同？
8. AI 每次结果都不一样，Eval 分数还有意义吗？
9. 有哪些常见的坑？
10. Eval 除了保质量，还能干嘛？

可以说这篇文章综合了 Anthropic、OpenAI、Meta、Braintrust、Hamel Husain 等多方最佳实践。文中每一个具体的观点、案例和建议，都标注了来自哪份材料，方便你去看原文。所有参考来源的链接放在了文末。

第一个问题：Eval 是什么？

Eval，全称 Evaluation，说白了就是给 AI 出考试题，然后自动阅卷。

你准备一组输入（模拟用户会怎么问、怎么操作），设好判断标准（什么样的回答算好），把输入丢给 AI，拿输出和标准对一下，出个分。这件事本身并不复杂。复杂的是怎么出好题、怎么定好标准、怎么让这套系统持续运转起来。

为什么需要这个东西？因为 AI 产品和传统软件有一个根本区别。

传统软件的逻辑是确定的。你写了一个按钮，点一下就提交表单，每次都一样。你可以写一条测试：”点了提交，表单发出去了没？”通过就是通过，失败就是失败。

AI 不是这样。同一个输入，你今天问一遍和明天问一遍，答案可能不一样。”质量好不好”这件事是主观的，边缘情况多到数不清。传统那套”手动检查几个 case”的方式，在 AI 产品面前就像拿渔网接水——漏得一塌糊涂。

所以你需要一套能自动跑、能反复跑、能覆盖几百个场景的测试系统。这就是 Eval。

第二个问题：这事跟 PM 有什么关系？

OpenAI 的 CPO Kevin Weil 和 Anthropic 的 CPO Mike Krieger，两家最顶尖 AI 公司的产品负责人，说过几乎一模一样的话：写 Eval 是 AI 时代 PM 最重要的能力。

为什么是 PM 的事，不是工程师的事？

因为 Eval 的核心不是技术实现，而是定义”什么算好”——这是一个产品判断。你是那个最清楚用户在乎什么、哪些边缘情况重要、什么质量可以接受的人。工程师能帮你搭 Eval 的基础设施，但”出什么题、怎么评分”这件事，应该由 PM 来定。

Meta 的 PM Daniel McKinnon 说得很直接：当合作团队想让 Llama 做某件事，他的回复是”别给我发 PRD 了，直接给我一个 Eval。”因为 Eval 本身就是最精确的需求描述——它定义了什么算好、什么算不好，而且可以立刻跑，跑完就知道做到了没有（来源：meta产品经理Daniel D. McKinnon的博客文章）。

传统的产品开发流程是：发现问题 → 写 PRD → 出设计 → 排开发 → 上线。你在 PRD 里写”模型回复应该简洁有用”——”简洁”到什么程度？”有用”怎么衡量？这句话对工程师来说等于什么都没说。而且模型一更新行为就可能变，你的 PRD 还没改呢，产品已经不一样了。

Braintrust 把 AI 产品的新流程总结成（来源：Braintrust）：

发现问题 → 写 Eval 来定义”好”的标准 → 团队针对 Eval 做优化 → 上线。

你给工程师的指令从”请把这个做好”变成了”请让这个分数上去”。

PRD 写完就躺在文档里落灰了。Eval 可以每次代码提交都自动跑一遍。一个活的、持续运行的质量标准，肯定比一份落灰的文档有用。

第三个问题：一个 Eval 由什么组成？

搞清楚 Eval 的三个组件，是 PM 做这件事的起点。

1. Dataset（数据集）—— “考试题”

你要测试 AI 的那组输入。需要覆盖三类：你的产品绝对不能搞砸的核心场景、不常见但踩到就出大事的边缘情况、你已经知道 AI 犯过错的地方。

很多人觉得得准备几百道题才能开始。不用。Anthropic 说 20-50 道就够起步了（来源）。Hamel Husain 教过 700 多个工程师和 PM 做 Eval，他的建议更直接：找一个最懂你用户的人，花 30 分钟看 20-50 条 AI 的真实输出，标好哪条行、哪条不行——这就是你的最小起步（来源：Anthropic）。

2. Task（任务）—— “考试规则”

这个词在 Eval 的语境里不是指”做一件事”，而是指“这道题怎么考”——用哪个模型、用什么 Prompt（提示词）、参数怎么设、要不要调用外部工具。Task 定义的是从”输入进去”到”输出出来”的整个执行过程。

如果 Dataset 是试卷上的题目，Task 就是”这次考试的规则”——开卷还是闭卷、能不能用计算器、考多长时间。

PM 不需要自己写代码搭 Task。但你得知道当前 Task 里用的是什么模型、Prompt 是怎么写的，并且能上手改改 Prompt 的措辞——这往往是影响产品质量最直接的变量。

3. Scorer（评分器）—— “阅卷标准”

定义”怎么判断好坏”。这是 PM 在 Eval 里最核心的活儿。

最重要的原则：”好”不是一个整体，它是好几个维度拼起来的。每个维度要单独打分。

比如你做了一个 AI 客服。一条”好”的回复需要同时做到：回答准确、态度有温度、不啰嗦、符合公司规定。如果你把这四件事揉成一个总分，就很容易出现一种荒谬的结果：语气优化上去了，但准确率掉下来了，你还不知道。所以每个维度一个 Scorer，各管各的（来源：Braintrust）。

那 Scorer 有哪几种？这就引出了下一个问题。

第四个问题：谁来”阅卷”？三种 Scorer 怎么选？

Eval 里有三种 Scorer，搞明白它们各自擅长什么、什么时候该用哪种，是 PM 的基本功。

代码评分器（Code-based Scorer）：非黑即白

最简单的一种。用确定性的代码逻辑来判。回复里有没有包含某个关键词？长度超没超限？生成的代码能不能跑？数据库里是不是真的多了一条记录？

好处是快、便宜、结果稳定。坏处是死板——AI 如果用了你没想到的方式把事情做对了，它可能会误判成”错”。

Anthropic 的建议是：凡是能用代码判的场景，优先用代码判。（来源：Anthropic）

AI 评分器（LLM-as-Judge）：让另一个 AI 来打分

你先写一份评分标准（Rubric），然后让另一个 AI 按标准来给被测 AI 的输出打分。适合那些代码没法判的模糊场景——比如回复有没有同理心、语气是否专业、是不是在胡编乱造。

好处是灵活，能处理开放式的场景，还能大批量跑。坏处是每次结果可能不完全一样（毕竟判官本身也是 AI），而且需要定期和人类专家的判断做校对。

Anthropic 提了几个实操细节（来源：Anthropic）：

一，给 AI 阅卷老师一个”不确定”的选项。如果它信息不够，允许它说”我判断不了”，别让它硬凑一个分数出来。

二，每个维度用单独一个 AI 来打分，别让一个 AI 同时判所有维度。你让一个人同时改数学和作文，质量肯定不如分开改。

三，定期校准。光让 AI 打分不管不行，隔段时间要拿人类专家的判断来对一下，看 AI 的打分有没有跑偏。

人类评分器（Human Grader）：金标准，但也最坑

让真人来审——领域专家、训练过的标注员。质量当然最靠谱，但贵、慢，而且有一个大部分人都不知道的坑。

Meta 的 PM Daniel McKinnon 讲过一个很反直觉的数学问题（来源：meta产品经理Daniel D. McKinnon的博客文章）：

你安排三个标注员做一道二选一的题。结果两个人选了 A，一个选了 B。你可能觉得 66% 一致，还行。实际上不是。

你得看每一对标注员之间是不是一致：

• 1 和 2：都选了 A，一致 ✓
• 1 和 3：一个 A 一个 B，不一致 ✗
• 2 和 3：一个 A 一个 B，不一致 ✗

三对里只有一对一致，实际一致率是 33%。而如果纯靠蒙，随机一致率都有 50%。你的 33% 甚至还不如瞎猜。

McKinnon 的结论是：大部分人严重高估了人类评测的可靠性。如果你要做人类评测，判断标准必须写到极其精确以确保 Inter-annotator Agreement（标注员间一致性），否则等于白做。

小结：三种 Scorer 怎么组合

Anthropic 总结成一句话：能用代码判的用代码，需要灵活性时用 AI，人类只用于验证和校准。

Hamel Husain 还有一个补充建议：用通过/不通过的二分法，别用 1-5 分。1-5 分制下不同人对”3 分”和”4 分”的理解差距太大，噪音太多。二分法反而逼着你把”什么算过”定义清楚。

第五个问题：拿到一个 AI 产品，怎么从 0 到 1 建 Eval？

概念讲完了。现在假设你是一个 PM，面前有一个 AI 产品——可能是个客服机器人、可能是个写作助手、可能是个代码生成工具——你需要从零开始给它建 Eval。怎么走？

以下步骤综合了 Anthropic、Braintrust 和 Hamel Husain 的建议。

第一步：别等”准备好”，现在就开始

最常见的借口是”我的 Dataset 还没准备好”。别等了。

Anthropic 的原话：Eval 拖得越久越难建。早期阶段产品需求天然就能转化成测试题，但等你的系统已经在线上跑了很久，再回头补 Eval，就等于要从一个活的系统反向推导”到底什么算成功”——这比从头建难得多（来源：Anthropic）。

Hamel Husain 的建议更极端：先花 30 分钟手动看 20-50 个 AI 输出，用一个最懂你用户的人作为质量裁判——他管这个人叫”Benevolent Dictator（仁慈的独裁者）”。这就是你的最小可行 Eval（来源）。

第二步：把你已经在手动干的事情变成 Eval

你每次发版之前，是不是都会手动试几个 case 看看效果？把这些 case 写下来，就是你的第一批 Dataset。

如果产品已经在跑了，去翻 bug 记录和客服工单。用户真实报过的问题是最好的 Eval 素材。按影响面从大到小排个序就行。

第三步：把”好用”拆成几个可以打分的信号

来看一个具体例子。

假设你在做一个功能：根据烹饪视频自动生成食谱。需求文档写着”生成的食谱应该准确好用”。但”准确好用”怎么衡量？

你需要把它拆成几个具体的、可以打分的信号（这个例子来自 Braintrust 和 McKinnon 的文章）：

信号一：格式对不对？ 食材应该放前面，步骤放后面。→ 可以让一个 LLM-as-Judge 拿着”正确格式”的示例来对比打分。

信号二：视频里提到的食材，食谱里是不是都有？ → 先用语音识别把视频里的食材提出来，然后做个字符串匹配。这是纯 Code-based Scorer 能搞定的事。

信号三：步骤写得够不够简短好读？ → 可以直接统计每句话的字数（Code-based），也可以让 LLM-as-Judge 参考好写法和差写法来对比评分。

三个信号，三个 Scorer，分别打分。你不再跟工程师说”把食谱做好一点”，而是说”让这三个分数往上走”。

这就是 PM 在 Eval 里最核心的工作：把模糊的产品需求翻译成具体的、可衡量的评分维度。

第四步：写好题目——别有歧义

Anthropic 总结了一条判断标准：一道好的 Eval 题，应该让两个领域专家分别看完后，独立给出一样的通过/失败判断。如果两个人看完都不确定怎么打分，问题出在题目身上（来源）。

他们举了一个真实教训：审查 Terminal-Bench（一个编程基准测试）时发现，有一道题要求 AI 写一个脚本，但没指定文件存在哪。而 Scorer 默认脚本在某个特定路径下。结果 AI 脚本写对了，但因为放的位置不对被判失败——这不是 AI 的错，是题出得有漏洞。

一个实用的验证方法：给每道题写一个你知道一定对的”标准答案”（Reference Solution）。如果标准答案都过不了你自己的 Scorer，那是 Scorer 有 bug。

他们在实操中还遇到过更离谱的事：Claude Opus 4.5 在一个叫 CORE-Bench 的评测里一开始只得了 42 分。后来一个 Anthropic 的研究员去细查，发现一堆问题——Scorer 太死板（模型回答 “96.12” 但 Scorer 要求精确到 “96.124991…” 才算对）、有些题意思模糊、还有些随机任务根本没法精确复现。把这些 bug 修完之后，分数从 42% 直接跳到了 95%（来源）。

第五步：正反两面都得测

只测”AI 应该做 X”的场景，会训出一个对什么都做 X 的 AI。

Anthropic 在给 Claude.ai 做搜索功能的 Eval 时吃过这个亏。一开始他们只测了”应该搜索”的场景——比如”今天北京天气怎么样”。结果模型学到了一个错误策略：对几乎所有问题都先搜一下。但像”苹果公司是谁创立的”这种常识题根本不需要搜索，搜了反而更慢。他们后来加上了”不应该搜索”的场景，才在两个方向之间找到平衡。而且这个平衡调了很多轮才调好（来源）。

第六步：评结果，不评过程

很多人的直觉是去检查 AI 有没有按”正确的步骤”做事——比如是不是按顺序调用了工具 A、工具 B、工具 C。

Anthropic 说这条路走不通。AI 经常找到你压根没想到的正确路径，如果你只认自己设计好的那条路，等于在惩罚创造力。更好的做法是只管最终结果对不对（来源）。

打个比方：你点了个外卖，你在乎的是菜对不对、好不好吃、准时不准时。骑手走哪条路，你管不了也不用管。

还有一条相关的原则：允许 Partial Credit（部分得分）。一个 AI 客服正确识别了问题、也验证了用户身份，但最后退款操作没走通——这比一个开口就崩溃的 AI 客服好得多。你的 Scorer 得能体现这种差别，不能简单粗暴只分”过”和”不过”（来源）。

第七步：跑完 Eval 之后，一定要自己读 Transcript

这一条 Anthropic 反复强调，内部把它当作 AI 产品开发的关键技能。

Transcript（追踪记录）是 Eval 一次运行的完整日志——AI 说了什么、调了哪些工具、中间的推理过程是怎样的。每次 Eval 跑完，不要只看分数。你得点开那些失败的 case，看完整的 Transcript。很多时候你会发现，不是 AI 做错了，是你的 Scorer 拒绝了一个实际上挺好的方案。

他们专门投了资源做查看 Transcript 的工具，团队成员定期花时间读。这个习惯帮他们抓到了大量 Scorer 自身的 bug。

Anthropic 内部有一条规矩：在有人读完 Eval 细节和 Transcript 之前，不把任何 Eval 分数当作事实。（来源）

第六个问题：Eval 建好了，然后呢？

到这里，你已经有了第一个可以跑的 Eval。但 Eval 不是一锤子买卖，它真正的价值在于持续运转——Braintrust 把这叫做 Eval Flywheel（评测飞轮）（来源）。

飞轮的四个环节

观察（Observe）： 把 AI 在线上的每次输入输出和完整 Transcript 都记下来。

分析（Analyze）： 在日志里找规律。什么场景在出问题？哪类用户碰到的问题最多？

转化成 Eval（Evaluate）： 发现了失败模式，就加进 Dataset 里。每一次线上翻车，都是一道新的考试题。

改进（Improve）： 团队针对更新后的 Eval 做优化，发布改进，回到第一步。

这个循环跑起来之后会越转越快：更多的线上数据养出更好的 Eval，更好的 Eval 逼出更好的 AI，更好的 AI 带来更好的体验，更好的体验带来更多用户和数据。

你的用户其实一直在”出题”，只是你可能没收：一个差评 = 一道新题；用户编辑了 AI 输出 = 一份”标准答案”；用户对着同一个需求换了三种说法问 = 一个你还没覆盖到的场景。

飞轮的四个成熟度等级

零档：靠感觉。 手动试几个、凭直觉判断、等用户来投诉。

一档：有考试但不常考。 有了一些测试题和标准，大版本发布前跑一遍。

二档：自动化。 Eval 接进了 CI/CD 流程，质量不过关的版本自动被拦下来。

三档：飞轮转起来了。 线上的失败案例自动变成新的 Eval 题目，系统每周都在变好。

到第三档的团队，竞争优势是能积累的。大多数团队应该瞄准这一档。

两种 Eval 的区别

飞轮运转的过程中，你会自然遇到两种不同性质的 Eval：

Capability Eval（能力评测）——爬山。 回答的问题是”AI 还能多做好什么新的事“。通过率从低开始，给团队一座要爬的山。比如你的客服 AI 目前只能处理简单退款，你加入了”处理复杂的跨境退货”这种新题——一开始通过率可能只有 30%，随着优化逐步提升。

Regression Eval（回归评测）——守城。 回答的问题是”AI 还能不能做好它以前会做的事“。通过率应该接近 100%，掉了就说明改坏了什么东西。

Anthropic 讲了一个”毕业”机制：当一个 Capability Eval 的通过率稳定在高位之后，它就可以转成 Regression Eval——从”我们能做到吗”变成”我们还能稳定做到吗”（来源）。

但也要注意 Eval Saturation（评测饱和）的问题——通过率到 100% 之后，这个 Eval 对改进就没有指引作用了。代码审查公司 Qodo 一开始对 Opus 4.5 不太满意，因为他们用的 Eval 太简单，没有覆盖到模型在复杂长任务上的进步。后来换了一套更难的 Eval，才看清了实际的提升（来源）。

一个参考的 PM 周节奏

Braintrust 建议了一个 AI PM 可以参考的每周节奏（来源）：

周一：翻线上 Transcript，标记 20 条有问题的 AI 输出。

周二：从里面挑出 5 个最典型的，加进 Dataset。

周三：用更新后的 Eval 跑一遍当前方案和候选改进方案，对比。

周四：看结果。好了还是差了？哪个维度提升了，哪个退步了？数据决定发不发。

周五：飞轮又多转了一圈。

第七个问题：不同类型的 AI 产品，Eval 有什么不同？

前面讲的原则是通用的。但不同类型的 AI 产品，Eval 的侧重点确实不一样。Anthropic 按产品类型总结了各自的做法（来源：Anthropic）。

对话类（客服、销售、教练……）

对话类 AI 的特殊之处在于：不光要看”任务做完了没”，还要看”做的过程体验怎么样”。对话本身就是产品的一部分。

所以它的 Eval 通常是多维度的：工单有没有关掉（Code-based Scorer）、对话轮数有没有超过上限（Code-based Scorer）、语气有没有同理心（LLM-as-Judge）、有没有按政策办事（LLM-as-Judge 或 Code-based）。

另外，对话类 Eval 经常需要让一个 AI 来扮演用户。你总不能每次测试都找真人来聊。Anthropic 在对齐审计项目中就是这么做的——用一个 AI 模拟各种用户角色来跟被测 AI 对话。

真实案例：Descript（视频编辑工具） 的 AI 助手从三个角度做 Eval：别搞坏原来的东西、做我让你做的事、做好它。从人工打分起步，逐步迁移到 LLM-as-Judge，再加上定期人类校准。现在维护着两套 Eval——一套管质量基准，一套管 Regression。

真实案例：Bolt.new 是等产品已经有大量用户之后才开始做 Eval 的。三个月内搭好了一套系统：用静态分析给代码打分，用浏览器 Agent 来测试生成的 app 能不能用，用 LLM-as-Judge 来评估指令遵循的质量。

编码类

代码的 Eval 相对省心，因为”对不对”有天然的判断标准：能跑吗？测试过了吗？

行业里最主流的基准测试 SWE-bench Verified 就是这个思路——给 AI 一个真实的 GitHub issue，让它修，修完跑测试，过了就算对。一年之内，前沿模型在这个测试上的得分从 40% 涨到了 80% 以上。

但只看”跑没跑通”不够。你可能还想看代码质量、安全隐患、AI 过程中有没有做多余的事。这些就需要加上 LLM-as-Judge 或静态分析工具。

检索/研究类

这一类最难做 Eval，因为”什么算好”本身就没有唯一答案。做市场调研、做收购尽调、写科学报告——每种”好”的标准都不一样。

Anthropic 推荐组合打分：Groundedness（AI 说的话有没有出处可查）、Coverage（一个好答案该覆盖的要点有没有覆盖全）、Source Quality（用的来源是权威机构还是随便搜到的第一个）。

第八个问题：AI 每次跑出来的结果都不一样，Eval 分数还有意义吗？

这是做 Eval 一定会碰到的问题。同一道题，AI 这次做对了下次可能做错。那分数到底能说明什么？

Anthropic 介绍了两个指标来理解这种波动（来源）：

1. pass@k：k 次里至少成功一次。 k 越大分越高。适合”只要有一次做对就行”的场景——比如代码生成，只要有一个方案能跑通就够了。
2. pass^k：k 次全部成功。 k 越大分越低。适合用户期望每次都靠谱的场景——比如客服，用户不在乎你”平均成功率 90%”，他在乎的是这一次能不能帮到他。

如果你的 AI 单次成功率是 75%，让它连续做对 3 次的概率只有 0.75 × 0.75 × 0.75 ≈ 42%。

两个指标在只试一次的时候是一样的。但随着试验次数增加，它们讲的故事完全相反：一个趋近 100%，一个趋近 0%。选哪个取决于你的场景。

第九个问题：有哪些常见的坑？

在做 Eval 这件事上，踩过坑的人不少。提前知道能省很多时间。

1. 别试图衡量”AI 聪不聪明”。 那是 MMLU、GPQA 这些学术基准该干的活。McKinnon 明确说过：创建那种基准是”昂贵的研究级挑战”。你的 Eval 应该只回答一个问题——我的产品在这个具体场景下做得好不好（来源）。
2. 别让太多人一起设计 Eval。 人多嘴杂，最后出来的方案一定是折中的、不聚焦的。McKinnon 说他很多 Eval 就是自己一个人写的（来源）。
3. 别拿来别人的 Eval 直接用。 McKinnon 反复叮嘱：再有名的开源基准也可能有错。拿到任何 Eval 之后，第一件事是手动抽几个样本看看结果合不合理。他在团队用的很多 Eval 里都发现过错误，而且这种错误从数字上根本看不出来（来源）。
4. 别只在发版的时候跑一次。 跑一次的 Eval 不是质量体系，只是一次抽检。模型在变、数据在漂移、新的边缘情况在冒出来。Eval 得持续跑。
5. 别盯着分数不看业务。 Hamel Husain 有一个判断标准：如果你的 Eval 通过率 100%，大概率说明 Eval 太简单了。70% 的通过率可能反而更说明问题（来源）。
6. 别用脏环境跑 Eval。 Anthropic 发现过 Claude 在 Eval 里偷看上一轮试验残留的 git 记录来”作弊”的情况。每次跑试验必须从干净的环境开始，否则结果不可信（来源）。

第十个问题：Eval 除了保质量，还能干嘛？

很多团队做了 Eval 之后发现，它的价值远不止”确保质量”。

1. 模型切换变快了。 每隔一两个月就有更强的模型出来。没有 Eval 的团队要花好几周手动测试。有 Eval 的团队跑一遍就知道新模型哪些方面更强、哪些退步了，几天就能完成切换。Anthropic 说过，有 Eval 的竞争对手可以”在几天内确定新模型优势、调整 Prompt 并完成升级”（来源）。
2. 团队认知对齐了。 同一份产品文档，两个工程师可能对”边缘情况怎么处理”理解完全不同。Eval 直接给出答案，消灭歧义。
3. 产品和研发之间有了共同语言。 Anthropic 的原话是 Eval 可以成为”产品和研究团队之间最高带宽的沟通渠道”——它定义了研究者可以优化的具体指标，比任何 PRD 都精确（来源）。
4. 更多人可以参与改进 AI。 Anthropic 说”最接近用户和产品需求的人最适合定义成功标准”。PM、客户成功、甚至销售都可以贡献 Eval 用例。让他们参与进来——更好的做法是主动给他们工具和权限（来源）。

最后

如果你今天只能做一件事，那就是：选你产品里的一个 AI 功能，找 10 条真实的用户输入，自己判一下 AI 的回答哪条好、哪条不好。

McKinnon 的原话是：做了比完美更重要。你的第一个 Eval 可以很小、甚至是一次性的，只要它能帮你判断模型是不是在解决用户的问题就行（来源）。

Eval 不是什么高深的技术活，它是一种思维方式的转变：从”我觉得 AI 做得不错”变成”我有数据证明 AI 做得不错”。越早完成这个转变越好。

参考来源

1. Anthropic: Demystifying Evals for AI Agents
2. OpenAI: Evaluation Best Practices
3. OpenAI Cookbook: Getting Started with OpenAI Evals
4. Hamel Husain: LLM Evals – Everything You Need to Know
5. Braintrust: Evals Are the New PRD
6. Braintrust: Evals for PMs
7. Daniel McKinnon (Meta PM): Show, Don’t Tell
8. arXiv: Agent-as-Judge