晚高峰，車機自動調暗燈光、播放音樂——對駕駛者是瞬間的舒適，對研發者卻是一場牽動座艙、車身、傳感器、數十個軟體版本的「極限協同」。今天的汽車，正從交通工具變成「移動智能空間」，每增加一種體驗，研發鏈條上就多出一批需求、接口、版本和測試任務。車越來越懂人，造車這件事卻變得越來越複雜。
當產品開發周期從「年」壓縮到「月」甚至「周」，過去依靠會議、表格和人工確認維持的研發方式開始承壓：客戶需求會不會在層層分解後走樣？硬體接口改變後，軟體和測試是否仍在使用舊版本？一項變更究竟會影響多少模組、測試任務和供應商？
在本期《新「智」中國行 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平台完成。
王勝航建議，企業首先應選擇痛點明確、數據基礎相對成熟的業務場景，例如需求歧義檢查、測試用例輔助生成或生產質量檢測。場景跑通後，再用效率、質量和風險等業務指標驗證價值，逐步複製到更多環節。
軟體定義汽車，把汽車變成了持續更新的產品，也把研發變成了一場永不停歇的系統工程。未來企業間的差距，不只在於誰先做出新功能，更在於誰能讓一項需求，在成百上千個版本、團隊和供應商之間，始終不失真、不走樣。當速度成為常態，支撐速度的體系能力，才是最深的護城河。
