硬體出了重大問題怎麼辦?鉑智7 上市不到 100 天召回兩次,兩次都是軟體寫錯的
8 月 1 日,廣汽豐田備案了兩張召回公告。
第一張 S2026M0083V,15266 輛鉑智7。缺陷原因是這麼寫的:「智慧藍牙模組的軟體控制程式考慮不充分,在特定條件下,可能向車輛控制模組發送異常指令,造成車輛在行駛中自動從 D 檔跳入 N 檔。」
第二張 S2026M0084V,24286 輛鉑智7。缺陷原因是「熱管理控制器的軟體控制策略不完善,車輛上電後,空調壓縮機及水加熱器可能停止工作」,極端情況下除霜除霧性能下降,影響駕駛員視野。
兩批加起來 39552 輛。鉑智7 這款車上市還不到 100 天。
兩張公告的解決措施是同一句話:透過汽車遠端升級(OTA)技術免費升級軟體,使用者無需到店即可完成。
同一個月的另外三張公告,是要動手的
8 月 8 日起,捷豹路虎兩張公告一起生效。S2026M0080V 召回 76422 輛進口路虎攬勝、路虎發現,S2026M0081V 召回 83810 輛路虎衛士,合計 160232 輛。缺陷是方向盤遊絲連接到駕駛員安全氣囊的接頭可能出現微動腐蝕,電阻增加,可能導致駕駛員安全氣囊無法正常展開。解決措施是免費為接頭端子塗抹專用潤滑脂。
8 月 28 日起,S2026M0082V,小鵬召回 33473 輛 X9。製造工藝波動導致前空氣彈簧氣密性下降,高溫高濕環境長時間使用後可能緩慢漏氣,極端情況下影響操控性。解決措施是免費更換改進後的前空簧滑柱總成。
把五張公告並排放:
| 召回編號 | 品牌車型 | 數量 | 缺陷所在 | 怎麼修 |
|---|---|---|---|---|
| S2026M0080V | 路虎攬勝、路虎發現 | 76422 輛 | 氣囊接頭微動腐蝕 | 逐台塗專用潤滑脂 |
| S2026M0081V | 路虎衛士 | 83810 輛 | 同上 | 逐台塗專用潤滑脂 |
| S2026M0082V | 小鵬 X9 | 33473 輛 | 前空氣彈簧氣密性 | 逐台換前空簧滑柱總成 |
| S2026M0083V | 鉑智7 | 15266 輛 | 藍牙模組軟體 | 推一次 OTA |
| S2026M0084V | 鉑智7 | 24286 輛 | 熱管理控制器軟體 | 推一次 OTA |
上面三行,19 萬多台車要一台一台開進服務站,舉升機、工時、備件、客戶預約,全部實打實地發生。下面兩行,39552 輛車,工程師發一個升級包。
召回公告的缺陷措辭變了:從「腐蝕」到「考慮不充分」
翻這兩個月的召回通告,老式硬體缺陷的詞是固定那幾個:腐蝕、金屬疲勞、開裂、強度設計不足、裝配了錯誤尺寸的半軸、電芯內部鋰生長。哈雷那批是「上三星夾材料強度設計不足,應力集中處可能產生裂紋」,Volvo EX30 那批是「生產偏差可能導致電芯內部鋰生長」。
新出現的那類詞是另一套:「考慮不充分」「策略不完善」「設置不當」。同一批通告裡,一汽豐田 Prado 召回 9408 輛,缺陷原文是「組合儀表控制程式設置不當,車輛啟動時,組合儀表可能無法正確啟動」。
「智慧藍牙模組的軟體控制程式考慮不充分」,翻譯成軟體團隊每天在說的話,就是某個邊界條件沒被寫進判斷裡。這種事在需求評審的會議紀要裡通常是一行「這個場景先不考慮」,在召回公告裡是 15266 輛車。
2025 年 1904 次 OTA 升級裡,只有 13 次算召回
中國市場監管總局公布的 2025 年數據:全國實施汽車召回 190 次、涉及 684.6 萬輛,次數和數量分別比上一年下降 18.5% 和 39.1%。其中採用 OTA 方式召回 13 次,涉及 175.6 萬輛,占全年召回總數量的 25.7%。
同一年,企業報告的 OTA 升級是 1904 次、涉及 1.4 億輛次,升級次數比上一年增長 38%。
1904 和 13。絕大多數 OTA 是加功能、改體驗、修小毛病,只有 13 次被定性成召回。這條線畫在哪裡,是這件事上最貴的一個判斷——線這邊是產品迭代,線那邊是要向監管備案、要停止生產銷售、要進年度統計的缺陷召回。
工信部和市場監管總局 2025 年 3 月那份通知(工信部聯通裝〔2025〕45 號)把線畫得很清楚:「企業實施 OTA 升級活動消除汽車產品缺陷、實施召回的,應當按照《缺陷汽車產品召回管理條例實施辦法》組織實施,並立即停止生產、銷售缺陷汽車產品。」同一份文件裡還有一句針對性更強的:「規範 OTA 升級應用方式,避免企業通過 OTA 升級隱瞞車輛缺陷或規避責任。」
OTA 把修復成本從「19 萬台車逐一進場」壓到「發一個包」,但沒有把備案義務減掉一分。能遠端改,不等於可以不聲張地改。
確認缺陷之後:十個工作日、三個月、貨值 1% 到 10%
召回不是從對外發公告那天開始的,是從「認為可能存在缺陷」那天開始的。
汽車這邊,《缺陷汽車產品召回管理條例》要求生產者在實施召回前向主管部門備案召回計劃。不做汽車的硬體按《消費品召回管理暫行規定》走,條款寫得更細:第九條,「生產者發現消費品可能存在缺陷的,應當立即組織調查分析」;第十七條,主動召回的,自調查分析認為存在缺陷之日起十個工作日內向所在地省級市場監管部門報告召回計劃;第二十一條,自召回實施之日起每三個月提交階段性總結,完成召回計劃後十五個工作日內提交召回總結。
罰則那一欄的量級差得很遠。汽車條例第二十四條,生產者違規的,處缺陷汽車產品貨值金額 1% 以上 10% 以下的罰款,情節嚴重吊銷許可;第二十三條,不配合缺陷調查等情形,拒不改正的處 50 萬到 100 萬。而《消費品召回管理暫行規定》第二十五條,逾期未改正處一萬元以上三萬元以下罰款。
所以在這條鏈上最難的動作不是修,是定性——承不承認這是缺陷。2025 年那 190 次召回裡,受市場監管總局督促影響而實施的有 55 次,涉及 293.4 萬輛,占全年召回總數量的 42.9%。按輛數算,近一半的車不是企業自己舉手報的。
修復方案、對外話術、補償方案都能在 48 小時內準備出來,卡住的一直是前面那一步:有人要簽字說「這是缺陷」。
我這邊最壞的情況是回滾
我做的是軟體,不做硬體。線上出問題,最壞的一次是半夜回滾一個版本,第二天寫覆盤,使用者那邊的損失是幾個小時用不了,或者一段資料要重導。這個代價我付得起,所以我以前做判斷的時候,「先上再說,出問題再修」幾乎不需要猶豫。
鉑智7 那份公告寫的是「車輛在行駛中自動從 D 檔跳入 N 檔」。同樣是一段控制邏輯沒考慮周全,我這邊的結果是回滾,那邊的結果是有人在路上失去動力。
軟體定義硬體之後,一次提交的最壞結果從「使用者重開一次 App」變成了一張有編號、有輛數、要向國家備案的公告。而寫這段邏輯的人,用的還是軟體那套習慣:先上,看數據,再迭代。
OTA 讓這個習慣更難改。修起來越像發版,就越容易按發版的標準去判斷「這算不算問題」。鉑智7 上市不到 100 天備案兩次召回,涉及車輛的生產日期最早那批是 2025 年 10 月 28 日,兩個缺陷都跟著第一批車一起出廠,只是先被開出去幾個月才被認下來。
2026 年 8 月這五張公告,編號從 S2026M0080V 到 S2026M0084V,加起來 233257 輛車。其中 39552 輛的問題,是有人在程式碼裡沒寫全一個條件。
討論