152 lines
15 KiB
Markdown
152 lines
15 KiB
Markdown
# PRD 模块需求文件
|
||
|
||
本目录把 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4 章的 14 个业务模块拆成独立文件，便于分模块维护、分模块评审、分模块指派负责人。
|
||
|
||
## ⚠️ 同步契约（必读）
|
||
|
||
| 项 | 约定 |
|
||
| --- | --- |
|
||
| **谁为准** | **本目录为准。** 需求变更一律改本目录的模块文件 |
|
||
| 主文件第 4 章 | **不要直接编辑，改动会在下次回灌时被覆盖。** 已于 2026-08 完成首次回灌，主文件升至 V1.1，与本目录一致 |
|
||
| 主文件其余章节 | 第 1–3、5–10 章与附录 A/B/C/D 仍以主文件为准，本目录只做**只读引用** |
|
||
| 回灌方式 | 跑 `scripts/build_prd.py backfill`（先 `--dry-run` 看差异）。范围仅限各模块文件 `## 附：本模块归拢信息` 分界线**以上**的部分，分界线以下不回灌 |
|
||
| 回灌时机 | 需要出 Word / PDF 交付件时，或模块文件改完想让主文件跟上时。脚本是幂等的，多跑无害 |
|
||
| 派生数据 | 附录 D.2、头部规模声明、附录 C.3 首句、10.2 图例计数、各模块头部信息表的「需求条数」行——**这五处由脚本重算，不要手改** |
|
||
| 仍需手工维护 | **附录 A / B / C.2 与 10.2 的条目正文**。脚本只校验数目对不对（对不上会在 `verify` 里报出来），不替你写条目 |
|
||
| 编号规则 | 沿用主文件 1.7：`REQ-<模块码>-<3位序号>`，**一经分配不再复用**，删除时保留编号并标注「已废弃」 |
|
||
| 待确认标记 | 沿用 `TODO(REQ-xxx-nnn)`，**禁止使用 `tbd`** |
|
||
|
||
三条命令，都用仓库根目录的 `.venv`（自带 pandoc 与 Pillow，系统 Python 跑不了）：
|
||
|
||
```bash
|
||
.venv/Scripts/python.exe scripts/build_prd.py verify # 只校验，不改文件
|
||
.venv/Scripts/python.exe scripts/build_prd.py backfill --dry-run # 看回灌会改什么
|
||
.venv/Scripts/python.exe scripts/build_prd.py backfill # 回灌，末尾自动跑 verify
|
||
.venv/Scripts/python.exe scripts/build_prd.py export # 压缩配图 + 出 docx
|
||
```
|
||
|
||
`export` 做两件事：把 `prd/` 下三个图源目录的 PNG **就地**调色板量化（首次跑：**23.4 MB → 9.7 MB**；已量化的跳过，日后新加的截图会自动压掉，免得仓库又长胖），再用 pandoc 生成 `prd/Continental-Retail-APP-PRD.docx`（约 9.8 MB，含全部 173 张图与三级目录）。**PDF 不由脚本生成**——pandoc 转 PDF 要 LaTeX，本机没装，用 Word 打开 docx 另存。
|
||
|
||
> 量化是有损的（256 色）。这批截图是扁平 UI 图，实测中位 RMS 误差 0.82/255、最差一张 3.10（延保「扫描车牌」，取景框里有实拍照片），文字与控件肉眼无差别。**原图都在 git 历史里**，要取回某张跑 `git checkout <commit> -- prd/xxx.png`。
|
||
|
||
版式模板是 `scripts/reference.docx`，首次 `export` 时自动生成（pandoc 默认模板 + 把东亚字体钉成标题「微软雅黑」/ 正文「等线」，否则换台机器 Word 会自挑中文字体）。**已存在就原样使用**，在 Word 里改过的版式不会被脚本覆盖；想重置就删掉它再跑一次。
|
||
|
||
> 主文件与本目录并存，漂移风险真实存在。降低漂移的唯一手段是：**只在本目录改需求**，主文件第 4 章当只读产物看待。
|
||
|
||
## 模块索引
|
||
|
||
「需求 / 待确认」两列是**本目录各模块文件的现值**；括号内是逐图核对前的 2026-08 基线，两者的差额就是核图时新增的条目。**主文件[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 与[第 10.2 节](../Continental-Retail-APP-PRD.md#102-待确认项清单)已按括号外的现值同步**，下次改需求后须再同步一次。
|
||
|
||
| 序 | 文件 | 章节 | 模块码 | 粒度 | 需求 | 待确认 | 完成度 | 图 | 现状承载系统 |
|
||
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||
| 01 | [账号登录](./01-LGN-账号登录.md) | 4.1 | LGN | 14 维 | 11 | 7 | 36% | 1 | O2O（用户主数据） |
|
||
| 02 | [APP 首页与导航](./02-HOM-APP首页与导航.md) | 4.2 | HOM | 14 维 | 16（15） | 11（10） | 31% | 5 | ROOS / O2O / 延保 |
|
||
| 03 | [销售](./03-SAL-销售.md) | 4.3 | SAL | 14 维 | 37（14） | 11（6） | 70% | 28 | F6 + O2O |
|
||
| 04 | [提醒](./04-RMD-提醒.md) | 4.4 | RMD | 14 维 | 7 | 2 | 71% | 3 | F6（PC 端，App 内嵌 H5） |
|
||
| 05 | [延保](./05-WTY-延保.md) | 4.5 | WTY | 14 维 | 38（10） | 6（5） | 84% | 43 | 延保门店端 |
|
||
| 06 | [采购](./06-PUR-采购.md) | 4.6 | PUR | 14 维 | 18（13） | 12（7） | 33% | 9 | ROOS（马牌）+ F6（非马牌） |
|
||
| 07 | [库存](./07-INV-库存.md) | 4.7 | INV | 6 维 | 11（7） | 9（5） | 18% | 12 | O2O + ROOS |
|
||
| 08 | [我的 / 个人中心](./08-MIN-我的.md) | 4.8 | MIN | 6 维 | 20（6） | 13（6） | 35% | 16 | ROOS + O2O + 延保 |
|
||
| 09 | [门店管理](./09-STM-门店管理.md) | 4.9 | STM | 6 维 | 14（7） | 13（6） | 7% | 14 | O2O |
|
||
| 10 | [财务与对账](./10-FIN-财务与对账.md) | 4.10 | FIN | 6 维 | 14（7） | 12（5） | 14% | 11 | O2O + ROOS |
|
||
| 11 | [返利中心](./11-RBT-返利中心.md) | 4.11 | RBT | 6 维 | 11（6） | 7（3） | 36% | 10 | O2O + 延保 |
|
||
| 12 | [经营业绩与报表](./12-PRF-经营业绩与报表.md) | 4.12 | PRF | 6 维 | 9（6） | 7（4） | 22% | 8 | O2O + ROOS + 延保 |
|
||
| 13 | [营销与会员](./13-MKT-营销与会员.md) | 4.13 | MKT | 6 维 | 8（5） | 7（4） | 13% | 7 | O2O |
|
||
| 14 | [福利兑换（MSIP）](./14-MSP-福利兑换.md) | 4.14 | MSP | 6 维 | 8（6） | 4 | 50% | 0 | MSIP |
|
||
| | **合计** | | | | **222**（121） | **121**（74） | **46%** | **167** | |
|
||
|
||
模块索引。完成度 =（需求条数 − 待确认）÷ 需求条数。
|
||
|
||
> **括号内的 D.2 基线曾有一处错**：STM 行原记「需求条数 8」，但当时 4.9 正文只有 REQ-STM-001~007 共 7 条且无空号，上表括号内按实际的 7 记（故基线合计 121 实为 120）。根因是 V1.0 的 STM-006/007 挂错了 TODO 编号，已在回灌时连同 FIN、MKT 的同类错位一并修正，主文件 10.2 各行标注了原编号以便追溯。详见 [09-STM 的附-5](./09-STM-门店管理.md#附-5-本次拆分新增发现)。
|
||
>
|
||
> 逐图核对把需求条数从 121 提到 222（+101）、待确认从 74 提到 121（+47 净增：新增 49 条、裁决关闭 2 条）。**增量全部来自逐张核看 167 张配图**：现状截图里实际存在、而 2026-08 版正文一字未提的机制（如门店本地化服务项目价目表、消费券额度按补货率累积、延保生效的两段式确认、扫码出库的「去延保」分支），以及设计稿与现状互相冲突、必须裁决的口径。各模块文件的 `附-5` 逐条列明了触发证据。
|
||
|
||
**需求依据**（主文件 4.0 模块总览）：LGN 业务需求 + 设计稿；HOM 业务需求 + 设计稿 3 版；SAL 业务需求 + 原型图 + O2O 订单截图；RMD 业务需求 + 原型图；WTY 业务需求 + 延保小程序 44 张截图；PUR 业务需求 + ROOS 截图 + 设计稿；INV / FIN / RBT / PRF / MKT 现状截图反推；MIN / STM 业务需求 + 现状截图 + 设计稿；MSP 现状入口 + 设计稿 + 业务确认（页面待补）。
|
||
|
||
> 第 4 章共 173 张图中的 167 张归属这 14 个模块；其余 6 张分布在主文件 2.7 现状小程序功能全景（4 张）与 6.1 / 6.2 后台管理（2 张），不在本目录范围内。
|
||
|
||
## 模块文件结构
|
||
|
||
每个文件以 `## 附：本模块归拢信息` 为分界线：
|
||
|
||
- **分界线以上** —— 1:1 对应主文件 4.x 正文，保留原有小节编号（如 `4.7.1`）。回灌主文件时只处理这部分。
|
||
- **分界线以下** —— 从主文件其它章节归拢来的本模块分片：业务数据字典（附录 A）、权限矩阵（附录 B）、待确认项（10.2）、配图清单（附录 C）。这部分**不回灌**，主文件的附录仍是全局视图。
|
||
|
||
> **文件标题必须与主文件 4.x 标题逐字一致**（如 `# 4.9 门店管理`，**不要**加模块码写成 `# 4.9 门店管理（STM）`）。两个原因：一是回灌时只需把 `#` 降为 `##`，不改标题文字；二是主文件附录 C 用 `[4.9 门店管理](#49-门店管理)` 这类锚点自引，各模块之间的互链也复用同一套 slug —— 标题一改，**上百条链接同时静默失效**。模块码写在下方信息表的「模块码」行和文件名里，标题里不重复。
|
||
|
||
## 配图说明规范（四段式）
|
||
|
||
每张图正下方接四段，段名加粗 + 破折号，与主文件 1.8.1 的写法一致：
|
||
|
||
```markdown
|
||
|
||
|
||
**页面内容** —— 一句话：这是什么页、有哪些主要区块
|
||
|
||
**关键交互** —— ①控件 → 结果 ②控件 → 结果
|
||
|
||
**可用角色** —— 店长 …；技工 …
|
||
|
||
**需求关联** —— REQ-xxx-nnn、REQ-xxx-nnn
|
||
```
|
||
|
||
硬性规则：
|
||
|
||
1. **页面内容只写一句话**，说清「这是什么页 + 有哪些主要区块」即可，**不逐个控件描述文案、颜色、位置**。一句写不下的，说明细节该放到别处：交互过程写进「关键交互」，结论与推断写进图下的 `>` 引用块，冗长的取值清单与脏数据明细写进 `附-5` 的证据列 —— **不在图下重复**。
|
||
2. **写之前必须实际打开该 PNG**，不得据文件名臆造。空态、测试数据、已选中的筛选值属于会误导读者的关键信息，须用一句点明（如「**本图为空态**，记录行字段无法确认」）。看不清或无法判断的写「本图无法确认 xxx」，**不猜**。
|
||
3. **关键交互**用 ①②③ 编号，每条写成「控件 → 结果」。纯静态展示图写「无交互，仅作内容佐证」。
|
||
4. **可用角色**沿用主文件附录 B 图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认。有待确认的就地带 `TODO(REQ-xxx-nnn)`。
|
||
5. **需求关联**列 REQ 编号并锚到本文件的业务规则小节；不支撑任何编号需求的写「—（仅作现状佐证）」。
|
||
6. 图片一律用**相对路径**引用，从本目录出发要多一层 `../`：`../app-design-images/`、`../mini-program-images/{O2O,ROOS,Warranty}/`、`../images/`。
|
||
|
||
## 链接写法
|
||
|
||
| 目标 | 写法 |
|
||
| --- | --- |
|
||
| 本模块内小节 | `[4.7.4](#474-业务规则)` |
|
||
| 其它模块整节 | `[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)` |
|
||
| 其它模块内小节 | `[4.2.5](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)` |
|
||
| 主文件其它章节 / 附录 | `[痛点 2.3](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)` |
|
||
|
||
锚点按 GitHub 规则从标题生成：转小写、去掉标点（含中文全角 `（）、，`）、空格换 `-`。所以 `## 4.14 福利兑换（MSIP）` 的锚点是 `#414-福利兑换msip`，`## 2.3 进销存 / ERP 数据` 的是 `#23-进销存--erp-数据`（`/` 被删除后留下两个空格，成为双连字符）。**写完链接要点开验证**——锚点错了不会报错，只是不跳转。
|
||
|
||
主文件本身仍须满足 CLAUDE.md 的「自包含、只用锚点、不引用其它 md」约束；本目录是仓库内部工作副本，不受该约束限制。
|
||
|
||
## 状态与待办
|
||
|
||
**14 个模块文件已全部建成**，167 张配图逐张核看后写了四段式说明，主文件 10.2 与附录 A/B/C 的本模块分片已归拢到各文件的 `附-1` ~ `附-4`，逐图核对中新增的需求与待确认项记在各文件的 `附-5`。**2026-08 已完成首次回灌**，主文件升至 V1.1。
|
||
|
||
拆分完成后跑过的一致性核对（结果均为通过）：
|
||
|
||
| 核对项 | 结果 |
|
||
| --- | --- |
|
||
| 图片路径可解析 | 167 处引用，磁盘缺失 **0** |
|
||
| 图不丢 | 主文件第 4 章 167 张 ∩ 本目录 167 张，双向差集**均为空** |
|
||
| 每张图都有说明 | 缺四段式说明的图 **0**（拆分前的基线是 173 张里 94 张裸图） |
|
||
| REQ 不丢不重 | 主文件第 4 章 121 个编号，每个**恰好**归属一个模块文件；本目录现有 222 个 |
|
||
| 待确认项 | 主文件 10.2 共 97 条 = 第 4 章 74 条 + 章外 23 条；74 条**全部**落到对应模块的 `附-3`，本目录现为 121 条 |
|
||
| 链接可达 | 全仓 md 共 1784 条带锚点/跨文件链接，失效 **0** |
|
||
|
||
> 最后一项曾一次性失效 139 条：模块文件的一级标题当初写成了 `# 4.9 门店管理（STM）`，多出的模块码改变了 slug，而上百条互链是按主文件的 `## 4.9 门店管理` 生成的。已把 14 个 H1 全部对齐主文件标题，另修正 `#d2-模块覆盖度`→`#d2-模块级追溯汇总`（主文件实为「D.2 模块级追溯汇总」）等 10 处失效目标。规则见上文[模块文件结构](#模块文件结构)与[链接写法](#链接写法)。
|
||
|
||
回灌后在**主文件一侧**另跑过一轮（结果均为通过）：
|
||
|
||
| 核对项 | 结果 |
|
||
| --- | --- |
|
||
| 图片路径可解析 | 173 处引用，磁盘缺失 **0** |
|
||
| 站内锚点 | 1289 条，失效 **0**；正文无跨文件链接（满足 CLAUDE.md 的自包含约束，`modules/` 的指引只写在 HTML 注释里） |
|
||
| REQ 编号 | 全文 296 个不同编号，正文重复定义 **0** |
|
||
| TODO ↔ 10.2 | 正文 146 个 `TODO(...)` 与 10.2 的 144 条 + 2 条已关闭**双向对齐**，无孤儿 |
|
||
| 计数三处联动 | 头部规模声明 / 附录 C / 附录 D.2 / 10.2 均为 296 需求、144 待确认、173 图、44 表；D.2 逐行累加与合计行一致，各行完成度按公式复算无误 |
|
||
| `tbd` | 全文 **0**（唯一一处出现在 1.8 的「本文档不使用 `tbd`」这句禁令本身） |
|
||
|
||
待办：
|
||
|
||
- [x] **回灌主文件**（2026-08 完成）—— 需求条数 121 → 222、待确认 74 → 121（全文 97 → 144、296 条需求），主文件的规模声明、附录 B / C / D.2 与第 10.2 节已同步，第 4 章开头加了指向本目录的 HTML 横幅
|
||
- [x] **构建脚本 [`scripts/build_prd.py`](../../scripts/build_prd.py)**（2026-08 完成）—— `backfill` / `verify` / `export` 三个子命令，见上文[同步契约](#-同步契约必读)。首次机器回灌顺带修好了主文件里 10 处被早前一次编辑误删字符的句子（模块文件留着完好原文）
|
||
- [x] **`prd-export/` 已删除**（2026-08）—— 那是一整套与 `prd/` 一模一样的图片副本，仓库白背 31 MB。改成配图就地量化，docx 直接出到 `prd/Continental-Retail-APP-PRD.docx`
|
||
- [ ] **PDF 待重出**：原 `prd-export/Continental-Retail-APP-PRD.pdf` 是 2026-08-21 的 V1.0 版，内容已过时，已随目录删除。脚本不生成 PDF，须用 Word 打开新 docx 另存到 `prd/Continental-Retail-APP-PRD.pdf`
|
||
- [ ] 主文件附录 A 缺 INV / RBT / MKT / MSP 四个模块的字段清单，需业务补（已记为 `TODO(REQ-INV-011)` 等，见各文件 `附-1`）
|
||
- [ ] 补采两张截图：延保「待补充装车视频」tab（附录 C 第 6、7 行指向的两个文件截图像素一致，该 tab 实际未拍到）、O2O「交易手续费说明」的抖音团购段（被底部按钮遮挡）
|
||
- [ ] 人工抽查：用 VS Code 的 Markdown 预览打开任一模块文件，确认图片经 `../` 正常渲染、四段式说明与图上所见一致（路径已机器校验，渲染效果需肉眼确认）
|