干工控的兄弟都知道那个场景：产线停了，设备报警，屏幕上一串故障代码。你翻出手册，几百页PDF，找到对应的故障码解释，结果就一句话——”检查XXX”，然后呢？然后没有然后了。
我以前做设备维修的时候，最怕的就是这种”说了等于没说”的故障码。西门子V90驱动器报F7450，手册说”EPOS位置跟踪误差过大”——废话，我也知道位置跟丢了，问题是为什么跟丢了？
上个月我终于受不了了，花了三天时间，用AI大模型做了个故障码解析工具。说句实话，这玩意儿比我想象的管用多了。
这工具到底能干啥
不是啥高大上的东西，就是一个微信小程序加后台一个AI接口。
你输一个故障码进去，比如”F7450″，它不光告诉你”位置跟踪误差过大”，还会给出：
- 可能的原因列表（按概率排序）
- 每个原因的排查步骤
- 排查需要的工具
- 参考的波形或参数值
说白了就是把老师傅脑子里的”故障码→原因→排查步骤”这个链条数字化了。
怎么做出来的
第一步，得先把设备手册塞进AI能理解的形式。
我手里有西门子V90、G120、S7-1200、三菱FX5U、台达等十几个品牌设备的PDF手册，加起来上百本。直接喂给大模型是不现实的——token太多，而且手册里很多内容跟故障排查没关系。
我写了个Python脚本，把PDF转成文本，然后按照”故障码”这个关键词切分——每遇到一个故障码，就把它后面的描述、原因、处理措施截成一条记录。这样从上百本手册里抽出了大概3000多条”故障码→处理方案”的记录。
第二步，把结构化数据存到向量数据库。
每条记录用embedding模型转成向量，存进一个本地的ChromaDB。这样用户输入一个故障码，我先精确匹配到设备型号+故障码编号，然后把对应的维修记录向量化，再从库里搜最相似的几条历史案例。
第三步，用大模型做最后一步的推理。
如果库里有这个故障码的精确记录，直接返回。如果没有（比如有一些冷门设备的故障码），就靠大模型的推理能力——把设备型号、故障码、故障现象描述一起发给大模型，让它生成排查建议。
我用的是通义千问的API，主要是因为便宜，而且对中文工控术语的理解还算可以。实际用下来，对于常见故障码，”有用率”大概在80%左右。对于冷门故障码，大模型生成的建议有时会有点天马行空，得自己去判断。
一个真实的排查案例
两周前，我一个兄弟在现场处理一台V90伺服报F52980（编码器电压低）。他没带手册，用了我的工具。工具给出的建议是：
- 检查编码器电缆有没有破损（最常见原因，占70%以上）
- 检查编码器接头有没有进水或油污
- 用万用表测编码器供电电压（TTL编码器5V±5%，HTL编码器24V±10%）
- 如果以上都正常，可能是编码器本身老化，需要更换
他按顺序查：第一步，编码器电缆从伺服驱动器到电机这一段，外观看着没事；第二步，拔接头一看——全是油，编码器接头的针脚已经被油腐蚀了。换了根电缆加密封接头，故障解决。
整个过程大概20分钟。他说以前遇到这种情况，要么打电话问老工程师（不一定会接），要么回去拿手册（来回半小时），要么一个一个试（更久）。
说说这玩意儿的局限
说几个实实在在的问题。
手册质量参差不齐。 有些国产设备的手册写得真是一言难尽。故障码就一行中文，连排查建议都没有。这种情况下工具基本废了——库里的记录都是”故障码：XXX，原因：请咨询厂家”。只能靠大模型硬推理。
故障码不是万能的。 很多设备故障根本不会报故障码。比如机械卡死、传感器漂移、接线松动、通讯间歇性中断——这些故障现象表现为”产线偶尔停一下”、”速度上不去”、”精度变差”，没有具体码可以查。
不同批次设备的故障码可能不一样。 我发现同样型号的一个PLC，固件版本不同，故障码列表都不一样。有些旧的故障码在新版本里消失了，加了新的。手册更新跟不上。
我后面想接着做啥
现在这个工具只能查故障码。下一步我想把”故障现象→可能原因”也做进去。比如用户描述”电机嗡嗡响但不转”，工具能给出几种可能的原因并按概率排序。
再下一步，如果能拿到设备的历史故障数据，还可以做预测——统计某个型号的设备在运行多少小时之后容易出现某个故障码，提前预警。
当然，这些都是理想情况。目前就是个能用但不够好使的小工具。写到这儿，也想问问各位同行——你们现场维修最头疼的故障码是啥？我帮我兄弟收录进去。