评测驱动开发：把 eval 当 CI
软件工程有 TDD，AI 工程需要 EDD——评测驱动开发。写代码前先写评测集，让它定义"什么是好"，每次改动跑评测，下降即拦。本文讲清 EDD 的流程、它和 TDD 的区别（非确定、概率性）、怎么落地，以及它如何把"凭感觉调 AI"变成可工程化的迭代闭环。
本文要点
- 主题聚焦：AI、DevOps
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
传统软件有 TDD（测试驱动开发）：先写测试定义"对"，再写代码满足它。AI 工程需要对应的范式：EDD（Eval-Driven Development，评测驱动开发）——先写评测集定义"好"，再调 prompt/模型/系统满足它，每次改动跑评测。
原因很简单：AI 部件是非确定的、没法用 assert 精确测，没有评测集你根本不知道改好了还是改坏了。
一、为什么 AI 工程需要 EDD
传统代码：assert(add(1,2) === 3)——确定性，对就是对、错就是错。
AI 部件：同一个 prompt + 输入，每次输出可能不同；"好"没有二元对错，是质量分布。所以：
- 没法用传统单测 assert。
- 改了 prompt，肉眼觉得好了，实际可能整体退化（你看了几个变好的，没看那 30 个变差的）。
- 没有"好"的客观定义，团队争论"这个 prompt 行不行"全凭嗓门。
EDD 的核心：用评测集给"好"一个客观、可量化的定义，让每次改动有据可依。
二、EDD 的流程
1. 定义任务 + "好"的标准 → 建评测集
2. 写初始 prompt/系统 → 跑评测,得到 baseline 分数
3. 改动(prompt/模型/参数) → 跑评测 → 和 baseline 对比
4. 分数提升 → 接受,更新 baseline
分数下降 → 拒绝,回滚
5. 持续: 新发现的 bad case 进评测集,迭代
和 TDD 的"红-绿-重构"对应，EDD 是"定标-跑评-迭代"。评测集就是你的"测试套件"，分数就是"通过/失败"。
三、评测集：EDD 的地基
评测集的质量决定 EDD 的有效性。要点：
- 覆盖核心场景 + 边界。不只是"标准问题"，要有边界/模糊/对抗 case。
- 持续从真实流量补充。线上 bad case 是评测集最好的来源——脱敏后加入，防回归。
- 标注"期望"而非"标准答案"。AI 输出多变，标注关键事实/属性（"答案应含 X""格式要 JSON""不能含 Y"），而非逐字答案。
- 规模够用即可。50–200 条覆盖好，比 1000 条噪声强。
评测集要版本化进 Git，和代码同级——它是产品逻辑的一部分。
四、跑评测：自动化是关键
EDD 要求"每次改动跑评测"，所以必须自动化：
- 一个脚本/命令跑全量评测集 + 打分。
- 分数和 baseline 对比，输出报告（哪些指标变了、哪些 case 翻车）。
- 接进 CI：PR 改了 prompt/模型 → CI 跑评测 → 下降超阈值拦下来。
打分方式（之前评测相关文章详谈）：
- 规则打分（格式合法率、关键词命中）。
- LLM-as-judge（faithfulness、relevancy）。
- 人工抽检（关键 case）。
CI 里的样子：
# .github/workflows/eval.yml
on: pull_request (paths: prompts/**, models/**)
jobs:
eval:
- run: pnpm eval --baseline main
- if: metrics dropped > 3%, fail the PR
五、EDD 和 TDD 的关键区别
| TDD | EDD | |
|---|---|---|
| 被测对象 | 确定性代码 | 非确定 AI 部件 |
| 通过标准 | 精确相等/布尔 | 概率/分布/分数 |
| 一次运行 | 确定结果 | 有方差（可能要多次取均） |
| 失败定位 | 明确哪行错 | 看 bad case + trace |
| 维护 | 改代码改测试 | 改 prompt 补 bad case 到 eval |
最大的差别：EDD 的"通过"是概率性的、有方差的。所以：
- 跑评测要看分布/均值，不是单次。
- 指标小幅波动（±1%）是噪声，别过激反应。
- 设置"显著变化"阈值（如 ±3%），超了才算真变化。
六、EDD 落地的现实挑战
1. 评测集的冷启动。没有评测集，EDD 无从谈起。但建集要标注、要时间。对策：先小（20 条核心场景），边跑边补。
2. LLM-judge 的成本。用强模型当裁判跑评测集，要花 token。对策：CI 用便宜模型粗评、关键节点用强模型精评。
3. 指标和产品价值的对齐。"faithfulness 提升了 5%"，但留存没动——你的指标可能没抓住真实价值。要持续校准"评测指标"和"业务指标"的关联。
4. 团队习惯。EDD 要求团队接受"改 AI 必须跑评测"的纪律。文化建设，靠流程强制 + 数据说服。
七、EDD 的进阶：分层评测
成熟团队做分层评测：
- 冒烟评测（10–20 条，每次 PR 跑，秒级）：快速挡住明显退化。
- 核心评测（50–100 条，合并前跑，分钟级）：质量门槛。
- 全量评测（数百条，发版前跑，小时级）：全面验证。
- 在线评测（真实流量灰度，发版后）：线上真实分布。
按改动风险选跑哪层，平衡速度和覆盖。
八、EDD 的真正价值
EDD 不只是"测得严"，它改变了 AI 开发的工作方式：
- 改动有据。不再"我觉得好"，是"评测分数 +X%"。
- 敢改。有评测兜底，敢于做激进优化（换模型、重构 prompt），不怕悄悄退化。
- 团队协作。prompt/模型评审有客观依据，不靠嗓门。
- 知识沉淀。评测集本身是产品知识的沉淀（什么是对的、边界在哪）。
没有 EDD 的 AI 团队，迭代是玄学的；有 EDD 的，迭代是工程的。 这个差距在长期会被放大。
小结
评测驱动开发（EDD）是 AI 时代的 TDD：
- 评测集定义"好"，是 EDD 的地基（覆盖场景 + 边界 + 持续补 bad case）。
- 自动化评测进 CI，每次改动跑、下降即拦。
- 理解概率性：看分布不看单次、设显著阈值。
- 分层评测：冒烟/核心/全量/在线，按改动风险选。
记住一句：没有评测的 AI 开发，是闭眼开车；有评测的，是看着仪表盘开。 EDD 的投入（建集、接 CI）看着重，但它是 AI 产品从"凭感觉迭代"走向"工程化迭代"的分水岭——这件事一旦做起来，你的迭代速度和质量都会拉开那些还在"玄学调 prompt"的团队一个身位。
Related