《评测驱动开发（EDD）》系列写到第 14 篇，收官。前 13 篇沿着"要不要评 → 数据集 → 评估器 → 粒度 → 工具 → 门禁 → 线上 → 人工 → 红队"一路推进，每篇解决一个专门问题；但真要动手时，没人会按系列顺序重读 13 篇——你面对的永远是一个具体处境：新项目从哪起步、judge 分数不对劲翻哪篇、团队四周冲刺怎么排。参照《上下文工程》第 18 篇的手册化收官，本篇不再引入新知识，把 13 篇浓缩成一套可随身查阅的落地手册。
手册五件套：一条主线回顾、一张症状处方速查表、一份四周落地路线图、一张 14 篇知识地图，外加评测文化的组织落地与三件立刻可做的事。可以通读一遍，更建议把速查表与知识地图收进书签，出事时按图索骥。本文按"主线 → 速查 → 路线图 → 地图 → 版图 → 组织 → 行动 → 总结"组织全文。
1、系列主线回顾
先回答总问题：这 13 篇到底在讲什么？一句话——把"感觉更好"换成"分数更好"，并让分数贯穿离线与线上全生命周期。第 1 篇立下总纲：评测集就是规格说明书，先定义"好"再写应用，这套做法在 Braintrust 的 EDD 原文里叫 eval-as-oracle。其余 12 篇是一条环环相扣的链，全貌如下：
这张图的读法自上而下，也是依赖顺序：每个环节吃上一个环节的产出。没有数据集，评估器无从校准；没有评估器，CI 无物可挡；没有离线基线，线上监控就失去"上线前已知好"的参照。反过来，跳步是最常见的返工原因——先买工具再想清楚要不要评（第 2 篇的四个信号没对过一遍）、judge 先上线而金标还没标（第 6 篇的 kappa 无从算起），都会在几周后推倒重来。
链条末端两环各有闭环属性：人工不是自动化之前的过渡形态，而是全体系的地基——judge 的 kappa、金标集、线上抽检全部压在人的判断上（第 12 篇）；红队是安全口，把对抗样本变成发版流水线的常客，而不是事故后的补丁（第 13 篇）。
2、症状处方速查表
第一个随身工具解决"出了状况翻哪篇"。以症状为索引、处方为行，出处一列就是该翻的那篇：
| 症状 | 首选处方 | 出处 |
|---|---|---|
| 想改提示词没底气，改好一处怕坏别处 | 建 5～10 条冒烟集，改动前后各跑一遍 | 第 2 篇 |
| 用例涨过 30 条，肉眼判不过来 | 断言接管确定性维度，肉眼退到模糊地带 | 第 4 篇 |
| 冒烟集只守已知火点，测不出盲区 | 真实流量采样扩黄金集，分层覆盖 | 第 3 篇 |
| judge 分数忽高忽低，不知该不该信 | 跑换序、注水、跨厂三个自查实验 | 第 6 篇 |
| judge 通过率报表没人敢签字 | 人工标 50 条金标算 kappa，0.6 是可用线 | 第 6 篇 |
| Agent 结果对，工具链路经常绕路 | 轨迹评估，把调用序列当评测对象 | 第 7 篇 |
| 端到端分数降了，定位不到组件 | 组件级拆开测，按金字塔分层归因 | 第 8 篇 |
| 工具选型摇摆，LangSmith 还是 promptfoo | 先列需求五件套，再查决策矩阵 | 第 9 篇 |
| CI 无故飘红，本地复跑又绿 | 抖动三件套：重跑、容忍带、取中位数 | 第 10 篇 |
| 离线指标全绿，线上用户在骂 | 采样审计加漂移检测，坏例回流评测集 | 第 11 篇 |
| 用户点踩误报多，backlog 堆伪需求 | 置信度清洗加人工确认卡点 | 第 12 篇 |
| 提示词被注入，越狱输出失控 | 红队对抗样本进发版流水线 | 第 13 篇 |
用表两条纪律。其一，处方按出处叠加而非单选：数据集、断言、judge 本就是组合拳，多数症状的完整解横跨两三篇。其二，改完必须回评测关单——凭体感放行的改动，会在两周后以更隐蔽的方式复发，这是 13 篇里重复次数最多的一条教训。
3、四周落地路线图
速查表治已病，路线图防未病。给"决定把评测体系一次搭起来"的团队一份四周计划：每周对应第 2 篇成熟度阶梯的一级，周末以产出物验收，且产出物要变成下一周的日常。
| 周 | 目标 | 关键动作 | 周末产出物 |
|---|---|---|---|
| 第 1 周 | L1 冒烟集与首条断言 | 固化 5～10 条真实用例；写 20 行跑批脚本；高频维度接断言 | smoke.yaml、跑批脚本、基线通过率 |
| 第 2 周 | L2 黄金集与 judge | 用例扩到 30～50 条并分层；写 rubric 与 judge 提示词；标 50 条金标 | 黄金集 v1、judge 套件、kappa 报告 |
| 第 3 周 | L3 CI 门禁 | 评测改写 pytest 参数化用例；配两级流水线与阈值表 | workflow 配置、阈值表、红灯处置文档 |
| 第 4 周 | L4 监控与红队起步 | 采样审计与漂移报表；反馈入口埋点；攒首批对抗样本 | 周报脚本、漂移指标、10 条对抗用例 |
四周是冲刺节奏，不是军令状。第 2 篇的结论仍然成立：多数项目停在 L1～L2 性价比最高，两三人维护的系统把第 4 周推迟到流量上来之后再做，完全健康。路线图的关键不在快，而在每周的产出物都要活下来——第 1 周的脚本要跑进此后的每次提示词修改，第 3 周的门禁要真的拦过一次合并。每周末问一句"这个产出物下周还会被谁用"，答不上来，说明在赶进度而不是建体系。
4、十四篇知识地图
第二个随身工具是全系列索引：每篇一行，第三列写"何时回头查"。用法不是通读，是定位。
| 篇 | 主题 | 何时回头查 |
|---|---|---|
| 1 | EDD 全景与八步闭环 | 给团队定调、讲清 eval-as-oracle 时 |
| 2 | 要不要评与冒烟起步 | 第一次想上评测、L0 升 L1 时 |
| 3 | 数据集工程 | 冒烟集撞天花板、黄金集扩容时 |
| 4 | 确定性断言 | judge 太贵太抖、想先省后稳时 |
| 5 | judge 搭建 | 第一次写 rubric 与 judge 提示词时 |
| 6 | judge 校准与偏差治理 | 分数可疑、kappa 验收不达标时 |
| 7 | 轨迹评估 | Agent 工具链路失控时 |
| 8 | 端到端与组件级 | 归因不清、搭评测金字塔时 |
| 9 | 工具选型 | 采用与自研之间摇摆时 |
| 10 | 评测进 CI | 定阈值、治抖动、红灯分诊时 |
| 11 | 线上监控 | 上线后漂移告警、A/B 判断时 |
| 12 | 人工反馈闭环 | 点踩治理、金标与标注运营时 |
| 13 | 红队与安全 | 接外部输入、防注入越狱时 |
| 14 | 本篇路线图 | 不知道从哪开始、翻哪篇时 |
5、三系列知识版图
收官时把三个系列放回一张图。本站的 Agent 工程知识体系至此 62 篇：30 篇搭骨架，18 篇供血液，14 篇验健康。
| 系列 | 篇数 | 角色 | 核心问题 |
|---|---|---|---|
| AI Agent 开发 | 30 | 搭骨架 | 系统能不能干起来：规划、工具、RAG、记忆、多 Agent、部署 |
| 上下文工程 | 18 | 供血液 | 每一步喂给模型什么：窗口账、压缩、注入、缓存、安全 |
| 评测驱动开发 | 14 | 验健康 | 到底干得好不好：数据集、评估器、门禁、监控、红队 |
三系列的咬合点在原文里都留了接口：上下文工程第 15 篇把"上下文质量"变成可评测对象，正是本系列的交接点；Agent 系列第 27 篇的 LangSmith 实战是工具前站；本系列第 1 篇的 eval-as-oracle 则把前两个系列的一切产出统一纳管进评测循环。
合起来的判断是：骨架决定能力上限，血液决定稳定下限，评测决定你敢不敢说"它现在没问题"。前两个系列的任何改动——换了压缩策略、调了提示词、升了模型版本——只有经过 EDD 的门禁与监控，才有资格宣称"变好了"。这也是为什么评测是第三根支柱，而不是锦上添花的可选件。
6、评测文化的组织落地
工具链是机器的部分，评测体系能不能活下来，取决于组织习惯。两件事最关键：小团队从哪起步，以及变更评审的纪律。
**小团队的起步姿势。**1～3 人的团队不必按大厂分工幻想"标注组加评测组"：先花两小时把 L1 冒烟集跑起来，断言能接的维度全部交给断言（第 4 篇）。要上 judge 之前，金标标注找一位同事交换交叉标——既写提示词又当金标裁判的人，确认偏误会把坏输出标成好输出，judge 对着这份金标校准，等于把偏差焊死。日常运营用轮值：每人每周固定半天看失败 case 与新点踩，比专职标注扛得住倦怠（第 12 篇）。
**变更评审的纪律。**提示词也是代码，改提示词的 PR 就该像改代码一样带测试结果：评测报告当附件，无报告不评审。报告只需要两样——改动前后的通过率对比，以及新增失败 case 清单；评审人看两件事：分数动了多少、失败的是哪几条。把这条写进贡献文档，它就与"红灯 PR 不许合并"（第 10 篇）同级的默认纪律。Hamel Husain 的评估长文有同样的观察：没有评测护栏的提示词评审，最终都退化为比谁嗓门大。
评测文化落地的标志，不是工具链凑齐，而是再也没人问"能不能先合了再说"。
7、三件立刻可做的事
手册的最后是行动清单。三件事按顺序做，每件半天以内，分别对应第 2、4、6 篇。
**第一件：写 5 条冒烟集，两小时。**从线上日志或测试对话里挑 5 条最常翻车的真实问法，固化成 YAML：
# evals/smoke.yaml —— 最小冒烟集：每次改提示词后全量跑
- id: order-status-001
input: 我的订单 38291 到哪了
context: user_id=u1024；订单=已发货；承运=顺丰
expect: 含运单号与预计送达日，不编造物流节点
- id: refund-002
input: 买完九天了还能退吗
context: 订单收货 9 天，政策是 7 天无理由
expect: 明确告知超期，给人工客服入口
验收标准：改一处提示词，前后各跑一遍，两分钟内能回答"变好还是变坏"。做到这一步，项目就离开了 L0 手工点测。
**第二件：给一条断言，一小时。**挑最常出问题的确定性维度——必须包含的字段、禁止出现的措辞、JSON 结构校验——从第 4 篇的断言家族里选一种，写成 pytest 参数化用例。验收标准：下次提示词改动被它拦下一次，或干净放行一次，都算数；DeepEval 与 promptfoo 都能让这一条用例直接跑进 CI。
**第三件：算一次 kappa，半天。**人工标 20 条金标，judge 跑同一批，用第 6 篇的脚本算 Cohen's kappa。判读线：低于 0.4 不可用，0.6 可用于低风险决策，0.8 以上才算可靠的自动评分。这一步的意义在于，你第一次知道自己那把尺子准不准——多数团队第一次算都低于预期，而低于预期本身就是收获：它告诉你要先修 rubric 还是先换 judge 模型。
8、总结
14 篇收束成一条链：评测当规格（第 1 篇），先想清楚要不要评（第 2 篇）；数据集定上限（第 3 篇）；断言打底、judge 校准后上岗、轨迹管过程（第 4～7 篇）；粒度分层好归因（第 8 篇）；工具减摩擦（第 9 篇）；CI 当刹车（第 10 篇）；线上当哨兵（第 11 篇）；人工是拆不掉的地基（第 12 篇）；红队守住安全口（第 13 篇）。概率世界里没有 100% 绿，只有"分数不劣化"——这是全系列唯一需要背诵的定理。
本系列之后，博客的下一个系列是《本地大模型部署实战》16 篇：从"判好坏"走向"模型自持"，推理引擎、量化与显存账都在那边的射程里。更远处，Mastra（TypeScript 优先的 Agent 框架，内置 workflows 与 evals）、多模态应用、后训练三个主题已经排队。对于跟着走完全程的读者，建议今天就把第 7 节的第一件事做掉——冒烟集第五个条目写完的那一刻，你的项目就正式进入了评测驱动。
