公众号文章系列 · 19 · 评测三部曲 · 收官

评测即 PRD
PM 的交付物变了

那份我们写了十几年的 PRD 正在失效，接替它的是评测
Author姚光华 Colin
Role声网 ConvoAI 产品负责人
一手源Braintrust 三篇 · 2025-07 / 2026-03
Date2026.07
19
写评测，是 AI 时代一个产品经理能做的最重要的事。
—— Kevin Weil，OpenAI CPO。第一次读到这句话，我本能地觉得夸张，甚至有点博眼球。
原文标注为「OpenAI Ex CPO」，引文中作 "CPO at OpenAI"。
MONEY QUOTE · 01
写评测 是 AI 时代一个产品经理 能做的最重要的事
"Writing evals is the most important thing a PM can do in the AI era."
不是写 PRD，不是画原型，也不是排 roadmap —— 而是先把「什么叫好」写成一套可运行的 evals。
开场 · 我为什么改了看法04
一套评测，怎么就成了 PM 的头号交付物

我本能地觉得夸张

第一次读到
觉得夸张，甚至有点博眼球
一套评测，怎么就成了 PM 的头号交付物？
后来改了看法
这不是一句话，是岗位在迁移
把它和最近我们拆「活人感」基准、搭线上数据回流 Loop 的经历放在一起看。
不是写 PRD，不是画原型，也不是排 roadmap —— 而是先把「什么叫好」写成一套可运行的 evals。
这一篇讲清楚为什么。
ACT I / VI
SPEC
PRD 死于非确定性
传统产品开发是一条确定性的流水线：问题 → 需求 → 设计 → 开发 → 上线。
它能转起来，靠一个前提 —— 系统的行为，可以被事先完整地规定下来。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
ACT I · PRD 失效06
Problem → Spec → Design → Engineering → Ship

一条确定性的流水线

问题 Problem 需求 Spec 设计 Design 开发 Engineering 上线 Ship 它能转起来，靠一个前提： 系统的行为，可以被事先完整地规定下来 你写「点击按钮后弹出确认框」，工程照做，测试对着验，永远成立
PRD 是为「行为可以事先规定」的世界设计的。
ACT I · PRD 失效07
同一个输入，每次输出都不一样

AI 把这个前提抽掉了

同一个输入 输出 A 输出 B 输出 C 每次输出都不一样 同一个输入，也可能产生不同输出 模型、上下文或工具一变 行为还会整体漂移 PRD 是为「行为可以事先规定」的世界设计的。AI 不住在那个世界里。
你在 PRD 里写下那句经典的「回复要有帮助、要简洁」—— 原文的判决是三个 too。
ACT I · PRD 失效08
对「回复要有帮助、要简洁」的判决

三个 too，判了 PRD 的死刑

TOO VAGUE too vague to be actionable 太模糊，没法执行
TOO AMBIGUOUS too ambiguous to verify 太含混，没法验证
TOO STATIC too static to keep up with a system that changes behavior with every model update 太静态，跟不上
完整原文："A spec that says 'the model should be helpful and concise' is too vague to be actionable, too ambiguous to verify, and too static to keep up with a system that changes behavior with every model update."
系统每更新一次模型，行为就变一次，它根本跟不上。
MONEY QUOTE · 02
PRD 为「行为可预先规定」而生 AI 不住在那个世界里
同一个输入，每次输出都不一样；模型、上下文或工具一变，行为还会整体漂移。
你在 PRD 里写下的那句「回复要有帮助、要简洁」，太模糊、太含混、也太静态。
ACT II / VI
HILLCLIMB
把好换成一个可爬的数字
那用什么取代它？新循环是：问题 → 评测 → 爬坡 → 上线。
PM 用一组结构化、可重复的测试来定义「什么叫好」，工程对着这组测试迭代。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
ACT II · 新的循环11
Problem → Eval → Hillclimb → Ship

从一条流水线，到一个循环

OLD · LINEAR 问题 需求 设计 开发 上线 Problem → Spec → Design → Engineering → Ship 前提：行为可以被事先完整规定 AI 把这个前提抽掉了 NEW · LOOP 问题 评测 上线 爬坡 Problem → Eval → Hillclimb → Ship
工程对着这组测试迭代 —— 换 prompt、换检索、换工具、换模型都行，直到分数爬过质量线。
ACT II · 新的循环12
评测在这个循环里，不止一个身份

评测身兼三职

SPEC 它是规格 定义目标 「什么叫好」写成可运行的东西 ACCEPTANCE 它是验收 给出通过 / 失败 不再靠一场评审会拍板 ROADMAP 它是路线图 指出下一步该改哪 哪一项分数低，就先修哪一项 从此 PM 对工程说的不再是「做得更好一点」这种没法执行的话
它是规格（定义目标），是验收（给出通过 / 失败），也是路线图（指出下一步该改哪）。
ACT II · 新的循环13
例子 · 做一个「从做菜视频生成菜谱」的功能

一句 PRD，拆成三个命题

PRD 写法拆成的可测试命题怎么打分
菜谱要有帮助、步骤要准确一、格式对不对 —— 先食材后步骤？AI 裁判按一张评分细则打分
（同一句 PRD）二、视频里提到的食材都在吗？确定性检查，字符串匹配就行
（同一句 PRD）三、步骤是不是短句、易扫读？另一个 AI 裁判，用好 / 坏范例校准过
三个命题，三个可运行、可比较、可以持续往上推的数字标准。原文的 PRD 写法是「菜谱对用户要有帮助、步骤要准确」。
还抽象吗？拆开之后，它就是三个可以爬的数字。
ACT II · 新的循环14
同一件事，两句话就说完了

PM 对工程说的话，变了

MAKE IT GO UP Here is the eval. Make this number go up. 评测在这儿。把数字弄上去。
DUST vs COMMIT A PRD gathers dust in a Google Doc. An eval suite runs on every commit. PRD 积灰，eval 每次 commit 都跑
THE PM SHIFT PM 用一组结构化、可重复的测试来定义「什么叫好」 评测 = 规格 + 验收 + 路线图
工程团队对着这组测试迭代 —— 换 prompt、换检索、换工具、换模型都行 —— 直到分数爬过质量线。
从此 PM 对工程说的，不再是「做得更好一点」这种没法执行的话。
MONEY QUOTE · 03
评测在这儿 把这个数字给我弄上去
"Here is the eval. Make this number go up."
一份 PRD 在 Google Doc 里积灰；一套评测，每一次代码提交都会跑一遍。
ACT III / VI
SCORER
一个 scorer 只测一个维度
具体怎么写评测？配套的实操手册给了个三件套：数据集、任务、打分器。
三件套里，最重要的纪律落在 scorer 上 —— 而且它是纪律，不是建议。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
ACT III · 一维一器17
dataset · task · scorer

一套 Eval 的三件套

DATASET 数据集 黄金用例 / 边缘用例 生产里真实出过的失败 5–10 条就能起步 TASK 任务 prompt / agent / tools 被测的那个东西 SCORER 打分器 一个 scorer 只测一个维度 数据集要小而新鲜，别养一个越长越陈旧的大静态集 三件套里，最重要的纪律落在 scorer 上
数据集要覆盖黄金用例、边缘用例，以及生产里真实出过的失败。
ACT III · 一维一器18
最重要的原则，写在 scorer 上

把「好」拆成具体的维度

THE PRINCIPLE break 'good' into specific dimensions and score each one independently 每一项独立打分
THE KEY The key is one dimension per scorer. 一个 scorer，只测一个维度
WHAT GOES WRONG improving tone while letting accuracy slide, or tightening policy compliance while making responses robotic 语气变好，准确率下滑
原文："A customer support response might need to be correct, empathetic, concise, and compliant with company policy. If you lump all of these into a single score, you'll accidentally optimize the wrong thing."
一条客服回复要同时做到准确、共情、简洁、合规 —— 揉成一个总分，就会优化错方向。
ACT III · 一维一器19
为什么这条是纪律，而不是建议

总分会掩盖此消彼长

ONE DIMENSION PER SCORER 语气 ↑ 准确率 ↓ 总分 → 不动 你看着一条上扬的曲线 庆祝一个正在恶化的产品 把它们揉成一个总分，你就会在不知不觉中优化错方向
合规收紧了，回复却变得像机器人 —— 而总分看上去毫无变化。
ACT III · 一维一器20
这个坑我们自己结结实实踩过

做「活人感」基准那次

一开始想要的
一个漂亮的总分
一个数字，对内好汇报，对外好传播。做出来才发现它毫无用处。
后来全拆了
一项一个独立的 scorer
音色、情感、打断时机、话尾判定、解决率 —— 各自一个。
分涨了，不知道是音色变好了还是打断变准了；分跌了，不知道该派谁去修。拆完的那一周，评测才第一次真正开始指导迭代，而不只是每月发一张没人知道怎么办的成绩单。
总分会掩盖此消彼长。你看着一条上扬的曲线，庆祝一个正在恶化的产品。
MONEY QUOTE · 04
你看着一条上扬的曲线 庆祝一个正在恶化的产品
语气变好了，准确率却在往下滑；合规收紧了，回复却变得像机器人。
所以这条是纪律，不是建议：一个 scorer，只测一个维度。
ACT IV / VI
FLYWHEEL
单个评测不值钱，飞轮才值钱
写出第一个评测很容易。这篇文章真正的重心在后面一句 ——
难的是把它转成飞轮：观察 → 分析 → 评测 → 改进，然后回到第一步。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
ACT IV · 飞轮23
观察 → 分析 → 评测 → 改进

四个阶段，一个飞轮

FLYWHEEL 观察 · 记录生产里每一次 输入、输出、轨迹 分析 · 找出什么在坏、对谁坏 评测 · 把每一个真实失败 变成评测集里一条新用例 改进 · 对着更新后的评测集 迭代，上线，回到第一步 观察 分析 评测 改进 写出第一个评测很容易 难的是把它转成飞轮 真实世界的失败 会自动变成新的测试用例 系统每一周都在变好
单个评测不值钱，飞轮才值钱。
ACT IV · 飞轮24
它还给这个飞轮画了成熟度分级

四级成熟度，对号入座

MATURITY 对号入座：你的团队在哪一级？ STAGE 0 靠感觉 relying on vibes 原文说这叫盲飞 STAGE 1 有个测试集 只在大版本前跑一跑 多数团队在这儿 STAGE 2 评测进了 CI/CD 每次代码提交都自动跑 坏版本上线前会被拦下 STAGE 3 生产数据持续回流 系统每周都在变好 复利成持久优势 大多数团队该瞄准的地方
Stage 3 才是能复利成持久优势的那一级。
ACT IV · 飞轮25
读到这个飞轮的时候，我停了一下

同一套结构，两头画出来

STAGE 3 production data continuously flows back into your eval suite 生产数据持续回流评测集
WHY IT COMPOUNDS This is the stage that compounds into a durable advantage 复利成持久优势
它就是我们新产品里那套 Loop 在做的事 —— 让线上真实通话回流、自我学习、自我迭代。
它不能证明我们一定对，但至少说明：这不是关起门来造出的孤立判断。
一家评测公司从方法论这头画出的图，和我们从产品那头搭出的 Loop，是同一套结构。
MONEY QUOTE · 05
方法论这头画出的图 和产品那头搭出的 Loop 是同一套结构
Stage 3 就是飞轮：生产数据持续回流进评测集，系统每一周都在变好，
因为真实世界的失败会自动变成新的测试用例。
ACT V / VI
LESSONS
五条硬教训
来自每天跑三千个评测的团队。Braintrust 的 CEO 另写过一篇五条教训，
数据来自他们平台上真实的用量。我挑对你最有用的几条。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
3000+
平均每个组织每天跑约 13 个评测；
而最猛的团队，每天跑 3000+ 个，还要花几小时泡在 trace 日志里。
trace 日志 = 每次调用的完整执行记录。这个量级的差距，本身就是一条结论：评测不是季度性的验收动作，是每天都在跑的基础设施。
ACT V · 五条教训29
来自每天跑三千个评测的团队

五条硬教训

0124 小时好评测的标志，是你敢在 24 小时内换模型。Notion 的 AI 团队就是这么干的 —— 每一次大的模型发布，第二天就出现在产品里。
02够不着养一组 aspirational evals —— 故意维护一批当前模型只能得 10% 的测试，每次新模型出来就换进去重跑。
03上下文Context beats prompts。现代 agent 花在工具调用和输出上的 token，远多于系统 prompt 本身。
04整个循环An eval = data + task + scoring。只优化 prompt 的 A，输给了优化整个评测的 B —— 把一个不可行的功能变成了可行。
05别人 vibes不加验证就信第三方的评测，是有风险的。永远抽检一部分结果。
支撑这套打法的三件事：评测早就写好了、基础设施让换模型很容易，以及一条文化 —— If a new model enables something, drop everything and ship.
ACT V · 五条教训30
三句最扎的话

YAML、vibes，和标题的出处

YAML Switching one internal tool's output from JSON to YAML literally doubled its success rate 更短、更好解析、更省 token
VIBES an eval you haven't validated is just someone else's vibes 没验证过的 eval
THE TITLE Think of a scorer as the PRD for your AI's behavior 这句就是本文标题的出处
这一条管住所有引用第三方榜单的人：永远抽检一部分结果 —— 因为一个你没验证过的评测，只是别人的 vibes。
如果你用的是通用指标，那你交付的是别人的需求，不是你的。
MONEY QUOTE · 06
把打分器当成 你 AI 行为的 PRD
"Think of a scorer as the PRD for your AI's behavior: if you rely on a generic metric,
you're shipping someone else's requirements, not yours." 这句话，就是这篇文章标题的出处。
ACT VI / VI
WEEK
PM 的新一周
最后落到最实的地方。文章给了 AI 时代 PM 的一周节奏，具体到星期几。
注意这张时间表里没有的东西 —— 没有写 PRD 的日子。
I PRD 失效II 新的循环III 一维一器IV 飞轮V 五条教训VI 新一周
ACT VI · 新一周33
具体到星期几

PM 的一周长什么样

MON 周一 看生产轨迹 标出 20 条 没达标的回复 TUE 周二 把这 20 条整理成 5 条新评测用例 加进套件 WED 周三 拿上周版本和 本周候选 跑全套评测 THU 周四 看差值 上，或者不上 数据决定，不辩论 FRI 周五 飞轮比上周 又快了一点 注意这张时间表里没有的东西：没有写 PRD 的日子
周四那句最关键：上，或者不上 —— 数据决定，不开辩论会。
ACT VI · 新一周34
PM 的活，变成了四件

四件活，一条告诫

01定义好用可执行、可重复运行的标准定义「好」。
02挑出坏亲手挑出暴露「坏」的数据。
03拥有飞轮拥有那个把坏变好的飞轮。
04守不回归在模型换代时守住产品不回归。
唯一的告诫是 Goodhart 定律：如果你纯粹为了指标去优化，你就会把它玩坏。要不断把评测分数系回真实结果 —— 任务完成率、满意度、留存。
分数是山的形状，不是山本身。
MONEY QUOTE · 07
分数是山的形状 不是山本身
Goodhart 定律在这里同样成立：如果你纯粹为了指标去优化，你就会把它玩坏。
要不断把评测分数系回真实结果 —— 任务完成率、满意度、留存。
收官 · 三层验收36
评测三部曲到这儿收官

三篇，一层一层往上搭

THREE LAYERS 往上搭 #17 数据层 一句话听没听对不重要，重要的是错误改没改答案 一句话 #18 对话层 每一轮都对不重要，重要的是整段解决了没有、路径干不干净 一整段 #19 组织层 测什么、什么叫好，这个定义权是 PM 的核心交付物 谁定义 架构是你的主张，评测是你的证明
一个团队的评测水平，暴露它对自己产品的诚实程度。
MONEY QUOTE · 08
谁定义「什么叫好」 谁就在定义产品本身
在一个行为无法被事先规定的时代，这句话不是修辞，是字面意思。
而这支笔，现在就放在每个 PM 的桌上。
收官 · 导航与来源38
三部曲导航与一手来源

这支笔，就放在你桌上

17数据层《你的 demo 在骗你》—— 一句话听没听对不重要，重要的是错误改没改答案。
18对话层《每一轮都对，整段却错了》—— 重要的是整段解决了没有、路径干不干净。
19组织层《评测即 PRD》—— 测什么、什么叫好，这个定义权是 PM 的核心交付物。
References：[1] Evals are the new PRD（2026-03-27）· [2] Evals for PMs（2026-03-17）· [3] Five hard-learned lessons（2025-07-17），均来自 Braintrust 博客。
区别只是，有人还在用它写「回复要有帮助、要简洁」， 有人已经在用它写 scorer 了。
谢谢

谁定义什么叫好
谁就在定义产品

架构是你的主张，评测是你的证明
Author姚光华 Colin
一手源Braintrust 三篇 · 2025-07-17 / 2026-03-17 / 03-27
已核验三个 too · 三件套 · Stage 0-3 · 五条教训
立场提示Braintrust 是一家做 AI 评测的公司