第3章人机交互设计

第三章：人机交互设计：HMI设计原则，告警与接管请求的时机

各位工程师，咱们今天聊聊HMI。说白了，就是车怎么跟人“说话”。

我做了这么多年ADAS，最深的体会是：系统做得再好，如果人机交互搞砸了，用户照样骂娘。你想想看，一个紧急刹车功能，明明救了命，结果因为告警太吓人，用户反而投诉说“这车有毛病”。这就是典型的“技术满分，体验零分”。

所以这一章，咱们重点讲两个事：HMI设计该遵循什么原则，以及什么时候该告警、什么时候该让用户接管。

我个人习惯把HMI设计原则归纳为三条。不多，但每条都是踩坑踩出来的。

什么叫可预测？就是系统要做什么，用户提前能感觉到。

举个例子。ACC自适应巡航要减速了，你不能等到刹车都踩下去了才“叮”一声。我建议提前1-2秒给个视觉提示，比如仪表盘上显示“前车减速，本车将跟随减速”。用户一看就明白：“哦，系统要刹车了，正常。”

我在项目中遇到过一个问题：某款车的车道保持功能，每次介入修正方向盘时都没有任何提示。结果用户觉得“车在跟我抢方向盘”，投诉率极高。后来加了一个轻柔的震动反馈和图标闪烁，问题就解决了。

  核心要点： 用户对系统的行为要有预期。没有预期的交互，就是惊吓。

这个原则其实很简单：同一个功能，在不同场景下，交互方式要一致。

比如，LKA（车道保持辅助）的告警，不管是白天还是晚上、高速还是市区，声音、图标、震动模式都应该统一。你不能说白天用“滴滴”声，晚上用“嗡嗡”声。用户会懵的。

我记得有一次评审一个HMI方案，设计团队把“系统故障”和“功能降级”用了两种完全不同的图标和颜色。我说：“你们这是让用户考驾照呢？记这么多图标？”后来统一成红色代表“立即行动”，黄色代表“注意观察”，简单多了。

小技巧： 建议建立一套HMI设计规范文档，把所有告警的触发条件、表现形式、优先级都写清楚。团队照着做，就不会跑偏。

这一点尤其重要。告警和接管请求，必须在用户还有反应时间的时候发出。

我见过一个反面案例：某款车的AEB（自动紧急制动）告警，在碰撞前0.3秒才响。你想想看，0.3秒够干什么？眨个眼就过去了。用户根本来不及反应，告警等于白设。

那什么时候算“及时”？我一般按这个标准来：

你可能会问：“10秒够吗？”说实话，在高速上，10秒能跑将近300米。如果用户注意力分散，10秒可能都不够。所以我个人建议，能早尽量早。

注意： 接管请求的时机不能太晚，但也不能太早。太早了用户会觉得“这系统怎么老烦我”，产生信任危机。这个度，需要大量实车测试来标定。

告警不是越响越好。我习惯把告警分成三个层级：

这里有个坑，我曾经踩过：L3告警的声音频率和音量，一定要经过主观评价。太尖锐了用户会吓一跳，反而影响操作；太柔和了又起不到警示作用。我一般建议用400-800Hz的中频音，音量比车内正常语音高10-15dB。

咱们聊点具体的。接管请求（TOR，Take Over Request）是HMI设计里最难的部分。

我曾经参与过一个项目，系统在高速上遇到施工区域，需要用户接管。设计团队把TOR设置在碰撞前8秒。结果测试时发现，有30%的用户在8秒内无法完成接管——因为有的人在聊天，有的人在看后视镜，注意力根本不在路上。

后来我们做了改进：

这个方案最终通过了验收。说白了，就是给用户留足“反应+决策+操作”的时间。

  经验公式： 接管请求的提前时间 = 用户反应时间（2-3秒）+ 决策时间（2-3秒）+ 操作时间（3-5秒）+ 安全余量（2-3秒）。加起来至少10-14秒。

最后，分享几个我亲身经历过的教训：

坑一：告警太多，用户直接关掉。 我曾经见过一个系统，每次变道都“滴滴”响。结果用户直接把告警音量调到最低，等于废了。所以，告警要“少而精”，只在真正需要的时候触发。
坑二：声音和视觉不同步。 有一次测试，图标已经显示“请接管”了，声音却晚了2秒才响。用户说：“我看到图标了，但声音没响，我以为系统自己处理了。”结果就是没接管。所以，多模态告警必须同步。
坑三：忽略用户状态。 同样的告警，对专注的驾驶员和分心的驾驶员，效果完全不同。我建议系统如果能检测驾驶员状态（比如通过摄像头看视线方向），可以动态调整告警强度。比如，发现驾驶员在看手机，告警音量自动提高5dB。

嗯，关于HMI设计，今天就先聊这么多。记住一句话：好的HMI，让用户觉得“这车很聪明”；差的HMI，让用户觉得“这车在跟我作对”。下一章咱们讲功能安全与HMI的融合设计，到时候再细聊。