通用大模型之后，智能驾驶企业如何突围

一、一次低速测试，为什么会引发行业焦虑

当通用大模型能够通过视觉输入和工具接口，控制车辆在封闭场地完成起步、转向、绕障、倒车和停车等连续动作时，其技术意义并不在于行驶速度有多快，也不在于路线有多复杂，而在于它验证了一种新的能力边界：未经特定驾驶任务深度定制的模型，也可能理解环境、拆解目标并调用外部执行机构完成物理任务。

不过，这类测试通常具有非常明确的限制条件：

• 场地封闭，交通参与者数量少；
• 行驶速度较低，留给模型的决策时间较长；
• 路线和任务相对简单；
• 允许失败后重新尝试；
• 不需要长期连续运行；
• 通常不覆盖雨雪、逆光、遮挡和施工改道等复杂条件。

因此，它不能直接证明通用大模型已经具备量产智能驾驶能力。真实道路系统需要在几十毫秒到数百毫秒的时间尺度内持续完成感知、预测、规划与控制，还要应对通信中断、传感器污染、算力降频、执行器延迟和其他道路参与者的随机行为。

这意味着，封闭测试与量产系统实际上处于两个不同的评价坐标系中。

前者关注的是“模型是否表现出通用驾驶认知的萌芽”，后者关注的则是“系统能否在明确的安全边界内长期稳定运行”。两者并不矛盾：测试结果尚不足以替代现有量产方案，却可能预示下一代技术架构的方向。

二、通用大模型带来的不是功能增加，而是范式变化

传统智能驾驶系统通常由多个相对独立的模块组成，包括目标检测、车道识别、目标跟踪、轨迹预测、行为规划、运动规划和车辆控制。每个模块拥有自己的输入、输出和评价指标，工程团队可以分别优化。

这种模块化方案具有较强的可解释性和可调试性，但也存在明显问题。

第一，模块间的信息传递会造成语义损失。例如，感知模块可能只输出目标类别、位置和速度，却没有保留道路参与者的姿态、意图和上下文关系。

第二，误差会逐级传播。上游一次轻微误检，可能在预测模块中被放大，最终导致规划结果不稳定。

第三，大量复杂场景依赖人工规则补丁。规则不断叠加后，系统容易出现条件冲突，维护成本也会快速上升。

大模型范式试图通过更统一的表示空间处理视觉、语言、地图、车辆状态和历史轨迹，使系统能够基于上下文理解场景，而不只是识别孤立目标。例如，模型不但要看到前方存在一名行人，还要结合行人的朝向、道路结构、信号状态和附近车辆行为，判断其是否可能横穿道路。

更重要的是，大模型可以将“驾驶任务”表示为连续的决策问题，而不是大量彼此割裂的分类任务。它带来的潜在变化主要体现在四个方面：

1. 从目标识别走向场景理解
   系统需要理解道路参与者之间的关系、交通规则约束以及潜在风险，而不是只生成检测框。

2. 从局部预测走向长时序推理
   驾驶决策往往需要考虑数秒甚至更长时间范围。模型需要理解当前动作对后续通行空间的影响。

3. 从规则驱动走向数据与模型共同驱动
   明确的安全规则仍然不可缺少，但大量长尾行为将更多依赖数据学习，而不是逐条编写逻辑。

4. 从单任务模型走向统一基础模型
   数据标注、仿真生成、场景理解、驾驶决策和问题诊断可能共享部分基础能力，降低模型体系的碎片化程度。

因此，所谓“向大模型转型”，并不是在现有系统旁边增加一个对话模块，也不是用自然语言直接控制方向盘，而是重新设计数据、训练、推理、验证和安全架构。

三、智能驾驶企业是否只剩一条路

从技术方向看，行业可能逐步收敛到以大规模数据和统一模型为核心的路线；但从工程实现看，不会只剩下一种架构。

不同企业可以选择不同程度的融合方式。

1. 大模型作为离线教师

这是风险相对较低的路径。大型模型在训练环境中分析复杂场景、生成语义标签、补充轨迹信息，或者为轻量车端模型提供监督信号。最终部署到车辆上的仍然是经过压缩和专项优化的小模型。

这种方案有利于控制时延和算力成本，也便于沿用既有量产系统，但车端模型的泛化能力可能受到压缩程度限制。

2. 大模型作为高层决策器

模型负责理解场景并生成行为级决策，例如等待、跟车、绕行、变道或者减速让行；底层轨迹生成与车辆控制仍由确定性较强的模块完成。

这种分层方式可以兼顾语义理解和执行稳定性，也是较容易建立安全边界的路线。即使高层模型输出异常，底层约束模块仍可拒绝危险动作。

3. 端到端生成驾驶轨迹

系统直接从多传感器输入和车辆历史状态生成未来轨迹，减少人工设计的中间接口。其优势是能够联合优化整体驾驶效果，但问题定位、边界验证和安全解释更困难。

真正的量产系统通常不会毫无约束地执行生成结果，而是在输出端增加动力学约束、碰撞检查和安全仲裁。

4. 统一模型与确定性安全系统并行

更现实的架构是“双系统”：学习型模型负责提供更强的环境理解和驾驶候选方案，确定性系统负责检查道路边界、车辆动力学、碰撞风险和法规约束。

其基本逻辑可以抽象为：

环境输入 -> 学习模型生成候选轨迹
        -> 轨迹约束检查
        -> 风险预测
        -> 安全仲裁
        -> 执行或降级

由此可见，行业真正趋同的不是某一种模型结构，而是几个基础原则：扩大高质量数据规模、提高模型泛化能力、建立快速闭环，并通过独立安全机制约束模型输出。

四、从演示走向量产，需要跨越五道工程门槛

1. 实时性门槛

通用模型通常追求能力覆盖面，而车载系统更强调确定性时延。车辆不能因为某一帧计算耗时增加，就暂停决策。

工程上需要关注的不只是平均推理时间，还包括高分位时延、启动时间、内存峰值、温度变化下的算力波动以及多个任务并发时的资源争抢。即便平均响应速度足够快，只要偶发长尾延迟不可控，就可能影响安全。

因此，车端部署通常需要进行模型裁剪、低精度计算、算子融合、分层推理和缓存复用。对紧急制动等高优先级任务，还应预留独立计算资源。

2. 数据闭环门槛

大模型并不会自动解决长尾问题。它仍然依赖覆盖充分、分布合理且质量稳定的数据。

完整的数据闭环至少包括以下环节：

1. 车辆侧识别异常或低置信度片段；
2. 对原始数据进行脱敏、筛选和去重；
3. 按风险类型和场景特征进行聚类；
4. 通过自动标注与人工复核生成训练数据；
5. 将问题样本加入训练或微调集合；
6. 在仿真、封闭场地和道路测试中回归验证；
7. 通过灰度机制发布新版本；
8. 持续监控新版本是否引入能力退化。

关键问题不是企业累计了多少行驶里程，而是数据中包含多少有效信息。大量重复的直行数据，对解决遮挡行人、异形障碍物和临时施工等问题帮助有限。

高质量闭环应优先发现“模型不知道自己不知道”的场景。可以通过预测不一致、模型集成分歧、低置信度、异常接管和轨迹突变等信号进行挖掘。

3. 安全约束门槛

生成式模型存在输出波动，不能将其结果直接视为可执行指令。量产架构必须在模型与车辆执行机构之间建立安全闸门。

示意逻辑如下：

def select_safe_trajectory(model_output, vehicle_state, environment):
    candidates = decode_candidates(model_output)
    valid = []
    for trajectory in candidates:
        if not satisfies_vehicle_dynamics(trajectory, vehicle_state):
            continue
        if crosses_drivable_boundary(trajectory, environment):
            continue
        if collision_risk(trajectory, environment) > allowed_threshold:
            continue
        valid.append(trajectory)
    if not valid:
        return generate_minimum_risk_action(vehicle_state)
    return choose_lowest_risk_candidate(valid)

这段逻辑体现了一个重要原则：模型可以负责提出方案，但不能独占最终决定权。当全部候选轨迹不满足约束时，系统应进入最小风险状态，例如平稳减速、保持车道或请求驾驶员接管，而不是强行选择一个不安全结果。

此外，安全模块应尽可能与主模型保持一定独立性。若安全判断与驾驶模型共享完全相同的数据、参数和故障模式，两者可能在同一场景中同时失效。

4. 评价体系门槛

只看“是否完成路线”远远不够。量产智能驾驶需要多层指标体系。

模型层指标包括：

• 目标识别与场景理解准确率；
• 未来轨迹预测误差；
• 不确定性估计质量；
• 不同天气与光照条件下的稳定性。

规划层指标包括：

• 碰撞风险；
• 越界率；
• 急加速、急减速和方向突变次数；
• 轨迹可执行性；
• 对交通规则的遵守情况。

系统层指标包括：

• 接管频率与接管原因；
• 严重事件间隔；
• 关键任务时延；
• 系统可用率；
• 软件升级前后的能力回归情况。

用户体验层还要考察通行效率、舒适性、驾驶风格一致性，以及系统行为是否容易被驾驶员理解。

尤其需要警惕单一平均指标。某系统可能在绝大多数简单道路上表现优秀，却在某一类高风险场景中反复失败。安全评价必须同时关注总体水平和关键场景下限。

5. 成本与交付门槛

模型能力提升并不必然带来商业成功。智能驾驶系统最终需要进入量产车辆，这意味着企业必须同时考虑计算平台成本、传感器成本、功耗、散热、软件维护、数据存储和持续训练费用。

若新模型需要大幅增加车端算力，却只带来有限体验提升，其商业价值可能无法覆盖成本。企业需要建立“能力收益—资源消耗—风险变化”的综合评估机制，而不是单纯追求参数规模。

五、未来竞争的核心是闭环效率

当基础模型能力逐渐普及时，模型本身可能不再构成唯一壁垒。真正拉开差距的，是企业将道路问题转化为模型改进的速度。

高效闭环需要解决三个问题。

第一，能否快速发现问题

车辆每天产生大量数据，不可能全部上传和人工检查。企业需要在车端或数据处理环节识别高价值片段，包括异常刹车、规划抖动、驾驶员突然接管、模型间预测分歧以及罕见道路结构。

第二，能否准确解释问题

一次接管可能来自感知漏检、意图预测错误、规划过于激进，也可能只是用户偏好不同。如果无法定位根因，训练数据就可能被错误使用，甚至造成模型退化。

因此，需要建立从车辆日志、传感器输入、模型中间结果到最终控制指令的完整追踪链路。模型越趋向端到端，越要增强离线可观测性。

第三，能否安全地修复问题

模型更新不能只验证目标场景，还要检查其他能力是否退化。每次迭代都应经过固定回归集、风险场景集、仿真测试、封闭测试和受控道路验证。

对于高风险变更，还应保留版本回退和分阶段发布能力。一旦监控指标异常，系统能够及时停止扩大发布范围。

六、组织结构也必须随技术范式调整

大模型转型不仅是算法部门的任务。它会改变数据、研发、测试和交付团队之间的协作方式。

传统组织常按感知、预测、规划和控制进行划分，团队分别维护各自指标。统一模型出现后，问题可能跨越多个传统边界。例如，一个转弯失败案例可能同时涉及视觉理解、历史状态建模、轨迹生成和安全约束。

企业需要建立以场景和闭环为中心的协作机制：

• 场景团队定义问题和验收标准；
• 数据团队负责样本发现、治理与版本管理；
• 模型团队负责训练与能力分析；
• 系统团队负责车端部署和资源优化；
• 安全团队独立完成风险审查；
• 测试团队维护分层回归体系。

同时，企业应避免把所有问题都归因于“模型规模不够”。数据分布错误、评价集失真、传感器标定偏差和控制参数异常，同样可能导致驾驶体验下降。

七、中小型智能驾驶企业如何选择转型路线

并非所有企业都具备从零训练大型基础模型的资源。对资源有限的团队而言，更合理的策略是围绕自身优势构建差异化能力。

第一，聚焦明确的道路环境或车辆类型，在有限范围内做深数据闭环，而不是一开始追求覆盖所有场景。

第二，将通用模型更多用于离线数据处理、场景理解、自动标注和测试生成，避免直接承担全部实时控制任务。

第三，保留成熟的安全控制与规则体系，通过分层架构逐步引入学习型能力，降低一次性重构风险。

第四，强化数据治理。数据来源是否合法、标注过程是否可追踪、训练集与测试集是否存在泄漏，都会影响最终系统的可信度。

第五，把可验证性视为产品能力。能够清楚说明系统在哪些条件下可用、何时会降级、如何处理异常，比展示少量理想案例更有价值。

八、结论：方向正在收敛，胜负仍取决于工程能力

通用大模型控制真车的实验具有重要象征意义，它说明语言、视觉、推理与工具调用能力正在进入物理世界。但低速封闭测试与量产智能驾驶之间，仍隔着实时计算、数据闭环、安全验证、成本控制和法规适配等多重门槛。

因此，智能驾驶企业并不是只剩下“直接使用更大模型”这一条路。真正不可回避的，是从依赖规则堆叠和孤立小模型，转向以数据闭环、统一表征和持续学习为核心的开发范式。

未来能够留下来的企业，未必拥有参数规模最大的模型，但大概率具备以下共同特征：

• 能持续获得并治理高价值数据；
• 能把复杂道路问题快速转化为训练任务；
• 能在有限车端资源下稳定部署模型；
• 能以独立安全系统约束学习模型；
• 能通过严格评价证明每次迭代没有引入新的风险；
• 能将技术能力转化为可量产、可维护、可持续升级的系统。

大模型打开的是新的能力上限，而决定企业能否穿越行业洗牌的，仍然是完整、稳健且可验证的工程体系。