上一章结尾预告了：当公司想把「找异常」自动化，会遭遇另一种噪声灾难。这一章讲的就是这个——也是所有做过监控系统的人都深有体会、却很少被讲透的一件事：告警系统 itself 会变成噪声发生器。
例外报告：把前五章写成规则
想法很自然：审计师那套「捞异常」的手艺，能不能写成程序天天跑？于是有了例外报告——系统按预设规则自动扫描业务数据，把「不合规」的记录标红推给人看。超过审批线的标红、周末过账的标红、供应商主数据缺失的标红、同一卡号一天刷五次的标红。内审部门不用等项目启动，每天早上就有一批「嫌疑人」躺在收件箱里。
某集团上了这么一套系统，配了 47 条规则，上线第一天，例外报告里有多少条红色警报？三千二百条。负责处理的合规专员只有两个人。三个月后，这套系统的真实状态是：三千多条警报里，两人每天能看大约四十条，其余的靠「看标题觉得不重要就批量关闭」。又过三个月，批量关闭变成了肌肉记忆——90% 的警报活不过五秒钟。
行业里给这个病起了名字：告警疲劳。大白话讲：警报太多，人就麻了；人麻了，系统就废了。这套系统不是没有发现真问题——是发现得太多，多到把真的也埋了。
误报率：噪声的再生父母
问题出在哪？出在每一条规则单独的误报率都不高，但叠起来是灾难。
算一笔账。假设一条规则抓「周末过账」：全公司每月五万笔过账，周末过账占 3%（月底结账、系统自动任务都会落在周末），就是 1500 条标红，其中真有问题的大概千分之一——一两条。这条规则的误报率超过 99%。再假设每条规则每月贡献几百上千条误报，47 条规则叠在一起，就是每天收件箱里那三千条。
这里有个统计学的冷知识，值得单独说：当「真问题」在总体里极其稀少时，哪怕检测手段很准，报警的大多数也是误报。医学上这叫基础概率的陷阱：一种发病率千分之一的病，用准确率 99% 的筛查验血，查出阳性的人里，十个有九个是假阳性。例外报告面对的正是这个数学：真舞弊在交易里的浓度可能只有万分之一，而任何规则的「准确率」都到不了 99.99%——分母里正常交易太多了，每个正常交易都有一点点概率踩线，聚起来就是红色的海洋。
告警系统的设计本质是在两种错误之间做交易：漏报（真问题没报警）和误报（好交易被冤枉）。规则越灵敏，漏报越少但误报爆炸；规则越迟钝，误报少了但真问题会漏。不存在「又灵敏又准」的免费午餐——你能选的只是天平往哪边歪，以及花多少人力去消化误报。
怎么治：从加规则到调系统
面对红色海洋，第一反应往往是「再加几条规则，把误报的特征也排除掉」——结果规则越加越多，误报越排越杂，系统越调越没人敢动。成熟的做法是把例外报告当一个需要运营的产品，而不是一个装完就忘的灭火器：
第一，给每条规则算绩效。定期统计每条规则的「命中率」：它报的警里有多少最终被确认是真问题。命中率长期低于 5% 的规则，要么改条件，要么下线。规则和人一样，要有 KPI，要有淘汰。47 条规则的系统，健康的状态通常是十几条核心规则贡献 90% 的真发现。
第二，分层报警，不一锅端。同样是踩线，「金额超线 100 倍 + 新供应商 + 周末」和「金额超线 5%」不该是同一个红度。多条弱信号叠加成一条强信号，让最可疑的 1% 浮到最上面——这其实就是第五章贴线三板斧的思路自动化：单条规则捞的是浓度千分之一的候选，规则叠加把浓度提到十分之一，人的注意力只花在最浓的那层。
第三，阈值跟着基线走。第三章的基线思维在这里复用：固定阈值（「超过 5 万报警」）会在业务增长后变成误报之源——公司做大了，5 万的单子天天有。动态阈值（「超过该部门过去半年均值的 3 倍标准差报警」）让规则随业务的体温自动调节，把「正常长大」这种噪声挡在门外。
第四，闭环反馈。每条警报的处理结果（确认问题/误报/无法判断）必须回流，用来修正规则。没有反馈回路的告警系统是死的——它永远在犯同样的错误，而人在替它付学费。
告警疲劳的深层教训
退后一步看，例外报告的困境是全书主题的一面镜子。检测从不缺灵敏度，缺的是信噪比。找信号的难点从来不是「把可疑的都标出来」——这太容易了，一条 SQL 就能标三千条——而是「标出来的东西里，真的占多大比例」。审计师的手艺、抽样的数学、访谈的三角验证，归根到底都在做同一件事：提高你面前那堆候选里信号的浓度。
所以评价任何检测系统（无论人工还是自动），只看一个指标：推给人看的东西里，多大概率是真的。这个指标不好，灵敏度再高都是负资产——因为它在系统性地训练使用者忽略警报。
一句话总结
例外报告把找异常自动化了，但低基础概率 + 规则叠加 = 红色海洋，警报反而成了噪声；解法是当产品运营：给规则算命中率、分层叠加、阈值跟基线走、结果闭环反馈。到这儿，工具层讲完了。但工具有个前提：公司的内控本身是好的。如果控制本身就是坏的——下一章，看看裂缝是怎么产生的。