现实有时候比想象还要有想象力。3月29日晚上，一辆小米标准版在德上高速公路池祁段行驶过程中，遭遇重大事故，车上3人全部死亡。隔了2天半，4月1日中午，小米官方对这件事的回应，突然冲上热搜第一。这次是不是买的热搜，需要大家自行判断。如果是的话，小米确实有些路径依赖了，舆论工具箱里不应只有流量一种。

小米官方称，当时高速事发路段施工修缮，用路障封闭本车道，改道至逆向车道。车辆检测障碍物后，发出提醒，并开始减速。随后驾驶员接管车辆进入人驾状态，持续减速并操控车辆转向，随后车辆与隔离带水泥桩发生碰撞，碰撞前系统最后可以确认的时速约为97km/h。

更应该关注的，并非电池爆燃和能否开门，因为时速97公里下的正向碰撞，什么能源方式和车门设计，已经不重要了。

我们更应该聚焦官方发布的时间-事件轴，争取找出原因或者规律来。

接下来，我们全文抄录官方数据：

这里面蕴含的信息，哪怕有可能被遮掉的信息，对还原事态都价值非凡。信任官方数据的前提下，我们关注到以下3个重要的点：

第一，小米标准版没有AEB。不管他配置表上有没有，实际就是没有。

22:44:24提示风险，22:44:25就被人工接管，驾驶员反应是相当在线的。至于减速，2秒内从116km/h减到97km/h，大部分减速是人工完成的。因为被接管的刹那，制动踏板开度仍然只有31%（开度越大，刹车力度越大，但非线性对应关系）。

策略上，不管人工还是高速NOA，这么快的车速下，配合打一点方向（不能打大方向，否则姿态稳不住），同时应全力刹车。而全力刹车每秒应该能减25m/s左右。而实际上高速NOA并未采取这一策略，让人困惑。看来它并未将局面视作必须全力避免的情况。

这表明，SU7的AEB没有介入。

第二，传感器探测距离，不支持120km/h下的NOA。

SU7标准版没有激光雷达。摄像头探测距离莫衷一是，大致的说法是100米以内，但这和现场夜间照度有关。如果高速上照度不足，远光灯也射不了100米以上，116km/h的速度，折算成32.2m/s。100米的距离，3.1秒跑完。NOA系统没有能力在1秒内处理这个非结构化场景（修缮、封闭本车道、导引到其他车道），就只剩下2.1秒给人工了。这套规则显然不合理。

实际情况下，距离碰撞2秒的时间（未标精确碰撞时间点）才要求接管，驾驶员花1秒接管（已经很快了），剩下1秒。全力刹车的话，官方百公里时速刹车距离是33.5米。而时速116公里，刹停距离33.5*1.16=38.86米，是非常理想化的。因为高速制动存在钝化效应。而且说实话，就是这个33.5米，也是专业人士在赛道上、非紧急情况下踩出来的。普通人慌乱时要是能达到这个水平，可以说比赛车手都厉害了。

如果现场这个驾驶员说天赋异禀行不行？不行。因为碰撞时速仍有97公里，人工接管时的时速至少在105公里以上。此时还剩1秒-3秒。如果取“时间前沿”（1秒），我们按照最保守的97公里时速来算，距离障碍物只有26.9米，时速97公里，完全无法刹停。

如果取“时间后沿”（3秒），此时距离障碍物还有80.8米（仍按97公里时速），理论上可以刹停。

那么就引出第三个问题了，时间颗粒度问题。

即碰撞发生前的时间-事件轴颗粒度非常精细，但到了碰撞的时候，官方就给出非常宽泛的2秒时间，以至于无法精确标定碰撞时间点。

一种可能，碰撞过程花了2秒，那么就满足时间前沿的说法，即当时情况下，只要NOA是这个工作方式，碰撞就无法避免。

另一种可能，车辆碰撞的瞬间，大电池和小电瓶均掉电，后台因此没收到精确数据。

第三种可能，官方有意“粗化”了碰撞时间颗粒度，避免引向一个唯一的结论——小米SU7标准版，在夜间不应该支持时速超过100公里以上的NOA。

具体结论如何，各位自行判断。

以上三点，并非一定就是小米的问题。小米如果希望自证的话，应该公布更详细的原始数据，比如传感器日志、制动系统响应曲线、重建现场动态图等。一方面有助于透明化调查过程，另一方面也可以重建对小米NOA技术的信心。

智驾系统在事故无法避免的情况下要求人工接管，是非常不负责任的。既然硬件能力上不支持，就不应该允许客户低照度下进入高速NOA。

虽然小米不大可能公布具体的算法逻辑，但我们猜想，算法对非标障碍物的识别存在短板。采取措施太晚，措施又不够坚决。发现不行，再让人工接管，已经于事无补。

和NOA的甩锅一样，官方声明也有甩锅嫌疑。官方字里行间可能暗示，NOA系统减速了，也提醒了，驾驶员没处理好。但实际情况是此时接手，神仙来了也难救。即算法未能给接管机制提供足够冗余。

还有个小细节，就是有人认为小电瓶没断电，Ecall能够接通。而Ecall实际上用的是备用电源，和小电瓶无关。

这也反映了小米对实车验证、数据闭环非常不足。高速修缮，属于长尾工况，低照度下高速，是常见工况（出现风雪雨雾等天气，也是常见的）。而高速上出现标准和非标障碍物，是必须要测试到的。

这个时候考验AEB阈值的时候就到了。结果AEB没有介入，系统响应延迟，导致未能把握时间窗充分降速。

小米此前因为自动泊车Bug，导致多辆车同一时间段出事故。官方并未给详细解释，因为舆论压力不大（似乎没出现伤亡）。这次很难回避了，小米迄今的回应，很聪明地没给结论。但官方数据本身，已经透露了小米技术存在缺陷的可能性很大。

任何NOA，不管高速还是城区，都需要增强场景泛化能力，提升对非标障碍物的识别能力，这方面的验证是否充分，决定了NOA的体验，少数时候则是生与死的差别。机制上，应该给人工接管留下冗余时间。

小米应该将重点放在还原事态、优化技术上面。小米的流量打法，一直以来确实无往不利，若这种事也用流量打法，未免太过突破下限。小米应该不屑为之。

-   E N D   -

点击下方名片 关注我们↓↓↓