第 22 章 · 什么叫做好了
老板先看这一句： 验收标准是保护你钱包的那把尺子——先定标准再动手,你才不会在项目尾声被「感觉还行」忽悠,更不会上线后才发现效果没人说得清。你要问团队一句:「这事做好了,用什么数字证明?谁定的线?」这四样不能省:典型、边界、失败、高风险样本,以及每条带验收线的指标——它们既是验收的凭证,也是往后每次改动 regression 的红线。
「感觉还行」的陷阱
一个做在线教育的团队,让 AI 给学生的作文打分和评语。做了一个月,每次演示都挺好——挑几篇一看,评语写得像模像样,大家点头,「感觉还行」。
上线两周,家长炸了:同一篇作文,今天 85 分明天 78 分;有个明显跑题的作文,AI 夸它「立意新颖」。团队慌了,回头想查「到底哪里退化了」,却发现没有基准——他们从头到尾没定义过「什么叫打对了」,只有一堆「感觉还行」的记忆。想修都不知道从哪修起。
这是 AI 交付最隐蔽的死法:没有标准,你永远活在「感觉」里。 感觉会骗人——挑着看的样本永远比整体好看,而且今天觉得行、明天标准就飘了。
治它的办法叫 EDD(Evaluation-Driven Development,评估驱动开发):核心就一句话——动手做之前,先定义清楚「什么叫做对」。 先有靶子,再开枪;先有尺子,再量长短。这一章讲怎么立这把尺子。
为什么要「先」定义
很多人把评估当成最后一步:做完了再测测看。EDD 反过来,把它提到最前面。为什么?
- 没有标准,调优就是瞎调。 你都不知道「对」长什么样,怎么判断改动是变好还是变坏?第 15 章那句「按样本调」,前提是先有样本。
- 没有标准,验收就是扯皮。 交付时业务方说「感觉不太准」,你说「挺准的呀」,谁也说服不了谁。数字才能一锤定音。
- 没有标准,回退无法察觉。 开头那个「今天 85 明天 78」,就是没有基准盯着、退化了都不知道。
所以顺序必须是:先立标准 → 再动手 → 每次改动都拿标准量一遍。 标准这把尺子,就是 Golden Dataset 加上一组验收指标。
Golden Dataset:四类样本,一类都不能少
Golden Dataset 是一组「标准答案已知」的样本,你拿它给智能体打分。它必须包含四类,缺一类都会在上线后爆雷(完整说明见附录 D):
| 类型 | 作用 | 缺了会怎样 |
|---|---|---|
| 典型样本 | 覆盖最常见的正常情况 | 连日常都没测,基本盘不稳 |
| 边界样本 | 临界、模糊、一条里裹两件事的 | 遇到复杂输入就露馅(如作文既有亮点又跑题) |
| 失败样本 | 已知会答错的,专门防退化 | 修好的问题过几周又退回来,没人发现 |
| 高风险样本 | 答错代价大的(合规、金额、对外) | 出一次事就可能被叫停 |
那个作文项目要是早备好这四类——典型:普通记叙文;边界:文笔好但跑题的;失败:上次夸错的那篇;高风险:涉及敏感内容的——「立意新颖」夸错跑题作文这种事,跑一次分就现原形了。
怎么攒?和业务方一起,从真实数据里挑。 别自己编,编的样本不接地气。第 12 章那个案例,就是 Agent 落地工程师和运营一起从真实评论里凑出第一版 Golden Dataset 的。
定验收指标和门禁
有了样本,还要定「达到多少算过」。从场景卡的价值假设里拆出 3–5 个可量化指标(指标库见附录 D),给每个定一条验收线,并说清判定方式。
| 指标 | 验收线(示例) | 怎么判定 |
|---|---|---|
| 打分一致性 | 同一篇多次打分误差 ≤ 3 分 | 规则打分 |
| 跑题识别准确率 | ≥ 90% | 精确匹配(对/错) |
| 高风险内容漏报率 | = 0 | 人工评审 |
| 评语采纳率 | 老师直接采用 ≥ 70% | 人工抽样 |
定完线,它就是双重身份:交付时是验收依据,交付后是回归门禁——以后每次改动都要用它跑一遍,分数不退才准上(呼应第 15 章的可演化)。
不要只做一包样本
真实项目里，Golden Dataset 最好拆成三份：
| 数据集 | 用途 | 注意 |
|---|---|---|
| 开发集 | Agent 落地工程师日常调 prompt、调规则 | 可以频繁看、频繁改 |
| 验收集 | 和 AIBP 对齐后用于 PoC 验收 | 不要天天拿来调，避免过拟合 |
| 回归门禁集 | 上线后每次改动前必跑 | 高风险样本必须稳定保留 |
如果所有样本都被拿来反复调，最后系统可能只是「背熟了测试题」，遇到真实业务仍然不稳。拆分样本，是为了让评估更接近真实。
指标也不能只看总分。比如总体准确率 90% 听起来很好，但如果高风险类别只有 60%，项目依然不能上线。建议至少按类别看：
| 类别 | 样本数 | 准确率 | 漏报率 | 判定 |
|---|---|---|---|---|
| 普通咨询 | 50 | 92% | 通过 | |
| 复杂边界 | 20 | 80% | 待优化 | |
| 高风险 | 8 | 100% | 0 | 必须通过 |
人工标注也要留痕。争议样本最好由两名业务专家各自判断，再对齐口径；如果两个人都说不清标准，问题就不是 AI 不准，而是业务规则本身还没定义清楚。
LLM-as-Judge 与人审的边界
样本一多,人工一条条判太慢,于是有了 LLM-as-Judge:让另一个模型来当裁判,自动判智能体答得好不好。它很省事,但有明确边界,Agent 落地工程师必须守住:
| 判定方式 | 适合 | 边界 |
|---|---|---|
| 精确匹配 / 规则打分 | 分类、抽取、格式 | 最可靠,能用就优先用 |
| LLM-as-Judge | 回答质量、语气、引用一致性 | 快但会错,高风险场景不能只靠它 |
| 人工评审 | 高风险、主观、争议样本 | 慢但权威,抽样即可 |
一条铁律:高风险样本,必须保留人工复核,不能全交给 LLM-as-Judge。 让一个会出错的模型去判另一个会出错的模型,在高风险场景等于风险叠加。LLM-as-Judge 用来跑大批量的日常回归,人审用来守住那几条要命的样本——分工清楚,才既快又稳。
📎 技术深读:评测脚本怎么写、LLM-as-Judge 与自动化回归的工程实现,见 Harness Agent Book · 附录 D。本章给 Agent 落地工程师视角的样本设计与验收标准。
📍 场景示例：老陈只写了「ACOS<30%」，两个 Listing 被下架后才补验收线
老陈给广告 Agent 定的验收线只写了一句「ACOS 降到 30% 以下」(月广告费约 $30k),没列边界和失败样本。一个月后素材迭代上来,ACOS 看着达标,却因合规词(CE/FCC/各平台禁售词)漏判,两个 Listing 被平台下架——验收线根本没覆盖这类高风险样本。FDE 返工两周,补上四类样本才重新过线。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 验收线 | 只写「ACOS<30%」 | 3–5 指标 + 四类样本 |
| 高风险覆盖 | 漏判合规词,2 个 Listing 下架 | 高风险样本零漏报 |
| 返工 | 上线后返工 2 周 | 上线前一次过 |
老板决策点： 立项时你要问「做好了用什么数字证明、谁定的线」——高风险类样本缺一条,都不能放行预算。 ——对应 → L3
常见坑
- 靠「感觉还行」验收。 挑好看的样本演示,上线才现原形。
- 样本缺类。 只测典型、不测边界和高风险,复杂输入和要命场景全裸奔。
- 不留失败样本。 修好的 bug 过几周又退回来,无人察觉。
- 高风险也交给 LLM-as-Judge。 用会错的裁判判会错的选手,风险叠加。
- 定完标准就锁死。 Golden Dataset 要随新发现的失败样本持续长大,不是一次性产物。
本章产出
老板行动点： 在立项评审时,要求团队交付一份带验收线的「评估标准」再开工;没有标准就别放行预算——这是你避免「钱花了、效果说不清」的最低门槛。
往交付包里放一份「Golden Dataset + 验收指标表」:
用 附录 D 的模板,为你的场景凑齐四类样本(典型/边界/失败/高风险,和业务方一起从真实数据挑),定出 3–5 个带验收线的指标,并标明每个指标用精确匹配 / LLM-as-Judge / 人审哪种判定。这套东西,既是你验收时的凭证,也是往后每次改动的回归门禁。
成熟度自检
- [ ] 我能在动手前,和业务方一起备齐四类样本、定出带验收线的指标(→ L3)
- [ ] 我能守住 LLM-as-Judge 与人审的边界,让评估集持续回归、持续长大(→ 迈向 L4)