大厂 Evals 经验系列 · EDD 专题
改了一段提示词，几个回答看起来更好了。这个版本应该上线吗？
先设想一个资料助手：旧版偶尔漏掉来源，新版总会补上引用。但引用可能并不支持结论，回答也可能更慢。仅凭几个顺眼的回答，我们还不知道这次改动解决了什么，又带来了什么。
评测驱动开发，英文为 Eval-Driven Development 或 Evaluation-Driven Development，简称 EDD。本文将它理解为一种开发方式：先把成功条件变成可重复检查的案例和规则，再依据结果选择下一次改动。Google、OpenAI 和 Anthropic 都明确讨论了这种做法。Google 指南、OpenAI 指南、Anthropic 指南
这篇先建立完整的理解路径。后续厂商解读分别讨论提示词实验、需求断言、执行记录和线上反馈；这里不展开各个平台的安装与接口。
什么叫“评测驱动”
评测是检查 AI 系统表现的过程。它可以检查一句回答，也可以运行一个完整任务，核对工具调用、生成文件和实际业务状态。
EDD 中的“驱动”落在开发决策上。一个评分报告是否被做出来，并不足以说明开发已经由评测驱动。还要看：这份证据是否改变了团队要修什么、采用哪个版本，以及何时上线的判断。
我的判断方法是追问三件事：修改前预期改善哪项行为？修改后在哪批任务上得到支持？如果其他重要行为变差，团队怎样处理？回答不清这些问题，评测与迭代之间就还有一段没有接上的关系。
它也不要求一开始把所有标准写完。新任务常常需要看过输出后，才能发现“完整”“有用”里藏着哪些要求。标准可以演进，但版本比较时必须知道采用的是哪一版标准。
与 TDD、常规测试和模型榜单的关系
TDD 是测试驱动开发。它通常按写出失败测试、实现通过测试、重构的短循环推进；测试也帮助澄清行为约定。Martin Fowler 的 TDD 说明
EDD 借鉴了先明确预期、再用反馈迭代的思路。变化在于，AI 的合理输出可能不止一种，同一个输入也可能得到不同结果。检查可以结合代码规则、人工判断和模型评分，而不必逐字匹配一个标准答案。
这不意味着单元测试失效。对一个能查询订单的 Agent，订单接口和金额计算仍可以用代码测试；还要另外评测 Agent 有没有选对订单、有没有误解问题，以及是否向用户报告了正确状态。
| 做法 | 主要回答什么 | 在开发中的用途 |
|---|---|---|
| 单元／集成测试 | 某个组件或接口是否符合约定 | 检查工程实现 |
| 应用评测 | AI 系统在具体任务中表现怎样 | 发现能力缺口、检查改动 |
| EDD | 怎样让评测证据持续影响开发选择 | 组织迭代流程 |
| 公共模型榜单 | 模型在指定基准上表现怎样 | 提供选型线索 |
这是本文为理解所作的分层，不是四种互斥方法。公共榜单可以提供信号，但其任务分布未必代表你的用户。应用自己的案例仍然需要建立。Google 对公共基准的提醒
跑起一轮 EDD，需要准备什么
可以从五项准备开始。下面是一套本文建议的最小组织方式。
第一，成功标准。 写清用户要达成的结果、必须遵守的约束、遇到信息不足时应怎样处理。把“分析专业”拆成可判断的要求，例如关键数字正确、主要判断有依据、未知信息明确标注。
第二，代表案例。 保留输入、必要上下文和预期行为。正常任务、历史失败、边界情况都需要，但它们承担不同用途。不要把只包含难题的压力测试成绩，解释成全体用户的平均体验。
第三，评分规则。 每项规则说明看什么证据、怎样判定。代码适合数值和状态核验；模型可以辅助判断相关性与完整性；人工用于确定业务标准，并检查自动评分是否可靠。
第四，执行环境。 固定可用工具、初始数据、权限和必要文件。每次运行尽量从同样的初始状态开始，避免上次生成的文件或缓存替新版本完成了任务。
第五，版本基线。 记录模型、提示词、代码、知识数据和评测规则的版本。基线是准备比较的参照，不一定是一套成熟产品。
Anthropic 特别强调清楚的任务条件、评分器校准和稳定环境。它们共同解决一个问题：低分究竟来自 Agent，还是来自题目、评分或运行条件。任务与环境建议
一次修改怎样走完这个循环
下面继续用一个假设的资料助手说明，不对应任何厂商的实测结果。
用户希望得到一份有依据的分析。团队发现旧版有时把来源中的相关关系写成因果关系，于是把这类错误列为本轮要改善的行为。
先准备一组案例：材料只支持相关关系的任务；材料明确提供因果证据的任务；证据不足、应该保留判断的任务。第三类很重要，否则系统可能为了降低错误率，对任何问题都不下结论。
用旧版建立基线，保留每次输出、使用的来源和评分理由。再提出一个可检查的修改假设：在提示词中要求区分事实和推断，可能减少没有依据的因果判断。
新版本在相同案例、相同评分规则和相同环境下运行。比较时既看目标错误有没有减少，也看是否出现大量回避、关键内容遗漏或成本增加。不要同时换模型、改检索、改提示词，再把所有变化都归功于其中一项。
如果失败集中在拿错资料，下一次应该检查检索；如果资料正确、回答却扩大结论，就检查生成行为；如果合理回答被判错，则修订评分规则。发现评分规则有问题后，应使用修订后的同一规则重评可比版本。
离线结果支持改动后，再安排与风险相称的小范围验证，观察真实用户能否完成任务。线上新问题可以加入下一轮案例，而不是只留在聊天记录里。这种线上记录与离线实验相互连接的方式，也能在 Langfuse 的官方流程中看到。线上与离线评测
整个过程可写成：
定义成功 → 建立案例和基线 → 分析失败 → 修改一项关键因素 → 同条件复测 → 线上验证 → 补充案例。
“下一步应该改什么”来自失败证据。修改可以涉及提示词、模型、检索或工具，并没有“只要调提示词就能解决”的前提。
Agent 为什么还要检查结果和稳定性
普通回答主要面对文本质量。Agent 还会调用工具、改变状态，多步操作中的错误可以传到后面。
例如一个假设的报表 Agent 说“文件已生成”，至少要检查文件是否存在、内容是否覆盖指定范围。文本中宣告成功，与环境中确实完成，是两类证据。Anthropic 将最终环境状态称为 outcome；这一点对会实际执行操作的系统尤其重要。评测结构
检查过程时，要区分业务约束和偶然路径。如果要求先获得授权再修改数据，这个顺序必须检查；如果两种查询方式都能得到正确结果，就没必要只接受设计者预想的一种。
还要区分“能成功”与“经常成功”。某道任务跑一次通过，不能证明它之后都可靠。需要重复运行，观察波动，并保留各次执行记录。尝试多次至少成功一次，与每次都成功，代表的产品体验不同。tau-bench 论文也专门提出了检查多次运行一致性的指标。论文摘要
报告成功率时，应写清分母。是案例数、执行次数，还是所有线上请求？本文建议同时列出成功、失败、未知和运行故障的数量。若部分结果无法核验，就不能用剩下的已评分结果悄悄代表全部任务。
成本也要与结果一起看。本文建议的一种指标是“单位有效任务成本”：在口径一致的运行批次中，用总调用成本除以满足成功标准的任务数，并把失败与重试成本纳入总成本。若按业务任务计算，同一任务的重试合并为一项，成功任务按任务 ID 去重；若按成功执行次数计算，则另行注明口径。成功数为零时，该指标不适用。这个定义是本文建议，不是统一行业标准。
为什么分数上升仍可能误导
第一种情况是案例不代表实际使用。比如只测资料齐全的简单问题，真实用户却经常缺少关键条件。这套评测可以说明一个局部能力，不能支持更大的上线范围。
第二种情况是评分规则偏了。模型裁判可能偏好更长的回答，或受到候选答案位置影响。需要用人工已判断的案例校准它，尤其检查影响业务结论的错误。OpenAI 的评分建议
第三种情况是过度适应已知题目。为几个错误追加越来越窄的规则，可能修好了眼前句子，却没有改善同类问题。本文建议把用于开发调试的案例与用于验证的保留案例分开，重要改动还要看没有参与调试的新案例。
第四种情况是比较条件变化了。知识库更新、工具故障、评分模型变化，都可能改变结果。若多个因素同时变化，报告应该说明无法单独归因，不能只展示一个涨分数字。
第五种情况是测到了错误目标。更高的回答质量分，未必带来更高的任务完成率或用户复用率。离线评测负责减少已知失败；真实产品结果还需要线上观察。评测不能替代用户研究。
EDDOps 是把这套思路延伸到开发与运行全周期的提法。一篇相关论文提出连接离线和线上评测的过程模型与参考架构。它可以作为组织流程的参考，不能视为所有团队已经验证的标准；当前 arXiv 页面仍标注在审稿。论文摘要与版本信息
产品、研发和评测人员怎样开始
不必先购买平台。先选择一个重要、范围清楚的任务，准备少量真实案例，跑完一轮有记录的比较。Anthropic 建议早期可以从 20–50 个真实任务起步；这个数量用于发现较明显的问题，不构成上线保证。起步建议
角色分工可以这样安排，这是本文给项目团队的建议：
| 角色 | 主要贡献 | 第一轮交付物 |
|---|---|---|
| 产品／业务人员 | 定义用户目标、重要约束和不可接受的失败 | 成功条件与案例预期 |
| 研发人员 | 提供可重复执行的系统与改动版本 | 执行入口、版本记录、运行日志 |
| 评测／领域人员 | 检查题目、评分与真实判断是否一致 | 评分规则与校准记录 |
| 运营／支持人员 | 提供实际失败和使用分布 | 线上案例与用户反馈 |
第一轮至少留下四份东西：带预期的案例集、版本配置、逐案例的结果记录、明确的改动决策。可以很小，但要能让没有参与调试的人复核为什么采用或拒绝一个版本。
上线条件也应该先约定。哪些业务行为必须满足？哪些波动可以接受？未知结果怎样处理？需要多少线上证据？这些条件随任务风险而变，不适合抄一个统一的 80 分。
后续指定案例与评分规则的维护人。新失败进入案例池，业务规则变化触发标准更新；更新评测后重新建立可比基线。EDD 的价值需要靠这种持续维护兑现。
下一次团队准备换模型或改提示词时，可以先把要改善的行为写成一条案例。跑出基线，再讨论改哪里。第一轮最有用的产出，是一份别人能复核、能影响开发选择的证据。
相关阅读
本文是「大厂 Evals 经验系列」的 EDD 专题入口。评测任务、评分器与可信分数的细节，可回读系列中的 Anthropic 精读与裁判质量解读；本专题后续分别讨论 Google、OpenAI、Microsoft、Databricks／MLflow、AWS 和美团的做法。
来源访问日期：2026-10-11。本文为原创综合科普，来源支持的观点在对应段落标注；示例、组织方式和项目建议由本文提出，不代表厂商实测。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。