先说清楚整台车要完成什么,再谈任何一个算法。否则你学到的是零件,不是机器。
从一个路口开始
雨后傍晚,你的车在支路上,前方 80 米的路口要右转,汇入车流不断的主路。
接下来十几秒,车要依次回答五个问题,这也是后面几章的顺序:
- 我在哪条车道,该汇入哪条?——第 2 章 · 定位、地图与导航
- 周围有什么?——第 3 章 · 感知与场景表征
- 它们接下来会怎么动?——第 4 章 · 预测
- 现在该等,还是该走?——第 5 章 · 决策
- 要走的话,走哪条线、开多快?——第 6 章 · 规划与轨迹生成(控制接口)
最后两章把这几步合起来看:
- 第 7 章 · 从模块化到端到端及 IL/RL 训练:端到端怎么把这几步合到一起;
- 第 8 章 · 评测、量产与数据闭环:怎么证明车真的会开,出了问题怎么改。
这个路口会跟着我们走完全程,路上的麻烦到了对应的章节再登场。
这一章先不讲算法,只做一件事:把整台车的任务和信息流摆上桌面,让后面每一章都知道自己在哪、接谁的输入、交付给谁。
任务是什么:四个要求,互相打架
自动驾驶的任务不是“识别更多目标”,而是把人从 A 点送到 B 点。对规划输出的轨迹,一种常见的归纳是四条要求:
- 驾驶安全:不撞;
- 符合交规:不违章;
- 体感舒适:不顿挫;
- 高效便捷:不磨蹭。
这四条常常互相牵制。一辆在路口永远等到主路完全清空才汇入的车,前三条满分,效率为零——乘客会骂,后车会按喇叭。所以自动驾驶工程说到底,是在这四个目标之间做带约束的权衡。后面很多设计争论,比如保守还是激进、靠规则还是靠学习,最后都落在这四条的取舍上。
任务成立还有一个前提,叫 ODD(运行设计域):系统设计时限定的道路和环境条件,比如哪些道路、什么天气和光照、多高的车速。超出这个范围,系统就不该启用;快要越界时,要么请人接管,要么自己把车停到安全状态。这条主线里它只作背景,记住这个词就够。
管线:信息从哪进,沿哪流,交给谁
从工程上看,车上的系统是一条流水线:信息从传感器进来,一环接一环往下传,最后变成方向盘和油门刹车上的动作。
- 输入传感器
- 第 2 章定位导航
- 第 3 章感知
- 第 4 章预测
- 第 5 章决策
- 第 6 章规划
- 输出控制
每一环都有明确的上游输入和下游交付物。这个“接口”视角是整条主线最重要的习惯:评价任何模块,先问它消费什么、交付什么,再问它内部用了什么算法。一个模块离线指标再漂亮,如果输出的格式、时序或坐标系下一环接不住,对整车就毫无价值。
还有一件事,这条流水线画不出来:交互。设想一辆车要汇入主路,它通常分三步:
- 没人让路时,一边试探着靠近,一边准备随时退出;
- 后车减速让行,开始并入;
- 完成汇入。
驾驶决策不是一次算出答案,而是在别人怎么反应还不确定时,边试探边调整。记住这个画面:第 4 章的交互预测,和第 5 章“看不全也得做决定”的决策方法(POMDP),都从这里出发。
两种造法:规则栈与学习栈
同一条管线,行业里有两种典型造法。把两张公开的系统架构图放在一起看,差别很清楚。注意这是两个时间点上的示例:Apollo 是 9.0 版的四层架构图,Tesla 是 2022 年 AI Day 上的 FSD 总览图,那时已有占据网络,规划仍单独成块。
多模块 · 规则规控
百度 Apollo
- 四层:硬件设备、软件核心、应用软件、工具服务
- 地图引擎、定位、感知、预测、规划、控制各是一个独立模块
- 每个模块单独设计、调试、迭代,模块之间靠定义好的接口通信
少模块 · 神经网络为主
Tesla FSD
- 图上只有寥寥几块:一组神经网络往上交给规划,两侧是训练基础设施和 AI 编译与推理,底下是训练数据
- 神经网络统一完成感知,输出占据栅格和车道、目标;这张图上规划还单独成块
- 工程重心在数据:自动标注、仿真、数据引擎
中间的差别是:几十上百个人工设计的模块,还是一张(或几张)神经网络。但这里其实有两条轴,别混成一条:
- 架构:切不切成模块,模块之间用什么接口;
- 组件:每一块主要靠规则还是靠学习。
模块化的系统里照样可以有大量学习组件,端到端系统外面也照样有规则和验证层。
下文的“规则栈”,指感知之后的决策规划主要靠工程师写规则的传统做法;“学习栈”,指从感知到规划主要靠数据训练。这是两种做法的简称,不是给公司贴的标签。公司的方案一直在变:比如 Waymo 2025 年底公开的架构,组件之间用学习出来的嵌入作接口,训练时可以端到端回传,同时保留物体、语义属性、道路图元这类紧凑的显式结构;生成式模型出轨迹后,还要过一层独立的车载验证。Waymo 自己说,它比纯端到端和纯模块化都好。Tesla 还在往更彻底的方向走:感知之后,规划也逐步交给网络;到 2025 年,它公开的方向已是一张大模型直接输出下一步驾驶动作。
行业的方案代际,大致也沿着这条线演进:
- 到 2021高精地图地图里存好静态环境
- 2022BEV 无图多路相机融合成鸟瞰图
- 2023Occupancy认出不规则的障碍物
- 2024端到端模型直接出短时轨迹
- 2025VLA看和做之间用语言搭桥
这几个词在术语图鉴里都有详解:BEV、Occupancy、端到端、VLA。
这条主线的读法是:第 2–6 章沿模块化管线走。不是因为模块化更先进,而是每个模块都对应驾驶里一个绕不开的子问题:定位、感知、预测、决策、规划。架构换成端到端,这些问题不会消失,只会换一种方式被解决。第 7 章回头看端到端怎么重组这条管线,第 8 章看两种造法共同的终极考题:怎么证明车真的会开。
这一环容易出错
从管线的角度看,最常见的系统性错误有三类:
- 只看零件,不看机器:讲一个感知或规划模型时,说不清它在整车里依赖谁、交付给谁。这样的理解是悬空的。
- 接口错配:局部模型离线得分很高,但输出的格式、时序或坐标系下一环接不住。指标好看,对整车没有贡献。
- 局部最优不等于全局最优:各模块分头优化自己的离线指标,比如检测看 mAP、预测看 minADE,却没有一起服务于“安全高效地通过这个路口”。第 7 章讲端到端时,这一条是核心论据。
接到下一环
管线讲清楚了。回到那个路口,第一个现实问题是:车怎么知道自己在哪条支路上、该在这个路口右转、要汇入的是哪条车道?答案不在传感器里,在定位、地图和导航里。下一章从手机导航屏幕上那行“85 米后通过路口”讲起。
本章速查
| 概念 | 一句话 |
|---|---|
| 任务四条 | 安全、合规、舒适、高效,常常互相牵制,很多设计争论都落在它们的取舍上 |
| ODD | 运行设计域:系统设计时限定的道路和环境条件(天气、光照、车速范围等) |
| 管线 | 传感器 →(定位导航、感知两路并列)→ 预测 → 决策 → 规划 → 控制,每环有明确的输入和交付物 |
| 接口视角 | 评价模块先问消费什么、交付什么;离线高分 ≠ 下游可用 |
| 三步并道 | 决策是边试探边调整的交互过程,不是一次性求解 |
| 规则栈 vs 学习栈 | 两种典型做法的简称:决策规划主要靠规则,还是从感知到规划主要靠数据训练;分不分模块是另一条轴;公司方案会变,不贴永久标签 |
| 方案代际 | 高精地图(到 2021)→ BEV 无图(2022)→ Occupancy(2023)→ 端到端(2024)→ VLA(2025) |
