理解其含义
别名: 态势理解 · Level 2 situation awareness
概念解释
理解其含义是态势感知的第二层，即把已觉察的读数、状态与事件组合成对当前运行状况的解释。理解不是"知道更多数字"，而是建立数字之间的因果关系以及它们和目标的关系：压力升高本身是上一层的信息，判断它与下游阀门关闭共同构成堵塞风险，才是这一层特有的产物。
机制
理解依赖心智模型，把互相独立的读数映射到因果结构、目标和约束上。界面如果只是并列显示离散数值，操作员必须在工作记忆里自己完成这次映射——工作记忆容量有限，一旦需要同时追踪的变量超过大约四五个，整合就会开始丢失细节或被简化的启发式取代真正推理。如果显示直接呈现变量之间的关系（比如把压力和下游阀位画在同一张趋势图上）与正常运行的包络范围，这部分整合工作被搬到了外部表征上，操作员只需要识别偏离，不需要在脑内重建因果链。
这里有一个会翻转结论的条件：经验丰富的操作员通常能更快完成模式识别，因为常见故障模式已经被压缩成可以直接匹配的模板；但同一种经验也会导致确认偏误——一旦匹配上某个熟悉模板，后续证据会被优先按这个模板解释，即使实际情况已经偏离。专家理解得"快"不等于理解得"对"，模板匹配速度和诊断准确率在证据模糊时会分道扬镳，界面能不能呈现与当前假设相矛盾的数据，决定了这个分歧会不会被及时发现。
怎么研究
冻结情境后可以问"系统为何处于此状态""哪些目标受到威胁"，以解释准确率和诊断一致性为因变量；过程追踪要求操作员在得到新证据时口头更新假设，记录假设修正的时间点和方向，而不是只看最终结论对不对。题目设计要避免只测数值记忆，比如"当前压力是多少"这种问题会退化成第一层的测量，真正测这一层要问因果关系或后果预判。
可以设置一组特意包含误导性自动诊断建议的对照场景：同一批读数，一组给出正确的自动诊断提示，一组给出看似合理但错误的提示，比较两组操作员各自构建的解释内容，以及后续证据出现矛盾时，操作员是修正了解释还是延续了最初被给出的结论。这类设计能把操作员自己理解和操作员采信系统结论区分开来，后者本质上是把理解过程外包给了系统。
边界
正确复述界面标签不证明理解——操作员可以背出"温度 85 度、压力 3.2 兆帕"却说不出这两个数字之间的关系，这时候的错误来源在整合而不在感知，补救办法完全不同：应该改善关系表达，而不是加大字号。专家之间也可能因为掌握的证据不完整而形成不同但各自成立的解释，这不是失败，是信息本身还不足以唯一确定原因，界面能做的是标注证据缺口，而不是强行给出单一诊断结论。
自动诊断建议会系统性地改变操作员的假设空间：一旦系统给出结论，操作员倾向于沿着这个方向解释后续证据，即便证据本身指向别处。长期处于这种模式下的操作员会出现脱离环路问题（out-of-the-loop performance problem）的前兆——建立自己因果模型的能力随依赖程度增加而退化，一旦需要脱离自动化独立判断（系统故障、结论存疑），恢复理解所需的时间比从未依赖自动化的操作员更长。这条边界的实际后果是：比较界面设计优劣时，必须把操作员自己理解和操作员采信系统结论分开评分，两者在自动化正常工作时表现相同，只有在自动化出错时才会分化。
怎么落地
在概览中并置相关变量、设定值、约束与最近的控制动作，并提供从异常直接追溯因果链的路径，不要求操作员凭记忆把分散在不同页面上的数字拼起来。
验证办法：用无提示口述法——不给任何引导性问题，只让操作员自由说出"发生了什么、为什么会这样"，记录下来后核对这段解释能不能预测接下来几分钟内出现的证据；如果操作员的解释和实际后续演变一致，才算真正理解，操作是否碰巧正确不能作为理解的证据。对于依赖自动诊断建议的界面，额外设一组隐藏建议来源的测试——同样的建议不标注是系统给出的还是操作员自己得出的，比较两种呈现下操作员对该建议的怀疑和验证行为是否有差异。