通用大模型上车之后，智驾公司还剩哪条路

一、一次低速测试，为什么值得认真讨论

近期，一项独立评测让通用大模型通过工具接口直接控制一辆真实乘用车，在封闭场地内完成起步、绕桩、倒车和入位。全程约一百三十多米，测试车辆平均时速只有每小时一点五公里左右，部分模型完成率很低，只有少数模型在多次尝试后完成整套动作。

表面上看，这样的成绩距离量产智驾系统差距巨大。真实量产系统已经在城市开放道路上处理红绿灯、无保护转弯、人车混行和复杂车流，头部方案的平均接管里程不断拉长，日均被大量用户用于通勤。而通用大模型控制真车的这次测试，只是低速、封闭、简单路线、多次试错后完成，既没有随机行人，也没有连续城市交通流。

但这件事仍然值得认真对待。原因在于：这可能是第一次有通用大模型没有经过专门的驾驶策略训练，仅仅依靠跨领域知识与工具调用能力，就控制真实车辆完成了一套完整动作。它的意义不在于跑得多快、多稳，而在于验证了一条此前停留在设想中的路径是否走得通。

这背后隐藏着一个更关键的问题：当通用模型开始具备“控制真实物理系统”的入口，智能驾驶公司过去积累的那套以规则、模块、专家知识和工程堆叠为核心的研发体系，是否还具备长期壁垒。

---

二、从模块化智驾到模型驱动智驾：范式差异

过去十年，量产智驾系统的主流架构可以概括为“感知—预测—规划—控制”的模块化链路。每一层都有专门团队负责，使用不同类型的数据与模型，输出结构化结果，再层层传递。这种架构强调可解释、可验证、可回溯，也更适合功能安全与工程落地。

但这种架构也存在明显问题。

第一，误差在链路中逐层累积。感知的漏检会造成预测偏差，预测的不准确会传导到规划，规划输出的不自然轨迹最后交给控制层执行，问题定位困难、优化成本高。

第二，每一层都需要大量专门数据。障碍物检测、意图识别、轨迹预测、行为决策、轨迹规划、控制参数，每一步都可能训练独立模型，导致数据需求分散，且难以形成统一的知识表征。

第三，系统能力由大量规则与边界条件维持。工程师不断为长尾场景补规则，系统越来越复杂，但泛化能力并未线性提升。

而模型驱动智驾的提法，其核心不是简单引入一个大模型作为组件，而是尝试用更统一的模型去吸收过去多个模块承担的职责。比如，让模型直接理解场景、推理交通参与者意图，并在一定约束下输出可执行的驾驶行为，而不是先检测再决策、再规划、再控制。

这种范式变化带来几个显著优势。

首先是知识复用。通用大模型在语言、视觉、物理常识、逻辑推理和工具调用上已有广泛训练，虽然这些能力不直接等于驾驶能力，但可以作为学习驾驶策略的先验基础，降低从头训练的成本。

其次是端到端优化的可能性。当系统从多模块串联走向更统一的模型表达，很多中间量可以被隐式学习，减少人工定义和逐级误差。

第三是更强的意图理解与交互能力。传统系统更擅长处理结构化目标，而模型驱动方案有机会理解模糊指令、解释自身决策，并与乘客进行更自然的人机交互。

但范式切换并不意味着简单替换。驾驶是安全性要求极高的实时控制任务，通用大模型的输出需要经过严格约束、校验与兜底，概念可行与工程可用之间还有巨大距离。

---

三、通用大模型控制真车的工程含义

通用模型控制车辆，本质上是把车辆控制能力作为一种“工具调用任务”来对待。模型接收传感器信息与场景描述，输出驾驶动作或意图，再由车辆控制接口执行。这与常见的函数调用、代码执行、机器人操作等任务在结构上相似，只是对象从数字世界变成了高速运动的物理系统。

这一路径如果继续发展，可能带来几种影响。

第一，降低跨平台部署的边际成本。传统智驾系统需要针对不同车型、不同传感器配置做大量适配和标定。如果模型能够理解通用环境语义并输出相对稳定的行为策略，底层差异可以被抽象为工具接口差异，从而减少重复开发。

第二，加速数据飞轮形成。模型驱动方案天然更容易吸收跨任务、跨场景的数据。一旦具备批量部署入口，每一次真实驾驶都可以成为训练信号的来源，迭代速度可能显著快于传统模块化系统。

第三，改变竞争要素。过去的竞争集中在规则数量、工程整合能力和长尾场景覆盖率；模型驱动时代的竞争可能转向数据规模、模型训练效率、安全约束能力和算力基础设施。

但同样要看到当前通用大模型控制车辆的明显局限。

从测试表现看，低速、封闭场地、简单路线已经需要多次尝试，说明模型对物理状态、空间关系、运动约束的理解仍不稳定。真实驾驶中，车辆在几十毫秒内就要做出合适决策，同时还要保证安全、舒适、合法。这种实时性、可靠性和确定性要求，远不是当前通用模型所能满足。

因此更现实的路径，不是让通用大模型直接开车，而是让它在合适的位置发挥作用：例如场景理解、行为预测、决策建议、异常检测、端到端模型中的语义先验等。

---

四、窗口期两三年：智驾公司的真实选择

有观点认为，智驾公司如果不能在两到三年内完成向大模型范式的转型，可能面临被降维打击的风险。这个判断的核心逻辑不在于通用大模型短期内能替代量产智驾，而在于技术迭代曲线已经发生改变。

传统智驾系统的演进更像线性工程积累：更多规则、更多场景、更多测试、更多边缘案例。而模型驱动系统的演进更接近能力跃迁：数据规模、模型规模、训练方法和通用能力提升会共同推动系统上限抬升。

当通用模型的工具调用能力、空间推理能力和多模态交互能力持续增强，驾驶任务在技术上越来越像一种可以被更通用能力覆盖的特例。即使短期无法达到量产安全标准，它也在不断压缩传统技术栈的相对价值。

在这个窗口期内，智驾公司大致有三条路径。

路径一：全栈转为模型驱动

这类公司会尝试减少传统模块数量，构建端到端或接近端到端的车端模型，同时建立云端数据闭环与大规模训练能力。优势在于技术路线彻底，长期竞争力更强；风险在于工程落地的安全稳定性难以快速达到量产标准，尤其在复杂城市场景中。

路径二：混合架构渐进过渡

保留传统模块作为安全兜底和可验证骨干，同时引入模型驱动能力处理复杂场景和长尾任务。比如用大模型做场景理解、风险预判或生成候选驾驶意图，再交由传统规划控制模块验证执行。这种路径更适合有量产压力的公司，但需要解决两套系统之间的接口设计与协同问题。

路径三：聚焦域控与工程服务

部分公司可能不再追求完整智驾系统，而是聚焦于模型驱动的数据平台、评测体系、安全机制或计算基础设施。这类角色更偏工具与生态，而不是直接面向终端用户提供驾驶能力。

无论走哪条路，一个共同前提是：公司需要具备模型训练、数据闭环、仿真评测和车端部署的工程能力，而不是只停留在研发演示阶段。

---

五、模型驱动智驾的五个关键工程问题

1. 安全边界如何构建

传统智驾可以通过功能安全分解、规则校验和冗余设计来保证基本安全。模型驱动方案中，黑盒程度上升，可解释性下降，必须有独立于模型的安全层。比较常见的思路包括：行为约束、物理约束、规则校验器、安全包络监控等。无论模型输出什么，最终都要经过确定性的安全检查。

2. 实时性如何保证

车端计算资源有限，通用大模型无法直接满足高频推理需求。现实做法通常是分层：大模型做低频的场景级理解与决策建议，小模型或规则系统做高频的轨迹生成与控制。这又回到了混合架构的工程复杂度。

3. 数据闭环如何建立

模型驱动系统需要海量高质量数据。数据采集、清洗、标注、回传、训练、评测、再部署，整个闭环周期越短，系统迭代越快。这背后依赖云端的对象存储、数据处理、训练平台和模型发布系统等基础设施。

4. 泛化能力如何验证

传统智驾测试强调固定场景和明确通过标准。模型驱动系统的行为更多样，如何设计有效的仿真测试、对抗测试和真实路测，证明系统在未见场景中的安全性，是一个尚未完全解决的问题。

5. 组织能力如何重构

智驾公司过去以感知、预测、规划、控制等模块划分团队。模型驱动架构下，团队需要围绕数据、模型、评测和安全机制重新组织。这种组织转型的难度往往不亚于技术转型。

---

六、大模型不是万能钥匙，但会成为新的底座

当前阶段，通用大模型控制真车更多是一次技术验证，而不是成熟产品能力的证明。它跑得慢、不稳定、依赖多次尝试，距离真实量产智驾系统还有明显距离。但这并不意味着可以忽视其方向意义。

过去智驾行业的竞争，本质上是工程集成能力与场景覆盖能力的竞争。当大模型开始展示出对物理系统进行通用控制的可能性时，行业原先的竞争坐标系就出现了变化。那些不能完成模型化转型的公司，未必会立刻消失，但会逐渐从技术前沿退到集成边缘，最终失去定义下一代系统的资格。

未来的智驾系统，很可能不是“大模型直接开车”，而是以大模型作为理解、推理和交互的底座，与确定性规划、安全控制和车端实时系统深度结合。这种结合既需要模型能力，也需要工程能力，更需要云端基础设施与数据闭环支撑。

对行业从业者而言，现在最值得做的不是争论“通用大模型会不会开车”，而是认真评估自身团队是否具备模型驱动系统的搭建能力、安全验证能力和快速迭代能力。窗口期不会等人，技术趋势一旦越过关键拐点，后来的追赶成本会变得极高。

智驾公司只剩一条路：不是放弃自己的积累，而是把积累迁移到新的技术轨道上。