3.9 AI时代的软件工程——工具变了，原则没变
上午十点的对话
上午十点，一个工程师对着Copilot说了句“更新CAN唤醒逻辑，增加对网络管理报文超时的处理“。AI生成了四十行代码，改了三个函数签名。编译通过。git push。CI绿灯。当天下午五点，测试台架上的EPS控制器突然无规律掉线：CAN总线上的NM超时处理引入了一个竞态条件，每两个小时触发一次。排查花了三个团队四十八个小时。
AI生成这四十行代码用了大概四秒。
AI没有引入任何C语言的语法错误。AI也完全符合导师在课堂上教你的“防御式编程“风格，加了空指针检查，加了边界条件处理。AI还写了干净的注释。但AI不知道这辆车的方向盘控制器是ASIL-D级别的系统。AI不知道那个timeout_ms参数在另一个ECU上有硬实时约束：它必须落在精确的50ms窗口内，少一毫秒NM不能确认休眠，多一毫秒造成唤醒风暴。AI不知道你公司的CAN协议栈使用了一个略有偏差的定时器实现，而AI生成代码里的超时计算方式恰好和那个偏差构成了“相消干涉“：大部分时候没问题，特定条件下系统性失效。
速度乘以了十。风险也乘以了十。你没准备好后者的防御手段之前，先别急着拥抱前者的速度。
核心洞察：AI 把速度乘以十，也把风险乘以十，防御手段没跟上之前别拥抱速度。 AI 不会犯语法错、符合编码规范、注释干净，但它不知道这是 ASIL-D 系统、不知道 timeout 参数的硬实时窗口、不知道协议栈定时器实现与生成代码构成“相消干涉“——特定条件下系统性失效。四秒生成，四十八小时排查。
一、AI在汽车软件工程中到底能做什么
1.1 它本能就擅长的：模式匹配和样板生成
AI最让人印象深刻的能力（代码生成、测试用例生成、静态分析规则提取）本质上都是模式识别的高级形式。
一个AUTOSAR的COM模块开发，如果让你手写，你需要从零搭建状态机、编写回调注册机制、处理CAN ID到PDU ID的映射逻辑。AI呢？它“读过“几十个开源COM栈的实现，它知道一个典型的COM模块长什么样。当你描述“我需要一个符合AUTOSAR 4.4规范的COM模块，支持I-PDU组的收发和截止时间监控“时，AI可以生成长达数百行的框架代码：包括函数骨架、基本的状态转换、初步的错误处理路径。
这不是魔法。这是在执行一项人脑也能执行但速度差百倍的任务：在已确定的架构约束下，填充“预期形态“的代码。
更准确地说：当问题的“解空间“已经被充分约束（输入格式确定、输出格式确定、架构模式已选定、编码规范已明确），AI就是一台超高速的代码合成器。它可以填充一个函数体、展开一个Switch-Case分支、为给定的函数签名生成一组边界测试用例。你不是在和AI“讨论设计“，你是在把AI当成一台后端代码写入引擎：你设计接口和约束，它负责展开实现。
1.2 它能辅助但需要判断的：静态分析、文档生成、代码翻译
比代码生成更深一层的应用是辅助分析工作：
静态分析建议：AI可以阅读整个代码库，识别出潜在的违规模式。例如，它能在几千个文件里找出所有“在ISR中调用阻塞函数“的模式：这不只是传统的Lint工具可做的模式匹配，还包括语义层面的判断：“这个函数虽然不叫WaitForEvent，但从其调用链来看，它最终会执行一个忙等待循环。“传统的MISRA-C检查器做不到这件事。AI做到了。但AI的判断需要人工复核，因为它也可能误判，把某些经过精心设计的非阻塞等待误标为问题。
文档生成：AI能从源代码中提取比Doxygen更丰富的描述。Doxygen只能提取你在注释里明确写下的东西。AI可以分析代码逻辑，推断出函数的副作用、前置条件和后置条件，生成更完整的接口规范。但AI也可能过度推断，把某个特殊Case的具体实现误读为通用逻辑，所以你需要Review生成的文档，就像你需要Review同事写的代码。
代码翻译：将一个基于CAN 2.0的协议栈迁移到CAN FD。这不是简单的头文件替换：CAN FD引入了更大的数据场、新的DLC编码、不同的帧结构。AI可以完成绝大部分的语法转换工作，但需要人类来判断：哪些CAN ID应该留在传统CAN通道上、哪些应该迁移到FD通道。这是系统架构决策，不是代码翻译问题。
核心洞察：AI 擅长的本质是模式识别：在解空间已被充分约束时，它是一台超高速代码合成器。 框架代码、测试用例、静态分析模式提取都是强项，但语义级判断需要人工复核：它可能把精心设计的非阻塞等待误标为问题，把特殊 Case 误读为通用逻辑。你设计接口与约束，它负责展开实现——判断权不能交出去。
二、AI不能做什么——以及为什么这些恰好最值钱
2.1 安全论证：ASIL不是算出来的，是坐出来的
ISO 26262要求每个功能危害分析和风险评估（HARA），判定其ASIL等级。这个判定过程看似是一个矩阵计算（严重度×暴露度×可控性→ASIL），但实际上它的核心环节不是计算，是协商和判断。
“转向助力失效在高速工况下“的严重度是多少？S1（轻微）还是S3（致命）？这取决于你和OEM的安全经理、系统工程师、测试工程师在会议室里讨论的结果。讨论的输入不只有数值：还有市场部的“客户投诉历史数据”、法务部的“同类召回案例统计“、保险公司的“事故赔率分布“。AI可以做表格，但不能坐在会议室里为自己的判定承担法律责任。
更进一步，ISO 26262要求的**安全案例（Safety Case）**是一份论证文件，它要说服的不是编译器，是一个TÜV/SGS的资深评估员。评估员会问：“你为什么选择了ASIL分解而不是直接满足ASIL-D？“如果回答是“因为AI建议我这样做”，你可能要被送回重做。
2.2 架构决策：给定64KB SRAM和5ms截止时间，你选哪个模式？
一个ZynqMP Cortex-R5核心，64KB TCM，5ms控制周期。你要在其中运行三个ASIL-B级别的监控任务和一个ASIL-QM级别的通信栈。你可以选择：
- 方案A：抢占式调度，给ASIL-B任务最高优先级，风险是抢占延迟不确定
- 方案B：协作式调度，用TDMA时间片，风险是QM任务被粒度卡住
- 方案C：Hypervisor隔离，把ASIL-B任务放在独立的分区里，代价是更复杂的内存保护配置
AI能帮你评估每个方案的CPU利用率和内存占用。但AI不知道你的团队里有没有人真正部署过Hypervisor。AI不知道你的客户（OEM）是否接受TDMA调度带来的额外系统延迟。AI不知道你下个季度的预算能不能覆盖一套新的Hypervisor License的采购成本。
工程决策的核心从来都是：“在当前约束下，哪个方案的成本（时间、金钱、风险、人的能力）是可接受的”。 这个判断里的每一个词（“当前约束”、“成本”、“可接受”）都是人的判断，不是参数。
2.3 需求理解：“转向手感有点怪“是什么意思？
客户（或者内部的车辆动力学工程师）给你发了一封邮件，标题是“Steering Feel Feedback“，正文是一个简短视频链接和一句话：“The steering feels a bit weird above 80 km/h. Can you check?”
AI可以把这段英文翻译成六种语言。AI可以为这句话生成十个可能的JIRA任务模板。AI甚至可以根据视频画面分析轮速和转角的大致关系。
但AI不能替你做的事是：拿起电话打给那个工程师，问“你说的weird是指方向盘太轻、回正太慢、还是有异常的振动？从多少公里每小时开始明显？路面是柏油还是水泥？胎压正常吗？“，然后设计一个数据采集方案，在他的测试车上装好CAN Logger，跑一圈高速，拿回几百MB的CAN Trace，从里面找出哪个信号的时序特征和“weird“这个词吻合。
这个过程叫需求理解（Requirement Elicitation）。这是软件工程中最古老也最没有被自动化攻克的问题。因为需求（真正的、反映用户意图的需求）不是写在PRD里的文字，是活在人脑子里的模糊感知。把模糊感知变成精确规格的过程，靠的是同理心、领域经验、和反复的面对面沟通。这三样东西，AI一条都不具备。
核心洞察：ASIL 判定、架构权衡、需求理解——AI 的三个盲区恰好定义工程师的核心价值。 安全论证是协商与判断，评估员要的是“为什么选 ASIL 分解“的回答，而不是“AI 建议的“；架构决策的核心“哪个方案成本可接受“里的每个词都是人的判断；需求理解靠同理心、领域经验与反复沟通，这三样 AI 一条都不具备。
三、原则没变——它变得更重了
3.1 CI Gate：从“最好有“到“必须有“
在AI没加入你的工作流之前，你可能偶尔跳过某个CI检查：“这个Warning我知道，下个MR再修。“代码是手写的，你对手写代码有一种朴素的安全感：“我自己写的，不会太离谱。”
AI生成的代码打破了这种安全感。AI不提供“自己写的“这种心理安慰。AI生成的代码通过了编译器的语法检查、符合了编码规范的格式要求，但它的语义正确性和安全性是完全未知的。你不知道AI在生成这个函数时是不是“读“了十个正确的例子和一个有Bug的例子并混在了一起。
弥补这个不确定性的唯一手段，就是加厚你的防护网：
- CI必须跑完全部静态分析检查：MISRA-C:2012全量规则，零容忍，即使是Advisory规则也不允许跳过。
- CI必须覆盖全部单元测试，代码覆盖率达到MC/DC（如果功能要求ASIL-B以上）。
- CI必须对每一次提交运行回归测试集，不是“最近改过的模块“，是全部。
- 如果AI生成的代码通过了所有检查，它还不够。它必须经过人工评审。人工评审的责任回答一个AI回答不了的问题：“这段代码运行在真实车辆上的真实物理环境中，会出现什么AI训练数据里没出现过的情况？”
3.2 追溯性：从“审计需要“到“生存需要“
在ASPICE的世界里，追溯性（Traceability）经常被误解为“额外的文书工作“：一种为了通过认证不得不做的事。在AI参与编码后，追溯性的性质变了：它从“给审计员看的“变成了“给自己和同事看的“。
AI生成一个函数，三周后你发现它的逻辑有问题。你需要回到生成它的那一刻，理解：
- 这个函数是响应哪条需求生成的？（需求追溯）
- 生成时的Prompt是什么？AI参考了哪些上下文？（生成过程追溯）
- 后续有哪些人工修改叠加在了AI生成的代码上？（修改记录追溯）
如果这三道追溯链断了：你不知道这条函数为什么存在、它对应了哪条功能需求、修改它的过程中有没有人引入新的副作用，你面对的一段你无法承担责任的代码。在ISO 26262的语境下，“不知道这段代码从哪里来、为什么在这里、改了会怎样“的代码 = 不被允许部署的代码。
3.3 代码评审：从“查Bug“到“答问题“
AI生成的代码也会进入Merge Request，也需要被人评审。但评审的内容变了。
传统代码评审的核心问题是：“这段代码有Bug吗？”
AI时代代码评审的核心问题变成：
- “这段代码的逻辑和我对需求的理解一致吗？”
- “这个函数的行为在所有合法的输入组合下都是正确的吗？”
- “AI做了哪些隐含假设？如果假设不成立会发生什么？”
- “这段代码和系统中其他模块的交互有没有引入新的时序依赖？”
评审者不再是一行一行地检查语法和边界条件（如果CI已经做完了这些），而是在做一层更高阶的验证：语义与预期的一致性检查。这要求评审者不仅懂代码，还要懂系统：懂这辆车在什么工况下运行、懂这个模块和其他ECU之间有什么隐含的时间契约。
代码评审没有因为AI变得不重要。恰恰相反：代码评审从“保证代码质量“升级为“保证AI生成物的安全合规性“。这份责任重了，不是轻了。
核心洞察：AI 时代三道防线变得更厚，而不是更薄。 AI 代码打破了“自己写的“心理安全感，CI 必须全量静态分析、全量回归、MC/DC 覆盖，再加人工评审回答“真实物理环境里会出现什么“；追溯性从审计需要变成生存需要，不知道代码从哪来就不被允许部署；评审从“查 Bug“升级为验证语义与预期的一致性。
四、建筑隐喻：更快的砌砖机不替代结构工程师
让工地上来一台全自动砌砖机器人。它一小时能砌一千块砖，精度比任何工匠都高。它不需要休息，不会累，不会把砂浆抹得不均匀。
但谁来告诉这台机器，这面墙要砌在哪里？是承重墙还是隔断墙？墙后面要走水电管线吗？这堵墙在八级地震下会倒吗？
没有人回答这些问题，砌砖机器人只是一台速度很快的废砖生产机。
AI就是你的全自动砌砖机器人。它速度快，精度高，不知道累。但决定项目成败的不是砌砖速度：是这个人有没有在正确的位置砌了正确的墙，有没有在正确的位置预留了门窗洞口，有没有为未来的管线预埋了套管。
结构工程师的职责在有了砌砖机器人之后没有减弱。它被凸显了。 因为以前砌砖慢的时候，工程师有时间边砌边想。现在砖砌得太快了，工程师必须在砌之前就把所有结构决策都做完：因为砖砌上去之后再改，就不是返工一面墙的问题，是返工一整层。
同理，AI代码生成的高速度意味着：你的架构决策、接口设计、安全策略必须先于代码生成一步到位。 你不能等AI生成了代码之后再“看着改“：改的成本太高了。你必须在Prompt里就把所有约束条件讲清楚，在Review阶段用比以往更严格的视角检查生成结果，在CI流水线里布上比以往更密集的防御层。
以前是“写代码的人不犯错，系统就安全“。现在是“写Prompt的人和审代码的人不犯错，系统才安全“。人的责任从“执行“位移到了“规约“和“验证“。位置变了，重量没变。
核心洞察：砌砖机越快，结构工程师越必须在砌之前把所有结构决策做完。 砖砌上去再改是返工一整层，同理 AI 的高速度意味着架构决策、接口设计、安全策略必须先于代码生成一步到位。人的责任从“执行“位移到“规约“与“验证“——位置变了，重量没变。
本篇小结
- AI的能力边界：从一段AI生成代码引发EPS控制器故障的真实工程场景出发，系统分析了AI在汽车嵌入式软件工程中的能力边界和永恒不变的核心原则。
- AI擅长：代码生成（在有明确约束的解空间内）、测试用例生成、静态分析模式识别、API文档生成、代码翻译：本质上都是“模式匹配和语法合成“的高级形式。
- AI不擅长：安全论证（ASIL判定是协商判断，不是计算）、架构决策（多约束下的成本权衡需要人类判断力）、需求理解（模糊感知→精确规格的过程靠同理心和沟通），这些恰好是工程中最有价值、最难被替代的环节。
- 不变的原则：CI Gate从“最好有“升级为“必须有“；追溯性从审计要求升级为生存要求；代码评审从“查Bug“升级为“验证语义一致性“，三道安全防线在AI时代变得更厚、更严格。
- 建筑隐喻：更快的砌砖机器人和更强的混凝土泵车没有淘汰结构工程师，它们只是让工程师从“确保砂浆均匀“中解放出来，把全部心力投入到真正决定建筑成败的事情上：结构设计、荷载计算、抗震分析、规范合规。你的未来不在代码的语法里，在系统的架构里。
【下集预告】：如果AI已经能生成90%的ECU样板代码，如果CI流水线能在几秒内跑完数千个测试，如果静态分析工具能在你还没看到代码之前就修好违规：那么留给“你“的任务到底是什么？当AI接管了搬砖，谁来画图纸？当软件工程的工具前所未有地强大时，软件工程师这个职业是消失了，还是升华了？