评测集放在仓库里，不如接进流水线
评测集建好之后最大的风险是没人跑：改动上线了，指标退化了，几天后才发现。
把它接进 CI（持续集成）意味着：每次改动自动跑一遍，退化当场拦下。
三条流水线
- 快速冒烟（每次提交，1~2 分钟）：抽 20~30 条样本，看有没有崩溃级退化（格式错、拒绝回答、超时）；
- 完整评测（合并主干，5~15 分钟）：跑完整评测集（100~300 条），比较正确率与失败类型分布；
- 夜间回归（每天）：加跑成本/延迟统计与更贵的评估（人工抽检或强模型打分）。
判定规则要写死在配置里
- 主指标允许的波动范围（例如正确率下降不超过 2 个百分点）；
- 失败类型的硬约束（例如"编造事实"类不得增加）；
- 成本与延迟的上限（防止为了指标把成本翻倍）。
超限时阻断合并，而不是只在评论里提示——人的注意力会被别的事吸走。
三个工程细节
- 缓存与并发：同样的样本结果可复用，别每次都真调模型；并发跑，但限速避免打爆配额；
- 基线要固定：与"上一次主干"比，而不是与某个历史最好成绩比；
- 失败也要留档：把失败样本与原始输出存下来（脱敏后），这是最有价值的素材。
常见坑
- 评测集与提示词在同一仓库但版本不一致（改了提示词却没重跑基线）；
- 只在发布前跑：等于把发现问题的时机推到最后一刻；
- 评测环境与线上不一致（不同模型版本、不同参数）→ 结论不可迁移；
- 把评测做成"打分游戏"：只盯总分，忽略失败类型的变化（平均不变但极差回答变多，是恶化）。
落地顺序
- 先把冒烟跑起来（20 条、1 分钟、阻断合并）；
- 再加完整评测与基线对比；
- 最后加夜间回归与成本看板；
- 每次改动都在 PR 描述里附本次的评测结论（含没变好的地方）。