报警描述含糊时操作员会依赖经验猜测而非规程
别名: 含糊报警 · ambiguous message
概念解释
含糊报警文本只写"异常""故障"或内部缩写，不说明具体是哪个对象、哪个变量、偏离的方向、当前处于什么运行模式、什么时候发生的。这条讨论的是文字本身缺失了哪些信息、缺失后操作员会怎么补——不是响应时间是否够用（那是同组另一叶的问题），也不是有没有给出第一步动作（那也是另一叶的问题）。这里的核心是：语言留白必然会被填上，问题是被谁、用什么填。
机制
人在压力下处理不完整信息时，会用最近、最容易想起的故障模式去补全语言留下的空白，这个过程往往发生在核对证据之前，而不是之后。同一条含糊消息在不同班组、不同资历的操作员那里会被补成不同的具体判断，造成响应不一致；新手因为缺乏可用来补全的经验库存，反而完全无法把消息映射到规程条目上，只能等老员工解释。多台设备共享同一条消息模板时，这种"猜对象"的风险会进一步放大，因为经验补全给出的往往是最常见的那台设备，而不一定是真正触发的那台。
边界
不能反过来把所有含糊都当成缺陷去消除——某些新颖故障本身就没有确定的原因，经验判断在这种时候仍然是有价值的诊断资源，不该被一句"必须写清楚"抹掉。真正该改的是另一种含糊：明明只有一个症状层面的传感器读数，消息却写得像是确定的根因结论。这种情况下正确的做法不是编造一个看起来具体的说法，而是明确写出"原因未定"并给出下一步的鉴别路径，把不确定性如实呈现出来，而不是伪装成确定文本。
怎么落地
清除消息里所有未在全厂统一定义过的缩写，把资产名称、变量、偏离方向、当前运行模式、发生时间和规程入口五项信息写全。验证方法是找不同资历的人员，在不给作者本人任何口头补充说明的情况下，单独解释同一条消息，统计他们给出的对象判断和处置方向之间的分歧率，以及选错对象的比例；分歧率高的消息模板要重写，重写后再用同样的方法复测，直到跨资历的解释基本收敛。