回归 CI——只卡回归，不设绝对门槛
主流对 prompt 程序的发布纪律，可以归结为一条流水线：任何触及 prompt、工具定义或 agent 配置的 PR，都会在 CI 中触发一次完整的 golden-set 运行（预算约 30 分钟）；结果与当前基线做差异对比；出现显著下降就阻断合并。这个设计靠两条原则撑住：
- 先有基线，才有门槛。 对 LLM 输出而言，绝对质量阈值毫无意义（分数会随裁判模型版本、案例组合、措辞而漂移）——所以永远不要先定一个"及格分"。而是让当前生产系统先在这个集合上打分，然后只卡方向：这次改动有没有把原本能通过的东西变差？Promptfoo 的核心产物正是这个东西：一张"案例 × prompt 版本"矩阵，把翻转的格子高亮出来。
- 沉默的漂移才是真正的敌人。 Prompt 之间的相互作用是非局部的——为了改善某个行为而调的一句措辞，可能悄悄拖垮另一个行为；供应商不声不响地更新底层模型，也会让全局一起偏移。没有 CI 评测，这类回归要等到几周后用户抱怨才会浮出水面。"三十分钟的 CI 评测跑一次，和祈祷之间的差别，就是这个。"
机制上：nondeterminism-statistics 在这里适用（多次运行取 n、判定翻转前先过显著性阈值）；失败的运行会直接链接到那些翻转案例的 trace；基线只有在一次改动被接受之后才会前移。
与 um 的关系：这是 um 目前最大的缺口。 um 会把每一份 ARTIFACT 审得很彻底，却完全不审 MACHINE CHANGES——一次 skill 编辑不会重跑任何东西，于是一条被磨锐的规则完全可能悄悄破坏掉原本能通过的东西（有一次小规模地发生过：RF6 第一次磨锐时把 imagery 层整个删掉了——是 owner 发现的，不是任何 harness 发现的）。修法在父笔记和 HANDOFF 里已经写明了：已提交的 ledger 本身就是不断累积的 golden set；一次 machine change 会触发对一个抽样切片的重新审计；出现回归就阻断。um 在这一点上比主流多出一样东西：内容寻址意味着每个 golden case 都绑定在精确的字节上——不存在"当初测的到底是什么"这种预期过期的模糊性。
来源：evals 主流实践（Promptfoo 差异矩阵、CI-eval 惯例，2026-07 现状核查）