泛滥导致关键报警被淹没
别名: 关键报警淹没 · alarm masking
概念解释
关键报警被淹没指的是报警潮期间的信号遮蔽（alarm masking）：某条报警本身已经触发、后果严重或响应窗口很短，却因为排在列表靠后、声音被其他报警覆盖、画面被占满或操作员认知负荷过高，而没有在需要的时间窗口内得到处理。它和报警没有触发是两回事——系统里确实存在这条记录，问题出在“存在”没能转化成“被处理”。
机制
多条报警共享同一批呈现通道——同一块屏幕、同一个声音提示、同一份注意力和工作记忆容量——时，注意捕获和工作记忆就成了瓶颈：人在同一时刻能够主动追踪的报警数量有限，报警潮期间新增的每一条都在和已经占用注意力的那些争夺同一份资源。反复出现的低价值报警还会推动操作员养成批量确认的习惯，确认动作变成清空列表的手势，而不是逐条判断。
报警潮还会带来一层更隐蔽的机制：频繁出现的骚扰性报警（nuisance alarm）不只是增加了列表长度，还会系统性地改变操作员对“这条报警值不值得认真对待”的判断标准——这可以用信号检测的框架理解，反复的低价值信号会把操作员的响应门槛整体抬高，关键报警要跨过的不再是原来那个门槛，而是被抬高之后的门槛，仅仅让它在颜色或列表位置上更醒目并不足以抵消这层门槛的抬升。如果优先级设计只体现在颜色而不体现在队列位置、声音区分和是否升级上，关键报警依然可能在物理上可见却在实际操作中不可达。
怎么研究
评估报警呈现设计能不能防止关键项被淹没，常用的实验范式是在报警潮里嵌入一条关键报警作为目标信号，让被试在处理背景报警的同时完成对这条目标的检测与响应，用信号检测的指标衡量结果：命中率、虚报率、辨别力（d′）以及对目标的反应时间，用来比较不同优先级编码方案（例如纯颜色编码与颜色加声音加队列位置的组合编码）之间的差异。
这类研究的用途是回答一个具体问题——某种呈现设计在报警潮的背景噪声下，能不能把关键信号的辨别力维持在可接受水平，而不是笼统地问“这个界面好不好用”。
方法论注意点：辨别力和反应时间对背景报警的数量与相似度非常敏感，背景报警设置得过于稀疏或过于同质，都会高估某种编码方案的效果；要让背景条件尽量接近真实报警潮里报警类型混杂、优先级分布不均的样子，结论才谈得上适用于实际系统。
边界
最响、优先级最高的报警不一定是根因，也不一定是唯一需要立刻处理的一条；单纯压低或隐藏所有低优先级报警同样会丢失事故的因果结构，因为低优先级报警里可能记录着后续排查所需的上下文。
持续存在的旧报警和刚刚出现的新报警需要不同的排序逻辑：一条已经存在很久、状态未变的报警和一条刚刚跨越阈值的报警即便优先级相同，紧迫程度也不一样，把两者混在同一套排序规则里会让新出现的高优先级报警被旧报警的数量稀释。
怎么落地
把后果严重程度、剩余可用响应时间、报警新近程度和是否与其他报警争用同一个责任人这几个维度合并成一套排序逻辑，而不是只用一个优先级字段；把判定为关键的项目固定在列表顶部，同时显示被折叠或收起的报警数量，让操作员知道背后还有多少条没展开。
验证办法：用历史报警潮或人工构造的报警潮做仿真回放，在其中嵌入一条关键报警，测量操作员定位到这条报警和采取首个有效动作所用的时间；同时检查从关键报警能不能顺着记录追溯到与它相关的从属证据，确认排序和折叠没有把因果链条切断。