AI × 汽车

摘要：2026 年初，Harness Engineering（驾驭工程）在 AI 工程社区迅速崛起，成为继 Prompt Engineering、Context Engineering 之后的第三代方法论范式。本文从驾驭工程的核心概念出发，系统分析其与当前基于端到端算法的智能驾驶系统在全生命周期各阶段的深层对应关系，揭示两者在控制论框架、改进循环、失败应对哲学上的结构性同构，并详细阐述其对智能驾驶用户体验与安全工程（尤其是 SOTIF / ISO 21448）的参考价值。研究发现：驾驭工程与汽车安全工程并非表面相似的类比，而是面对同一类根问题的两套独立演化解法，共享同一套底层操作系统。 一、驾驭工程：第三代 AI 工程范式的崛起 1.1 概念与起源 Harness Engineering（驾驭工程） 是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制与持续改进循环的系统工程实践。它不优化模型本身，而是优化模型运行的整个"环境"。 “Harness"一词来自马具——缰绳、马鞍、嚼子——一套引导强大但不可完全预测的动物的完整装备。驾驭工程不是去削弱 AI 的能力，而是为它打造一套完整的约束与引导系统，让它跑得又快又稳。 这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出。六天后，OpenAI 在其百万行代码实验报告中正式采用这一术语。随后 Martin Fowler 团队撰文深度分析，Anthropic 发布长时运行 Agent 最佳实践，一个月内"Harness Engineering"成为全球开发者社区的高频词。 Mitchell Hashimoto 的原始定义： “Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.” ...

摘要：一篇关于博世工程师开源项目的文章收获15万+曝光，但真正Fork动手的只有50多人。这种"围观多、动手少"的现象背后，是AI工具落地的结构性错位——真正需要AI工具的人不会用GitHub，会用GitHub的人不需要通用工具。AI工具的上限取决于注入者的领域深度，而非AI本身的能力。 这篇文章发出后，评论区出现了这样一条留言： 图 1 “车企一线大头兵，现在真的压力山大，看到这种项目出来真是五味杂陈，被时代浪潮卷死应该快要进入倒计时了…” 那篇文章在公众号和LinkedIn两个平台加起来，超过15万人看了——公众号近3万阅读、2000多次转发，LinkedIn近13万曝光、1400多个赞。 然而，打开GitHub一看——真正Fork下来用的人，只有50多个。 15万人围观。50人动手。转化率不到万分之三。 我一开始以为是技术门槛的问题——可能大家不会用GitHub、不用Claude Code。 后来发现，事情没这么简单。 一、真正的障碍不是技术，是一种结构性错位 最近一段时间，和团队内外部同事朋友等各类人聊了这个话题——OEM、Tier1的工程师、做AI Agent的创业者、高校老师、咨询公司。聊完之后我得出了一个让自己也挺意外的结论： 真正需要这些AI工具的人，不会用GitHub。会用GitHub的人，根本不需要这些通用开源工具。 这不是段子，是一个结构性的错位。展开说说。 AI-native公司怎么看这个项目 我紧密协作的团队，几乎每个人都在用Claude、Cursor做日常工作，每个人都在琢磨怎么把自己的活儿用AI自动化。他们对这类通用开源项目的反应是什么？ 不太感兴趣。 不是因为不好，是因为自己已经在做了——针对自己公司的流程、自己团队的know-how、自己产品的需求，搞定制化的AI工具。一个通用的"功能安全Agent"，远不如他们自己那个塞满了内部案例和模板的版本好使。 传统车企怎么看这个项目 另一边，有咨询公司的朋友找我聊，说有车企客户想做"AI提效"——同时给底盘域、车身域、智驾域等多个域开发AI Agent，让AI读需求文档、自动提测试用例。 图 2 需求是真实的、强烈的。 但这些一线工程师平时用的是Excel和飞书，不是GitHub和Terminal。你让他Fork一个项目、配置Claude Code、写.claude目录——他做不到，也没时间学。 两个案例，一个对比 案例A： 一位咨询机构的朋友接了车企项目，要给多个域同时开发AI Agent。问题是：他对这几个域缺乏深刻的工程经验，只能从企业收集文档做"黑盒"训练——把文档丢进去，让AI硬提取。我的判断：有一些价值，但很难做深。 案例B： 一位在德国做了20多年座舱研发的创业者，公司本身就做座舱产品，作为Tier1给国内外车企供货。他现在也在做座舱领域的AI Agent。不同的是，他有二十多年的座舱开发经验和现成的产品积累——他知道哪些know-how最值得喂给AI。我的判断：有可能做成。 差距在哪？ 不是AI能力的差距。同一个Agent 或 Skill，两个人用，输出天差地别。 差距在注入者的领域深度。 图 3 AI工具的上限 = 注入者的领域深度 × AI的能力。 AI的能力大家都一样。决胜的是你往里面灌了什么——你在这个行业踩过的坑、见过的失败模式、积累的判断标准。这些才是AI真正缺的原料。 最近a16z的一篇文章（Institutional AI vs Individual AI）把类似的现象总结得很到位： 针对特定任务构建的领域专用方案，相比通用大模型始终保持能力优势——而且这个优势会持续累积。 翻译成汽车行业的话就是： 通用AI Agent谁都能生成，但领域know-how注入后的AI才是武器——而且这个武器会越用越锋利。 二、说来惭愧，我自己也没用过 坦诚地说：我的那个GitHub Fork，加上那篇公众号文章，前前后后花了大概2个小时，就是周日早上用Claude Code高度自动化完成的。 我没有亲自在Claude Code里跑过一次HARA分析，也没有用它生成过一份SOTIF触发条件报告。 原因很简单——这些具体的分析工作是团队的工程师在做，他们才是每天和工具、标准、真实项目打交道的人。我的日常更多是定方向、定方法、审输出。我协作的团队刚拿了中国汽车功能安全标准化促进中心的卓越贡献奖——这个奖靠的不是某一个人，而是一线工程师的实战积累和团队的协作。我没有亲自操作这个工具，但这恰恰说明了一件事：** ** AI工具要真正好用，既需要一线工程师的实战经验，也需要有人把这些经验结构化地注入进去——这是两种不同的价值，缺一不可。 前几天，雷诺集团的一位开源项目负责人在LinkedIn评论区直接说： ...

摘要：2026年3月，德国VDA发布了全球汽车行业首个AI质量管理标准化指南——VDA 20《AI in Quality Management》（191页）。本文深度解读其AIQM三级风险分级、80项检查表和12个应用案例，分析对中国自动驾驶行业的参考价值，并探讨中国在端到端评估方法论和数据基础设施上的领先优势与机会窗口。 图 1 文末附全文下载链接 章节导读 一、文档背景——VDA AI in QM 是什么？为什么全球汽车行业需要关注？ 二、核心框架——风险分级、80项检查表、应用案例、AI安全标准全景图 三、对中国自动驾驶的参考价值——填补AI质量管理空白、变更管理分类 四、中国落地的额外考量——法规差异、组织文化差异、数据生态差异 五、挑战与优化——自身局限 + 端到端可解释性、数据漂移、供应链协调 六、中国的领先优势——AI应用速度领先、端到端评估、数据基础设施 七、关键启示——对OEM/Tier1、标准制定者、研究者分别的行动建议 八、一句话总结——谁先给路上跑的AI立规矩，谁就定义下一个十年 一、文档背景 2026年3月，德国汽车工业协会（VDA）发布了VDA 20——《AI in Quality Management》（以下简称"黄皮书"），这是全球汽车行业首个针对AI质量管理的系统性标准化指南，共191页。 为什么值得关注？ 德国VDA标准在全球汽车行业的影响力不亚于ISO标准——VDA 6.3（过程审核）、VDA 6.5（产品审核）是几乎所有进入德国市场的汽车供应商的必修课。VDA 20的发布，意味着AI在汽车质量管理中的使用不再是"可选项"，而是开始有了规范化的框架和评估方法。 图 2 黄皮书章节框架 二、黄皮书的核心框架 2.1 AIQM三级风险分级——给AI系统"定安全等级" 黄皮书最核心的贡献是提出了AIQM（AI in Quality Management）三级风险分类方法，基于七个风险维度对AI系统进行评估。 七个风险维度： 维度 评估什么 与自动驾驶的关联 1. AI法规合规 是否属于EU AI Act高风险AI系统 端到端自动驾驶AI组件→高风险 2. 数据保护 是否涉及个人敏感数据 驾驶行为数据、车辆位置→涉及 3. 偏差与公平 模型是否存在系统性偏差 训练数据地域偏差→影响跨区域泛化 4. 透明性 模型是否可解释 端到端黑箱→AIQM-3最高等级 5. 财务风险 错误输出的经济损失 误判导致召回→巨大财务风险 6. 声誉风险 错误的公众影响 自动驾驶事故→极高声誉风险 7. 产品安全特性 功能安全 + 预期功能安全 + 网络安全 最直接的自动驾驶关联维度 分级结果： ...

摘要：博世工程师Thejeswarareddy R开源了一套将汽车工程标准知识系统性注入Claude Code的智能体项目，覆盖75+技能类别。我Fork后补充了自动驾驶安全标准（ISO 21448/34502/4804等）、中国即将实施的强制性国标、以及SOTIF深度实践内容。本文解读这个项目的架构亮点，以及我的补充思路。 图 1 如果你是一个初级的汽车功能安全工程师，你一定有过这样的经历： 早上9点，项目经理发来消息：“这个ADAS功能需要做ASIL分解，下午客户评审前需要给我更新的HARA表格。” 于是你开始翻ISO 26262 Part 3。翻了半小时找到ASIL确定规则，又花20分钟回忆严重度S、暴露率E、可控性C的定义。然后打开Excel模板，逐行填写。填到一半，某个失效模式的ASIL等级拿不准，又翻回标准。等HARA初稿完成——三个小时过去了。 而这还只是一个标准的一个环节。 你同时还要查AUTOSAR的命名规范、MISRA的合规规则、ISO 21434的TARA分析模板、ASPICE的工作产品清单…… 这些工作不难，但极其耗时。据统计，一个初级的功能安全工程师每周大概有10-15个小时花在”翻标准、对条款、填模板”上。 我一直觉得这件事应该有更好的解决方式，但从来没有真正动手去做。直到上周，我看到了一个博世工程师做的事情。 这位博世工程师做了什么 Thejeswarareddy R，博世的一位Lead Engineer，做了一件让我佩服的事： 他把汽车软件工程中最常用的标准和工程知识，系统性地“注入”到了AI助手Claude Code****中，做成了一个完整的开源智能体系统。 图 2 这不是“把几篇标准摘要丢给ChatGPT”那种问答式玩法。他做的是一套经过精心架构设计的工程化系统： 图 3 我来翻译一下这意味着什么。 以前你要做ASIL分解，需要自己翻标准、建模板、填表格。现在你可以直接说： “帮我对这个L3级别的HWP的紧急制动功能做HARA分析，输出ASIL等级” AI会根据注入的ISO 26262知识，按标准流程输出一份结构化的HARA表格。你要做的是审核和判断——而不是把时间花在查找和格式化上。 这个项目有几点让我特别欣赏： **第一，架构设计很讲究。**它用了一种”追加式”安装方式——你现有的开发环境一个字符都不会被修改，所有新增内容都带automotive-前缀避免冲突。这说明作者是真正做工程的人，知道不能动别人的工作环境。 **第二，规模感令人敬畏。**75+个技能类别意味着他梳理了ADAS、BMS、V2X、动力总成、诊断、OTA、数字孪生、Zonal架构等十几个汽车细分领域的知识体系。这不是一两天能做出来的事情。 **第三，完全开源。**MIT协议，你可以自由使用、修改，甚至用在商业项目中。 我做了一些小小的补充 说了这么多好话，说一个”但是”。 这个项目的覆盖重心是传统汽车软件工程——ISO 26262功能安全、AUTOSAR架构、MISRA编码规范、ASPICE过程管理——这些做得很扎实。 但有两个方向，由于作者的工作背景和地域，覆盖比较薄： **一是自动驾驶安全领域的专项标准。**近两三年密集发布了一批重要的ADAS/AD安全标准，原项目基本没有涉及。 **二是中国标准法规体系。**中国正在加速建立自己的智能网联汽车标准，包括两个即将实施的强制性国标，原项目里完全没有。 这两个方向恰好是我日常工作的领域，所以我Fork了这个项目，做了一些补充。以下是我补充的主要内容： 图 4 补充一：自动驾驶安全标准 这几年，自动驾驶安全评估从”没有标准可依”快速进入了”标准框架基本成型”的阶段。以下几项标准构成了当前AD安全评估的核心框架： 图 5 这几项标准，在我的Fork中都以结构化的技能文件形式集成了——不是放一份摘要，而是提取了核心框架、关键概念和工程实施要点。 补充二：中国标准法规 对在国内做L2/L3产品的工程师来说，有两份即将实施的强制性国标是绕不开的： 第一个是L2组合驾驶辅助系统安全要求（GB强标）。 图 6 这是中国第一个针对L2 组合驾驶辅助系统的强制性国家标准。2027年执行，所有新上公告的搭载L2组合辅助驾驶功能的车型都必须满足。它涵盖了ODD定义、功能安全、SOTIF、DMS、HMI、网络安全等全方位要求。如果你在主机厂或Tier1做L2产品，明年这个标准就是你的”甲方”。 第二个是自动驾驶系统安全要求（GB强标）。 图 7 这是面向L3准入的国家战略级的强制标准（还在征求意见中），要求ADS的安全水平至少等同于”合格谨慎的人类驾驶员”。标准里提出了安全管理体系（SMS）、仿真测试验证、在用安全监控（ISMR）等系统性要求，覆盖L3和L4。草案目前50页，结构清晰，对做ADS产品准入的团队非常重要。 ...