AI Agent赋能电梯投影运维：从人工巡检到智能预测的十年实践

1. 十年电梯投影这门生意，到底在做什么

电梯投影广告机这个品类，外行听起来像是“在电梯里装个投影仪放广告”，但真正做过的人知道，它是一整套硬件、结构、光学、内容分发和运维体系的组合。我从2014年前后开始接触这个方向，那时候市场上做电梯广告的主流还是框架海报和液晶屏，投影方案算是偏门。为什么偏门？因为电梯井道环境太恶劣了——震动、粉尘、温湿度变化、供电不稳、检修停梯，任何一个环节出问题，设备就是黑屏一块，广告主直接扣款。

我们做的核心产品逻辑很简单：在电梯轿厢门上方或井道内壁安装一台短焦投影设备，向电梯门或轿厢内壁投射广告画面。乘客等电梯的十几秒里，视线自然落在门或内壁上，广告触达率比传统框架高出一截。但这个“简单”背后，藏着至少五个硬骨头：投影距离与画面尺寸的匹配、电梯运行时的震动抑制、无人值守的远程内容更新、设备状态的实时回传、广告播放数据的可信统计。

十年下来，我最大的感受是：这个行业的技术门槛不在“投影”本身，而在“稳定运行”和“规模化运维”。一台设备装上去容易，一百台设备分布在几十个小区、写字楼里，每天要保证按时开关机、内容不卡顿、故障能预警，这才是真正的考验。早期我们靠人工巡检，一个师傅一天跑三四个点，路上时间比干活时间还长。后来上了远程管理平台，能看在线状态和播放日志，但故障预判还是靠经验——比如某台设备连续三天温度偏高，大概率是散热风扇积灰了，得提前安排上门。

这个项目适合谁看？如果你是做智能硬件产品经理、广告设备运维负责人、或者正在考虑用AI改造传统业务的创业者，这里面的坑和思路应该对你有用。如果你只是好奇电梯投影怎么赚钱，我也能告诉你：单台设备的硬件成本在两千到四千之间，广告分成模式下一台设备月收入从几百到上千不等，关键看点位质量和广告主资源。但今天不展开商业模式，重点聊AI怎么把这个“苦活累活”变成“超级个体”能扛住的生意。

2. 为什么传统电梯投影运维必须引入AI

2.1 人工巡检的成本结构已经撑不住了

先算一笔账。假设你手上有200台设备，分布在一个二线城市的50个小区和30栋写字楼里。每台设备每月至少需要一次现场巡检，检查投影清晰度、散热口积灰、固定支架松动、供电线老化。一个运维师傅一天最多跑6个点，按22个工作日算，一个月能覆盖132台。200台就需要1.5个全职师傅，加上车辆、工具、保险，一个月人力成本至少1.2万。这还没算突发故障的应急上门——电梯停梯检修窗口往往只有半夜或凌晨，加班费另算。

更麻烦的是，巡检质量依赖师傅的责任心。我遇到过师傅到了现场拍张照就走，投影镜头上的灰根本没擦，结果画面模糊了半个月，广告主投诉到物业，差点丢点位。这种“人治”模式在设备数量超过50台之后就很难维持。

2.2 故障预判比故障维修值钱十倍

电梯投影设备最常见的故障排序是这样的：散热不良导致光机过热保护（占35%）、投影镜头积灰导致画面模糊（占25%）、固定支架松动导致画面偏移（占15%）、供电模块老化（占10%）、信号传输中断（占8%）、其他（占7%）。你会发现，前两项加起来占了60%，而这两项完全可以通过温度趋势监测和画面清晰度分析提前预警。

传统做法是等设备黑屏了才去修，这时候广告已经停播至少半天。如果能在温度连续三天高于阈值时自动派单，在画面清晰度评分连续下降时提醒清洁，故障率能降一半以上。这就是AI介入的第一个切入点：用传感器数据和时间序列分析做预测性维护。

2.3 内容分发的“千人千面”需要AI决策

早期我们给所有电梯投同一套广告，后来发现不同点位的受众差异巨大。高档写字楼的电梯里，早上8点到9点投咖啡和早餐广告转化率最高；住宅小区的电梯里，晚上6点到8点投生鲜电商和儿童教育广告效果更好。人工排期根本忙不过来，200台设备乘以每天16小时乘以不同时段，组合爆炸。

AI在这里的作用是基于历史播放数据和转化反馈，自动生成最优排期。比如某台设备在过去一个月里，周三晚上7点播放某品牌牛奶广告的扫码率是其他时段的3倍，系统就会自动把这个时段的权重调高。这不需要复杂的深度学习模型，一个带时间衰减的协同过滤算法就能跑出不错的效果。

3. AI破局的核心架构：从单点工具到Agent工作流

3.1 整体思路：把运维拆成“感知-决策-执行”三层

我最终落地的方案不是买一个现成的AI平台，而是自己搭了一套轻量级Agent工作流。为什么？因为市面上的通用AI运维工具要么太贵，要么不贴合电梯投影这个细分场景。比如某云厂商的预测性维护套件，按设备数收费，200台一年要好几万，而且传感器数据格式还得自己适配。

我的架构分三层：

• 感知层：每台设备上的温湿度传感器、电流传感器、加速度传感器，加上定时抓拍的投影画面截图，通过4G模块回传。数据频率不高，温度每5分钟一次，画面每2小时一张，一天下来单台设备的数据量不到5MB。
• 决策层：跑在一台云服务器上的Agent工作流。核心是一个规则引擎加一个轻量级时序模型。规则引擎处理明确阈值（比如温度>65度触发告警），时序模型处理趋势预测（比如按当前升温速率，预计8小时后触发保护）。
• 执行层：自动生成工单推送给运维师傅的微信，同时自动调整该设备的播放策略（比如降低亮度减少发热），严重时自动关机保护。

这套架构的关键在于决策层不依赖大模型。我试过用大模型做故障诊断，效果不稳定，而且每次调用都有延迟和成本。后来改成“小模型做预测，规则引擎做决策，大模型只负责生成工单描述和给运维师傅的排查建议”，整体响应时间从秒级降到毫秒级，成本几乎为零。

3.2 为什么选择Agent工作流而不是单体AI应用

这里要解释一个概念：AI Agent不是聊天机器人，而是一个能自主感知环境、做出决策并执行动作的系统。在电梯投影运维场景里，Agent的工作流是这样的：

1. 感知：温度传感器回传68度，超过65度阈值。
2. 决策：查询该设备过去24小时温度曲线，发现是持续上升趋势，不是瞬时波动。判断为散热不良，风险等级中。
3. 执行：自动将该设备亮度从100%降到70%，减少发热；同时生成工单“检查散热风扇和通风口”，推送给负责该片区的师傅。
4. 反馈：师傅完成后拍照上传，Agent验证照片中的散热口是否清洁，验证通过则关闭工单，否则重新派单。

这个流程里，只有第4步的“照片验证”用到了图像识别模型，其他都是规则和简单统计。但整体效果比人工巡检好得多——师傅不用自己判断该不该去，系统直接告诉他去哪、干什么、怎么干。

3.3 多AI协作：让不同模型干不同的事

我用了三个不同的AI能力，各司其职：

• 时序预测模型：用Prophet或轻量级LSTM，预测未来24小时温度趋势。训练数据就是每台设备过去30天的温度序列，不需要标注，完全无监督。
• 图像质量评分模型：用MobileNetV3做迁移学习，输入投影画面截图，输出清晰度评分（0-100）。训练数据是我人工标注的500张截图，清晰、轻微模糊、严重模糊三档。这个模型很小，推理一次不到50毫秒。
• 自然语言生成：用大模型生成工单描述和排查建议。比如输入“设备A-023，温度68度持续上升，画面清晰度评分72”，输出“该设备散热异常，建议检查风扇运转情况和通风口积灰，同时确认电梯井道温度是否过高”。这部分用API调用，一天几百次，成本可以忽略。

这三个模型通过一个简单的消息队列串联起来，任何一个环节出问题都不会影响其他环节。比如图像模型挂了，温度告警照常工作，只是画面质量检测暂停。

4. 实操落地：从零搭建AI运维工作流

4.1 硬件改造：加装传感器和4G回传模块

老设备改造是第一步。我们用的投影仪本身没有数据接口，所以外挂了一个STM32开发板，接温湿度传感器（DHT22，精度±0.5度）、电流传感器（ACS712）、加速度传感器（ADXL345）。STM32通过串口读取数据，再通过4G模块（Air724UG）发到云服务器。

这里有个坑：电梯井道里4G信号不稳定。我试过三家运营商的物联网卡，最后发现电信的信号在多数井道里最好，但地下室电梯还是会有盲区。解决方案是加一个本地缓存，信号恢复后补传。STM32的Flash存一周的数据没问题。

另一个坑是供电。电梯井道里取电不方便，我们最初从电梯照明电路取电，但电梯检修时照明会断电，导致设备重启。后来改成从电梯控制柜的220V常电取电，加一个隔离电源模块，稳定多了。电流传感器就是用来监测这个供电是否正常的。

4.2 数据管道：从设备到云端的完整链路

数据链路是这样的：

# 设备端伪代码 import time from sensors import read_temperature, read_current, read_acceleration from modem import send_data while True: data = { "device_id": "A-023", "timestamp": int(time.time()), "temperature": read_temperature(), "current": read_current(), "acceleration": read_acceleration() } send_data(data) # 通过4G发送 time.sleep(300) # 5分钟一次

云端用Python Flask接收数据，存到TimescaleDB（PostgreSQL的时序扩展）。为什么不用InfluxDB？因为TimescaleDB支持标准SQL，和现有业务数据库统一，运维成本低。

# 云端接收端伪代码 from flask import Flask, request import psycopg2 app = Flask(__name__) @app.route('/data', methods=['POST']) def receive_data(): data = request.json conn = psycopg2.connect("dbname=iot user=admin") cur = conn.cursor() cur.execute( "INSERT INTO sensor_data VALUES (%s, %s, %s, %s, %s)", (data['device_id'], data['timestamp'], data['temperature'], data['current'], data['acceleration']) ) conn.commit() return "OK"

4.3 预测模型训练：用30天数据跑出可用模型

温度预测模型我用了Facebook的Prophet，原因是它对缺失值和异常值不敏感，而且训练速度快。每台设备单独训练一个模型，30天数据大概5000个点，训练时间不到10秒。

from prophet import Prophet import pandas as pd # 读取某台设备过去30天温度数据 df = pd.read_sql("SELECT timestamp, temperature FROM sensor_data WHERE device_id='A-023' AND timestamp > NOW() - INTERVAL '30 days'", conn) df.columns = ['ds', 'y'] # 训练模型 model = Prophet(interval_width=0.95) model.fit(df) # 预测未来24小时 future = model.make_future_dataframe(periods=24, freq='H') forecast = model.predict(future) # 如果预测最高温超过70度，触发预警 max_temp = forecast['yhat'].max() if max_temp > 70: trigger_alert('A-023', max_temp)

实测下来，Prophet对电梯井道这种周期性明显的环境（白天电梯运行频繁，温度高；夜间停梯多，温度低）预测准确率不错，24小时预测误差在±2度以内。

4.4 图像质量评分：500张标注图搞定

图像模型我用了MobileNetV3 Small，因为要在云端CPU上跑，不能太重。训练数据是人工标注的500张投影画面截图，分三档：清晰（评分80-100）、轻微模糊（评分50-79）、严重模糊（评分0-49）。

import torch import torchvision.models as models import torchvision.transforms as transforms # 加载预训练模型 model = models.mobilenet_v3_small(pretrained=True) model.classifier[3] = torch.nn.Linear(1024, 3) # 三分类 # 训练过程省略，大概跑了20个epoch，准确率92% # 推理 transform = transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), ]) img = transform(Image.open('screenshot.jpg')).unsqueeze(0) output = model(img) score = torch.softmax(output, dim=1)

这个模型部署在云端，每2小时处理一次所有设备的截图。200台设备一天2400张图，CPU推理完全扛得住。

4.5 工单自动生成与闭环验证

当温度预测或图像评分触发阈值时，Agent自动生成工单。工单内容用大模型生成，提示词是这样的：

你是一个电梯投影设备运维专家。设备{device_id}出现以下异常： - 当前温度：{temp}度，预测未来24小时最高{max_temp}度 - 画面清晰度评分：{score}分 - 历史故障记录：{history} 请生成一段给运维师傅的排查建议，要求： 1. 用口语化中文，不要专业术语 2. 列出最可能的2-3个原因 3. 给出具体的检查步骤 4. 控制在100字以内

大模型返回的结果直接推送到师傅微信。师傅完成后拍照上传，图像模型再次评分，如果评分提升到80以上，工单自动关闭；否则重新派单并升级优先级。

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

5.1 温度传感器读数漂移怎么办

DHT22用久了会有读数漂移，特别是井道里粉尘大的环境。我遇到过一台设备温度读数连续一周都是42度，但实际用手持测温枪测是38度。解决方案是每季度用标准温度计校准一次，在软件里加一个偏移量。更省事的办法是用两个传感器取平均值，成本增加不到10块钱，但可靠性提升明显。

5.2 4G流量超了怎么控制

200台设备，每台每5分钟发一次数据，一次大概200字节，一天就是200×288×200=11.5MB。加上每天12张截图（每张50KB），一天600KB。合计一天约12MB，一个月360MB。我买的是1GB的物联网卡，本来够用，但有一次某台设备固件bug导致疯狂重传，一天跑了500MB。后来加了流量熔断机制：单台设备日流量超过50MB自动断网，等人工检查后再恢复。

5.3 图像模型误判怎么处理

投影画面有时候会被乘客挡住，或者电梯门反光，导致截图模糊，但设备本身没问题。这种误判大概占5%。我的处理方式是连续两次评分低于阈值才触发工单，单次低分只记录不派单。另外，如果同一台设备在一天内多次误判，系统会自动降低该设备的图像评分权重，避免频繁误报。

5.4 师傅不配合怎么办

这是最头疼的问题。老师傅习惯了“我说了算”，突然被系统派单，会有抵触情绪。我的做法是把工单和绩效挂钩，但初期给缓冲期。前三个月，系统派单只是建议，师傅可以拒绝，但拒绝要填原因。三个月后，系统派单必须执行，但完成质量高的师傅有额外奖金。同时，我把工单描述写得非常具体，师傅到了现场不用自己想，照着做就行，反而省事了。

5.5 常见问题速查表

6. 从单打独斗到AI超级个体的真实体会

6.1 我一个人管200台设备是怎么做到的

以前管200台设备需要1.5个全职运维，现在我自己一个人加一个兼职师傅就能搞定。兼职师傅只负责现场操作，所有判断和调度都由系统完成。我每天花在运维上的时间不超过1小时，主要是处理系统无法自动决策的异常情况，比如某个点位物业突然要求调整投影角度，或者广告主临时换素材。

这套系统最大的价值不是省了人力，而是把不可控的运维变成了可控的流程。以前师傅说“今天跑了5个点”，我不知道他到底干了什么。现在系统里每一台设备的温度曲线、画面评分、工单记录都清清楚楚，广告主问起来我能直接拉数据。

6.2 AI不是替代人，是让人做更值钱的事

我算过一笔账：AI系统开发花了大概两个月时间，加上服务器和API费用，一年成本不到5000块。但它让我从“每天接电话处理故障”变成了“每天看数据优化策略”。省下来的时间我用来谈新点位、维护广告主关系，这部分带来的收入增长远超5000块。

所以我的体会是：AI超级个体不是一个人干所有事，而是一个人用AI干以前一个团队干的事。你不需要会训练大模型，也不需要懂深度学习原理，只需要知道你的业务里哪些环节是重复的、可预测的、有数据积累的，然后找一个最轻量的AI工具把它自动化掉。

6.3 给想入局的人几个实在建议

第一，先从单点自动化开始。不要一上来就搞大平台，先解决一个最痛的问题。比如你手上只有20台设备，那就先做温度告警，用最简单的规则引擎，温度超过阈值发微信。跑通了再逐步加图像识别、预测模型。

第二，数据比算法重要。我见过很多人纠结用LSTM还是Transformer，但连30天的温度数据都没存下来。先把数据采起来、存下来，哪怕用Excel记，也比没有强。有了数据，最简单的算法也能出效果。

第三，别迷信大模型。大模型适合生成文本、做对话，但不适合做实时决策。温度预测用Prophet，图像分类用MobileNet，这些轻量级模型在细分场景里比大模型靠谱得多。大模型只用在工单描述生成这种“锦上添花”的环节。

第四，运维师傅的配合决定成败。系统再好，现场执行不到位也是白搭。我的经验是：工单要写得像“说明书”一样具体，师傅照着做就行；绩效要挂钩，但要有缓冲期；最重要的是，让师傅感受到系统是帮他省事的，不是来监督他的。

6.4 这个模式还能怎么扩展

我现在把这套逻辑复制到了另一个业务上：社区充电桩的运维。充电桩的故障模式和电梯投影很像——温度、电流、通信状态，加上一个摄像头看车位是否被占。同样的Agent工作流，改一下阈值和工单模板就能用。所以如果你在做的是分布式智能硬件运维，这套思路大概率能复用。

另外，广告播放数据的分析还可以更深。比如结合电梯的客流数据（通过摄像头或红外计数），分析不同时段、不同人群对广告的反应，自动调整播放策略。这部分我还在摸索，目前用的是简单的时段权重调整，效果已经比人工排期好不少。

最后分享一个小技巧：Agent的决策日志一定要存。每次系统自动做了什么决策，为什么做这个决策，都要记下来。一方面方便排查问题，另一方面，当你需要向广告主或物业解释“为什么这台设备今天亮度降低了”时，直接拉日志就行，比口头解释有说服力得多。