# 4.2 APP 首页

> **本文件是【APP 首页与导航 HOM】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.2 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。

| 项 | 值 |
| --- | --- |
| 模块码 | HOM |
| V1.0 章节 | 4.2 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 设计稿 3 版 |
| 现状承载系统 | ROOS / O2O / 延保（三套 tabbar 待废弃） |
| 需求条数 | 14（待确认 11，完成度 21%） |
| 本次新增待确认 | 1（REQ-HOM-016 见[附-5](#附-5-本次拆分新增发现待业务确认)） |
| 配图 | 5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1） |

模块概要

---

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

![设计稿-首页-店长](../app-design-images/首页-店长.png)

**页面内容** —— 店长首页目标形态，自上而下为门店名 + 问候语 + 铃铛（角标 9）的头部、橙色「今日预计营收」卡、快速核销与车牌扫码两张卡、待办事项五项计数、动态预警与促销横幅，底部五 tab 为 **首页 / 入库 / 采购 / 延保 / 我的**。

**关键交互** —— ①点门店名 → 切换门店（**本稿未画下拉箭头**，见下方说明）；②点眼睛图标 → 隐藏 / 显示金额类指标（[REQ-HOM-011](#426-业务规则)）；③点铃铛 → 进入消息列表，角标清零；④「快速核销-扫码 / 输码」→ 核销流程；⑤「车牌扫码-扫码 / 车牌」→ 接车进销售流程；⑥点待办任一项 → 进对应订单列表；⑦「查看全部」→ 全量预警列表；⑧点促销横幅 → 活动详情；⑨底部 tab 切换模块。

**可用角色** —— 店长 ✅ 全量。本稿的金额类分区（预计营收 / 毛利 / 客单价）对技工 ✗，见 [4.2.4](#424-技工首页)。

**需求关联** —— [REQ-HOM-001](#426-业务规则) 门店切换、[REQ-HOM-002](#426-业务规则) 问候语、[REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-005](#426-业务规则)/[006](#426-业务规则) 扫码与输码接车、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-008](#426-业务规则) 待办、[REQ-HOM-009](#426-业务规则) 动态预警、[REQ-HOM-011](#426-业务规则) 今日经营卡片

> **本稿的三处状态缺失**（属设计稿补稿，不新增需求）：①门店名旁**未画下拉箭头**，而功能宫格版画了 `▾` —— 切店器的表现形式两版不一致，随 [REQ-HOM-001](#426-业务规则) 统一；②动态预警角标写「2 项待处理」，但列表区**只画了 1 条**（低库存），第 2 条未画；③金额隐藏后的形态（打码还是留空）未画。

![设计稿-首页-技工](../app-design-images/首页-技工.png)

**页面内容** —— 技工首页目标形态，头部**无门店名与铃铛**、橙色卡改为「今日已完工 8 单」且**不含任何金额**，快速核销与车牌扫码两张卡同店长版，其下是技工独有的「当前施工队列（共 2 单）」工单卡，底部五 tab 与店长版一致。

**关键交互** —— ①「查看绩效明细」→ 技工个人绩效页（该页无设计稿）；②「开始施工」→ 工单转「安装中」；③「完工并结算」→ 结算（去 F6 结算页还是 App 内页未定 `TODO(REQ-HOM-012)`）；④快速核销与车牌扫码同店长版。**本稿未画**消息铃铛、待办事项、动态预警、促销位。

**可用角色** —— 技工 ✅。「当前施工队列」为技工独有，店长 ✗。技工是否应有消息 / 待办 / 预警三个分区，业务需求说有、本稿未画 —— `TODO(REQ-HOM-003)` / `TODO(REQ-HOM-008)` / `TODO(REQ-HOM-009)`。

**需求关联** —— [REQ-HOM-011](#426-业务规则)（技工只看完工单数，本稿是该规则的直接落地）、[REQ-HOM-012](#426-业务规则) 当前施工队列

> 卡片一的施工内容写作「**更**正品查验 + 动平衡 + 轮胎号延保绑定」，疑为「更换 / 正品查验」的文案笔误，补稿时一并核对。

![设计稿-首页-功能宫格版](../app-design-images/首页-功能宫格版.png)

**页面内容** —— 首页备选方案（对应[三版底部导航](#425-导航收敛与角色化配置)的方案 C），自上而下为内嵌核销码输入框的橙色头部、限时活动三张商品卡、待办事项五项计数、八宫格功能入口与经营业绩区（四个时间 tab + 三项指标，数值为占位），底部五 tab 为 **首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心**。

**关键交互** —— ①输核销码 → 点「核销」直接核销（比店长版少一步进卡片）；②「限时活动-更多」→ 活动列表；③点商品卡 → 目标未定，见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)；④点八宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）任一 → 进对应模块；⑤切换当日/当周/当月/当季 → 刷新经营指标；⑥「经营业绩-更多」→ 经营报表。

**可用角色** —— 本稿**未区分角色**，仅作导航方案备选。若采用，需补技工版 —— 稿中「经营业绩」含 O2O 成交金额，属金额类，对技工应不可见（`TODO(REQ-PRF-001)`）。

**需求关联** —— [REQ-HOM-010](#426-业务规则) 角色化导航（本稿即方案 C 的实体）、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 促销位形态与来源

> **本稿与店长版的两处口径不一致**，需在 [REQ-HOM-008](#426-业务规则) / [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并裁决：①待办首项，店长版写「待**接**单」、本稿写「待**订**单」；②促销位，店长版是底部活动横幅、本稿是顶部三商品卡、技工版没有 —— **三版稿画了三种形态**；且本稿三张商品卡**直接用了京东站内推广创意**（可见「京东JOY」「JD.COM」「爱奇艺」等第三方水印），正式稿须换成马牌自有素材。

## 4.2.1 需求描述

**业务目标** —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏，让门店开工第一眼就知道「今天有什么要做、有什么要盯」，解决[痛点 2.1](../Continental-Retail-APP-PRD.md#21-多小程序分散) 与 [2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)

**目标角色** —— 店长、技工（内容差异见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)）

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

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

**页面内容** —— 见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)

**主流程**：

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

**异常流程**：

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

**业务规则** —— 见 [4.2.6](#426-业务规则)

**权限规则** —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发，客户端不硬编码，见 [4.2.5](#425-导航收敛与角色化配置)

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

**逻辑数据来源** —— 见 [4.2.7](#427-业务数据列表)

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

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

**验收标准** —— 见 [4.2.8](#428-验收标准)

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

整合前，三套小程序各带一套底部导航，且互相之间用「首页放友链」的方式跳转（见 [2.7.1](../Continental-Retail-APP-PRD.md#271-现状导航结构)）。整合后**全部小程序 tabbar 一律废弃**，App 只保留一套底部导航。

| 现状入口 | 现状位置 | App 归属 |
| --- | --- | --- |
| ROOS 首页 / 商品 / 购物车 | ROOS tabbar | 合并进「采购」tab（[4.6](./06-PUR-采购.md)） |
| ROOS 我的 | ROOS tabbar | 拆分：账务类进「我的」（[4.8](./08-MIN-我的.md)），对账单进[财务](./10-FIN-财务与对账.md)，业绩进[经营业绩](./12-PRF-经营业绩与报表.md) |
| ROOS 扫码出库 / 扫码入库 | ROOS 首页 | 「入库」tab（[4.7](./07-INV-库存.md)） |
| O2O 核销码输入 + 核销 | O2O 首页顶部 | 首页「快速核销」卡片 |
| O2O 订单管理五状态 | O2O 首页 | 首页「待办事项」+ [4.3 销售](./03-SAL-销售.md)的订单列表 |
| O2O 两组功能宫格（13 项） | O2O 首页 | 分派至 [4.9](./09-STM-门店管理.md) / [4.10](./10-FIN-财务与对账.md) / [4.11](./11-RBT-返利中心.md) / [4.12](./12-PRF-经营业绩与报表.md) / [4.13](./13-MKT-营销与会员.md) |
| 延保 首页 / 工作台 / 待办事项 / 我的 | 延保 tabbar | 合并进「延保」tab（[4.5](./05-WTY-延保.md)） |
| 「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格 | ROOS + O2O 首页 | **取消**——整合后无需互跳；其中「积分兑换」保留为 [4.14 福利兑换](./14-MSP-福利兑换.md)入口 |

现状入口 → App 导航映射

## 4.2.3 店长首页

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

**一、门店切换**

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

**二、问候语**

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

**三、消息公告**

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

![现状-ROOS 公告列表-空态](../mini-program-images/ROOS/公告列表-空态.png)

**页面内容** —— ROOS 小程序「公告列表」页，**本图为空态**（「暂无公告」占位），故公告条目的字段构成无法从本图确认。

**关键交互** —— ①左上返回；②有数据时点条目进详情（本图无法确认）。本页除返回外**无任何筛选、搜索或标记已读的控件**。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-HOM-003)`。ROOS 侧现状不区分角色。

**需求关联** —— [REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-004](#426-业务规则) 促销信息（往期促销即在本列表中承载）

![现状-O2O 消息-门店违规提醒](../mini-program-images/O2O/消息-门店违规提醒.png)

**页面内容** —— O2O 接单宝「消息」页，按日期分组的卡片流，**本图可见的消息全部是同一类**（`【门店违规】提醒`），且**最新一条已是 2023-04-13**。

**关键交互** —— ①上下滑动按日期倒序浏览。**未见**已读标记、删除、分类筛选或点击进详情的控件 —— 本页是纯只读消息流。

**可用角色** —— 店长 ✅（违规会导致「禁止接单」，属店长必须知悉的治理类消息）；技工 ❓ `TODO(REQ-HOM-003)`。

**需求关联** —— [REQ-HOM-003](#426-业务规则)。本图是「消息分类体系」这条待确认的核心证据：O2O 侧是**会阻断经营的治理类消息**，ROOS 侧是**促销与通知类公告**，两者的紧急程度、是否需强提醒、能否删除完全不同，合并进一个消息中心时必须分类承载。本图的违规原因样例为「车牌号已超出年度最大下单量」「同一手机号下多笔订单超过限制数量」「门店单日销量超过限制数量」，均由风控规则触发，正文写「门店触发违规条件，已被禁止接单」并附「如有异议，请联系门店相应的销售代表」。

> 现状消息分散在 ROOS「公告」与 O2O「消息」两处，且类型不同（ROOS 为促销/通知公告，O2O 含门店违规提醒等治理类消息）。整合后需在一个消息中心内分类承载 —— 消息分类体系 `TODO(REQ-HOM-003)`。
>
> **补充**：附录 A.2 已定义消息列表「支持查看、标记已读、删除」，但上面两张现状图**都没有这三个控件** —— 这三项是 App 的新增能力，不是现状迁移，开发时需明确它们作用于哪一侧数据（App 自有消息表还是回写 ROOS / O2O）。

**四、促销信息**

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

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

> ⚠️ 三版设计稿对促销位画了三种形态 —— 形态与来源需一并裁决，见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)。

**五、扫码接车**

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

> 扫码由 **App 原生能力**实现（`native_scan`），非 F6 提供的扫码页，见 [C5](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。**车牌识别走云端 OCR 服务**：拍一张照上传识别，不是取景框里的实时识别，因而**依赖网络**——「输码」不是失败后的降级，而是与「扫码」并列的常驻入口。见[第 10 章风险 R9](../Continental-Retail-APP-PRD.md#104-风险登记)。

**六、输码**

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

**七、快速核销**

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

> 扫码核销的详细流程待确认 —— `TODO(REQ-SAL-010)`，详见 [4.3.4](./03-SAL-销售.md#434-核销)。

**八、待办事项**

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

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

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

待办事项两层口径

> 设计稿的五项与 O2O 现状五状态一一对应但措辞不同（「待调货」vs「调货中」、「待服务」vs「配送中」）。首页最终展示哪一层、或两层如何合并展示 —— `TODO(REQ-HOM-008)`，见 [C2](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
>
> **补充**：措辞不一致不止存在于「设计稿 vs O2O 现状」，**两版设计稿之间也不一致** —— 店长版首项写「待**接**单」，功能宫格版写「待**订**单」。取哪一套措辞随本条一并定稿。

**九、动态预警**

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

预警项全集：

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

动态预警项

> 各项预警的触发阈值（如低库存的条数门槛、时效订单的提前量）均未定义 —— `TODO(REQ-HOM-009)`，见 [C3](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。

**十、今日经营卡片**

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

> 该卡片仅见于设计稿。**「预计营收」的口径**（是否含未结算订单、是否含延保与返利、毛利率的成本口径）未定义 —— `TODO(REQ-HOM-011)`，见 [C8](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。金额隐藏功能对应[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 中「技工可查看门店财务数据」的风险控制诉求。

**十一、底部导航**

见 [4.2.5](#425-导航收敛与角色化配置)。

## 4.2.4 技工首页

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

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

店长 / 技工首页分区差异

> **上表「促销信息 技工 ✅」与技工版设计稿不符** —— 技工版稿中**没有促销位**（店长版有底部横幅、宫格版有顶部商品卡）。该行按业务需求填写，实际形态随 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并确认。

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

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

> 该分区仅见于设计稿。涉及的问题：施工任务如何分派给具体技工？状态机与 F6 工单、O2O 服务单的关系？「完工并结算」跳转到 F6 结算页还是 App 内页？—— `TODO(REQ-HOM-012)`，见 [C13](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。

## 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](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。下表为待确认的建议值：

| tab | 店长 | 技工 | 门店能力依赖 | 对应章节 |
| --- | --- | --- | --- | --- |
| 首页 | ✅ | ✅ | — | 4.2 |
| 入库 | ✅ | ✅ | — | [4.7](./07-INV-库存.md) |
| 采购 | ✅ | ⚠️ 授权可见 | — | [4.6](./06-PUR-采购.md) |
| 延保 | ✅ | ✅ | 门店已开通延保 | [4.5](./05-WTY-延保.md) |
| 我的 | ✅ | ✅ | — | [4.8](./08-MIN-我的.md) |

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

> 店长版与技工版两张设计稿的底部导航**完全一致**（首页 / 入库 / 采购 / 延保 / 我的），即稿中并未体现角色化差异 —— 差异全在页面内容而非 tab 集合。上表把「采购」对技工标为「授权可见」，属建议值，设计稿并未画出技工少一个 tab 的形态。

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

已明确一条硬规则：

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

推广为通用规则：任一 tab 或首页分区若依赖某外围系统，而当前门店未接入该系统，则该 tab / 分区整体隐藏（而非置灰或点击后报错）。能力开关清单见 [7.4](../Continental-Retail-APP-PRD.md#74-门店能力开关)。

## 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](./03-SAL-销售.md#434-核销)）

**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 分区降级** —— 任一数据源失败仅该卡片降级，不影响其它分区渲染

**REQ-HOM-016 促销位形态与来源** —— 三版设计稿画了三种互不相同的促销位形态（店长版底部通栏横幅、宫格版顶部三商品卡、技工版无），[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页) 又写作顶部滚动提示，共四种说法；宫格版素材直接用了第三方电商推广创意，正式稿须换成马牌自有素材。最终形态、数据来源、点击目标与技工可见性均待定 `TODO(REQ-HOM-016)`

## 4.2.7 业务数据列表

| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 门店名称列表 | StoreNameList | 马上下单 | 来自马上下单的门店列表 |
| 2 | 用户问候 | GreetingStr | APP Backend | 首页问候语，来自登录后获取的姓名和当前时间 |
| 3 | 消息公告 | Msg2PromotionList | APP 后台 + ROOS | 消息公告来自 APP 后台，促销信息来自 ROOS |
| 4 | 促销信息 | PromotionMsg | ROOS | 来自最新的 ROOS 促销信息 |
| 5 | 待办事项 | TodoList | 多源 | O2O 订单接单提醒：O2O 接口<br>CDMS 采购单支付提醒：CDMS 接口<br>延保视频上传提醒：延保接口<br>问卷提醒：`TODO(REQ-HOM-014)`<br>过期门店信息更新提醒：`TODO(REQ-HOM-015)` |
| 6 | 动态预警 | PrecautionIndexList | 多源 | 总预警数：APP 后台计算<br>月度签约达成预警：`TODO(REQ-HOM-009)`<br>库存预警：F6（⚠️ 未接 F6 不显示此项）<br>时效订单预警：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. 消息角标数字与消息列表未读条数一致；进入列表后角标归零。

---

## 附：本模块归拢信息

> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。

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

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

首页模块数据集（摘自主文件[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页)）。字段级清单见上方 [4.2.7](#427-业务数据列表)。

> **第 5 条与设计稿不符**：附录 A 写促销信息是「首页**顶部滚动提示**」，而店长版稿把它画成**底部通栏横幅**、宫格版画成**顶部三商品卡**。三处形态互不相同 —— 随 [REQ-HOM-016](#附-5-本次拆分新增发现待业务确认) 统一。
>
> **第 6 条的三个动作在现状中都不存在**：ROOS 公告列表与 O2O 消息页均无「标记已读 / 删除」控件（见 [4.2.3](#423-店长首页) 两张现状图）。这三项属 App 新增能力，需明确作用于 App 自有消息表还是回写源系统。

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

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

| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 门店切换 | ✅ | ❓ | 技工是否允许多门店 `TODO(REQ-HOM-001)` |
| 消息公告 | ✅ | ❓ | 业务需求说有、设计稿未画 `TODO(REQ-HOM-003)` |
| 待办事项 | ✅ | ❓ | 同上 `TODO(REQ-HOM-008)` |
| 动态预警 | ✅ | ❓ | 同上 `TODO(REQ-HOM-009)` |
| 今日经营卡片（金额类） | 🔸 | ✗ | 店长可隐藏金额；技工仅见完工单数 `TODO(REQ-HOM-011)` |
| 当前施工队列 | ✗ | ✅ | 技工独有 `TODO(REQ-HOM-012)` |

首页模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）

适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。

> 本模块权限的特殊之处：**四个 ❓ 全部指向「技工能不能看」**，且四项都是设计稿未画所致，而非业务上已判定不可见。按 REQ-ACC-006，这四项在关闭前一律实现为技工不可见 —— 也就是说，**技工首页首版会是设计稿画的那个精简版**。若业务实际期望技工也有待办与预警，需尽早关闭这四条，否则会返工。

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

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| 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.2](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)，10 条）

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

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-HOM-016** | **首页促销位的形态与来源** —— 三版设计稿画了三种形态、附录 A.2 又是第四种；素材含第三方电商水印；点击目标、数据来源与技工可见性均未定，详见[附-5](#附-5-本次拆分新增发现待业务确认) | 产品 / 业务 |

合计 11 条待确认（原 10 条 + 新增 1 条）。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 HOM 行（15 / 10 / 33% → 16 / 11 / 31%）与第 10.2 节总数。

> `TODO(REQ-HOM-010)` 是全文最高优先级的待确认项（**C1**），其落地前提是后台的「APP 配置」粒度 `TODO(REQ-ADM-002)`。两者构成一条链：**后台配得出来 → tab 才下发得下去 → 首页才知道画谁的版本**。

### 附-4 配图清单（主文件附录 C 4.2 节）

| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-首页（店长）：营收卡 + 双扫码卡 + 待办五项 + 动态预警 + 促销横幅 + 五 tab | `../app-design-images/首页-店长.png` |
| 2 | 设计稿-首页（技工）：完工单数卡 + 双扫码卡 + **当前施工队列**，无消息/待办/预警 | `../app-design-images/首页-技工.png` |
| 3 | 设计稿-首页（功能宫格版，备选方案 C）：核销码输入 + 限时活动三商品卡 + 八宫格 + 经营业绩 | `../app-design-images/首页-功能宫格版.png` |
| 4 | 现状-ROOS 公告列表（空态，无已读/删除控件） | `../mini-program-images/ROOS/公告列表-空态.png` |
| 5 | 现状-O2O 消息（全部为【门店违规】治理类消息，最新一条 2023-04） | `../mini-program-images/O2O/消息-门店违规提醒.png` |

首页模块配图清单，5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。

### 附-5 本次拆分新增发现（待业务确认）

以下 1 条**不在主文件现有 15 条 HOM 需求内**，是本次逐张核看 5 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-HOM-015 顺延，**尚未登记进主文件 10.2.2**，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。

| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-HOM-016 | **首页促销位的形态与来源**：三版设计稿画了三种互不相同的形态 —— 店长版是底部通栏活动横幅（「马牌高端系列 买三送一」），宫格版是顶部「限时活动」三张商品卡（带划线价、「已售 N」、立减券，**素材含京东JOY / JD.COM / 爱奇艺水印，属第三方电商推广创意**），技工版**没有促销位**；而主文件附录 A.2 又写作「首页**顶部滚动提示**」，共四种说法。需裁决：①最终形态；②数据来源是 ROOS 活动接口（[REQ-HOM-004](#426-业务规则) 现有口径）还是第三方电商商品位；③若含商品位，点击后去哪（App 内商详 / 跳京东小程序 / 跳 [ROOS 采购](./06-PUR-采购.md)）；④技工是否可见（[4.2.4](#424-技工首页) 差异表写 ✅，但技工版稿没画）。 | 本节图 1 / 2 / 3 + 附录 A.2 | 产品 / 业务 |

本次拆分新增待确认项，1 条

> 另有三项**不需新增编号**的观察，已就地记在各图下方：①店长版门店名旁未画切店下拉箭头而宫格版画了（随 [REQ-HOM-001](#426-业务规则) 补稿）；②动态预警角标写「2 项待处理」但只画了 1 条（补稿）；③店长版「待接单」与宫格版「待订单」措辞不一致（随 [REQ-HOM-008](#426-业务规则) 定稿）。
>
> 另有一项数据观察：O2O 消息页**最新一条消息的日期是 2023-04-13**，距今已超三年，且全部为同一类型。可能是该测试账号无近期消息，也可能是 O2O 消息通道现状本就低频 —— 若属后者，「消息中心」在 App 内的实际价值需重新评估。本图不足以判定，建议向业务核实真实门店的消息量级。
