AI 遇上 ECU 工程:汽车软件工程师的岗位还那么稳吗?

AI 写代码越来越像那么回事，每天都有新玩法出来，我所在的几个IT 开发者居多的微信群我都已经设置“消息免打扰”，每天都很热闹，从早到晚。相对来说汽车工程师的微信群就像尖子生的晚自习教室。也难怪这个被AI 抢工作的时代，都说程序员很焦虑，但是很少有焦虑的汽车软件工程师。

“别的行业不好说，我们应该还挺稳。AUTOSAR 那么复杂，还要考虑实时性、功能安全，上台架、做实车验证，AI 哪有那么容易替代？”

“前面Vibe Coding 热起来的时候跟着一起恐慌，后来就越来越见怪不怪了。”

这话有道理。但如果顺着它得出“所以我的岗位很安全”，恐怕得加一个时间定语。

AI 不需要独立完成整个 ECU 开发，才会影响工程师的岗位。它只需要让其中一部分工作，不再需要那么多工时。

查规范、改配置、补接口、整理日志、写测试初稿……这些工作，单独看都不是汽车软件最难的部分，合在一起却占用了不少时间。如果它们逐渐被自动化，岗位不会立刻消失，工作内容和用人方式却可能先发生变化。

所以，当前需要直面的问题不是汽车软件工程师会不会被替代，而是我们现在做的这些工作，是否仍然需要同样多的人？留给新人的工作机会还有多少？

一、AI辅助ECU开发的困境：代码是代码，工程是工程

不妨看一个 ECU 项目里并不陌生的场景。

一个通信相关的改动，代码生成了，编译通过了，基本功能也跑通了。但上了台架，在某种总线负载和任务组合下，报文偶发超时。

应用团队说接口调用没问题，基础软件团队说配置已经通过校验，供应商建议再抓一轮日志。

接下来怎么办？

继续改超时参数？检查任务调度？看缓冲区和队列？还是先确认测试条件与需求是否一致？

真正费时间的，往往是沿着这些线索收集证据，排除错误假设，找到根因，再证明修改没有带来新的问题。

这也是汽车软件工程师暂时不容易被整体替代的原因：写出代码只是一个环节，工程交付还要把需求、配置、软件行为和硬件条件对上。汽车软件软件开发是一个系统工程的一部分。

配置器没有报错，不代表系统行为正确；台架上跑通一次，也不代表时序、资源和故障响应都满足要求。对于涉及功能安全的部分，还需要与项目安全流程相匹配的验证和证据。

不过，这个判断也有范围。这里主要讨论 ECU、AUTOSAR 和嵌入式软件交付，不能直接套到所有汽车软件岗位上。座舱应用、云端服务、开发工具与底层控制软件，受到 AI 影响的方式和速度很可能不同。

汽车软件不是一整块，岗位的“安全系数”也不会只有一个答案。

二、AUTOSAR 很复杂，但复杂不全是护城河

“我们这行门槛高”，是另一种常见的安全感来源。

确实高。一个新人进入项目，要认识模块、理解接口、熟悉配置器，还要弄清楚供应商的约束和团队自己的规矩。光是让工程顺利生成、编译、运行，就可能踩不少坑。

但这些门槛，至少可以分成两类。

一类来自系统本身：实时约束、资源竞争、故障传播、硬件边界条件。这些问题需要分析和取舍。

另一类来自信息和工具：资料不好找，菜单层级深，报错不直观，操作步骤重复，有些知识只存在于老师傅的记忆里。

过去，两类经验都很值钱。AI 工具正在尝试降低的，首先是后一类门槛。

比如，AutonomousGuy 这类开源 Skills，尝试把汽车软件的领域上下文和作业方法整理成可复用的指引，让模型在分析代码、审查需求、排查问题时，不必每次都从零开始。

它并不因此成为可靠的汽车软件专家，更不能替代正式的安全分析和工程评审。但它代表了一种变化：原来需要反复口头传授的部分方法，开始变成团队可以共享的工具资产。

另一款AI辅助工具AutoC （需要氪金）的定位则更进一步：通过自然语言，在既有 AUTOSAR 配置器中完成配置和建模操作，让 AI 从“告诉你怎么改”，走向“通过工具执行修改”。

因为没有上手试用过，工具兼容性、复杂工程表现和异常处理能力，需要实际评估。但这个方向已经值得重视。

如果一个人的优势主要是“我记得参数在哪里，知道该点哪几个菜单”，那么工具越好用，这部分优势就越容易缩水。

这不是否定经验。真正需要区分的是：

知道某个参数在哪里，和知道为什么要这样配，不是一回事。

后者还要回答：它影响哪些模块？与哪些需求有关？出错会有什么表现？应该用什么测试确认？

一份经验是否稀缺，不能只看当年学它花了多久，还要看今天别人获得它需要付出多少成本。

三、AI 来开发，人来兜底？

聊到替代问题，汽车软件工程师还有一个很有底气的理由：

“最后总要有人负责吧？AI 又不能签字。”

没错。正式决策和工程责任，仍然需要由组织及授权人员承担。AI 给出的建议，不能自己批准、自己验证，再宣布自己符合要求。

但这只能说明责任不能随意转移，责任人仍然需要，并不意味着每一个执行步骤都必须沿用过去的人员配置。

假设某个团队借助 AI，减少了查资料、重复配置和测试初稿的工时，企业可以有不同选择：

• 用同样的人做更多项目；
• 补上过去来不及做的测试和质量工作；
• 减少加班，缩短交付周期；
• 放缓招聘，或者调整团队结构。

反过来，也不能因为“最终需要人负责”，就认为效率变化与岗位数量无关。

还有一个经常被忽略的成本：生成快了，评审未必跟得上。

如果 AI 一次生成大量改动，工程师却需要花更长时间核对上下文、发现隐含假设、补充测试，那么所谓提效可能只是把工作从编写端搬到了验证端。

衡量 AI 是否有用，要看一项变更从提出到验证关闭的总成本，而不是它几秒钟生成了多少行代码。

四、更值得担心的，也许是新人怎么成长

岗位讨论很容易被简化成两句话：初级工程师做重复劳动，所以危险；资深工程师有系统能力，所以安全。

事情没这么整齐。

资深工程师也可能把大量时间花在熟悉工具操作和协调信息上。年限长，并不意味着每一部分经验都难以替代。

新人则可能借助 AI 更快理解仓库、找到规范、梳理调用关系，不必在一些低价值障碍上卡太久。

但这里有个值得团队负责人认真考虑的问题：

如果入门工作越来越自动化，新人靠什么积累判断力？

很多人的系统理解，恰恰是从那些“不高级”的工作里长出来的：配错一次参数，追过一次调用链，看过一轮总线日志，才逐渐知道模块是怎样连起来的。

如果这些工作全部交给工具，新人只负责点确认，接触复杂项目的时间未必会自动转化为能力。

可为了培养人，就要求大家继续手工重复操作，也不是办法。

更合理的做法，是改变带人的方式。让工具完成重复步骤，让新人必须讲清楚修改的依据、影响范围和验证方法；用真实缺陷复盘和受控实验，替代一部分抽卡式的“踩坑成长”。

省下来的时间要用在哪里，是管理问题，也是人才培养问题。买了工具，并不会自动得到一支更强的团队。

五、工程师该积累什么？学 Agent？

会使用 AI 当然重要，但如果只是把“熟悉配置器菜单”换成“熟悉几种提示词”，护城河依然不深。

更值得练的，是把模糊问题变成可验证问题的能力。

同样是遇到 ECU 偶发复位，一种问法是：

“帮我看看可能是什么原因。”

另一种做法是先整理：复位原因寄存器记录了什么，故障前有哪些任务和中断活动，供电与看门狗证据是否完整，复现是否依赖特定负载，哪些假设已经被测试排除。

AI 可以参与这两种工作，但工程师提供的约束与证据不同，结果的可用性也会差很多。

再比如，AI 建议修改通信超时参数。工程师不能只看这个修改能否消除当前报错，还得追问：它是否改变了故障检测时限？有没有掩盖调度问题？与系统需求是否冲突？

这些能力并非 AI 永远无法触及。工具也会继续进入分析、测试和评审。只是相比记忆规则和机械操作，跨层理解问题、权衡约束、组织验证，是当前更值得投入的能力。

至于怎样开始，不必一上来就追求“自动开发 ECU”。

选一个范围小、结果容易核对、变更能够回滚的任务，记录人工耗时、工具耗时、复核成本和漏检情况。涉及项目代码和供应商资料时，先确认数据与授权边界；涉及写入操作时，保留差异、审批和执行记录。

用完之后，回答两个问题：

它到底替我省了哪一步？

为了相信它的结果，我又增加了多少工作？

这比“用了 AI 感觉很快”更能帮助你判断工具，也更能看清自己工作的价值。

写在最后：岗位仍有门槛，但别拿门槛当保证书

汽车软件的系统复杂度、硬件约束和验证要求，确实让 AI 的落地比普通代码生成更困难。

这些约束不会因为模型升级就突然消失。

但行业难进入，不代表行业内部的分工不会改变；项目必须有人负责，也不代表每一个执行岗位都会原样保留。

更可能出现的，是一些工作被压缩，一些责任变得更重，一些岗位重新组合。具体速度如何，要看工具成熟度，也要看企业能否把数据、接口和流程接起来。

所以，我不太赞成用“汽车软件工程师依然坚挺”来给整个职业下结论。

更稳妥的判断是：汽车软件仍然需要工程师，但不能指望过去让自己值钱的那部分工作，未来一直值同样的价。

如果明天 AI 能可靠地完成查规范、改配置和生成基础代码，你现在的工作会少掉哪一部分？

剩下的那些，是你已经擅长的，还是你一直没时间去学的？