自动驾驶测试的真相：九家公司、九位专家，揭开这个行业最没说清楚的问题

2018年3月18日晚上10点，一辆Uber自动驾驶测试车在美国亚利桑那州坦佩市撞死了一名叫Elaine Herzberg的行人。她推着自行车横穿马路，车上的系统识别到了她,但没能正确分类,更没能及时刹车。

这件事发生七年后,类似的问题依然没有解决。2025年,中国进行了一场针对36台车辆的ADAS高速公路测试,涉及15种危险场景,结果撞出了216次碰撞。其中一个场景是一只假的黑猪玩偶横穿马路,多辆车压根没反应过来,因为这个物体不在它们的训练数据分布里。

你可能会觉得奇怪:都2025年了,自动驾驶都吹了这么多年,怎么连"识别一只在路上的猪"这种事都做不好?

这正是本文要讲的这篇论文想要挖出来的东西。伦敦大学学院、慕尼黑工业大学、塔尔图大学和伦敦国王学院的研究团队,采访了来自六个国家、九家公司的九位一线自动驾驶测试专家,试图搞清楚一件听起来很基础、但行业内部至今没有共识的事:自动驾驶系统到底应该怎么测?测到什么程度才算够?谁说了算?

为什么这个问题一直没有答案

先说清楚问题有多难。

自动驾驶系统不是普通软件。普通软件的测试逻辑很直接:输入A,期望输出B,跑一遍看对不对。但自动驾驶要面对的是真实世界,而真实世界里的场景数量几乎是无穷的。下雨天加逆光加突然窜出来的猫,和晴天加正常光线加同样的猫,是两个完全不同的测试场景。你永远无法穷举所有可能性。

更麻烦的是,这个行业还没有一套公认的"及格线"。飞机有明确的适航认证标准,药品有临床试验的三期流程,但自动驾驶系统要跑多少公里、覆盖多少场景类型、失败率控制在多少以内才算"足够安全",目前每家公司都有自己的一套内部标准,彼此并不透明,外界也无从比较。

这就好比每个学校都在用自己的方式给学生打分,却从来不组织统一的中考高考。学生之间没法比较,家长也不知道某个分数到底意味着什么水平。自动驾驶行业现在就是这种状态:每家公司都说自己的系统"经过了严格测试",但严格到什么程度、跟别家比起来谁更靠谱,没人知道。

正因为这种模糊,这九位受访专家分享的东西才特别有价值。他们不是在讲PPT里的理想流程,而是在讲自己每天上班要面对的真实困境。

这些专家在测什么样的车

先了解一下受访者的背景,能帮你更好判断后面信息的可信度。

九位专家来自瑞典、中国、德国、英国、日本、比利时六个国家的九家公司,大部分是员工超过一万人的整车制造商,也有软件开发和技术类公司。他们的从业经验从2年到14年不等,但每个人都至少有2年自动驾驶领域的直接经验。角色也很杂:系统分析师、总工程师、系统测试员、研究员、产品工程师、高级工程师、董事总经理、工程经理。

这些人测试的系统类型跨度也很大,从L2级别的辅助驾驶(ADAS,driver assistance system,车辆提供辅助但司机仍需对驾驶负全责的系统)到L4甚至号称L5的全自动驾驶系统都有覆盖。功能上包括自主泊车、城市道路驾驶、高速公路驾驶,乃至跨越城市、高速、乡村路况的全场景系统。

这里有个特别值得说的细节。一位受访者(编号P6)提到,他们公司的泊车系统实际上已经能做到完全自主泊车,达到了L4的技术水平,但官方却把它标注为L2。原因不是技术不够,而是责任归属问题:自动驾驶等级越高,厂商承担的法律责任就越大,监管要求也越严格。L2的责任还在司机身上,所以厂商更愿意把系统标为L2、L2+甚至L2++,即便实际体验已经接近L3甚至L4。

这就像一个厨师明明手艺已经能开米其林餐厅,却坚持只挂"家常菜馆"的招牌,因为米其林招牌意味着更严苛的卫生检查和更高的赔偿风险。表面上是谦虚,实际上是精算过的风险规避。这种"官方等级"和"实际能力"之间的灰色地带,论文特别指出值得未来深入研究。

测试到底是怎么做的:一场层层递进的接力赛

如果你以为自动驾驶测试就是"造一辆车,上路试试",那和真实情况差得远。

受访者描述的测试流程更像一场接力赛,分成好几个阶段,一步步把风险从"纯软件层面"推向"真实马路上"。这套体系有个专业名字。

X-in-the-Loop测试:指模型在环(model-in-the-loop)、软件在环(software-in-the-loop)、硬件在环(hardware-in-the-loop)、整车在环(vehicle-in-the-loop)测试的统称,是自动驾驶行业最主流的分阶段验证方法,核心思路是让被测系统逐步从虚拟环境走向真实物理世界。

具体怎么运作?先从最抽象的层面说起。模型在环测试阶段,系统还只是一堆高层次的数学模型,工程师用它来快速跑大量场景变体,因为这时候还没有具体代码要调试,跑得快、成本低。这一步的另一个好处是让不同团队能各自专注自己负责的模块,比如感知团队不用管规划团队的代码细节。

接下来是软件在环测试,这时候某个功能模块比如控制系统已经写成真实代码了,要在仿真环境里测试这段代码本身或者它跟别的模块搭配起来是否稳定,是否会莫名其妙报错或死机。

再往下是硬件在环测试,把传感器、转向、制动、底盘这些真实硬件接进来,部分模拟软件依然保留。这一步要看硬件反应速度、通信延迟、组件间的相互影响。有位受访者(P3)描述得很具体:用CAN总线和线束把传感器和执行器连接到测试台上,把软件加载进去,验证功能是不是真的存在、是不是真的能跑起来。

最后是整车在环测试,把所有软硬件装进一台完整的车,拉到封闭测试场或者开上公开道路。这时候关注的不只是"功能对不对",还有"体验好不好":刹车是不是平顺、转向是不是舒适、换挡是不是让人心里发慌。

这个从抽象到具体、层层递进的结构,其实很像学开车考驾照的过程。你不会一上来就直接上高速,而是先在驾校练车场学倒车入库,再去简单路段跑几圈,最后才被允许独自上路。如果跳过中间步骤直接把新手扔上高速,一旦出事根本不知道是方向盘的问题、是判断力的问题、还是纯粹运气不好,排查起来无从下手。分阶段测试的价值就在这里:每个阶段只暴露特定类型的问题,方便快速定位和修复。

如果没有这套分层结构会怎样?论文里有个例子特别说明问题。有位受访者(P5)提到,某些极端场景根本没有可靠的"标准答案"数据,自动化评估系统判断不出对错,工程师得亲自去量真实世界的物理距离才能确认系统到底做对了没有。可以想象,如果所有测试都只在真实道路上一次性完成,类似这种需要精细核查的边缘情况会淹没在海量正常数据里,根本找不出来。

测试策略:六种不同的思考起点

除了测试流程,受访者还分享了他们制定测试计划的思路,这部分论文归纳出六种不同的策略取向。

功能驱动策略是最直觉的做法:测试内容完全跟着被测功能走。测泊车系统就去找不同类型的停车场,垂直的、平行的、斜角的都试一遍;测车道保持和自适应巡航,就去高速公路上跑。

需求驱动策略则更系统化,一切从系统需求文档出发,确保每一条需求,无论是功能层面、系统层面还是零部件层面,都被充分定义和正确实现。这种策略下,测试环境的选择要看需求本身的性质。比如要验证一个自动驾驶功能的响应时间是否足够快到能避免碰撞,软件在环或者硬件在环环境根本不够用,必须拉到试车场或者上路实测才能拿到真实数据。

仿真驱动策略,也叫"左移策略",目标是尽量把测试往开发早期推,多用仿真、少用实车,理由很实际:实车测试贵、还有安全风险。但这条路要付出代价,仿真必须足够真实才有意义,而"足够真实"本身又是个无底洞。测感知和视觉系统往往需要接近电影级画质的仿真,而测决策和控制逻辑,低精度的简化环境反而够用了。

开发驱动策略更贴近某些企业实际的迭代节奏。因为ADAS功能跟车辆底盘、动力系统、车身控制系统紧密耦合,开发和测试往往是同步演进的,今天上线一个泊车功能,收集问题,打补丁,下一轮再测,如此循环往复。

数据驱动策略是被反复提及的一种新兴思路,尤其是随着大模型进入自动驾驶领域后变得越来越重要。传统的仿真方法建立在显式的、基于物体级别的建模上,适合规则明确的低阶系统,但现代AI驱动的自动驾驶系统越来越依赖隐式的、基于token的表示方式和海量真实传感器数据,传统的场景建模方式已经跟不上了。行业正在转向直接用摄像头、激光雷达等原始多模态驾驶数据作为测试场景的核心素材。

最后一种叫目标驱动策略,测试用例直接从"保证案例"(assurance case,一套用来支撑系统安全性和质量声明的结构化论证)里推导出来。这种做法用一种叫GSN的工具来组织整个论证结构。

GSN:全称Goal Structuring Notation,目标结构表示法,是一种用来梳理"目标-子目标"层级关系的图形化框架,常用于安全论证,帮助工程师清晰展示"为什么我们认为这个系统是安全的"这套逻辑链条。

这六种策略不是互相排斥的,现实中往往是混着用。这一点其实揣摩得出研究者的用意:他们没有强行给出一个"标准答案"式的最佳策略,而是老老实实呈现了行业里真实存在的多样性,这恰恰反映出这个领域还没走到"大家用同一套方法"的成熟阶段。

怎么知道该往下一阶段推进了

一个更棘手的问题是:测试从一个阶段过渡到下一个阶段,靠什么判断"这一步够了,可以往前走了"?

论文归纳出四种过渡策略。需求驱动型是最理论化的做法,先定义需求规范,分析ODD(Operational Design Domain,运行设计域,指系统被设计用来正常工作的具体条件范围,比如晴天、限速120以下的高速公路),再选择或生成对应场景,跑完之后检查系统是否满足预设的性能要求,达标才推进。

指标驱动型更依赖量化数据。比如从仿真过渡到试车场,要看碰撞次数、偏离道路次数、乘坐舒适度这些指标是否达标;从试车场过渡到公开道路,还要评估延迟、安全行为、对各种交互场景的响应能力。有位受访者(P1)提到一种覆盖率的判断标准,可以按百分比、组合覆盖等级、优化迭代次数来定义,比如设定"跑够多少轮优化迭代,如果没发现新问题,就算测完了"。

经验驱动型听起来不太"科学",但却是行业里非常真实的现状。一位受访者(P2)直言,行业内目前没有清晰的共识来划定不同测试阶段的边界,实践中主要靠各家公司、部门、项目积累的最佳实践和经验判断,团队觉得"信心足够了"就往下推进。

分析驱动型则是基于变更影响分析:系统每次改动都要先分析这次改动影响了哪些规格和实现,再决定哪些测试场景需要重新跑。比如一次改动只影响纵向控制,那横向控制相关的场景可能就不用重跑了,因为之前已经测过。

这四种方式混杂共存的现状,其实暴露了整个行业的一个尴尬事实:大家都知道"经验判断"不够严谨,但目前还没有一套足够可靠的量化标准能完全取代它。这也是论文后面提出改进框架的重要动因。

满意标准:安全到底意味着什么

测试通过的"满意标准"是什么,论文里有个特别值得展开的细节。

有位受访者(P8)提出一个很朴素但极具冲击力的观点:自动驾驶最基本的安全要求,就是不能主动撞上路上的东西,尤其是静止的障碍物。听起来是常识,但现实里很多系统在标准物体上表现良好,遇到"训练数据里没见过的东西"就容易翻车。他提到的那个黑猪玩偶测试就是个例子,这只玩偶之所以能让多辆车失灵,本质原因是它跳出了系统训练时见过的物体分布范围。

类似的问题也出现在Elaine Herzberg的悲剧里,她推着自行车横穿马路的姿态,是一种"不常见的行人呈现方式",系统的感知模块没能正确归类。

这揭示了一个深层次的矛盾:机器学习系统的"聪明"高度依赖训练数据的覆盖范围,而现实世界的丰富程度永远超出任何数据集能覆盖的边界。这不是简单加大数据量就能彻底解决的问题,而是这类系统与生俱来的局限。

除了"别撞上东西"这条底线,受访者还提到了不少具体的量化指标。成功率是最常见的一种,比如泊车系统看不同停车场类型下的成功率,高速驾驶系统看车道偏离、车道居中、弯道处理、减速行为、急刹车事件这些细项。

准确率则常常跟欧洲监管标准挂钩,比如某些欧洲法规和TUV(德国技术监督协会,负责车辆认证等技术合规审查的权威机构)标准要求,开放道路测试跑满300公里,系统准确率必须超过90%。而且白天和夜晚的表现要分别达标,任何一项不达标,整体就算失败,不能靠平均分蒙混过关。

还有一种叫故障率的指标,关注系统在长期测试周期里的问题趋势。高速驾驶这类安全关键功能对故障率要求极其严格,哪怕是很小的bug都可能导致产品无法发布,而泊车这类低速功能因为风险相对较低,标准会宽松一些。

值得一提的是"数据饱和"这种更另类的判断方式。有受访者(P1、P7)提到,他们把路测本质上看作一个数据收集的过程,判断路测是否可以结束的标准是"收集到的里程里,观察到的车辆行为是否持续符合预期"。但这里有个诚实的困惑,连他们自己都还没搞清楚:到底要收集多少数据,才能有信心说这辆车已经足够成熟可以发布了?目前没有一个被普遍接受的标准答案。

那些没人愿意公开谈的挑战

说完了测试流程和标准,该谈谈这个行业真正头疼的问题了。

论文把这些挑战归纳成了十几类,我挑几个最核心、最有代表性的详细展开。

**仿真和现实之间的差距,是被提得最多的一个问题。**

这个差距有专业名字。

Sim-to-real gap:仿真到真实世界的差距,指的是在虚拟仿真环境里训练或测试出来的系统性能,搬到真实世界后往往打折扣,因为仿真环境无法完全复现真实世界的物理特性和随机性。

这个问题至少体现在三个层面。第一个层面是仿真精度不足。有受访者(P9)提到,路面、建筑物、玻璃、树木都会产生不同的物理反射特性,影响传感器和点云数据,而目前仿真环境在这方面的还原度还远远不够。特别是摄像头数据的仿真尤其困难,新型传感器还在不断涌现,仿真跟不上现实设备的迭代速度。

第二个层面更微妙,叫仿真表征能力的局限。有受访者(P7)举了个特别具体的例子:如果一个系统的感知模块和规划模块之间有一个预定义的接口,而这个接口只能表示"检测到的智能体"和"道路结构",却不包括交通锥桶、交通指挥员、临时路障这些元素,那这些场景就压根没法在仿真里被正确表示和测试。他特别提到交通锥桶这个例子,因为这类物体体积小、在训练数据里出现频率低,感知系统很难可靠识别。而感知系统识别不出来的东西,仿真器自然也就没法还原,这形成了一个死循环:要解决就必须重新训练感知系统,这个过程可能要花上几个月,还得依赖收集足够的真实世界稀有场景数据。

第三个层面是仿真质量本身怎么评估的问题。有受访者(P4)提到,像CARLA这样在学界和业界广泛使用的仿真平台,大家其实都不太确定它的精度到底够不够用来测试某些视觉系统或特定模块。

针对第一个层面,行业里出现了一个技术方向的尝试。

3D Gaussian Splatting:一种实时三维场景表示方法,通过大量微小的高斯分布点来重建三维空间,能比传统渲染方式更快速、更逼真地还原真实场景,近年被引入自动驾驶仿真领域,用来提升虚拟环境的物理真实度。

有受访者提到他们已经在探索用这种技术来提升仿真质量,但同时强调,光是提升视觉外观上的逼真度还不够,材质、纹理、传感器反射、环境形变这些更底层的物理真实性也需要跟进。

针对第二个层面的接口局限问题,受访者提出了两个方向:一是端到端架构,直接去掉感知和规划之间的显式接口;二是所谓的"世界模型"。

世界模型(World Model):一种能直接从数据里学习并生成逼真驾驶环境和传感器交互表现的AI技术,目标是让系统能更整合地进行仿真、测试和训练,而不需要依赖预先设计好的模块接口。

Waymo和Nvidia这些公司正在重点投入这个方向。它的好处是能绕开"感知模块识别不出某个物体,仿真就没法还原这个场景"的死结,但代价是牺牲了系统的可解释性,因为端到端系统直接输出驾驶轨迹,不再暴露中间的感知表示,出了问题也更难排查是哪个环节的锅。

这个权衡有点像去一家全自动化的中央厨房吃饭还是一家开放式厨房的餐馆。全自动化厨房出餐速度快、味道稳定,但一旦你吃出问题,厨房是黑箱,没法直接看到到底哪个环节出了差错。开放式厨房你能看清每个步骤,出问题容易定位,但效率和灵活性会打折扣。行业现在正处于要不要往"黑箱但更强大"的方向走的十字路口,这不是一个纯技术判断,而是"可解释性"和"性能上限"之间的取舍。

**第二个大问题是行业缺乏公开的性能基准。**

这一点被一位受访者(P8)称为最关键的挑战之一。他拿大语言模型行业作对比,即便是闭源的大模型,业内也有一批公认的公开评测榜单,大家能在同一套标准下比高低。但自动驾驶公司几乎不公开自己的性能数据、测试数据、传感器配置或评估方法,导致外界根本没法横向比较不同公司的系统谁更靠谱。

虽然确实存在一些公开数据集,比如加州车管所(California DMV)的脱离报告、Waymo开放数据集、nuScenes数据集,但这些数据集在传感器配置、地图信息、评测设置上都不统一,没法直接拿来做公平对比。

针对这个问题,受访者提出了一套组合方案:监管、透明度、行业领导力、标准建设,四管齐下。他特别指出,单靠监管是不够的,因为公司总能找到形式上合规却实际没有真正提升性能的方法。真正能推动改变的,是像Waymo、Nvidia这样的行业头部玩家主动带头公开基准和性能结果,逐渐把透明度变成行业惯例。

**第三个大问题是场景覆盖的不完整性,这被一位受访者(P5)明确认定为最critical的挑战。**

道理很简单:再怎么努力测试,系统总会有覆盖不到的场景,而现实世界里最危险的往往正是那些没被覆盖的稀有场景。这也解释了为什么当前的脱离率和碰撞率数据显示,完全可靠的L4甚至L5级自动驾驶系统离现实还有距离。

针对这个问题,有个方向是用AI生成的方式来扩充测试场景库,思路是不断积累的真实世界数据可以为训练大型AI模型打底,让AI去生成人类可能从未想到过的场景组合。这被描述为一种从"量变到质变"的过程:先靠大规模数据积累打基础,再靠AI去做组合和延伸。相比完全依赖人类设计的场景,AI辅助生成可能更擅长探索超出人类想象力的方向。

不过这里也藏着前面提到的另一层困境:AI生成的场景本身是否足够真实、足够有代表性,又成了一个新问题,论文里称之为"场景真实性的不确定性"。这就形成了一种嵌套的难题,你想用AI来解决场景不够用的问题,但AI生成的场景本身够不够真实又需要另一套验证。

**还有几个不那么"高大上"但极其真实的运营层面挑战,值得单独说一说。**

数据传输困境是其中一个。有受访者(P6)提到,他们的车辆日志需要从车上取出再手动传输到内部网络,而不是像特斯拉那样直接通过云端实时上传。这个流程效率低,尤其是海外测试的时候,国内团队根本没法直接访问车端网络远程取数据。他建议参考特斯拉的云端持续改进模式,但也坦诚地指出,不同国家对数据存储和传输有不同的法律要求,海外部署可能还需要建立本地数据中心并对数据做脱敏处理才能共享,这不是纯技术问题,还牵扯到跨国合规。

资源约束也是个绕不开的话题。有受访者(P3)认为这是最critical的挑战之一,原因很现实:压缩的开发周期和紧迫的上市时间表往往留不出足够的时间做全面测试,公司有时候不得不降低预期的成功率标准来赶发布节点。更让人无奈的是,有些问题技术上是可以解决的,比如传感器计算延迟,但需要更换成本高昂的硬件,一旦开发进入后期,这种改动就变得不现实了,只能带着已知的缺陷发布产品。

不可复现的问题则是另一种令人头疼的现实。有受访者(P3)描述,某些在测试中观察到的问题极其critical,但发生频率极低,几乎复现不出来,即便在看起来完全相同的条件下也难以重现。解决这类问题往往需要测试团队、系统设计负责人、供应商等多方长时间协作。

安全论证的空白同样是个尚未解决的核心难题。有两位受访者(P2、P4)提到,针对基于机器学习的组件,行业还缺乏专门的安全论证方法。现有的安全理论和框架大多是为传统的规则驱动系统设计的,面对大型AI模型的黑箱特性,这些框架的有效性正在打折扣。这里面还牵涉到一个专业概念。

SOTIF:全称Safety of the Intended Functionality,预期功能安全,是一套关注"系统即便没有硬件故障,但因为设计局限或性能不足而导致的安全问题"的国际标准(ISO 21448),这跟传统功能安全标准关注硬件失效的角度不同,更贴合AI系统"没坏,但判断错了"这种问题类型。

未来会怎样:专家们的预测和顾虑

聊完当下的困境,受访者们也分享了他们对未来的展望,这部分内容同样值得认真读。

一个比较一致的预期是测试流程会变得更快、更自动化。有受访者(P9)提到,现在从模型在环到软件在环再到硬件在环的整个流程还是相对顺序化的,未来会通过持续地把真实世界日志数据喂入不同测试阶段来大幅缩短这个流程。他还提到了一个概念。

SDV:软件定义车辆(Software-Defined Vehicle),指的是车辆的核心功能和性能主要由软件而不是硬件来定义和迭代的车辆设计理念,配合OTA(Over-The-Air,空中下载)技术,厂商能像更新手机应用一样远程升级车辆功能,而不需要召回换硬件。

另一个受访者(P6)的预测则更激进一些,他设想未来的车辆本身会成为一个"自主测试代理",能自己判断该测什么、去哪测、收集数据、发现问题、自动反馈改进,几乎不需要人工介入测试过程。这个设想听起来有点像科幻,但如果放在软件定义车辆和大规模OTA更新的背景下想,倒也不完全是空想。

AI在测试场景生成中的应用是另一个被广泛提及的趋势,但受访者也很坦诚地指出了这条路上的现实障碍:除非AI生成的环境能真正在物理层面上还原真实世界的物理规律、传感器行为和动力系统交互,否则这类方法很难被大规模采用。这一点其实又绕回了前面提到的仿真精度问题,说明整个行业的挑战是相互关联、层层嵌套的,不是解决了A就自动解决了B。

行业透明度和数据共享也被寄予厚望。有受访者提到Nvidia开源了名为Alpamayo的安全透明自动驾驶项目,认为这代表着行业正在从"炫技式演示"转向"真实部署和可衡量性能"的阶段,这种转变自然会推动更透明的指标、数据和基准共享。

关于安全论证的走向,有位受访者(P1)提出一个特别值得深思的观点。他们希望减少对"proven-in-use"(通过长期实际使用积累的运行数据来证明系统安全性,而不是通过系统化验证方法)这种论证方式的依赖,转而追求更系统化的安全论证,而不是简单地说"这套系统已经用了很多年没出大问题所以是安全的"。但他也很诚实地承认,如果其他验证和论证方法仍然不够充分,proven-in-use可能仍然会是唯一可行的论证手段。

这个坦白特别打动我。研究者和从业者都清楚地知道"用了很久没出事"不等于"真的安全",但在没有更好替代方案之前,这种不够严谨的论证方式依然会被使用。这不是掩耳盗铃,而是在承认现实约束下的一种权衡。

一个尝试整合一切的框架

基于所有这些访谈内容,论文最后提出了一个叫"证据中心闭环测试框架"的东西,试图把前面讲到的所有零散实践和挑战,串成一套结构化的流程。

这个框架分六个阶段。第一阶段是定义安全声明和测试意图,意思是测试不应该从"我们要测哪些场景"开始,而应该从"我们想证明这个系统满足什么安全或质量声明"开始。比如一个泊车系统的安全声明可能是"车辆在目标泊车运行域内不会撞上静止或移动的障碍物",这个声明再被拆解成更具体、可测试的子目标,比如检测相关障碍物、保持安全距离、无危险行为完成泊车动作。

第二阶段是构建并维护一个场景组合库,场景来源可以是法规标准、专家知识、自然驾驶数据、优化技术、AI辅助生成等多种渠道,每个场景都要打上尽可能丰富的标签,比如来源、运行域标签、稀有度、关键程度、真实性置信度、预期行为等,这样才能清楚知道每个场景在整体测试目标中扮演什么角色。

第三阶段是规划证据生产和测试环境路由,意思是根据每个场景需要产出什么证据,来决定它应该被分配到哪种测试环境,仿真、试车场、还是真实道路,并在正式执行前确认测试就绪状态,比如传感器和日志系统是否配置正确、数据同步是否正常。

第四阶段是应用证据门槛和验收标准,这一步不再单纯依赖工程师的经验判断,而是设置一系列检查关卡,比如场景质量关、仿真适配度关、覆盖率关、性能安全关、数据质量关、变更影响和回归测试关、部署一致性关、发布就绪关。如果某个关卡没通过,就要生成更多场景、优化现有场景,或者换个更合适的环境重新测试。

第五阶段是构建安全论证并决定推进或发布,把整个测试过程中积累的证据整合成一套结构化的安全论证,据此决定系统是否可以进入下一测试阶段、正式发布、在受限运行域内运行、还是需要更多数据或重新设计。

第六阶段是从运营中进行闭环学习,把大规模路测和部署后收集到的运营反馈,比如车辆日志、安全员干预记录、脱离事件、不可复现故障、部署差异、新遇到的场景,统统反馈回场景组合库和回归测试流程里,让整个测试体系随着系统的生命周期不断进化。

这个六阶段框架说白了不是一个全新的发明,而是把访谈里散落各处的实践、痛点和期望,用一条逻辑线串了起来。它最大的价值不在于提出了什么颠覆性的新方法,而在于第一次把"要证明什么"、"用什么场景证明"、"在哪测"、"怎么判断够不够"、"怎么从实际运营中学习"这几件事,明确地连接成了一个闭环,而不是让它们各自为战。

这就像修一座桥。以前各家公司都在各自的河段上架桥,有的用木头,有的用钢筋,谁也不知道对岸的桥能不能跟自己的接上。这个框架试图画出一张统一的施工图,不强求每家公司用一样的材料,但至少让大家知道桥墩要建在哪、跨度该怎么算、验收标准怎么定,这样将来这些桥才有可能真正连成一条完整的路。

写在后面

读完这份访谈整理,我最大的感触是这个行业远比外界想象的更"手工"、更依赖经验判断。我们平时看到的自动驾驶宣传总是充满数字,多少亿英里的路测,多少个九的准确率,但访谈里九位一线专家反复提到的却是"没有明确的分界标准""靠经验判断""目前还没有很有效的解决方案"。这种落差挺有意思,因为它说明公开话语和内部实践之间存在一道明显的缝隙。

有个细节我一直在想。中国那场36车15场景的ADAS测试,撞出216次碰撞,这个数字放在新闻标题里显得挺唬人,但读完整篇论文后我更愿意把它理解成一种"压力测试暴露真相"的健康信号,而不是行业的耻辱。一个愿意把系统拉出来公开撞、公开记录失败数据的测试活动,本身恰恰是论文里反复呼吁的那种"透明度"的雏形。真正让人担心的,反而是那些从不公开测试结果、只靠营销话术讲故事的系统。

还有一个问题我没能在论文里找到答案,也想留给你:当"proven-in-use"这种靠时间堆出来的信任,和"系统化安全论证"这种靠结构证明出来的信任,两者都不够成熟的时候,普通人上车的那一刻,到底应该相信哪一种?

Q&A

Q1：自动驾驶系统测试目前主要用什么方法？

A：主要采用场景化测试和X-in-the-Loop分阶段测试,从模型在环、软件在环、硬件在环逐步过渡到整车在环测试,再到试车场和真实道路测试,层层递进验证系统的功能和安全性。

Q2：为什么自动驾驶系统在仿真里表现好,到了真实世界却容易出问题？

A：这就是所谓的sim-to-real gap(仿真到真实的差距),原因包括仿真环境无法完全还原真实世界的物理反射特性、感知模块的接口限制导致某些物体类型无法在仿真中表示、以及仿真平台本身的精度评估标准不明确。

Q3：自动驾驶行业为什么没有统一的安全测试标准？

A：因为各家公司很少公开自己的性能数据、测试方法和评估标准,行业内缺乏类似大语言模型领域那样公开透明的基准测试体系,导致外界无法横向比较不同厂商系统的真实可靠性水平。