以一个后台基础工具「用户管理」为起点，从零学会产品经理最常用的 8 张图。每张图都给「怎么下笔 → 完整源码 → 踩坑点 → 动手练习」。
后台系统里的工具分两类：CRUD 型（用户管理、商品管理、标签管理）和流程型（退款审批、工单、报销）。流程型带状态、跨角色，新手一上来就画它，会被"状态"和"跨部门"两个难点同时卡住。
用户管理是标准的 CRUD，关系最干净：有列表、有详情、有增删改、有状态、有权限——恰好每一张图都能画到最小的规模。学会它，退款审批那种复杂图只是往上加料：多加两个角色、多加几个状态而已。
这段比后面 8 张图都重要。心法不对，画 100 张图也长不了本事。
新手最常见的错误是：打开工具 → 挑模板 → 拖框 → 想内容。正确顺序刚好反过来。
| 问题 | 为什么必须先问 |
|---|---|
| 这张图给谁看？ | 给老板看要结论、给研发看要细节、给测试看要分支。同一件事，三种画法。 |
| 要表达哪一个问题？ | 一张图只回答一个问题。想同时表达"谁做什么"和"数据怎么存"，就必须画两张。 |
| 图里不画什么？ | 不主动砍，图一定会画爆。先定"这一版不画的部分"，比加东西难，也更有用。 |
这张图的完整用法（什么时候用、更多变体）见 图集 · 2. 功能结构图
什么时候用：需求刚立项，你要跟别人说清"这个工具到底包含哪些功能"。它是所有图里最容易画、也最该先画的——因为它逼你把功能列全。
一句话：「管理员打开用户管理，他能干哪几件事？」把答案列完，图就有了一半。
用户管理。只有一个。
flowchart TD
ROOT[用户管理]
ROOT --> A[用户列表]
ROOT --> B[用户详情]
ROOT --> C[用户编辑]
ROOT --> D[状态管理]
A --> A1[搜索与筛选]
A --> A2[分页浏览]
A --> A3[批量导出]
B --> B1[基础信息]
B --> B2[角色与权限]
B --> B3[操作日志]
C --> C1[新增用户]
C --> C2[修改信息]
C --> C3[重置密码]
D --> D1[启用 / 禁用]
D --> D2[删除用户]
flowchart TD ROOT[用户管理] ROOT --> A[用户列表] ROOT --> B[用户详情] ROOT --> C[用户编辑] ROOT --> D[状态管理] A --> A1[搜索与筛选] A --> A2[分页浏览] A --> A3[批量导出] B --> B1[基础信息] B --> B2[角色与权限] B --> B3[操作日志] C --> C1[新增用户] C --> C2[修改信息] C --> C3[重置密码] D --> D1[启用 / 禁用] D --> D2[删除用户]
这张图的完整用法（什么时候用、更多变体）见 图集 · 3. 信息架构图
什么时候用：要跟人确认"这个功能放在导航的哪个位置、要点几下才能到"。它回答的是用户几步能到目标页面，不是"有哪些页面"。
先问："管理员从后台首页出发，要几步能到用户详情页？"把这条路径上的每一跳写下来，就是信息架构。
flowchart LR
N[后台导航]
N --> G[系统管理]
N --> P[数据看板]
G --> P1[用户管理页]
G --> P2[角色管理页]
G --> P3[操作日志页]
P1 --> D1[用户详情页]
D1 --> E1[编辑信息弹窗]
D1 --> E2[分配角色弹窗]
P2 --> D2[角色权限页]
P --> V1[用户增长看板]
flowchart LR N[后台导航] N --> G[系统管理] N --> P[数据看板] G --> P1[用户管理页] G --> P2[角色管理页] G --> P3[操作日志页] P1 --> D1[用户详情页] D1 --> E1[编辑信息弹窗] D1 --> E2[分配角色弹窗] P2 --> D2[角色权限页] P --> V1[用户增长看板]
这张图的完整用法（什么时候用、更多变体）见 图集 · 8. 页面流程图
什么时候用：画线框/原型之前先定跳转。它管的是"从 A 页面能到哪些页面、什么条件下跳"。
拿一个具体的人来走：管理员想改一个用户的状态（启用 → 禁用）。他从哪进入、点了什么、看到什么、最后回到哪？把他走的这条路写下来。
flowchart LR
L[用户列表页] --> S{是否点击行}
S -->|否| L
S -->|是| D[用户详情页]
D --> ED[编辑信息弹窗]
ED --> SAVE{保存校验}
SAVE -->|通过| OK[保存成功提示]
SAVE -->|不通过| ED
OK --> D
D --> BACK[返回列表页]
D --> DEL{删除确认}
DEL -->|确认| L
DEL -->|取消| D
flowchart LR
L[用户列表页] --> S{是否点击行}
S -->|否| L
S -->|是| D[用户详情页]
D --> ED[编辑信息弹窗]
ED --> SAVE{保存校验}
SAVE -->|通过| OK[保存成功提示]
SAVE -->|不通过| ED
OK --> D
D --> BACK[返回列表页]
D --> DEL{删除确认}
DEL -->|确认| L
DEL -->|取消| D
SAVE -->|不通过| ED 这一条线是最容易被省掉的——但没有它，设计师不知道该在弹窗里留报错位，研发不知道失败后该留在原地还是跳走，测试也测不到。一条失败线都不画的页面流程图，等于没画。
这张图的完整用法（什么时候用、更多变体）见 图集 · 4. 业务流程图（泳道图）
什么时候用：一件事要跨角色才能完成时。泳道图最大的价值是把"这步该谁做"钉死——90% 的评审扯皮都发生在这句话上。
先列角色。哪些人或系统参与了这个流程？后台里常见的是：运营 / 管理员、前端、后端服务、第三方服务（邮件、短信、支付）。一个角色一条泳道，别合并。
flowchart LR
subgraph 运营
A1[点击新增用户]
A5[确认提交]
end
subgraph 前端
A2[表单校验]
end
subgraph 后端服务
A3[用户名查重]
A4[创建账号]
end
subgraph 邮件服务
A6[发送初始密码]
end
A1 --> A2 --> A3
A3 -->|重复| A2
A3 -->|通过| A4 --> A5 --> A6
flowchart LR
subgraph 运营
A1[点击新增用户]
A5[确认提交]
end
subgraph 前端
A2[表单校验]
end
subgraph 后端服务
A3[用户名查重]
A4[创建账号]
end
subgraph 邮件服务
A6[发送初始密码]
end
A1 --> A2 --> A3
A3 -->|重复| A2
A3 -->|通过| A4 --> A5 --> A6
这张图的完整用法（什么时候用、更多变体）见 图集 · 5. 状态流转图
什么时候用：只要这个东西有"状态"——用户（未激活 / 已激活 / 禁用 / 锁定）、订单、工单、审批单。图里任何对象有状态，就必须画这张。
先问三个问题：① 它一共有几种状态？② 哪些状态是终点（进去就出不来）？③ 每个状态能跳到哪些状态？
stateDiagram-v2
[*] --> 未激活
未激活 --> 已激活: 首次登录成功
未激活 --> 已禁用: 管理员禁用
已激活 --> 已禁用: 管理员禁用
已激活 --> 已锁定: 密码连续错误 5 次
已锁定 --> 已激活: 重置密码
已禁用 --> 已激活: 管理员启用
已激活 --> 已删除: 管理员删除
已禁用 --> 已删除: 管理员删除
已锁定 --> 已删除: 管理员删除
已删除 --> [*]
stateDiagram-v2 [*] --> 未激活 未激活 --> 已激活: 首次登录成功 未激活 --> 已禁用: 管理员禁用 已激活 --> 已禁用: 管理员禁用 已激活 --> 已锁定: 密码连续错误 5 次 已锁定 --> 已激活: 重置密码 已禁用 --> 已激活: 管理员启用 已激活 --> 已删除: 管理员删除 已禁用 --> 已删除: 管理员删除 已锁定 --> 已删除: 管理员删除 已删除 --> [*]
这张图的完整用法（什么时候用、更多变体）见 图集 · 11. ER 图
什么时候用：要跟研发对齐"数据怎么存、字段有哪些、表之间什么关系"。产品画 ER 图的目的是挑出字段缺失和口径不一致，不是设计数据库。
先问："这个功能里，有哪些东西需要被记下来？"用户、角色、操作日志——每个"东西"就是一个实体，每个实体就是一张表。
erDiagram
USER ||--o{ USER_ROLE : 拥有
ROLE ||--o{ USER_ROLE : 包含
USER ||--o{ OPERATION_LOG : 产生
USER {
bigint id PK
string username
string phone
string email
int status
datetime last_login_at
datetime created_at
}
ROLE {
bigint id PK
string role_name
string permission_codes
}
USER_ROLE {
bigint user_id FK
bigint role_id FK
}
OPERATION_LOG {
bigint id PK
bigint user_id FK
string action
string detail
datetime created_at
}
erDiagram
USER ||--o{ USER_ROLE : 拥有
ROLE ||--o{ USER_ROLE : 包含
USER ||--o{ OPERATION_LOG : 产生
USER {
bigint id PK
string username
string phone
string email
int status
datetime last_login_at
datetime created_at
}
ROLE {
bigint id PK
string role_name
string permission_codes
}
USER_ROLE {
bigint user_id FK
bigint role_id FK
}
OPERATION_LOG {
bigint id PK
bigint user_id FK
string action
string detail
datetime created_at
}
| 符号 | 含义 | 例子 |
|---|---|---|
||--|| | 一对一 | 用户 —— 用户实名信息 |
||--o{ | 一对多 | 一个用户 —— 多条操作日志 |
}o--o{ | 多对多 | 用户 —— 角色（中间加关联表） |
varchar(64) 还是 text，那是研发的活。产品要盯的是业务字段完整性——"禁用原因"、"禁用操作人"、"禁用时间"这三个字段，业务上需要记录吗？这种问题研发不会主动问，你问了才是价值。
这张图的完整用法（什么时候用、更多变体）见 图集 · 6. 时序图
什么时候用：和研发对齐接口调用顺序、以及失败时怎么处理。它是唯一能表达"先调谁后调谁"的图。
先列参与者，按调用方向从左到右排：用户、前端、后端、数据库、第三方。谁发起谁在最左边。
Note over 或分支把失败路径标出来。这是产品画时序图唯一的核心价值——研发自己会想顺利路径，但不会主动告诉你失败时是重试还是报错。
sequenceDiagram
participant U as 管理员
participant W as 前端页面
participant S as 用户服务
participant D as 数据库
participant M as 邮件服务
U->>W: 填写表单并提交
W->>W: 表单格式校验
W->>S: POST /users 创建用户
S->>D: 查询用户名 / 手机号是否重复
D-->>S: 无重复记录
S->>D: 插入用户记录
D-->>S: 插入成功
S->>M: 异步触发初始密码邮件
S-->>W: 201 创建成功
W-->>U: 提示成功并返回列表
Note over S,M: 若查重命中则返回 409，不创建账号
Note over M: 邮件失败不回滚账号，进入重发队列
sequenceDiagram participant U as 管理员 participant W as 前端页面 participant S as 用户服务 participant D as 数据库 participant M as 邮件服务 U->>W: 填写表单并提交 W->>W: 表单格式校验 W->>S: POST /users 创建用户 S->>D: 查询用户名 / 手机号是否重复 D-->>S: 无重复记录 S->>D: 插入用户记录 D-->>S: 插入成功 S->>M: 异步触发初始密码邮件 S-->>W: 201 创建成功 W-->>U: 提示成功并返回列表 Note over S,M: 若查重命中则返回 409，不创建账号 Note over M: 邮件失败不回滚账号，进入重发队列
Note over 才是这张图真正的价值所在——这张图的完整用法（什么时候用、更多变体）见 图集 · 18. 分层架构图
什么时候用：评审、立项、给领导汇报时，让人一眼看清「这套系统有多大、分几块、谁依赖谁」。它不讲流程——图上没有箭头串业务，只有层。这是它和流程图最根本的区别。
先定分几层，不是先想画什么形状。后台系统基本就是这 5 层，你把清单里的东西往这 5 个筐里扔就行：
| 层 | 往里放什么 | 怎么判断该不该放这层 |
|---|---|---|
| ① 接入层 | 用户从哪儿进来 | PC 后台、App、小程序、开放 API、第三方对接 |
| ② 应用层 | 用户直接点的功能 | 能对应到某个页面或按钮的，就放这层 |
| ③ 服务层 | 被多个功能复用的能力 | 只有一个页面用 → 不是服务，别往上拆 |
| ④ 数据层 | 数据落在哪儿 | 主库、缓存、文件、搜索、向量库 |
| ⑤ 基础设施层 | 跑这些东西的地基 | 服务器、容器、网关、日志、监控 |
flowchart TB
subgraph L1["① 接入层 · 用户从哪儿进来"]
direction LR
A1["运营后台 Web"] --- A2["企业微信 / 钉钉"] --- A3["开放 API"]
end
subgraph L2["② 应用层 · 用户直接点的功能"]
direction LR
B1["用户列表与检索"] --- B2["用户详情与编辑"] --- B3["角色与权限分配"]
end
subgraph L3["③ 服务层 · 被多个功能复用的能力"]
direction LR
C1["账号服务"] --- C2["权限校验"] --- C3["通知服务"]
end
subgraph L4["④ 数据层 · 数据落在哪儿"]
direction LR
D1["用户主库"] --- D2["会话缓存"] --- D3["操作日志库"]
end
subgraph L5["⑤ 基础设施层 · 跑这些东西的地基"]
direction LR
E1["容器 / 服务器"] --- E2["网关"] --- E3["日志与监控"]
end
L1 --> L2 --> L3 --> L4 --> L5
flowchart TB
subgraph L1["① 接入层 · 用户从哪儿进来"]
direction LR
A1["运营后台 Web"] --- A2["企业微信 / 钉钉"] --- A3["开放 API"]
end
subgraph L2["② 应用层 · 用户直接点的功能"]
direction LR
B1["用户列表与检索"] --- B2["用户详情与编辑"] --- B3["角色与权限分配"]
end
subgraph L3["③ 服务层 · 被多个功能复用的能力"]
direction LR
C1["账号服务"] --- C2["权限校验"] --- C3["通知服务"]
end
subgraph L4["④ 数据层 · 数据落在哪儿"]
direction LR
D1["用户主库"] --- D2["会话缓存"] --- D3["操作日志库"]
end
subgraph L5["⑤ 基础设施层 · 跑这些东西的地基"]
direction LR
E1["容器 / 服务器"] --- E2["网关"] --- E3["日志与监控"]
end
L1 --> L2 --> L3 --> L4 --> L5
前面 8 张图都是 Mermaid 源码。这一章告诉你怎么把它变成能看的图，两条路线任选。
零安装、零成本，而且你本来就在用飞书。
```mermaid 然后回车（三个反引号 + mermaid）。飞书会自动创建一个 Mermaid 代码块。open 了网址就能用，不用注册。适合要交给别人、要打印、要导图的正式场景。
swimlane，直接把泳道容器拖进来，再往里放框。| 可以用 AI 做的 | 不能交给 AI 的 |
|---|---|
| 把一段文字转成 Mermaid 初稿 | 判断"这个状态能不能跳"——业务决策 |
| 给已有图补排版、补配色 | 检查有没有漏掉分支（它只会画你提到的） |
| 把流程图转成别的格式 | 确认角色权责——得你和业务方定 |
画图的唯一学习方式就是画。每题都用一个真实的后台功能，做完这 10 题，日常需求里的图你都能自己出了。
| # | 题目 | 练的是 |
|---|---|---|
| 1 | 选一个你熟悉的后台工具（商品管理 / 标签管理 / 公告管理都行），画它的功能结构图，第一层控制在 4 个以内 | 列全功能、同层粒度一致 |
| 2 | 给第 1 题的工具画信息架构图，标出到最深页面要几跳 | 页面层级、层级深度控制 |
| 3 | 找一个你正在用的后台系统（公司内部的就行），画出它的信息架构，找出一个"超过 3 跳"的路径 | 用图发现真实问题 |
| # | 题目 | 练的是 |
|---|---|---|
| 4 | 画"新增一条公告"的页面流程图，必须包含"保存失败"的回退线 | 失败分支不能省 |
| 5 | 画"商品批量下架"的页面流程图，包含"部分成功部分失败"的情况 | 批量操作的特殊场景 |
| 6 | 画"运营提交一条公告 → 主管审批 → 发布"的泳道图，泳道：运营 / 主管 / 系统 | 跨角色权责划分 |
| # | 题目 | 练的是 |
|---|---|---|
| 7 | 给"公告"画状态流转图：草稿 / 待审 / 已发布 / 已下架 / 已删除。标出终态，并检查每个状态有没有回退路径 | 状态穷举、终态、回退 |
| 8 | 把第 7 题的状态图转成状态矩阵表（行是当前状态、列是目标状态，格子里填触发条件） | 用矩阵自查漏项 |
| 9 | 给"商品"画 ER 图：商品、分类、SKU、库存。注意检查"创建时间""操作人""软删除标记"三个字段在不在 | 业务字段完整性 |
| 10 | 画"用户下单"的时序图：用户 / 前端 / 订单服务 / 库存服务 / 支付服务。至少标出两条失败路径 | 异步与失败分支 |
每次画完图，拿这张表过一遍。前 5 条是高频错误，后 5 条是进阶自查。
| # | 错误 | 后果 | 怎么改 |
|---|---|---|---|
| 1 | 只画顺利路径 | 评审必被追问，等于没画；测试测不到 | 每张流程图至少补一条"失败 / 异常"分支 |
| 2 | 状态图漏终态和回退 | 研发做出状态机死锁，上线才发现 | 先穷举状态 → 标终态 → 再画箭头；最后用状态矩阵自查 |
| 3 | 一张图想表达两件事 | 图爆炸，看的人抓不到重点 | 一张图只回答一个问题，拆成两张 |
| 4 | 同层粒度不一致 | 图看着歪，说明某块没想清 | 同一层级的节点，描述详细程度必须一致 |
| 5 | 先挑模板再想内容 | 图很漂亮但没信息量 | 改成：纯文本列清单 → 连关系 → 最后才开工具 |
| 6 | 箭头没写条件 | 研发不知道什么时候走这条线 | 每条有分支的箭头都标触发条件 |
| 7 | 泳道里混进系统内部模块 | 角色边界模糊，权责讨论失效 | 泳道只放有决策权的参与方 |
| 8 | ER 图盯着字段类型 | 花了力气，但没发现业务缺口 | 产品只盯业务字段是否完整，类型交给研发 |
| 9 | 时序图不标异步 | 用户看到的表现和预期不符 | 明确标出哪些调用是同步等、哪些是异步不等 |
| 10 | AI 出的图直接当终稿 | 关系错、顺序反、漏分支，还错得很自信 | 逐节点核一遍再发出去 |
以电商后台「退款审批（含 AI 自动预审）」为例，把产品经理该掌握和该看懂的图全部走一遍。
| 分级 | 图 | 为什么是这个级别 |
|---|---|---|
| 必会画 10 张 |
1 系统架构图 · 2 功能结构图 · 3 信息架构图 · 4 泳道图 · 5 状态流转图 · 8 页面流程图 · 12 指标树 · 15 价值-成本四象限 · 16 AI 决策与人工兜底 · 18 分层架构图 | 这些是只有产品能画、别人替不了的图。架构图决定系统视角，泳道图决定权责划分，状态图决定会不会出事故，指标树决定上线后怎么验收。面试也基本只问这几张。 |
| 常用 4 张 |
6 时序图 · 9 线框图 · 11 ER 图 · 13 埋点事件图 | 要看得懂，也要能画简版；但精修环节通常研发、设计、数据同学会接手。你的价值在于「能挑出缺什么」——时序图缺失败分支、ER 图缺业务字段、埋点图缺指标口径。 |
| 了解即可 5 张 |
7 用户旅程图 · 10 AI 数据流图 · 14 漏斗图 · 17 Prompt 与评审指标 · 19 数据治理闭环 | 知道它长什么样、能读懂、能提得出要求就够了，实际通常由用研、算法、数据同学主画。但「能读懂」不是可选项——看不懂这三张，你没法评估他们给的结论对不对。 |
| 清单里的图 | 本图集对应章节 |
|---|---|
| 业务架构图 （严格说应为「系统架构图」） | 1. AI 系统架构图 |
| 用户旅程图 | 7. 用户旅程图 |
| 泳道图 | 4. 业务流程图（泳道图） |
| 时序图 | 6. 时序图 |
| 状态图 | 5. 状态流转图 |
| 信息架构图 | 3. 信息架构图 |
| 原型图 / 线框图 | 9. 线框图 |
| 数据流图 | 10. AI 数据流图 |
解决「系统里有哪些模块、模块之间怎么协作」。这是 AI 产品经理和普通 PM 最大的分水岭：普通 PM 画功能模块，你画的是 LLM、Memory、Tool、MCP、知识库和业务系统之间的关系。
flowchart TD
subgraph 接入层
A1[买家端]
A2[客服工作台]
A3[财务后台]
end
subgraph Agent编排层
B1[任务规划 Planner]
B2[会话记忆 Memory]
B3[工具调用 Tool]
end
subgraph 模型层
C1[LLM 推理]
C2[Embedding 模型]
C3[重排序 Rerank]
end
subgraph 知识与数据层
D1[RAG 检索]
D2[向量库]
D3[规则知识库]
D4[业务数据库]
end
subgraph 外部能力层
E1[MCP Server]
E2[支付网关]
E3[OCR 服务]
end
A1 --> B1
A2 --> B1
A3 --> B1
B1 --> C1
B2 --> C1
D2 --> D1
D3 --> D1
D4 --> D1
D1 --> C1
C1 --> B3
B3 --> E1
B3 --> E2
E1 --> B3
E2 --> B3
E3 --> D1
想看这张图怎么下笔画 → 画图手册 · 1. 功能结构图
解决「这个模块到底有多大」。拆完你就知道该分几个需求、排几期。
graph TD
A[退款审批模块] --> B[退款单管理]
A --> C[审核工作台]
A --> D[打款管理]
A --> E[配置中心]
A --> F[数据看板]
B --> B1[列表与筛选]
B --> B2[详情与凭证]
B --> B3[批量导出]
C --> C1[初审队列]
C --> C2[复审与申诉]
C --> C3[AI 建议与理由]
C --> C4[驳回理由模板]
D --> D1[批量打款]
D --> D2[失败补单]
D --> D3[渠道对账]
E --> E1[AI 阈值配置]
E --> E2[消息模板]
E --> E3[角色与权限]
F --> F1[核心指标]
F --> F2[漏斗与趋势]
想看这张图怎么下笔画 → 画图手册 · 2. 信息架构图
解决「用户几步能点到目标页面」。做后台、工作台、知识库这类产品必画——它回答的是导航深度，不是页面清单。
flowchart LR
R[退款审批模块] --> M1[退款单管理]
R --> M2[审核工作台]
R --> M3[打款管理]
R --> M4[配置中心]
R --> M5[数据看板]
M1 --> P11[退款单列表]
M1 --> P12[退款单详情]
M2 --> P21[待初审队列]
M2 --> P22[复审与申诉]
M3 --> P31[待打款批次]
M3 --> P32[失败补单与重试]
M4 --> P41[AI 阈值与开关]
M4 --> P42[角色与权限]
M5 --> P51[核心指标]
M5 --> P52[漏斗与趋势]
想看这张图怎么下笔画 → 画图手册 · 4. 业务流程图（泳道图）
解决「谁在什么时点做什么」。跨部门需求评审的核心武器，权责一旦画出来就没得扯。
flowchart TB
subgraph 买家
A1[提交退款申请]
A2[收到结果通知]
end
subgraph AI预审引擎
B1[拉取订单与历史行为]
B2[预审打分并输出理由]
end
subgraph 客服
C1[人工初审]
C2[驳回并填写理由]
end
subgraph 财务
D1[财务复核]
D2[发起批量打款]
end
subgraph 支付网关
E1[执行打款]
E2[回调打款结果]
end
A1 --> B1 --> B2
B2 --> C1
B2 --> D1
C1 --> C2
C1 --> D1
D1 --> D2 --> E1 --> E2
E2 --> A2
想看这张图怎么下笔画 → 画图手册 · 5. 状态流转图
解决「这个状态能不能跳到那个状态」。研发问得最多的一张图，漏了终态和回退就是线上事故。
stateDiagram-v2
[*] --> 待预审
待预审 --> 预审中: 进入风控队列
预审中 --> 待初审: 中低置信或大额
预审中 --> 打款中: 高置信且小额
待初审 --> 待复核: 初审通过
待初审 --> 已驳回: 初审不通过
待复核 --> 打款中: 复核通过
待复核 --> 已驳回: 复核不通过
打款中 --> 已完成: 渠道成功
打款中 --> 打款失败: 渠道失败或超时
打款失败 --> 打款中: 自动重试
打款失败 --> 已完成: 人工补打
已驳回 --> 预审中: 买家申诉
已完成 --> [*]
想看这张图怎么下笔画 → 画图手册 · 7. 时序图
解决「接口谁先谁后、失败怎么办」。这张图是研发画的，你要能一眼看出它缺了失败分支和降级路径。
sequenceDiagram
participant B as 买家端
participant G as 后台服务
participant AI as AI 预审引擎
participant C as 客服工作台
participant P as 支付网关
B->>G: 提交退款申请
G->>G: 校验订单状态与退款金额
G->>AI: 请求预审打分
AI-->>G: 返回置信度与理由
alt 高置信且小额
G-->>B: 自动通过通知
G->>P: 发起退款
P-->>G: 打款成功
else 中低置信或大额
G->>C: 进入人工初审队列
C->>G: 提交审核结论
G->>P: 发起退款
P-->>G: 打款成功
end
Note over AI,G: AI 超时 3 秒即降级转人工
P-->>G: 异步回调最终结果
G-->>B: 退款到账通知
Note over AI,G: 人工结论回流为训练样本
解决「用户在哪一步最想骂人」。情绪低点是需求的来源，不是拍脑袋来的。
journey
title 买家退款旅程
section 发起申请
找到退款入口: 3: 买家
填写退款原因: 2: 买家
section 提交凭证
上传图片凭证: 1: 买家
提交申请: 2: 买家
section 等待审核
等待审核结果: 1: 买家
section 收到结果
查看审核结论: 4: 买家
section 退款到账
钱到账: 5: 买家
想看这张图怎么下笔画 → 画图手册 · 3. 页面流程图
解决「点了之后去哪」。画线框之前先定这个，不然原型返工。
flowchart LR
P1[退款单列表] --> P2[退款单详情]
P1 --> P3[批量打款确认页]
P2 --> P4[人工审核面板]
P2 --> P5[申诉记录页]
P4 --> P6[驳回理由填写]
P4 --> P7[通过并提交财务]
P7 --> P3
P3 --> P8[打款结果页]
解决「页面骨架长什么样」。用灰度块和假数据就行，别在这一步纠结颜色。目的是让研发和设计在写代码前就页面结构达成一致。
| 区域 | 必须覆盖的状态 |
|---|---|
| 筛选区 | 默认、筛选无结果、条件组合过多提示 |
| 数据表格 | 加载中、空态、超 500 条分页、AI 未跑完 |
| 详情抽屉 | 凭证加载失败、AI 置信度过低警告 |
| 批量操作 | 无勾选禁用、超权限置灰、二次确认 |
解决「数据从哪来、到哪去」。AI 产品里这条链最长也最容易断——很多人只画了离线建库和在线推理，忘了回流那一环，结果模型永远是第一天的水平。
flowchart LR
subgraph 离线数据准备
A1[业务库与日志] --> A2[采集清洗]
A2 --> A3[切分 Chunk]
A3 --> A4[Embedding 向量化]
A4 --> A5[向量库]
end
subgraph 在线请求链路
B1[用户请求] --> B2[RAG 检索]
B2 --> B3[拼接上下文]
B3 --> B4[LLM 推理]
B4 --> B5[结构化输出]
end
subgraph 回流模型迭代
C1[人工结论与申诉] --> C2[标注与质检]
C2 --> C3[训练样本集]
C3 --> C4[微调与评测]
end
A5 --> B2
B5 --> C1
C4 -.-> B4
想看这张图怎么下笔画 → 画图手册 · 6. ER 图
解决「数据存在哪、字段够不够」。产品不用会建表，但必须能挑出缺字段——比如漏了 ai_score，后面就没法做数据回流。
erDiagram
REFUND_ORDER ||--o{ REFUND_ATTACHMENT : 附带
REFUND_ORDER ||--o{ AUDIT_LOG : 产生
REFUND_ORDER ||--o{ PAYMENT_RECORD : 关联
REFUND_ORDER }o--|| ORDER : 来源
REFUND_ORDER }o--|| USER : 申请
REFUND_ORDER {
string refund_id PK
string order_id FK
string buyer_id FK
decimal amount
string reason_code
string status
decimal ai_score
string ai_reason
string current_operator
datetime created_at
}
REFUND_ATTACHMENT {
string attach_id PK
string refund_id FK
string file_url
string attach_type
}
AUDIT_LOG {
string log_id PK
string refund_id FK
string operator
string action
string remark
datetime created_at
}
PAYMENT_RECORD {
string pay_id PK
string refund_id FK
string channel
string channel_txn_id
string pay_status
datetime paid_at
}
ORDER {
string order_id PK
decimal pay_amount
string item_status
datetime paid_at
}
USER {
string user_id PK
string nickname
int risk_level
int refund_count_90d
}
解决「提升效率这句话落在谁头上」。北极星往下拆到能被单个人负责的粒度，否则不是指标，是口号。
graph TD
N[退款资金安全率] --> A[效率]
N --> B[成本]
N --> C[体验]
N --> D[风险]
A --> A1[平均退款时长]
A --> A2[自动通过率]
B --> B1[人工介入率]
B --> B2[单均人力成本]
C --> C1[退款满意度]
C --> C2[申诉率]
D --> D1[资损率]
D --> D2[误通过率]
解决「数据从哪来」。指标树上每一个指标，都要能倒推回某个埋点事件，否则上线后你只能干瞪眼。
flowchart LR
E1[refund_apply_click] --> E2[refund_reason_select]
E2 --> E3[refund_attach_upload]
E3 --> E4[refund_submit]
E4 --> E5[ai_precheck_done]
E5 --> E6[audit_manual_submit]
E6 --> E7[payout_request]
E7 --> E8[payout_callback]
E8 --> E9[refund_finish]
| 事件 | 关键参数 |
|---|---|
ai_precheck_done | refund_id、ai_score、model_version、cost_ms、是否超时降级 |
audit_manual_submit | refund_id、operator_id、结论、是否采纳 AI 建议、处理时长 |
payout_callback | refund_id、channel、结果、失败码、重试次数 |
解决「转化在哪一步掉的」。退款场景里，漏斗掉的每一格都对应一个可优化的动作。
flowchart TD
F1[提交退款申请 100%] --> F2[AI 自动通过 62%]
F1 --> F3[转人工初审 38%]
F3 --> F4[初审通过 30%]
F4 --> F5[财务复核通过 28%]
F5 --> F6[打款成功 27%]
解决「先做哪个、明确不做什么」。只列要做的、不列不做的，那不叫排优先级。
quadrantChart
title 退款模块需求优先级
x-axis 低成本 --> 高成本
y-axis 低价值 --> 高价值
quadrant-1 规划
quadrant-2 先做
quadrant-3 顺手做
quadrant-4 不做
AI自动预审: [0.25, 0.85]
批量打款: [0.3, 0.8]
退款原因结构化: [0.2, 0.7]
申诉自动仲裁: [0.75, 0.8]
跨渠道自动对账: [0.8, 0.7]
风控模型自训练: [0.85, 0.6]
列表筛选导出: [0.2, 0.25]
退款单备注: [0.15, 0.2]
消息模板配置: [0.25, 0.3]
全自动无人工: [0.85, 0.25]
模型实时热更新: [0.9, 0.3]
自建大模型: [0.95, 0.2]
普通产品画「订单状态」，AI 产品必须多画一张「模型不确定时怎么办」。阈值怎么定、谁兜底、降级路径是什么，全在这张图里。
flowchart TD
A[退款申请] --> B[AI 预审打分]
B --> C{置信度与金额}
C -->|置信不低于0.9 且金额不超200| D[自动通过]
C -->|置信不低于0.9 但金额超200| E[转人工初审 大额必审]
C -->|置信0.6到0.9| F[转人工初审 附AI理由]
C -->|置信低于0.6| G[转人工复审 附建议驳回]
B -.->|超时或异常| H[兜底转人工]
D --> I[进入打款队列]
E --> I
F --> J[人工结论]
G --> J
H --> J
J -.->|结论回流| K[训练样本集]
K -.->|定期重训| B
解决「模型吃了什么、输出什么、怎么验收」。Prompt 结构图让研发和你对齐上下文；评审指标让「效果还行」变成可验收的数字。
flowchart LR
subgraph 输入上下文
I1[订单信息 金额 时间]
I2[买家历史 退款次数 风险等级]
I3[凭证图片 OCR 文本]
I4[客服聊天记录摘要]
end
I1 --> P[Prompt 模板]
I2 --> P
I3 --> P
I4 --> P
P --> M[大模型]
M --> O[结构化输出 JSON]
O --> V[规则校验层]
V --> R[置信度 判定 理由]
| 指标 | 定义 | 验收线（示例） |
|---|---|---|
| 准确率 | AI 判定与人工最终结论一致的比例 | ≥ 92% |
| 误通过率 | AI 判定通过、但人工认定为应驳回的比例 | ≤ 0.5% |
| 误驳回率 | AI 判定驳回、但人工认定为应通过的比例 | ≤ 3% |
| 自动通过率 | 无需人工介入即完成的退款单占比 | ≥ 55% |
| 单次耗时 | 从请求到返回结果的 P95 耗时 | ≤ 3 秒 |
| 降级率 | 因超时或异常转人工的比例 | ≤ 2% |
| 理由可读性 | 客服认为 AI 理由可直接用于沟通的比例 | ≥ 80% |
想看这张图怎么下笔画 → 画图手册 · 8. 分层架构图
解决「这套系统到底分几块、谁依赖谁」。它和 1 号系统架构图画的是同一类东西，区别只在「按功能模块分」还是「按层分」——1 号图回答"有哪些模块"，这张回答"上下分几层"。
flowchart TB
subgraph L1["① 接入层 · 用户从哪儿进来"]
direction LR
A1["商家后台 Web"] --- A2["买家端 / 小程序"] --- A3["开放 API"]
end
subgraph L2["② 应用层 · 用户直接点的功能"]
direction LR
B1["退款单列表"] --- B2["审批工作台"] --- B3["规则配置"] --- B4["数据看板"]
end
subgraph L3["③ 服务层 · 被多处分复用的能力"]
direction LR
C1["退款服务"] --- C2["审批流引擎"] --- C3["风控校验"] --- C4["消息通知"]
end
subgraph L4["④ 数据层 · 数据落在哪儿"]
direction LR
D1["退款主库"] --- D2["缓存"] --- D3["日志 / 审计库"] --- D4["向量库（AI 预审）"]
end
subgraph L5["⑤ 基础设施层 · 跑这些东西的地基"]
direction LR
E1["容器 / 服务器"] --- E2["API 网关"] --- E3["日志与监控"]
end
L1 --> L2 --> L3 --> L4 --> L5
flowchart TB
subgraph L1["① 接入层 · 用户从哪儿进来"]
direction LR
A1["商家后台 Web"] --- A2["买家端 / 小程序"] --- A3["开放 API"]
end
subgraph L2["② 应用层 · 用户直接点的功能"]
direction LR
B1["退款单列表"] --- B2["审批工作台"] --- B3["规则配置"] --- B4["数据看板"]
end
subgraph L3["③ 服务层 · 被多处分复用的能力"]
direction LR
C1["退款服务"] --- C2["审批流引擎"] --- C3["风控校验"] --- C4["消息通知"]
end
subgraph L4["④ 数据层 · 数据落在哪儿"]
direction LR
D1["退款主库"] --- D2["缓存"] --- D3["日志 / 审计库"] --- D4["向量库（AI 预审）"]
end
subgraph L5["⑤ 基础设施层 · 跑这些东西的地基"]
direction LR
E1["容器 / 服务器"] --- E2["API 网关"] --- E3["日志与监控"]
end
L1 --> L2 --> L3 --> L4 --> L5
解决「数据从哪来、经过什么、最后去哪」。政务、央企、数据中台的汇报材料里几乎必出现，通常写成 采 → 集 → 治 → 分 → 用 → 保 六个字。
flowchart LR
A["① 采集 · 多源数据进得来"] --> B["② 集成 · 清洗、对齐口径"] --> C["③ 治理 · 质量 / 标准 / 血缘"]
C --> D["④ 分析 · 建模、标签、指标"] --> E["⑤ 应用 · 报表、推荐、AI"]
E -.->|"回流迭代"| A
subgraph S["⑥ 保障 · 贯穿全程，不在链上任何一环"]
direction LR
S1["标准规范"] --- S2["安全合规"] --- S3["运维监控"] --- S4["组织与流程"]
end
flowchart LR
A["① 采集 · 多源数据进得来"] --> B["② 集成 · 清洗、对齐口径"] --> C["③ 治理 · 质量 / 标准 / 血缘"]
C --> D["④ 分析 · 建模、标签、指标"] --> E["⑤ 应用 · 报表、推荐、AI"]
E -.->|"回流迭代"| A
subgraph S["⑥ 保障 · 贯穿全程，不在链上任何一环"]
direction LR
S1["标准规范"] --- S2["安全合规"] --- S3["运维监控"] --- S4["组织与流程"]
end
以电商后台「退款审批（含 AI 自动预审）」为例，按标准 PRD 结构 + EARS 需求描述原则撰写。每章标注使用频率，可当模板直接改用。
作用只有一个：让人知道找谁、改过什么。3 分钟能填完，但省掉的是每周三小时的扯皮。
| 版本 | 日期 | 修改人 | 改动摘要 |
|---|---|---|---|
| v1.0 | 2026-09-18 | 产品 | 初稿，覆盖退款审批主流程 + AI 自动预审 |
| v1.1 | — | 产品 | （评审后补：按风控意见调整置信度阈值） |
| 角色 | 负责人 | 职责 |
|---|---|---|
| 产品负责人 | 待填 | 需求定义、范围裁决、验收 |
| 设计 | 待填 | 交互稿、设计验收点 |
| 前端 / 后端 | 待填 | 技术方案、排期、实现 |
| 算法 | 待填 | 模型选型、准确率达标、数据回流 |
| 测试 | 待填 | 用例、回归范围、上线把关 |
| 风控 / 财务 | 待填 | 阈值与口径的共同决策方——不是知会方 |
写「现状有多痛」，不是写「我们要做什么」。区分点：这一段里不该出现任何功能名。
| 角色 | 痛点 | 后果 |
|---|---|---|
| 买家 | 提交后不知道要等多久，也无进度可见 | 反复催问客服 / 差评 / 流失 |
| 客服 | 被迫承接「我的退款到哪了」的重复询问 | 客服成本被无效咨询吃掉约 40% |
| 审核员 | 大量重复劳动，规则靠经验而非标准 | 口径不一致，同一单不同人结论不同 |
| 风控 / 财务 | 缺事前拦截，只能事后追 | 薅羊毛 / 恶意退款难以及时止损 |
目标必须可量化、可归因。写「提升用户体验」等于没写。
| 层级 | 目标 |
|---|---|
| 业务目标 | 降低售后投诉中「退款慢」相关占比，提升售后退款处理效率 |
| 产品目标 | 常规退款自动闭环，审核员只处理争议与异常单 |
| 技术目标 | 建立可迭代的模型 + 人工回流闭环，具备持续调优能力 |
| 类型 | 指标 | 现状 | 目标值 |
|---|---|---|---|
| 北极星 | 退款平均处理时长（提交 → 终态） | 4.6 h | ≤ 1 h |
| 北极星 | 常规退款自动闭环率 | 0% | ≥ 70% |
| 护栏 | 模型审批准确率 | — | ≥ 92% |
| 护栏 | 误通过率（不该退却退了） | — | ≤ 0.5% |
| 护栏 | 降级率（模型异常转人工） | — | ≤ 2% |
| 护栏 | 售后投诉「退款慢」占比 | 31% | ≤ 15% |
小型需求可以合并到第 2 章。中大型需求独立成章，尤其当「用户」包含内部角色（客服、审核员）时。
| 角色 | 使用频次 | 核心诉求 |
|---|---|---|
| 买家 | 事件触发 | 尽快拿到退款，过程透明 |
| 客服 | 高频 | 能查到单、能代客发起、能解释进度 |
| 审核员 | 高频（自动预审后降为低频） | 只处理真正需要判断的单，有依据可循 |
| 风控专员 | 中频 | 拦截疑似恶意退款，可追溯 |
| 财务 | 低频 / 批量 | 账目可对、口径一致 |
| 编号 | 用户故事 | 优先级 |
|---|---|---|
| US-001 | 作为买家，我希望提交退款后立即知道预计到账时间，以便不用反复询问客服 | P0 |
| US-002 | 作为审核员，我希望系统只把模型不确定的单推给我，以便专注处理真正需要判断的案例 | P0 |
| US-003 | 作为客服，我希望能在同一页面看到退款单全链路进度，以便一次性回答买家 | P1 |
| US-004 | 作为风控专员，我希望看到模型给出判断的依据摘要，以便判断是否人工推翻 | P1 |
| US-005 | 作为财务，我希望每笔自动放款都有可追溯的审批记录，以便对账与审计 | P0 |
「明确不做」这四个字的含金量，高于整个「做什么」清单。不写，需求就会在评审会上无限膨胀。
PRD 里被引用次数最多的一张表。粒度要「一个功能点能被一个人负责」。
| 编号 | 模块 | 功能点 | 优先级 | 依赖 |
|---|---|---|---|---|
| F-01 | 买家端 | 退款申请提交（表单 + 原因选择） | P0 | — |
| F-02 | 买家端 | 退款进度查询与预计到账时间展示 | P0 | F-04 |
| F-03 | 规则引擎 | 基础规则校验（订单状态、时效、金额上限） | P0 | — |
| F-04 | AI 预审 | 模型意图识别与置信度打分 | P0 | 算法模型 v1 |
| F-05 | AI 预审 | 置信度阈值分流（自动通过 / 转人工 / 直接拦截） | P0 | F-04、风控阈值确认 |
| F-06 | 审核工作台 | 待审列表（含自动预审标记与排序） | P0 | F-05 |
| F-07 | 审核工作台 | AI 判断依据摘要展示 | P1 | F-04 |
| F-08 | 审核工作台 | 人工通过 / 驳回 + 理由记录 | P0 | F-06 |
| F-09 | 资金 | 退款发起与结果回调 | P0 | 支付网关 |
| F-10 | 数据 | 埋点采集与效果看板 | P1 | 数据团队 |
| F-11 | 数据 | 人工修正结果回流落库 | P1 | F-08 |
| F-12 | 买家端 | 退款原因自助修改（限未处理状态） | P2 | F-02 |
文字描述 + 引用图集中的流程图。别在 PRD 里重复画一遍图，给链接就行。
核心章节。每条需求都要能被单独验收，不能出现「优化体验」「提升效率」这种无法验证的表述。EARS 提供五种句式，覆盖全部场景类型。
| 类型 | 句式模板 | 适用 |
|---|---|---|
| Ubiquitous | 系统应始终…… | 全局约束、不变规则 |
| Event-driven | 当 [事件] 时，系统应…… | 用户操作、外部触发 |
| State-driven | 当处于 [状态] 时，系统应…… | 特定状态下的行为 |
| Unwanted | 如果 [异常]，则系统应…… | 失败、超时、异常兜底 |
| Optional | 若具备 [特性]，系统应…… | 可选功能、配置驱动 |
当买家提交退款申请时，系统应在 3 秒内完成基础规则校验（订单存在性、订单状态、退款时效、单笔金额上限），并返回校验结果。
验收：覆盖「订单不存在」「已退款」「超过 15 天时效」「金额超限」四类拒绝场景，各返回对应错误码与用户可读文案。
如果规则引擎在 3 秒内未返回结果（超时或异常），则系统应自动降级为转人工审核，并向审核队列插入一条标记为「规则校验异常」的待审单。
验收：模拟规则服务超时 5 秒，确认单据出现在人工队列且带异常标记，买家端展示「审核中」而非报错。
系统应始终对同一订单的重复提交做幂等处理：同一订单在同一时刻只允许存在 1 条处于非终态的退款单。
验收：并发提交同一订单 10 次，仅 1 条成功创建，其余返回「处理中，请勿重复提交」。
当规则校验通过时，系统应调用模型对退款单进行意图识别与风险打分，输出 0–1 的置信度分值及主要判断依据。
验收：模型调用成功率 ≥ 99%，单次调用 P95 延迟 ≤ 800ms，输出结构固定（分值 + 依据标签 + 模型版本号）。
当模型置信度 ≥ 阈值 T1 时，系统应自动通过并直接进入放款流程，不再进入人工审核队列。
验收：T1 初值待风控确认（建议 0.90）；可通过配置中心热更新，无需发版。变更需留操作人记录。
当模型置信度处于 T2 ≤ 置信度 < T1 的灰区时，系统应由人工审核裁定，并在审核工作台展示模型的判断依据供参考。
验收：灰区单据 100% 进入人工队列；审核页能看到置信度数值、命中标签、模型版本。
如果模型调用超时（> 3 秒）、返回格式非法或服务不可用，则系统应自动转人工审核，并将该单标记为「模型降级」，同时上报监控告警。
验收：三种异常各模拟 1 次，单据均进入人工队列且带降级标记；降级率指标可被看板统计（目标 ≤ 2%）。
当模型置信度 < T2 时，系统应将该单转入高风险复核队列，由风控专员优先处理，不走普通审核流。
验收：低分单据进入独立队列，普通审核员不可见（权限隔离）。
当审核员打开待审列表时，系统应按「风险等级降序 + 提交时间升序」排序，并支持按状态、金额区间、是否 AI 预审筛选。
验收：列表首屏加载 ≤ 1.5 秒；筛选条件可与分页共存，刷新后条件保持。
当审核员提交通过或驳回时，系统应记录 操作人、操作时间、结论、理由（驳回必填），并写入不可篡改的审批流水。
验收：驳回未填理由时无法提交；审批流水支持按单号导出，且任何角色不可删改。
如果两名审核员同时对同一单据提交结论，则系统应只接受先到达的一次，后提交方收到「该单已被处理」提示并刷新为最新状态。
验收：并发提交测试，无二次放款，无状态错乱。
如果退款请求在支付网关侧失败，则系统应将单据状态置为「放款失败」并自动转入人工队列，同一订单最多自动重试 3 次，间隔 5 / 30 / 120 分钟。
验收：3 次重试均失败后停止自动重试并告警；人工介入后可手动再次发起。
当退款进入终态（成功 / 驳回 / 失败）时，系统应在 1 分钟内向买家推送结果通知，并同步更新买家端进度页。
验收：三类终态各验证一次；通知失败时应有补偿重推机制。
若订单开启了「极速退款」标记，系统应跳过人工审核环节直接进入放款流程（前提为规则校验通过且不存在历史恶意退款记录）。
验收：标记订单自动放款；存在恶意记录的订单即使有标记也转人工。
| 状态 | 含义 | 是否终态 |
|---|---|---|
DRAFT | 买家填写中，未提交 | 否 |
SUBMITTED | 已提交，等待校验 | 否 |
AI_PENDING | 模型预审中 | 否 |
MANUAL_PENDING | 人工审核中 | 否 |
PAYING | 放款处理中 | 否 |
REFUNDED | 退款成功 | 是 |
REJECTED | 审核驳回 | 是 |
PAY_FAILED | 放款失败 | 否（可转人工） |
CANCELLED | 买家主动撤销 | 是 |
| 当前状态 | 允许流转到 | 触发条件 |
|---|---|---|
| SUBMITTED | AI_PENDING / REJECTED / CANCELLED | 校验通过 / 校验拒绝 / 买家撤销 |
| AI_PENDING | PAYING / MANUAL_PENDING | 置信度达标 / 置信度灰区或降级 |
| MANUAL_PENDING | PAYING / REJECTED | 审核通过 / 审核驳回 |
| PAYING | REFUNDED / PAY_FAILED | 网关成功 / 网关失败 |
| PAY_FAILED | MANUAL_PENDING | 自动重试耗尽后转人工 |
| 注意：REFUNDED / REJECTED / CANCELLED 为终态，不可逆向流转。若需修正，走独立的「退款冲正」流程（本期不做）。 | ||
| 场景 | 规则 |
|---|---|
| 金额边界 | 单笔 ≤ ¥5,000 可由 AI 自动放款；> ¥5,000 一律转人工（不受置信度影响） |
| 时效边界 | 超过订单完成 15 天的申请直接拒绝；大促特殊规则单独配置 |
| 并发 | 同一订单幂等；同一审核员并发提交以先到为准 |
| 超时 | 人工审核超过 24 小时未处理，自动升级至主管队列 |
| 撤销 | 仅 SUBMITTED / AI_PENDING 允许买家撤销 |
| 模型版本切换 | 切换期间的存量单据沿用旧版本判断结果，不重算 |
后台类产品的必写章节。C 端需求可以合并进第 9 章。
| 操作 | 买家 | 客服 | 审核员 | 风控专员 | 财务 |
|---|---|---|---|---|---|
| 提交退款 | ✅ 本人订单 | ✅ 代客发起 | — | — | — |
| 查看退款单 | ✅ 本人 | ✅ 全部 | ✅ 全部 | ✅ 全部 | ✅ 全部 |
| 审核通过 / 驳回 | — | — | ✅ | ✅ 高风险单 | — |
| 修改置信度阈值 | — | — | — | ✅ 需审批 | — |
| 导出审批流水 | — | — | — | ✅ | ✅ |
| 撤销申请 | ✅ 限非终态 | ✅ 代客撤销 | — | — | — |
| 指标 | 计算口径 | 统计周期 |
|---|---|---|
| 退款处理时长 | 终态时间 − SUBMITTED 时间，不含买家撤销单 | 自然日 / 滚动 7 日 |
| 自动闭环率 | AI 自动放款成功单量 ÷ 校验通过总单量 | 自然日 |
| 模型准确率 | 人工复核样本中，模型结论与人工结论一致的比例（抽样 ≥ 200 单/周） | 周 |
| 误通过率 | 自动放款后经投诉 / 风控确认为「不应退」的单量 ÷ 自动放款总量 | 周 |
| 降级率 | 因模型异常转人工的单量 ÷ 模型调用总单量 | 自然日 |
| 事件名 | 触发时机 | 关键字段 |
|---|---|---|
refund_apply_submit | 买家提交退款申请 | order_id, reason_code, amount, channel |
refund_rule_result | 规则校验返回 | order_id, pass(0/1), reject_code, cost_ms |
refund_ai_score | 模型打分完成 | order_id, score, tags, model_version, latency_ms |
refund_route | 分流决策完成 | order_id, route(auto/manual/block), threshold_t1/t2 |
refund_manual_result | 人工审核提交 | order_id, operator_id, result, reason |
refund_pay_result | 放款结果回调 | order_id, success(0/1), fail_code, retry_count |
refund_final | 进入终态 | order_id, final_status, total_cost_ms |
设计同学直接吃这一章。重点是状态覆盖，不是画得多漂亮。
| 页面 | 核心交互 | 必须覆盖的状态 |
|---|---|---|
| 退款申请页 | 选择原因 → 填写金额 → 提交 | 默认 / 校验失败 / 提交中 / 提交成功 |
| 退款进度页 | 查看当前状态与预计到账时间 | 各状态文案 / 加载 / 接口失败重试 |
| 审核工作台列表 | 筛选 → 排序 → 进入详情 | 空列表 / 加载 / 筛选无结果 / 分页边界 |
| 审核详情页 | 查看依据 → 通过 / 驳回（填理由） | AI 依据缺失 / 已被他人处理 / 提交中 |
| 场景 | 文案要求 |
|---|---|
| 预计到账时间 | 给区间不给具体点，如「预计 2 小时内到账」；避免「尽快」这类不可验证表述 |
| 驳回原因 | 对买家展示的是「可理解的业务原因」，不是内部审核术语 |
| 异常提示 | 必须包含「发生了什么 + 你可以做什么」，不能只报错误码 |
涉及资金、用户隐私、高并发的需求必须写；内部小工具可以省略。
| 类别 | 要求 |
|---|---|
| 性能 | 规则校验 P95 ≤ 3s；模型打分 P95 ≤ 800ms；工作台列表首屏 ≤ 1.5s |
| 可用性 | 核心链路可用性 ≥ 99.9%；模型服务不可用时必须降级而非阻断 |
| 安全 | 审批流水不可篡改；金额与结论字段加密存储；操作全量留痕 |
| 合规 | 退款金额、买家信息按最小必要原则使用；模型训练数据需脱敏 |
| 数据保留 | 审批流水保留 3 年（财务对账与审计要求） |
| 依赖项 | 提供方 | 影响 | 状态 |
|---|---|---|---|
| 模型 v1（意图分类） | 算法团队 | 阻塞 F-04 / F-05 | 待确认排期 |
| 置信度阈值确认 | 风控 + 财务 | 阻塞 F-05 联调 | 待评审 |
| 支付网关退款接口 | 支付团队 | 阻塞 F-09 | 已有接口，需确认频率限制 |
| 效果看板 | 数据团队 | 影响 F-10 | 待排期 |
| 风险 | 概率 | 影响 | 应对 |
|---|---|---|---|
| 模型准确率未达 92% | 中 | 自动闭环率无法达标 | 阈值保守起步（T1 设 0.95），灰度中逐步下调 |
| 误通过导致资金损失 | 低 | 财务损失 + 合规风险 | 设金额上限自动转人工；保留人工抽检机制 |
| 大促峰值压垮模型服务 | 中 | 降级率飙升 | 限流 + 排队 + 降级预案；提前压测 |
| 审核员抵触（担心被替代） | 中 | 推行受阻 | 定位为「减负工具」；保留完整审核权；做内部宣导 |
这一章是给测试同学的输入，也是上线准入的判断依据。写完 PRD 直接能用它生成用例。
| 编号 | 验收项 | 通过标准 |
|---|---|---|
| AC-01 | 常规退款自动闭环 | 构造 100 单常规退款，自动放款成功率 ≥ 70% |
| AC-02 | 灰区单据转人工 | 置信度落在 [T2, T1) 的单据 100% 进入人工队列 |
| AC-03 | 模型异常降级 | 模拟超时 / 非法返回 / 服务不可用，均转人工且无资金动作 |
| AC-04 | 幂等与并发 | 同订单并发提交 10 次仅 1 条成功；同单据并发审核仅 1 条生效 |
| AC-05 | 金额上限 | 超 ¥5,000 的申请不进入自动放款，强制转人工 |
| AC-06 | 放款失败重试 | 失败后按 5/30/120 分钟重试 3 次，耗尽后告警并转人工 |
| AC-07 | 状态不可逆 | 终态单据无法被任何操作改回非终态 |
| AC-08 | 审批留痕 | 每次操作可查操作人 / 时间 / 结论 / 理由，且不可删除 |
| AC-09 | 埋点完整 | 7 个埋点事件全部上报，字段无缺失 |
| AC-10 | 权限隔离 | 普通审核员不可见高风险队列；非授权角色无法修改阈值 |
| 阶段 | 范围 | 观察指标 | 退出条件 |
|---|---|---|---|
| 灰度 1（约 1 周） | 单类目 + 自动放款【关闭】，仅跑模型影子打分 | 模型准确率 vs 人工结论 | 准确率 ≥ 92% 方可进入下一阶段 |
| 灰度 2（约 2 周） | 单类目 + 自动放款开启，金额 ≤ ¥1,000 | 误通过率、降级率、投诉率 | 误通过率 ≤ 0.5% |
| 全量 | 全类目，金额上限提升至 ¥5,000 | 全量指标 + 客服咨询量 | — |
把没想清的事写下来，比在会上被问倒体面得多。这张表也是你申请延期 / 要资源的依据。
| 编号 | 待确认问题 | 影响范围 | 找谁确认 | 截止 |
|---|---|---|---|---|
| Q-01 | 置信度阈值 T1 / T2 取值 | F-05 全部逻辑 | 风控 + 财务 | 评审当日 |
| Q-02 | 单笔自动放款金额上限是否 ¥5,000 | F-05 分流规则 | 财务 | 评审当日 |
| Q-03 | 模型不可用时的降级是否影响 SLA 赔付 | 非功能需求 | 运营 + 法务 | 本周内 |
| Q-04 | 大促期间是否启用特殊时效规则 | 规则引擎配置 | 运营 | 下周一 |
| Q-05 | 模型训练数据脱敏方案是否合规 | 数据回流链路 | 法务 + 安全 | 开发前 |
| Q-06 | 是否需要向买家公示 AI 参与决策 | 买家端文案 | 法务 | 开发前 |