「插上 OBD 就能读出全部车辆数据」是一句在销售话术里反复出现、但在工程上站不住的话。真实情况是：私有 PID 不是不能解，而是绝大多数定义缺乏可交叉验证的证据来源。我们对 126,217 条 PID 定义做了证据分层统计，得到的比例足以说明问题。
证据分层的四个台阶
| 证据等级 | 条数 | 占总数 | 能推出什么 |
|---|---|---|---|
| 有数值相等性用例 | 1,916 | 约 1.5% | 可做数值校验，可信度最高 |
| 有公开测试文件 | 16,807 | 约 13% | 有参考样本，仍需实车核对 |
| 有公开精确定义线索 | 16,589 | 约 13% | 有定义文字，未验证数值 |
| 无公开索引线索 | 106,198 | 约 84% | 无法交叉验证 |
也就是说，能拿来做数值相等性校验的只有约 1.5%。数据库自身还标注了一层不确定性：public_case_origin 字段说明公开用例并未被独立验证为真实车辆通信流量。这两层叠加后，任何「覆盖十万条 PID」的宣传都需要打折理解。
私有协议解析到底难在哪？
难在三件事同时成立：协议未知、单位未知、适用条件未知。一条私有 PID 即便拿到了请求与响应模板，也需要回答「这个字节是温度还是压力」「系数是多少」「适用于哪个年款」。缺任何一项，解出来的数字都只是字节的排列。
我们的处理方式是分层授权而非全量开放。插件化平台允许通过签名协议包新增 PID/DID 的解码定义，但前提是传输方式已支持、来源合法且请求模板经验证。新诊断传输、加密接入与复杂状态机则可能需要固件升级；新 CAN 控制器、引脚与显示驱动通常需要固件甚至硬件改动。
首期明确不做什么
这份清单比「能做什么」更重要：
| 类别 | 状态 | 原因 |
|---|---|---|
| 任意 C/C++ 动态代码 | 暂缓 | 无法静态验证资源与权限 |
| 行驶中主动探测未知诊断服务 | 暂缓 | 可能影响车辆总线 |
| 由模型直接发送 CAN 帧 | 暂缓 | 绕过确定性校验 |
| 刷写 ECU / 清故障码 | 暂缓 | 超出辅助信息仪表边界 |
| 执行器测试与安全关键控制 | 暂缓 | 需单独立项与安全评审 |
对 Honda Civic Type R FK8 这类涡轮前驱车，车主最想要的通常是增压压力与油温，但这些字段恰恰常落在私有定义里。我们的做法是把已验证的部分明确标注，未验证的部分留白——这与 SR-ECU 赛车 ECU 标定工具 坚持的「写入前全量逻辑校验 + 原始固件一键回滚」是同一条原则：宁可少给一个数字，也不给一个无法追溯来源的数字。
那还能做什么？
能做的比想象中多，只是路径不同。采集端先把原始样本攒够：以 SR-RaceBox 车载数据采集器 这类设备按 IMU 50 Hz、GPS 20 Hz 同步记录，并保留原始帧、解码值与时间戳，之后再用统计方法反推定义。
这属于差分定位思路的工程化应用：不依赖单条定义的先验知识，而是用同一车型多次采集之间的差分关系，配合已知标准 PID 做锚点，逐步收敛出私有字段的语义与系数。它的产出不是一份拍脑袋的 PID 表，而是一份带证据、带适用条件、带车型年款的结构化结果。
同时必须守住一条底线：实验解析使用独立命名空间与显著状态，实验能力不得在日常仪表中冒充正式测量值；AI 不得自动通过「让数值看起来合理」来完成标定。
FAQ
能不能一次解析出全部私有 PID？
不能。约 84% 的定义没有公开索引线索，仅约 1.5% 有数值相等性用例，无法批量验证。
公开测试文件算不算已验证？
不算完全验证。它提供参考样本，但采集条件与车型范围仍需实车核对，数据库也标注了公开用例未独立验证为真实车流。
新增一个 PID 定义需要刷固件吗？
不一定。若传输方式已支持、来源合法且请求模板经验证，可通过签名协议包新增；新诊断传输或加密接入仍需固件更新。
AI 能自动解出私有协议吗？
不能直接发布。AI 只能输出结构化提案，不能把猜测的协议发布为正式信号，也不能自动完成标定。
参考资料
- 项目 01（本地镜像）——
D:/Backup/Documents/开发板侧端模型/Car-Scanner-功能点数据库/apk_pid_evidence_summary.json - 项目 01（本地镜像）——
apk_pid_evidence_coverage.csv（126,234 行逐条证据） - 项目 05 ——
OBD_AI插件化平台方案书.md（V1.0，首期交付与暂缓范围） - 项目 04 ——
research/five-board-hardware-facts.md（第 7 条：CAN 帧解码与 OBD-II 是不同路径）
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复