docs: align platform goal with 0716 meeting
This commit is contained in:
@@ -1,125 +1,362 @@
|
||||
# 车辆数据中台会议待办与 Goal 清单
|
||||
# 车辆数据中台 0716 会议待办与 Goal 清单
|
||||
|
||||
更新时间:2026-07-16
|
||||
|
||||
## 1. 来源与范围
|
||||
唯一会议依据:`张兰发起的视频会议_0716.txt`
|
||||
|
||||
本清单综合以下会议纪要和一期建设目标整理:
|
||||
当前项目:`vehicle-data-platform`
|
||||
|
||||
- `时生亮发起的视频会议.txt`
|
||||
- `张兰发起的视频会议_0715.txt`
|
||||
- 车辆数据中台一期建设目标
|
||||
## 1. 范围与执行原则
|
||||
|
||||
明确不纳入本 Goal:
|
||||
本清单以 2026-07-16 最新会议纪要为准,替代此前根据 0715 及更早纪要整理的版本。待办已经结合当前代码、数据库迁移和生产能力去重。
|
||||
|
||||
- 车辆锁车、控车和其他远程控制;
|
||||
- 修改 `ln-asset-management` 现有业务逻辑;
|
||||
- 伪造或反推无法取得的历史轨迹;
|
||||
- 本期直接建设原生 App、小程序、维修站预约等尚未定稿的外部端能力。
|
||||
不纳入本 Goal:
|
||||
|
||||
- 车辆锁车、控车及其他远程控制;
|
||||
- 直接修改 `ln-asset-management` 或 OneOS 现有业务逻辑;
|
||||
- 短信、邮件、企微等外部告警通道正式上线;
|
||||
- 原生 App 或小程序建设;
|
||||
- 伪造无法取得的历史轨迹或里程。
|
||||
|
||||
执行原则:
|
||||
|
||||
- 客户主路径以车辆和车牌为中心;VIN 作为辅助标识和内部关联键。
|
||||
- 客户默认查看推荐融合结果;内部运维可以展开全部来源证据。
|
||||
- OneOS 后续提供业务接口,车辆数据中台只调用,不直接改其代码或业务库。
|
||||
- 本轮先完成可交付页面和客户演示,再推进数据差异自查与专业运维能力。
|
||||
- 缺失、未知或协议不提供的字段显示 `-`,不得用 `0` 冒充真实数据。
|
||||
|
||||
状态定义:
|
||||
|
||||
- `已完成`:代码、部署和基础验证已完成,不再重复开发;
|
||||
- `待验收`:主要能力已完成,需要业务场景或指定客户验证;
|
||||
- `进行中`:已有部分能力,但尚未形成完整闭环;
|
||||
- `待开发`:尚未实现或尚未接入生产;
|
||||
- `后续规划`:会议提出的演进方向,不作为当前首批交付阻塞项。
|
||||
- `已完成`:代码、部署和基础验证均已完成。
|
||||
- `待验收`:主要能力已上线,仍需指定业务场景验收。
|
||||
- `进行中`:已有基础能力,但尚未达到会议验收口径。
|
||||
- `待开发`:当前尚无完整实现。
|
||||
- `暂缓`:会议明确不是本轮重点,不阻塞当前 Goal 首批交付。
|
||||
|
||||
## 2. 已完成基线
|
||||
## 2. 会议结论索引
|
||||
|
||||
以下能力已经完成,后续只做缺陷修复和验收,不重新立项:
|
||||
| 会议时间 | 明确结论 | 对应待办 |
|
||||
| --- | --- | --- |
|
||||
| 00:00–00:05 | 每个客户车辆授权需要启用/停用日期、历次开放记录、操作人员;后续补部门和负责人 | P0-01 |
|
||||
| 00:05–00:12 | 接入品牌和 JT808 数据仍需校准;告警配置复杂;需要把后台来源选举和配置做成专业运维页面 | P1-01、P1-02、D-01 |
|
||||
| 00:12–00:24 | 历史数据应支持配置全部可用字段、质量原因、导出;导出需绑定时间和账号/角色;客户页车牌优先 | P0-04、P0-05 |
|
||||
| 00:24–00:41 | 全局监控是首期核心;缺失 SOC 显示 `-`;只展示真实来源;无位置车辆也要进入列表;位置/里程可展开全部来源 | P0-02、P0-03 |
|
||||
| 00:40–00:41 | 全国视角可按省聚合并显示数量;移动端继续优化但分阶段推进 | P1-03、D-02 |
|
||||
| 00:41–00:48 | 全局监控是功能中枢;进入车辆、轨迹、历史后要统一返回原车辆上下文;单车页动态信息在静态档案之前 | P0-06、P0-07 |
|
||||
| 00:48–00:49 | OneOS 由其团队提供接口,数据中台调用;不直接修改 OneOS | P1-04 |
|
||||
| 00:49–00:53 | 高频数据差异必须建立自动自查和持续对账,不能长期依赖人工发现 | P1-05 |
|
||||
| 00:43–00:44 | 32960 历史已有较长周期;G7 已导入 6 月 1 日至 7 月 15 日,更早数据按需求补齐 | D-03 |
|
||||
| 00:24–00:25、00:52–00:53 | 先完成客户交付页面,向秦总、蒲总演示并开通账号 | P0-08 |
|
||||
|
||||
## 3. 当前已完成基线
|
||||
|
||||
以下能力不重复立项,只在对应待办中补齐会议要求:
|
||||
|
||||
| 编号 | 能力 | 当前结果 |
|
||||
| --- | --- | --- |
|
||||
| BASE-01 | 管理员/客户账号登录 | 已支持本地账号、管理员与客户角色、密码策略、失败锁定、会话撤销和审计 |
|
||||
| BASE-02 | 客户菜单权限 | 客户只能被分配全局监控、车辆查询、轨迹回放、里程查询 |
|
||||
| BASE-03 | 客户车辆权限 | 管理员可按车牌/VIN 搜索并分配车辆,服务端对车辆查询统一执行 VIN Scope |
|
||||
| BASE-04 | 全局监控地图/列表双模式 | Web 和移动端均支持地图与列表,车辆点聚合、平滑移动、筛选及详情已上线 |
|
||||
| BASE-05 | 手机访问入口 | 全局监控支持二维码和访问地址复制,二维码不携带 Token |
|
||||
| BASE-06 | 里程查询 | 支持多车、日期区间、每日里程矩阵、区间总里程、今天/昨天/近 7 天、分页和 Excel 导出 |
|
||||
| BASE-07 | 里程数据源策略 | 支持 GB32960、JT808、YUTONG_MQTT 启停和优先级配置;来源含义已说明 |
|
||||
| BASE-08 | 接入差异列表 | 已按主车辆展示应接协议、实际协议、缺失协议、在线状态和接入证据 |
|
||||
| BASE-09 | OneOS 只读车辆范围投影 | 已使用专用只读账号和事务事实同步,不修改 OneOS 业务逻辑 |
|
||||
| BASE-10 | 基础 UI 与移动端适配 | 主要页面已统一视觉体系,并完成常见桌面与移动端尺寸适配 |
|
||||
| BASE-01 | 管理员/客户登录与 RBAC | 已支持本地管理员、客户账号、菜单权限、车辆 VIN Scope、会话撤销和认证审计 |
|
||||
| BASE-02 | 客户四菜单 | 已支持全局监控、车辆查询、轨迹回放、里程查询的客户菜单配置 |
|
||||
| BASE-03 | 多源车辆归并 | GB32960、JT808、YUTONG_MQTT 已按 VIN/车牌归并;JT808 同协议多终端已有后台选举基础 |
|
||||
| BASE-04 | 全局监控 | 已有地图/列表、聚合、车牌、车辆搜索、选中车辆、平滑移动、地图详情和移动端适配 |
|
||||
| BASE-05 | 历史与轨迹 | 已有位置历史、RAW 解析字段、轨迹回放、质量诊断和导出任务框架 |
|
||||
| BASE-06 | 里程查询 | 已有多车、日期区间、每日里程、区间总里程、来源优先级、分页和 Excel 导出 |
|
||||
| BASE-07 | 运维证据基础 | 接入管理、来源覆盖、数据质量、来源一致性和告警基础能力已存在 |
|
||||
| BASE-08 | OneOS 只读投影 | 已有只读业务范围同步和接口契约分析,不修改 OneOS 业务逻辑 |
|
||||
|
||||
## 3. 当前执行待办
|
||||
## 4. P0:客户交付前必须完成
|
||||
|
||||
### P0:客户可安全交付
|
||||
### P0-01 客户车辆授权启停履历
|
||||
|
||||
| 编号 | 状态 | 待办 | 依赖/风险 | 完成验收标准 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| P0-01 | 待验收 | 完成首个真实客户账号的端到端验收 | 需要业务方提供验收客户、车辆清单和菜单清单 | 客户登录后只看到授权菜单;列表、地图、轨迹、里程中的车辆集合一致;客户 A 无法通过 VIN、车牌、URL 或分页访问客户 B 车辆 |
|
||||
| P0-02 | 待开发 | 补齐客户历史数据的授权时间边界 | 当前车辆授权主要按 VIN 限制;需要明确交付前、还车后历史是否可见 | 轨迹和里程查询同时满足 VIN 与授权有效期;交付前数据不可见;还车后的访问策略有明确产品口径和自动化越权测试 |
|
||||
| P0-03 | 待开发 | 建立约 20 天缺失里程的可审计补录流程 | 需要 GPS 厂家/原平台导出文件及字段说明;历史轨迹无法补录 | 定义导入模板;按 VIN+自然日+来源+批次幂等;输出成功、重复、冲突、缺 VIN、异常跳变报告;补录前后总量可对账 |
|
||||
| P0-04 | 进行中 | 固化客户车辆范围与 OneOS 业务范围的映射方式 | 目前支持管理员手工分车,OneOS 范围快照已存在,但账号与业务客户的自动绑定尚未形成完整流程 | 明确 `customerRef/tenantRef` 映射;可选择手工授权或跟随 OneOS 快照;范围变化有审计;失败时不退化为全量车辆 |
|
||||
| P0-05 | 待开发 | 完成外部身份接入方案并实现一个正式适配器 | 已预留 `IdentityAdapter`,但尚未取得 Yudao Cloud/RuoYi-Sys 的 issuer、JWKS 或 token introspection 契约 | 接入方 Token 必须签名验证或服务端内省;映射到本地用户后仍执行菜单和车辆权限;本地管理员与运维 Token 保留回滚通道 |
|
||||
| P0-06 | 待验收 | 与秦总/业务负责人完成客户门户验收并冻结首期范围 | 会议要求先出一版再确认;需避免持续扩散范围 | 对登录、授权车辆、实时位置、轨迹、里程、移动端逐项签字;形成问题清单和首期冻结结论 |
|
||||
状态:`进行中`
|
||||
|
||||
### P1:数据可信与运营闭环
|
||||
目标:
|
||||
|
||||
| 编号 | 状态 | 待办 | 依赖/风险 | 完成验收标准 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| P1-01 | 进行中 | 为“应接但未接”车辆增加人工处置闭环 | 当前能发现差异,但缺少“无需接入/待接入/异常/已确认”等业务结论 | 每辆差异车可设置处置状态、原因、负责人、备注和更新时间;支持筛选、导出和审计;无需接入车辆不再长期混入异常待办 |
|
||||
| P1-02 | 进行中 | 统一位置与里程的数据融合策略 | 里程已有可配置优先级;实时位置当前采用服务端固定优先级并有漂移保护 | 形成统一策略模型;管理员可查看全部来源及差异;客户只看到融合结果;来源切换、坐标冲突和里程跳变均保留证据 |
|
||||
| P1-03 | 进行中 | 完善全局监控列表的管理员溯源视图 | 客户只需关键融合结果;管理员需要查看各来源的客观状态 | 客户列表保持简洁;管理员可展开查看各协议最新时间、位置/里程来源、在线状态和差异原因;不在主列表堆叠无关字段 |
|
||||
| P1-04 | 进行中 | 完善接入管理的业务筛选维度 | 当前已有协议、厂家、车型、接入/上报时间和状态能力,客户/运营状态仍需统一验证 | 支持按客户、运营状态、厂家、车型、应接协议、实际协议、未接原因组合筛选;统计口径与列表总数一致 |
|
||||
| P1-05 | 待开发 | 建立正式外部访问域名和内部统一入口 | 需要 DNS、HTTPS 证书和 OneOS 菜单配置权限;不得修改 OneOS 业务逻辑 | 外部客户使用独立 HTTPS 子域名;内部从统一入口新标签页进入;无需记忆 ECS IP;登录回跳和退出行为一致 |
|
||||
| P1-06 | 待验收 | 完成真实客户移动端可用性验收 | 会议明确客户主要使用手机;需要真实设备和弱网场景 | 在主流手机上完成登录、地图/列表切换、车辆搜索、详情、轨迹、里程查询;关键操作不依赖横屏;无明显卡顿和误触 |
|
||||
- 一辆车可以在不同时间段授权给不同客户,也可以多次授权给同一客户。
|
||||
- 记录每次启用时间、停用时间、客户账号、操作人、操作时间。
|
||||
- 当前先支持管理员手工维护日期;后续 OneOS 接入后补部门、负责人、合同/项目等业务信息。
|
||||
- 所有历史查询同时校验车辆和授权时间,不允许看到授权开始前的数据。
|
||||
|
||||
### P2:统一车辆数字档案
|
||||
验收标准:
|
||||
|
||||
| 编号 | 状态 | 待办 | 完成验收标准 |
|
||||
1. 账号管理中可查看每台授权车辆的当前状态和历次启停记录。
|
||||
2. 保留未变更车辆原有启用时间,重新授权产生新的授权区间,不能覆盖旧历史。
|
||||
3. 轨迹、历史位置、RAW、里程和导出均按授权有效期裁剪。
|
||||
4. 客户 A 无法通过 VIN、车牌、URL、分页或导出访问客户 B 的车辆或历史。
|
||||
5. 变更审计包含操作人、目标账号、车辆、变更前后、时间和结果。
|
||||
|
||||
依赖/风险:
|
||||
|
||||
- 当前表已预留 `valid_from/valid_to`,但账号管理 UI、完整履历模型及所有历史入口的统一强制校验仍需补齐。
|
||||
- 自然日里程在授权首日可能混入授权前数据,首日需采用完整授权日或提供明确的部分日口径。
|
||||
|
||||
### P0-02 全局监控客户列表重构
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 客户列表以车牌为主、VIN 为辅,突出当前动态状态。
|
||||
- 默认列控制在:车牌、推荐来源、速度、总里程/当日里程、经纬度/位置、最后上报时间。
|
||||
- SOC、氢气余量、压力等仅在真实来源提供时展示;不可用显示 `-`。
|
||||
- 没有有效坐标的授权车辆仍出现在列表中,并可筛选“无实时位置”。
|
||||
- 地理位置采用按需解析或受控缓存,不按每条上报调用高德逆地理 API。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 无位置车辆不会从车辆总数或列表中消失。
|
||||
2. JT808 不提供 SOC 时页面显示 `-`,不会显示 `0%`。
|
||||
3. 页面只显示车辆真实存在的数据来源,不生成空来源或错误来源。
|
||||
4. 列表首屏紧凑,Web 和移动端均能快速看到足够车辆。
|
||||
5. 地址结果带更新时间,缓存命中时不重复消耗高德配额。
|
||||
|
||||
### P0-03 位置与里程的多来源展开
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 客户默认看到系统推荐来源和融合结果。
|
||||
- 点击车辆的当前位置、经纬度或里程,可展开该车所有真实来源。
|
||||
- 同一协议存在多个终端时,显示具体提供方/终端来源、最新时间和值。
|
||||
- 清楚标记当前推荐来源、备用来源、离线来源和差异值。
|
||||
- 后台已有选举继续作为默认策略,但不隐藏专业运维所需证据。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 多源车辆可以一次看到 GB32960、各 JT808 终端和 YUTONG 的实际值。
|
||||
2. 推荐来源与后台选举结果一致;来源切换不改变原始证据。
|
||||
3. 位置差异、里程差异、上报时间差有明确说明。
|
||||
4. 单来源车辆不展示无意义的空卡片。
|
||||
5. 展开操作按需请求,不在列表初始化时为每辆车加载全部明细。
|
||||
|
||||
### P0-04 历史数据可配置字段与质量原因
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 历史查询不固定为少量字段,允许从服务器字段目录选择可用字段。
|
||||
- 支持位置数据、RAW 解析字段和日里程的统一时间范围查询。
|
||||
- 质量列由平台规则计算,并增加“质量原因/可能原因”。
|
||||
- 客户界面去掉未实现或无意义的占位信息;车牌主显、VIN 辅显。
|
||||
- 日期使用一个起止时间范围组件,不拆成两个割裂输入框。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 可搜索并多选当前协议/车辆实际存在的字段。
|
||||
2. 表格、图表和导出使用同一字段选择及时间范围。
|
||||
3. 异常记录展示具体原因,如字段缺失、坐标异常、重复点、漂移、延迟或来源切换。
|
||||
4. 未实现的“证据”或空操作不出现在客户页面。
|
||||
5. 大字段查询有数量、时间窗和行数限制,页面不会因一次请求卡死。
|
||||
|
||||
### P0-05 导出任务账号归属与审计
|
||||
|
||||
状态:`待开发`
|
||||
|
||||
目标:
|
||||
|
||||
- 导出任务绑定创建账号、角色、客户、车辆 Scope、查询时间范围和创建时间。
|
||||
- 管理员可按权限查看任务;客户只能看到和下载自己的导出。
|
||||
- 文件名和任务名称包含业务可读时间及创建者信息。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 导出列表显示创建时间、创建人/账号、角色、车辆数、数据类型、时间范围和状态。
|
||||
2. 客户不能查看、猜测 ID 下载或复用其他客户的导出。
|
||||
3. 账号停用或车辆授权撤销后,未完成任务停止,历史文件下载重新校验权限。
|
||||
4. 服务重启后任务 owner 和 Scope 不丢失。
|
||||
5. CSV/Excel 元数据中记录查询条件和生成时间,不泄露其他客户信息。
|
||||
|
||||
### P0-06 从全局监控进入子功能后保留车辆上下文
|
||||
|
||||
状态:`待开发`
|
||||
|
||||
目标:
|
||||
|
||||
- 从全局监控进入车辆查询、轨迹回放、历史数据或里程查询时,保留车辆、地图中心、缩放级别、筛选条件和侧栏状态。
|
||||
- 子页面使用统一“返回全局监控”入口,返回后仍选中原车辆。
|
||||
- 避免以新页面或新标签破坏当前工作流。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 四个子功能都能返回原选中车辆。
|
||||
2. 返回后地图中心、Zoom、列表筛选和详情展开状态可恢复。
|
||||
3. 直接从菜单进入子功能时不显示误导性的返回上下文。
|
||||
4. 浏览器前进/后退行为与页面返回按钮一致。
|
||||
|
||||
### P0-07 单车详情信息优先级调整
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 最新上报、当前位置、速度、SOC、总里程、数据时间和来源放在页面上部。
|
||||
- 车辆基础档案、VIN、型号、公司等静态信息放在动态信息之后。
|
||||
- 轨迹、历史、里程入口围绕当前车辆统一排列。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 用户打开单车后无需滚动即可看到最新动态状态。
|
||||
2. 缺失动态字段显示 `-` 并说明来源不可用。
|
||||
3. 静态档案不会挤占动态状态首屏。
|
||||
4. Web 与移动端保持相同的信息层级。
|
||||
|
||||
### P0-08 客户账号与演示验收
|
||||
|
||||
状态:`待验收`
|
||||
|
||||
目标:
|
||||
|
||||
- 为秦总、蒲总相关验收场景准备客户账号、车辆清单和四个客户菜单。
|
||||
- 演示主线:全局监控选车 → 单车动态 → 轨迹 → 历史/字段 → 里程。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 使用非管理员客户账号完成全流程。
|
||||
2. 只看到授权车辆和授权菜单。
|
||||
3. 演示车辆包含单来源、多来源、无位置、离线四类样本。
|
||||
4. 记录现场问题、责任人、优先级和是否阻塞首期交付。
|
||||
5. 业务负责人确认首期可交付范围。
|
||||
|
||||
## 5. P1:客户演示后立即推进
|
||||
|
||||
### P1-01 专业运维多来源诊断页
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 新建或重构独立运维菜单,把后台来源选举、优先级、终端提供方、最新值和差异证据可视化。
|
||||
- 普通客户不进入该页面;管理员/运维可查单车所有协议和同协议多终端。
|
||||
- 可在前台完成初步问题定位,不要求开发人员查数据库或代码。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 按车牌模糊搜索后展示所有来源和终端。
|
||||
2. 展示来源提供方、终端标识、首次/最后上报、间隔、位置、里程、在线状态和选举得分/原因。
|
||||
3. 支持调整可配置优先级,但每次调整有版本、操作人和审计。
|
||||
4. 能解释“为什么当前推荐这个来源”。
|
||||
5. 页面按需加载并分页,不能一次拉取全量 RAW 数据。
|
||||
|
||||
### P1-02 接入管理数据校准
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 运维补齐 JT808 各品牌/提供方资料。
|
||||
- 修复“品牌未维护”、来源数量不准、车辆明明只有 JT808 却显示三来源等问题。
|
||||
- 接入数量以去重后的车辆身份和真实来源证据计算。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 同一车辆不因多终端重复计入车辆总数。
|
||||
2. 品牌、提供方、协议、终端和 VIN 关系可追溯。
|
||||
3. 接入管理、全局监控和车辆查询的车辆总数口径一致。
|
||||
4. 无法识别的终端进入待处理队列,不伪造 VIN 或品牌。
|
||||
|
||||
### P1-03 全国视角省级聚合
|
||||
|
||||
状态:`待开发`
|
||||
|
||||
目标:
|
||||
|
||||
- 地图缩放到全国视角时,可切换为按省聚合。
|
||||
- 每个省展示车辆数量,并可下钻到当前已有点位聚合。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 省级数量与当前授权范围、筛选条件一致。
|
||||
2. 下钻和平移不与定时刷新争抢地图控制权。
|
||||
3. 省级聚合采用矢量/DOM 或高清渲染,浏览器 150% 缩放仍清晰。
|
||||
4. 聚合计算不阻塞主线程。
|
||||
|
||||
### P1-04 OneOS 业务接口对接
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- OneOS 团队提供正式接口后,数据中台只读调用客户、部门、负责人、合同/项目、车辆启停范围等业务信息。
|
||||
- 不直接修改 `ln-asset-management`,不把草稿时间当作正式交还车事实。
|
||||
- 后续支持按客户、人员批次、部门或项目筛选。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 有明确接口契约、鉴权方式、超时、重试、版本和回滚方案。
|
||||
2. OneOS 不可用时失败关闭,不退化为全量车辆。
|
||||
3. 业务事实与遥测事实的权威边界清楚。
|
||||
4. 授权范围变化产生可审计版本。
|
||||
|
||||
### P1-05 数据差异自动自查与对账
|
||||
|
||||
状态:`进行中`
|
||||
|
||||
目标:
|
||||
|
||||
- 将目前由人员在群里频繁发现的数据差异变成平台自动发现。
|
||||
- 以多来源数据、接入事实和 OneOS 业务事实做差异检测;系统不擅自判定未知来源谁绝对正确。
|
||||
- 形成每日自查、差异队列、复核结论和趋势。
|
||||
|
||||
验收标准:
|
||||
|
||||
1. 自动检测车辆重复、来源缺失、来源误挂、位置漂移、里程跳变/倒退、总数不一致和业务范围不一致。
|
||||
2. 每条差异保留来源值、时间、规则、影响车辆和证据。
|
||||
3. 支持“待确认、已确认来源 A、已确认来源 B、无需处理、已修复”等结论。
|
||||
4. 相同问题去重,恢复后自动关闭或进入已恢复状态。
|
||||
5. 每日输出新增、存量、恢复和超 SLA 数量,避免长期依赖人工群消息。
|
||||
|
||||
## 6. 暂缓和非阻塞项
|
||||
|
||||
| 编号 | 状态 | 事项 | 会议结论 |
|
||||
| --- | --- | --- | --- |
|
||||
| P2-01 | 后续规划 | 建立“一车穿透到底”的统一车辆详情入口 | 从车辆搜索进入后,可按权限查看基础档案、实时数据、协议来源、告警、轨迹、里程及后续附件/维保/违章等模块 |
|
||||
| P2-02 | 后续规划 | 扩展角色与字段级展示能力 | 在管理员、内部业务、车队长、客户、司机等角色间控制模块、字段和账单可见性,不仅依赖菜单隐藏 |
|
||||
| P2-03 | 后续规划 | 对接 App/小程序统一能力 | Web、App、小程序复用同一身份、菜单和车辆 Scope;首期 Web 能力不被重复实现 |
|
||||
| D-01 | 暂缓 | 告警配置重做、短信/外部通知 | 当前离线/长时间未上报告警可继续内部使用,但“告警先不用弄”,不阻塞本轮客户交付 |
|
||||
| D-02 | 暂缓 | 大规模移动端交互重构 | 继续修复阻塞问题,但会议确认移动端优化较多,分阶段推进 |
|
||||
| D-03 | 暂缓 | 补齐 G7 2026-06-01 之前全部历史里程 | 能低成本取得则导入;否则等明确业务需求,不优先于当前页面和数据一致性 |
|
||||
| D-04 | 暂缓 | 基于客户/人员批次的告警规则 | 等 OneOS 业务维度正式接入后再设计 |
|
||||
|
||||
## 4. 建议执行批次
|
||||
## 7. 推荐执行顺序
|
||||
|
||||
### 批次 A:交付安全闭环
|
||||
### 批次 A:客户演示可用
|
||||
|
||||
1. P0-01 真实客户越权和功能验收;
|
||||
2. P0-02 历史授权时间边界;
|
||||
3. P0-04 OneOS 客户范围与平台账号映射;
|
||||
4. P0-06 业务验收与首期冻结。
|
||||
1. P0-02 全局监控列表修正;
|
||||
2. P0-03 多来源展开;
|
||||
3. P0-06 返回车辆上下文;
|
||||
4. P0-07 单车动态信息上移;
|
||||
5. P0-08 客户账号与演示验收。
|
||||
|
||||
### 批次 B:历史里程补录
|
||||
### 批次 B:客户数据安全
|
||||
|
||||
1. 获取并固化厂家导出样例;
|
||||
2. 定义导入模板、校验规则和幂等键;
|
||||
3. dry-run 生成差异报告;
|
||||
4. 经业务确认后正式导入;
|
||||
5. 页面和导出结果对账。
|
||||
1. P0-01 授权启停履历与历史时间边界;
|
||||
2. P0-05 导出 owner、Scope 和审计;
|
||||
3. P0-04 历史字段配置与质量原因;
|
||||
4. 双客户自动化越权测试和生产验证。
|
||||
|
||||
### 批次 C:外部正式入口
|
||||
### 批次 C:内部运维闭环
|
||||
|
||||
1. P0-05 外部身份适配器;
|
||||
2. P1-05 HTTPS 子域名和内部入口;
|
||||
3. P1-06 移动端真实客户验收。
|
||||
1. P1-01 专业多来源诊断页;
|
||||
2. P1-02 接入资料和数量口径校准;
|
||||
3. P1-05 每日差异自查与处置闭环;
|
||||
4. P1-03 全国省级聚合。
|
||||
|
||||
### 批次 D:数据治理
|
||||
### 批次 D:业务系统联动
|
||||
|
||||
1. P1-01 接入差异处置;
|
||||
2. P1-02 统一融合策略;
|
||||
3. P1-03 管理员溯源列表;
|
||||
4. P1-04 业务筛选维度。
|
||||
1. P1-04 OneOS 正式接口契约;
|
||||
2. 客户、部门、负责人、合同/项目映射;
|
||||
3. 基于业务维度的筛选和后续告警范围。
|
||||
|
||||
## 5. Goal 完成条件
|
||||
## 8. Goal 完成条件
|
||||
|
||||
本 Goal 只有在以下条件全部满足后才可标记完成:
|
||||
只有同时满足以下条件,才能将本 Goal 标记为完成:
|
||||
|
||||
1. 所有 P0 项均为“已完成”,并有测试或业务验收证据;
|
||||
2. 所有 P1 项均为“已完成”,或由业务负责人明确书面降级到后续范围;
|
||||
3. 历史里程补录具备来源文件、批次记录、差异报告和回滚/重跑能力;
|
||||
4. 至少完成两个互斥客户账号的自动化越权测试;
|
||||
5. 外部客户不通过 ECS IP 或运维 Token 使用平台;
|
||||
6. 生产部署、配置、数据口径和运维说明同步更新;
|
||||
7. 不修改 `ln-asset-management` 现有业务逻辑;
|
||||
8. 无车辆锁车、控车能力进入本次交付。
|
||||
|
||||
## 6. 已知产品边界
|
||||
|
||||
- 会议已确认:缺失历史里程可以从厂家平台补录,但历史轨迹拿不到就不补造;
|
||||
- 客户门户默认展示融合后的统一位置和里程,管理员保留查看多来源证据的能力;
|
||||
- 移动端首期继续使用响应式 Web 和二维码入口,App/小程序统一方案后续再定;
|
||||
- 外部身份系统只负责证明用户身份,最终菜单和车辆数据权限仍由车辆数据中台强制执行。
|
||||
1. P0-01 至 P0-08 全部为 `已完成`,并有测试、部署或业务验收证据。
|
||||
2. P1-01 至 P1-05 全部为 `已完成`,或由业务负责人书面确认降级为后续范围。
|
||||
3. 至少两个互斥客户账号通过车辆、时间范围、历史和导出的越权测试。
|
||||
4. 客户页面不存在用 `0` 表示“协议不提供/未知”的关键字段。
|
||||
5. 多来源车辆可解释推荐来源,无位置车辆不会从列表和统计中消失。
|
||||
6. 从全局监控进入子功能并返回时,能恢复原车辆和地图上下文。
|
||||
7. 导出任务具备 owner、客户 Scope、时间范围和持久化审计。
|
||||
8. 数据差异具备自动发现、证据、处置状态和恢复闭环。
|
||||
9. 生产部署、数据库迁移、运维说明和页面口径同步更新。
|
||||
10. 未修改 `ln-asset-management` 业务逻辑,未引入车辆锁车/控车能力。
|
||||
|
||||
Reference in New Issue
Block a user