芝能科技出品
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每次给不同的答案
大模型生成的代码怎么确保可信，用很直白的说法来概括用户最大的顾虑："你给它相同的输入，可能它会给出不同的结果。"这句话切中了汽车行业对生成式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时代，这才能为工程师构筑一个值得信赖的根基
