1. 从“最后一公里”到“城市通勤”May Mobility的渐进式扩张逻辑最近看到May Mobility在又一个城市落地了自动驾驶通勤服务的消息这让我想起了几年前他们还在大学校园和封闭园区里做小范围测试的场景。从“最后一公里”的微循环摆渡到如今切入城市核心通勤线路这个路径选择本身就很有意思。很多同行一提到自动驾驶脑子里蹦出来的就是Robotaxi自动驾驶出租车或者干线物流卡车觉得那才是“星辰大海”。但May Mobility走了一条看似更“窄”实则更稳的路——专注于固定路线、低速场景的共享出行服务。为什么是固定路线这背后其实是一个关于技术成熟度与商业可行性的经典权衡。完全无人的、任意点对点的Robotaxi对感知、预测、规划和控制系统的要求是指数级上升的。一个十字路口可能同时有几十个交通参与者每个都有不同的意图再加上复杂的交通信号、行人鬼探头任何一个环节的误判都可能导致严重事故。而固定路线意味着系统可以提前进行高精地图的采集与标注对每一个路口、每一个潜在的冲突点都了如指掌。这极大地降低了实时感知和决策的难度让系统可以更专注于处理路线上的“已知未知”和“未知未知”。May Mobility选择的“通勤服务”场景更是将这种优势放大了。通勤路线有几个特点一是高度重复性早晚高峰流量大但路线固定二是速度相对较低通常在市区限速范围内这给了系统更长的反应时间三是用户需求明确就是解决从家到公司、从交通枢纽到办公区的“确定性”出行问题。这种场景简直就是为当前阶段的L4级自动驾驶技术量身定做的试验田。它不需要去应对一个游客在陌生城市漫无目的的出行需求只需要像一位经验丰富的班车司机每天沿着同一条路安全、平稳地把大家送到目的地。所以当我们看到May Mobility“又下一城”时不应该仅仅理解为他们又开拓了一个市场。这更像是一次精心设计的“压力测试”升级。每进入一个新的城市就意味着他们的系统要学习一套新的交通规则、适应新的道路拓扑结构、应对新的驾驶习惯比如不同城市的司机在并线时的激进程度可能完全不同。这种跨城市的复制能力才是检验其技术栈是否真正具备鲁棒性的关键。这远比在同一个测试场里跑出百万公里无事故接管更有说服力。2. 技术栈拆解如何用“经典算法组合拳”撑起商业化服务很多人被“端到端大模型”、“世界模型”这些热词搞得心潮澎湃觉得传统的模块化自动驾驶栈已经过时了。但像May Mobility这样已经实现商业化收费运营的公司其技术底座恰恰是那些经过千锤百炼的“经典算法”。他们的成功给行业提了个醒在追求技术前沿的同时工程的稳定性、可靠性和可解释性才是商业化落地的生命线。2.1 感知层多传感器融合与场景化降维在公开资料和其车辆外观上可以看到他们采用了相当务实的传感器方案激光雷达LiDAR、毫米波雷达和摄像头的组合。这不是堆料而是针对通勤场景的精准配置。激光雷达提供精确的三维点云用于构建车辆周围的高精度静态环境模型以及检测障碍物的轮廓和距离尤其是在光线不佳的夜晚。毫米波雷达的优势在于测速精准、不受天气影响对于检测突然切入的车辆非常有效。摄像头则负责丰富的语义信息提取如交通灯颜色、车道线、行人姿态、交通标识等。关键在于融合。并不是所有数据都要进行前融合数据级融合那样计算负荷太大。更常见的策略是后融合或特征级融合。例如激光雷达识别出一个移动物体的轮廓和位置毫米波雷达提供其精确的相对速度摄像头则判断它是不是一辆车、一个行人还是一辆自行车。这种“各司其职结果汇总”的方式在保证安全冗余的同时也兼顾了系统的实时性。对于固定路线系统甚至可以预先标注出所有关键感知点告诉感知模块“在这个位置你需要特别关注右侧汇入的车辆”从而实现算力的有侧重分配这是一种典型的场景化降维思路。2.2 规划与控制Apollo EM Planner思想与业务逻辑的深度结合规划模块是自动驾驶的大脑决定了乘坐的舒适性和效率。May Mobility虽然没有明确说明其规划器细节但从其行驶风格和场景推断其核心思想很可能与百度Apollo开源的EMExpectation-MaximizationPlanner有异曲同工之妙。EM Planner的核心是分层迭代首先在 Frenet 坐标系以道路中心线为参考的坐标系下生成一条粗粒度的、考虑交通规则和障碍物的“可行路径”然后在笛卡尔坐标系下进行精细化优化考虑车辆的动力学约束如曲率连续、加速度平滑。对于通勤服务规划器有一个独特的优势它拥有海量的历史运行数据。这意味着它可以学习人类司机在这条线上的优秀驾驶习惯。比如在某个路口人类司机通常会提前50米开始向左侧车道并线以避开右转专用道。规划器可以将这种经验固化为一条“偏好规则”。同时控制模块负责将规划出的路径转化为方向盘、油门、刹车的具体指令也会针对固定车型进行深度标定。通勤车通常是同一型号这省去了大量适配不同车辆动力学参数的麻烦可以让控制算法调校得极其细腻从而实现接近“老司机”的平顺启停和过弯。2.3 为什么不是纯粹的“端到端”当前火热的端到端自动驾驶指的是用一个大模型直接从传感器输入图像、点云映射到控制输出方向盘、油门。它的优势是简洁理论上能更好地处理长尾场景。但它的“黑盒”特性是商业化运营的致命伤。当发生一次不寻常的刹车时工程师如何排查是摄像头被强光眩目了还是激光雷达误把飘过的塑料袋当成了障碍物在模块化架构下我们可以检查感知模块的输出日志、规划模块的决策树。但在端到端模型里这几乎是不可能的。对于承担实际客运服务、需要明确责任界定的运营商来说系统的可解释性、可调试性与安全性同等重要。May Mobility选择的这条“经典算法”道路虽然看起来不够“性感”但每一步都走得扎实每一个环节都可追溯、可分析、可优化。这正是工程化思维与科研思维的典型区别。3. 数据闭环商业化运营背后的“隐藏引擎”如果说算法模型是自动驾驶的“大脑”那么数据就是喂养这个大脑的“粮食”而数据闭环系统则是高效生产、加工粮食的“自动化农场”。May Mobility能够快速拓展城市其背后一定有一套成熟的数据闭环体系在高效运转。这套体系才是其真正的竞争壁垒。3.1 数据采集与“影子模式”每一辆在线上运营的May Mobility车辆都是一个持续不断的数据采集单元。它们不仅记录着传感器原始数据图像、点云、雷达信号更关键的是记录着车辆的状态数据速度、位置、控制指令以及最关键的人类安全员的干预行为如果有的话。当安全员认为系统决策不当而接管车辆时这次接管的触发前几秒到后几秒的数据就成了一份宝贵的“负面教材”。更高级的模式是“影子模式”。即便在无人驾驶状态下系统也在默默地运行两套逻辑一套是实际控制车辆的“主模型”另一套是并不输出控制指令只是进行虚拟推演的“影子模型”。影子模型可以尝试不同的决策比如“如果当时我选择更早变道会怎样”然后将推演结果与实际情况对比。这个过程不干扰实际驾驶却能源源不断地产生用于模型对比和优化的仿真数据。3.2 自动化标注与仿真重建海量的原始数据是矿石需要被提炼成标注好的数据才能用于训练。对于自动驾驶标注工作极其繁重需要框出每一辆车、每一个行人、每一个交通标志。May Mobility由于路线固定可以大量运用自动标注技术。通过高精地图的先验信息系统可以预先知道某个位置应该有一个停止线。当车辆再次经过时算法可以自动将摄像头捕捉到的图像特征与地图匹配从而半自动地完成标注效率远高于纯人工。对于像安全员接管这样的关键场景仅仅有数据还不够还需要在仿真环境中进行“场景重建”。工程师们会利用采集到的数据在虚拟世界里1:1复现当时的路况、天气、所有交通参与者的位置和运动轨迹。然后让更新后的算法模型在这个仿真场景中反复“演练”直到它能够做出比之前更安全、更合理的决策。这种基于真实数据生成的仿真场景比完全随机生成的虚拟场景对算法提升的价值要大得多。3.3 模型迭代与OTA部署通过上述流程算法团队获得了高质量的标注数据和仿真测试用例。接下来就是模型训练、验证和测试。在仿真环境中通过严格测试后新模型会先在一个“小车队”上进行实际道路测试持续收集数据确认其表现优于旧模型。最后通过OTA空中下载技术的方式将新模型同步部署到所有运营车辆上。至此一个完整的数据闭环就完成了从真实世界发现问题、采集数据到自动化处理、仿真测试再到模型更新和车队同步最后又回到真实世界接受检验。这个闭环转得越快算法的进化速度就越快。May Mobility每进入一个新城市这个闭环就会吸收该城市独特的数据快速迭代出适应本地交通风格的驾驶模型这是其能够快速复制的技术内核。4. 安全与体验商业化运营必须跨越的双重门槛技术再先进如果不能转化为乘客可感知的安全感和舒适感一切都是空谈。对于自动驾驶通勤服务安全和体验不是两个独立指标而是交织在一起的统一体。一次不舒适的急刹即使是为了安全也可能让乘客心生疑虑而过于保守的驾驶策略导致通行效率低下同样会影响用户体验和商业效率。4.1 功能安全与预期功能安全SOTIF功能安全关注的是系统“不发生故障”的能力比如硬件坏了、软件出错了怎么办。这通过冗余设计来实现双计算单元、双电源、双通信链路。一个系统失效备份系统立即接管确保车辆能执行最低风险策略比如安全靠边停车。但自动驾驶更多的事故并非源于系统故障而是源于“性能不足”——即系统在复杂的场景下做出了错误决策。这就是预期功能安全SOTIF的范畴。SOTIF关注的是如何消除由于设计局限或场景认知不足而导致的危险。对于May Mobility提升SOTIF的主要手段就是前面提到的数据闭环。通过不断收集“边缘场景”那些不常见但危险的情况的数据来扩充系统的认知边界减少“未知的不安全”。4.2 乘坐体验的精细化调校乘坐体验直接关系到用户留存和口碑。这主要靠规划与控制算法的精细打磨。平顺性控制算法对加速度和加加速度急动度有严格限制。起步和停车不是简单的“给油”和“刹车”而是遵循一条平滑的速度曲线模仿最沉稳的司机。过弯时规划器会计算出一条曲率连续变化的轨迹避免方向盘的突然转动。可预测性乘客的紧张感往往来源于“不知道车子要干什么”。好的自动驾驶系统应该像一位沟通清晰的司机。例如在需要变道时它会提前一段时间开始温和地靠近车道线而不是临到路口才突然并线。这种“意图表达”通过车辆的运动轨迹提前传递出来让乘客和周围车辆都感到安心。场景化策略通勤路线上常有公交站、学校等特殊区域。在这些区域系统会主动采用更保守的策略比如将最高时速限制得更低对行人的检测范围扩大准备更早的制动。这种策略不是全局的而是基于高精地图的语义信息触发的从而在安全与效率间取得最佳平衡。4.3 人机交互与冗余保障车内的人机交互界面也至关重要。一个清晰的界面能够实时显示车辆感知到的周围环境如用图形标示出检测到的车辆、行人、自行车并语音提示下一步动作“前方红灯正在减速”可以极大地缓解乘客的焦虑建立信任。最后尽管目标是无人化但在现阶段远程监控中心和必要时的人类安全员仍然是重要的安全冗余。远程监控中心可以同时关注多辆车的状态在车辆遇到无法处理的极端情况时远程操作员可以介入提供指导或直接控制车辆脱困。这种“人在回路”的混合模式是当前阶段实现商业化运营不可或缺的安全网。5. 挑战与展望通勤服务只是起点虽然May Mobility在固定路线通勤服务上找到了突破口但前方的挑战依然巨大。商业模式的可持续性是首要问题。自动驾驶车辆的硬件成本尤其是激光雷达仍然高昂车队规模、运营效率、票价设定需要找到一个微妙的平衡点才能实现盈利。这不仅仅是技术问题更是运营和财务问题。法规与责任认定是另一座大山。在不同城市乃至不同国家如何取得运营许可发生事故后责任如何在运营商、技术提供商、车辆制造商之间划分这些都需要清晰的法规框架。May Mobility与地方政府紧密合作往往是以试点项目的形式落地正是在为未来更大规模的法规制定积累实践案例。从技术演进看固定路线通勤服务可以看作一个“训练场”和“数据富矿”。在这里验证成熟的技术模块感知、规划、控制积累海量的、高质量的、带有详尽标注的“场景库”。这些资产的价值是无限的。未来当传感器成本进一步下降算力进一步提升算法更加鲁棒从固定路线扩展到半固定路线如区域接驳再逐步扩大运营区域ODD是一条水到渠成的路径。届时今天在通勤线上积累的每一个应对雨雪天气的案例、每一个处理施工路段的策略都将成为构建更通用自动驾驶能力的基石。我个人看来自动驾驶的终局未必是彻底取代人类司机而是在不同的细分场景下找到最适合机器发挥优势的形态。像May Mobility这样从真实需求出发用工程化的思维一步步解决具体问题反而可能比那些一开始就瞄准“全场景”的玩家更早地跑通商业闭环真正让技术服务于人们的日常生活。他们的每一次“又下一城”不仅是商业版图的扩张更是整个行业向务实发展迈出的坚实一步。