2024 年以来，我一直在支持出行行业的自动驾驶客户。在和客户的对接里，逐渐萌生了把自动驾驶算法认真捋一捋的想法，于是陆续拉了 BEVFormer、YOLO、MapTR、UniAD、SparseDrive 等开源仓，搭配 nuScenes, Waymo等 数据集做了一些上手体验。后来顺着「模块化自动驾驶」和「端到端自动驾驶」这两个概念往下挖，才把原先一个个孤立的算法仓串起来，搭起一个初浅的知识框架。最近借 AI 引导思考，把这段经历又梳理了一遍，整理成此文。

文中涉及的十个主流开源项目，大致可以归为三种路线：先教机器「规则」（模块化），再让机器「模仿」人开（端到端），然后让机器在统一表示上「理解」再决策（统一端到端 + 世界模型）。下文先厘清这三种路线的系统架构差异，再落到具体场景与仓库，接着拆解技术细节、哲学根源与未来走向，最后按不同角色给出一套可操作的建议，力求一气贯通。

一、自动驾驶系统与算法模型的关系

在进入具体仓库与场景之前，不妨先建立一张总览图。自动驾驶系统负责从传感器到执行器的整条链路，算法模型是里面做感知、预测、规划的那一块，可以单独换。模块化、端到端、统一端到端之间的差别，主要在这三点：有没有把子任务拆开、中间表示是否共享、有没有用最终目标（比如规划质量）反传去优化前面的模块。下面用三种架构图把数据流说清楚。

1. 模块化方案（Perception → Prediction → Planning → Control）

模块化把开车拆成四步：感知、预测、规划、控制，每步有明确输入输出，可以单独开发、评测和替换。感知负责「看到什么」（障碍物、车道线、红绿灯等），预测负责「别人会怎么动」，规划负责「我该怎么走」，控制负责「把规划轨迹跟住」。百度 Apollo、Waymo 等 L4 平台都是这一套，工程上成熟、可解释性强，但对高精地图和接口设计依赖大。

模块化方案架构图

整体来看，数据流是单向串联的：前面错了后面会跟着错，误差会一路往下游传。模块之间靠显式接口传东西，比如障碍物列表、轨迹分布、参考线；高精地图和定位作为先验参与规划和感知（例如红绿灯 ROI），相当于把「静态世界」事先告诉系统，感知只需聚焦动态障碍物。这种拆分的优点是每个环节可独立调试和替换，缺点是接口设计和误差传播都是工程上的难点。

与模块化形成对照的是端到端路线：不再显式拆感知、预测、规划，而是用一个网络从传感器直接映射到控制量。

2. 端到端方案（传感器 → 单一网络 → 控制）

端到端不显式拆感知、预测、规划，一个大网络从原始传感器（多为相机）直接映射到控制量，中间表示不强制对应「检测框、轨迹」这些人造概念。comma.ai 的 openpilot、Tesla FSD 等 L2+ 系统走这条路。

端到端方案架构图

这里没有单独的感知/预测/规划模块，只有「编码器 → 时序 → 控制头」：图像先进编码器提特征，再在时间维上融合多帧，最后从隐表示直接回归方向盘和油门/刹车。训练目标多是行为克隆（人类驾驶数据）或强化学习；不依赖高精地图，但对数据量和质量依赖很大，需要百万英里级、多场景的数据才能把长尾兜住。工程上部署简单，单模型上车载 SoC 即可，适合 L2 量产。

在这两条路线之外，还有一条「统一理解」的路：在共享表示上联合多任务，并用规划损失反传驱动前端，同时可选地引入世界模型的想象能力，让系统在「脑子里」试动作再选优。

3. 统一端到端 + 世界模型（BEV 多任务联合 + 世界模型想象）

统一端到端在共享的 BEV（鸟瞰图）表示上一起做检测、跟踪、轨迹预测和规划，并且用规划损失反传，让前面几项为「规划好不好」服务，而不是各干各的。世界模型再往上加一层「想象」：学环境动力学，在脑子里 rollout 不同动作再选优，更接近人类「先想再动」的决策方式。UniAD、OpenDriveLab（GAIA-1/DriveLM）等属于这一类，目前以学术界和前沿团队为主，工业落地还在逐步推进。

统一端到端+世界模型架构图

规划 loss 参与总损失并反传到检测和预测，使前端任务为「规划好不好」服务；中间表示是统一 BEV，方便做空间推理和多任务共享。世界模型（图中虚线）学 P(s’|s,a)，在「想象」里试动作或做数据增强，目前仍是研究热点，算下一代方向。

有了上面三张图，三种路线在数据流与模块划分上的差异就大致清晰了：模块化是「拆开干、接口传」；端到端是「一个网络到底」；统一端到端是「共享表示 + 规划反传 + 可选世界模型」。接下来从具体场景和十个仓库入手，看它们在工程里长什么样。

二、同一个左转，三种解法：从场景与仓库看三种路线

前面用三张架构图把三种路线的「数据流、模块划分」说清楚了。这一部分从具体场景和十个仓库入手，看这三种路线在工程里长什么样：同一个左转场景，三种系统分别怎么解？市面上有代表性的开源项目，又分别属于哪条线？不求你立刻记住每个仓库的细节，只求建立一种直觉——同样叫「自动驾驶」，背后可以是完全不同的技术信仰。

2.1 一个具体场景

先看一个具体场景，你就能直观感受到三种路线的差异。

场景设定： 傍晚六点，城市主干道，无保护左转。对向来车不断、行人过斑马线、灯刚变黄，车要在保证安全的前提下择机并入对向车道。这是很常见、也很考验系统的一道题。

三种系统，三种解法：

·Apollo 会先「认」：用激光雷达和相机检测障碍物和红绿灯；再「猜」：预测别的车和行人接下来会怎么动；然后「算路」：在参考线上生成路径和速度曲线；最后「跟住」：控制车按这条轨迹跑。四步串成一条流水线，每步都有明确输入输出。

·openpilot 不拆这几步，而是把前置摄像头过去大约一秒的画面，直接喂进一个叫「supercombo」的大网络，网络直接输出方向盘角度和加速度。画面进、动作出，中间不显式做「认车、猜别人、算路」。

·UniAD 在一套统一的鸟瞰图（BEV）上，同时做检测、跟踪、轨迹预测和规划，并且用「规划好不好」反传，让前面几项为「规划好不好」服务，而不是各干各的。相当于「先理解再决策」，而不是单纯模仿人的动作。

下面这张图把「无保护左转」场景和三种架构的对比画在一起，方便你一眼看出差异：

无保护左转场景与三种架构对比

同一个左转场景，三种系统三种做法。 差别不只在于谁更快更稳，更在于它们对「智能」的假设不一样：有的信规则和分解，有的信数据和端到端，有的信联合建模和因果理解。顺着这三条线，下面用十个有代表性的开源仓库，把各自阵营说清楚。

2.2 十个仓库怎么归类

按「模块化、端到端、统一理解」三条线，下面把文中涉及的十个仓库做个归类，并简要说明各自在对应路线里的角色和特点。你不需要记住每个仓库的算法细节，先建立「这条线里都有谁、各自干什么」的直觉就够了。

模块化工程派（教机器「规则」）

这一类把「开车」拆成感知、预测、规划、控制几步，用规则和代价函数把人类的安全驾驶经验编码进去，交给各模块执行。代表仓库：

Apollo（百度）百度 L4 全栈平台，感知–预测–规划–控制流水线非常清晰，强依赖高精地图和自家通信框架（Cyber RT）。思路就是任务分解 + 规则编码：人类把「怎么开车才安全」总结成规则和代价函数，工程师写成算法，各模块按接口串起来执行。感知用激光雷达和相机做检测与融合，预测做轨迹预测，规划在参考线上做路径和速度决策，控制做轨迹跟踪。文档和生态都比较成熟，想深入可以看《Apollo 核心模块详解》。

OpenPCDet激光雷达 3D 检测工具箱，不做规划和控制，是模块化感知的「底座」：很多经典 3D 检测算法都在里面实现，常被 Apollo 等系统当感知子模块的数据源，适合做算法验证和对比。

与模块化相对，端到端一派把「模仿人开」放在首位：不显式拆感知、预测、规划，而是用数据驱动一个网络从图像到控制量，依赖大规模人类驾驶数据做行为克隆或强化学习。

端到端数据派（让机器「模仿」）

这一类不拆「认、猜、算路」几步，而是让一个网络从画面直接学到动作，靠数据规模和质量迭代。代表仓库：

openpilot（comma.ai）L2 辅助驾驶，输入是前置摄像头图像序列，输出是方向盘和油门/刹车。核心是一个端到端网络（业内常叫 supercombo），从大约百万英里人类驾驶数据里做行为克隆，不做显式的感知–预测–规划拆分。支持 300+ 车型，靠众包数据和 OTA 迭代。思路就是把驾驶当成「图像 → 控制」的一道大题，让网络自己学。

BEVFormer把多路相机画面变成一张「从正上方往下看」的鸟瞰图（BEV），是端到端感知里很关键的一步：后面检测、分割甚至规划都能在这张图上做。它本身偏感知模块，但给「端到端」搭了从图像到结构化空间表示的桥，UniAD 等常用它做前端，也是很多 BEV 工作的基础实现。

再往上走一层，是「统一理解」：在共享鸟瞰图上联合做检测、跟踪、预测和规划，用规划损失反传，并显式建模意图与交互，让系统「先理解再决策」而不是单纯模仿人的动作。

统一理解派（机器开始「理解」）

这一类在共享表示上联合多任务，用「规划好不好」反过去驱动前面的检测和预测，更接近因果与交互理解。代表仓库：

UniAD（CVPR 2023 Best Paper）规划导向：在统一鸟瞰图上联合做检测、跟踪、轨迹预测和规划，用规划损失反传，让感知和预测为规划服务。思路是显式建模意图、轨迹和交互，做因果理解再决策，而不是单纯模仿人的动作。在 nuScenes 规划任务上，规划误差和碰撞率等指标明显好于传统模块化方法（如 ST-P3）。

TransFuser多模态（相机 + 激光雷达）融合的端到端驾驶模型，输出一般是「未来轨迹点」（waypoints），再交给传统控制器执行，算「半端到端」：保留轨迹点这种中间表示，既享受端到端表示学习，又保留可调试、可合规的接口。在 CARLA 等闭环评测里，复杂路口和动态障碍物场景表现不错。

基础设施

除了上面按路线归类的仓库，还有一批基础设施级的开源项目，做算法的人多半会碰到：

·CARLA / AirSim：提供仿真环境和闭环评测（如 CARLA 排行榜），用来验证算法、做回归测试和打榜，是研究和工程里常用的仿真底座。

·Waymo Open Dataset：大规模真实路采数据和 3D 标注，感知和预测评测的常用基准，很多论文和仓库都用它做对比。

·OpenDriveLab 生态：覆盖世界模型、视觉–语言等方向（如 GAIA-1、DriveLM），偏「下一代」理解和生成，适合关注前沿的人跟进。

2.3 从现象到问题

上面可以看到，同样叫「自动驾驶」，Apollo、openpilot、UniAD 走的是三条路：规则驱动、数据驱动、联合优化与因果理解。 于是问题自然就来了：

这三代范式的本质区别到底是什么？又是什么在推动范式演进？ 要回答这些，不能只停留在「谁用了什么模型」，而得看它们在同一场景下怎么工作、性能上限和数据依赖各是什么；只有把这些拆开，选型和落地时才有依据。

因此下一部分就从「同一场景、不同解法」切入，把技术层拆开讲：在同一道无保护左转的题上，Apollo、openpilot、UniAD 分别怎么解？从输入到输出，数据流和决策逻辑各长什么样？

三、同一道题，三种解法：技术层在做什么

3.1 同一场景，不同解法

仍以城市复杂路口无保护左转为例：有行人、对向来车、交通灯，系统要在满足安全约束的前提下择机完成左转。下面分别看 Apollo、openpilot、UniAD 在这道题上怎么解，从输入到输出把数据流和决策逻辑捋一遍。

Apollo 的模块化流水线

Apollo 最新版本（Apollo 11.0）采用四层开放平台架构：硬件设备平台、软件核心平台、软件应用平台、云端服务平台。其中「认、猜、算路、跟住」对应的感知、预测、规划、控制位于软件核心平台的应用层。下图即为 Apollo 11.0 的模块化架构示意（自上而下：工具服务、通用应用软件、软件核心、硬件设备；含定位、感知、预测、规划、控制及 Cyber RT、RTOS 等）。

Apollo 11.0 开放平台架构

下面用简化流程图概括该架构与模块化流水线的关系（官方文档见 Apollo 开放平台架构）。

Apollo 的做法可以概括成一句话：把「开车」拆成四步——先「认」、再「猜」、再「算路」、最后「跟住」。每一步都有明确的输入和输出，像流水线一样串起来：激光雷达和相机先认出「谁在哪、多大、往哪动」，预测再猜「别人接下来几秒会怎么动」，规划再算「我该走哪条路径、什么速度」，控制最后让车按这条路径和速度执行。高精地图和定位会参与「认」和「算路」，相当于事先告诉系统车道、红绿灯在哪，减轻感知和规划的负担。

·第一步：感知（认）用激光雷达、相机、毫米波雷达等传感器，先各自识别周围的车辆、行人、红绿灯、车道线等，再把多传感器的结果对齐、合并，得到一张统一的「障碍物名单」：谁、在哪、多大、朝哪、速度大概多少。红绿灯和车道线会结合高精地图做定位（例如地图里标了红绿灯位置，相机只需在对应区域识别灯色）。这一步的输出，就是后续「猜」和「算路」的输入。

·第二步：预测（猜）根据当前看到的障碍物名单和自车状态，判断周围车和人「接下来几秒可能会怎么动」：是直行、转弯、减速还是变道？系统会给出多条可能的轨迹，并给每条一个概率。例如在路口，对向车可能直行也可能左转，预测模块会输出「直行 70%、左转 30%」这类结果，供规划使用。输出的是带概率的未来轨迹，给下一步「算路」用。

·第三步：规划（算路）在「参考线」（通常由导航路线 + 高精地图车道线得到）的基础上，结合预测结果和交通规则，算出一条本车要走的路径和速度曲线：什么时候加速、什么时候减速、在哪并线、在哪避让。会按场景选择不同的规划策略（例如跟车、变道、路口通过、靠边停车等）。输出的是「路径点 + 速度 + 时间」的一条轨迹，给控制去跟。

·第四步：控制（跟住）根据规划好的轨迹，计算方向盘该转多少、油门/刹车该踩多少，让车实际按这条轨迹跑。横向（转向）和纵向（加速/制动）会分别控制，复杂情况下还会考虑执行器极限和道路边界，尽量跟得稳、跟得准。输出的是最终给执行器的指令。

简单总结：优点是每一步都可单独调试、单独换算法，出问题时也容易查是「认错了」「猜错了」还是「路算错了」，可解释性和可维护性都比较好；代价是前面任何一步有误差，都会传到后面，而且四步之间的接口设计（传什么、怎么传）本身就很费劲，高精地图的制作与更新也是一笔不小的成本。

下面看端到端路线在同一场景下是怎么做的。

openpilot 的端到端

openpilot 的做法可以概括成一句话：摄像头拍到的画面，直接交给一个大网络，网络输出方向盘该转多少、油门/刹车该踩多少。中间不显式做「先认车、再猜别人怎么动、再规划路径」这几步，而是让网络自己从数据里学出一套「画面 → 动作」的映射。其端到端架构可概括如下（传感器 → 模型推理 → 控制输出，单一大网络即业内常称的 supercombo）。

openpilot端到端架构图

·输入：车前摄像头最近大约 1 秒的连续画面（具体多少帧、多长由配置决定）。                

·网络在干什么：先把每一帧画面压成一组「特征」，再把多帧在时间上拼在一起，得到「当前这一刻」的一种内部表示，最后从这个表示直接算出方向盘角度和加速度（或油门/制动）。整条链路就是一个大网络，业内常叫它 supercombo。                

·怎么训练：用大量人类开车时的「画面 + 当时的方向盘/油门动作」当训练数据，让网络学会「在这种画面下，人通常会怎么开」，也就是模仿人类驾驶（行为克隆）。不需要事先标出「哪里有车、车会往哪走」这类中间结果，只要画面和人的动作就够了。                

·怎么上车：一个模型就能跑，部署在车里的计算芯片上，算得快、成本可控，适合 L2 辅助驾驶这类量产场景。

简单总结：优点是整条链路简单、没有「前面算错后面跟着错」的串联误差，完全靠数据驱动，数据越多越能迭代；缺点是对外像个黑盒，单次「为什么这么开」很难说清，而且非常依赖数据量和数据质量，出了事故要追责时也比较难解释。

第三种路线则试图在「可解释的中间表示」和「端到端优化」之间取平衡：保留鸟瞰图、检测框、轨迹等人类能看懂的表示，同时又用「规划好不好」反过去调前面的认车、跟车、预测，让整条链路为「最终开得好」服务。

UniAD 的规划导向统一框架

UniAD 的做法可以概括成一句话：在一张统一的「鸟瞰图」上，同时做认车、跟车、猜别人怎么动、算自己怎么走，并且用「规划好不好」反过去调整前面的认车、跟车和预测。和 Apollo 的「四步流水线」不同，这里认、跟、猜、算是在同一套表示上一起做的，而且训练时会强调「最终规划要安全、合理」，让前面的检测和预测都为这个目标服务；和 openpilot 的「一个网络到底」也不同，这里仍然有明确的鸟瞰图、检测框、轨迹等中间结果，人类能看懂、能调试。其系统架构可概括如下（多视角 → 统一 BEV → 多任务联合 → 规划输出，规划损失反传至前端任务）。

UniAD架构图

·输入：多路相机拍到的环视画面（也可以扩展激光雷达等）。                

·先变成一张「鸟瞰图」：把多路画面通过神经网络转换成一张从正上方往下看的「鸟瞰图」表示，这样后续的认车、跟车、预测、规划都在同一张图上做，信息共享、坐标统一。这一步业内常叫 BEV（Bird’s Eye View，鸟瞰图），很多新架构都会用。                

·在鸟瞰图上同时干四件事：

o认车：在鸟瞰图上检测出车辆、行人等，得到 3D 框（谁、在哪、多大）。                

o跟车：把前后帧的检测结果关联起来，知道「这一帧的车」和「上一帧的车」是不是同一个，形成轨迹 ID。                

o猜别人怎么动：对每个跟到的目标，预测它未来几条可能的轨迹及概率（类似 Apollo 的预测，但和检测、规划在同一套网络里）。                

o算自己怎么走：以自车为视角，在鸟瞰图和预测结果的基础上，生成本车的规划轨迹（路径 + 速度）。                四件事共享同一张鸟瞰图，数据互通；训练时还会用「规划好不好」（例如是否碰撞、是否合理）来反传梯度，让前面的认车、跟车、预测都往「有利于规划」的方向优化，所以叫「规划导向」。                

·输出：规划轨迹（以及检测框、预测轨迹等中间结果），可以接到仿真里评测，也可以接到下游控制器执行。

简单总结：优点是「认、跟、猜、算」联合优化，规划直接约束前面的检测和预测，更接近「先理解场景再决策」，在 nuScenes 等规划评测里指标也明显优于传统模块化方法；缺点是训练和工程复杂度高，对算力和数据要求都高，目前仍以学术界和头部团队为主，量产案例还不多。

讲完三种解法各自怎么工作，再拉高一层，看它们在性能上限和数据依赖上的差异：为什么模块化容易在长尾上吃亏，端到端为什么又特别吃数据。

3.2 性能上限

模块化时，感知、预测、规划各自 98%、97%、99% 准确率，串联下来整体大约 0.98×0.97×0.99 ≈ 94%。更麻烦的是长尾：每个模块都在「常见场景」上优化，罕见组合（Corner Case）容易在接口或假设不一致的地方暴露。比如感知在遮挡下只给出「半辆车」，预测若假设输入是「完整目标」，就会得到错误意图和轨迹，规划跟着错。

反过来，端到端优化的是「图像 → 决策」的全局映射，中间表示不必和人类概念一一对应，在长尾和极端场景有时反而更稳。openpilot 在百万英里级数据里见过大量遮挡、光照、天气变化，学的是「安全驾驶行为」而不是「先检测全所有车再规划」。CARLA Leaderboard 上 TransFuser 等端到端/混合方法在复杂交互场景的分数常高于传统模块化 baseline；UniAD 在 nuScenes 规划任务上 L2 error 和碰撞率也明显优于模块化方法。

这里一句话概括下：模块化优化的是各子任务的平均表现，误差会串联；端到端优化的是整体任务在极端和长尾上的鲁棒性，但依赖大规模高质量数据。统一框架在理论上兼有「可解释中间表示」和「联合优化」的好处，实际能发挥多少还取决于工程化和数据效率。

性能之外，三种路线对数据的要求也各不相同：有的依赖高精地图和规则，有的依赖众包驾驶数据，有的理论上更省数据但训练成本未必低。

3.3 数据依赖

Apollo（模块化） 依赖规则和高精地图。地图把静态环境事先告诉系统，感知只需盯动态障碍物，难度下来一截，对「有多少车、多少车道、红绿灯在哪」这类信息不用完全从零学。代价是地图制作和更新贵、无图区域跑不了、施工和标线一变地图就滞后，拓展新区域和新国家的成本不低。

openpilot（端到端） 依赖众包和数据规模。用户车采的数据（如 comma 设备）形成数据飞轮，百万英里、多车型多地区，长尾场景会自然出现在数据里。代价是数据质量参差（含不良驾驶）、需要强清洗和主动学习 pipeline，冷启动也要相当规模的种子数据，否则模型在边缘场景容易崩。

UniAD（统一框架） 理论上多任务共享表示应该更「省数据」，但实际在 nuScenes 上往往要更长训练和更多 GPU，原因包括联合优化搜索空间大、标注更细（不止 3D 框，还有轨迹和意图等）。也就是说，学术上的优雅不一定直接变成工程上的省数据、省算力，选型时要结合团队的数据和算力现实来看。

3.4 技术层小结

综合来看：模块化用规则和地图降低对数据的依赖，但性能受接口设计和误差串联限制，长尾场景要靠不断补规则；端到端用数据和整体优化冲高上限，但对数据规模和质量依赖大，可解释性弱，监管和事故归因时会比较被动；统一框架在理论上兼有「可解释中间表示」和「联合优化」的好处，实际能发挥多少还取决于工程化和数据效率。这些技术选择背后，还有一层认识论和伦理问题：归纳与演绎、可解释与性能的权衡，会直接影响产品形态和监管态度。顺着这条线，下一部分从哲学和认知角度简单捋一捋。

四、规则还是数据？演绎与归纳背后的技术信仰

4.1 两种认识世界的方式

为什么 Apollo 更信「规则」、openpilot 更信「数据」？背后其实是人类认识世界的两种方式：演绎和归纳。这一段用最直白的话说清楚这两种方式是什么，以及它们在自动驾驶里长什么样。

演绎：从「一般规则」推出「具体结论」。先定好规则，再按规则推理。哲学里常说的理性主义（如笛卡尔、康德）就是这一路。在自动驾驶里，对应的是：人类把「怎么开车才安全」总结成规则和代价函数，工程师把它们写成算法，车按这些规则执行。Apollo 的规划和决策逻辑就是这一套——先认车、再猜别人怎么动、再按规则算路径，每一步都有「为什么这么干」的条文可依。

归纳：从「大量现象」里提炼「统计规律」。先看很多例子，再从例子里归纳出规律，下次遇到类似情况就按这个规律来。经验主义、贝叶斯那套思路属于这一类。在自动驾驶里，对应的是：收集大量人类开车时的「画面 + 动作」数据，让神经网络自己学出一套「在这种画面下，人通常会怎么开」，再泛化到新场景。openpilot 就是这一套——不手写「该什么时候转弯、什么时候刹车」，而是让网络从数据里学。

下面这张表把两种方式对比一下，方便你一眼看出差异：

这两种思路在自动驾驶里的具体落地，又和过去十几年「深度学习」这场革命的节奏密不可分。下一段就捋一捋这段历史。

4.2 深度学习革命的缩影

自动驾驶的三种路线，不是凭空来的，而是过去十几年「视觉 + 深度学习」这场革命在驾驶领域的延伸。这一段简单捋一捋这段历史，你就更容易理解：为什么有的公司更信规则，有的更信数据。

从「人设计怎么看」到「让数据学怎么看」。大约 2012 年以前，做视觉识别主要靠「人设计特征」：工程师先想好「机器该看哪些线条、哪些纹理」（业内常说的 SIFT、HOG 就是这类手工特征），再交给一个简单的分类器去判断。2012 年 AlexNet 出来之后，大家发现：不用人设计「看什么」，只要给网络大量标注好的图片，它自己能学出一套「看什么」。特征变成数据驱动的、整条链路可以端到端训练，效果还更好。于是「认东西」（检测）、「抠轮廓」（分割）、「跟住目标」（跟踪）等任务，陆续被深度学习重塑，准确率大幅提升。

从「只做感知」到「感知 + 决策 + 规划」一起学。再往后，端到端不再只用在「认东西」上，而是从「画面进 → 动作出」整条链路一起学，也就是从感知蔓延到了决策与规划。自动驾驶、机器人都在往这个方向走。但自动驾驶行业大规模拥抱「端到端」，比别的领域晚一些，原因也不难理解：安全和监管对「能不能说清为什么这么开」要求高、传统车企习惯先做感知再手写规划、早期也缺百万英里级的大规模驾驶数据。所以很长一段时间里，主流是「用深度学习做感知，用规则做规划」——也就是 Apollo 那套。

谁先证明「端到端」在车上可行？Tesla 和 comma.ai 通过真实车队和众包数据，把「画面 → 方向盘/油门」的端到端模型真的跑上了路，在 L2 辅助驾驶场景证明了：不手写规划模块，神经网络也能学会「怎么开」。近几年，BEV（鸟瞰图）等表示又把多路相机画面统一成一张「从正上方往下看」的图，让「图像 → 规划」在结构上更顺了，UniAD 这类统一框架才得以兴起。所以粗略说：Apollo 是「用深度学习认路、认车，用规则算路径和决策」；openpilot 是「整条链路端到端，把驾驶当成『画面进、动作出』的一道大题」。

comma.ai 创始人 George Hotz 有一句话点得很透：传统自动驾驶公司是在用 2010 年的 AI 思路解决 2020 年的问题——他们不相信神经网络能学会「规划」，所以非要手写规划模块；但 Tesla 已经证明，端到端是可以 work 的。这句话背后，其实就是「演绎 vs 归纳」「规则 vs 数据」在产业里的真实碰撞。

演绎与归纳、规则与数据，一旦落到产品与监管，就会碰到一个绕不开的问题：可解释性。用户、监管和法院都会问：车为什么这么开？出事了责任怎么划分？这就把技术路线和伦理、法规绑在一起了。

4.3 可解释性的伦理困境

规则也好、数据也好，一旦车真的上了路，就会碰到一个躲不掉的问题：出了事，怎么说得清「车为什么这么开」？ 这就是可解释性带来的伦理困境。用户会问、监管会问、法院也会问：责任怎么划分？所以技术路线和伦理、法规是绑在一起的。

模块化：能一步步往回查。因为每一步都有明确输入输出，出事后可以回溯：感知当时检测到了谁、置信度多少，预测认为对方会怎么做，规划选了哪条轨迹、依据哪条规则。这样就能定位问题出在哪一环节——是「认错了」（漏检、误检）、「猜错了」（预测偏差），还是「路算错了」（规划逻辑有问题）。对外也比较好解释：「当时系统认为对方会直行，所以选择了这条轨迹。」责任认定和事故分析都有据可查。

端到端：很难说清「这一帧为什么这么开」。输入是像素，输出是方向盘和油门，中间是一大堆网络权重。你很难用人类语言解释「这一帧为什么要左打 3 度」——没有显式的「检测到谁、预测对方会怎样、依据哪条规则」。辩护往往只能靠统计：例如「在百万英里测试里，事故率低于人类驾驶员」。但单次事故仍然给不出「因为 A 所以 B」的因果解释，监管和公众很难满意。欧盟 GDPR 等法规对「算法决策可解释性」有要求，这类争议会长期存在。

核心问题：能不能为「统计上更安全、但单次不可解释」的系统开绿灯？没有标准答案。有的地区更看重「能说清」，有的更看重「整体更安全」。但这个问题会持续影响技术选型和产品形态，做技术决策时有必要提前想清楚：你的场景、你的用户、你的监管环境，更接受哪一种。

4.4 哲学层小结

哲学层捋完，可以收个口：演绎和归纳各有天花板，历史也证明没有银弹，所以选型时要看清自己更在意什么。

演绎的天花板： 想靠「所有情况都有规则」做到逻辑完备，在开放世界里不现实——路况千变万化，规则写不完，总有没覆盖到的场景。              归纳的天花板： 想靠「大数定律下整体更安全」做到统计鲁棒，可以，但个体行为仍难预测，单次事故仍难解释，监管和公众会追问「这一次为什么这么开」。

历史已经表明：早年依赖规则的专家系统，因为规则无法穷举而在复杂场景里遇挫；今天的深度学习，也面临「没见过的场景」（分布外）和对抗样本等问题。所以结论只能是：没有普适的最优范式，只有和场景、监管、成本相匹配的选择。 选型时不妨想清楚：你更在意可解释性（出了事能说清）、性能上限（开得更好），还是落地成本（数据、算力、地图）？想清楚这一点，再去看模块化、端到端、统一框架，就更容易做取舍。

说完哲学根源，下一部分回到技术前沿：第三代「统一理解」和未来几年可能怎么走。

五、统一理解、世界模型与仿真：未来往哪儿走

前面把三种路线的「是什么、怎么工作、优缺点」都捋了一遍。这一部分往前看几步：第三代「统一理解」会怎么走？在「纯模块化」和「纯端到端」之间还有没有折中？再往后，世界模型、仿真与评测又会扮演什么角色？ 不求预测准，只求帮你建立一个「未来几年可能怎么变」的直觉，方便选型和规划时心里有数。

5.1 UniAD：规划导向的统一框架

UniAD 代表的「统一理解」路线，不是简单把 Apollo 那四步串起来，而是用「规划好不好」反过去驱动前面的认车、跟车和预测。在统一鸟瞰图上同时做检测、跟踪、轨迹预测和规划，训练时把「规划质量」的权重加大，让前面的任务都为「最终开得好」服务，并且显式建模「我这么走，对方会怎么反应」——更接近「先理解再决策」，而不是单纯模仿人的动作。

和 openpilot 比，差在哪？openpilot 学的是「像人那样动」：画面进、动作出，模仿人类驾驶。UniAD 学的是「在给定场景理解下，怎样规划更安全、合理」：先有鸟瞰图、检测框、轨迹这些表示，再在这些表示上算路径，并且用规划损失反传，让前面的表示为规划服务。所以更接近因果与交互理解，而不是纯行为克隆。

指标上有没有优势？在 nuScenes 规划 benchmark 上，UniAD 和传统模块化方法（如 ST-P3）的对比大致如下：

规划误差更小、碰撞率更低，说明「规划反传 + 联合优化」在规划质量上是有优势的。当然，这是特定数据集和评测设置下的结果，落地时还要看工程化和数据效率。

在「纯端到端」和「模块化」之间，还有一种折中思路：不直接出方向盘和油门，而是出「未来轨迹点」，再交给传统控制器去跟。这样既享受端到端的表示学习，又保留可调试、可合规的接口。TransFuser 就是这一类。

5.2 TransFuser：混合架构的中间道路

TransFuser 的做法可以概括成一句话：网络不直接输出「方向盘转多少、油门踩多少」，而是输出「未来一段时间车该经过哪些点」（业内常叫 waypoints），再交给成熟的控制算法去跟踪这些点，得到最终的转向和油门。 相当于「半端到端」：前半段用神经网络学表示和轨迹，后半段用传统控制，兼顾性能和可解释性。

为什么不全出控制量？作者提到的一个原因是：直接出控制量对数据质量和规模要求极高，稍有不稳就容易抖；出轨迹点更稳，而且能和现有控制器、合规流程对接，方便调试和量产。所以在需要和车企现有系统对接、或者对「可解释、可审计」要求高的场景里，这种折中往往更现实。

在评测里表现怎样？在 CARLA 仿真排行榜的 Longest6 等设置里，TransFuser v6 的「路线完成度」约 84%、「违规得分」约 0.71，优于传统模块化方法（约 61%、0.52）；复杂路口和动态障碍物场景表现不错。但在极端天气等「没见过的场景」里，仍会暴露数据不足的问题。所以当前阶段，「半端到端」——保留部分可解释的中间表示，同时享受端到端表示学习——可能是工业落地的一种务实选择，尤其在需要和现有控制器、合规流程对接的场景里。

再往前看，还有一个方向值得关注：世界模型——不再只「反应」当前看到的东西，而是在「想象」里先试几种动作、再选最优，更接近人类「在脑子里试一遍再动」的决策方式。

5.3 世界模型：下一个前沿

目前主流系统（Apollo、openpilot、UniAD）大多是反应式的：看到什么就根据当前观测做决策，很难在「脑子里」先推演多种未来、再选一条。世界模型的愿景是：学一套「环境怎么变」的规律（给定当前状态和动作，预测下一时刻会变成什么样），然后在「想象」里试不同的动作、看会带来什么结果，再选一条最优的。相当于「先想再动」，而不是「看到就动」。

谁在做？做到哪一步了？OpenDriveLab 等团队在做的工作包括：GAIA-1 等生成式世界模型（给定当前帧和动作，预测未来几帧会变成什么样，用于数据增强和仿真）；DriveLM 等视觉–语言模型（用自然语言解释「车为什么这么开」，提升可解释性）。目前仍以研究和原型为主，离大规模上车还有距离。

挑战在哪？算力和数据需求大、长期预测误差会累积（想象得越远，偏差越大）、生成质量和真实性难客观评测。所以短期（2–3 年）里，UniAD 这类统一框架可能在学术界占主流；中期世界模型 + 强化学习（在「想象」里练策略）可能突破；更长期则可能由多模态、多任务的大模型带来新一轮范式变化。时间尺度不必较真，重要的是：世界模型代表的是「先想再动」的方向，和当前「看到就动」的反应式系统形成对照。

讨论未来推演时，离不开一件事：算法好不好，总得有个可重复、可对比的尺子。 这就是仿真与评测环境扮演的角色。

5.4 CARLA 与仿真的角色

仿真（如 CARLA、AirSim）提供安全、可重复的评测环境：同一套场景可以反复跑、不同算法可以用同一把尺子比，很多论文和比赛都基于它们做对比。所以仿真是算法迭代和排行榜的基础设施，也是「理解算法、验证想法」的加速器。

但仿真不能替代真实道路。sim-to-real gap（仿真和现实的差距）一直在：在 CARLA 里表现好，不等于在真实道路同样可靠。光照、材质、行人行为、车辆动力学都和真实世界有差距，有些在仿真里见不到的极端情况，上了路才会暴露。所以仿真适合做快速迭代和对比实验，最终还是要到实车和真实路况上去闭环验证。

各家怎么用仿真？Apollo 重度用仿真做回归测试和场景回放（同一批场景反复跑，看改版后有没有退步）；openpilot 更依赖真实路测和影子模式（在真人开车时后台跑算法、对比人的决策）。没有谁对谁错，取决于产品阶段和资源：前期可以多靠仿真快速试，后期要加大真实路测和闭环。

一句话： 仿真是理解和迭代的加速器，但不能完全替代真实数据的验证；算法好不好，最终还是要到实车和真实路况上去看。

5.5 未来推演小结

三种路线在未来几年可能怎么走？下面这张表给一个粗线条的概括，方便你建立直觉（不必较真时间点）：

开放问题仍不少。 监管能否接受「统计上更安全、但单次不可解释」的系统？世界模型能否突破算力和长期预测的瓶颈？开源与闭源的数据闭环会怎么演化？这些短期内不会有定论，但会持续影响技术选型和产品节奏。

六、三条路，三次追问

从架构图到同一个左转场景，从十个仓库到认、猜、算路、跟住的技术拆解，从「规则还是数据」的哲学追问到可解释性的伦理困境，再从 UniAD、世界模型到仿真与未来——这篇文章把自动驾驶的三种范式捋了一遍。它们不是谁取代谁的关系，而是「在什么场景下、更信什么」的选择：有的信规则与分解，有的信数据与端到端，有的信联合建模与因果理解。开放问题还在，监管、算力、数据闭环会持续塑造行业走向；但有一点可以确定：自动驾驶的三次范式演进，也是人类对「智能」这一概念的三次追问——从「教规则」到「让模仿」再到「促理解」。 看清这三条路，不是为了押注单一答案，而是为了在变化里少一点盲目、多一点从容。

三条路各自都还有不少可以单独深挖的空间——无论是模块化里的 Apollo 与高精地图、端到端里的 openpilot 与数据飞轮，还是统一框架下的 UniAD 与世界模型。若读者对某一条路特别有共鸣或想看得更细，日后或许会视情况，考虑就单条路线再写一写、做更细的展开；若这篇梳理对你有一点用，也权当一份小小的参考，能传阅给同好就更好。

参考文献与延伸阅读

·论文：UniAD: Planning-Oriented Autonomous Driving (CVPR 2023); BEVFormer: Learning Bird’s-Eye-View Representation from Multi-Camera Images (ECCV 2022); TransFuser: Imitation with Transformer-Based Sensor Fusion (PAMI 2023)。

·开源与文档：Apollo Architecture Design；openpilot Technical Overview；CARLA Documentation。

·行业观点：George Hotz (comma.ai) 推特/博客；Andrej Karpathy (Tesla AI) 技术分享；Waymo/百度技术博客。

·本仓库参考：《Apollo 核心模块详解》；《自动驾驶评估标准在实际应用中的具体体现与优化方向深度分析报告》；《自动驾驶领域模型评估方法综合分析报告》。

·评估与基准：nuScenes Detection Score (NDS)、Planning L2/Collision Rate；CARLA Leaderboard 2.0 Driving Score；Waymo APH、TTC/RSS 等安全指标。