如果你问一个圈外人“自动驾驶到底涉及哪些技术”大概率得到的回答是“AI算法”“深度学习”这类笼统说法。但真正在量产项目里待过一阵子就会明白自动驾驶从来不是一个算法问题而是一条从传感器到转向电机、从车端到云端的完整技术链——任何一环掉链子整台车都只能在测试场里原地打转。这是自动驾驶系列的第一篇我把整张全景图摊开来写清楚。无论行业里的哪家玩法骨架都逃不出“感知—决策—控制”这条主链路再加上高精地图与定位、算力平台、软件栈、数据闭环、车路协同这些横切组件。这篇文章适合刚入行的学生、想转岗自动驾驶的软件工程师以及需要跟研发团队对齐认知的产品和项目经理——看完你能拿到一张属于自己的技术地图后面几篇我再逐个模块往深里挖的时候你至少不会迷路。1. 先拆框架自动驾驶是一台“感知—决策—执行”的闭环机器1.1 三层主链路和它们的“时间边界”自动驾驶系统最朴素的类比就是人开车眼睛和耳朵负责感知大脑负责判断手脚负责执行。机器版本的“眼睛”是摄像头、雷达、激光雷达“大脑”是决策规划算法“手脚”是线控底盘和转向/制动执行器。三个部分串成一个闭环以固定频率循环运转。这个循环的频率直接决定了系统能不能安全兜底。我算一笔账一辆车以72km/h行驶时每秒前进20米。感知模块处理一帧传感器数据通常要100毫秒左右决策规划给出轨迹要50毫秒左右控制模块下发指令并等执行机构响应又要50毫秒左右。算下来端到端延迟大约200毫秒对应4米的行进距离——这还只是理想情况。所以工程师嘴上常挂着的“实时性”从来不是纸面指标而是用米和毫秒算出来的安全余量。各模块之间的时间同步、超时降级、新旧数据一致性都是量产项目里最耗时的工程问题之一。很多人误以为自动驾驶的难点全在“算法聪不聪明”真正做过的人会告诉你让每个模块在严格的时序约束下稳定协作难度一点都不比算法低。这也是为什么行业招人时既看重算法能力也看重系统工程能力。1.2 三条横切支撑线地图定位、算力底座、数据闭环除了纵向的感知—决策—控制还有三条横切的技术线贯穿整个系统。第一条是高精地图与定位它给车辆提供一个“我在哪、路在哪”的先验坐标系第二条是车载算力平台与软件架构它决定你手里有什么级别的“脑子”来跑模型和算法第三条是数据闭环包括仿真、实车路测、数据回传、模型迭代它决定系统能不能越跑越聪明。这三条线不是点缀是主链路能跑起来的前提。没有高精地图感知就只能像蒙着眼走路每个路口都要现场推理没有足够算力再好的算法也只能降频运行没有数据闭环系统永远处理不了那20%的长尾场景。第一篇文章强调框架就是为了让你别一头扎进某个算法细节却忘记这些东西是互相咬合的。1.3 分级和ODD别把“能做”和“处处能做”混为一谈聊技术之前还得先把分级这关过了。行业通行的是L0到L5的分级L0是纯人工L1/L2是辅助驾驶驾驶员仍是责任主体L3以上系统在特定条件下承担驾驶责任L4/L5则是高度或完全自动驾驶。这串分级背后藏着一个更重要的词——ODD运行设计域。简单说就是系统在什么路况、什么天气、什么速度范围下才能启用。比如同样一套系统在晴天封闭高速上可能表现优秀一进雨天城市道路就能力断崖。我说这个是因为太多人只看“支持L2”“接近L3”这种宣传口径却忽略了ODD的限定。任何一套量产系统的能力边界都是由ODD刻画的。看懂架构前先看懂这个边界后面聊感知、决策时你才知道它们各自在为什么样的ODD服务。2. 感知层摄像头、激光雷达、毫米波雷达各怀绝技也各有软肋2.1 三类主力传感器的工作原理与数据形态感知层是自动驾驶的“眼睛”目前量产系统基本绕不开三类传感器。摄像头是唯一能提供丰富语义信息的传感器。它像人眼一样被动接收环境光输出二维RGB图像能分辨红绿灯颜色、车道线、交通标志、行人动作这类“细活”。但它有两个天生短板一是没有直接的深度信息要靠双目视差或模型估计二是在暗光、逆光、大雾天气下表现明显变差。激光雷达是主动测距选手向空间发射激光束并根据回波时间计算距离输出高精度三维点云。它的好处是几何测量精准、不受光照影响晚上和白天表现接近坏处是受雨雪雾衰减明显、点云在远距离会变稀疏而且过去几年价格虽大幅下降但相对摄像头仍是成本大头。毫米波雷达靠发射电磁波并分析多普勒频移来测距测速测速能力极强、作用距离远、全天候适应好是自适应巡航、自动紧急制动的传统主力。它的弱点是角分辨率有限点云稀疏很难像摄像头那样把目标“认”得很细——有时候会把路边的金属护栏也当成静止障碍物。另外低速泊车场景还会用到超声波雷达属于短距离“近身感知”。2.2 一张表看懂三类传感器的核心差异维度摄像头激光雷达毫米波雷达输出数据RGB图像三维点云稀疏点/目标列表测距方式双目/模型估计激光飞行时间电磁波多普勒语义识别强弱弱测速能力弱中等强暗光/逆光差不受影响不受影响雨雾雪较差衰减明显较好成本趋势低大幅下降但仍较高低典型用途车道线、交通灯、目标分类障碍物轮廓、可行驶区域ACC/AEB、中远距离测速看这张表能发现一个规律没有任何单一传感器能同时具备“看得清”“测得准”“扛得住坏天气”三个优点。摄像头语义强但缺深度激光雷达几何准但怕恶劣天气毫米波雷达全天候但分不清细节。所以行业共识从来不是“哪个好就堆哪个”而是把不同传感器组合起来互相补位——这正是传感器融合要解决的核心问题也是2.3要展开的内容。2.3 传感器融合为什么不是硬件堆料就完事我在一些评审场合见过一种误判传感器数量越多越安全。实际上多传感器的价值不取决于数量取决于融合质量。融合首先要解决“时间对齐”和“空间对齐”激光雷达和摄像头分别有各自的坐标系和触发时刻得通过标定把外参统一、用时间戳做插值同步才能把点云和图像像素一一对应起来。这一步做不好后面所有算法都是空中楼阁。融合策略大致分三层数据级融合把点云和图像在底层直接拼接成BEV鸟瞰图特征目标级融合让各个传感器先各自感知障碍物再在目标层做匹配合并决策级融合则是各模块独立判断后再投票。量产项目往往采用目标级和BEV特征融合的混合方案——既保证鲁棒性又不至于因为传感器延迟差异导致底层数据对不上。融合里最容易踩的坑是“传感器打起来了”摄像头认为前方是车辆激光雷达却认为那是一团稀疏噪声。这种不一致比单个传感器失灵更危险所以融合模块通常还带一致性校验和置信度仲裁逻辑。多传感器系统的真实价值从来都是靠融合算法释放的而不是靠堆硬件数量。2.4 感知算法从规则特征到深度学习再到端到端感知算法这些年走了条清晰的路。早期是传统计算机视觉用边缘检测、车道线拟合这类规则方法后来卷积神经网络把目标检测、语义分割、实例分割做到接近甚至超过人类成了感知主力的标配。再往后Transformer和BEV视角流行起来把多摄像头特征统一投影到鸟瞰空间方便后续规划直接拿到“一张俯视图”。感知模块输出的不只是“这里有个东西”还包括物体的类别、尺寸、朝向、速度、航向以及多目标跟踪给出的历史轨迹。有了这些规划模块才知道前方那辆车是在正常行驶还是要变道。近几年端到端方案把感知、预测、规划揉成一个神经网络训练更简单、信息损失更少但也带来了可解释性差、极端场景难调试的问题。这条路值不值得走行业还在激烈讨论我会在后续专门写一篇展开。3. 高精地图与定位没有“厘米级自知”安全落地就是空谈3.1 高精地图比导航地图多画了什么普通导航地图是给人看的——它告诉你哪条路通向哪里精确到“米”级就够用了。高精地图是给机器看的精度要到10~20厘米内容也从“路网”细化到“车道模型”每条车道的中心线、宽度、曲率、坡度、车道线类型、路沿、路牌、红绿灯位置甚至限速和施工区都预先标注好。相当于给车准备了一张“电子轨道”感知模块不用每次都从零开始识别道路结构。高精地图在架构上通常分几层基础地图层负责道路几何和拓扑车道模型层负责车道级语义定位图层提供供点云或视觉匹配用的特征动态图层则承载实时拥堵、事故、施工信息。动态图层一般靠车路协同或众包数据高频刷新这也是地图行业投入巨大的原因之一。做规划的同学应该有个感受地图质量直接决定规划器敢跑多快地图上一处车道线缺失车就可能把路肩当可行驶区域。3.2 组合定位GNSS、IMU、点云匹配与视觉匹配定位不等于GPS。卫星定位在隧道、高楼峡谷里会丢信号或产生多路径误差单纯依赖它车可能开着开着就“漂”到隔壁车道。量产方案几乎清一色是组合定位GNSS提供绝对位置基准IMU惯性测量单元以100~200Hz的高频率推算短时间内的相对运动里程计提供轮速信息再通过滤波算法把这几个源融合起来。这还不够。为了让车辆在车道级保持稳定还需要“相对地图的匹配定位”一种做法是拿激光雷达当前点云和高精地图里的点云地图做配准常见有NDT和ICP算法另一种做法是用摄像头识别到的车道线、路牌与地图特征做视觉匹配。匹配结果会被持续反馈进滤波器把长期漂移纠正回来。我实际参与过的某个Robotaxi项目里最折腾的不是算法选型而是标定和异常切换GNSS信号跳变、IMU温漂、地图版本升级导致特征变化都会让定位输出“跳一下”。所以定位模块必须配套健康监测任何信号源的可信度下降都要能平滑切到别的源而不是等定位彻底崩了才发现。这一点在写定位方案时很容易被忽略却往往是实车测试时的第一杀手。3.3 “重感知轻地图”之争地图新鲜度才是命门高精地图有个天然痛点——新鲜度。路改了、线划了、树挡了路牌地图没更新车就会“按旧地图自信地犯错”。传统方案靠专业测绘车定期采集周期长、成本高现在的趋势是众包更新用量产车上的传感器把道路变化实时传回云端经过处理再分发给所有车缩短更新间隔。与之相关的还有“重感知轻地图”路线让系统更多依赖感知实时重建道路结构减少对事先建图的依赖。这个方向听起来美好但它并没有取消定位和先验信息只是把“地图”的一部分换成了实时构建的局部地图。我的看法是短期内行业会走折中路线地图做全局先验感知做局部实时校验两套信息互相纠错这样既照顾了鲜度又保证了定位可靠性。4. 决策与规划从“看得懂路”到“想明白怎么走”4.1 行为决策有限状态机里的“礼貌与博弈”感知告诉系统“前面有什么”接下来决策层要回答“我要干什么”。传统量产方案里行为决策往往是一套有限状态机巡航、跟车、变道、超车、靠边停车、过路口、礼让行人……状态之间按规则切换。规则来自驾驶常识和通行习惯所以它天然可解释、可审查。但真实交通里到处是博弈旁边车道车辆打灯想并进来你是让还是不让路口对面左转车和你的直行有冲突谁该先走行为决策要评估的不只是当前状态还有对周围目标未来几秒意图的预测。好的决策模块会把“预测别人要干什么”和“我的选择会不会让局面更安全”放在一起权衡这已经接近博弈论的味道。很多公司在尝试用模仿学习和强化学习去替换手工状态机但落地里依然需要规则兜底防止模型在没见过的场景里做出离谱决策。4.2 运动规划在安全、舒适、效率之间“解轨迹”行为决策给个大方向运动规划负责把它细化成一条具体可执行的轨迹。轨迹是个时空概念不只要规划“往哪走”也就是路径还要规划“以什么速度走”也就是速度曲线合在一起是一串带时间戳的车辆状态点位置、航向、速度、加速度。现代运动规划基本上分成几类做法采样类方法在空间或控制空间撒点找一条连接起点和终点的无碰撞轨迹典型代表有栅格法、RRT以及把横纵向分开采样的Lattice规划优化类方法把“舒适度、效率、离障碍物距离”写成代价函数在动力学约束和安全约束下求最优解还有基于搜索的方法和最近火起来的端到端规划。实际产品大多是“多策略混合”先粗粒度搜索出候选走廊再用优化方法在走廊里求平滑解。这里有个工程细节值得注意规划器输出的每条轨迹要同时满足车辆运动学约束比如方向盘最大转角下的最小转弯半径还要满足舒适度约束比如加速度变化率不能太大。否则规划器给出的轨迹在数学上很漂亮车上坐着的人却会晕到骂人。此外规划结果还要通过安全校验才能发给控制层校验内容包括碰撞检测、超限检测、执行可行性检测这是量产里绝不可省的关卡。4.3 规划为什么难加塞、切场景与长尾问题规划模块是自动驾驶里被吐槽最多的模块因为它要面对无穷无尽的长尾场景。高速公路上的典型难题是cut-in加塞侧后方车辆突然斜切进你的车道预测和规划必须在一两百毫秒内判断对方意图给出“让速”还是“加速过去”的决策。这里最考验的是预测置信度——判断错了要么过于保守被频繁别停要么反应慢了酿成险情。城区场景更麻烦无保护左转、环岛博弈、窄路会车、施工改道、外卖车逆行……变量多、交互强任何一条规则都可能被某个真实路口打破。所以行业普遍做法是“能避则避”在ODD里把高难度场景先排除掉等数据和算法成熟了再逐步开放。这也是为什么量产产品大多先限定在封闭园区、高速和结构化停车场——不是不想做全场景是长尾场景实在吞掉了大部分研发预算。5. 控制执行大脑再好手脚掉线也白搭5.1 纵向控制与横向控制的分工规划层给出目标轨迹控制层负责让车真的沿着轨迹走。控制通常拆成两路横向控制管方向盘转角让车辆保持在车道中线纵向控制管加速踏板和制动踏板让车速跟随目标速度曲线。两路并非独立因为转向会改变横向加速度刹车会改变车头姿态所以现代控制器往往在模型里显式考虑横纵向耦合。实际标定时横向和纵向的调试手感差别很大。纵向控制直接决定乘客会不会晕车刹车过猛、加速过冲都是体验灾难横向控制决定车会不会“画龙”弯道里参数调不好车会在车道内来回修正既不舒服还显得很“新手”。见过太多团队把资源都砸在感知上最后发现试驾打分差在控制质感上。5.2 从PID到MPC控制算法选型的现实考量控制算法圈里总在争论PID到底够不够用。PID结构简单、调参直观、鲁棒性好在速度不快、工况稳定的场景里表现够用很多量产项目的基础纵向控制至今还是PID打底。但PID的短板也很明显——它不知道未来的约束过弯时经常出现“转向不足再修正”的来回摆舒适性一般。更进阶的选择是LQR和MPC。LQR基于线性模型求最优反馈增益适合做横向控制的稳定内环MPC模型预测控制则可以在每个控制周期里基于车辆动力学模型预测未来若干步的状态在一个优化窗口内同时处理转向、制动、速度、障碍物距离等约束。MPC的优势是天生“有远见”但代价是计算量大、模型不准时鲁棒性下降、参数比PID多得多。我见到的大多数实际方案是做“组合拳”内环用高频率的PID或LQR稳住执行器的响应外环用较低频率的MPC做全局约束下的轨迹跟踪。控制参数标定是另一个大坑——不同车速、不同负载、不同路面附着系数下同一套参数表现天差地别所以量产项目都配了海量的标定试验数据。这活儿看着不起眼却是真正决定驾驶质感的地方也是最容易在项目排期里被低估的工作。5.3 执行机构线控底盘与冗余配置控制器输出的是“转角多少度”“减速度多少”这类期望值真正干活的是底盘的转向和制动执行机构。传统机械和液压系统响应慢、延迟不一致量产自动驾驶车基本都换成了线控底盘转向用电机直接驱动、制动用电子液压或电子机械制动响应在几十毫秒内还能接受高频指令。线控也带来新的安全问题电子系统一旦失效方向盘可能失控。所以L3及以上系统必须做冗余——制动至少双套独立回路转向系统双电机双控制器供电双路通信双路。这些冗余不参与正常驾驶只为失效那一刻兜底。很多团队在算法上投入巨大却忽视了对执行器失效模式的测试转向电机卡死、制动压力传感器漂移、线束进水导致偶发断连……每一样都能让一个“性能很好”的系统瞬间变成危险品。做这行越久越明白安全不是加个功能而是从头到尾的失效模式分析。6. 算力、软件栈与数据闭环看不见的隐形地基6.1 从分布式ECU到域控制器传统汽车里有上百个ECU各管一摊窗户、空调、制动防抱死各司其职。但自动驾驶需要处理海量传感器数据、跑大模型、做高实时性决策靠传统分布式ECU的算力和通信带宽根本扛不住。于是行业转向集中式架构引入自动驾驶域控制器把摄像头、雷达、激光雷达的数据汇总到一块算力极高的芯片平台统一完成感知、融合、决策、规划。这块芯片平台的算力是最近几年最卷的参数厂商从几十个TOPS一路标到上千TOPS。但从业者的视角要冷静TOPS只是理论算力上限实际可用算力受内存带宽、算子利用率、散热功耗约束。很多系统宣传算力高得吓人真跑到量产车上因为散热降频实际吞吐直接腰斩。选型时我更关注几个现实指标单位功耗算力、内存带宽、工具链和算子库的成熟度、模型部署的生态支持而不是纸面峰值。6.2 中间件与操作系统实时性、安全与生态的平衡自动驾驶软件栈绝不是“在通用系统上跑个脚本”那么简单。量产车需要对安全敏感的通信和调度做到可预测所以操作系统往往用带实时扩展的通用内核或商业级实时系统方案中间件则采用数据分发协议保证模块间通信的可靠和低延迟。为了不让一个模块崩溃拖垮整车还需要故障隔离、看门狗、状态监控这些基本功。这层软件架构最折磨人的地方是“既要又要”既要生态丰富能跑起各种AI框架又要实时确定关键路径不被调度方差拖累还要符合功能安全标准的规定流程。所以行业里普遍做法是“异构混合”非安全相关的模块跑在通用系统上安全关键的感知结果下发、规控执行跑在独立的高可靠性分区里。软件架构设计得不好算法再强都上不了车这个问题往往要到实车联调阶段才暴露那时返工成本极高。6.3 仿真测试与数据闭环让系统在虚拟世界里先摔够跟头自动驾驶上路的门槛极高不可能靠实车把所有场景都测完于是有了仿真测试这条腿。测试体系大致分几层单元测试和模块测试、场景仿真测试、硬件在环HIL接入真实控制器甚至真实执行器、封闭场地测试最后才是公开道路测试。越是上层成本越高、可重复性越差所以行业追求的是“能虚拟尽量虚拟”。数据闭环则是另一条腿。量产车或测试车在路面上遇到的各种奇怪场景会通过数据回传进入云端存储数据挖掘工具会从海量数据里自动挑出“高价值片段”——失败案例、预测错误、极端气象这些片段经过标注、清洗变成训练集和验证集模型更新后再放回仿真和实车验证验证通过的版本通过OTA推到车队。这套飞轮转得越快系统处理长尾的能力就越强。说白了今天的自动驾驶竞争一半是算法竞争一半是数据处理和迭代效率的竞争。7. 单车智能之外的变量车路协同、安全冗余与落地顺序7.1 车路协同V2X到底补了什么短板单车智能再强也有物理盲区被大车挡住的交叉路口、遮挡的行人、看不到的红绿灯状态。车路协同通过车与车、车与路侧设施、车与行人设备之间的通信把路侧感知和信号灯信息直接发给车辆。一个典型例子车路通信可以直接拿到红绿灯的精确倒计时和路口当前状态车辆在盲区路口也能从容决策。又比如前方事故、施工、临时封路信息可以提前几百米就通知到车规划器有充足时间变道。V2X目前的落地瓶颈是渗透率路上只有少数车和少数路口有设备协同价值就很难发挥。所以行业把抓手放在示范区、高速路网、港口码头这类“可以统一部署”的场景上。技术上还涉及通信制式的选择但这块更多是工程和产业问题不是自动驾驶算法本身的核心难点这里就不展开了。7.2 功能安全与失效保护冗余不是堆料而是系统工程前面聊执行器冗余时提到过功能安全这里再往深说一层。功能安全的思路不是“尽量不出错”而是“出错后系统依然安全”。ISO 26262功能安全标准按危害的严重度、暴露概率和可控性给系统划分安全等级等级越高开发和验证要求越严格。L3以上的系统尤其苛刻因为驾驶员可能正在看手机系统一旦失效必须能靠自己完成安全停车。对应到架构上就需要“失效可运行”设计主系统失效时备用系统还能维持一段时间的受限驾驶直到安全停车同时要有清晰的降级策略比如感知置信度低时自动减速靠边。很多人以为冗余就是“再买一套传感器”但量产里的冗余是层层设防传感器冗余防物理损坏算力冗余防计算失效通信冗余防链路中断电源冗余防断电。每一层都要经过故障注入测试验证这比算法指标更花钱、更花时间却是L3以上车型绕不过去的门槛。7.3 落地场景的先后顺序技术强不等于场景先落地自动驾驶的落地从来不是“哪条路技术最强就先上哪条”而是“哪个场景的ODD最简单、容错率最高、商业路径最顺就先跑通”。所以你会看到这样的先后顺序封闭园区和港口矿山的限定区域无人驾驶最早跑通流量高速结构化道路的领航辅助是当前量产主战场城市公开道路的Robotaxi在特定区域逐步扩大运行范围自主代客泊车是最容易被用户感知价值的场景。每个场景背后对应一套不同的技术侧重园区车不需要处理复杂的城市博弈但需要高可靠性的低速避障高速领航核心考验跨场景切换和系统验证的成熟度城市Robotaxi则必须啃下交互预测和长尾场景。这也是为什么系列文章不能一上来就只聊算法——没有场景感地聊技术等于看了半天菜谱却不知道自己要做的是哪道菜。最后给准备入坑的朋友一句我的体会我见过太多人拿着论文里最花哨的算法模型跟我聊自动驾驶却答不上来车载算力能跑多快、传感器延迟有多少毫秒、执行器刹车响应要多久。先完整跑通一个哪怕很粗糙的“感知—融合—决策—控制”最小闭环你对整套系统的理解会超过刷十篇顶会论文。下一篇我会选感知融合展开那个模块最容易被概念名词绕晕也最值得先讲清楚。