1975年，IBM工程師Fred Brooks在《人月神話》中提出軟體工程的核心難題：隨著系統規模和團隊規模增長，複雜度會呈指數級上升。他的結論是，軟體工程“沒有銀彈”，沒有單一技術能帶來數量級的生產力提升。
50年後，汽車行業正在經歷軟體工程史上最大規模的挑戰之一。
吉利汽車數智中心AI產品專家阮航透露了一組數字：過去幾年，吉利內部軟體開發人員佔比從不到10%躍升至40%。當一輛智慧汽車的程式碼量突破億行，當座艙、智駕、底盤等異構系統需要在不同晶片上協同工作，Brooks描述的複雜度問題被放大了數百倍。
不過這一次，車企找到了不同的應對方式。自2025年上半年開始，短短幾個月時間，吉利汽車已有數千人研發使用通義靈碼，AI生成佔比超過30%，尤其在通用程式碼邏輯開發、程式碼檢查測試環節，程式碼開發效率提升20%。
與阿里雲通義靈碼的深度合作，正在探索一個可能：AI會是Brooks說的那個“銀彈”嗎?
“軟體”汽車
人員結構的劇變，對映的是汽車產業本質的轉變。
“過去汽車是硬體主導，軟體只是輔助。現在軟體決定了產品的核心體驗。”阮航說。這種轉變帶來的，是開發模式和產品複雜度的“Double Kill”。
首先是迭代速度的加快。傳統面向硬體的V模型開發週期以年計，如今要支撐月級甚至周級的OTA迭代，必須轉向“敏捷+DevOps”模式。與此同時，產品複雜性也在同步增長。汽車行業正經歷電子電氣架構從分散式ECU向中央計算和區域架構的演進，面向服務架構（SOA）的引入，讓系統整合的複雜度呈指數級增長。
以吉利為例，研發體系需要同時應對座艙域的Linux/Android、智駕域的QNX，以及車身控制域廣泛採用的AUTOSAR平臺。應用層多用Java/Python，底層則依賴C/C++。如何讓這些異構系統在不同晶片生態上高效、安全地協同工作，是極其複雜的系統工程。
更具挑戰性的是守住安全底線。汽車軟體開發必須遵從ISO 26262功能安全、ISO/SAE 21434資訊安全，以及ASPICE等極其嚴格的國際認證標準。特別是在底層開發中，還需要遵循MISRA C/C++等嚴苛的編碼規範。這些標準確保了汽車的極致安全，但也天然地與快速迭代的敏捷開發模式存在張力。
看清了系統性挑戰的本質後，吉利明確了以AI技術提升研發效率的路線，與阿里雲通義靈碼的深度合作隨即展開。一系列採訪之後，我們得到了一個工程師變身“指揮官”的故事。
全方位AI
談AI落地，首先要談場景。所以，我們先呈現一個完整的場景概括，吉利的研發體系涵蓋應用層軟體研發、嵌入式開發和演算法研發三大板塊。一言以蔽之：目前通義靈碼等AI手段正在全面滲透。
其中，應用層軟體研發團隊對通義靈碼的應用最為深入，覆蓋了智慧座艙HMI、車聯網服務等場景的快速開發。工程師們頻繁使用通義靈碼來生成新服務的模板程式碼和資料轉換邏輯。
嵌入式開發是汽車軟體的“深水區”，以C/C++為主，對即時性、記憶體管理要求極高。在這一板塊，吉利正探索將AI能力引入底層開發場景，重點在於提升程式碼質量和合規性。
演算法研發領域，通義靈碼正在協助團隊處理PB級的雷達點雲資料和影片資料清洗工作。工程師可以透過自然語言描述資料清洗規則，AI自動生成對應的複雜資料處理指令碼。
對於最受關注的提效指標，阮航給我們講了一個專案案例。一個原本30天的專案，透過通義靈碼加成，原本耗時10天的“編碼實現”環節，編寫程式碼從5人天縮減為4人天，註釋補全從1.5人天縮減為0.5人天，單元測試從2.5人天縮減為2人天，程式碼最佳化從1人天縮減為0.5人天。編碼階段效率提升30%，帶動專案整體提效10%。考慮到吉利汽車是一個相當龐大的組織，眾多專案累加可得的收益是相當可觀的。
每個深度使用AI的工作者講到大模型的痛點，一定會談的必然包括“幻覺”。其實用幻覺描述也不一定準確，講“模型對不瞭解的事情容易胡說八道”更能讓人感同身受。
所以，規模化應用也很快引出了另一個關鍵問題：通用大模型需要精準理解吉利的技術棧和業務邏輯。如果AI生成的程式碼不符合企業規範或者無法呼叫內部API，它的價值將大打折扣。“我們需要AI能理解吉利的業務上下文，而不僅僅是通用程式碼。”阮航說。
不過阿里雲和吉利汽車各自的能力組合，很大程度躍過了這個山脈。
阿里雲通義靈碼解決方案專家賈彬介紹了通義靈碼的特點：它本質上是一個高階的編碼智慧體（Coding Agent），結合 RAG（檢索增強生成）和MCP（模型上下文協議）等技術，能夠深度融合企業的私有知識庫。
吉利的工作，則是構建一個高質量的，包含了私有程式碼庫、API文件和技術規範的“專有知識庫”提供給大模型。這樣就能構建起一個高度精準的上下文環境，能更好利用大模型的推理能力解決研發問題。
這種配合機制，確保了AI不僅“會寫程式碼”，還“會寫吉利的程式碼”。例如，當工程師需要呼叫吉利內部的車控服務API時，通義靈碼能夠準確提示API的呼叫方式和引數規範，並遵循統一的錯誤處理機制。
當然，為了適應吉利複雜的開發環境和極高的安全要求，通義靈碼支援企業專屬版部署，確保核心程式碼資產不出企業內網。雙方透過VPC專線等方式實現了網路隔離與安全接入。
不只是提效
所以，大規模的人數使用，讓AI工具的價值在不同維度顯現出來。
最直觀的是效率提升。大量模板化、重複性工作被交給AI，工程師可以聚焦於系統架構設計和核心業務邏輯的創新。質量維度的改善同樣明顯，透過與CI/CD流水線等研發工具鏈的整合，通義靈碼可以在編碼階段就進行邏輯預檢，提升程式碼的規範性和健壯性。
但效率和質量的提升，還不是AI工具的所有價值。
軟體工程領域有一個著名概念叫“技術債”——因過去妥協而積累的、需要未來償還的維護成本。對於汽車這樣長生命週期的產品，龐大的遺留系統就是最主要的“債務”來源。維護和迭代這些遺留程式碼的挑戰尤為嚴峻，很多程式碼之所以存在，可能是為了繞過特定的硬體約束，或者是為了處理某些複雜的工況。
如果不理解其原始的設計意圖就盲目修改，極有可能引入安全隱患。所以開發者之間常半開玩笑地說：“能跑就別動，動了就出事。”
知識傳遞需要藉助於人，但人會流動，這使得“償還技術債”變得更加困難，形成了所謂的“程式碼考古”困境。
“但這對AI不是問題，因為它能快速讀取程式碼，能幫你解釋遺留系統的複雜邏輯，看懂他人的開發邏輯。”賈彬說。
阮航分享了一個例項：一位新入職的工程師需要修改一個有著數年曆史的核心模組，透過通義靈碼的程式碼解釋功能，他得以快速理解原作者的設計意圖和複雜的依賴關係，將原本預估需要一週的熟悉過程縮短到了兩天。AI在這裡扮演了“知識管家”，甚至“任意門”的角色，讓經驗得以沉澱和複用，讓沉寂中的程式碼得以換一種方式新生。
這種傳送能力，在吉利的全球化協同中體現得更為明顯。作為一家在瑞典、德國、義大利等地均設有研發中心的全球化企業，吉利透過推進統一程式碼倉、統一研發工具、統一協同平臺來解決跨地域協同的問題。AI在其中扮演了越來越不可或缺的作用，促進了全球團隊在統一的AI輔助環境下工作，客觀上推動了編碼規範和研發流程的標準化。
依託阿里雲的全球基礎設施，通義靈碼支援吉利在多個研發中心實現“多地部署、就近接入”，確保全球開發者都能獲得低延遲體驗，同時滿足各地的資料合規要求。
AI的介入，也在改變人的角色。
我們就用開始提過的一個質量保障為例具體展開。傳統的程式碼評審是在提交後進行，由技術負責人手動稽覈。這種模式的問題在於：問題被發現時，程式碼已經寫完，修復成本高，還可能影響進度。阮航介紹，吉利正在推動質量“左移”（Shift Left），在開發的早期階段就發現並修復問題。
具體做法是：工程師在提交程式碼合併請求時，系統會自動觸發呼叫通義靈碼的API，讓AI代替技術負責人完成初步的、高頻的稽覈工作。例如檢查變數命名是否規範、是否有充分的異常處理、是否符合既定的安全編碼要求等。
這一轉變使得資深工程師的角色發生了變化，他們從“執行者”轉變為“規則制定者”，負責定義稽覈的標準，再交由AI去高效執行。而他們自己則可以聚焦於更復雜的系統架構和業務邏輯稽覈。
執行者到指揮官
所以，AI對於開發場景的影響是全方位的，AI對“人與程式碼”、“人與人”、“人與組織”的關係的影響也是全方位的。
這甚至涉及了一個業內廣泛關注的討論：“AI是否會進一步取代人類程式設計師?”阮航在採訪中分享了他的洞察。他認為，未來職業生涯受到挑戰的，其實是不使用AI的工程師。
“在我們內部，一直在推的一個思維就是：以後我們所有的員工都是Leader。我們要Lead誰?就是AI。我們要指揮AI，把原先我們自己在做的工作做得越來越好。”
從“一線執行者”到“AI指揮官”，人與AI顯然並非取代關係。但這意味著工程師的核心能力要求正在從“實現能力”轉向“定義問題、拆解任務和評估結果”的能力。在這個模式下，工程師更多是從設計、架構、驗收的視角去定義需求，真正的執行和操作交給AI。
“當前工程師和AI可能各佔一半，”阮航說，“但未來，我們希望工程師主導規則制定，AI承擔更多執行工作。”
吉利的終極願景是實現“黑燈研究院”：一個高度自動化的研發環境，從需求提出到部署交付的全流程，由AI與人類工程師協同完成。“當前我們已經搭建起智慧化軟體平臺，實現了從需求到交付鏈路的點狀能力閉環，”阮航說，“接下來希望將點狀能力連線成線狀能力，即實現從需求分析、程式碼生成到測試部署的自動化工作流，最終實現端到端的自動化交付。”
賈彬觀察到：AI正在向“自主智慧體”演進。隨著模型在長期記憶、規劃與決策上的能力提升，未來的智慧體將能夠承擔長時程任務，自動進行復雜的任務分解、資源排程與工作流編排。與此同時，非同步程式設計與雲端Agent的興起允許將子任務委派到雲端並行執行，工程師負責高層目標與策略制定，可以同時指揮多個Agent，實現更高的並行性與可擴充套件性，同時透過人類監督與回滾機制保證可控性與安全性。
但是指揮官這個新一代人類程式設計師的定位，顯然也讓產業出現了“一將難求”的問題。
阮航在雲棲大會的公開發言中就提出了一個呼籲：要共建AI程式設計的安全標準，共享軟體研發的優質實踐，共育新型人才。
這背後是對行業共同挑戰的洞察。對汽車行業來說，既懂機械硬體又精通軟體系統工程的交叉人才，是當前最急迫的需求。這個人才缺口不是個別企業能解決的。
不過，跨界對AI來說，從來都不是問題。或許，在AI降低了軟體開發的技術門檻後，更多機械背景的工程師也能參與到軟體開發中來。
吉利與阿里雲的合作，正在驗證這種可能性。當車企開始用軟體的方式思考問題，當雲廠商深入到製造業的具體場景，產業邊界的模糊或許正是創新發生的地方。
50年前，Brooks說軟體工程沒有銀彈。今天，AI或許不是那顆銀彈，但它正在改變我們尋找答案的方式。