电机异响已换。这是某电子组装厂上个月一条设备维修工单的全部正文六个字。设备主管老周把这张工单截图甩进管理层群时附的话是同一台贴片机三年里换了第八个同型号电机的轴承每次工单都这六个字谁看得出来根因到底在润滑、在装配还是在外围供电老周管着两条产线、四十多台关键设备。他不是没想办法。厂里上线的设备管理系统里历史维修工单累计有几千条可这些工单躺在数据库里除了月底统计工时和停机时长几乎从没被人认真读过。新来的工程师遇到同类故障还是得挨个去问老师傅因为翻几百条口语化工单找出有用的那条比直接问人慢得多。堆满简略记录的维修工单台账界面一、痛点背景历史工单成千上万却无人细读很多工厂的设备管理系统运行了三五年沉淀下来的维修工单少则几千条多则上万条参考量级视工厂规模、设备数量与系统使用年限而定。这些工单绝大部分只在月底被用来统计工时、核算停机损失或者应付体系审核。真正要从中挖出为什么这台设备总坏的人几乎没有。工程师接到新故障习惯动作是打电话问老师傅而不是去翻工单库。原因很现实翻几百条口语化、不规范工单找到有用的那一条耗时远超直接问人性价比太低。工单库因此沦为只写不读的黑箱。老师傅经验无法系统性沉淀设备维修高度依赖个人经验。同一台注塑机合模不到位A 师傅凭手感就知道是哥林柱受力不均B 师傅得拆半天。问题在于这些判断路径只存在于老师傅脑子里退休、调岗、离职之后就断了。工单上记的已处理恢复正常完全还原不出当时的思考过程。企业花几年培养了人却没把人的能力变成可检索、可复用的组织资产。人一走经验清零下一拨人从头踩坑。同类故障反复发生的隐性代价最贵的不是一次停机而是同一类故障反复发生却没人发现它们是同一类。某工厂的传送带变频器一年内报修十几次参考量级每次工单写的都是变频器故障已更换没人把十几次更换汇总起来看结果一直换配件、一直坏。这类问题的根因往往不在设备本身而在工况、保养节奏或上游供电。隐性代价体现在三方面重复采购备件、重复停机损失、工程师重复劳动。不靠系统汇总这类根因在人工习惯里几乎不可能被暴露。二、现象拆解工单数据与故障分析的典型表现工单描述一句话带过大量工单正文只有十来个字设备异响停机了已修复。没有故障发生时的工况、负载、环境温湿度没有前置异常。后续任何人看到这条工单都无法还原现场。这种记录对当时完成考核够用对事后分析几乎没有价值。大模型拿到这种文本能抽取的实体和信息极其有限根因分析就成了无米之炊。故障现象与原因混写新手常把现象和原因写在一起因为皮带打滑所以异响。但皮带打滑到底是现象还是原因他自己可能都没想清楚。大模型如果直接拿这种混写文本做根因抽取很容易把现象当原因、把推测当结论。必须在结构化阶段把观察到的现象和推断的原因拆成两个字段否则下游聚合会一路错下去。这是工单改造里最容易被忽略、却最关键的一步。同义异词造成检索割裂同一个故障不同人用词完全不同异响、异音、噪音、声音大、响动、杂音说的可能都是同一件事。还有卡料堵料卡阻不下料。标准全文检索按关键词匹配搜异响就漏掉异音。不先做同义词归一工单库里同类故障会被切成十几摊永远汇总不到一起。大模型做语义聚类能缓解一部分但仍需要一套统一的标准故障词作为锚点。维修动作缺失很多工单只写结论不写过程。已修复三个字省掉了拆检步骤、测量结果、替换测试。事后想复盘当时是怎么判断出是轴承问题的无从下手。缺失维修动作记录等于把最有价值的诊断推理过程丢掉了。大模型能从结果反推但反推的置信度远低于带着过程记录的工单。只记更换不记判断过程更换轴承一件更换密封圈两个配件清单很全但为什么换、依据什么数据换、换之前做了哪些测量一律没有。备件消耗数据很漂亮根因分析却断了线索。大模型能从更换反推可能原因但反推出来的置信度远低于带判断过程的记录。这类工单对库存管理有用对根因分析价值有限。跨设备同类故障无人汇总A 线贴片机和 C 线贴片机都报过吸嘴取料不稳工单分别挂在两条线、两个工程师名下。没有机制把跨线、跨设备的同类现象归并。结果同一设计缺陷或同一批次来料问题被当成两个孤立事件处理错过了从源头整改的机会。这类问题在单线视角下永远看不出规律。工单库只用于统计工时最普遍的现象工单系统的最大用途是月底出工时表和停机时长表。只要工时填了、停机时长填了工单就算合格。至于故障到底是什么、为什么发生系统既不强求、也不引导。这直接决定了工单内容天然偏向应付统计而非支撑分析。不改变这个第一用途后面再大模型的补丁也贴不牢。时间与环境上下文缺位工单普遍不记故障发生的时段、生产批次、环境温湿度、当前节拍。没有这些上下文故障现象就是孤立的无法和当时的工况建立关联。大模型即使识别出异响也无法判断它和某批次高负载生产是否相关。上下文缺位是工单从记录走向分析的最大拦路虎之一。三、根源分析挖到执行层面工单为考核而非分析而生根子上的设计目标就偏了。工单系统的第一使命是确保做了事能记录、能算工时、能划清责任不是帮工程师找根因。字段设计、填写规范、审核重点全部围绕考核。分析能力从一开始就不是系统的目标。这个底层定位不调整后面补再多大模型也救不回工单天生不是为分析设计的先天不足。填写动机天然不足写工单对维修工程师是额外负担不是本职工作带来的成就感来源。写得越细暴露的问题可能越多写得粗略反而省事。在没有正向激励的情况下理性人会选择少写。这不是态度问题是机制问题。不改变激励结构光靠开会要求认真填写没有用。得让写细这件事对填写者本人也有收益。缺乏统一的故障分类字典厂里很少有维护良好的故障分类字典比如按部件、故障模式、失效机理三级分类。每个人凭自己的习惯归类甚至不归类。没有字典工单之间就没有可比的共同语言。大模型也无法在统一口径下做聚合分析。字典不是文档是要有人持续维护、定期修订的活资产否则很快过时失真。缺少结构化字段自由文本工单最大的问题是不可计算。现象、原因、处置、备件、工况全挤在一段文字里。没有结构化字段任何自动化分析都要先做从自然语言里抠信息这一步成本高、准确率还低。结构化不是给大模型看的是给后续所有分析打地基。地基不牢上层智能就是空中楼阁。知识封存在个人脑子里前面提过老师傅的诊断路径在脑子里。更深层的原因是工厂没有把个人知识外化的流程和工具。复盘会开了但结论没进系统师傅带徒弟但经验没成文。组织记忆始终等于在场的那几个人。人一旦不在记忆归零。这是比单条工单质量差更根本的流失。没有闭环复盘机制修完即结束。没人定期把一段时间内的工单拉出来做趋势复盘、共性归因。即使偶尔有人想做也苦于工单质量差、工具缺失而放弃。没有复盘同类故障就没有被发现的制度性机会。复盘机制缺位是故障反复发生的制度根因。维修数据与工艺生产数据割裂设备为什么坏常常藏在工艺参数、生产节拍、来料批次里。但维修工单系统、MES 生产系统、质量系统往往是三张皮数据不互通。大模型只看工单文本看不到设备当时的真实工况数据根因判断就缺了一半证据。跨系统取数是工程也是组织协同问题。责任与激励错配谁发现系统性根因往往意味着暴露管理或设计问题反而可能惹麻烦。而快速换件让设备转起来才是被表扬的动作。这种错配让深挖根因在文化上不占优。技术工具解决不了文化问题但技术设计至少要不加剧它比如把发现根因纳入正向激励。四、大模型应用设计适用场景与不适用场景对照先说清楚大模型能帮上什么、帮不上什么。下表给出对照避免团队对能力产生不切实际的预期。维度适用场景建议用大模型不适用场景不要指望大模型文本理解从口语化、不规范的工单描述中抽取故障现象、可能原因、处置动作需要精确数值计算、公差配合、应力校核等硬工程计算同义词归一把异响、异音、噪音等归并为统一故障词统一检索口径需要确定唯一权威分类须由设备专家拍板的字典维护跨工单聚合汇总一段时间内同类现象输出共性趋势与高频部件替代现场点检、红外测温、振动分析等检测手段根因线索提示基于历史相似工单给工程师列出可疑原因清单与排查顺序直接给出 唯一正确根因 并自动派单维修新人辅助把老师傅式判断路径沉淀为可检索的问答知识处理涉密、未脱敏的工艺与配方数据复盘报告草稿自动生成阶段性故障复盘初稿供人修订作为责任认定、绩效考核的最终依据工单结构化字段与抽取要素设计把自由文本转成可计算字段是大模型在工单场景落地的核心动作。下表给出建议字段与抽取要素供字段改造参考。字段分组字段名抽取要素说明大模型作用设备信息设备编号、部件、位置从描述中识别具体设备与故障部位实体识别与归一故障现象现象描述、严重度、发生频率区分 观察到的现象 与 人的推测 现象与原因分离工况上下文负载、温湿度、节拍、批次抽取故障发生时的环境与生产条件上下文补全可能原因推测原因、置信度列出可能根因并标注强弱候选原因生成处置动作拆检、测量、替换、验证还原诊断与修复步骤过程还原备件消耗备件名、数量、批次关联备件与故障模式关联分析结论与验证是否解决、复发标记标记本次是否彻底解决闭环标记同义归一标准故障词映射到统一故障字典词典映射落地机制与提示词思路设计上建议采用抽取—聚合—建议三层机制。第一层用大模型做信息抽取把每条工单变成结构化记录第二层做横向聚合按标准故障词和时间窗汇总趋势第三层基于相似工单给工程师生成可疑根因清单与排查建议。大模型输出一律作为线索而非结论最终判断权留在工程师手里。提示词设计的核心是给它明确的角色、字段清单、输出格式以及证据不足就标注不确定的硬约束而不是让它自由发挥。五、能力边界与风险控制幻觉与误判风险大模型会一本正经地编出看似合理的根因。比如工单只写了异响它可能补出一段因轴承润滑不足导致滚道点蚀的详细推理听上去专业实则毫无依据。必须要求模型对每条推断标注置信度对证据不足的部分明确写无法判断并把所有输出默认视为待核实线索。置信度不是装饰是防止工程师被误导的护栏。不可解释与黑箱问题大模型给的根因线索往往说不清为什么这么认为。在工程场景不能解释的判断很难被工程师信任更难以作为整改依据。应对办法是把结论锚定到具体历史工单和相似案例上让每条建议都能回溯到原始证据而不是凭空出现。可解释性优先于看起来很准。数据保密与合规边界维修工单可能关联工艺参数、来料批次、甚至配方信息。把这类数据直接丢给公有云大模型存在泄密风险。落地时必须做数据分级敏感字段脱敏或本地化处理能本地部署的优先本地部署必须上云的走合规通道并签保密条款。保密红线不能因为模型方便而让步。责任归属与人工确认环节这是底线。大模型给出的是辅助线索不是维修指令。任何基于模型输出的处置动作都必须有具备资质的工程师确认并签字留痕。责任始终在人不在模型。系统界面上要强制设置人工确认节点跳过确认不能进入执行环节。这一步省不得也省不起。六、落地路径与常见坑三阶段落地路径第一阶段做工单结构化试点。选一条问题最突出的产线把历史工单用大模型做字段抽取先不追求全自动人工校正输出跑通字段与字典。第二阶段做聚合与共性挖掘。在结构化基础上按标准故障词汇总趋势输出高频故障与可疑根因清单供工程师复盘使用。第三阶段做闭环辅助。把模型建议嵌入日常维修流程作为工程师的排查助手但保留人工确认。三个阶段循序渐进别一上来就想全自动替代人。常见坑一指望模型直接给根因表现上线就要求系统自动定位根因并派单。结果模型乱给结论工程师不信任项目被判不准而黄掉。规避明确定位为线索助手所有输出标注置信度决策权留人。把期望值从替代判断降到辅助排查。常见坑二工单不改造直接喂模型表现拿着一堆已修复三字的工单让模型分析抽不出任何有效字段效果惨淡团队失去信心。规避先补结构化字段与填写规范哪怕先半人工也要让输入具备可抽取性。输入质量决定输出天花板。常见坑三忽略同义词归一表现检索异响找不到异音的工单同类故障被切散聚合结果严重失真趋势图全是噪声。规避先建标准故障词字典并做同义映射再谈聚合分析。归一这一步做不好后面全白费。常见坑四数据不脱敏直接上云表现为图省事把含工艺参数的工单整库上传公有云模型触发保密红线项目被合规叫停。规避上线前做数据分级与脱敏敏感字段本地处理或剔除必要时走本地部署方案。常见坑五没有人工确认就执行表现模型建议直接进入维修工单执行环节出错后无法追溯责任出问题互相推诿。规避强制人工确认节点确认人留痕责任清晰。把人确认做成流程里不可跳过的关卡。常见坑六一次性大跃进表现规划阶段就想覆盖全厂、全自动、实时分析资源摊太薄哪头都没做好半年没产出。规避单线试点、小步快跑用可见的小成果争取持续投入。先证明价值再谈扩展。七、验收标准准确性指标抽取字段的准确率要有可接受基线例如关键字段设备、部件、现象、可能原因的抽取准确率应达到可工程化使用的水平。具体阈值视工厂容忍度与人工校正成本而定参考量级建议先设内部目标再逐步抬高。模型给出的根因线索凡标高置信的经工程师复核的命中率要达到约定比例。准确率不达标宁可先半人工也别急着全自动。可用性指标系统产出的可疑根因清单、共性故障周报工程师实际打开率、引用率要可观测。如果生成了一大堆报告却没人看说明口径或呈现方式不对。建议把周报被引用次数线索被采纳次数作为核心可用性信号。被用起来才算真落地。业务价值指标最终看是否减少了同类故障复发、降低了重复备件消耗、缩短了新工程师上手时间。这类指标见效周期长但才是项目存在的理由。建议设对照试点线与非试点线在同类故障复发率上的差异。业务价值说话比准确率数字更有说服力。八、小结大模型该站在什么位置大模型在维修工单根因分析里最好的角色是不知道疲倦的线索整理员它把几千条口语化工单变成可比、可聚、可检索的结构化记录把散落在个人脑子里的经验外化成组织资产把跨设备的同类故障挑出来摆到桌面上。它做不到的是替工程师拍板、替现场做检测、替管理背责任。把辅助两个字刻在系统设计的最前面角色才不会跑偏。先补管理课再上模型车先结构化工单、再做聚合、最后才谈辅助决策这条路才走得通。技术能放大好的机制也能放大坏的机制。在工单这件事上先补管理的课再上模型的车。模型是放大器不是补课班。机制对了模型才有用武之地。本文为公开精简阅读版本。全套完整Word标准化资料包支持自助购买系统自动交付不含人工咨询答疑不提供工厂问题解答服务。入口见博主CSDN主页名片欢迎按需取用。更多工厂数字化与智能制造实战资料请访问官网www.yezhihui.cn