1. 从“提前知道”到“实时感知”：自动驾驶地图依赖的底层逻辑正在被重写

如果你这两年一直在关注自动驾驶的技术演进，会发现一个非常明显的信号：越来越多的量产方案开始把“无图”或者“轻图”挂在嘴边。前几年大家还在比拼谁的高精度地图覆盖城市多、更新频率快，现在风向突然变了——地图从“必选项”变成了“可选项”，甚至在某些场景下成了“被嫌弃的对象”。这个转变不是某一家公司的营销话术，而是整个技术栈从感知到规控、从数据闭环到车端算力的一次系统性迁移。

我最早接触自动驾驶相关项目的时候，高精度地图几乎是默认的基础设施。那时候做方案，第一步就是确认地图供应商的覆盖范围，第二部才是讨论传感器配置。地图提供了车道线、路沿、交通标志、曲率、坡度等先验信息，车端感知只需要做“局部修正”就行，整个系统的负担很轻。但问题也很明显：地图的采集成本极高，更新速度永远追不上道路变化，而且一旦遇到施工、临时改道、事故管制，地图反而可能成为误导源。更关键的是，依赖地图的方案很难规模化——每开通一个新城市，就要重新采集、标注、验证，这个周期动辄数月。

现在的情况完全不同了。BEV（Bird‘s Eye View）感知架构的成熟，让车端可以在没有地图先验的情况下，直接输出一个鸟瞰视角下的道路结构、障碍物分布和可行驶区域。再加上Occupancy Network对三维空间的稠密建模能力，车辆对周围环境的理解从“平面车道线”升级到了“立体空间占用”。这意味着，即使没有任何地图信息，车辆也能知道哪里能走、哪里不能走、哪里有动态障碍物。实时感知的能力上来了，地图的角色自然就从“主导”退居到“辅助”，甚至在某些场景下可以被完全替代。

这篇文章我想从技术演进的脉络出发，拆解一下“无图化”背后的核心驱动力，包括BEV感知的原理、Occupancy Network的落地细节、数据闭环的构建方式，以及在实际项目中如何平衡地图与实时感知的权重。如果你正在做自动驾驶相关的开发、测试或者产品规划，这些内容应该能帮你少走一些弯路。

2. 高精度地图的黄金时代与它的三个硬伤

2.1 高精度地图到底提供了什么价值

在讨论“为什么不再依赖地图”之前，得先搞清楚地图曾经解决了什么问题。高精度地图本质上是一层“超视距的先验信息”，它把道路的几何结构、车道拓扑关系、交通标识位置、信号灯相位等信息提前存储在车端。车辆行驶时，通过定位模块（通常是RTK+IMU+视觉匹配）确定自身在地图中的精确位置，然后就可以“预知”前方几百米甚至几公里内的道路情况。

这种预知能力带来的好处非常直接。首先是感知压力的降低：车端摄像头和激光雷达只需要处理地图没有覆盖的动态障碍物，静态元素直接查表就行。其次是规控的稳定性：车辆可以提前知道前方有弯道、匝道、路口，从而提前调整速度和轨迹。最后是安全冗余：即使传感器短暂失效，地图仍然能提供基本的道路结构信息，让车辆保持在一个相对安全的行驶状态。

我参与过的一个园区接驳项目，早期就是靠高精度地图撑起来的。整个园区道路提前采集了一遍，车道线、减速带、停车位全部标注清楚，车端只装了一个低线束激光雷达和几个摄像头，就能跑得很稳。那时候的体验确实好，车辆行驶平顺，几乎不会出现画龙或者急刹的情况。

2.2 采集成本与更新频率的矛盾

但高精度地图的问题很快就暴露了。第一个硬伤是采集成本。一套高精度地图的采集设备包括高线束激光雷达、组合惯导、多目相机，单车成本动辄几十万甚至上百万。采集完还要经过标注、清洗、验证、编译，整个流程走下来，一个城市的地图制作周期通常在三到六个月。这还只是第一次采集，后续的更新才是真正的无底洞。

道路每天都在变。今天这里封路施工，明天那里新增了一个临时红绿灯，后天某条车道线被重新画过了。高精度地图的更新频率根本追不上这些变化。我见过最夸张的情况是，某条道路因为市政施工改道了三个月，地图上还是旧的车道线，车辆按照地图走直接冲进了施工区域。虽然安全员及时接管了，但这种案例足以说明地图的局限性。

2.3 定位依赖与场景退化

第二个硬伤是定位依赖。高精度地图的使用前提是车辆能精确知道自己在地图中的位置。但在隧道、地下车库、城市峡谷、密集林荫道这些场景下，GNSS信号要么丢失，要么多径效应严重，定位精度会急剧下降。一旦定位漂移，地图信息不仅没用，反而会误导感知和规控模块。

我印象很深的一次测试是在一个地下停车场。车辆进入地库后GNSS信号完全丢失，只能靠IMU和轮速计推算位置。但地库的坡道和弯道很多，推算误差很快就累积到了几米。结果车辆按照地图上的车道线行驶，直接压到了对向车道的车位线上。虽然速度很慢没有造成事故，但这次经历让我意识到，依赖地图的方案在封闭场景下非常脆弱。

2.4 规模化落地的经济账

第三个硬伤是经济账。假设你要覆盖全国主要城市的高速公路和城市快速路，高精度地图的采集和更新成本是一个天文数字。而且每开通一个新城市，都要重新走一遍采集、标注、验证的流程。对于车企来说，这笔钱花出去之后，用户并不会因为“地图覆盖广”就多付几万块钱。相反，如果能把地图依赖降下来，用实时感知覆盖更多场景，整车的成本结构会更健康。

这三个硬伤叠加在一起，让行业开始重新思考地图的定位。地图不应该被抛弃，但它必须从“主导者”变成“辅助者”，从“提前知道一切”变成“实时感知为主，地图兜底为辅”。

3. BEV感知：让车辆自己“看懂”道路结构

3.1 BEV视角为什么比传统视角更接近人类驾驶直觉

BEV的全称是Bird’s Eye View，翻译过来就是鸟瞰视角。传统的自动驾驶感知是在图像空间或者激光雷达坐标系下做的，摄像头看到的是透视图像，激光雷达看到的是三维点云。这些数据要经过复杂的坐标变换和融合，才能变成规控模块能用的道路结构信息。而BEV的思路是：不管传感器是什么视角，最终都统一投影到一个俯视的二维平面上，在这个平面上做感知和预测。

这个思路的好处非常直观。人类驾驶员在脑子里构建的道路模型，本质上就是一个俯视图：我知道我在哪条车道上，左边是护栏，右边是绿化带，前方路口有三条车道，其中一条是左转专用道。BEV感知就是在车端复现这个俯视图，让规控模块直接在这个平面上做决策。

我实际对比过传统方案和BEV方案的输出。传统方案的车道线检测是在图像空间做的，输出的是像素坐标下的曲线，规控模块需要先做逆透视变换才能用。这个变换过程会引入误差，尤其是在坡道和弯道上。BEV方案直接输出俯视图下的车道线方程，规控模块拿到就能用，整个链路的延迟和误差都小了很多。

3.2 BEV感知的核心技术栈拆解

BEV感知的实现路径有好几种，目前主流的是基于Transformer的架构。简单来说，它的流程是这样的：首先用CNN backbone提取多相机图像的特征，然后通过Transformer的注意力机制，把这些图像特征投影到BEV平面上。投影的过程中，网络会学习每个图像像素对应BEV平面上的哪个位置，这个学习过程是通过大量数据训练出来的。

这里面的关键点是“空间注意力”机制。传统的投影方法是基于几何的，需要知道相机的内外参，然后做射线投射。但这种方法对相机标定的精度要求极高，而且很难处理遮挡和深度不确定的问题。Transformer-based的方法不依赖显式的几何投影，而是让网络自己学习图像特征和BEV特征之间的对应关系。这样一来，即使相机标定有轻微误差，网络也能通过数据驱动的方式补偿回来。

我试过用纯几何投影的方法做BEV转换，在标定完美的仿真环境里效果很好，但一到实车就各种问题。相机震动、温度变化、镜头畸变都会导致投影误差。后来换成Transformer-based的方案，虽然训练成本高了很多，但泛化能力确实强了一个档次。

3.3 多传感器融合在BEV空间里的实现方式

BEV空间的另一个优势是天然适合多传感器融合。摄像头、激光雷达、毫米波雷达的数据都可以投影到同一个BEV平面上，然后在特征层面做融合。摄像头的优势是语义信息丰富，能识别车道线、交通标志、信号灯颜色；激光雷达的优势是深度信息准确，能精确测量障碍物距离；毫米波雷达的优势是测速直接，能穿透雨雾。

在BEV空间里做融合，比在图像空间或者点云空间做融合要简单得多。因为所有传感器数据都统一到了同一个坐标系下，融合就变成了特征拼接或者注意力加权。我实际项目中用过的一种做法是：先把摄像头特征投影到BEV平面，再把激光雷达点云也投影到BEV平面，然后在通道维度上拼接，最后用一个卷积网络做融合。这种方案在夜间和雨雾天气下的表现比纯视觉方案稳定很多。

3.4 BEV感知的局限性与当前边界

BEV感知不是万能的。它最大的局限性在于高度信息的丢失。BEV是一个二维平面，它把三维空间压缩到了二维，所以对于天桥、隧道、立交桥这种高度差异明显的场景，BEV感知很容易出现误判。比如车辆前方有一座天桥，BEV感知可能会把天桥的桥面当成路面上的障碍物，导致不必要的刹车。

另一个局限是远距离感知精度。BEV平面的分辨率是有限的，距离越远，每个像素代表的实际面积越大，感知精度就越低。目前主流的BEV方案在100米以内的感知精度可以做到厘米级，但超过150米之后，车道线的检测误差就会明显增大。

还有一个问题是算力消耗。BEV感知需要处理多相机的高分辨率图像，Transformer的注意力机制计算量很大。我实测过，一套完整的BEV感知模型在Orin芯片上跑，单帧推理时间在30到50毫秒之间，这还是在做了量化和剪枝之后的结果。如果算力不够，要么降低分辨率，要么降低帧率，都会影响体验。

4. Occupancy Network：从平面车道线到立体空间占用

4.1 Occupancy Network解决了什么问题

BEV感知输出的是二维平面上的道路结构，但现实世界是三维的。车辆不仅要关心“前方有没有车道”，还要关心“前方有没有悬空的障碍物”“路沿有多高”“施工区域的围挡是什么形状”。Occupancy Network就是为了解决这个问题而出现的。

Occupancy Network的核心思想是：把周围的三维空间划分成一个个小体素（voxel），然后预测每个体素是否被占用。这个占用信息可以是静态的，比如路沿、护栏、建筑物；也可以是动态的，比如行人、车辆、自行车。有了这个三维占用栅格，车辆就能知道哪些空间是可以通过的，哪些是必须避开的。

我最早看到Occupancy Network的应用是在特斯拉的AI Day上，当时他们展示了一个三维占用栅格的实时可视化效果，车辆周围的空间被划分成密密麻麻的小方块，每个方块的颜色代表占用概率。那个效果非常震撼，因为它让车辆对环境的理解从“平面地图”升级到了“立体沙盘”。

4.2 体素化与三维卷积的计算挑战

Occupancy Network的实现难点在于计算量。假设你要覆盖车辆周围50米的范围，分辨率做到0.2米，那么体素数量就是250×250×50，大约是300万个体素。对每个体素做三维卷积，计算量是天文数字。即使做了稀疏化处理，只计算可能被占用的体素，计算量依然很大。

目前主流的优化方法是“由粗到细”的策略。先用低分辨率预测一个大致的占用区域，然后只在高概率区域做高分辨率的细化。另一种方法是利用时序信息，因为相邻帧之间的占用栅格变化很小，可以用上一帧的结果作为先验，只更新变化的部分。

我实际测试过几种Occupancy Network的实现，在Orin芯片上，如果分辨率做到0.4米，覆盖范围30米，推理时间可以控制在20毫秒以内。但如果要把分辨率提到0.2米，覆盖范围50米，推理时间就会飙升到80毫秒以上，根本达不到实时性要求。所以目前量产方案里，Occupancy Network的分辨率通常不会太高，更多是作为BEV感知的补充，而不是替代。

4.3 Occupancy与BEV的协同工作模式

在实际系统中，BEV和Occupancy通常是协同工作的。BEV负责输出道路结构、车道线、可行驶区域这些二维信息，Occupancy负责输出三维空间占用、障碍物高度、悬空物体这些三维信息。规控模块会综合两者的输出，做出最终的决策。

举个例子，车辆前方有一个施工区域，BEV感知可能会把施工围挡识别成车道线的一部分，因为它看到了一条连续的边界。但Occupancy Network会检测到围挡是一个三维的占用体素，高度超过1米，不是路面。规控模块结合这两个信息，就能判断出“前方有障碍物，需要变道避让”，而不是“沿着车道线继续行驶”。

这种协同模式的好处是各取所长。BEV在语义理解上更强，能识别车道线、交通标志、信号灯；Occupancy在几何理解上更强，能处理不规则障碍物和三维结构。两者结合，车辆对环境的理解就更完整了。

4.4 实际部署中的算力分配与模型剪枝

在实际部署中，算力分配是一个很现实的问题。Orin芯片的总算力是254 TOPS，但并不是所有算力都能给感知模块用。规控、定位、地图、人机交互都要分走一部分。我参与过的一个项目里，感知模块分到的算力大约是100 TOPS，其中BEV占了60 TOPS，Occupancy占了30 TOPS，剩下的10 TOPS留给后处理和融合。

为了在有限的算力下跑出可用的效果，模型剪枝和量化是必须的。剪枝就是把网络中冗余的通道和层去掉，量化就是把浮点运算变成定点运算。我实测过，经过剪枝和量化之后，BEV模型的推理时间可以从50毫秒降到25毫秒，精度损失在2%以内。Occupancy模型的压缩空间更大，因为它的输出是稀疏的，很多体素根本不需要计算。

但剪枝和量化也有风险。过度剪枝会导致模型对长尾场景的泛化能力下降，比如异形车辆、临时路障、动物横穿这些场景。我踩过的一个坑是，为了把推理时间压到20毫秒以内，把Occupancy模型的分辨率降到了0.6米，结果车辆对路沿的检测变得很不稳定，有时候会把路沿当成可行驶区域。后来把分辨率调回0.4米，虽然推理时间增加到了30毫秒，但安全性明显提升。

5. 无图方案的数据闭环与实车验证

5.1 数据采集与自动标注的流水线搭建

无图方案的核心竞争力不在于模型结构，而在于数据闭环。因为没有了地图先验，模型必须从数据中学习所有的道路结构和交通规则。这就需要一个高效的数据采集、标注、训练、验证流水线。

数据采集方面，我建议采用“影子模式”加“触发式回传”的策略。影子模式就是让车辆在人工驾驶或者辅助驾驶状态下，持续运行感知模型，但不对车辆控制产生任何影响。感知结果和人工驾驶行为之间的差异，就是最有价值的数据。比如人工驾驶员变道了，但感知模型认为应该直行，这个片段就会被标记为“困难样本”，自动回传到数据中心。

自动标注是降低标注成本的关键。纯人工标注一帧BEV数据需要几分钟，成本极高。现在的做法是先用一个预训练的大模型做初步标注，然后人工只需要做修正和验证。我实测过，自动标注可以把标注效率提升5到10倍，而且一致性更好。

5.2 仿真测试与实车路测的配比策略

无图方案的验证不能只靠实车路测，因为实车路测的成本太高，而且很难覆盖所有长尾场景。仿真测试是必不可少的补充。我通常建议的配比是：仿真测试占70%，实车路测占30%。

仿真测试的优势是可以任意构造场景，比如突然横穿的行人、逆行的车辆、施工区域的临时围挡。这些场景在现实中很难遇到，但在仿真环境里可以反复测试。仿真测试的另一个优势是可重复性，同一个场景可以跑几百遍，验证模型的稳定性。

但仿真测试也有局限性。仿真环境里的传感器模型和真实传感器有差异，光照、天气、材质反射这些细节很难完全模拟。所以实车路测仍然是不可替代的。我通常会把仿真测试中表现最差的场景挑出来，在实车上重点验证。

5.3 从高速到城区的场景泛化挑战

无图方案在高速场景下相对容易落地，因为高速道路结构简单，车道线清晰，交通参与者类型少。但到了城区，难度就上了一个数量级。城区道路有大量的路口、环岛、窄路、人车混行、临时停车、施工围挡，这些场景对实时感知的要求极高。

我参与过的一个城区无图项目，最开始在高速上跑得很稳，但一到城区就频繁出现急刹和画龙。排查之后发现，主要问题是BEV感知对路口的车道线连接关系理解不够。高速上车道线是连续的，BEV感知很容易跟踪；但城区路口没有车道线，BEV感知就不知道该怎么走了。后来我们在训练数据里增加了大量路口的样本，并且引入了导航地图的粗略先验（比如“前方路口左转”），才把这个问题解决掉。

5.4 安全冗余与降级策略的设计

无图方案的安全冗余设计比有图方案更重要。因为有图方案至少有一个“地图兜底”，即使感知失效，车辆还能靠地图保持基本的安全。无图方案没有这个兜底，所以必须设计多级降级策略。

我通常建议的降级策略是这样的：第一级，BEV感知和Occupancy Network都正常，车辆可以正常运行；第二级，Occupancy Network失效，但BEV感知正常，车辆降速到40公里每小时以下，保持车道内行驶；第三级，BEV感知也失效，车辆靠毫米波雷达和超声波雷达做紧急避障，同时请求人工接管；第四级，所有感知都失效，车辆靠IMU和轮速计做紧急停车。

这个降级策略的关键是“逐级降级，而不是直接退出”。直接退出会让驾驶员措手不及，逐级降级可以给驾驶员足够的反应时间。我在实车上测试过这个策略，从第二级降级到第三级的过程中，车辆会先减速、打双闪、发出接管提示，整个过程大约有5到8秒的缓冲时间，足够驾驶员接管了。

6. 常见问题与排查技巧实录

6.1 BEV感知在弯道和坡道上的车道线漂移

这是BEV感知最常遇到的问题之一。车辆在弯道上行驶时，BEV输出的车道线会出现明显的抖动和漂移，导致车辆画龙。根本原因是BEV平面的分辨率有限，弯道上的车道线曲率变化快，网络很难精确拟合。

排查思路是这样的：首先检查训练数据里弯道样本的比例，如果弯道样本太少，网络就会欠拟合。其次检查BEV平面的分辨率，如果分辨率太低，弯道上的车道线就会变成折线。最后检查时序融合模块，如果时序融合做得不好，相邻帧之间的车道线跳变就会很明显。

我的解决方法是：在训练数据里增加弯道样本的比例，尤其是小半径弯道；把BEV平面的分辨率提高到0.1米；在时序融合模块里加入车道线曲率的平滑约束。这三个措施叠加之后，弯道画龙的问题基本解决了。

6.2 Occupancy Network对悬空障碍物的误检

Occupancy Network的一个典型问题是把悬空障碍物误检为地面障碍物。比如天桥、隧道顶、树枝、广告牌，这些物体在三维空间里是悬空的，但Occupancy Network可能会把它们投影到地面上，导致车辆误刹车。

排查方法是：检查Occupancy Network的高度预测精度。如果高度预测误差超过0.5米，就很容易出现误检。另一个方法是检查训练数据里悬空障碍物的样本比例，如果太少，网络就学不会区分悬空和地面。

我的解决方法是：在Occupancy Network的输出里增加一个“高度通道”，专门预测每个体素的高度。然后在后处理阶段，根据高度信息过滤掉悬空障碍物。这个改动增加了大约10%的计算量，但误检率下降了一个数量级。

6.3 无图方案在隧道内的定位丢失

隧道是无图方案最头疼的场景之一。GNSS信号完全丢失，视觉特征重复（隧道壁的纹理很相似），激光雷达的反射特征也不明显。车辆在隧道里很容易丢失定位，导致感知和规控都失效。

排查方法是：检查隧道内的视觉里程计精度。如果视觉里程计漂移太快，就需要引入其他传感器做辅助。我试过在隧道里用毫米波雷达做速度估计，结合IMU做航位推算，可以在短时间内保持定位精度。

我的解决方法是：在隧道入口前提前切换到“隧道模式”，降低车速，增加毫米波雷达和IMU的权重，同时用隧道壁的激光雷达反射特征做定位修正。这个方案在短隧道（1公里以内）效果很好，但长隧道（3公里以上）仍然需要地图兜底。

6.4 常见问题速查表

6.5 几个我踩过的坑和实操心得

第一个坑是过度依赖仿真测试。我曾经在一个项目里把仿真测试的通过率做到了99%，但实车路测第一天就出了三次急刹。后来发现是仿真环境里的传感器噪声模型太理想化了，真实世界的摄像头噪声、激光雷达点云噪声、毫米波雷达的多径效应都没有模拟到位。从那以后，我坚持仿真测试和实车路测的比例不超过7比3。

第二个坑是忽略了数据标注的一致性。无图方案对标注质量极其敏感，如果不同标注员对同一条车道线的标注标准不一致，训练出来的模型就会摇摆。我的做法是：制定详细的标注规范，每个标注员先做100帧的培训样本，通过一致性检查之后才能正式标注。正式标注过程中，每周做一次交叉验证，确保标注标准没有漂移。

第三个坑是低估了时序融合的重要性。单帧BEV感知的输出抖动很大，如果不做时序融合，规控模块会收到大量噪声。我试过简单的滑动平均，效果一般；后来改用LSTM做时序融合，效果好了很多，但延迟增加了。最终的方案是用一个轻量级的时序注意力模块，在延迟和稳定性之间取得了平衡。

第四个坑是忽略了降级策略的实车验证。降级策略在仿真里跑得很好，但实车上从正常模式切换到降级模式时，车辆会有明显的顿挫感，驾驶员体验很差。后来我们在降级过程中加入了平滑过渡，让车辆在2到3秒内逐渐减速，而不是突然降速。

7. 无图方案的未来演进与我的个人判断

无图方案不是要彻底抛弃地图，而是重新定义地图的角色。地图从“提前知道一切”的先验信息，变成了“兜底和校验”的辅助信息。车辆的主要决策依据是实时感知，地图只在感知失效或者置信度低的时候介入。这种架构的好处是显而易见的：规模化成本大幅降低，场景适应能力大幅提升，系统的鲁棒性也更强了。

从技术演进的趋势来看，BEV感知和Occupancy Network的融合会越来越紧密。未来的感知架构可能会把两者统一到一个端到端的模型里，输入是多相机图像和激光雷达点云，输出是三维占用栅格和道路结构。这种端到端模型的好处是信息损失更少，但训练难度和算力需求也会更高。

另一个趋势是数据闭环的自动化程度会越来越高。现在的数据闭环还需要大量人工介入，比如标注、场景筛选、模型调参。未来这些环节会逐步自动化，车辆在影子模式下发现的问题，可以自动触发数据回传、自动标注、自动训练、自动验证，整个闭环的周期从几周缩短到几天。

我个人在实际操作中的体会是，无图方案的核心竞争力不在于模型有多复杂，而在于数据闭环有多高效。一个能快速迭代的数据闭环，比一个复杂的模型结构重要得多。我见过太多团队把精力花在模型调参上，却忽略了数据质量，结果模型在实车上表现一塌糊涂。相反，那些把数据闭环做扎实的团队，即使模型结构简单，也能跑出很好的效果。

最后再分享一个小技巧：在无图方案的早期阶段，不要急着把地图完全去掉。可以先做“轻图”方案，用地图提供粗略的先验信息（比如道路等级、路口位置），实时感知负责精细的车道线和障碍物检测。等实时感知的能力足够强了，再逐步降低地图的权重。这种渐进式的方案风险更低，落地速度也更快。