企业官网建设流程全解析

傍晚的城中村，双向两车道上停满了各种车，测试车面前突然出现一辆歪着停的快递三轮。老一代感知系统大概率把它当成背景，因为模型里没有“歪着停的快递三轮”这个类别。而基于 OCC 占用网络的那套系统，会在三维网格里标出“这里有东西占了，不能走”，车辆提前减速刹停。

就是这一幕让我意识到，占用网络不是又一种花哨的感知输出，而是在给整个自动驾驶系统换一个更接近物理世界的表达底座。把 OCC、世界模型、端到端技术栈放在一起看的人不少，但真正从“窗口期”角度去拆机会和坑的，目前还不多。这篇文章我想用一线算法工程视角，把这三个东西之间的关系、落地细节和行业节奏一次讲透，适合正在做感知、规划或者技术选型的工程师，也适合想判断这个方向该不该投入的管理者。

1. 为什么 OCC 能成为感知表征底座

1.1 从 2D 检测到 3D 占用：感知范式到底变了什么

过去十年，量产感知系统的标准输出是“框 + 类别 + 轨迹”。检测模型解决的是“是什么、在哪、在动”，但人类开车时从来不是靠框来开的。路面上翘起来的井盖、突出来的货车挡板、没有任何语义类别的异形施工围挡，物体检测模型天然拿它们没办法，因为类别体系里根本没有这些项。

占用网络把这个问题反过来看：不先问“这是什么”，而是先问“这个三维区域到底空不空、能不能走”。场景被划分成离散的体素，每个体素输出占据概率和可选语义类别，识别不出来的物体直接归入通用的 occupied。这样感知输出的不是一个稀疏的目标列表，而是稠密的三维几何 + 语义描述。传统检测像交通广播告诉你“前方 200 米有车”，占用网络则是实时更新的可通行空间地图，把自由空间这个被传统模型忽视的一等公民还给了系统。

也是从这一刻起，OCC 不再只是感知模块里的一个分支，它开始承担“表达底座”的角色。下游规划不需要再从稀疏目标框去猜哪里能压线、哪里能通过，直接查占用网格就行。现在不少量产车型的 AEB、APA、城市 NOA 都把占用网络作为安全兜底，原因就在这：框可能漏，但三维空间是否被占用的几何事实不容易骗人。

1.2 自由空间表达：比“目标列表”更值钱的输出

早期 BEV 感知盛行时，大家用鸟瞰图做俯视分割，已经能表达可行驶区域。但 BEV 只有二维，无法处理立交桥下、跨线桥、悬浮物这类真实场景。OCC 把 BEV 拍扁的空间重新立起来，Z 轴上一旦有连续几何，很多过去靠规则硬扛的场景就自然化解了。

我经常打一个比方：检测模型给人看的是一份“在场人员名单”，占用网络给的是一张“房间实时平面图”。名单可能在关键时刻漏人，但平面图不会漏掉任何物理占据空间的物体，哪怕它没有名字。对自动驾驶这种安全系统来说，底座的完备性比精细的语义更重要。

1.3 为什么恰好是现在：传感器、芯片、模型三者同步到位

占用网络的理论并不新，视觉几何里几十年都在做三维重建。过去不量产是因为三个条件没齐：车身摄像头分辨率和动态范围不够，夜间和逆光下三维深度根本恢复不出来；车规芯片算力撑不起稠密体素推理；Transformer 这类能隐式建模全局关系的结构还没有在视觉领域成熟。这三样在近两年同步到位，OCC 才从论文走向产品。

理解这个历史过程很重要。OCC 的量产窗口不是某一家公司“想通了”，而是整个技术栈的上下游水位同时涨上来了。现在上车的是初步方案，往后两三年随着芯片升级和数据积累，占用网络的精度和实时性还会继续提高。

2. 占用网络方案选型与实现要点

2.1 三种主流技术路线怎么选

现在做占用网络，主线大致有三种：纯视觉方案、激光雷达方案、多传感器融合方案。三者没有绝对优劣，关键看传感器硬件和成本约束。

纯视觉路线是目前量产的主流选择，因为不需要依赖高线束激光雷达，成本结构可以压到消费级。实际落地时最常见的做法是：用激光雷达离线生成伪标签，蒸馏给视觉网络。也就是训练时让激光雷达当老师，推理时只保留摄像头，兼顾了精度和成本。

激光雷达方案更适合限定区域或高级别验证车队，比如 Robotaxi 和干线物流重卡。这类场景本身已经在车上装了激光雷达，不需要额外增加硬件成本，点云的几何先验能让占用质量上一个台阶。缺点也很明显：120 线甚至 200 线雷达在 60 米外仍然稀疏，远处的小物体照样没有点云支撑。

多传感器融合是最终形态，但工程复杂度最高。时间同步、外参漂移、传感器失效降级都要单独设计，通常只有在整车平台已经具备完整传感器组时才会考虑。

2.2 体素化参数怎么定：范围、分辨率、类别一个都不能少

占用网络的体素参数直接影响最终精度和算力账单。范围定多大、分辨率取多少、类别设哪些，本质上是在做一个三维空间的编码取舍。

行业内一个典型的城区配置大概是：X 方向 100 米，Y 方向 50 米，Z 方向从 -5 米到 3 米，体素分辨率 0.5 米。算一下体素数量：200 × 100 × 16 = 32 万个体素。如果分辨率提到 0.4 米，体素数量变成 250 × 125 × 20 = 62.5 万，直接翻倍。这就是分辨率和算力的残酷交换。

我建议工程上不要一刀切均匀分辨率。近区 30 米范围内用 0.3 米细粒度，满足泊车和低速避障；30 米到 80 米用 0.5 米；再远用 1 米甚至更低分辨率给高速场景做前哨。这样体素总量可控，近处安全兜底又足够精细。类别上不要贪多，基础类别建议保持“free、occupied、车辆、行人、骑行者、路面”这几类，其他新类别用通用 occupied 兜底。类别越多，标注成本和模型容量都需要指数级增长，量产初期并不划算。

2.3 标注与真值是第一道坎

很多团队一开始把占用网络当成普通分割任务做，结果发现数据真值比模型还难搞。激光雷达点云扫出来的三维空间是稀疏的，不可能直接输出稠密占用标签。Occ3D 那套思路是拿激光雷达点云做射线投射，把射线穿过的“空隙”标记为 free，把末端遮挡的 voxel 标记为 occupied。听起来简单，但工程坑很多：运动物体会在帧内产生拖影，低矮物体与地面点混在一起，远距离点云太稀导致真值全是空洞。

所以我的经验是：先把真值可视化放到第一位。每一批标注数据都要抽查 top view 和 side view 的可视化结果，检查动态物边缘、栏杆、路沿、树冠这类高频出错区域。宁可少一点数据，也要保证真值质量，否则模型不收敛的时候你根本分不清是网络问题还是标签问题。

2.4 实时性和部署：占用的算力账单

占用网络最大的“劝退点”是算力。32 万体素的稠密预测，再加上 Transformer 编码器的全局注意力，一次前向推理的 FLOPs 非常容易冲到几十 G。中端量产芯片上，这种量级通常只够跑 10 到 15 帧每秒，距离 30 帧的要求差一大截。

工程优化方向大致有这么几个：第一，把网络头部从稠密卷积改成稀疏卷积，只对包含有效特征的体素做计算；第二，把体素生成拆成两段，先用低成本模块找出可能 occupied 的区域，再做细粒度分类，相当于 coarse-to-fine 级联；第三，用深度估计和 2D 语义先做锚点，把 3D 注意力范围限制在合理候选集合里，大幅压缩计算量；第四，INT8 量化已经是标配，占用网络对量化误差比检测更敏感，量化校准集必须专门挑夜间、雨天和逆光场景，不能随便拿白天数据凑数。

我见过不少团队纸面精度很好看，一上嵌入式平台就掉到 2 帧，最后被迫把范围砍一半。所以选型阶段就要把算力预算前置，别先跑大模型再考虑裁剪。

3. 世界模型：从感知到推演，OCC 是最好的“世界状态”

3.1 视频预测不是世界模型，目标在“可推演的状态”

聊世界模型之前必须先破除一个误解：视频预测不是世界模型。生成模型可以生成形似合理的未来帧，但那只是像素层面的外推，模型没有真正理解“车往前开会撞到路沿”这样的物理约束。真正的世界模型，应该是对环境状态和动态转移的建模，它要能回答“如果执行某个动作，下一秒世界会变成什么样”这个问题。

自动驾驶的世界模型通常包含几个组件：历史观察编码器、隐状态表征、未来预测头、以及可供规划查询的损失接口。问题是，状态表征到底用什么？用高维特征，不可解释也不可约束；用渲染出的图片，训练不稳定、评估困难。这时候 OCC 的价值就凸显了：一个显式的三维占用网格，天然适合作为世界模型的中间状态。预测未来占用，本质就是在预测“空间哪些区域将被占据”，这对规划器来说几乎是直接可用的输入。

3.2 把未来预测放进 OCC 网格，显式又可控

我特别看好的一个方向是“基于占用的未来预测”。现有研究里，很多工作把历史多帧占用序列输入模型，学习时空动态，输出未来 1 到 5 秒的占用场。相比直接预测原始图像，预测占用有几个天然优势：占用空间维度更低、语义干扰更小、输出可以被规划 cost 直接消费；监督信号是稠密的三维几何，而不是复杂的 RGB 颜色分布；模型学到的动态规则更容易在三维世界里对齐。

实际工程中，这类模型跑影子模式已经有可行路径。我们最开始只在测试车队上开影子模式，让模型预测未来 3 秒的占用序列，拿真实发生的轨迹做对比。第一批结果通常会高估动态物体的运动速度，原因在于训练数据里刹车急、起步猛，时序动态分布偏激。后来我们按场景平衡数据，并加入运动学约束作为辅助损失，情况才明显改善。

3.3 从未来占用到闭环：世界模型怎么给系统“剧透”

世界模型真正值钱的地方，不只是给当前帧画一张更准的占用图，而是让系统拿到一个时间维度上的预测。规划器如果只知道“现在这里有障碍”，只能被动刹车；如果能知道“接下来 2 秒这个障碍会以某种轨迹挪开或者停下”，就可以提前规划更平滑的路径。

落地节奏上可以分四步走。第一步，先做短期占用预测，只预测 1 到 3 秒，用于增强 AEB 和紧急转向的预判；第二步，把预测的占用序列投影成带时间戳的 cost map，接入规控模块；第三步，用预测结果自动挖掘难例，比如鬼探头场景，回灌训练集；第四步，当模型精度稳定后，再用它做规划策略的离线评估和仿真推演，替代一部分人工编写规则。

这四步里，第一步到第二步的跨越最关键。很多团队把预测做到了 80% 以上精度，却不知道怎么让规划器使用带不确定性的占用序列，最后只把预测结果可视化，价值大打折扣。我的建议是：规划侧提前预留 cost 接口，把占用场转成不同置信度下的膨胀障碍，再叠加时间维度的速度约束，不要指望一个非黑即白的二值网格能做安全决策。

3.4 和 AGV、机器人技术栈的交叉：同一个思想在落地

占用网络和世界模型不只属于自动驾驶。仓储 AGV、工厂 AMR 这类移动机器人的技术栈，也在经历从“2D 激光 + 反射板 + 二维占据栅格”到“3D 语义感知 + 动态环境预测”的升级。二维占据栅格本质上就是 2D 版的占用网络，而世界模型可以让机器人在已知地图上预判“这边有托盘要移动、那边有人员经过”。

对做机器人技术的团队来说，直接复用自动驾驶那套 OCC + 世界模型的思路是可行的，但要注意算力和传感器差异。AGV 通常没有昂贵的高线束雷达，更多依赖深度相机、2D 激光和低算力工控机，所以需要更紧凑的模型结构。优先级建议：先做局部 3D 占用避障，再做短时动态预测，最后才考虑全局的运动规划闭环。

4. 端到端技术栈：OCC 插在哪一层，怎么收口

4.1 端到端不是黑盒：中间表征必须“有骨头”

端到端自动驾驶这两年非常热，算法把感知、预测、规划放进一个可微网络里，直接输出轨迹或控制指令。但端到端不等于做死黑盒，纯靠标注轨迹反向传播，在复杂场景下的样本效率和可解释性都是灾难。一个让端到端真正可用的架构，往往要保留若干有物理意义的中间表征，OCC 就是其中最值得投资的骨头之一。

有了占用网络作为中间表征，端到端模型的“感知—预测—规划”链条就有了一个稳定的几何锚点。感知部分输出当前占用场，预测部分把占用场推演到未来几帧，规划部分直接基于这些占用场生成轨迹。训练时，上游有占用真值做监督，下游有轨迹真值做监督，中间层不会漂移到无法解释的隐空间。

4.2 三种插入方式：辅助监督、上下文 Token、世界模型状态

端到端模型里集成 OCC，有三种典型做法，工程节奏完全不同，我直接对比一下。

现实量产中，辅助监督型最容易在 6 到 9 个月内出成绩，特别适合在已有端到端框架上快速验证 OCC 的价值。上下文 Token 型适合感知已经跑稳、规划模块打算和感知协同调优的团队。世界模型状态型是方向，但不建议第一次做端到端就硬上。

我建议团队把三条路线当成一个连续演进：第一年用辅助监督型建立占用表征能力，第二年升级成上下文 Token，第三年再往世界模型状态型推进。这个节奏比一步到位稳得多。

4.3 占用输出怎么变成规划能用的 Cost

很多规划团队拿到占用网格后一脸茫然，说“这玩意儿是一堆体素，我该怎么用”。实际操作里，规划器并不需要直接处理体素，而是把占用场膨胀成带安全边界的 cost map，加到 A*、DWA、MPPI 或者优化求解器的代价项里。

具体参数上，膨胀半径要根据车速动态调整：低速泊车用 0.2 米左右，城市道路 30 km/h 用 0.5 到 0.8 米，高速场景再放大到 1 米以上。占用概率不能只做阈值硬切，最好把概率值直接映射成 cost 梯度，让规划器能平稳地“感知到”障碍边缘。预测的占用序列则按时间衰减打折：第 1 帧的占用可信度最高，第 3 秒以后的预测prob cut 到 0.3 倍甚至更低，避免过激进转向。

4.4 多传感器融合与统一状态空间

OCC 是天然的融合骨干。不同传感器虽然物理形态不同，但在占用空间里可以被统一量化：摄像头负责稠密语义，激光雷达负责锐利几何，毫米波雷达负责运动速度与穿透性。多传感器输出的差异被消解在“这个体素是否被占用、属于什么类别”的统一问题里。

工程上融合的难点不在模型，在标定和时间同步。摄像头与激光雷达外参漂移 1 厘米，近距离还能忍，50 米外误差会被放大到无法解释的占用伪影。我踩过的坑是：标定好的静态外参在车辆行驶一段时间后受振动影响而漂移，最终在占用真值中造成连续的“双边缘”，模型怎么训练都学不对。最后解决方案不是换更贵的标定设备，而是加了一条在线外参修正流程，用路面和车道线特征做轻量级回归，效果立竿见影。

5. 融合窗口期的行业判断与落地节奏

5.1 四个推力为什么在 2024 到 2026 年集中爆发

“窗口期”这个词常被滥用，但我认为这一轮 OCC 和世界模型的融合窗口真实存在。四个推力正好同时到位：算力进入车规高算力时代，新一代座舱和智驾芯片能端侧承载稠密三维推理；量产车队积累了海量多模态数据，覆盖各种天气、城市和长尾工况；视觉网络结构成熟，Spatial Transformer、3D 注意力、扩散模型、大语言模型这些基础组件被反复验证；更重要的是整机厂对城市 NOA、复杂路口、无保护左转等场景的交付压力，逼着系统能力从二维上升到三维，从现在延伸到未来。

窗口期意味着什么？意味着现在投入，能同时吃下“感知表征升级”和“端到端架构演进”两波红利。等整车厂和 Tier1 把占用网络做成了标配，世界模型的融合也会被头部玩家抢先占住定义权，后来的团队就只能做供应链角色。

5.2 真需求与伪需求：别被 Demo 带跑

窗口期也容易滋生泡沫。我见过不少团队把占用网络可视化做得极漂亮，动态点云在屏幕上像水一样流动，但关掉渲染后，底层模型的漏检率和误检率连传统检测都不如。这就是典型的伪需求——为演示效果而做，而不是为安全边界和决策质量而做。

判断一个技术方向有没有真需求，我只看两个指标：安全关键场景的召回率有没有提升，以及下游规划指标有没有改善。占用网络如果不能在遮障物、异形车、施工场景、停车位边界这几类高频安全场景中带来可量化的提升，那它做得再花哨也只是学术玩具。另一个常被忽略的指标是“可解释性”：当端到端规划出错时，工程师能不能回查占用输出来定位是感知问题还是规划问题。能，就是真需求；不能，就是黑盒负担。

5.3 团队配置和路线图建议

如果现在要组一个团队做这件事，我不建议一上来就铺一个大而全的“世界模型组”。更稳妥的做法是以占用网络为圆心分三圈配置：第一圈是感知工程团队，负责 OCC 数据管线、真值生成、模型训练和部署；第二圈是感知预测联动团队，负责未来占用预测和 cost map 转换；第三圈才是世界模型与端到端融合团队，负责把预测结果接入端到端训练和闭环仿真。

路线图建议按 18 个月规划：前 6 个月完成数据管线、真值系统、V1 版单目 OCC 量产部署，在影子模式下验证安全召回；第 7 到 12 个月，上线未来 1 到 3 秒占用预测，接入规控 cost；第 13 到 18 个月，做端到端集成，把 OCC 作为中间表征与世界模型联合训练。这么走，每一步都有可回退的节点，不至于研发两年颗粒无收。

6. 工程实践中的常见问题与排查技巧

6.1 占用网络明明有障碍物，模型还是漏了

最常见的原因是单帧信息不足。远处的低矮障碍物在图像里的视差很小，深度估计器往往把它们抹平到路面上。解决思路是时序聚合：把历史多帧的占用结果在 ego 坐标系下累积，再融合当前帧。通过时间换精度，对静止小目标恢复效果非常明显。我在项目里用 5 帧滑动窗口聚合之后，三轮车和小锥桶的召回率大约提升了 25 个百分点，代价只是多占用了 20% 的内存带宽。

6.2 真值看起来对，训练起来就塌

占用真值最常见的隐性错误来自三处：点云扫描过程中的动态物体畸变，会让车辆边缘出现拉花；多帧拼接时的位姿误差，会让地面点抖动，把 free 误标成 occupied；低矮物体、栏杆、铁丝网在射线投射时容易出现内部空洞，导致模型学到“这些东西是网状可穿透”的错误先验。排查办法只有一个——做高质量的可视化 dashboard，按场景类型抽样，人工逐帧看真值，没有捷径。

6.3 一上嵌入式平台就掉帧、爆显存

占用网络掉帧的前三大原因是算子不支持、内存反复申请、量化失效。很多 PyTorch 里很顺滑的自定义算子，到了推理引擎里性能反而很惨，比如隐式 GEMM 和稀疏卷积的 runtime 支持差异很大。建议在模型设计阶段就用部署工具链支持的算子集合做约束，不要等训练完再迁移。内存方面，体素特征图最好一次性预分配缓冲区，不要逐帧动态申请。量化方面，占用网络对每个类别的误量化容忍度不同，重要类别如行人、车辆要单独统计激活范围。

6.4 端到端一起训练，Occ Loss 和 Tracking Loss 打架

把 OCC 作为中间监督加进端到端模型时，经常出现两个 loss 一起反向传播后模型顾此失彼。我处理的方式是两段式训练：先用感知数据固定住视觉 encoder 和占用 head，训练规划部分；稳定后再放开联合训练，并把 Occ Loss 权重从 1.0 逐步降到 0.3，把轨迹 Loss 维持在主导地位。如果 Occ Loss 权重设得太高，模型会把更多容量花在“画面好看”上，而不是“驾驶安全”上，训练曲线看着很漂亮，路测指标却很一般。

6.5 部署后不同车辆的标定漂移

同一套模型装到不同车辆上，占用输出经常出现系统性偏移。排查时要先区分是传感器内参改变还是外参漂移，内参问题会表现为整体模糊，外参漂移会导致几何位置移动。更要命的是，车辆载重变化会导致激光雷达相对地面的角度变化，连带真值发生整体倾斜。根治方案是在车上关键传感器之间加在线标定，用车轮、地面、车道线作为参考物，每趟出车做一次轻量回归，把漂移控制在几厘米以内。

6.6 避坑速查表

最后分享一点我个人的体会：占用网络解决的是“表达”问题，世界模型解决的是“推演”问题，端到端解决的是“决策优化”问题，三者放到一起才配得上“技术栈融合”这个词。窗口期里最容易被追逐概念和炫酷 Demo 带偏，真正该盯的永远是安全召回、可解释性和闭环指标。如果让我给同行一句建议，就是别急着一步到位做那个宏大的世界模型，先把未来 3 秒的占用预测接到规划器的 cost 上，这个从“很好看”到“很好用”的距离，才是当下最值得走的一段路。