企业官网建设流程全解析

夜间行车，你正以80公里时速巡航在城市快速路上。前方十米，一辆货车掉落了一个大纸箱——你的刹车反应需要 0.8 秒，系统感知处理需要 150 毫秒。传统 3D 目标检测器盯着这个纸箱，却大概率直接无视：因为它不在任何训练类别里。这个场景，恰好戳中了传统 3D 目标检测最尴尬的软肋，也是占据网络（Occupancy Networks）这两年在自动驾驶领域火出圈的根本原因。

这篇文章不追概念，从原理到工程落地完整拆一遍：传统 3D 目标检测为什么在真实路况中越来越吃力、占据网络怎么用一套体素网格把所有障碍物一网打尽、前两年量产车上这类模型是怎么一步步部署落地的，以及最常被误解的一个问题——它到底会不会真的完全取代传统 3D 目标检测。

1. 传统3D目标检测的"边界困境"：当世界被装进方盒子

1.1 为什么我们习惯了用3D边界框看世界

传统的 3D 目标检测，核心输出是一个个三维边界框（3D Bounding Box）。这个框由中心点坐标、长宽高尺寸、朝向角和类别标签组成。业界的主流做法，不管是用激光雷达点云做 PointPillars、SECOND，还是用视觉做 BEVDet、DETR3D，本质上都在做同一件事：先框出一个长方体区域，再给框里的点云或图像特征分类。

这套范式之所以能统治行业这么多年，是因为它和下游模块配合得太顺了。追踪模块可以直接用框的中心点做关联匹配，预测模块可以根据框的历史轨迹拟合速度和加速度，规划模块也能把框当作凸多边形避障边界。整个感知-决策-执行的链路，都是围绕"一个目标一个框"设计的。

但问题恰恰也出在这个"框"字上。边界框假设世界上的所有障碍物都可以用一个长方体近似，这个假设在标准化的园区、高速公路上勉强成立，到了城市开放道路就漏洞百出。

1.2 长尾场景里的"隐形障碍物"：类别盲区的代价

我见过太多实际路测案例翻车，最后诊断出来的根因几乎都一样：障碍物类型不在训练类别里。

新势力车企的感知训练集，通常覆盖车辆、行人、骑行者、锥桶、卡车等十几到几十个类别。但真实世界是一个开放式集合：掉落的纸箱、飞来的塑料袋、翻倒的垃圾桶、掉在路上的轮胎、施工区域的沙堆、被风吹倒的围挡、甚至是卡在路中间的一只野猪——这些东西都有实体，都会造成事故，但它们恰恰很难进入训练集。

更麻烦的是，即使想扩充类别，数据标注的成本也在指数级上升。一个 3D 框要标注出八个角点的精确位置、朝向和类别，一帧点云标一个物体就需要好几秒。想把所有长尾物体都纳入框检测体系，几乎是不可能的任务，这也是传统 3D 检测在处理开放世界时最本质的缺陷。

1.3 边界框另一个隐性问题：形状信息几乎丢失

边界框的第二个物理缺陷，是形状表达粗糙。一辆车可以用长 4.8 米、宽 1.9 米、高 1.5 米的框近似，但一辆装载着钢管、钢筋超出车体范围的皮卡呢？一个一半车身伸出停车位的箱式货车呢？一个正在倾倒、吊臂横跨半条街的混凝土泵车呢？

边界框只能给一个"包络盒"，盒子里到底哪里实心、哪里空心、哪里悬空，一概不知道。这导致规划模块在做避障时，只能把整个框都当作障碍区域处理。本来只需要绕开吊臂的一段，结果整条路都被标记为不可通行。感知精度没上去，通行效率倒是先牺牲了一半。

提示：在实际工程中，有一个不成文的经验——框检测的召回率做得再高，开放道路上的安全性上限也绑定在训练类别的覆盖率上。类别覆盖率解决不了，换再强的骨干网络也只是在已知类别里卷精度。

2. 占据网络到底在做什么：从"这是什么类别"到"这里有没有东西"

2.1 体素化世界：把空间切成小方块

占据网络（Occupancy Networks）的思想非常直接：不再问"那里是什么"，而是问"那里有没有东西"。具体做法是把自车周围的三维空间划分成一个个小立方体（Voxel），然后让网络对每个小立方体输出一个占用概率（Occupancy Probability）——它的值在 0 到 1 之间，接近 1 表示该体素被障碍物占据，接近 0 表示空闲。

举个例子，在自车前方 50 米、左右 25 米、高度 6 米的范围内，用 0.2 米的体素尺寸去离散化，会产生约 18.75 万个待预测的体素位置。网络输出一整个稠密的占用网格（Occupancy Grid），不仅告诉系统哪里有障碍物，还天然携带了形状和轮廓信息——这和只输出几个方框是两种维度的信息。

这里要说明一个容易被混淆的细节：计算机视觉里最早提出Occupancy Networks的，是做三维重建的研究团队，重点解决的是单视角物体重建问题。自动驾驶行业把它借鉴过来，演变成了以多相机图像（或多帧点云）为输入、以自车周围体素空间为输出的感知任务。虽然都叫Occupancy，但底层的网络结构、损失函数和工程链路差别不小。

2.2 从多相机图像到3D体素：跨视角特征如何变成占用预测

视觉方案的占据网络，输入一般是 6 到 8 个环视相机的图像，外加 IMU 和轮速计提供的运动信息。网络的处理链路大致分三步：

• 第一步，每路图像过共享权重的 2D 骨干网络提取特征，得到多视角的 feature map；
• 第二步，利用内外参把 2D 特征通过可微分的投影变换映射到 3D 空间，生成一个 BEV（Bird's Eye View）或者 3D 空间的初始特征体；
• 第三步，对体素空间的每个查询位置，通过注意力机制或者 MLP 解码器，回归出占用概率。

第三步的高明之处在于：体素查询不只看当前帧的 2D 特征，还会结合时序融合的历史信息。具体来说，前一帧在某个体素位置预测有物体，当前帧即便因为遮挡看不到对应的图像特征，网络也能根据时序一致性推理出"这里大概率还有东西"。这个能力对遮挡场景特别关键——前车挡住的静止行人，传统视觉 3D 检测经常会漏检，占据网络却能靠时序把概率稳住。

2.3 占据标签从哪来：训练真值不靠纯人工框选

很多刚接触占据网络的人最疑惑的问题，是训练标签怎么搞。难道要把 3D 空间每个体素都人工标一遍？真这样做的话，成本比标 3D 框还高好几个数量级。

业界主流的做法，还是靠激光雷达自动生成真值。LiDAR 点云天然携带距离信息，可以直接投影到体素空间，被点云覆盖的体素标记为 occupied，没有点的标记为 free。稀疏的点云会有一些需要处理的边界体素，但大规模自动标注完全可行。走纯视觉路线、没有激光雷达车队的团队，也可以退而求其次，用多帧图像的深度估计结果来生成弱标签，但精度和训练稳定性都会打折扣。

注意：点云投影生成占用标签时，一个最常踩的坑是"遮蔽漏标"——被前景物体挡住的背景区域，激光雷达打不到，会被误标成 free，但这块实际上是被占据的。不做处理的话，网络会被反复灌输矛盾信号。常见缓解办法是用高度先验和时序融合把"未知区域"单独设成一类，而不是简单二分类成 occupied / free。

3. 从论文到量产：占据网络的工程化演进

3.1 某海外头部新能源车企公开的技术方向

前两年，某海外头部新能源车企在年度技术分享活动上，集中展示了自研的 Occupancy Network 方案，当时在行业里引起了不小的震动。这套方案的核心，就是把纯视觉多相机输入，通过 Transformer 结构的网络直接输出稠密占用网格，并且能泛化到训练时完全没见过的异形物体。

从公开信息能梳理出的几个要点：

• 输出的是带语义标签的体素，而不仅仅是纯几何占用——同一个 grid 里还能区分路面、车辆、行人、建筑物等不同语义；
• 支持连续时间维度上的占用预测，不只是当前帧还是短时未来帧的占用状态；
• 设计目标是直接服务规划控制，占用网格成了规划模块的可行空间输入，而不是像框检测那样先出一堆目标再单独算避障。

这家车企展示的另一个关键细节是——占用网络对"物体可见面积"很敏感。一辆车被挡住了 70% 的像素，人类驾驶员也能判断它的位置和轮廓，传统视觉检测做不到，但时序融合后的占用网络在很大程度上做到了。这是我个人认为比单纯体素化更核心的进步。

3.2 国内产业界的集体跟进与方案变体

海外巨头公开方向之后，国内做智能驾驶的车企和供应商也迅速跟进。我观察到，目前行业里落地比较多的其实是三种变体：

第一种是"视觉为主、LiDAR辅助"的双模态占用网络，图像负责语义理解，点云负责几何精度的校准，两者在 BEV 或体素层面做融合。这是目前量产主流，因为安全冗余足够、工程成熟度高。

第二种是纯视觉占用网络，靠多相机图像和长时序优化来保证精度，成本低，但需要非常强的数据积累和仿真验证能力，只有少数几家头部企业敢做主力方案。

第三种是"Occupancy + 稀疏体素"的轻量架构，只在预测有物体可能性的候选区域周围建网格，而不是全空间稠密推理，算力消耗大幅下降，适合中低算力平台。这一类的工程技巧，后面会详细讲。

3.3 部署落地中最现实的难题：计算量与存储

占据网络占据网络听起来很美，但一到部署就暴露杀手锏级的问题——稠密体素的计算量实在太大了。

一个 100 米 × 50 米 × 6 米的空间，按 0.2 米分辨率划分，差不多 375 万个体素位置，每个位置要过解码器输出占用概率和特征维度。如果全量计算，单帧推理的 FLOPs 会冲到几百 G，直接压垮车规级芯片。这在实验室里跑跑没关系，量产车型的域控制器可受不了。

实际工程中，业界普遍会做三类优化：

• 稀疏化：先用轻量网络或区域提案找出可能占据的子空间，只在这些 sparsity 区域内做精细预测，把计算量往下砍一个量级；
• 分辨率分级：近处用 0.1 米的高分辨率体素，远处放宽到 0.4 米甚至 0.8 米，既保住了近场的避障精度，又把整体体素数量压下来；
• 量化与剪枝：占用网络有大量逐体素 MLP 分支，激活函数和矩阵乘对低比特量化容忍度较好，量到 INT8 后推理速度能再快 2 到 3 倍。

没有统一的调优捷径，三种手段一般要组合使用。我见过不少团队第一次移植模型时，在这个阶段卡了整整两三周，所以放在这里提醒一句：模型结构设计阶段就得把推理算子约束考虑进去，别等训完再回头优化。

4. 占据网络和3D目标检测的真实关系：是替代，还是协同

4.1 为什么"完全取代"的说法站不住脚

标题里的"取代"两个字听起来很颠覆，但作为从业者，我想泼一盆冷水：占据网络不会单方面取代 3D 目标检测，至少在量产自动驾驶的定义里不会。

原因很实在。占据网络输出的是几何占用，它知道"这里被填满了"，但它不知道"这个被填满的物体是一辆车还是一个人"。绝大多数下游场景，比如路口转向时的车流判断、判断前方是否缓慢移动、预测旁边行人的轨迹，没有语义信息就是耍流氓。追踪和预测系统需要的目标 ID、速度、朝向、类别，占用网格给不出来。

还有一个容易被忽略的点：占用网格的表达精度受限于体素分辨率。0.2 米的网格去表示一辆车，轮廓误差在 ±10 厘米左右，直接用来做高精度泊车或者低速紧急刹车，余量不够。3D 检测框反而能通过后处理把姿态和尺寸估计得精细得多。

4.2 实际量产方案中两者如何配合

从我接触的量产项目来看，目前更常见的做法，是把两者做成一个并行双通道的感知架构，而不是二选一：

• 通道一：传统 3D 目标检测，负责输出带语义类别、尺寸朝向和 ID 的障碍物列表，供追踪、预测和交通规则理解使用；
• 通道二：占据网络，负责输出稠密的通用占用空间，专门兜底长尾障碍物和异形物体，供避障规划使用。

两者在融合阶段各取所需。规划模块拿到 3D 框列表后，先做常规的意图预测和舒适性规划；如果占据网络在可行驶区域内发现了一个没有 ID、没有类别的高置信度占用块，就直接触发保守避让策略。这套组合，既保留了传统检测的语义丰富度，又弥补了类别盲区，是目前安全性和性能平衡最好的路径。

4.3 如何根据自身条件选择技术路线

如果你正在搭建一套感知系统，我个人的选型建议是这样的：

• 预算充足、传感器配置高（激光雷达 + 多相机 + 高算力芯片）：直接上双模态融合方案，占据网络负责通用障碍物感知，3D 检测负责语义目标，冗余度最高；
• 纯视觉、算力有富余：可以考虑纯视觉占据网络做长尾兜底，但一定要保证足够的训练数据覆盖和多帧时序稳定性；
• 中低算力平台：建议把占据网络限制在近距离（前视 30 米内）的稀疏区域，其余位置用传统检测框补齐，不要在量产的第一个版本里追求全空间稠密输出，否则落地周期会失控。

技术本身没有优劣之分，适合自己传感器配置、算力预算和应用场景的方案，才是好方案。

5. 踩坑实录：从评估到上车的真实经验

5.1 评估占据网络时最容易误判的指标

我曾经见过一个团队，满怀信心地报告占据网络在测试集上的 IoU 精度很高，接近 85%，结果一上车就频繁误刹车。排查到最后才发现，他们在评估时用的是固定场景中规整的障碍物，没有单独测"悬空类"和"稀疏点云类"的物体——比如树叶伸进路肩、栏杆顶端、低矮的行道树台。

占据网络的误检，和传统 3D 检测的误检完全不同。传统检测误检，往往是一个框里夹带噪声；占据网络误检，可能是路面某个凸起长期被判为 occupied，导致车辆频繁减速。评估阶段一定要把指标拆细，单独看"非平坦地面区域"的误检率，单独看"遮挡恢复区域"的召回率，这两项比整体 IoU 更能预测真实路测体验。

5.2 时序稳定性的坑：为什么单帧很强、连续起来会抖

还有一个在仿真测试里很难暴露、一跑真实路段就原形毕露的问题——体素占用的时间抖动。

单帧推理时，网络对某个障碍物的占用概率是 0.7，下一帧由于视野变化、光照变化，可能跳到 0.3，再过一帧又回到 0.8。规划模块如果直接吃这个概率值，避障决策会来回振荡，体感就是车辆忽快忽慢，甚至频繁变道意图。

缓解方案通常有两个方向。一个是输出端加时间域滤波，对每个体素的占用概率做多帧滑动平均，降低瞬时跳变的影响；另一个是训练端引入时序一致性损失，约束相邻帧的特征和输出平滑过渡，效果更好但训练难度也更大。如果你在验证时发现"单帧视频看着完美、连续视频就鬼畜"，大概率就是这个问题在作祟。

5.3 数据闭环里的特殊技巧：把误检转化成自动挖掘样本

占据网络对长尾物体的感知能力，让它天然适合做数据闭环里的"探矿机"。实际路测采集的海量视频，先用轻量版的占据网络扫一遍，凡是出现高置信度占用、但没有对应 3D 检测框的区域，自动截取出来作为候选数据。这种做法不需要人工先看视频，就能高效率地找到标注团队平时很容易漏掉的"特殊场景"。

我自己的实操体会是，这套自动挖掘通道跑起来以后，团队收集到的高价值数据量比原本靠运气路测多出好几倍，而且很多都是此前完全不知道该怎么主动去找的稀奇场景。把这些数据半自动标注后重新灌进训练集，占据网络的长尾泛化能力还会继续滚雪球式增长。

提示：做自动挖掘时，建议同时记录触发点的自车速度、转向角、油门状态这些上下文信息，而不只是传感器数据。同样的障碍物，在低速泊车场景和高速巡航场景中对车辆决策的威胁等级完全不同，后续打标签和仿真回放时，这些上下文能帮你快速做场景分级。

写在最后：我的一点点个人体会

从传统 3D 检测一路看到占据网络的普及，我有一个越来越强烈的感觉：感知技术的进步，很多时候不是把旧问题打磨得更好，而是重新定义了"要解决的问题本身"。3D 目标检测问的是"路上有什么种类的物体"，占据网络问的是"空间里哪些区域是物理上不可通行的"。后者更接近驾驶决策真正需要的答案。

如果你准备在项目里引入占据网络，我的建议是从小处着手，先做一个极小范围的稀疏体素感知模块，接进现有的规划链路里兜底长尾障碍物，跑通之后再逐步扩展。不要一开始就指望它替代所有模块、接管全部规划输入，那样大概率会陷入模型调参和系统联调的泥潭。循序渐进，让每个增量都稳定落地，这条技术路线才会真正给你带来安全感。