评测集构建：怎么证明你的规则没有改坏？

上一篇立了 flag，这篇还上：规则做成了可编译的本体之后，怎么证明每次修改没有把原来对的东西改坏？我的答案是评测集——一组带预期结果的测试单据，每次规则变更前全量跑一遍，全部通过才允许发布。听起来就是软件测试的常识，但把它用在业务规则上，有些细节值得记下来。

三类 case：正例、反例、边界

评测集里的每个 case 是一笔构造出来的单据加一个预期判定。我按三类去配比：

• 正例：完全合规的单据，预期通过。作用是防止规则改严之后"错杀"——这是最容易被忽略的一类，因为出错时没人报警，只有业务方默默受苦；
• 反例：明确违规的单据，预期拦截，而且要拦在正确的规则上。我会校验命中的 rule_id，而不只是"被拦了就行"，因为拦错规则意味着给出的整改指引是错的；
• 边界 case：卡在阈值上的、日期恰好等于时限的、关键字段缺失的。规则的 bug 几乎都藏在这里——等号往哪边算、缺失算不算违规，都要有 case 钉死。

确定性是前提

评测要可信，判定必须确定：同样输入永远给同样输出。这意味着两件事。一是判定路径里不能有大模型——抽取、转写可以用模型，但判定本身必须是确定性引擎，否则今天全绿明天飘红，评测就成了玄学；二是所有随时间变化的量要参数化冻结，比如"审核日期"在评测里是一个固定参数，否则超期类规则的边界 case 今天过、明天挂，评测集自己先不可信了。

评测集怎么长出来

初版评测集是我对着规则清单手工构造的，每条规则至少配一正一反。之后它主要靠两个来源生长：一是线上转人工的真实单据，人工给出结论后，脱敏简化成新 case 补进来；二是每次修 bug，先写一个能复现这个 bug 的 case，再去改规则——和测试驱动开发是一个思路。

评测集是规则系统的另一半：本体说"规则是什么"，评测集说"规则应该表现成什么样"。少了任何一半都不完整。

门禁：不可绕过

最后是流程约束：评测通过率必须 100% 才能发布，这个门禁做在发布动作里，不靠自觉。有人觉得苛刻——"就改了一个阈值，跑什么全量"。但我的经验恰恰相反：越是"只改了一点点"的变更越危险，因为没人会为它认真回归。全量评测几秒钟就跑完，这点成本换来的是敢改规则的底气。规则系统最怕的不是有 bug，而是没人敢动。