ARTICLE · 1191241
Waymo 第 6 次软件召回:L4 运维新常态
Waymo 第 6 次软件召回：L4 运维新常态
VPERED-143 · 深拆 · 底盘智驾
2026 年 6 月 12 日，Waymo 向美国国家公路交通安全管理局（NHTSA）提交自愿召回备案，编号 26E035，涉及 3871 辆搭载第五代自动驾驶系统（ADS）的车辆（整车口径）。NHTSA 于 6 月 17 日发函确认。
缺陷描述写得很直白：软件可能允许车辆进入已封闭的高速公路施工区并继续高速行驶。后果是：通过封闭施工区会增加碰撞风险。补救措施是更新 ADS 软件，使其能检测是否处于施工区并避免驶入，免费提供。在修复部署完成前，Waymo 主动限制了高速公路运营范围。
按公开报道口径，这已是 Waymo 2026 年内的第 6 次软件类召回（统计口径以报道为准，是否含硬件类召回及同一缺陷的多次备案未逐笔核对）。对习惯了"硬件缺陷才召回"的人来说，这个频率本身就是一个信号：在 L4 车队里，召回正在从一次性事件变成持续性运维。
· · ·
① 事件本身：一次备案里的两组数字 |
把这起召回的时间线还原出来，能看到一个值得学习的内在逻辑——它不是出了事故才召回，是内部安全委员会从运营数据里挖出来的。
两个细节值得注意。其一，召回文件记录的事件总数为 13 起（凤凰城 6 起 + 旧金山 7 起），据 Waymo 表述全部没有导致碰撞或人员受伤——Waymo 明确表示这一点。其二，召回文件列出的受影响系统生产日期跨度为 2022 年 3 月 17 日至 2026 年 5 月 19 日。该跨度对应的是本次备案涉及的第五代 ADS 系统件，而非整车生产日期；这批系统与其他系统的区别在于具备无人驾驶高速公路行驶能力。
⚠️ 口径标注：召回编号、日期、涉及车辆数与缺陷描述均来自 NHTSA 官方召回文件；事件总数取自召回文件，各起事件的时间与场景细节为公开报道转述，个别日期在不同信源中表述略有差异。 |
② 缺陷的技术本质：施工区是感知的长尾，不是 bug |
把"软件缺陷"理解成代码写错，会低估这件事的工程含义。施工区识别的难点不在算法能力，而在场景的不可枚举性。
一个封闭高速施工区的完整语义是多重信息的叠加：锥桶的摆放形状、车道线的临时变更、护栏的连续性、施工标志的牌面、有时还有作业人员的姿态。这些元素各自都不难识别，难的是它们的组合方式近乎无限——顺向封闭、匝道封闭、部分车道封闭、移动式作业，每一种都有不同的空间语义。
召回文件里有一句关键描述：在某些情况下，车辆可能因不当优先规避其他高速公路风险和/或未能识别施工区域，而驶入施工区。另据报道，部分事件中车辆驶过了匝道封闭标志——该表现的归属层级（感知或决策）属推测。若按召回文件描述推断，这更接近决策层的风险优先级排序问题，而非单纯的"看不见锥桶"；但具体归属层级仍属推测。
这一分层与最终采取的"软件更新"补救方向一致（补救方式的选择还受成本与部署可行性影响），也解释了为什么这类问题无法在出厂前"测完"——测试集可以覆盖已知场景分布，但覆盖不了尚未出现过的组合。
③ 制度对照：中美召回机制差在哪 |
Waymo 在 2026 年内已发生 6 次软件类召回，放在中国的召回体系里看，差异是结构性的。
⚠️ 口径标注：上表为基于公开召回案例的实践观察，非制度条文对比，亦非法律意见；中国智能汽车软件召回的具体认定标准与流程以主管部门正式文件为准。 |
最值得关注的是最后一行的责任主体问题。Waymo 的模式是三位一体——车是它的、运营是它的、软件也是它的，所以召回义务清晰、执行也快。国内 Robotaxi 与 L3 量产车里，车企、运营方、算法供应商常常是三家公司，一旦出现软件层面的缺陷，召回义务由谁发起、费用由谁承担，需要协议先约定。
④ 软件召回的工程流程：OTA 不等于召回 |
一个常见混淆是：既然能 OTA，那软件问题远程升级就行了，为什么要走召回？这两件事在法律与工程上是分开的。
Waymo 这起召回的补救措施写得很有意思：备案时（6 月 12 日）修复方案"正在开发中"，在此期间先限制高速公路运营；随后 6 月 16 日完成首版软件更新，6 月 25 日恢复高速运营。也就是说，在软件修好之前，用运营范围的收缩来降低暴露——对具备运营控制权的 L4 车队而言，这是一种可用的过渡手段；不直接控制运营车队的车企，通常缺少以 ODD 收缩快速降低暴露的手段。
对国内做智驾的团队，这条经验可以直接借鉴：当某个场景存在未解决的风险时，先用 ODD 收缩把风险窗口关掉，再慢慢修。这比"边跑边修"在安全论证上干净得多。
⑤ 安全叙事与召回并存：那个 12 倍怎么说 |
公开报道中常引用一个数据：Waymo 称其行人伤害事故率约为人类驾驶员的 1/12。需要点破的是，媒体常见的"比人类少 12 倍"这个说法在算术上并不成立——减少量不能超过基数本身，正确口径就是"约为人类的 1/12"。把它和 2026 年内 6 次召回放在一起看，很多读者会觉得矛盾——既然安全 12 倍，为什么老在召回？
这两个数不矛盾，因为它们测的不是同一件事。事故率是结果指标，反映的是系统在已运营场景中的表现；召回频率是过程指标，反映的是发现问题后如何处置。一个系统完全可能同时做到"事故率显著低于人类"和"频繁召回"——两者可能同源于较高的安全投入与问题暴露意愿，而非简单的因果关系。
真正需要警惕的是另一种组合：事故率数据漂亮，但召回记录空白。那可能意味着问题没有被发现，也可能是因为缺陷通过 OTA 静默处置而未进入召回统计，还可能确实未出现达到召回门槛的缺陷——需结合 OTA 记录与运营数据综合判断。在缺陷真实且处置及时的前提下，召回频率或可作为安全投入与问题暴露意愿的间接观察窗口，而不必然代表安全水平差。
你所在的团队遇到智驾相关缺陷时，是走 OTA 静默修复，还是会评估是否需要备案召回？这个判断在国内还没有特别清晰的判例，评论区聊聊你们的做法——这可能是未来两年最需要行业共识的一件事。
— 本文基于 NHTSA 公开召回文件与公开报道整理，制度对比部分非法律意见 —
以上是本文的全部内容。如果觉得有收获，欢迎转发给做智驾系统、功能安全和整车合规的同行——软件召回不是失败的标志，是 L4 时代的常态运维。
— VPERED-143 END —
· · ·
