自动扶梯AI图像识别监控系统设计与功能安全落地实践

上个月我接了一个电梯厂的活儿，要在自动扶梯上加一套AI图像识别监控系统。本来以为跟普通安防项目差不多，无非是部署几个摄像头、训练一个检测模型、出报警了推送给值班室——结果越做越深，涉及功能安全标准、安全回路改造、故障注入测试，甚至还要跟认证机构开会解释“AI能不能进安全回路”这种灵魂拷问。整套搞下来我才意识到，这个题目比我想象的大得多，而且行业里真正能把视觉AI和功能安全两套体系都讲清楚的人，真的不多。

今天就把这个项目的完整思路、落地步骤和踩坑经验整理出来。文章里会讲清楚自动扶梯监控到底要解决哪些问题、AI图像识别的方案怎么选、功能安全标准怎么卡你、以及现场部署时那些文档里不会写的细节。适合三类人看：一类是做电梯/扶梯维保和安全管理的工程师，想了解AI监控能补哪些盲区；一类是AI算法或边缘计算工程师，想进入工业安全场景但不知道标准怎么约束你；还有一类是方案集成商，准备投标类似项目，需要知道怎么把系统做到“过得了验收”。

1. 为什么自动扶梯必须做智能监控：从事故痛点到传统方案的盲区

1.1 自动扶梯的主要事故类型与监控需求

自动扶梯事故不是低频事件。最常见的几类，我列一下：梯级缺失或下陷、梳齿板异物卡入、扶手带入口夹人、乘客摔倒未及时停梯、扶梯盖板开启或分离。每一类都对应一个明确的监控需求。比如梯级缺失这种，一旦乘客踩上去就是踏空坠落，伤害等级极高；盖板打开而扶梯继续运行，曾经出过死亡事故。这些都是安监和电梯厂家最怕的场景。

但有意思的是，很多扶梯本身不是没有安全保护装置。梯级链断裂有安全开关，梳齿板有异物开关，扶手带入口有防夹开关——这些都是传统机械或电气保护。那还要AI干什么？核心原因有两个。

第一，不少关键风险没有直接触点。乘客摔倒就是典型。传统扶梯不会因为你摔倒了就自动停，只有严重到卡入梳齿板或者触发某个开关才停。但摔倒后如果被拖行，几秒钟就可能导致严重伤害。还有盖板打开这件事，很多老梯靠巡检去发现，巡检间隔可能是一小时一次，中间出了事没人知道。第二，传统安全开关是“点式检测”，触发时往往事故已经发生了至少一小段。AI图像识别能做的是“状态和行为的持续感知”，在事故发生前或刚发生的瞬间就发现异常，争取时间差。

1.2 现有监控方案的几个硬伤

我去现场调研的时候，发现很多扶梯已经装了监控，但基本都是普通安防摄像头，有几个问题非常突出：

一是录像不等于预警。出了事以后调录像回放，这叫事后追溯，对减轻伤害毫无帮助。二是单靠人盯屏幕不现实。一个商场几十台扶梯，中控室值班人员根本没精力一直盯着看。三是普通视频分析算法在扶梯场景表现很差。扶梯环境光照变化剧烈、有大量玻璃反射、人员密集且相互遮挡，用通用的人体检测模型去跑，误报率能高到让人想把它砸了。

所以这个项目最终要回答的问题其实很清楚：怎么用AI图像识别，把扶梯运行中的关键隐患变成及时、可靠、可联动停梯或降速的报警信号，同时在整个链路里满足功能安全相关标准的要求。这个“可靠”和“标准”四个字，才是真正让项目从“demo玩具”变成“工业可用产品”的分水岭。

2. 系统整体架构与AI图像识别方案选型

2.1 边缘计算为主、云端为辅的整体架构

接到这种项目，第一个要定的就是架构。我的选择是边缘端为主、云端为辅。每个监控点位配一个AI计算盒子，摄像头直接接入盒子，盒子做实时推理，输出开关量信号或通过网络协议发给扶梯主控。云端只用来做模型远程更新、数据统计和异常录像的二次复核。

为什么不用纯云端方案？很简单，实时性不够。扶梯安全场景要求的是从异常发生到输出告警控制在1秒以内，最严格的情况甚至要求500毫秒以内。上一趟云、做一次推理、再回来，网络抖动一下就超时了。而且很多扶梯在地下商场、地铁站、机场，网络环境并不稳定。边缘计算把推理放在本地，延迟可控，也不依赖带宽。

那为什么还需要云端？因为边缘端跑的人脸识别、摔倒检测这些模型，初始版本不可能完美。现场场景和训练数据总有差异，需要定期收集边缘端的误报样本回传云端，重新训练后再推给边缘端。云端在这里扮演的是“持续优化闭环”的角色，不是核心推理路径上的节点。

2.2 硬件配置与选型心得

硬件这块我踩过坑，最开始有人提议用ESP32-S3-CAM这种极低成本的方案。我直接否了。不是说它不能跑图像识别，而是它跑不了稳定、低延迟的工业级推理。扶梯监控需要7x24小时连续运行，散热、稳定性、算力余量都必须考虑，这些是MCU级别方案无法满足的。

我的选型思路分两层：摄像头和AI计算盒子。

摄像头方面，首选工业级网络摄像机。关键参数是帧率和宽动态能力。扶梯口往往是逆光环境——室外扶梯有太阳直射，室内扶梯有商场灯光，人从亮处走进暗处或反过来，普通摄像头拍出来的画面经常会过曝或者全黑。宽动态范围至少要120dB，最好支持背光补偿。分辨率200万到400万像素就够了，不需要超高像素，因为目标检测算法在640或1280的输入分辨率下就能跑得很好，拍得太清楚了反而浪费带宽和算力。

AI计算盒子方面，我推荐Jetson Orin Nano或者瑞芯微RK3588方案。这两者我实际都用过：Jetson的软件生态更好，TensorRT加速部署方便，对PyTorch模型的兼容性很高；RK3588的优势是国产化要求好过、价格更低、功耗控制不错。如果项目有国产化替代要求，RK3588是稳妥的选择；如果没有特殊要求，Jetson系列开发效率更高，更适合快速落地。

算力怎么定？以YOLOv8s检测模型为例，640分辨率输入，在Jetson Orin Nano上做完TensorRT加速和INT8量化，单路推理延迟大约在20-40毫秒。如果同时要跑两个模型——比如一个目标检测模型检测梯级和盖板状态，一个姿态估计或行为分类模型识别乘客摔倒——那算力至少要留30%冗余，不能满负荷跑，否则系统长时间运行后热降频，帧率掉下来，告警延迟就上去了。

2.3 AI模型选型：检测什么、用什么模型

先梳理检测目标，再选模型。根据扶梯事故清单，我分成了两类：

第一类是结构性状态检测。包括：梯级缺失/下陷、梳齿板异物、盖板开合状态。这类目标相对固定，可以用目标检测或语义分割来做。第二类是人员行为检测。包括：乘客摔倒、在扶梯上逆行、携带超限物品（如婴儿车、大件行李）、人员拥挤。这类需要“目标检测+跟踪+动作分类”的组合方案。

具体模型选择我讲自己的习惯。目标检测现在是YOLO系列的天下，YOLOv8或者YOLOv9都有成熟的开源实现和预训练权重，在公开数据集COCO上的表现足够作为baseline。但注意，COCO预训练权重不包含“梯级”“盖板”“梳齿板异物”这些工业对象类别，所以要自己标注数据，进行微调。人员摔倒检测，可以直接用目标检测（检测到人的位置）+跟踪（Deepsort或者ByteTrack）+一个基于人体关键点的姿态估计模型，判断人的朝向、重心高度和速度变化，综合判断是否摔倒。也可以用3D CNN或Video Transformer直接做端到端的行为识别，但这类方案训练数据需求量更大，部署成本更高，在工程上不如“检测+跟踪+规则判断”稳妥。

我最终用的是组合管线：先用YOLOv8检测人、梯级、盖板、异物，再用ByteTrack做多目标跟踪，最后用一套基于运动状态的规则引擎判断摔倒或逆行。为什么要加规则引擎？因为纯端到端的行为识别模型在复杂光照下误报率高，而规则判断逻辑清晰、便于解释，这在功能安全评审时是一个加分项。

2.4 数据集准备与标注要点

数据是这种项目最大的隐性成本。扶梯场景的公开数据集非常少，我找过几个电梯公司的安全测试视频，也扒过一些事故新闻里的视频素材，但量远远不够。最后自己到现场采集了三个不同商场的扶梯视频，包含不同光照、不同人流密度、不同扶梯型号，累计大概200小时有效视频。

标注的颗粒度要讲究。梯级和盖板这类结构件，用矩形框标注就行，但要注意区分“完全缺失”“局部破损”“异物覆盖”三种状态。人员摔倒的标注，除了给每个人打检测框，还要标注一个“摔倒”事件的时间区间，供后续序列模型用。这里有个经验：宁可视频采样的场景数量多，也不要单一场景的时长多。模型泛化能力的提升主要来自场景多样性——不同商场的装修风格、地砖纹理、扶梯颜色都会影响模型表现。

我自己在标注还有一个小技巧：对扶梯两侧的玻璃围栏反射，要专门采一批容易产生误检的场景，标注时把反射里的人影目标全部标注成“忽略”。如果不做这一步，模型会把玻璃反射里的虚拟人当成真人，出现大量莫名其妙的空报警。

3. 功能安全标准与合规要求：AI系统如何过安全关

3.1 功能安全到底是什么：不是“可靠”那么简单

做电梯行业的人对“功能安全”这四个字应该不陌生。但做AI视觉的人，很多第一次听到这个概念时是一脸懵的——什么SIL、PL、安全完整性等级、失效率，跟“测准确率”完全不是一个语言体系。

我用一句话解释：普通AI系统关心的是准确率，比如检测到摔倒的准确率是95%；功能安全关心的是“万一出错了，后果有多严重，以及这个错能不能被控制”。功能安全的核心是把“随机硬件失效”和“系统失效”的概率降到可以接受的水平，并给出可量化、可验证的证据。

自动扶梯的安全相关部件，按ISO 13849标准，一般要求性能等级PL d或PL e；按IEC 62061，则对应SIL 2。这意味着什么？意味着如果你想让AI识别系统直接作为安全功能的一部分——比如AI检测到梯级缺失后直接触发安全回路断开——那AI系统本身的失败率必须低到可量化的程度，且必须有系统性失效的规避措施。这就遇到一个非常现实的困难：目前AI组件普遍不被认证机构认可为“安全相关”部件。

为什么不被认可？最核心的问题是AI模型的黑盒属性和数据依赖性。你没法证明模型在所有的边界情况下都不会出错；你也没法计算出模型失效的概率分布。功能安全标准要求的是确定性逻辑，而AI是概率性逻辑，两者在范式上冲突。

3.2 扶梯监控涉及的标准梳理

这个项目里你会遇到的标准，我逐个说一下：

国际和国内基础标准方面，IEC 61508是功能安全的基础标准，所有其他功能安全标准都从这里派生；GB/T 20438对应IEC 61508在国内的采用。ISO 13849对应GB/T 16855.1，是机械安全相关的控制系统安全部件标准，用PL等级衡量；IEC 62061对应GB/T 38926?（这里我记不太准，具体看最新版本），用SIL等级衡量。扶梯产品本身的制造与安装标准是GB 16899（等同于EN 115），它规定了自动扶梯必须配置哪些安全装置，以及安全电路的要求。

此外还有针对图像监控系统的标准要求，比如GA/T 1400视频监控系统标准，虽然主要是公安视频监控用的，但很多项目验收时也会参考其中的视频编码、存储和图像质量要求。

3.3 AI监控系统在功能安全框架下的三种定位

在跟认证机构沟通时，我把AI监控系统的功能安全定位分成了三种，这是最关键的方案决策：

第一种是纯告警辅助系统。AI系统不接入扶梯安全回路，只是输出声光报警、推送给中控室，由人决定是否停梯。这种定位下功能安全要求最宽松，AI系统被定义为“信息提示设备”，不承担安全功能。缺点也明显：依赖人工响应，反应速度慢，容易漏处理。

第二种是降速联动系统。AI系统发现异常后，不直接切断安全回路，而是通过非安全相关的信号控制变频器降速到低速运行。这样即使AI误报，最坏的结果是扶梯慢速运行一小段时间，不会造成长时间停运，也不会带来安全事故。这种定位需要AI系统具备一定的可靠性，但不需要达到SIL等级，因为它不承担“防止伤害”的核心安全功能。

第三种是直接介入安全回路。AI识别到危险后直接触发安全继电器断开扶梯电源。这种定位下AI系统必须作为“安全相关系统”来设计和验证，难度成倍增加。

我最终在项目中采用了第二种定位：AI系统输出后，通过一组独立的中间继电器，控制扶梯的降速或暂停请求信号，同时保留原机械安全装置直接触发安全回路的路径。这么做的好处是：AI系统出错了不影响原有安全功能，原有安全保护还保留着；AI系统的可靠性做得好，可以明显减少事故发生，也能缩短停机响应时间。第三种定位，我建议除非客户明确要求并且愿意承担巨额认证费用，否则不要碰。

3.4 功能安全设计中的几个落地细节

先讲安全回路独立性。AI监控系统最好采用独立供电、独立布线，不要和原有安全回路混在一起。否则当AI系统故障时，可能影响到扶梯原有安全回路的完整性。现场部署时，我用了一个独立的隔离变压器给AI盒子供电，输出信号通过光耦隔离后再接到接口端子。

再讲故障响应时间设计。扶梯行业对安全功能响应时间是有要求的，GB 16899里对机械制停距离有明确规定。AI系统从图像采集到输出开关量，整体延迟必须控制在一个确定的范围内。我的设计目标是：从异常发生到输出信号不超过800毫秒，其中图像采集50毫秒，推理50-100毫秒，跟踪和规则判断20毫秒，继电器动作50毫秒，其余为系统余量。这要求推理框架必须做性能测试和下限保证，不能出现偶发性超时。

还要讲故障注入测试。这是验证系统可靠性的重要手段。可以用CANoe对扶梯主控进行故障注入，模拟各种传感器失效的情况，验证AI系统在这些场景下是否还能正确响应。比如模拟梯级链故障信号注入时，观察AI系统是否误判、是否漏报、系统是否发生死机等异常。

3.5 认证与验收陷阱

这个项目最容易被坑的地方是：功能安全评审时，评审专家一定会问你“AI系统是否被定义为安全相关系统”。你要在这个问题上做好预备答案。

我的建议是：在技术方案和产品说明书中，明确写入“本AI监控系统为非安全相关设备，不参与安全保护功能，扶梯安全仍由符合GB 16899的安全装置保障”。这样做的目的是把AI系统的功能安全责任边界划清楚，避免认证时陷入“你们这个AI系统是否达到了SIL 2要求”这种无法回答的问题。评审问起来，你就能理直气壮地说：我们不是安全相关系统，但我们给值班员多提供了一层额外的监测和报警能力。

当然，这不意味着AI系统的质量可以随便做。作为集成商或开发方，你应该主动用功能安全的管理方法来规范AI系统的开发过程——包括需求追溯、变更管理、验证测试记录、现场运行数据留存。这些文档在项目验收和后续责任界定时有巨大价值。

4. 系统实现与现场部署实操

4.1 部署流程全景

整套系统的落地流程，我把经验压缩成九步：现场勘察、点位设计、网络与供电规划、硬件安装、相机标定、模型部署调试、联动逻辑配置、系统联调测试、验收文档准备。

每一步都有具体的坑。先说现场勘察，一定要记录扶梯的规格参数、所在环境的照明条件、人流高峰期时段、有无玻璃围栏、有无遮挡物。这些直接关系到相机选型和安装角度。我在一个地铁站项目里，扶梯上方有大型广告灯箱，灯光直射相机镜头，导致画面中的人脸完全过曝——勘察时没注意，后来返工换了安装位置。

再说点位设计，这是决定识别效果的核心环节。

4.2 相机点位与角度设计

扶梯监控点位设计有三个关键位置：上端、中段、下端。上端相机用于检测盖板状态和乘客进入扶梯区域的拥挤情况；中段相机用于检测乘客摔倒、逆行、携带大件物品；下端相机用于检测梳齿板异物、乘客离开扶梯时是否摔倒。

相机安装角度对识别效果影响极大。我实测的经验是：俯视角度在30度到45度之间最合适。角度太正，行人彼此遮挡严重；角度太斜，人的轮廓变形，检测框不稳定。安装高度建议在2.5米到3.5米之间，既能覆盖扶梯全长，又不容易被人为破坏。

另外提一个镜头选择问题。扶梯通常是直线型，一台相机覆盖的视场范围有限。如果扶梯长度超过15米，建议在中段位置再补相机，不然远端的人只有几十个像素，识别效果会很差。

4.3 模型的训练与优化

模型训练这一块，我基于YOLOv8做了一个通用基线模型，然后在自采数据上微调。整个过程大概说一下：

第一步，数据清洗。把采集的视频按帧抽出来，去掉模糊帧、重复帧，剩余有效帧约12万张。第二步，标注。我用了X-AnyLabeling做预标注，再人工修正。梯级、盖板、梳齿板异物、人、婴儿车、大件行李，一共六个类别。第三步，训练。用COCO预训练权重初始化，输入分辨率640，batch size 16，训练100个epoch。第四步，测试与调优。单独留出两个从未参与训练的商场场景做验证集，计算map、误报率和漏报率。

这里我说一个关键的验收指标：我给自己定的标准是漏报率不高于千分之一，误报率每路每天不超过2次。千分之一的漏报率不是随便定的，是根据功能安全里“危险失效概率”的概念推导出来的。做不到这个水平，报警系统就会变成狼来了，值班员最终不再信任系统。

模型优化方面我做了几件事：一是用光度畸变和随机擦除做数据增强，提升模型对光照变化的鲁棒性；二是专门收集了玻璃反射误报样本做负样本挖掘；三是对扶梯梯级这类小目标，在训练时增加了更高的分辨率训练分支。

4.4 边缘端部署：TensorRT加速与稳定性验证

推理优化是部署的王道。PyTorch模型直接跑在Jetson上，速度大概只有5-8帧每秒，根本不够用。我用TensorRT做了导出和优化，经历了FP16精度到INT8量化两个阶段。

FP16量化后，在Jetson Orin Nano上单路推理能达到25-30毫秒每帧，精度损失几乎可以忽略。INT8量化后速度更快，但精度略有下降，我做了校准集来缓解。最终我在项目里用的是FP16，原因是INT8在玻璃反射、暗光等复杂场景下的误报率上升比较明显，而FP16的速度已经够用了。这里想提醒大家：不要盲目追求INT8，工业场景里精度优先于速度，帧率差几十毫秒不影响结果，误报率高了会让人崩溃。

长期运行稳定性一定要做压力测试。我让系统不间断跑了72小时，记录每小时的推理耗时、内存占用、显存温度。实测下来有些问题：边缘盒子在商场高温环境下，散热不做好会触发降频，推理耗时从30毫秒涨到80毫秒，这绝对不能接受。后来换了带风扇的工业导轨式工控机，问题解决。

4.5 与扶梯主控的联动与接口设计

AI系统的输出要与扶梯主控对接，接口方案有几种：干接点继电器输出、RS485串口协议输出、Modbus TCP输出。最稳妥的是继电器干接点，电噪声干扰小、隔离性好，也容易被电梯控制柜接受。

我在项目里用了一个自研的小逻辑控制器，接收AI盒子的告警信号，经过延时防抖后再驱动输出继电器。为什么要加延时防抖？因为单帧误检很常见，比如光线突然变化会导致某几帧出现误判。我设置的是连续3帧确认后才输出告警，这个逻辑大大减少了误报，代价是响应时间增加了约100毫秒。3帧确认这个参数，是在误报率和响应时间之间的平衡点，亲测效果很好。

联动策略上，我设计了分级告警：一般异常（如乘客在入口逗留超过5秒）只输出提示信号，中控室LED屏显示黄色提示，不联动扶梯；较严重异常（如乘客摔倒）输出红色告警，联动扶梯降速运行；严重异常（如梯级缺失、盖板打开）除了红色告警，同时请求扶梯主控停机。这个分级策略解决了“频繁停梯造成乘客不满和运营困扰”的问题，也更有说服力。

5. 常见问题与排查技巧实录

5.1 光照与反射类问题

扶梯场景最头疼的就是光照。我先说逆光：扶梯口往往朝向室外，出入口是强光源，乘客人脸和检测目标处于背光状态。我的排查经验是，首先确认摄像头是否开启了宽动态模式，其次看安装位置是否可以让光源在侧面而不是正前方。实在避不开，就在相机上加遮阳罩或用偏振镜减少强光进光量。

然后是玻璃反射。商场扶梯两侧十有八九是玻璃围栏，灯光照上去会形成大量反光，反光里的行人影像会被模型当成真人。我的处理办法综合了几步：在训练数据中加入现场采集的强反射场景样本，模型可以学会忽略反射区域；在推理阶段，对画面中特定ROI区域进行屏蔽，比如两侧玻璃反射区直接不参与检测。这里有个技巧：用Polygon ROI标注把非扶梯区域全部排除，模型就不需要在这些区域浪费算力和产生误判。

5.2 遮挡与密集人流问题

高峰期扶梯上人挤人，人体检测框互相重叠，摔倒的人可能被其他人完全挡住。实测下来，我的组合方案给人满意的效果：先用多目标跟踪建立每个人的轨迹，当某个人轨迹消失前突然出现大幅垂直方向位移，或者长时间静止不动时，就算摔倒疑似事件。这样即使目标被遮挡，跟踪器依然能维持一定的判断能力。

另外，检测框重叠导致漏检的问题，我用的是非极大值抑制调参。默认参数比较保守，密集场景下很多真实目标被抑制掉了，我适当降低了NMS阈值，并把类别置信度阈值从默认的0.5下调到0.35。这个改动优点明显：召回率提升了，代价是误检略有上升，但通过3帧确认机制控制后，整体可用性很好。

5.3 硬件与运行环境问题

工业现场最容易出现在电源和网络的坑。边缘盒子和相机如果采用同一个非稳压电源，扶梯启停时电压波动会导致设备重启。我的做法是：整个AI监控系统单独拉一路稳压电源，在配电箱里加UPS，断电后至少能撑10分钟，把实时告警信息完整推送给值班室。

网络方面，现场用交换机时遇到一个典型情况：摄像头和盒子都是千兆口，但网线是老旧的超五类，长时间高码流传输时丢包严重。排查下来替换成六类网线后问题解决。还有一个容易被忽略的点，交换机的PoE供电功率不够，多个摄像头同时启动时功率过载，摄像头反复重启。选PoE交换机时一定要算总功率，并且预留20%以上余量。

5.4 模型失效与持续优化问题

项目运行一段时间后，误报会慢慢增多。原因是现场环境会变：商场换了地砖、扶梯重新刷漆、广告牌换了新画面。这些视觉变化都会降低模型置信度。我的对策是建立一个现场反馈闭环：所有告警事件都保存截图和视频片段，每周由维保人员快速打标一次，把误报样本定期回传到云端，增量训练后更新模型。这个闭环是人类专家，用户主动挖掘，构建版本迭代，有明确的流程体系。

有人会问，增量训练会不会把之前学习到的知识遗忘掉？实际中确实可能会发生。我加了经验回放机制：每次增量训练时，从历史数据中心抽取一部分旧样本混合训练，避免灾难性遗忘。这是我从持续学习研究里借来的思路，实测效果稳定。

5.5 功能安全相关的“经典”答疑

这部分我把评审和客户咨询的高频问题整理成速查表，方便直接参考：

这些回答不能说是绝对“安全”的，但它能帮助项目在验收阶段不被卡住，也能清楚界定风险责任边界。说实话，这是工程现实，每个做AI安全项目的人都得面对。

6. 项目复盘与个人体会

做这个项目，我最有感触的一句话是：AI图像识别只是这套系统拼图的一部分，真正决定系统能不能落地、能不能通过验收的，是功能安全意识和工程化能力。

我踩过最大的坑，是把AI识别当成技术核心来打磨，花了很多时间调模型提升指标，结果到了现场发现接口协议没对好、供电不稳、网络丢包、标准文档缺失，暴露出大量工程问题。后来重新梳理了体系，把功能安全文档、接口设计、现场部署规范放到和算法同等的优先级，项目推进才恢复正常。

如果你要复现这个项目，我建议你从最朴素的场景做起：选一台扶梯，只做“盖板打开检测”和“乘客摔倒报警”两个功能，先跑通“相机-边缘盒子-中控提示”这条链路，再逐步叠加降速联动、多扶梯集中管理、模型远程更新。一次做太多功能，很容易被误报率和故障排查淹没。

最后再分享一个小技巧：给系统做界面时，不要把AI识别结果直接堆给用户。值班员不关心置信度是多少、检测框大小，他们只想要一个清晰的结论——这台扶梯状态是否正常、是否需要处理。我最终做成了一个三色状态界面：绿色正常，黄色提示，红色告警并附一张现场截图。这个设计比任何花哨的AI可视化都管用，维保人员用了几天就完全接受了系统。技术的价值，不在于你用了多高深的模型，而在于它能不能真正帮到人。