维修群里有描述，工单里有时间，交接本上还有补充。同一次故障的信息散在几处，很难查清。用一个小工作流，让AI整理记录、标出冲突，再由设备负责人确认，不让它代下维修结论。

文｜最极客

这篇教程适合先从十几条维修记录试起。目标是把文字整理成能查到出处的台账，不是让AI诊断设备、替代维修人员，或者自动决定能不能开机。

需要的工具只有文本编辑器、一款组织允许使用的AI对话工具，以及现有的台账系统。可用DeepSeek网页对话处理脱敏文本；若公司要求内网处理，就使用批准的内部工具，不要为了方便把生产资料搬到公共服务。

整个流程都不连接机床、PLC或维修控制系统，也不改写现有工单。先产出一份待审核文本，确认后再由负责人归档。

第一步：按原文保留，而不是先改得好看

为每一段输入建立来源编号，如R001、R002。保留原始日期、设备编号、记录人和原文；缺失的信息直接写“未记录”，不要根据聊天顺序猜日期。

手机照片或扫描件需要先转成可读文字时，应由人对照原图检查数字和设备代码。尤其是字母O与数字0、小时与分钟、不同设备的相近编号，识别错了会污染后续整张台账。

同一个报警代码在不同设备上可能含义不同。整理阶段只保留原值，不让模型从网上找一个“最像”的解释填进去。

下面使用完全虚构的教学记录：R001写“10月15日09:10，设备A停机，屏幕显示E17，原因待查”；R002写“10月15日09:35，设备A恢复运行，原因尚未确认”；R003写“10月15日10:00交接，设备A刚才停了约20分钟”。

这三条材料没有给出维修操作，也没有确定根因。R001与R002的时间差是25分钟，而R003记的是“约20分钟”，两种口径应保留，不能让AI替你选一个。

第二步：规定字段，禁止补全原因

建议先设置这些字段：事件编号、设备编号、开始时间、恢复时间、观察到的现象、原文记录的处理、原因状态、原因原文、来源编号、冲突项、审核状态。

“现象”和“原因”必须分列。设备停机、界面出现代码，是记录的现象；“怀疑某部件异常”是待验证判断；“已确认原因”则应有相应记录和责任人。

可复制提示词：你是设备记录整理助手，不提供诊断或维修建议。只提取下方原文明确写出的信息。输出逐事件记录，字段为事件编号、设备编号、开始时间、恢复时间、现象、处理原文、原因状态、原因原文、来源编号、冲突项、审核状态。缺失项填“未记录”；推测不能改写为确认；每个事实附来源编号。不要生成开机、停机或维修指令。原文如下：【粘贴脱敏记录】。

一次先输入少量记录，人工确认模型是否遵守字段定义，再扩大批量。不要一开始把半年材料混在一起，让模型在很长的对话里自行决定哪些内容重要。

第三步：合并事件，保留不确定性

相同设备、相近时间，不一定就是同一次故障。一个班次可能有两次停机；一条交接消息也可能回顾前一天的事，因此事件合并需要证据。

可复制提示词：检查这些记录是否可能属于同一事件。只有设备一致、时间能够衔接且原文语义支持时，才提出合并建议。输出“候选记录、支持依据、反对或缺失证据、需人工确认的问题”。信息不足则保持分开，不依据常识填补时间线。

对教学示例，AI可以建议把三条记录交给负责人一起核对。但最终是否属于同一事件，仍由审核人确认，不应仅凭时间接近直接固化。

一个合适的示范结果是：设备A；开始09:10，来源R001；恢复09:35，来源R002；现象为停机并显示E17；原因未确认；原文另有“约20分钟”的交接记录，来源R003；审核状态为待核对。

如果需要停机时长，应另列“按时间戳计算的间隔”和“原文报告时长”。本例前者为25分钟，后者约20分钟；计算间隔不自动等于经确认的生产损失时间。

这里的输出是人工编写的教学示范，不是某家工厂的实际记录，也不是声称已运行某个模型得到的实测结果。实际使用时，请用自己的小样本验证能否稳定得到同样清楚的证据关系。

第四步：先查漏项，再谈规律

第二轮不要让AI继续美化语句，而要让它查错。原文里有、台账里没有的内容，以及台账里出现、原文却找不到的内容，都应列出来。

可复制提示词：逐条对照原文与整理结果。分别列出遗漏、无依据新增、时间冲突、设备混用、把推测写成结论的地方。指出对应来源编号与原句。不要自动修复不确定事实，先形成审核问题清单。

设备负责人解决问题后，再标记“已审核”，记录审核人和版本。未经确认的条目保留在待处理区，不要混进正式统计。

如果后续想找重复现象，可以先按设备和“已观察现象”分组，查看哪些描述多次出现。高频现象只能提示值得复查的方向，不能证明几个事件有相同根因。

这一步也别急着做“故障预测”。十几条零散文字并不能自动变成可靠的预测模型；运行时长、负荷、采集完整度等信息缺失时，简单比较条数很容易产生误解。

第五步：让同事能看懂，也能回查

最终交付两份内容就够：一份简洁台账，一份未解决问题清单。台账每行保留来源编号，原文另存，确保看到“原因未确认”时，能直接找回当时记录。

需要配图汇报时，可以画一张事件时间线，标明“原文时间”和“待核对口径”；不要用红色故障灯、损坏零件照片等视觉元素暗示尚未证实的原因。

归档前由人逐项确认：设备编号正确；日期完整；不同事件没有误合并；现象与原因分开；时间冲突仍可见；每条事实有出处；没有新增操作指令；审核人和版本已经登记。

成本、隐私与使用边界

这套方法最先节省的可能是查找和抄写工作，而不是维修工时。本文不承诺节省比例；试跑时记录资料准备、AI处理、人工复核的总时间，再与原流程比较。

网页额度、企业工具费用与API费用不同。若以后接入接口，按当日模型价格计算输入、输出及复核重试成本，并先限制批量规模；不要因为单次调用便宜就无限重跑。

上传前去掉客户订单、人员电话、供应商底价、网络地址和未获授权外传的图纸信息。外部维修手册也要检查使用权限，不将整本受限制资料上传后再要求AI复述。

对制造现场而言，可追溯比“看起来完整”更重要。AI可以把散落的信息摆整齐，但缺失的证据依然是缺失的证据；需要谁确认、依据什么确认，应当始终留在人负责的流程里。