芝能科技出品
MathWorks 2026年中國汽車年會上，嵌入式軟件及認證產品經理Tom Erkkinen接受了一場將近一小時的群訪。
當生成式AI來了以后，汽車軟件工程師手里的MATLAB?和Simulink?還怎么用？MBD（Model-Based Design）這套做了幾十年的方法論會不會被顛覆，大模型寫出來的代碼怎么讓人信？
MathWorks嵌入式軟件及認證產品經理Tom Erkkinen
Tom的回答給出了很清楚的框架，生成式AI和工程師，和MBD的關系，用了一個詞來定義“合作關系”
生成式AI找人干活
● 生成式AI在工程軟件開發的角色
MathWorks的MATLAB MCP Core Server是去年10月發布的，是一個通用的協議，讓任何大語言模型都可以通過這個Server去調用MATLAB和Simulink。
今年4月又發布了Agentic Toolkit，向大模型灌入MATLAB和Simulink的專家級知識，讓它寫出符合建模規范的代碼和模型。
給大模型裝了兩樣它本來沒有的東西：一是調用真實工程工具的接口，二是使用這些工具的最佳實踐。
如果讓一個大語言模型直接生成MATLAB代碼，它可能寫了幾十行去實現一個MATLAB自帶工具箱已經有的功能。有了Skills以后，大模型知道正確的做法是調用那個工具箱，一行就解決了。Token消耗大幅降低，產出的代碼也更快捷、更不容易出錯。
怎么用最小的Token消耗來產生最好的效果，往往是要依靠這些技能。
MathWorks做的是"不讓AI直接寫代碼，而是讓AI去找已經被驗證過的工具來干活。生成式AI像是一個知道哪個工具能解決什么問題的調度員，不是一個自己動手的工人。
● 生成式AI每次給不同的答案
大模型生成的代碼怎么確?？尚牛煤苤卑椎恼f法來概括用戶最大的顧慮："你給它相同的輸入，可能它會給出不同的結果。"這句話切中了汽車行業對生成式AI最深層的擔憂。
做功能安全的工程師習慣了確定性：同一條輸入進同一套工具鏈，出來的代碼應該是唯一的、可追溯的、可被驗證的。大語言模型的概率性本質，和這個要求天然沖突。
大模型無法直接產出產品級代碼，結合Agentic Toolkit， 正確使用和運行MATLAB和Simulink里對應的工具完成設計與驗證，調用Embedded Coder工具生成可部署的嵌入式代碼。MBD工具本身是經過ISO 26262認證的，它生成的代碼是確定性的。
MathWorks提供的offering，就是讓大語言模型正確使用和運行MATLAB和Simulink工具，這些工具都是已經驗證了的，它產生的東西是確定性的。
大語言模型的創新能力確實很強，可是如果你要讓它落地、讓它工程化、產品化，怎么讓它的產出從不確定性的變成確定性的，這就是MBD（Model-Based Design）工作流與工具鏈的價值。
這個方案的聰明之處在于把生成式AI的不確定性約束在一個可控的范圍里。范圍的邊界是：生成式AI負責理解需求、調用工具、設計任務。工具負責執行。
執行的結果是確定性的、可追溯的、已被認證的。生成式AI尚不具備直接觸達產品代碼的那一層。
對于手寫代碼的用戶，Tom認為直接用大模型生成代碼也行，只要那些代碼不用于安全關鍵系統。你的目標不一樣，需求不一樣。
對于工程化、安全關鍵系統，代碼質量有門檻、必須符合功能安全。手寫代碼的用戶如果不考慮工程化、產品化，不使用Simulink進行開發也沒問題。
工程師會比寫代碼更值錢
● 產品開發的節奏
被問到未來三到五年AI Agent會如何改變汽車工程師的日常工作，Tom先說了一句"你說的是Simulink Copilot嗎"，然后給出了一個可能會讓很多寫代碼的工程師需要消化一陣的判斷。
Simulink Copilot出來以后，工程師要做的更多的不是親自去實現軟件，是讓AI Agent去執行任務。讓Agent來生成規范化需求、生成測試用例、創建模型等。
工程師的角色從"寫代碼的人"變成了"定義目標和系統架構的人"和"評審AI產出的人"。從原來的軟件工程師更多focus在軟件實現，接下來更多要去做結果評審、系統決策、框架定義的工作，這一塊會更有價值。
這句話如果放到整個汽車軟件行業的發展脈絡里看，指向的是一個更深的變化。過去幾十年，汽車軟件工程師的核心競爭力是懂工具、能寫代碼、能跑通工具鏈。
當AI接走了實現的環節，競爭力會往兩頭走：一頭往上，定義系統的架構和目標；一頭往下，審核和驗證AI產出是否滿足安全和標準要求。
MathWorks R2026a發布了Simulink Copilot和Agentic Toolkit，讓生成式AI接管實現；Polyspace工具套件，包括Polyspace as You Code，把代碼分析和安全漏洞檢測下沉到開發窗口里。一頭放，一頭收。
● 標準還在草稿階段
關于生成式AI生成代碼的認證問題，ISO 22440還在草稿階段，針對AI工具認證的章節大家都在爭論。ISO 26262對AI生成代碼目前還沒有成熟的實踐指引。
采用MBD (Model-Based Design) 進行軟件開發所生成的代碼不存在追溯性缺失和不確定性的問題，因為Embedded Coder是經過26262認證的，每一次輸入對應確定性的輸出。
但大語言模型直接生成的代碼想通過功能安全認證，挑戰非常大。你稍微改一下大語言模型的提示詞，代碼又不一樣了，這是一個非常大的隱患。對于手寫代碼，Tom認為理論上也能通過認證，歷史上手寫代碼通過認證的情況很多。
大語言模型生成的代碼邏輯上也能走同樣的認證流程，但每一次微調帶來輸出離散化的特性讓認證的工作量絕不是一個倍增，是好幾個數量級的差距。
生成式AI很強，但沒有強到可以獨自承擔安全責任的程度。讓生成式AI去調度已經被驗證過的MBD (Model-Based Design)工具鏈，而不是讓AI自己寫代碼。工程師的角色從實現者變成架構者和審核者。
標準和認證還在爭論階段，短期內不會有一個讓大模型生成的代碼直接通過功能安全認證的成熟方案。這恰恰準確地反映了汽車行業在引入生成式AI時所面臨的工程現實。當一輛車的軟件出故障可能涉及人身安全，任何一個不確定的輸出來源都是不可接受的。
工具鏈的價值，就是把大語言模型的不確定性限制在可控的范圍內。而MathWorks的落腳點，正是要確保每年兩次的發布始終高質量、可靠，尤其在AI時代，這才能為工程師構筑一個值得信賴的根基
