docs: 召回分配产品设计文档(面向产品/业务)

基于 docs/design/plan-assignment-doctrine.md 重写成产品视角,放进 docs app
新建的「设计 › 产品设计」分组。

与原教条文档的关系:那份是工程内部的决策留痕(含表名、字段、弯路记录、
踩坑复盘),给开发看;这份只讲**为什么这么设计**和**流程长什么样**,
去掉全部实现细节与代码路径 —— 讲给产品和业务听。

结构按设计思路重排(不按 T 编号顺序):
  问题 → 全流程 → 这是什么 → 谁做什么 → 怎么选人 → 怎么落到人头上
  → 确认单 → 闭环

5 张图代替长段落:
  ① 五步生产线(带反哺回环)  ② 三方职责与唯一写动作
  ③ 初选两轴矩阵            ④ 落人三趟(专属封顶 → 无主补空 → 有主改派)
  ⑤ 一条单子的状态机(含退回/到期/撤销三条回池路径)

保留了对业务最有说服力的两处真实数据:70% 挂在同一客服名下、
封顶前后 248/34/31/14/14 → 每人 20。

实测:docs 已渲染,5 张图全部成 SVG(4 flowchart + 1 stateDiagram),
无残留代码块;导航挂在「设计 › 产品设计 › 召回分配」。
⚠️ 新增 content 目录会让 Fumadocs 索引发僵(整树打不开),
   清 .next/.source 重建才恢复 —— 老坑,已按记录处理。

apps/pac-docs/content/docs/design/batch-assignment.mdx

+---
+title: 召回分配
+description: 把「要不要做」变成「做了没有」—— 批次分配的设计原则、流程与闭环。
+icon: Users
+---
+
+## 问题
+
+召回池成千上万条，**头部反复被看、长尾无人碰**，池子形同虚设。
+
+根因不是客服不努力，是纯自助认领的三个结构性缺口：
+
+| 缺口 | 表现 |
+|---|---|
+| 责任真空 | 认领零成本，领了不做没有后果 |
+| 无目的 | 各捞各的，运营意图落不了地 |
+| 无法归因 | 做了什么、效果如何，事后说不清 |
+
+**分配要做的，是把「要不要做」变成「做了没有」。**
+
+---
+
+## 全流程
+
+```mermaid
+flowchart LR
+  A["① 初选<br/>主管点一格<br/>治疗项 × 时机"] --> B["② 精选<br/>助手挑人、排客服"]
+  B --> C["③ 确认单<br/>主管过目"]
+  C --> D["④ 分配<br/>确认落库"]
+  D --> E["⑤ 跟踪<br/>看效果、调下一批"]
+  E -.反哺.-> A
+
+  style A fill:#e0e7ff,stroke:#6366f1
+  style C fill:#fef3c7,stroke:#f59e0b
+  style D fill:#d1fae5,stroke:#10b981
+```
+
+**主管只在两处动手**：点一格（①）、点确认（④）。中间全是助手的活。
+
+---
+
+## 一、这是什么
+
+### 分配是批次运营，不是工单派发
+
+目标是「选一批人、配一套打法、看效果」，**从不追求把池子分完**。
+所以"主管扛不住全量"不是缺陷 —— 设计上就不打算分全量。
+
+### 宁缺毋滥
+
+一批宁可只做 100 人做透，不做 1000 人做浅。
+**池子里剩下的不是遗漏，是还没轮到。**
+
+### 每一步都在收缩人群
+
+从"万"级压到"十"级。**主管只做判断，不做筛选** —— 筛选是助手的活。
+
+---
+
+## 二、谁做什么
+
+```mermaid
+flowchart TB
+  L["👤 主管<br/>判断 · 取舍 · 拍板"]
+  A["🤖 助手<br/>筛选 · 计算 · 呈现"]
+  S["📞 客服<br/>执行"]
+
+  L -->|"点一格 / 提要求"| A
+  A -->|"确认单"| L
+  L ==>|"确认（唯一的写动作）"| S
+  S -.->|"结果 / 退回原因"| L
+
+  style L fill:#e0e7ff,stroke:#6366f1
+  style A fill:#f3e8ff,stroke:#a855f7
+  style S fill:#d1fae5,stroke:#10b981
+```
+
+| | 做什么 | **不做什么** |
+|---|---|---|
+| 主管 | 判断、取舍、拍板 | 不翻明细、不做算术 |
+| 助手 | 筛选、计算、呈现 | **不替主管决定、不自动执行** |
+| 客服 | 执行 | 不做选择 |
+
+**任何改变数据的动作，只能由主管的「确认」触发。**
+
+### 客服看不到池子
+
+客服左侧只有「我的」，**无从认领**；主管才有「召回池」。
+主管本质也是客服，也要执行 —— 所以分配入口就在召回池里，不新开页面、不把他劈成两个身份。
+
+---
+
+## 三、怎么选人
+
+初选是一张矩阵，两个轴：
+
+```mermaid
+flowchart LR
+  subgraph X["X 轴 · 潜在治疗（8 类机会）"]
+    direction TB
+    X1["种植 / 正畸 / 早矫<br/>根管 / 牙周 / 充填<br/>修复 / 拔牙"]
+  end
+  subgraph Y["Y 轴 · 时机（3 档）"]
+    direction TB
+    Y1["🔥 黄金期<br/>🌡 窗口内<br/>❄️ 窗口外"]
+  end
+  X --> M["矩阵格子<br/>= 一批候选人"]
+  Y --> M
+
+  style M fill:#fef3c7,stroke:#f59e0b
+```
+
+**X 轴是「有需求但没做的机会」**，不是内部技术分类。按业务视角拆：正畸按年龄分成正畸与早矫，残根合成拔牙。
+
+**Y 轴是该治疗项目自己的临床周期**，不是客户价值、不是意愿、不是多久没来。
+每个项目用自己的尺度，归一化后横向可比 —— 种植的"过期"和补牙的"过期"不是一个天数。
+
+### 不用没有数据支撑的因素
+
+客服的**态度、能力**没有数据，不进决策。
+分配只依据**客观事实**（专属客服、在岗、在手量）和**主管的显式指定**。
+
+> 不给客服建能力评分 —— 分数一旦可见就成了绩效工具，会诱导行为扭曲。
+
+### 画像圈人放在"调整"阶段
+
+助手第一次出方案时**不做画像分层**，保持简洁。
+主管追问「只要商保直付的」「排掉怕疼的」时，才当场用画像收窄 —— 那时候它正是主管要的精确回应。
+
+---
+
+## 四、怎么落到人头上
+
+只有**两个基数**，都沿用主管上一次用的值：
+
+| 基数 | 含义 | 首次 | 之后 |
+|---|---|---|---|
+| **本批人数** | 这一轮推多少人 | 在岗人数 × 20 | 沿用上次 |
+| **时效** | 多久没动自动回池 | 3 天 | 沿用上次 |
+
+> 没有第三个数。曾经有过"每人容量"，删掉了 —— 一个数当两个用，第二批必然分不出来。
+
+落人分**三趟**，目标是**又满又平**：名额全部落地，且分完大家在手量齐平。
+
+```mermaid
+flowchart TB
+  S(["N 个名额"]) --> T1
+
+  T1["① 专属优先<br/>有专属客服的 → 回到他手上"]
+  T1 -->|"但封顶在目标水位"| T2
+  T2["② 无主补空<br/>没有专属的 → 给当前最空的人"]
+  T2 -->|"还没填平？"| T3
+  T3["③ 有主改派<br/>超出水位的专属患者 → 改派给最空的人"]
+  T3 --> E(["每人在手量齐平"])
+
+  style T1 fill:#e0e7ff,stroke:#6366f1
+  style T2 fill:#dbeafe,stroke:#3b82f6
+  style T3 fill:#fef3c7,stroke:#f59e0b
+  style E fill:#d1fae5,stroke:#10b981
+```
+
+**顺序不能颠倒**：②③ 总量一样，但被拆散的老客户关系数不一样。先用"没有关系要顾"的人填坑，代价最小。
+
+**为什么第一趟要封顶**（真实数据）：某个格子 1,081 人里 **70% 挂在同一个客服名下**，而 17 位在岗客服中有 **10 位名下一个患者都没有**。
+不封顶，一批 340 人分下去是 **248 / 34 / 31 / 14 / 14**；封顶后是**每人 20，完全齐平**。
+
+> 改派**不是"抢客户"** —— 语义是「关系还在，只是这轮没轮到」。
+
+---
+
+## 五、确认单
+
+助手把结果一次性摆出来，**直出，不追问**。最好的情况是主管看一眼就点确认。
+
+**三层展开**：汇总 → 按客服 → 患者明细（折叠，展开才看）。
+患者明细必须给**姓名和病历号** —— 给一串编号等于让主管对着乱码猜。
+
+主管在卡片上能做四件**局部**修正，判据是「要不要重跑算法」：
+
+| 卡片上直接做 | 回对话让助手做 |
+|---|---|
+| 改批次时效 · 改单条时效 | 换人群（换治疗项 / 时机 / 画像条件） |
+| 删掉某一条 | 改本批人数 |
+| 把某一条拖给别的客服 | 给某个客服设本批名额 |
+| 移除某个客服 | 设本批福利 |
+
+时效的文案是「**N 天后自动退回**」而不是光一个"时效" —— 主管要知道到期会发生什么，否则这个数对他没有意义。
+
+### 福利挂在批次上，不挂在个人上
+
+同一批共享同一个福利，才能归因（这批的效果 = 这个福利的效果）。
+
+福利作为**事实**交给助手，由它自然融进话术。硬约束：**只能说福利原文包含的内容**，不得追加条件、期限、名额，不得夸大。
+
+### 助手不出没有证据的结果
+
+- 缺的数据（如医生档期）→ **不用，也不猜**
+- 首次无历史 → 用默认值，**并标明这是默认值**
+- 有数据之后 → 反推真实习惯，替换默认值
+
+> 时效"3 天"现在只能写「默认值，暂无历史数据」，**不能**写成「依据平均结案 2.4 天」—— 那个数还算不出来。
+
+---
+
+## 六、闭环
+
+一条单子的完整生命：
+
+```mermaid
+stateDiagram-v2
+  [*] --> 池子里
+  池子里 --> 在客服手上: 主管分配
+  在客服手上 --> 已处理: 联系到 / 约上了
+  在客服手上 --> 池子里: 客服退回（必须写原因）
+  在客服手上 --> 池子里: 到期自动退回
+  在客服手上 --> 池子里: 主管撤销整批
+  已处理 --> [*]
+
+  note right of 池子里
+    退回 / 到期的人会回到池子
+    只是排序上排到后面
+  end note
+```
+
+### 退回必须写原因
+
+退回是**正常路径**不是异常。原因分布是主管调整下一批的输入 ——
+「派多了」「时效太紧」「压根不该派给他」，这三种的下一步动作完全不同。
+
+### 撤销 ≠ 退回
+
+| | 谁做 | 做什么 | 粒度 |
+|---|---|---|---|
+| **撤销** | 主管 | 收回整批（分错人 / 条件填错） | 批次 |
+| **退回** | 客服 | 退回单条（不是我的客户 / 没时间） | 单条 |
+
+撤销**几乎总是部分成功** —— 客服已经打开过的单不会被收回（他可能已经联系了患者）。
+所以结果如实报三个数，不能只说一句"已撤销"。
+
+### 跟踪是为了自优化
+
+**不做「分配 vs 自认领」的对照** —— 认领已经隐藏，没有对照组；
+而且那种框法把分配当成"待验证的假设"，与定位不符。分配是**既定的运营方式**，问题不是"要不要用"，而是**"怎么越用越准"**。
+
+主管能看到的：
+
+| 指标 | 口径提醒 |
+|---|---|
+| 分了多少人 / 在手 / 已处理 | 「已处理」= 这单动过了，**不等于谈成了** |
+| 客服主动退回 · 原因分布 | 「不该我做」，是**分配**问题 |
+| 到期没人动 | **没处置**，是派多了 / 时效太紧 / 人不在岗 |
+| 通话结果：成功 / 不成功及原因 | 打了之后的结果，是**召回效果**问题 |
+| 一次结果都没有 | 最该先看的数 —— 不是效果差，是**根本没做** |
+
+> **退回率永远给两个数**：「退回 5 / 已处置 40 = 12.5%（另有 60 条没人动）」。
+> 没人动的数量本身就是信号，只报一个百分比会让人把前者误读成后者。
+
+> **样本不足就直说**。上线初期成功记录会长期是 0 或个位数，
+> 这时候必须写「已处置 12 人，暂无转化记录，样本量不足」，⛔ 不能渲染成「0.0% 转化率」。
+
+---
+
+## 一句话总结
+
+> 主管点一格、看一眼、点确认；剩下的事系统做完，并且**回头说得清**。

apps/pac-docs/content/docs/design/meta.json

+{
+  "title": "产品设计",
+  "icon": "Lightbulb",
+  "pages": ["batch-assignment"]
+}

apps/pac-docs/content/docs/meta.json

@@ -5,6 +5,7 @@
     "---了解 PAC---",
     "start",
     "---设计---",
+    "design",
     "architecture",
     "algorithms",
     "design-system",