自动驾驶安全

摘要：Yoav Hollander 是芯片验证领域的世界级专家，他创立的 Foretellix 把覆盖驱动验证（Coverage-Driven Verification, CDV）带进了自动驾驶。最近，他写了一篇文章，把这套方法论推到了更大的范围：AI 对齐。本文从我的研究领域出发，结合 SOTIF 四象限、Robot SOTIF 的树状结构和中国的标准语境，解读 CDV 的跨领域迁移。核心问题只有一个：你怎么知道你不知道什么？ 几个月前，Yoav Hollander（Foretellix 联合创始人/CTO）给我发了一封邮件。 他是芯片验证领域世界级专家，发明了通用验证方法论（Universal Verification Methodology，UVM）的前身“e”语言，创办的 Verisity 被 Cadence 收购后，又创立了 Foretellix——做自动驾驶覆盖驱动验证（Coverage-Driven Verification, CDV），拿了 NVIDIA、沃尔沃和淡马锡的 C+ 轮融资。 Yoav 读了我几篇关于端到端安全、基于场景测评、SOTIF 的文章后，我们通过邮件和线上会议聊了几轮。最近，他写了一篇文章，把问题推到了更大的范围：AI 对齐。 经过 Yoav 本人许可，我把那篇文章翻译成了中文：[译] 覆盖驱动对齐：Teaching Claude Why 能从自动驾驶验证中借鉴什么。英文原文在这里：Coverage-driven alignment – What ‘Teaching Claude Why’ can borrow from AV verification。 下面从我的研究领域出发，对 CDV 跨领域迁移进行一些解读和延伸——结合 SOTIF 的实际情况，看看 CDV 在中国语境下意味着什么。 两条线的交汇 Yoav 在邮件里说过一句： “I am at heart a V&V guy, thinking about ‘how to achieve best risk reduction per week for the SUT, given fixed resources’. I feel much less confident regarding safety standards and ‘how to build a safety case’.” ...

导读：智能驾驶要“像人一样开车”，前提是搞清楚人到底是怎么开的。本文从“类人驾驶”这个概念出发，讨论人类驾驶行为研究的五个落地方向、获取答案的四条路径，以及我们团队正在做的开源数据实践。全文约5000字。本文 2026 年 3 月底首发于微信公众号，2026 年 6 月收录入本站。 人类自古以来就热衷于研究自己的行为。 婴儿后半夜为什么突然哭醒？我有经验——大半是尿憋的。 两三岁的孩子为什么每天追着你问一百个“为什么”？ 青春期为什么开始在意同学的看法胜过父母？ 刚工作的年轻人为什么明知该早睡却总忍不住刷手机到凌晨？ 人到中年为什么突然迷上了跑步、钓鱼或者自驾？ 人老了，为什么总喜欢翻老照片、讲当年的故事？ 每一种行为研究的背后，都有实际的用处。搞清楚孩子为什么问“为什么”，你就不会不耐烦而是顺势引导；理解了“报复性熬夜”的心理机制，你才能真正改掉它；知道中年人为什么迷上户外，也许下一个消费品牌就藏在里面。 那——人到底是怎么开车的？搞清楚这个问题，又能帮到谁？ 一、研究“人类”驾驶，实现“类人”驾驶 我研究车辆相关的工作，不经意间也快二十年了，时间都去哪儿了！从小对车就非常感兴趣，小时候在农村，很少有漂亮的轿车从门口经过，每次都会和小伙伴追在车后面跑，连闻汽车尾气都觉得是一种乐趣。 高考的时候，每一个志愿填的第一专业都是车辆工程。本科没去成，进了机械工程。后来辗转进入吉大汽车学院读博，研究过水陆两栖车、工程车辆、飞行汽车、商用车……最终聚焦到乘用车智能驾驶方向。 近十几年的核心工作，是研究智能驾驶的安全——怎么让智能系统比人更安全。 在这个过程中，我逐渐意识到一个问题：要让系统“比人更安全、或高一个数量级”，你得先知道人的安全水平到底是什么样的。更进一步，要让智能驾驶“像人一样开车、开得比人更好”，得先搞清楚人到底是怎么开车的。 前几天卓驭×红旗的BOSS直测中，沈老师反复提到一个词——“类人驾驶”。我觉得这个词比行业里常说的“拟人驾驶”更好。“拟人”是“模拟人”，暗含着一个假设：人是标准答案，系统去模仿就好。但“类人”更诚实——它承认智能驾驶不是也不该是人类的复制品，而是一种“像人但可以更好”的驾驶方式。安全的底线要守住甚至超越，但在舒适、效率、交互节奏上，要像人一样自然。 更妙的是，“类人”和“人类”恰好构成一组镜像。我们研究的是“人类”的驾驶行为，研究的目的，是让智能驾驶实现“类人”的驾驶。 人类，类人。两个字颠倒过来只需要一秒，但从研究人类驾驶到实现类人驾驶，中间隔着海量的数据采集、场景分析、模型构建、工程验证——这条路很长也很艰辛，但值得整个行业去推进。 什么是“类人驾驶”？安全是底线，这毫无疑问。但消费者真正为之买单的，是那些比“安全”更微妙的东西：起步不顿、跟车不紧、变道不愣、过弯不晃。绿灯亮了不会傻等半天，遇到加塞不会急刹到乘客晕车。 这些不是靠几个安全指标就能覆盖的。这些是人类在日常驾驶中，每天都在做的事情。 驾驶行为研究其实由来已久。我的导师郭孔辉院士，早在1981年赴美国密歇根大学做访问学者期间，就在驾驶员行为模型与人-车闭环系统动力学仿真方面做出了开创性的工作。当时的驾驶员模型主要服务于车辆操纵稳定性研究，而非自动驾驶。 近年来更常被提及的是“驾驶员参考能力模型”，比如UNECE R157法规和ISO 34502中的定义，主要基于场地测试——在封闭环境中，选取驾驶员样本，针对特定场景进行测试，得出关键安全参数。这些工作很有价值，它们画出了安全的底线。 但场地测试能覆盖的场景是非常有限的。而人类每天在路上面对的场景，99%以上都不是那些极限工况。起步时踩油门的力度曲线，跟车时保持的时距随速度怎么变化，过弯时的轨迹偏好，在十字路口和行人、非机动车怎么交互——这些“正常”的行为数据，才是实现“类人驾驶”的真正基准。 场地测试画出“安全”的底线，自然驾驶数据画出“类人”的基准。两条线之间，就是智能驾驶该有的样子。 二、这个答案到底对谁有用 回到那个问题：搞清楚“人是怎么开车的”，到底能帮到谁？ 我沿着一辆智能汽车从开发到上路的全过程来展开。 产品定义和系统开发 智能驾驶的开发链条上，很多环节都需要人类驾驶行为数据作为参考。 当前行业正在快速向端到端方案演进——感知、决策、控制不再是分开的模块，而是一个大模型端到端学习。但即便在端到端的范式下，仍然有大量工作离不开“人类是怎么开的”这个问题： 产品经理在定义功能边界：城市NOA需要覆盖哪些场景？这些场景中人类的行为多样性有多大？ 系统/安全工程师在划定安全边界：巡航功能需要应对多激进的加塞？什么程度的cut-in算超出系统能力？ 数据工程师在筛选训练数据：海量车端数据中，哪些片段包含高价值的人车交互行为？筛选标准是什么？ 测试工程师在定义验收标准：端到端模型输出的轨迹，怎么判断“够好”还是“不够好”？ 他们面对的其实是同一个问题：人类在这些场景下到底是怎么开的？ 据我了解，现实中很多边界和标准是“拍脑袋”定的，或者从文献里找一个不太完备的数字凑合用。上路后发现太激进或太保守，再反复调。说实话，很多时候做了很多妥协。 如果有一份足够丰富的人类驾驶行为数据——不同速度段、不同道路类型、不同交互场景下的行为参数分布——上面这些工作就可以从“拍脑袋”变成“看数据”。 这不是效率的提升，是开发范式的升级。 标准制定与合规测试 标准法规是智能驾驶准入和上路的门槛。门槛定得太低，有安全隐患；定得太高，企业合规成本爆炸，技术进步被拖慢。 场地测试数据能支撑有限场景下的标准制定。但中国的交通环境——高速加塞、非机动车混行、不规则路口、匝道博弈——远比场地测试能模拟的要复杂得多。 更丰富多样的自然驾驶场景数据与实车场地测试等数据联合，可以在两个维度上帮助标准制定： 一是场景选择更合理。哪些场景在中国的道路上真正高频出现？哪些场景看似常见实则罕见？有了大规模自然驾驶数据的统计支撑，标准中纳入的场景就能更贴近真实道路情况，而不是靠专家经验或个别热点事件来决定。 二是通过阈值更准确。日本的SAKURA项目在这方面做了很好的方法论探索——它提出了“可预见/不可预见”和“可预防/不可预防”的四象限框架，给出了典型场景清单。但要画出每个具体场景中那条“可预防边界”到底在哪里——比如在某个速度段下，多短的TTC算“人类也来不及反应”，多长的TTC算“正常人完全可以避免”——这需要大量真实数据来定义，而不是拍脑袋划一条线。 类人驾驶测评 这是我认为当前最有价值、也最有想象力的应用方向。 现有的辅助驾驶和自动驾驶标准法规测试，大多聚焦在安全性上：能不能识别障碍物？能不能紧急制动？这些当然重要——车厂和供应商会使用“各种方法”让推向市场的量产车的智驾系统都能“通过”这类场景——但消费者的感受远不止于此。 经常看智驾博主试驾视频的朋友一定熟悉这些场景： 高速上开着智驾，旁边车道的车一个接一个插进来——系统每次都礼让，你坐在车里越来越焦虑，最后忍不住接管了。 前面明明没什么车了，智驾还在用60码的速度慢悠悠地巡航——你手动踩一脚油门，车速上去了，体验也上去了。 过一个大曲率弯道，方向盘修正的节奏和你自己开时不一样——说不上哪里不对，但你就是觉得不自然。 这些画面在各种直播和试驾评测中反复出现。有意思的是，博主们和车企领导在描述这些问题时，用的几乎都是主观感受——“跟车太远了”“过弯有点愣”“起步不够丝滑”。但到底“太远”是远了多少？“不够丝滑”的减速曲线长什么样？目前并没有一个权威的量化基准来回答这些问题。 这恰恰是“类人驾驶”真正要解决的事情。智能驾驶要想让消费者真正信任并愿意持续使用，不仅要“安全”，还要在舒适性和通行效率上接近甚至超越人类驾驶习惯——而这些维度的量化，必须建立在大规模人类驾驶行为数据之上。 类人驾驶测评需要的不是“一个老司机的意见”，而是“千万条行车轨迹告诉你的答案”。 事故研究：区分“能避免”和“避不了” 前面说的都是正向开发和测评的应用。还有一个是反向的——从事故中学习。 交通事故数据是极其宝贵的资源。但光看事故本身，你很难判断一个关键问题：这个事故，换一个正常的人类驾驶员，能不能避免？ ...

摘要：ASIL E 目前不是正式标准。它真正有价值的地方，不是提出了一个更高等级名称，而是把 L4/L5 自动驾驶安全论证里一个长期存在的问题说清楚了：当车里没有人时，安全案例不能继续 credit 一个不存在的人类控制者。对我来说，这份 proposal 更适合被翻译成三类工程资产：一页 L4 无人兜底审查清单、ADSafetyPilot 里的四个证据字段，以及 ROAM / DRIVEResearch / ADSafetyPilot 之间的一条运行阶段证据闭环。 前段时间，我在 LinkedIn 上看到一位功能安全同行发了一个 proposal，题目很直接： The Case for ASIL E. 本地 PDF 是 79 页，副标题是 A Sixth Integrity Level for L4/L5 Autonomous Systems。它的核心观点是：ISO 26262 的 ASIL D 是当前最高等级，但它背后的 controllability 逻辑，来自一个仍然有驾驶员作为残余控制者的世界。到了 SAE L4/L5，系统设计目标就是不依赖驾驶员接管，这个假设会断掉。 我读完之后，第一反应不是“ASIL E 要来了”。 恰恰相反，我的第一反应是： 这不是一个新等级问题，而是一个老问题终于被说清楚了。 先把边界说清楚 截至 2026 年 6 月 3 日，ASIL E 不在已发布的 ISO 26262、ISO 21448 或 UL 4600 中。 ...

摘要：2026年6月2日，《机器人预期功能安全实施指南》国家标准项目进入公示，公示截止日期为2026年7月2日。我把这个方向放进 OpenTopic，作为第二个开放研究专题：Robot SOTIF。它不是把自动驾驶 SOTIF 简单搬到机器人上，而是尝试建立一条从标准、ODD、场景、触发条件、物理交互、LLM/VLA 决策安全到 safety case 的证据链。 我最近看到一个标准项目公示，觉得必须认真记一笔。 2026年6月2日，国家标准项目《机器人预期功能安全实施指南》进入公示。项目周期18个月，归口全国机器人标准化技术委员会，公示截止日期是2026年7月2日。 这个标题里最值得关注的词，不是“机器人”。 而是“预期功能安全”。 英文不要逐词硬译。这个领域对应的是 SOTIF，也就是 Safety of the Intended Functionality。 它问的不是“零部件坏了怎么办”。 它问的是： 如果系统没有发生故障，功能也在按设计运行，但在某个复杂开放场景中仍然做出了不安全行为，我们该如何识别、量化、验证和缓解？ 这个问题，自动驾驶行业已经痛苦地讨论了很多年。现在，它开始正式进入机器人标准化语境。 一、为什么这是一个重要信号 传统机器人安全，很多时候围绕隔离、防护、急停、限力、限速和协作应用展开。 这些当然重要。ISO 10218、ISO/TS 15066、ISO 13482 这些标准，给工业机器人、协作机器人和个人护理机器人提供了很重要的安全基础。 但机器人正在变。 它不再只在围栏里面工作，也不再只在结构化产线里重复动作。移动服务机器人、清洁消杀机器人、安防巡检机器人、物流配送机器人、养老医疗机器人，都会进入开放环境，面对普通用户、复杂任务和不稳定场景。 更关键的是，大模型和 VLA 让机器人决策系统从规则逻辑，走向语义理解、任务分解和端到端动作生成。 这时，安全问题就不再只是“有没有撞上人”。 还包括： 机器人是否理解错了用户意图？ 是否在 ODD 边界外仍然继续执行？ 是否为了完成任务而靠得太近、走得太急、停得太突然？ 是否在长时序任务里一步步积累风险？ 是否能把拒绝执行、回退、人工介入和运行日志变成可审查证据？ 这就是机器人 SOTIF 的价值。 二、为什么我把它放进 OpenTopic OpenTopic 的初衷，是把研究思路也像数据集一样开源。 说来惭愧，我手里其实一直有一些可以继续做深的材料。之前已经整理过三份关于具身智能安全、物理交互安全、LLM/VLA 决策安全的报告。但这些报告如果只是留在文件夹里，价值很有限。 这次标准项目公示出来以后，我重新看了一遍，觉得最合适的处理方式不是再写一篇普通评论，而是把它开放成一个可持续维护的问题入口。 所以我在 OpenTopic 里新增了第二个话题： Robot SOTIF：机器人预期功能安全开放研究专题 专题下面先放了三条线索： 机器人 SOTIF 的标准地图与证据链 通用移动物理 AI 的物理交互安全 LLM/VLA 机器人决策安全 我的处理原则很保守：标准只引用官方来源；没有逐条核验的 SOTA 论文和实验数字，先作为研究线索，不写成事实结论。 ...

摘要：OpenODC 是一个把 GB/T 45312—2025《智能网联汽车 自动驾驶系统设计运行条件》落地成机器可读公共数据集的开源项目。目前包含 144 个 ODC 要素 Schema、6 个公开样例库（Tesla FSD Supervised、Tesla 中国区辅助驾驶、华为乾崑 ADS 4、百度萝卜快跑武汉示范运营、小鹏 XNGP、小马智行 Gen-7 Robotaxi）、横向矩阵、双视图（开发者 / 消费者）、以及未来的厂家资料工作台。本文是这个项目的起点说明，也是一封欢迎共创、必要时可以无偿交接的公开邀请。 如果一个车企说自家的智驾系统"全国都能开"，我现在最想问的不是它能开到哪里。 我更想问： 它不能在哪里开？ 什么天气要退出？ 遇到施工、积水、车道线不清、传感器遮挡，系统到底怎么处理？ 这些问题不如"有路就能开"“车位到车位"“全场景"好传播。 但安全往往就藏在这些不太适合做标题的细节里——当然更不是 PPT 右下角的小字备注里 😅。 一、ODC 到底是啥？ 设计运行条件（Operational Design Conditions，ODC），包括运行设计范围 ODD、驾乘人员状态和车辆状态。 国标 GB/T 45312—2025《智能网联汽车 自动驾驶系统设计运行条件》 对 ODC 进行了详尽的阐述（文末有官方标准解读）。 但我们不用陷进标准术语。换成大白话，ODC 就是一张边界清单： 这个功能被设计在什么道路、什么速度、什么天气、什么光照、什么交通参与者条件下使用。 哪些情况不建议使用，哪些情况应该降级，哪些情况应该提示驾驶员接管，哪些情况系统本来就没有公开说清楚。 消费者真正需要的，不只是"这个功能很强”。 还包括——”这个功能在什么情况下不该被依赖"。 这就是我做 OpenODC 的起点。 二、OpenODC 是什么？ OpenODC，目前是一个单人周末开源项目（文末链接）。 它想做的事情很朴素：把散落在各种公开资料里的辅助驾驶和自动驾驶的运行边界，整理成一张可查、可比、可追溯的开放表格。 它不是智驾排行榜。它不是智驾排行榜。它不是智驾排行榜。 也不是安全认证。 它只回答一个更基础的问题： ...

摘要：当无人车的 AI 搞不定的时候，行业有没有一套成体系的应急管理机制？答案是没有，连一个参考标准都没有。本文从武汉萝卜快跑事件出发，回顾 Robotaxi 行业近期的三记重锤，扫描 ISO/SAE/IEC/中国四大标准体系在远程运营领域的全部空白，分析武汉事件后中国监管的根本性转向，并介绍 ROAM（Remote Operations & Anomaly Management）开源参考架构的四个模块、十种运营模式与 52 条标准扫描结果。 3 月 31 日，武汉。 近百辆萝卜快跑在晚高峰时段于高架路段同时熄火。乘客被困车内，SOS 按钮无响应，客服热线打不通。最终解决方案是什么？ 交警，一辆一辆地，手动救。 整个过程持续了两个小时。 同一天，大洋彼岸，美国参议员 Markey 发布了一份名为《Remote Back Seat Operators》的调查报告。他向七家头部自动驾驶公司（Aurora、May Mobility、Motional、Nuro、Tesla、Waymo、Zoox）提了一个很简单的问题： 你们的无人车到底多久需要一次远程人工干预？ 七家公司的回答高度一致——商业机密，拒绝回答。 这两件事凑在一起，指向了同一个问题：当无人车的 AI 搞不定的时候，行业有没有一套成体系的应急管理机制？ 答案是没有。更让人不安的是，连一个参考标准都没有。 一、Robotaxi 的三记重锤 把时间线拉长一点看，2025 年底到 2026 年初这几个月，行业连续挨了三记重锤。 2025 年 12 月 13 日，旧金山电网故障。 Waymo 的 20 多辆车失去通信，瘫在路上。应急服务拨打 Waymo 热线 31 次，累计等了 2 小时 36 分钟。Waymo 事后承认：断网的时候，他们没有办法把整个区域的车统一召回来。 2026 年 3 月 31 日，武汉萝卜快跑事件。 规模更大——近百辆车同时出问题，乘客被困在高架桥上。所有远程系统集体失效：SOS、客服、远程干预，全部瘫痪。 ...

摘要：2026 年 Q1，Harness Engineering 在 OpenAI、Anthropic、明日新程 Nextie 几乎同步出现，“12 Primitives"在社区收敛为新的隐性共识。本文论证：主流路线对 Harness 的投入几乎全部集中在"用户体验、性能、效率"维度；而 Safety-Critical 场景里决定能否上市的"安全合规"维度几乎没有被任何商业玩家系统性投入。本文用 12 Primitives × SOTIF / ISO 21448 的双向映射建立桥梁，并识别 12 条可深入研究的方向，作为标准组织、企业预研团队、第三方机构、研究机构共同补位"安全合规维度 Harness"的起点。本文约一万字，公众号上有约 3000 字的精简版。 一、引子：两条线索的同时浮现 最近两个月，“Harness Engineering"这个词在两个完全不同的圈子里被高频讨论。 1.1 AI 工程圈的密集信号 2026 年 2 月，OpenAI 官方博客《Harness Engineering: Leveraging Codex in an Agent-First World》第一次把这个概念从隐性共识变成正式术语。同年 3 月，Anthropic 推出 Managed Agents 架构，技术文档反复强调"Agent Harness"作为一等工程对象。4 月，明日新程 Nextie 在一个月内连融两轮，陆奇和李开复罕见同框入场，核心叙事是"群体智能 + Harness”。同月新智元一篇《最新风口 Harness，李开复、陆奇已重金入场》把 Harness 推成产业热词。 与此同时，GitHub 上的 awesome-harness-engineering 仓库把 12 个原语（Agent Loop、Planning、Context Delivery、Tool Design、Skills/MCP、Permissions、Memory、Task Runners、Verification、Observability、Debugging、HITL）从社区隐性共识收敛成了一份分类法。 1.2 汽车行业的低调但明确的同期信号 汽车行业的信号则相对低调但同样明确。头部智驾公司不约而同地在加码模型输出可解释性与透明度相关工作，把它定义为未来 5–10 年的核心战略。越来越多的车企技术团队开始在内部文件里讨论 Harness。 ...

摘要：端到端架构正从论文走向量产，但全球自动驾驶安全评价体系的基石——基于场景的开发与测试方法——仍建立在"感知-规划-控制"三模块可分解的假设之上。本文系统分析场景方法在端到端时代面临的五个结构性挑战，论证其仍然有效但不再充分，并提出以大规模航测自然驾驶数据补充场景方法、构建三层方法协同框架的演进路径。 图 1 引子：一个正在发生的范式冲突 2024年，自动驾驶行业发生了一个不太被安全工程师关注、但可能深刻改变他们工作方式的变化： 端到端（End-to-End）架构开始从论文走向量产。 特斯拉FSD V12全面转向端到端神经网络。华为、理想、小鹏、蔚来相继发布或预告了各自的端到端方案。学术界，UniAD拿下CVPR 2023最佳论文，DriveTransformer登上ICLR 2025，DiffusionDrive成为CVPR 2025 Highlight。 但与此同时，全球自动驾驶安全评价体系的基石——基于场景的开发与测试方法——仍然建立在一个核心假设之上：自动驾驶系统可以被分解为感知、规划、控制三个模块，分别识别各模块的干扰因素，进而构建测试场景。 当端到端把这三个模块融为一体，这套方法还能用吗？ 这不是一个学术问题。这是每一个正在做L2+/L3产品的SOTIF工程师、测试工程师和安全架构师，今天就需要面对的实际问题。 图 2 图1 文章全景导航图 一、先理解场景方法的技术内核 在讨论"还有效吗"之前，必须先理解基于场景的方法到底在做什么。很多人对它的理解停留在"就是列一堆测试场景"的层面，这远远不够。 1.1 ISO 34502：场景的三层抽象 ISO 34502:2022是当前基于场景的安全评价领域最重要的国际标准，由日本SAKURA项目主席Satoshi Taniguchi（丰田）主导制定。它定义了一个三层场景抽象模型： 层级 定义 示例 功能场景 用自然语言描述的场景类型 “高速公路上，前车突然变道切入本车车道” 逻辑场景 参数化描述，参数取值为范围 切入角度5°-30°，相对速度10-40 km/h，横向距离1.5-3.5 m 具体场景 参数取值为单一确定值 切入角度15°，相对速度25 km/h，横向距离2.0 m 这个三层模型的价值在于：它把"无穷多的驾驶情况"转化为"有限且可管理的场景空间" 。功能场景用于专家讨论，逻辑场景用于参数化测试设计，具体场景用于可复现的仿真测试。 图 3 图2 ISO 34502 三层场景抽象模型 1.2 SAKURA从物理原理推导场景 上一篇文章详细介绍了SAKURA框架。这里聚焦它最核心的方法论——物理原理方法（Physical Principles Approach）。 SAKURA把动态驾驶任务（DDT）分解为三个过程，然后针对每个过程，基于物理原理系统性地识别干扰因素： 感知过程 → 传感器物理干扰 ├── 摄像头：可见光特性 → 强光、反光、低光照 ├── 毫米波雷达：电磁波特性 → 多径反射、相互干扰 └── LiDAR：红外光特性 → 雨雪吸收、灰尘散射 ...

摘要：2026年3月，JAMA发布了SAKURA自动驾驶安全评价框架第四版（Ver.4.0），一份344页的国家级安全评价技术文档。本文从公司价值、工程师视角、核心方法论到端到端AI时代的前沿挑战，系统解读这份由丰田、本田、日产等日本主流车企联合打造的安全评价体系，并探讨其对中国标准工作的启示。 图 1 2026年3月，SAKURA项目正式结题，日本汽车工业协会（JAMA）发布了SAKURA自动驾驶安全评价框架的第四版——一份长达344页的技术文档。 这不是某个车企的内部报告，而是丰田、本田、日产、马自达、斯巴鲁、铃木、日野、三菱等几乎全部日本主流车企，加上博世日本、大陆日本等Tier 1，在日本经济产业省（METI）主导下，联合打造的国家级安全评价体系。 SAKURA项目主席Satoshi Taniguchi来自丰田，同时也是ISO 34502的项目负责人。该项目也与我们熟知的德国PEGASUS系列项目有密切联动和协作，并支持了第一个L3法规UNECE R157，换句话说，这份文档的方法论直接塑造了国际标准。 图 2 它为什么值得我们花时间读？读完又能用在哪里？ 本文将从公司价值、工程师价值、核心方法论，一直到端到端AI时代的前沿挑战，做一个系统的解读。 一、先搞清楚：SAKURA到底在做什么 SAKURA的全称是Safety Assurance for automated driving using Knowledge-based Universal Risk Assessment。名字很长，核心思路却很简洁： 用物理原理，系统性地穷举自动驾驶需要面对的所有安全场景。 图 3 具体怎么做？框架把动态驾驶任务（DDT）拆解为感知****→决策→****操作三个过程，然后针对每个过程，基于物理原理识别可能的干扰因素： 感知干扰传感器物理机制决定的——雷达的电磁波特性、LiDAR的红外光特性、摄像头的可见光特性，分别会在什么条件下"看不清" 交通干扰道路几何×自车行为×周围车辆行为的系统组合——什么样的交通态势会构成威胁 车辆动力学干扰作用于车辆的物理力——路面状态、风力、轮胎性能如何影响控制 这套方法的精髓在于：不是从事故数据中倒推场景（数据驱动），而是从物理第一性原理正向推导场景（原理驱动）。好处是可以论证场景集合的完备性——你能说清楚为什么这些场景"够了"。 在此基础上，框架还建立了一个四象限模型：按"合理可预见性"和"可预防性"两个维度划分所有场景。核心评价对象是象限A——可预见且可预防的场景，自动驾驶系统在这些场景中不能出事故。 图 4 Ver.4.0相比之前的版本，最大的更新是在之前主要面向结构化道路的基础上，全面纳入了城市行车场景和弱势交通参与者VRU（行人和骑行者），并扩展了一般道路的遮挡场景考量。 图 5 二、这份文档对谁有用？ 整车企业（OEM） 安全论证结构。文档展示了一套完整的、与ISO 21448对齐的安全保障流程——从ODD定义到安全评估的闭环。OEM安全部门可以直接参照搭建自己的安全论证体系。 场景矩阵。框架通过系统组合构建了58类交通干扰场景，为测试场景库建设提供了结构化起点。不用再从零开始拍脑袋。 C&C Driver****模型。这是文档技术含量最高的部分之一——将人类驾驶员的碰撞规避行为量化为具体参数：感知延迟0.75秒、最大减速度0.774G。这些数字直接定义了安全判据的基准线。 自动驾驶科技公司 合规出海的核心参考。Annex G直接对应UN R-157法规的仿真验证要求。如果你的AD系统要出海，这一章是必读。 Pass/Fail****的量化依据。文档给出了Cut-in、Cut-out、Deceleration三类典型场景的可预防性边界——绿色区域表示系统应当能避免碰撞。这是算法测试判据的直接来源。 传感器供应商 Annex E大约100页，是全球最系统的传感器物理原理干扰场景建模文档之一。毫米波雷达5类干扰、LiDAR 3类干扰、摄像头3类干扰，每类都从物理原理出发建立了完整的干扰模型。传感器团队的必读材料。 研究机构 Physical Principle Approach本身就是方法论创新。C&C Driver模型的局限性（仅覆盖制动、仅覆盖安全维度、参数区域局限）是明确的open research question。VRU场景的量化方法尚在发展中。 三、工程师应该怎么读 不同角色的工程师，关注点差异很大。 算法工程师 应该重点理解场景不是随机产生的，而是通过DDT过程分解+物理原理推导出来的。重点看第5章——Cut-in场景如何从数据采集→参数提取→分布估计→概率阈值设定，一步步定义出"合理可预见"的参数范围。以及第6.4节的可预防性边界——这直接决定了你的规划模块应该设置多大的安全裕度。 ...