企业官网建设流程全解析

我们路测车队有一天传回来的数据是12TB，负责筛选的同事在群里说：今天的录像里应该有三处高价值场景，但没人能说清在哪一分钟。这句话几乎概括了我这几年的感受——数据吞吐越来越大，模型迭代却越来越慢。直到我开始认真评估盘古大模型3.0与自动驾驶开发平台的结合，才意识到问题可能不是某个模块不够强，而是整套研发范式需要换一层逻辑。

我在自动驾驶公司做算法平台方向已经有些年头，主要工作是搭数据闭环、训练感知模型、跑仿真验证。盘古大模型3.0对外宣传的调性很响，“全面赋能”这种词我们做工程的人见得多了，但真正让我耐下性子去研究它的，是它背后那套“行业大模型+场景模型”的思路恰好撞上了我这两年最头疼的痛点：数据用不起来、场景筛不出来、仿真不像真的。

这篇就聊聊我从一个平台工程师视角看到的盘古大模型3.0，以及所谓“进化新模式”在自动驾驶开发平台上到底改变了什么、能落到什么程度、有哪些坑。

1. 传统自动驾驶开发卡在哪：规则死角、标注成本和验证周期

1.1 路测数据堆积如山，模型却在原地踏步

先说说我们自己的情况。一个中型自动驾驶测试车队，几十辆车，每天回传的原始数据加中间产物，十几个TB起步。这些数据会进入一个标准的闭环：采集、筛选、标注、训练、仿真、路测，然后循环。听起来很完整，但实际跑起来，第一个卡点就是“筛数据”。

传统做法是写规则。比如急刹车、急转向、后车切近、行人横穿，这些行为可以通过IMU信号和感知输出去触发。规则筛数据的问题在于：你只能筛出你提前定义好的事件。真正让自动驾驶翻车的往往是那些“你没想到要定义”的事件——老人推着婴儿车在货车盲区里横穿，雨夜灯光下把积水反光误判成车道线，电动自行车逆行贴着车头擦过去。这些场景不是在规则里写出来的，是在路测数据里躺着但没人发现的。

我见过最典型的例子，是某个城区路口的无保护左转，连续三个迭代周期通过率都上不去。数据回放看了一遍又一遍，问题出在前方对向直行车辆的“让行意图”判断上，但这属于语义级别的理解，传统规则和普通感知模型根本表达不了这种场景。数据在那儿，模型用不上，人就只能熬夜看视频。

1.2 标注、仿真、验证三个环节的成本瓶颈

数据筛不出来，往下就是标注。4D标注（三维空间加时间序列）的价格，做过的人都懂。一帧点云加图像，复杂的连续场景要几十块钱，一个需要模型重点学习的路口交互片段，动辄上百帧，一条路段标下来就是几千块。一个中型项目一年标注费用七位数很常见，稍微大点的项目直接奔着八位数去。

仿真这边的问题更隐蔽。传统仿真平台用的是“场景库”方案——预先搭好的道路模型、交通流模型、目标物模型，在里面注入预设的测试用例。这套东西在单车规控测试阶段够用，但对感知模型的训练帮助很有限，因为渲染出来的图像和真实传感器数据之间的domain gap太大。模型在仿真里跑得挺顺，一上实车就露馅，因为仿真器里的树影、玻璃反光、路面材质跟真实世界差了不止一个量级。

验证周期也躲不掉。每改一版模型，除了离线评测集上的回归，还要跑几百个标准仿真场景，再安排实车路测。一次完整回归流程，快则两周慢则一个月。算法团队改一个loss函数，推演结果要等三周，这种节奏直接拖死了创新速度。

1.3 问题的本质：开发平台缺一个“会思考的引擎”

把这些卡点放在一起看，底层的共性就出来了：传统开发平台是一个“规则+人力”的体系。规则负责定义边界，人力负责填补边界之外的空白。自动驾驶的长尾场景无穷无尽，规则怎么补都补不齐，人力怎么标都标不完。

问题不在某个模块的精度，而在平台缺少一个能“理解场景”的引擎。这个引擎要对路测数据有语义级别的认知，能说清楚这段视频里发生了什么；要能自动把低质量标注变成高质量标注；要能把一个真实路口的几何、光照、交互重建到仿真器里；还要能对模型的决策行为给出可解释的判断。

盘古大模型3.0进入自动驾驶开发平台，本质上就是往这个位置上塞了一个具备通用理解能力的底座。后面章节我会按平台模块一个个拆开讲。

2. 盘古大模型3.0接入开发平台的逻辑：从“工具链”变成“能力底座”

2.1 不是把聊天机器人搬上车，而是重新分层

先说一个容易误解的点：盘古大模型3.0不是让你在车端跑一个几百B参数的Transformer，那既不现实也没必要。它对外提的是一套“基础大模型+行业大模型+场景模型”的分层体系。基础层解决通用的语言、视觉、多模态理解和生成能力；行业层把通用能力和汽车行业的工程知识、传感器数据、标准规范结合；场景层则面向具体的自动驾驶任务，比如BEV感知、场景描述、数据标注、仿真生成，做定向的精调和部署。

这个分层逻辑对我们做平台的人来说特别重要，因为它解决了一个以前绕不过去的问题：通用大模型能力很强，但不懂自动驾驶的“行话”。让一个通用的视觉语言模型描述路测视频，它能说“有一辆车在路口停下来”，但说不出“该车辆在无保护左转场景中未让行对向直行车辆，存在碰撞风险”。行业层的存在，就是把后者这种专业认知注入模型。

场景层则是落地的最后一公里。自动驾驶开发平台里的具体任务——挖掘危险场景、预标注4D数据、生成仿真素材——每个都对应一个轻量化的场景模型。它们共享底座的知识，但各自负责一个具体的工程环节。

2.2 平台级接入的五个关键模块

在我眼里，盘古大模型3.0对自动驾驶开发平台的改造，不是单点替换，而是串起了一条新链路。我列了五个关键模块：

数据挖掘：用大模型对路测视频做语义级别的场景分类，自动找出“外卖车逆行”“行人鬼探头”“大车盲区交互”这类高价值事件，替代人工看视频和规则触发。

自动标注：大模型先做4D预标注，对连续帧做跨帧关联和类别打标，人工从“逐帧精标”降级为“抽检修正”，标注单位成本断崖式下降。

场景生成：利用生成式模型对真实路采场景做三维重建和编辑，比如把一个晴天路口“迁移”成雨天、夜间、逆光，批量制造真实感极高的长尾场景。

仿真评测：大模型作为评测官，对感知和决策模型在仿真中的表现做多维度分析，不只报“通过/不通过”，而是说清楚“为什么不通过、问题可能出在哪个模块”。

驾驶策略：在云端利用大模型的推理和交互理解能力，处理复杂博弈场景，再蒸馏成车端可跑的轻量模型。

这五个模块不是平行关系。数据挖掘喂给自动标注，自动标注喂给模型训练，模型训练喂给仿真评测，评测结果反哺数据挖掘，形成一个闭环。大模型在环里充当的是“理解中枢”，每个模块都被它增强，但每个模块又都保留着工程化的接口。

2.3 与传统“模块拼装”模式的本质区别

以前我们做平台是“模块拼装”：感知一个模型、融合一个模型、预测一个模型、规划一个模型，各自独立训练、独立部署、独立调参。模块之间靠接口通信，信息经过层层抽象后损失很多。最直接的体现就是，感知模型对角锥桶的检测精度已经很高了，但规划模块在锥桶引导的施工路段还是频繁犹豫，因为感知输出的只是“这里有锥桶”，丢了“这个锥桶的朝向暗示了车道往哪边偏”这样的上下文。

大模型底座式的平台不一样，它让所有模块共享同一个语义理解空间。感知、预测、决策都从这个空间里取用特征和知识，模块之间传递的是“语义”而不是“抽象后的残缺信息”。

打个比方，以前的平台是一条流水线，每个工人只干自己那道工序，零件走到哪一步就是哪一步的样子。大模型底座更像一间工作室，大家共享一块白板，每个人的工作状态都画在白板上，任何环节需要信息都可以直接从白板上取。

这里要泼一盆冷水的是，这种底层重构短期内会显著增加平台复杂度。模块独立性下降，意味着某一个模块的改动可能通过共享底座传导到其他模块，回归测试的工作量不减反增。但从更长的周期看，共享理解能力带来的效率提升会远超增加的那部分复杂度。我们自己的实测数据是，接入自动标注和场景挖掘之后，数据闭环的吞吐量提升了接近一个数量级，虽然前半程调试折腾掉不少时间。

3. 感知链路重构：多模态大模型如何解决BEV与Occupancy的难题

3.1 从单模态到多模态：一个路口场景为什么难住传统视觉

感知是整个自动驾驶栈里最吃数据、最吃算力的部分，也是盘古大模型3.0这类多模态模型最能直接发力的地方。

传统感知是单模态模型各干各的：图像模型检测目标、LiDAR模型检测目标，然后在后融合层做匹配。这套打法在晴天直道绰绰有余，一遇到复杂路口就露怯：雨雾天LiDAR点云稀疏，图像的反光、暗影扭曲了目标边界，两个模态各自输出的目标框对不上，后融合不知道该信谁。

盘古大模型3.0的多模态理解能力，让事情有了新的做法。在BEV特征融合阶段，不是等每个模态输出目标框再做后融合，而是让图像和点云在特征层面就完成对齐和融合——用跨模态注意力机制把图像里的语义细节（灯牌、车道线、行人姿态）和点云里的几何结构（距离、速度、朝向）统一进同一个BEV特征空间。这个特征空间里既保留了几何精度，又补充了语义丰富度，下游的检测头和Occupancy头都能直接受益。

3.2 大模型参与BEV特征融合和Occupancy预测的工程路线

我们实际尝试过用多模态大模型的结构来做BEV感知的骨干网络。具体工程上，是拿一个预训练好的视觉语言模型当图像分支的初始化权重，用它的文本对齐能力帮助模型理解“类别和外观之间的关系”。比如一个挎着外卖箱的电动车，传统模型可能要见几百个类似样本才能把“外卖车”和“普通电动车”分开，但预训练模型里已经内建了“外卖箱”这个概念和图像特征的关联，只需要少量数据微调就能迁移过来。

Occupancy网络那边，大模型的先验知识帮助更大。Occupancy要做的是把三维空间划分成体素网格，预测每个格子是被占据还是空闲。以前模型对“不规则物体”的泛化很差，路边停着一辆装满纸箱的三轮车，纸箱的几何形状没有训练样本，传统模型倾向把纸箱区域预测成可通行。大模型见过海量物体类别的视觉形态，三轮车、纸箱、堆叠的杂物都是熟悉的视觉概念，即便没有精确的LiDAR样本，也能通过图像语义给出“这里被占据”的提示。

这个阶段我们踩过的坑很典型：直接把大模型当在线感知骨干，推理速度根本压不下来。一个几十B参数的视觉模型跑一帧图像要用几百毫秒，而车端的实时性要求是30毫秒以内。最后方案还是回到了“云边协同”：云端用大模型做离线自动标注和难例挖掘，车端部署蒸馏后的小模型。

3.3 “蒸馏”上车：云端大模型与车端小模型的实操搭配

蒸馏这块我多说几句，因为这是大模型在自动驾驶里能否真正产生价值的分水岭。

简单说，蒸馏就是让一个大而强的“教师模型”把自己的知识教给一个小而快的“学生模型”。在自动驾驶场景里，教师模型在云端跑，可以用最大的分辨率、最全的传感器输入、最长的时序上下文；学生模型在车端跑，要满足严格的延迟和功耗约束。我们实践下来的做法是：

云端用盘古大模型3.0做多模态感知和场景理解的底层引擎，对海量路测数据生成稠密标注和语义解释；然后把这些标注作为训练数据，蒸馏训练车端轻量模型。车端模型只需要继承“识别结果”，不需要继承“推理过程”，参数量可以压到原来的十几分之一。

一个重要的实操心得是，蒸馏时一定要给教师模型加噪声。我们第一版蒸馏出来的车端模型，晴天表现和教师几乎一致，一到雨天就崩。复盘发现，教师模型在干净数据上的输出太“锋利”了，学生模型学到的全是高置信度的标准答案，对噪声完全没有鲁棒性。后来我们在教师模型的输入上叠加模拟传感器噪声——图像加亮度抖动、点云加随机丢点，让教师输出带有不确定性的软标签，学生模型反而学到了更稳健的特征表征。

4. 数据闭环进化：长尾场景挖掘、自动标注与生成式仿真

4.1 数据挖掘从“规则筛”走向“模型筛”

数据挖掘是盘古大模型3.0给数据闭环带来的第一个肉眼可见的升级。以前我们筛场景靠信号触发，现在可以靠语义理解。

这条管线跑起来的逻辑很简单，用伪代码示意一下就是：

# 场景语义挖掘伪代码：用大模型对路测片段做初步语义判断 scenes = load_segments_from_data_warehouse(last_days=7) prompt = """ 你是一名自动驾驶场景分析专家。请对以下路测感知片段描述进行判断： 1. 是否存在非机动车逆行、行人近距离横穿、车辆强行加塞等危险交互； 2. 交互参与者之间是否存在复杂的让行博弈； 3. 场景是否具备长尾训练价值。 请输出JSON格式，包含risk_level与reason字段。 """ for seg in scenes: result = multimodal_model(seg.sensor_summary, prompt=prompt) if result.risk_level == "high": push_to_training_queue(seg, reason=result.reason) elif result.semantic_value > threshold: push_to_curation_queue(seg, note=result.reason)

这套东西跑起来之后，变化的量级是惊人的。以前数据筛选组每周要人工复审上千段触发片段，现在大模型先把所有片段做粗筛，把“疑似有故事”的片段挑出来，人工只需要看大模型挑出来的结果，而且大模型还给每段配了一段语义摘要，不用从头到尾拖视频。

还有一层我们没预料到的价值：大模型会把“为什么值得训练”这类理由写清楚。比如“该场景存在行人从静止车辆前方横穿，且行人被遮挡超过2秒，模型对该区域的Occupancy预测不稳定”。这些理由直接变成了数据集的元信息，训练时可以按元信息做定向采样，而不是眉毛胡子一把抓。

4.2 自动标注管线：人机协同的标注效率提升

标注成本的下降幅度，保守估计在60%到70%，激进一点说80%也不夸张。原因是工作量结构变了。

传统4D标注，标注员要逐帧画框、逐帧关联ID。大模型做预标注之后，标注员只需要做两件事：第一，检查大模型输出的类别和轨迹有没有错；第二，对模糊场景做修正。一个片段的标注时间从半小时压缩到几分钟。

里面有一个特别容易翻车的细节：大模型预标注的错误往往不是“完全错误”，而是“看起来正确但不精确”。比如车道线偏移了两个像素、目标框缺了一个角，肉眼粗看没问题，模型训练出来之后精度就是差那么几个点。我们的对策是强制人工对关键帧做100%精查，非关键帧做抽样检查，并且每年做一次标注质量审计，抽调不同标注员对同一批数据重新标注，计算一致率。

另外，自动标注不能只标感知框，还要标“语义”。路口的红绿灯状态、施工区域的引导线方向、前车刹车灯的亮灭，这些属性传统标注流程经常漏，但对决策模型至关重要。大模型做这类属性标注几乎是零成本——它看一眼图像就能告诉你“这辆车的转向灯在闪”，人工逐个标注则是巨大的时间黑洞。

4.3 生成式仿真：补上极端场景与传感器差异的缺口

实车路测跑一百万个场景，也很难覆盖所有的高危交互。生成式模型要做的就是填补这个缺口。

我们试过两条路线。第一条是场景重建，拿路采数据做三维高斯溅射或者NeRF重建，把真实路口的几何结构和材质渲染进仿真器。重建出来的场景相比传统手工建模，真实感提升非常明显，感知模型在这样的仿真场景里测试，性能和实车表现的相关性更高了。第二条是场景编辑，在重建好的场景里做语义编辑——把一个晴天场景的全局光照改成雨天，给路面叠加积水反光，把路边停着的车挪个位置让视野遮挡关系改变。这相当于在真实数据的基础上“批量制造”变体，一个路口可以衍生出几十种天气、光照和交通流组合。

做这套东西时，计算资源消耗很大。生成一组高质量重建场景的GPU时间和成本不是小数，但如果对比的是“为了收集一个雨天路口的数据而专门派车队去等一场雨”，这笔账其实是划算的。

生成式仿真现在已经可以支撑一部分开放道路测试的预验证。以前开放道路测试前要盲跑，现在可以先在生成场景里把模型跑一遍，把明显会出问题的版本直接挡在上路之前。

5. 决策规划与安全验证：大模型的边界和上车前的硬约束

5.1 交互预测与社会行为建模：大模型的推理优势

感知之外，盘古大模型3.0在交互预测上展现出来的能力，比我想象中更有想象力。

传统的预测模块做的是轨迹回归：根据目标的历史轨迹预测未来几秒的位置分布。这套方法对直线行驶和巡航工况很有效，但一到博弈场景就抓瞎。典型的例子是无保护左转：你对向直行车的驾驶员可能在加速通过，也可能减速让你过去，这个决策不取决于它自己的运动学状态，而取决于它对你的行为意图的理解。传统预测模型看不到这一层。

大模型在这里能做的事情，是把“交互”抽象成一种社会行为推理。它可以根据场景上下文，推断出“对向车辆可能认为我停下了，所以它会加速通过”这样的高阶语义，然后把这种语义转化成多模态的轨迹假设。我们实测过，在高度博弈的路口场景，这类语义引导的预测模型相比传统轨迹回归模型，交互场景下的预测误差下降了接近三成。

当然，这种推理能力是从大量视频数据里学来的，不是程序写出来的规则。这意味着它会有“想当然”的时刻，所以下游规划模块必须对预测结果做安全边际处理，不能被带偏。这引出了下一节的安全验证问题。

5.2 安全验证怎么做：SOTIF、回归测试与版本管理

从工程上看，大模型给决策链增加了不确定性的方差，安全验证的复杂度相应上升。SOTIF（预期功能安全）的框架对这类问题有一些指导性思路：要识别触发条件、评估风险、建立缓解措施、验证剩余风险是否可接受。

落到实操上，我们做的事情分三层。第一层是离线场景库回归：几千个标准场景加上上万个大模型生成的长尾变体，每次模型更新都要全量回归，不允许通过率回退。第二层是实车路测抽检：按城市、天气、时段分层抽样，保证新版本在真实交通里的表现和离线评测一致。第三层是异常监控：车上常驻一个异常检测器，当感知或决策模块的置信度低于阈值时，自动降级到保守策略。

版本管理这里有一个很现实的挑战：大模型版本的语义变化不好量化。传统模型的版本差异可以用指标数值来衡量，比如mAP涨了多少。大模型改一版底座，可能90%场景表现都提升了，但某几个极端场景的行为完全变了，这几个变化如果没被场景库覆盖到，就是安全隐患。我们的对策是用“语义回归”的思路：给每个版本的大模型做一次大规模的场景语义聚类评测，把行为变化的场景自动聚类出来，逐一确认变化是否符合预期。

5.3 幻觉与可解释性：自动驾驶必须守住的风险底线

大模型在自动驾驶里最让人紧张的两个词，一个是幻觉，一个是黑盒。

幻觉的问题我已经提过：模型可能“脑补”出并不存在的障碍物。在文本生成场景里，幻觉顶多让聊天内容变离谱；在自动驾驶场景里，一个不存在的障碍物直接导致急刹或者绕行，在高速上就是致命风险。

工程上有一些缓解手段。一是在输出端加物理一致性校验：感知模型报出一个障碍物，必须和LiDAR点云或图像特征有可验证的对应，否则标记为低置信度。二是用规则兜底：大模型感知可以作为主要来源，但安全相关的决策必须经过规则层的交叉验证。三是数据层面的治理：对容易触发幻觉的高风险输入类别，专门构建对抗样本做训练集扩充，压低幻觉发生频率。

可解释性虽然没有安全需求那么紧迫，但对开发和监管都很重要。盘古大模型这类架构，可以通过attention可视化、文本解释生成等手段，让工程师至少在模型做出激进决策时看到依据。我们内部建了一个“决策解释回放”工具：模型每次输出高风险决策，都会附带一条文本摘要说明关键依据。这些摘要能帮我们快速定位是感知问题还是预测问题，调试效率比对着黑盒分析快得多。

6. 落地之后的三点冷静判断

6.1 算力和成本：先算清楚投入产出比

说了这么多赋能，回到现实层面，第一个绕不开的就是钱。盘古大模型3.0走的是云端重计算路线，训练一个行业底座或者跑大规模自动标注，GPU成本是传统方案的好几倍。拿我们自己的账算，一年路测数据全量用大模型过一遍，光是推理成本就够买好几台测试车。

所以我的建议是“梯度接入”：数据挖掘和自动标注这类离线任务，可以全量接入大模型，因为容忍延迟且能摊薄成本；车端感知和规划，只接蒸馏后的小模型，绝不在车上跑大模型；仿真评测这类中间任务，按批次接入，不需要实时。

但千万别指望大模型能省钱。它带来的是质量提升和人力释放，不是直接的算力下降。如果团队预算紧张，优先做数据挖掘和自动标注这两块，这是投资回报率最高的切入点。

6.2 卡点不在模型本身，而在数据质量与工程化

盘古大模型3.0把行业大模型这个层做起来之后，模型能力本身已经不是瓶颈了。真正的瓶颈在两端：一端是数据质量，另一端是工程化。

数据质量的问题在于，大模型是“喂什么就学什么”。如果路测数据采集本身有盲区，比如传感器配置不统一、标定漂移没校正、夜间低照度数据占比太少，那么大模型再强也学不出安全可靠的驾驶能力。我们后来花了大半年把数据采集规范重写了一遍，各车型传感器配置统一，增加夜间和雨雾天路测排班，这些动作比调任何模型参数都管用。

工程化的问题在于，大模型的接入不是一次性的开发工作，而是一个持续运营的系统工程。模型要迭代、数据要持续回流、效果要持续评估。没有一支足够强的基础设施团队，别说落地，连跑通都费劲。

6.3 团队架构要跟着变：从“调参”转向“训模型”

最后这点可能对团队管理者更有用。盘古大模型3.0这套东西进入开发平台之后，团队的角色构成会发生明显变化。传统算法工程师的核心技能是调网络结构、调loss、调训练参数；新模式下，更多的时间会花在数据策略、评测策略、提示词设计和教师模型的训练管理上。

我们现在团队里新增了两个角色：一个是数据策略工程师，负责设计数据回流和难例挖掘的方案；另一个是模型运营工程师，负责管理教师模型的版本、评估行为变化、和车端模型对齐。原有的调参工程师不是消失了，而是转型成“在底座之上做适配”的工程师。

从我个人这几年的实际感受来说，自动驾驶研发的比拼已经不在单点模型的精度上，而在数据闭环的效率和工程体系的成熟度上。盘古大模型3.0这一类行业大模型，提供的恰恰是让闭环转得更快、让工程体系更集约的能力底座。真正拉开差距的，还是一家公司能不能把这个底座用好，把它沉淀成自己数据飞轮的一部分。