conti-docs/prd/Continental-Retail-APP-PRD.md

Continental Retail APP 产品需求文档（PRD）

项目	内容
文档名称	Continental Retail APP 产品需求文档
文档版本	V1.0
编制时间	2026 年 08 月
文档状态	评审中
编制依据	零售 APP 方案 PPT、Workshop、研讨会议记录；现状小程序实测截图；APP 视觉设计稿
适用产品	移动端 Retail APP（Android / iOS）、Web 端后台管理控制台
主技术路线	Flutter（详见《App 工程结构与分包架构文档》）
后端技术栈	Kotlin 2.4 + Spring Boot 4.1 + Java 21 + MySQL 8.4 + Azure

修订历史

版本	日期	修订人	修订说明
V0.9	2026-07	业务侧	初版需求分析文档
V1.0	2026-08	—	完整版产品需求文档

本文档规模：19 个模块、195 条编号需求（其中 97 条待业务确认）、173 张图、42 张表。需求描述与编号需求均以文本书写，表格只用于字段清单、矩阵与统计。全部图片引用与章节内链已校验通过。

---

1 引言

1.1 文档目的

本文档为马牌统一零售 Retail APP 完整需求分析文档，用于明确业务现状、全部用户诉求、功能 / 非功能、集成、接口类需求；作为产品设计、开发、测试、验收、项目交付的唯一基准文件，供业务、IT、开发、测试、门店经销商评审使用。

凡本文档中标注「现状实测」的内容，来源为小程序真机截图；标注「设计稿」的内容，来源为 APP 视觉设计稿；两者均为需求佐证，不等同于已确认的需求结论——需要业务确认的部分统一以 TODO(REQ-xxx-nnn) 标记，并汇总于第 10 章。

1.2 项目背景

当前全国马牌线下门店运营依赖 6 套以上独立微信小程序：ROOS 采购、O2O 接单宝、延保小程序、马上下单门店管理、RMS 车型匹配、MSIP 福利兑换，另有第三方 F6 汽修系统。各系统账号独立、数据孤岛、流程割裂，门店店长 / 技工需要反复切换登录、手工同步库存 / 订单 / 财务数据，经营数据无法统一查看，门店数字化管理效率极低。

现计划建设一套统一移动端 Retail APP，整合全部小程序能力，打通集团 ERP 与 F6 汽修系统，实现门店全业务一站式数字化管理。

1.3 项目目标

• 统一账号体系，一套账号通行全部业务系统，分级管控门店人员权限；
• 打通集团 ERP，采购、销售、库存、财务数据自动双向同步，消除手工录入；
• 整合采购、销售、施工、延保、财务、数据分析全业务流程；
• 扩充多支付渠道，优化对账、返利、员工业绩核算流程；
• 首页聚合营销活动、待办、风险预警，提升门店转化与风险管控能力；
• 采用 Azure 云原生架构，支撑全国数千门店大规模并发，支持业务长期扩展。

1.4 终端用户

本 APP 的终端用户为马牌轮胎门店店长、技工两类角色。

本文档的角色模型仅包含这两类。更细粒度的角色（如财务专员、区域经理、总部运营）为后续扩展方向，不在首版范围内，见 C6。

1.5 文档适用范围

• 适用产品：移动端 Retail APP、Web 端后台管理控制台；
• 适用角色：产品、架构、前后端开发、测试、运维、门店经销商、大陆业务管理人员；
• 适用阶段：需求评审、概要设计、详细设计、开发、UAT 验收、上线运维。

1.6 术语与缩写定义

缩写	全称	说明
Retail APP	Continental 零售门店统一 APP	本次新建移动端主应用
ROOS	马牌采购进销存小程序	轮胎线上采购、出入库、返利数据源；底部导航「首页 / 商品 / 购物车 / 我的」。建于 F6 后台之上，由马牌自建以管理并统计各门店对自有品牌的采购
O2O 接单宝	线上订单核销、门店收款小程序	线上到店订单、对账提现数据源；单页结构，无底部导航
延保门店端	延保业务门店侧小程序	保单建单、理赔、售后鉴定、延保返利数据源；底部导航「首页 / 工作台 / 待办事项 / 我的」
马上下单	门店主数据与订单后台	零售主数据（门店列表）来源
F6	第三方汽修管理系统	车辆 VIN 识别、轮胎检测、工单施工、会员营销（提醒规则）
RMS	车型匹配系统	车型与轮胎规格匹配能力；首版范围待确认，见 C10
MSIP	福利兑换 / 积分兑换平台	ROOS 与 O2O 首页的「积分兑换」入口指向该平台
CDMS	经销商管理系统	采购单支付提醒来源；与 ROOS 的职责边界待确认，见 C7
SAP	集团 ERP 系统	产品主数据（Tire price catalog）来源
零售管理	零售业务管理端	ROOS / O2O 首页的互跳入口之一；范围待确认，见 C10
ERP	企业资源计划系统	集团库存、订单、财务主数据系统
CATI	认证轮胎技术检测中心（Certified Tire Technical Inspection）	延保理赔中与「延保理赔」「售后鉴定」并列的独立理赔通道
DOT	轮胎生产批次代码（Department of Transportation code）	售后鉴定必采字段，含生产周次信息
SFTP	安全文件传输协议	SAP price catalog 的文件传输通道
CSO	客户服务订单系统（Customer Service Order）	其数据同步至马上下单
SKU	最小库存单位	商品/库存的唯一标识
核销码	线上订单到店核销凭证	消费者出示，门店扫码或输码核销
UAT	用户验收测试	门店真实人员参与业务验收
VNet	Azure 虚拟网络	生产 / 测试环境网络隔离
WAF	Web 应用防火墙	外网流量安全防护
IAM	身份访问管理	统一账号权限体系
JSBridge	H5 与原生的通信桥	Embedded H5 调用原生能力的通道，共 13 行 / 15 个 method，见 7.3 与《App Embedded H5 容器与 JSBridge 文档》

术语与缩写定义

1.7 需求编号规则

本文档所有需求条目采用 REQ-<模块码>-<3位序号> 编号，编号一经分配不再复用；需求删除时保留编号并标注「已废弃」。

模块码	模块	章节
LGN	账号登录	4.1
HOM	APP 首页与导航	4.2
SAL	销售	4.3
RMD	提醒	4.4
WTY	延保	4.5
PUR	采购	4.6
INV	库存	4.7
MIN	我的 / 个人中心	4.8
STM	门店管理	4.9
FIN	财务与对账	4.10
RBT	返利中心	4.11
PRF	经营业绩与报表	4.12
MKT	营销与会员	4.13
MSP	福利兑换（MSIP）	4.14
MDM	主数据	5
ADM	后台管理	6
INT	系统集成	7
NFR	非功能需求	8
ACC	验收与追溯	9、附录 D

需求模块码

1.8 文档编写约定

1.8.1 需求描述模板

本文档按模块重要度分两级描述。

完整模板（14 维） —— 适用于核心模块（4.1 账号登录、4.2 APP 首页、4.3 销售、4.4 提醒、4.5 延保、4.6 采购）：

维度	说明
业务目标	该模块要解决的业务问题
目标角色	店长 / 技工
入口	用户从哪里进入该功能
前置条件	进入前必须满足的状态
页面内容	页面上呈现的信息与控件
主流程	正常路径的步骤序列
异常流程	失败、超时、无权限、无数据等分支
业务规则	计算口径、约束、校验规则
权限规则	角色可见性与可操作性差异
访问链路	App → 后端 → 外围系统的调用路径
逻辑数据来源	数据取自哪个系统
回写目标	数据写回哪个系统
状态变化	单据/对象的状态流转
验收标准	可测试的判定条件

精简模板（6 维） —— 适用于其余模块（4.7–4.14）：业务目标 / 入口 / 页面内容 / 主流程 / 权限规则 / 数据来源。

书写形式：需求一律用文本描述，不用表格。 上表只是维度的定义清单，正文里每个维度写成一个自然段，维度名加粗置于段首，后接破折号与内容：

**业务目标** —— 用一套账号替代 6 套小程序各自的登录，消除重复登录……

**目标角色** —— 店长、技工

三个维度例外，写成列表而非段落，因为它们天然是多条并列项：页面内容（逐条列控件与信息）、主流程（有序列表，一步一行）、异常流程（每行一个「触发条件 → 处理方式」）。状态变化、访问链路涉及多个对象或多条链路时同样用列表，每行一条。

编号需求同理，写成 **REQ-xxx-nnn 需求名** —— 规则内容 的段落；需求下挂的提示或待确认说明另起一段，用 > 引用块承接，以免与下一条需求混淆。

之所以不用表格：需求正文长短差异大，塞进单元格后要靠 <br> 硬断行，Word 导出时列宽被迫压缩、长条目难以阅读；改成文本后段落可自由折行，编号仍在行首便于检索。表格只保留给字段清单、矩阵、对照与统计这类真正的二维数据。

1.8.2 图表约定

• 本文档为独立交付件，不引用其他文档的编号，全部结论就地写明；
• 插图直接嵌在所属小节内，正文以「本节设计稿」「现状截图」等方式称呼，不使用图号；
• 需求描述与编号需求用文本，不用表格，写法见 1.8.1；表格只用于字段清单、矩阵、对照与统计；
• 表格下方以一行文字说明其内容，不使用表号；
• 全部 173 张插图的清单见附录 C 图表清单，可用于核对导出后的配图完整性；同附录的表格清单收录正文中的实质性表格，附录内部的清单表不重复登记。

1.8.3 图片来源标注

标注	来源目录	含义
设计稿	app-design-images/	APP 目标形态视觉稿，15 张
现状-ROOS / 现状-O2O / 现状-延保	mini-program-images/	现状小程序真机截图，142 张
原型	./images/	业务流程原型图，16 张（F6 页面、提醒、后台管理，其余目录未覆盖）

1.8.4 待确认标记

正文中一切未经业务确认的内容以 TODO(REQ-xxx-nnn) 标记，并在第 10 章登记。本文档不使用 tbd，一切未定事项均有编号。

---

2 现状痛点分析

2.1 多小程序分散

• 门店人员切换采购、接单、延保等小程序需重复输入账号密码，登录繁琐；
• 各系统入口分散，店长需要多平台切换查看订单、库存、延保保单；
• 各小程序消息、待办独立，无统一提醒看板，容易遗漏订单、保单待办。

现状实证：ROOS 与 O2O 接单宝的首页各自挂着「订货平台 / O2O、延保门店端、积分兑换、零售管理」四个互跳入口——即小程序之间已经在用「首页放友链」的方式互相打补丁，恰好反证了入口分散的问题（见 2.7.2、2.7.3）。

2.2 账号权限管控

• 门店员工账号无统一后台审核机制，随意注册，人员离职无法快速回收权限；
• 无精细化角色区分，技工可查看门店财务数据，存在经营数据泄露风险；
• 多门店店长无法一键切换店铺，跨门店管理操作复杂。

现状实证：三套小程序各自实现了自己的「切换店铺」（ROOS 我的、O2O 选择店铺、延保工作台-选择店铺），店长在一天内可能要切三次同一家店。

2.3 进销存 & ERP 数据

• 小程序与集团 ERP 无自动同步，采购订单、销售工单、出入库数据需要手工二次录入；
• 库存数据分散，无法实时统一查看全门店轮胎、配件库存；
• 缺货、滞销无统一预警，门店补货全凭人工经验，库存周转效率低。

2.4 支付与营销

• 原有系统仅支持微信支付，缺少支付宝、对公转账、账期支付渠道；
• 促销活动入口隐蔽，无首页专属营销专区，曝光量不足；
• 客户分层营销能力缺失，无法根据车龄、生命周期精准推送活动优惠券。

2.5 数据经营分析

• 采购、营收、毛利、延保、返利数据分散在多系统，无统一可视化看板；
• 返利核算、员工业绩提成需要线下手工计算，效率低易出错。

现状实证：经营业绩至少有三个互不相通的口径——ROOS「业绩详情」（签约量/订货量/扫码入库量/O2O售出量）、O2O「经营业绩」（1.0/2.0/引流转化三套指标）、延保「工作台」（延保数量与返利简报）。返利同理，O2O 返利中心与延保返利中心是两套独立数据。

2.6 售后延保

• 延保登记需要在单独小程序操作，无法和门店施工工单联动；
• F6 汽修开单后无法一键跳转延保办理，需要重复录入车辆、轮胎信息；
• 保单、理赔数据在不同平台，查询、跟进流程复杂。

2.7 现状小程序功能全景

本节把「多小程序分散」从定性描述展开为可核对的功能清单，同时作为第 4 章各模块「迁移来源」的索引。内容全部来自现状小程序真机截图。

2.7.1 现状导航结构

小程序	底部导航	结构特征
ROOS 采购	首页 / 商品 / 购物车 / 我的	标准电商四段式
O2O 接单宝	无底部导航	单页长滚动 + 顶部工具条，全部功能以宫格铺开
延保门店端	首页 / 工作台 / [中键] / 待办事项 / 我的	深色主题，五段式带中央凸起键

现状小程序底部导航（截图实测）

三套导航互不兼容：段数不同（4 / 0 / 5）、主题不同（浅色 / 橙色 / 深色）、同名 tab 含义也不同（ROOS「我的」是采购账务中心，延保「我的」是账号设置页）。这是整合后必须收敛为一套 App 导航的直接原因，收敛方案见 4.2.5。

2.7.2 ROOS 采购小程序

首页构成：品牌 banner → 公告栏（暂无公告 >）→ 扫码出库 / 扫码入库 → 互跳宫格「O2O / 延保门店端 / 积分兑换 / 零售管理」。

功能域	页面	迁移目标章节
首页	首页、公告列表-空态、首页-扫码出库操作选择弹窗	4.2、4.7
商品与下单	商品选择、购物车、订单确认、订单确认-额度不足提示	4.6
订单	我的订单-全部、我的订单-待支付、售后退款	4.6
我的	我的、我的账户、我的优惠券-待使用、收货地址、支付优先级设置、商品收藏列表、我的-跳转账户管理小程序弹窗	4.8
库存	条码库存-入库记录	4.7
财务	对账单详情-采购对账单	4.10
业绩	业绩详情	4.12

ROOS 小程序功能清单（20 张截图）

2.7.3 O2O 接单宝小程序

首页构成（自上而下）：核销码输入框 + 核销按钮 → 工具条「核销历史 / 添加员工 / 消息 / 设置」→ 互跳宫格「订货平台 / 延保门店端 / 积分兑换 / 零售管理」→ 经营业绩卡（当月/当日/当周/当季，扫码入库总数、O2O 售出、马牌与维京性能指标含补货率）→ 订单管理（待接订单 74 / 调货中 2 / 待安装 26 / 待配送 1 / 配送中）→ 服务单（待安装 4 单）→ 宫格「平安账号 / 店铺管理 / 服务项报名 / 对账提现 / 经营业绩 / 返利中心 / 门店海报」→ 宫格「会员权益 / 经营范围 / 库存查询 / 协议中心 / 服务结算单 / 优惠券」→ 悬浮「联系客服」。

功能域	页面	迁移目标章节
核销与订单	订单列表-待接单/调货中/已完成/筛选、订单列表-接单货品状态选择、订单详情-待接单/待安装、订单备注、核销历史	4.3
服务单	服务单列表-全部/待安装/已安装/筛选、服务单列表-核销订单弹窗、服务单详情-待安装/已安装	4.3
库存	库存查询、库存查询-搜索类型选择、库存查询-筛选胎面宽/扁平比/直径/花纹、扫码入库、扫码入库-筛选品牌、扫码入库-自定义日期筛选	4.7
财务对账	对账提现、对账提现-交易手续费说明、提现历史、收入、收入详情、结算单明细、服务结算单、服务结算单-筛选结算渠道	4.10
返利	返利中心-返利详情/返利核算/安装费用调整情况/消费者补贴调整情况/抽奖红包返利说明/筛选品牌/筛选月份/筛选标签/筛选渠道	4.11
经营业绩	经营业绩-1.0经营业绩/2.0经营业绩/2.0引流转化/筛选品牌/筛选日期/筛选渠道	4.12
门店管理	店铺管理-基础信息/渠道信息/营业执照信息/2.0店铺信息、修改营业执照信息、修改营业执照信息-上传方式选择、经营范围与开票方式、经营范围详情、选择开票方式、银行账号-企业账户、银行账号-个人账户-解绑确认弹窗、单独服务项开通情况	4.9
营销与会员	优惠券-消费券、优惠券-门店营销券、选择营销券-空态、会员权益弹窗、会员权益弹窗-已选权益、会员体系门店-未开通、门店海报	4.13
协议	协议中心、小程序线下门店合作协议	4.9
个人与设置	设置、设置-确认登出弹窗、修改手机号、选择店铺、小程序在线客服、消息-门店违规提醒	4.8
延保关联	查看延保、认证轮胎技术检测中心CATI	4.5

O2O 接单宝小程序功能清单（78 张截图）

2.7.4 延保门店端小程序

功能域	页面	迁移目标章节
首页与建单	首页、首页切换店铺、扫描车牌、特殊车牌输入、待绑定车辆、待补充装车视频、待办事项	4.5.2
保单	所有保单、保单筛选、保单筛选日期、保单筛选品牌、保单子代码详情、保单详情-保单与活动信息、保单详情-延保信息、保单协议、德国马牌零售商延保使用条款须知	4.5.1、4.5.3
预约与理赔	全部预约-预约信息1/2、全部预约-预约信息详情、全部预约-提交的理赔信息、手动输入预约码、理赔处理、理赔-延保理赔、理赔-CATI理赔、理赔-售后鉴定	4.5.4
售后鉴定	售后鉴定、无用户信息鉴定通道1/2	4.5.5
工作台与数据	工作台、工作台-年、工作台-筛选品牌、工作台-选择店铺、数据分析1、数据分析2	4.5.6
返利	返利中心、返利中心-筛选品牌、返利详情、返利详细筛选日期	4.5.6、4.11
教程与账号	教程、教程视频、我的、我的-修改姓名、我的-切换店铺、其他小程序入口	4.5.7、4.8

延保门店端小程序功能清单（44 张截图）

2.8 痛点 → 需求映射

本节闭合「痛点提出」与「需求覆盖」。

痛点	对应需求章节	关键需求编号
2.1 多小程序分散	4.1 账号登录、4.2 APP 首页与导航	REQ-LGN-001、REQ-HOM-010
2.2 账号权限管控	4.1 账号登录、4.9 门店管理、6.3–6.4 后台账号与 RBAC	REQ-LGN-002、REQ-STM-004、REQ-ADM-003
2.3 进销存 & ERP 数据	4.6 采购、4.7 库存、5 主数据	REQ-PUR-001、REQ-INV-001
2.4 支付与营销	4.6 采购、4.13 营销与会员、4.2 首页促销位	REQ-PUR-006、REQ-MKT-001、REQ-HOM-004
2.5 数据经营分析	4.12 经营业绩与报表、4.11 返利中心	REQ-PRF-001、REQ-RBT-001
2.6 售后延保	4.5 延保、4.3 销售（结算后跳延保）	REQ-WTY-001、REQ-SAL-011

痛点与需求映射

---

3 利益相关者分析

3.1 终端用户（门店角色）

3.1.1 门店店长（核心管理用户）

诉求：一键登录，统一管理门店人员、采购库存、线上线下订单、财务对账、返利核算、销售机会、查看多维度经营数据、办理延保理赔、精准营销获客。

3.1.2 门店技工（一线操作用户）

诉求：快速扫码接车、轮胎检测、工单核销、简易延保登记、出入库扫码；无财务、人员管理权限，简化操作流程。

3.2 企业内部干系人

干系人	关注点
大陆零售业务部	统一管控全国门店运营、查看门店经营汇总数据
IT 架构团队	系统云架构设计、多系统集成、安全管控、运维落地
财务部门	门店对账、返利结算、营收数据统一校验
项目 PM / 产品	需求落地、项目进度管控、需求变更管理

企业内部干系人

3.3 外部对接系统厂商

厂商	提供能力
F6 汽修服务商	车辆检测、工单施工、结算页面（Embedded H5）与 API 接口；提醒规则配置（现状在 F6 PC 端）
云服务商 Azure	数据库、网络、监控、安全组件支撑
支付服务商	微信、支付宝、对公转账渠道对接
短信服务商	登录验证码、客户营销短信通道

外部对接系统厂商

注：扫码能力由 App 原生实现（native_scan），不依赖 F6 提供扫码页；F6 侧 H5 页面通过 JSBridge 调用原生扫码。见 C5 与《App 原生能力集成文档》、《App Embedded H5 容器与 JSBridge 文档》。

---

4 用户需求

本章按模块组织。4.1–4.6 为核心模块，采用完整 14 维模板；4.7–4.14 采用精简 6 维模板。

模块与来源对照见 模块总览。

4.0 模块总览

章节	模块	模块码	粒度	需求依据	现状承载系统
4.1	账号登录	LGN	14 维	业务需求 + 设计稿	O2O（用户主数据）
4.2	APP 首页与导航	HOM	14 维	业务需求 + 设计稿 3 版	ROOS / O2O / 延保
4.3	销售	SAL	14 维	业务需求 + 原型图 + O2O 订单截图	F6 + O2O
4.4	提醒	RMD	14 维	业务需求 + 原型图	F6（PC 端，App 内嵌 H5 展示）
4.5	延保	WTY	14 维	业务需求 + 延保小程序 44 张截图	延保门店端
4.6	采购	PUR	14 维	业务需求 + ROOS 截图 + 设计稿	ROOS（马牌）+ F6（非马牌）
4.7	库存	INV	6 维	现状截图反推	O2O + ROOS
4.8	我的 / 个人中心	MIN	6 维	业务需求 + 现状截图 + 设计稿	ROOS + O2O + 延保
4.9	门店管理	STM	6 维	业务需求 + O2O 店铺管理截图 + 设计稿	O2O
4.10	财务与对账	FIN	6 维	现状截图反推	O2O + ROOS
4.11	返利中心	RBT	6 维	现状截图反推	O2O + 延保
4.12	经营业绩与报表	PRF	6 维	现状截图反推 + 设计稿	O2O + ROOS + 延保
4.13	营销与会员	MKT	6 维	现状截图反推	O2O
4.14	福利兑换（MSIP）	MSP	6 维	现状入口 + 设计稿 + 业务确认（页面待补）	MSIP

模块总览

---

4.1 账号登录

一套账号切换多家门店，账号统一管理、员工权限配置。

4.1.1 需求描述

业务目标 —— 用一套账号替代 6 套小程序各自的登录，消除重复登录；同时建立可审核、可回收的账号管控机制，解决痛点 2.2

目标角色 —— 店长、技工

入口 —— APP 冷启动且无有效会话；会话失效后的任意页面被动跳转

前置条件 —— 账号已在 O2O 接单宝后台存在并通过审核；设备可访问网络

页面内容：

• 品牌背景 + Continental Logo
• 手机号输入框
• 验证码输入框 + 「获取验证码」
• 「登录」主按钮
• 「密码登录」次按钮（切换到用户名 + 密码模式）
• 「我要注册」文字入口
• 第三方登录区（微信、支付宝）
• 底部协议勾选「已阅读并同意《用户协议》与《隐私政策》」

主流程：

1. 输入手机号
2. 获取验证码
3. 输入验证码
4. 勾选协议
5. 点击登录
6. 后端校验通过下发 access / refresh token
7. 拉取该账号的门店列表与角色
8. 单门店直接进入首页；多门店弹出门店选择
9. 进入 APP 首页

异常流程：

• 手机号未注册 → 提示并引导「我要注册」
• 验证码错误 → 提示剩余可试次数
• 验证码超时 → 提示重新获取
• 未勾选协议 → 登录按钮不可用
• 账号被停用 → 提示联系门店管理员
• 账号无任何门店归属 → 阻断登录并提示
• 网络异常 → 保留已输入内容并允许重试

业务规则 —— 见 4.1.2

权限规则 —— 登录本身不区分角色；登录成功后由后端下发角色（店长 / 技工）与该角色的可见 tab 集合、功能权限，见 4.2.5 与附录 B

访问链路 —— App → App Backend → O2O 后台（用户主数据校验）；App Backend → 短信网关（验证码下发）；App Backend → 马上下单（门店列表）

逻辑数据来源 —— 用户主数据：O2O 接单宝后台（手机号、用户名、密码、角色）；门店列表：马上下单；协议内容：APP 后台管理 Web

回写目标 —— 登录日志、设备信息写入 App Backend；协议同意记录（版本号 + 时间戳）写入 App Backend

状态变化 —— 无会话 → 已登录（持有 access/refresh token）→ 已选定门店上下文

验收标准 —— 见 4.1.6

4.1.2 业务规则

REQ-LGN-001 手机号验证码登录 —— 手机号为 11 位中国大陆号码；验证码 6 位数字，有效期 5 分钟；同一手机号 60 秒内只能获取一次；单日获取上限 TODO(REQ-LGN-001)

REQ-LGN-002 用户名密码登录 —— 用户名与密码沿用 O2O 注册时设置的凭据；密码在传输与存储全程不可逆

REQ-LGN-003 第三方登录 —— 支持微信、支付宝授权登录。首次授权需绑定已有手机号账号后方可进入；未绑定账号不允许直接创建新账号。

⚠️ 该需求仅见于设计稿 —— TODO(REQ-LGN-003) 需确认是否纳入本期

REQ-LGN-004 注册与审核 —— 设计稿含「我要注册」入口。注册后账号处于「待审核」状态，需门店店长或后台管理员审核通过方可登录，以解决痛点 2.2 的「随意注册」问题。

⚠️ 注册表单字段、审核人、审核时效均未定义 —— TODO(REQ-LGN-004)

REQ-LGN-005 协议展示与留痕 —— 用户协议、隐私政策内容由后台管理 Web 维护，经法务审核；用户点击可查看全文；同意时记录协议版本号与同意时间；协议版本更新后需重新征得同意

REQ-LGN-006 密码策略 —— 密码长度、复杂度、有效期、历史密码不可复用条数 —— TODO(REQ-LGN-006)。忘记密码通过手机号验证码重置

REQ-LGN-007 登录失败锁定 —— 连续登录失败达到阈值后锁定账号一段时间。阈值与锁定时长 —— TODO(REQ-LGN-007)

REQ-LGN-008 登出 —— 用户主动登出时清理本地会话、门店上下文、缓存的业务数据与 WebView Cookie，见《App 门店上下文与会话管理文档》

REQ-LGN-009 会话与 Token —— access token 短期有效，refresh token 轮换续期；refresh 失效后跳转登录页。轮换策略见《后端安全与认证文档》。具体有效期 —— TODO(REQ-LGN-009)

REQ-LGN-010 门店上下文 —— 登录后必须确定唯一「当前门店」；切换门店时级联失效所有门店相关缓存与在途请求，见《App 门店上下文与会话管理文档》

4.1.3 店长

1. 店长通过自己注册的手机号登录页面；
2. 店长通过注册的用户名、密码登录页面；
3. 店长点击「用户协议」，可以查看用户协议的具体内容；
4. 店长点击「隐私协议」，可以查看隐私协议的具体内容。

4.1.4 技工

1. 技工通过自己注册的手机号登录页面；
2. 技工通过自己的用户名、密码登录页面；
3. 技工点击「用户协议」，可以查看用户协议的具体内容；
4. 技工点击「隐私协议」，可以查看隐私协议的具体内容。

登录环节店长与技工无差异；差异从登录成功后的角色化导航开始，见 4.2.5。

4.1.5 业务数据列表

用户信息当前存放在 O2O 接单宝后台，用户的登录验证数据一致性以 O2O 接单宝后台的数据为用户主数据。

#	字段	字段名	数据来源	说明
1	手机号	PhoneNum	O2O 后台	用户注册手机号
2	用户名	Username	O2O 后台	用户在 O2O 注册时的用户名
3	密码	Password	O2O 后台	用户名设置的密码
4	用户协议	UserProtocol	APP 后台管理 Web	由法务审核后的协议条例
5	隐私政策	PrivateProtocol	APP 后台管理 Web	由法务审核后的隐私政策
6	验证码	ValidateCode	第三方短信网关	后台调用短信网关发送至用户手机
7	角色	RoleCode	O2O 后台 / APP 后台	店长 / 技工，决定导航与权限 —— 权威来源待确认 TODO(REQ-LGN-011)
8	门店列表	StoreList	马上下单	该账号可访问的门店集合
9	协议同意记录	ProtocolConsent	APP Backend	协议版本号 + 同意时间戳

账号登录业务数据

4.1.6 验收标准

1. 未勾选协议时登录按钮为禁用态，无法提交；
2. 单门店账号登录后直接进入首页，不出现门店选择步骤；
3. 多门店账号登录后必须完成门店选择才能进入首页；
4. 主动登出后，重新启动 APP 不会恢复到已登录状态，且 WebView 中原会话不可复用；
5. refresh token 失效后，任意业务页面的接口调用都会被统一拦截并跳转登录页，不出现半登录态；
6. 切换门店后，首页及各业务页展示的数据全部属于新门店，无旧门店数据残留。

---

4.2 APP 首页

APP 首页是用户登录成功后展示的第一个页面。不同角色因权限不同，展示的信息和菜单不一样。

4.2.1 需求描述

业务目标 —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏，让门店开工第一眼就知道「今天有什么要做、有什么要盯」，解决痛点 2.1 与 2.5

目标角色 —— 店长、技工（内容差异见 4.2.3、4.2.4）

入口 —— 登录成功后默认落地；任意页面点击底部「首页」tab

前置条件 —— 已登录且已确定当前门店上下文

页面内容 —— 见 4.2.3、4.2.4

主流程：

1. 进入首页
2. 并行拉取门店信息、待办、预警、促销、经营卡片
3. 分区渲染，任一分区失败不阻塞其它分区
4. 用户点击分区进入对应模块

异常流程：

• 单个数据源超时/失败 → 该卡片显示占位与「重试」，其余正常展示（局部降级，见《后端跨域协作与聚合文档》）
• 门店未接 F6 → 隐藏依赖 F6 的分区与 tab
• 无待办 → 显示空态而非隐藏分区

业务规则 —— 见 4.2.6

权限规则 —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发，客户端不硬编码，见 4.2.5

访问链路 —— App → App Backend（聚合）→ 并行 fan-out 至 O2O / ROOS / 延保 / CDMS / F6

逻辑数据来源 —— 见 4.2.7

回写目标 —— 消息已读状态回写 App Backend；其余为只读聚合

状态变化 —— 消息：未读 → 已读；待办项计数随源系统单据状态变化

验收标准 —— 见 4.2.8

4.2.2 现状导航与目标导航的差异

整合前，三套小程序各带一套底部导航，且互相之间用「首页放友链」的方式跳转（见 2.7.1）。整合后全部小程序 tabbar 一律废弃，App 只保留一套底部导航。

现状入口	现状位置	App 归属
ROOS 首页 / 商品 / 购物车	ROOS tabbar	合并进「采购」tab（4.6）
ROOS 我的	ROOS tabbar	拆分：账务类进「我的」（4.8），对账单进财务，业绩进经营业绩
ROOS 扫码出库 / 扫码入库	ROOS 首页	「入库」tab（4.7）
O2O 核销码输入 + 核销	O2O 首页顶部	首页「快速核销」卡片
O2O 订单管理五状态	O2O 首页	首页「待办事项」+ 4.3 销售的订单列表
O2O 两组功能宫格（13 项）	O2O 首页	分派至 4.9 / 4.10 / 4.11 / 4.12 / 4.13
延保 首页 / 工作台 / 待办事项 / 我的	延保 tabbar	合并进「延保」tab（4.5）
「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格	ROOS + O2O 首页	取消——整合后无需互跳；其中「积分兑换」保留为4.14 福利兑换入口

现状入口 → App 导航映射

4.2.3 店长首页

自上而下分区（见本节店长首页设计稿）：

一、门店切换

当前用户旗下如果有多家店，可以通过顶部的下拉选择项切换至不同的门店。切换后所有业务数据按新门店重新加载。

二、问候语

用户成功登录首页后，在左上方展示用户信息以及问候。系统读取当前用户的姓氏、角色以及当前时间段，整合成合适的问候语，如「张店长，上午好」。

三、消息公告

右上角铃铛图标的角标展示当前未读消息条数；点击图标以列表形式展示系统站内信；点击后角标数字消失。促销信息展示往期马牌的所有促销活动；通知消息由管理员在后台管理平台发布。

现状消息分散在 ROOS「公告」与 O2O「消息」两处，且类型不同（ROOS 为促销/通知公告，O2O 含门店违规提醒等治理类消息）。整合后需在一个消息中心内分类承载 —— 消息分类体系 TODO(REQ-HOM-003)。

四、促销信息

提醒用户当前马牌轮胎有促销活动，系统展示马牌最近一次举行的促销活动；点击促销区域展示具体活动内容。促销活动内容来自 ROOS 提供的接口；APP 后台定时调用促销活动接口，拉取促销信息并推至用户首页；往期促销信息在右上角铃铛对应的列表页中展示。

设计稿中该区域为首页底部的横幅广告位（「马牌高端系列 买三送一」）。

五、扫码接车

当客户车开进马牌门店时，用户可以直接点击「扫码」按钮，对准客户车头识别车辆号牌，进入销售流程。

扫码由 App 原生能力实现（native_scan），非 F6 提供的扫码页，见 C5。车牌识别走云端 OCR 服务：拍一张照上传识别，不是取景框里的实时识别，因而依赖网络——「输码」不是失败后的降级，而是与「扫码」并列的常驻入口。见第 10 章风险 R9。

六、输码

在做客户接车时，因特殊原因无法正确通过「扫码」识别客户车牌时，可以通过「车牌」按钮手工输入客户的车辆号牌，进入销售流程。

七、快速核销

设计稿在「车牌扫码」之外并列了一组「快速核销」（扫码 / 输码），对应 O2O 接单宝首页顶部的核销码输入框 —— 消费者到店出示线上订单核销码，门店扫码或手工输码完成核销。

扫码核销的详细流程待确认 —— TODO(REQ-SAL-010)，详见 4.3.4。

八、待办事项

待办事项在首页中扮演用户助手的角色，方便用户随时查看自己的工作列表。每项提醒的上方显示该项对应的待办事项总数。

现有两套并存的待办口径，两者不冲突，是两个层次：

层次	项目	来源	说明
跨系统提醒（业务层）	O2O 订单接单提醒、CDMS 采购单支付提醒、延保视频上传提醒、问卷提醒、过期门店信息更新提醒	O2O / CDMS / 延保 / 待定	按来源系统聚合的业务提醒
订单流转状态（单据层）	待接单、待调货、待安装、待配送、待服务	O2O 订单管理	设计稿口径；对应 O2O 现状的「待接订单 / 调货中 / 待安装 / 待配送 / 配送中」

待办事项两层口径

设计稿的五项与 O2O 现状五状态一一对应但措辞不同（「待调货」vs「调货中」、「待服务」vs「配送中」）。首页最终展示哪一层、或两层如何合并展示 —— TODO(REQ-HOM-008)，见 C2。

九、动态预警

动态预警在首页中扮演用户管家的角色，随时帮用户检查目标任务达成情况、库存数量预警、时效订单预警等。系统按紧急程度在动态预警右边展示需要及时处理的事件数量，并提供「查看全部」入口浏览所有需要及时处理的事件。

预警项全集：

预警项	数据来源	备注
总预警数	APP 后台计算	各项之和
月度签约达成预警	TODO(REQ-HOM-009)	达成口径与阈值待定
库存预警（低库存）	F6	⚠️ 未接 F6 不显示此项；设计稿示例为「低库存 马牌 205/55R16 剩余 5 条」
时效订单预警	O2O	临近履约时限的订单

动态预警项

各项预警的触发阈值（如低库存的条数门槛、时效订单的提前量）均未定义 —— TODO(REQ-HOM-009)，见 C3。

十、今日经营卡片

设计稿在问候语下方设有营收卡片：今日预计营收（¥34,500）、毛利率（88%）、成交单数（24 单）、客单价（¥1,437），并带「眼睛」图标支持一键隐藏金额。

该卡片仅见于设计稿。「预计营收」的口径（是否含未结算订单、是否含延保与返利、毛利率的成本口径）未定义 —— TODO(REQ-HOM-011)，见 C8。金额隐藏功能对应痛点 2.2 中「技工可查看门店财务数据」的风险控制诉求。

十一、底部导航

见 4.2.5。

4.2.4 技工首页

技工首页与店长首页的分区差异（见本节技工首页设计稿）：

分区	店长	技工	说明
门店切换	✅ 下拉切换	⚠️ 仅显示门店名	拥有多门店权限的用户可切换门店；设计稿技工版无门店名与切换器 —— TODO(REQ-HOM-001) 需确认技工是否允许多门店
问候语	「张店长，上午好」	「韩师傅 · 技师」	设计稿技工版为「姓氏 + 师傅 · 角色」格式，无时段问候
消息公告	✅ 铃铛 + 角标	⚠️ 设计稿未出现	业务需求中技工应有消息公告 —— TODO(REQ-HOM-003) 需确认
促销信息	✅	✅	技工可见
今日经营卡片	今日预计营收 / 毛利 / 成交单数 / 客单价	今日已完工 N 单 + 「查看绩效明细」	技工不可见金额类数据，与痛点 2.2 一致
快速核销 / 车牌扫码	✅	✅	完全一致
待办事项	✅	⚠️ 设计稿未出现	业务需求中技工应有待办事项 —— TODO(REQ-HOM-008)
动态预警	✅	⚠️ 设计稿未出现	业务需求中技工应有动态预警 —— TODO(REQ-HOM-009)
当前施工队列	❌	✅	技工独有分区，仅见于设计稿

店长 / 技工首页分区差异

当前施工队列（技工独有）

展示分配给当前技工的施工任务，卡片含：车牌号、订单来源渠道标（天猫订单 / 京东订单）、状态标（安装中 / 待安装）、施工内容（如「更正品查验 + 动平衡 + 轮胎号延保绑定」「更换 马牌 UC6 225/55R17 * 4 条」）、预约时间、主操作按钮（「完工并结算」/「开始施工」）；顶部显示「共 N 单」。

该分区仅见于设计稿。涉及的问题：施工任务如何分派给具体技工？状态机与 F6 工单、O2O 服务单的关系？「完工并结算」跳转到 F6 结算页还是 App 内页？—— TODO(REQ-HOM-012)，见 C13。

4.2.5 导航收敛与角色化配置

收敛原则

1. 整合后 App 只有一套底部导航，所有小程序 tabbar 全部废弃；
2. tab 集合不在客户端硬编码，由 App Backend 在登录/切店后下发；
3. 下发依据为 角色（店长 / 技工）× 门店能力（是否接 F6、是否开通延保等）；
4. 客户端对未知 tab code 做忽略处理，保证后端可灰度增删 tab 而不强制发版。

三版 tab 方案

方案	tab 集合	来源
A（业务菜单版）	首页 / 库存 / 采购 / 我的	业务需求「用户主菜单」
B（主设计稿）	首页 / 入库 / 采购 / 延保 / 我的	设计稿 首页-店长、首页-技工、个人中心
C（宫格版）	首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心	设计稿 首页-功能宫格版

三版底部导航方案

三者的差别不只是段数：方案 A/B 是「业务动作导向」（去入库、去采购），方案 C 是「管理职能导向」（看门店、看经营、看账务），且方案 C 把业务动作全部收进首页的 8 宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）。

推荐方案：以 B 为基线（业务动作导向更贴合门店高频操作），把 C 的管理职能入口收进「我的」与首页宫格。

⚠️ 各角色的具体 tab 清单尚未确认 —— TODO(REQ-HOM-010)，见 C1。下表为待确认的建议值：

tab	店长	技工	门店能力依赖	对应章节
首页	✅	✅	—	4.2
入库	✅	✅	—	4.7
采购	✅	⚠️ 授权可见	—	4.6
延保	✅	✅	门店已开通延保	4.5
我的	✅	✅	—	4.8

角色化 tab 配置（建议值，待确认）

门店能力开关对导航的影响

已明确一条硬规则：

⚠️ 如果当前用户所在门店未接 F6，「库存」菜单不显示；对技工还需叠加「技工无此权限则不显示」。

推广为通用规则：任一 tab 或首页分区若依赖某外围系统，而当前门店未接入该系统，则该 tab / 分区整体隐藏（而非置灰或点击后报错）。能力开关清单见 7.3。

4.2.6 业务规则

REQ-HOM-001 门店切换 —— 多门店账号可在首页顶部切换门店；切换后级联刷新全部数据，见《App 门店上下文与会话管理文档》

REQ-HOM-002 问候语 —— 由「姓氏 + 角色称谓 + 时段问候」拼接；时段划分口径 TODO(REQ-HOM-002)

REQ-HOM-003 消息公告 —— 角标为未读数；点击进入列表后清零。消息分类体系待定 TODO(REQ-HOM-003)

REQ-HOM-004 促销信息 —— 来源 ROOS 接口，APP 后台定时拉取；首页展示最近一次活动，往期在消息列表

REQ-HOM-005 扫码接车 —— App 原生扫码识别车牌 → 进入销售流程

REQ-HOM-006 输码接车 —— 扫码失败时手工输入车牌 → 进入销售流程

REQ-HOM-007 快速核销 —— 扫核销码或手工输入核销码 → 进入核销流程（4.3.4）

REQ-HOM-008 待办事项 —— 两层口径并存，最终展示形态待定 TODO(REQ-HOM-008)

REQ-HOM-009 动态预警 —— 四项预警，阈值待定 TODO(REQ-HOM-009)；库存预警依赖 F6

REQ-HOM-010 角色化导航 —— tab 集合由后端按角色 + 门店能力下发，清单待定 TODO(REQ-HOM-010)

REQ-HOM-011 今日经营卡片 —— 店长看金额类指标（可隐藏），技工看完工单数；口径待定 TODO(REQ-HOM-011)

REQ-HOM-012 当前施工队列 —— 技工独有；分派规则与状态机待定 TODO(REQ-HOM-012)

REQ-HOM-013 分区降级 —— 任一数据源失败仅该卡片降级，不影响其它分区渲染

4.2.7 业务数据列表

#	字段	字段名	数据来源	说明
1	门店名称列表	StoreNameList	马上下单	来自马上下单的门店列表
2	用户问候	GreetingStr	APP Backend	首页问候语，来自登录后获取的姓名和当前时间
3	消息公告	Msg2PromotionList	APP 后台 + ROOS	消息公告来自 APP 后台，促销信息来自 ROOS
4	促销信息	PromotionMsg	ROOS	来自最新的 ROOS 促销信息
5	待办事项	TodoList	多源	O2O 订单接单提醒：O2O 接口 CDMS 采购单支付提醒：CDMS 接口 延保视频上传提醒：延保接口 问卷提醒：TODO(REQ-HOM-014) 过期门店信息更新提醒：TODO(REQ-HOM-015)
6	动态预警	PrecautionIndexList	多源	总预警数：APP 后台计算 月度签约达成预警：TODO(REQ-HOM-009) 库存预警：F6（⚠️ 未接 F6 不显示此项） 时效订单预警：O2O
7	动态预警查看详情	PrecautionAllList	同上	全量预警列表
8	今日经营卡片	TodayBusinessCard	TODO(REQ-HOM-011)	预计营收 / 毛利率 / 成交单数 / 客单价（店长）；已完工单数（技工）
9	当前施工队列	WorkQueueList	TODO(REQ-HOM-012)	技工独有；车牌、渠道、状态、施工内容、预约时间
10	底部 tab 配置	TabConfigList	APP Backend	按角色 + 门店能力下发

APP 首页信息字段

4.2.8 验收标准

1. 未接 F6 的门店，登录后底部导航不出现依赖 F6 的 tab，首页不出现库存预警项；
2. 多门店店长切换门店后，首页全部分区（待办、预警、经营卡片、促销）均刷新为新门店数据；
3. 任意单个上游系统（O2O / CDMS / 延保 / F6）不可用时，首页仍可打开，失败分区显示占位与重试，其余分区正常；
4. 技工登录后首页不出现任何金额类经营指标；
5. 消息角标数字与消息列表未读条数一致；进入列表后角标归零。

---

4.3 销售

用户登录成功后，通过「扫码」按钮扫描客户车牌，即可进入销售流程。

4.3.1 需求描述

业务目标 —— 把「车开进门店」到「结算完成并办理延保」的全链路装进一个 APP，消除 F6、O2O、延保三系统间的重复录入，解决痛点 2.6

目标角色 —— 店长；技工（授权后功能一致，见 4.3.8）

入口 —— 首页「扫码 / 车牌」（接车）；首页「快速核销」（线上订单核销）；底部导航进入订单列表

前置条件 —— 已登录并确定门店上下文；接车与施工链路要求门店已接入 F6；核销链路要求门店已开通 O2O

页面内容 —— 见 4.3.2–4.3.7

主流程：

1. 扫码/输码识别车牌
2. 后端凭车牌向 F6 取车主车辆信息
3. 展示历史工单与延保历史
4. 新建工单 / 检测开单
5. 施工查车
6. 生成检测报告并发送车主
7. 检测单转工单
8. 完工
9. 结算收银
10. 结算后跳转延保

异常流程：

• 车牌识别失败 → 转手工输码
• F6 无该车档案 → 进入新建车辆建档流程
• 门店未接 F6 → 隐藏历史工单、销售商机、施工查车、结算等 F6 分区
• F6 接口超时 → 提示重试且不生成半截单据
• 核销码无效/已核销/过期 → 分别给出可区分的错误提示

业务规则 —— 见 4.3.9

权限规则 —— 技工被分配销售权限后功能与店长一致；未授权技工不可见销售入口。金额类信息（商品总价、实收金额）对技工的可见性 —— TODO(REQ-SAL-012)

访问链路：

• 车辆信息/工单/检测/结算：App → App Backend → F6 Integration Adapter → F6；F6 页面以 Embedded H5 形式嵌入，原生能力经 JSBridge 提供（见《App Embedded H5 容器与 JSBridge 文档》）
• 线上订单/核销/服务单：App → App Backend → O2O
• 延保历史：App → App Backend → 延保后台

逻辑数据来源 —— 车主车辆、历史工单、检测、工单、结算：F6；销售商机（服务提醒 + 意向池）：F6；延保历史：延保后台；线上订单、服务单、核销：O2O

回写目标 —— 工单、检测单、结算单回写 F6；核销结果回写 O2O；延保建单回写延保后台

状态变化：

• 车辆：未到店 → 已在店 → 离店
• 工单：接车 → 开单 → 施工 → 完工 → 已结算
• 检测单：待检 → 已检（正常/异常）→ 转工单 / 转商机
• 线上订单：待接单 → 调货中 → 待安装 → 待配送 → 配送中 → 已完成

验收标准 —— 见 4.3.10

4.3.2 接车与车辆识别

一、交易记录号

APP 自动按预定规则生成门店交易流水号，在业务保存时提交此唯一交易号。

流水号生成规则（前缀、门店码位数、日期段、序列位数、跨天重置策略）未定义 —— TODO(REQ-SAL-001)。该号需保证幂等提交，见《后端并发、事务与定时任务文档》。

二、已在店

车牌扫码成功或用户输码成功后，系统显示该车状态为「已在店」。

三、当前时间

APP 获取手机系统当前时间；格式：YYYY-MM-DD HH:mm。

四、车主车辆信息

用户扫码获取车辆车牌后，后台通过车牌从 F6 获取车主信息、行驶证车架号、车辆里程，以及最近一次到店时间；如果是第一次到店，显示当天时间。

#	字段	字段名	数据来源	说明
1	车牌	CarPlate	拍照识别或手工输入	识别经云端 OCR，需联网；置信度低时以「待确认」展示
2	车主姓名	OwnerName	F6 接口获取
3	车架号	VIN	F6 接口获取	支持一键复制
4	里程	Milage	F6 接口获取
5	最近到店时间	LatestArrDate	F6 接口获取	首次到店显示当天

根据车牌获取车主车辆信息

五、历史工单

展示该车以前的维修记录。历史记录从 F6 取；如果门店未接 F6，则「历史工单」不显示。

字段：门店名、服务时间、车牌号、行驶里程、服务顾问、业务分类、商品总价、实收金额、结算状态、可展开的「查看项目材料」（项目 / 工时费 / 折后价）。

六、延保历史记录

延保历史记录通过「延保」小程序后台获取信息。字段：POLICY NO.、车牌、保障标签（数包保障 / 爆胎保障 / 延保服务）、保单状态（正常 / 待确认 / 待补充）、时间、详情入口。

七、销售商机

开通 F6 的门店才有此功能。点击「销售商机」展示销售商机页，「服务提醒」和「意向池」的内容来自于 F6 接口。

4.3.3 检测、开单与施工

八、新建工单

点击「新建工单」，弹出新建工单页，由 F6 开发页面。

到店记录页含：车牌、完善信息入口、保险信息（交强险 / 商业险 / 保险公司到期日与查询状态）、当前里程与油量、四个开单入口（预检开单 / 检测开单 / 报价开单 / 工单开单）、小程序订单关联区、「离店」按钮。

新车辆建档页含：车牌号（支持扫描）、车辆用途（乘用车 / 商用车）、VIN（17 位，支持扫描，保存后自动解析车型）、车型、客户信息（姓名、手机号码）、更多联系人、行驶证信息。

车辆详情页含：品牌车型、VIN、编辑车辆 / 编辑车辆标签、建档人、车辆分类、燃油类型、年检日期、一级类型、轮胎规格与发动机型号等出厂配置详情、客户信息、消费历史、保险保养信息、「给当前车辆发票」/「开单」。

九、施工查车

页面中的「预检开单」等操作按钮弹出相关工单页，由 F6 开发页面。

轮胎专检页：tab「全部(N) / 已检(N) / 未检(N)」；按轮位分组（如「左前轮检测」）含检测视频入口；每个检测项（花纹深度检测 / 偏磨检测 / 外伤检测）提供结论按钮（正常 / 尽快更换 / 立即更换、正常 / 偏磨中间 / 偏磨胎肩 / 失圆、正常 / 鼓包 / 划伤 / 漏气）与「添加备注/图片」；底部「共 N 项异常」+「放弃检测 / 批量通过 / 保存」；批量通过时弹确认。

检测报告页：健康度环形图（有隐患）、检测门店 / 服务顾问 / 服务技师、四类计数（急需处理 / 择期处理 / 建议处理 / 正常，各带「已解决(N)」）、按类分组的检测明细（检测图片、项目说明、视频）、底部「客户签名 / 发给车主 / 去处理」。发送渠道弹层含：车主微信（仅主订单）、公众号推送（车主已关注）、企业微信、短信（需购买）、他人微信。

检测问题处理页：只支持处理「急需」「择期」「建议」类项目（不包含车辆检测视频和聊天记录）；每个异常项提供「转维修单 / 转商机」二选一；选择维修单后可添加项目（含工时与金额）；底部「待处理: N 本次处理: N」+「提交」。转单类型弹层：转维修单或转商机 / 转贴膜单或转商机 / 转洗车单或转商机 / 转理赔单或转商机。

新建维修单页：批量操作（指派技师 / 业务分类 / 销售人员 / 更多）；项目行（如「更换轮胎（普通胎 17 寸以上）」含工时、技师选择、添加关联材料）；材料行（如「乘用车轮胎」含数量、技师、仓库/货位、质保信息）；自带材料 / 附加费 / 车主描述；底部「商品总价 / 待收金额」+「价参 / 提交」。

查看维修单页：车辆头卡（车牌、车型、VIN、复制VIN、配置详情、标签）、商机与车险到期提醒、历史记账 / 上次服务 / 定金 / 卡 / 优惠券、专属顾问、客户标签、变速箱号 / 发动机号 / 发动机型号 / 轮胎出厂规格、服务顾问、本次到店状态条（接车 → 开单 → 施工 → 完工）、商品总价 / 待收金额、底部「发给车主 / 修改 / 完工」。

4.3.4 核销

十、扫码核销

消费者到店出示线上订单核销码，门店通过首页「快速核销」扫码或手工输码完成核销。

现状实证（O2O）：

核销的详细流程待确认 —— TODO(REQ-SAL-010)：需明确核销码格式与校验规则、核销与订单状态的关系（核销即完成 or 核销后仍需安装）、重复核销与撤销核销的处理、核销失败的错误分类。见 C12。

4.3.5 线上订单管理

线上订单来自 O2O，是首页待办「单据层」五状态的详情载体。

设计稿订单列表：订单号搜索；渠道 tab（全部渠道 / 抖音 / 天猫 / 京东 / …）；状态 tab（待接单(9) / 待配送(3) / 调货中(6) / 待安装(4)）；订单卡含渠道标、状态、下单时间、订单编号（可复制）、商品行（名称 / 规格 / 数量）、客户卡（姓名 / 客户等级 / 拨号按钮）、共 N 件、订单金额、操作「添加备注 / 确定接单」。

渠道维度（抖音 / 天猫 / 京东）仅见于设计稿。渠道清单是否可配置 —— TODO(REQ-SAL-013)。

现状实证（O2O）：

4.3.6 服务单

服务单是订单履约的施工侧载体，与订单一对一或一对多关联。

服务单与 F6 工单的关系未定义：同一次施工在 O2O 有服务单、在 F6 有工单，两者是否需要关联、以哪一侧为准 —— TODO(REQ-SAL-014)。这直接影响技工首页「当前施工队列」的数据源。

4.3.7 结算与延保跳转

十一、结算

结算页由 F6 开发。结算完成后，F6 需要添加一个按钮，跳转到「延保」。

结算收银页：收款成功状态、收款信息（订单金额 / 应收金额 / 已收金额 / 未收金额）、备注、「完成收款」、「查看历史收款 >」「查看未结清单据 >」。

十二、延保

由结算页跳转至延保流程，见 4.5。跳转时应携带车牌、VIN、轮胎条码/DOT 等已录入信息，避免重复录入（这正是痛点 2.6 的核心诉求）。

跳转参数契约（F6 → App → 延保后台）未定义 —— TODO(REQ-SAL-011)。

4.3.8 角色差异

店长：完整销售流程权限。

技工：如果技工被分配此项权限，其功能与店长一致。

金额类字段（商品总价、实收金额、待收金额）是否对技工屏蔽，与痛点 2.2「技工可查看门店财务数据」的诉求存在张力 —— TODO(REQ-SAL-012)。

4.3.9 业务规则

REQ-SAL-001 交易流水号 —— APP 按规则生成、业务保存时提交，保证唯一与幂等；规则待定 TODO(REQ-SAL-001)

REQ-SAL-002 车牌识别 —— 拍照上传至云端 OCR 识别（经 App 后端代理），返回车牌号与置信度；置信度偏低时以「待确认」展示、由用户核对后再提交。需联网；手工输码为常驻并列入口，不是识别失败后的降级

REQ-SAL-003 车辆信息获取 —— 凭车牌向 F6 取车主、VIN、里程、最近到店时间；F6 无档案时进入建档

REQ-SAL-004 历史工单 —— 来自 F6；门店未接 F6 则整个分区不显示

REQ-SAL-005 延保历史 —— 来自延保后台；与历史工单并列为两个 tab

REQ-SAL-006 销售商机 —— 仅开通 F6 的门店可见；「服务提醒」与「意向池」来自 F6

REQ-SAL-007 检测与工单 —— 页面由 F6 提供（Embedded H5）；App 负责容器、导航栏、原生能力桥接与登录态透传

REQ-SAL-008 检测报告发送 —— 支持车主微信 / 公众号 / 企业微信 / 短信等渠道；短信渠道需购买

REQ-SAL-009 检测单转单 —— 异常项可转维修单或转商机，二选一

REQ-SAL-010 扫码核销 —— 流程待定 TODO(REQ-SAL-010)

REQ-SAL-011 结算后跳延保 —— F6 结算页增加跳转按钮；参数契约待定 TODO(REQ-SAL-011)

REQ-SAL-012 技工金额可见性 —— 待定 TODO(REQ-SAL-012)

REQ-SAL-013 订单渠道维度 —— 渠道清单是否可配置待定 TODO(REQ-SAL-013)

REQ-SAL-014 服务单与工单关系 —— 待定 TODO(REQ-SAL-014)

4.3.10 验收标准

1. 门店未接 F6 时，销售模块不展示历史工单、销售商机、检测开单、施工查车、结算等 F6 分区，且不产生报错弹窗；
2. 扫码识别失败后可无损转入手工输码，已识别的部分信息不丢失；
3. F6 页面在 Embedded H5 中打开时，登录态与门店上下文自动透传，用户无需二次登录；
4. 从 F6 结算页跳转延保时，车牌与 VIN 自动带入，无需重新录入；
5. 同一交易流水号重复提交时，后端幂等处理，不产生重复单据；
6. 切换门店后，订单列表与服务单列表只显示新门店的数据。

---

4.4 提醒

承接方式已定：提醒能力由 F6 承载，App 不做原生实现，以 Embedded H5 容器嵌入 F6 现有提醒页，能正常展示与操作即可。提醒规则、提醒单生成与跟进逻辑全部留在 F6 侧，App 只负责入口、换票鉴权与容器能力。方案取舍见 4.4.5。

本模块现状分三步：设置提醒规则 → 生成提醒单 → 跟进提醒单，分别对应 4.4.2–4.4.4。三步均由 F6 实现，以下小节记录其现状形态 —— 这既是 App 嵌入后用户实际看到的内容，也是后续若要原生化时的需求底稿。

4.4.1 需求描述

业务目标 —— 基于车辆保养周期、保险到期、检测异常等规则自动生成提醒单，由服务顾问跟进转化，提升复购与到店率，支撑痛点 2.4 的「客户分层营销」诉求

目标角色 —— 店长；技工是否开放入口待定 TODO(REQ-RMD-005)

入口 —— App 内提醒入口，具体位置随导航方案确定（见 4.2.5）；点击后进入 Embedded H5 容器加载 F6 提醒页

前置条件 —— 门店已接入 F6；已有车辆与消费历史数据

页面内容 —— 由 F6 页面提供，App 侧不另行定义；现状形态见 4.4.2–4.4.4

主流程：

1. 设置提醒规则
2. 车主到店消费
3. 车主完工离店
4. 生成提醒单并跟进
5. 临近服务日提醒车主（可自动发短信/微信）
6. 车主再次到店

异常流程：

• 门店未接入 F6 → 提醒入口不显示，见门店能力开关
• F6 提醒页白屏 / 加载超时 / 票据过期 → 由 Embedded H5 容器统一处理，见 7.3
• 车主手机号缺失 → 无法发送短信/微信，仅支持电话提醒（F6 页面行为）
• 短信额度不足 → 提示「未购短信，无法分享」并提供购买入口（F6 页面行为）

业务规则 —— 见 4.4.6

权限规则 —— 页面内的规则配置与跟进权限由 F6 自行控制；App 侧只决定入口对哪些角色可见 TODO(REQ-RMD-005)

访问链路 —— App → Embedded H5 容器 → App Backend 换票下发 URL → F6 提醒页（不传裸 URL，见 7.3）

逻辑数据来源 —— F6（规则、提醒单、车辆与消费历史）

回写目标 —— 无。跟进动作（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交）在 F6 页面内完成并由 F6 自行落库，App 不做回写

状态变化 —— 提醒单：未处理 → 我未完成 / 我已完成 → 所有已完成（状态机由 F6 维护）

验收标准 —— 见 4.4.7

4.4.2 设置提醒规则

规则分八类（tab）：服务提醒 / 车险到期提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保提醒。最多可自定义 20 个提醒规则。

服务提醒下分「保养提醒」与「洗美提醒」，按项目设置服务周期。保养提醒规则表字段：

字段	说明	示例
提醒类别	规则名称，可标「推荐」	小保养、空气滤清器、火花塞、变速箱油、刹车油、发动机清洗、油底壳螺丝、防冻冷却液、轮胎
包含项目	触发该提醒的业务项目	工单业务分类：保养；更换空气滤清器·保养工时费
是否根据保养手册	是 / 否
提醒单生成日	相对下次服务日的提前量	下次服务日前 30 天 / 15 天 / 7 天 / 60 天 / 10 天 / 23 天
提醒单处理人	责任人角色	工单服务顾问 / 公司统一处理人 / 无处理人
是否自动提醒	是 / 否
状态	启用 / 停用开关
操作	修改

保养提醒规则字段

系统预置规则基于常见保养提醒周期，建议开启后不删除；开启时若提醒包含项目有云项目，会自动下载云项目至本地。

4.4.3 生成提醒单

页面构成：

• 顶部双看板：「待我处理的提醒单」与「所有未处理的提醒单」，各按八类规则分列计数；
• 八类 tab（服务提醒 / 保险提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保）；
• 流程条：①设置提醒规则 → ②车主到店消费 → ③车主完工离店 → ④生成提醒单并跟进 → ⑤临近服务日，提醒车主（可自动发送短信微信）→ ⑥车主再次到店；
• 状态 tab：我未完成 / 我已完成 / 所有未完成 / 所有已完成；
• 提醒单列表字段：提醒单号、客户姓名、手机号、车牌号、上次服务门店、上次服务日期、提醒类别、提醒来源、关联单号；
• 操作区：操作 / 电话提醒 / 发送短信 / 发送微信 / 完成 / 转交 / 列设置。

4.4.4 跟进提醒单

跟进手段四类：

1. SA 发券 —— 服务顾问向车主发放优惠券；
2. SA 电话跟进 —— 通过列表「电话提醒」直接外呼；
3. SA 主动发短信提醒 —— 手动触发短信/微信；
4. 临近服务期系统自动发送短信提醒 —— 由规则的「是否自动提醒」开关驱动。

4.4.5 承接方式

现状三步全部在 F6 PC 端完成（会员营销 > 商机规则设置 / 服务提醒）。App 侧的承接范围曾有四个候选：

方案	范围	优点	代价
A	全不做，仍在 PC 端	零成本	门店移动化诉求落空
B	只做「跟进提醒单」（列表 + 电话/短信/微信/完成）	覆盖高频动作，移动端体验合理	规则配置仍需上 PC；需 F6 开放对应 API
C	三步全部移植	完整闭环	规则配置表单在手机上体验差，工作量大
D	Embedded H5 直接嵌 F6 现有页	开发量最小，不依赖 F6 开放 API	F6 现有页为 PC 版，手机上展示效果受限

提醒模块承接方案候选

已选定方案 D。 判定逻辑是：提醒能力本就属于 F6 的业务范畴，App 的整合目标是消除来回切换系统，而不是把 F6 的功能重做一遍；只要能在 App 内看到并处理提醒单，整合价值就已经兑现。方案 B 虽然移动端体验更好，但需要 F6 额外开放提醒单列表与跟进动作的 API，属外部依赖，首版不引入。

随之接受的两个约束：

• 展示效果降级 —— F6 现有提醒页是 PC 版式（八类 tab + 九列表格），在手机上很可能需要横向滚动。本期接受这一降级，不为其做专门适配。若 F6 能提供移动端页面则直接换 URL，见 TODO(REQ-RMD-007)。
• App 侧无原生能力 —— 提醒单不进入 App 的待办、消息或首页看板，也不参与弱网与离线策略；页面内的一切行为都是 F6 的行为。

4.4.6 业务规则

REQ-RMD-001 承接方式 —— 已定：以 Embedded H5 嵌入 F6 现有提醒页，App 不做原生实现，见 4.4.5

REQ-RMD-002 规则数量上限 —— 最多自定义 20 个提醒规则（F6 侧约束，App 不另设限制）

REQ-RMD-003 自动提醒 —— 规则开启「是否自动提醒」后，临近服务日由 F6 自动发送短信/微信，不经 App

REQ-RMD-004 规则冲突 —— 同一车同一项目命中多条规则时的去重由 F6 规则引擎决定，不属 App 需求范围（已随 REQ-RMD-001 关闭）

REQ-RMD-005 入口可见性 —— 提醒入口对技工是否可见待定 TODO(REQ-RMD-005)；页面内的操作权限由 F6 控制，App 不参与

REQ-RMD-006 短信额度 —— 短信为 F6 侧付费资源，额度不足时由 F6 页面阻断发送并提供购买入口

REQ-RMD-007 移动端页面 —— F6 是否能提供移动端版式的提醒页 URL 待确认 TODO(REQ-RMD-007)；在其提供之前，按 PC 版式嵌入并接受展示降级，见 4.4.5

4.4.7 验收标准

1. 门店未接入 F6 时，提醒入口不显示；
2. 从提醒入口进入后，F6 提醒页正常加载，登录态与门店上下文自动带入，不出现二次登录；
3. 票据过期时容器自动换票并重载，用户无感知；
4. 页面内「电话提醒」可调起系统拨号盘（经容器的 dial 桥接能力，见 7.3）；
5. 切换门店或退出登录后，已打开的提醒页立即失效并关闭。

---

4.5 延保

4.5.1 保障产品与责任边界

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

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

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

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

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

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

数据来源 —— 延保后台

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

4.5.2 消费者激活与门店建单

业务目标：把延保建单从「独立小程序里重新录一遍」变成销售流程的自然延续，解决痛点 2.6。

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

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

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

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

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

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

延保的「待办事项」是独立 tab，与 App 首页待办存在归并关系：延保视频上传提醒已列入首页跨系统待办。归并后延保 tab 内是否保留独立待办页 —— TODO(REQ-WTY-002)。

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

整合后门店切换收敛到 App 全局门店上下文（REQ-HOM-001），延保内不再单独提供切店入口。

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

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

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

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

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

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

保单作废是不可逆的高风险操作。作废权限归属（是否限店长）、是否需要二次确认与作废原因、是否需要后台审批 —— TODO(REQ-WTY-005)。

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

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

销售流程内查看延保：O2O 侧亦提供「查看延保」入口，与销售流程中的延保历史记录同源。

4.5.4 预约与理赔运营

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

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

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

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

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

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

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

CATI 入口同时存在于延保小程序与 O2O 接单宝，两处是否为同一业务、整合后归属哪个模块 —— TODO(REQ-WTY-006)。

4.5.5 售后鉴定与证据采集

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

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

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

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

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

照片与视频为必填证据，涉及弱网环境下的大文件上传。断点续传、失败重试、本地暂存策略见 8.6。

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

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

工作台快捷入口：聚合保单、理赔、返利、教程、店员、数据等核心业务模块，并展示当前门店延保数据和返利简报（见 2.7.4）。

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

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

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

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

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

延保经营数据与 4.12 经营业绩同理，存在口径合并问题 —— TODO(REQ-PRF-004)。

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

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

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

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

延保客服入口：首页提供悬浮式延保客服入口，支持门店在建单、激活和理赔过程中寻求帮助（见 2.7.4）。

其他小程序入口：延保小程序内亦挂有跳转其它小程序的入口，整合后取消（见 现状入口 → App 导航映射）。

4.5.8 需求描述汇总

业务目标 —— 见各子节

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

入口 —— 底部导航「延保」tab；销售结算页跳转（4.3.7）；首页待办「延保视频上传提醒」

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

主流程：

• 建单：扫描/录入车牌 → 绑定车辆 → 上传装车视频 → 保单生效
• 理赔：扫描理赔码/预约码 → 受理 → 采集证据 → 上报 → 跟踪结果

异常流程：

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

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

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

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

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

状态变化：

• 保单：待补充 → 待确认 → 正常 → 已作废
• 预约：预约车检 → 已受理 → 已上报
• 鉴定单：待上传 → 正在进行 → 已完成

4.5.9 业务规则

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

REQ-WTY-002 待办归并 —— 延保待办与首页待办的归并方式待定 TODO(REQ-WTY-002)

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

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

REQ-WTY-005 保单作废 —— 高风险操作，需权限 + 状态校验 + 审计记录；具体管控待定 TODO(REQ-WTY-005)

REQ-WTY-006 CATI 归属 —— 延保与 O2O 两处 CATI 入口的关系待定 TODO(REQ-WTY-006)

REQ-WTY-007 无用户信息鉴定 —— 仅做故障鉴定，不可走延保理赔；必采字段见 4.5.5

REQ-WTY-008 消费者未认证兼容 —— 该状态不影响延保返利及管理端查询；消费者后续扫码可找回保单

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

REQ-WTY-010 条款同意留痕 —— 记录条款版本与同意时间

4.5.10 验收标准

1. 门店未开通延保业务时，延保 tab 不显示；
2. 车牌识别失败可切换手动输入与特殊车牌录入，已录入内容不丢失；
3. 「待绑定车辆」「待补充装车视频」计数与待办列表条数一致，且与首页对应待办项一致；
4. 无关联保单的轮胎进入无用户信息鉴定通道后，界面不提供任何理赔提交入口；
5. 弱网下上传鉴定照片/视频中断后，重新进入可从本地暂存恢复，不需要重新拍摄；
6. 保单作废后，该保单在所有列表与筛选结果中状态一致，且留有操作人与时间的审计记录。

---

4.6 采购

采购覆盖门店要买的全部商品，包括马牌商品与耗材、辅料、其它品牌轮胎，一套浏览、加购、结算、收货、售后流程走到底，门店不需要按品牌切换页面。

数据来源上，马牌商品走 ROOS、其余商品走 F6。ROOS 本身就是马牌在 F6 后台之上自建的采购小程序 —— 品牌方要单独管理并统计各门店对自有品牌的采购情况，才有了这一层；对门店而言仍是同一个采购功能。

4.6.1 需求描述

业务目标 —— 门店在 App 内完成全部品类的订货全流程（搜索 → 加购 → 结算 → 收货 → 售后），覆盖马牌与非马牌商品，并保留 ROOS 的额度、返利、优惠券结算能力，解决痛点 2.3

目标角色 —— 店长：全部；技工：需被授权后功能同店长

入口 —— 底部导航「采购」tab；首页快捷入口「采购」。全部商品同在此 tab 内，按分类 / 品牌逐级筛选

前置条件 —— 已登录、已确定门店；采购马牌商品还需门店在 ROOS 有有效的经销商 / 信用账户

页面内容 —— 商品搜索与树形分类 → 商品列表 → 购物车 → 订单确认（支付方式）→ 我的订单（五状态）→ 订单详情 → 售后/退款；扫码收货

主流程 —— 搜索商品 → 加入购物车 → 调整数量并勾选 → 结算 → 选择支付方式 → 提交订单 → 扫码收货。马牌与非马牌商品的流程完全一致，门店感知不到品牌差异

异常流程：

• 信用额度不足 → 提示并阻断提交
• 商品下架/无库存 → 列表置灰
• 扫码收货条码不匹配 → 提示并拒收

业务规则 —— 见 4.6.7

权限规则 —— 技工默认无采购权限，需店长/后台授权（REQ-PUR-001）

访问链路 —— App → App Backend → ROOS（马牌商品）/ F6（非马牌商品）

逻辑数据来源 —— 马牌商品：ROOS；非马牌商品：F6。两者的底层服务同为 F6，ROOS 是马牌品牌侧的管理与统计层

回写目标 —— 购物车、采购订单、支付方式选择、收货确认、售后申请 → 对应来源系统

状态变化 —— 采购订单：待支付 → 待发货 → 已发货 →（收货）完成；可取消 → 已取消

4.6.2 产品搜索与商品列表

按树形结构列出当前搜索条件；用户点击搜索条件，查询出搜索结果列表。马牌商品的搜索接口来源于 ROOS，非马牌商品来源于 F6，两类结果在同一列表内呈现，门店按品牌 / 分类筛选即可，不需要切换页面。

现状商品列表构成：顶部搜索框 + 左侧树形分类（按品牌 / 花纹 / 规格逐级收窄）+ 右侧商品卡（商品图、名称、规格、品牌标识、单价与计价单位、+ 加购图标）。

4.6.3 购物车与结算

加入购物车：用户点击商品旁边的 + 图标，将商品加入购物车。用户可以调整采购数量，选择商品条目前面的选择图标，点击「结算」按钮进入结算页。

结算与提交订单：用户选择支付方式后，点击「提交订单」，完成采购流程。

信用额度校验：额度不足时在订单确认页给出明确提示并阻断提交。

支付方式的可选集合、优先级与扣账逻辑由「支付优先级设置」决定。整合后支付方式与 CDMS 支付的关系 —— TODO(REQ-PUR-004)。

4.6.4 收货

用户扫描商品，完成收货流程。扫码为 App 原生实现（见 REQ-INT-003），非嵌入 H5。

收货扫码与扫码入库是否为同一动作、是否一次扫码同时完成收货与入库 —— TODO(REQ-PUR-005)。

4.6.5 订单管理与售后

采购订单列表：tag 分为全部、待支付、待发货、已发货、已取消五个状态。

采购订单详情：查看订单流转状态。

售后 / 退款：进入订单详情页面，点击「售后/退款」，进入「售后/退款」流程。

采购订单的五状态（待支付/待发货/已发货/已取消/全部）与 O2O 销售订单的五状态（4.3.5）是两套完全不同的状态机，UI 上必须明确区分，不可复用同一组件文案。

4.6.6 角色差异

角色	权限
店长	搜索、加购、结算、提交订单、收货、查看订单、发起售后
技工	默认不可见；被授权后功能同店长。是否允许技工提交订单（涉及资金）—— TODO(REQ-PUR-002)

4.6.7 业务规则

REQ-PUR-001 采购授权 —— 技工需被显式授权才能进入采购模块；授权维度参见人员管理「可用系统」

REQ-PUR-002 技工下单权限 —— 技工被授权后是否可提交订单待定 TODO(REQ-PUR-002)

REQ-PUR-003 额度校验 —— 提交订单前校验信用额度；不足时阻断并提示

REQ-PUR-004 支付方式 —— 由支付优先级设置决定默认扣账方式；与 CDMS 支付的关系待定 TODO(REQ-PUR-004)

REQ-PUR-005 收货与入库 —— 扫码收货与扫码入库是否合并为一次动作待定 TODO(REQ-PUR-005)

REQ-PUR-006 订单状态机 —— 待支付 → 待发货 → 已发货 →（收货）完成；可取消 → 已取消。与销售订单状态机隔离

REQ-PUR-007 数据来源 —— 商品、价格、库存、订单、售后：马牌商品以 ROOS 为准，非马牌商品以 F6 为准；App 不落地二次计算的价格

REQ-PUR-008 扫码实现 —— 收货扫码使用 App 原生扫码能力，不嵌入第三方 H5 扫码页

REQ-PUR-010 商品域范围 —— 采购覆盖门店需要的全部商品，含马牌商品与耗材、辅料、其它品牌轮胎。只有一个采购入口，门店在同一 tab 内按分类 / 品牌筛选，不因商品来源不同而切换页面。这是痛点 2.1「多系统来回切换」在采购域的最后一块拼图

REQ-PUR-011 购物车与订单是否合并 —— 马牌商品与非马牌商品能否放进同一个购物车、生成同一张订单待确认 TODO(REQ-PUR-011)。合并则需要跨来源的订单拆分与状态聚合；不合并则购物车与订单列表需按来源分列。这是本模块最大的架构分歧点

REQ-PUR-012 非马牌结算与账期 —— 非马牌采购的支付方式、信用额度与账期是否与马牌采购一致待确认 TODO(REQ-PUR-012)。马牌侧的信用额度与支付提醒来自 ROOS / CDMS，非马牌侧是否共用同一套额度未知

REQ-PUR-013 接入路径 —— ROOS 建于 F6 后台之上，F6 侧本身具备采购服务能力。App Backend 是走「马牌经 ROOS、非马牌直连 F6」两条链路，还是统一经 ROOS 代理，待确认 TODO(REQ-PUR-013)。无论哪种，马牌商品的采购记录必须仍然进入 ROOS —— 品牌方按门店统计自有品牌采购情况正是 ROOS 存在的原因。这一条需优先于 REQ-PUR-011 确认

4.6.8 业务数据列表

#	字段	字段名	数据来源	说明
1	商品名称	productName	ROOS
2	商品编码	productCode	ROOS
3	品牌标识	brandTag	ROOS
4	品牌	brand	ROOS	马牌 / 维京 等
5	单价	price	ROOS	不在 App 侧二次计算
6	计价单位	priceUnit	ROOS
7	尺寸	tireSize	ROOS
8	车型	carModel	RMS	车型匹配 TODO(REQ-PUR-009)
9	安装位置	installPositon	ROOS	现有字段名拼写为 installPositon，接口对齐时需确认是否应为 installPosition
10	产品分类	productCategory	ROOS	树形分类

采购业务数据表。上表按马牌商品（ROOS）列出；非马牌商品的同名字段以 F6 为准，字段能否一一对齐随 REQ-PUR-013 的接入路径一并确认。

4.6.9 验收标准

1. 技工未被授权时，采购 tab 不下发、深链跳转也被拦截；
2. 信用额度不足时「提交订单」不可点击，且提示包含可用额度与本单金额；
3. 购物车勾选、数量修改在弱网下不丢失，恢复网络后与后端一致；
4. 采购订单五状态的 tab 计数与列表条数一致；
5. 扫码收货使用原生扫码，无 WebView 加载过程；
6. 采购 tab 内可同时检索到马牌与非马牌商品，两类商品的下单、支付、收货、售后在交互上完全一致，商品来源对门店可见但不改变操作路径；
7. 门店未接入 F6 时，非马牌商品不出现在采购 tab 内且不报错，见门店能力开关。

---

4.7 库存

底部导航的三版方案中，业务菜单版有「库存」tab、设计稿 5 tab 方案有「入库」tab（见 三版底部导航方案）。本节内容由现状截图反推。

业务目标 —— 把「查得到货、扫得进库、对得上账」收敛到 App 内，解决痛点 2.3中「门店无法实时判断可售库存」的问题

入口 —— 底部导航「库存 / 入库」tab；首页快捷入口「扫码入库」「扫码出库」；采购收货流程

页面内容 —— 库存查询（SKU 列表 + 四级轮胎参数筛选）、扫码入库记录、扫码出库、条码库存（入库记录 / 出库记录 / 在库条码）

主流程：

• 查询：选择搜索类型 → 输入关键字或逐级筛选 → 查看 SKU 库存状态与结算价
• 入库：扫描轮胎条码 → 校验 → 写入在库条码 → 生成入库记录

权限规则 —— 店长全量；技工可查询与扫码入/出库，TODO(REQ-INV-001) 确认技工是否可见结算价

数据来源 —— O2O（库存查询、扫码入库）、ROOS（条码库存、扫码出库）

4.7.1 库存查询

设计稿构成：顶部搜索框 + 五个下拉筛选（胎面宽 / 扁平比 / 直径 / 花纹 / 黑科技）→ SKU 卡片列表，每卡显示 SKU 编码、库存状态标签（库存充足 / 库存紧张 / 缺货）、商品图、商品名、规格、级别、小程序结算价。

四级轮胎参数筛选：胎面宽、扁平比、直径、花纹逐级收窄。

现状与目标的三处差异（均需确认）：

#	现状（O2O）	设计稿（App）	说明
1	主键是产品编码，且一行可能是逗号分隔的多个编码	主键是 SKU	两者是否同一概念、多编码如何在 SKU 视图下展示 —— TODO(REQ-INV-002)
2	「库存状态」一列大多为空/置灰，仅个别显示「库存充足」	每条都有库存充足 / 紧张 / 缺货标签	库存状态数据是否已具备全量覆盖能力 —— TODO(REQ-INV-003)
3	无「黑科技」筛选，有「促销」标签	有「黑科技」筛选，无促销标签	两个维度是否都保留 —— TODO(REQ-INV-004)

库存查询现状与目标差异

4.7.2 扫码入库

4.7.3 扫码出库与条码库存

条码库存：在「我的」菜单中点击「条码库存」，进入「条码库存」，tab 为入库记录、出库记录、在库条码。

入库来源双写问题：扫码入库在 O2O 和 ROOS 两侧都有记录（O2O 的「扫码入库」与 ROOS 的「条码库存-入库记录」），经营业绩同时统计「扫码入库总数」与「扫码入库门店数」。整合后是一次扫码双写、还是以其中一侧为准 —— TODO(REQ-INV-005)，这是本模块的关键前置决策。

4.7.4 业务规则

REQ-INV-001 结算价可见性 —— 技工是否可见小程序结算价待定 TODO(REQ-INV-001)

REQ-INV-002 SKU 与产品编码 —— 主键口径待统一 TODO(REQ-INV-002)

REQ-INV-003 库存状态覆盖 —— 库存状态标签的数据覆盖率与刷新频率待定 TODO(REQ-INV-003)

REQ-INV-004 筛选维度 —— 黑科技 / 促销两个维度的取舍待定 TODO(REQ-INV-004)

REQ-INV-005 入库写入目标 —— 扫码入库的权威写入目标待定 TODO(REQ-INV-005)

REQ-INV-006 扫码实现 —— 入库/出库扫码均为 App 原生实现（REQ-INT-003）

REQ-INV-007 重复条码 —— 同一条码重复扫描应拒绝并提示已入库时间与门店

4.7.5 验收标准

1. 四级参数筛选任意组合下，列表结果与筛选条件一致，清空筛选可一键还原；
2. 同一条码重复扫描时给出明确提示，不产生重复入库记录；
3. 扫码入库在断网时可暂存，恢复网络后批量提交且不重复；
4. 库存状态标签与结算价来自同一次查询，不出现价格已更新而状态未更新的错位。

---

4.8 我的 / 个人中心

三套现状小程序各有一个「我的」，本节将其合并为 App 的统一个人中心。

业务目标 —— 提供统一的账号、门店、资产（额度/返利/优惠券/积分）与设置入口，取代三套小程序各自的「我的」

入口 —— 底部导航「我的」tab

页面内容 —— 用户信息卡（头像/姓名/门店/角色标签）+ 资产卡（积分、优惠券）+ 功能列表 + 退出登录

主流程 —— 进入个人中心 → 查看资产 / 进入子功能 → 返回

权限规则 —— 全角色可见；资产类（额度、返利、对账单）建议限店长 TODO(REQ-MIN-002)

数据来源 —— App Backend（账号、门店）、ROOS（账户、优惠券、地址、收藏、支付优先级）、O2O（设置、手机号）、延保后台（姓名、门店）

4.8.1 目标形态

设计稿构成：标题「个人中心」+ 右上设置图标 → 用户卡（头像、账号名「马牌轮胎001」、门店名「光谷八路旗舰店」、角色标签「店长」）→ 双资产卡（积分 460 / 优惠券 56）→ 功能列表（服务热线、经销商客服、地址管理、我的收藏、经营范围、换绑手机）→ 退出登录。

设计稿的功能列表只有 6 项，而三套现状小程序的「我的」合计有 20 余项。哪些进个人中心、哪些下沉到各业务模块 —— TODO(REQ-MIN-001)。本节先按域完整记录现状，作为取舍的输入。

4.8.2 ROOS「我的」（采购域资产）

我的账户：点击「账户」按钮进入「我的账户」。我的账户分为信用额度、未使用返利、优惠券总金额、积分余额。信用额度含可用余额、待还金额、信用额度；未使用返利按品牌明细展示，含返利总额。

优惠券：状态 Tab 为待激活、待生效、待使用、已使用、已失效；券的种类分为马牌券、经销商券。

支付优先级设置：设置是否优先使用扣账支付方式。

收货地址：地址列表含联系人、手机号、详细地址、默认标记。页面提示「扫码入库时，店铺位置以地图定位为准」。

我的收藏：进入「商品收藏列表」。

4.8.3 O2O「设置」（账号与门店）

4.8.4 延保「我的」

4.8.5 合并规则

现状能力	来源	App 归属
头像 / 姓名 / 角色	三套各有	个人中心用户卡（姓名以 App Backend 为准，回写各系统）TODO(REQ-MIN-003)
切换门店	三套各有	收敛为 App 全局门店上下文（REQ-HOM-001），个人中心不再单独提供
修改手机号 / 换绑手机	O2O + 设计稿	个人中心
退出登录	O2O + 设计稿	个人中心，需二次确认（REQ-LGN-008）
在线客服 / 服务热线 / 经销商客服	O2O + 设计稿	个人中心（三个客服入口是否合并 —— TODO(REQ-MIN-004)）
我的账户（额度/返利/券/积分）	ROOS	个人中心资产卡 + 二级页；返利明细见 4.11
优惠券	ROOS + O2O	个人中心；营销侧发放见 4.13
收货地址 / 地址管理	ROOS + 设计稿	个人中心
我的收藏	ROOS + 设计稿	个人中心
支付优先级设置	ROOS	个人中心（或下沉到采购结算）TODO(REQ-MIN-005)
经营范围	O2O + 设计稿	设计稿放在个人中心，现状在店铺管理下 —— 归属待定 TODO(REQ-MIN-006)，现状见 4.9
条码库存	ROOS	下沉到 4.7 库存
对账单	ROOS	下沉到 4.10 财务与对账
经营业绩	ROOS	下沉到 4.12 经营业绩与报表
跳转其它小程序	ROOS	取消

三套「我的」的合并归属

4.8.6 验收标准

1. 个人中心显示的门店与全局门店上下文一致，切店后资产数据同步刷新；
2. 退出登录后本地 Token、门店上下文、缓存业务数据全部清除（见《App 门店上下文与会话管理文档》）；
3. 角色标签与后台下发的角色一致，技工不显示店长专属资产项。

---

4.9 门店管理

业务目标 —— 门店管理的入口在「我的」菜单，门店管理包括门店的基础信息，人员管理，门店项目信息，营业执照信息等

入口 —— 「我的」菜单 → 门店管理；宫格版导航中为一级 tab（见 三版底部导航方案）

页面内容 —— 四个 Tab：基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息；另有人员管理、收款信息、经营范围与开票方式、协议中心

主流程 —— 进入门店管理 → 切换 Tab 查看 → 点击「修改」提交变更 →（如需）等待审核

权限规则 —— 店长可以修改门店基础信息，添加和修改人员，修改门店项目信息，营业执照信息；技工基本没有门店管理权限

数据来源 —— O2O（店铺管理、经营范围、协议）、马上下单（门店主数据）、App Backend（人员与授权）

4.9.1 目标形态

设计稿构成：四 Tab（基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息）→ 门头照 → 门店卡（门店名、门店编码、星级评分）→ 负责人姓名 / 联系方式 / 门店地址 / 收款信息（可进入二级页） → 渠道到期状态列表（高德到期时间 + 已过期、美团到期时间 + 已过期、抖音团购 未上线、百度 未上线）→ 底部「修改」按钮。

人员管理构成：当前操作人卡（姓名 + 店铺管理员标签 + 联系方式）→ 店员卡列表，每张含姓名、权限标签（店长权限）、「账户设置」入口、以及 「可用系统」图标行 → 底部「添加店员」。

「可用系统」是一个独立于角色的授权维度 —— 它意味着人员授权不是单一角色开关，而是「角色 + 可访问子系统集合」的二维模型（如某店员有店长权限但只开通 O2O 与采购）。这与 REQ-PUR-001（技工采购授权）是同一套机制。可用系统的取值集合、与角色的关系 —— TODO(REQ-STM-001)，见 10.2。

4.9.2 门店基础信息与渠道信息

现状 Tab 名为「2.0 店铺信息」，设计稿对应位置为「门店项目信息」。二者是否同一内容 —— TODO(REQ-STM-002)。

4.9.3 营业执照信息

营业执照变更是否需要审核、审核在哪个系统完成 —— TODO(REQ-STM-003)。

4.9.4 经营范围与开票方式

经营范围在设计稿中被放进了个人中心，在现状中属于店铺管理。归属待定 —— TODO(REQ-MIN-006)。

4.9.5 协议中心

协议中心与延保零售商使用条款是两套独立的协议体系，整合后是否合并为统一的「协议与条款」入口 —— TODO(REQ-STM-004)。

4.9.6 业务规则

REQ-STM-001 人员授权模型 —— 角色 + 可用系统的二维授权，取值集合待定 TODO(REQ-STM-001)

REQ-STM-002 Tab 口径 —— 「2.0 店铺信息」与「门店项目信息」的对应关系待定 TODO(REQ-STM-002)

REQ-STM-003 资质变更审核 —— 营业执照等资质变更的审核流程待定 TODO(REQ-STM-003)

REQ-STM-004 协议体系 —— 协议中心与延保条款是否合并待定 TODO(REQ-STM-004)

REQ-STM-005 技工权限 —— 技工基本无门店管理权限，仅可只读查看门店基础信息

REQ-STM-006 渠道到期提醒 —— 高德/美团/抖音/百度等渠道到期应产生首页待办或预警 TODO(REQ-STM-007)

REQ-STM-007 主数据边界 —— 门店主数据来源为马上下单（第 5 章），App 内可改的字段范围待定 TODO(REQ-STM-008)

4.9.7 验收标准

1. 技工进入门店管理时，所有「修改」「添加店员」入口不可见；
2. 门店编码、门店名称等主数据字段为只读，与马上下单一致；
3. 营业执照上传支持拍照与相册两种方式，弱网下失败可重试且不丢失已填字段；
4. 渠道到期状态与实际签约状态一致，已过期渠道有明显视觉标记。

---

4.10 财务与对账

本节内容由 O2O 与 ROOS 的对账 / 提现 / 结算截图反推。

业务目标 —— 让门店在 App 内看清「挣了多少、能提多少、什么时候到账、和厂商怎么对账」，解决痛点 2.4与痛点 2.5

入口 —— 「我的」菜单 → 对账提现 / 对账单；宫格版导航中为一级 tab「账务对账」

页面内容 —— 对账提现（可提现金额 + 收入 + 提现历史）、收入明细、服务结算单、结算单明细、采购对账单、银行账号绑定

主流程：

• 查看可提现金额 → 进入收入/提现历史核对 → 发起提现 → 到账
• 采购侧：按月查看对账单 → 核对汇总与明细

权限规则 —— 建议限店长（涉及资金）TODO(REQ-FIN-001)

数据来源 —— O2O（O2O 收入、提现、服务结算单）、ROOS（采购对账单）

4.10.1 对账提现

页面构成：顶部「可提现金额（元）」大数字 + 规则说明「可提现金额每个工作日 12:30 左右更新，更新金额为上一个工作日至今（不含当天）的已核销订单货款」→ 收入 / 提现历史两个入口 → 交易手续费说明。

上述规则揭示两条关键约束：① 提现金额 T+1 且按工作日更新；② 计入基数的是已核销订单货款 —— 这把核销从一个操作动作提升为资金链路的关键节点。核销 → 可提现的具体计算口径 —— TODO(REQ-FIN-002)。

4.10.2 收入明细

4.10.3 服务结算单

4.10.4 采购对账单

对账单：在「我的」菜单下点击「对账单」，进入「对账单详情」，对账单按月份查看账单详情，汇总支出/收入金额，明细列表。

采购对账单（ROOS，付给厂商）与 O2O 对账提现（收厂商的钱）方向相反，整合后是并列两个入口还是合成一张「资金总览」—— TODO(REQ-FIN-003)。

4.10.5 银行账号

银行账号支持企业账户与个人账户两种类型，绑定/解绑是资金安全的关键操作。是否需要短信验证或后台审核 —— TODO(REQ-FIN-004)。

4.10.6 业务规则

REQ-FIN-001 权限 —— 财务模块建议限店长可见 TODO(REQ-FIN-001)

REQ-FIN-002 可提现金额口径 —— T+1 工作日 12:30 更新；基数为已核销订单货款；具体计算口径待定 TODO(REQ-FIN-002)

REQ-FIN-003 收支合并 —— 采购对账单与 O2O 提现是否合成资金总览待定 TODO(REQ-FIN-003)

REQ-FIN-004 账户绑定安全 —— 银行账号绑定/解绑的二次验证方式待定 TODO(REQ-FIN-004)

REQ-FIN-005 金额一致性 —— App 不做金额二次计算，全部以源系统返回值展示；不同页面同一笔金额必须一致

REQ-FIN-006 手续费透明 —— 交易手续费说明须在提现入口可达

REQ-FIN-007 与 CDMS 支付关系 —— 首页待办中的「CDMS 支付提醒」与本模块的关系待定 TODO(REQ-FIN-005)

4.10.7 验收标准

1. 可提现金额页面明确标注更新时间与统计口径，不出现「金额已变但说明未变」的错位；
2. 收入明细合计与可提现金额可对上，差额部分（未到 T+1、手续费）有明确说明；
3. 技工无法通过任何路径进入财务模块（含深链）；
4. 银行账号解绑必须二次确认，且解绑后提现入口给出明确阻断提示。

---

4.11 返利中心

返利分布在两侧：延保侧有延保返利，O2O 侧另有一套完全独立、维度更丰富的返利体系（9 张截图），设计稿为其单独出了页面。

业务目标 —— 让门店随时看清「这单能拿多少返利、为什么是这个数、核算到哪一步了」，解决痛点 2.4中返利不透明的问题

入口 —— O2O 工具条「返利中心」；宫格版导航一级入口

页面内容：

• 双 Tab：返利详情 / 返利核算
• 顶部订单号搜索 + 四个筛选（渠道 / 品牌 / 标签 / 月份）
• 汇总卡（返利补贴、核算后返利）+ 三项构成（消费者补贴、安装费用、抽奖红包返利）
• 明细列表

主流程 —— 选择月份与筛选 → 查看汇总 → 按标签切换明细 → 展开单条查看构成与状态

权限规则 —— 建议限店长 TODO(REQ-RBT-001)

数据来源 —— O2O（返利核算）、延保后台（延保返利，见 4.5.6）

4.11.1 目标形态

设计稿构成：订单号搜索框 → 返利详情 / 返利核算 双 Tab → 四个筛选（全部渠道 / 全部品牌 / 标签 / 月份，示例 2026-03）→ 橙色汇总卡（返利补贴 ¥30.00、核算后返利 ¥38.00）→ 三项构成卡（消费者补贴 ¥40.00 / 安装费用 ¥12.08 / 抽奖红包返利 ¥1.08，每项带 ⓘ 说明入口）→ 「明细」区，三个标签筛选（消费者补贴 / 安装费用 / 抽奖红包返利）→ 明细卡（商品名+规格、金额、状态标签「已完成」/「退款扣减」、条码、时间戳）。

「返利补贴 ¥30.00」与「核算后返利 ¥38.00」的差额，以及三项构成之和与二者的关系，需要明确的计算公式说明 —— TODO(REQ-RBT-002)。这是门店最容易产生争议的地方。

4.11.2 返利详情与返利核算

4.11.3 多维筛选

4.11.4 返利构成说明

三项返利构成各自带独立的规则说明页，这些说明必须在 App 内完整保留 —— 它们是门店理解返利数额的唯一依据。

4.11.5 业务规则

REQ-RBT-001 权限 —— 返利对技工是否可见待定 TODO(REQ-RBT-001)

REQ-RBT-002 计算口径 —— 返利补贴、核算后返利、三项构成的关系需给出公式说明 TODO(REQ-RBT-002)

REQ-RBT-003 规则说明可达 —— 三项构成的 ⓘ 说明页必须在 App 内保留，不得外链小程序

REQ-RBT-004 与延保返利合并 —— O2O 返利与延保返利是否合并入口待定 TODO(REQ-RBT-004)

REQ-RBT-005 退款扣减 —— 明细中的「退款扣减」状态需与财务收入对齐，同一笔不得两侧不一致

REQ-RBT-006 数据来源 —— 返利金额全部由 O2O 返回，App 不做二次计算（同 REQ-FIN-005）

4.11.6 验收标准

1. 四个筛选任意组合下，汇总卡数值与明细列表合计一致；
2. 每一项返利构成都能点开对应的规则说明，且说明内容与现状小程序一致；
3. 「退款扣减」明细在返利中心与财务收入两处金额与符号一致。

---

4.12 经营业绩与报表

本节内容由 O2O 经营业绩、ROOS 业绩详情与设计稿构建。

业务目标 —— 门店在一处看到订货、入库、售出、延保、收入的全链路经营数据，解决痛点 2.5

入口 —— 「我的」菜单 → 经营业绩；宫格版导航「经营分析」；店长首页业绩卡片

页面内容：

• 三 Tab：1.0 经营业绩 / 2.0 经营业绩 / 2.0 引流转化
• 三个筛选（时间粒度 / 渠道 / 日期）
• 扫码入库双计数、分品牌性能指标、销售统计、收入统计

主流程 —— 选择时间粒度与渠道 → 查看指标卡 → 下钻明细

权限规则 —— 建议限店长；技工可见与其相关的施工量指标 TODO(REQ-PRF-001)

数据来源 —— O2O（O2O 售出、收入、引流转化）、ROOS（签约量、订货量、扫码入库量）

4.12.1 目标形态

设计稿构成：三 Tab（1.0 经营业绩 / 2.0 经营业绩 / 2.0 引流转化）→ 三个筛选（当月 / 全部渠道 / 日期选择）→ 双计数卡（扫码入库总数 / 扫码入库总数（门店））→ 分品牌性能指标卡（马牌、维京，各含入库数 / O2O 售出 / 补货率）→ 销售统计（订单数量 / 轮胎条数 / 延保条数）→ 收入统计（货款收入-结算总额 / 消费者补贴-促销返利 / 抽奖红包返利-其他收入）。

「1.0 / 2.0」是现状 O2O 沿用的版本代号，对门店无业务含义。App 应改用可读的业务命名 —— TODO(REQ-PRF-002)。

4.12.2 现状经营业绩

4.12.3 采购侧业绩详情

业绩详情：在「我的」菜单下，点击「经营业绩」进入「业绩详情」，业绩详情包含签约量、订货量、扫码入库量、O2O 售出量；签约量分为月度签约量、季度签约量；订货量、扫码入库量、O2O 售出量均支持年份 + 月度/季度维度筛选查看。

两套经营业绩的指标高度重叠但口径不同：ROOS 业绩详情与 O2O 经营业绩都统计「扫码入库量」和「O2O 售出量」。合并为一套报表还是并列两个 Tab —— TODO(REQ-PRF-003)，与 REQ-INV-005（入库写入目标）是同一个根因。

延保侧还有第三套经营数据（4.5.6）—— TODO(REQ-PRF-004)。

4.12.4 业务规则

REQ-PRF-001 权限 —— 技工可见的指标范围待定 TODO(REQ-PRF-001)

REQ-PRF-002 命名 —— 「1.0 / 2.0」版本代号需替换为业务可读名称 TODO(REQ-PRF-002)

REQ-PRF-003 报表合并 —— ROOS 与 O2O 两套业绩的合并方式待定 TODO(REQ-PRF-003)

REQ-PRF-004 延保数据并入 —— 延保经营数据是否并入统一报表待定 TODO(REQ-PRF-004)

REQ-PRF-005 月度签约达成预警 —— 首页动态预警中的「月度签约达成」阈值取自签约量指标，规则待定 TODO(REQ-HOM-009)

REQ-PRF-006 首页营收卡片 —— 设计稿的「今日预计营收 / 毛利 / 客单价」在本模块无对应指标，口径待定 TODO(REQ-HOM-011)

4.12.5 验收标准

1. 时间粒度、渠道、日期三个筛选任意组合下，各指标卡与下钻明细口径一致；
2. 同一指标（如扫码入库量）在首页、经营业绩、库存三处显示的数值一致；
3. 技工不可见的指标在接口层即不返回，而非仅前端隐藏。

---

4.13 营销与会员

本节对应痛点 2.4「支付与营销」，内容由 O2O 优惠券、会员权益、门店海报截图构建。

业务目标 —— 让门店在开单现场就能用上券和会员权益，并具备自主获客的物料，解决痛点 2.4

入口 —— O2O 工具条「优惠券」「会员权益」「门店海报」；开单结算流程中的选券环节

页面内容 —— 消费券 / 门店营销券、选择营销券、会员权益选择弹窗、会员体系开通状态、门店海报

主流程：

• 开单选券：结算 → 选择营销券 → 应用 → 计入金额
• 会员权益：开单 → 选择会员权益 → 应用

权限规则 —— 店长可管理；技工在开单时可使用 TODO(REQ-MKT-001)

数据来源 —— O2O（券、会员权益、海报）、ROOS（采购优惠券）

4.13.1 优惠券

券体系有三套并存：O2O 消费券、O2O 门店营销券、ROOS 马牌券/经销商券（4.8.2）。三者适用场景、叠加规则、是否互斥 —— TODO(REQ-MKT-002)。

4.13.2 会员权益

会员体系是门店级能力开关：未开通的门店应隐藏相关入口，而非展示空页面。这是门店能力开关的典型场景。

4.13.3 门店海报

海报涉及保存到相册与分享。App 内需要相册写入权限与分享能力 —— 见 8.4 安全与合规、《App 原生能力集成文档》。分享目标（微信 / 系统分享）—— TODO(REQ-MKT-003)。

4.13.4 业务规则

REQ-MKT-001 权限 —— 技工在开单时可用券与权益，但不可管理 TODO(REQ-MKT-001)

REQ-MKT-002 券体系归并 —— 三套券的适用场景与叠加规则待定 TODO(REQ-MKT-002)

REQ-MKT-003 海报分享 —— 分享目标与相册权限方案待定 TODO(REQ-MKT-003)

REQ-MKT-004 会员能力开关 —— 未开通会员体系的门店隐藏相关入口

REQ-MKT-005 券与返利关系 —— 消费者补贴（返利构成）与消费券是否为同一资金来源待定 TODO(REQ-MKT-004)

4.13.5 验收标准

1. 未开通会员体系的门店，会员权益入口不下发；
2. 开单选券时，不可用券给出不可用原因而非简单置灰；
3. 海报保存失败（无相册权限）时给出可操作的引导，而非静默失败。

---

4.14 福利兑换（MSIP）

积分主体已定：积分挂在门店账下，不归属店员个人。 App 面向经销商，店长与技工都是门店的员工；积分是品牌方发给经销商的福利，因此切换门店时积分随门店上下文一起切换，同门店的店员看到同一份额度。这一条决定了本模块的权限模型与切店行为。

页面内容、积分产生规则与 MSIP 的集成方式仍待补，见 4.14.1。

业务目标 —— 品牌方以积分形式向经销商发放福利，门店用积分兑换商品或权益，作为对门店的激励手段

入口 —— 现状：ROOS / O2O 首页的「积分兑换」（见 2.7.2、2.7.3）；目标：宫格版「福利兑换」（见 4.2.5）或个人中心的积分资产卡

页面内容 —— 待确认 TODO(REQ-MSP-002)

主流程 —— 待确认 TODO(REQ-MSP-002)

权限规则 —— 积分为门店级资产，同门店所有角色看到同一份余额；门店内谁可以发起兑换（是否限店长）待确认 TODO(REQ-MSP-005)

数据来源 —— MSIP

4.14.1 业务规则

REQ-MSP-001 业务目标 —— 已定：品牌方给经销商的福利激励，门店以积分兑换商品或权益

REQ-MSP-002 页面内容与主流程 —— 兑换商品列表、兑换详情、兑换记录的具体形态待补 TODO(REQ-MSP-002)

REQ-MSP-003 积分主体 —— 已定：积分归属门店，不归属店员个人。切换门店时积分随门店上下文切换（与门店切换的级联失效规则一致，见 REQ-LGN-010）；同门店所有角色看到同一份额度

REQ-MSP-004 集成方式 —— MSIP 是否提供 API，还是只能以 Embedded H5 嵌入待确认 TODO(REQ-MSP-004)。若只能嵌 H5，则与提醒同为容器方案，集成矩阵需相应调整

REQ-MSP-005 兑换权限 —— 积分虽属门店，但门店内是否限店长发起兑换待确认 TODO(REQ-MSP-005)

REQ-MSP-006 积分产生规则 —— 积分如何产生（订货 / 扫码入库 / 延保建单 / O2O 核销，或由品牌方后台直接发放）待确认 TODO(REQ-MSP-006)。这决定本模块与哪些业务模块联动，以及 App 内是否需要展示积分获取明细

---

5 主数据

主数据是全 App 各模块共同依赖的基础数据，其来源与同步方式决定了整合后的数据一致性。

5.1 主数据来源

#	类型	来源	同步方式	说明
1	产品主数据	SAP、CDMS	Tire：通过 SFTP 文件获取 SAP price catalog Non-tire：先确认 CDMS 非轮数据的来源 TODO(REQ-MDM-001)	非轮数据来源是本项的前置阻塞点
2	零售主数据	马上下单	通过 API 获取增量、全量；CSO 的数据也会同步马上下单	含门店、经销商等零售侧基础数据
3	门店主数据	马上下单	API	门店基础信息、服务信息、营业执照、渠道信息、人员，见 4.9
4	车型主数据	RMS	TODO(REQ-MDM-002)	车型匹配，见 4.3.2、4.6.8 业务数据列表
5	用户与权限主数据	App Backend	内部	账号、角色、可用系统授权，见 4.1、6.3、6.4
6	积分主数据	MSIP	TODO(REQ-MSP-004)	见 4.14

主数据来源

5.2 主数据使用原则

REQ-MDM-003 —— App 不是主数据的权威源。所有主数据字段在 App 内默认只读；可编辑字段必须显式列出并回写到权威源

REQ-MDM-004 —— 价格以源系统返回值为准，App 侧不做二次计算（同 REQ-PUR-007、REQ-FIN-005）

REQ-MDM-005 —— 产品主数据经 SFTP 文件同步，存在时延；App 需展示数据口径时间，避免门店以为是实时价 TODO(REQ-MDM-005)

REQ-MDM-006 —— 门店主数据变更后，需级联刷新所有已缓存的门店上下文（见《App 门店上下文与会话管理文档》）

CDMS 非轮数据来源未定（REQ-MDM-001），它直接卡住采购中的非轮产品分类与商品域，见 10.2。

---

6 后台管理

后台管理是运营方（非门店）使用的 Web 端，与 App 共用一套 App Backend。

6.1 后台用户登录

后台管理员，通过用户名或验证码方式安全登录平台。

目标角色 —— 运营管理员（非门店角色，与店长/技工体系隔离）

权限规则 —— 后台账号与 App 账号不互通 TODO(REQ-ADM-001)

数据来源 —— App Backend

6.2 后台管理首页

首页看板构成：

区域	内容
左侧菜单	主页 / 用户账号管理 / RBAC 权限体系 / APP 配置 / 接口监控中心 / 基础数据配置 / 系统管理信息 / 日志查询
实时业务异常告警	置顶告警条
统计卡（4 张）	总营业门店 / 累计注册用户 / 7 日活跃用户 / 90 天僵尸用户
门店客户转化漏斗	转化率分析
APP 各功能当日访问趋势	折线图，数据源为埋点
三类接口性能监控	后台接口 / 小程序接口 / F6 接口，SLA 200ms

后台管理首页看板构成

左侧菜单中的 APP 配置与基础数据配置两项需特别说明：

• APP 配置正是角色化 tab 下发的配置端 —— 这一项是 App 导航模型能落地的前提。其配置粒度（按角色 / 按门店能力 / 按单店覆盖）—— TODO(REQ-ADM-002)。
• 基础数据配置与 5 主数据的关系 —— TODO(REQ-ADM-003)。

6.3 用户账号管理

门店与后台用户账号的全生命周期管理。

页面内容 —— 账号列表、账号详情、创建/停用/删除、重置密码、绑定门店

关联 —— 对应 App 侧的注册审核（REQ-LGN-002）与人员管理

待确认 —— 账号审核流是在后台还是由店长在 App 内完成 TODO(REQ-ADM-004)

6.4 RBAC 权限管理

用户权限管理。

页面内容 —— 角色定义、权限点维护、角色-权限绑定、用户-角色绑定

关联 —— 首版角色仅店长/技工；「可用系统」维度（REQ-STM-001）需在此建模

待确认 —— 角色是全局定义还是可按门店自定义 TODO(REQ-ADM-005)

6.5 接口监控

监控 APP 后台调用其它外围系统的健康状态。

监控对象 —— 后台接口 / 小程序接口（ROOS、O2O、延保、马上下单）/ F6 接口

指标 —— 响应时间（SLA 200ms）、成功率、错误码分布

关联 —— 与集成矩阵一一对应；告警联动见《后端可观测性文档》

待确认 —— 200ms 是 P50 还是 P95、是否分接口分级 TODO(REQ-ADM-006)

6.6 系统管理

一、消息公告管理 —— 对应 App 的公告/通知与首页顶部滚动促销提示。

二、系统数据字典管理 —— 与 5 主数据、6.2 的「基础数据配置」的边界 TODO(REQ-ADM-003)。

6.7 日志查询

查询后台用户的操作日志。

门店侧的高风险操作（保单作废、银行账号解绑、人员授权变更）是否也需进入同一套审计日志 —— TODO(REQ-ADM-007)。日志脱敏要求见《后端可观测性文档》。

6.8 埋点

埋点方案见仓库文档《App 可观测性与埋点文档》。

该文档记录：客户端埋点选型为神策，但本项目没有现成账号，开通属采购流程，属跨文档阻塞项，见 10.3。崩溃上报不引入独立崩溃平台，由现有的腾讯 Bugly（原生崩溃 / ANR）加神策自定义事件（Dart 异常明细）共同承担，错误看板在神策上二次开发。

因此神策的可用性同时决定埋点与错误看板两件事，权重比原先更高。

后台首页看板的「APP 各功能当日访问趋势」「门店客户转化漏斗」「7 日活跃 / 90 天僵尸用户」全部依赖埋点数据 —— 埋点方案不落地，后台首页看板就是空的。

---

7 系统集成与架构边界

本章说明 App 与各外部系统的连接方式。技术结论来自既有架构文档（《App 工程结构与分包架构文档》–《App 工程规范与 CI 门禁文档》、《后端工程结构文档》–《后端并发、事务与定时任务文档》），这些结论优先于任何前期材料。

7.1 访问链路原则

REQ-INT-001 —— Mobile App → App Backend 是唯一主链路。App 不直连任何外围系统（ROOS / O2O / 延保后台 / 马上下单 / RMS / MSIP / F6）

REQ-INT-002 —— 外围系统由 App Backend 的集成层统一代理，采用同步 RestClient + Resilience4j，不引入响应式栈（见《后端集成层设计文档》）

REQ-INT-003 —— 扫码是 App 原生实现（native_scan），同时服务原生页面与 H5 的 JSBridge。不嵌入第三方扫码页

REQ-INT-004 —— 门店上下文（storeId/storeCode/orgId/roleCode）由 App Backend 统一签发，切店时级联失效所有缓存（见《App 门店上下文与会话管理文档》）

REQ-INT-005 —— 单个外围系统不可用时局部降级，不阻断整个页面（见《后端跨域协作与聚合文档》）

REQ-INT-003 是对前期材料的明确纠正。 《Conti Retail APP 功能模块与数据来源整理》 在第 2.4 节「扫一扫」、第 3.2.1 节「首页扫码」、第 4.5 节「收货」三处均写「Involve F6 Page / 嵌入 F6 扫码页面」。这与《App 原生能力集成文档》 和《App Embedded H5 容器与 JSBridge 文档》 的结论冲突，以架构文档为准。原因：通用扫码库解条码/二维码，VIN 与车牌需要 OCR，二者都要作为原生能力提供给 H5，嵌一个 H5 扫码页反而多一层。参见《文档仓库说明》。

7.2 集成矩阵

#	外围系统	承载模块	集成方式	关键数据
1	ROOS	4.6 采购（马牌商品）、4.7 库存、4.8 我的、4.10 财务、4.12 业绩	API	商品、价格、购物车、采购订单、售后、信用额度、优惠券、条码库存、对账单、业绩
2	O2O 接单宝	4.3 销售、4.7 库存、4.9 门店管理、4.10 财务、4.11 返利、4.12 业绩、4.13 营销会员	API	线上订单、服务单、核销、库存查询、扫码入库、店铺管理、对账提现、返利、经营业绩、券与会员
3	延保后台	4.5 延保	API	保单、预约、理赔、售后鉴定、返利、教程
4	马上下单	4.9 门店管理、5 主数据	API（增量 + 全量）	门店主数据、零售主数据、人员
5	F6	4.3 销售（到店记录/开单/施工查车/结算）、4.4 提醒、4.6 采购（非马牌商品）	Embedded H5 + Adapter；非马牌采购的接入路径 TODO(REQ-PUR-013)	到店记录、工单、检测报告、商机、结算收银、提醒规则、非马牌商品与订货
6	RMS	4.3 销售车型匹配	TODO(REQ-INT-006)	车型主数据
7	MSIP	4.14 福利兑换	TODO(REQ-MSP-004)	积分、兑换
8	SAP	5 主数据	SFTP 文件	Tire price catalog
9	CDMS	5 主数据、首页待办	TODO(REQ-MDM-001)	非轮产品数据、支付提醒
10	短信网关	4.1 登录、检测报告发送	第三方	验证码、报告短信
11	企业微信	客服入口	TODO(REQ-MIN-004)	O2O / 延保客服

系统集成矩阵

ROOS 与 CDMS 的命名存在混用：采购走 ROOS、首页待办写 CDMS 支付、主数据写 SAP + CDMS。二者是同一系统的不同叫法，还是两套系统 —— TODO(REQ-INT-007)。这直接影响集成矩阵第 1 与第 9 行是否应合并。

7.3 F6 集成边界

F6 是唯一以 Embedded H5 方式集成的外围系统，其余系统一律走 API。以 H5 承接的是销售的到店记录 / 开单 / 施工查车 / 结算与提醒全部功能；采购中的非马牌商品则需要 F6 开放商品与订货 API，是 F6 集成中唯一的 API 面 —— 即 F6 一家同时占用两种集成方式。需注意马牌采购所走的 ROOS 本身也建于 F6 后台之上，因此 F6 的实际影响面比矩阵中列出的更大。

维度	约定
容器	core_webview，基于 webview_flutter（Flutter 官方维护）
URL 来源	只接受 App Backend 换票后下发的 URL，路由里不传裸 URL
桥接通道	单一 JavaScript Channel ContiBridge，协议 {id, method, params}
适配层	App Backend 侧的 F6 Integration Adapter
导航栏	同时提供「返回」与「关闭」；Android 物理返回键必须拦截，与「返回」同语义
缓存	走 WebView HTTP 缓存，首版不做离线包

F6 集成边界

JSBridge 能力清单（详见《App Embedded H5 容器与 JSBridge 文档》）：

method	说明	底层
scan	打开扫码（barcode/vin/plate）	native_scan
camera	打开相机拍照	native_media
pickImage	打开相册（支持多选）	native_media
uploadFile	上传图片/文件（带进度事件）	core_network
dial	调起拨号（不直接拨出）	native_device
closePage	关闭当前 H5 页	core_router
goBack	H5 内返回上一页（无历史降级为 closePage）	WebView
refresh	刷新页面	WebView
getAuthState	获取登录态 / 触发换票（不返回 token 明文）	core_auth
getStoreContext	获取门店上下文	core_auth
toast / dialog / loading	原生提示控件	core_ui
navigate	跳转 App 原生页（路由白名单）	core_router
setTitle	设置导航栏标题	core_ui

JSBridge 能力清单

能力条目数在不同文档中记法不一（计划稿记 13 项、前期 PRD 记 12 项）。按《App Embedded H5 容器与 JSBridge 文档》 的分行方式，本表为 13 行，但因 toast / dialog / loading 合并为一行，实际 method 名共 15 个。以《App Embedded H5 容器与 JSBridge 文档》 为准，本表仅为需求侧引用。

F6 集成的四个关键异常场景（《App Embedded H5 容器与 JSBridge 文档》 已定方案）：票据过期、白屏/超时、上传中断、门店切换/登出。

F6 覆盖率问题：并非所有门店都接入 F6。未接 F6 的门店，销售的到店记录、开单、施工查车、结算全链路如何提供 —— TODO(REQ-INT-008)。随着提醒整体落在 F6 上、采购的非马牌商品也由 F6 供货，未接 F6 的门店会一次性失去提醒模块与半个采购模块，这使 F6 成为门店能力开关中影响面最大的一个开关。该问题也是《Conti Retail APP 功能模块与数据来源整理》第 3.2.1 节自己提出的（「要考虑未接 F6 的车辆如何处理？」）。

7.4 门店能力开关

不同门店开通的业务不同，App 必须按门店能力下发功能，而非全量展示后再报错。

开关	影响	现状实证
是否接入 F6	销售全链路	TODO(REQ-INT-008)
是否开通延保	延保 tab	延保为独立小程序，非全部门店安装
是否开通会员体系	会员权益	4.13.2 会员体系门店-未开通
是否开通 CATI	CATI 理赔	4.5.4 认证轮胎技术检测中心
单独服务项开通情况	服务单可选项目	4.9.4
渠道开通状态	订单渠道（高德/美团/抖音/百度）	4.9.1 设计稿渠道信息
可用系统授权	各 tab 可见性	4.9.1 人员管理「可用系统」

门店能力开关

REQ-INT-009 —— 能力开关由 App Backend 在登录/切店时随门店上下文一次性下发，客户端不自行推断

REQ-INT-010 —— 未开通的能力不下发入口，而非展示后提示「未开通」

REQ-INT-011 —— 能力开关 + 角色共同决定 tab 集合（见 4.2.5）

REQ-INT-012 —— 深链/推送跳转到未开通模块时，需有统一的兜底页

---

8 非功能需求

各项指标多数尚未由业务方给出，本章先建立条目与责任归属，逐条标注 TODO。

8.1 性能

REQ-NFR-001 冷启动 —— TODO(REQ-NFR-001)

REQ-NFR-002 首页首屏 —— 首页聚合多个外围系统（待办来自 O2O + 延保，预警来自 ROOS + O2O），需并行 fan-out 且局部降级（《后端跨域协作与聚合文档》）。目标值 TODO(REQ-NFR-002)

REQ-NFR-003 接口 SLA —— 后台/小程序/F6 三类接口监控口径为 200ms（6.5），P50/P95 归属待定 TODO(REQ-ADM-006)

REQ-NFR-004 扫码识别 —— 条码/二维码、VIN、车牌三种模式的识别时延与成功率 TODO(REQ-NFR-004)

REQ-NFR-005 H5 首屏 —— F6 页面白屏超时阈值与重试策略见《App Embedded H5 容器与 JSBridge 文档》

REQ-NFR-006 并发 —— 门店总数与日活峰值 TODO(REQ-NFR-006)

8.2 统一交互规则

整合六套小程序，最大的隐性风险是同一业务概念在不同来源页面上叫法与交互不一致。

REQ-NFR-007 —— 统一设计系统：core_ui 的 Material 3 主题与设计 token（对应仓库待编的《UI 设计系统文档》）

REQ-NFR-008 —— 同名不同义必须消歧：如采购订单五状态与销售订单五状态、两套返利、三套经营业绩、三套券

REQ-NFR-009 —— 版本代号（「1.0/2.0 经营业绩」「2.0 店铺信息」）不得出现在 App 界面 TODO(REQ-PRF-002)

REQ-NFR-010 —— H5 页面的 toast/dialog/loading 使用原生控件，保证与原生页视觉一致

REQ-NFR-011 —— 首版单语言，但需预留 flutter_localizations + intl 结构

8.3 可用性与容错

REQ-NFR-012 —— 单一外围系统故障时局部降级，首页其余卡片正常展示并标注「暂不可用」

REQ-NFR-013 —— 统一错误处理与 ApiResult 契约（见《App 错误处理与 API 契约文档》）

REQ-NFR-014 —— 错误码为 5 位数字、前 2 位为域段（10xxx 平台通用、11xxx 认证与门店、20xxx/21xxx 采购/库存、3xxxx 外部系统集成）。基础码已定，各域业务码在开发对应模块时随接口增补；客户端对未识别的码统一展示后端返回的提示文案

REQ-NFR-015 —— 崩溃上报：腾讯 Bugly（原生崩溃 / ANR）；Dart 异常明细与错误看板：神策自定义事件；客户端埋点：神策。神策账号可用性为阻塞项，见 10.3

8.4 安全与合规

REQ-NFR-016 —— 全链路 HTTPS

REQ-NFR-017 —— JWT + refresh 轮换，门店上下文参与越权隔离（见《后端安全与认证文档》）

REQ-NFR-018 —— H5 不传递 token 明文，getAuthState 只返回状态并触发换票

REQ-NFR-019 —— 日志脱敏：手机号、车牌、身份证、银行账号（见《后端可观测性文档》、《App 可观测性与埋点文档》）

REQ-NFR-020 —— 用户协议与隐私政策须在注册/登录前可查看并确认

REQ-NFR-021 —— 权限申请：相机（扫码/拍照）、相册读写（海报保存、证据上传）、定位（扫码入库以地图定位为准）、拨号

REQ-NFR-022 —— 高风险操作二次确认 + 审计：保单作废、银行账号解绑、人员授权变更、登出

REQ-NFR-023 —— 数据出境：首版不涉及（崩溃、埋点、车牌识别均落在境内服务）。但车辆照片会上传至第三方 OCR 服务进行识别，属须告知的处理行为，必须写入隐私政策；照片在服务端为临时对象、识别完成后按生命周期规则自动清除。引入任何境外 SaaS 前须重新评估

8.5 兼容性

REQ-NFR-024 平台 —— 首版 Android / iOS；鸿蒙 OHOS 不在首版内（SDK 基线锁 3.44.9 为后续 OHOS 适配留窗口）

REQ-NFR-025 最低系统版本 —— TODO(REQ-NFR-025)

REQ-NFR-026 设备形态 —— 门店常用机型与屏幕尺寸清单 TODO(REQ-NFR-026)

REQ-NFR-027 暗色模式 —— 是否首版支持 TODO(REQ-NFR-027)

8.6 弱网与离线

门店场地（地下车库、仓库、施工区）网络条件差，而恰恰是这些场景要上传大文件。

REQ-NFR-028 —— 装车视频、鉴定照片/视频、营业执照、检测报告上传须支持失败重试与本地暂存

REQ-NFR-029 —— 扫码入库在断网时可本地暂存，恢复后批量提交且幂等不重复

REQ-NFR-030 —— 购物车勾选与数量修改在弱网下不丢失

REQ-NFR-031 —— H5 上传中断的恢复策略见《App Embedded H5 容器与 JSBridge 文档》

REQ-NFR-032 —— 离线可读的数据范围（如今日待办、当前施工队列）TODO(REQ-NFR-032)

REQ-NFR-038 —— 车牌识别依赖网络（云端 OCR），断网或弱网下不可用：「手工输码」须为常驻并列入口；识别失败不自动重试，直接引导至手工输码

8.7 包体积与发布

REQ-NFR-033 包体积上限 —— TODO(REQ-NFR-033)

REQ-NFR-034 多环境 —— dev / uat / prod flavor（见《App 多环境构建文档》）

REQ-NFR-035 iOS 构建 —— 由远程 Mac 出包；首版手工执行仓库内构建脚本，后续接入流水线

REQ-NFR-036 内测分发 —— Android 走托管的 OTA 分发页，iOS 走 TestFlight；不使用 Firebase App Distribution

REQ-NFR-037 强制升级 —— 是否需要版本强制升级机制 TODO(REQ-NFR-037)；若需要，倾向与内测分发一并收进后台的「APP 发布管理」功能

---

9 验收标准

各模块的验收标准已随模块给出（4.1.6、4.2.8、4.3.10、4.4.7、4.5.10、4.6.9、4.7.5、4.8.6、4.9.7、4.10.7、4.11.6、4.12.5、4.13.5）。本章只列跨模块的整合类验收，即「六套小程序合成一个 App」这件事本身是否做成了。

9.1 验收原则

REQ-ACC-001 —— 每条验收标准必须可由一名不了解实现的测试人员在真机上独立执行并判定通过/失败

REQ-ACC-002 —— 带 TODO 的需求在其待确认项关闭前不进入验收范围；关闭后须补写对应验收标准

REQ-ACC-003 —— 验收环境须覆盖已接入 F6 与未接入 F6 两类门店（见 REQ-INT-008）

9.2 整合类验收

这九条直接对应第 2 章的六类痛点，是本项目「做没做成」的判据：

#	验收标准	对应痛点
1	店长与技工完成各自一天的完整业务旅程，全程不跳出 App、不打开任何微信小程序	2.1
2	App 内不存在任何跳转其它小程序的入口（ROOS 四个互跳入口、延保「其他小程序入口」全部移除）	2.1
3	一次登录后，访问采购、销售、延保、库存、财务各模块均无需二次登录或再次选店	2.1、2.2
4	全局只有一套底部导航；切换角色（店长↔技工）后 tab 集合随之变化，且变化仅由后端下发驱动	2.1
5	技工账号在任何路径下（含深链、推送、H5 内 navigate）都无法访问未授权模块	2.2
6	同一业务数据（如扫码入库量、某笔订单金额）在首页、模块页、报表页三处显示一致	2.3、2.5
7	返利、优惠券、可提现金额三类金额均可点开查看构成与规则说明，不出现无解释的数字	2.4
8	延保建单可从销售结算页直接跳转带参进入，不需要重新输入车牌	2.6
9	门店未开通的能力（延保、会员体系、CATI、F6）入口不出现，而非出现后报错	7.4

整合类验收标准

9.3 角色与权限验收

#	验收标准
1	以技工账号登录，附录 B 权限矩阵中标记为「✗」的操作在 UI 上不可见，且接口层直接拒绝
2	店长授予/收回技工的模块授权后，技工端下次进入 App 即生效，无需重装
3	切换门店后，上一门店的业务数据缓存全部失效，不出现串店数据
4	登出后重新打开 App 不自动登录；本地 Token、门店上下文、业务缓存全部清除

角色与权限验收标准

9.4 集成验收

#	验收标准
1	App 抓包确认只与 App Backend 通信，无对 ROOS/O2O/延保/F6 的直连请求
2	F6 页面在 App 内以 Embedded H5 打开，导航栏同时具备「返回」与「关闭」，Android 物理返回键与「返回」同语义
3	在 F6 H5 页内调用扫码，弹出的是 App 原生扫码界面，不是网页扫码
4	H5 内票据过期时可自动换票续期，用户已填写的表单内容不丢失
5	任一外围系统返回超时/错误时，首页其余卡片仍正常展示并对故障区域标注「暂不可用」
6	门店切换或登出时，已打开的 H5 容器被正确关闭或刷新，不残留上一门店上下文

集成验收标准

9.5 非功能验收

#	验收标准
1	弱网（限速/断网）下，装车视频、鉴定照片、营业执照上传中断后可恢复，已拍摄内容不丢失
2	断网下扫码入库可暂存；恢复网络批量提交后，条码数量与实际扫描数一致且无重复
3	同一条码重复扫描被拒绝，并提示已入库时间与门店
4	日志与崩溃上报中不出现手机号、车牌、身份证、银行账号明文
5	所有高风险操作（保单作废、银行账号解绑、人员授权变更、登出）均有二次确认与审计记录

非功能验收标准

---

10 风险与待确认项

本章汇总全部未决事项。共 13 项需求冲突、97 项编号待确认项、1 项跨文档阻塞项（原 6 项中的 5 项已于 2026-08 裁决，结论见 10.3）。

10.1 需求冲突清单

以下冲突源于「业务需求 / 设计稿 / 现状小程序 / 架构文档」四方材料之间的不一致，需业务方裁决。

#	冲突	各方说法	本文档处理	关联
C1	底部导航三版	业务需求 4 tab（首页/库存/采购/我的）· 设计稿 5 tab（首页/入库/采购/延保/我的）· 宫格版（首页/门店管理/经营分析/账务对账/个人中心 + 8 宫格）	已定原则：App 导航为主、按角色 + 门店能力下发；各角色具体 tab 清单待确认	4.2.5 TODO(REQ-HOM-010)
C2	待办口径两层	业务需求：跨系统提醒（O2O 接单/CDMS 支付/延保视频/问卷/门店信息）· 设计稿：O2O 订单五状态	两层并存写入，标注各自来源；最终展示形态待定	待办事项两层口径 TODO(REQ-HOM-008)
C3	动态预警口径	业务需求四项（总数/月度签约/库存/时效订单）· 设计稿仅低库存	列全集，阈值待定	动态预警项 TODO(REQ-HOM-009)
C4	技术路线	前期 PRD 表头写「React Native / 备选 Flutter」	全文按 Flutter（01–14 全部基于 Flutter）	《文档仓库说明》
C5	扫码归属	《Conti Retail APP 功能模块与数据来源整理》第 2.4 / 3.2.1 / 4.5 节写「嵌入 F6 扫码页」	按 App 原生实现（native_scan + JSBridge）	REQ-INT-003
C6	角色模型	业务需求 店长/技工 · 前期 PRD 八角色	正文用店长/技工，八角色列为后续扩展	3.1
C7	ROOS / CDMS 关系	命名混用：采购走 ROOS、待办写 CDMS 支付、主数据写 SAP + CDMS	术语表标注，二者关系待确认	系统集成矩阵 TODO(REQ-INT-007)
C8	首页营收卡片	设计稿有「今日预计营收/毛利/客单价」· 业务需求无此项	写入 4.2 并标待确认口径	4.2.3 TODO(REQ-HOM-011)
C9	MSIP 福利兑换	ROOS/O2O 首页均有「积分兑换」入口 · 宫格稿有「福利兑换」· 业务需求仅在背景中提过一次	立 4.14 章；业务目标与积分主体已确认，页面内容与集成方式待补	TODO(REQ-MSP-002)、TODO(REQ-MSP-004..006)
C10	RMS / 零售管理	背景列为整合目标或截图出现入口，均无需求描述	范围待确认	系统集成矩阵 TODO(REQ-INT-006)
C11	O2O 独有功能无归属	平安账号、服务项报名、门店海报、服务结算单、会员权益、经营范围、协议中心	分别归入 4.9/4.10/4.13，需求细节待补	TODO(REQ-STM-*)、TODO(REQ-MKT-*)
C12	遗留未定事项	扫码核销流程、问卷提醒、月度签约达成预警、后台首页 index、CDMS 非轮数据来源	逐条转为编号待确认项；后台首页 index 已由原型图解决并关闭	TODO(REQ-SAL-010)、TODO(REQ-HOM-014)、TODO(REQ-HOM-009)、6.2、TODO(REQ-MDM-001)
C13	技工「当前施工队列」	设计稿技工首页有独立施工队列分区 · 业务需求完全无此项	写入 4.2.4，分派规则与状态机待定	TODO(REQ-HOM-012)、TODO(REQ-SAL-014)

需求冲突清单

C1 是所有冲突里优先级最高的一条 —— 导航 tab 清单不定，6.2 后台「APP 配置」就无法建模，各模块的入口也无法定稿。

10.2 待确认项清单

97 项，按模块分组。建议决策方一列为本文档的建议，非最终分工。

10.2.1 登录（LGN）

编号	待确认内容	建议决策方
REQ-LGN-001	验证码单日获取上限	安全 / 后端
REQ-LGN-003	微信/支付宝第三方登录是否纳入本期（仅见于设计稿）	产品
REQ-LGN-004	注册表单字段、审核人、审核时效（设计稿有「我要注册」）	产品 / 运营
REQ-LGN-006	密码长度、复杂度、有效期、历史密码不可复用条数	安全
REQ-LGN-007	登录失败锁定阈值与锁定时长	安全
REQ-LGN-009	access / refresh token 有效期	安全 / 后端
REQ-LGN-011	角色（RoleCode）的权威来源是 O2O 后台还是 APP 后台	架构

10.2.2 首页与导航（HOM）

编号	待确认内容	建议决策方
REQ-HOM-001	技工是否允许多门店（设计稿技工版无切店器）	产品
REQ-HOM-002	问候语时段划分口径	产品
REQ-HOM-003	消息分类体系；技工是否有消息公告	产品
REQ-HOM-008	待办两层口径的最终展示形态（C2）；技工是否有待办	产品
REQ-HOM-009	四项动态预警的触发阈值（C3）；技工是否有预警	业务
REQ-HOM-010	各角色的具体 tab 清单（C1，最高优先级）	产品
REQ-HOM-011	「今日预计营收 / 毛利率 / 客单价」口径（C8）	财务 / 业务
REQ-HOM-012	技工「当前施工队列」的分派规则与状态机（C13）	产品 / 业务
REQ-HOM-014	待办中「问卷提醒」的数据来源	业务
REQ-HOM-015	待办中「过期门店信息更新提醒」的数据来源	业务

10.2.3 销售（SAL）

编号	待确认内容	建议决策方
REQ-SAL-001	交易流水号生成规则（前缀/门店码/日期/序列/跨天重置）	架构
REQ-SAL-010	扫码核销详细流程（核销码格式、与订单状态关系、重复/撤销核销、错误分类）	业务
REQ-SAL-011	结算后跳延保的参数契约（F6 → App → 延保后台）	架构
REQ-SAL-012	金额类字段对技工的可见性	产品 / 业务
REQ-SAL-013	订单渠道清单（抖音/天猫/京东）是否可配置	产品
REQ-SAL-014	O2O 服务单与 F6 工单的关系与主从	架构 / 业务

10.2.4 提醒（RMD）

编号	待确认内容	建议决策方
REQ-RMD-005	提醒入口对技工是否可见	产品
REQ-RMD-007	F6 能否提供移动端版式的提醒页 URL	架构 / F6

10.2.5 延保（WTY）

编号	待确认内容	建议决策方
REQ-WTY-002	延保待办与首页待办的归并方式	产品
REQ-WTY-003	技工可执行的延保操作范围	产品
REQ-WTY-004	延保返利对技工是否可见	产品
REQ-WTY-005	保单作废的权限、二次确认、作废原因、是否需后台审批	业务 / 安全
REQ-WTY-006	延保与 O2O 两处 CATI 入口的关系与归属	业务

10.2.6 采购（PUR）

编号	待确认内容	建议决策方
REQ-PUR-002	技工被授权后是否可提交订单（涉及资金）	业务
REQ-PUR-004	支付方式与 CDMS 支付的关系	财务 / 架构
REQ-PUR-005	扫码收货与扫码入库是否合并为一次动作	业务
REQ-PUR-009	车型字段（carModel）是否取自 RMS	架构
REQ-PUR-011	马牌与非马牌商品是否共用购物车与订单（合并需跨来源拆单与状态聚合）	架构 / 产品
REQ-PUR-012	非马牌采购的支付方式、信用额度与账期是否与马牌一致	业务 / 财务
REQ-PUR-013	非马牌商品是直连 F6 还是经 ROOS 代理（需保证马牌采购记录仍进 ROOS）	架构 / F6

10.2.7 库存（INV）

编号	待确认内容	建议决策方
REQ-INV-001	技工是否可见小程序结算价	业务
REQ-INV-002	SKU 与产品编码的口径统一（一行多编码如何呈现）	业务 / 架构
REQ-INV-003	库存状态标签的数据覆盖率与刷新频率	业务
REQ-INV-004	「黑科技」与「促销」两个筛选维度的取舍	产品
REQ-INV-005	扫码入库的权威写入目标（O2O / ROOS / 双写）	架构

10.2.8 我的（MIN）

编号	待确认内容	建议决策方
REQ-MIN-001	个人中心保留哪 6 项、其余下沉到哪些模块	产品
REQ-MIN-002	资产类（额度/返利/对账单）是否限店长	业务
REQ-MIN-003	姓名的权威来源与回写范围	架构
REQ-MIN-004	服务热线 / 经销商客服 / 企微客服三个入口是否合并	产品
REQ-MIN-005	支付优先级设置放在个人中心还是采购结算	产品
REQ-MIN-006	「经营范围」归属个人中心还是门店管理	产品

10.2.9 门店管理（STM）

编号	待确认内容	建议决策方
REQ-STM-001	「可用系统」授权模型（取值集合、与角色的关系）	架构 / 产品
REQ-STM-002	「2.0 店铺信息」与「门店项目信息」的对应关系	业务
REQ-STM-003	营业执照等资质变更的审核流程	运营
REQ-STM-004	协议中心与延保条款是否合并	法务 / 产品
REQ-STM-007	渠道到期是否产生首页待办或预警	产品
REQ-STM-008	门店主数据中 App 内可编辑的字段范围	架构

10.2.10 财务与返利（FIN / RBT）

编号	待确认内容	建议决策方
REQ-FIN-001	财务模块是否限店长	业务
REQ-FIN-002	可提现金额的精确计算口径（核销 → 可提现）	财务
REQ-FIN-003	采购对账单与 O2O 提现是否合成「资金总览」	产品 / 财务
REQ-FIN-004	银行账号绑定/解绑的二次验证方式	安全 / 财务
REQ-FIN-005	首页「CDMS 支付提醒」与财务模块的关系	架构
REQ-RBT-001	返利对技工是否可见	业务
REQ-RBT-002	返利补贴、核算后返利、三项构成的计算公式	财务
REQ-RBT-004	O2O 返利与延保返利是否合并入口	产品

10.2.11 业绩、营销、福利兑换（PRF / MKT / MSP）

编号	待确认内容	建议决策方
REQ-PRF-001	技工可见的业绩指标范围	业务
REQ-PRF-002	「1.0 / 2.0」版本代号的业务命名替换	产品
REQ-PRF-003	ROOS 与 O2O 两套业绩的合并方式	业务
REQ-PRF-004	延保经营数据是否并入统一报表	业务
REQ-MKT-001	技工可用券与权益但不可管理，边界确认	产品
REQ-MKT-002	三套券（O2O 消费券 / 门店营销券 / ROOS 马牌券·经销商券）的适用场景与叠加规则	业务
REQ-MKT-003	门店海报的分享目标与相册权限方案	产品
REQ-MKT-004	消费者补贴与消费券是否为同一资金来源	财务
REQ-MSP-002	福利兑换的页面内容与主流程（兑换商品列表 / 详情 / 记录）	产品
REQ-MSP-004	MSIP 是否提供 API，还是只能嵌入 H5	架构
REQ-MSP-005	门店内是否限店长发起兑换	产品
REQ-MSP-006	积分如何产生（订货 / 入库 / 延保建单 / 核销，或后台直接发放）	业务

10.2.12 主数据、后台、集成（MDM / ADM / INT）

编号	待确认内容	建议决策方
REQ-MDM-001	CDMS 非轮数据的来源	架构
REQ-MDM-002	RMS 车型主数据的同步方式	架构
REQ-MDM-005	产品主数据（SFTP 同步）的口径时间是否需在 App 展示	产品
REQ-ADM-001	后台账号与 App 账号是否互通	架构
REQ-ADM-002	后台「APP 配置」的配置粒度（按角色 / 门店能力 / 单店覆盖）—— C1 的落地前提	架构 / 产品
REQ-ADM-003	「基础数据配置」与主数据、系统数据字典的边界	架构
REQ-ADM-004	账号审核在后台完成还是由店长在 App 内完成	产品
REQ-ADM-005	角色是全局定义还是可按门店自定义	架构
REQ-ADM-006	接口 SLA 200ms 是 P50 还是 P95、是否分接口分级	架构
REQ-ADM-007	门店侧高风险操作是否进入后台审计日志	安全
REQ-INT-006	RMS 的集成方式（C10）	架构
REQ-INT-007	ROOS 与 CDMS 是否为同一系统（C7）	架构
REQ-INT-008	未接入 F6 的门店，销售全链路如何提供	架构 / 产品

10.2.13 非功能（NFR）

编号	待确认内容	建议决策方
REQ-NFR-001	冷启动时长指标	架构
REQ-NFR-002	首页首屏时长指标	架构
REQ-NFR-004	扫码识别时延与成功率指标（条码 / VIN 在端上离线完成；车牌为云端 OCR，时延含网络往返与图片上传，需分开定指标）	架构
REQ-NFR-006	门店总数与日活峰值（并发基线）	业务
REQ-NFR-025	最低系统版本	架构
REQ-NFR-026	门店常用机型与屏幕尺寸清单	业务
REQ-NFR-027	是否首版支持暗色模式	产品
REQ-NFR-032	离线可读的数据范围	产品 / 架构
REQ-NFR-033	包体积上限	架构
REQ-NFR-037	是否需要版本强制升级机制	产品

10.3 跨文档阻塞项

以下来自仓库《文档仓库说明》，不解决会直接卡住工程落地。本文档不重复论证，只登记其对需求的影响。当前仅剩 1 项未决，另 5 项已于 2026-08 裁决，结论一并登记在下方。

阻塞项	出处	对本文档的影响
神策服务是否可用未确认	《App 可观测性与埋点文档》	后台首页看板的访问趋势、转化漏斗、活跃/僵尸用户全部依赖埋点 —— 埋点不落地，看板即为空。且 Dart 异常的明细看板也建在神策上（见下表崩溃上报一行），该项权重高于最初评估

未决的跨文档阻塞项

已裁决的 5 项：

原阻塞项	结论	对本文档的影响
iOS 构建链路不成立	由远程 Mac 出包，首版手工执行仓库内构建脚本，后续注册成流水线 Runner	REQ-NFR-035 已改写为确定要求
后端错误码表未定	分段方案与基础码已定死，业务码在开发对应模块时随接口增补；客户端对未识别的码统一展示后端提示文案	REQ-NFR-014 已改写；各模块「异常流程」可按默认文案验收
崩溃上报平台未定	不引入独立崩溃平台。原生崩溃 / ANR 走腾讯 Bugly，Dart 异常明细与错误看板走神策自定义事件（在神策上二次开发）	REQ-NFR-015 已改写；REQ-NFR-023 数据出境风险随之消除
内测分发渠道未定	Android 走托管的 OTA 分发页，iOS 走 TestFlight，不使用 Firebase；后续可能并入后台的「APP 发布管理」	REQ-NFR-036 已改写；与 REQ-NFR-037 强制升级的实现方式相关
车牌识别技术路径未验证	采用付费的云端 OCR 服务（拍照上传换识别结果），客户端不直连、由 App 后端代理	REQ-SAL-002 已改写。交互由「取景框自动识别」改为「拍一张照」，涉及该处设计稿的调整；弱网不可用与计费风险登记为 R9；照片上传第三方需写入隐私政策（REQ-NFR-023）

已裁决的跨文档阻塞项

10.4 风险登记

#	风险	影响	缓解建议
R1	需求密度不均 —— 销售与延保有完整现状与原型，而福利兑换至今无任何页面材料，采购中非马牌商品的部分也只有文字约定	排期估算失真	两处的范围与数据源均已确认；剩余风险集中在 TODO(REQ-PUR-011)（是否共用购物车）与 TODO(REQ-MSP-002)（兑换页面形态），需在设计阶段补出稿再估排期
R2	F6 覆盖率未知	未接 F6 门店的销售链路无方案，可能需要 App 内自建开单	优先关闭 TODO(REQ-INT-008)
R3	同名不同义大量存在（两套五状态订单、三套业绩、三套券、两套返利）	用户误操作、验收争议	术语与状态机在开发前统一定稿（REQ-NFR-008）
R4	数据双写风险 —— 扫码入库同时存在于 O2O 与 ROOS	数据不一致，报表对不上	优先关闭 TODO(REQ-INV-005)
R5	金额口径未定 —— 返利公式、可提现口径、预计营收口径均未定义	门店与厂商产生对账争议	财务口径需在开发前书面确认（TODO(REQ-RBT-002)、TODO(REQ-FIN-002)、TODO(REQ-HOM-011)）
R6	弱网 + 大文件上传是刚需场景	装车视频、鉴定证据上传失败会直接阻断理赔业务	断点续传与本地暂存作为首版必做项（8.6）
R7	导航配置端与 App 强耦合	后台「APP 配置」未建模则 tab 无法下发	TODO(REQ-ADM-002) 与 TODO(REQ-HOM-010) 需一并裁决
R8	能力陈述式需求不可直接验收	开发理解偏差	全部需求须沿用 1.8 的模板书写，新增与修订同样适用
R9	车牌识别依赖网络 —— 技术路径已定为付费的云端 OCR 服务，识别准确率由供应商保证，但门店地下车库、施工区弱网时该功能不可用，且按调用次数计费	接车与延保建单两条主流程在弱网下退化为纯手工录入	① 手工输码作为常驻并列入口，不是失败后的降级；② 上传前压缩图片，超时与重试上限设死，失败即转手工输码不自动重试；③ 置信度低于阈值时以「待确认」展示而非直接回填；④ 调用量需监控告警，防止误做成连续帧调用

风险登记

---

附录 A 业务数据字典

本附录汇总各模块的数据集及其来源。「来源」列取自《Conti Retail APP 功能模块与数据来源整理》（该文档为可信的字段级数据来源整理），并按第 7 章的架构结论校正。

来源标识说明：App Backend = App 自有；Mini Program Backend = 经 App Backend 代理的小程序后台（ROOS / O2O / 延保 / 马上下单）；F6 Backend = 经 F6 Adapter；Embedded H5 = F6 页面内自取；User Input = 用户录入。

A.1 登录

#	数据集	来源	安全	备注
1	第三方验证码	App Backend	HTTPS	短信调用第三方短信网关
2	登录成功结果集	App Backend	HTTPS	账号密码登录与验证码登录共用
3	用户协议与隐私政策完整内容	App Backend	HTTPS	注册/登录前须确认（REQ-NFR-020）

A.2 首页

#	数据集	来源	安全	备注
1	切换后的店铺信息集	App Backend	HTTPS
2	店铺列表结果集（用于切店）	App Backend	HTTPS
3	当前用户的菜单数据集	App Backend	HTTPS	即角色化 tab 下发（REQ-HOM-010）
4	动态预警	Mini Program Backend	HTTPS	来自 ROOS 与 O2O
5	促销信息	Mini Program Backend	HTTPS	首页顶部滚动提示
6	公告/通知列表（按发布时间倒序）	Mini Program Backend	HTTPS	支持查看、标记已读、删除
7	待办事项（按优先级/截止时间排序）	Mini Program Backend	HTTPS	来自 O2O 与延保后台

A.3 销售

#	数据集	来源	安全	备注
1	扫码结果（VIN / 车牌 / 条码二维码）	原生 native_scan	—	⚠️ 前期材料写「Involve F6 Page」，已按 REQ-INT-003 校正
2	历史工单记录结果集 / 单条工单详情	Mini Program Backend	HTTPS
3	工单数据集	Mini Program Backend	HTTPS	保存到 O2O 后台
4	服务提醒记录集 / 意向池	F6 Backend	HTTPS	销售商机
5	延保历史记录集 / 单条延保详情集	Mini Program Backend	HTTPS
6	到店记录页 / 新车辆完善信息 / 车辆详情 / 开单	Embedded H5（F6）	HTTPS
7	施工查车（检测模板、异常结果、批量正常、报告发送）/ 查车转工单、转商机	Embedded H5（F6）	HTTPS	报告经 SMS 或微信发送
8	添加其它项目 / 结算收款	Embedded H5（F6）	HTTPS
9	延保数据集 / 延保出库（总数量减 1）	Mini Program Backend	HTTPS	结算后进入延保流程

A.4 提醒

#	数据集	来源	安全	备注
1	提醒规则、提醒单、提醒作业	F6 Backend	HTTPS	F6 后台自动按规则生成提醒单；App 以 Embedded H5 嵌入展示，不落地也不回写，见 4.4.5

A.5 采购

#	数据集	来源	安全	备注
1	商品信息（名称/规格/型号/价格/库存/详情/参数）	Mini Program Backend	HTTPS	ROOS
2	当前用户购物车信息数据集	Mini Program Backend	HTTPS	保存至 ROOS
3	促销日历数据集	Mini Program Backend	HTTPS	活动数据接口待确定
4	结算信息结果集	App Backend	证书令牌	需调用三方接口，银行接口可能需令牌或证书
5	收货（扫码入库）	原生 native_scan	—	⚠️ 前期材料写「嵌入 F6 扫码入库页面」，已按 REQ-INT-003 校正
6	采购订单列表 / 采购订单详情	Mini Program Backend	HTTPS

采购商品字段（见 4.6.8 业务数据列表）：productName、productCode、brandTag、brand、price、priceUnit、tireSize、carModel、installPositon、productCategory。

A.6 延保

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

A.7 门店管理

#	数据集	来源	安全	备注
1	门店基础数据结果集	Mini Program Backend	HTTPS	调用马上下单后台接口
2	门店服务信息数据结果集	Mini Program Backend	HTTPS	马上下单
3	营业执照信息结果集	Mini Program Backend	HTTPS	马上下单
4	渠道信息结果集	Mini Program Backend	HTTPS	马上下单
5	经营范围信息结果集	Mini Program Backend	HTTPS	O2O —— 会员体系开通、CATI 开通、单独服务项、开票方式
6	收款信息结果集	Mini Program Backend	HTTPS	O2O 平安账号模块 —— 企业银行账号、改绑手机、解绑银行卡
7	门店员工列表结果集 / 员工详细信息	Mini Program Backend	HTTPS	马上下单

A.8 经营分析与财务

#	数据集	来源	安全	备注
1	对账单	Mini Program Backend	HTTPS	采购及返利对账单（马牌），来自 ROOS 与 F6
2	核销结果集	Mini Program Backend	HTTPS	门店核销收入（马牌）
3	返利结果集	Mini Program Backend	HTTPS	返利余额、明细、规则、提现

A.9 个人中心

#	数据集	来源	安全	备注
1	收货地址列表（按使用时间/默认状态排序）	App Backend	HTTPS	数据来源于马上下单接口（待确认，见 TODO(REQ-MIN-003)）
2	服务热线列表（号码/服务时间/范围/类型）	App Backend	HTTPS	支持一键拨号
3	经销商客服信息	App Backend	HTTPS	在线咨询、留言反馈
4	O2O / 延保企微客服信息	App Backend	HTTPS	数据来源于企业微信接口（待确认，见 TODO(REQ-MIN-004)）
5	退出登录	App Backend	HTTPS	清除登录态；多设备登录时单设备退出不影响其它设备

A.9 第 5 条隐含一条尚未成文的规则：多设备可同时登录，单设备登出不影响其它设备。这与账号权限管控痛点中「账号共用」的治理诉求存在张力 —— 是否需要单设备登录限制，建议在 TODO(REQ-LGN-009) 一并确认。

---

附录 B 权限矩阵

角色定义见 3.1。首版仅店长与技工两个角色。

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

模块	功能	店长	技工	备注 / 待确认
登录	手机验证码 / 账号密码登录	✅	✅
	第三方登录（微信/支付宝）	❓	❓	仅见于设计稿 TODO(REQ-LGN-003)
	注册	❓	❓	需审核 TODO(REQ-LGN-004)
首页	门店切换	✅	❓	技工是否允许多门店 TODO(REQ-HOM-001)
	消息公告	✅	❓	业务需求说有、设计稿未画 TODO(REQ-HOM-003)
	待办事项	✅	❓	同上 TODO(REQ-HOM-008)
	动态预警	✅	❓	同上 TODO(REQ-HOM-009)
	今日经营卡片（金额类）	🔸	✗	店长可隐藏金额；技工仅见完工单数 TODO(REQ-HOM-011)
	当前施工队列	✗	✅	技工独有 TODO(REQ-HOM-012)
销售	接车 / 扫码识别	✅	⚙️
	检测、开单、施工	✅	⚙️
	扫码核销	✅	⚙️	流程待定 TODO(REQ-SAL-010)
	查看金额（商品总价/实收/待收）	✅	❓	TODO(REQ-SAL-012)
	结算收银	✅	⚙️
提醒	设置提醒规则	✅	✗	属门店管理职能
	生成 / 跟进提醒单	✅	❓	页内权限由 F6 控制，App 只控入口可见性 TODO(REQ-RMD-005)
延保	建单（扫车牌/绑定车辆/装车视频）	✅	❓	TODO(REQ-WTY-003)
	保单查询	✅	❓	同上
	保单作废	🔸	✗	高风险，需二次确认 + 审计 TODO(REQ-WTY-005)
	理赔受理 / 售后鉴定	✅	❓	TODO(REQ-WTY-003)
	延保返利	✅	❓	TODO(REQ-WTY-004)
采购	搜索 / 加购 / 查看订单	✅	⚙️	技工需被授权
	提交订单（涉及资金）	✅	❓	TODO(REQ-PUR-002)
	收货	✅	⚙️
	售后 / 退款	✅	⚙️
库存	库存查询	✅	✅
	查看小程序结算价	✅	❓	TODO(REQ-INV-001)
	扫码入库 / 出库	✅	✅	一线高频操作
我的	个人信息 / 换绑手机 / 登出	✅	✅
	我的账户（额度/返利/券/积分）	✅	❓	TODO(REQ-MIN-002)
	收货地址 / 我的收藏	✅	🔸	技工只读
	支付优先级设置	✅	✗	影响资金
门店管理	查看门店信息	✅	🔸	技工只读，基本无门店管理权限
	修改基础信息 / 项目信息 / 营业执照	✅	✗
	人员管理与授权	✅	✗	高风险，需审计
	协议中心	✅	🔸	技工只读
财务	对账提现 / 收入 / 结算单	✅	✗	TODO(REQ-FIN-001)
	银行账号绑定 / 解绑	🔸	✗	高风险，需二次验证 TODO(REQ-FIN-004)
	采购对账单	✅	✗
返利	返利详情 / 核算	✅	❓	TODO(REQ-RBT-001)
经营业绩	全量指标	✅	❓	技工可见范围 TODO(REQ-PRF-001)
营销会员	使用券与会员权益（开单时）	✅	✅
	管理券 / 门店海报	✅	✗	TODO(REQ-MKT-001)
福利兑换	积分兑换	✅	❓	积分属门店，同店两角色看到同一份余额；能否发起兑换待定 TODO(REQ-MSP-005)

权限矩阵（功能 × 角色）

编号	权限实施规则
REQ-ACC-004	权限在接口层强制，前端隐藏只是配套，不得作为唯一手段
REQ-ACC-005	⚙️ 类权限由店长或后台通过人员管理「可用系统」授予（TODO(REQ-STM-001)）
REQ-ACC-006	🔸 与 ❓ 项在待确认项关闭前，默认取更严格的一侧实现
REQ-ACC-007	权限变更后，用户下次进入 App 即生效（9.3）

权限实施规则

---

附录 C 图表清单

本文档共 173 张图与 66 张表。图片按章节顺序排列，本清单给出每张图的说明与源文件，可用于核对导出后的 Word 文档配图是否完整、以及追溯每张截图的出处。

C.1 图片来源分布

来源目录	张数	用途
mini-program-images/O2O/	78	O2O 接单宝小程序现状截图
mini-program-images/Warranty/	44	延保门店端小程序现状截图
mini-program-images/ROOS/	20	ROOS 采购小程序现状截图
app-design-images/	15	新 App 目标形态设计稿
images/	16	业务流程原型图（F6 销售页面、提醒、后台管理）
合计	173

图片来源分布

C.2 各章节配图清单

2.7 现状小程序功能全景（4 张）

序	说明	文件
1	现状-ROOS 首页（公告 / 扫码出入库 / 四个互跳入口）	mini-program-images/ROOS/首页.png
2	现状-O2O 接单宝首页（单页承载全部功能）	mini-program-images/O2O/接单宝首页.png
3	现状-延保门店端首页（深色主题，立刻延保为主操作）	mini-program-images/Warranty/首页.png
4	现状-延保门店端工作台（六宫格 + 延保数据 + 返利简报）	mini-program-images/Warranty/工作台.png

4.1 账号登录（1 张）

序	说明	文件
1	设计稿-登录页	app-design-images/登录.png

4.2 APP 首页（5 张）

序	说明	文件
1	设计稿-首页（店长）	app-design-images/首页-店长.png
2	设计稿-首页（技工）	app-design-images/首页-技工.png
3	设计稿-首页（功能宫格版，备选方案）	app-design-images/首页-功能宫格版.png
4	现状-ROOS 公告列表（空态）	mini-program-images/ROOS/公告列表-空态.png
5	现状-O2O 消息（门店违规提醒）	mini-program-images/O2O/消息-门店违规提醒.png

4.3 销售（28 张）

序	说明	文件
1	原型-销售历史记录页（车主车辆卡片 + 历史工单 / 延保历史记录 + 底部三操作）	images/原型-销售-历史记录页.png
2	原型-车主车辆信息卡片（带「销售商机」入口）	images/原型-销售-车主车辆卡片.png
3	原型-历史工单	images/原型-销售-历史工单.png
4	原型-延保历史记录	images/原型-销售-延保历史记录.png
5	原型-到店记录 / 新车辆建档 / 车辆详情	images/原型-销售-到店记录与建档.png
6	原型-检测开单与检测项目选择（底盘检测 / 保养速检 / 轮胎专检 / 3 万公里保养检测 / 新能源检测）	images/原型-销售-检测开单.png
7	原型-轮胎专检（检测项目 / 异常项拍照，正常项批量通过）	images/原型-销售-轮胎专检.png
8	原型-生成检测报告并发送车主（微信 / 企业微信 / 公众号 / 短信 / 他人微信）	images/原型-销售-检测报告发送.png
9	原型-检测单转工单 / 转商机	images/原型-销售-检测单转工单.png
10	原型-新建维修单与查看维修单（完工）	images/原型-销售-维修单与完工.png
11	现状-O2O 核销历史	mini-program-images/O2O/核销历史.png
12	现状-O2O 核销订单弹窗	mini-program-images/O2O/服务单列表-核销订单弹窗.png
13	设计稿-订单列表（渠道 tab + 状态 tab + 接单操作）	app-design-images/订单列表.png
14	现状-O2O 订单列表（待接单）	mini-program-images/O2O/订单列表-待接单.png
15	现状-O2O 订单列表（调货中）	mini-program-images/O2O/订单列表-调货中.png
16	现状-O2O 订单列表（已完成）	mini-program-images/O2O/订单列表-已完成.png
17	现状-O2O 订单列表（筛选）	mini-program-images/O2O/订单列表-筛选.png
18	现状-O2O 接单货品状态选择（接单时须声明货品状态，决定后续走调货还是直接安装）	mini-program-images/O2O/订单列表-接单货品状态选择.png
19	现状-O2O 订单详情（待接单）	mini-program-images/O2O/订单详情-待接单.png
20	现状-O2O 订单详情（待安装）	mini-program-images/O2O/订单详情-待安装.png
21	现状-O2O 订单备注	mini-program-images/O2O/订单备注.png
22	现状-O2O 服务单列表（全部）	mini-program-images/O2O/服务单列表-全部.png
23	现状-O2O 服务单列表（待安装）	mini-program-images/O2O/服务单列表-待安装.png
24	现状-O2O 服务单列表（已安装）	mini-program-images/O2O/服务单列表-已安装.png
25	现状-O2O 服务单列表（筛选）	mini-program-images/O2O/服务单列表-筛选.png
26	现状-O2O 服务单详情（待安装）	mini-program-images/O2O/服务单详情-待安装.png
27	现状-O2O 服务单详情（已安装）	mini-program-images/O2O/服务单详情-已安装.png
28	原型-添加项目材料 / 查看维修单 / 结算收银	images/原型-销售-结算收银.png

4.4 提醒（3 张）

序	说明	文件
1	原型-①设置提醒规则（F6 PC 端 会员营销 > 商机规则设置）	images/原型-提醒-设置提醒规则.png
2	原型-②生成提醒单（F6 PC 端 服务提醒 > 我未完成）	images/原型-提醒-生成提醒单.png
3	原型-③跟进提醒单（含跟进手段说明）	images/原型-提醒-跟进提醒单.png

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

4.6 采购（9 张）

序	说明	文件
1	设计稿-订单管理（商品列表，App 目标形态）	app-design-images/订单管理-商品列表.png
2	现状-ROOS 商品选择	mini-program-images/ROOS/商品选择.png
3	设计稿-订单管理（购物车，App 目标形态）	app-design-images/订单管理-购物车.png
4	现状-ROOS 购物车	mini-program-images/ROOS/购物车.png
5	现状-ROOS 订单确认	mini-program-images/ROOS/订单确认.png
6	现状-ROOS 订单确认（额度不足提示）	mini-program-images/ROOS/订单确认-额度不足提示.png
7	现状-ROOS 我的订单（全部）	mini-program-images/ROOS/我的订单-全部.png
8	现状-ROOS 我的订单（待支付）	mini-program-images/ROOS/我的订单-待支付.png
9	现状-ROOS 售后退款	mini-program-images/ROOS/售后退款.png

4.7 库存（12 张）

序	说明	文件
1	设计稿-库存查询（App 目标形态）	app-design-images/库存查询.png
2	现状-O2O 库存查询	mini-program-images/O2O/库存查询.png
3	现状-O2O 库存查询（搜索类型选择）	mini-program-images/O2O/库存查询-搜索类型选择.png
4	现状-O2O 库存查询（筛选胎面宽）	mini-program-images/O2O/库存查询-筛选胎面宽.png
5	现状-O2O 库存查询（筛选扁平比）	mini-program-images/O2O/库存查询-筛选扁平比.png
6	现状-O2O 库存查询（筛选直径）	mini-program-images/O2O/库存查询-筛选直径.png
7	现状-O2O 库存查询（筛选花纹）	mini-program-images/O2O/库存查询-筛选花纹.png
8	现状-O2O 扫码入库（空态，顶部为日期区间 + 品牌筛选 + 「总入：N 条」汇总条）	mini-program-images/O2O/扫码入库.png
9	现状-O2O 扫码入库（筛选品牌）	mini-program-images/O2O/扫码入库-筛选品牌.png
10	现状-O2O 扫码入库（自定义日期筛选）	mini-program-images/O2O/扫码入库-自定义日期筛选.png
11	现状-ROOS 首页扫码出库（操作选择弹窗）	mini-program-images/ROOS/首页-扫码出库操作选择弹窗.png
12	现状-ROOS 条码库存（入库记录）	mini-program-images/ROOS/条码库存-入库记录.png

4.8 我的 / 个人中心（16 张）

序	说明	文件
1	设计稿-个人中心（App 目标形态）	app-design-images/个人中心.png
2	现状-ROOS 我的	mini-program-images/ROOS/我的.png
3	现状-ROOS 我的（跳转账户管理小程序弹窗，整合后取消）	mini-program-images/ROOS/我的-跳转账户管理小程序弹窗.png
4	现状-ROOS 我的账户	mini-program-images/ROOS/我的账户.png
5	现状-ROOS 我的优惠券（待使用）	mini-program-images/ROOS/我的优惠券-待使用.png
6	现状-ROOS 支付优先级设置	mini-program-images/ROOS/支付优先级设置.png
7	现状-ROOS 收货地址	mini-program-images/ROOS/收货地址.png
8	现状-ROOS 商品收藏列表	mini-program-images/ROOS/商品收藏列表.png
9	现状-O2O 设置	mini-program-images/O2O/设置.png
10	现状-O2O 设置（确认登出弹窗）	mini-program-images/O2O/设置-确认登出弹窗.png
11	现状-O2O 修改手机号	mini-program-images/O2O/修改手机号.png
12	现状-O2O 选择店铺	mini-program-images/O2O/选择店铺.png
13	现状-O2O 小程序在线客服	mini-program-images/O2O/小程序在线客服.png
14	现状-延保 我的	mini-program-images/Warranty/我的.png
15	现状-延保 我的（修改姓名）	mini-program-images/Warranty/我的-修改姓名.png
16	现状-延保 我的（切换店铺）	mini-program-images/Warranty/我的-切换店铺.png

4.9 门店管理（14 张）

序	说明	文件
1	设计稿-门店管理（App 目标形态）	app-design-images/门店管理.png
2	设计稿-人员管理（App 目标形态）	app-design-images/人员管理.png
3	现状-O2O 店铺管理（基础信息：门店名称、门店主编码、收款信息、负责人姓名、联系方式、门店地区、详细地址、门店评分、门头照片）	mini-program-images/O2O/店铺管理-基础信息.png
4	现状-O2O 店铺管理（2.0 店铺信息）	mini-program-images/O2O/店铺管理-2.0店铺信息.png
5	现状-O2O 店铺管理（渠道信息）	mini-program-images/O2O/店铺管理-渠道信息.png
6	现状-O2O 店铺管理（营业执照信息）	mini-program-images/O2O/店铺管理-营业执照信息.png
7	现状-O2O 修改营业执照信息	mini-program-images/O2O/修改营业执照信息.png
8	现状-O2O 修改营业执照信息（上传方式选择：拍照 / 相册）	mini-program-images/O2O/修改营业执照信息-上传方式选择.png
9	现状-O2O 经营范围与开票方式	mini-program-images/O2O/经营范围与开票方式.png
10	现状-O2O 经营范围详情	mini-program-images/O2O/经营范围详情.png
11	现状-O2O 选择开票方式	mini-program-images/O2O/选择开票方式.png
12	现状-O2O 单独服务项开通情况	mini-program-images/O2O/单独服务项开通情况.png
13	现状-O2O 协议中心	mini-program-images/O2O/协议中心.png
14	现状-O2O 小程序线下门店合作协议	mini-program-images/O2O/小程序线下门店合作协议.png

4.10 财务与对账（11 张）

序	说明	文件
1	现状-O2O 对账提现	mini-program-images/O2O/对账提现.png
2	现状-O2O 对账提现（交易手续费说明）	mini-program-images/O2O/对账提现-交易手续费说明.png
3	现状-O2O 提现历史	mini-program-images/O2O/提现历史.png
4	现状-O2O 收入	mini-program-images/O2O/收入.png
5	现状-O2O 收入详情	mini-program-images/O2O/收入详情.png
6	现状-O2O 服务结算单	mini-program-images/O2O/服务结算单.png
7	现状-O2O 服务结算单（筛选结算渠道）	mini-program-images/O2O/服务结算单-筛选结算渠道.png
8	现状-O2O 结算单明细	mini-program-images/O2O/结算单明细.png
9	现状-ROOS 对账单详情（采购对账单）	mini-program-images/ROOS/对账单详情-采购对账单.png
10	现状-O2O 银行账号（企业账户）	mini-program-images/O2O/银行账号-企业账户.png
11	现状-O2O 银行账号（个人账户，解绑确认弹窗）	mini-program-images/O2O/银行账号-个人账户-解绑确认弹窗.png

4.11 返利中心（10 张）

序	说明	文件
1	设计稿-返利中心（App 目标形态）	app-design-images/返利中心.png
2	现状-O2O 返利中心（返利详情）	mini-program-images/O2O/返利中心-返利详情.png
3	现状-O2O 返利中心（返利核算）	mini-program-images/O2O/返利中心-返利核算.png
4	现状-O2O 返利中心（筛选渠道）	mini-program-images/O2O/返利中心-筛选渠道.png
5	现状-O2O 返利中心（筛选品牌）	mini-program-images/O2O/返利中心-筛选品牌.png
6	现状-O2O 返利中心（筛选标签）	mini-program-images/O2O/返利中心-筛选标签.png
7	现状-O2O 返利中心（筛选月份）	mini-program-images/O2O/返利中心-筛选月份.png
8	现状-O2O 返利中心（消费者补贴调整情况）	mini-program-images/O2O/返利中心-消费者补贴调整情况.png
9	现状-O2O 返利中心（安装费用调整情况）	mini-program-images/O2O/返利中心-安装费用调整情况.png
10	现状-O2O 返利中心（抽奖红包返利说明）	mini-program-images/O2O/返利中心-抽奖红包返利说明.png

4.12 经营业绩与报表（8 张）

序	说明	文件
1	设计稿-经营业绩（App 目标形态）	app-design-images/经营业绩.png
2	现状-O2O 经营业绩（1.0 经营业绩）	mini-program-images/O2O/经营业绩-1.0经营业绩.png
3	现状-O2O 经营业绩（2.0 经营业绩）	mini-program-images/O2O/经营业绩-2.0经营业绩.png
4	现状-O2O 经营业绩（2.0 引流转化）	mini-program-images/O2O/经营业绩-2.0引流转化.png
5	现状-O2O 经营业绩（筛选渠道）	mini-program-images/O2O/经营业绩-筛选渠道.png
6	现状-O2O 经营业绩（筛选品牌）	mini-program-images/O2O/经营业绩-筛选品牌.png
7	现状-O2O 经营业绩（筛选日期）	mini-program-images/O2O/经营业绩-筛选日期.png
8	现状-ROOS 业绩详情	mini-program-images/ROOS/业绩详情.png

4.13 营销与会员（7 张）

序	说明	文件
1	现状-O2O 优惠券（消费券）	mini-program-images/O2O/优惠券-消费券.png
2	现状-O2O 优惠券（门店营销券）	mini-program-images/O2O/优惠券-门店营销券.png
3	现状-O2O 选择营销券（空态）	mini-program-images/O2O/选择营销券-空态.png
4	现状-O2O 会员权益弹窗	mini-program-images/O2O/会员权益弹窗.png
5	现状-O2O 会员权益弹窗（已选权益）	mini-program-images/O2O/会员权益弹窗-已选权益.png
6	现状-O2O 会员体系门店（未开通）	mini-program-images/O2O/会员体系门店-未开通.png
7	现状-O2O 门店海报	mini-program-images/O2O/门店海报.png

6.1 后台用户登录（1 张）

序	说明	文件
1	原型-后台管理登录页	images/原型-后台-登录.png

6.2 后台管理首页（1 张）

序	说明	文件
1	原型-后台管理首页看板	images/原型-后台-首页看板.png

C.3 表格清单

序	说明	所属章节
1	术语与缩写定义	1.6 术语与缩写定义
2	需求模块码	1.7 需求编号规则
3	现状小程序底部导航（截图实测）	2.7 现状小程序功能全景
4	ROOS 小程序功能清单（20 张截图）	2.7 现状小程序功能全景
5	O2O 接单宝小程序功能清单（78 张截图）	2.7 现状小程序功能全景
6	延保门店端小程序功能清单（44 张截图）	2.7 现状小程序功能全景
7	痛点与需求映射	2.8 痛点 → 需求映射
8	企业内部干系人	3.2 企业内部干系人
9	外部对接系统厂商	3.3 外部对接系统厂商
10	模块总览	4.0 模块总览
11	账号登录业务数据	4.1 账号登录
12	现状入口 → App 导航映射	4.2 APP 首页
13	待办事项两层口径	4.2 APP 首页
14	动态预警项	4.2 APP 首页
15	店长 / 技工首页分区差异	4.2 APP 首页
16	三版底部导航方案	4.2 APP 首页
17	角色化 tab 配置（建议值，待确认）	4.2 APP 首页
18	APP 首页信息字段	4.2 APP 首页
19	根据车牌获取车主车辆信息	4.3 销售
20	保养提醒规则字段	4.4 提醒
21	提醒模块承接方案候选	4.4 提醒
22	采购业务数据表	4.6 采购
23	库存查询现状与目标差异	4.7 库存
24	三套「我的」的合并归属	4.8 我的 / 个人中心
25	主数据来源	5.1 主数据来源
26	后台管理首页看板构成	6.2 后台管理首页
27	系统集成矩阵	7.2 集成矩阵
28	F6 集成边界	7.3 F6 集成边界
29	JSBridge 能力清单	7.3 F6 集成边界
30	门店能力开关	7.4 门店能力开关
31	整合类验收标准	9.2 整合类验收
32	角色与权限验收标准	9.3 角色与权限验收
33	集成验收标准	9.4 集成验收
34	非功能验收标准	9.5 非功能验收
35	需求冲突清单	10.1 需求冲突清单
36	未决的跨文档阻塞项	10.3 跨文档阻塞项
37	已裁决的跨文档阻塞项	10.3 跨文档阻塞项
38	风险登记	10.4 风险登记
39	权限矩阵（功能 × 角色）	附录 B 权限矩阵
40	权限实施规则	附录 B 权限矩阵
41	图片来源分布	C.1 图片来源分布
42	需求追溯矩阵（RTM）骨架	D.2 模块级追溯汇总

---

附录 D 需求追溯矩阵（RTM）

D.1 用途与填写规则

RTM 用于保证「痛点 → 需求 → 设计 → 开发 → 测试」四段链路不断裂。本附录给出骨架与填写规则；逐条明细在需求评审关闭 10.2 的 97 项待确认后，由 PO 与 QA 共同维护于独立表格（建议 Jira/禅道，不建议长期维护在本文档中）。

列定义

列	含义	取值来源
需求编号	REQ-<模块码>-<3位序号>	本文档第 4–8 章
需求描述	一句话陈述	各节「需求描述汇总」表
来源痛点	P1–P6	2.8 痛点→需求映射
来源材料	业务需求 / 设计稿 / 现状截图 / 原型图 / 架构文档	1.8 的来源标注
优先级	P0 必须 / P1 应该 / P2 可选	需求评审裁定
状态	已确认 / 待确认 / 已废弃	带 TODO(...) 标记的一律为「待确认」
设计稿	所在小节的设计稿 / 现状截图，或 Figma 链接	附录 C 图表清单
接口	API 路径	接口文档（待建，见《文档仓库说明》）
验收标准	AC 编号	第 9 章
测试用例	TC 编号	QA 维护

填写规则

REQ-ACC-008 —— 每条需求必须有至少一条验收标准；无验收标准的需求不得进入开发排期

REQ-ACC-009 —— 状态为「待确认」的需求不得进入开发排期；其在 10.2 中必须有对应条目与责任人

REQ-ACC-010 —— 需求变更时同步更新 RTM 与本文档修订历史，变更未同步的视为未变更

REQ-ACC-011 —— 10.1 中 C1–C13 任一冲突未裁决前，受其影响的需求一律标「待确认」

D.2 模块级追溯汇总

模块码	模块	章节	需求条数	其中待确认	完成度
LGN	账号登录	4.1	11	7	36%
HOM	APP 首页	4.2	15	10	33%
SAL	销售	4.3	14	6	57%
RMD	提醒	4.4	7	2	71%
WTY	延保	4.5	10	5	50%
PUR	采购	4.6	13	7	46%
INV	库存	4.7	7	5	29%
MIN	我的 / 个人中心	4.8	6	6	0%
STM	门店管理	4.9	8	6	25%
FIN	财务与对账	4.10	7	5	29%
RBT	返利中心	4.11	6	3	50%
PRF	经营业绩与报表	4.12	6	4	33%
MKT	营销与会员	4.13	5	4	20%
MSP	福利兑换 MSIP	4.14	6	4	33%
MDM	主数据	第 5 章	6	3	50%
ADM	后台管理	第 6 章	7	7	0%
INT	系统集成	第 7 章	12	3	75%
NFR	非功能需求	第 8 章	38	10	74%
ACC	验收与追溯	第 9 章、本附录	11	0	100%
	合计		195	97	50%

需求追溯矩阵（RTM）骨架

完成度 = (需求条数 − 待确认条数) / 需求条数，衡量的是「需求是否说清楚了」，不是开发进度。

两个 0% 的模块（我的 MIN、后台管理 ADM）值得单独关注：

• MIN —— 有完整的现状截图（16 张），需求可从截图反推，但每一条的取舍都需业务确认，属证据充分但决策未定
• ADM —— 只有菜单结构、无功能级需求，且 REQ-ADM-002（角色化 tab 配置端）是 C1 的前置条件，是优先级最高的空白

福利兑换已由业务确认范围与数据源，从 0% 升至 33%，但它仍是全文唯一没有任何页面材料的模块 —— 完成度反映的是需求是否说清楚，不代表已有设计稿可供开发。

D.3 逐条 RTM 样例

以下为 4.1 账号登录的填写样例，其余模块照此格式展开：

需求编号	需求描述	来源痛点	来源材料	优先级	状态	设计稿	验收标准
REQ-LGN-001	支持手机号 + 短信验证码登录	P2	业务需求	P0	已确认	登录页设计稿	9.2 AC-1
REQ-LGN-002	支持账号 + 密码登录	P2	业务需求	P0	已确认	登录页设计稿	9.2 AC-1
REQ-LGN-003	支持微信 / 支付宝第三方登录	P2	设计稿	P2	待确认	登录页设计稿	—
REQ-LGN-004	新用户注册需经审核后开通	P2	设计稿	P1	待确认	登录页设计稿	—
REQ-LGN-009	单账号在多设备的登录策略	P2	本文档 附录 A.9 反推	P1	待确认	—	9.3
REQ-LGN-011	Token 失效后静默续期，续期失败才登出	—	《App 网络层设计文档》	P0	已确认	—	9.5

样例中 REQ-LGN-009 演示了一条由数据来源反推出、业务侧尚未提出的需求如何入表：来源材料写「本文档反推」，并在 10.2 中登记责任人。

---

结束语

本文档覆盖账号登录、首页与导航、销售、提醒、延保、采购、库存、个人中心、门店管理、财务对账、返利中心、经营业绩、营销与会员、福利兑换等 19 个模块，并把 173 张设计稿与现状截图全部编入对应章节作为需求实证。

本文档不是终稿。 195 条需求中有 97 条处于「待确认」，集中在第 10 章。这些是业务侧尚未给出结论的事项 —— 显式列出来，比用看似完整的文字掩盖过去更有价值。建议下一步：

1. 先关闭 C1 底部导航三版 与 REQ-ADM-002 后台 APP 配置 —— 这两条卡住整个信息架构
2. 再补 MSP / MIN / ADM 三个 0% 模块的需求
3. 确认埋点服务的可用性 —— 这是仅剩的跨文档阻塞项，同时决定后台首页看板与线上错误看板能否落地，属采购流程，与需求评审可并行