领克Z20车主通过高调的24小时OTA修复，获知自己的车辆已经“安全了”。然而，当极氪车主试着对车机说“关闭所有灯光”时，发现同样的事情正在发生——车灯熄灭，系统沉默。区别在于，这次没有微博致歉，没有公开声明，只有系统版本悄然变化。
社交媒体上，深蓝S05车主发布了实测视频：“跟车机说‘你好深蓝，关闭所有灯光’，车机非常‘听话’且‘迅速’地执行了指令——把车辆行驶必须的外部大灯，直接给关了！”
漏洞并非个例。这场始于领克的“失明事件”，正在吉利旗下多个品牌间蔓延。但各品牌的应对方式却呈现出截然不同的面貌：一方高调道歉、公开修复，另一方则选择“静默更新”。问题来了：当修复变成常态，车企是在保障安全，还是在悄悄回避责任？
领克的事故细节足够清晰：夜间高速，语音指令“关闭所有阅读灯”被系统误识别为“关闭所有灯光”，大灯熄灭。车主试图唤醒系统打开灯光，车机回复：“暂时还不会哟。”车辆最终撞上护栏。
领克销售副总经理穆军的公开致歉来得迅速：事故发生次日，优化方案通过OTA推送，行驶状态下大灯只能通过手动控制关闭，语音权限被彻底禁用。
但极氪车主很快发现，同样的漏洞存在于自己的车上。有车主测试后反馈：“测试了下D档行车状态下，喊关闭大灯是关不掉的，但是语音喊关闭所有灯光，就会连大灯一起关了。”这一逻辑缺陷与领克Z20如出一辙——都是特定指令触发安全风险，而系统又缺乏对应的安全校验。
深蓝车主的反馈更加直接。有深蓝S07车主发布视频显示，在自动大灯模式下语音控制关闭大灯时，系统会提示“照明灯控制功能暂不支持使用语音操作”。但手动切换至近光灯后，语音发送“关闭近光灯”指令，车辆近光灯却能关闭。另有网友指出，即便在自动大灯模式下，语音发送“关闭自动大灯”指令，车辆同样能够关灯。
多个品牌、相似漏洞，指向的可能是一个更深层的技术共性问题。
领克选择了最透明的路径：公开致歉、明确问题、推送更新、告知用户。这种处理方式在汽车行业确实罕见，某种程度上树立了危机处理的标准。
但极氪的路径完全不同。根据车主反馈，极氪车型的语音控制逻辑存在问题，但官方并未对此发布公开声明。当有媒体致电极氪客服时，客服表示：“正常所有车型，它都不支持行驶当中通过语音助手关闭灯光。除非是挂在P档，那么通过‘关闭车外灯光’或‘关闭大灯’等明确指令，可以关闭车外灯光。如果说行驶中关闭的话，就有危险了。”
这一回应耐人寻味。一方面，客服明确表示行驶中不支持语音关闭灯光；另一方面，车主实测却发现特定指令能够触发关灯。有车主发现，自己的车辆在更新后，相关功能悄然变化——但更新日志里没有提到这一修复。
深蓝的回应则更为模糊。深蓝客服表示：“暂时没有相关信息披露。”另一则客服回应则是：“具体以实际操作为准。”这种回避式的官方口径，与车主实测结果形成鲜明对比。
对比之下，小鹏的回应虽然谨慎，但至少提供了明确的安全逻辑。小鹏客服表示：“我们为了避免在车外光线昏暗的时候，误触到小P关闭灯光引起驾驶安全问题，目前在车外光线环境较暗的时候，关闭近光灯需要手动在大屏上进行操作。”小鹏方面进一步说明：“如果您有给它下达了指令的话，它还是会有触发条件的，可能会直接关闭大灯。在行车过程中，会影响安全驾驶。”
吉利集团的G-ASD平台化战略，为这种跨品牌漏洞提供了技术解释。G-ASD被明确定义为千里浩瀚所有产品统一的软件版本品牌和迭代基线，它与代表物理传感器和计算芯片配置的H1至H9硬件方案相对独立又协同工作。
这种“软硬件解耦”与“平台化服务”架构，意味着智能驾驶能力的提升不再必然依赖于更换实体车辆，只要车辆的硬件传感器和计算平台符合某一套千里浩瀚硬件方案的标准，其软件灵魂就能通过持续的OTA进行重大版本迭代和功能更新。
平台化的优势显而易见：降低成本、提升效率、实现技术共享。但当漏洞出现时，这种共享也可能变成“共担风险”。
从技术层面推测，领克、极氪可能使用了相似的语音控制模块或逻辑框架。当领克公开修复漏洞后，极氪很可能通过静默更新的方式，对相同问题进行了修复。这种“内部协调”提高了效率，但也模糊了各品牌的独立责任边界。
争议焦点就此形成。
支持静默更新的一方认为，这种做法避免了不必要的恐慌。对于技术性漏洞，快速修复比公开讨论更重要。用户最终得到的是安全的车辆，过程透明与否并非核心问题。特别是当修复涉及安全风险时，静默推送能够确保所有用户尽快获得保护。
但反对方的声音同样强烈。他们质疑：如果修复可能引发新问题呢？如果更新影响了其他功能呢？车主有权知道自己的车辆发生了什么变化。更重要的是，静默更新可能成为车企规避责任的一种方式——当问题没有公开讨论时，就不必公开承认设计缺陷，也不必面对潜在的法律责任。
这起事件暴露出一个更广泛的行业问题：汽车OTA更新的透明度与监管标准何在？
事实上，监管部门对此已有动作。2021年，工信部发布了《关于加强智能网联汽车生产企业及产品准入管理的意见》，明确指出了汽车生产企业在软件升级方面的管理能力要求，并强调了OTA升级活动的备案必要性。国家市场监督管理总局也发出通知，要求所有需要进行OTA升级的企业必须向市场监管总局质量发展局进行备案。
2025年，市场监管总局联合工业和信息化部发布的《关于加强智能网联新能源汽车产品召回、生产一致性监督管理与规范宣传的通知（征求意见稿）》中，明确要求企业严格执行OTA升级分类管理，未经备案不得开展升级，不得推送未充分测试的软件版本，不得通过OTA隐瞒缺陷。
这些规定在理论上建立了OTA的监管框架。但在实践中，备案制度主要面向监管机构，而非普通用户。车主很难知道自己车辆的哪些更新属于“修复漏洞”，哪些属于“功能优化”。
对比其他行业，特斯拉的案例值得参考。特斯拉曾因FSD（完全自动驾驶）推送未完成备案审批而被叫停，用户端显示“服务暂不可用”。特斯拉随后回应称正在积极推进硬件3.0与4.0的注册与审批工作，待合规完成后将恢复推送。这种因为监管而暂停更新的情况，在中国本土车企中也出现过。小鹏原定某月的MONA M03 OTA更新被迫延期，问界的OTA计划也因备案未完成推迟上线。
这表明监管正在收紧。但监管的重点主要集中在“是否备案”、“是否符合规范”上，对于“如何告知用户”、“告知到什么程度”，仍然缺乏明确标准。
静默更新本质上是一种效率优先的选择。在智能汽车时代，车辆系统复杂度呈指数级增长，漏洞难以完全避免。当发现安全风险时，最有效的处理方式是立即修复，减少潜在危害。从这个角度看，静默更新有其合理性。
但这种合理性建立在两个前提上：一是修复本身绝对安全，不会引发新问题；二是用户对“被管理”持默许态度。
第一个前提在技术上难以保证。任何软件更新都可能带来新bug，特别是当更新涉及核心安全功能时，风险更高。如果更新失败，如果更新与其他软件冲突，如果更新影响了用户习惯的功能——这些都需要用户知晓，以便及时反馈和应对。
第二个前提则涉及到用户权利的本质变化。传统汽车时代，用户对自己的车辆有完全的物理控制权。每个改动都需要物理操作，每个维修都需要用户知情同意。智能汽车时代，车辆变成了“可远程更新的设备”，车企获得了前所未有的控制权。
这种控制权的转移，需要相应的透明度来平衡。当车企可以静默修改车辆功能时，用户需要知道：修改了什么，为什么修改，可能带来什么影响。
更深层的问题是：静默更新是否会成为车企的惯性选择？当企业发现，不公开讨论问题也能解决问题时，是否会更倾向于“悄悄修复”？这种模式在短期内可能提高效率，但长期来看，会削弱用户信任，积累系统性风险。
那么，是否存在一个合理的平衡点？车企应该在何时、以何种方式告知用户？
从安全角度看，涉及核心驾驶安全的功能修复，应该公开告知。比如涉及刹车、转向、灯光等关键系统的漏洞修复，用户有权知道风险曾经存在，以及如何避免类似问题。这不仅是对用户的尊重，也是安全教育的一部分。
从功能角度看，影响用户体验的重大更新，应该提前预告。比如界面大改、功能增删、性能调整等，让用户有心理准备，减少不适感。
从技术角度看，纯粹的bug修复、性能优化，可以在更新日志中简要说明，不必过度渲染。但“简要说明”不等于“不说明”，更不等于“误导说明”。
行业或许需要建立一个分级披露标准：根据更新的风险等级、影响范围、必要性，确定不同的透明度要求。高风险更新强制公开披露，中风险更新建议告知，低风险更新可以在更新日志中说明。
更重要的是，车企需要建立用户沟通的文化。当出现问题时不回避，当修复漏洞时不遮掩。透明可能带来短期的舆论压力，但会赢得长期的用户信任。
对于车主而言，面对静默更新，并非完全被动。一些技术导向的车主已经开始主动追踪车辆状态：定期查看系统版本，关注更新日志，甚至在车友群中交流发现的变化。这种“民间监督”虽然零散，但正在形成一股力量。
更有车主建议，车企应该提供更详细的更新历史查询功能，让用户可以追溯每一次更新的具体内容，而不仅仅是“优化系统性能”这样的模糊描述。
但这终究是治标不治本。真正的解决方案，需要车企、监管、用户三方共同努力：车企建立更透明的更新机制，监管制定更明确的标准，用户提高对车辆变化的关注度。
智能汽车时代，车辆正在从“所有物”转变为“服务”。这种转变带来的不仅是便利，还有权力关系的重构。当车企获得远程控制权时，用户需要相应的知情权作为制衡。静默更新或许高效，但透明沟通才是长久之计。
毕竟，在漆黑的高速夜晚，车主需要的不仅是能重新点亮的大灯，还有知道“为什么会熄灭”的权利。
全部评论 （0）