开头先聊点实际的。我在这行做了不少年，从早期基于规则的决策规划，到后来端到端模型上车，再到现在大模型开始渗透智能驾驶的每一个环节，最直观的感受是——大家讨论的技术底座已经完全变了。“大模型驱动智能驾驶全链路革新”这个标题，不是某一家公司的宣传口号，而是整个行业正在发生的真实迁移：感知、预测、规划、数据、仿真、测试、云端训练，整条链路都在被大模型重写。这篇文章不聊虚的，只拆解全链路到底变了哪些环节、每个环节怎么做、踩过哪些坑，以及哪些经验可以直接复用到你的项目里。无论你是做感知算法、规划控制、数据平台，还是做工程落地的同学，希望这篇能给你一张相对完整的地图。
1. 全链路革新的整体设计与链路拆解
1.1 从“规则驱动”到“数据驱动”再到“模型驱动”
要理解大模型给智能驾驶带来的变化，得先回顾一下过去的架构长什么样。传统智驾系统是典型的分层流水线：传感器原始数据进来，先做目标检测、语义分割，得到一个中间表征；然后基于这个表征做目标跟踪、轨迹预测，输出未来N秒的障碍物轨迹；再往上走，决策规划层基于这些预测结果，在Frenet坐标系或笛卡尔坐标系下做行为决策、路径规划和速度规划；最后交给控制层去执行。
这套体系在过去十年里打磨得非常成熟，但问题也很明显：每个模块都是独立优化的，误差会逐级累积。感知层漏检了一个小目标，预测层就不知道它的存在，规划层自然更不可能避让。而且大量规则逻辑是人写的，corner case越多，规则就越臃肿，最终陷入“修不完的patch”困境。
大模型介入后的第一个核心变化，是这套流水线开始被压缩和重构。感知侧不再只输出目标框，而是输出占用网格、拓扑关系、语义图；预测不再只是几条轨迹，而是基于整个场景embedding的概率分布；规划也不再用A-star、EM Planner这类传统搜索，而是直接条件在感知表征上生成轨迹。整条链路从“有监督的模块组合”变成了“可微的统一模型”，这是全链路革新的底层逻辑。
1.2 全链路到底革了什么：五层拆解
我用自己实际参与过的项目来做个整体抽象。大模型驱动的智驾全链路，大致可以分成五层：
- 车端感知层：引入BEV（Bird's Eye View）统一表征，基于Transformer架构构建多模态融合模型，输出动态目标、静态要素、占用网格等多任务head的结果。
- 决策规划层：从有限状态机转向基于大模型/Transformer的序列决策模型，把“感知特征 + 导航信息 + 自车状态”作为context，直接输出轨迹或驾驶意图。
- 数据闭环层：大模型参与数据挖掘、自动标注、场景生成的整个循环，让数据不再是海量的原始录像，而是高价值的训练样本。
- 云端训练层：借助大模型底座构建统一特征提取器，配合数据并行和模型并行策略，让训练效率和模型能力持续迭代。
- 部署验证层：大模型产物经过蒸馏、量化后部署到车端，配合仿真和路测大模型实现高效的闭环验证和回归测试。
这五层不是独立的，它们通过数据流和反馈机制串成一条完整的链路。你改了一个感知模型的结构，下游的预测、规划、数据标注、仿真场景都会受影响；你换了一种数据挖掘策略，训练分布变了，车端表现也会变。所以做这个方向时必须保持全局视角，不能只盯着单一模块刷指标。
1.3 为什么只有大模型能承担“全链路”角色
有人会问：以前也有数据驱动方法，LSTM轨迹预测、端到端RL规划，这些不都是“模型化”吗？为什么全链路革新偏偏发生在大模型时代？我的理解是，以前的模块化模型在表征能力和表达范围上有天花板，而大模型带来了三个关键能力的跃迁：
- 统一的表征空间。BEV特征的引入让视觉、激光雷达、毫米波雷达都能投影到同一个鸟瞰空间下做特征融合，大模型的注意力机制天然适合处理这种“多模态对齐”问题。
- 强大的先验与泛化能力。预训练模型从海量驾驶数据中获得了对交通场景的常识理解，遇到长尾场景时不再完全依靠规则的暴力堆砌，而是靠embedding的泛化来完成迁移。
- 序列建模的长程依赖。驾驶本质是序列决策问题，大模型对时序上下文的长程编码能力，让预测和规划可以真正利用到前十秒的全局场景信息，而不再局限于滑动窗口。
这三项能力叠在一起，决定了重构全链路的技术底座。我们团队最开始也是保守地在感知模块里引入Transformer encoder做BEV融合，后来发现收益不够大，才逐步往上推，把预测、规划也模型化，最后形成了统一架构。这个过程比较曲折，但也让我对“全链路”这个词有了实感。
2. 核心环节：感知重构与大模型基础能力
2.1 BEV感知：从“像素视角”到“鸟瞰视角”的范式转移
感知是全链路革新的第一环，也是大模型最先落地的地方。传统的单目视觉感知是在图像坐标系里做检测，每个摄像头各自理解自己视角下的场景，然后靠后处理把结果拼起来。这种方案在遮挡、跨相机目标、动态目标位置不连续的情况下很容易出问题，而且很难做时序融合。
BEV方案的核心思路是，借助Transformer和注意力机制，把多个相机的图像特征投影到一个统一的鸟瞰平面网格上。这个网格相当于是把车周围一圈的空间分成比如200x200的格子，每个格子对应一个特征向量。投影过程中，模型通过可学习的query（Anchor）去查询图像特征，自动学会“图像中哪个像素属于这个地面网格位置”。这套机制其实不需要显式的内外参几何变换，模型的注意力自己就把对应关系学到了。
我做过几个不同平台的BEV迁移，实操中需要注意的维度包括：网格的分辨率、感知范围、特征对齐方式。拿网格分辨率来讲，如果感知范围是前后各50米、左右各25米，用0.5米的网格分辨率就是200x100个grid cell，每个cell的特征维度通常在256维以上。网格越细，小目标召回越好，但计算量成倍增长。如果部署平台的NPU算力有限，第一版可以先上0.5米分辨率，后续再根据corner case的暴露情况做局部加密。
2.2 多模态融合与Occupancy网络
BEV一个很自然的优势是，不同传感器的特征都能投影到这个统一空间里——激光雷达点云体素化之后投影BEV，毫米波雷达点云也投到同一平面。这样就不需要再做复杂的后融合策略，直接在特征层面做concat或者cross-attention融合。
多模态融合有个容易踩坑的地方：不同传感器之间存在时延差和坐标系差异。摄像头是30Hz的曝光，激光雷达旋转一周10Hz，毫米波雷达的更新频率也不稳定。如果不在输入侧做时间对齐，模型学到的特征融合关系就是错位的。我的经验是，在输入特征里增加一个时间delta embedding，让模型自己知道每路传感器的最新帧距离当前时刻有多远，修正效果比后处理强行同步好得多。
Occupancy Network也是大模型时代感知层的重点方向。传统检测只会输出目标框，但路面上的异形障碍物、拖车、野外植被、工程护栏，这些用矩形框根本无法表达。Occupancy的思路是把BEV空间划分为体素网格，每个格子预测它的占据概率和语义类别。这本质上是三维语义分割问题，Transformer架构配合跨层连接做起来效果比较好。
占用网络训练时的标签通常来自离线点云标注系统，但对移动的物体需要结合目标追踪结果做时序膨胀，否则会出现“拖尾”和“空洞”现象。我们在做的时候发现，把占用预测做成多尺度的，从1米分辨率到0.2米分辨率的三个head，在长尾障碍物上的召回率提升非常明显，代价是训练显存大约多出30%——这个取舍值得提前评估。
2.3 车端模型怎么“瘦身”上车
大模型在云端的效果好，但是车端的算力是严格受限的。市面上主流智驾平台的AI算力从几十TOPS到几百TOPS不等，但通常还要跑多个模型服务，单个模型能拿到的算力预算很紧。所以车端部署不能直接跑一个几十亿参数的大模型，常用的路线是“云侧大模型 + 车侧小模型”的师生蒸馏结构。
蒸馏的具体做法是，让云端大模型对海量驾驶数据做特征提取，生成软标签或中间特征，用这些去训练车端的小模型。小模型可以通过结构搜索来设计，比如基于RepVGG风格的轻量化backbone，配合ONNX导出和TensorRT的int8量化，在保持主干感知精度不降太多的前提下，把单帧推理时间压到30ms以内。
量化这一步要特别小心。纯int8量化对Transformer里的softmax和LayerNorm敏感性很高，经常出现精度掉点。我们的处理方式是，对qkv投影和FFN里的线性层做per-channel量化校准，对LayerNorm和softmax保留fp16，混合精度方案整体掉点在1%以内。上了这个方案之后，模型体积缩小接近四倍，车端推理效率明显提升。
3. 决策规划层的模型化与大模型化
3.1 从有限状态机到条件轨迹生成
传统规划控制模块最核心的组件是有限状态机（FSM），里面有诸如“直线巡航”、“跟车”、“变道”、“绕障”、“靠边停车”等一堆状态，状态之间靠枚举的跳转条件来切换。这个系统在简单场景里够用，但一旦遇到复杂交互（比如拥堵排队、匝道汇入、无保护左转），状态组合爆炸，参数调起来非常痛苦。
大模型驱动的规划，本质上是把“轨迹生成”变成了一个条件生成问题。输入不再是离散状态，而是“感知BEV特征 + 自车状态 + 高精地图/导航意图token”，模型直接输出一条或者一组带概率的轨迹。这个过程和LLM生成一个句子非常相似：前视特征和导航意图就是prompt，轨迹点序列就是生成的token。
实际落地中，我建议采用“仿真验证优先”的策略。在真实道路前，先在仿真环境里大规模采样场景，验证模型在不同速度区间、不同曲率道路下的轨迹平滑性和安全性。仿真数据虽然和真实数据有domain gap，但用来做回归测试和边界能力摸底，效率远高于路测。
3.2 VLA：视觉-语言-动作统一模型的实践思路
VLA（Vision-Language-Action）模型是决策规划方向上一段时间以来的热点方向。它的思路是把摄像头图像和对场景的自然语言描述统一编码，然后输出具体的车辆控制动作或轨迹。比如前方有施工围挡、右侧有大货车挤压，大模型通过语言模态理解这些语义信息，再映射到具体的避让轨迹。
实际落地VLA有几个绕不开的问题。第一是实时的推理延迟，Transformer解码整个轨迹点的耗时通常远高于传统插值方法，因此工程上可以先让VLA生成意图和关键航点，底层仍然用确定性控制器做轨迹平滑；第二是对语言标注的依赖，训练数据里需要大量的场景描述文本，这对数据标注链条提出了新要求；第三是安全兜底，任何模型输出都不能绕过硬限速、碰撞检测这些刚性约束。
我团队实践出来的一个折中方案是，将VLA模型输出的不是最终轨迹，而是“驾驶行为的离散token”：比如“匀速直行30米”、“向左变道至相邻车道”、“在stop线前停车等待”这类高层决策。这些高层决策再由一个轻量级的轨迹求解器把它翻译成具体控制指令。这套架构既保留了语义理解和复杂交互推理能力，又让实时性落到了可控范围内。
3.3 安全冗余不能因为大模型而缺席
这是整个行业都心知肚明但很少公开细聊的话题。大模型在复杂场景的理解上限很高，但背后的可解释性和确定性仍然是短板。因此全链路革新从来都不是“全交给模型”，而是模型与规则互为备份。
实际工程里，我会在模型输出的轨迹之后套一层安全校验模块：包括车辆运动学约束检查（曲率、加速度是否超限）、Frenet坐标系下的碰撞检测、车道边界约束、最小安全距离校验。任何一个条件不满足就拒绝模型的输出，并回退到保守的规则轨迹。这套冗余机制虽然听起来不那么“前沿”，但它是真正敢把大模型系统推向量产的底气。没有这层兜底，再强的模型也只能停留在Demo阶段。
另外，规划模型训练时还必须加入“交互博弈”的概念。如果你的系统每次都在路口选择最保守的策略，其他司机就会不断加塞，最终导致通过效率极低甚至根本无法汇入车流。大模型的优势恰好在于它可以从大量驾驶数据里学到“适度强硬”的交互策略，这和规则系统的“固定让行”有明显的体验差异。
4. 数据闭环：全链路革新的背后引擎
4.1 大模型驱动的自动标注体系
数据闭环是全链路革新的隐形引擎，而自动标注是其中最典型的应用。传统标注依赖大量人工画框、画车道线、标轨迹，一个复杂场景的3D标注可能耗时几十分钟，成本高、效率低，而且标注质量波动大。
大模型介入后，自动标注的路径发生了根本变化：感知大模型先对所有原始数据做预标注，生成目标的3D框、语义分割mask、跟踪ID；然后一个轻量级的人工审核环节只处理模型置信度低的部分；最后再用时序优化模型对轨迹做平滑修正。这套流程做下来的效果是，同等质量下标注成本可以降到原来的三分之一左右，周期压缩了约一半。
做自动标注时有一个需要特别关注的环节——数据的一致性。不同时间段、不同天气条件下同一位置的标注如果存在不一致，训练出的模型在时空泛化上会出问题。我们的做法是引入“场景级标注复核机制”，即由大模型对同一个场景的连续帧整体推理，只允许标注的置信度按帧传播，避免单帧模型的抖动导致标注闪烁。
4.2 场景挖掘与大模型辅助的数据分布优化
大量路测数据里真正需要训练的是长尾场景，也就是那些“十万里挑一”的危险情况。如何在海量视频里把这些场景高效挖出来，直接决定了模型能力的天花板。大模型可以承担场景检索和分类的角色：对每一段路测视频做场景embedding，再用聚类算法识别“没见过”的语义簇，自动把异常、冷门样本捞出来进入训练集。
这个机制本质上利用了CLIP风格的多模态embedding——将视频帧与一条自然语言描述对齐，比如“雨天夜间，前方有一个临时施工路障”，通过这种对齐，数据平台可以做到语义级检索。我体验过这个流程后直观的感受是，原先需要数据工程师看几百段录像找样本的工作，现在变成了一条SQL查询加几次聚类分析。这个效率差距非常大。
场景分布优化方面，我们通常还会在训练集里做“采样权重控制”。一般按困难样本的挖掘难度赋权，高频出现但差异度低的场景降权，低频但罕见度高的场景升权。这个权重本身也可以由一个离线模型拟合，而不是人工拍脑袋设置。整个数据闭环跑起来之后，模型的迭代节奏从原来的“版本周更”变成了“按需日更”，这个变化对工程流水线提出了全新的要求。
4.3 合成数据与仿真环境生成
真实路测数据的获取成本很高，尤其是危险场景，几乎不可能在公开道路上“原生采集”。合成数据因此成为数据闭环的重要补充。大模型在这里的玩法是，利用扩散模型生成高逼真的交通场景渲染图片，或者用 Neural Radiance Fields / 3D Gaussian Splatting 的基础把采集过的场景做视角合成，生成不同天气、不同光照、不同遮挡条件下的同场景数据。
我在项目实践中感受到，合成数据在总量上可以做得很大，但真正提升模型能力的核心是“领域的对齐度”。如果合成数据的背景纹理、光照模型、物体材质与真实域差异太大，模型会学到合成域特有的伪特征。转为在下游任务上加一个判别器做domain adaptation，或者让合成数据从真实数据提取的布局做条件生成（即定结构、变外观），能显著缓解这个domain gap。
仿真环境的自动生成也很关键。现在做决策规划模型回归测试，不能再只靠人工搭几个固定场景，而是用GPT风格的大模型生成一份“场景行为树”，比如“主车以60km/h接近路口，左侧有直行车加速通过，右侧盲区有摩托车突然切入”，然后由仿真引擎自动实例化为可运行的物理场景。这套体系跑通后，模型的回归覆盖能力从几十个场景提升到几千个场景，验证效率提升了几个数量级。
5. 工程落地与基础设施实战
5.1 训练框架与分布式训练基建
全链路革新的技术底座是云端训练基础设施。做过多传感器融合模型的都知道，这类模型经常包含图像编码器、点云编码器、注意力融合模块、多个任务head，参数量动辄几亿到几十亿。单卡训练根本不现实，必须上多机多卡分布式训练。
工程上我偏向于使用混合并行策略：视觉backbone用数据并行（Data Parallel），融合模块因为涉及不同传感器特征的对齐，用模型并行（Model Parallel），优化器状态用ZeRO阶段2或者阶段3来切分。这几种并行策略的组合需要调试，实践下来最影响训练效率的是通信瓶颈——每步迭代都要做梯度all-reduce，如果机间网络带宽不足，多卡扩展效率上不去。
训练策略上面，我们通常会采取“三阶段训练”：先在大规模无标注数据上做自监督预训练（masked autoencoding之类），让模型学到通用的视觉/点云表征；然后在有标注数据上做多任务微调，同时学习检测、分割、占用预测、轨迹预测等任务；最后用难例挖掘数据做困难样本增强训练。三阶段训练的总时长通常在数百个GPU日以上，但换来的是模型泛化能力的本质性提升。
5.2 车端推理的工程优化
云端模型的算力再强也搬不到车上，车端推理优化的核心约束是：计算资源有限、功耗有限、内存带宽有限、实时性要求高。常用的优化手段包括模型蒸馏、结构重参数化、剪枝、量化，以及算子融合。
以Transformer模型的上车为例，一个核心的优化是算子融合。把QKV投影合并成一个GEMM，把多个连续的LayerNorm和残差连接合并，可以减少kernel launch次数和数据搬运量。TensorRT可以通过onnx-graphsurgeon做这种图优化，但需要手工写插件来处理一些自定义算子——比如BEV池化、稀疏注意力这类非标准结构。
硬件选型上也需要实测不同平台的兼容性。有的NPU对int8的卷积支持很好，但Transformer里的矩阵乘法和Softmax支持不完整，这种情况下就得把关键算子回退到float16。我的经验是，在做模型选型之前，先用目标硬件跑一个小型的算子benchmark，覆盖卷积、矩阵乘、注意力、归一化这些核心算子，评估结果直接决定模型结构设计走向。
5.3 仿真测试与路测的结合
大模型系统的测试验证与传统规则系统有很大不同。规则系统可以逐条对标需求，而大模型的行为是涌现出来的，它可能在某些没有显式定义的场景里表现出超出预期的能力，也可能在一些“看起来很简单”的场景里突然失灵。所以测试策略必须从“需求覆盖”转向“分布覆盖+压力探测”。
仿真测试适合做大规模压力探测。把大量的历史路测片段注入仿真环境，让模型重新跑一遍，对比轨迹差异；再用自动生成的corner case做鲁棒性抽查。仿真通过率高不代表实车安全，因为仿真引擎的物理精度、传感器噪声模型和真实世界总是有差距。
路测依然是最终安全验证的必要环节。实车路测时需要采集完整的“影子模式”数据：大模型在后台跑，但执行的是保守策略，只在离线评估差异大的时机人工审查。影子模式跑的里程越多，模型在真实场景下的表现profile就越完整。我们的路测团队在不同城市、不同时段、不同天气下做覆盖，重点盯那些交互复杂度和场景稀疏度过高的区段。
5.4 版本管理与快速回滚机制
大模型系统上线后，版本管理与快速回滚是个容易被忽略的关键工程问题。传统智驾版本的更新周期按季度算，而数据闭环跑起来后，模型的迭代速度可以到周甚至天。如果没有一套成熟的版本管理机制，更新风险会急剧放大。
我们的做法是，线上采用“双模型并行架构”：新版本模型与旧版本同时跑在量产车上，新版本的结果只用于影子分析，不实际控制车辆；经过一段时间的影子验证，确认新模型在各项指标上都不劣于旧版本，并且没有新增的已知危险行为，才通过OTA逐步灰度放量。灰度比例从1%到10%到50%再到100%，每步观察业务指标和投诉数据，任何异常都能通过配置动态回滚到上一版本。
这个机制和大模型的能力迭代是匹配的。大模型的更新不像规则系统那样可预测，必须用渐进式的发布策略来对冲不确定性。如果谁的CI/CD流程里没有沉淀出这样的发布体系，大模型量产落地基本无从谈起。
6. 常见问题与排查技巧实录
6.1 多模态融合时间戳不同步问题
这是我在做BEV多模态感知时踩得最深的坑之一。摄像头和激光雷达的触发机制天然不同步，如果直接把两路特征concat，模型拟合出来的融合关系是扭曲的。表象是雨天或夜间目标漏检率上升，排查时单看一路传感器都很正常，但融合输出就不稳定。
解决思路是，在融合模块前加一个时间同步层，把每路传感器的时间戳归一化成相对于当前推理时刻的delta，再用一个小的MLP把delta编码成embedding拼到特征里。另一个实用的排查技巧是，在训练日志里专门输出每个batch的“传感器时间差分布”，如果发现时间差范围和模型感知性能有相关性，那基本可以断定是同步问题。
6.2 蒸馏模型精度掉点的排查思路
师生蒸馏在上车阶段经常出现精度掉点，但这不一定是学生模型容量不够。我排查下来发现常见的坑有四个：
- 教师模型的软标签本身包含噪声，蒸馏之前需要做标签清洗；
- 中间特征蒸馏的loss权重设置不当，cover了任务loss；
- 学生模型结构改动过大，与教师的表征空间不一致；
- 量化后的学生模型在低比特下分布偏移明显。
排查方法也很直接：先在fp32精度下单独验证学生模型精度，如果这里就掉了，问题出在结构或蒸馏策略；如果fp32不掉但int8掉了，问题出在量化校准。分层排查可以很快定位问题源头，不用一上来就推翻整个方案。
6.3 仿真通过率高但路测拉胯的原因
仿真和真实路测之间存在所谓的domain gap，即便仿真里跑几千个场景全通过，实际路测仍可能翻车。常见的几个原因包括：
- 仿真引擎的车辆动力学模型过于理想化，极限工况下的轮胎力、悬挂响应和真实车辆差距较大；
- 仿真里的传感器噪声是人工加的，和真实光学噪声、电磁干扰的分布完全不一致；
- 真实环境的地图拓扑、交规语义比仿真复杂得多，模型在仿真里没有机会见到这些分布外输入。
我的建议是，仿真测试的重点不要放在“证明模型没问题”，而是放在“寻找模型失效边界”。仿真里失败是好事，它能精准暴露薄弱环节，让你把有限的真实路测资源用在最值得验证的场景上。仿真里全过反而是危险的信号，说明场景设计得还不够有挑战性。
6.4 训练数据不平衡导致的任务坍缩
多任务联合训练经常出现任务间竞争，最终导致某个任务精度下降甚至完全崩溃，也就是“任务坍缩”。比如感知模型里检测任务和占用任务并存，检测loss太小而占用loss太大，模型可能为了压低占用损失，干脆把所有区域都预测成占用，检测精度随之崩掉。
排查任务坍缩的有效手段是，在训练过程中实时监控每个任务loss和对应精度的曲线。如果某个任务的loss在下降但精度长期不再提升，通常说明该任务被其他任务压制。解决方式可以调整loss权重，更有效的是为每个任务设计独立的任务head和特征提取分支，让底层共享表征，上层分支解耦，减少梯度的直接竞争。
6.5 模型无法收敛的迁移学习陷阱
大模型预训练之后在智驾数据上微调，偶尔会遇到整个loss曲线不降反升的情况。很多团队第一反应是学习率太大，但我在实践中遇到过的更隐蔽的原因是：预训练阶段模型的输入归一化方式和智驾数据分布严重不一致。比如预训练数据是ImageNet风格的自然图像，而智驾的鱼眼图像畸变和光照分布完全不同，微调阶段如果沿用预训练模型的输入归一化参数，模型底层卷积核全部的分布假设都是错的。
解决思路是，在预训练模型接入智驾数据之前，用数据集的统计均值/方差重新计算归一化参数，并且在前几个epoch使用一个较低的学习率来“唤醒”底层特征。如果还是不行，考虑把模型前几层冻结，只微调后续层和任务头。我在一个鱼眼感知项目里用过冻结前两层再微调的方式，收敛速度和最终精度都明显改善。
7. 从工程视角看全链路革新的边界与心得
大模型驱动智能驾驶全链路革新不是一句口号，它把感知、预测、规划、数据、测试、部署整个链条的技术范式都换了一套。但这整套范式换新，并不意味着传统的工程素养被抛弃了——恰恰相反，越是大模型占主导的地方，越需要扎实的工程兜底：可复现的训练流程、可观测的日志指标、可回滚的发布机制、可解释的安全校验。
我个人在实际项目里最深的体会是，不要迷信某一个模型或者某一种架构能解决所有问题。全链路革新的关键不是把某个模块换成大模型，而是让大模型能力在整个数据流里形成正向循环：车载端不断生成数据，数据闭环持续筛选高价值样本，云端模型不断迭代，蒸馏后的车端模型能力逐步爬升，再通过影子模式和灰度发布交付给用户。这是一个系统工程，不是算法团队的“单点突破”。
最后再分享一个小技巧：无论你的模型结构设计得多先进，先花时间把整个数据链路的评估指标体系统一起来。感知、决策、规划、测试各环节都有自己独立的指标，但如果不能通过一个统一的标准把它们关联起来，很多性能提升在产品层面是无法感知的。我们内部最终把“接管率”、“安全干预率”、“用户平均行驶里程内舒适制动次数”这几个端到端指标当作北极星，其他所有环节的指标都围绕它们做对齐。这种链路级的对齐，才是全链路革新真正落地时最难但最有价值的部分。
