过去一年，大模型给工程师的感受有点复杂。
在很多软件开发场景里，AI写代码、补测试、改脚本已经进入日常开发流程。可到了汽车软件这里，事情没那么简单。底盘控制、电池管理、嵌入式软件这些工作，往往要经过严格的验证和测试，每一个开发环节都需要留下清晰记录，最终才能进入量产流程。
AI大模型到底能给汽车研发带来什么变化？它能帮助工程师提升研发效率吗？
在2026 MathWorks中国汽车年会上，MathWorks嵌入式软件及认证产品经理Tom Erkkinen给出了他的答案。AI可以从聊天窗口走进MATLAB®和Simulink®，去建模型、跑仿真、分析结果，甚至参与模型重构；但它面对的，是一套已经在汽车和航空航天领域里成熟运转几十年的工程体系。
MathWorks嵌入式软件及认证资深产品经理Tom Erkkinen
这也决定了MathWorks引入AI的方式会更克制。它没有让AI游离在现有开发体系之外，而是让AI在既定的工程流程中完成建模、分析和仿真等工作，所有过程都能够被工程师跟踪、验证和管理。
理解了这一点，再看MATLAB MCP Core Server、MATLAB Agentic Toolkit和Simulink Agentic Toolkit，就不会只把它们看成几个新功能名。
它们其实都在回答同一个问题：AI进入工程流程之后，如何保持可靠、可追溯和可验证。
01 .AI进入汽车软件，先要过工程这一关
MathWorks在思考大模型进入汽车软件开发时，首先关注的并不是模型能力本身，而是一个更实际的问题：AI生成的模型、代码和测试结果，如何融入车企现有的开发、验证和量产流程。
在互联网应用、数据处理、内部工具这些场景里，AI写出来的代码只要能跑通测试，就已经能省下不少时间。开发者可以先用它搭一个版本，再慢慢优化。
汽车软件不能这么做。
底盘控制、电池管理、嵌入式控制器上的一段逻辑，往往从需求阶段就要被记录，之后会进入一套完整的开发和验证流程。无论是模型调整还是代码修改，都需要留下记录，并能够追溯到具体原因以及可能受到影响的部分。
对于汽车工程师来说，大模型带来的，往往是一种期待与谨慎并存的心态。
它确实能理解需求、生成代码，也能帮人查工具、写测试。但它的输出如果每次都有差异，推理过程又说不清，工程师就很难把它当成开发流程里的稳定环节。
更重要的问题是，这些由AI生成的结果，能否顺利进入后续的验证、审查和量产流程。
MathWorks在大会中提到，大模型进入工程开发后，仍然会面临一些绕不开的问题。
例如结果缺乏可解释性、输出存在随机性、开发过程难以完整追溯，以及在复杂系统中的一致性和规模化应用挑战。这些问题在不少软件项目中并不会立刻成为障碍，团队往往可以通过代码审查、持续迭代和后续维护逐步解决。放到汽车软件里，余地小得多。
一段控制代码进了车，它面对的是几年的产品生命周期、复杂工况和功能安全要求，不是一版可以随时回滚的小程序。
这也是基于模型的设计（MBD，Model-Based Design）能够在汽车行业长期应用的重要原因。基于模型的设计看起来是用模型替代一部分手写代码，实际更重要的是把需求、模型、仿真、代码和测试串在一起。工程师改了哪里，为什么改，影响了哪个模块，后面都要能顺着链路追溯回去。
流程虽然笨重，但它给复杂系统留下了证据。
有了这个前提，MathWorks引入GenAI的方式就更好理解了。它选择的是把AI纳入现有开发体系，而不是重新搭建一套独立于工程流程之外的工作方式。
更合适的做法，是让AI进入MATLAB和Simulink这些已有工具，在工程师熟悉的环境里建模、分析、仿真、重构。AI可以承担更多操作，但结果仍然保留在原来的工具链里，继续接受验证和管理。
MATLAB MCP Core Server、MATLAB Agentic Toolkit和Simulink Agentic Toolkit等新功能，本质上都是围绕这一思路设计的。MathWorks希望让AI真正参与到建模和仿真工作中，但参与的方式仍然建立在现有工具链之上。
对于汽车研发来说，可靠性、可追溯性和可验证性这些要求并不会因为AI的加入而改变，它们依然是整个开发流程赖以运行的基础。
02 .让大模型成为工具链里的操作员
在汽车软件开发领域，讨论AI与代码开发时，很容易把不同性质的工作混在一起。
工程师日常会写很多代码。比如MATLAB脚本、测试脚本、参数处理脚本，用来搭模型的命令，或者一些自动化工具里的辅助代码。这些代码更多服务于研发过程，帮助工程师组织模型、运行仿真、检查结果、减少重复操作。
还有一类代码更敏感。它最后要进入量产流程，可能会运行在ECU、域控制器或者其他嵌入式硬件上，和底盘、电池、动力系统这些功能绑在一起。这类工程代码要经过验证、审查和功能安全流程，不可能因为大模型能生成一段C/C++，就直接被放进车里。
把 AI 引入汽车软件开发流程后，如何划定自己的边界？
MathWorks的做法，是先让大模型进入工具使用层。它可以帮工程师写脚本、生成测试、创建或修改Simulink模型，运行仿真，分析结果，也可以调用已有工具完成一些自动化操作。到了真正需要生成量产代码的时候，流程仍然回到MBD原有链路里，由经过验证的模型，以及Embedded Coder、Polyspace等工具来承接。
这一点恰恰体现了MathWorks对AI的定位。它希望AI能够参与研发过程，但并不承担最终工程结果的输出责任。相比直接生成最终成果，大模型更像是工程师身边的助手，负责理解需求、组织任务、调用工具，把原本需要人工完成的一部分操作自动执行起来。
MATLAB MCP Core Server解决的就是“怎么让AI进入工具”的问题。
过去工程师用大模型，大多是在聊天窗口里问问题。大模型给出一段代码、一种思路，或者一份操作建议。工程师觉得有用，再回到MATLAB和Simulink里自己动手。MCP 是大模型的通用接口，接入工具之后，AI Agent可以直接和MATLAB、Simulink交互，调用工具执行脚本、创建模型、修改模块、启动仿真，再根据结果继续调整。
但连上工具，只是第一步。
用过MATLAB和Simulink的人都知道，即使面对同一个问题，不同经验水平的工程师往往会采用完全不同的实现方式。很多能力工具箱里本来就有，新手可能会绕远路重新写一遍；模型层级怎么搭，模块怎么拆，测试怎么组织，也都不是随便拼一拼就行。
大模型进入这个环境，也会遇到类似问题。它可能知道语法，也能生成一段看起来没错的MATLAB代码，但未必知道在MathWorks的工具体系里，哪种做法更省事、更稳定、更符合工程习惯。
MATLAB Agentic Toolkit和Simulink Agentic Toolkit解决的，正是大模型对工具理解不够深入的问题。它们把MathWorks对自家工具的使用经验整理成Skills，告诉大模型在这个环境里应该怎样写脚本、怎样理解和修改模型、什么时候调用已有函数，什么时候生成测试，怎么少走弯路。
Skills 还有一个很现实的作用：帮助大模型用更少的 Token 得到更好的输出。AI 真正在企业里跑起来以后，这也是一笔工程账。对一个工程团队来说，AI 能不能用，除了效果，也要看成本。
MathWorks 并没有用 AI 重构原有工程体系，而是在 MATLAB 和 Simulink 工作流上增加一层智能化能力。
AI 负责理解工程师意图，调用工具，执行一部分建模、仿真和分析操作；模型验证、代码生成、功能安全和工程追溯这些更重的环节，仍然沿着 MBD 原有流程运行。
03 .从建模到重构：AI 会接手哪些工作
把AI接进工具链之后，最直接的变化，是工程师不用再把很多操作拆成一条条命令自己执行。
Tom在发布会上演示了一个F1赛车模型的例子，很适合说明MathWorks想让AI承担什么工作。
工程师给出一段需求，让AI根据架构要求创建一个F1赛车的Simulink模型。接下来，AI Agent通过MCP进入Simulink，读取需求和参数，调用建模相关的Skills，再开始搭子系统。
这里的关键并不是AI“凭空设计一辆赛车”。它做的事情更像一个熟练的建模助手：按照已有架构，把发动机、能量回收系统、传动、制动、车辆动力学这些部分搭出来。模型里的模块，仍然来自MathWorks或用户已经准备好的模块库。AI负责调用、组合和连接，底下用的还是经过审核的工具和模块。
模型搭完之后，AI还可以继续往下走。它能启动仿真，读取仿真结果，看圈速、能量状态、车辆动力学表现这些数据。如果结果不对，比如电池能量提前耗尽，AI可以回到参数里做调整，再重新运行仿真。
这类工作过去并不一定难，但很耗时间。工程师要在需求、模型、参数、仿真结果之间来回切换。模型越大，切换成本越高。AI进入Simulink之后，更大的意义在于把原本分散的操作串成一条连续流程。工程师不用频繁在不同环节之间来回跳转，可以把更多精力放在分析结果和做工程判断上。
另一个很典型的场景是模型重构。
很多团队的Simulink模型用久了之后，都会变得越来越重。层级变深，接口变乱，模块之间的连接也会变得不够清楚。发布会上展示的重构案例里，AI对一个已有模型做结构整理，把模型深度从4层减到2层，容器数量从16个减到8个，顶层接口也变得更清晰。
这类能力或许没有自动生成模型那么吸引眼球，但在实际研发中往往更实用。很多Simulink模型的问题并不在功能本身，而是长期迭代带来的结构复杂度。层级变深、接口增多、模块关系混乱，都会增加维护成本。让AI先完成分析和初步重构，再由工程师确认和调整，效率会高得多。
问题排查也是类似逻辑。AI可以读取现有Simulink模型，帮助发现异常，创建测试，复现问题，再把结果交给工程师判断。
它不替工程师承担最终结论，但可以把“找问题”的前半段做得更快。
MathWorks这次展示的重点，并不是打造一个无所不能的AI工程师，而是让AI接手建模、仿真、重构、测试生成和问题复现等重复性工作，把工程师从繁琐操作中解放出来。
当这些重复性的工作开始由AI承担，工程师也能把更多精力放在更高维的问题上。最终的架构决策、需求判断和结果评估，仍然需要工程师负责。AI并没有替工程师做决定，它更多是在处理那些耗时但价值相对有限的重复工作，把时间重新还给工程师。
结语从上世纪90年代飞控软件开始，基于模型的设计一路进入汽车行业，MathWorks也逐渐成为这套研发方法的重要推动者。通过MATLAB和Simulink，它把需求、建模、仿真、验证、代码生成和测试连接起来，让复杂系统的开发过程变得更加系统化和可追溯。
AI时代到来之后，MathWorks也开始探索如何让智能体参与研发过程，帮助工程师完成更多工作。
大模型不是要推翻过去几十年的工程体系，而是在原有基础上进一步提升研发效率，让工程师把更多精力放在系统设计和工程判断上。
这或许才是AI进入汽车研发更现实的方式。它未必以颠覆者的姿态出现，而是先成为工程师身边更懂工具、更能执行任务的助手。
当越来越多日常工作被接手，效率提升也会从产品演示，逐渐变成工程师每天都能感受到的变化。