10月21日15点13分，问界用户服务发布关于陕西省榆林神木市车辆事故的说明，其中最值得关注的一条是：碰撞发生后，车辆紧急呼叫(eCALL)系统即时触发并接通，同时问界道路救援中心拨打122上报事故信息，协助开展救援。这条"车自动触发→车企救援中心打122"的链路是真实存在的，并且已在深夜的事故现场运转过。但它能把遇险车主救到哪一步、车主自己还要补哪一半，比声明本身更值得拆开看。国是直通车
事故结果上，神木警方10月21日确认，该事故系一起单方事故，事发车上仅司机一人，已遇难，交警部门仍在进一步调查。车企侧的初步核实则显示：事发时车辆处于人驾状态，行经交汇路口时车速139.1km/h（路段限速50km/h），起火位置为车辆前部，初步分析为剧烈撞击致机舱线路短路及油液泄漏，同时否认"电池爆燃""智驾撞击"等网传信息。说明没有披露消防与急救到场的时间，也没有写明是否同步联动了119和120——这个信息空白，正是"拨打122"冲上热搜后的争议焦点。新京报
122确实打了，但122只派得出交警
eCALL并非车企自创概念，而是装在车端的紧急呼叫系统：简单来说，它是一种能够在满足条件的事故发生后，自动发起紧急呼叫或救援联络的系统。这套系统的存在感早已进入监管视野：北京奔驰2025年5月发布的部分国产E级召回中，就明确列出了"自动紧急呼叫（eCall）功能无法使用"的安全隐患。链路前半段——车端与车企接通——有成熟的工程依据；但后半段的去向才是理解的关键。122是公安交管部门的报警专线，今年7月下旬聊城交管支队122报警台接群众举报后15分钟查获一名涉酒驾驾驶人，这个号码调动的是交警的出警、到场和路面管控能力。知乎央视网光明网
交警的派单能力替代不了消防和医疗。今年9月四川广元朝天区一起货车相撞起火事故中，119指挥中心接报后调派3车15人到场，先控火再救出被困驾驶人。火情走119、伤员走120、事故路面走122，三条热线平行运转，彼此不会因为一通122就自动触发另外两条。问界发布说明当天，四川消防的安全提示把优先级讲得很直白：发现冒烟起火第一时间撤离到安全区域，立刻拨打119并远离车辆至少50米，切勿强行靠近灭火。人民网四川消防
这条链路有个前提：车的联网得在线
eCALL和SOS按键生效的前提，是车辆通信模块能拨出电话，而这个环节实际断过。今年7月，浙江一位车主反映其提车两个月的问界M8轮胎失压，按下SOS救援键后系统反复提示"电话因欠费暂时无法呼出"；售后回应称系流量卡切换故障，车主则质疑"险情时如何保障安全"。这起个案未起火、无伤亡，与致命事故场景完全不同，但指向同一个事实：车载紧急呼叫绑定在车联网卡与通信模块上，不等于手机119那样随时可通。据2024款问界M9车主晒出的体验，按下顶部SOS键可接通"问界紧急救援中心"并提供转人工服务——链路本身是否顺，取决于联网是否活着，两件事不能混为一谈。经理人杂志七略视频知乎
车主遇险，正确的联动顺序只有四步
致命事故里，再快的链路也快不过火：从撞击到整车燃烧以十秒计，这段时间内乘员唯一有效的动作是撤离。而在不至于起火、伤情的险境里，车端与车企链路才真正发挥价值——有问界车主分享过轮胎失压后按下救援电话，十几分钟拖车到店的免费道路救援经历。把顺序摆在车主面前就四步：先弃车撤离并远离车辆；再按情形打对号码，火情119、伤员120、事故上报122或110，说清位置和"起火""被困"两个关键词；第三步用车端SOS或问界救援渠道让车企数据与警方信息互相印证；最后保护现场，等待交警勘查定责。小红书
这起事故已进入正式调查程序，122那一通电话与到场处置衔接得如何，有待官方结论。但热搜暴露出的结构性事实适用于所有智能电动车：eCALL加车企救援中心解决的是"交警更快知道车在哪里"，而让消防车和救护车知道"人在哪里"，靠的仍是车主或路人自己那一通电话。两条链路都跑顺了，才叫高效联动。
