船舶柴油机是远洋船舶的动力心脏，而燃烧室部件就是这颗心脏里工作条件最苛刻、故障后果最严重的一组零件。搞可解释故障诊断这几年，我最大的感触是：活塞环磨损导致窜气、喷油器结焦导致雾化恶化、排气阀烧蚀导致密封失效、缸套拉缸导致整机停机——这些故障光靠“准确性高”的黑盒模型去报一个结论，轮机长是不敢信的。我之前在项目现场就遇到过这种事：AI 模型准确率已经做到 95% 以上，但船上的老轨追着问“你说喷油器堵了，依据是什么”，算法工程师只能指着混淆矩阵说模型学到的规律就是这样。这种场景经历多了之后，我意识到工业故障诊断真正缺的不是更高的准确率，而是让结论可追溯、可解释、可复核的能力。
可解释故障诊断，简单说就是在模型给出“哪个部件出问题、故障程度多大”结论的同时，还给出“为什么是这个结论”的依据——它用了哪些传感器信号、哪些特征贡献最大、这些特征符合不符合这台机器的实际工况。放到船舶柴油机燃烧室部件这个场景里，就特别有代表性：燃烧室内部没法直接安装传感器观察，只能靠缸压、振动、温度、转速等外部信号间接推理，正好是黑盒模型容易出错、现场工程师又不放心的典型环境。
这篇文章我会以船舶柴油机燃烧室部件为例，把可解释故障诊断从原理到实操完整拆一遍：燃烧室有哪些典型故障、传感器特征怎么设计、模型选谁、SHAP 解释怎么落地、上船部署会遇到什么问题。适合工业 AI、设备健康管理、PHM 方向的技术人员，也适合轮机工程背景想跨界做智能诊断的人。下面直接进入正题。
1. 为什么船舶柴油机诊断必须从“准”走向“可信”
1.1 黑盒模型的准确率陷阱
为什么我先说黑盒模型的局限？因为很多团队一开始都是把故障诊断当成“分类任务”来解：采集信号、打标签、跑一个 ResNet 或者 LSTM、把准确率刷到 95% 以上，就以为项目交付了。但工业诊断和学术比赛有一个本质区别：学术比赛看 top-1 准确率，现场看的是“误诊代价”。
我举个例子，燃烧室部件故障里，喷油器结焦和缸内燃烧恶化在振动信号上可能表现得很像。模型如果给个笼统标签“燃烧异常”，拆机检查时是要把喷油器、活塞、缸套、排气阀全拆一遍的，拆装一台大型低速二冲程柴油机的缸头，在船期间至少一到两天，备件、人力、停机损失加在一起非常可观。哪怕模型 100 次里有 95 次对，只要那 5 次误诊发生在航行途中，造成的直接损失就能抹平整个诊断项目的收益。
黑盒模型的另一个麻烦是没法定位责任。一旦 AI 报出的结论和人工拆检结果不一致，现场工程师需要知道“模型是在什么证据下做的判断”，是传感器数据异常，还是特征提取逻辑有问题，还是模型训练样本覆盖不足。没有解释能力，这些问题全都查不了，项目就变成了“讲不清、改不动、不敢拆”。所以可解释性在船舶柴油机这种高价值、高安全等级设备上，不是锦上添花，而是落地的前提条件。
1.2 可解释性不只是一种方法，而是一组分层次的能力
现在行业里讨论可解释性时，经常把不同层次的东西混在一起。我按自己的理解把它分成三类，这样后面选型才清楚。第一类是模型本身可解释，比如决策树、线性回归、逻辑回归，结构透明，系数直接能读出含义。优点是天然可信，缺点是拟合复杂非线性关系的能力较弱，对燃烧室这种强耦合、强非线性的系统往往精度不够。
第二类是事后解释，就是先用黑盒模型把精度做上去，再用 SHAP、LIME、Grad-CAM 这些工具去解释单个预测。这是目前工业落地的主流，因为它把“性能”和“可解释性”解耦，两边都能做到最好。第三类是机理引导的解释，把物理模型、热力学方程、故障机理知识嵌入到诊断过程中，让解释结果符合工程逻辑。比如缸压曲线里某个相位峰值异常，对应的是喷油提前角偏移，这种解释方式最容易被轮机工程师接受，但对团队机理建模能力要求高。
对船舶柴油机燃烧室部件来说，单纯的模型本身可解释通常不够用，我建议的路线是“高精度黑盒模型 + 事后解释 + 机理知识校验”的组合，后面会详细展开。这个组合的好处是：性能不会因为追求可解释而妥协，同时解释结果又有物理逻辑兜底，不至于让工程师看到一堆统计上的“伪相关”。
1.3 这篇内容适合谁
如果你正在做船舶智能机舱项目，或者负责设备健康管理，又或者所处团队刚从理论转向工业落地，我想这篇内容能帮你避开不少弯路。如果你只是对可解释 AI 感兴趣但还没有工业数据背景，我也会把必要的基础知识交代清楚，尤其是数据和机理背景，不至于让你觉得在读天书。我本人在这类项目里踩过不少坑，文章中会尽量把那些“书上看不到、现场一定会遇到”的细节一并带出来。
2. 燃烧室部件故障场景拆解：到底要在什么上做解释
2.1 燃烧室关键部件与典型故障模式
船舶柴油机燃烧室是一个高度耦合的系统，核心部件集中在缸头、缸套、活塞三大块。我梳理故障模型时，习惯先列一张“部件—故障模式—可观测信号”的表，因为后面特征工程和解释设计都得围绕这张表展开，否则很容易变成“拿着特征去找故障”，方向完全反了。
| 部件 | 典型故障模式 | 早期可观测信号 | 恶化后的表现 |
|---|---|---|---|
| 喷油器 | 喷孔结焦、针阀卡滞、雾化不良 | 缸压峰值波动、爆发压力下降、排气温度不均 | 单缸熄火、功率下降、排温飙升 |
| 活塞环/活塞 | 活塞环磨损、卡滞、活塞顶烧蚀 | 窜气量大、曲轴箱压力高、缸套振动异常 | 压缩压力下降、拉缸、刮伤缸套 |
| 排气阀 | 阀面烧蚀、密封带磨损、间隙漂移 | 排气温度升高、缸压曲线拐点异常 | 阀杆卡滞、漏气、缸内燃烧恶化 |
| 缸套 | 磨损、拉缸、穴蚀 | 振动加速度频谱变化、缸套水温异常 | 窜机油、压缩失效、整机停机 |
| 缸头垫片 | 烧蚀、泄漏 | 冷却水系统压力波动、燃气泄漏信号 | 冷却液混入机油、高温报警 |
这里要特别指出一个核心难点：燃烧室故障往往是“级联”的。喷油器雾化不良会引发燃烧不充分，燃烧不充分又导致活塞头和排气阀过温，长时间后又引发排气阀烧蚀。如果模型只做单一故障的分类，很容易把级联故障归错到某一个源头。可解释诊断的价值在这种时候就体现出来了——通过特征归因，能把“近因”和“远因”分开，至少能告诉工程师当前特征异常更偏向哪个环节。这不是靠提高模型复杂度能解决的，必须依赖可解释归因的介入。
2.2 传感器系统：我们能“看见”什么
燃烧室内部没法直接安装摄像头或热电偶进行观察，现实可行的观测手段主要有几大类。缸压传感器通过示功孔测量缸内压力，直接反映压缩、燃烧、膨胀全过程，是燃烧诊断最核心的信号。测点一般装在示功阀或缸头专用通道，采样率通常做到 0.1 到 1 度曲轴转角分辨率，也就是每循环 360 到 3600 个点。振动加速度传感器贴在缸头、缸套外侧，测量燃烧激励和机械冲击引起的表面振动，采样率一般 20 到 50 kHz，能捕捉喷油器针阀落座、排气阀开关、活塞敲击等瞬态事件。排气温度热电偶装在每缸排气管处，成本低、耐恶劣环境，是现场用得最多的粗糙指标。转速和曲轴转角编码器提供相位基准，所有信号必须按曲轴转角对齐，否则特征完全对不上。此外还有冷却水温度、滑油压力、扫气压力、燃油流量等辅助信号，主要用来做工况归一化。
这意味着数据来源是异构的、多尺度的。做特征工程时必须把不同物理单位、不同采样率的信号统一到同一个样本里，这个多源异构特性，正好是树模型和深度模型都擅长处理的场景，也是事后解释工具能发挥价值的地方。但反过来也要注意，如果采集系统没有做相位对齐和标定，解释的结论会直接被噪声带偏，后面第 5 节我会专门讲这类问题。
2.3 为什么拿燃烧室部件当切入点最合适
不是因为燃烧室故障最多，实际上船用柴油机辅助系统的故障率可能更高，而是因为燃烧室故障具备可解释诊断研究最需要的三个条件。第一是意义重大，燃烧室故障直接影响动力性和安全性，做解释的投入产出比最高，机务主管愿意为它花时间和预算。第二是信号丰富，缸压、振动、温度多源信号让解释有足够的信息量，模型不会因为信号太少而无从归因。第三是机理相对清晰，燃烧过程有明确的热力学规律，专家知识可以被用来校验解释结果，避免“AI 说燃烧变差，但说不出是喷油还是点火问题”的尴尬。
从这个角度看，拿燃烧室部件做可解释故障诊断的案例，不是随机选的，而是整个问题域里最有代表性、最能讲清楚方法价值的一个切片。后续所有技术细节都会围绕这个场景展开。
3. 技术路线：完整的可解释故障诊断方案设计
3.1 先定框架：诊断不是单一的模型问题
我见过很多失败项目，都是把故障诊断简单理解成“传感器数据→深度学习模型→故障类别”的单链条。实际部署时这样不行，原因是工业现场的数据质量参差不齐，样本不平衡严重，单模型方案一旦误诊就无法收敛。模型报了一个错，你想去查逻辑，发现整条管线都是不透明的，最后只能回退到“多收集数据重新训练”的老路。
我推荐的整体框架是四条腿走路。数据层做多源信号采集、清洗、对齐、工况归一化，形成干净的标准样本；特征层提取时域、频域、热力学特征，并结合机理做降维和筛选；模型层用高精度的分类或回归模型判断故障类型和严重程度，选型以“能配合解释工具”为前提；解释层用 SHAP 等工具做局部归因，生成“故障依据报告”，再由轮机专家复核。这四个层次不是串行执行的，解释层会反哺特征层，比如某次归因发现某个传感器特征对诊断贡献异常大但机理上说不通，就要回到特征层去检查这个特征是不是引入了某种数据伪影。
这个框架的核心思想是：可解释不是模型之后的一个附加步骤，而是贯穿数据、特征、模型、输出全链路的设计目标。每一层都要保留中间产物，否则解释层想做归因也没有抓手。比如特征层如果直接做 PCA 并丢弃了成分与原始特征的映射关系，后面 SHAP 就算算出了“第一主成分重要”，现场工程师也无法理解，因为主成分没有物理含义。
3.2 特征工程：解释的素材库
特征工程环节直接决定了解释的质量。模型可以换，特征不行，因为 SHAP 解释是在特征维度上分配贡献的，特征本身没有物理意义，解释就没有意义。我按燃烧室诊断的实际需求把特征分成四组。
时域特征包括缸压峰值、峰值相位、平均指示压力、压缩压力、压力升高率峰值、振动信号 RMS、峰值因子、峭度等，能直观反映“燃烧早晚、强弱”的问题。频域特征包括缸压信号的频谱能量分布、振动信号的分量幅值、特定频带能量比，能捕捉周期性的机械冲击和燃烧激励变化。循环间稳定性特征包括相邻循环峰值压力的标准差、循环变动系数，喷油器状态劣化早期往往表现为循环间变动增大，这个特征对早期故障特别敏感。热力学特征包括指示热效率、排气温度偏差、扫气压力与压缩压力关系等，是机理特征的补充。
我还想强调一下特征数量的控制。特征量太多会给解释带来麻烦，一般我会先用机理和相关性分析把特征压缩到 10 到 30 个，再进入模型。特征太多时 SHAP 的归因会发散，解释图变成一团密密麻麻的条，现场根本没法用。这里的原则是“解释要像讲故事，特征要少而精”。你可以理解为给一台设备做体检，医生不会把 200 项化验指标全打印给患者看，而是只标注其中最异常的几项，再加上综合判断。
3.3 模型选型和可解释方法：SHAP 为什么是首选
模型层面我建议优先选梯度提升树（LightGBM 或 XGBoost），或者随机森林，不要一上来就上深度学习。原因是振动、缸压这类工业表格型特征，树模型往往能取得与深度模型相当甚至更好的精度，训练成本低，可解释工具生态也成熟。SHAP 对树模型有原生高速算法 TreeSHAP，算得快、结果稳定，特别适合现场快速反馈的场景。
| 模型类型 | 精度表现 | 可解释配合 | 计算成本 | 适用场景 |
|---|---|---|---|---|
| 决策树 | 中低 | 天然可解释 | 低 | 简单规则快速筛查 |
| LightGBM/XGBoost | 高 | SHAP 原生支持，解释快 | 中 | 工业表格特征默认选择 |
| 随机森林 | 高 | SHAP 支持，稍慢 | 中 | 需要高稳健性时选用 |
| 一维 CNN | 高 | Grad-CAM/注意力，解释的是信号片段 | 高 | 直接用原始信号建模 |
| LSTM/Transformer | 高 | 注意力权重只能粗略参考 | 高 | 强时序依赖场景 |
这里顺便说一句，为什么不用注意力权重代替真正的可解释。注意力权重本质上是模型内部的 softmax 系数，只能告诉你“模型在看哪里”，不能告诉你“看了之后为什么得出结论”。现场工程师要的是后者，也就是归因。我坚持用 SHAP 做归因，因为它基于合作博弈论，能把一次预测结果分配成每个特征带来的贡献值。
SHAP 的原理可以理解成：模型的预测结果相当于几个球员一起打出的比分，SHAP 负责把比分拆解到每个球员头上，并且遵循公平分配原则。比如模型预测“喷油器结焦”概率为 0.9，SHAP 会告诉你：缸压峰值偏低贡献了 0.3，压力升高率峰值相位后移贡献 0.25，振动高频段能量增加贡献 0.2，其余特征贡献较小。每个特征都拿到一个沙普利值，加起来等于预测结果与基线预测的差值。有了这套数值，解释不再是“我认为”，而是有明确数学依据的归因。
3.4 为什么要引入机理知识做校验
纯数据驱动的解释有一个先天盲区：它只能告诉你特征重要，不能告诉你“为什么这个特征在这个故障里重要”。比如 SHAP 说“缸压峰值下降”是喷油器结焦的最大贡献特征，但缸压峰值下降也可能是因为供油量减少、进气不足或压缩泄漏。这时就需要机理知识来收口。
我的做法是建一个“故障—特征—机理”关联表。喷油器结焦对应喷油雾化差、喷油持续期延长，因此燃烧推迟、压力升高率峰值降低、缸压峰值相位后移；排气阀烧蚀对应漏气，因此压缩压力下降、膨胀后期压力异常、排气温度升高；活塞环磨损对应窜气，因此缸压峰值下降、曲轴箱压力上升、振动信号中的摩擦分量增大。当模型解释输出的特征归因和机理表不一致时，系统会标记为“可疑解释”，交由专家复核。这个机制虽然不是全自动的，但能极大提升现场信任度。大家可以把它理解成“AI 先给诊断意见，老师傅再对着病理机制图谱复核病历”，最后签字的是人，不是模型。
4. 实操过程：一个完整的落地样例
4.1 数据准备与预处理流程
我用一个实际项目中常见的样例数据形态来说明：单台船用中速柴油机，额定转速 720 r/min，四冲程六缸，采集了正常、喷油器结焦、排气阀烧蚀、活塞环轻度磨损四种状态下的缸压、振动、转速信号。每类状态采了 500 个循环样本，按曲轴转角对齐后做特征提取，得到 18 维特征向量。
预处理这件事看起来枯燥，但解释结果靠不靠谱，第一步就埋在这里。我按经验拆成四步。第一步剔除异常循环，缸压传感器的偶发失真、转速剧烈波动导致的错位循环，如果不剔除会变成解释里的“幽灵特征”，模型明明没学到，归因里却有一席之地。第二步做曲轴转角对齐，按编码器脉冲将缸压信号重采样到 0.5 度曲轴转角分辨率，如果对齐有偏差，特征相位会整体漂移，机理校验直接失效。第三步工况归一化，把不同转速、负荷下的信号统一折算到标准工况，否则解释出来的“特征偏差”可能只是工况不同，而不是故障引起的。第四步按时间顺序划分训练、验证、测试集，避免同一工况的数据在训练集和测试集中互相泄漏。
4.2 核心代码：特征提取后的模型训练
这里放一段精简可用的 Python 代码，涵盖 XGBoost 模型训练和测试准确率检查。特征提取部分我假设已经做好了，因为实际项目中特征提取代码跟现场测点强相关，没法给通用版本。
import pandas as pd from sklearn.model_selection import train_test_split import xgboost as xgb # features_df 包含 18 维特征和 label 列 # label: 0=正常, 1=喷油器结焦, 2=排气阀烧蚀, 3=活塞环磨损 X = features_df.drop(columns=["label", "rpm", "load"]) y = features_df["label"] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.25, random_state=42, stratify=y ) model = xgb.XGBClassifier( n_estimators=300, max_depth=5, learning_rate=0.05, subsample=0.8, colsample_bytree=0.8, eval_metric="mlogloss", ) model.fit( X_train, y_train, early_stopping_rounds=20, eval_set=[(X_test, y_test)], verbose=False ) acc = model.score(X_test, y_test) print(f"test acc: {acc:.4f}")这段代码本身不是重点，重点是训练之后要做什么。模型训练完不能只看准确率，我额外看三样东西：一是混淆矩阵，搞清楚哪两类最容易互相误判，这往往是解释需要重点关注的部位；二是每个类别的特征重要度，构造全局解释；三是单条样本的 SHAP 值，用于局部解释。这三样结合起来，才算把黑盒变成了“半透明”的盒子。
4.3 SHAP 解释的完整落地步骤
模型训好之后，可解释落地的操作分三步。
第一步是全局解释。用 TreeExplainer 对测试集所有样本计算 SHAP 值，然后画 summary plot，看每个特征对不同故障类别的贡献方向。比如“压力升高率峰值”这个特征，对喷油器结焦类样本贡献为负，对正常样本贡献为正，这个信息比单一准确率有说服力得多。全局解释通常只用于离线分析，不直接推送到现场，它负责帮我们理解模型整体的行为边界。
第二步是局部解释，也就是对某一条预测做 force plot。当模型对某个样本报了“排气阀烧蚀”，立刻能看到压缩压力下降贡献了 0.2、排气温度偏差贡献 0.15、高频振动能量贡献 0.1，三者叠加把预测概率推到 0.8。这个输出的价值在于，它既给了结论又给了证据，证据条数可以裁剪，方便现场快速阅读。操作上我会对每一条测试样本生成 top-N 特征归因，以表格形式输出，而不是直接把 force plot 原图丢上船。
第三步是生成“诊断依据报告”。报告包含样本基础信息、模型预测、SHAP 归因 Top-N、机理表匹配结果，以及一句人话总结。报告不用写太长，但必须满足一个标准：一个没接触过 AI 的轮机员能看懂。近年我在项目里越来越觉得，好用的报告不是堆信息，而是把信息组织成“结论、证据、可信度”三段式，现场一看就明白。
4.4 可视化与现场呈现技巧
解释做出来后，另一个关键点是呈现方式。船上的显示屏往往不大，现场工程师也没有精力读一大堆图表。我实际项目里用过一张“柱状归因图”：横轴是特征，纵轴是 SHAP 值，正负分色，下方再配一句人话结论。在仪表台上几秒钟就能读懂，比输出一堆学术图实用得多。
可视化这里有一个坑：不要把归因图做得太学术。SHAP 的依赖图、交互图在分析阶段很有用，但给现场看要狠狠简化。我的习惯是分析阶段把各种图都看一遍，交付阶段只保留一张诊断卡片。如果你面对的对象是算法团队，那可以展示完整火焰图；如果是船东代表，那最好就一张图加一句话。别小看这一步，解释方法选得再好，呈现端把用户劝退了，项目一样会失败。
5. 常见问题与排查技巧实录
5.1 解释结果和专家经验打架怎么办
这个问题几乎必然发生，而且发生在项目最敏感的时候。有一次模型给一个活塞环磨损样本的归因里，“排气温度偏高”贡献排在最前，轮机员立刻质疑，说排温高明明是燃烧后段的问题，怎么会跟活塞环磨损有关。排查下来发现原因是：样本里活塞环磨损已经导致窜气，窜气又让燃烧过程恶化，排气温度自然涨了。模型学到的是这条级联路径，而专家下意识按“单故障单特征”的思维理解。
这种时候，光给 SHAP 不够，还要给级联路径的展开解释。我的处理方式是在诊断报告里增加“相关特征与机理提示”栏，标注“排气温度偏高可通过窜气路径间接关联”，让专家确认级联逻辑。这么一改，专家反而觉得模型更聪明了。这个经历让我学到一个道理：解释工具的产出要和人的理解框架对齐，不能只丢一堆数字，要让数字背后的逻辑能被对话。
5.2 特征之间的相关性把归因搞乱了
SHAP 在强相关特征面前会出现“功劳分配抖动”的问题。比如“缸压峰值”和“缸压峰值相位”物理上相关性强，这次可能把 0.3 归给峰值大小，下次可能变成 0.25 和 0.1 重新分配，看起来模型行为不够稳定，现场很难接受。这是 SHAP 这类基于博弈论解释方法的一个已知特性，不是 bug，但需要处理。如果是同一个样本反复推理，解释结果还好说，麻烦的是现场会拿不同时间窗口的样本对比，一旦抖动明显，用户就会怀疑整个系统。
我的规避办法有三个。一是在特征工程阶段就把相关性过高的特征合并，比如峰值相位和峰值高度在很多故障模式下同涨同跌，就只保留其中一个；二是用聚类后的特征组做解释，比如把强相关特征合并成“压力水平组”“压力陡峭度组”“振动能量组”，在组级别上做归因，稳定性会明显提升；三是增加样本量、降低模型复杂度，也能缓解一部分抖动。这三点在现场项目中我基本都会同时用，尤其是第二点，效果最直接。
提示：如果发现 SHAP 归因在两次运行中抖得很厉害，优先检查特征之间的高相关性，而不是急着换模型。换模型通常解决不了归因不稳定的问题。
5.3 样本不平衡让解释偏向多数类
工业故障样本天然稀缺，喷油器结焦可能只有正常样本的十分之一。样本不平衡时，模型全局解释会被正常类主导，故障类的少数样本得不到可靠归因。我常用的做法是过采样加类别权重调整，但更关键的是解释要按类别分开计算 SHAP，不要把所有样本混在一起看 summary plot。
类别不平衡还意味着准确率指标会骗人。比如 95% 的准确率可能只是把所有故障都判成正常的“假阴性陷阱”造成的。所以一定要单独看每个故障类的召回率，再决定解释重点放在哪个类别上。如果一个故障类的召回率很低，先不要急着做解释，而是回到数据层把样本质量和数量问题解决，否则解释出来的东西毫无意义。
5.4 现场部署的若干提醒
最后补充几个现场部署时容易被忽略的细节。第一，算力限制。船上工控机通常没有 GPU，所以方案里必须控制模型规模和解释计算量，我选 LightGBM 而不是 Transformer 级别的模型，SHAP 用 TreeSHAP 也能大幅加速。第二，数据流时序。现场是流式采集，必须做固定窗口的滑窗推理，解释要跟着推理一起输出，不能事后补算，否则会错过报警窗口。第三，交互设计。解释结果最好落到监控系统里一个单独的“诊断详情”页面，不要放在实时报警主界面刷屏，否则反而降低信任。
上船部署前我会把模型和解释器做成一体化的离线推理包，验证时用“模拟数据注入”的方式回放历史故障，不在真实机器上做破坏性试验。这一点在船舶场景里尤其重要，因为你是动别人的生产设备，一旦影响主机运行，责任就大了。
6. 最后说几句个人的体会
可解释故障诊断在船舶柴油机燃烧室这件事上，技术难度其实没有想象中那么高，难的是把“模型输出”变成“机舱里人人能沟通的语言”。我做这个项目最大的感受是：解释工具本身（SHAP、LIME 之类）只是起点，真正决定项目成败的是是否能把设备机理、现场习惯和故障级联逻辑组织起来，把解释变成让人信服的故事。
具体到落地，我有三个建议。第一，多花时间在特征工程和数据清洗上，这比换更强模型更能提升解释质量。第二，解释要按受众裁剪，给算法工程师看完整 SHAP 图，给轮机员只看归因 Top3 和一段人话结论。第三，一定要让一线轮机师傅参与复核，他们掌握大量实船经验，能发现数据里根本看不出来的故障耦合关系。
我自己在项目最后又加了一个小功能：把所有历史诊断解释存成结构化档案。后来做故障复盘时，这些“带解释的历史病例”成了最宝贵的资料——遇到新故障时，直接比对历史归因模式，就能快速定位同型问题。这个扩展成本很低，但价值极高，强烈建议做类似项目的人考虑进去。
