评测驱动开发：让 AI 功能不再靠"感觉还不错"上线

传统测试对 AI 不够用

写传统软件，你可以断言 2+2==4。但 AI 功能的输出是”一段话""一个判断”，没有唯一正确答案。于是很多团队干脆不测，全凭上线后用户反馈——这就是静默退化的温床。

模型升级、提示词微调、检索策略改动，任何一处调整都可能悄悄拉低质量，而你在投诉爆发前毫无察觉。

解法是评测驱动开发（Eval-Driven Development）：先定评测集，再改功能。

第一步：建一份会成长的评测集

评测集不是一次性任务，而是持续积累的资产。三类来源：

1. 真实线上案例：从生产日志里抽取有代表性的请求。
2. 边界与故障案例：每次线上出问题，把案例补进评测集，永不复发。
3. 合成对抗案例：故意构造刁钻输入（空输入、超长、矛盾要求）。

规模上，起步 50–100 条足够跑通闭环；质量比数量重要，覆盖要广、标注要准。

第二步：选对指标——不要只测”好不好”

AI 输出的评测分四类，按成本递增：

规则类：格式是否合法、是否包含必需字段、长度是否合规。便宜、确定性高，最先做。

参考类：有标准答案时，比对相似度（编辑距离、语义相似）。

模型裁判：用更强的模型给输出打分。便宜但有偏差，需要给人写的评分标准约束它，并定期用人工抽检校准。

人工评测：最准但最贵。只用于关键场景和小样本校准。

实践原则：能用规则就别用模型，能用模型就别用人。

第三步：把评测塞进 CI

评测不跑在流程里，就一定会被跳过。做法：

• 每次改提示词、检索参数、模型版本 → 自动触发评测
• 设定质量门禁：核心指标跌破阈值就阻止合并
• 记录每次评测结果，形成质量趋势曲线

这样你才能看到”这次改动让准确率从 87% 掉到 81%“这种肉眼看不见的退化。

第四步：区分离线与线上

• 离线评测：固定数据集，快、可复现，用于开发阶段拦截回归。
• 线上评测：A/B 实验、用户反馈、隐式信号（采纳率、重试率），用于验证真实价值。

两者缺一不可：离线的分数涨了，线上不一定涨；线上涨了，也不知道是哪个改动带来的。离线控质量，线上证价值。

三个常见的坑

坑一：评测集和训练数据泄漏 如果你的提示词是照着评测集调的，分数虚高。要留一份从未看过的测试集做最终验收。

坑二：只看平均分 平均分掩盖长尾。真正让用户流失的是那 5% 的灾难性失败。要看分位数和失败分布。

坑三：模型裁判不校准 模型裁判会偏爱长回答、偏爱和自己风格接近的输出。必须用人工标注的小样本定期校准它的打分。

一个最小可用的起步方案

1. 今天：从线上抽 50 条真实请求，人工标注”好/坏”。
2. 本周：写 5 条规则校验（格式、必填字段、长度）。
3. 下周：接入模型裁判，写一份 10 行的评分标准。
4. 本月：把评测跑进 CI，设一条质量门禁。

这套跑起来，你就从”感觉还不错”进入了可度量的阶段。

小结

评测驱动开发的本质，是把主观判断变成可复现的证据。四步走：建集、选指标、进 CI、分离离线与线上。起点不需要完美，关键是让评测成为日常动作，而不是上线前的突击。

能持续度量的团队，才有资格持续迭代。