前几天，小米前高管王腾在社交媒体上提到，自己驾驶的 SU7 Ultra 遥控泊车出了问题。车没按预期识别到车位，最后还是得靠驾驶员手动泊入。这个场面之所以被放大，不只是因为“出 bug”，更因为提问题的人偏偏是前高管，话题一下就有了戏剧性。
现在这件事又有了后续。王腾再次发文，把前因后果和处理进度补了一遍，也算是替老东家把一些误会先压下来。按他公开的说法，当时是喝酒后请同事帮忙代驾回家，到车库后原本想直接用遥控自动泊车，结果故障出现了。
故障不是“没停好”，而是没认出车位
从这次描述看，问题的核心不是泊车执行得不够顺，而是前面的识别环节就卡住了。也就是说，车没有顺利判断出可用车位，后续的自动泊入自然就没法继续。
这类故障在智能车里并不陌生。遥控泊车本身也不是“方向盘自己转一下”这么简单，它前面依赖感知、环境识别、路径规划，后面还要接上执行控制。前面任何一环出问题，最后呈现出来的结果，可能都只是“车没反应”或者“识别失败”。
所以很多人看到的只是一个很直观的现象：功能没跑通。但工程师真正要查的，往往是识别逻辑、环境条件、软件分支，甚至是具体版本下的触发边界。
小米反应快，但问题还被复现了
王腾发动态后，小米很快给他拉了个群，把泊车相关工程师也拉了进来。这个反应速度不慢，至少说明厂商对这类高关注问题是接得住的，不至于让外部吐槽一直悬着。
更关键的是，按王腾公布的聊天截图来看，这件事并不是只出现了一次的偶发毛刺。第二天同样的问题还被复现出来了。
这点挺重要。能复现，意味着它更像是一个有条件触发的稳定问题，而不是一次性的“运气不好”。对工程师来说，可复现 往往比“偶尔报错”更有价值，至少能缩小排查范围；对用户来说，复现也意味着别急着把它当作已经被解决的小插曲。
车上还有一个“上传数据”的操作
聊天记录里还提到一个数据上传动作：方向盘按键、左侧、调距键任意一个长按 5 秒，可以完成数据上传。这个细节很像车企在处理故障时的常规手段——先把车端日志传上去，再判断到底是哪一段链路出了问题。
但这里要留一点余地：这是不是专门针对王腾那台故障车做的远程设定，还是 所有小米车辆 都预留了类似操作，现有材料并没有说明白。车主如果真的想试，也得先确认官方说明，别把一个排障动作误当成通用技巧，更别在不清楚机制的情况下反复操作。
因为对智能汽车来说，上传日志、复现问题、确认版本，这些步骤往往比“能不能当场修好”更重要。车机、泊车、辅助驾驶这些功能，表面看像体验问题，底层其实都靠代码和数据闭环撑着。
这类 bug 不奇怪，关键是后续怎么收口
王腾自己也说了，这种 bug 很正常，还感谢了小米团队的快速响应。这个态度其实挺现实：新能源车越来越像一台大号电子产品，功能靠软件堆出来，bug 也就很难完全绝缘。
但“正常”不等于可以忽略。真正拉开差别的，不是出了没出问题，而是问题出现后，厂商能不能快速定位、能不能复现、能不能把修复推到后续 OTA 里。对车主来说，最实在的期待也不是热闹，而是下一次更新里，这个泊车逻辑能不能更稳一点。
如果后续 OTA 真的把这类识别问题修掉了，那这次看起来有点尴尬的“抓包”，反而可能变成一次很典型的产品回收过程：用户暴露问题，工程师复现问题，厂商再把功能补齐。
说到底，智能车的魅力和麻烦，本来就是同一件事。它能靠软件不断变强，也会因为软件不断暴露边界。王腾这次把一段尴尬过程摆到台面上，未必是坏事，至少让大家看见了一个很现实的链路：问题出现、工程师介入、数据上传、继续复现、等待修复。这比空喊“体验升级”要真实得多。
