突显消退的时机需避免异常尚未解决就被忽略
别名: 异常提示持续性 · alarm cue persistence
概念解释
突显的消退时机要跟着异常本身的风险生命周期走：被操作员看见、正在被处置、以及问题已经真正消除，是三个不同的状态。如果突显只因为操作员按了确认、或者读数短暂回落到阈值以内就自动消退，尚未真正解决的风险会从操作员的注意范围里退出，即便它仍然存在。
机制
短暂的强显著性（闪烁、变色）负责把新出现的异常从背景里拉出来，捕获注意；持续但不那么抢眼的状态标记，负责在异常没有处理完之前一直提醒它还在，起到外部记忆的作用，弥补操作员不可能一直盯着这一个点看的限制。这两个功能如果绑定在同一个视觉信号上——比如都靠闪烁——就会出现两难：一直闪会让人疲劳并干扰对新异常的捕获，一旦停止闪烁又在视觉上等同于"恢复正常"。把"刚出现""已确认""仍未解决""已清除"当成四个可以分开编码的状态，才能让捕获和持续提醒各自独立起作用。
确认（acknowledge）这个操作本身只是操作员告诉系统"我看到了"，不代表问题被解决，但很多系统架构里唯一容易稳定捕捉的状态迁移就是"报警产生"和"被确认"这两个事件——确认在系统里有明确的事件边界，而"问题实际解决了没有"往往没有一个同样干脆的信号可以触发，需要额外的清除判定逻辑。如果不特意补上这层判定逻辑，界面设计上最省事的做法就是拿确认动作去触发闪烁停止，确认和解决就会在界面上被压缩成同一件事，结果是最危险的状态——已确认但仍未解决——在屏幕上看起来和已经处理完的状态没有区别。这一点会因为持续关注被打断而进一步恶化：一段时间没人主动去看这个不再闪烁的点，仅靠余光扫视很难重新注意到一个没有变化的静态标记，因为对静止、无瞬变信号保持警觉本身会随时间衰退，这与长时监视里的警觉衰减是同一类机制在不同尺度上的表现。
怎么研究
在仿真环境里设计确认后仍持续、间歇性自行恢复又复发、以及需要人工手动关闭三类异常，测操作员事后被问及"当前有哪些未解决问题"时的遗漏率、重复确认次数（说明操作员忘了自己已经确认过并再次被提醒），以及不同呈现方案下操作员能不能准确区分"已确认仍存在"和"已清除"两种视觉状态。交接班场景特别值得设计：让接班操作员只看画面、不看日志，说出当前所有仍未解决的异常，再和真实日志核对遗漏了哪些。
边界
有些瞬态报警在触发条件消失后不需要继续占据主视野——比如一次短暂的仪表尖峰，只要有完整的事件记录可查，没必要让它一直保持显著；把所有历史上出现过的异常都维持高显著性，本身会制造新的视觉负荷，等于把"避免遗漏"的问题换成了"到处都是需要处理的东西"的问题。另外，有些异常会被操作员主动、有时限地屏蔽（通常称为屏蔽或搁置，即 alarm shelving），这是一种应当留痕、到期要重新评估的显式动作，如果它和普通的"已确认"用同一套持续标记呈现，屏蔽就失去了它本该具备的可追溯性和到期提醒——操作员分不清一个安静的点是"已经被判定安全所以暂时不管"还是"只是没人去点开看"。
怎么落地
新出现的异常用短促的高强度线索完成捕获，一旦被确认或经过一段时间，转为形态不同但仍然清晰可辨的"未解决"标记，而不是转为无标记；只有满足预先定义好的清除条件（比如读数回到正常范围并保持一段时间，或者有对应的维修工单关闭）才允许移出活动异常区域，操作员的手动确认不能单独触发这一步。对确实需要人工屏蔽的异常，单独给一种和"未解决"、"已清除"都不同的呈现方式，并且系统要在屏蔽到期时重新提示。验证办法：抽取历史日志里确认后又保持较长时间未解决的真实案例，回放当时的画面状态，核对当时的视觉呈现能不能让人一眼看出它和已清除的异常不同；同时检查屏蔽记录里有没有超期未复核的条目。