报警疲劳：视觉 SOP 项目最常见的死因

一个项目从上线到失效，往往走完这样一条路径：第一周大家很新鲜，第二周开始有人抱怨太吵，第三周班组长把音量调低，一个月后系统只在后台记录，三个月后没人再看。这条路径与算法准不准关系不大，它是由报警的设计方式决定的。

决定报警是否被认真对待的三个因素

• 呈现给谁。 报警如果直接指向个人，容易引发对抗；如果呈现给班组或品质岗用于改善，接受度明显更高。这一点在方案阶段就要想清楚。
• 频次如何。 每小时十条报警一定被无视。可接受的经验值是：现场人员能够逐条查看并做出反应的频率。
• 后果是什么。 报警之后有明确动作（返工、停机确认、班后复盘），报警才有意义。如果报警之后什么也不发生，很快就会没人理。

渐进上线的三个阶段

报警设计的细节方法可以参考装配错工序报警怎么做才不误报，那篇里整理了六个具体的误报控制做法。

报警疲劳的早期信号

• 反应时间变长。 报警出现后，从提示到有人处理的间隔逐渐拉长。
• 处理趋于敷衍。 操作人员不再看具体内容，直接按确认键清除。
• 开始自行调低。 有人把音量、亮度或灵敏度调低，而且没有报备。
• 提出「关掉它」。 班组长开始把系统描述成负担，这是最接近失效的信号。

这些信号不一定会写进任何报表，但在现场待几天就能感受到。发现得越早，调整的余地越大。等到系统已经被调成「只记录不提示」，再想恢复现场对它的信任，代价要高得多。

把报警量降下来的做法

报警应该送到谁那里

接收对象决定了报警的性质。送给操作人员，是要求当场纠正，报警必须是即时的、明确的、可执行的；送给班组长或品质岗，是用于当班复盘与改善，可以聚合、可以延后；送进管理层报表，是用于趋势分析，关注的是比例与走向而不是单条记录。把三种需求混成一种报警，是设计上最常见的失误。

比较稳妥的分工是：工位端只承担「当场能纠正的少数关键工序」；其余异常进入班组与品质的复盘视图；系统再按周或按月汇总趋势给管理层。让每个层级看到的都是对自己有用的那一部分，报警才不会被当成负担。

要不要把报警和考核挂钩

这是最需要谨慎的一步。报警与个人绩效直接挂钩，短期内可能压低异常数字，但代价是数据失真：员工会想办法规避检测，例如遮挡、绕开、或按白名单的路径操作，系统看到的不再是真实作业。

更稳妥的做法是分两步走：系统稳定、判定可信之前，报警只用于改善，不进入考核；等到判定的一致性经过一段时间验证，再考虑对少数关键工序的合规情况纳入管理，而且以班组为单位，而不是直接指向个人。

报警少一点，反而更有效

与其让系统在每个工位都响，不如让它只在真正重要的地方响。报警越少、越准，现场越会认真对待每一条。这一点和「报警越多越安全」的直觉正好相反，却是很多项目跑通之后才慢慢体会到的经验。现场的接受度问题见操作人员抵触与试点成功为什么推广失败。