证据中心闭环框架：自动驾驶怎么测才算过关

自动驾驶测试最尴尬的地方，不是没工具，而是工具、场景、指标全都有，最后还是没人敢拍板“能上路了”。这篇论文直接去问了6个国家9家公司的实战派，把工业界到底怎么测、卡在哪、以后想怎么测，摊开讲明白了。

龙哥读论文发布于 2026-08-14 21:47:07 阅读 4 查看原文

#自动驾驶 #AI应用 #综述

原论文信息如下：

论文标题:
In the Driver’s Seat: A Multi-Company Study on the Reality of Autonomous Driving System Testing

发表日期:
2026年07月发表单位:
University College London, Technical University of Munich, University of Tartu, King’s College London 原文链接:
https://arxiv.org/pdf/2607.15820v1.pdf

自动驾驶测试为何仍被视为“玄学”？

自动驾驶最难的地方，从来不是“能不能跑起来”，而是“凭什么说它安全”。功能演示视频里，车能稳稳拐弯、识别行人、自动泊车，看起来像是已经毕业；可一旦进入测试环节，问题就变成了另一句更扎心的话：到底测多少场景才够？用什么指标才算过关？模拟器和现实世界差了多少？

这篇论文没有继续在实验室里“脑补最佳实践”，而是直接去问工业界：6个国家、9家公司、9位一线专家，他们到底怎么测自动驾驶系统（ADS，Autonomous Driving Systems，自动驾驶系统），卡在哪，未来又想往哪走。这个视角很难得，因为它不是再造一个漂亮框架，而是先把现实世界里那些不太体面的细节摊开。

图：论文提出的证据中心闭环测试框架。整篇文章的核心，不是单点测试技巧，而是把“证据怎么收集、怎么验证、怎么回流到下一轮测试”串成闭环。

6国9家一线公司：他们的真实测试流程是怎样的？

先说结论：工业界的自动驾驶测试并不是一条“从仿真到路测”的直线，而更像一条来回折返的流水线。不同公司、不同车型、不同自动化等级，测试流程都不完全一样，但大体都围绕场景、证据、环境、回归四个词打转。

图1：受访者所工作的自动驾驶系统特征，包括功能、运行设计域（ODD）、自动化等级和系统架构。

从图1能看出，受访公司覆盖的系统很杂：有自动泊车，也有城市驾驶、高速驾驶，还有跨城市/高速/乡村道路的全栈方案。自动化等级从SAE L2到L5都有，架构上则以模块化为主，也有人开始往端到端和混合架构上试探。换句话说，论文讨论的不是某一种“理想自动驾驶”，而是真实工业现场里那堆形态各异、还没完全统一口径的系统。

在测试策略上，论文总结出几类典型思路。第一类是功能驱动：测什么功能，就围绕对应场景来排计划，比如泊车就测垂直、平行、斜列车位，高速巡航就去高速路。第二类是需求驱动：测试不是拍脑袋，而是从需求和安全目标倒推，软件在环、硬件在环、车在环、实车路测分别承担不同证据角色。第三类更有时代感，叫左移+仿真驱动，意思是尽量把测试前移到仿真里，少在真实道路上“拿命堆”。

这里的“X-in-the-loop”也值得顺手解释一下。它是工业界常用的一组术语，X 可以是 model、software、hardware、vehicle，分别对应模型在环、软件在环、硬件在环、车在环。简单说，就是把系统从“纸面模型”一路推进到“真车真路”，每一层都做不同粒度的验证。这个思路不新，但论文的价值在于它把这些层级在工业界到底怎么用、怎么衔接，说清楚了。

图2：测试过程的主题模型，包括整体策略、测试流水线、具体活动，以及它们之间的流转和转换关系。

图2把这条流水线画得很直白：先定策略，再进各类在环测试，然后进入台架、封闭场地、公开道路，最后还要面对认证和合规。听起来像教科书，实际做起来却像搬家——每往前走一步，设备、人员、数据、责任边界都要重新配一遍。尤其是车队集成阶段，传感器、信号采集、定位模块、通信设备都得先装好、调好、排错，测试还没开始，工程师已经先被“前置工作”消耗了一轮。

论文还提到一个很现实的灰色地带：有些系统实际能力已经接近L3甚至L4，但官方口径仍保守地标成L2或L2+。原因并不神秘，主要是责任、法规和商业风险。这个现象很关键，因为它说明测试不只是技术问题，还是责任边界和产品叙事的问题。系统能开，和系统敢不敢被宣称能开，是两回事。

为了更深入地理解这些流程，我们有必要拆解一下每个阶段的具体输入和输出。在策略制定阶段，输入通常是系统需求文档、安全目标（如ISO 26262或ISO 21448中定义的危害分析与风险评估结果）以及运行设计域（ODD）的详细描述。输出则是一份测试计划，明确哪些场景需要覆盖、使用哪些测试环境、以及每个阶段期望收集的证据类型。例如，对于自动紧急制动功能，策略会规定在仿真中测试100种不同的前车切入场景，在封闭场地中验证30种典型场景，最后在公开道路上通过影子模式收集1000小时的干预数据。

进入在环测试阶段后，模型在环（MIL）是最早的环节，主要验证控制算法的逻辑正确性，输入是数学模型和理想化的传感器信号，输出是算法是否在数学意义上收敛。软件在环（SIL）则将算法编译成实际代码，在虚拟环境中运行，输入开始包含更真实的传感器噪声模型，输出关注的是代码实现是否与模型一致。硬件在环（HIL）是最关键的转折点，它将真实的ECU（电子控制单元）接入仿真环境，输入是真实的电信号和总线数据，输出验证的是硬件是否能在实时约束下正确执行软件指令。一位受访者特别强调：“我们在HIL上发现过因为CAN总线延迟导致刹车指令晚到20毫秒的问题，这在MIL和SIL里根本不可能暴露。”车在环（VIL）则是将真实车辆放在测试场地上，但通过虚拟场景注入来制造危险情况，输入是真实车辆状态与虚拟交通参与者数据的融合，输出是系统在接近真实动态下的响应。

在台架和封闭场地测试中，输入变成了经过标定的真实传感器（摄像头、激光雷达、毫米波雷达）和经过精心设计的物理场景（如假人、假车、特殊路况）。输出是传感器融合、感知、规划、控制全链路的端到端性能数据。一位来自欧洲的受访者提到，他们在封闭场地中专门搭建了一个“雨隧道”，可以精确控制降雨强度和路面水膜厚度，用来验证系统在湿滑路面的制动性能。这种测试的输入参数多达50多个，包括雨滴大小、风速、光照角度、路面摩擦系数等，输出则是一张“性能边界图”，标明系统在哪些参数组合下会失效。

公开道路测试则是最终的试金石。输入是真实交通流中的无限变量，输出不再是简单的“通过/失败”，而是一系列需要人工分析的“异常事件”。论文中受访者普遍反映，公开道路测试的最大挑战不是收集数据，而是从海量正常驾驶数据中高效地筛选出那些真正有意义的边缘案例。一家公司提到，他们每天从测试车队收集超过10TB的数据，但其中99.9%都是正常驾驶，只有不到0.1%的数据值得深入分析。为此，他们不得不开发专门的数据挖掘工具，用规则和异常检测算法来标记那些可能暴露系统弱点的片段。

*表格超出部分左右可以滑动

论文主体思路	对应内容
应用场景	自动驾驶系统与高级驾驶辅助系统的工业测试、验证、认证与安全论证
问题建模	围绕测试实践、挑战、潜在解决方案与未来趋势的工业访谈研究
模型Backbone及选择原因	无深度学习模型；采用半结构化访谈与主题分析，更适合获取工业实践细节
损失函数	无
训练数据集	9家公司、9位专家的访谈数据，覆盖6个国家
测试数据集	访谈转录文本、录音与主题编码结果
训练方法	半结构化访谈 + 主题分析 + 迭代编码与归纳
实验效果	不是数值SOTA，而是形成了较完整的工业实践画像，并提出闭环框架
方法优势	贴近真实工业场景，能补足纯文献综述看不到的执行细节
方法缺点	样本量有限，结论依赖受访者经验，难以直接推广到全部公司与地区

痛点重重：模拟与现实差距、场景覆盖、安全论证……

工业界最头疼的，不是“有没有测试工具”，而是“工具能不能真的证明系统没问题”。论文总结的挑战非常集中，几乎每一条都能戳中自动驾驶测试的软肋。

图4：自动驾驶系统测试挑战的主题模型。

第一类痛点是场景真实性。仿真里能造出无数极端场景，但“像不像真世界”才是关键。传感器噪声、交通参与者行为、天气变化、道路细节，这些东西一旦和现实不够像，测试结果就会变成“在模拟器里很稳，在现实里很悬”。一位受访者举了一个具体的例子：他们的仿真环境能完美模拟雨天，但真实雨天的摄像头图像会因为镜头上的水珠产生局部模糊和光晕，这种“脏镜头效应”在标准仿真中几乎从未被建模。结果就是，系统在仿真中雨天测试通过率高达98%，但在真实雨夜测试中，车道线检测的准确率直接跌到了60%以下。

第二类痛点是场景覆盖。自动驾驶面对的是组合爆炸，不可能靠人工把所有场景穷举完；但如果覆盖不够，安全论证又站不住。论文中详细讨论了场景覆盖的度量问题。受访者提到，他们通常使用“场景参数空间覆盖率”来量化覆盖程度。例如，一个简单的变道场景可能涉及自车速度、目标车速度、相对距离、道路曲率、路面摩擦系数等5个参数，每个参数取10个离散值，理论上就有10^5 = 100,000种组合。但实际测试中，受限于时间和成本，他们可能只能覆盖其中几百种。问题在于，没有人能准确回答“覆盖了1%的参数空间是否意味着99%的风险未被发现”。一家公司尝试用统计方法建立“覆盖率-残余风险”模型，但受访者坦言：“那个模型本身的假设就很多，我们不太敢用它来做最终决策。”

第三类是仿真保真度，也就是模拟器到底能不能忠实复现真实系统的行为。保真度太低，测试就像拿塑料模特练拳击，姿势挺标准，结果不一定靠谱。论文将保真度问题细分为几个层面：传感器保真度（激光雷达点云是否模拟了真实的多回波和噪点）、物理保真度（车辆动力学模型是否准确反映了悬挂、轮胎、制动的非线性特性）、以及行为保真度（虚拟交通参与者是否表现出与真实人类驾驶员一致的决策模式）。一位受访者分享了一个教训：他们的仿真中，所有虚拟车辆都严格遵守交通规则，从不压线、从不犹豫，结果系统在仿真中表现完美。但到了真实道路上，面对一个在路口犹豫不决、打了转向灯却迟迟不变道的真实驾驶员，系统的规划模块直接“死机”了，因为它从未在训练或测试中见过这种“不完美”的行为。

更麻烦的是接受标准。什么叫“测试通过”？是指标达标、场景覆盖够了、还是认证机构点头了？论文里受访者普遍提到，很多公司并没有统一、稳定、可复用的判定标准。于是测试经常变成一种组织协商：研发说差不多了，测试说还不够，安全团队说证据不足，最后谁也不敢第一个签字。这不是谁怂，而是自动驾驶的失败代价太高。论文中记录了一位受访者的原话：“我们有一个功能，在仿真中跑了100万公里，零事故。在封闭场地跑了1万公里，零事故。在公开道路用安全员跑了5000公里，零事故。但当我们问‘可以去掉安全员了吗？’整个会议室沉默了10秒钟。因为没有人能回答‘这5000公里没出事，是不是因为安全员在关键时刻介入了？’”

论文还提到一个很有意思的趋势：传统基于显式对象和规则的仿真，正在被更数据驱动的测试方式冲击。原因是新一代自动驾驶越来越依赖多模态原始数据，比如摄像头、激光雷达、像素级和点云级数据，而不是简单的场景脚本。换句话说，测试对象正在从“我知道场景里有什么”变成“我只知道一堆真实数据，系统自己去理解”。这会让测试更贴近真实，但也更难解释。一位受访者指出，对于端到端系统，你很难像传统模块化系统那样，单独测试感知模块的精度或规划模块的合理性。你只能给系统一个完整的驾驶任务，然后看它最终的表现。如果它在一个左转场景中失败了，你很难定位到底是感知没看到行人、还是预测错了行人的轨迹、还是规划选择了错误的时机。这种“黑盒”特性使得测试结果的归因变得极其困难。

这部分最打动人的地方，是它没有把问题包装成“技术还不成熟，所以再等等”。恰恰相反，论文把工业界的真实困境摆出来之后，才更清楚地说明：自动驾驶测试不是缺方法，而是缺一套能把方法、证据、责任和流程接起来的工程体系。

图3：测试方法、指标、基准和工具的主题模型。

图3说明，工业界并不是“没有工具可用”，而是工具太多、口径不一。参与者提到的指标、基准和工具五花八门，有些偏功能正确性，有些偏安全，有些偏系统性能，还有些偏认证合规。问题在于，这些东西各自都对，但拼起来未必形成一个完整的证据链。例如，一个公司可能同时使用“每千公里接管次数”作为安全指标，“场景通过率”作为功能指标，“平均决策延迟”作为性能指标。但这些指标之间是什么关系？接管次数少是否一定意味着场景通过率高？决策延迟短是否一定意味着更安全？受访者普遍承认，他们缺乏一个统一的框架来整合这些不同维度的证据，导致最终的“安全论证”更像是一份拼盘报告，而不是一个逻辑严密的证明。

此外，论文还揭示了一个被学术界经常忽略的痛点：测试数据的标注与管理。自动驾驶测试会产生海量的传感器数据，这些数据需要被标注（例如，标记出每一帧图像中的行人、车辆、交通标志），才能用于评估感知模块的性能。但标注成本极高，而且不同标注人员之间的一致性难以保证。一位受访者抱怨道：“我们花了三个月标注了10万帧雨夜场景，结果发现标注员对‘积水区域’的定义不一致，导致我们的感知评估结果偏差了5个百分点。我们不得不花一个月时间重新统一标注标准。”这种数据管理上的“脏活累活”，虽然不直接体现在算法论文中，却是工业测试中真实且巨大的消耗。

破局之道：AI赋能、世界模型、闭环框架

既然问题这么多，工业界和论文里提到的方向也就很一致：让测试更自动化、更数据化、更可解释。这听起来像口号，但受访者给出的方向其实挺具体。

首先是AI。这里的AI不是泛泛地“用大模型提效”，而是更实在地用在场景生成、异常挖掘、数据筛选和测试优先级排序上。工业界希望AI能帮忙找出最值得测的场景，而不是继续把工程师困在“人工挑场景”的苦力活里。一位受访者详细描述了他们的AI辅助场景生成流程：首先，他们用生成对抗网络（GAN）或变分自编码器（VAE）学习真实驾驶数据的分布，然后在这个分布中进行插值和外推，自动生成在物理上可能但现实中罕见的场景，例如“一辆自行车突然从停放的卡车后面窜出，同时对面来车开着远光灯”。这种AI生成的场景，比人工手写的脚本更丰富、更难以预测，能更有效地暴露系统的边界。另一家公司则使用强化学习来训练一个“对抗性”的交通参与者，这个参与者的目标不是安全驾驶，而是“诱导”被测自动驾驶系统犯错，从而自动发现系统的脆弱点。

其次是世界模型（world models）。它的意思不是玄乎地“模拟一个宇宙”，而是建立更接近真实交通交互规律的环境模型，让系统在更高保真度的虚拟世界里接受压力测试。论文中受访者对世界模型的期待非常务实：他们希望世界模型能够解决仿真中“行为保真度”不足的问题。具体来说，一个理想的世界模型应该能够根据当前交通状态，预测出所有交通参与者（包括行人、自行车、其他车辆）在未来几秒钟内最可能的多种行为轨迹，并且这些轨迹的分布应该与真实世界中人类驾驶员的决策分布一致。这样，被测系统就必须学会处理各种合理的、甚至略带侵略性的他人行为，而不是只面对仿真中那些“温顺”的虚拟车辆。一位受访者提到，他们正在尝试用Transformer架构训练一个大规模的世界模型，输入是过去10秒的道路拓扑和所有交通参与者的轨迹，输出是未来5秒的多种可能轨迹及其概率。初步结果显示，这种模型生成的虚拟交通流，在统计特性上已经非常接近真实高速公路的交通流数据。

最后是端到端方法。它之所以被频繁提到，不是因为它天然更安全，而是因为它可能在复杂场景里减少模块接口上的误差传播，测试对象也会随之变化。对于端到端系统，测试的重点从“每个模块是否达标”转向了“整个行为策略是否安全”。这意味着需要开发新的测试指标，例如“驾驶风格激进程度”、“对不确定性的鲁棒性”、“长尾场景的泛化能力”等。一位受访者指出，他们测试端到端系统时，会特别关注系统在“感知混淆”情况下的行为。例如，在仿真中故意给摄像头图像添加一种罕见的对抗性噪声（如特定图案的贴纸），看系统是否会做出危险决策。这种测试在模块化系统中很难进行，因为感知模块可能会过滤掉这种噪声，但端到端系统直接处理原始像素，更容易受到这种攻击。

图5：自动驾驶系统测试的未来趋势主题模型。

图5里最明显的信号，是未来测试会更自动化、数据驱动、透明化。自动化，是为了减少人工挑场景和重复执行测试的成本；数据驱动，是为了让测试更贴近真实世界；透明化，则是为了让测试过程能被审计、复核和追责。后两者尤其重要，因为自动驾驶不是“跑得像样”就结束了，而是要能回答：为什么认为它足够安全？证据链在哪里？

在透明化方面，论文中受访者提到了“可追溯性”的重要性。这意味着，对于测试中发现的每一个问题，都必须能够追溯到具体的测试用例、测试环境配置、软件版本、甚至代码提交记录。这样，当问题被修复后，才能精确地回归验证。一家公司分享说，他们建立了一个“测试证据管理系统”，每个测试用例都有一个唯一的ID，关联了其输入数据、预期输出、实际输出、执行日志、以及最终是否通过的判定。这个系统不仅用于内部质量管控，也用于向监管机构展示其测试过程的严谨性。一位受访者说：“当监管问我们‘你怎么证明你的系统在雨夜场景中是安全的？’时，我们不是只给一个结论，而是能打开系统，展示我们测试了哪些具体的雨夜场景、每个场景的结果是什么、以及这些场景是如何覆盖了ODD中定义的雨夜条件范围。”

图6：由访谈结果综合而成的证据中心闭环测试框架，共六个阶段及其关键活动。

这张图是全文最像“落地方案”的部分。所谓证据中心闭环测试框架，本质上就是把测试从“做一堆活动”变成“围绕证据来组织活动”。先定义要证明什么，再决定用哪些场景、哪些环境、哪些工具去收集证据；测试得到的结果再反哺场景选择、指标修正和下一轮测试。它和传统“测完就算完”的思路不同，更像一个持续迭代的安全论证机器。

这个框架的价值不在于“新”，而在于它把工业界已经在做的事情，重新整理成一个更清楚的闭环：目标—场景—执行—证据—反馈—再测试。这套逻辑很朴素，但工程上往往最管用。自动驾驶测试之所以难，不是因为大家不会测，而是因为测完之后，证据怎么沉淀、怎么复用、怎么支持下一步决策，长期没有统一答案。

让我们更细致地拆解这个框架的六个阶段。第一阶段是目标定义：明确系统需要满足的安全目标和性能目标。输入是系统需求、法规要求（如UN R157对于ALKS功能的要求）以及公司内部的安全标准。输出是一份结构化的“安全论证目标树”，将顶层目标（如“系统在ODD内不会导致不可接受的伤害风险”）逐层分解为可验证的子目标（如“感知模块对行人的检测召回率>99.9%”、“规划模块在紧急制动时的减速度不超过5m/s²”）。第二阶段是场景选择与生成：基于目标树，确定需要测试哪些场景。输入是ODD描述、真实驾驶数据中的边缘案例、以及AI生成的对抗性场景。输出是一份“测试场景库”，每个场景都包含明确的初始条件、环境参数和预期行为。第三阶段是测试执行：在合适的测试环境（MIL、SIL、HIL、VIL、封闭场地、公开道路）中执行选定的场景。输入是场景定义和被测系统版本，输出是原始的传感器日志、系统内部状态记录和执行结果。第四阶段是证据收集与评估：从原始日志中提取出与安全目标相关的证据。输入是原始数据，输出是结构化的证据项，例如“在场景X中，系统在距离行人3.2米处成功刹停，制动减速度为4.5m/s²，符合安全目标”。第五阶段是证据整合与论证：将所有证据项整合到安全论证目标树中，判断每个子目标是否被充分满足。输入是分散的证据项，输出是一份“安全论证报告”，明确指出哪些目标已达成、哪些目标存在证据缺口。第六阶段是反馈与迭代：将论证中发现的证据缺口和系统弱点反馈到第一阶段和第二阶段，驱动新的目标定义和场景选择，形成闭环。这个框架的关键在于，它要求每个测试活动都必须明确回答“我为哪个安全目标提供了什么证据”，从而避免了“为了测试而测试”的盲目性。

一份来自工业界的声音：未来测试将走向何方？

如果把这篇论文看成一份“工业界口供”，它传递出来的信号其实很一致：未来的自动驾驶测试不会更轻松，只会更系统。因为系统越聪明，测试就越不能靠经验主义糊过去。

一方面，测试会继续向仿真和数据平台集中，尽量把高风险、高成本、高重复度的任务留在虚拟环境里；另一方面，真实道路测试仍然不可替代，因为很多问题只有在现实世界里才会暴露。也就是说，未来不是“仿真取代路测”，而是仿真、在环、封闭场地、公开道路共同组成证据链。

另一方面，测试标准会越来越像“安全工程”而不是“功能调试”。这意味着指标不再只是成功率、接管率、碰撞率这些简单数字，还要包括场景覆盖、边界条件、证据完整性、可追溯性和合规性。自动驾驶最终拼的不是谁的演示更炫，而是谁能更稳定地回答监管和用户最关心的问题：出了事，为什么不会再出；没出事，凭什么认为不会出。

这也是这篇论文最有现实味道的地方。它没有把自动驾驶测试写成“未来已来”的宣传稿，而是把工业界真正还没解决的事，老老实实说了出来。对研究者来说，这些问题足够具体，值得继续做方法；对工程团队来说，这些问题足够真实，不能再靠PPT解决。

论文最后还讨论了不同国家法规环境对测试实践的影响。受访者来自6个国家，他们普遍反映，欧洲的法规（如UN ECE法规）对测试流程和证据要求更为严格和具体，这迫使欧洲公司必须建立更正式的测试管理体系。而北美的公司则相对更依赖行业自律和内部标准，测试流程的灵活性更高，但有时也面临“标准不统一”的困惑。亚洲的公司则处于两者之间，正在快速吸收欧美经验，同时也在探索适应本地交通环境（如摩托车混行、非严格车道线）的测试方法。这种地域差异意味着，一个放之四海而皆准的“最佳测试实践”可能并不存在，未来的测试框架需要具备足够的灵活性，以适应不同地区的法规和文化要求。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它没有发明一个新的自动驾驶算法，而是回答了更现实的问题：工业界到底怎么测试自动驾驶系统、难点在哪里、未来可能怎么改。它的价值在于把分散的实践经验整理成了可复用的工业画像。

X-in-the-loop 是什么意思？就是把测试分层推进：模型在环、软件在环、硬件在环、车在环。前面的层级更便宜、更快，后面的层级更接近真实世界，代价也更高。工业界通常希望尽量把问题挡在前面，别等到实车阶段才暴雷。

为什么大家都在强调“闭环框架”？因为自动驾驶测试不是一次性验收，而是持续迭代的过程。测试结果要能回流到场景选择、指标修正和下一轮验证中，形成证据链闭环。没有闭环，测试就容易变成“做了很多，证明不了什么”。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★☆☆

创新点不在算法本身，而在工业访谈视角和证据中心闭环框架的整合，属于“把现实讲透”的创新。

实验合理度：★★★★☆

定性研究路线和研究目标匹配，样本虽不大，但覆盖国家、公司和角色较多，内部逻辑是成立的。

学术研究价值：★★★★☆

对自动驾驶验证、软件工程和安全论证都有参考价值，尤其适合补足“论文里看不到的工业细节”。

稳定性：★★★☆☆

框架思想稳定，但具体流程高度依赖公司制度、工具链和法规环境，落地时会有明显差异。

适应性以及泛化能力：★★★☆☆

适合大多数自动驾驶测试团队参考，但不能直接当成统一模板照搬，尤其是不同国家法规差异很大。

硬件需求及成本：★★★★☆

方法本身成本不高，主要是访谈和分析；但它揭示的工业测试体系本身，成本和组织复杂度都不低。

复现难度：★★★☆☆

访谈研究可以复现方法，但很难完全复现受访企业的组织语境和真实决策过程。

产品化成熟度：★★★☆☆

闭环框架很适合做成内部测试管理和证据管理流程，但要真正产品化，还需要和具体工具链、法规体系深度绑定。

可能的问题：样本量有限，更多反映受访公司的实践；结论偏定性，缺少大规模量化验证。

主要参考文献

[1] Qunying Song, Yuan Gao, Johannes Betz, Dietmar Pfahl, Mohammad Reza Mousavi, and Federica Sarro. In the Driver’s Seat: A Multi-Company Study on the Reality of Autonomous Driving System Testing. arXiv:2607.15820v1, 2026.

[2] 论文中引用的相关工作：Beringhoff et al., Song et al., Zhang et al., Ding et al., Riedmaier et al., Tang et al., Lou et al., Liao et al. 等。

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！