凌晨两点半，我手机在床头柜上疯狂震动。打开一看，厂区运维群炸了锅——三号线的空压机毫无征兆地停了，整条产线停摆，全厂紧急调度。那会儿我刚做完设备预测性维护的项目复盘，手机里还存着那台空压机过去两年的维修记录。说“毫无征兆”其实不准确，数据里早就写了答案，只是没人去读它。

那次停机让我真正开始琢磨一件事：工厂关键设备的维修记录，能不能不只是“坏了以后才写”的流水账？AI能不能从这些记录里，提前几天甚至几周把“要出事”的信号挖出来？这个念头后来变成了一个完整的落地项目。这篇文章我把整个思路、操作链路和踩过的坑都拆开讲清楚，给正在折腾设备智能维护、却又不知道怎么下手的朋友做个参考。

维修工单、保养记录、故障备注这些数据，大多数工厂都有，但基本都躺在EAM系统或Excel里吃灰。我做的这事，说白了就是把这些“死数据”变成“活信号”，让AI替老师傅盯住几十上百台设备的“身体状况”。它的核心价值不是炫技，而是把传统的“坏了再修”变成“坏了之前就提醒”，少一次非计划停机，省下的可能是几十万的产能损失。

文章适合三类人看：一类是工厂设备/IT部门的负责人，想给预测性维护找个轻量级切入点；一类是算法工程师，正愁工业场景落地没抓手；还有一类是一线维修老师傅、车间主任这类懂设备但不懂AI的人，看完你能明白AI到底在帮你看什么、它会怎么帮你看。

1. 从“坏了再修”到“提前发现”：拆解这件事的底层逻辑

1.1 维修记录不是废纸，它是设备写给人类的“病历”

很多人一听“用维修记录做预测”，第一反应是：维修记录都是故障之后才写的，人都坏了才修，怎么预测？这个理解有个漏洞——一台设备的重大故障，从来不是凭空跳出来的。电机不是突然烧的，轴承不是突然碎的，在“到寿”之前，它一定经历过若干次小毛病、小维修、参数偏移。

维修记录这东西，本质上是设备的一本病历。你回忆一下自己看病的情形：医生不是只看你今天哪里疼，还要翻你过去五年的病历，看你是不是老犯同一个部位的毛病、有没有慢性基础病、上次用药效果如何，然后才判断这次是不是大问题前兆。设备的维修记录也是同样的道理。

我见过一台注塑机，三个月内因为“液压油温度偏高”换了两次冷却器密封圈，每次都是小几百块的配件、半小时的工时，维修单上写的都是“例行维护”。但从数据角度看，这已经是一个强烈的信号：冷却系统在持续劣化。果然，第四次的时候，液压泵因为过热直接报废，那一停就是十几个小时。

所以我把维修记录当成“病历档案”而不是“事后流水账”。每一次小修，都是设备器官在发警报；每一条“暂无异常”的回访记录，都可能是病情缓解或恶化的拐点。AI要做的，不是直接预测哪一天坏，而是从这些零碎的互相关联的记录里，找出“这套组合拳以前出现过，接下来大概率是场大病”的规律。

1.2 为什么靠老师傅的经验看不过来，而AI能从中发现规律

有人会说：这些规律老师傅也知道啊，为什么非要AI？

我承认，最了解设备的一定是干了二十年维修的老班长。你问他三号空压机什么脾气，他能跟你聊半小时不带重样的。但现实是，一个中等规模工厂，动辄几百台设备，老师傅只有几个人。他不可能同时盯住每台设备的每一条维修记录、每一次参数变化。人脑擅长的是深度理解单一事件，不擅长对一堆相似又不同的事件做全局统计。

AI擅长的是另一件事：把一万条记录里反复出现的“前兆组合模式”找出来，并且不受疲劳、情绪、轮班影响，持续地、端到端地盯着。工业界的经验数据告诉我，老师傅能凭直觉预判的设备故障率大约是同类故障的30%到40%，而且他们只会盯自己熟悉的重点设备；而一个训练好的模型，只要数据质量到位，可以把这部分覆盖率提到70%以上。

这里多说一句：不要把AI理解成“机器版老师傅”。它更像一个永不疲倦的统计员，能帮你把“老师傅注意力没覆盖到的角落”也检查一遍。真正聪明的落地方式，不是让AI替代老师傅，而是让AI把可疑对象圈出来，请老师傅去复查。人机配合，而不是人机对立。

1.3 不是所有设备都适合做维修记录预测，先想清楚边界

再讲讲边界，免得有人拿着这篇文章回去盲目照搬，最后效果不好回来骂我。

维修记录驱动的预测，适合两类设备：第一类是“坏一次代价极高”的关键设备，比如空压机、冷水机组、注塑机、成型机，停机一小时就是几万块；第二类是“有历史维修数据积累”的设备，至少得有一年以上、几十条以上的有效维修记录。对那些便宜、坏了直接换新的设备，做这个没意义，预警省下的钱还不够模型折腾的。

不适合的场景也有：完全没有历史记录、设备刚上新的；维修记录基本都是乱填的（这个坑后面细说）；或者设备故障本身就是随机性的、跟磨损无关的。遇到这三种情况，劝你先别上AI，先把数据规范和采集做好了再说。这个判断要是不做，后面项目大概率烂尾。

2. 数据基础：把维修记录从“流水账”变成AI能吃的“特征矩阵”

2.1 先盘点手里的原材料：维修工单里到底有哪些字段

动手写代码之前，我习惯先拉出一张表，把过去两三年的维修记录整理成统一的格式。一般来说，一份成熟的维修工单至少包含下面这些字段：

别急着直接拿这堆原始字段去跑模型。特征工程的价值，就是把这种非结构化的、事件型的记录，转化成“以设备为中心、以时间窗口为刻度”的统计指标。这也是我踩过最深的坑，前两次项目挂在了一个地方：直接把原始工单丢给模型，模型根本学不出来。

2.2 三道常规工序，把废料变成半成品

我把整个转化过程分成三步，每一步都有讲究。

第一步是数据清洗。这一步决定成败，也是大家最容易偷懒的环节。维修记录最大的毛病是“多人填写、风格混乱”：同一台设备，张三写的故障现象是“电机异常响”，李四写的是“RUN时有异响”，王五干脆只写个“保养”。不做清洗直接挖掘，关键词统计就是一场灾难。我在这一步花了整个项目大约四成的时间，真不夸张。

具体做法是，先把文本统一小写，把同义词合并掉（异响/噪音/响动/有异常声统统归到一个词族里），再把明显填错的记录剔除（比如维修时间早于报修时间、设备编号不存在、同一设备同一分钟出现几十条重复记录）。清洗完的数据集，是后面一切工作的地基。

第二步是数据聚合。以每台设备为分析单位，按时间窗口做聚合统计，把“事件流”变成“指标序列”。最简单的窗口是30天、60天、90天滚动。我实际用下来，30天窗口最灵敏，90天窗口最平稳，两者结合使用效果最好。后面我会给一个具体的特征清单。

第三步是数据标注。说白了，就是给每一段历史数据打标签：这段时间的设备状态，到底是“健康”还是“即将故障”。我的做法是，把设备实际停机前24小时或者72小时设定为“正样本窗口”，窗口内的记录标注成“异常前兆期”，其余标注为“正常运行期”。这是监督学习路线的做法；如果走异常检测路线，标注可以省掉一半，后面会讲。

2.3 特征工程里的隐藏门道：时间窗口、设备分组、文本向量

特征工程这一步，模型效果好坏七八成从这里决定。我分享一套自己打磨过、后来复制到好几家工厂都能用的特征配方。

第一类是频次与间隔特征。统计每台设备在滚动窗口内的维修次数、平均维修间隔、距离上一次维修的天数。设备突然从“半年不坏”变成“一个月修三次”，这个信号比什么模型参数都灵敏。

第二类是停机时间特征。窗口内累计停机时长、最长一次停机时长、平均每次修复耗时。停机时间越来越长，通常意味着故障在变严重、维修难度在加大，这是非常强的劣化前兆。

第三类是备件消耗特征。窗口内换过的轴承数、密封圈数、过滤器数。备件消耗速度等于设备磨损速度，这条是我后面几期项目的核心特征。一台泵一年换两次机械密封是正常的，一个月换三次就不对劲了。

第四类是文本特征。对故障描述做关键词抽取和频次统计。重点不是看单个词，而是看“痛苦词汇”的密度：渗油、异响、过热、跳闸、抖动，这些词在窗口内出现的频次一旦抬头，基本可以认定设备在往坑里走。

我给个参考代码片段，是用Python做30天滚动聚合的思路，实际项目里可以按设备ID和时间分片跑：

import pandas as pd def build_features(df, window_days=30): # df: 已经清洗过的维修工单，包含device_id、report_time、downtime_hours、parts_count、fault_text df = df.sort_values(['device_id', 'report_time']) features = [] for device_id, group in df.groupby('device_id'): group = group.set_index('report_time') roll = group.rolling(f'{window_days}D', min_periods=1) feat = pd.DataFrame({ 'repair_count': roll['repair_id'].count(), 'total_downtime': roll['downtime_hours'].sum(), 'avg_downtime': roll['downtime_hours'].mean(), 'parts_consumed': roll['parts_count'].sum(), 'abnormal_text_count': roll['fault_text'].apply( lambda x: sum(1 for w in x if '异响' in str(w) or '渗油' in str(w) or '过热' in str(w)) ) }) feat['device_id'] = device_id feat['days_since_last_repair'] = (group.index - group.index.max()).days features.append(feat) return pd.concat(features)

这段代码的思想就是：对每台设备的维修记录流，按30天滑动窗口滚出统计指标，最终形成“某个时间点该设备的健康状况快照”。模型训练用的就是这种以“设备-时间”为主键的快照表。

3. 模型选型与实操：不追新，只求稳

3.1 先用规则建一条“红外线”，再考虑上不上模型

直接上深度学习，是我见过工业AI落地最常见的翻车姿势。原因是工业场景的数据量通常很小，一台设备的有效维修记录一年能有一百条算不错了，这点样本撑不起复杂模型。

我的习惯是分两步走。第一步，先用领域规则搭一条“红外线报警器”——把上一步算出来的特征，和同类型设备的正常基线对比。比如发现某台设备30天内的维修频率超过了同类设备90分位、或者连续两次停机时间的间隔缩短超过30%，立刻先拉黄牌。这套规则哪怕不用机器学习，已经能捕捉到大量前兆信号，而且解释性极强，车间主任和维修师傅都愿意信。

第二步才是机器学习建模。为什么规则够用还要上模型？因为规则是我这个领域的人总结的，有盲区；模型能从更多特征的组合里发现人没注意到的相关性。规则是底线，模型是补充。工业场景，别一上来就追求SOTA，先确保底线稳定。

3.2 两种建模路线怎么选：分类式预警 vs 异常检测

基于维修记录做预测，建模路线有两种主流的，我把它们放在一起对比一下。

第一种是监督分类，把问题定义为“未来72小时内会不会发生故障停机”的二分类任务。特征用前面构建的窗口指标，标签用停机事件作指引。优势是结果容易解释，“预警概率85%”可以直接推给业务部门；劣势是需要人工标注历史样本，而且样本不平衡问题严重，故障事件太少了。

第二种是异常检测，不区分“健康”和“故障”，而是学“正常状态长什么样”，然后把偏离正常状态的时刻标出来。工业数据里故障永远是少数派，异常检测天然适合这种场景。常用算法有孤立森林、自编码器、One-Class SVM，我用的较多的是孤立森林，因为实现简单、对高维特征不敏感、跑起来也快。

如果数据标注条件好、样本量足够，我推荐以分类为主、异常检测为辅的混合路线：模型预测概率算一级，异常偏离算一级，两者同时拉响再升级为红色预警。这个方案的逻辑是：不同源头的信号同时报警，比单一源头更可靠，误报会明显减少。

3.3 阈值怎么定：别迷信默认值，回归业务去校准

模型跑出来之后，会输出一个连续的异常分数或概率，接下来要决定的是：分数多高算警告、多高算危险。这一步是工业场景和比赛场景最大的分水岭，比赛看AUC，工厂看“误报率和漏报率的真实代价”。

我常用的校准方法是画一条业务权衡线。打比方，红色预警每误报一次，维修师傅白跑一趟，心情变差，以后就不信这个系统了——这个代价其实挺贵的。黄色预警误报一次，成本低，最多是让计划员多看一眼。所以我一般把阈值定成“宁可多给黄牌，少给红牌”。具体操作上，先把训练集里模型分数的分位数算出来，比如把90分位作为黄牌线、99分位作为红牌线，再拿最近三个月的真实工单回测，看每一档预警对应的真实停机概率，根据结果微调线。这一步没有标准答案，完全看你的工厂对“空跑的容忍度”和“漏报的容忍度”之间的博弈。

我实操下来的一个心得是：阈值不能设完就固定。工厂有淡旺季、设备有新旧更替、天气有冷热变化，阈值至少每个季度重新校准一次。否则夏天一到，空调负荷猛增，一大半设备分数集体上扬，系统天天喊狼来了，最后没人理。

4. 案例回放：一台注塑机“突然”停机的前7天，AI到底看到了什么

4.1 项目背景：两班倒的注塑车间，一台关键机台老是闹脾气

我之前做过一个项目，对象是一个有四十多台注塑机的车间，核心机台编号INI-12。这台机过去8个月的维修记录被我从EAM系统里拉出来，一共是46条工单，看起来不多，但足够支撑一个实证。

它的故障史分两个阶段。第一阶段是小毛病期：液压油管接头渗油、冷却水温偏高、偶尔出现一次“模温不稳”的报警。第二阶段是恶化期：高温型号的密封圈更换频次从一季度一次飙升到一个月三次，还伴随两次短停。到了第八个月，终于来了一次大故障——液压系统核心组件损坏，整机停机28小时，车间产出直接掉了一截。

我拿这个案例做回测时问了一个问题：如果模型提前部署，能不能在第8个月的大故障之前给出有效预警？

4.2 数据回放：特征曲线在“事发前7天”已经向上拐

我把INI-12前8个月的维修数据喂给特征工程流水线，生成了逐日的滚动特征曲线。看结果的那一刻，说实话我后背有点发凉——模型在大故障发生前第7天，异常分数已经越过了黄色警戒线；第3天，越过了红色警戒线。

导致模型拉响警报的核心特征组合有几个：30天滚动维修次数从2次递增到5次；备件消耗量比同类型其他设备高出180%；故障描述文本里“高温”“渗油”“异响”三个关键词密度明显抬升。单独看任何一条都不至于触发停产，但组合在一起，就是教科书级的“劣化前兆”。

这里要强调一个关键点：维修记录驱动预测的提前量，不是模型“猜出来”的，而是师傅们一次次小修过程中“写下来”的。设备并不是突然坏的，它给了大家很多次机会，只是这些机会散落在几十条没人串联的工单里。

4.3 结果验证：提前预警一次的价值，远超模型的训练成本

我们在这个案例上做了更严格的时间序列回测：把数据按时间切成训练集和验证集，只允许模型用过去的信息预测未来，避免“偷看”未来数据。回测结果显示，模型能提前72小时捕获故障前兆的准确率约在75%到82%之间，误报率控制在20%左右，对于一个以维修记录为主要信号源的方案来说，这个水平已经具备实用价值。

更重要的是算一笔经济账。那次28小时停机，损失的产值保守估计在20万以上，还不算维修加班费和后续的交期赔付。而我在这个项目上从数据清洗到模型上线，前后折腾了大约三周，折算的人力成本不到那次停机损失的十分之一。这个账算清楚，决策者没有理由不上这一层防护。

5. 落地路上的坑，我替你先踩一遍

5.1 数据质量的三种常见病：脏、缺、乱

先说最让人头疼的数据问题。有些厂里的维修工单是完全纸质的，师傅修完设备手写两行字，月底才由文员录入Excel。这种记录往往字段缺失、时间不准、设备编号靠猜，直接拿来做分析等于在垃圾堆里淘金。我的建议是前期别追求完美数据，先做一轮“能用的部分”，同时把电子化工单流程推起来，数据质量会随着时间自然改善。

第二种病是设备编号不规范。同一个机台，在EAM里叫“INI-12”，在备件系统里叫“注塑12号机”，在维修师傅嘴里叫“三区那台红色的”，三个系统对不上号。不搞定这个，特征聚合会直接散架。我一般会先花半天拉齐设备台账，建一张一对一映射表，这是不可跳过的基础工作。

第三种病是维修措施描述太简略，只有“换了配件”四个字，没说换的是什么、换了几个。遇到这种数据，备件消耗特征就废了一半。补救办法是去仓库领料记录里交叉核对备件出库数据，哪怕工单写得简单，备件编码和数量也能补上很大一块信息量。

5.2 误报太多怎么办：先别急着调模型，先调业务流程

误报率太高，是预测性维护项目被一线人员抵制的最主要原因。模型每天叫十分钟，维修工跑过去一看设备正常运行，三天之后就把预警系统当空气了。怎么办？我的经验是分两层处理。

模型层面，检查是不是特征里混进了季节性因素。我之前就经历过一次，入夏后车间温湿度整体抬高，所有设备的“温度相关异常词”频率同步上涨，模型把全车间将近四分之一的设备都拉进了黄色预警。排查后发现是外部环境因素的“共因”干扰，把外部温湿度作为上下文变量加入模型，误报立刻降了一半。

业务层面，预警不一定都要“立刻派人去现场”。我把预警分级处理：黄色预警只推送给班组长，在交接班时多看一眼；红色预警才推到维修主管，要求4小时内到场确认。这样把空跑成本降下来，一线人员对系统的信任度自然就上来了。误报不可怕，可怕的是所有预警都按同一优先级去惊动所有人。

5.3 一线维修工不买账怎么办：预警要设计成“帮手”，不是“挑刺”

技术落地的最后一公里，永远是“人”的问题。维修师傅看到系统弹出“该设备存在故障风险”的提示，第一反应往往是：我干了十几年，还用你告诉我？这是非常正常的防御心理。

我在操作中会做两件事降低阻力。第一，预警消息里永远附上依据：模型是看到了哪几条维修记录、哪个指标异常，才给出这个判断。比如“过去30天维修3次，其中2次为渗油类故障，备件消耗环比上升120%”。先给证据，再给结论。第二，把现场确认的结果纳入模型反馈：师傅确认了是虚惊一场，这条样本会被记录成“误报”；师傅确认确实有隐患、提前处理了，这条样本会成为模型优化的重要素材。让一线师傅感觉到系统在跟自己配合，而不是在监视自己，项目才能良性滚动。

5.4 模型预测的样本量太小时，怎么保证效果可信

团队里总有懂行的会问：“你这模型就几百条样本，靠谱吗？”这个问题很关键，我的应对方式有三个。

第一个是用时间序列回测代替随机切分。随机抽样的交叉验证会无意中泄露未来信息，工业数据必须按时间顺序切训练集和验证集，用过去预测未来才是真实场景。第二个是对多台同类型设备进行迁移验证——在A设备的规律上训练，在B设备上测试，看泛化能力如何。如果A设备学到的东西放到B设备上也成立，说服力翻倍。第三个是持续学习，模型上线后每积累一个月的新工单，就自动增量训练一次。随着数据变多，置信区间逐步收紧，“样本太少”这个问题会随着时间自然消解。

6. 补充一点：大模型和AI Agent在这件事里到底是什么角色

这两年大模型火得一塌糊涂，不少老板会问：“既然AI这么强，是不是用ChatGPT直接读维修记录就行了？”我也试过，这里分享一点个人观察。

大模型确实在“理解维修文本”上表现很好。过去我们做关键词提取要靠人工维护同义词表，现在可以直接用大模型做故障描述的语义归类，“机器有异响”和“RUN时有噪音”“运转声音变大”它都能归到同一个语义簇下，这一块效率提升是很明显的。

但大模型不适合直接做预警判断。原因在于：预警讲究的是稳定的统计规律和可解释的证据链，而大模型的本质是概率化的语言生成，它的输出有随机性，给出同一个维修记录，你今天问它和明天问它，可能得到不同强度的结论。这种不稳定性在设备维修这个领域是不能接受的，解释不了“为什么报警”的模型，在现场根本立不住。

所以我的建议是分层使用：传统机器学习模型负责确定性计算，负责输出“是否预警”的结论；大模型负责语义理解和人机交互，负责把预警理由用师傅能看懂的话写出来；AI Agent负责自动派工单、追踪闭环、沉淀知识。各干各擅长的，不越位，也不互相替代。

7. 关于这件事，我最想对同行们说的一句实在话

我做了几期维修记录驱动的预测性维护项目，最大的体会是：这套东西真正的技术瓶颈不在模型，而在数据和对业务的理解。谁能把维修记录从“废纸”变成“数据资产”，谁能把预警阈值校准得贴合现场，谁的项目就能真正用起来。算法再漂亮，落不了地也是一堆代码而已。

最后分享一个小技巧：新项目启动后，我建议先从一台或一小批设备做起，用回测验证效果，跑通闭环后再扩大范围。不要贪多求全，一口气把全厂几百台设备全部接入。控制住首期的复杂度，把方案跑得让一线人员愿意用、让管理层看到实实在在减少的停机损失，后面的事情会顺利得多。