上周三的实训课，刚进门就看见第三组的俩男生蹲在实训台边上抠传感器接线，台面上摊了半拉从旧数控机床上拆下来的振动探头，旁边的笔记本上写得密密麻麻全是采样频率的参数。
我走过去瞟了一眼，问他们“你们这系统要抓的根因，是主轴过载跳停，还是传送带卡料堵转？”
俩人抬头愣了半天，说“老师，我们想把所有能测的都测上，总不会错吧？”
说实话我当时差点气笑。
之前的旧教案啊，写得那叫一个规整：第一步接传感器，第二步校准采样频率，第三步写阈值比对逻辑，第四步做可视化界面。结果上了两次课就发现，学生照着这个流程走出来的东西，全是中看不中用的花架子。我当着学生的面把那几页教案撕了——倒不是作秀，是真的觉得，之前那套按部就班的流程，根本教不会人怎么真的解决产线停机的问题。
别把“数据全采”当根因分析的万能解
之前几届学生做这个方向的设计，十个有八个上来就奔着“全量采集”去——温度、振动、电流、气压，恨不得把产线上每个螺栓的扭矩都给记上。真到要定位那台实训铣床为什么无预警停机的时候，翻出来三个月的采样数据，愣是找不出来哪组参数是触发跳停的直接变量。
根因分析的核心从来不是“采了多少数据”，而是“你提前预判了哪些故障模式会和采集的变量产生映射关系”。
之前有个学生组，花了俩礼拜接了12个传感器，最后系统提示“故障未知”，原因是他们压根没考虑到“气源压力低于阈值导致气动夹具松脱”这个最常见的停机原因——因为他们的传感器全装在主轴和传送带上，压根没接气路的压力变送器。
不过话说回来，学生一开始有“多采点总没错”的想法也正常——毕竟刚接触工业系统，谁都怕漏了哪个参数导致系统不准。但我每次都要敲着桌子提醒他们：你先把产线上过去半年的停机记录翻一遍，把出现频率最高的10个故障列出来，再对应着找需要测的变量。上来就堆传感器，纯纯是浪费时间。
对吧？你连最常发生的故障是什么都不知道，采再多数据也是白搭。
给学生搭的系统框架，得留“试错的冗余位”
最开始我给学生的系统模板，是固定的线性逻辑：传感器采集数据，传到处理器和预设阈值比对，匹配上了就输出对应的故障代码。
结果呢？只要遇到不在预设列表里的故障，系统直接卡死。
后来我把整个框架拆成了可插拔的组件化结构：最底层是原始数据的循环缓存池，存最近72小时的全量采样数据，不会因为系统断电就丢；中间层是完全开放的规则编辑区，学生可以自己往上加故障匹配的逻辑，想删想改全凭自己的判断；最上层是根因溯源的推演界面，系统会自动把和故障相关的历史数据拉出来，给做判断的人做参考。
改教案那会我熬到两点，就怕太灵活了学生摸不着北。
结果第一届试的那组学生，直接在中间层加了个“人工标注修正”的功能——就是系统判定错了故障原因的时候，操作工可以手动把正确的原因打上去，系统下次自动把这个特征匹配上。
真的很有用。
现在这组学生做的模块，已经被后面三个组拿去用了。毕竟真实生产里的故障，哪可能全是教材上写的那几种？留够试错的空间，系统才会越用越准，不是做出来就定型成个摆设。
别让学生对着仿真软件“闭门造车”
最开始实训课留的作业，有一半是让学生在仿真软件里搭系统模型。
直到有个学生在仿真里设振动阈值是5.3mm/s，结果到真实产线上一测，正常运行的时候振动就已经到6.2了——因为仿真模型里根本没算上产线旁边空压机开机带来的共振干扰。
我当时盯着那个数值看了半分钟。
现在每次课的前20分钟，我都不让学生开电脑，就带着他们围着实训产线走，摸每个部件运行时的温度，听每个电机的运行声音，记下来哪些干扰是真的存在的，哪些是仿真里压根没有的。
上周那俩蹲在台边抠传感器的男生，今天下课的时候过来找我，说他们把气路的压力变送器加上了，现在系统能准确识别出“气源压力不足导致夹具松脱”的故障了。
我瞟了一眼他们的记录，原来列了半页的故障可能，划掉了三分之二没用的传感器点位。
挺好。
