对应错误在紧急时后果最严重
别名: 紧急映射错误 · compatibility error
概念解释
对应错误（compatibility error）本身不是一种新的错误类型，而是显示、控制、对象或方向之间存在容易被误读的映射——可能是布局镜像，也可能是控制方向与结果方向相反。日常运行下，这类映射缺陷未必会酿成事故，因为操作员有时间核对、有记忆缓冲可以纠正；一旦进入紧急状态，压缩的时间窗口会同时抽走这些缓冲，同一个映射缺陷才第一次变得致命。
机制
紧急状态改变的不是映射本身，而是纠错所需的资源供给。按 Rasmussen 的技能—规则—知识框架，时间越紧，行为越被压向技能层：不再逐条核对规则，而是直接执行最熟练、最自动化的反应——这恰好是不兼容映射最容易被绕过训练、退回默认刻板反应的层级。同时，按 Reason 的多层防御模型看，日常运行下一次误操作要连续穿透交叉核验、报警确认、监督复核等好几层防护才会造成后果；这些防护层几乎全部依赖同一种稀缺资源——可用时间与注意力。紧急状态一来，时间和注意力同时被压缩，原本互相独立的防护层因为共享同一个瓶颈而同时出现漏洞，形成"漏洞对齐"，误操作不再需要连续闯过多道关卡，而是直接穿透。再加上系统此时往往已经接近安全边界，同样大小的一步错误，留给后续纠正的余量也更小。
边界
熟练训练能降低这类错误的发生率，但降不到零——这属于 Reason 所说的"强却错"（strong-but-wrong）习惯捕获，越熟练的动作越容易在压力下被无意识地触发，哪怕训练明确教过反例。"紧急"不能只按主观感受判断，需要按可用响应时间窗口来定义：同样的映射缺陷，在有充裕响应时间的场景里可能从未显现，在响应窗口只有几秒的场景里才会暴露。也要防止另一个方向的误用：不能把所有事故都归因于"压力下选错了方向"，权限冲突、程序缺失、设备本身故障同样可能是主因，压力只是放大器，不是万能解释。
怎么落地
在高后果控件上优先排查并消除不兼容映射，这类控件的清单应该按响应时间窗口而不是按主观重要性排序——响应窗口越短的控件，映射错误的容错空间越小。对已知无法完全消除映射风险的场合，增加对象与控制之间的物理邻近、赋予独特形状或纹理便于盲操作确认，并提供动作后的即时可撤销反馈，让选错方向的后果不至于在被发现前就不可逆。验证办法：用贴近真实响应时间窗口的时间压力，加上典型的并发干扰任务（报警、通信中断）测试操作员的首选动作方向，而不只是在无压力环境下测试映射是否"可以学会"——可学会和会不会在压力下用对，是两件不同的事。