防护不得阻碍紧急操作
别名: 紧急操作可达 · guarded emergency control
概念解释
防护装置本身的阻力该怎么校准，是防护机制自己的工程问题；这里要说的是控制界面容易在无意中制造的另一种延误——不是防护装置太"紧"，而是紧急控件被套用了和日常控件相同的通用界面确认模式，这套模式默认所有需要确认的操作都可以通过阅读文字、辨认菜单项来完成，而这个默认在紧急状态下并不成立。
机制
阅读一段文字、在菜单里找到目标选项，这两个动作依赖的是当下的认知加工——需要理解文字含义、比较选项、做出选择，而这条通路在人处于高唤醒、高恐慌状态时会明显退化，工作记忆容量下降，逐字阅读和菜单搜索都会变慢、变得容易出错；相反，一个已经练成肌肉记忆的物理动作（掀盖、双手同时按压）不需要认知加工，靠触觉和条件反射就能完成，唤醒水平升高时反而更稳定。软件界面几乎必然要求用户读点什么、找点什么才能完成一次确认——这是界面这种媒介本身的局限，不是某次设计没做好。如果紧急控件被不假思索地接入日常控件同款的确认组件（文字弹窗、下拉菜单式的原因选择），就等于把一个在紧急场景下会退化的认知通道，用在了一个恰恰最需要绕开认知通道的场景上。
边界
不是所有紧急路径都必须做成纯物理动作——如果这条路径本身是给培训不足、不熟悉具体流程的人员用的兜底通道，短暂的文字提示反而能防止他们凭错误的直觉动作；这里的边界是使用者的熟练程度，越是要求受过专门训练的人员在数秒内完成的动作，越不能依赖阅读。另外，即便紧急控件采用了物理动作而不是软件确认，如果这个物理动作背后触发的软件逻辑还要经过一次不必要的网络请求确认或者服务器响应等待，物理层面的"够快"仍然会被软件链路的延迟拖累，防护延误不只发生在界面呈现的确认步骤上，也可能藏在确认之后的执行链路里。
怎么落地
审查所有标记为紧急用途的控件，逐一确认它触发时走的确认路径是不是复用了日常控件的通用组件（阅读文字、下拉选择原因）；凡是复用了通用组件的，要么改成不依赖阅读的物理化交互（大按钮、固定位置的双手动作），要么把确认内容压缩到不需要理解语义就能识别的程度（单一颜色块、单一符号，而不是一句话）。
- 验证办法：追踪一次紧急动作从操作者触发确认到系统真正执行完毕之间的完整链路耗时，把界面呈现层的确认耗时和后台执行链路的耗时分开测量，因为这两段延误的成因和整改方式完全不同，笼统地测总耗时找不出问题出在哪一段。