去年接了一个预测性维护项目。五个月开发，验收通过，尾款结清。三个月后系统停用。
记录一下原因。
客户是精密零件加工厂，年营收约两亿。需求是设备故障预测，减少计划外停机。
合同金额 80 万，周期五个月。交付标准是：预测准确率 85% 以上，提前预警时间 2 小时。
团队配置：两名算法，两名后端，一名前端，我负责架构。
前两个月数据采集，在 47 台关键设备上安装振动和温度传感器，采样频率 1kHz。
第三个月标注数据。与设备主管一起回顾了过去两年的故障记录，共 23 次，作为正样本。
第四个月训练模型。用 LSTM，准确率 92%，满足要求。
第五个月开发前端和告警系统。大屏展示设备健康度，微信推送异常通知。
验收时，客户技术负责人确认指标达标，签字。
系统上线后，发现几个问题：
预警时效不足
模型提前 2 小时预警，但工厂维修排班需要提前 1-2 天协调人员和备件。2 小时不足以安排维修，预警失去操作价值。
用户不用
车间操作员平均年龄 48 岁，习惯通过设备声音和手感判断状态。大屏上的 ” 健康度 87%” 对他们没有明确指导意义。微信告警被多数用户关闭，原因是 ” 太频繁，不知道怎么处理 ”。
ROI 为负
系统年运维成本约 8 万，加上模型迭代和人员培训，总持有成本较高。按实际避免的停机损失计算，回本周期超过 4 年，客户决策层失去推广动力。
需求验证不足
“ 预测故障 ” 被当作明确需求，但未验证 ” 提前多久 ” 才具备操作价值。2 小时是技术实现的结果，不是业务需求推导的结果。
用户研究缺失
系统设计基于技术视角，未考虑一线操作员的使用习惯和认知水平。大屏可视化对管理层有展示价值，对操作层无实用价值。
MVP 范围过大
直接部署 47 台设备，全量上线。如果先选 3-5 台设备试运行一个月，上述问题可以更早暴露，成本更低。
技术验收通过 ≠ 产品可用 ≠ 商业成功。
这个项目的技术方案没有明显缺陷，但技术方案解决的是错误的问题。
记录于 2024 年 3 月
关于作者： 做 AIoT 技术咨询，主要工作是帮企业避开我踩过的坑。如果你正在规划类似项目，欢迎聊聊——有些坑，你不用自己踩。