一場事故引發全網測試語音關大燈，安全不能“聽不懂”

深夜高速路上，車主只是想關掉車內閱讀燈，卻因語音助手的一次“誤解”，導致全車燈光熄滅，車輛在黑暗中撞向護欄。更令人心驚的是，當車主慌亂中試圖喚醒車機重開大燈時，得到的回應卻是：“暫時還不會喲。”

所幸事故未造成人員受傷，但這起涉及語音操作的意外，卻激起了整個汽車行業對于智能座艙安全底線的深層思考。

一次“誤聽”引發的全網大測試

相關品牌高管在事發后公開回應，確認事故源于語音誤操作，并在24小時內通過云端推送了優化方案：車輛行駛狀態下，大燈關閉功能僅支持手動物理控制，徹底切斷語音誤觸的可能。

官方的快速響應值得肯定，但事件并未就此平息。一場由車主自發參與的“語音關燈”全網大測試，在社交媒體上悄然展開。不同品牌車型在面臨“關閉大燈”這一指令時的不同反應，卻進一步將語音操作“漏洞”進一步展示在消費者面前。

測試結果令人咋舌，不同車企的策略大致可分為三類：

第一類是“嚴守底線型”。以特斯拉、小米為代表，它們在底層代碼中設置了嚴格的安全鎖。只要車輛處于行駛狀態（非P檔），語音助手會直接拒絕執行“關閉大燈”指令，并明確提示“為保證安全，請停車后操作” 。這種將關鍵安全功能與車輛物理狀態強綁定的邏輯，被業內人士視為理應成為行業標配的“安全基線”。

第二類是“條件限制型”，情況則復雜得多。部分新勢力品牌在常規語音指令下拒絕關燈，但車主卻可以通過預設“自定義快捷指令”等方式繞開限制，實現行駛中關燈。也有一些品牌在低速時可以語音指令關閉，速度超過20km/h時，則拒絕執行操作。

第三類是“直接執行型” ，暴露出的問題最為嚴峻。據車主實測，一些品牌車型在行駛中，只需一句“關閉所有燈光”或手動將大燈調至近光模式后說“關閉近光燈”，車燈便會應聲而滅，沒有任何攔截或二次確認機制。

“智能”不能變“智障”

為何看似相同的語音功能，執行邏輯卻天差地別？

“這本質上不是語音識別率的問題，而是系統架構層面的安全哲學問題。”一位汽車電子安全專家指出，當前行業存在一種誤區，認為“智能”等于“有求必應”。

“汽車不是智能手機，更不是家居音箱。家居音箱誤操作，最多放錯歌；汽車誤操作，付出的可能是生命的代價。”該專家強調，根據功能安全（ISO 26262）和預期功能安全（ISO 21448）的標準，涉及車輛縱向和橫向控制的核心功能，如轉向、制動、照明等，必須具備足夠的安全冗余和防錯機制。“語音作為單一的、存在誤識別率的輸入通道，其權限必須受到場景的限制。在高速行駛、夜間無照明等高風險場景下，系統甚至應該具備‘抗旨不遵’的能力。”

這一觀點得到了不少業內人士的認同。有數據顯示，車載語音識別在真實復雜的行駛環境中，誤識率普遍在5%上下 。5%的概率看似不高，但當它落在某個具體駕乘者身上，就是安全隱患提升。

不能靠消費者“測試”來補漏

語音指令被誤識別引發事故，是一次不幸的“實景測試”，它暴露了當前智能汽車發展中一個普遍存在的短板：為了追求交互的極簡和功能的炫酷，部分車企的安全驗證流程未能跟上軟件快速迭代的步伐。

“互聯網思維講究小步快跑、快速迭代，但在汽車領域，這種思維需要加上一道‘安全鎖’。”一位汽車行業分析師表示，此次全網測試之所以引發巨大反響，是因為消費者發現自己正在被動地扮演“道路測試員”的角色。“不能總靠用戶撞了南墻，車企才去回頭修補。很多安全邏輯，比如‘行駛中能否關大燈’，在產品定義階段就應該想清楚。”

事實上，并非所有場景下關閉大燈都是“不合理”需求。比如，在地庫等明亮環境，不希望大燈晃到對面行人和車輛，所以要求行駛中關閉大燈，這是否該獲得語音操作支持？

“滿足用戶需求的前提，是不能觸碰安全紅線。”上述分析師認為，針對此類場景，更合理的解決方案并非無底線地開放語音權限，而是優化自動大燈的靈敏度，或提供更便捷的手動控制方式。

根據了解，工業和信息化部等相關部委正在加快推進《智能網聯汽車組合駕駛輔助系統安全要求》等強制性國家標準的制定與實施 。這意味著，關于“語音該不該在行駛中關燈”的爭論，即將迎來明確的法規紅線。

智能汽車的未來，一定是在便捷的“快車道”上，但始終行駛在安全的“護欄”內。