想象一下，你深夜开车在没有路灯的高速上，车内一盏阅读灯刺眼影响视线，你对着车机说了一句“嗨领克，关闭所有阅读灯”，结果外头的前大灯也被同时关掉，车瞬间陷入黑暗，最后失控撞上了护栏。
这样的场景不是电影镜头，而是发生在真实路上的一段行车记录：2月25日凌晨近1点，一位在广西某高速路段行驶的领克车主正是经历了这样的惊魂时刻。
所幸人员未受伤，车辆财产损失细节尚未公布。
事后视频在网络上广泛传播，引发大量车主去测试自家语音系统是否会误关大灯。
社交平台上不少人上传了测试片段，参与的包括Z20、Z10、07、08等车型。
有的车主说语音只关了车内灯，系统语音提示称行驶中近光灯和示廓灯无法通过语音关闭；也有车主表示大灯确实被关掉。
甚至有其他品牌的车主也参与讨论，认为能在行驶中用语音关闭车头灯是严重的安全设计缺陷。
领克方面的回应来得很快。
2月26日晚，领克汽车销售有限公司副总经理穆军确认事故起因为Z20车型在行驶中发生的语音误操作。
通过多次排查，领克判定问题仅出现在部分升级到Flyme auto 2.0.0的Z20车型上，其他车型未发现此类情况。
公司表示已紧急通过云端优化修复该问题，并已与当事车主沟通确认其人身安全并达成一致。
官方还解释，事故现场为高速行驶，车外噪音或网络环境可能影响了语音识别，进而触发了异常识别。
但他们同时强调，正常情况下车机会有语音提示，并在行驶中不允许关闭行驶灯光。
在这件事上，有一个原文没有深入回答但非常关键的问题：为什么语音误识别会直接触发能影响行车安全的动作？
我认为，问题的核心不在于单次识别错误，而在于系统设计缺少必要的等级保护。
理想的安全逻辑应至少包含三层防护：第一层，关键车灯等与行车安全直接相关的命令应在本地有明确的禁止策略，行驶中不接受关闭大灯的语音指令；第二层，当识别出可能影响安全的意图时，必须要求显式确认或用其他输入渠道复核；第三层，系统应记录语音与执行日志，便于事后追溯与修复。
把所有判断都押在远端云识别和一次性语义解析上，就会在噪声、网络波动或误唤醒时暴露风险。
那么，遇到这样的事情，我们能做什么？
首先，不要在行驶中测试可能影响安全的语音指令；如果你拥有Z20且升级到Flyme auto 2.0.0，建议尽快与厂商或经销商确认是否已下发并生效云端修复。
更多通用的自我保护措施包括：了解并熟悉自己的语音控制权限，优先使用物理按钮或方向盘控制夜间行车灯光；在收到更新提醒时及时安装，并保留更新记录和系统日志屏幕截图以备查询。
这件事让人底层感受到了焦虑：我们把驾驶中的一部分控制权交给了语音与软件，期望便利，却也在某一刻看到了被便利反噬的可能。
你是否愿意在行驶中把关键安全功能托付给语音助手？
如果你的车也能通过一句话改变行车安全，你会选择信任厂商的云端修复，还是更想看到一种硬性的车内安全锁，彻底杜绝行驶中通过语音关闭大灯？
这将是每位车主必须面对的现实抉择。
全部评论 （0）