#技术巡猎# #小鹏汽车# “车辆终端的交互处理方法、装置和电子设备”。主旨比较明确，“用户吐槽”在这里，可以直接变成“可定位、可分发、可闭环”的缺陷数据。这件事其实就有点像医院急诊的分诊台了，问问症状，看看你的体征，然后最后该挂哪个科、谁来处理，系统在这里做个初判。

它的输入主要有两路，一条是用户在车机交互组件里说出来的“问题描述数据”，另一条是车辆同步组件实时抓到的“多维运行数据”。多维数据怎么来呢？软件配置信息（典型就是OTA版本特征）、运行状态（静止/行驶/充电/上下电）、交互记录（大屏日志）、以及总线通信信号（CAN状态变化）。

实操的时候，单靠一句“音乐播不了”很难判断是网络、是版权、还是你点错了，或者是升级把兼容性搞崩了；把这些上下文一起带上，才有可能讲清楚“问题”到底是啥。

专利里提到了一个规则引擎，它是一个“适配器+调度器+多个执行单元”的并行结构，单机脚本那套思路在这里不够用：适配器把自然语言做语义拆解，映射到预定义诊断维度，形成结构化特征向量；调度器把请求拆成调度任务集合；多个执行单元并行跑规则匹配。

专利里甚至写了每个并行执行单元可以维护20条规则，靠多节点把规则命中做成毫秒级。规则还分三类：静态匹配规则、多维联合条件规则、历史行为时序规则；然后聚合命中结果，给不同类型规则分权重（举例0.4/0.3/0.3），最后算一个总置信度；置信度高于阈值（例子里是0.7）就给主标签，低一点就当次标签。

也给了一个很“医生”的例子：如果OTA版本+某个CAN地址状态一起命中，就把候选先指向OTA模块异常。
这个环节的意义很简单：先把候选池缩小，否则后面再上机器学习、图模型、GNN，算力也只会用来“认真地胡说八道”。

再往后是更像“算法层”的部分：基于软件配置、状态、日志、CAN这些维度，构建多维异常评分模型，对不同匹配类型打异常置信度分；根据评分对匹配结果做置信度调整；最后用目标归因算法做归因判定。专利给了一些输出字段：问题类型、可能故障模块、概率/评分、建议措施，还包括故障代码、归因逻辑说明、以及后续建工单需要的字段（业务线、来源、关联版本、发现阶段等）。

甚至强调了前置过滤、二次校验、降权规则、补充规则这些“防误判护栏”---很明显是怕系统一上来就把工单打爆，最后工程团队只会选择关掉它。

真正改变用户感知的，是它可以把结果“当场说出来”。
专利举了一个例子：用户反馈娱乐系统播放异常，系统把原因归到最近一次OTA兼容性问题，于是几秒内在大屏弹窗解释并给建议（比如先重启试试），同时后台自动创建缺陷工单、做属性分类、分发到处理终端；车机和手机APP还能同步状态，显示“已创建/处理中/修复测试中/已解决”，用户也能补充信息。

它最聪明的点反而是“主标签/次标签”这种表达方式---系统敢给结论，但也承认不确定性，把话说死的风险交给置信度去管理，用户体验会稳定很多。

这其实是一套非常考验体系的存在。
你得有稳定的日志口径、版本标识、CAN信号字典、缺陷字段治理；你得持续维护规则库和故障知识库，不然新版本一上线，命中率就像抽盲盒一样；你还得把合规做扎实---专利在末尾专门写了用户授权、提供入口可授权或拒绝、遵守各国家地区法律标准---这已经考虑到“很市场”的情况了。

再现实一点：它也要求你把车端、云端、缺陷系统全部打通，工单状态能返回到车里让用户看到，“人盯人”的客服模式，在这里可以推向“系统盯系统”的质量运维模式。