技术巡猎 零跑 车辆故障可视化引导方法、系统、设备及存储介质。过去车子出故障，用户看到的通常是一个灯、一个弹窗，或者一串让人头大的故障码。比如发动机故障灯亮了，普通人第一反应大概不是“我知道混合气过稀该检查哪里”，而是“这车是不是要坏了”。这就是传统故障提醒的问题：它把结果告诉你了，但没有告诉你下一步该怎么做。

这份专利想做的，就是把车上的故障提示从“报警”变成“引导”。

流程其实不复杂。车上的传感器、OBD、IMU、摄像头、温湿度传感器这些东西，会持续看车辆状态。发动机参数、车身姿态、环境条件，只要某些数据超出系统设定的故障判断条件，车就会先生成一个故障标识，也就是我们常说的故障码。

但关键不在故障码本身。

故障码对工程师有用，对普通用户没那么友好。所以系统接下来会做一次“翻译”：它会根据故障码，到预设的故障标识与操作指引映射关系里找对应规则。简单说，就是这类故障通常意味着什么、可能要检查哪里、应该提醒用户做什么。然后再结合用户类别，比如新手驾驶员、老手驾驶员，把这段说明改写成不同风格的提示词。

同一个故障，对不同用户不应该讲同一套话。

一个老司机看到胎压异常，可能只需要知道是哪条轮胎、当前压力多少、还能不能低速开到服务区。一个新手用户看到同样的提示，系统就应该讲得更明确一点：先不要急刹，找安全位置停车，打开双闪，再检查轮胎状态。表达方式变了，信息颗粒度也变了。

专利里还进一步把这个提示词交给视频生成模型。模型包括编码器、适配器和扩散模型。普通人可以把它理解成三步。

第一步，系统先读懂这句话。比如“使用10mm套筒逆时针拧松节气门固定螺丝”，它要识别出动作是“拧松”，工具是“10mm套筒”，对象是“节气门螺丝”。

第二步，系统决定视频风格。新手可能用卡通动画，老手可能用写实风格。这里专利提到了适配器和风格权重，实际意思就是不用为每种风格重新训练一个大模型，而是加载不同的风格参数，让视频呈现方式发生变化。

第三步，扩散模型把这些信息生成连续视频。为了让动作不是一帧一帧硬拼起来，专利里还写了时序注意力层和时序卷积层。这个东西说白了，就是让模型知道“动作有前后关系”。手伸过去、工具对准螺丝、逆时针旋转、螺丝松开，这几步要连得上。否则视频看着热闹，实际没法指导人。

专利举了一个 P0171 的例子，也就是燃油混合气过稀。系统检测到燃油空气比异常后，可以把故障码转换成“检查进气系统是否漏气，建议清洁节气门”这样的提示。如果外部温度比较高，还会提醒避免高温时段操作；如果用户是新手，就生成一段卡通风格的视频，展示如何用手电检查进气管、如何使用套筒拆节气门、如何喷清洗剂。

这就比一个冷冰冰的故障码友好多了。

但这里一定要讲边界。车辆故障引导这件事，不能让AI自由发挥。汽车不是做菜教程，错一步最多难吃；车上很多系统一旦误导用户，后果可能很严重。尤其是制动、转向、高压电池、气囊、热管理这些部分，系统可以解释，可以引导用户安全停车，可以建议联系救援，但绝不能随便教普通用户自己拆。

所以这项技术核心是前面的规则库要足够严谨。哪些故障可以自助检查，哪些只能做安全提醒，哪些必须锁定为服务救援流程，这些边界要先被工程体系定死。AI负责表达，规则负责安全。

我觉得它比较适合几类场景。

第一类是低风险、高频的小故障，比如胎压、玻璃水、灯光、雨刮、空调滤芯、充电口异物、部分车门闭锁异常。这些问题不一定需要马上进店，但用户很容易紧张。如果车机能用视频把操作讲清楚，售后电话会少很多，用户体验也会好不少。

第二类是中风险但需要解释的故障，比如动力受限、辅助驾驶退出、传感器遮挡、摄像头脏污。过去用户可能会觉得车突然“降智”了，其实很多时候是传感器条件不满足。视频化引导可以告诉你：不是系统坏了，而是摄像头被雨水、泥点、逆光或者结霜影响了。用户知道原因，焦虑会小很多。

第三类是高风险故障的安全流程，比如高压系统异常、电池温度异常、制动系统报警。这里视频不该教维修，而是教用户怎么撤离、怎么停车、怎么联系救援、哪些地方不要碰。越是高风险场景，越要把“不要做什么”讲清楚。

从产品体验上看，车越来越复杂了，但用户理解车的能力没有同步增长。

智能座舱、智驾、三电、热管理、域控、传感器，系统越来越多，故障提示也越来越难被普通人理解。以前机械车时代，很多问题能靠听声音、闻味道、看抖动判断。现在的车用户能看到的往往只剩一行提示。于是车企要解决的，不只是“让车更智能”，还包括“让用户理解智能系统发生了什么”。

能把问题讲清楚，本身就是一种系统能力。