3. 缺陷根因分析基础：从现象到本质

做座舱开发这些年，我见过太多团队在同一个坑里反复跌倒。屏幕闪了一下，重启就好了——然后呢？没人再管了。直到量产前，这个问题突然爆发，整批货堵在产线上。

为什么会这样？说白了，我们只修了「症状」，没挖到「病根」。这一章，我就聊聊怎么从现象一路追到本质。三种方法：5Why、鱼骨图、FTA，都是我亲手用过的。

3.1 5Why分析法：追问到底

5Why不是让你刚好问五次。它的核心是：一直问，直到找到能采取行动的根因。

我当时拦住了。我说，先问几个为什么。

现象：中控屏黑屏
Why 1：为什么黑屏？ → 背光驱动未响应
Why 2：为什么驱动未响应？ → I2C总线报错
Why 3：为什么I2C报错？ → 从设备ACK超时
Why 4：为什么ACK超时？ → 从设备供电电压跌落至2.7V
Why 5：为什么电压跌落？ → 电源管理IC在特定工况下进入限流保护

你看，根因根本不是屏幕本身，而是电源策略。换屏？换一百块也没用。

3.2 鱼骨图：系统性地找原因

5Why适合线性问题。但座舱系统复杂啊，一个问题往往是多个因素凑出来的。这时候，鱼骨图就派上用场了。

我记得有一次，某车型的语音唤醒成功率从95%掉到了60%。团队吵了三天，有人说是算法问题，有人说是麦克风坏了，还有人说是网络波动。

我拉了一张鱼骨图，把可能的原因按维度列出来：

画完这张图，大家就安静了。我们逐条验证，最后发现根因是空调开启时，风噪改变了车内噪声谱，而VAD阈值没有适配这个场景。

3.3 FTA：用逻辑树锁定根因

FTA（故障树分析）比前两种更严谨。它用逻辑门把「顶事件」拆解成「底事件」，适合处理安全相关的缺陷。

举个例子。某车型的电子手刹在低温环境下偶发释放延迟。这是个安全相关的问题，必须用FTA来系统分析。

你想想看，如果只用5Why，可能只追到「电机润滑脂凝固」就停了。但FTA告诉我们，还有另外两条路径也可能导致同样的问题。

3.4 三种方法怎么选？

嗯，这里我直接给个对照表，方便你快速决策。

3.5 从缺陷数据到根因：一个完整流程

光讲方法太干了。我拿一个真实案例，把整个流程串一遍。

背景： 某车型OTA升级后，约3%的用户反馈导航语音播报卡顿。

第一步：数据清洗
从日志中提取出卡顿发生时的共性特征：CPU占用率 > 85%、内存剩余 < 200MB、TTS进程优先级被降低。

第二步：鱼骨图分析
画出原因维度：CPU竞争、内存泄漏、优先级策略、TTS引擎版本。

第三步：5Why深挖

Why 1：为什么TTS优先级被降低？ → 系统调度器在内存紧张时降级非前台进程
Why 2：为什么内存紧张？ → 地图应用在后台持续缓存数据
Why 3：为什么地图缓存不受控？ → OTA升级后地图版本变更，缓存策略未适配新内存预算

第四步：FTA验证
确认「地图缓存不受控」是唯一底事件后，制定修复方案：限制地图后台缓存上限为50MB。

第五步：效果验证
修复后，卡顿率从3%降至0.1%。剩下的0.1%经确认是网络波动导致，与本次缺陷无关。

好了，这一章的内容就是这些。三种方法，各有各的脾气。关键是要根据问题的性质，选对工具。别让方法成了形式，也别让经验代替了分析。