从0到1搭建预测性维护系统：完整踩坑记录

去年带团队做了一个预测性维护项目，从立项到上线花了 8 个月。记录完整的踩坑过程。

最初的设想

“ 用 AI 预测设备故障，提前维修，减少停机损失。”

听起来很美好。但具体怎么做，没人说得清。

踩坑一：没有量化目标

客户说 ” 减少停机 ”，但没有具体数字。是减少 50% 还是 5%？是预测所有故障还是关键故障？

结果：验收时双方标准不一致，扯皮 3 个月。

正确做法

立项时必须量化：

• 预测准确率目标：≥85%
• 提前预警时间：≥24 小时
• 覆盖设备范围：关键设备 100%
• 预期减少停机损失：具体金额

传感器部署

在 47 台设备上装了振动、温度传感器。采样频率 1kHz，一天产生 4TB 数据。

踩坑二：数据标注困难

需要标注 ” 正常 ” 和 ” 故障 ” 数据。但：

• 什么是 ” 正常 ”？不同工况差异大
• 故障数据少，过去一年只坏了 3 次
• 设备主管和算法工程师对 ” 故障 ” 定义不一致

结果：标注数据质量差，模型训练效果不理想。

正确做法

• 先定义清楚业务规则：正常 / 异常的判定标准
• 收集至少 6 个月数据再开始标注
• 设备主管和算法团队一起制定标注规范

最初的方案

用 LSTM 做时序预测，预测未来 7 天的设备状态。

踩坑三：模型和业务场景不匹配

LSTM 预测的是 ” 未来状态 ”，但维修需要 ” 具体故障类型 ” 和 ” 剩余寿命 ”。

结果：模型准确率 92%，但无法指导维修决策。

正确做法

• 明确模型输出要直接服务业务决策
• 预测故障类型，而不是状态评分
• 给出剩余寿命（RUL），而不是概率

需要对接的系统

• ERP：获取设备台账
• MES：获取生产计划
• 维修系统：创建维修工单
• 钉钉 / 企微：推送告警

踩坑四：接口文档不全

对方系统接口文档过时，实际接口和文档不一致。调试花了 2 个月。

正确做法

• 项目启动就做技术对接评估
• 要求对方提供真实接口文档
• POC 阶段就完成核心接口对接测试

系统功能

• 设备健康度评分
• 故障预警推送
• 维修建议

踩坑五：用户不会用

• 车间操作员看不懂 ” 健康度 87%”
• 维修工收到告警不知道优先级
• 管理层觉得系统没用

结果：系统上线 3 个月，实际使用率不到 10%。

正确做法

• 设计阶段就让一线用户参与
• 输出结果要 actionable：谁、什么时候、做什么
• 先做试点，验证价值再推广

总预算 ：100 万 / 6 个月
实际支出 ：180 万 / 8 个月

1. 需求必须量化 ：模糊的需求必然导致验收扯皮
2. 数据质量优先 ：没有好数据，再好的算法也没用
3. 模型要服务业务 ：准确率不等于有用
4. 集成要早验证 ：接口问题是项目延期的主要原因
5. 用户参与设计 ：系统再智能，用户不用等于零

预测性维护不是技术问题，是工程问题。

技术只占 30%，剩下 70% 是需求梳理、数据治理、系统集成、用户培训。

关于作者： 做 AIoT 技术咨询，帮企业避开预测性维护的坑。如果你正在规划类似项目，欢迎聊聊——有些坑，你不用自己踩。