例外比规则更重要：业务判断中的“灰色地带”处理

做规则引擎的人有个职业病：总想用更多规则覆盖更多情况。这半年在财务审核场景里摸爬滚打，我的结论恰恰相反——决定一套判断机制能不能落地的，不是规则写得多漂亮，而是例外处理得好不好。

从一次误判说起

有一笔单据，发票号缺失。按当时的规则，“发票号与台账不一致则拒绝”，缺失被当成了不一致，直接判拒。业务方看到结果哭笑不得：这笔单据只是扫描件还没上传，人工审核时会补看纸质件，从来不会因此拒付。

这次误判暴露的不是某条规则写错了，而是整个机制缺了一层：缺失不等于不符。

三值逻辑：给“不知道”留位置

传统布尔判断只有真和假。但真实业务里大量字段是“暂时没有”：单据没传全、系统没同步、格式不对没抽出来。把这些统统折算成真或假，都是在替业务撒谎。

我后来把引擎改成三值语义：真、假、未知。任何规则引用了缺失字段，结果就是未知；未知不放行也不拒绝，而是转人工。这一个改动消掉的误判，比之后新增的十几条规则加起来还多。

机器最大的美德不是什么都能判，而是知道自己什么时候不该判。

规则加例外的双层结构

另一个发现是，例外不该混进规则里写。早期我把“金额超限拒绝，但某类紧急采购除外”写成一条带嵌套条件的规则，很快就维护不动了——每加一个“除外”，规则就复杂一分，而且谁批准的这个例外、什么时候过期，全都说不清。

后来拆成两层：规则层只写普遍标准，例外层单独建模，每条例外必须带三样东西：

• 适用范围：哪个部门、哪类单据、什么金额区间；
• 依据：谁批准的、对应哪份文件；
• 有效期：到期自动失效，想续必须重新审批。

判定时先匹配例外，命中则按例外走，并在结果里显式标注“因例外某条放行”。这样复核的人一眼能看到：这笔单据是被例外救的，不是规则漏了。

灰色地带的价值

我现在把“转人工”的比例当作一个健康度指标。转人工太多，说明规则覆盖不足；等于零反而更可疑——大概率是把不该自动判的也判了。灰色地带不是系统的失败，而是系统对自己边界的诚实。

老会计有句话我记在了笔记本扉页：“制度管八成，剩下两成靠判断。”我做的事不是消灭那两成，而是让八成走得又快又稳，让两成清清楚楚地摆到该判断的人面前。