企业官网建设流程全解析

“端到端自动驾驶”这个词，过去一年多一直卡在技术讨论的中心位置。城市NOA开始量产，各家都把端到端写在宣传页上，好像不聊端到端，算法团队就少了点什么。可你一旦跟真正做产品的人聊起来，又会发现大家嘴里的端到端经常不是一回事。有些方案说的是“感知、预测、规划全由一个模型搞定”，另一些只是在模块里引入了大模型，也拿来当端到端讲。这正是我想写这篇文章的原因：把这条技术路线从头梳理一遍，聊聊它解决的真正问题、底层的模型结构、落地时躲不开的数据与测试工程，以及我在多个项目里实际看到的坑。无论你是做算法的、做产品的，还是刚想入门自动驾驶的学生，把这些问题串起来之后，再回头去看各家方案，应该会清晰很多。

1. 先想明白：端到端算法到底在解决什么问题

1.1 传统模块化架构为什么会走到瓶颈

传统自动驾驶方案，大家都清楚，基本是感知、预测、规划、控制四个大模块，每个模块各司其职。感知负责识别车道线、红绿灯、车辆行人，预测负责估计周围目标的未来轨迹，规划在感知和预测结果上找出一条安全轨迹，控制再把轨迹转换成方向盘和油门的指令。

这套架构最直接的问题，是接口太粗，信息在模块之间传递时被大幅压缩。感知模块的输出，通常是一串目标列表，每个目标带上3D框、尺寸、类别、速度。但真实世界是高度复杂的，一个骑滑板车的人，一个托着长木板的路人，一辆尾部拖着链条的三轮车，用3D框很难描述清楚。感知一旦在关键帧上漏检或错检，后面的预测和规划只能基于错误输入继续推演，再多的规则也拉不回来。这种级联误差带来的现象，就是车辆在真实路段上表现得“愣”，不灵活。

第二个问题，是规则系统的复杂度不可持续。为了应付复杂的城市交互，规划模块里往往堆着几十万行if-else逻辑。单独测某个场景，规则表现还行；一旦场景组合起来，某条规则被意外触发，车辆就可能出现很别扭的加减速或者犹犹豫豫地停在路口。我见过不少团队把大量人力花在写规则、调阈值上，而不是在产品行为本身上。不是说规则一无是处，而是当道路从高速扩展到大街小巷，规则系统会进入组合爆炸，复杂度增长是没法靠堆人力来续命的。

1.2 端到端的核心主张：从观测到动作的直接映射

端到端算法的底层主张非常朴素：驾驶决策本质上是一个“观测到动作”的连续映射。人类开车时，并不会在脑子里先标出每个障碍物的精确框，再去计算一条几何路径。人类更像是一个整体，从视网膜图像直接形成了踩油门还是打方向盘的判断。端到端希望让模型直接学习“输入看到什么、输出该做什么”的对应关系，中间不再保留人为设计好的语义接口，理论上也就消除了接口处的信息损失。

不过这里必须区分两个层次，否则后续很多讨论都是鸡同鸭讲。一个是严格意义上的全端到端，原始传感器数据进去，方向盘、油门、刹车信号出来，中间没有任何人工语义量；另一个是带约束的端到端，输入也是原始数据，但模型内部会预测轨迹或一些结构化中间量，比如BEV网格、占用栅格、语义边界，再用这些量做监督或约束。现在量产车上的所谓端到端方案，多数是后者。纯黑盒式的全端到端，更多还停留在研究和小规模验证阶段，离大规模上车还有距离。

1.3 为什么这两年它才成为主流叙事

很多人以为端到端是新概念，其实二三十年前就有人用神经网络做方向盘跟随。之所以近一两年才集中爆发，是因为几个基础条件同时成熟了。

第一是模型结构。Transformer和BEV这类方法出现后，多路相机、激光雷达的信息可以在一个统一空间里做时空融合。前端特征不再是一张二维图，而是一套稠密的鸟瞰特征，模型对空间关系的理解能力有了质的提升。第二是算力。端到端模型很吃训练资源，早期团队根本撑不起上干小时数据的训练，现在集群训练、混合精度、分布式推理都成熟了，这层限制被打破。第三是数据。城市领航辅助大面积落地之后，有能力通过量产车回传大规模真实驾驶场景，特别是城中村、老城区、复杂环岛这种过去很难拿到的交互数据，端到端模仿学习终于有了充足的燃料。

所以我的看法是，与其说端到端是某个算法模型的胜利，不如说是Transformer架构、大规模算力和量产数据三股力量汇聚之后的必然阶段。

2. 技术脉络：端到端并不等于一个黑盒

2.1 全端到端与带约束的端到端，差在哪

全端到端模型的优点是接口信息零丢失，特征完全由数据驱动，训练目标可以直接对齐任务指标，比如舒适性、行驶效率、碰撞风险。但坏处也极其明显：一旦出了bad case，很难定位责任。车突然撞到路边护栏，你根本不知道是模型没看见护栏，还是轨迹预测有偏差，还是目标概率打分错了。排查这类问题，往往要同时查看输入序列、中间特征、注意力权重、候选轨迹，连续跟好几天才能有一点点眉目。

带约束的端到端则在模型内部保留一些可解释的中间监督信号。比如训练时让模型同时输出占用网格、目标框、车道语义，轨迹误差之外再叠加感知子任务的误差。这样模型仍然是一个整体，但具备了局部的可审计性。遇到问题时，可以先看感知子任务的输出是否异常，再决定是进入感知分支还是规划分支排查。量产团队更愿意接受这种方案，因为可以基于子任务加规则、加监控。

如果打个比方，全端到端像直接让一个新手司机上路，你只看他踩刹车、打方向，出了事很难复盘；带约束的端到端像让司机一边开车一边把自己看到的空间图画出来，出了事能对照看是哪一笔画错了。现阶段量产项目里，绝大多数宣传片里说的“端到端”，落地形态其实都是后者。

2.2 一个典型端到端模型由哪些部分组成

抛开具体平台，主流视觉端到端方案的结构可以拆成四段，方便大家建立一个整体画面。

输入部分，一般包含前视、环视等多路相机，部分方案还会加入激光雷达或毫米波雷达，用于特殊天气下的冗余。各路相机图像先经过一个共享的视觉骨干网络提取特征，配上时序上的循环网络或注意力模块，把过去几秒钟的运动信息带进来。然后通过几何投影或Transformer模跨视角关联，把所有相机特征统一到BEV坐标系，生成一张鸟瞰特征图。

在BEV特征图之上，模型会预测“占用网格”。占用网格相当于把车周围空间分成一个个小格，每个格子输出被障碍物占据的概率。这是一种比3D框灵活很多的表示，它不依赖物体的类别，也不要求几何规则，能把板车、异形路障、排烟管道这类“不规则存在物”也表达出来。

第三段是轨迹解码。模型在特征基础上，输出未来几秒的多条候选轨迹，每条轨迹带概率。这里强调“多条”很重要，因为驾驶行为是典型的多模态问题，同一个路口既可以直行也可以左转，用单条轨迹去回归，往往只能得到一条模棱两可的中庸路径，非常危险。

第四段是执行仲裁。模型可以直接选概率最高的轨迹交给底层控制，也可以把候选轨迹作为建议，再经过一道规则约束层筛选。后一种做法更接近现实量产。模型最终给出的是一条带时间戳的路径，这本身就是可解释的，再加上保存好的BEV特征和注意力信息，端到端模型并非完全不可调试。

2.3 训练范式：模仿学习为主、强化学习为辅

端到端模型的训练，当前主流是模仿学习。采集大量人类驾驶片段作为监督数据，输入是传感器历史，监督信号是方向盘角度、油门刹车踏板或者更抽象一点的未来轨迹。模型训练目标就是让自身输出尽可能接近人类驾驶行为。

模仿学习有个显著缺陷叫“回归到均值”。同一个路口，老司机可能会选择偏左一些通过，另一个老司机可能偏右一些，两种都是合理策略。行为克隆如果训练成回归平均值，最后模型学到的是“骑在中间线”上的轨迹，左右都不靠，既不安全也不自然。应对办法是让模型输出多个候选策略，每条候选有自己的概率分布，相当于让模型学会“在这个场景下，有哪几种合理走法”，再做选择。

纯强化学习在真实环境里很难直接做，因为探索成本太高，一个错误的加速就可能造成事故。现阶段更务实的做法是先用海量人类数据做模仿学习预热，让模型先有一个接近人类的驾驶雏形，再放到仿真环境里用强化学习微调，把“碰撞惩罚”“急刹惩罚”“绕路惩罚”这些奖励项压进去。我不建议新手一上来就复现花哨的模型结构，先搞明白“预热-微调”这套方法论，比背结构重要得多。

2.4 可解释性差，怎么补安全兜底

端到端被质疑最多的就是“黑盒”。放在量产语境下，可解释性其实可以通过三件事来弥补。第一是离线可视化，把输入图像、注意力热力图、BEV特征、预测轨迹同时渲染出来，人来看模型到底在关注什么。第二是敏感性分析，扰动输入里某个目标的位置或某条车道线的形状，观察输出轨迹变化方向是否符合直觉。第三是bad case聚类，把离线仿真中失败案例按特征自动分组，减少人工逐帧筛查的工作量。

但即便有这些手段，端到端模型内部仍然不是逐行可审计的。所以量产方案普遍会在底层叠加一套不依赖模型输出的独立监控，比如基于卡尔曼滤波的物理安全层。模型轨迹合格，系统就走模型；轨迹触发了安全边界，比如与前车距离过近、偏离车道过远，就立刻降级到规则式应急策略，执行最小风险操作。

这套安全兜底就像安全气囊，平时不参与驾驶，关键时刻必须可靠。没有这层兜底的端到端系统，我个人的态度是：现阶段不应该直接上量产车。

3. 落地真相：数据、评测与工程基建才是主战场

3.1 数据闭环：影子模式、数据清洗与长尾挖掘

数据闭环是端到端落地的胜负手。系统通常按这个循环运转：量产车或测试车在跑当前模型版本时，后台判断哪些片段值得回传，比如发生接管、感知置信度下降、模型在博弈场景里被迫减速等，把对应传感器数据和真值状态传到云端。云端做自动标注、清洗，进训练流程，训练出的新模型先去仿真集合验证，再OTA下发到车上。如果每天能沉淀几小时高质量的有效数据，模型迭代速度会非常可观。

但光堆数据量没有用，还要防数据偏置。如果大部分数据都来自白天、晴天、某几个快速路片区，模型就会对夜晚、雨雾、施工路段严重不敏感。我更看重的是数据挖掘能力和清洗质量。时间戳没对齐、传感器曝光异常、雨滴糊住前视相机、标注员对同类物体的框法不统一，这些都会变成训练损失里的噪声。一个务实的建议是：团队从一开始就走“影子模式加离线自动刷选”的流程，而不是先攒几个月原始数据，再回头想怎么用。数据质量工程比模型结构更脏更累，但也更能拉开差距。

3.2 评测体系：离线回放、在线仿真与实车验证

评测是数据闭环的另一半。最低一档是离线回放。把所有历史驾驶数据喂给新模型，看模型在相同输入下会不会撞、会不会偏航、轨迹是否平滑。回放有个致命缺陷：历史数据里其他参与者的行为是固定的，模型插进去操作时，那些车辆和行人并不会因为模型的操作而改变行为，所以对交互场景错误的评估会偏乐观。离线回放只能当第一层筛选，不能当最终结论。

更接近实战的是在线仿真。测试对象是模型，仿真场景里的其他车辆和行人是可交互、有行为模型的，模型输出轨迹后，他们会做出响应，形成真正闭环的博弈过程。对抗性场景库在这里特别重要，把窄路会车、行人横穿、前车紧急切入这类高价值场景做成参数化模板，每次测试生成不同变种，逼着模型在边缘情况下应战。用得好的仿真平台，比单纯堆路测里程性价比高得多。

不过仿真替代不了实车，特别是车辆动力学、传感器时延、风噪等细节很难完全还原。合理的推进路径还是“离线仿真初筛、封闭场地复测、城市受限公测、全量放开”的多层漏斗，每一层都会筛掉一批bad case。评测指标也要分维度盯，不能只看碰撞次数，接管率、舒适性、通行效率、感知误检率都要一起看，否则模型容易过拟合到单一指标上。

3.3 训练与部署的算力账，算清楚才能立项

再说算力。很多人一听说“端到端”，就以为把数据扔进GPU跑一跑就行，实际完全不是这么回事。一套基于BEV+Transformer的方案，驾驶数据量要做到上千小时级别，才会有基本效果。每条数据训练时要经过图像预处理、视觉特征提取、BEV投影、时序建模、轨迹解码、多任务loss反传，一轮完整训练要跑几天甚至几周。工程师还要跑消融实验、调参、做版本对比，实验日志、特征缓存、数据版本管理都吞噬存储和算力。一个认真做端到端的团队，至少要有几十张千卡级别起步的训练资源，否则很难支撑起有意义的迭代速度。

部署端的账同样不轻松。车端芯片的算力和功耗有严格限制，端到端模型又大，如果再保留一个兜底规则系统，资源分配非常紧张。为了让模型塞进车规级平台，普遍要做int8量化、蒸馏、稀疏化，这些操作会让模型在实车上的表现跟离线评测产生一些偏差。上线前必须跟实车标定做联调，模型设计和部署反馈越早打通，方向错误带来的浪费就越少。

4. 从Demo到量产：我在实际项目中看到的坑

4.1 规则与模型并行时，仲裁比模型更重要

我见过不少方案其实是端到端模型和规则系统并行运行的“混合形态”。本意是搞安全冗余，但问题往往出在仲裁层。举个例子，模型看到左前方有空隙，按照人类驾驶习惯打算提前并入左侧车道；可在规则系统里，本车与目标车的纵向距离小于阈值，变道请求被直接压下，最后车没有执行变道。结果就是模型给出一个更拟人的建议，仲裁层却把它当风险过滤掉了，整车驾驶风格仍然生硬。

要解决这个问题，必须把仲裁逻辑和系统边界设计在同一个框架里，而不是简单把模型输出当参考意见。更好的做法是让模型学习输出已经被约束在安全区间内的轨迹，规则层只负责做少数几项“总线式”监控，比如纵向碰撞距离、车道偏离程度，而不是对模型输出的每一个细节都做重新规划。两个系统打架的问题等到联调阶段才发现，改起来成本极高，架构阶段就要把仲裁权重定义清楚。

4.2 幻觉、过拟合，以及城市泛化问题

幻觉问题在端到端感知里并不少见，尤其在夜间和强逆光条件下。有段时间我们在测夜间的场景，模型频繁出现“前面明明没车，但BEV占用网格里出现一团障碍物”的情况。原因通常是暗部纹理被误判成了障碍物边缘，或者图像增强对夜间适配不足。如果这个幻觉障碍物恰好落在本车道，车辆会突然减速甚至停在路中间，体验非常差。这类问题在规则系统里定位相对容易，在端到端模型里却只能靠增加夜间数据、多模态融合、对抗训练来缓解。

另一个高频问题是城市泛化。如果训练数据过多来自某个城市，模型会记住那个城市特有的车道线画法、路面纹理甚至交通标志风格，换一个城市性能就会明显下滑。缓解办法是在训练集里加入多城市分布，或者用高精地图的语义信息做约束，削弱模型对视觉特征的过度依赖。我其实不太支持“端到端必须去掉所有先验、全让模型自己学”的说法，现实中加入一小部分可用的先验，比如可行驶区域和车道拓扑，往往能大幅提升泛化性，这并不违背端到端的初衷。

4.3 接管数据不分类，等于白采

实车测试和用户使用过程中，一定会出现接管：安全员伸手介入转向、刹车，用户觉得系统太激进主动踩下刹车。每一帧接管数据背后都是一个模型还不够好的真实样本，这种数据极具价值，但问题在于接管的触发原因完全不同。可能是因为感知误检，可能是因为规划太保守，也可能是用户不信任系统而提前接管。

如果不加分类直接扔进训练集，模型就会学到“正常路况下也要允许用户接管”，反而给自己增加矛盾行为。比较稳妥的做法是建立“接管字典”，记录接管主因、触发场景、系统置信度、时间戳和真值状态，定期统计各模块的接管占比。模型迭代的重点要跟着问题分布走，而不是漫无目的地往内存里堆数据。这一步决定了数据反馈的准确度，也直接决定了端到端模型的成长速度。

4.4 渐进式上线：安全验证没有捷径

最后说上线。端到端模型即使离线指标再好，也没有谁敢一次性全量放量。合理路径是分阶段小步验证：先在离线大库里跑全量回放，确认新模型相对老版本没有回归劣化；再到封闭场地做长尾场景实测，专门测那些前车急刹、路口鬼探头、施工绕行的危险case；随后进入城市小范围受限公测，允许安全驾驶员接管；数据达到阈值后，再考虑无安全员试点，最后才能全量开放。

每个阶段都要有清晰的“允许上路”阈值，比如每千公里接管次数、每千公里潜在碰撞次数、感知误检率等。没有阈值就放开，那不叫勇敢，叫盲目。我特别想强调的一点是，渐进式放量不是对模型不信任，而是对系统的整体负责。端到端模型的非线性太强，你很难通过离线数据完全推测出它在真实世界里遇到的所有情况，上线节奏必须匹配验证深度。

我在这一路上的体会是，端到端不是一个可以“毕其功于一役”的黑盒，它更像一套需要长期投入的方法论：数据管线、评测体系、仿真平台、安全兜底，每一环都比模型结构本身更决定成败。如果你正在考虑要不要上端到端，也先别只盯着指标刷分，先评估自己的团队撑不撑得起这套系统工程。很多时候，团队与团队之间的差距不在算法，就在基础工程。

最后再分享一个小习惯：做端到端项目时，从第一天就把“bad case可追溯”当硬需求来做。无论给样本打标签、记录模型版本，还是保存中间特征，都要有固定的规范。别等模型出了问题再回头补，那时候你已经在大海里捞针了。这个习惯，比调任何训练参数都值钱。