夜雨聆风
新能源软件工程师为什么会被 AI 焦虑击中
这可能是很多新能源软件工程师第一次真正感到焦虑的一年。
以前的压力主要来自项目节点、需求变更、问题单、标定试验和测试报告。现在又多了一个新问题：身边有人开始用大语言模型写脚本、改代码、生成测试用例、整理文档，甚至让 AI Agent 直接跑工程文件。你会发现，自己并不是不会开发，而是原来那套开发节奏突然显得有点慢。
尤其是长期做 VCU、BMS、MCU、热管理、底盘或智驾执行层的软件工程师，工作方式和互联网程序员不一样。很多交付物不是一个 Python 文件，而是需求文档、Simulink 模型、Stateflow 状态机、Embedded Coder 生成代码、AUTOSAR 接口、CAN 信号、MIL/SIL/HIL 测试、Polyspace 或模型规范检查报告。
所以，新能源汽车软件工程师的 AI 转型，不能照搬“让 AI 帮我写代码”的故事。真正要解决的是：怎样把大语言模型接入模型开发、测试验证和工程交付闭环。
一、焦虑不是因为 AI 很聪明，而是因为工程负担已经太重
在新能源软件项目里，很多工程师每天做的不是单一的“写代码”。更常见的节奏是：上午评审需求，下午改 Simulink 模型，晚上补测试用例；第二天问题单来了，再去翻日志、查信号、对版本、补说明。
真正消耗人的，往往不是最核心的控制算法，而是大量低风险、高重复、却又不能出错的工程劳动。比如把需求拆成信号表，检查状态机转移条件，整理 DTC 触发逻辑，给评审会准备变更说明，根据模型接口补测试点。
AI 之所以让人焦虑，是因为它首先冲击的正是这些工作。它不需要完全理解一台车，也能在文档整理、边界条件枚举、脚本生成、日志摘要、代码解释上明显提速。
图 1：MathWorks 官方 MATLAB MCP Core Server 已经把 MATLAB 与 Claude Code、VS Code、GitHub Copilot 等 agentic AI 应用连接起来。它说明 AI 正在进入工程工具链，而不只是停留在聊天窗口。来源：GitHub / matlab/matlab-mcp-core-server。
二、Simulink 工程师用 AI，第一步不是让它画模型
很多人一听到 AI 接入 Simulink，就会想到“让 AI 自动搭模型”。这个方向可以探索，但不应该是第一步。原因很简单：量产软件模型不是一张能跑起来的框图那么简单，它背后有接口约束、采样时间、数据类型、状态机优先级、故障降级、代码生成规则和测试证据。
更现实的第一步，是让 AI 先参与那些更容易验收的环节：读需求、拆信号、列边界条件、解释历史模型、生成测试用例草稿、整理问题排查路径。AI 给出的是草稿和假设，工程师负责判断、修正和验证。
图 2：AI 不是绕过工程师，而是进入需求、模型、测试和交付之间的协作闭环。没有验证约束的 AI 提效，很容易把风险写得更快。
三、真正的变化：工程师从执行者变成 AI 工作流组织者
过去，一个工程师的价值很大程度体现在“我能把这个模型搭出来”“我能把这段 C 代码写出来”“我能把这个问题定位出来”。这些能力仍然重要，但未来会多出一层能力：你能不能把任务拆成 AI 能协作的输入、约束和验收标准。
一个会用 AI 的新能源软件工程师，不是把保密项目文件一股脑丢进聊天框，而是知道什么可以给 AI，什么不能给；什么可以让 AI 起草，什么必须自己确认；什么输出可以直接作为参考，什么输出必须经过 MIL、SIL、HIL 或代码审查验证。
| 开发环节 | AI 适合做什么 | 工程师必须守住什么 |
|---|---|---|
| 需求分析 | 提取功能点、信号、状态、边界条件和异常路径 | 需求原文、接口定义和安全目标必须人工确认 |
| 模型开发 | 解释子系统职责，辅助设计 Stateflow 状态和转移表 | 采样时间、数据类型、代码生成约束不能交给 AI 猜 |
| 测试验证 | 生成测试点、故障注入场景和覆盖率缺口清单 | 测试结果、覆盖率报告和问题关闭必须可追溯 |
| 问题定位 | 根据日志、DTC、版本差异生成排查假设 | 根因必须通过复现实验或数据证据确认 |
四、第一个可落地的 AI 工作流：从五类任务开始
如果你现在还没有系统使用 AI，不要一开始就追求“全自动开发”。更稳妥的做法，是先挑五类任务：它们重复、耗时、输入相对明确，而且输出容易被工程师验收。
图 3：第一阶段先让 AI 进入低风险、高重复、可验收的任务。工程师要守住保密、评审和测试三条底线。
1. 需求拆解
把一段控制需求整理成信号表、状态表、异常路径和测试点。这里 AI 的价值不在于替你决定策略，而在于帮你发现漏掉的边界条件。
2. 模型阅读
接手历史 Simulink 模型时，可以先让 AI 根据模块命名、接口说明、注释和导出的结构信息生成阅读笔记。它不一定完全正确，但可以帮你更快建立第一张地图。
3. 测试用例草稿
AI 很适合根据需求生成等价类、边界值、状态迁移和故障注入场景。最终用例仍然要由工程师结合工具链、测试环境和项目规范确认。
4. 问题单排查
当你手里有 CAN 日志、DTC、版本变更记录和现象描述时，AI 可以帮你整理排查假设。但它不能替你完成复现，也不能替你证明根因。
5. 工程文档
评审材料、变更说明、测试报告摘要、问题关闭记录，这些都适合让 AI 起草。工程师要做的是补事实、删废话、加证据。
五、为什么这件事现在必须开始
过去，AI 和 MATLAB/Simulink 的距离比较远，很多工程师觉得它只是帮人写一点脚本。现在情况在变化。MathWorks 已经发布 Simulink Copilot，用生成式 AI 辅助模型解释和 Model-Based Design 工作流；MATLAB MCP Core Server 则把 MATLAB 连接到 Claude Code、GitHub Copilot、OpenAI Codex、Gemini CLI 等 agentic AI 应用；MATLAB Agentic Toolkit 进一步提供面向 AI coding agents 的技能和配置。
这说明一个趋势：AI 正在从“问答工具”变成“工程工具链的一部分”。未来的竞争差距，不只是会不会使用某个聊天机器人，而是能不能把需求、模型、代码、测试和文档组织成一套可验证的 AI 协作流程。
图 4：MATLAB Agentic Toolkit 把工程技能、配置和工具链能力提供给 AI agents。对 Simulink 工程师来说，关键不是追逐概念，而是理解 Skills、MCP tools 与验证流程如何分工。来源：GitHub / matlab/matlab-agentic-toolkit。
六、这轮转型的底线：AI 可以提效，不能替你背责任
新能源汽车软件不是普通网页应用。一个状态机优先级写错，一个数据类型溢出，一个故障降级路径遗漏，都可能带来真实的车辆风险。
所以，本系列不会把 AI 包装成万能工具。相反，我们会一直强调三件事：第一，AI 输出必须能被工程流程验收；第二，安全相关逻辑必须保留人工责任和证据链；第三，所有提效都不能绕过测试、评审和版本管理。
真正值得学习的，不是某个神奇提示词，而是 AI 与工程验证之间的闭环。
从下一篇开始，我们会进入更具体的操作：一个 Simulink 工程师应该怎样搭建自己的 AI 工作台，怎样写提示词，怎样让 AI 帮你拆需求、读模型、写测试，又怎样避免把不该交给 AI 的东西交出去。
参考资料
[1] MathWorks：Simulink Copilothttps://www.mathworks.com/products/simulink-copilot.html
[2] MathWorks：MATLAB MCP Core Serverhttps://www.mathworks.com/products/matlab-mcp-core-server.html
[3] GitHub：matlab/matlab-mcp-core-serverhttps://github.com/matlab/matlab-mcp-core-server
[4] MathWorks Blog：Introducing the MATLAB Agentic Toolkithttps://blogs.mathworks.com/matlab/2026/04/13/introducing-the-matlab-agentic-toolkit/
[5] GitHub：matlab/matlab-agentic-toolkithttps://github.com/matlab/matlab-agentic-toolkit
[6] GitHub Docs：What is GitHub Copilothttps://docs.github.com/en/enterprise-cloud@latest/copilot/get-started/what-is-github-copilot