从5死车祸看ADAS的交互设计失败点

2026年5月30日，美国I-95公路一起施工区车祸导致5人死亡、40余人受伤。官方初步结论：大巴“未能减速”撞上多辆前车。这不是一起新技术事故——大巴很可能配备了传统AEB（自动紧急制动），但为何失效？

作为AI产品经理，我想跳出“算法还不够好”的归因，从交互设计角度问三个问题：

这三个问题，恰好对应当前ADAS人机交互的经典失败点。

用户真正需要的是什么？

施工区场景下，驾驶员需要的是一个双重保障系统：

但现在的ADAS产品设计往往把这两层割裂：信息层依赖导航地图和视觉标识，执行层依赖雷达和摄像头。而施工区恰好是信息层最薄弱的地方——临时标识可能被遮挡、地图更新不及时、视觉识别易受光线影响。

现在的AEB在标准测试场景下（静止车辆、前车急刹）表现不错。Euro NCAP 2025数据显示，AEB在30-50km/h下可避免约70%的追尾。

预警过早或过晚：施工区通常有多重减速标志。如果系统只在碰撞前2秒才报警，驾驶员来不及反应；如果过早报警（比如500米外），经验丰富的司机可能会习惯性忽略。
预警形式单一：大部分车辆只有声光警报，没有个性化强度调节。研究表明，持续高强度的蜂鸣声反而会降低司机对后续警报的信任（“狼来了”效应）。
缺乏渐进式干预：典型的AEB只在最后关头紧急刹停，而不是从“轻微压力->警示性减速->全力制动”逐步介入。这导致系统要么不工作，要么工作太晚。

ADAS warning timing diagram construction zone speed

当一个传感器说“前方有静止车辆”，而另一个传感器说“道路限速65mph可通行”时，系统应该信哪个？大多数OEM的决策逻辑是保守优先：只要有一个传感器认为有碰撞风险，就触发警报。但这里有一个隐藏的产品问题：警报频率与可靠性负相关。

以特斯拉为例，其视觉+毫米波方案在施工区常常因为识别到“塑料袋”或“反光锥”而触发误报警。用户不断关闭或忽略后，当真正危险来临时，用户反应时间反而延长。

我的判断是：在施工区这种高不确定性场景中，系统应该先假定风险存在，但报警方式应从“低干扰”开始，而不是“全面惊恐”。同时引入上下文置信度——当车辆进入施工区、导航显示限速变化时，提高对视觉识别的置信度，降低误报率。

这种设计的关键是让用户感觉到车辆在不断“检查”自己的行为，而不是突然决定接管。

在HUD或仪表盘上用环形进度条显示当前系统对前方障碍物的置信度。比如“85%确信前方有静止车辆”。这能帮助驾驶员理解系统是否“看到”了风险，而不是在黑盒中等待警报。

建议增加一个通过软件升级实现的“施工区模式”：当车辆检测到路侧临时施工标志或HD Map中的施工区时，自动启用更灵敏的AEB阈值和更早的预警。类似福特BlueCruise的“Hands-Free”区域限制思路。

如果你正在开发ADAS或L2+系统，以下4点可以立即评估并落地：

融合地图与视觉：将Nav2（离线地图）中的施工区数据作为视觉检测的先验概率。实验表明，这样可将施工区AEB的误报降低42%（来源：Waymo 2025施工区检测白皮书）。
实现渐进式制动：不要等到最后一秒全力刹停。在AEB激活前500ms，先施加0.2g减速度作为警示。用户报告认为“车辆在帮自己”而不是“突然吓一跳”。
设计用户反馈机制：允许用户在事后（停车后）对误报警告进行标记。用这些数据优化本地置信度模型。不需要上传到云端，利用端侧学习即可。
测试施工区场景：在内部测试矩阵中，加入“临时路锥被吹倒”“夜间施工区无反光标识”等边缘场景。目前大多数OEM的测试用例中，施工区覆盖率不足15%。

这次I-95车祸未必是因为ADAS失灵，但正是这种对“正常”系统失效的揣测，暴露出整个行业在交互设计上的懒惰。我们希望驾驶员信任系统，却只给了他们两个按钮：关闭Alertness或接受一堆假警报。

真正的产品能力，不在于有多少传感器，而在于让用户在正确的时间、以正确的强度得到正确的信息。这起事故不该被遗忘，它应该出现在每一个ADAS产品经理的OKR里。