3.10 未来——AI接管了搬砖，谁来画图纸？
2030年，斯图加特
2030年，斯图加特。你走进一间会议室，对面坐着TÜV的安全评估员。他面前是一本厚厚的安全案例文件，你的团队花了六周时间编写，从HARA到安全目标，从功能安全概念到技术安全概念，从硬件度量到软件架构。在文件的后半段，软件部分的大部分C代码是AI生成的。单元测试是AI写的。静态分析报告是AI跑的。但安全案例里的每一句话（每一条安全目标的论证、每一个ASIL分解的理由、每一次“可接受残余风险“的判断）是你写的。
评估员翻到一页，指着上面一行字：“你在这里将转向辅助扭矩监测功能分解为ASIL-B(D)，理由是CAN信号层的E2E保护提供了足够的故障覆盖率。请向我解释：为什么E2E Profile 5的CRC-16校验在你的系统总线负载率为85%的工况下，仍然能保证单帧检测概率满足ASIL-D对报文丢失的容忍度要求？”
AI回答不了这个问题。不是因为AI不够聪明，是因为AI从未在那台真实的测试车上坐过200个小时，从未亲眼看过CANoe的Trace窗口在负载率冲到87%时开始出现的“偶发帧间隔异常“，从未在被暴雨淋过的接插件上测过接触电阻。AI没见过这些物理现实，所以AI不知道“85%总线负载率“在纸面上是一个数字、在车上是一个截然不同的物理现象。而你知道，因为你吃过这个苦。你在2019年那个冬天，因为一个CAN收发器的冷焊点，在寒风中排查了整整三天。那个经验长在你的直觉里，不在任何训练数据里。
核心洞察：安全案例里 AI 答不出的那个问题，答案长在工程师吃过的苦里，不在任何训练数据里。 85% 总线负载率在纸上是个数字，在车上是被暴雨淋过的接插件、是偶发帧间隔异常的物理现象。AI 没见过这些物理现实，而你的直觉来自排查三天的冷焊点经历——这正是评估员问你、而非问 AI 的原因。
一、AI将接管什么——以及这为什么是好事
1.1 代码生成：从“手写样板“到“规约驱动“
到2030年，一辆高端车型的软件总量可能突破3亿行。但其中真正承载“差异化逻辑“的代码不到10%。剩下的90%是什么？是AUTOSAR标准模块的配置驱动代码、RTE的生成胶水代码、DCM/DEM/FIM等诊断栈的协议实现、E2E保护的封装层、XCP标定驱动的数据帧编解码器，每一行都必须精确无误，但每一行都是“已知模式的再次实例化“。
让AI处理这90%。而且AI已经比人处理得好，它不会因为疲劳而漏掉某个状态机的转移路径，不会因为赶进度而少加了某个错误检查分支。只要你的规约（Specification） 足够精确（接口定义清晰、状态转换表完整、时序约束明确），AI就能生成比人工手写质量更高的代码。
这意味着什么？意味着你作为工程师的时间分配会发生根本性的变化。你不再花百分之六十的时间在“写代码“上（那90%的胶水代码），而是把绝大部分时间花在“写规约“上：定义接口、描述约束、澄清需求的歧义、验证需求的完整性和一致性。你从“代码作者“变成了“规约作者“。这其实更接近建筑师的日常：建筑师不砌砖，建筑师画图纸、写标注、检查施工。
1.2 测试生成：从“人想测试用例“到“AI做组合爆炸“
AI的第二个接管域是测试用例的自动生成。传统的MC/DC测试需要人手工推导“哪个条件组合覆盖了哪个判定路径“。对于一个包含六个布尔条件的表达式，手工推导可能耗费一个下午。AI能做同样的事情，而且只需要几秒：它直接解析AST，穷举条件组合，生成覆盖所有独立条件影响的测试向量。
更关键的是边界值测试。你在一个函数的注释里写了“参数取值范围0~255“。AI在生成测试用例时不仅会测0和255，它还会测-1（下溢）、256（上溢）、127→128的bit翻转边界、以及该参数在struct中与相邻字段的字节对齐关系。人也能想到这些，但人会忘。AI不会忘，它的“遗忘概率“为零。
组合爆炸是AI的盟友，不是它的敌人。 人在面对组合爆炸时会试图“聪明地“抽样：选几个有代表性的组合，希望它们能覆盖大部分故障模式。AI不需要做这种妥协，它可以直接跑完全组合，然后把时间花在真正值得人工关注的失败案例上。你不是在减少测试覆盖，你是在把测试从“设计用例“升级为“设计测试目标、AI填充用例“。
1.3 静态分析与自动修复
到2030年，你提交一个Merge Request之后的体验会是这样的：
- CI流水线自动运行MISRA-C:2012全量检查，2秒完成，全绿。
- AI静态分析引擎对代码做语义级审查：“第147行：函数
CalculateDeadline在特定路径上可能返回未初始化值。建议初始化路径分析如下。自动修复？[Y/n]” - 你按Y。AI改好了代码，重新运行全量回归，全绿。
- 系统自动生成变更影响分析：“本次修改影响了三个模块的外部接口：ComM、EcuM、CanIf。以下是受影响的接口的追溯链接。”
你不再需要盯着屏幕找“哪个变量忘了初始化“。你把精力留给AI做不到的事：理解变更对系统行为的影响，判断它是否符合功能安全的论证逻辑。
这是一个工程师应该做的工作：决策、判断、论证。而不是排查和抄写。
核心洞察：AI 接管的是占 90% 的“已知模式的再次实例化“，让你从代码作者变成规约作者。 代码生成是规约驱动，测试生成让 AI 做组合爆炸（遗忘概率为零），静态分析自动修复并生成影响分析。你的时间从“写代码“移到“写规约“：定义接口、描述约束、澄清歧义——这更接近建筑师：不砌砖，画图纸、写标注、检查施工。
二、什么将永远留在人的手中——以及为什么
2.1 安全论证：道德判断不能外包
ISO 26262的HARA分析里有一项叫“可控性“，驾驶员或其他交通参与者在危险事件发生时，有多大可能避免伤害。判定C1（一般可控）还是C3（难以可控）的依据包括道路类型、交通密度、典型驾驶员反应时间、以及事故统计数据库。
但最终，落在纸面上的那个“C“字母，承载着一个隐含的判断：“我们认为，在X条件下，一个人有足够的概率通过合理反应来避免严重后果。”
这个“我们认为“不是算法输出。它是一个组织对另一个组织、对终端用户、对公众做出的道德承诺。如果你把这个承诺外包给一个AI模型（无论它的训练数据多丰富、推理过程多严谨），在发生事故后的法庭上，法官问“你们为什么判定这个失效模式是C1而非C3？“你回答“因为AI模型给出的输出如此”，这不是合格的安全论证。这是把人的责任推卸给了一个没有法律主体资格的软件工具。
安全论证不能被自动化的核心原因是责任归属不能模糊，而非技术能力不足。在功能安全的框架下，每一项安全决策都需要一个明确的责任主体（一个人或一个组织）来承担其后果。AI不承担后果。人会。所以人必须做决定。
2.2 架构决策：你不知道的那部分，AI也不知道
架构决策的困难之处在于：你永远在信息不完备的条件下做选择。
你要在Cortex-R5和Cortex-A53之间选择核心来跑一个监控任务。Paper上说R5有TCM，确定性极高；A53有Cache，性能更强但WCET分析更复杂。但Paper上没告诉你：你的团队里唯一的WCET分析专家下个月休产假；供应商的Cache分析工具只有两个License，第三个License的采购还在法务审批中；上次用A53做安全监控的那个项目，WCET分析完成了四轮迭代才通过TÜV审核，超了预算三十七万。
这些信息不在任何文档里，不在任何训练数据里，它在一个上午的咖啡闲谈里、在项目周会的闲聊间隙里、在你和首席工程师私下打电话的三分钟里。AI永远拿不到这些信息，因为这些信息没有被数字化、被记录下来、被整理成结构化数据。它们是散落在组织里的人的网络中的隐性知识。
隐性知识是工程师最重要的护城河。 你不是因为比别人更懂C语言而值钱。你是因为“知道那个供应商的工具的第三个Bug要避开“、“知道那个客户的安全经理在第二页必问的三个问题”、“知道上个月那个CAN休眠问题的根因是收发器的寄存器位配置“而值钱。AI可以学C语言，可以在网上的公开代码仓库里训练，但AI进不了你公司的咖啡间。
2.3 需求理解：同理心是最后一个自动化不了的环节
“这个车的转向手感，在80km/h以上，有点奇怪。”
说出这句话的是一个人，可能是一个试车员，一个产品经理，一个终端用户。他用的词是“奇怪“（weird），不是“方向盘转角传感器输出信噪比低于28dB“。
从“weird“到“SNR < 28dB“之间，隔着一段漫长的路。这条路叫需求理解。你要：
- 追问描述者，让模糊感受变得更具体（“是轻了还是重了？是一直存在还是偶尔出现？”）
- 提出假设（“可能是EPS的助力曲线在某个车速区间切换不平顺”）
- 设计验证实验（“在高速环道上以85km/h匀速行驶，连接CANalyzer记录方向盘转角和助力扭矩，重复三次”）
- 分析数据，确认或推翻假设
- 形成可追溯的工程规格：“当车速在75-90km/h区间、方向盘转角变化率<30deg/s时，助力扭矩曲线在中心位置±5°范围内的斜率波动不应超过15%”
这个过程的每一步都需要同理心，你需要站在描述者的角度，理解他的“奇怪“可能对应的是你系统中的哪个物理量。你需要领域经验，你以前见过类似的抱怨，知道大概是哪个模块的问题。你需要创造性的实验设计，市面上没有现成的测试标准针对“weird steering above 80 km/h“，你得自己设计出来。
这三样东西（同理心、领域经验、创造性实验设计）是目前所有AI模型都无法可靠提供的。不是因为它们不够大，是因为它们的工作方式与这三样东西的本质不匹配。AI是做统计推断的，它从已有的数据中提取模式。但“这个描述者口中的weird，在当前的系统架构下是什么物理现象“，这个推断没有历史数据可依赖。它需要你跳进描述者的脑袋里，用他的眼睛看一遍世界。这是人的能力，不是模型的能力。
核心洞察：安全论证、架构决策、需求理解会永远留在人手中，因为责任无法外包、隐性知识无法数字化、同理心无法建模。 “我们认为 C1“是组织对公众的道德承诺，法官面前不能回答“AI 说的”；架构决策依赖散落在咖啡闲谈里的隐性知识，AI 进不了公司咖啡间；从“weird“到“SNR<28dB“需要跳进描述者的脑袋看一遍世界——这是人的能力，不是模型的能力。
三、未来：软件开发不消失——它升华了
如果你回顾人类建筑史，你会发现一个有趣的平行叙事。古埃及时期，法老的金字塔是靠数十万奴隶用肉体和撬棍一块一块叠上去的。那时“建筑师“的角色很模糊：决定金字塔位置和比例的那个人，和负责运石头的监工，是同一批人。到了古罗马，出现了一个分界：维特鲁威写出了《建筑十书》，建筑师成为一种独立的职业，他们只画图纸、只决定结构逻辑，不再需要亲自扛石头。
到了20世纪，混凝土泵车、塔式起重机、预制件技术全面普及。砌砖不再需要工匠级的技艺，预制墙板在工厂里生产好，吊车直接装上。建筑工人的平均技能需求在下降，但建筑师和结构工程师的需求反而在上升。因为建筑的复杂性在增加（超高层、大跨度、异形幕墙），这些需要更精确的结构计算、更复杂的荷载分析、更严格的规范合规论证。
软件工程正走在同一条路上。AI是混凝土泵车，它让“把代码写出来“这件体力活的技能门槛急剧降低。但这不代表“把系统设计出来“的需求减少了。正好相反：当代码的生产效率暴增后，能被快速实现的系统复杂度也会暴增，复杂的系统需要更强的架构能力和更深的领域知识，以及更严谨的安全、需求分析。在这些领域，人的价值不降反升。
“写代码“不再是最稀缺的技能。“理解应该写什么代码“才是。
核心洞察：“写代码“不再是稀缺技能，“理解应该写什么代码“才是。 就像混凝土泵车让砌砖门槛降低却抬高了建筑师需求，AI 让代码生产率暴增、系统复杂度暴增，更强的架构能力与领域知识反而更值钱。你从“如何实现“的执行者，变成“实现什么、为什么这样实现“的决策者——职业没有消失，它升华了。
本篇小结
- AI时代汽车软件工程师的未来图景：从2030年一个TÜV安全评估的场景出发，用“砌砖机器人→结构工程师“的建筑史类比，系统阐述了AI时代汽车软件工程师的未来图景。
- AI接管了搬砖：代码生成、测试用例生成、静态分析和自动修复、文档生成，这些“重复性高、决策空间小、规模庞大“的体力型工作，AI正在迅速地、不可逆转地接管。
- 人留下了画图纸：安全论证（不能外包的道德判断）、架构决策（信息不完备条件下的权衡）、需求理解（从模糊感知到精确规格的转化），这些需要隐性知识、同理心、创造性思维和法律责任归属的工作，AI在可预见的未来无法替代。
- 职业在升华而非消失：当“写代码“不再是稀缺技能时，“理解应该写什么代码“变得前所未有地重要。你从“如何实现“的执行者，变成了“实现什么“和“为什么这样实现“的决策者。
- AI是工具，图纸是你画的：AI生成的那些代码干净、规整、通过了所有的检查，它们是你指令的产物、你规约的实例化、你设计的执行。但安全案例上的每一个论证，是你一个字一个字写的。这些论证将来可能出现在法庭上、召回报告上、新闻发布会上，而那个时候，AI不会坐在被告席上。你会。而你对此没有恐惧，因为你画的图纸，你负责。
【下集预告】：从版本控制到需求追溯，你走完了软件工程“质量管控“的全部学科。下一章，我们走出建筑工地，走进一座真实的“别人家的楼“：Arctic Core。看一个支撑6种编译器、52块目标板的真实嵌入式工程，是如何把构建、模块化、测试、静态分析和文档追溯组织成一个运转了十多年的体系的。参观完毕，第五章就该你自己动手了。