把人放回回路：安全人机工程里那些被高估的“适配”与被低估的“失配”

凌晨三点，中控室。一个液位高高报警在四十分钟里响了十一次，操作员在第十一次按掉了它。事故调查报告里写：“未及时响应报警。”这个句子很省事。但它解释不了一件事——前三次为什么是误报，第五次为什么和另一个已经劣化的传感器联动，第九次为什么正好赶上交接班。安全人机工程如果只停在“操作员疏忽”这一层，它就变成了事后追责的修辞工具，而不是设计工具。

说句不客气的，很多所谓“人因分析”，本质上是把系统设计的账单寄给了当班的那个人。

差错是症状，不是病灶

Reason 的瑞士奶酪模型流行了三十多年，流行到有点被用滥了。它的价值在于把事故看成防御层被穿透的过程，而不是单点失效。但它在实践里经常被简化成一张画着几片奶酪的PPT，然后大家点点头，继续回去改操作规程。麻烦在于，差错是系统的输出，不是系统的输入。一个人在某一个时刻做了某个动作，这个动作之所以发生，往前推，通常能找到绩效影响因素：照明、噪声、信息密度、任务时序、培训迁移、轮班节律、界面反馈延迟。把这些因素拿掉，同样的动作未必发生；把这些因素保留，换一个人来，大概率也会踩同一脚。

这里有个容易被忽略的区分：失误（error）和违规（violation）不是一回事。失误是意图正确、执行跑偏；违规是意图本身就绕开了规则。前者靠界面设计、防错设计、冗余与确认来压；后者靠规则合理性、监管感知和组织压力来解。把两者混成一锅“人的不安全行为”，后面开的药基本是安慰剂。

更棘手的是告警。告警设计的初衷是提醒，但告警泛滥之后，它起的作用是训练人忽略它。听觉通道的紧迫感、视觉通道的信息承载、告警的分级逻辑，这些在安全人机工程里都是老话题，可现场还是经常见到一屏几十个红黄点，优先级靠颜色深浅来暗示。操作员的认知资源是有限的，告警不是越多越安全，超过某个阈值，它就从信号变成了噪声。

化工中控室操作员多屏告警界面实景

越自动，越脆弱？

Bainbridge 在1983年写的那篇关于自动化的“讽刺”，今天读起来还是扎人。自动化把常规操作接过去，人退到监控位；监控位上的任务反而更不连续、更依赖情境意识；一旦自动化失效，人要在极短时间里从“旁观者”切回“操作者”。这个切换不是按个按钮那么简单。技能会退化，注意力会漂移，对系统当前状态的心智模型会变薄。

自动化偏见也是同一枚硬币的另一面。系统说没问题，人就倾向于不查；系统给了建议，人就倾向于接受。这不是懒惰，这是认知经济性。问题在于，当自动化在大多数时候是对的，人恰恰丧失了发现它错的那部分敏感度。所以人机功能分配不能是一次性的静态切分，Fitts 列表那种“人擅长什么、机器擅长什么”的清单，放在动态任务里经常失灵。分配要跟着任务不确定性走，跟着风险暴露走，跟着人的负荷状态走。

但“动态分配”这四个字说起来轻巧，做起来有反例。自适应界面如果变得太快，人会失去对系统行为的可预测感，反而增加认知负担。接管请求给几秒？三秒够不够？这取决于驾驶人当时在看哪里、手在不在方向盘上、前方场景的复杂度。脱离具体条件谈“人机共驾”，基本等于谈玄。

飞行模拟器驾驶舱自动化情境意识测试

标准量不出的人

人体测量学给了我们百分位，第5百分位、第50百分位、第95百分位，设计手册上写得清清楚楚。可百分位是静态总体的切片，不是动态任务里的个体。一个人弯腰搬箱子，NIOSH 提举方程能算出一个推荐重量限值，但它有一串前提：双手对称、无扭转、良好抓握、稳定站位、重复次数可控。现场呢？单手、侧身、箱子没把手、地面有油、旁边还有人催。条件一变，方程的结论就悬空了。

姿势评估工具也一样。RULA、REBA 这类观察法在筛查层面有用，但观察者间信度从来不是满分，关节角度的目测误差、任务周期的采样偏差、多任务叠加时的取舍，都会让结果漂。标准给出的是底线，不是答案。它告诉你什么情况下大概率有问题，不告诉你这个工位上具体该怎么改。改，还得回到任务本身：能不能把物料抬到腰高、能不能去掉那次转身、能不能让搬运频次降下来。

包容性设计常被误解成“照顾少数人”。其实它处理的是分布尾部和任务变异之间的冲突。控制台按第50百分位的身高定高度，矮个子得抬肩，高个子得窝着；可如果任务要求频繁切换坐站，固定高度本身就成了问题。可调，比“精确匹配某一个百分位”更接近安全人机工程的思路。但可调也有代价：调节范围、锁定可靠性、误调风险、以及人会不会真的去调。

装配工位弯腰搬举作业姿势测量现场

验证发生在现场，不在PPT里

验证发生在现场，不在PPT里

人因验证这件事，最容易被做成一次性交付物。界面设计完了，找几个受试者做一轮可用性测试，任务完成率、NASA-TLX 负荷评分、SAGAT 情境意识探测，数据挺好看，报告归档。然后系统上线，工况变了，任务耦合变了，原来的结论悄悄失效。

实验室和模拟器的保真度是个老争论。高保真不等于高生态效度。模拟器里没有真实的组织压力、没有隔壁工段的催促、没有那天正好缺人的排班。反过来，现场试验又受伦理、成本、可重复性的限制。折中的办法不是追求“完全真实”，而是把验证嵌进迭代：先在最能暴露设计假设的边界场景里测，再在运行初期做纵向观察，把偏差回灌到设计里。人因验证不是一道验收工序，它更像一条持续校准的回路。

方法上，STPA 这类基于控制结构的方法，擅长找出“不安全控制行为”及其上下文；FRAM 则更关注功能之间的共振和变异。它们各有适用边界：任务边界清晰、耦合弱的时候，清单式方法够用；一旦系统进入高耦合、连续变化的状态，静态清单就会漏掉交互效应。选方法不是选立场，是选跟问题匹配的粒度。

那条说不清的边界

那条说不清的边界

安全人机工程能做什么？它能把“人”从事故报告里的责任主体，还原成系统设计中的一个受约束节点；它能把界面、任务、环境、组织这些变量放到同一个分析框架里；它能给出可检验的假设，而不是停留在“加强培训”这种万能句上。

它不能做什么？它不能替代安全管理，不能把所有系统缺陷都翻译成界面问题，也不能保证在资源约束下一定有一个既便宜又有效的方案。有时候最有效的干预是减少夜班频次，有时候是换一种物料包装，有时候是承认某个自动化等级在当前任务复杂度下不成立。这些都不太像“人机工程”，但它们确实是。

回到凌晨三点那个中控室。如果设计阶段有人问过一句：这十一次报警里，有几次是真的需要操作员立刻动作？这个问题不解决，换谁来坐那把椅子，结局都差不多。说到底，把人放回回路，不是给人加责任，是给设计加约束。