作者：于佳卉

晚高峰，車機自動調暗燈光、播放音樂——對駕駛者是瞬間的舒適，對研發者卻是一場牽動座艙、車身、傳感器、數十個軟件版本的“極限協同”。今天的汽車，正從交通工具變成“移動智能空間”，每增加一種體驗，研發鏈條上就多出一批需求、接口、版本和測試任務。車越來越懂人，造車這件事卻變得越來越復雜。

當產品開發周期從“年”壓縮到“月”甚至“周”，過去依靠會議、表格和人工確認維持的研發方式開始承壓：客戶需求會不會在層層分解后走樣？硬件接口改變后，軟件和測試是否仍在使用舊版本？一項變更究竟會影響多少模塊、測試任務和供應商？

在本期《新“智”中國行 AI會客廳》中，至頂科技CEO兼總編輯高飛與蜂巢電子科技研發副總經理袁光、IBM中國科技事業部ELM業務總經理王勝航展開對話，討論軟件定義汽車時代，汽車電子企業如何管理快速迭代的軟硬件產品，以及AI如何進入需求、開發、測試和制造流程。

這場對話指向一個很具體的問題：汽車電子企業如何在加快迭代的同時，不讓復雜度演變為質量和交付風險？

當開發周期從“年”壓縮到“周”，哪里最先承壓？

汽車電子企業最先感受到的變化，是時間。

袁光表示，過去一款全新車型的開發周期通常以年計算，如今主機廠頻繁提出三個月實現SOP、六個月交付新車等要求，部分功能的開發周期甚至從幾個月壓縮到一個月或一周。

產品迭代速度提升的同時，質量門檻也在提高。

過去，ASPICE、功能安全和網絡安全等能力可能是供應商的加分項，如今已逐漸成為進入主機廠供應體系的基本條件。企業不僅要把產品做出來，還要證明每項需求經歷了怎樣的設計、開發和驗證，每次變更又影響了哪些環節。

更大的挑戰來自協同復雜度。

傳統汽車電子產品相對獨立，儀表、收音機等模塊之間的交互有限。隨著智能座艙、智能車控、網聯和輔助駕駛進入整車，不同產品開始與多個域交互。接口、軟硬件版本、測試環境及供應商交付，只要有一個環節出現偏差，問題就可能在聯調甚至量產階段集中暴露。

過去比的是能不能把產品做出來；今天比的是，在軟件快速迭代時，能否把硬件、軟件、測試和安全放進同一套研發體系。

這也改變了汽車行業對“自動化”的理解。

王勝航表示，十年前的自動化更多集中在生產側，通過機器和設備代替重復勞動。今天的智能制造，則開始把數據、物聯網、算法和AI引入研發、生產和運維的全鏈路。

自動化關注單一工序能否更快、更穩定地運轉，智能制造則要求整套體系能夠感知變化、判斷影響并作出反應。汽車電子的研發過程，也因此成為智能制造的重要起點。

告別“重復造輪子”，研發需要一套“共同語言”

蜂巢電子主要從事汽車智能化相關產品的研發、生產與銷售，產品覆蓋智能座艙域控制器、輔助駕駛域控制器、顯示屏、音響系統、T-BOX和雷達等。

隨著產品數量、研發團隊和客戶范圍擴大，蜂巢電子近幾年進行了三次重要的研發管理調整。它們對應著汽車電子企業規模化過程中常見的三個問題：項目增多后如何減少重復開發，團隊擴大后如何形成共同語言，工程數據持續積累后又如何轉化為組織能力。

首先是從項目制轉向平臺化。

早期的軟件、硬件和結構開發主要圍繞單個車型項目展開。這種方式能夠快速響應客戶，但項目越多，重復開發越明顯。同樣的基礎功能可能被多個團隊反復實現，已有工程資產也難以復用。

蜂巢電子隨后開始推進平臺化研發，讓不同車型項目共享基礎軟硬件平臺，并在需求、結構和軟件模塊等方面提高復用率。

平臺化的價值不只是少寫一遍代碼。車型項目越多，復用已有模塊帶來的時間和成本優勢越明顯，也更有利于團隊將精力集中在真正具有差異化的功能上。

第二次調整是統一研發體系和工具鏈。

團隊成員來自不同企業，研發習慣和流程認知存在差異。如果缺少統一的研發語言和標準，同一個需求、版本或測試狀態，很容易在不同團隊之間產生不同理解，跨部門協作也會因此依賴大量溝通和人工確認，協作效率難以提升。

蜂巢電子先將流程體系化，再把流程固化到研發工具中，引入包括IBM ELM在內的工程管理系統，讓團隊盡可能在統一的流程、數據和工具環境中工作。

第三次調整指向技術知識管理。

一家企業運營多年后，會沉淀大量問題分析、設計規范和工程經驗。但這些知識往往分散在文檔、系統和個人經驗中，工程師真正需要時未必能找到。

在袁光看來，AI提供了一種新的可能：讓模型學習企業內部積累的工程數據，把過去“沉默”的知識重新呈現在工程師面前。

三次調整指向一個變化：當產品和團隊規模擴大，研發不能再只依賴項目經驗和個人能力，而需要形成可復用的平臺、統一的協作規則和能夠持續調用的知識資產。

最昂貴的錯誤，為什么總在最后才被發現？

研發周期越短，質量問題越不能留到最后。

袁光表示，當產品進入最終測試階段才暴露問題，時間和成本往往已經難以挽回。汽車電子研發需要將測試驗證前移，在需求、設計和開發過程中持續檢查產品狀態。

傳統V字研發模型的一側是需求分解和產品開發，另一側是對應層級的測試與驗證。面對快速迭代，蜂巢電子開始在大的V字模型中加入多個小型敏捷循環，讓需求、開發和測試以更短周期反復迭代。

用袁光的話說，測試不應是最后一步，而要為全過程“量體溫”。

測試前移之后，一個基礎問題變得更加重要：每一項測試，究竟對應哪一條需求？

一項客戶需求可能經過系統需求、軟件需求和硬件需求多層分解，最終轉化為不同的測試用例。只要其中一次傳遞發生偏差，最終實現的功能就可能偏離原始意圖。

版本管理同樣復雜。硬件接口已經調整，軟件和測試環境仍然沿用舊版本，問題通常要等到聯調時才會暴露。一旦需求發生變化，受到影響的設計、測試、缺陷和交付物，也很難單靠人工迅速判斷。

因此，工程生命周期管理在這里就變得很重要，它承擔著建立關系鏈的角色。

王勝航表示，通過IBM ELM，客戶需求如何被分解，最終由哪些測試驗證，發現缺陷后如何關閉，都可以沿著同一條工程鏈路被查詢。需求發生變化后，團隊也能據此判斷哪些模塊、版本和測試任務需要重新關注。

這種追溯關系同時支撐著汽車企業的合規管理。

在ASPICE、功能安全等審核過程中，企業需要提供研發活動的過程證據。如果日常工作沒有留下完整記錄，項目團隊只能在審核前翻找文檔、補充表格。通過工程系統持續記錄需求、測試和變更，證明材料可以在正常研發過程中同步形成。

工程師不必額外完成一份“證明自己工作過”的工作。質量與合規也由項目結束前的集中補課，轉變為研發流程本身的一部分。

系統接口通了，但業務真的“通”了嗎？

從研發樣件走向量產，企業還要跨越研發、測試、制造和供應鏈之間的邊界。

蜂巢電子在實踐中發現，最容易出現問題的地方首先是上下游需求不一致。信息經過多個團隊傳遞后發生變化，上游已經調整，下游仍然沿用原來的要求。

另一個問題來自流程中的灰色地帶。企業流程不可能一次設計完成，隨著產品、客戶和組織發生變化，總會出現原有流程沒有覆蓋的新情況。

此外，系統很多，數據知識也很多，但是系統和系統之間到底哪些數據應該互通，要挖掘哪些數據及報表展示，沒有統一的說法，這樣就導致了數據孤島及系統孤島。

王勝航進一步強調，不同系統可能采用不同的數據格式、版本規則和業務語義。同一個零件、需求或測試狀態，在不同供應商和業務部門眼中，含義可能也不一致。即使建立了接口，數據也可能無法被對方理解和信任。

因此，從研發成果真正落到制造交付，重要的一點是，要做好系統之間的互聯互通和數據的活用。

袁光認為，引入多個系統時，應從業務的角度出發。系統展示什么、連接什么，由真實業務需求定義，再通過持續的PDCA循環補齊，才能發揮出流程和工具的最大價值。

在蜂巢電子的實踐中，當需求發生變化時，系統可以主動提示工程師哪些測試用例需要重新執行，哪些任務和版本可能受到影響。工程師減少了充當“傳話筒”的時間，才能將更多精力投入分析和創新。

AI可以放大成熟體系，也會放大混亂

如今，蜂巢電子已經在多個方向探索AI應用。企業內部搭建了虛擬導師，將工程數據和知識經驗提供給員工；在代碼開發環節引入AI IDE，用于輔助代碼生成、低級錯誤檢測和軟件單元測試生成；通過自研AI Agent，對軟件缺陷進行分析和自動流轉。

王勝航表示，AI在研發場景中更像一個放大器。企業要先把需求、設計、測試和缺陷之間的關系管理清楚，再利用AI提升分析和執行效率。如果研發流程本身沒有被結構化，灰色地帶仍然大量存在，AI獲得的上下文就不會完整。它可以放大一套成熟體系，也可能放大數據缺失、版本混亂和流程不一致。

關鍵還在于，AI需要嵌入工程師日常使用的系統和流程，而不是成為研發鏈條外的又一個孤島。

如果工程師完成一項工作后，還要把數據手動復制到另一個AI系統中重新處理，AI不僅沒有減負，反而增加了一道流程。真正的智慧研發，應當讓AI“長”在研發數字主線上，在工程師工作的同時理解項目背景。

同時，企業數據也決定了AI能力的差異。通用大模型可以提供廣泛知識，卻不了解一家企業多年積累的設計規范、問題記錄乃至客戶要求。模型基礎能力逐漸趨同后，企業自身的工程上下文，將成為決定AI應用效果的重要變量。

從“被動響應”到“提前預判”，還有多遠？

站在未來三年的尺度上，袁光認為，汽車電子研發可能從被動響應需求，逐漸轉向提前預判。

企業可以基于已有產品平臺、用戶反饋和市場數據預測客戶需求，提前完成一部分技術預研。工程師和專家積累的排故經驗、設計規范和項目知識，也將進一步轉化為系統可調用、AI可學習的企業資產。

AI則會批量處理更多規則明確的常規任務，工程師將精力轉向系統架構、產品判斷和創新。

研發與制造之間的邊界也會繼續被打通。研發端的軟件版本、測試標準和工藝參數更快地傳遞到生產線，制造端的設備和質量數據再反向進入研發流程。

類似的邏輯也可以延伸到生產運維環節。比如先通過Maximo等軟件連接設備數據和維護流程，再利用AI識別異常、輔助質量檢測和預測性維護。

但這一轉變不會通過一次性建設一個龐大的AI平臺完成。

王勝航建議，企業首先應選擇痛點明確、數據基礎相對成熟的業務場景，例如需求歧義檢查、測試用例輔助生成或生產質量檢測。場景跑通后，再用效率、質量和風險等業務指標驗證價值，逐步復制到更多環節。

軟件定義汽車，把汽車變成了持續更新的產品，也把研發變成了一場永不停歇的系統工程。未來企業間的差距，不只在于誰先做出新功能，更在于誰能讓一項需求，在成百上千個版本、團隊和供應商之間，始終不失真、不走樣。當速度成為常態，支撐速度的體系能力，才是最深的護城河。