conti-docs/prd/modules/05-WTY-延保.md

# 4.5 延保

> **本文件是【延保 WTY】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.5 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**

| 项 | 值 |
| --- | --- |
| 模块码 | WTY |
| V1.0 章节 | 4.5 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 延保小程序 43 张截图 |
| 现状承载系统 | 延保门店端小程序 + O2O |
| 需求条数 | 38（待确认 7，完成度 82%） |
| 配图 | 43 张（设计稿 2 / 现状-延保 39 / 现状-O2O 2） |

## 4.5.1 保障产品与责任边界

**业务目标**：明确延保产品的保障范围与责任边界，避免门店与消费者对「什么该走原厂质保、什么该走延保」产生争议。

**双保障并行生效**：原厂质量质保与「1 年撞击延保」互不替代、并行存在。制造缺陷应进入原厂基础质保；外力撞击导致的胎侧鼓包、爆胎等应进入撞击延保换新。

**延保协议与零售商使用条款**：支持查看保单协议，以及零售商延保使用条款、违规处理等规则，并留存同意条款时间。

![现状-延保 保单协议](../mini-program-images/Warranty/保单协议.png)

**页面内容** —— 「文件预览」容器里打开的《延保服务政策》PDF 长文，内容为保障范围与不予保障的 15 种情形。

**关键交互** —— ①上下滚动翻阅，跨页连续；②无任何可点控件，纯阅读页。

**可用角色** —— 店长 ✅、技工 ✅（只读）。

**需求关联** —— [REQ-WTY-001](#459-业务规则) 双保障并行、[REQ-WTY-036](#459-业务规则) PDF 预览与密级标识

> 三处细节值得注意：①这是**以 PDF 文件预览器打开的**，不是原生页面，App 侧需要原生 PDF 容器能力；②文档页脚带 Continental 的**密级标识「Public」**，属公司文档规范，展示时不得裁剪；③政策正文写明了两个品牌的生效起点 —— 美国将军轮胎 UC7/CC7/SC7 自 2022 年 9 月 1 日起、维京轮胎自 2020 年 11 月 1 日起，这是 [REQ-WTY-031](#459-业务规则) 品牌枚举的业务依据。

![现状-延保 德国马牌零售商延保使用条款须知](../mini-program-images/Warranty/德国马牌零售商延保使用条款须知.png)

**页面内容** —— 深色主题的两页式条款页，当前是第一页「使用条款」，顶部带本账户的同意时间戳。

**关键交互** —— ①顶部两段式进度条显示「使用条款 → 违规处理」两页，点底部橙色「下一页」翻到第二页；②灰底提示行「本账户于 2026.03.18 14:57 同意本条款」为只读留痕，不可点。

**可用角色** —— 店长 ✅、技工 ✅（只读查看）；同意动作记录操作人。

**需求关联** —— [REQ-WTY-010](#459-业务规则) 条款同意留痕、[REQ-WTY-035](#459-业务规则) 两页式与留痕字段

> **[REQ-WTY-010](#459-业务规则) 在现状已实现** —— 同意时间戳精确到分钟并展示在页面顶部。但两点须补：①条款是**两页**（使用条款 + 违规处理），须两页读完才可同意；②留痕只有时间，**没有条款版本号，也没有操作人**（现状延保侧拿不到真实员工身份，见 [REQ-WTY-015](#459-业务规则)）。见 [REQ-WTY-035](#459-业务规则)。

**目标角色** —— 店长、技工（只读查看）

**入口** —— 延保 tab 首页顶部「零售商延保使用条款须知」；保单详情页「保单协议」

**权限规则** —— 全角色可见；同意动作记录操作人

**数据来源** —— 延保后台

**回写目标** —— 条款同意时间戳回写延保后台

## 4.5.2 消费者激活与门店建单

**业务目标**：把延保建单从「独立小程序里重新录一遍」变成销售流程的自然延续，解决[痛点 2.6](../Continental-Retail-APP-PRD.md#26-售后延保)。

![设计稿-延保服务](../app-design-images/延保服务.png)

**页面内容** —— App 目标形态的延保服务首页：门店选择器 + 两个待办计数卡 + 「立刻延保」车牌录入区 + 保单管理 / 理赔处理双入口。

**关键交互** —— ①点门店名右侧 `▼` → 切换操作门店；②点右上橙色耳机 → 延保客服；③点「零售商延保使用条款须知 >」→ 条款页；④点两个计数卡 → 各自的待办列表；⑤点橙色「扫描车牌」→ 拍照识别；⑥或在车牌格子逐位输入，点绿色「+新能源」在 7 位/8 位车牌间切换；⑦车牌未填满时「下一步」为禁用态；⑧点「切换特殊车牌录入」→ 换成自由文本输入模式；⑨底部「保单管理」「理赔处理」两个入口。

**可用角色** —— 店长 ✅ 全量；技工 ❓ 建单权限待定 `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-037](#459-业务规则) 车牌录入的两种模式、[REQ-WTY-028](#459-业务规则) 待办归并

> 设计稿有两处与现状不符，须在设计评审时修正：①「切换特殊车牌录入」带**外链图标 ↗**，暗示跳出到别的页面，但现状是**同页切换输入控件**（车牌格子 ⇄ 自由输入框），见 [REQ-WTY-037](#459-业务规则)；②门店选择器与客服入口都放在延保页内，而按 [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 门店上下文应收敛到 App 全局，延保内不再单设切店入口。

设计稿延保服务页构成：门店选择器（门店名 + 门店编码）+ 客服入口 → 「零售商延保使用条款须知」→ 待绑定车辆 / 待补充装车视频 双计数卡 → **立刻延保**（扫描车牌主按钮 / 或手动录入车牌，车牌格子含「新能源」标记，「下一步」，「切换特殊车牌录入」）→ 保单管理 / 理赔处理 双入口。

**消费者延保激活链路**：消费者需通过「大陆马牌轮胎服务」公众号进入「延保换新 | 消费者端」，以手机号注册，上传驾驶证认证，添加车辆并上传行驶证，录入轮胎条码 / DOT 和购买凭证，确认激活。

> 该链路在消费者侧完成，不在本 APP 范围内，但门店端的「待绑定车辆」「待补充装车视频」待办正是由该链路的未完成状态产生。

**门店端立即延保建单**：首页提供「立即延保」入口，门店扫描或录入车牌后进入下一步，为消费者建立 / 承接延保业务。

**车牌识别与特殊车牌兼容**：支持拍摄车牌进行识别；识别失败或特殊车牌场景下可切换普通车牌手动输入。

![现状-延保 扫描车牌](../mini-program-images/Warranty/扫描车牌.png)

**页面内容** —— 「拍摄车牌」相机页，橙色取景框 + 底部快门按钮，框内是拍摄时误对准键盘的测试画面。

**关键交互** —— ①对准车牌点底部橙色快门 → 拍照并上传识别；②点中部横条「使用手动输入车牌 >」→ 转手工录入。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-037](#459-业务规则) 车牌录入的模式与文案配色

> **确认了识别方式**：有快门按钮，说明是**拍照上传识别**而非实时视频流识别，与销售模块 [REQ-SAL-002](./03-SAL-销售.md#439-业务规则) 的口径一致，两处应复用同一套 OCR 能力。
> 两处 UI 问题：①提示文案写「请将**黄色**取景框对准车牌」，而实际取景框是**橙色**；②「使用手动输入车牌」用了**红色按钮**，红色在本 App 中是危险操作色（如「作废保单」），此处语义不符。均见 [REQ-WTY-037](#459-业务规则)。

![现状-延保 特殊车牌输入](../mini-program-images/Warranty/特殊车牌输入.png)

**页面内容** —— 延保小程序首页处于「特殊车牌录入」模式时的样子，车牌格子已换成一个自由文本输入框。

**关键交互** —— ①点橙色「扫描车牌」→ 拍照识别；②在「输入车牌号码」框内自由输入，不受 7/8 位格子约束；③点橙色文字「切换普通车牌录入」→ 切回车牌格子模式；④点顶部两个计数「0 >」→ 各自的待办列表；⑤点右下绿色悬浮胶囊「延保客服」→ 客服会话；⑥底部 tab 五项：首页 / 工作台 / 中间橙色圆形图标 / 待办事项 / 我的。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-037](#459-业务规则) 两种录入模式为同页切换、[REQ-WTY-028](#459-业务规则) 待办归并

> **本图证明普通 / 特殊车牌是同页切换控件，不是两个页面** —— 普通模式用车牌格子（逐位约束），特殊模式用自由输入框（不做位数校验），两者用一个橙色文字链互切。设计稿把它画成外链跳转是错的，见 [REQ-WTY-037](#459-业务规则)。
> 另有三点：①底部 tab **中间那个橙色圆形指南针图标没有文字标签**，其功能本图无法确认；②「延保客服」用了**绿色**悬浮胶囊，在这套深色 + 橙色主题里是唯一的绿色元素，疑为跳转微信客服；③顶部条款提示条压在系统状态栏上，属遮挡。

**待办驱动的激活完善**：将未完成业务拆为「待绑定车辆」和「待补充装车视频」，并可在待办页按待处理 / 已完成状态查询。

![现状-延保 待绑定车辆](../mini-program-images/Warranty/待绑定车辆.png)

**页面内容** —— 「待绑定车辆 / 待补充装车视频」两 tab 的待办列表页，当前是待绑定车辆的空态。

**关键交互** —— ①切换顶部两个 tab；②切换「待绑定 / 已完成」两个状态胶囊；③在「搜索车牌号」框内检索。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并

![现状-延保 待补充装车视频](../mini-program-images/Warranty/待补充装车视频.png)

**页面内容** —— 与上一张**完全相同**（同一时刻、同一 tab、同一空态），未拍到「待补充装车视频」tab 的实际内容。

**关键交互** —— 同上一张，无新增。

**可用角色** —— 同上一张。

**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并

> **这两张图是同一张截图** —— 附录 C 第 6、7 行分别指向两个文件，但两个文件的内容逐像素一致（均为 16:47、5G 88%、选中「待绑定车辆」tab、空态）。**「待补充装车视频」tab 的实际内容至今没有任何佐证**，而它恰恰是首页待办里唯一被列入 App 跨系统待办的延保事项。**建议优先补拍。**

![现状-延保 待办事项](../mini-program-images/Warranty/待办事项.png)

**页面内容** —— 延保小程序底部 tab「待办事项」页的空态，页面仅有标题与「暂无待办事项」占位。

**关键交互** —— 无交互，空态页。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并

> **延保小程序内部就已经有两套待办** —— 首页的「待绑定车辆 / 待补充装车视频」两个计数卡有自己的列表页（上两张图），而底部 tab 的「待办事项」是**另一个独立页面**。两者是否同源、为何并存，本图无法确认。这使 `TODO(REQ-WTY-002)` 的归并问题比原文描述的更复杂 —— 要归并的不是「延保待办 vs 首页待办」两套，而是三套。见 [REQ-WTY-028](#459-业务规则)。

> 延保的「待办事项」是独立 tab，与 [App 首页待办](./02-HOM-APP首页与导航.md#423-店长首页)存在归并关系：延保视频上传提醒已列入首页跨系统待办。归并后延保 tab 内是否保留独立待办页 —— `TODO(REQ-WTY-002)`。

**门店切换**：用户可在首页和工作台选择当前操作门店，保证建单、查询、返利等数据归属于正确门店。

![现状-延保 首页切换店铺](../mini-program-images/Warranty/首页切换店铺.png)

**页面内容** —— 从首页调起的「选择操作店铺」弹层，列表中只有一个门店。

**关键交互** —— ①点门店行选中并关闭弹层；②点右上「✕ 关闭」取消。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文（整合后本入口取消）

> 该测试账号只绑一个门店，因此**弹层没有搜索框，也看不出多门店时的排序与置顶规则**。[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的切换门店页有搜索且当前门店置顶，两处口径须统一到全局门店上下文。

![现状-延保 工作台-选择店铺](../mini-program-images/Warranty/工作台-选择店铺.png)

**页面内容** —— 从工作台调起的同一个「选择操作店铺」弹层，遮罩下可见工作台的六宫格与延保数据卡。

**关键交互** —— 与上一张完全一致，是同一个组件。

**可用角色** —— 同上一张。

**需求关联** —— [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文（整合后本入口取消）

> 两张图佐证的是**同一个弹层组件挂在两个入口下**（首页 + 工作台）。正文原写「用户可在首页和工作台选择当前操作门店」，本次确认二者共用同一组件，整合后**两个入口一并取消**。

> 整合后门店切换收敛到 App 全局门店上下文（[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则)），延保内不再单独提供切店入口。

## 4.5.3 保单与延保生命周期管理

**业务目标**：提供保单的全量查询、状态跟踪与生命周期操作，替代跨平台查保单的现状。

![设计稿-保单管理](../app-design-images/保单管理.png)

**页面内容** —— App 目标形态的保单管理页：搜索框 + 四个分组胶囊 + 保单卡列表。

**关键交互** —— ①搜索框检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个胶囊；③点卡片右下「详情 >」→ 保单详情；④卡右上角状态胶囊为只读标识。

**可用角色** —— 店长 ✅；技工 ❓ 保单查询权限待定 `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-013](#459-业务规则) 一车四胎、[REQ-WTY-014](#459-业务规则) 保障类型枚举、[REQ-WTY-011](#459-业务规则) 状态机

> **本设计稿有四处必须修正的问题：**
> 1. **`POLICY NO.` 标错了字段** —— 卡片主号 8507302611 在现状里是**轮胎条码**，真正的保单号是 15 位的「保单子代码」（如 173147928125200）。见 [REQ-WTY-012](#459-业务规则)。
> 2. **「数包保障」是「鼓包保障」的错别字** —— 现状小程序写的是「鼓包保障」。见 [REQ-WTY-014](#459-业务规则)。
> 3. **三条示例数据的保单号与车牌完全相同、状态却不同** —— 现状是「一车四胎、一胎一保单」，同一车牌下应是**四个不同的轮胎条码**。见 [REQ-WTY-013](#459-业务规则)。
> 4. **状态色与语义错配** —— 正常=橙、待确认=绿、待补充=红；按通行约定应为 正常=绿、待确认=橙、待补充=红。
>
> 另：设计稿的状态胶囊（正常/待确认/待补充）是对现状的**增强** —— 现状列表卡没有状态标识，只能靠切 tab 区分，这个改进值得保留。

**保单全量查询与搜索**：按车牌或轮胎条码搜索全部保单，并按全部、正常保单、待补充保单、待确认保单分组查看。

![现状-延保 所有保单](../mini-program-images/Warranty/所有保单.png)

**页面内容** —— 深色的「所有保单」列表，5 条记录均带「鼓包保障 / 爆胎保障」双标签，底部固定筛选条。

**关键交互** —— ①搜索框支持**车牌号或条码**两种检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个平铺 tab；③点任意行 `>` → 保单详情；④点底部「筛选 | 已筛选 >」→ 筛选弹层。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-013](#459-业务规则) 一车四胎、[REQ-WTY-009](#459-业务规则) 保单筛选

> **本图给出了保单数据结构的关键事实**：豫AQ27Z3 一个车牌下有 **4 条不同编号**的记录（8507302611 / 8506983288 / 8507302660 / 8505665909），时间都是 2024.11.13 14:16 —— 这是**一车四胎、每条胎一条记录**，而列表主号是**轮胎条码**不是保单号。见 [REQ-WTY-013](#459-业务规则)、[REQ-WTY-012](#459-业务规则)。
> 另：底部「已筛选」是橙色，说明当前列表**带着生效中的筛选条件**，不是全量；现状卡片**没有状态标识**，设计稿的状态胶囊是新增能力。

**保单状态、标签和安装留痕**：显示保单子代码、保单类型、轮胎条码、轮胎规格、保障状态、安装门店、安装时间、安装城市及安装店员。

![现状-延保 保单子代码详情](../mini-program-images/Warranty/保单子代码详情.png)

**页面内容** —— 单个保单子代码的详情页，分「保单基础信息 / 保单状态信息 / 安装信息」三段。

**关键交互** —— 无交互，纯信息展示页。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-015](#459-业务规则) 安装店员须为真实身份

> **这张图澄清了保单的字段结构**：保单子代码 `173147928125203`（15 位）才是保单主键，`8507302611` 的字段名明确写作「**轮胎条码**」，「轮胎描述」是规格串 `215/55R17 94W FR UC7 #`。列表页与设计稿把轮胎条码当保单号展示，须更正，见 [REQ-WTY-012](#459-业务规则)。
> **「安装店员」显示「微信用户」，不是真实姓名** —— 正文把安装店员列为留痕字段，但现状拿不到员工身份。这直接架空了 [REQ-WTY-005](#459-业务规则) 保单作废的审计要求（不知道是谁操作的），见 [REQ-WTY-015](#459-业务规则)。

**延保详细信息管理**：集中展示轮胎规格、保单号、投保车辆、VIN、投保人、保单有效期及保单状态；关联系统流水，如「新胎激活」「用户核保」等。

**保单作废**：门店具备作废保单的操作入口，应配合权限、状态校验和审计记录控制使用。

![现状-延保 保单详情-保单与活动信息](../mini-program-images/Warranty/保单详情-保单与活动信息.png)

**页面内容** —— 保单详情页下半部分：三条系统流水 + 空的活动信息区，底部是常驻的红色「作废保单」。

**关键交互** —— ①点分区右侧「^ 收起」折叠「保单信息 / 活动信息」；②点任一条流水的 `>` → 该笔流水详情；③点底部红色「作废保单」→ 作废流程。

**可用角色** —— 店长 🔸 受限（高风险）；技工 ✗ 无权限 `TODO(REQ-WTY-005)`。

**需求关联** —— [REQ-WTY-016](#459-业务规则) 作废的状态校验与二次确认、[REQ-WTY-017](#459-业务规则) 流水排序与事件枚举

> **两处必须修正的问题：**
> 1. **该保单状态已是「延保已过有效期」，「作废保单」按钮仍然可点** —— 现状没有任何状态校验，也没看到二次确认。正文 [REQ-WTY-005](#459-业务规则) 要求「权限 + 状态校验 + 审计记录」，现状三样都缺。见 [REQ-WTY-016](#459-业务规则)。
> 2. **三条流水的排序无规律** —— 依次是 14:16 爆胎保障 / 14:21 用户核保 / 14:16 新胎激活，既非正序也非倒序。按业务发生顺序应为 新胎激活 → 爆胎保障 → 用户核保。见 [REQ-WTY-017](#459-业务规则)。
>
> 另：「用户核保」那条没有门店信息（因为是消费者侧动作），说明流水混合了门店端与消费者端两类事件。

![现状-延保 保单详情-延保信息](../mini-program-images/Warranty/保单详情-延保信息.png)

**页面内容** —— 保单详情页上半部分：橙色轮胎卡 + 「延保信息」字段区，底部同样常驻红色「作废保单」。

**关键交互** —— ①三处「复制」按钮（轮胎条码 / 保单号 / 投保车辆车牌）；②点「保单协议 >」→ PDF 预览；③点「^ 收起」折叠分区。

**可用角色** —— 店长 ✅ 查看 / 🔸 作废；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-011](#459-业务规则) 状态机补「已过有效期」、[REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-015](#459-业务规则) 投保人身份

> **本图暴露了保单状态机的缺口**：保单有效期 2025.11.14、保单状态「**延保已过有效期**」—— 而正文 4.5.8 声明的状态机是「待补充 → 待确认 → 正常 → 已作废」，**根本没有这一态**。见 [REQ-WTY-011](#459-业务规则)。
> 另两点：①**保单号 `173147928125200` 与上一张图的保单子代码 `173147928125203` 只差末位** —— 同一条轮胎下有多个子代码，分别对应「鼓包保障」与「爆胎保障」两种保障，印证 [REQ-WTY-013](#459-业务规则) 的三层结构；②**投保人显示「微信用户」**，与安装店员同样是兜底值，见 [REQ-WTY-015](#459-业务规则)。

> 保单作废是不可逆的高风险操作。作废权限归属（是否限店长）、是否需要二次确认与作废原因、是否需要后台审批 —— `TODO(REQ-WTY-005)`。V1.1 已明确其中的状态校验与原因留痕要求，见 [REQ-WTY-016](#459-业务规则)。

**保单筛选**：支持按激活起止日期、轮胎品牌筛选保单；品牌可选全部、马牌轮胎、维京轮胎。

![现状-延保 保单筛选](../mini-program-images/Warranty/保单筛选.png)

**页面内容** —— 保单筛选弹层，上方压着一整块黄色的「消费者未认证」提醒卡。

**关键交互** —— ①点激活开始 / 结束日期 `>` → 日期滚轮；②点「选择品牌 >」→ 品牌滚轮；③「清除条件」（红色描边）重置，「确认筛选条件」（橙色）应用；④「✕ 关闭」取消。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-009](#459-业务规则) 保单筛选、[REQ-WTY-008](#459-业务规则) 消费者未认证兼容

> 黄色提醒卡是正文「消费者认证状态兼容」的原文出处，并补充了两个正文没写的细节：**新老系统切换点是 2020 年 8 月 24 日 7 点**，且消费者找回保单的方式是「在新系统扫描**两证**」（驾驶证 + 行驶证）。
> 注意 **筛选的激活开始日期默认就是 2020-08-24** —— 即默认筛选已排除老系统保单，这与提醒卡的说明是同一件事的两面。
> 一处 UI 问题：「清除条件」用了红色描边，与「作废保单」同色，但两者风险等级完全不同。

![现状-延保 保单筛选日期](../mini-program-images/Warranty/保单筛选日期.png)

**页面内容** —— 同一筛选弹层下方升起的微信原生日期滚轮（年 / 月 / 日三列）。

**关键交互** —— ①三列滚轮各自滑动选值；②「取消」放弃，绿色「确定」回填到筛选项。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-038](#459-业务规则) 统一选择器

> **白底 + 绿色确定按钮的微信原生 picker，压在深色页面上，视觉断裂明显。** 这是小程序无法改写原生组件主题的典型代价，本模块共 4 张截图出现同一问题（日期 ×2、品牌 ×2）。App 自研后可统一，见 [REQ-WTY-038](#459-业务规则)。

![现状-延保 保单筛选品牌](../mini-program-images/Warranty/保单筛选品牌.png)

**页面内容** —— 同一筛选弹层的品牌滚轮，三项：全部 / 马牌轮胎（选中）/ 维京轮胎。

**关键交互** —— ①滚动选择品牌；②「取消 / 确定」。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-009](#459-业务规则) 保单筛选、[REQ-WTY-031](#459-业务规则) 品牌枚举统一

> 品牌三项与 [REQ-WTY-009](#459-业务规则) 一致 ✓。但本模块内品牌枚举出现了**三种不同写法**：此处 3 项（全部/马牌轮胎/维京轮胎）、工作台指标用「马 / 维」单字缩写、返利中心筛选**只有 2 项且没有「全部」**。见 [REQ-WTY-031](#459-业务规则)。

**消费者认证状态兼容**：历史保单可能显示「消费者未认证」，页面提示该状态不影响延保返利及管理端查询；消费者后续在新系统扫码可找回保单。

**销售流程内查看延保**：O2O 侧亦提供「查看延保」入口，与销售流程中的[延保历史记录](./03-SAL-销售.md#432-接车与车辆识别)同源。

![现状-O2O 查看延保](../mini-program-images/O2O/查看延保.png)

**页面内容** —— O2O 侧的「查看延保」页（浅色），顶部是订单与延保的比对汇总，下方按轮胎逐条列出延保状态。

**关键交互** —— ①无操作按钮，纯查询页；②粉色顶条为风险提示，橙色行为数据审核状态提示。

**可用角色** —— 店长 ✅；技工 ⚙️ 需被授权（沿用销售模块的订单权限）。

**需求关联** —— [REQ-WTY-018](#459-业务规则) 两段式生效、[REQ-WTY-019](#459-业务规则) 状态收敛、[REQ-SAL-033](./03-SAL-销售.md#439-业务规则) O2O 侧延保入口

> **本图是全模块信息量最大的一张，暴露了三处状态自相矛盾：**
> 1. 每张卡的标题写「**暂无延保信息**」，但卡内又同时显示「**✅ 激活成功**」和「**🔄 用户未确认**」——三个状态互相打架。
> 2. 顶部汇总写「订单轮胎数：4，**延保成功轮胎数：0**」，而下方 4 条全部显示「激活成功」——**计数与明细对不上**。
> 3. 还叠加了一条「订单数据审核中，请稍后查询」。
>
> 但矛盾之下藏着一条**正文完全没记录的核心业务规则**：「激活成功」与「用户未确认」并存，说明**延保生效是两段式的 —— 门店激活之后还需消费者确认**，只有两者都完成才计入「延保成功」。这解释了为什么 4 条激活成功却统计为 0。见 [REQ-WTY-018](#459-业务规则)、[REQ-WTY-019](#459-业务规则)。
>
> 另：第 3 条轮胎规格 255/45R19 与前两条 235/55R20 不同，属前后轮不同规格的正常情况；门店名「智慧园杀虫轮胎店」是脏数据。

## 4.5.4 预约与理赔运营

**业务目标**：把预约车检与理赔受理的跟进从多平台查询收敛到门店端一处。

**预约车检管理**：按车牌搜索预约，按「预约车检、已受理、已上报」跟踪预约处理状态。

![现状-延保 全部预约-预约信息1](../mini-program-images/Warranty/全部预约-预约信息1.png)

**页面内容** —— 「预约信息」列表的「预约车检」页签，三条预约记录。

**关键交互** —— ①切换顶部「预约信息 / 提交的理赔信息」两个 tab；②切换「预约车检 / 已受理 / 已上报」三个状态胶囊；③搜索框按车牌号检索；④点任一行 `>` → 预约详情。

**可用角色** —— 店长 ✅；技工 ❓ 理赔受理权限待定 `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛、[REQ-WTY-022](#459-业务规则) 三类案件状态机、[REQ-WTY-023](#459-业务规则) CATI 归属

> **每条预约都带一个「CATI预约：<日期>」字段** —— 这是回答 `TODO(REQ-WTY-006)` 的关键证据：**预约车检本质就是预约 CATI 检测**，预约、理赔、CATI 是同一条业务链上的三个环节，不是三套独立业务。见 [REQ-WTY-023](#459-业务规则)。
> 另：预约序列号统一为 `TI` 前缀 + 7 位数字（TI0000657）；申请时间与 CATI 预约日期可以是同一天，也可相隔数日。

![现状-延保 全部预约-预约信息2](../mini-program-images/Warranty/全部预约-预约信息2.png)

**页面内容** —— 同一列表切到「已受理」页签，为空。

**关键交互** —— 同上一张，无新增。

**可用角色** —— 同上一张。

**需求关联** —— [REQ-WTY-022](#459-业务规则) 三类案件状态机、[REQ-WTY-030](#459-业务规则) 空态统一

> 「已受理」为空，因此**已受理状态下的卡片长什么样、比预约车检多哪些字段，本图无法确认**。
> 另：本模块的空态至少有三种写法 —— 待办列表用插画 +「暂无数据」、本页用纯文字「没有更多了」、理赔管理页用虚线框 +「暂无预约记录」。见 [REQ-WTY-030](#459-业务规则)。

**预约详情与订单凭证**：记录车辆同步问题、申请时间、申请人、脱敏手机号、预约序列号、预约检测时间、订单编号及订单 / 确认图片。

![现状-延保 全部预约-预约信息详情](../mini-program-images/Warranty/全部预约-预约信息详情.png)

**页面内容** —— 预约详情页，分「基础信息 / 预约时间 / 订单信息」三段。

**关键交互** —— 无交互，纯信息展示页。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-025](#459-业务规则) 脱敏格式统一

> 三处发现：
> 1. **手机号脱敏为 `*******3963`（7 星 + 后四位）**，而 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)用的是 `138****7616`（前三 + 四星 + 后四）。**全 App 脱敏格式不统一**，且此处的申请人姓名「王磊」是消费者姓名、完全未脱敏。见 [REQ-WTY-025](#459-业务规则)。
> 2. **字段名「车主同步问题」，值是「抖动」** —— 从值可判断这是消费者反馈的故障现象，字段名疑为「反馈问题」之误。
> 3. **「订单图片」「订单确认图片」两栏都是空的** —— 正文把它们列为记录项，但无图可看，**其展示形式（缩略图 / 点击放大 / 几张）本图无法确认**。

**延保理赔受理**：支持扫描消费者延保理赔码进入处理，并支持按车牌号或条码搜索，分别查看进行中和已完成案件。

![现状-延保 理赔-延保理赔](../mini-program-images/Warranty/理赔-延保理赔.png)

**页面内容** —— 「理赔管理」页的「延保理赔」tab，顶部是「临近预约」提醒卡，下方是案件列表（空）。

**关键交互** —— ①点提醒卡底部橙色「全部预约」→ 预约列表页；②切换「延保理赔 / 售后鉴定 / CATI理赔」三个 tab；③搜索框支持车牌号或条码；④切换「正在进行 / 已完成」两个状态胶囊。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-021](#459-业务规则) 临近预约并入待办、[REQ-WTY-020](#459-业务规则) 入口收敛、[REQ-WTY-022](#459-业务规则) 状态机

> **顶部的「临近预约（未来3天内的预约）」是一个正文完全没提的主动提醒机制。** 它与 [4.4 提醒](./04-RMD-提醒.md#44-提醒)、[App 首页待办](./02-HOM-APP首页与导航.md#423-店长首页)是同一类东西 —— 门店需要在预约日前被提醒备料备人。整合后应并入首页跨系统待办，见 [REQ-WTY-021](#459-业务规则)。
> 另：「全部预约」的入口挂在这张卡的底部，即**预约列表是理赔管理的下级页面**，而不是平级功能。

![现状-延保 理赔处理](../mini-program-images/Warranty/理赔处理.png)

**页面内容** —— 极简的「理赔处理」页，只有「延保理赔」扫码卡与「售后鉴定 >」两个入口。

**关键交互** —— ①点橙色「扫描消费者的延保理赔码」→ 相机扫码；②点「售后鉴定 >」→ 售后鉴定页。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛

> **理赔码由消费者出示、门店扫** —— 与销售模块的核销码是同一种交互模型。
> 「理赔处理」页与「理赔管理」页是**两个不同的页面**（前者是发起入口，后者是案件跟踪），但命名极为接近，门店容易混淆。页面下方还有一块几乎不可见的深色文字，**本图无法确认其内容**（疑为扫码失败时的手动输入提示）。

**预约码手动录入**：当扫码不可用时，可人工输入预约码进行匹配和受理。

![现状-延保 手动输入预约码](../mini-program-images/Warranty/手动输入预约码.png)

**页面内容** —— 「输入预约码」弹层，单输入框 + 橙色「确认」。

**关键交互** —— ①键入预约码；②点「确认」提交匹配；③「✕ 关闭」取消。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛

> 两点：①**该弹层是从「售后鉴定」页调起的**（遮罩下可见售后鉴定页），不是从理赔处理页；②输入框**没有格式提示**，而预约序列号现状为 `TI` + 7 位数字，应在占位文案里给出样例，并做前缀校验。

**提交理赔信息跟踪**：理赔信息按正在进行、已完成分组展示，便于门店持续跟进处理结果。

![现状-延保 全部预约-提交的理赔信息](../mini-program-images/Warranty/全部预约-提交的理赔信息.png)

**页面内容** —— 「预约信息 / 提交的理赔信息」两 tab 中的第二个，为空。

**关键交互** —— ①切换两个顶部 tab；②切换「正在进行 / 已完成」；③搜索框按车牌号检索。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛

> **本页与「理赔管理 > 延保理赔」tab 的结构完全相同**（都是 搜索 + 正在进行/已完成 + 列表），两处是否为同一份数据本图无法确认。这是入口冗余最直接的证据 —— 同一批理赔案件至少有两个查看路径，见 [REQ-WTY-020](#459-业务规则)。

**CATI 理赔分流**：理赔管理中独立提供 CATI 理赔入口，与延保理赔和售后鉴定并列管理。

![现状-延保 理赔-CATI理赔](../mini-program-images/Warranty/理赔-CATI理赔.png)

**页面内容** —— 「理赔管理」页切到「CATI理赔」tab，结构与「延保理赔」tab 完全一致。

**关键交互** —— 同「延保理赔」tab，无新增。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-022](#459-业务规则) 状态机、[REQ-WTY-023](#459-业务规则) CATI 归属

> 三个 tab 共用同一套页面结构，只是数据源不同。但状态机不同：延保理赔与 CATI理赔是**两态**（正在进行 / 已完成），售后鉴定是**三态**（多一个「待上传」），见 [REQ-WTY-022](#459-业务规则)。

![现状-O2O 认证轮胎技术检测中心CATI](../mini-program-images/O2O/认证轮胎技术检测中心CATI.png)

**页面内容** —— O2O 侧的 CATI 页，是一个**门店资质的开通状态页**，底部按钮为「关闭服务」。

**关键交互** —— ①滚动阅读 CATI 说明文字；②点底部橙色「关闭服务」→ 关闭本门店的 CATI 资质。

**可用角色** —— 店长 ✅（属门店资质管理）；技工 ✗。

**需求关联** —— [REQ-WTY-023](#459-业务规则) CATI 的两个面（关闭 `TODO(REQ-WTY-006)`）、[REQ-WTY-024](#459-业务规则) 文案脏数据

> **本图回答了 `TODO(REQ-WTY-006)`。** 底部按钮是「**关闭服务**」，说明 O2O 侧的 CATI 是**门店资质的开通 / 关闭开关**，而延保侧的 CATI 是**理赔案件的跟踪列表** —— 两者不是重复功能，而是同一项资质的两个面：**资质开关归 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)，案件跟踪归本模块**。见 [REQ-WTY-023](#459-业务规则)。
> 另两处必须处理：①**说明文案是脏数据** —— 同一段介绍重复了 4 遍，每遍后面还跟着一行测试串「xxx特热爱1111…」，上线前须由业务重新提供；②「关闭服务」会使门店失去 CATI 资质，属高风险操作，现状**没有二次确认**。见 [REQ-WTY-024](#459-业务规则)。

> CATI 入口同时存在于延保小程序与 O2O 接单宝 —— ~~两处是否为同一业务、整合后归属哪个模块~~ **V1.1 关闭**：两处不是同一业务，结论见 [REQ-WTY-023](#459-业务规则)。

## 4.5.5 售后鉴定与证据采集

**业务目标**：为轮胎故障提供标准化的鉴定资料采集流程，保证证据链完整可追溯。

**售后鉴定受理入口**：支持扫描消费者理赔码 / 预约码、手动输入预约码，以及进入无用户信息鉴定通道。

![现状-延保 售后鉴定](../mini-program-images/Warranty/售后鉴定.png)

**页面内容** —— 「售后鉴定」入口页：一个扫码主按钮 + 两个次级入口，下方是两条说明文字。

**关键交互** —— ①点橙色「扫描消费者的理赔码/预约码」→ 相机扫码（**一个入口同时接受两种码**）；②点「手动输入预约码 >」→ 输入弹层；③点「无用户信息鉴定 >」→ 无用户通道表单。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-007](#459-业务规则) 无用户信息鉴定、[REQ-WTY-020](#459-业务规则) 入口收敛

> 页内说明文字是 [REQ-WTY-007](#459-业务规则) 的原文出处 ✓：「该模式未关联消费者的延保保单，因此，无法进行延保鉴定理赔」。
> 但说明第 1 条讲的是「CATI理赔」，而页面标题是「售后鉴定」—— **CATI 理赔与售后鉴定在这个入口下是混在一起的**，与「理赔管理」页把二者拆成两个 tab 的做法不一致。这是 [REQ-WTY-020](#459-业务规则) 要收敛的又一处。
> 另：主按钮同时接受「理赔码 / 预约码」两种码，App 侧须能自动判别码型并路由。

**售后鉴定状态跟踪**：可按「待上传、正在进行、已完成」管理鉴定单，且支持按车牌或条码查询。

![现状-延保 理赔-售后鉴定](../mini-program-images/Warranty/理赔-售后鉴定.png)

**页面内容** —— 「理赔管理」页的「售后鉴定」tab，状态胶囊比另两个 tab 多一个「待上传」。

**关键交互** —— ①切换「待上传 / 正在进行 / 已完成」三个状态胶囊；②其余同「延保理赔」tab。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-022](#459-业务规则) 三类案件状态机各不相同

> 正文 4.5.5 写的「待上传、正在进行、已完成」**只适用于售后鉴定**，延保理赔与 CATI理赔 都是两态。App 侧不应强行统一，见 [REQ-WTY-022](#459-业务规则)。「待上传」这一态的存在也说明鉴定单可以先建单、后补证据，与 [8.6 弱网与离线](../Continental-Retail-APP-PRD.md#86-弱网与离线)的本地暂存策略直接相关。

**无用户信息鉴定**：适用于未关联消费者延保保单的轮胎故障鉴定，**仅做故障鉴定，不可走延保理赔**。

**标准化鉴定资料收集**：采集车辆品牌 / 型号、轮胎故障、生产日期、完整 DOT、轮位、轮胎品牌，以及 DOT 照片、胎面照片、故障部位内外部照片；补充视频为可选项。

![现状-延保 无用户信息鉴定通道1](../mini-program-images/Warranty/无用户信息鉴定通道1.png)

**页面内容** —— 「无用户通道」表单上半部分，分车辆信息 / 轮胎故障信息 / 轮胎基础信息 / 轮胎照片信息四段，字段均为必填。

**关键交互** —— ①带 `>` 的字段点开下拉选择（车辆品牌 / 轮胎故障信息 / 轮位 / 轮胎品牌）；②车辆型号、生产日期、DOT 编码为文本输入；③点「ⓘ 示例：」旁的缩略图 → 查看拍照示范；④点上传区 → 拍照或选图；⑤底部「确认保存」提交。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)` —— 鉴定资料采集是现场作业，实际使用者以技工为主。

**需求关联** —— [REQ-WTY-007](#459-业务规则) 无用户信息鉴定、[REQ-WTY-026](#459-业务规则) 必填与张数、[REQ-WTY-027](#459-业务规则) 必填标识规范

> 两点：①**「生产日期（4 位）」与「DOT 编码（完整）」是两个独立字段**，前者是 DOT 尾部的周 + 年，正文写「生产日期、完整 DOT」是对的但未说明二者关系；②**必填标识的表达方式有问题** —— 所有字段都带 `*`，但下拉选择类的占位文字是**红色**、文本输入类是**灰色**，用颜色区分的是控件类型而非必填性，门店容易误读为「红的才必填」。见 [REQ-WTY-027](#459-业务规则)。
> 页面标题是「无用户通道」，比入口处的「无用户信息鉴定」短，两处命名应统一。

![现状-延保 无用户信息鉴定通道2](../mini-program-images/Warranty/无用户信息鉴定通道2.png)

**页面内容** —— 同一表单下半部分的四个上传区，每区各带一张拍照示范缩略图。

**关键交互** —— ①点 `+` 方格 → 拍照或从相册选择；②每类照片有各自的张数上限；③「补充视频」为唯一选填项；④底部「确认保存」提交。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。

**需求关联** —— [REQ-WTY-026](#459-业务规则) 必填项与张数上限

> **四类照片的张数上限各不相同**：DOT 照片 ≤1 张、胎面照片 ≤1 张、故障部位内外部照片 ≤3 张，胎侧整体照片的上限**被顶部返回胶囊遮挡，本图无法确认**。每类都配了拍照示范缩略图，这个设计降低了门店拍错率，App 侧应保留。见 [REQ-WTY-026](#459-业务规则)。
> 顶部的小程序返回胶囊常驻并遮挡页面内容，是小程序容器的固有问题，App 自研后可消除。

> 照片与视频为必填证据，涉及弱网环境下的大文件上传。断点续传、失败重试、本地暂存策略见 [8.6](../Continental-Retail-APP-PRD.md#86-弱网与离线)。

## 4.5.6 工作台、返利与经营数据

**业务目标**：为门店提供延保业务的聚合视图与返利可见性。

**工作台快捷入口**：聚合保单、理赔、返利、教程、店员、数据等核心业务模块，并展示当前门店延保数据和返利简报（见 [2.7.4](../Continental-Retail-APP-PRD.md#274-延保门店端小程序)）。

**经营数据时间粒度切换**：工作台支持按月、年查看延保数据，并可切换品牌口径。

![现状-延保 工作台-筛选品牌](../mini-program-images/Warranty/工作台-筛选品牌.png)

**页面内容** —— 工作台页 + 品牌选择滚轮，页内可见六宫格入口与「延保数据」卡的月粒度视图。

**关键交互** —— ①六宫格入口分别进入 保单 / 理赔 / 返利 / 教程 / 店员 / 数据；②「月 | 年」切换时间粒度；③滚轮选品牌后点绿色「确定」应用。

**可用角色** —— 店长 ✅；技工 ❓ 返利与数据可见性待定 `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-031](#459-业务规则) 品牌枚举

> 六宫格确认为 **保单 / 理赔 / 返利 / 教程 / 店员 / 数据**，与正文完全一致 ✓。
> 「延保数据」卡已经按品牌拆成「马牌延保数量 / 维京延保数量」两列，上面又有一个品牌筛选滚轮 —— **筛选与拆列功能重复**。另，两个指标下方各有一行「筛选结果」标签但没有对应数值，**本图无法确认**该行是被滚轮遮住还是本就为空。

![现状-延保 工作台-年](../mini-program-images/Warranty/工作台-年.png)

**页面内容** —— 工作台切到「年」粒度的完整视图，含「延保数据」与「店铺返利简报」两张卡。

**关键交互** —— ①「月 | 年」切换 → 日期区间随之变化；②点「查看返利明细」类入口进入下级页；③点底部「筛选品牌 | 全部 >」→ 返利简报的独立品牌筛选。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-029](#459-业务规则) 数据口径、[REQ-WTY-031](#459-业务规则) 品牌枚举

> 三点口径须写进 PRD：①**「月 / 年」切的都是「至今」区间** —— 月 = 当月 1 日至今（2026-04-01 ~ 04-21），年 = 1 月 1 日至今（2026-01-01 ~ 04-21），**不是完整自然周期**；②**返利简报的「本月 / 本年」两个指标不随上面的月/年切换变化**，是两套独立时间口径；③返利简报有**自己独立的品牌筛选**（底部橙色行），与延保数据卡的品牌筛选互不影响 —— 同一页面两个品牌筛选器，见 [REQ-WTY-031](#459-业务规则)。
> 免责声明「*享受延保奖励轮胎条数以最终实际发放为准」须保留，这是返利数字与实际到账可能不符的法律兜底。

**数据分析**：提供近 7 天、近 30 天的延保生效保单和理赔数量趋势；同时展示用户性别与年龄分布，用于门店经营分析。

![现状-延保 数据分析1](../mini-program-images/Warranty/数据分析1.png)

**页面内容** —— 「数据分析」页上半部分：时间范围胶囊 + 延保生效保单与理赔数量两张折线图（数据全为 0）。

**关键交互** —— ①切换「近7天 / 近30天」两个胶囊；②点折线上的数据点 → 弹出 tooltip 显示当日数值。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-029](#459-业务规则) 数据口径「截止到今日0点」

> **每张图表卡底部都标注「截止到 今日0点」，即数据是 T+1、不含当天。** 这是一条必须写进 PRD 的口径声明 —— 门店当天做的单子当天看不到，容易被当作 bug 反复提。与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)的实时性口径须一并裁决，见 [REQ-WTY-029](#459-业务规则)。
> 本图数据全为 0（折线呈水平直线），是空数据门店的样本。

![现状-延保 数据分析2](../mini-program-images/Warranty/数据分析2.png)

**页面内容** —— 「数据分析」页下半部分：用户性别信息与年龄分布信息两张图。

**关键交互** —— ①滚动查看；②图表本身在有数据时应支持点选查看数值。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-029](#459-业务规则) 数据口径、[REQ-WTY-030](#459-业务规则) 空数据兜底渲染

> **两处图表渲染缺陷**：①「用户性别信息」**只剩三条图例（男性 / 女性 / 未知），图形本体完全没渲染**；②「年龄分布信息」在数据全为 0 的情况下，六根柱子**仍然等高显示**且无数值标注 —— 会被误读为「各年龄段均匀分布」。见 [REQ-WTY-030](#459-业务规则)。
> 另：年龄分六档（17岁以下 / 18-24 / 25-29 / 30-39 / 40-49 / 50岁以上），须与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)的会员画像口径对齐；用户画像属消费者人口统计数据的聚合展示，其合规口径应在安全章节统一规定。

**返利中心**：展示品牌编码、经销商编码、本年返利总额、本月及本年延保轮胎奖励胎数，支持按品牌筛选。

![现状-延保 返利中心](../mini-program-images/Warranty/返利中心.png)

**页面内容** —— 「返利中心」页，一张指标卡 + 一行品牌筛选，卡内所有指标位均为空白。

**关键交互** —— ①点橙色「查看返利明细 >」→ 返利详情页；②点「筛选返利品牌 | 马牌轮胎 >」→ 品牌滚轮。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-030](#459-业务规则) 空数据兜底渲染

> **整张卡「有标签没有值」** —— 品牌编码、经销商编码、本年返利总额、本月 / 本年延保轮胎奖励数五个指标位全是空白，不是显示 0，而是彻底没有渲染。而工作台的返利简报在同样无数据时显示的是 `0`。**同一份数据在两个页面上的空态表现不一致**，见 [REQ-WTY-030](#459-业务规则)。

![现状-延保 返利中心-筛选品牌](../mini-program-images/Warranty/返利中心-筛选品牌.png)

**页面内容** —— 返利中心的品牌滚轮，**只有马牌轮胎与维京轮胎两项，没有「全部」**。

**关键交互** —— ①滚动选择品牌；②「取消 / 确定」。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-031](#459-业务规则) 品牌枚举统一

> **本模块第三处品牌枚举，且与前两处都不同** —— 保单筛选 3 项（含「全部」）、工作台筛选 3 项（含「全部」）、返利中心**只有 2 项且缺「全部」**，即返利数据无法一次看全品牌合计。加上 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的返利品牌里还出现过「卡迪睿德」，品牌枚举须作为主数据统一，见 [REQ-WTY-031](#459-业务规则)。

**返利明细与时间筛选**：可查看延保返利金额，并按起止日期筛选明细数据。

![现状-延保 返利详情](../mini-program-images/Warranty/返利详情.png)

**页面内容** —— 「返利详情」页，顶部是延保返利额汇总（0 元），下方明细列表为空。

**关键交互** —— ①点橙色「设置时间段 - 默认」→ 时间筛选弹层；②明细列表下拉加载。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-032](#459-业务规则) 返利明细的时间筛选改造

> 「设置时间段 - **默认**」这个文案含义不明 —— 「默认」是当前生效的时间段名称，还是按钮的一部分？结合下一张图（起止日期均为空）可判断**默认其实是「不限时间」**，但页面上完全看不出来。见 [REQ-WTY-032](#459-业务规则)。
> 另：顶部只有「延保返利额」一个汇总数，与返利中心的「本年返利总额」是否同一口径，本图无法确认。

![现状-延保 返利详细筛选日期](../mini-program-images/Warranty/返利详细筛选日期.png)

**页面内容** —— 「返利详情设置条件」弹层，仅开始 / 结束日期两项，均未填。

**关键交互** —— ①点「选择日期 >」→ 日期滚轮；②点橙色「确认筛选条件」应用；③「✕ 关闭」取消。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。

**需求关联** —— [REQ-WTY-032](#459-业务规则) 返利明细的时间筛选改造

> 三处体验问题：①**没有「清除条件」按钮**（保单筛选有）；②**没有快捷选项**（近 7 天 / 近 30 天），必须手动选两个日期，而同一个 App 内的数据分析页就是胶囊快捷选择；③起止日期默认为空即不限时间，与页面上的「默认」字样对不上。见 [REQ-WTY-032](#459-业务规则)。

> **延保返利与 O2O 返利是两套独立数据**（口径、维度、周期均不同）。整合后是否合并进统一的[返利中心](./11-RBT-返利中心.md#411-返利中心) —— `TODO(REQ-RBT-004)`。

> 延保经营数据与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)同理，存在口径合并问题 —— `TODO(REQ-PRF-004)`。

## 4.5.7 培训、操作指引与服务支持

**业务目标**：降低门店上手成本，减少因流程不熟导致的建单/理赔错误。

**内置教程中心**：提供零售店注册延保新流程、装车视频拍摄、延保理赔、售后鉴定、无用户信息鉴定、保单作废和延保客服等教程。

![现状-延保 教程](../mini-program-images/Warranty/教程.png)

**页面内容** —— 「使用教程」列表，7 条教程各占一张卡。

**关键交互** —— 点任一卡 `>` → 该教程的视频播放页。

**可用角色** —— 店长 ✅、技工 ✅（教程应全角色开放）。

**需求关联** —— [REQ-WTY-033](#459-业务规则) 教程与功能入口一一对应

> **7 条教程与正文所列完全一致** ✓：零售店注册延保新流程 / 拍摄装车视频 / 理赔操作(延保) / 理赔操作(售后鉴定) / 理赔操作(无用户信息鉴定) / 作废保单操作 / 延保客服操作。
> 但**教程口径与理赔功能的 tab 对不上**：教程有「理赔操作教程(无用户信息鉴定)」而理赔管理里没有该 tab；理赔管理有「CATI理赔」tab 却没有对应教程。见 [REQ-WTY-033](#459-业务规则)。
> 另：「作废保单操作教程」的存在说明作废是门店会常态使用的功能，更凸显 [REQ-WTY-016](#459-业务规则) 状态校验与审计的必要性。

**视频化教程承载**：教程详情以视频播放器形式呈现，支持播放进度与全屏查看。

![现状-延保 教程视频](../mini-program-images/Warranty/教程视频.png)

**页面内容** —— 教程视频播放页，播放区为全黑、进度条显示 00:00 / 00:00。

**关键交互** —— ①点播放区播放 / 暂停；②拖动进度条；③点右下图标全屏。

**可用角色** —— 店长 ✅、技工 ✅。

**需求关联** —— [REQ-WTY-034](#459-业务规则) 教程视频播放器能力

> **视频未加载**（总时长也是 00:00），无法确认是加载失败还是截图时机过早。播放器本身只有进度条与全屏两个控件 —— **没有独立的播放/暂停按钮、没有倍速、没有字幕、没有章节目录**，作为培训材料的承载偏弱，见 [REQ-WTY-034](#459-业务规则)。

**延保客服入口**：首页提供悬浮式延保客服入口，支持门店在建单、激活和理赔过程中寻求帮助（见 [2.7.4](../Continental-Retail-APP-PRD.md#274-延保门店端小程序)）。

**其他小程序入口**：延保小程序内亦挂有跳转其它小程序的入口，整合后取消（见 [现状入口 → App 导航映射](./02-HOM-APP首页与导航.md#422-现状导航与目标导航的差异)）。

![现状-延保 其他小程序入口](../mini-program-images/Warranty/其他小程序入口.png)

**页面内容** —— 延保首页底部升起的四宫格面板，用于跳转到其它四个小程序。

**关键交互** —— 点任一格 → 跳转对应小程序（订单平台 / O2O接单宝 / 积分兑换 / 零售管理）。

**可用角色** —— 店长 ✅；技工 ⚙️ 取决于各目标小程序自身的权限。

**需求关联** —— 整合后取消（见 [现状入口 → App 导航映射](./02-HOM-APP首页与导航.md#422-现状导航与目标导航的差异)）

> **这张图是整合价值最直接的实证**：四个入口分别对应本 PRD 要收编的四个现状系统 —— 订单平台（[4.6 采购](./06-PUR-采购.md#46-采购)）、O2O接单宝（[4.3 销售](./03-SAL-销售.md#43-销售)）、积分兑换（[4.14 福利兑换](./14-MSP-福利兑换.md#414-福利兑换msip)）、零售管理（[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)）。门店现状要在五个小程序之间靠这个面板来回跳，正是[痛点 2.1 多小程序分散](../Continental-Retail-APP-PRD.md#21-多小程序分散)的写照。
> 注意面板里**没有 F6** —— F6 不是小程序，走的是 H5，这也解释了为什么 F6 只能以 Embedded H5 方式整合。

## 4.5.8 需求描述汇总

**业务目标** —— 见各子节

**目标角色** —— 店长：全部功能；技工：建单、待办处理、保单查询、理赔受理（`TODO(REQ-WTY-003)` 需确认）

**入口** —— 底部导航「延保」tab；销售结算页跳转（[4.3.7](./03-SAL-销售.md#437-结算与延保跳转)）；首页待办「延保视频上传提醒」

> **V1.1 补充**：延保实际有**三条入口**，除上述两条外，销售模块的接车页底部还有一个「延保」按钮，且 O2O 已完成订单卡上有「查看延保」。参数契约须统一覆盖，见 [REQ-SAL-011](./03-SAL-销售.md#439-业务规则)。

**前置条件** —— 已登录、已确定门店；门店已开通延保业务

**主流程**：

- 建单：扫描/录入车牌 → 绑定车辆 → 上传装车视频 → **门店激活** → **消费者确认** → 保单生效
- 理赔：扫描理赔码/预约码 → 受理 → 采集证据 → 上报 → 跟踪结果

**异常流程**：

- 车牌识别失败 → 手动输入 / 特殊车牌录入
- 扫码不可用 → 手动输入预约码
- 无关联保单 → 走无用户信息鉴定通道（仅鉴定不理赔）
- 上传失败 → 本地暂存并重试

**权限规则** —— 保单作废、返利查看建议限店长 —— `TODO(REQ-WTY-005)`、`TODO(REQ-WTY-004)`

**访问链路** —— App → App Backend → 延保后台

**逻辑数据来源** —— 延保后台（保单、预约、理赔、鉴定、返利、教程）

**回写目标** —— 建单、装车视频、理赔申请、鉴定资料、条款同意记录 → 延保后台

**状态变化**：

- 保单：待补充 → 待确认 → 正常（生效中）→ **已过有效期** → 已作废（[REQ-WTY-011](#459-业务规则) 补入「已过有效期」）
- 延保生效：门店激活成功 → **用户未确认** → 用户已确认（计入「延保成功」）（[REQ-WTY-018](#459-业务规则)）
- 预约：预约车检 → 已受理 → 已上报
- 延保理赔 / CATI 理赔：正在进行 → 已完成
- 鉴定单：待上传 → 正在进行 → 已完成

## 4.5.9 业务规则

**REQ-WTY-001 双保障并行** —— 原厂质保与撞击延保互不替代；制造缺陷走原厂质保，外力撞击走延保换新

**REQ-WTY-002 待办归并** —— ~~延保待办与首页待办的归并方式待定~~ **V1.1 收窄**：延保内部本就有两套待办，处置方式见 [REQ-WTY-028](#459-业务规则)；**仅「归并后的计数口径与刷新时机」仍待定** `TODO(REQ-WTY-002)`

**REQ-WTY-003 技工权限范围** —— 技工可执行的延保操作范围待定 `TODO(REQ-WTY-003)`

**REQ-WTY-004 返利可见性** —— 延保返利对技工是否可见待定 `TODO(REQ-WTY-004)`

**REQ-WTY-005 保单作废** —— 高风险操作，需权限 + 状态校验 + 审计记录；状态校验与原因留痕的具体要求见 [REQ-WTY-016](#459-业务规则)，**权限归属与是否需后台审批仍待定** `TODO(REQ-WTY-005)`

**REQ-WTY-006 CATI 归属** —— ~~延保与 O2O 两处 CATI 入口的关系待定~~ **V1.1 关闭**：两处不是同一业务，结论见 [REQ-WTY-023](#459-业务规则)

**REQ-WTY-007 无用户信息鉴定** —— 仅做故障鉴定，**不可走延保理赔**；必采字段见 [4.5.5](#455-售后鉴定与证据采集)

**REQ-WTY-008 消费者未认证兼容** —— 该状态不影响延保返利及管理端查询；消费者后续扫码可找回保单。新老系统切换点为 **2020-08-24 07:00**，找回方式为在新系统扫描驾驶证 + 行驶证两证

**REQ-WTY-009 保单筛选** —— 支持激活起止日期 + 品牌（全部 / 马牌 / 维京）

**REQ-WTY-010 条款同意留痕** —— 记录条款版本与同意时间；完整字段要求见 [REQ-WTY-035](#459-业务规则)

> 以下 `REQ-WTY-011` ~ `REQ-WTY-038` 为 V1.1 逐图核对现状后补写。

**REQ-WTY-011 保单状态机补全** —— 保单状态为 **待补充 / 待确认 / 正常（生效中）/ 已过有效期 / 已作废** 五态。原文缺「已过有效期」，而现状详情页确实会显示该状态。列表 tab 的分组与详情页的状态取值须使用同一套枚举

**REQ-WTY-012 保单号与轮胎条码的命名统一** —— 三个概念须严格区分：**轮胎条码**（如 8507302611，商品条码）、**保单子代码**（15 位，如 173147928125203，保单主键）、**轮胎描述**（规格串，如 `215/55R17 94W FR UC7 #`）。列表卡的主标题现状展示的是**轮胎条码**，不得标注为「保单号 / POLICY NO.」；需要展示保单号时使用保单子代码

**REQ-WTY-013 一车四胎、一胎多保障** —— 保单数据是三层结构：**车牌 → 轮胎（各一条条码）→ 保障类型（各一个保单子代码）**。同一车牌下通常有 4 条轮胎记录，同一条轮胎下可有「鼓包保障」「爆胎保障」两个子代码。列表须按此三层组织，不得把同一车牌的多条胎并排展示为多张「相同保单号」的卡片

**REQ-WTY-014 保障类型枚举** —— 固定为 **鼓包保障 / 爆胎保障 / 延保服务** 三种。设计稿中的「**数包保障**」是「鼓包保障」的错别字，须修正

**REQ-WTY-015 操作人与投保人身份** —— ①**安装店员必须记录 App 登录员工的真实身份（工号 + 姓名）**，现状显示「微信用户」使审计留痕形同虚设，也架空了 [REQ-WTY-005](#459-业务规则) 的作废审计要求；②投保人为消费者，未实名时显示「未实名消费者」而非「微信用户」；③条款同意留痕同样须带操作人

**REQ-WTY-016 保单作废的状态校验与留痕** —— ①**已过有效期、已作废的保单，「作废保单」按钮置灰不可点**；②作废须二次确认，并**必填作废原因**（枚举 + 「其它」自由填写）；③作废记录操作人（依赖 [REQ-WTY-015](#459-业务规则)）、时间、原因；④作废不可撤销，二次确认文案须明示

**REQ-WTY-017 保单流水的排序与事件枚举** —— 流水按**业务发生时间正序**展示（现状排序无规律）；事件枚举至少含 **新胎激活 / 鼓包保障 / 爆胎保障 / 用户核保**；门店端事件带门店信息，消费者端事件（如用户核保）不带；每条流水可点进详情

**REQ-WTY-018 延保生效为两段式** —— 延保生效需两步：**门店激活成功 → 消费者确认**。只有两步都完成才计入「延保成功轮胎数」。门店端须明确区分「已激活待确认」与「已生效」两种状态，不得只显示「激活成功」使门店误以为已完成。**消费者未确认时的催办方式（是否推送消费者、门店能否主动催办）未定** —— `TODO(REQ-WTY-018)`

**REQ-WTY-019 O2O「查看延保」页的状态收敛** —— 该页现状同时展示三组互相矛盾的状态（卡片标题「暂无延保信息」/ 卡内「激活成功 + 用户未确认」/ 汇总「延保成功轮胎数 0」）。App 侧须收敛为**单一状态源**：每条轮胎只展示一个明确状态，汇总数由明细聚合得出，两者不得不一致

**REQ-WTY-020 理赔与预约的入口收敛** —— 现状同一批案件至少有三个查看路径（理赔管理三 tab / 全部预约两 tab / 理赔处理两入口），且「全部预约 > 提交的理赔信息」与「理赔管理 > 延保理赔」页面结构完全相同。App 侧收敛为**一个理赔工作台**：按案件类型（延保理赔 / 售后鉴定 / CATI理赔）分 tab，预约作为案件的前置阶段并入同一列表，不再单设「全部预约」页

**REQ-WTY-021 临近预约提醒并入待办** —— 现状理赔管理页顶部的「临近预约（未来 3 天内的预约）」是一条门店需要提前备料备人的主动提醒，须并入 App 首页跨系统待办（与延保视频上传提醒并列），提前天数阈值后台可配置

**REQ-WTY-022 三类案件的状态机各不相同** —— **延保理赔 / CATI理赔为两态**（正在进行 / 已完成），**售后鉴定为三态**（待上传 / 正在进行 / 已完成），**预约为三态**（预约车检 / 已受理 / 已上报）。App 不强行统一为一套状态，按案件类型各自保留，但每个 tab 上须显示待处理计数

**REQ-WTY-023 CATI 的两个面** —— **O2O 侧的 CATI 是门店资质的开通 / 关闭开关，归 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)；延保侧的 CATI 是理赔案件的跟踪列表，归本模块。** 二者不是重复功能，而是同一项资质的两个面。**未开通 CATI 资质的门店，延保侧的「CATI理赔」tab 隐藏。**（关闭原 `TODO(REQ-WTY-006)`）

**REQ-WTY-024 CATI 说明文案与高危开关** —— ①O2O 侧 CATI 页的说明文案现状为脏数据（同段重复 4 遍 + 测试串），须由业务重新提供一版；②「关闭服务」会使门店失去 CATI 资质并影响理赔受理能力，须**二次确认并说明影响范围**

**REQ-WTY-025 脱敏格式统一** —— 手机号统一按 `138****7616`（前三 + 四星 + 后四）脱敏，现状预约详情用的 `*******3963` 须改；**消费者姓名（申请人 / 投保人 / 车主）同样须脱敏**。本条与 [4.3 销售](./03-SAL-销售.md#439-业务规则)、[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)是同一问题，建议在安全章节统一规定

**REQ-WTY-026 鉴定资料的必填项与张数上限** —— 必填照片四类，张数上限各不相同：**DOT 照片 ≤1 张 / 胎侧整体照片（上限待向延保后台确认）/ 胎面照片 ≤1 张 / 故障部位内外部照片 ≤3 张**；补充视频为唯一选填项。每类上传区须配拍照示范缩略图（现状已有，须保留）

**REQ-WTY-027 必填标识与提交校验规范** —— 必填一律以 `*` 标识，**占位文字统一为同一灰色**，不得用红 / 灰区分控件类型（现状用红色表示下拉选择、灰色表示文本输入，易被误读为「红的才必填」）；提交时若有未填项，统一高亮并自动滚动定位到第一个未填项

**REQ-WTY-028 延保内两套待办的归并** —— 延保小程序内部现有两套待办：首页的「待绑定车辆 / 待补充装车视频」计数卡（含独立列表页）与底部 tab「待办事项」。整合后：**延保内不再保留独立待办 tab**，全部并入 App 首页待办；首页的两个计数卡保留为延保页内的快捷筛选入口

**REQ-WTY-029 数据口径「截止到今日 0 点」** —— 延保经营数据为 **T+1、不含当天**，图表上须保留该口径声明。与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)的实时性口径一并裁决（`TODO(REQ-PRF-004)`）

**REQ-WTY-030 空数据的兜底渲染** —— ①指标位无数据时显示 `0` 或 `—`，**不得出现「有标签无数值」**（现状返利中心整卡空白）；②图表无数据时显示统一空态插画，**不得只剩图例**（现状用户性别图）或**全 0 却等高**（现状年龄分布图）；③全模块空态文案统一（现状有「暂无数据」「没有更多了」「暂无预约记录」三种写法）

**REQ-WTY-031 品牌枚举统一** —— 品牌为主数据，全 App 使用同一套枚举与展示名，**筛选器一律包含「全部」**。现状本模块内有三种写法（保单筛选 3 项 / 工作台缩写「马 维」/ 返利中心 2 项缺「全部」）。**延保品牌是否包含卡迪睿德（[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的返利品牌中出现过）未定** —— `TODO(REQ-WTY-031)`

**REQ-WTY-032 返利明细的时间筛选** —— 改为「近 7 天 / 近 30 天 / 自定义」三档快捷选择，**默认近 30 天**（现状默认为不限，且页面上写作含义不明的「默认」），并提供「重置」按钮

**REQ-WTY-033 教程与功能入口一一对应** —— 教程清单须与实际功能入口对应：现状「无用户信息鉴定」有教程无 tab、「CATI理赔」有 tab 无教程。同时教程支持**从对应功能页直接唤起**（上下文帮助），而不是只能从工作台进教程列表逐个找

**REQ-WTY-034 教程视频播放器能力** —— 须支持 播放/暂停、进度拖拽、**倍速（0.75/1/1.25/1.5/2）**、全屏、加载失败重试；弱网下允许降码率播放。现状播放器只有进度条与全屏

**REQ-WTY-035 条款的两页式与留痕字段** —— 条款分「使用条款」+「违规处理」两页，**须两页均阅读完毕才可同意**；留痕记录 **条款版本号 + 同意时间 + 操作人**（现状只有时间）。（补充 [REQ-WTY-010](#459-业务规则)）

**REQ-WTY-036 保单协议的 PDF 预览** —— 保单协议以 PDF 文件形式提供，App 须具备原生 PDF 预览能力（缩放、分页、保存），并**保留文档页脚的 Continental 密级标识**，不得裁剪

**REQ-WTY-037 车牌录入的两种模式** —— ①**普通模式用车牌格子**（逐位输入、支持「新能源」切换 7/8 位），**特殊模式用自由文本输入框**（不做位数校验），两者为**同页切换控件**，不是页面跳转（设计稿画成外链跳转须修正）；②车牌识别为**拍照上传识别**，与 [REQ-SAL-002](./03-SAL-销售.md#439-业务规则) 复用同一套 OCR 能力；③取景提示文案须与实际框色一致（现状文案写「黄色」、框是橙色）；④「手动输入车牌」改用中性 / 次要按钮样式，**红色仅保留给危险操作**

**REQ-WTY-038 统一选择器** —— 日期与品牌等选择控件由 App 自研并随主题配色，替代现状的微信原生 picker（白底 + 绿色按钮压在深色页面上，本模块 4 处出现）

## 4.5.10 验收标准

1. 门店未开通延保业务时，延保 tab 不显示；
2. 车牌识别失败可切换手动输入与特殊车牌录入，已录入内容不丢失；
3. 「待绑定车辆」「待补充装车视频」计数与待办列表条数一致，且与首页对应待办项一致；
4. 无关联保单的轮胎进入无用户信息鉴定通道后，界面不提供任何理赔提交入口；
5. 弱网下上传鉴定照片/视频中断后，重新进入可从本地暂存恢复，不需要重新拍摄；
6. 保单作废后，该保单在所有列表与筛选结果中状态一致，且留有操作人与时间的审计记录；
7. 保单列表卡的主标题字段名为「轮胎条码」，详情页的「保单号」为 15 位保单子代码，两处不混用（[REQ-WTY-012](#459-业务规则)）；
8. 同一车牌下的 4 条轮胎在列表中展示为 4 条不同条码的记录，不出现「相同保单号」的重复卡片（[REQ-WTY-013](#459-业务规则)）；
9. 已过有效期的保单，其「作废保单」按钮为置灰不可点状态（[REQ-WTY-016](#459-业务规则)）；
10. 作废保单时必须选择作废原因并二次确认，作废记录中可查到操作人的真实工号与姓名（[REQ-WTY-015](#459-业务规则)、[REQ-WTY-016](#459-业务规则)）；
11. 门店激活成功但消费者未确认的轮胎，在门店端显示为「待消费者确认」，且不计入「延保成功轮胎数」（[REQ-WTY-018](#459-业务规则)）；
12. 「查看延保」页中每条轮胎只显示一个状态，汇总数与明细条数一致（[REQ-WTY-019](#459-业务规则)）；
13. 未开通 CATI 资质的门店，延保侧不显示「CATI理赔」tab（[REQ-WTY-023](#459-业务规则)）；
14. 预约详情中的消费者手机号按 `138****7616` 格式脱敏，姓名同样脱敏（[REQ-WTY-025](#459-业务规则)）；
15. 无用户信息鉴定表单在有未填必填项时点击「确认保存」，页面自动滚动到第一个未填项并高亮（[REQ-WTY-027](#459-业务规则)）；
16. 无数据门店进入返利中心与数据分析页时，所有指标位显示 `0` 或 `—`，图表显示统一空态插画，不出现空白标签或等高柱（[REQ-WTY-030](#459-业务规则)）；
17. 保单筛选、工作台、返利中心三处的品牌下拉，选项完全一致且均含「全部」（[REQ-WTY-031](#459-业务规则)）；
18. 教程视频支持倍速播放，加载失败时给出重试入口（[REQ-WTY-034](#459-业务规则)）。

---

## 附：本模块归拢信息（来自主文件其它章节）

### 附-1 业务数据字典（主文件 A.6）

| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 延保服务信息集 | Mini Program Backend | HTTPS | 保存到延保后台 |
| 2 | 延保出库 | Mini Program Backend | HTTPS | |
| 3 | 延保注册数据集 | User Input | HTTPS | 保存到延保后台 |
| 4 | 保单 / 预约 / 理赔 / 鉴定 / 返利 / 教程 | Mini Program Backend | HTTPS | 延保后台 |

**本次拆分对 A.6 的三点修订建议**（回灌主文件时一并处理）：

1. **第 4 条过于笼统** —— 一行囊括六类业务数据，无法据此设计接口。建议至少拆为：保单结果集 / 保单详情（含保单子代码、轮胎条码、安装信息、系统流水）、预约结果集 / 预约详情、理赔案件结果集（三类案件）、鉴定单与鉴定资料（含照片视频，走对象存储）、返利汇总与明细、教程清单与视频。
2. **缺「延保生效确认」数据** —— [REQ-WTY-018](#459-业务规则) 明确延保生效是两段式（门店激活 + 消费者确认），但附录 A 没有承载「消费者确认状态」的数据集。须补。
3. **鉴定照片与教程视频须区分存储通道** —— 二者都是大文件但性质不同：鉴定照片是门店上传的证据（写入，需断点续传与本地暂存），教程视频是平台下发的素材（读取，需 CDN 与降码率）。A.6 现在都归在「Mini Program Backend」下，须分开说明。

### 附-2 权限矩阵（主文件附录 B 本模块分行）

**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认

| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **延保** | 建单（扫车牌/绑定车辆/装车视频） | ✅ | ❓ | `TODO(REQ-WTY-003)` |
| | 保单查询 | ✅ | ❓ | 同上 |
| | **保单作废** | 🔸 | ✗ | 高风险，需二次确认 + 审计 `TODO(REQ-WTY-005)` |
| | 理赔受理 / 售后鉴定 | ✅ | ❓ | `TODO(REQ-WTY-003)` |
| | 延保返利 | ✅ | ❓ | `TODO(REQ-WTY-004)` |

**本次拆分建议新增的三行**（回灌主文件时一并处理）：

| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **延保** | 鉴定资料采集（拍照 / 录像 / 提交） | ✅ | ⚙️ | 现场作业，实际以技工为主，建议默认授予（[REQ-WTY-026](#459-业务规则)） |
| | 经营数据 / 用户画像查看 | ✅ | ❓ | 含消费者性别年龄聚合，口径同 `TODO(REQ-WTY-004)` |
| | 使用教程 | ✅ | ✅ | 培训材料，全角色开放（[REQ-WTY-033](#459-业务规则)） |

另需明确：**「保单作废」一行的 🔸 受限需要落到实处** —— 现状既无状态校验也无二次确认，且操作人记录为「微信用户」。在 [REQ-WTY-015](#459-业务规则) 落地前，该行的审计要求无法满足。

### 附-3 待确认项（主文件 10.2.5）

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-WTY-002 | ~~延保待办与首页待办的归并方式~~ **收窄为：归并后的计数口径与刷新时机**（归并方式已由 [REQ-WTY-028](#459-业务规则) 明确） | 产品 |
| REQ-WTY-003 | 技工可执行的延保操作范围 | 产品 |
| REQ-WTY-004 | 延保返利对技工是否可见 | 产品 |
| REQ-WTY-005 | ~~保单作废的权限、二次确认、作废原因、是否需后台审批~~ **收窄为：权限归属与是否需后台审批**（状态校验、二次确认、作废原因已由 [REQ-WTY-016](#459-业务规则) 明确） | 业务 / 安全 |
| ~~REQ-WTY-006~~ | ~~延保与 O2O 两处 CATI 入口的关系与归属~~ —— **本次拆分关闭**，结论见 [REQ-WTY-023](#459-业务规则) | — |

**本次拆分新增 2 条**（回灌主文件时并入 10.2.5）：

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-WTY-018 | 消费者未确认延保时的催办方式（是否推送消费者、门店能否主动催办） | 业务 |
| REQ-WTY-031 | 延保品牌枚举是否包含卡迪睿德 | 业务 / 主数据 |

合计 6 条待确认（原 5 条中关闭 1 条、收窄 2 条，新增 2 条）。

### 附-4 配图清单（主文件附录 C 4.5 节，43 张）

| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 现状-延保 保单协议 | `mini-program-images/Warranty/保单协议.png` |
| 2 | 现状-延保 德国马牌零售商延保使用条款须知 | `mini-program-images/Warranty/德国马牌零售商延保使用条款须知.png` |
| 3 | 设计稿-延保服务（App 目标形态，与现状延保首页 2.7.4 一一对应） | `app-design-images/延保服务.png` |
| 4 | 现状-延保 扫描车牌 | `mini-program-images/Warranty/扫描车牌.png` |
| 5 | 现状-延保 特殊车牌输入 | `mini-program-images/Warranty/特殊车牌输入.png` |
| 6 | 现状-延保 待绑定车辆 | `mini-program-images/Warranty/待绑定车辆.png` |
| 7 | 现状-延保 待补充装车视频 | `mini-program-images/Warranty/待补充装车视频.png` |
| 8 | 现状-延保 待办事项 | `mini-program-images/Warranty/待办事项.png` |
| 9 | 现状-延保 首页切换店铺 | `mini-program-images/Warranty/首页切换店铺.png` |
| 10 | 现状-延保 工作台选择店铺 | `mini-program-images/Warranty/工作台-选择店铺.png` |
| 11 | 设计稿-保单管理 | `app-design-images/保单管理.png` |
| 12 | 现状-延保 所有保单 | `mini-program-images/Warranty/所有保单.png` |
| 13 | 现状-延保 保单子代码详情 | `mini-program-images/Warranty/保单子代码详情.png` |
| 14 | 现状-延保 保单详情（保单与活动信息） | `mini-program-images/Warranty/保单详情-保单与活动信息.png` |
| 15 | 现状-延保 保单详情（延保信息） | `mini-program-images/Warranty/保单详情-延保信息.png` |
| 16 | 现状-延保 保单筛选 | `mini-program-images/Warranty/保单筛选.png` |
| 17 | 现状-延保 保单筛选（日期） | `mini-program-images/Warranty/保单筛选日期.png` |
| 18 | 现状-延保 保单筛选（品牌） | `mini-program-images/Warranty/保单筛选品牌.png` |
| 19 | 现状-O2O 查看延保 | `mini-program-images/O2O/查看延保.png` |
| 20 | 现状-延保 全部预约（预约信息 1） | `mini-program-images/Warranty/全部预约-预约信息1.png` |
| 21 | 现状-延保 全部预约（预约信息 2） | `mini-program-images/Warranty/全部预约-预约信息2.png` |
| 22 | 现状-延保 全部预约（预约信息详情） | `mini-program-images/Warranty/全部预约-预约信息详情.png` |
| 23 | 现状-延保 理赔（延保理赔） | `mini-program-images/Warranty/理赔-延保理赔.png` |
| 24 | 现状-延保 理赔处理 | `mini-program-images/Warranty/理赔处理.png` |
| 25 | 现状-延保 手动输入预约码 | `mini-program-images/Warranty/手动输入预约码.png` |
| 26 | 现状-延保 全部预约（提交的理赔信息） | `mini-program-images/Warranty/全部预约-提交的理赔信息.png` |
| 27 | 现状-延保 理赔（CATI 理赔） | `mini-program-images/Warranty/理赔-CATI理赔.png` |
| 28 | 现状-O2O 认证轮胎技术检测中心（CATI） | `mini-program-images/O2O/认证轮胎技术检测中心CATI.png` |
| 29 | 现状-延保 售后鉴定 | `mini-program-images/Warranty/售后鉴定.png` |
| 30 | 现状-延保 理赔（售后鉴定） | `mini-program-images/Warranty/理赔-售后鉴定.png` |
| 31 | 现状-延保 无用户信息鉴定通道（1） | `mini-program-images/Warranty/无用户信息鉴定通道1.png` |
| 32 | 现状-延保 无用户信息鉴定通道（2） | `mini-program-images/Warranty/无用户信息鉴定通道2.png` |
| 33 | 现状-延保 工作台（筛选品牌） | `mini-program-images/Warranty/工作台-筛选品牌.png` |
| 34 | 现状-延保 工作台（年） | `mini-program-images/Warranty/工作台-年.png` |
| 35 | 现状-延保 数据分析（1） | `mini-program-images/Warranty/数据分析1.png` |
| 36 | 现状-延保 数据分析（2） | `mini-program-images/Warranty/数据分析2.png` |
| 37 | 现状-延保 返利中心 | `mini-program-images/Warranty/返利中心.png` |
| 38 | 现状-延保 返利中心（筛选品牌） | `mini-program-images/Warranty/返利中心-筛选品牌.png` |
| 39 | 现状-延保 返利详情 | `mini-program-images/Warranty/返利详情.png` |
| 40 | 现状-延保 返利详细（筛选日期） | `mini-program-images/Warranty/返利详细筛选日期.png` |
| 41 | 现状-延保 教程 | `mini-program-images/Warranty/教程.png` |
| 42 | 现状-延保 教程视频 | `mini-program-images/Warranty/教程视频.png` |
| 43 | 现状-延保 其他小程序入口（整合后取消） | `mini-program-images/Warranty/其他小程序入口.png` |

**看图后对本清单的补充说明**：

- **第 6、7 两行指向的两个文件内容完全相同** —— 均为「待绑定车辆」tab 的空态截图（同一时刻、同一电量）。**「待补充装车视频」tab 至今没有任何佐证**，而它恰是首页待办里唯一被列入 App 跨系统待办的延保事项。**建议优先补拍。**
- **第 5 行「特殊车牌输入」实际拍的是延保小程序首页**（处于特殊车牌模式），说明文字应改为「现状-延保 首页（特殊车牌录入模式）」。
- **第 28 行的 O2O CATI 页不是理赔页，而是门店资质开通页**（底部按钮「关闭服务」），说明文字应补上这一点 —— 这正是 [REQ-WTY-023](#459-业务规则) 的依据。
- **测试与脏数据分布**：第 4 张取景框内拍的是笔记本键盘；第 19 张门店名「智慧园杀虫轮胎店」；第 28 张说明文案重复 4 遍并含测试串「xxx特热爱111…」。
- **数据全为 0 的门店样本**：第 6–10、20–27、29–30、33–40 张均为空态或全 0，因此**有数据时的卡片形态、图表形态、列表字段大多无法确认**。
- **无法确认的四处**：第 5 张底部 tab 中间的橙色圆形图标无文字标签，功能不明；第 22 张的「订单图片 / 订单确认图片」两栏为空，展示形式不明；第 32 张「胎侧整体照片」的张数上限被返回胶囊遮挡；第 33 张「筛选结果」标签下无数值。
- 建议**补拍 5 张**：「待补充装车视频」tab 的实际内容、有数据的保单列表（能看到状态标识）、已受理状态的预约卡片、有案件的理赔列表（三类各一）、教程视频加载成功后的播放器。补拍后附录 C 的 4.5 节计数由 43 → 48，须同步更新文档头部规模声明与本文件头部信息表。

### 附-5 本次拆分新增发现

1. **保单的数据结构与正文表述不符，这是本模块最重要的一处更正** —— 列表卡上的 `8507302611` 不是保单号而是**轮胎条码**，真正的保单号是 15 位的「保单子代码」。数据是**车牌 → 轮胎 → 保障类型**三层：一车四胎、一胎可有鼓包与爆胎两个子代码。设计稿把它标成 `POLICY NO.` 并画出三张「同号不同状态」的卡片，是对业务的误解。见 [REQ-WTY-012](#459-业务规则)、[REQ-WTY-013](#459-业务规则)。
2. **延保生效是两段式的，正文完全没写** —— O2O「查看延保」页同时显示「激活成功」与「用户未确认」，且「订单轮胎数 4 / 延保成功轮胎数 0」。**门店激活之后还需要消费者确认才算生效**。这条规则直接决定门店端的状态展示与催办设计，见 [REQ-WTY-018](#459-业务规则)。
3. **保单状态机缺一态** —— 现状会显示「延保已过有效期」，而正文声明的状态机只有「待补充 → 待确认 → 正常 → 已作废」。见 [REQ-WTY-011](#459-业务规则)。
4. **审计留痕现状是空的** —— 「安装店员」和「投保人」都显示「微信用户」，拿不到真实身份。这不是显示问题，而是**使 [REQ-WTY-005](#459-业务规则) 的作废审计要求形同虚设** —— 作废了保单也不知道是谁作废的。见 [REQ-WTY-015](#459-业务规则)。
5. **作废保单现状没有任何防护** —— 已过有效期的保单，红色「作废保单」按钮仍常驻底部且可点，没看到状态校验，也没有二次确认与作废原因。正文要求的「权限 + 状态校验 + 审计记录」三样现状全缺。见 [REQ-WTY-016](#459-业务规则)。
6. **`TODO(REQ-WTY-006)` 可以关闭** —— O2O 侧的 CATI 页底部按钮是「**关闭服务**」，说明那是**门店资质开关**（归门店管理）；延保侧的 CATI 是**理赔案件跟踪**（归延保）。两处不是重复功能，而是同一资质的两个面。见 [REQ-WTY-023](#459-业务规则)。
7. **`TODO(REQ-WTY-002)` 比原文描述的更复杂** —— 要归并的不是「延保待办 vs 首页待办」两套，而是三套：延保首页的两个计数卡（有独立列表页）、延保底部 tab 的「待办事项」（另一个独立页）、App 首页待办。见 [REQ-WTY-028](#459-业务规则)。
8. **发现一条正文完全没记的主动提醒机制** —— 理赔管理页顶部有「临近预约（未来 3 天内的预约）」卡。门店需要在预约日前备料备人，这与 [4.4 提醒](./04-RMD-提醒.md#44-提醒)和首页待办是同一类东西，应并入跨系统待办。见 [REQ-WTY-021](#459-业务规则)。
9. **理赔与预约的入口严重冗余** —— 同一批案件至少有三个查看路径，其中「全部预约 > 提交的理赔信息」与「理赔管理 > 延保理赔」的页面结构完全相同。且「理赔处理」与「理赔管理」是两个不同页面却几乎同名。见 [REQ-WTY-020](#459-业务规则)。
10. **三类案件的状态机不同，不能强行统一** —— 延保理赔 / CATI理赔两态，售后鉴定三态（多「待上传」），预约三态（预约车检 / 已受理 / 已上报）。正文 4.5.5 写的三态**只适用于售后鉴定**。见 [REQ-WTY-022](#459-业务规则)。
11. **品牌枚举在本模块内就有三种写法** —— 保单筛选 3 项（含全部）、工作台缩写「马 / 维」、返利中心 2 项（缺全部）；加上 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)出现过的「卡迪睿德」，品牌须作为主数据统一。见 [REQ-WTY-031](#459-业务规则)。
12. **空数据的兜底渲染有三类缺陷** —— 返利中心整卡「有标签无数值」、用户性别图只剩图例、年龄分布图全 0 却六柱等高。空态文案也有三种写法（暂无数据 / 没有更多了 / 暂无预约记录）。见 [REQ-WTY-030](#459-业务规则)。
13. **数据口径是 T+1** —— 三张图表都标「截止到 今日0点」。这条必须写进 PRD，否则门店会把「今天的单看不到」当作缺陷反复提。见 [REQ-WTY-029](#459-业务规则)。
14. **脱敏格式与 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心) 不一致** —— 此处是 `*******3963`（7 星 + 后四），我的模块是 `138****7616`（前三 + 四星 + 后四），且消费者姓名完全未脱敏。这是本次拆分在 [4.3 销售](./03-SAL-销售.md#439-业务规则)、[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)之后**第四次**遇到同一类问题，**强烈建议在第 5 章或安全章节统一规定一次**。
15. **教程口径与功能入口对不上** —— 教程有「无用户信息鉴定」但理赔管理无该 tab；理赔管理有「CATI理赔」tab 但无对应教程。见 [REQ-WTY-033](#459-业务规则)。
16. **微信原生 picker 是小程序无法回避的主题断裂** —— 深色页面上弹出白底 + 绿色确定按钮的滚轮，本模块 4 处出现。这条是「为什么要做原生 App」的一个具体论据。见 [REQ-WTY-038](#459-业务规则)。
17. **「其他小程序入口」是整合价值最直接的实证** —— 四宫格面板（订单平台 / O2O接单宝 / 积分兑换 / 零售管理）正好对应本 PRD 要收编的四个现状系统，门店现状要在五个小程序间来回跳。**建议把这张图同时引用到第 2 章痛点部分**（现状仅在 4.5 出现一次）。
18. **[REQ-WTY-010](#459-业务规则) 条款留痕在现状已实现**（页面顶部展示「本账户于 2026.03.18 14:57 同意本条款」），但缺条款版本号与操作人，且条款实为两页。见 [REQ-WTY-035](#459-业务规则)。