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