1. 先把“主线”这个词掰开揉碎

我做了五六年自动驾驶算法，感知、预测、规控都沾过，GTC'26 的自动驾驶相关 session 基本一场不落。这一届看下来，印象最深的不是某个具体的黑科技，而是满屏的“端到端”三个字：台上讲端到端，台下也在聊端到端，可每个人嘴里的端到端含义都不太一样。这篇文章不打算复述发布会，我想从一个算法工程师的视角，把“端到端时代，自动驾驶的主线到底是什么”这个问题拆开，聊一聊技术方向、落地方法，还有我们这拨人接下来到底该把力气往哪使。在搞自动驾驶算法、正在转型入行、或者带算法团队的朋友，应该都能从中找到一些能拿去用的判断。

1.1 端到端快被说成“玄学”了

先别急着争论模型，第一步是搞清楚大家嘴里的端到端到底指什么。我在会上至少听到了三种说法：一种是感知到规划的联合优化，内部依然有明确模块，只是接口可微；另一种是传感器进、控制指令出的纯端到端，中间完全靠网络自己表达；还有一种是把大模型、世界模型、VLA 都塞进去的“大端到端”。这三类东西的训练方式、数据要求、失效模式、评测手段完全不一样，硬放在一个词底下讨论，最后必然会变成各说各话。

这种含糊带出一个实际问题：很多项目立项时说“我们要上端到端”，但并没有定义是哪种端到端，结果算法团队按联合优化做，产品团队以为能去掉规则缓解，管理层希望一步到位换掉整个老系统。不到三个月，交付标准和预期就会开始打架。所以我的建议永远是，谈端到端之前，先把范围和验收约束写清楚，否则后面大概率要互相甩锅。

1.2 车圈聊的主线和算法圈聊的主线，根本不是一回事

把“主线”这个词放到自动驾驶语境里，至少有两个完全不同的方向。车企和产品侧眼里的主线，其实是“规模化迭代能力”：能不能让系统又快又便宜地量产、能不能通过监管和保险、能不能让用户真的敢用。算法侧眼里的主线，通常是“模型能力的下一个突破点”：网络结构怎么演进、长尾场景怎么解决、新的训练范式什么时候能落地。这两个主线长期错位，也是项目最容易对不齐的深坑。

以我自己的经历为例。某次内部评审会上，产品负责人问“端到端什么时候能去掉安全员”，算法这边只能指着指标解释“接管间隔还差一个数量级，而且长尾场景的置信度不够”。两边其实都认为自己在聊主线，但一个聊的是商业化节奏，一个聊的是技术成熟度。真正的分歧不是技术上的，而是大家对“主线”的定义不同步。想明白了这一点，很多争论其实能收敛成“先定主线口径，再定优先级”的讨论。

1.3 我的答案：主线在数据闭环和评测体系

现在说我的核心判断。模型架构的趋同速度，比很多人想象得快。今天你手里的 Transformer 家族、VLA 范式、世界模型思路，竞争对手大概率半年到一年内也会握在手里。但数据管道、自动标注体系、场景挖掘能力、评测基准、仿真回放系统，这些东西没法靠一篇文章或一次开源快速复制，它们需要持续投入，并且得在真实路况里被反复打磨。

所以我的答案很明确：端到端时代自动驾驶的主线，不是某一个更深的模型，而是“数据闭环的工程效率”和“评测体系的诚实程度”。谁能让数据闭环转得更快，谁的评测体系更能暴露问题，谁就能在接下来的迭代竞赛里占住身位。这条判断贯穿我后面的所有内容，后面的技术风向、落地细节、避坑经验，都是围绕它展开的。

2. GTC'26 上我看到的四个技术风向

2.1 风向一：数据生产力取代模型炫技

这一届 GTC'26 上的自动驾驶分享，给我的一个直观变化是：大家不再只秀模型指标，而是开始展示“数据是怎么被生产出来的”。某厂商的流水线从路采原始数据开始，经过场景挖掘、自动标注、难例筛选，再到训练集发布，全链路讲得很细。另一个团队讲的是如何把一次真实碰擦事件的几十秒录像，重建成高保真场景，再扩展出成百上千个带噪声变体的训练样本。

这个变化背后其实是被逼出来的。当大家的骨干网络都差不多时，端到端模型的泛化能力基本是由训练数据的分布决定的。你想让模型学会极端近距离切入、不规则路口、刁钻天气下的行为，靠手写规则和人工调参根本不现实，只能靠持续地往训练集里注入高质量稀缺样本。所以“数据从哪来、怎么标注、怎么去重、怎么保证质量”这类问题，反而变成了最值钱的算法问题。

2.2 风向二：场景重建与生成式仿真成为标配

和上一届相比，场景重建、生成式仿真这次明显从“学术 demo”变成了“工程基座”。基于神经辐射场或三维高斯溅射的方向，能把路采视频恢复成可以任意变换视角、调整光照的虚拟场景；扩散模型则被用来生成现实中很难遇到的对抗性场景，比如碎片横飞的匝道、突然压线的大车。配合一套可控场景编辑器，测试效率能得到数量级提升。

我在这块吃过亏。早期做仿真用的是手搭的 3D 场景，模型在仿真里跑得顺风顺水，一上真车就露馅，原因是仿真场景和真实路采在纹理、遮挡、传感器噪声上的差距太大。后来改成“真实场景重建加参数化扰动”，也就是先把真实录像重建出来，再在重建场景里加扰动、换天气、改障碍物轨迹，测试结果和实车的相关性才明显提上来。这个转变也让我理解了为什么 GTC'26 上各家都在强调场景重建，因为它本质上是在补“仿真与真实之间的桥”。

2.3 风向三：大模型开始渗透规控，VLA 概念持续升温

VLA（视觉-语言-动作模型）是这次会上被反复提及的词。粗看它和端到端是同一条路线的延伸：把视觉输入、语言指令和动作输出统一到一个模型里。争议点也很现实：语言模型对驾驶究竟是有真理解，还是在用海量数据“记忆”场景。我的倾向是，VLA 更适合处理需要常识推理和用户交互的细分场景，比如理解“前车打灯但意图模糊”“施工标识和导航出现矛盾”，但在安全关键的执行路径上，短期还是得靠轻量模型加规则兜底。

这里可以把几条技术路线放在一起看：

对算法工程师来说，选哪条路线不取决于谁的论文更漂亮，而取决于团队手里的数据、算力和评测能力能不能撑起这条路。很多团队一上来就追 VLA，结果连基础的数据闭环都没有，模型训出来根本没法验收，这个顺序我觉得是错的。

2.4 风向四：车端推理效率被摆上台面

大模型往车端走，第一个撞上的就是算力、功耗和时延这三堵墙。今年的分享里，针对注意力机制的稀疏化、低比特量化、token 化的时空表达、流式推理这些技术被反复提到，说明大家已经不再满足于在云端跑大模型，而是开始认真考虑“它能不能在车里实时跑”。对量产项目来说，模型涨两三个点的指标，通常抵不上一句“端到端延迟增加 10 毫秒就不能上车”。

我自己做部署时的体感是：算法工作量的重心正在从“刷精度”往“精度、延迟、功耗三角”转移。一个看起来简单的量化操作，放到量产链路里可能要过功耗测试、热管理测试、寿命老化测试。所以如果你的团队想走端到端路线，建议从立项第一天就把部署团队拉进来，而不是等模型训好了再谈优化，否则大概率要推倒重来。

3. 端到端项目落地：我踩过的坑和攒下的经验

3.1 数据闭环的最小可用版本怎么搭

很多人以为端到端项目的第一步是选模型，但我的经验是第一步永远是搭闭环。最小可用版本大概这么几条线：

1. 采集：按触发条件收集原始数据，触发条件可以是重刹车、近距离切入、异常天气、高精地图边界等。
2. 粗筛与去重：先去掉无效路段，再用向量聚类降低重复度，保留高信息量片段。
3. 自动标注：用基础模型先标一遍，人工只抽检高难样本，而不是全部人工标注。
4. 训练与对比：新模型和旧模型在同一个固定评估集上做 AB 对比，指标不涨不准进下一环。
5. 回放与仿真：把新样本注入仿真环境，跑一轮闭环测试，确认没有明显退化。
6. 影子模式验证：在车上并行跑统计，收集接管和干预样本。
7. 回流：把失败样本重新送回标注和训练环节，形成循环。

听起来不复杂，但每条线上都有坑。采集触发条件定得太松，一天能录十几个小时无效数据；定得太紧，关键的接管前几秒又总录不上。自动标注省了人力，但模型标注错的东西被当成真值喂回去，就是雪球式的自污染。我自己的做法是给每一批训练数据都加“来源标记”，回放评测时按来源切片看指标，哪一批数据让指标变差，能很快定位到是哪个环节出了问题。

注意：数据闭环的价值不是“数据量”，而是“最短回旋时间”。从发现一个 bad case 到它变成训练样本，再到评测回流，这个周期能不能压缩到一周以内，往往决定了团队的迭代速度。

3.2 影子模式是最便宜的安全验证方式

真实路测成本极高，端到端模型又没法像规则系统那样逐条去查逻辑，影子模式就成了性价比很高的验证手段。做法并不复杂：把新模型部署在一批车上，但不让它控制车辆，只在后台和线上系统并行运行，记录它的输出、线上系统的输出、以及最终驾驶员的行为。一旦人类接管、触发紧急制动、或者规则系统介入，这几秒的传感器数据连同三个输出就一起被存下来，成为后续分析的样本。

这里要特别说一个常见的认知误区：影子模式收集的样本，在严格意义上不是“模型错了”，而是“模型和人类行为不一致”。不一致不一定是错误，可能只是策略风格不同。我们当时给差异做了分类：安全相关差异、舒适度差异、无效差异。只有安全相关差异才会被直接加入训练集，舒适度差异可能只是参数调整，无效差异直接丢弃。不做这个分类，训练集里很快会堆满“看似重要但毫无训练价值”的噪声。

3.3 别拿单一指标验收模型：三层评估体系

端到端模型最怕用单一指标验收。我们的评测体系分三层，每一层回答不同的问题：

三层指标的视角完全不同。场景通过率高，只能说明设计好的场景没问题，说明不了真实路口涌现出来的各种组合；平均接管间隔高了，又可能意味着系统在边缘场景里过于保守。所以我给团队定了一个硬规矩：发布模型必须同时跑这三层，且任何一层出现明显回退都不能上线。哪怕整体指标在涨，某一层回落，也得先解释原因再说。因为这个回落往往就是下一次事故的种子。

3.4 端到端也要有安全带：部署侧的兜底设计

我再强调一遍我的观点：端到端负责聪明，兜底负责不蠢。量产系统里，安全兜底不是要不要的问题，而是怎么设计边界的问题。具体来说，输入端要做传感器一致性检查和信号质量校验；输出端要对控制指令做范围限制、平滑处理和单调性约束；系统级还要有最小风险状态（MRM），一旦端到端模型给出明显越界的输出，自动切到规则安全模式或执行减速、靠边停车。

有人会觉得加规则兜底是“退回到传统方案”，我不这么看。规则兜底本质上是一个浅层的高频保护回路，它和端到端模型并不是二选一，而是叠加关系。真正危险的是把宣传话术当成技术方案，觉得“端到端不需要规则”。我见过不止一个项目，因为盲目追求“纯端到端”而砍掉兜底逻辑，最后在评测中暴露出大量本可以用简单规则挡掉的风险。这个教训，希望看到这篇文章的朋友能记住。

4. 常见问题速查：新手最容易卡住的地方

4.1 训练不收敛、效果时好时坏怎么办

端到端项目里，“训练不收敛”和“效果忽好忽坏”是最常被问到的问题。但我的排查经验里，一大半情况根本不是训练的问题，而是评测不稳定。换个随机种子、换一批数据采样，同一套代码的评估结果都能差一大截，那你怎么判断迭代方向？所以遇到这类问题，第一件事是固定评估集、固定推理参数、固定随机种子，先确认你的观测本身是稳定的。

如果确认了训练确实有问题，再从头检查数据分布。端到端模型对数据分布极其敏感，某个场景类别样本突然变多，或某批自动标注的标签存在系统性偏差，loss 曲线就会变得“看着玄学”。我们的惯例是按数据来源和场景切片看指标，单独观察长尾子集的 loss 和精度。几乎所有“时好时坏”的模型，最终都能定位到某个数据来源的标签质量在波动。

4.2 仿真成绩很好、实车一塌糊涂的排查思路

这是最经典的落差，我在不同项目里遇到过不止一次。仿真成绩漂亮，说明模型在“标准输入”上表现良好，失败的根因通常有三类：第一是传感器差异，仿真里的点云和图像太干净，缺少真实噪声、运动模糊和遮挡；第二是时序差异，实车有控制延迟、底盘响应和标定误差，仿真往往过于理想；第三是场景组合差异，仿真脚本不会自动生成真实世界里那些“半遮半掩、意图不明”的交通参与者组合。

所以如果仿真成绩好而实车差，我的建议是别急着改模型，先做输入一致性测试。把实车采集的原始数据拿到仿真环境里做回放，看模型输出是否和实车端一致；如果不一致，很可能是时序对齐、传感器标定或者推理环境不同造成的。把这一层问题先清掉，再谈模型本身行不行。

4.3 长尾场景数据永远不够，到底怎么取舍

端到端时代大家都抱怨长尾数据永远不够，但“不够”其实不是一个数量问题，而是分布问题。你需要的是“对场景空间的覆盖率”，不是绝对数据的多少。我们在做数据预算时，会先按“风险等级乘发生频率乘可挖掘难度”给场景排序，优先补那些高风险、有一定发生频率、又最容易通过采集或仿真拿到足够样本的场景，而不是看到什么有趣就采什么。

另外一个取舍原则是看数据的“有效信息量”。一条 100 公里的平顺高速，对模型的训练价值可能不如一个 5 秒的极端切入片段。所以采集端我们会刻意配置触发条件，只存有用的片段；离线端再用嵌入向量做聚类去重，把重复度极高的样本降到最低。用这个思路，训练集可以在不涨绝对样本量的前提下，明显提升模型在长尾上的表现。

4.4 团队转型：算法工程师的“新基本功”

最后聊个和每个人直接相关的事：端到端时代，算法工程师的角色正在变化。以前大家觉得算法工程师就是写模型、调参、刷指标；但现在更值钱的技能，是理解数据从哪来、标注怎么做、评测怎么搭、仿真怎么用、部署怎么落。我招聘时基本不先问网络结构，而是让候选人现场设计一个数据闭环：从发现 bad case 开始，说明怎么筛数据、怎么标注、怎么训练、怎么验证、怎么回流。这个问题的答案，基本能看出一个人是在做“模型”还是在做“系统”。

我不是说要放弃模型能力，恰恰相反，理解模型原理仍然是基本功。但在端到端时代，模型越来越像一个大工业系统里的标准件，真正拉开团队差距的，是把这个标准件装进数据闭环和评测体系里的工程能力。所以我的建议很直白：每周留一点时间去看数据管道、评测平台和仿真工具的进展，比追着每篇新论文跑更有长期复利。

5. 我再多说几句个人判断

5.1 两三年内，主线大概率还是这三件事

把自己这些年看到的和踩过的放在一起，我对端到端时代主线的最终判断是三条：第一，数据闭环的工程效率，这决定你迭代的速度；第二，可解释、可验证的安全体系，这决定你敢不敢把系统交给用户；第三，低成本、可扩展的部署能力，这决定你能不能把技术变成产品。这三条每一条做扎实，都比单纯堆模型参数更接近自动驾驶的真正主线。

这里也是想给刚开始关注这个领域的朋友提个醒：别被“某个网络刷新了指标”的新闻带着走。新闻里的每个突破，放在真实量产语境里通常只是整个系统的一小块拼图。看一场技术会议，最有价值的动作不是记住几个炫酷的名字，而是观察各家在数据、安全和工程上到底把资源押在了哪里。

5.2 算法工程师接下来建议补的三类能力

如果非要给同行一个更具体的建议，我会说补三类能力。第一是数据工程能力，包括场景挖掘、自动标注质量评估、数据版本管理；第二是评测与仿真能力，能设计出暴露问题而不是掩盖问题的评估方案；第三是部署与量化能力，理解模型在真实算力、功耗和延迟约束下如何存活。这三类能力不会因为某个新模型出现而贬值，反而会在行业回归理性后变得越来越刚需。

顺便说一句，很多在校学生或者想转入自动驾驶的朋友，一上来就研究最前沿的模型结构，这没错，但我更建议他们同时花时间做小规模的闭环项目：自己设计一个最小数据管道、训练一个小模型、再搭一套简单的回放评测。这个闭环哪怕是玩具级别，也会让你在面试和实际工作中的认知比别人高一层，因为你会真正理解“纸上模型”和“线上系统”之间的距离。

5.3 最后分享一个我自己的工作习惯

我平时有个习惯，每隔一段时间就把最近一次模型发布时的失败案例重新翻出来看一遍，记录“当时为什么没发现”“后来是怎么发现的”“如果重来一次，哪个环节可以先拦住”。端到端系统最大的风险就是问题发现得晚，因为它的失败往往不是一个模块的逻辑错，而是数据分布、标注质量或者评测盲区一点点累积出来的。这个复盘习惯帮我在很多项目里提前挡住了问题，也希望对你有点用。

算下来我在这个行业里也踩了不少坑，但对自动驾驶这件事仍然保持乐观。端到端不是魔法，它只是把更多决策交给了数据，而数据背后的工程体系，恰恰是我们这些算法工程师最能发挥价值的地方。多关注闭环、多盯住安全、多理解部署，比任何单点技术突破都更能决定你在这个时代的位置。