大模型如何進入汽車研發(fā)？MathWorks選擇從工具鏈開始

過去一年，大模型給工程師的感受有點復(fù)雜。

在很多軟件開發(fā)場景里，AI寫代碼、補測試、改腳本已經(jīng)進入日常開發(fā)流程。可到了汽車軟件這里，事情沒那么簡單。底盤控制、電池管理、嵌入式軟件這些工作，往往要經(jīng)過嚴格的驗證和測試，每一個開發(fā)環(huán)節(jié)都需要留下清晰記錄，最終才能進入量產(chǎn)流程。

AI大模型到底能給汽車研發(fā)帶來什么變化？它能幫助工程師提升研發(fā)效率嗎？

在2026 MathWorks中國汽車年會上，MathWorks嵌入式軟件及認證產(chǎn)品經(jīng)理Tom Erkkinen給出了他的答案。AI可以從聊天窗口走進MATLAB?和Simulink?，去建模型、跑仿真、分析結(jié)果，甚至參與模型重構(gòu)；但它面對的，是一套已經(jīng)在汽車和航空航天領(lǐng)域里成熟運轉(zhuǎn)幾十年的工程體系。

MathWorks嵌入式軟件及認證資深產(chǎn)品經(jīng)理Tom Erkkinen

這也決定了MathWorks引入AI的方式會更克制。它沒有讓AI游離在現(xiàn)有開發(fā)體系之外，而是讓AI在既定的工程流程中完成建模、分析和仿真等工作，所有過程都能夠被工程師跟蹤、驗證和管理。

理解了這一點，再看MATLAB MCP Core Server、MATLAB Agentic Toolkit和Simulink Agentic Toolkit，就不會只把它們看成幾個新功能名。

它們其實都在回答同一個問題：AI進入工程流程之后，如何保持可靠、可追溯和可驗證。

01 .AI進入汽車軟件，先要過工程這一關(guān)

MathWorks在思考大模型進入汽車軟件開發(fā)時，首先關(guān)注的并不是模型能力本身，而是一個更實際的問題：AI生成的模型、代碼和測試結(jié)果，如何融入車企現(xiàn)有的開發(fā)、驗證和量產(chǎn)流程。

在互聯(lián)網(wǎng)應(yīng)用、數(shù)據(jù)處理、內(nèi)部工具這些場景里，AI寫出來的代碼只要能跑通測試，就已經(jīng)能省下不少時間。開發(fā)者可以先用它搭一個版本，再慢慢優(yōu)化。

汽車軟件不能這么做。

底盤控制、電池管理、嵌入式控制器上的一段邏輯，往往從需求階段就要被記錄，之后會進入一套完整的開發(fā)和驗證流程。無論是模型調(diào)整還是代碼修改，都需要留下記錄，并能夠追溯到具體原因以及可能受到影響的部分。

對于汽車工程師來說，大模型帶來的，往往是一種期待與謹慎并存的心態(tài)。

它確實能理解需求、生成代碼，也能幫人查工具、寫測試。但它的輸出如果每次都有差異，推理過程又說不清，工程師就很難把它當成開發(fā)流程里的穩(wěn)定環(huán)節(jié)。

更重要的問題是，這些由AI生成的結(jié)果，能否順利進入后續(xù)的驗證、審查和量產(chǎn)流程。

MathWorks在大會中提到，大模型進入工程開發(fā)后，仍然會面臨一些繞不開的問題。

例如結(jié)果缺乏可解釋性、輸出存在隨機性、開發(fā)過程難以完整追溯，以及在復(fù)雜系統(tǒng)中的一致性和規(guī)模化應(yīng)用挑戰(zhàn)。這些問題在不少軟件項目中并不會立刻成為障礙，團隊往往可以通過代碼審查、持續(xù)迭代和后續(xù)維護逐步解決。放到汽車軟件里，余地小得多。

一段控制代碼進了車，它面對的是幾年的產(chǎn)品生命周期、復(fù)雜工況和功能安全要求，不是一版可以隨時回滾的小程序。

這也是基于模型的設(shè)計（MBD，Model-Based Design）能夠在汽車行業(yè)長期應(yīng)用的重要原因。基于模型的設(shè)計看起來是用模型替代一部分手寫代碼，實際更重要的是把需求、模型、仿真、代碼和測試串在一起。工程師改了哪里，為什么改，影響了哪個模塊，后面都要能順著鏈路追溯回去。

流程雖然笨重，但它給復(fù)雜系統(tǒng)留下了證據(jù)。

有了這個前提，MathWorks引入GenAI的方式就更好理解了。它選擇的是把AI納入現(xiàn)有開發(fā)體系，而不是重新搭建一套獨立于工程流程之外的工作方式。

更合適的做法，是讓AI進入MATLAB和Simulink這些已有工具，在工程師熟悉的環(huán)境里建模、分析、仿真、重構(gòu)。AI可以承擔更多操作，但結(jié)果仍然保留在原來的工具鏈里，繼續(xù)接受驗證和管理。

MATLAB MCP Core Server、MATLAB Agentic Toolkit和Simulink Agentic Toolkit等新功能，本質(zhì)上都是圍繞這一思路設(shè)計的。MathWorks希望讓AI真正參與到建模和仿真工作中，但參與的方式仍然建立在現(xiàn)有工具鏈之上。

對于汽車研發(fā)來說，可靠性、可追溯性和可驗證性這些要求并不會因為AI的加入而改變，它們依然是整個開發(fā)流程賴以運行的基礎(chǔ)。

02 .讓大模型成為工具鏈里的操作員

在汽車軟件開發(fā)領(lǐng)域，討論AI與代碼開發(fā)時，很容易把不同性質(zhì)的工作混在一起。

工程師日常會寫很多代碼。比如MATLAB腳本、測試腳本、參數(shù)處理腳本，用來搭模型的命令，或者一些自動化工具里的輔助代碼。這些代碼更多服務(wù)于研發(fā)過程，幫助工程師組織模型、運行仿真、檢查結(jié)果、減少重復(fù)操作。

還有一類代碼更敏感。它最后要進入量產(chǎn)流程，可能會運行在ECU、域控制器或者其他嵌入式硬件上，和底盤、電池、動力系統(tǒng)這些功能綁在一起。這類工程代碼要經(jīng)過驗證、審查和功能安全流程，不可能因為大模型能生成一段C/C++，就直接被放進車里。

把 AI 引入汽車軟件開發(fā)流程后，如何劃定自己的邊界？

MathWorks的做法，是先讓大模型進入工具使用層。它可以幫工程師寫腳本、生成測試、創(chuàng)建或修改Simulink模型，運行仿真，分析結(jié)果，也可以調(diào)用已有工具完成一些自動化操作。到了真正需要生成量產(chǎn)代碼的時候，流程仍然回到MBD原有鏈路里，由經(jīng)過驗證的模型，以及Embedded Coder、Polyspace等工具來承接。

這一點恰恰體現(xiàn)了MathWorks對AI的定位。它希望AI能夠參與研發(fā)過程，但并不承擔最終工程結(jié)果的輸出責任。相比直接生成最終成果，大模型更像是工程師身邊的助手，負責理解需求、組織任務(wù)、調(diào)用工具，把原本需要人工完成的一部分操作自動執(zhí)行起來。

MATLAB MCP Core Server解決的就是“怎么讓AI進入工具”的問題。

過去工程師用大模型，大多是在聊天窗口里問問題。大模型給出一段代碼、一種思路，或者一份操作建議。工程師覺得有用，再回到MATLAB和Simulink里自己動手。MCP 是大模型的通用接口，接入工具之后，AI Agent可以直接和MATLAB、Simulink交互，調(diào)用工具執(zhí)行腳本、創(chuàng)建模型、修改模塊、啟動仿真，再根據(jù)結(jié)果繼續(xù)調(diào)整。

但連上工具，只是第一步。

用過MATLAB和Simulink的人都知道，即使面對同一個問題，不同經(jīng)驗水平的工程師往往會采用完全不同的實現(xiàn)方式。很多能力工具箱里本來就有，新手可能會繞遠路重新寫一遍；模型層級怎么搭，模塊怎么拆，測試怎么組織，也都不是隨便拼一拼就行。

大模型進入這個環(huán)境，也會遇到類似問題。它可能知道語法，也能生成一段看起來沒錯的MATLAB代碼，但未必知道在MathWorks的工具體系里，哪種做法更省事、更穩(wěn)定、更符合工程習(xí)慣。

MATLAB Agentic Toolkit和Simulink Agentic Toolkit解決的，正是大模型對工具理解不夠深入的問題。它們把MathWorks對自家工具的使用經(jīng)驗整理成Skills，告訴大模型在這個環(huán)境里應(yīng)該怎樣寫腳本、怎樣理解和修改模型、什么時候調(diào)用已有函數(shù)，什么時候生成測試，怎么少走彎路。

Skills 還有一個很現(xiàn)實的作用：幫助大模型用更少的 Token 得到更好的輸出。AI 真正在企業(yè)里跑起來以后，這也是一筆工程賬。對一個工程團隊來說，AI 能不能用，除了效果，也要看成本。

MathWorks 并沒有用 AI 重構(gòu)原有工程體系，而是在 MATLAB 和 Simulink 工作流上增加一層智能化能力。

AI 負責理解工程師意圖，調(diào)用工具，執(zhí)行一部分建模、仿真和分析操作；模型驗證、代碼生成、功能安全和工程追溯這些更重的環(huán)節(jié)，仍然沿著 MBD 原有流程運行。

03 .從建模到重構(gòu)：AI 會接手哪些工作

把AI接進工具鏈之后，最直接的變化，是工程師不用再把很多操作拆成一條條命令自己執(zhí)行。

Tom在發(fā)布會上演示了一個F1賽車模型的例子，很適合說明MathWorks想讓AI承擔什么工作。

工程師給出一段需求，讓AI根據(jù)架構(gòu)要求創(chuàng)建一個F1賽車的Simulink模型。接下來，AI Agent通過MCP進入Simulink，讀取需求和參數(shù)，調(diào)用建模相關(guān)的Skills，再開始搭子系統(tǒng)。

這里的關(guān)鍵并不是AI“憑空設(shè)計一輛賽車”。它做的事情更像一個熟練的建模助手：按照已有架構(gòu)，把發(fā)動機、能量回收系統(tǒng)、傳動、制動、車輛動力學(xué)這些部分搭出來。模型里的模塊，仍然來自MathWorks或用戶已經(jīng)準備好的模塊庫。AI負責調(diào)用、組合和連接，底下用的還是經(jīng)過審核的工具和模塊。

模型搭完之后，AI還可以繼續(xù)往下走。它能啟動仿真，讀取仿真結(jié)果，看圈速、能量狀態(tài)、車輛動力學(xué)表現(xiàn)這些數(shù)據(jù)。如果結(jié)果不對，比如電池能量提前耗盡，AI可以回到參數(shù)里做調(diào)整，再重新運行仿真。

這類工作過去并不一定難，但很耗時間。工程師要在需求、模型、參數(shù)、仿真結(jié)果之間來回切換。模型越大，切換成本越高。AI進入Simulink之后，更大的意義在于把原本分散的操作串成一條連續(xù)流程。工程師不用頻繁在不同環(huán)節(jié)之間來回跳轉(zhuǎn)，可以把更多精力放在分析結(jié)果和做工程判斷上。

另一個很典型的場景是模型重構(gòu)。

很多團隊的Simulink模型用久了之后，都會變得越來越重。層級變深，接口變亂，模塊之間的連接也會變得不夠清楚。發(fā)布會上展示的重構(gòu)案例里，AI對一個已有模型做結(jié)構(gòu)整理，把模型深度從4層減到2層，容器數(shù)量從16個減到8個，頂層接口也變得更清晰。

這類能力或許沒有自動生成模型那么吸引眼球，但在實際研發(fā)中往往更實用。很多Simulink模型的問題并不在功能本身，而是長期迭代帶來的結(jié)構(gòu)復(fù)雜度。層級變深、接口增多、模塊關(guān)系混亂，都會增加維護成本。讓AI先完成分析和初步重構(gòu)，再由工程師確認和調(diào)整，效率會高得多。

問題排查也是類似邏輯。AI可以讀取現(xiàn)有Simulink模型，幫助發(fā)現(xiàn)異常，創(chuàng)建測試，復(fù)現(xiàn)問題，再把結(jié)果交給工程師判斷。

它不替工程師承擔最終結(jié)論，但可以把“找問題”的前半段做得更快。

MathWorks這次展示的重點，并不是打造一個無所不能的AI工程師，而是讓AI接手建模、仿真、重構(gòu)、測試生成和問題復(fù)現(xiàn)等重復(fù)性工作，把工程師從繁瑣操作中解放出來。

當這些重復(fù)性的工作開始由AI承擔，工程師也能把更多精力放在更高維的問題上。最終的架構(gòu)決策、需求判斷和結(jié)果評估，仍然需要工程師負責。AI并沒有替工程師做決定，它更多是在處理那些耗時但價值相對有限的重復(fù)工作，把時間重新還給工程師。

結(jié)語

從上世紀90年代飛控軟件開始，基于模型的設(shè)計一路進入汽車行業(yè)，MathWorks也逐漸成為這套研發(fā)方法的重要推動者。通過MATLAB和Simulink，它把需求、建模、仿真、驗證、代碼生成和測試連接起來，讓復(fù)雜系統(tǒng)的開發(fā)過程變得更加系統(tǒng)化和可追溯。

AI時代到來之后，MathWorks也開始探索如何讓智能體參與研發(fā)過程，幫助工程師完成更多工作。

大模型不是要推翻過去幾十年的工程體系，而是在原有基礎(chǔ)上進一步提升研發(fā)效率，讓工程師把更多精力放在系統(tǒng)設(shè)計和工程判斷上。

這或許才是AI進入汽車研發(fā)更現(xiàn)實的方式。它未必以顛覆者的姿態(tài)出現(xiàn)，而是先成為工程師身邊更懂工具、更能執(zhí)行任務(wù)的助手。

當越來越多日常工作被接手，效率提升也會從產(chǎn)品演示，逐漸變成工程師每天都能感受到的變化。