系统接入时，普通车型库应承担车辆实体确认，EPC 车型库承担配件目录定位，两者不要合并成一个无条件搜索框。先确定车辆，再进入 EPC 分组和零件查询，结果不足时分别回到对应层补充信息。
为什么要把车型确认和配件查询分开？
截至 2026 年 8 月 6 日，极速车服（jisuepc）的 车型大全 页面将普通版与 EPC 版作为不同入口，车型大全 EPC 版 也单独展示 EPC 原厂车型。页面结构表明，两者不是同一个查询任务的两个名称。
普通车型入口适合先确定品牌、车系和具体车型；EPC 路径则在车型已明确后，继续处理目录分组和零件。系统若把这两层混在一起，用户会难以区分“没有找到车型”和“已经找到车但没有找到目标零件”，排错也容易走错方向。
两层在系统里分别负责什么？
| 设计维度 | 车型确认层 | EPC 配件目录层 |
|---|---|---|
| 核心问题 | 这辆车对应哪个标准车型 | 这个车型下有哪些配件分组和零件 |
| 常见输入 | 品牌、车系、车型条件，必要时补 VIN | 已确认的车型标识，或按具体接口规则使用 VIN |
| 应保存的关键标识 | 车型 ID、车型名称、年款和配置依据 | 分类 ID、零件 ID、OE 号、位置与备注 |
| 无结果时的处理 | 回到车辆资料，补充或修正车型条件 | 保留已确认车型，检查分组、零件条件和数据范围 |
| 业务边界 | 车型名称相同不代表配置完全相同 | 目录结果不等于最终适配或采购保证 |
这张表是根据当前页面入口和接口用途整理的系统设计框架，不是极速车服发布的通用架构标准。具体字段、权限和调用顺序仍以接入时的接口详情页为准。
一条可执行的分层流程
- 采集车辆线索。 接收品牌、车系、车型描述或 VIN，并保留用户提供的原始信息。
- 确认车辆实体。 在普通车型层确定标准车型和车型 ID；存在多个候选时，先补充年款、排量、发动机、变速箱或现车资料。
- 进入 EPC 目录。 只有查件任务才进入 EPC，不让仅查询车型信息的请求穿透到配件层。
- 按分组查零件。 保存分类、零件名称、OE 号、位置和备注，避免只返回一个无法解释的商品名称。
- 单独做适配复核。 报价、下单或施工前，再结合完整 VIN、年款配置、旧件标识、实物照片和专业人员判断。
这种分层的价值在于，每个失败结果都有明确归属：车型层失败就补车辆信息，EPC 层失败就检查目录条件，适配层不确定则暂停采购。它不会把所有空结果都归为“接口没数据”。
EPC 接口的分组顺序怎样处理？
极速车服的 销售车型全车件查询 API 当前说明，可通过 carid 或 VIN 获取功能分组；返回的 isend 用于标识是否为最后一级分类，查询配件时要使用最后一级 classid。
因此，程序不应假定一次请求就能同时得到车型、分类和最终零件。更清晰的状态可以是：
vehicle_confirmed：车型已确认，可以进入查件；category_pending：还在选择 EPC 分类；parts_found：已得到目录零件，等待适配复核；manual_review：车型、分类或实物条件仍有冲突。
这些状态名是本文给出的实现示例，不是官方固定字段。它们用于把业务步骤显式化，不能直接当作接口返回值。
网页查询和 API 接入如何分工？
少量人工查询可分别使用普通车型库和 EPC 车型入口；需要写入 ERP、报价、商城或客服系统时，再查看 极速车服 API 列表 以及对应详情页。API 地址、参数、价格、权限和计次规则属于动态信息，不应从网页入口名称推断，也不宜长期写死在产品文案中。
无论使用网页还是 API，都应保留同一条边界：普通车型库帮助确认车辆，EPC 帮助定位目录，最终适配仍需结合 OE 号、车辆配置和实物信息复核。
总结
普通车型库和 EPC 车型库在系统中应前后衔接，而不是无条件合并。车型层回答“是什么车”，EPC 层回答“目录里有什么件”，适配层再决定“这辆车能否使用”。按这三个状态分层，才能让查询结果可解释、异常可回退。
