紧急操作后的状态反馈必须清晰无歧义
别名: 紧急动作反馈 · command execution feedback
概念解释
紧急操作完成后，系统反馈需要清楚区分命令已接收、动作正在执行、物理效果已实现、安全状态已通过独立手段确认这四个阶段。一个指示灯亮起或按钮变色，如果不说明这是哪个阶段，操作者容易把"命令已接收"误当成"危险已解除"，从而过早停止后续处置或撤离警戒。
机制
从操作者按下控件到最终的安全效果真正生效之间，天然存在若干段独立的延迟——通信链路传递指令需要时间，执行机构（阀门、断路器）从接到指令到完成物理动作需要时间，被控过程本身对该动作作出响应也需要时间。界面上常见的按钮按下即变色这类局部回显，其实只证明"这次点击事件被捕捉到了"，并不能证明后面这几段延迟已经真正走完——阀门可能因为卡涩没有真正关到位，界面上却早已显示"已完成"。要打破这种虚假的确定感，反馈必须依靠独立于命令通路的传感器去检测物理效果本身，并把意图（命令已发出）、过程（动作正在进行）、结果（效果已核实）这三层显式区分开分别显示，而不是用一个笼统的状态图标概括所有阶段。
边界
反馈本身依赖的传感器也可能失效或读数矛盾，不能把反馈系统当成绝对可信的来源——当传感器状态不明或几个读数互相矛盾时，应当明确呈现"未知"或"存疑"，而不是默认展示乐观结果。某些安全效果（比如确认某个空间里确实没有残余能量或危险物质）本身超出了任何传感器能覆盖的范围，仍需要人工到现场做物理确认，界面反馈在这类场景只能提示"该去核实"，不能替代现场核实本身。当多个工位可以同时对同一套设备发出紧急操作命令时，反馈还必须额外显示命令来源以及是否存在多个工位同时下达冲突指令的情况，否则操作者可能误以为是自己的操作生效，实际上是另一个工位造成的效果。
怎么落地
给命令接收、执行中、效果确认这几个阶段各自设计明确的文字说明，伴随时间戳和信息来源，让操作者能一眼判断现在处于哪个阶段。为每个阶段设置合理的超时：如果在预期时间内没有收到下一阶段的确认，状态应当主动转为"未知"或"失败"，并同时给出下一步该采取的安全动作建议，而不是让界面停留在最后一个乐观状态不再更新。对于依赖现场物理确认的安全效果，保留明确的"仍需人工核实"提示并默认存在剩余危险。验证阶段应当主动注入通信中断、执行机构卡死、多个传感器给出互相矛盾读数这几类故障场景，检查界面在这些异常下是否仍然给出诚实的状态描述。