之前说过不会太惊讶。1. 先说结论汽车软件里AI编程的真实生产力在哪里先说一个我自己的结论AI在汽车软件领域的生产力是真实的但它能扛的事情高度集中在“模式固定、规范明确、反馈闭环短”的代码类型上。不是说大模型会写代码所以它什么代码都能写而是说汽车软件里存在大量重复性强、范式标准、结构可预测的编码任务这些任务第一次真正被大模型拉高了效率。那什么是“模式固定、规范明确”的代码我随便举几个例子在座做车控或者做工具链的朋友肯定秒懂基于DBC文件的CAN报文解析代码字段排列、字节序、信号缩放都有明确规则AUTOSAR Classic平台下的RTE接口骨架、Port配置、数据元素映射UDS诊断协议栈里的服务解析函数27服务、31服务、19服务的子功能枚举单元测试桩代码、Mock函数的批量生成MISRA C违规告警的批量整改建议。这些工作有一个共同点规则在明面上。要么在协议标准里要么在AUTOSAR配置里要么在芯片手册里。你只要把规则喂给AI它产出的东西基本能到七八十分人工再修一修边界就能用。反过来凡是涉及功能安全、实时调度、硬件失效模式判断、系统级权衡的编码任务AI目前能做的很有限甚至可以说不适合让它独立完成。不是它语法不行而是它缺乏“系统上下文”——它不知道这块代码被调用时的前置条件、不知道一个故障码触发后对整车其他域的影响、不知道ASIL等级背后要求的安全机制。语法层面AI非常擅长规则和上下文层面它很容易翻车。我自己的实践数据是用大模型辅助编写Python工具链脚本比如DBC解析、CAPL测试脚本生成、测试报告汇总一天的工作量能压缩到两小时内省下来的时间基本可以交给评审和调试。但同样是这个AI我让它为某个ASIL D的电源管理模块生成故障响应代码它给出的方案里每一次都能指出2到3处逻辑漏洞而且漏洞不是在语法层面而是在“故障注入后的目标状态是否安全”这种判断上必须靠人来兜底。所以“AI接管汽车软件开发”这个说法我的理解不是AI替代工程师做所有决策而是AI在代码层面接管了那些高重复、高模式的生成工作能力层面它才刚刚触及汽车软件工程师日常承担的那部分判断工作。从代码边界到能力边界中间这段距离就是我们接下来要聊的核心。2. 我试了一圈哪些场景AI真能扛事哪些只能打辅助自打AI编程工具进入日常开发流程之后我基本上把手里能拿来试的任务都试了一遍。下面是四个我反复用到的场景有预期外的提升也有意料之中的翻车分开讲会清楚一些。2.1 场景一Python工具链脚本——AI直接上手人只审逻辑汽车软件这一行有一个长期存在的痛点算法工程师和嵌入式工程师的代码能力参差不齐但工具链脚本解析DBC、操作ARXML、批量处理Excel、生成测试报告以及基于PyVISA的仪器控制脚本很少有人愿意认真写因为它“不算产品代码”但写起来又极其费时间。我试过让大模型直接生成一个DBC解析工具输入dbc文件路径输出所有报文、信号、周期和初始值的一张汇总表。给我的第一版就能跑能在几分钟内处理完一个包含数百条报文的DBC。唯一的坑是它默认按Motorola字节序处理而实际项目里混合了Intel和Motorola两种字节序我需要在提示词里明确告诉它“每个信号从DBC的属性里读字节序不要假设”。这类脚本我现在的用法是让AI写我审逻辑然后跑几个真实数据文件做回归。效率提升非常明显而且风险很低因为工具链脚本的出错影响面有限有自动化测试兜底错了也能快速发现。这个场景我认为已经是AI编程在汽车软件领域最成熟的应用。2.2 场景二C语言驱动与寄存器配置——AI当“结对搜索助手”不能完全放开再往上一个台阶是芯片驱动代码。我拿某个MCU的CAN控制器驱动试过。我先让它读芯片手册中寄存器描述的PDF片段然后生成初始化代码。结果很有意思对于移位、掩码、置位这些常规操作AI的产出质量很高但你一旦问它某个寄存器的某个位在特定模式下是什么含义它就很容易开始“编”。这不是大模型先天缺陷而是因为芯片手册动辄几千页它没有真正“看”到完整手册只看到了我贴给它的部分片段。它就会用语言模型的统计规律去“合理猜测”寄存器位的行为而不是像人一样先去查表格、确认没歧义再写代码。所以这个场景我现在的做法是让它生成“看起来合理”的代码框架把寄存器地址、位定义、时序要求这些需要查证的信息留空或标记TODO然后我人工对照手册一一填入。换句话说AI在这里不是生产者而是一个对寄存器操作范式非常熟悉的结对搜索助手它能帮你把骨架搭得又快又标准但细节必须人来确认。2.3 场景三UDS诊断状态机——AI能写出漂亮的框架但边界条件会漏UDS诊断状态机是我项目中经常碰到的需求。诊断会话切换、安全访问、待处理响应、服务禁止条件这些交织在一起状态数量和迁移条件很容易膨胀。我试过让AI基于一整套诊断规范文档生成状态机代码它给出来的代码结构相当漂亮状态枚举、迁移表、动作函数分层清晰接口设计也符合我的预期。但问题出在边界条件上。举个例子它很自然地把“当前会话切换”和“正在执行27服务解锁流程”当成两个独立状态处理但实际诊断需求里这两者是可能发生冲突的——比如在安全解锁流程进行到一半时上位机突然切会话这时候应该终止解锁、还是完成解锁再切换会话我把这个场景问AI它给出的答案也会变一会儿说要重置一会儿说先完成当前流程没有一致性。这类问题不是AI不会写代码而是它缺乏“对这个诊断状态机负责”的全局意识。它能看到你给它的文档片段但它看不到这个状态机上线之后测试工程师会在哪些边界场景里反复试探它。所以状态机代码我会用AI生成框架然后拿着ISO 14229、OEM的诊断规范以及历史缺陷清单一项一项地对照人工补边界测试和状态保护。这一步目前没有捷径。2.4 场景四功能安全相关代码——目前不建议让AI独立写这个场景要单独拿出来说。ISO 26262对安全相关代码的要求不仅仅是“功能正确”还要包括可追溯性代码到需求的双向追踪、安全机制设计冗余、自检、错误处理路径、故障注入下的行为以及对应的验证充分性。我尝试过让AI为BMS的过压保护逻辑生成完整代码它在功能正确性上做得不错——电压阈值比较、超时累计、故障置位这些都写得很顺手。但当我追问“如果ADC采样通道发生故障导致电压信号固定在最大值这个保护逻辑还能不能正确区分过压故障和传感器故障”它沉默了或者给出的方案非常幼稚比如“增加一个看门狗”——但这个问题真正的答案通常是硬件层面需要冗余采样通道软件层面需要做合理性校验和故障确认逻辑这已经超出“让代码跑起来”的范畴进入系统安全设计的领域。所以我的结论很直接功能安全相关代码AI不能独立写不能作为“自动化生成工具”直接接入流程。它只能作为辅助分析工具帮你生成代码草图、列检查清单、辅助写可追溯性标记但设计决策和安全论证必须由有资质的功能安全工程师完成。3. 从代码边界到能力边界AI在汽车软件里的四块硬伤上一节说的场景其实反映了同一个核心问题AI在代码层面很强但能力层面有几块硬伤直接影响它在汽车软件领域能走多远。我梳理了一下最关键的四个是幻觉、上下文窗口、随机性、以及责任归属。这些词在互联网应用里可能只是“效果不稳定”但在车规级软件里每一个都可能是安全事故的引线。3.1 幻觉最危险的不是“报错”而是“看起来全对”的错大模型幻觉在汽车软件开发里和平时在聊天框里遇到的幻觉完全不是一个量级。聊天框里它胡诌一个事实你一笑了之但在代码里它“编”一个不存在的API函数或者“编”一个错误的CAN ID映射如果你的代码评审、静态检查和单元测试没有覆盖到这个点这个错误会直接进入量产软件。我遇到过最典型的幻觉案例让它生成一段接收CAN报文的代码它自动假设了一个DLC数据长度代码为8但实际上那条报文在DBC里的定义是DLC6。如果你只看代码逻辑根本看不出问题因为数据长度变量是从常量宏定义的宏定义那行写得也没毛病——除了这个值是AI编出来的并不来自DBC文件。这种错误最可怕的地方在于它不是显而易见的语法错误而是逻辑伪装下的数据错误。人类工程师写代码时通常会带着某个具体报文结构来写而对AI来说它只是觉得“DLC8比较常见”。应对幻觉的办法我觉得只有一条给AI喂真实的原始资料而不是让它凭记忆生成数据。凡是涉及具体协议、具体地址、具体数值、具体ID的信息必须由人从原始资料中确认并写进提示词或者由脚本从DBC/ARXML/Excel中导出后拼接进提示词。绝不依赖模型内部记忆。3.2 上下文窗口它看不到整个系统怎么做系统决策汽车软件的工程遗产是轻则上万、重则上千万行的代码。以现代大模型的上下文窗口别说整个仓库了一个大型模块的源码加配套文档都放不下。所有AI编程工具的实际工作方式都是“挑片段看”。这个特点造成了能力边界上的一个直接后果AI无法理解跨模块的隐式约定。整个车控软件里很多行为约束不是写在接口函数里而是写在需求文档、在代码评审记录里、甚至写在某个老员工的脑子里。比如“这个标志位只能在特定状态下修改”这种隐含约束只有当你同时看到生产者、消费者、以及状态机的全部代码时才能意识到。AI看不到它就会在你给它指定的局部代码里“合理”地打破这个约定产出单看没问题、放进系统就会出事的代码。现在很多AI编程产品在尝试用“仓库索引”或者“全量代码检索”来缓解上下文问题这个方法对跨文件检索有一点帮助但对理解“为什么这样设计”几乎无能为力。因为这类设计决策通常不在代码里而是在文档和评审记录里。所以我的体会是越到系统级任务越不能依赖AI做全局判断相反你要主动把全局判断做在前面把明确的边界条件写清楚再让AI在局部执行。3.3 温度与随机性车规代码不需要“创造性”大模型生成代码时有一定随机性这个特性在创意写作里是优点但在车规代码里是麻烦。你希望功能相同的两次请求生成逻辑一致的代码方便评审、方便测试、方便追溯。但AI有温度参数温度越高输出越随机即便同一段需求两次生成的代码可能风格不同、变量名不同、甚至采用的算法策略不同。在汽车软件领域代码统一性是重要资产。可维护性、可测试性、可追溯性全都依赖这种统一性。你当然可以把温度调到最低但即便温度是0大模型的解码策略本身也还是概率性的贪心解码也可能因为softmax分布的非确定性产生差异只是概率更集中而已。我现在的做法是给AI建立固定的代码模板和风格规则在提示词里明确后缀——“严格使用现有文件中的命名规范和错误处理风格不要引入新的宏或头文件除非我说可以”。这种约束能显著降低随机性带来的“AI风格化”问题。另外一个技巧是尽可能在已有文件的上下文中让AI续写或修改而不是让它新建文件从零生成。从零生成的代码AI更容易暴露它的“平均风格”在既有上下文中做局部修改它的输出会被约束得多。3.4 安全责任当AI参与生成代码谁来为ASIL等级负责这可能是团队引入AI编程时最容易被忽略的问题。无论是功能安全认证还是质量体系评审最终要对代码负责的是作为“组织”的团队是你不是大模型。它不会签质量协议不会承担召回责任不会出现在FMEA的评审组里。我在推进团队使用AI编程时明确做了一件事在代码评审清单里增加一条——“本PR是否包含AI生成代码如果是请注明AI生成的范围以及人工审查的结论”。不是为了走形式而是为了在质量问题暴露时你能回溯“这段代码是在什么上下文下生成的、谁做的评审、用的什么资料”。这样的话AI参与的范围就变成一个可控变量而不是一个隐形变量。可能有人觉得这是小题大做但在车规项目里“追溯性”本身就是硬指标。AI生成代码如果不纳入追溯代码的SPICE评估、功能安全认证都会出现一个“来源不明”的大窟窿。把AI生成的代码当成供应商交付的代码来管理它才有资格进入量产流程。4. 我的工程化用法把AI规训在“安全围栏”里聊了这么多边界接下来说说实际方法论。我不主张一禁了之也不主张敞开了用。我的做法是给AI画一个“围栏”把它规训在安全范围内发挥效率。下面这几个方法是过去半年反复调整后留下来的可以直接抄作业。4.1 场景×风险二维矩阵该不该让AI写先分类第一步不是写提示词而是给任务分类。我自己用的是一个二维矩阵横轴是任务的规范性高规范规则明确、标准清晰低规范需求模糊、需要判断纵轴是任务的安全风险高/低。高规范 低风险例如工具链脚本、单元测试桩、诊断协议解析。这个象限可以放心让AI写人工只审逻辑。高规范 高风险例如安全机制相关的算法实现、网络通信的关键路径。这个象限可以使用AI辅助生成但必须人工逐行评审并且补充故障注入测试。低规范 低风险例如文档模板、内部演示代码、架构草图。AI可以打草稿人做最终决策。低规范 高风险例如系统级的失效模式分析、跨模块安全架构设计、ASIL等级分解。这个象限目前不建议让AI产出最终方案只能让它做“被提问的助手”。这个矩阵最直接的改变是团队里不再有“AI能不能用”之争而是按照任务落到哪个象限来决定协作模式。分类过程本身也让每个人都重新审视了一遍自己的任务是偏规范性还是偏判断性这对团队能力建设也有意外的好处。4.2 提示词里带上“边界条件清单”而不是只给需求我发现很多AI生成代码翻车不是模型不行而是用户给的需求太“顺畅”了。你在提示词里写“实现一个报文管理模块”它当然按平均理解来但你在提示词里写“这个模块必须保证输入为空时返回错误码NOT_INIT缓冲区满时丢弃最新报文并置位溢出标志所有对外的接口函数都必须加线程保护不允许使用全局变量”它输出质量立刻上一个档次。用工程师的话说提示词就是在给AI写需求规格书。车规开发里我们早就知道需求写得越明确开发效率越高、返工越少。这个经验直接平移给AI同样成立。我现在的习惯是让AI生成代码前先花五分钟把边界条件列成清单输入范围、异常处理、资源约束、调用条件、禁止事项。这些本身就是平时代码评审要检查的内容把它前置到提示词里等于让AI从一开始就往正确方向走。4.3 用AI生成的测试去验证AI生成的代码是可行的闭环这个方法我一开始是抱着试试看的心态做的结果发现意外有效。既然代码是AI写的那不如也让AI根据同一份需求生成单元测试。这样形成了一个天然的自校验闭环如果AI的测试能覆盖描述的关键路径且测试能通过说明这段代码至少和它自己理解的需求是一致的如果测试发现代码跑不过去那说明它自己生成了“连自己也跑不通”的代码问题暴露得特别快。但这个闭环有一个大坑测试和代码可能共享同一个错误假设。AI理解需求时产生的偏差往往同时体现在代码和测试里两条线一起错测试就变成“用错误验证错误”很容易带来虚假的安全感。所以我给这个闭环加了一个人工约束生成测试后由人写至少一个“破罐破摔”的对抗性测试用例专门去测那些“需求没写明但系统很可能出问题”的边界比如非法输入、资源耗尽、状态机冲突。这样一个由AI自检加人工对抗性验证的框架才能在车规模块里真正发挥作用。4.4 AI参与的代码评审必须再做一遍“失效模式检查”AI生成的代码进入评审阶段时我不想让评审人按普通代码的逻辑去看。我要求团队对AI生成的代码额外做一遍“失效模式检查”——不是看代码怎么写得好不好而是问几个固定的问题如果某个传感器输入失效这段代码会走哪条路径如果调用的底层函数返回一个非预期状态这段代码能不能感知并处理如果这段代码在某次迭代中被其他模块误调用违反调用时序会发生什么代码里有没有“看起来理所应当”的假设协议周期固定、内存够用、外部设备永远响应这其实是在模仿汽车行业做FMEA的思路。我们把功能失效分析从系统层面下沉到代码层面效果不错尤其是针对AI生成代码。因为AI生成代码最擅长的事情恰恰是生产“语法优雅、逻辑平庸”的代码它很少像资深工程师那样主动在代码里暴露对异常路径的关注。失效模式检查就是专治这个毛病的。5. 当AI真正“接管”了一部分开发工程师的价值在哪里最后聊聊能力边界这个问题。我在标题里写“从代码边界到能力边界”意思是AI正在快速越过“能不能写代码”这条线但还没有越过“能否为一个安全关键系统负责”这条线。那么问题就变成——当AI真的接管了大部分代码生产动作我们这些做汽车软件的人价值还能体现在什么地方我的答案有三个第一定义边界条件。无论AI多强总得有人告诉它哪些路径合法、哪些路径非法、哪些资源不可触碰。这些边界不是代码语法而是你对系统运行环境的理解。第二做技术权衡。代码永远不是孤立的、美好逻辑的组合它受调度周期、内存带宽、芯片良率、BOM成本、生产一致性、售后诊断多重因素挤压。AI不会帮你做“用两个字节的阈值表换五十毫秒诊断延迟”这种决策它甚至不会意识到这个选项存在。第三承担安全责任。ISO 26262要求的不是代码好看而是从组织流程到工程活动都证明系统在可接受的风险水平下运行这个证明链条的每一环都必须有真实工程师的签名。不是我悲观我个人反而很乐观。AI大量接管规范化编码之后工程师终于有机会从复制粘贴、不耐烦地写注释、通宵调协议栈的泥潭里爬出来把时间还给更值得投入的故障模式分析、面向智能制造的可诊断性设计以及跨域协同的问题。过去半年我自己最明显的感受是有了AI做初稿我能多在仿真环境里验证几个极端工况而不是天天赶工写接口实现。这种分工比想象中要愉快得多。所以关于“CEO应不应该参与”我的看法是如果一家公司用一个通用大模型工具没做任何任务分类、没做追溯性管理、直接让团队在量产代码仓库里用AI生成然后老板还以为“AI已经接管了汽车软件开发”——那这个CEO要担心的不是AI能力边界而是质量体系的边界在哪。AI的方向是对的但工程化的护栏必须像咱们写功能安全需求一样提前设计、成文落地、持续回顾。想试的朋友也建议先从工具链脚本往下走等流程真正发自内心适应了AI协作再慢慢往关键路径迁移。这个过程本身就是CEF从代码边界走向能力边界的必经之路。