1. 从为什么汽车需要自己看路说起很多人第一次接触自动驾驶这个概念脑子里冒出来的画面大概是科幻电影里那种没有方向盘、乘客坐进去报个地址就能刷手机的场面。但如果你真的在这个行业里待过一段时间就会发现真实的技术演进路径远比电影里琐碎、笨拙也远比电影里有意思。自动驾驶汽车的故事本质上不是一个造一辆更聪明的车的故事而是一个如何让机器在充满不确定性的物理世界里做出安全决策的故事。这个故事的起点甚至比大多数人想象的要早得多。我最初接触这个领域的时候以为核心难点在于让车认路。后来才明白认路只是最表层的问题。真正棘手的是当一条路上同时存在遵守交通规则的人、不遵守交通规则的人、突然冲出来的动物、被风吹倒的锥桶、施工改道的临时标线以及传感器本身在雨雾天气下的性能衰减时机器该如何判断现在做什么才是对的。这个问题的复杂度远超一般人的直觉。所以这篇文章我想做的事情是把自动驾驶汽车这个故事从头到尾捋一遍。不是那种新闻稿式的某公司又完成了多少万公里路测而是从技术演进的逻辑出发讲清楚每一个阶段人们遇到了什么问题、用了什么办法、这些办法的边界在哪里。如果你是对自动驾驶感兴趣的开发者、产品经理、投资人或者只是单纯想搞明白这东西到底靠不靠谱的普通读者我希望这篇内容能给你一个相对完整的认知框架。文章会覆盖从最早的自动化尝试到传感器体系的形成到感知与决策算法的演进再到当前阶段真正卡住整个行业的那些硬骨头。我会尽量用从业者的视角来讲而不是教科书式的罗列。有些地方我会给出具体的参数和计算过程有些地方我会分享一些在实际项目中踩过的坑。这些经验不一定适用于每一个团队但至少能让你少走一些弯路。2. 自动驾驶的史前时代从不用马拉的车到第一个自动控制回路2.1 最早的自动其实和智能无关如果要追溯自动驾驶的思想源头很多人会提到二十世纪早期那些关于无线电控制车辆的实验。但严格来说那些实验和今天说的自动驾驶没有太多技术上的继承关系。它们更像是遥控玩具的放大版——操作者仍然在远端做所有决策车辆本身没有任何自主判断能力。真正有意义的转折点是人们开始思考一个问题能不能让车辆自己维持一个状态而不是每一步都依赖人的指令这个思路的第一次工程化落地其实出现在航空领域而不是汽车领域。飞行器的自动驾驶仪在二十世纪早期就已经有了比较成熟的产品核心原理是用陀螺仪感知姿态偏差然后通过机械或电气回路驱动舵面进行修正。这是一个典型的闭环负反馈控制系统传感器测量偏差控制器计算修正量执行器执行修正然后传感器再次测量。这个循环每秒重复几十次甚至上百次就能让飞行器稳定在一个设定的姿态上。汽车领域借鉴这个思路要晚得多。原因也很简单天空是三维的、相对空旷的而道路是二维的、充满障碍物的。飞行器只需要维持姿态和高度汽车却需要处理前方突然出现一个行人这种高度非结构化的事件。所以汽车上的自动控制最早只能从最简单的场景切入——比如定速巡航。2.2 定速巡航第一个被大规模接受的自动功能定速巡航的原理非常朴素驾驶员设定一个目标速度控制器通过调节油门开度来维持这个速度。上坡时油门加大下坡时油门减小。它不感知环境不判断危险只做一件事——让车速稳定在设定值。这个功能之所以能被市场接受是因为它的边界极其清晰驾驶员仍然负责所有环境感知和决策系统只接管了踩油门这一个动作。但正是这个看似简单的功能暴露了后来所有自动驾驶系统都会面对的一个核心矛盾人机共驾时的责任边界问题。定速巡航在湿滑路面上可能导致车辆失控因为系统不知道路面附着力下降了。驾驶员如果过度信任系统就会在关键时刻反应不及。这个矛盾在后来更高级的辅助驾驶功能上被放大了无数倍至今仍然是行业里最难解决的问题之一。我在实际项目中观察到的一个现象是当系统表现得越稳定驾驶员就越容易分心。这不是驾驶员的错而是人的注意力机制决定的。所以任何涉及自动驾驶的产品设计都必须把驾驶员在什么时候必须接管这件事想得非常清楚并且用足够强烈的方式提醒驾驶员。2.3 从辅助到自动SAE分级背后的逻辑后来行业里逐渐形成了一套分级体系把自动驾驶从L0到L5分成六个等级。这套分级被广泛引用但很多人其实没有理解它真正的划分依据。它不是按技术难度分的而是按谁负责什么来分的。等级转向与加减速环境感知接管请求设计运行范围L0人人人无L1人系统人人有限L2系统人人有限L3系统系统系统请求人有限L4系统系统系统自行处理限定场景L5系统系统系统自行处理无限制这张表里最关键的一列其实是接管请求。L2和L3之间的鸿沟不在于技术能力差多少而在于当系统遇到处理不了的情况时是把问题抛给人还是自己兜底。L3要求系统在请求接管时驾驶员必须能够及时响应但大量研究表明人在长时间监控一个稳定运行的系统后反应时间会显著延长。这就导致L3在实际落地中非常尴尬——技术上能做到但人因工程上很难保证安全。所以你会看到很多公司干脆跳过L3直接从L2往L4走。L4的逻辑是在限定的场景内比如某个城市的某个区域、某个时间段、某种天气条件系统完全自己负责不需要人接管。超出这个范围就不启动。这个思路在工程上更干净因为责任边界清晰。3. 传感器体系汽车如何看见世界3.1 摄像头信息最丰富但也最容易被骗摄像头是自动驾驶传感器里信息量最大的一个。它输出的图像包含了颜色、纹理、文字、形状等极其丰富的信息理论上如果算法足够强单靠摄像头就能完成大部分感知任务。但摄像头的弱点也非常明显它是被动的依赖环境光照。夜间、逆光、隧道出入口、大雨大雾都会让图像质量急剧下降。更重要的是摄像头输出的二维图像丢失了深度信息。虽然可以通过多帧运动估计或者深度学习来推断深度但这个推断在纹理稀疏的区域比如一面白墙、一片空旷的天空会非常不可靠。我在一个项目里遇到过这样的情况车辆在高速上行驶前方是一辆白色的大货车背景是阴天的天空。摄像头因为对比度太低没能把货车从背景里分割出来导致系统误判前方无障碍物。这个案例后来被用来论证纯视觉方案在极端场景下的风险。当然纯视觉方案的支持者会说人也是靠两只眼睛开车的人能做到机器为什么不能这个反驳有一定道理但它忽略了一个关键差异人的视觉系统经过了数百万年的进化有极强的先验知识和注意力机制而机器的视觉算法目前还远没有达到这个水平。所以现阶段多传感器融合仍然是更稳妥的选择。3.2 毫米波雷达全天候但分辨率有限毫米波雷达的工作频率通常在24GHz到77GHz之间通过发射电磁波并接收回波来测量目标的距离和相对速度。它的最大优势是不受光照和天气影响在雨雾天气下仍然能稳定工作。而且它直接测量的是距离变化率所以对速度的估计非常准确。但毫米波雷达的分辨率比较低很难区分相邻的两个目标也很难判断目标的形状。它擅长回答前方有没有东西、离我多远、相对速度多少但不擅长回答那个东西是什么。所以在实际系统中毫米波雷达通常和摄像头配合使用雷达负责发现目标并测距测速摄像头负责识别目标类型。这里有一个实操中很容易踩的坑雷达和摄像头的坐标系标定。如果两个传感器的外参标定有偏差融合时就会出现雷达看到一个目标摄像头看到另一个位置的目标的情况导致系统要么漏检要么误检。标定这件事在实验室里做起来很规范但在量产车上随着车辆震动、温度变化、轻微碰撞标定参数会慢慢漂移。所以量产系统通常需要在线标定或者定期校准的能力。3.3 激光雷达高精度但成本曾是拦路虎激光雷达通过发射激光束并测量反射时间来获取精确的三维点云。它的角分辨率和距离精度都远高于毫米波雷达能生成非常详细的环境三维模型。在早期激光雷达是自动驾驶研发的标配因为它的点云数据直观、易于处理算法团队可以快速验证感知和规划逻辑。但激光雷达的问题也很突出。第一是成本早期的机械旋转式激光雷达单价动辄数万美元根本不可能量产。第二是可靠性机械旋转部件在车辆长期震动下容易损坏。第三是天气影响大雨或浓雾会散射激光导致点云质量下降。最近几年固态激光雷达和半固态激光雷达的成本大幅下降已经有一些量产车型开始搭载。但行业里对激光雷达是不是必需品仍然有激烈争论。纯视觉阵营认为随着算法进步摄像头可以替代激光雷达多传感器阵营认为激光雷达提供的冗余是安全底线。我的看法是在L4级别的无人驾驶出租车上激光雷达几乎是必须的在L2的量产辅助驾驶上是否搭载取决于成本目标和场景定义。3.4 传感器融合的工程现实把多个传感器的数据融合在一起听起来很美好做起来非常复杂。融合可以在不同层级进行数据级融合原始数据直接合并、特征级融合各自提取特征后合并、决策级融合各自做出判断后投票。层级越低信息损失越少但对时间同步和空间标定的要求越高。在实际项目中我见过最多的做法是后融合每个传感器独立完成目标检测然后在一个统一的框架里做关联和跟踪。这种做法的好处是模块化程度高某个传感器出问题不会影响其他传感器坏处是信息利用率低而且关联逻辑本身很容易出错。一个常见的坑当摄像头和雷达对同一个目标给出不同的距离估计时融合算法该信谁如果简单取平均可能两个都不准如果按固定权重又无法适应不同场景。比较稳妥的做法是根据每个传感器在当前场景下的置信度动态调整权重但置信度本身怎么估计又是一个难题。4. 感知算法从手工特征到端到端学习4.1 传统视觉时代特征工程的天花板在深度学习大规模应用之前自动驾驶的感知主要依赖手工设计的特征。比如车道线检测会用边缘检测加霍夫变换车辆检测会用HOG特征加SVM分类器行人检测会用Haar特征加级联分类器。这些方法在受控场景下能工作但一旦光照、视角、遮挡发生变化性能就会急剧下降。那个时代的工程师有一个共同的体会调参调到怀疑人生。同一个算法在晴天上午的数据上表现很好到了傍晚逆光就完全失效。你不断调整阈值、增加特征、组合分类器但总是按下葫芦浮起瓢。根本原因在于手工特征无法覆盖真实世界的全部变化。4.2 深度学习带来的范式转变卷积神经网络在图像识别上的突破彻底改变了自动驾驶感知的技术路线。2012年之后基于CNN的目标检测算法快速迭代从R-CNN到Fast R-CNN到Faster R-CNN再到YOLO系列检测速度和精度都在飞速提升。对于自动驾驶来说这意味着可以用一个统一的网络同时完成目标检测、分类和定位而不需要为每个任务单独设计特征。但深度学习也带来了新的问题。第一是数据依赖网络的表现高度依赖训练数据的覆盖度如果训练集里没有夜间雨天的样本网络在夜间雨天的表现就无法保证。第二是可解释性当网络做出一个错误判断时你很难知道它为什么错。第三是对抗样本在图像上添加人眼不可见的扰动就能让网络把停止标志识别成限速标志。这些问题在安全关键的自动驾驶场景下都是必须认真对待的。我在实际项目中的经验是数据闭环比模型结构更重要。与其花大量时间尝试最新的网络架构不如把精力放在数据采集、标注、难例挖掘和持续迭代上。一个用中等复杂度网络但数据覆盖充分的系统往往比一个用最先进网络但数据有偏的系统表现更好。4.3 鸟瞰图与占用网络当前的主流思路最近几年感知算法的一个明显趋势是把多传感器数据统一到鸟瞰图视角下进行处理。鸟瞰图的好处是它和车辆的行驶决策在同一个空间里规划模块可以直接使用感知模块的输出不需要做复杂的坐标转换。而且鸟瞰图天然适合融合不同传感器的数据摄像头图像可以通过透视变换投影到地面激光雷达点云可以直接投影到地面毫米波雷达目标也可以直接放进去。更进一步的是占用网络的思路不再显式地检测每个目标而是预测三维空间中每个体素是否被占用。这种表示方式对未知障碍物特别友好因为不管那个东西是车、是人、是锥桶还是一堆掉落的货物只要它占据了空间网络就会标记为占用。这对于处理长尾场景非常有价值。但占用网络的计算量很大对车载芯片的算力要求很高。而且它的输出是稠密的三维网格后处理比较复杂。所以目前量产系统里占用网络更多是作为传统检测的补充而不是完全替代。4.4 感知模块的评测离线指标和在线表现的鸿沟做感知算法的人都知道离线评测指标比如mAP、IoU和实际路测表现之间往往有巨大差距。一个在离线数据集上mAP很高的模型上车之后可能频繁出现误刹车或者漏检。原因有很多离线数据集和真实场景的分布不一致、评测指标没有覆盖关键场景、模型在边缘设备上的量化误差等等。所以成熟的团队都会建立在线评测体系在真实车辆上跑记录每一次感知输出和对应的真值然后分析哪些场景下系统表现不好。这个体系比离线评测贵得多但它是唯一能真正反映系统能力的方法。我见过一些团队为了追求离线指标好看在训练集上过拟合结果上车之后表现一塌糊涂。这种教训在行业里反复出现。5. 决策与规划在不确定中寻找安全路径5.1 从规则到优化规划算法的演进早期的规划算法主要是基于规则的。比如如果前方有障碍物就减速如果左侧车道空闲就变道。这些规则容易理解和调试但很难覆盖所有情况。当场景稍微复杂一点规则之间就会冲突或者出现规则没有覆盖到的边缘情况。后来逐渐转向基于优化的方法。把规划问题建模成一个优化问题定义一条代价函数包含安全性、舒适性、效率等多项指标然后在满足车辆动力学约束的前提下寻找代价最小的轨迹。这种方法的优点是数学上严谨可以处理复杂的约束缺点是计算量大而且代价函数的权重需要仔细调整。最近几年基于采样的方法比如RRT、Lattice Planner和基于学习的方法比如模仿学习、强化学习也在自动驾驶规划中得到应用。采样方法适合处理高维空间和非凸约束学习方法则有可能从大量人类驾驶数据中学到更自然的驾驶策略。但学习方法的安全性和可解释性仍然是很大的挑战。5.2 预测比规划更难的问题规划的前提是预测其他交通参与者的行为。但预测人的行为本质上是一个极其困难的问题。一个人可能因为看到手机而突然减速可能因为赶时间而强行变道可能因为不熟悉路况而犹豫不决。这些行为背后的意图从外部观察是很难准确推断的。目前主流的预测方法有两种思路。一种是基于物理模型的假设目标会保持当前运动状态或者做简单的匀加速/匀减速运动。这种方法简单可靠但对复杂行为的预测能力有限。另一种是基于学习的用大量轨迹数据训练网络来预测未来轨迹。这种方法能捕捉更复杂的行为模式但需要大量数据而且对分布外的场景泛化能力差。在实际系统中通常会结合两种方法用物理模型做短期预测比如未来1秒用学习模型做长期预测比如未来3到5秒。同时预测模块会输出多个可能的轨迹以及对应的概率规划模块需要在这些可能性下都保证安全。5.3 安全冗余与失效应对自动驾驶系统必须假设任何组件都可能失效。传感器可能被遮挡算法可能出错执行器可能卡滞。所以系统设计时必须有多层冗余。比如制动系统要有主制动和备份制动转向系统要有主转向和备份转向电源要有主电源和备份电源。但冗余只是第一步更重要的是失效时的降级策略。当某个传感器失效时系统应该怎么处理是继续运行但降低速度还是靠边停车还是请求远程协助这些策略需要在设计阶段就定义清楚并且经过充分验证。我在一个项目里遇到过这样的情况车辆在行驶中前向毫米波雷达突然被泥水遮挡信号丢失。系统检测到这个问题后自动降级到只依赖摄像头和激光雷达同时把最高速度限制在40公里每小时并提示驾驶员接管。这个降级策略是提前设计好的所以整个切换过程很平滑没有造成危险。但如果系统没有这个降级逻辑直接退出自动驾驶驾驶员可能来不及反应。6. 那些真正卡住行业的硬骨头6.1 长尾场景99%和99.99%之间的鸿沟自动驾驶系统在99%的常见场景下表现良好这已经可以做到了。但剩下的1%才是真正要命的。这1%包括施工路段的临时标线、被树叶遮挡的交通标志、穿着奇装异服的行人、翻倒在路中间的货物、突然打开的车门、逆行的电动车等等。这些场景在训练数据里出现频率极低但一旦遇到系统就可能完全不知所措。解决长尾问题没有捷径。只能通过大规模路测不断发现新的长尾场景然后针对性地采集数据、标注、训练、验证。这个过程需要巨大的资源投入而且边际收益递减——从99%到99.9%可能只需要几个月但从99.9%到99.99%可能需要几年。6.2 仿真与真实路测的配比为了加速长尾场景的覆盖仿真测试变得越来越重要。在仿真环境里可以任意构造极端场景可以反复运行同一个场景来验证算法的稳定性可以并行运行成千上万个测试用例。但仿真环境再逼真也和真实世界有差距。传感器的噪声模型、其他交通参与者的行为模型、天气和光照的模拟都很难做到完全真实。所以实际的做法是仿真和路测结合用仿真做大规模回归测试和极端场景验证用路测做真实环境下的确认和补充。两者的比例取决于具体的开发阶段和场景定义。我见过的比较健康的比例是仿真里程是路测里程的几百倍甚至上千倍但路测仍然是不可替代的最终验证手段。6.3 算力、功耗与成本的三角约束车载计算平台面临一个经典的三角约束算力要足够大功耗要足够低成本要足够便宜。这三者很难同时满足。大算力芯片通常功耗高、成本高低功耗芯片算力有限便宜芯片往往两者都不行。目前主流的方案是用异构计算CPU负责逻辑控制和通用计算GPU负责深度学习推理还有专门的ISP处理图像信号专门的MCU负责安全监控。不同任务分配到最合适的硬件上才能在算力、功耗和成本之间找到平衡。但软件团队往往希望硬件提供尽可能多的算力因为算法迭代是无止境的。硬件团队则希望控制功耗和成本因为量产车对这两项极其敏感。这个矛盾在项目里经常引发争论。我的经验是在项目早期就要把算力预算定清楚并且留出一定的余量但不要指望硬件能无限升级。算法团队需要在给定的算力约束下做优化而不是无限制地堆模型。6.4 法规与责任技术之外的真正瓶颈技术问题再难至少还有明确的攻关方向。但法规和责任问题往往比技术更难推进。当一辆自动驾驶汽车发生事故时责任在谁是车主、是制造商、是算法供应商、还是传感器供应商这个问题在不同国家和地区的法律框架下有不同的答案而且随着技术演进还在不断变化。对于企业来说这意味着必须做最坏的打算假设事故一定会发生然后提前设计好数据记录、事故还原、责任认定的流程。同时在产品宣传上必须极其谨慎不能让用户产生这车可以完全自己开的误解。我见过一些公司因为宣传过度导致用户在开启辅助驾驶后完全放手最终酿成事故。这种教训是血淋淋的。7. 我在实际项目中的几点体会做了几个和自动驾驶相关的项目之后有几个体会是反复被验证的。第一场景定义比技术选型更重要。在开始写代码之前一定要把这个系统在什么条件下工作、什么条件下不工作、不工作时怎么办这三个问题回答清楚。很多项目失败不是因为算法不够好而是因为场景定义模糊导致系统在边界条件下表现不可预测。第二数据质量比数据数量更关键。采集一百万公里数据不难难的是从这一百万公里里找出真正有价值的那些片段。一个高效的难例挖掘流程能让数据效率提升好几倍。第三安全冗余的设计要贯穿始终。不要等到系统快完成了才考虑失效应对。从架构设计的第一天起就要把如果这个模块挂了怎么办作为必答题。第四仿真和路测要形成闭环。仿真发现的问题要在路测中验证路测发现的问题要能在仿真中复现。这个闭环转得越快迭代效率越高。最后分享一个很小的技巧在调试感知算法时把原始传感器数据和算法输出同时可视化并且加上时间戳。这样当出现问题时你可以快速定位是传感器的问题、同步的问题、还是算法的问题。这个习惯帮我省下了大量排查时间。