刚看到这条消息时我第一反应不是“又一座城市被攻克了”而是“他们终于要啃这块骨头了”。自动驾驶Robotaxi往这座欧洲老牌都市扩张几乎是我这几年心里默认的“终极副本”——靠左行驶、几百年的窄街布局、密集的行人和自行车、一年里一半时间是雨天加上那种“车必须让行人”的路权文化。任何一个做感知、做规划、做高精地图的人看到这个组合都会倒吸一口气。严格说自动驾驶在美国几座城市跑通和在这儿跑通根本不是同一个难度级别。之前跑的那些地方路宽、天气好、交通习惯统一驾驶员相对守规矩。而这座英伦都市的路况是被几百年城市演化一层层叠出来的结果——老城区那种双向两车道的石头路两辆巴士在窄巷里错车都要互相让一把环岛的让行规则跟美国完全相反路面上的车道线有时候根本不是靠漆线标出来的而是靠路缘石、井盖和路边停着的车“暗示”出来的。这些东西AI感知模块稍微少看一样就会做出一个让人冒冷汗的决策。这篇文章我打算从技术和落地的角度把“进军这座复杂欧洲都市”这件事拆开揉碎来讲。里面会有我这些年做自动驾驶项目积累的经验哪些环节最容易被低估、最容易翻车也会结合这次扩张对外透露的信息做一个合理拆解。不管你是做感知算法的、搞高精地图的还是做Robotaxi运营的看完应该都能收获一些可以直接用在项目里的判断。1. 为什么说这里是自动驾驶的“终极考场”而不是又一座普通扩容城市1.1 从“已验证道路环境”到“未知复杂路况”的跨度到底有多大先看这家公司此前运营的主要城市环境。总体上是典型的北美城市肌理棋盘式路网道路宽敞十字路口间距大车道线清晰行人流量相对低。在那种环境里自动驾驶遇到的最大难题往往是高速公路汇入、施工改道和偶尔的极端天气核心冲突简单且可枚举。而这座欧洲都市的环境属性完全不同。路网密度高单行道和公交专用道几乎覆盖了核心区老城区街道窄到连错车都要靠某个方向的驾驶者主动让行。更关键的是这里的交通参与者构成极其复杂——行人不太看信号灯骑行者会在车流里穿梭外卖电单车常见摩托车也会在堵车时从两排车的缝隙里钻上来。这种“非结构化的随机博弈”才是自动驾驶最不擅长的场景。美国式路口的冲突点少、规则明确算法可以通过学习常规轨迹实现较低干预率但在这儿很多路口连标准的信号相位都没有靠环岛和让行标志维持秩序。这对决策规划系统是一个指数级的复杂度上升。1.2 所谓的“最严峻挑战”到底是挑战了什么不少不在一线的朋友听到“复杂路况”第一反应是“感知能不能看清”。但真正干过这行的人会告诉你感知反而只是第一关后面还有三座大山。第一座大山是行为预测。在这座城市行人和骑行者的行为模式高度随机不能按北美那种“行人会走斑马线、会看信号灯”的假设去做预测。举个例子在窄路没有信号灯的地方很多行人过马路的习惯是“先看车是否减速再决定要不要继续走”这是一种双向交互。传统预测模型把行人当作“独立运动的物体”碰到这种交互场景很容易傻掉——车减速行人反而停在路边等你你不走他也不走。谁先动这个问题人类驾驶者靠眼神和手势就能解决但自动驾驶没有这个器官只能用行为和外部交互信号来替代。第二座大山是道路语义理解。靠左行驶不只是把地图左右翻转那么简单。环岛让行方向变了公交车的开门侧变了路口转弯时对向车辆的位置关系也变了。这一切都要求高精地图从底层的道路拓扑数据结构开始重新适配不是改一个参数就能搞定的。第三座大山是天气与环境干扰。频繁的雨天让激光雷达的点云里到处都是雨滴回波让摄像头镜头沾满水渍让路面的车道线被积水淹没。冬天低角度阳光还会造成镜头眩光。这些干扰单看都不致命但叠加在一起会让系统的置信度全面下降。如果置信度阈值调高车辆会频繁进入“保守模式”停得太多导致路怒调低又会冒安全风险。这个平衡点需要大量本地数据去“喂”出来。做自动驾驶行业的朋友都应该明白一个词ODD即运行设计域。任何一套系统都是在某个限定条件下才能安全运行。这家公司宣布进军这座都市本质上就是大幅扩张ODD边界——不仅是地理边界还包括天气、光照、交通文化这些维度。边界扩得越多系统需要重新验证的组合就越多项目复杂度不是线性增长是乘法级增长。2. 硬件底牌拆解面对窄街、雨天和密集人流传感器怎么分工2.1 激光雷达、毫米波雷达、摄像头各自的“强项重排”在北美晴天环境下摄像头能提供最丰富的语义信息——车道线、信号灯颜色、行人姿态、路面标牌都靠视觉来认。但到了这座阴雨连绵的城市摄像头反而是最先失效的环节。雨水在镜头上形成水膜夜间对向车灯在水膜上拉出光晕画面质量断崖式下降。因此在这类环境下毫米波雷达的地位会显著上升。它对雨雾不敏感能直接测距和测速尤其擅长在城市里追踪前车和横向切入的摩托车。但毫米波雷达的缺点是分辨率低分不清单个行人和其他金属物体容易把路边的铁护栏、检修井盖误判成障碍物。激光雷达则站在中间位置它在雨天点云里会产生噪点但可以通过时序滤波把静态噪点筛掉同时它提供的三维轮廓信息是其他传感器给不了的。我在这类项目里的经验是不要奢求任何一种传感器在所有天气下都完美关键是设计一套失效降级逻辑。比如大雨天视觉置信度下降时系统应自动提高毫米波雷达在融合权重中的占比同时降低速度上限。这套降级逻辑的安全性必须在仿真里先跑上千个降雨场景而不是等到真车开进雨里才去试。2.2 传感器布局与清洗系统经常被低估的“硬件工程”城市里跑车最大的传感器敌人不是算法是泥浆和虫子。在这座都市的秋冬季节路面潮湿前车甩起的泥水会直接糊住保险杠上的激光雷达窗口和摄像头镜头。如果传感器脏了没发现系统等于戴着墨镜开车。所以一支准备充分的车队必须配备传感器清洗系统高压喷嘴冲洗摄像头和激光雷达窗口配合雨刮器清理。但光有硬件还不够还得有“脏污检测算法”。怎么判断镜头脏了对比当前图像和地图的匹配度如果整体模糊度升高而车辆没有运动模糊大概率就是镜头脏了。这个逻辑听起来简单实际调起来却容易误报比如大雨本身就会让图像匹配度降低。我在自家项目里被这个问题折磨过很久最后结论是在清洗逻辑里加一个“降水信号”的调制只有在雨刮启动或天气API显示有降水时才允许触发脏污判断否则一律当成天气干扰。车载计算单元的冗余度也要跟着上调。城市道路场景需要同时处理多路激光雷达点云、十几路摄像头图像、毫米波雷达数据再叠加高精地图定位和高复杂度决策模型。我在项目里测过同样的算力在这种复杂环境的负载比高速道路上高出一倍不止。如果芯片温度压不住整个系统会降频出现“决策变慢”这种更隐蔽的问题。2.3 高精地图不是“画线”而是给车辆讲清一套规则体系进入一座新城市高精地图是比传感器更前置的瓶颈。普通导航地图只需要知道“从这里能到那里”高精地图得把每条车道、每个路缘、每根杆子、每块标志牌的三维位置和语义都存下来。在这座欧洲都市高精地图的复杂度集中在三个方面。第一车道级拓扑关系更复杂——同一个物理路口往往有五六条通行轨迹在北美很少碰到的“多岔路口加电车道”组合在这里并不少见。第二道路属性带有时间维度和条件维度比如公交专用道的使用时段、部分路段对车重和排放的限制、周末步行街的切换。第三也是让我最头疼的一点路面标记经常不可靠很多老城区道路根本没有完整车道线车道边界必须从路缘石、井盖序列、路边停车轮廓甚至建筑立面推测出来。高精地图的“新鲜度”也是一个运营风险。城市施工频繁围挡、锥桶和临时改道可能一夜之间出现。解决这个问题只能靠两条腿走路一条是让车队在运营过程中用实时感知结果做地图差异检测发现偏差后自动上报另一条是保持一支本地的地图采集更新团队定期开车扫描验证。这部分的运营成本很高但省不得。3. 从采集到上线一支Robotaxi车队落地的完整链路3.1 第一阶段数据采集与高精地图生产至少要跑出“可运营”的地图基础进军一座城市第一个月投入的人力大概率不是算法团队而是地图采集和验证团队。我见过不少项目在起步阶段低估了地图生产周期结果车都到了地图还没做完整个测试计划往后拖了两个月。地图采集不能只靠一辆车跑几趟就算完。主干道、支路、小巷、不同天气、不同时段、不同光照角度都要采集。尤其是那些大树遮顶的老街道即使是晴天卫星定位信号也会因为多径效应出现漂移必须靠激光雷达点云和轮速计做融合定位来修正。地图做完后还要经历一个“人机联合审查”阶段。算法会先把采集数据自动分帧、标注、提取要素但关键路口和车道连通关系还要由人工确认。因为高精地图错了比没有地图更危险——系统会非常自信地沿着错误车道走。我此前参与的一个项目里地图团队在一条单行道上把方向标反了测试车开进去直接逆行了半条街全靠安全员手动接管。从那次以后我们的地图验收清单里加了一条铁规矩每条单行道必须双人复核方向属性。3.2 第二阶段仿真场景库与“废数据”回放真正烧钱但最值的环节很多非从业者以为自动驾驶的安全性主要靠路测里程堆出来。但实际上头部公司普遍采用的策略是“仿真优先”把路测时采集到的真实数据尤其是那些安全员接管的临界场景全部回放到仿真环境里让算法反复练习。这些数据圈内叫“废数据”——不是说它们没价值而是指它们记录了系统“失败”的瞬间。一帧一帧地回放能让工程师看清是感知漏检了、预测偏差了还是规划层逻辑冲突。一家公司如果积累了几百万公里的路测数据仿真里相当于运行了几十亿英里。在这座复杂城市这类数据的价值会被放大本地路况的“奇怪场景”远多于其他城市每一个安全员接管都可能对应一个算法补丁。仿真环境还用来验证“车辆与行人的博弈策略”。比如在无信号灯路段车要往前慢慢蠕动一下给行人传递“我看到了你我可以等你先过”的信号但又不能蠕得太激进让行人误以为车要抢行。这种细腻的行为参数写在文档里是一行字调起来是几百次仿真迭代。3.3 第三阶段安全员管控、远程接管与本地运维体系车队落地时无论自动驾驶系统多成熟安全员和远程接管席都是标配。在这座城市安全员需要额外的本地驾驶培训熟悉当地的环岛规则、公交车道规则和窄路会车礼仪。不要小看这个培训安全员如果对本地路况不熟会在接管时机上做出错误判断——要么接管太晚要么接管太早反而打断了系统的自主学习过程。远程接管席位也会遇到本地特有的问题。城市里大量街道有密集的高层建筑车联网信号容易衰减。远程席如果出现画面卡顿接管指令就滞后了。我在项目里的经验是远程接管权限必须设置严格的条件只有在车辆已经进入安全停车状态或低速状态下才能接管控制权不能在高架上以时速80公里完成远程变道。这套“远程冗余但受限”的设计既能兜底又不会引入新的风险。运维体系还包括一个容易被忽视的环节车辆清洁和传感器校准。雨天跑一天车身传感器区域会积累大量泥渍每天收车后都要清洗。如果车辆发生过轻微剐蹭或因为道路颠簸受到冲击激光雷达和摄像头的外参就可能发生微小偏移。这个小偏移平时感觉不到但在窄路错车时可能让车辆离路缘距离的判断偏出几厘米。所以车队必须建立周期性质检机制用标定场快速校验外参发现偏差立刻重新标定。4. 真正的硬仗人车博弈、细微路权信号与天气叠加的干扰4.1 在“人人都在博弈”的城市里保守派和激进派都会翻车这座城市路权文化的核心是“规则给行人博弈靠司机”。对自动驾驶来说这非常考验行为策略的微调能力。举一个最常见的场景一条没有信号灯的老街上行人准备过马路。人类司机的做法是减速但不完全停下用车辆姿态告诉行人“我注意到你了你先过”。行人看到车减速后会快速通过。自动驾驶如果完全按照北美风格“刹停等待行人先过”行人反而会愣住甚至在车前犹豫不决造成交通阻塞。更麻烦的是后面排队的本地司机看到自动驾驶车这种过度礼让的行为会选择变道绕行这又引入了新的危险。但反过来如果系统过于激进像本地出租车司机那样贴着行人的身体加速通过又会对行人的心理造成很大压迫。处理这种场景的正确方式是学会“以小幅度动作传递意图”车缓缓向前滚动停在一个能让行人安全通过但有压迫感的临界距离之外同时用外部显示屏打出一句“你先行”。这套交互逻辑听起来简单但要在各种路宽、车速、行人密度组合下都能做对必须反复调参数和做路测。4.2 雨天和夜间叠加时感知系统要祈祷的点很多如果说白天的复杂博弈是“社交问题”那么加上雨夜就是“物理问题”和“社交问题”的合体。雨夜场景下视觉画面里到处是灯光反射湿漉漉的路面上红色尾灯倒影和刹车灯几乎无法区分对向车灯在摄像头里形成大面积光晕可能遮住半边画面激光雷达点云里雨滴会形成大量细微的“鬼点”如果算法没有做过针对性的点云过滤这些鬼点会被当成静止障碍物导致车辆频繁刹车——就是圈内常说的“幽灵刹车”。我处理过一起典型的雨夜误判测试车在一条多车道上正常行驶车载系统突然在65公里时速下紧急制动。事后回放数据发现毫米波雷达锁定了前方路面积水反射的“虚影”把它误判成了静止金属物体。从那以后我们在融合层加入了一个“可信度地图”机制——当视觉和激光雷达同时确认该位置不存在物体时毫米波雷达的可信权重自动降低。这个逻辑在雨夜场景非常管用但也需要注意不能矫枉过正否则会漏掉真正跨线而来的摩托车。4.3 上下客与路边停靠Robotaxi用户体验的第一道陷阱Robotaxi能不能被这座城市的居民接受上下客体验比很多人想象的更重要。在市区狭窄的双车道上如果车辆要临时停靠让乘客下车得找到一个合法的、不会阻碍交通的位置。这里面的技术难点是如何判断路缘石边缘与停车位边界的可信度。传统感知算法在识别路缘石时非常依赖激光雷达的连续反射。但在雨天路缘石表面的排水槽积水会反射掉一部分激光点云会变得稀疏。更麻烦的是这座城市常见的“停靠限制”规则很细有些路段在特定时段禁止停车有些公交站前后几米内不能停靠。车辆不仅要识别物理空间是否足够还要把当地停车法规编码进地图系统。我见过不少项目第一版上线时整套停车逻辑沿用其他城市的规则结果一到本地就频繁违规。上下客时还有一个细节乘客开门。如果车停得离路缘太远乘客开门时会侵占相邻车道后面的自行车或摩托车来不及反应很容易发生“开门杀”。所以Robotaxi停靠时必须追求“尽量贴边”的精度。这项要求反过来作用于规划控制模块——它需要具备在狭窄空间内进行多段微调的能力而不是一把方向就草率停入。5. 问题排查实录我在类似项目中踩过的坑你可以直接照着排5.1 “幽灵刹车”问题优先怀疑传感器融合而不是规划逻辑很多团队遇到幽灵刹车第一反应是去查规划代码。但我的经验是八成情况出在感知融合层某个传感器给了一个虚假目标融合模块没有把它过滤掉。排查思路可以按顺序走一遍现象优先排查点具体操作雨天无故急刹毫米波雷达虚反射调出雷达点云看是否有来自路面或对向护栏的回波夜间偶发减速摄像头眩光导致误检对比同时间段的视觉标注结果确认是否把光晕当成障碍物阴天把树影看成行人激光雷达点云分类检查点云簇的形状特征看是几何外形成分还是分类器误判两侧都有车时无故向左让预测模块轨迹偏移检查目标车轨迹预测是否混杂了对面来车的语义幽灵刹车一旦确认是融合问题修复方案往往不是改一个阈值而是要重新审视各传感器在特定条件下的可信权重表。这份权重表必须基于大量本地场景数据标定不能用其他城市的经验直接搬到这座雨城。5.2 预测模型对骑行者“突然切入”不敏感怎么办本地骑行者的驾驶风格是“贴着你走”。很多电动自行车会从机动车右侧挤上来在路口前突然左转几乎没有任何传统意义上的转向信号。预测模型如果只按横向位置和速度变化来做判断留给规划层反应的时间往往不足。我的做法是为骑行者单独建立一套运动模型并加入“意图候选集”在车道边缘检测到骑行者的横向移动趋势时同时生成“保持直行”“向左变道”“右转”三个预测分支并在规划层提前为每个分支准备可行的减速策略。这样即使骑行者最后选择的是最激进的一个分支车辆最多是急减速而不是紧急刹停或碰撞。强调一下这条逻辑必须在仿真中反复跑因为预测模型一旦过于激进地假设骑行者会左转车辆就会频繁减速后面的汽车会不耐烦地变道超车反而增加风险。安全和效率的平衡永远是一个调参地狱。5.3 安全指标的“水分”怎么看才不容易被骗这个行业习惯用MPI每百万英里人工接管次数来衡量系统水平。数字越小越好但换算起来很容易产生误导。比如在空旷的郊区道路上跑出来的MPI和在城市复杂路况下跑出来的MPI完全没有可比性。在这座英伦都市MPI的参考价值要打个巨大的折扣因为任何一条看似普通的市区路线都可能包含几十个高风险博弈点。我评估一个系统适不适合进入新城市会额外看三个指标复杂路口无接管通过率、雨夜场景接管率、行人博弈交互成功率。这三个指标比单一MPI更能反映出系统在这个特定环境的真实水平。给从业者一个实际建议你在项目报告里看到“接管次数降低50%”这类数据时一定要追问数据是在哪个ODD、哪个天气范围、哪个道路类型下跑的。脱离了环境和场景边界谈安全指标基本都是对外的PR话术不能作为技术决策依据。6. 一些关于项目推进策略的个人判断以及最后想吐槽的细节如果这家公司真的想在这座城市站稳我认为最值得投入的不是感知模型的迭代而是“本地化数据闭环”的建设。简单说每一辆测试车每天跑出来的数据都要经过自动化管线快速筛选把那些让安全员接管的片段、让系统决策时间超过阈值的高压场景在24小时内送入仿真库并完成回放。算法团队根据回放结果决定打补丁还是调整参数。这个闭环速度决定了系统在本地环境里进步的速度比单纯堆传感器或堆算力重要得多。另外还有一个容易被忽视的软性工程对外交互设计。自动驾驶车辆在窄路让行时的“礼貌感”完全依赖于车外显示屏和灯光语言。我见过一些项目深夜在城市道路测试车辆在路口礼让行人但因为没开任何交互提示行人完全不知道这车是让还是不让双方都停在原地僵持几秒这种体验一旦让本地人觉得“不靠谱”测试阻力会迅速上升。最后分享一个我在实际项目里体会最深的细节这类老牌城市的道路基础设施看起来没有现代都市那么规整但背后有一套百年形成的“潜规则”。比如某些路口虽然没有信号灯但几方向车流之间会形成一种基于视线和车速的默契交替通行。自动驾驶要融入这种默契光靠强化学习很难最可靠的路径还是尽可能多地收集本地司机的实际驾驶数据分析出哪个路口存在“隐性的让行顺序”再把这些规律人工标注进地图系统和行为模型。我踩过的坑告诉我千万不要用工程师视角去假设“这个路口应该怎么走”而要先去看“这个路口的真人司机到底怎么走”。作为一个常年跟各种路况较劲的人我挺期待看到这套系统的真实落地表现。它如果真的能在这种环境下把接管率压到一个商业可用的水平那对整个行业都是一次信心的提振。至于中间会上演多少翻车、逆光、窄路惊魂的故事那大概就是Robotaxi走进大众生活之前注定要交的学费。
