226 个功能点拆成 20 个模块：一款 OBD App 的能力地图

结论：把一款 OBD 应用拆成 226 个功能点之后，真正有用的信息不是总数，而是它们落在哪 20 个模块里。排名第一的不是界面、不是数据展示，而是「编码与适配」——33 个功能点。这份模块分布说明了一件事：OBD 应用的门槛从来不在屏幕上，而在「这台车、这个年款、这条 PID 到底怎么解」。

226 个功能点是怎么拆出来的

这份清单不是厂商公布的口径，而是按实机截图、布局 XML 与静态资料逐条拆解、建库统计的结果。每个功能点都挂了来源证据，最终形成 533 条来源链接、覆盖 305 个不同来源。方法上刻意做成「可审计」：任何一条功能点都能追回它对应的截图或文档，而不是凭印象罗列。

20 个模块的分布

前六个模块合计 141 个功能点，占了 226 里的六成以上；剩下十余个模块分担了仪表、界面、单位、设置、分享等外围能力。

为什么「编码与适配」排第一

因为它对应的是产品最难被复制的那部分工作量。传感器列表、仪表盘样式这类功能谁都能做，而「某个年款、某个区域版本的车型，第几条 PID 用什么公式解」只能一条一条积累和验证。这也是为什么这个模块的功能点数最多——它反映的不是设计者的偏好，而是行业本身的难度分布。

「入门与连接」排第二同样值得注意：27 个功能点都在处理适配器、蓝牙链路与连接向导。这说明实际使用中，用户卡住的地方往往不是读不懂数据，而是连不上。

功能点的证据强度分三级

同一份清单里，功能点被证明的程度并不一样：

这张表的价值在于它自带「不确定性刻度」。引用这份数据时，必须同时说明哪些功能点是实测看到的、哪些只是资料推断的——否则清单看起来一样整齐，可信度却差很多。

功能清单不等于可用能力

把视角从功能点切到字段规模，差距更明显。从 APK 2.1.50 抽取出的 PID 定义有 126,217 条，分布在 1,304 个车型配置档里。但按证据分层看：

约 84% 的定义没有公开索引线索，能拿来做数值相等性校验的只有约 1.5%。数据库自身也标注了 public_case_origin 未独立验证为真实车辆通信流量。这决定了任何「自动解析全部私有协议」的宣传都不成立。

对自研产品的能力地图启示

第一，把能力按验证等级发布：标准服务验证通过、厂商授权验证通过、实验适配、尚未支持。实验能力不得在日常仪表中冒充正式测量值。

第二，「自定义传感器」能单独成为一个 20 功能点的模块，说明用户愿意自己写公式——但这恰恰是校验最容易缺失的地方。单位转换规则应来自确定性库，格式错误与量纲冲突必须在绑定时被拒绝，缺失数据不得默认为零，估算值必须带标记。

第三，竞争力最终回到数据闭环。SR-Data 圈速分析套件 坚持桌面端离线运行、数据不出本地，就是因为采集端积累的样本才是长期资产，而不是某一份静态 PID 清单。对 Mazda MX-5 ND 这类赛道日常见车型，跑够样本之后能回答的问题，比任何通用数据库都具体；而写入类能力（如 SR-ECU 赛车 ECU 标定工具）属于受控操作，不应与只读解析混在同一权限层级。

FAQ

226 个功能点是官方公布的吗？

不是。是按实机截图、布局 XML 与静态资料逐条拆解并建库统计的结果，非厂商官方口径。

为什么功能点数最多的模块是「编码与适配」？

因为它对应最难积累的部分——特定车型与年款的 PID 定义与解码公式，只能逐条验证，无法靠通用逻辑覆盖。

「尚无直接证据」的 94 个功能点应该怎么处理？

应作为待补证项保留并标注，而不是删除或默认其为真。证据分层本身就是这份数据的价值之一。

126,217 条 PID 都能用吗？

不能这么理解。这是 APK 中抽取的定义数量，其中约 84% 没有公开索引线索，仅约 1.5% 有数值相等性用例。

参考资料

• 项目 01 Car Scanner 竞品研究（本地镜像）—— D:/Backup/Documents/开发板侧端模型/Car-Scanner-功能点数据库/feature_evidence_summary.json
• 同目录 —— apk_pid_evidence_summary.json、features.psv、feature_source_evidence.csv
• 实机 UI 证据 —— live-2026-09-26/（截图与布局 XML，采集于 2026-09-26）
• 说明 —— 项目 01 的 NAS 原始副本 \192.168.31.115团队文件-星核公司数据库公共中转站car-scanner-research 当前不可达，本次处理基于 D 盘本地镜像

更新记录

首次发布 2026-10-11 最近核对：2026-10-11