“The new PRD are the evals.” —— Xavi Amatriain，Expedia Group 首任 Chief AI and Data Officer，VB Transform 2026
这句话最近从会场传遍了产品圈。Braintrust 的同名文章给了它一个更锋利的版本：
A PRD gathers dust in a Google Doc. An eval suite runs on every commit. （PRD 在 Google Doc 里落灰，eval 套件在每次提交时运行。）
口号很好记，但口号说不清两件事：为什么 PRD 会在 AI 产品上失效，以及——更少有人问的——eval 接过规格的位置之后，会继承哪些新的失效方式。这篇文章用三篇论文把这两个问题拆开。先给结论：
把 PRD 换成 eval，本质是把产品规格从「给人读的散文」变成「给机器跑的目标函数」。这解决了规格无法执行的老问题，但也让规格第一次可以被优化压力「钻空子」。所以真正的交付物不是一份 eval 套件，而是一个让 eval 与真实意图持续对齐的闭环。
PRD 失效的根源：确定性假设塌了
传统产品开发是一条流水线：问题 → PRD → 设计 → 工程 → 上线。这条线能走通，靠一个隐含前提——行为是确定的。规格写”点击按钮后弹出确认框”，工程实现它，QA 验证它，同样的输入永远产出同样的行为。文档描述意图，代码兑现意图，两者之间的翻译虽然有损，但至少可以逐条验收。
LLM 产品打破了这个前提。同一个 prompt，每次跑出来的结果都不一样；模型一升级，行为整体漂移。这时 PRD 里最常见的那类句子——“回答应该有帮助且简洁”——暴露出它的真实身份：它从来不是规格，只是愿望。它太模糊，无法执行；太静态，跟不上模型变化；而且没有任何机制在它被违反时报警。
Eval 针对的正是这三条。所谓 eval，就是一组结构化、可重复、自动化的产品质量评测：给定输入集（常称 golden dataset），对输出打分（用代码断言、或用另一个模型当裁判），产出一个可以被追踪的数字。对比一下两种规格形态：
| PRD（散文规格） | Eval（可执行规格） | |
|---|---|---|
| 形态 | 自然语言文档 | 数据集 + 打分器 + 阈值 |
| 如何生效 | 被人读、被人记住 | 每次提交自动运行 |
| 如何腐烂 | 落灰：没人再打开它 | 失准：分数上去了，体验没上去 |
| 典型失败 | 含糊、无法验收 | Goodhart、假阳性信心 |
| 对工程的指令 | ”理解我的意图" | "让这个数字上去” |
注意最后一行。Braintrust 文章里给工程团队的指令原话是 “Here is the eval. Make this number go up.”——这句话既是 eval 的全部威力，也是它全部风险的来源。我们后面回来说。
学术版本：EDDOps，把口号变成流程模型
如果”eval 是新的 PRD”只是产品圈的修辞，它不值得写一篇文章。但学术界几乎同步给出了系统化的版本。CSIRO Data61 的 Xia 等人在 Evaluation-Driven Development and Operations of LLM Agents: A Process Model and Reference Architecture（arXiv:2411.13768）中，通过对学界与工业界评测实践的多源文献综述，提炼出一个他们称为 EDDOps（Evaluation-Driven Development and Operations）的范式，核心主张一句话：
评测不是流水线末端的检查点，而是贯穿整个生命周期的治理函数。
论文给出一个流程模型和一个参考架构，把两类评测焊进一个闭环：离线评测（开发期，跑基准和测试集）和在线评测（运行期，监控真实流量中的行为），线上观察到的失败回流成新的离线测试用例。这正是 Amatriain 在 Transform 会上描述的 Expedia 实践——监控信号回流进 eval 套件，“You can almost automate the whole cycle”。
值得一提的是，这篇论文的 v1 标题里明确写着受测试驱动开发（TDD）启发。这刚好接住一个绕不开的质疑，值得单独一节说清。
插一问：Eval 不就是换了名字的 TDD 吗？
不是，但确实是近亲。共同点是把规格写成可执行、可自动运行的产物，用红绿循环驱动开发——这层血缘让工程师第一眼觉得眼熟。但差别从验证对象开始，一路分岔：
| TDD 的测试 | Eval | |
|---|---|---|
| 验证对象 | 你写的代码逻辑 | 模型的涌现行为（你没写、也不能直接改） |
| 结果性质 | 确定性断言：红/绿，可复现 | 分布上的统计度量：通过率、均分 |
| 标准何时确定 | 写测试前就知道正确行为 | 看了输出才知道标准是什么（下一节） |
| 打分器 | 精确断言（assertEquals） | 常靠 LLM 裁判或人打分，打分器自己会错 |
| 失败的含义 | 堆栈指向具体某行，去修它 | 分数掉了不告诉你哪里坏了 |
| 100% 通过 | 有意义的门禁 | 通常说明题太简单，该换更难的 |
| 生命周期 | 基本止步于 CI | 延伸到生产：在线监控回流 |
其中三条值得展开。
确定性 vs 分布。同样的代码跑同样的测试，结果永远一样；同样的 prompt 跑同样的 eval，分数会抖。所以测试结果是事实，eval 结果是统计——92 分掉到 89 分，你得先判断是回归还是噪声，TDD 里不存在这一步。这也解释了生命周期那一行：模型一升级，行为整体漂移，代码一行没动、测试照样全绿，只有 eval 能看见。
修复路径完全不同。测试挂了，堆栈指向某一行，你去改那一行。Eval 分数掉了，你不能”修改模型的第 384 层”——只能间接地调 prompt、换数据、微调。这正是 eval 更像 PRD 而不像测试的原因：它给工程的指令是”让这个数字上去”（定义目标），而不是”修复这个断言”（定位缺陷）。定义目标是产品文档的职能，定位缺陷才是测试的职能。
Goodhart 暴露面。确定性逻辑下，测试过了就是对了，几乎没有”钻空子”的空间；而 eval 分数只是意图的代理，优化代理可以偏离意图。测试不会被跑赢，eval 会——这是后面第二道裂缝的主题。
一句话收束这个对比：TDD 验证”我有没有把东西做对”（实现正确性），eval 定义”对的东西是什么”（产品意图）。测试是验收标准的可执行版，eval 是需求文档的可执行版——所以说它是新的 PRD，而不是新的单元测试。
还剩表里的第三行没讲，它是整个故事里最反直觉的一环：写测试之前你知道正确行为是什么，而写 eval 之前，你往往并不知道自己的标准是什么。
第一道裂缝：标准会漂（Criteria Drift）
Shreya Shankar 等人在 UIST 2024 的论文 Who Validates the Validators?（arXiv:2404.12272）中构建了 EvalGen——一个帮人生成评测标准和断言的系统——然后在对 9 位专家用户的定性研究中观察到一个现象，他们命名为 criteria drift（标准漂移）：
人们是在给模型输出打分的过程中，才逐渐弄清自己的评测标准的。
这是一个 catch-22：要给输出打分，你得先写下标准；但只有看过足够多的输出，你才知道标准该怎么写。研究中的参与者即使先定标准再打分，也会在打分过程中不断修订标准，甚至回头改掉自己之前打过的分。论文的结论很直接：有些评测标准依赖于你观察到的具体输出，无法先验地完整定义。
顺带一提，Shankar 同时也是那门最著名的 AI evals 课程的共同创作者（与 Hamel Husain 一起，Lenny’s Newsletter 的热门访谈就是围绕他们展开的）。教 PM 写 eval 的人，恰恰是证明了”eval 标准写不全”的人——这不是讽刺，而是这个领域最诚实的注脚。
对”eval 是新的 PRD”这个口号，criteria drift 是一次精确的修正而非否定：它宣判的其实是静态规格的死刑，不管这份规格是散文还是数据集。一份写完就锁进抽屉的 golden dataset，和一份落灰的 PRD 没有本质区别。Eval 相对 PRD 的真正优势不在”更准确”，而在它天生可以迭代——它是跑在流水线里的活物，每一次线上失败都能变成一条新测试用例，而文档做不到这一点。
第二道裂缝：Eval 自己就是有 bug 的代码
第二个问题更硬：如果 eval 是规格，那么有 bug 的 eval 就是有 bug 的规格。
Zhu 等人的 Establishing Best Practices for Building Rigorous Agentic Benchmarks（arXiv:2507.02825，NeurIPS）系统性地审计了十个流行的 agent 基准，发现问题普遍存在于两个环节——任务设置和奖励设计。两个例子足够说明问题：
- SWE-bench Verified 的部分任务测试用例不充分——补丁没真正修对，测试也能过；
- TAU-bench 把空响应计为成功——agent 什么都不做反而得分。
这类缺陷导致的性能误估，相对幅度可达 100%。作者提出一份 Agentic Benchmark Checklist（ABC），从任务有效性（任务可解当且仅当 agent 具备目标能力）、结果有效性（打分器真的在测目标产出）、基准报告三个维度做审计；应用到评测设计复杂的 CVE-Bench 上，修正了 33% 的高估。
现在回想那句指令——“Here is the eval. Make this number go up.”。当一个数字成为团队的优化目标，优化压力就会精准地流向打分器的每一条缝隙。这就是 Goodhart 定律在产品开发流程里的具身：一个度量一旦成为目标，它就不再是好度量。写 PRD 的时代不存在这个问题，不是因为 PRD 更好，而是因为没人会去”优化一份文档”；eval 第一次让规格变得可以被跑赢。模型会钻空子（reward hacking），团队也会——不是出于恶意，而是因为流程明确告诉他们：让数字上去。
第三道裂缝：过了 eval，死在客户手里
第三个问题来自生产环境的数据。VentureBeat 在报道 Transform 会议的同一篇文章里引用了 VB Pulse 对 157 家企业（百人以上规模，2026 年 6 月，自选样本，读作方向而非精确值）的调查：
- 66% 的企业已经允许某种程度的无人工审核生产部署，或正在 12 个月内朝这个方向推进；
- 但只有 5% 完全信任支撑这个决策的自动化评测；
- 一半的企业发布过通过内部 eval、却在真实客户面前失败的 agent，其中四分之一不止一次。
不信任的头号原因（29% 的受访者）恰好呼应了前两道裂缝：评测结果与真实世界的结果对不齐。这组数字画出的是一个危险的剪刀差：自动化的部署速度在超过对评测体系的信任速度。
耐人寻味的是，喊出”eval 是新的 PRD”的 Expedia 自己，实践里并不只有 eval。Amatriain 描述的是一套按风险校准的关卡机制（toll gates）：评测轮次、红队测试、安全审查与每个 agent 的风险等级挂钩，风险越高，检查从”建议”变成”强制”。而对最高风险的动作，答案干脆是不给自主权——“We don’t want the agent to book the hotel or buy you a plane ticket for you.”（我们不想让 agent 替你订酒店、买机票。）会上也有其他讲者明确反对把关口全交给 eval：最高风险的动作仍然需要硬护栏，而不是一个分数。
Eval 是规格，不是许可。分数决定”这个行为符不符合我们定义的好”，风险等级决定”这类行为允许自动化到什么程度”——这是两个独立的旋钮，混为一谈就会成为那 50% 中的一员。
收束：规格的三态，和搬不走的缝隙
把三道裂缝放回同一个框架里看，它们其实是同一件事的三个切面。产品规格从来有三种形态：
- 意图——活在人脑里的”我们想要什么”；
- 散文——PRD，意图的自然语言投影；
- 代理度量——eval，意图的可执行投影。
每一次投影都有损耗。意图→散文，损耗是含糊（criteria drift 告诉你：有些标准在看到输出之前根本无法写出）；散文→度量，损耗是代理偏差（ABC 论文告诉你：打分器本身会有 bug，而 Goodhart 保证这些 bug 会被找到）；度量→生产，损耗是分布外失效（VB Pulse 的 50% 告诉你：内部分布和真实客户不是一回事）。
“Eval 是新的 PRD”的正确读法，不是”把一份文档换成一个数据集”——那只是把规格从一种静态形态搬进另一种静态形态。正确的读法是：把”写规格”从一次性动作换成持续闭环。EDDOps 的离线-在线循环、EvalGen 的人在环中修订标准、Expedia 的监控回流，三者收敛在同一个形状上：
flowchart LR
I["意图<br/>（想要什么）"] --> C["评测标准<br/>（criteria）"]
C --> E["Eval 套件<br/>（数据集 + 打分器）"]
E -->|"每次提交运行"| D["开发迭代"]
D --> P["生产部署<br/>（按风险分级关卡）"]
P --> M["在线监控<br/>真实流量"]
M -->|"失败案例回流为测试用例"| E
M -->|"观察输出 → 修订标准<br/>（criteria drift）"| C
E -.->|"审计打分器本身<br/>（ABC checklist）"| E图里有两条最容易被省略的边：监控回到标准（承认标准会漂，主动修订而不是假装它先验完备），和 eval 审计自身（承认打分器是代码，代码就要被测试）。省略第一条，你的规格会静态腐烂——和 PRD 一样；省略第二条，你会带着 100% 的误估幅度满怀信心地发布。
所以，评估体系是新的 PRD 吗？是的——但要理解这次升级真正升级了什么。PRD 时代的规格问题是”写不清楚”，eval 时代的规格问题是”测不准确”。缝隙没有消失，只是从散文的含糊搬进了目标函数的偏差。区别在于：含糊无法度量，偏差可以。这就是全部的进步，也已经足够多了。
PRD 落灰，是因为没人跑它。Eval 不会落灰，但会被跑赢。你的工作，从”把意图写清楚”，变成了”把意图测准确——并且在它被钻空子之前发现”。
参考
论文
- Xia et al., Evaluation-Driven Development and Operations of LLM Agents: A Process Model and Reference Architecture, arXiv:2411.13768
- Shankar et al., Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences, arXiv:2404.12272, UIST 2024
- Zhu et al., Establishing Best Practices for Building Rigorous Agentic Benchmarks, arXiv:2507.02825, NeurIPS
报道与实践
- VentureBeat, Evals are the new PRD, Expedia’s AI chief tells VB Transform 2026
- Braintrust, Evals are the new PRD
- Lenny’s Newsletter, Why AI evals are the hottest new skill for product builders（Hamel Husain & Shreya Shankar 访谈）
- Anthropic Engineering, Demystifying evals for AI agents