Waymo扩张到三座新城市，把雪天与窄街推上台面。本文用它做案例，对比Tesla与中国车企的自动驾驶AI本地化路径与UX取舍。
Waymo进军三城：自动驾驶AI如何适应严冬与窄街？
Waymo把Robotaxi业务推进到明尼阿波利斯、新奥尔良和坦帕，这事表面看是“又多了三座城市”，但真正的难点写在城市名背后：极寒与积雪、老城窄路、潮湿暴雨与强光反射。自动驾驶落地从来不是“把同一套模型复制粘贴”，而是一场持续的本地化软件战。
我一直觉得，判断一家自动驾驶公司是否“能扩”，别只看它在某个示范区跑得多顺，而要看它愿不愿意、也有没有能力去啃不舒服的环境：雪天标线消失、路沿被雪堆吞掉、法国区那种窄巷突然来一辆送货车、佛州午后暴雨把传感器视野压成一团灰。
这篇文章放在《自动驾驶 AI：Tesla 与中国车企的发展路径对比》系列里，我们用Waymo这次扩城做一个更实用的案例：不同公司如何用AI与汽车软件体系，把“适应城市”这件事做成可规模化的产品能力。它不仅关乎自动驾驶，也直接影响智能座舱体验、功能上车节奏、以及最终的商业化效率。
扩城真正考验什么：不是地图，而是“长尾环境”
扩到新城市，最大的变量不是新增道路里程，而是新增“你从未见过的麻烦”。自动驾驶的事故往往不来自常规场景，而来自长尾（rare/edge cases）：低概率但高风险的组合条件。
拿这三座城市做拆解，会发现它们在“难点类型”上很互补：
- 明尼阿波利斯：典型北方城市冬季工况。积雪覆盖车道线、路口雪泥反光、黑冰导致前车轨迹异常、铲雪车与雪堆改变道路可通行区域。
- 新奥尔良：老城街区道路更窄、路边临停多、行人和非机动车混行更随机；加上节庆活动频繁，临时交通组织改变常态分布。
- 坦帕：潮湿、多雨、强对流天气更常见；暴雨下的可见度骤降、路面积水影响制动与跟车策略；强光和水膜带来镜面反射。
一句话概括：扩城不是“新增地图”，而是新增一整套数据分布与安全约束。
你以为的“本地化”：加点规则
很多团队最初会走向“加规则、加白名单”的路径：某些路口强行限速、某些区域强行保守。短期确实有效，但扩城一多就会变成维护地狱。
真正可规模化的本地化，是把城市差异分层处理：
- 感知层：恶劣天气下如何稳定检测边界、动态体、可行驶区域
- 预测层：本地驾驶风格、行人/车辆意图的分布变化
- 规划控制层：在低摩擦/低可见度下如何“更稳但不僵”
- 运营层：ODD边界、接管策略、远程支持、车队调度
Waymo选择的城市，几乎就是在逼迫系统把这四层都“练扎实”。
Waymo的路线：多传感器与强ODD运营，把不确定性关进笼子
Waymo一贯的核心思路很明确：用多传感器冗余 + 高精地图/语义先验 + 严格ODD（运行设计域）管理 + 成熟运营体系，把自动驾驶从“算法演示”做成“可交付服务”。
这条路的优点是：
- 安全裕度更容易做出来：传感器冗余（激光雷达、雷达、摄像头）对低光、雨雾、反射的鲁棒性更强，失败模式也更可控。
- 扩城是工程化过程：数据采集、仿真回放、封闭测试、灰度运营，有明确节奏。
- 用户体验更像“服务”而不是“功能”：Robotaxi的体验核心不是炫技，而是可预期——准点、平稳、少惊吓。
但代价也同样清晰：
- 成本结构重：硬件与标定、运维与车队运营的成本都不低。
- 城市复制速度受制于流程：每个城市都要走相对完整的验证链条。
一个现实判断标准：如果你的系统需要“每城一套特殊规则”，你扩城就会越来越慢；如果你能把差异吸收到数据与模型里，你扩城才会越来越快。
冬季城市最难的不是“看不见”，而是“看见了也不敢信”
雪天的感知难点不只在“检测不到车道线”，更在于可行驶区域的不确定性：雪堆可能把路沿推到车道里、铲雪后路宽变化、积雪覆盖的标线与真实边界不一致。
这会直接影响规划：系统需要更频繁地做“保守假设”，同时又不能把车开成“随时要停在路中间”。对UX来说，用户不关心你用了什么网络结构，只关心：
- 刹车是不是突然
- 变道是不是犹豫
- 过路口是不是一惊一乍
稳定的乘坐体验，本质上是稳定的风险评估与控制输出。
Tesla vs Waymo：一个押“端到端规模”，一个押“受控运营”
放到本系列主题里，Waymo与Tesla的差异可以用一句话讲透：
- Tesla更像“规模化的端到端学习系统”：靠海量车端数据、快速迭代，把能力往通用驾驶推；更接近“功能上车”。
- Waymo更像“可交付的自动驾驶服务系统”：ODD更清晰、运营更重、对安全验证更流程化；更接近“服务交付”。
两者并不是谁更先进的问题，而是产品形态不同带来的必然选择。
扩城速度的来源不同
- Tesla的速度来自“车多、数据多、分发快”，更适合做大范围的能力覆盖。
- Waymo的速度来自“每一步更确定”，更适合在限定区域做高可靠运营。
问题是：当你走进明尼阿波利斯这种冬季长尾环境，端到端模型要证明的不只是“平均表现”，而是极端条件下的可控性。这也是为什么严冬城市经常被视为自动驾驶能力的“压力测试”。
UX的差异也很明显
我观察到一个容易被忽略的点：自动驾驶UX不是屏幕交互，而是车辆行为本身。
- Tesla更强调“像人一样开”的连续性与覆盖面，但在某些边缘场景可能出现“突然接管压力”。
- Waymo更强调“少犯错、少让用户紧张”，因此会更保守，但稳定性更像一项公共交通服务。
对做智能座舱/用户体验的团队来说，这意味着：HMI提示、接管策略、风险提示的设计必须和自动驾驶能力边界一致。能力不稳定，UX再漂亮也会翻车。
中国车企的现实打法：多供应商协同 + 快速本地化，把体验做进“场景”
把视角拉回中国市场，很多主机厂与供应链的组合更接近“多传感器、多供应商协同”的工程路线：
- 传感器与域控平台多样（不同价位、不同配置）
- 城市NOA/高速NOA分阶段落地
- 更强调在本土路况（加塞密度高、两轮车多、路口形态复杂）下的体验打磨
这条路的强项在于：
- 本地场景理解更细：比如对非机动车、外卖骑手、路边临停的策略更“贴地气”。
- 功能迭代更贴近用户诉求：例如拥堵跟车舒适性、匝道汇入效率、城市路口通过率。
- 座舱与生态联动更快：导航、语音、泊车、充电等体验更容易做成闭环。
但难点也很硬：多供应商意味着数据闭环、仿真体系、指标口径、版本发布节奏都更复杂。你要扩到更多城市，必须把“协同成本”压下来。
我更看重的能力：把本地化做成“平台能力”
如果要给中国车企一个务实的扩城/扩区路线建议，我会盯住三件事：
- 统一数据与指标：同一类场景（如无保护左转、窄路会车、雨夜逆光）要有统一的成功定义与可回放评测。
- 把高频长尾场景产品化：不要只讲“覆盖率”，要讲“在雨夜+临停+两轮车穿插时，系统的行为是否可预期”。
- 把座舱提示当作安全系统的一部分：何时提示用户注意、何时解释系统意图、何时让用户接管，都是安全设计，不是UI美术。
能在不同城市保持一致的“驾驶性格”，才是用户真正愿意长期用的智能驾驶。
读者常问：恶劣天气与窄街，AI到底怎么“学会”的？
答案很直接：不是一次训练学会，而是“数据—仿真—上线—回收”循环把错误变成资产。
通常会包含这些关键环节：
- 数据采集要覆盖极端条件：雪夜、雨夜、逆光、积水、临时施工。
- 场景挖掘与重放：把“差点出事”的片段自动挖出来，做回放评测。
- 仿真增强：通过传感器噪声建模、路面摩擦变化、遮挡模型等，把真实难题放大到训练里。
- 分级上线：先限定ODD与时间段，再逐步放开。
这也是为什么Waymo扩到明尼阿波利斯意义很强：它相当于在公开承认——系统要开始对冬季最难的一批长尾负责。
该怎么把Waymo扩城的启示用到你的汽车软件与UX里
如果你做的是主机厂软件、智能座舱、或自动驾驶量产项目，我建议把“扩城”当成一个产品能力清单来做。
一份可落地的检查表是这样的：
- ODD声明是否清晰：哪些天气/哪些道路类型/哪些速度范围可用？
- 降级策略是否一致：从城市NOA降到ACC/LCC时，用户会不会被突然“甩锅”？
- 行为可解释性：车辆为何慢下来、为何不变道、为何绕行，座舱能不能用一句人话说明？
- 舒适性指标量化：急刹次数、横向加速度峰值、犹豫（hesitation）时长要能被追踪。
- 本地化迭代机制：每周/每月哪些场景在变好？如何向用户透明沟通？
这些东西听起来偏“工程”，但最后都会落到一个结果：用户是否敢在雨雪夜把家人交给系统。
下一步：扩城会成为自动驾驶与座舱体验的分水岭
Waymo进入明尼阿波利斯、新奥尔良、坦帕的信号很明确：自动驾驶竞争正在从“谁先跑通一座城”，转向“谁能在更多不友好的城市保持稳定体验”。这也是《自动驾驶 AI：Tesla 与中国车企的发展路径对比》系列一直想讲的主题——路线不同没问题，但必须把扩展能力沉淀为软件平台与用户体验的一致性。
如果你正在评估自家方案该走Tesla式的端到端规模路线，还是更接近Waymo式的受控运营路线，我的建议是先回答一个更现实的问题：你的组织最擅长把不确定性变成数据，还是变成流程？
接下来一年（尤其是2026年冬季），我会重点关注一个指标：当更多城市把雨雪、窄路、临时管制摆到台面上时，哪些团队能把“保守”做得不让人烦，把“激进”做得不让人怕？你的产品，准备好接受这种压力测试了吗？