1客户嘴上要的
「把这几年 9000 条维修工单和设备手册喂给大模型,做一个维修知识库,夜班机修能自己查。」
这是症状或现成方案,不一定是真问题。下面看两种做法。
2照字面做,会怎么烂
用大模型批量总结历史工单,生成 3000 条「故障码 → 处理方法」条目,做成查询页面。机修查了两次就不用了:一大半条目是「更换配件后恢复正常」,换的是哪个件、为什么判断是它,都没有;还有几条把当时的误判写成了原因。为什么烂:工单本身没有记下有用的东西,总结得再好也是空的。
3好 FDE 的实际走法
共 6 周,分 5 个阶段。带三角标记的是这一步最容易踩的坑。
第 1 周看工单是怎么写出来的
- 跟两个机修班组各跟一个班次,重点看修完之后发生什么。发现机修修完就去下一台,工单由班长在下班前凭记忆在 EAM 里批量关单;「处理描述」一栏 60% 写的是「已修复」「更换配件」。
- 原因在考核:设备科考「关单及时率」和「平均修复时间」,没有人考记录质量,写得越细越吃亏。
- 真问题不是「缺一个查询工具」,是「知识在修完的那一刻就丢了,考核还鼓励快关单」。成功标准改为:前 30 个故障代码的新工单里,「原因、处理、备件」三项完整并通过审核的比例,从 20% 提到 80%;夜班给白班打电话求助的次数作为结果指标。
- 踩坑别先拿历史工单做文章。历史数据质量差时,先改数据产生的环节。
第 2 周改记录环节和考核
- 和设备科长、车间主任定规则:工单要补全三项才算关单,关单及时率按补全时间算;补全记录由老师傅审核,审核通过的案例计入机修的技能等级评定。
- 老师傅担心经验被拿走后自己不值钱。车间主任把「审核和贡献案例」也算进老师傅的技能津贴,才推得动。
- 再请 3 个老师傅每人口述 2 小时,把前 30 个故障代码的排查顺序录下来,作为第一批种子知识。
- 踩坑别绕过车间主任直接找老师傅,会被认为在摸底裁人。
第 3–4 周原型:30 秒回填 + 追问
- 在班组手持终端上做回填:修完当场语音说一段,拍一张损坏件照片。大模型把语音整理成「原因、处理、备件」三项;说得太笼统时追问一句,例如「换的是哪个传感器?怎么判断是它坏的?」。
- 车间戴手套、噪声大,界面只有大按钮,不要求打字。
- evals:拿 100 条历史工单,50 条写得好、50 条写得空,请老师傅标注。标准:系统能识别出 90% 的空泛记录;对写得好的记录,三项整理结果和老师傅人工整理一致率 ≥ 90%。
第 5 周机修上手 + 开放查询
- 两个班组试用两周。审核通过的新案例和老师傅的种子知识进入查询,夜班按设备号和故障码查,每条显示是谁修的、谁审核的。
- 两周后让设备科长自己看数:三项完整率、审核积压量、夜班求助电话次数。
- 踩坑防爆区域或禁止带电子设备的工位不能用手持终端,要提前和安全员确认。
第 6 周交接交接
- 交给设备科的设备技术员:每周清审核积压,合并重复案例,删除错误做法;考核规则由设备科长维护。没有人审核,错误做法会被反复推荐。
4这个案例教给你的可复用判断
知识库的瓶颈常在知识产生的环节,先看记录是怎么写出来的。
历史数据是空的,总结出来也是空的。先改记录,再做查询。
考核决定记录质量,改工具要同时改考核和激励。
记录要在修完当下完成,30 秒以内,并且有人审核。
你手上也有类似的场景?
说说你所在的行业和想用 AI 做的事,留言会直接送达。觉得这个案例有误、过时,或有更好的做法,也欢迎指出。
制造的其他案例
内容更新:2026-11-11