一、项目背景

我们这家工厂客户，每次出质量事故，根因分析靠老师傅开会拍脑袋，写出来的措辞含糊，比如操作不规范、设备老化，整改措施写了没人跟。结果同样的毛病三个月犯两次，质量总监复盘时拿不出结构化结论，整改闭环基本靠吼。我们翻过他们的整改记录，一条典型事故从发生到写报告平均两天，但整改任务真正关闭往往要两三周，而且半数以上没有验证就标记完成了。更离谱的是，同一台设备因为没闭环，连续三次被写成不同根因，老师傅自己也糊涂，到底是哪个环节的问题谁都说不清。

我们当时判断，问题不在没人分析，而在分析没有沉淀成可追踪的结构，改不改全凭自觉，复查有没有做全靠良心，这种靠人盯的模式在人员流动时必然崩。

二、落地场景

方案分五块。一是事故数据归集：把工艺参数、检验记录、设备日志、批次信息拉到一起。二是根因推理：模型基于这些数据推结构化因果，给出可能根因排序。三是整改任务生成：每条根因对应一条整改动作，自动派给责任人和时限。四是责任到人：任务进工单系统，谁接谁签。五是闭环跟踪与复盘：整改完成要上传证据，复查通过才算闭环，否则重新挂起。

三、关键技术挑战与解决思路

最磨人的是事故数据归集。工艺、检验、设备分属三套系统，字段口径不一，模型拿到的是一锅夹生饭。我们做了统一批次维度的时间线对齐，把同一批次在各系统的事件按时间戳串起来，才喂得进模型，这一步占了项目一半的力气，也是后面推理靠谱的前提。

另一个坎是根因推理的可信度。第一版模型直接给结论不解释，老师傅不买账，说你凭什么说是温控。后来改成输出证据链：哪条工艺参数偏离、偏离多少、对照标准哪条，推理才有说服力，老师傅才愿意照着改， adoption 一下子上来了，整改派单也不再被搁置。

还有闭环跟踪。整改派单容易石沉大海，我们让复查必须上传现场照片或检测报告，系统比对整改前后指标，不达标自动重挂，杜绝写了等于做了这种假闭环，质量总监第一次能在月底看到真实的闭环率。

还有一处关键，是根因推理的输入质量。模型再聪明，喂进去的是脏数据也推不对。我们花了很多功夫做时间线对齐，把工艺、检验、设备三套系统的同一批次事件按时间戳串起来，这一步占了项目一半力气，但值得。对齐做好后，推理的命中率明显提升，老师傅也开始信了。反过来，如果对齐偷懒，模型推出来的根因会和实际对不上，派单出去没人执行，闭环又断了。所以我们内部有个规矩，数据对齐没验证过，不准上推理，这条底线帮我们少走了很多弯路。现在质量总监每月复盘，直接看系统生成的结构化报告，哪类根因最多、哪条整改老不闭环，一目了然，开会不再靠翻聊天记录。

案例片段（已脱敏）： 事故根因推理与整改派单（逻辑片段）：timeline_align(batch_id) -> events[] root_cause = llm_rank(events, top_k=3, with_evidence=true) for rc in root_cause:    create_task(owner=rc.owner, due=+3d, evidence_required=true) close_task: verify(metrics_before != metrics_after)某批次不良率突增，模型定位到温控区间偏离 1.8 度并附曲线证据，派单给设备组，三天内校准后复测不良率回落，闭环留痕，而此前同类问题平均要开两次会才动得了。

案例片段（已脱敏）： 某产线连续三周出现同类外观缺陷，过去三次分别被归因为"操作不当""来料问题""灯光干扰"，互相对不上。接入时间线对齐后，模型把三周的批次日志拉通，发现三次都落在同一台设备的同一时段，根因是夹具磨损而非人为，派单给设备组更换夹具，之后四周再没复发，老师傅终于信服了这套方法。

四、效果数据

根因定位时效从原来的平均两天缩短到约四小时，同类事故复发率下降约六成。整改任务完成率从靠自觉的约 50% 提升到 90% 以上，且每项都有验证证据。复盘材料从零散会议纪要变成结构化报告，质量总监的月度汇报第一次有了可量化结论。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

质量事故最怕根因写不清、整改不跟，让模型把数据揉成带证据链的根因再派单到人，复发明显少。根因推理一定要给证据，不然老师傅不买账，这一步我们栽过，光给结论没人信。闭环跟踪必须验前后指标，写了等于做了是最常见的假闭环，系统卡住这一关才有意义。说到底，模型在这里是帮人把混乱变结构，真正的判断还是留在人手里，这个边界别越过，模型给的是线索不是判决。质量这事，人不是不想做好，是缺少把经验变成结构的工具，模型的价值恰恰在这里，把老师傅脑子里的东西落到系统里，复盘才不再靠拍脑袋。