道路交通安全法修订草案提请审议明确自动驾驶违法由车企担责。这个方向对普通车主来说是“以后出事找车企”但对自动驾驶研发和测试来说真正的影响是车企必须能在事后讲清楚“车辆当时为什么这么做”。这不是单纯的法律表述变化而是整个开发流程要围绕“可解释、可追溯、可验证”重新组织。我接触过不少自动驾驶项目团队能把模型跑通但很难回答“这个版本在哪个数据集上训练、哪次测试通过、那个场景为什么这样决策”。责任划分一旦明确这些问题就不再是研发加分项而是产品落地的基本条件。下面按我自己的理解把自动驾驶数据集、L4代码、ROS系统、自动驾驶测试、路径规划和责任事件还原这条链路拆一遍。1. 车企担责意味着“事后解释权”要落到工程侧1.1 责任主体变化后最先被拷问的是研发记录以前讨论自动驾驶事故很容易先落到驾驶员身上。自动驾驶状态下如果出了交通违法或者事故很多人的第一反应是“司机有没有接管”但责任一旦明确由车企承担问题就变成了“车辆为什么在那一刻选择这么做”。要回答这个问题不能只靠产品说明书也不能只靠事后看一段视频。车企必须能拿出完整的研发记录当前系统用的是哪一版代码、哪一版模型权重、哪一版训练数据这辆车在事发前处于什么模式系统有没有发出接管请求驾驶员有没有响应感知、预测、规划、控制每个模块当时输出了什么。这些记录不是事故发生后临时凑的而是在开发和测试过程中就要按规范留存的。我见过很多团队测试报告很厚里面有通过率、有接管次数但真要定位某一个具体场景根本找不到对应的日志和参数。责任划分一明确这种状态就必须改变。1.2 车企要能回答的五个工程问题如果把“车企担责”落到工程侧我认为核心是五个问题车辆当时处于自动驾驶模式还是人工驾驶模式自动驾驶系统是否在预设的设计运行范围内工作系统针对当前场景做出了什么决策依据是什么这个决策对应的代码、模型、配置和数据版本是什么系统有没有提前预警、降级或请求接管留给驾驶员多少反应时间这五个问题覆盖了“状态判断、场景边界、行为解释、版本定位、安全兜底”五个层面。每一个问题都需要对应数据。状态判断靠车辆日志和模式切换记录场景边界靠地图、天气、道路信息和运行设计域定义行为解释靠感知结果、预测轨迹和规划输出版本定位靠代码提交记录、模型权重信息和部署清单安全兜底靠接管请求、驾驶员状态和紧急制动记录。所以车企担责并不是“出了事企业赔钱”这么简单它更像是一种对研发体系的倒逼如果回答不了这五个问题责任到底怎么分、怎么还原就很难讲清楚。2. 自动驾驶数据集责任追溯的起点2.1 数据集不是“越大越好”先要看能不能回溯很多自动驾驶项目一开始就陷入“数据饥渴”总觉得数据量越大模型越强。自动驾驶数据集确实重要但责任划分之后数据集的价值判断标准会多一个维度能不能回溯。每一条参与训练的数据最好能回答三个问题谁采集的在什么条件下采集的怎么标注的如果模型在某个场景下判断错误研发团队需要回溯到训练数据里看看这类场景占了多大比例、标注是否准确、数据是否完整。如果数据集是一个黑盒只看到一堆图片和标签没有来源、没有版本、没有场景分布那出了问题根本无从下手。我一般会建议团队给数据集维护一份清单至少包含下面几项数据集名称和版本采集地点、时间、天气、光照采集车辆配置传感器型号、安装位置、标定信息场景标签城市道路、高速、夜间、雨天、施工区域等标注规范版本和标注人员记录数据是否经过脱敏处理对应代码和模型版本这样看起来增加工作量但一旦遇到需要解释模型行为的时候它就是最主要的线索。2.2 采集同步信息时间戳、坐标、车辆状态一个都不能少数据采集最容易踩的坑是“只存传感器原始数据不存同步信息”。图像、激光雷达点云、GPS轨迹、车辆CAN信号如果时间对不上事后就没法恢复同一时刻的完整场景。采集时至少要同步记录GPS坐标和 UTC 时间车辆速度、方向盘转角、刹车踏板状态各传感器的相对时间戳和硬件触发时间天气、温度、道路类型等环境信息采集车辆编号和采集人员这里有一点容易被忽略时间戳统一。如果相机用相机本地时间点云用雷达时间CAN信号又用另一个时钟那还原一个场景时会非常痛苦。更稳妥的方式是统一使用 UTC 时间或者全车同步后再记录传感器时间。2.3 标注版本和模型版本要能对上训练自动驾驶模型标注质量直接影响感知结果。一个物体框偏了车辆可能把行人判断成远处障碍物一个车道线标错规划模块可能导出一条压线的路径。所以标注本身也要有版本和审核记录。我建议至少保留这样一条链条数据集版本对应标注规范版本标注规范版本对应标注人员培训记录模型版本对应训练数据和代码版本。部署到车上时再把模型版本写进启动日志。这条链条在平时看起来像项目管理在责任事件还原时就是判断依据。如果最终结论是感知误判那就要能继续往下查是训练数据里缺少对应场景还是标注错误还是模型结构问题。没有数据版本链基本查不到这一层。3. L4代码和ROS系统决策行为必须可审计3.1 代码、模型权重、运行配置三对应做自动驾驶L4代码开发时每个版本都要能回答“当前跑的是什么”。实际部署中经常出现这种问题代码仓库是最新的但车上加载的模型权重还是两周前的老版本配置文件里改了一个参数但没有同步更新版本号。功能测试能过问题一般在模块内部跟版本无关一旦上了责任链版本对不上就是大事。我建议在启动阶段就把以下信息写入日志代码仓库的 git commit模型权重文件的路径和哈希值比如 SHA256配置文件版本启动时间和启动人员车辆编号和计算平台信息这三个信息对应上之后后续任何行为分析都能先锁定“当前系统是什么版本”不用反复猜测。3.2 ROS消息记录要分级不能全存也不能不存自动驾驶ROS系统里消息类型非常多相机图像、点云、障碍物、规划轨迹、控制指令都在话题里发布和订阅。如果所有话题都全量保存存储很快被撑满如果只保存少量结果数据出了问题又看不出中间过程。更推荐的做法是分级记录第一级必存。控制指令、车辆速度、刹车/油门/转向、规划轨迹、障碍物列表、系统状态、接管请求。第二级按需保存。感知中间结果、预测轨迹、地图匹配结果、定位置信度。第三级关键帧保存。图像和点云可以按触发条件保存前几秒到后几秒的数据也可以降采样保存。触发条件可以是严重刹车、方向盘突变、接管事件、碰撞信号、超出设计运行域等。这样既能控制存储成本又不至于在关键时刻没有数据。ROS本身有 rosbag 工具但更重要的是规划好记录哪些话题、以什么频率记录、保留多长时间。不要等到出了问题再开 bag那就晚了。3.3 安全机制触发记录是责任判断的关键安全机制是自动驾驶系统里最值得被审计的部分。所谓安全机制包括降级策略、驾驶员接管请求、紧急制动、靠边停车等。这些动作一旦触发一定要有明确的日志记录。例如系统检测到感知置信度下降决定请求驾驶员接管。那就要记录触发时间触发原因哪个模块、什么指标超限系统当前状态是否降级、降级到什么程度是否发出声光提醒驾驶员是否响应接管后系统是否退出自动驾驶模式很多责任事件的核心争议点就在“系统有没有给驾驶员足够的时间反应”。如果接管请求只提前了 0.5 秒驾驶员即使注意力集中也可能来不及处理如果提前了 5 秒且提醒明确责任判断会不同。这些细节只能靠日志还原不能靠事后访谈。4. 自动驾驶测试从“跑通”到“能自证”4.1 测试计划先写清边界再谈里程和接管次数自动驾驶测试最怕的是“跑了很多公里但说不清跑的是什么”。责任划分之后测试计划本身就要承担“边界证明”的作用。一份可用的测试计划至少包括测试路线和覆盖场景天气、光照、时间段的允许范围最高速度和安全距离限制安全员数量和接管标准测试期间软件版本和数据版本可接受的接管次数和危险事件定义测试过程中如果超出计划边界需要在记录里标注。比如计划里允许小雨天气测试实际跑的时候下大雨了那这一段数据要单独标记不能混进常规测试结果里。这样做不是为了限制测试而是为了让“这次测试到底验证了什么”这个问题可回答。4.2 仿真、封闭场地、公开道路按顺序推进我一直建议测试按三层推进仿真测试、封闭场地测试、公开道路测试。责任压力越大越不能只跑仿真也不能直接跳过封闭场地去公开道路。仿真测试的价值在于回归和极值场景。比如路径规划规则改动后先用仿真把所有典型场景跑一遍能快速暴露明显问题。仿真测试的局限也很明显传感器噪声、车辆动力学、通信延迟和真实环境差别很大仿真通过不等于实车没问题。封闭场地测试可以验证控制精度、紧急制动、接管逻辑等关键功能环境可控重复性好适合做问题定位。公开道路测试能覆盖真实交互场景但不可控因素多比如其他车辆加塞、行人横穿、道路施工、GPS信号遮挡。公开道路测试必须在仿真和封闭场地验证通过后再进行同时要严格遵守测试路线和边界条件。4.3 测试报告要写出通过标准和失败原因测试报告不能只写“通过”两个字。很多团队的报告里全是“功能正常”“稳定性良好”但没有说明判断标准是什么。更合理的测试报告应该包含测试目的本次要验证什么能力测试环境软件版本、硬件版本、车辆状态、天气、道路测试场景场景列表、测试次数、通过标准结果数据接管次数、危险事件、异常日志、速度曲线失败原因每个失败用例对应什么问题是感知、规划、控制还是系统交互后续动作是否修复、是否回归、是否影响发布自动驾驶测试不是证明“所有场景都能通过”而是证明“本次测试覆盖了哪些场景结果如何失败点在哪里”。这样测试报告本身就有了审计价值。5. 路径规划是否合理不只看安不安全5.1 路径规划评估的四个维度安全、合规、舒适、效率很多团队评估路径规划时只看两点有没有撞到障碍物到没到终点。这两个指标太粗了。自动驾驶路径规划是否合理业界比较关注的至少是四个维度安全、合规、舒适、效率。安全是指车辆是否与障碍物保持合理距离有没有突然逼近行人、骑车人或其他车辆有没有频繁触发紧急制动。合规是指路径是否违反交通规则。压实线变道、连续变道、禁止转弯路口转弯、越过停止线这些即使没有碰撞也属于交通违法。车企担责之后路径规划的合规性比以往更关键因为违法本身就可能是责任认定的起点。舒适是指乘坐体验相关的加速度和横向摆动。频繁急刹、急加速、方向盘左右摇摆都会让乘客不适也会影响用户对系统的信任。效率是指通行时间、平均速度、停车次数、绕行距离。如果系统过度保守动不动就减速等待虽然安全但效率太低用户也不会接受。5.2 离线回放、场景测试、路测统计三步走评估路径规划是否合理我建议按三步走。第一步是离线回放。把路测采集的数据流重新输入规划模块对比实际路径和回放路径的差异。这个阶段可以快速判断代码改动是否引入问题也可以覆盖一些真实数据中的难例。第二步是场景测试。在仿真或封闭场地里构造典型场景比如近距离加塞、行人不按规则过街、连续变道、无保护左转看规划模块如何应对。场景测试适合检验边界条件和规则逻辑。第三步是路测统计。把一段时间内公开道路测试的数据汇总起来统计平均接管次数、紧急制动频率、变道次数、压实线事件、急加速/急刹车次数等指标。只有统计到一定里程才能看出路径规划的整体水平。5.3 评估中常见的五个误区我总结过路径规划评估常见的几个误区只看碰撞风险不看交通规则符合性。安全通过了但一路压线这种路径不能上线。只看平均速度不看停车次数和绕行。平均速度高但用户被频繁加减速折腾体验很差。只看是否到达终点不看是否存在逆行驶、跨多车道等危险行为。不看场景分布把高速和城区、白天和黑夜的数据混在一起统计结论很容易失真。过度优化单一指标。比如为了降低接管次数把变道逻辑调得特别保守结果效率下降严重。路径规划评估不是找一个“满分方案”而是要在安全、合规、舒适、效率之间做平衡。责任划分之后这种平衡还必须有据可查为什么在这个路口选择这个车道为什么在这个场景选择减速等待每条变化都要能对应到规则、模型或场景数据。6. 责任事件还原先找证据再下结论6.1 事件记录要覆盖哪些字段一旦发生需要还原的交通事件最怕的是数据格式不统一、字段缺失、时间对不上。我建议提前设计一套“事件记录字段表”上线前就嵌入系统而不是事后补录。比较关键的字段包括事件触发时间统一为 UTC 或带时区标记车辆位置经纬度和道路信息自动驾驶模式L2 辅助、L3 有条件自动驾驶、L4 高度自动驾驶等系统版本代码版本、模型版本、配置版本驾驶员状态是否检测到驾驶员注意力、是否握着方向盘接管请求是否发出、发出时间、驾驶员响应时间车辆状态速度、加速度、转向角、刹车状态环境信息天气、光照、道路类型、限速传感器状态是否失效、是否降级、是否有标定异常保存时长要根据产品生命周期和运营地区的实际要求来设计我一般会建议关键日志至少覆盖产品迭代周期和事故处理周期不要上线几个月就清理干净。具体多久要结合合规要求和存储成本确认。6.2 还原流程把数据、日志和外部信息对齐事件还原要有一个固定的流程不能一上来就猜“大概率是感知问题”。我常用的顺序是先确认状态。当前到底是自动驾驶模式还是人工模式模式切换发生在什么时间。再拉系统日志。看感知、预测、规划、控制各模块有没有异常输出。然后把车辆运动轨迹和控制指令对齐。看车辆实际行为与规划轨迹是否一致。接着看外部环境。地图、路况、其他交通参与者的轨迹尽量还原当时场景。最后回到设计运行域。这个场景是否在系统预设范围内。如果超出范围就要追问系统为什么没有提前降低风险或请求接管。每一步都要有时间点。多个数据源的时间如果不一致先解决时间同步再做后续分析。6.3 排查顺序人因、系统、外因三级拆解事件原因通常可以分成三类人因、系统、外因。排查时不要一开始就钻进算法细节。人因主要看驾驶员状态和接管行为。系统有没有发出接管请求驾驶员有没有在合理时间内接管。如果驾驶员根本没有接管的动作判断方向就会偏向人因但也要继续查系统提醒是否足够清晰是否给了足够时间。系统问题看代码版本、模型版本、传感器状态、日志异常。重点确认是感知漏检、误检预测错误规划不合理控制执行失败还是模块间交互异常。外因看超出设计运行域的情况比如天气突变、传感器被遮挡、GPS信号丢失、高精地图与真实路况不一致、前方出现施工区域等。如果发现系统是在设计运行域之外运行的那问题定位逻辑就变了真正要问的不是“为什么这个场景处理不好”而是“为什么系统没有在超出边界时主动降级或请求接管”。这是责任还原里很关键的一条边界。7. 研发团队现在就该做的四件事7.1 小团队也要先建数据版本和日志规范很多小团队觉得责任链是大公司才需要考虑的事自己只有一两台测试车先跑起来再说。但问题往往出在“跑起来之后”采集了几百 GB 数据没有版本模型迭代了十几次没有记录车上日志只写了时间戳没有存模型权重信息。等到需要解释某次行为时基本等于没有证据。更稳妥的做法是先建一套简单但固定的规范每次采集数据都有采集单记录时间、地点、车辆、传感器状态。每个数据集都有版本号和训练代码、模型权重关联。每次部署都在启动日志里写清代码版本、模型版本、配置版本。每次接管事件都记录原因和现场情况。这套规范不需要一开始就很复杂但必须固定下来形成习惯。越早建立后面的追溯成本越低。7.2 把责任链做成自动化流程手动填表很难坚持尤其是一忙起来很容易漏。我建议把关键信息尽可能自动化记录。比如启动脚本里自动写入 git commit 和模型哈希数据采集程序自动生成采集清单ROS 节点启动时自动记录配置版本接管事件通过统一接口写入事件日志。自动化之后责任链才不会依赖某个人的责任心。这里有一个常见误区为了自动化而自动化把大量中间结果全量保存结果存储爆炸真正有用的信息反而没存。更合理的是先定义“哪些数据必须留、哪些可以降采样、哪些不用留”再针对必留数据做自动化记录。7.3 给团队和产品的长期建议从产品角度我认为自动驾驶团队应该把“责任可追溯”当作一项产品能力来建设而不是把它看成合规负担。具体来说至少要在架构层面预留统一的数据采集和版本管理接口事件触发式的日志保存能力自动驾驶模式切换的完整记录与外部证据比如行车记录视频、云端数据对接的能力路径规划决策的解释接口能在事后还原每一步行为这些能力越早设计越容易等产品已经量产再补成本和难度都会高很多。7.4 不要只盯着“能不能跑”还要看“说不说得清”最后一条建议可能最朴素自动驾驶系统的成熟度不能只盯着算法在测试集上的表现也不能只看演示视频里跑得多顺更要看当问题出现时团队能不能快速定位、能不能解释、能不能还原。车企担责之后自动驾驶的研发逻辑会从“做得快”转向“做得稳、说得清”。一个系统能不能让人信任不只看它平时表现多好更看它在异常情况下有没有准备。我更建议团队现在就拿最近一次路测数据做个演练假设某条数据里出现了一次接管你能否在半小时内回答系统当时看到什么、决策是什么、为什么需要接管、对应版本是什么、数据从哪来。如果答不出来就趁早补齐记录和工具。这个问题没解决之前先不要急着谈规模化和商业化。