企业官网建设流程全解析

1. 从一个老问题说起：为什么端到端突然成了香饽饽

前两年我们团队做自动驾驶还是一条标准流水线：感知模块先识别出障碍物、车道线、红绿灯，预测模块再估计周围车两三秒之后的位置，规划模块在这堆不确定性里找一条最优轨迹，最后交到底层控制模块去执行。这套方案在公开道路上跑了很多公里，问题也踩了一堆。最大的痛点不是某个模块单独做得不够好，而是模块与模块之间的误差会逐级放大。感知漏检一次，预测跟着跑偏，规划出来的轨迹自然没法用，最后控制模块再努力也救不回来。这种“级联误差”是模块化架构的先天缺陷，也是我们开始认真研究端到端算法的直接原因。

所谓端到端算法，简单说就是从传感器原始数据进，到车辆控制指令出，中间没有人为划分的感知、预测、规划边界，全部交给一个大的神经网络模型来完成。最早大家觉得这就是个学术概念，但这两年特斯拉在AI Day上展示了基于视觉的端到端方案，国内头部智驾公司也陆续把端到端模型推上了量产车，大家才意识到这条路是能走通的。这篇内容我不打算复述论文，就结合我们团队从模块化转向端到端的实际经验，聊聊方案设计、数据命门、训练部署和那些文档里不会写的坑。如果你正在考虑从经典方案切到端到端，或者想搞清楚端到端到底解决了什么问题，这篇应该对你有用。

第一代端到端算法其实在上世纪八十年代就有人用神经网络做过车辆转向控制，但受限于算力和数据规模，一直停留在实验室里。现在的端到端和当年的区别，一是模型容量大了几个数量级，二是训练数据从几千张图片变成了几千万段视频片段，三是车端芯片能跑得起大模型了。当然，光靠堆参数和堆数据解决不了安全问题，所以才有了后面说的各种约束、兜底和评测手段。

2. 端到端算法的核心思路与方案选型

2.1 从传感器到方向盘：一条流水线的革命

传统模块化架构像是分工明确的生产车间：感知组负责把摄像头图像转成3D框和语义分割图，预测组负责在矢量地图上做多目标轨迹预测，规划组拿着高精地图和自车状态去算一条平滑曲线，控制组再把曲线转成方向盘转角。每个环节都可以独立调优、独立测试，这是它的优点，但代价是每一级都要把连续信息压缩成离散表示。比如感知输出的障碍物框丢了分类置信度低的不确定信息，预测只保留了几条固定数量的轨迹假设，规划做决策时根本拿不到底层像素级信息。信息损失是单向的，后面环节没法问前面的模块“你刚才为什么那么判断”。

端到端算法的思路是让模型自己决定在哪个抽象层次上做决策。一个设计良好的端到端模型，内部会自发形成类似“目标检测”和“轨迹预测”的中间表示，但这是数据驱动出来的结果，不是人为硬编码的规则。这种动态表征比手工特征更灵活，尤其是在处理交互博弈场景时，比如两辆车同时抢一个车道间隙，模块化方案要分别预测“对方让不让”和“自己该不该走”，而端到端模型可以直接从大量类似场景中学会一个相对安全的整体策略。

当然，这不是说端到端方案完全不感知。当前主流做法是“端到端感知-规划联合优化”，也就是感知还是存在的，但不再是一个独立的、输出结构化结果的模块，而是变成了网络内部的一组特征。模型输入的是一段视频或者多帧点云，输出的可能是未来几秒的自车轨迹点，也可能是直接的方向盘转角。感知和规划的边界被刻意模糊掉，换来的是信息流动的完整性和决策的一致性。

2.2 端到端方案的主流技术路线

现在聊端到端，行业内基本分成两派。一派是“直接控制派”，模型输入传感器数据，输出转向、油门、刹车信号，内部不显式建模任何中间量，代表是NVIDIA早期的DAVE-2以及一堆用模仿学习做的横向控制demo。这种做法的优点是系统极其简洁，训练、部署都省事，但缺点也很明显：很难引入规则约束，出了问题不好解释，一旦遇到训练分布外的场景基本没有兜底。

另一派是“轨迹生成派”，模型输出未来一段时间内自车要走的离散轨迹点序列，每个轨迹点附带置信度，再由一个轻量级的控制器把轨迹点转成车辆控制信号。这个方向是目前量产项目的主流，原因很实际：轨迹是一个相对低维的表示，容易做安全校验，比如偏离车道就拉回来，离障碍物太近就刹车；可以对模型输出做规则约束，虽然端到端是数据驱动的，但工程上还是习惯在尾部加一道保险丝。

我们当时的选择也是轨迹生成加轻量级安全层。模型的输出维度大概在几十维，对应5秒内每隔0.2秒一个横向和纵向位移点，外加每个点的一个可通行概率。安全层拿到这一段轨迹后，先做碰撞检测、边界约束、动力学可行性检查，全部通过了才发给底层执行器，不通过就降级到保守策略。这里要说明一下，安全层不是传统意义上的“独立规划器”，它是一个规则过滤器，作用域很窄，不影响模型在正常工况下的决策自由。

2.3 权重共享与多任务学习的实际价值

端到端模型通常会同时学多个任务，比如同时预测自车轨迹、他车轨迹、车道拓扑、红绿灯状态。为了减少参数和计算量，这些任务头会共享底层的特征提取网络，这就是热词里提到的“权重共享”。权重共享本身不是新概念，分类网络里很常见，但放在端到端自动驾驶里有个特殊价值：不同任务之间存在强耦合，比如预测他车轨迹时需要用到车道的几何信息，而车道拓扑的推理又依赖对历史帧的动态理解。让这些任务共享特征，等于强制模型学一个统一的场景表征，而不是每个任务各学一套互不通气的特征。

不过权重共享也带来了工程麻烦。一个最常见的坑是梯度冲突，各个任务头回传的梯度方向不一致，训练的时候一个任务在涨，另一个任务在掉。我们的做法是给不同任务头设定不同的损失权重，并且在网络里加了多个head之间独立的adapter层，所谓adapter就是一层很小的线性映射加激活函数，让共享主干输出的特征先做一下线性变换，再送入每个任务头。实测下来，加了adapter之后多任务收敛稳定了不少。另一个思路是用NAS（神经架构搜索，Neural Architecture Search）自动搜索共享层的结构，我们试过在离线实验里用NAS找过一层SE模块的位置，效果有一定提升，但搜索成本太高，量产阶段还是手工调参为主。

3. 数据是端到端的命门：从采集到闭环

3.1 一套靠谱的数据采集方案

端到端模型是一个典型的数据饥饿型算法。模块化时代，一千小时的有效驾驶数据可以完成感知模块的训练；到了端到端阶段，没有两万小时以上的多样化数据，模型根本不敢上路。数据质量和多样性甚至比模型结构更关键，这个观点我们踩过坑之后才真正认同。一开始我们觉得有几万帧标注数据就够了，结果模型在封闭测试场表现很好，一到开放道路就露馅。

做一个靠谱的数据采集方案，要从三个维度思考：传感器配置、场景覆盖、数据压缩与管理。传感器配置上，量产车的主力是8路摄像头加5个毫米波雷达，外加前向激光雷达选装。采集车最好和量产传感器完全一致，否则训练和部署之间的“传感器域差”会导致性能明显下降。我们曾经为了省钱用高线数激光雷达做采集，模型在仿真里跑得很好，装到量产车上一测，夜间和雨天性能掉了一截，最后排查发现是激光雷达点云密度和噪声分布差异太大，模型学到了不该学的采集车特定特征。

场景覆盖方面，核心是确保训练集里包含足够的极端场景：暴雨、逆光、夜晚无路灯的乡道、施工改道、前车急刹、行人突然横穿。这些场景在常规路采中出现的概率极低，所以需要一套挖掘机制，比如在采集车上跑一个轻量级预检模型，发现异常帧就自动打标并上传，回库之后再做重采样。我们统计过，有效极端场景大约只占原始采集数据的1%到2%，但训练收益占了一半以上。

数据的压缩与管理也容易被人忽视。一辆车一分钟的8路视频数据大约200MB，一天采集8小时就是接近100GB，一个车队如果跑20辆车，一个月的原始数据量轻松到60TB。我们用了分层存储，热数据放在NVMe盘上供训练随机访问，温数据放在对象存储里，冷数据直接转磁带，配合一套基于哈希去重的数据管理系统，把存储成本压到原来的三成左右。

3.2 时间同步与传感器标定：端到端的第一道坎

端到端模型对时间敏感性极高，这一点在模块化时代不太明显，因为感知模块本来就是单帧处理，规划模块用到的输入也通常是同一个时间戳下的结构化结果。但端到端模型直接吃原始传感器数据，如果各路传感器的时间基准不一致，就相当于把一个不同步的流喂给了空间感知模块。

时间同步有两层含义：一是硬同步，也就是每个传感器的曝光时刻要有统一的时间基准；二是软同步，也就是在模型输入侧对不同数据流做对齐。硬同步常用PTP（IEEE 1588精确时间协议）或者GPS脉冲信号加硬件触发线来做。摄像头最好用曝光中段时刻作为时间戳，因为曝光是一个积分过程，中间时刻代表实际感光的中心点；毫米波雷达的输出通常有几十毫秒的内部处理延迟，需要用标定表做延迟补偿；激光雷达如果是旋转式的，每次扫描的时间跨度就有几十毫秒，直接当成一个时刻处理会引入点云畸变。我们当时做了一个时间戳校准程序，定期记录每个传感器数据帧到达驱动层的硬件时间戳，再和各传感器自带的内部时间戳做差，算出一个统计延迟，写进模型前处理配置里。

软同步层面，做法是在网络输入前做一个简单的时间对齐层。比如，视频是20Hz，毫米波雷达是15Hz，激光雷达是10Hz，那把不同频率的数据插值到同一个时间网格上是不现实的，工程上一般取最近一帧对齐，但对“最近”的定义有讲究。不能直接对时间戳，要对时间戳加上延迟补偿后的“感知时刻”。否则，夜间高速上，前方车辆在两次采样帧之间急刹，错一帧对齐，模型看到的物体位置就和真实位置差了十几厘米，这对于控制指令级别的输出来说就太糙了。

标定方面，除了内参外参标定，端到端方案还需要做“时间偏移标定”，也就是精确测出摄像头曝光时刻和IMU运动补偿基准之间的时间差。这个偏差常规标定流程不会管，但端到端模型训练迭代时，几毫秒的时间误差对应的是高速场景下几十厘米的位置误差，足以让模型学出模糊的、平均主义的策略。我的建议是：时间同步的测试做进每辆车下线前的验收流程，不能只在算法实验室调。

3.3 数据闭环与真值生成的自动化

有了数据采集和时间同步，接下来就是怎么把原始数据变成可训练的监督信号。端到端模型的真值来源主要分三类：人工标注、高精地图/众包地图对齐、自动挖掘生成。

人工标注用于模型需要显式监督的任务，比如障碍物框、车道线、红绿灯状态。和感知时代不同，端到端模型的标注量更大，因为需要对连续时间帧做一致性的标注，不能某一帧漏一个物体，下一帧又冒出来。我们引入了一套时序标注工具，标注员可以在一段视频里先标第一帧，然后通过光流和点云追踪自动传播到后续帧，人工只需要修正漂移比较明显的区域，效率提高了大约4倍。

高精地图对齐主要用于生成高精位置真值，一是自车轨迹真值，通过RTK GNSS加组合导航系统获取厘米级的车体位姿，二是车道拓扑真值，把矢量地图投影到图像上和像素对齐。这个环节最容易出问题的是地图坐标系、车身坐标系和传感器坐标系之间的转换，任何一环节标定错误，训练出来的模型就会学到“系统性的地图偏差”，表现是车总往右偏一点或者过弯不够顺。

自动挖掘生成是数据闭环里最有技术含量的一步。比如，用端到端模型跑一段路采数据，自动找出模型预测轨迹和实际驾驶员操作差异大的片段，把这些片段拉出来做困难样本挖掘；又比如，在夜间场景里，用近距离超声波雷达的反馈作为近场障碍物的弱标签，去辅助模型训练近距离物体的感知和避让能力。这种自动生成的标签不是100%准确，但对模型来说，大规模的弱标签比小而精的强标签更能提升鲁棒性。

数据闭环做到最后，核心就是一句话：让模型碰过的每一段困难数据，都尽可能变成下一次训练集的一部分。这需要一套高效的调度系统，让数据从车端回传、筛选、标注、入库、训练、评测，再回到车端验证的整条链路跑起来。我们在这个系统上投入的人力比模型本身还多，但这笔钱花得值，因为端到端算法的上限在数据，不在模型结构。

4. 端到端模型的训练与部署实战

4.1 从模仿学习到RL的进阶之路

端到端训练的第一步是模仿学习。说白了就是把人类驾驶员的操作当作老师，让模型学着在这些状态-动作对上做回归。损失函数通常分两部分：横向轨迹用L1或者平滑L1损失，纵向速度用MSE损失。模仿学习的最大风险是分布偏移，训练时模型看到的是人类驾驶员的正确操作，而推理时一个小小的偏离，就让模型进入了一种训练时没见过的状态，之后的动作就完全失控了。这就是常说的复合误差问题。

缓解分布偏移的手段，第一个是数据聚合（DAgger类方法），让模型先开一段，再把模型遇到的那些偏离状态拿给人来纠正，反复迭代。这个思路在仿真里验证起来很顺，真实道路上的代价太高，因为让实车在边缘状态下跑还是有点吓人。我们的实际方案是混合策略：先在离线大数据上做模仿学习预训练，然后重点收集预训练模型开得不好的路段，针对性补充数据，专门做“对抗训练”。虽然不完全是DAgger，但思想和它是一致的，就是在模型容易犯错的地方多加老师示教。

模仿学习之后再往上一个台阶，就是强化学习（RL）。RL在端到端算法里的价值是主动探索策略空间，找到比人类驾驶员更优的驾驶策略，比如在无保护左转的狭窄路口，人类驾驶员会犹豫，RL模型反而能通过大量试错学会一个流畅又安全的通过轨迹。但RL训练的不稳定性是出了名的，尤其是真实环境中不能随便试错，所以大多数团队的方案是在仿真器里跑RL，然后做sim-to-real迁移，或者采用“RL微调+规则安全层约束”的混合架构。我们在实际项目中主要用PPO算法做微调，配合一个ppo训练的辅助任务：预测未来碰撞概率，这个碰撞概率头在后续安全评估模块里也派上了用场。

4.2 训练数据的组织与模型评测方法

训练端到端模型，最核心的一个超参数是batch的组织方式。一般会按“场景片段”为单位采样，一个场景片段是连续10到20秒的一段驾驶数据，模型每次输入几帧连续图像，输出未来几秒的轨迹。保证一个batch里的样本来自不同场景，是稳定训练的关键，否则模型会盯着一两种驾驶风格反复过拟合。

数据集划分也要讲究。训练集、验证集、测试集不能按帧随机切，必须按场景切。我们踩过的一个坑是，早期数据集按帧随机划分，结果同一段路的相似帧同时出现在训练集和测试集里，模型测试精度虚高，实车一测就打回原形。后来改成按“场景ID”分桶，同一段场景的所有帧要么全在训练集，要么全在测试集，这样评测指标才有参考价值。

模型评测分两个层面：开环评测和闭环评测。开环评测就是把一段真实路采数据喂给模型，比较模型输出的轨迹和人类驾驶员轨迹之间的误差，常用指标有横向位移误差、纵向速度误差、碰撞率、接管率。开环评测的问题在于，它没法衡量“模型遇到偏差之后能不能自己纠回来”，而闭环恰恰是端到端算法最需要验证的能力。闭环评测要在仿真器里做，通常的做法是把模型接进去，让它和仿真环境里的其他交通参与者互动，跑若干条设定的考核路线，统计安全性和舒适性得分。

仿真闭环测试现在能不能替代实车路测？我的观点是能替代一部分，但还不能完全替代。关键瓶颈是仿真器的传感器保真度，尤其是视觉传感器渲染的真实感，以及交通参与者行为的自然度。如果仿真器里的其他车辆行为太机械，模型学到的东西迁移到真实世界就会水土不服。我们团队在仿真器里引入了一套基于真实路采数据回放的交通流生成工具，把真实采集到的历史交通流直接变成仿真器的背景车，这样既保留了真实交互的复杂性，又能在可控条件下反复测试模型。

4.3 端到端与MPC、PID等经典控制算法的关系

很多人觉得端到端算法来了，MPC（模型预测控制）、PID这些经典控制算法就该被淘汰了。这个理解有很大偏差。在量产项目中，端到端模型的输出很少直接接到执行器上，因为底盘执行器对控制信号的频率和连续性有硬性要求，而神经网络推理天然是不稳定的，偶尔一帧的输出抖动就会被底盘放大成一顿一顿的体感。我们的方案是，端到端模型输出一条参考轨迹，真正算方向盘转角的是下层的一个轻量级MPC控制器。

MPC的核心思想是滚动优化，每过几十毫秒就重新算一次未来两三秒内的最优控制序列，只执行第一帧的控制量，下个周期再滚动重算。MPC的响应速度和控制平稳性都有保障，但它需要一个目标轨迹作为输入。传统方案里这个目标轨迹来自上层规划模块，在端到端方案里，这个目标轨迹由神经网络来生成。一个关键的工程细节是，MPC的优化目标函数里有一个跟踪误差权重的参数，如果权重调得过大，MPC会为了追轨迹而出现比较鲁莽的转向；调得小了，车辆会显得懒洋洋。我们通过大量实车标定，确定了一个“舒适性优先，安全边界内跟随”的权重组合，这套参数放在不同车型上还要做微调，并不是一个通用值。

PID则更底层一些，通常用在底盘控制层里做速度和转向的闭环补偿。比如MPC算出了期望加速度，但实际加速度受风阻、坡度、载重影响会有偏差，这时一个串联的PID环就能派上用场。所以说，端到端算法并不是替代了经典控制，而是把经典控制从“决策大脑”降级成了“踏实执行的手脚”。真正有价值的端到端系统，往往是“神经网络做感知级决策+规则做安全校验+MPC做轨迹跟踪+底层PID做执行补偿”分层协作的混合架构。

4.4 部署也能翻车：帧率、延迟与算力开销

模型训练得再好，部署到车端还是要过几道硬坎。第一道是算力墙。车端芯片的AI算力虽然越来越高，但端到端模型动辄几十亿参数，直接跑显然不现实。我们用了一套四步走：模型结构搜索阶段的轻量化约束，训练完成后的权重量化（FP16降到INT8），算子融合和裁剪，最后再配合一个流式执行框架，把模型的帧率从10Hz优化到了20Hz。这中间有个取舍，INT8量化带来的精度损失在某些场景下会导致模型输出的小幅偏差，MPC层反而能把这些高频噪声过滤掉，所以实际驾驶体验没有明显劣化。

第二道是延迟墙。从图像曝光到控制指令输出，整个链路的时间预算一般不超过100毫秒。这里面的延迟大头在神经网络推理、安全校验和MPC优化求解。我们遇到过一种情况，某个轻量化模型在GPU上推理只要25毫秒，但加上前后处理、序列化和锁等待，最终端到端延迟飙到了130毫秒。后来用到一个定时器监控每个阶段的耗时，定位到是数据拷贝环节占了大头，做了零拷贝的内存池改造才把延迟降到70毫秒。端到端系统的延迟优化，很多时候不是模型本身的问题，而是工程框架的问题。

第三道是安全冗余。端到端模型在推理时会给出置信度，但这个置信度和真实风险之间的相关性有时候并不可靠。我们的做法是额外训练了一个独立的“安全评估头”，它不参与轨迹生成，只负责评估当前模型输出的轨迹是不是安全的，一旦发现置信度偏低或者多层传感器互相打架，就触发降级策略。降级的路径包括：从轨迹生成派切换到底层AEB自动刹车，或者是触发驾驶员接管提醒，再或者是切换到备用的规则规划器。这三条路径的实现复杂度递增，我们在量产版上先做的是前两条，因为第二条链路简单且覆盖了最危险的场景。

5. 常见问题与排查技巧实录

5.1 模型训练不收敛，先别急着改网络结构

端到端模型的训练不收敛，是最常见也最容易让人抓狂的问题。很多团队的直觉反应是改网络结构，加正则化，换优化器，但往往折腾一圈仍不见效。根据我们的经验，90%的“不收敛”其实是数据问题和损失函数问题。

第一个要检查的是数据对齐是否正确。时间同步做不好，输入图像和输出的真值轨迹不在同一个时间基准上，模型自然会学出一个模糊的平均策略，损失降不下去。用一段我们踩过的案例来说明：有次把前视摄像头的时间戳硬编码成了毫米波雷达的时间戳，两个传感器之间存在大约40毫秒的偏差，这个偏差让模型学到的是一个“总是比真实位置晚一点”的状态映射，测试时横向误差一直维持在0.5米下不来，后来修正时间同步后，同样的模型结构误差直接降到0.15米。

第二个要检查的是损失函数里各项的尺度是否平衡。轨迹回归损失如果用L2损失，离群点的影响会被过分放大。高速公路上偶尔一辆车压线插进来，那一帧的轨迹差异会被放大成一个很大的梯度，导致训练震荡。我们的做法是把横向和纵向分开加权，横向损失用Smooth L1来降低离群点权重，纵向损失用MSE来保持对速度偏差的敏感度。另外，如果模型同时预测多模态轨迹，比如输出3条候选轨迹，那么损失函数需要对“最优轨迹”做软性加权，而不能简单地对所有轨迹求平均。

第三要检查训练时的batch组成。如果一个batch里全是同一时段采集的数据，模型很快会对这个时段的场景过拟合，损失低了但泛化能力极差。解决方法是做一个数据混洗策略，保证每个batch里至少包含白天、黑夜、晴雨、高速、城区等不同类型的样本，并且设置一个场景采样的权重参数，让稀少场景有更高的采样概率。

5.2 数据冲突：同一个场景，模型学出了两种行为

端到端模型训练到中后期，经常会出现一种现象：在训练集上损失一直下降，但到验证集上性能却原地踏步，甚至倒退。我们排查下来，多半是数据冲突导致的。所谓数据冲突，就是同一个或极其相似的场景下，人类驾驶员的操作却完全不同。举个例子：同一个路口，第一次通过时前面没车，驾驶员以60km/h匀速通过；第二次通过时旁边车道有一辆大货车，驾驶员可能选择了减速到40km/h再通过。如果模型感知不到“旁边车道的大货车”这个关键差异，就会在两个相差很大的速度标签之间来回摇摆，最终学出一个中间值。中间值在简单场景下表现尚可，在复杂场景下就容易触发接管。

解决数据冲突的办法有三种。第一种是增加输入信息，让模型有更强的能力区分这两个场景，比如加更大视角的鱼眼相机，或者加毫米波雷达点云，让“旁边车道有车”这个事实更容易被捕捉到。第二种是给相似场景打上语义标签，在损失函数里增加一个场景分类辅助任务，强制模型的中间表征去区分不同场景，这个方法在我们项目里效果很明显。第三种是主动做数据清洗，找出那些“标签方差过大”的样本聚类，人工再审核一下，把确实有分歧的样本剔除或者重新标注。数据清洗听着笨，但在端到端项目里非常值得做，因为模型一半的天花板在数据质量上。

5.3 长尾场景与安全兜底：100分的模型也会遇到没见过的事

哪怕数据做得再全，长尾场景依然无法穷尽。对于端到端自动驾驶来说，长尾场景的核心风险不是模型开不了，而是模型“自信满满地开错”。模仿学习有一个天然倾向，对一个状态如果训练数据里出现过几次相似样本，它就会倾向于输出一个“平均正确”的动作。但真实世界里，面对一个从未见过的异形施工路障，正确的动作可能是大幅减速并绕行，而模型因为没见过这种路障，可能只是做了一次小幅度的偏移，结果就撞上去了。

我们在工程上应对长尾场景的策略有四个。第一，在安全层里加硬约束，对网格化的可行驶区域做碰撞检测，网格中任何不可通行的区域只要和模型轨迹相交超过阈值，就强制降级。第二，训练一个独立的“数据分布外检测器”，这个检测器不输出驾驶决策，只判断当前输入和训练分布有多么不同。分布外分数超过阈值的时候，模型置信度会被压低，触发安全策略。第三，把一些高频危险场景（如前车急刹、行人横穿）用规则写死，作为模型之上的硬逻辑，也就是“规则优先”。这样做的代价是，极端情况下规则层会切断模型的一些更灵活的决策，但安全优先的前提就是这个。

我个人的体感是，端到端算法在正常工况下的驾驶流畅度上限高于模块化方案，但在突破认知边界时的安全下限又远低于模块化方案——模块化方案再怎么不济，规划模块还会检查一下碰撞；而一个没有加安全兜底的端到端模型，只会“盲目自信”地输出一条它认为最好的轨迹。所以，任何宣称“纯端到端不加规则”就能上路的说法，现阶段我是持保留态度的。

6. 写在最后的个人体会

从我自己的实践经验来说，端到端自动驾驶算法最大的魅力，不是它省掉了多少模块，而是它逼着整个团队重新思考“驾驶是什么”这个问题。模块化的思维是先把问题拆碎，再逐个吃掉；端到端的思维是先让系统整体学会开车，再回过头去理解它内部到底发生了什么。这二者的方法论差异，带来的不仅是技术栈的切换，更是团队协作、工程流程、数据资产、甚至组织架构的重构。

端到端的核心工作不在于搭模型，而在于搭数据闭环，在于把时间同步、传感器标定、真值生成、困难样本挖掘、仿真评测这一整套链路做扎实。模型结构在达到一定复杂度之后，边际收益很小，但数据环上的每一分投入，都能实打实地转化为系统能力。这一点，我觉得是未来几年做自动驾驶的同行需要重点投入的方向。

最后再分享一个小技巧：评估一个端到端系统好不好，不要只看平均指标，比如干预率、碰撞率、横向误差，这些都是“平均主义”的数字。一定要单独看最差5%场景的表现，因为端到端系统在绝大多数场景下都能开得很好，真正拉开差距的就是那些最恶劣的5%场景。把精力花在提升最差场景的性能上，比花在打磨平均指标上要值得得多。这是我们在经历过两轮实车测试迭代之后最深的体会，也希望对你做这块工作有参考价值。