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

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

一次“誤聽”引發(fā)的全網大測試

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

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

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

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

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

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

“智能”不能變“智障”

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

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

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

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

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

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

“互聯網思維講究小步快跑、快速迭代，但在汽車領域，這種思維需要加上一道‘安全鎖’?！币晃黄囆袠I(yè)分析師表示，此次全網測試之所以引發(fā)巨大反響，是因為消費者發(fā)現自己正在被動地扮演“道路測試員”的角色?！安荒芸偪坑脩糇擦四蠅?，車企才去回頭修補。很多安全邏輯，比如‘行駛中能否關大燈’，在產品定義階段就應該想清楚?！?/p>

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

“滿足用戶需求的前提，是不能觸碰安全紅線?！鄙鲜龇治鰩熣J為，針對此類場景，更合理的解決方案并非無底線地開放語音權限，而是優(yōu)化自動大燈的靈敏度，或提供更便捷的手動控制方式。

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

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