把评测集接进流水线：让退化在合并前就被拦下

评测集建好后最怕没人在跑。本文给出三条流水线（冒烟/完整/夜间）、写进配置的判定规则、三个工程细节与四个常见坑，让指标退化在合并前被拦下。

评测集放在仓库里，不如接进流水线

评测集建好之后最大的风险是**没人跑**：改动上线了，指标退化了，几天后才发现。

把它接进 CI（持续集成）意味着：**每次改动自动跑一遍，退化当场拦下**。

1. **快速冒烟（每次提交，1~2 分钟）**：抽 20~30 条样本，看有没有**崩溃级**退化（格式错、拒绝回答、超时）；

2. **完整评测（合并主干，5~15 分钟）**：跑完整评测集（100~300 条），比较正确率与失败类型分布；

3. **夜间回归（每天）**：加跑成本/延迟统计与更贵的评估（人工抽检或强模型打分）。

主指标**允许的波动范围**（例如正确率下降不超过 2 个百分点）；

**失败类型**的硬约束（例如"编造事实"类不得增加）；

成本与延迟的上限（防止为了指标把成本翻倍）。

超限时**阻断合并**，而不是只在评论里提示——人的注意力会被别的事吸走。

**缓存与并发**：同样的样本结果可复用，别每次都真调模型；并发跑，但**限速**避免打爆配额；

**基线要固定**：与"上一次主干"比，而不是与某个历史最好成绩比；

**失败也要留档**：把失败样本与原始输出存下来（脱敏后），这是最有价值的素材。

评测集与提示词**在同一仓库但版本不一致**（改了提示词却没重跑基线）；

**只在发布前跑**：等于把发现问题的时机推到最后一刻；

**评测环境与线上不一致**（不同模型版本、不同参数）→ 结论不可迁移；

**把评测做成"打分游戏"**：只盯总分，忽略失败类型的变化（平均不变但极差回答变多，是恶化）。

1. 先把冒烟跑起来（20 条、1 分钟、阻断合并）；

2. 再加完整评测与基线对比；

3. 最后加夜间回归与成本看板；

4. 每次改动都在 PR 描述里附**本次的评测结论**（含没变好的地方）。