事情发生在上海。 2026 年 9 月 5 日，China GT 一场比赛中，一辆赛车卷入多车碰撞，随后起火，车手被困在座舱里。 最先冲上去的，不是现场消防人员，也不是医疗团队，而是另一名参赛车手。他停车，跑过去，拿过灭火器，拆开受损车体，把被困车手拖了出来。 公开报道说，从起火到获救，大约 49 秒。 49 秒这个数字不算特别漫长。真正让人不安的是，完成这件事的，本应是赛道救援系统，而不是一个仍在比赛中的车手。 这件事后来迅速进入国际媒体。舆论当然会追问赛事管理、红旗时机、医疗车为什么迟到、现场人员是否训练充分。但我想从一个稍微不同的角度看它。 它不只是一次赛事管理的失败案例，更像一个提前出现的系统问题样本。 一、赛车安全，不是一个人的勇敢 很多人对赛车安全的理解，还停留在头盔、防火服、HANS、Halo、防滚架这些装备上。 装备当然重要。但一场真正的赛道事故，考验的是一整条链条。 FIA 在高压赛车安全框架里，反复强调的不是某一件新设备，而是角色和责任先固定下来。它的三个运营支柱是，现场电子安全代表、赛事控制室的专门协调链路，以及能够快速判断车辆是否安全的技术系统专家。1 换句话说，成熟赛事在事故发生之前，已经想好了谁负责判断、谁负责指挥、谁负责接近车辆、谁负责灭火、谁负责把伤员交给医疗车。 FIA University 最近发布的医学与安全白皮书，进一步把事故现场的救援指挥角色正式化，称为 Rescue Chief，并计划在 2026 年前对部分高级 FIA 医疗人员设定强制性的院前救护资质。2 这些词听起来像组织管理，但它们的价值非常具体。事故现场最怕的不是没有人愿意冲上去，而是大家都冲上去，却没有人知道下一步该做什么。 DMSB Academy 在纽伯格林做过国际医疗训练日。参加者不只是医生，还有医疗车驾驶员、救援人员和来自多个国家的急诊团队。训练内容包括真实赛车上的破拆，以及赛道创伤生命支持。3 他们的训练目标不是把人教成英雄，而是把灭火、接近、固定、破拆、转移这些动作，练成不需要临时讨论的分工。 这才是赛车安全真正的护城河。 二、连环碰撞没有标准答案，但有分层设计 如果只把这次事故看成单辆车起火，就会忽略一个更重要的问题，它是多车碰撞。 赛车领域并没有一个叫做“三车连环碰撞”的统一认证测试。FIA 的碰撞认证，是把前、侧、后、翻滚结构、转向柱等方向拆开，分别做静态和动态测试。45 有意思的是，部分认证还会在已经受损的结构上继续测试。这个做法的潜台词很清楚，一辆车在第一次撞击后，还要能承受后续冲击。 这是最接近连环碰撞的设计逻辑。 在此基础上，赛车安全还用很多层设计降低二次、三次碰撞的风险。 风险 典型设计 多次冲击挤压座舱 生存舱、前后碰撞结构、侧面侵入结构 多次加减速伤害头颈和脊柱 HANS、头枕、赛车座椅、多点式安全带 车轮或部件在二次碰撞中击中车手 Halo、轮系拉索、后部翻滚结构 碰撞后起火或电击 燃油箱隔离、高压电气系统隔离 车辆撞墙后反弹回赛道 TecPro 等吸能护栏 密集车流中车辆高速打转离地 NASCAR 的 roof flap 和 A-post flap 这些设计不是一次性发明，而是大量真实事故之后逐渐补上的。 这些分层设计分别可以在 FIA 的碰撞认证、赛道护栏、Formula E 轮系拉索规则和 NASCAR 防离地装置中看到。45678 ...

摘要：L2 辅助驾驶、L3/L4 自动驾驶、人形与载人四足机器人，三类产品共享同一套信息安全方法论，却在责任主体、监管形态与安全-网络安全耦合深度上分层。本文系统梳理三类产品的要求、差异、标准法规与最佳实践，并重点回答信息安全与功能安全（FuSa）/SOTIF 及整机安全的融合程度差异。 结论速览 三个产品族都已进入「网络安全是准入底线」阶段，但强制力梯度明显：L2 已落地、L3/L4 门槛最高、移动物理 AI 最薄弱也演进最快。 差异的本质是三句话：L2 把网络当「信息资产」护，L3/L4 把网络当「安全系统」护，物理 AI 把网络当「物理安全装置」护。 融合程度：L2 是协调态，L3/L4 是融合/收敛态，移动物理 AI 是「机理一体、方法空白」的一体化错位。 AI/ML 对抗面（数据投毒、逃避攻击、模型窃取）是 2026 年三类产品共同的新缺口，传统标准（21434/62443）覆盖不足。 最佳实践高度同源（TARA、纵深防御、SBOM、安全 OTA、监测、渗透测试、隐私影响评估），是可跨本体迁移的工程纪律。 一、分析框架：三条主线 + 融合度双轴 理解差异，抓两条结构比背标准号更有效。 三条主线决定「要求」：有没有人类兜底、跑在什么物理环境里、监管用什么抓手。L2 有人兜底、L3/L4 无兜底、移动物理 AI 控制的是物理本体与平衡——这三条直接决定网络安全是「信息资产问题」「安全系统问题」还是「物理安全装置问题」。 融合度双轴决定「耦合」：一是耦合的必要性（由兜底与物理后果直接性决定），二是方法论的成熟度（由标准是否落地、是否有统一的联合论证方法决定）。两个轴在三个产品上呈反相关错位。 二、共同工程底座 无论 L2、L3/L4 还是机器人，网络安全均已从「增值功能」变为「准入条件」，共享同一套方法学骨架： 风险驱动：以 TARA 为起点，基于 STRIDE 分类识别威胁，评估攻击可行性（ISO/SAE 21434 的攻击潜力与 CAL 1-4 风险等级）。 纵深防御：安全启动、HSM/可信执行环境信任根、代码签名、加密通信、网络分区与安全网关、运行时入侵检测（IDPS）。 全生命周期：概念—开发—生产—运维—退役全程覆盖，安全事件可追溯、可响应。 供应链与 SBOM：CycloneDX/SPDX 格式、CVE 持续监测、供应商约束与联合风险评估。 安全更新与 OTA：签名验证、回滚保护（UN R156 / ISO 24089 / GB 44496）。 验证与红队：静态分析、模糊测试、渗透测试、故障注入。 隐私与数据合规：最小化采集、隐私影响评估（PIA）、加密存储与传输（GDPR / 中国《数据安全法》《个人信息保护法》）。 AI 侧新增：对抗样本鲁棒性、感知冗余（多传感器交叉验证）、模型/数据投毒防护、运行时模型监控——正成为三类产品共同的新增维度。 三、L2 辅助驾驶（ADAS）：已强制合规，防干扰防泄密 要求与监管 中国：GB 44495-2024《汽车整车信息安全技术要求》原定 2026-01-01 实施，第 1 号修改单（2026-01-28）把实施时点延后约半年、适用范围收窄至 M/N 类（挂车不再强制）、调整申报审核方式。 欧盟：UN R155（网络安全＋CSMS，新车型 2022-07 起、所有新车 2024-07 起强制）、UN R156（软件升级＋SUMS）；技术依据 ISO/SAE 21434 与 ISO 24089。 中国配套：GB/T 46194-2025（等同采用 21434，2025-10-05 实施）、GB/T 44899-2024《道路车辆网络安全 通用要求》（2025-09-01 实施）、GB/T 40861-2021、GB 44496-2024《汽车软件升级通用技术要求》。 威胁焦点 远程攻击（T-Box/IVI、手机 App）、总线注入/篡改（CAN）、OTA 恶意更新、OBD 诊断接口、蓝牙/WiFi 入口。 数据侧：位置、驾驶行为、个人信息泄露；车辆被「控车」或「僵尸化」参与 DDoS。 与安全（FuSa & SOTIF）的关系 L2 由驾驶员全程负责，网络安全主要保护「辅助功能不被干扰、数据不被泄露」，单个攻击一般不会直接造成动态驾驶任务（DDT）失效。因此是「弱耦合/协调态」——目标是别被干扰，而非攻击后系统自担后果。 ...

《An Introduction to System Safety Engineering》既系统讲解经典安全工程基础，也用系统思维回应软件、智能化、复杂系统与组织带来的新问题。 中文版《系统安全工程导论》由我和王红老师两个课题组合作翻译。 相对于本书作者、MIT 教授 Nancy G. Leveson，我猜想大家更熟悉的是她提出的 STPA——系统理论过程分析。 该方法广泛应用于航空、航天、核能、化工等软件密集、人与自动化深度交互的安全关键复杂系统。最近几年，它在汽车行业，尤其是自动驾驶系统中也得到越来越多的应用。 SAE J3187 给出了 STPA 用于安全关键系统评估的推荐实践；国内《道路车辆 系统理论过程安全分析方法》国家标准项目也在推进中。 但是，STPA 只是本书的一小部分。 这本书真正想回答的，是一个更基础的问题：今天的安全工程师，应该具备哪些不会很快过时的基本功？ 一、它首先是一本夯实基础的系统安全教材 MIT Press 对原书的概括很准确：全面、与时俱进地介绍经典安全工程的基础，同时为未来的安全挑战作准备。 全书从安全、风险和危害等基本概念讲起，系统覆盖事故分析、危害分析、安全设计、软件安全、人因、安全保证、管理与运行。 FMEA、FTA、事件树、HAZOP 和 STPA 都讲，但不把任何一种方法当成万能答案。 本书更关心的是：每种方法基于怎样的事故模型？适合解决什么问题？边界又在哪里？ 会做安全分析、会填各种分析表，不等于会做安全。 安全工程师真正需要的，是面对一个新系统时，仍能判断该看什么、该问什么，以及手里的证据到底够不够。 二、它也是一本面向未来复杂系统的专著 今天的系统比过去复杂得多。 软件承担越来越多的控制功能，人与自动化系统不断重新分工，设计、运营、维护和管理相互影响。事故未必从某个部件失效开始，也可能来自多个“正常”部件之间的不安全交互。 因此，这本书一方面保留经典安全工程的基础；另一方面引入系统思维和系统理论，讨论复杂性、控制、反馈、组织，以及政策和伦理。 这是它最有价值的地方：不急着宣布旧方法过时，也不把新方法包装成灵丹妙药，而是把两者放进同一张地图里。 全书还收录了多个历史重大事故的分析案例，包括挑战者号、哥伦比亚号、切尔诺贝利和福岛等。 医疗、航天、石化和核电看起来离汽车很远，但事故背后的问题并不陌生：错误假设、反馈不足、组织沟通失效，以及对自动化的过度信任。 事故不同，工程上的教训可以迁移。 三、这本书为什么值得推荐？ 因为它既适合刚接触安全工程的学生，也适合已经做了多年项目的工程师。 学生可以用它建立一张完整的知识地图，不必一上来就被某一种方法绑住。 工程师可以用它重新校准熟悉的工具：哪些问题已经覆盖，哪些问题还藏在接口、场景和组织里。 管理者也可以借它理解：安全不是安全部门交付的一堆文档，而是设计、验证、运营和管理共同形成的系统属性。 对汽车行业而言，它不能替代 ISO 26262 或 ISO 21448，也不会直接告诉你某张表怎么填。它更像一本方法论的基础教材，让我们知道这些工作为什么要做，以及流程合规之后还要继续追问什么。 当下，AI 正在辅助驾驶和自动驾驶中得到广泛应用。L3、L4 高级别自动驾驶系统的安全运行依赖下图所示的众多利益相关方。建立扎实的系统思维，夯实系统安全工程基础，有利于我们更好地面对和处理未来复杂系统的安全问题。 图：安全关键系统中的利益相关方及反馈关系，源自中文版《系统安全工程导论》图 3.10。 四、关于中文版 本书中文版由我和王红老师两个课题组——吉林大学自动驾驶安全联合实验室、清华大学智能汽车设计与安全性研究中心——合作翻译，多位师生参与，李骏院士、王永军老师主审。 如果你是安全工程专业的学生，或者在汽车、航空航天、轨道交通、能源、医疗器械等领域从事安全相关工作，这本书值得放在案头：初读用来建立地图，遇到具体问题时再回来精读细查。 工具会更新，系统会越来越复杂。 真正经得起变化的，仍然是理解事故为何发生，又如何在设计中阻止它发生的能力。 延伸阅读：机械工业出版社《每日好书推荐｜〈系统安全工程导论〉——MIT 教授 Nancy Leveson 系统安全工程重磅新书》。 ...

今天是我在杜伦大学实验室停留的最后一天。 去实验室的路上，我随手拍下两段平凡至极的日常画面。没想到，无意记录下来的碎片光景，反倒成了这座古城送给我最珍贵、也最通透的最后一课。 那段两分钟的视频节奏很慢。如果愿意，也可以先看视频，再读下面这段文字： 杜伦最后一课：不急不徐，深扎稳打 威尔河对岸的杜伦大教堂 杜伦是一座沉淀了千年英伦文脉的古城。 威尔河穿城而过，古老的石拱桥横跨流水，见证数百年的光阴更迭。镜头里，一位老者独坐窄窄的小舟上，不疾不徐地摇着船桨。 没有赶路的匆忙，没有刻意的奔赴。 小船顺着河水的节奏缓缓前行，慢悠悠地穿过斑驳厚重的历史石桥。流水潺潺，桨声轻缓，古老建筑倒映在河面上，时间好像在这里放慢了所有脚步。 威尔河上的泛舟老者 世人总习惯追逐速度，痴迷捷径，执着于快出成果、快步前行。 可这位撑船老人教会我的第一件事是：真正的前行，从不是逆流狂奔，而是顺应节奏，从容慢行。 人生和科研从没有恒定的加速键。 很多赶路，不必急于求成。水流有快慢，前路有缓急。稳住自己的节奏，沉下心把控方向，哪怕步履缓慢，也能稳稳穿过岁月长河里一座座关口。 浮躁的时候急于冲刺，只会打乱本心。 不急不徐，方能行稳致远。 威尔河上的石拱桥 不远处的校园草坪上，我拍下了第二个画面。 园艺工人驾驶着小型工程压实车，一遍遍平整、夯实整片草坪。机器匀速缓慢地行进，没有一蹴而就的完工，也没有敷衍潦草的作业。 它只是一次又一次碾压土层、夯实草根，把松软松散的土地压得紧实稳固。 这一幕，刚好诠释了我此行最深的一层修行： 深扎稳打，沉底筑基。 夯实草坪的工程车 我们做学术研究、深耕专业领域，恰如这片草坪的培育。 光鲜平整的地表从不是凭空长成的。所有肉眼可见的平稳与成果，都源于地下看不见的深耕和夯实。 松散的地基撑不起繁茂的草木，浮躁的根基做不出扎实的科研。 无数枯燥重复的打磨、反复落地的验证、沉下心沉淀积累的基础工作，就像工程车一遍遍碾压草坪的过程：枯燥、缓慢、不起眼，却是一切成长和突破的根本。 所有惊艳的成果，都源于默默扎根、步步夯实。 所有长远的精进，都离不开脚踏实地、不浮不躁的沉淀。 在外研学近一年，最难的是放下焦虑 辗转纽卡斯尔与杜伦两地，转瞬在外研学已近一年。 朝夕深耕学术的日子匆匆而过，总让人恍惚察觉时光飞逝，也时常生出时间不够用的紧迫感。 身处异国研学，我心底始终藏着一份隐秘的焦虑：害怕放缓脚步就跟不上国内的发展节奏，担心潜心沉淀的日子里，自己悄然落后于并肩前行的同行。 这份对进度的忐忑、对时光的惶恐，让我一度在浮躁的紧迫感中反复内耗、步履焦灼。 直到离开这天，威尔河上的孤舟和草坪上的工程车，帮我解开了这个心结。 这便是杜伦送给我的最后一课。 无关学术理论，无关工程落地，而是刻在古城风骨里的人生修行： 上善若水，不急不徐；立身成事，深扎稳打。 对外从容，对内扎实 从容，是对外的处世节奏。 扎实，是对内的立身根基。 对外，学渡河老者：顺应时序，稳住心性，不慌不忙，从容奔赴前路。 对内，学园艺夯土：沉底扎根，步步夯实，摒弃浮躁，筑牢自身根基。 科研工作如此，人才培养如此，工程落地如此，行路如此，人生亦是如此。 不必跟风疾驰，不必焦虑快慢。 把脚步放慢，把根基扎深。 前路漫漫，稳比快重要。 行而不躁，深耕方有大成。 带走这堂课 告别杜伦，带走这堂课。 往后治学、行路、生活，我都希望能守一份从容不急，持一份深耕笃行。 不急不徐，是面对世界的节奏。 深扎稳打，是安顿自己的根基。 本文原发于微信公众号「张玉新-AutoZYX」。视频链接：杜伦最后一课：不急不徐，深扎稳打。

译者按：本文译自 Yoav Hollander（Foretellix 联合创始人/CTO）2026 年 6 月 8 日发布在 LessWrong 的文章 Coverage-driven alignment – What ‘Teaching Claude Why’ can borrow from AV verification，翻译已获作者本人授权。Yoav 是芯片验证领域的世界级专家、“e”语言发明人，他创立的 Foretellix 把覆盖驱动验证（CDV）带进了自动驾驶。译文保留了原文的全部链接。术语对照：alignment 译作“对齐”，misalignment 译作“失对齐”，safety 译作“安全”，security 译作“安全防御”，bucket 译作“桶”。我的解读与延伸，见《从 Robot SOTIF 看 CDV 的跨领域迁移》。 摘要：本文提出，对齐训练可以从覆盖驱动验证（Coverage-Driven Verification, CDV）中获益。Anthropic 最近报告称，向 Claude 教授对齐规则（通过在对齐相关故事上进行预训练式的下一 token 学习），比主要依赖 RL 式行为塑造更有效。一些自动驾驶开发者也得出了类似的结论，但他们还会额外使用一套系统性的、覆盖驱动的方法论来做训练和验证。我认为，对齐研究者应该考虑从这套方法论中借鉴思路；本文给出了具体建议（例如，如何使用并持续精化一张显式的覆盖地图）。 背景 Anthropic 的发现：Anthropic 最近发表了 Teaching Claude Why（另有扩展版）。他们发现，用行为演示来训练 Claude 几乎没有帮助；而用宪法文档加虚构故事、通过普通的下一 token 预测来训练（他们称之为 SDF，合成文档微调），把失对齐行为减少到了原来的三分之一以下（3x+），并且这些改进（用多种方式评估）在 RL 训练之后依然保持。最大的杠杆不是展示正确的行为，而是教授行为背后正确的推理和原则。 SDF 把更多的规范性负担转移到了预训练式学习中，减少了对基于 RL 的对齐塑造的依赖。 Teaching Claude Why（下文简称 TCW）让 Claude 在对齐评估上的表现大幅改善，而且这些改进在（中等强度的）RL 训练之后依然保持——在整体相当黯淡的对齐图景中，这算得上一个好消息。于是我开始思考进一步改进它的办法：理想情况下，让最终获得的对齐在长周期 RL 中也能保持（见下文）。 ...

摘要：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，目前是一个单人周末开源项目（文末链接）。 它想做的事情很朴素：把散落在各种公开资料里的辅助驾驶和自动驾驶的运行边界，整理成一张可查、可比、可追溯的开放表格。 它不是智驾排行榜。它不是智驾排行榜。它不是智驾排行榜。 也不是安全认证。 它只回答一个更基础的问题： ...