领克语音助手夜间误关大灯引发撞车，这是怎么回事？车企该怎样解决语音控制系统的安全问题？

大灯被车内语音关闭这件事来说，它的根源不是识别率，而是安全架构。有人把问题归结为语音识别错误其实是站不住脚的。因为识别率是表层触发条件，如果识别错误可以直接触发安全相关功能，那说明系统没有做足权限隔离。真正的问题是这家企业的安全观，没有强化他们预控的权限边界。
在功能安全体系里，ASIL[Automotive Safety Integrity Level，汽车安全完整性等级]从QM、ABC到D共五个等级，D最高，QM最低。

语音系统本身往往按QM开发，但当其能调用安全相关功能时，就必须满足功能安全中的干扰隔离要求。而前大灯控制在等级中划分并不明确，因为多数功能是ISO 26262之中通过HARA也就是危害分析和风险评估得出的，比如给出S，也就是severity严重度，还有Exposure暴露频率以及Controllability可控性，用S、E、C这些失效场景来综合定义的。

拿夜间行驶突然关大灯这例子来说，按严重度分类，可能是S3，也就是导致严重伤亡，按照频率分类，属于E4，高频，按照C可控性来说，可能是C2或者C3，因为驾驶员短时间内难以完成控制，有人认为这是个操作问题，认为语音能关大灯本身无所谓，只要保证推一下拨杆能再给灯开开不就行了。

且不说当时车主又再次发出语音指令让它再开灯时，其实是打不开的，单说这个所谓的机械拨杆冗余在紧急状态下用户是否还能反应这一点，就绝对是车企的锅，因为紧急情况下，人本能只会溯源反推，而不会另辟渠道。这个在哲学上叫做认知资源收缩现象，也叫做耶科斯·多德森定律，俗称的U型应激，所以一些人谈到的所谓的拨杆冗余理论，是混淆了一级冗余和被动补救冗余之间的关系。就像有的车撞了之后，扣紧急扳手发现是个假的，手得伸进去抠那个拉线才能机械开车门，这要搁谁谁都得应激，这种都是属于典型的不良工程冗余，需要立即整改。
传统分布式架构时代，座舱内部的舒适性控制一般是通过物理线束、独立的ECU或总线隔离，有一个天然边界，即便上层HMI出现误操作，也很难直接穿透到底层控制。但在新能源的一些新的域控架构，功能被抽象为可调用的服务接口。如果权限逻辑不严谨，异常状态下缺乏强制冻结策略，那么软件层面的“调用自由”就可能突破安全边界。这不是识别问题，而是权限设计问题。而逻辑隔离比物理隔离更难被用户理解。用户看不见代码，看不见权限矩阵，也看不见异常状态冻结机制。他只看到结果，就是高速行驶中灯灭了。问题的挑战在于：复杂度上升后，架构问题的可解释性极低。问题出现后，给你进行解释的时间窗口特别短，进行线性解释，就很难赶上指数型负面的速度。信任一旦受损，恢复成本远高于修复代码。