一年一度的MathWorks中国汽车年会，今年在深圳举办。嵌入式软件及认证产品经理Tom Erkkinen接受了一场将近一小时的群访，话题自然绕不开生成式AI——当这股浪潮涌进汽车软件工程领域，工程师手里的MATLAB和Simulink还怎么用？MBD（基于模型的设计）这套被验证了几十年的方法论会不会被碘伏？大模型写出来的代码，谁敢信？

Tom的回答给出了一个很清晰的框架。他用了一个词来定义生成式AI与工程师、与MBD之间的关系——“合作关系”。

01 生成式AI找人干活

生成式AI在工程软件开发的角色

MathWorks去年10月发布了MATLAB MCP Core Server，这是一个通用协议，让任何大语言模型都能通过这个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提供的方案，就是让大语言模型正确使用和运行MATLAB和Simulink中那些已经被验证过的工具，这些工具产出的东西是确定性的。

大语言模型的创新能力确实很强，可如果你要让它落地、让它工程化、产品化，怎么让它的产出从不确定性变成确定性？这正是MBD工作流与工具链的价值所在。这个方案的聪明之处在于把生成式AI的不确定性约束在一个可控的范围里。范围的边界是：生成式AI负责理解需求、调用工具、设计任务，而工具负责执行。执行的结果是确定性的、可追溯的、已被认证的。生成式AI目前尚不具备直接触达产品代码的能力。

当然，对于手写代码的用户，Tom认为直接用大模型生成代码也行——前提是那些代码不用于安全关键系统。目标不同，需求不同。对于工程化、安全关键系统，代码质量有门槛、必须符合功能安全，那就得用另一套玩法了。

02 工程师会比写代码更值钱

产品开发的节奏

被问到未来三到五年AI Agent会如何改变汽车工程师的日常工作，Tom先是反问了一句“你说的是Simulink Copilot吗”，然后给出了一个可能会让很多写代码的工程师需要消化一阵的判断。

Simulink Copilot出来以后，工程师要做的更多不是亲自去实现软件，而是让AI 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进行软件开发所生成的代码不存在追溯性缺失和不确定性的问题，因为Embedded Coder是经过26262认证的，每一次输入对应确定性的输出。

但大语言模型直接生成的代码想通过功能安全认证，挑战非常大。稍微改一下提示词，代码就变了，这是一个非常大的隐患。对于手写代码，Tom认为理论上也能通过认证——历史上手写代码通过认证的情况很多。大语言模型生成的代码逻辑上也能走同样的认证流程，但每一次微调带来的输出离散化特性，让认证的工作量绝不是一个倍增，而是好几个数量级的差距。

小结

生成式AI很强，但没有强到可以独自承担安全责任的程度。让生成式AI去调度已经被验证过的MBD工具链，而不是让AI自己写代码——这可能是目前最务实的路径。工程师的角色从实现者变成架构者和审核者，这一转变已经在发生。标准和认证还在争论阶段，短期内不会有一个让大模型生成的代码直接通过功能安全认证的成熟方案。但这恰恰准确地反映了汽车行业在引入生成式AI时所面临的工程现实：当一辆车的软件出故障可能涉及人身安全，任何一个不确定的输出来源都是不可接受的。工具链的价值，就是把大语言模型的不确定性限制在可控的范围内。而MathWorks的落脚点，正是要确保每年两次的发布始终高质量、可靠——尤其在AI时代，这才能为工程师构筑一个值得信赖的根基。