# 疗效保障项目方案与 Milestone v2

> **版本:** v2.0(基于 v1.2 [design.md](design.md) 优化)
> **面向对象:** 集团管理层、业务负责人、5i5ya / Friday SaaS 相关负责人、技术负责人
> **文档目的:** 明确"疗效保障"项目的项目范围、一期业务闭环、系统边界、实施路径,以及项目对 PAC 框架的依赖关系。
> **核心结论:** **疗效保障是一个正式业务项目,PAC 是该项目采用的集团级患者分析框架。** 疗效保障项目一期聚焦"治疗链已完成患者的疗效保障召回服务",通过 PAC 完成患者事实汇聚、实时分析、Persona 画像、Follow-up Plan 生成、证据链管理与执行反馈闭环。
>
> **v2 主要变化**(原版 [design.md](design.md) 不变):
> - 进度对齐 [W1 报告](w1-report.md):W1 框架已 closure,当前在 W2 阶段
> - API Pool 1 事实层细化为**双表模型**(`patient_transactions` 账本 + `patient_facts` 版本流)
> - Persona 起步特征明确为 4 个(value / treatment_chain_status / recall_risk / do_not_contact_status)
> - 一期 scenario 在 [scenarios/post_treatment_recall.md](scenarios/post_treatment_recall.md) 细化为**一个 scenario 内 4 个子分支**(根管未戴冠 / 正畸中断 / 种植年度复查 / 牙周维护期)
>
> **⚠️ 代码漂移修订(2026-06-16,以代码为准):** 一期实际主战场已演进为 `treatment_initiation_recall`(启治召回,canonical code K00–K09 子场景,union-find 牙位合并)+ `treatment_aftercare_recall`(疗效保障),非本文写的 `post_treatment_recall` 4 子分支;Persona 实际落地 **16 个 feature**(非起步 4 个);LLM 走 **AiCall 框架多 provider**(deepseek/gemini/qwen),无 Dify;隔离字段为 **`hostId`**。
> - 接入路径标准化为 Pull + Push 双通道,详见 [host-integration.md](host-integration.md)
> - 验收口径第 10 条补充"双表模型 + 版本流" 落地具体表名

---

## 1. 项目定义

本项目当前名称为:**疗效保障项目**。

疗效保障项目不是单独新增一个回访页面,也不是在 5i5ya 或 Friday SaaS 中重复开发一套回访任务功能。

疗效保障项目的核心是:

```text
基于患者真实业务事实,持续分析患者状态,生成可执行的疗效保障计划,
并将计划、依据、摘要和话术输出给业务宿主系统执行。
```

项目采用 PAC 框架作为底层分析能力。

```text
疗效保障项目 = 业务项目
PAC = 支撑疗效保障项目的集团级患者分析框架
```

两者关系如下:

| 对象 | 定位 |
|---|---|
| 疗效保障项目 | 面向业务落地的正式项目,当前一期聚焦治疗链已完成患者召回服务 |
| PAC 框架 | 面向患者事实、画像、计划、证据链和 AI 分析的底层框架 |
| 5i5ya / Friday SaaS | 业务宿主系统,负责业务动作承接、执行记录落地、预约 / 回访等业务闭环 |
| DW / BI / CDP / SCRM | 患者事实数据来源或辅助数据源 |
| 企微 / 外呼系统 | 触达通道,不是 PAC 的替代对象 |
| **DeepSeek V4 Pro**(W2 替代 AI Gateway / Dify) | AI 调用链路 — PAC 通过自建 AiCall 框架直连 DeepSeek(国内合规) |

PAC 不直接替代 5i5ya、Friday、企微、外呼系统或 SCRM。PAC 负责分析、计划与证据链;宿主系统负责业务动作执行和业务数据落地;AiCall 框架 + DeepSeek 承担 LLM 调用本职。

---

## 2. 项目背景

> 跟 v1 一致,详见 [design.md §2](design.md#2-项目背景)。

### 2.1 5i5ya 已存在回访功能

瑞尔集团现有 5i5ya 系统已经具备回访相关能力(回访任务、跟进记录、接待任务、400 回访记录、SCRM 跟进、销售机会)。疗效保障项目**不替代** 5i5ya 现有回访模块,而是补齐"统一患者事实视角 / 实时分析 / Persona 画像 / Plan 生成 / 证据链 / AI 辅助"6 项能力。

### 2.2 Friday 已完成智能召回 POC

Friday SaaS 侧已经完成智能召回能力探索(通善口腔 POC)。后续将该能力抽象为 PAC 框架,由 Friday / 5i5ya 及其他宿主通过接口接入。

### 2.3 试点门诊范围

| 试点门诊 | 城市 |
|---|---|
| 杭州大厦 | 杭州 |
| 杭州高德 | 杭州 |
| 无锡学前街 | 无锡 |
| 上海世纪公园 | 上海 |
| 北京朝阳公园 | 北京 |

### 2.4 疗效保障需要支持的业务视角

| 视角 | 需要支持的内容 |
|---|---|
| 回访谁 | 去重、价值排序、风险判断、近期是否适合触达 |
| 为什么回访 | 患者事实、治疗链状态、Persona 特征、Plan 生成依据 |
| 何时回访 | 基于治疗链状态、复查周期、预约状态、近期触达情况生成建议 |
| 谁回访 | 客服、前台、400、医生助理等执行角色匹配 |
| 怎么回访 | One Page Summary、参考话术、历史事实、待关注事项 |
| 回访后看什么 | 进度、效果、转化、执行质量、计划状态变化 |
| 如何解释 | 患者事实、Persona 版本、Plan 版本、证据引用 |

---

## 3. 项目一期业务范围

### 3.1 一期业务场景

> **治疗链已完成患者的疗效保障召回服务。**

宿主系统通过 **PAC 开放 API** 查询和使用 PAC 输出,获得:
- 哪些患者进入该服务范围
- 为什么需要召回(inclusionReason)
- 建议什么时候触达 / 由谁触达
- One Page Summary + 参考话术
- 执行后如何回写

详见 [scenarios/post_treatment_recall.md](scenarios/post_treatment_recall.md)。

### 3.2 一期选择该场景的原因

1. 业务边界相对清晰
2. 数据来源相对明确
3. 与预约、复查、诊后体验、老客户关系维护均有关联
4. 可验证 PAC 的事实接入、实时分析、画像、计划、话术与执行反馈链路
5. 可在 W4-W6 形成第一个业务可用闭环

### 3.3 一期 4 个高价值子场景(v2 细化)

**post_treatment_recall** 内部覆盖 4 个高价值子场景:

| 子场景 | 业务定义 | 时间窗 | 业务价值 |
|---|---|---|---|
| **#1 根管未戴冠** | 根管完成但没及时加冠保护 | 30 天-18 个月 | 立刻转化 ¥3,000+;防后续高价拔牙→种植 |
| **#2 正畸中断 / 保持器期** | 正畸完成 2 年内,长期未回诊 | 6-24 个月 | 防 4-5 万投入打水漂;防反弹投诉 |
| **#3 种植年度复查** | 种植完成超过 11 个月,没有年度复查 | 330-540 天 | 防种植失败(¥1-2 万维修代价);锁定 VIP 终身维护 |
| **#4 牙周维护期** | 牙周治疗后超过 5 个月,未做维护 | 150-360 天 | 长尾高频复购(年 2-3 次);防复发 |

**4 个分支同属一个 scenario**(`scenario='post_treatment_recall'`),DB 层 partial UNIQUE 保证单 patient 同时只一个 active plan(取 priorityScore 最高的命中)。

### 3.4 一期业务输出

| 输出能力 | 说明 | 对应表 / 字段 |
|---|---|---|
| 患者召回列表 | 满足条件的患者清单 | `followup_plans` WHERE status='active' |
| 召回优先级 | 基于价值/时间/风险加权 | `followup_plans.priorityScore` |
| 召回原因 | 自然语言解释 | `followup_plans.inclusionReason`(v0 模板) |
| One Page Summary | 一线使用的患者简要信息 | `plan_summaries` type=one_page |
| 参考话术 | 完整对话脚本(Markdown 分节) | `plan_scripts.content` |
| 参考证据 | 关联 fact / persona / 规则 / agent | `followup_plans.evidence` JSONB |
| Follow-up Plan | 建议触达时间 / 角色 / 渠道 | `followup_plans.recommendedAt/Role/Channel` |
| 执行结果回写 | 宿主反馈执行情况 | `plan_executions` 表 |

---

## 4. 项目一期系统范围

疗效保障项目一期系统范围包括三类能力。这些属于 PAC 框架的组成部分,在一期项目中按 "治疗链已完成患者疗效保障召回服务" 业务闭环落地。

### 4.1 API Pool 1:事实输入池(v2 双表模型)

API Pool 1 是宿主系统 / 数据源系统给 PAC 的患者事实输入池。

#### v2 双表模型细化

```
宿主原生事件 / 资源对象
        ↓
patient_transactions(操作账本,append-only)
   - 字段:event_seq BigInt / source_event_id(幂等键)/ raw_payload / action / subject_type / clinic_id ...
   - 14 种 action × 10 种 subject_type 起步(详见 host-integration.md §4.4)
        ↓ parser 解析 + 衍生
patient_facts(事实单元版本流)
   - 字段:subject_id / version / kind(actual/planned)/ type(16 种)/ status / content JSONB
   - parser 衍生:1 条 transaction → 0/1/N 个 fact 版本变化
```

详见 [three-layer-model.md](three-layer-model.md)。

#### 一期 API Pool 1 输入范围(v2 详化)

按 11 种 `subject_type` 维度组织:

| 资源 | 一期必填 | 业务价值 |
|---|---|---|
| `patients`(主档) | 🔴 必填 | 身份对象 |
| `appointments`(预约) | 🔴 必填 | 召回核心信号("已预约" 不召回) |
| `clinical_encounters`(医生接诊) | 🔴 必填 | 治疗链核心(parser 衍生 treatment_record / diagnosis_record) |
| `charge_orders`(收费单) | 🔴 必填 | 价值评估 + 治疗链推断 |
| `payments`(收款) | 🔴 必填 | 同上 |
| `refunds`(退费) | 🟡 推荐 | 投诉风险信号 |
| `consultations`(400 咨询) | 🟡 推荐 | 早期意向信号 |
| `visit_registrations`(挂号) | 🟡 推荐 | 到诊行为细粒度 |
| `visit_receptions`(接诊登记) | 🟢 可选 | 流程细节 |
| `emr_documents`(电子病历) | 🟡 推荐 | 治疗链状态推断 |
| `image_studies`(影像) | 🟢 可选 | 影像 AI 接入(W5+ 评估) |

#### 接入路径(v2 — Pull 主流,Push 增强)

**一期主路径**:**Pull**(PAC 主动拉)+ **Mock 数据集 W2 启动**(脱敏样本 + 兜底典型病例)。

- **W2-W4**:Mock-first(PAC 团队造 / 业务方提供脱敏样本驱动开发,不阻塞)
- **W5+**:第一个真实 host(DW 团队配合或先用 mock 升级)
- **Push 接入**:可选增强,宿主有事件总线时启用,详见 [host-integration.md §4](host-integration.md#4-push-路径宿主主动推事件)

### 4.2 API Pool 2:能力查询池(v2 改名为"PAC 开放 REST API")

PAC 提供一组**开放 REST API**(供 PAC 自有前端 + 宿主自有前端 / 后端 调用):

| 模块 | 关键 endpoint | 用途 |
|---|---|---|
| Plan 列表 / 详情 | `GET /plans` / `GET /plans/{id}` | 召回名单展示 |
| Plan 操作 | `POST /plans/{id}/assign` / `recycle` | 分配 / 回收 |
| Plan 执行回写 | `POST /plans/{id}/executions` | ⭐ 接口 2 |
| Plan 资产重生 | `POST /plans/{id}/assets:regenerate` | 客服不满意话术时手动重生 |
| Patient | `GET /patients/{id}/timeline` | 患者时间轴(active facts) |
| Persona | `GET /patients/{id}/persona` | 当前画像 + features |
| Sync | `POST /sync/patient/{id}/refresh` | 单患者即时刷新 |

完整契约见 [host-integration.md §5](host-integration.md#5-pac-开放-rest-api)。

### 4.3 Agent Pool:AI 分析工具池(W2 末调整 — AiCall 框架 + DeepSeek 直连)

Agent Pool 是 PAC 内部调用的 AI 分析工具池。**所有 agent 调用走 PAC 自建 AiCall 框架**:
- AiCall 框架(packages/ai-core)负责 prompt 装配 / output schema(zod)/ token 计量 / cost 计算 / prompt cache / 失败重试
- v1 LLM provider = **DeepSeek V4 Pro 直连**(国内合规);未来可切 Qwen / GPT 等,provider 切换不动调用方
- 每次调用强制落 `agent_invocations` 表(audit / replay / 成本核算)
- 失败 / 限流 / 超时由 BullMQ 异步重试 + 模板兜底

> **跟原 v2 设计的差异**:原计划走 AI Gateway → Dify(两层基础设施),W2 末决策改为 AiCall 框架直连 LLM provider — 省运维成本 + 国内合规 + token 计量更准。Dify 风格的 workflow 编排能力 PAC 暂不需要(召回算法走 scenario 应用层常量)。

#### 一期 Agent 清单

| Agent kind | 一期作用 | 落库位置 |
|---|---|---|
| `script` | 生成 PlanScript(每个 plan 一份完整话术 Markdown 含多子段) | `plan_scripts` |
| `summary` | 生成 PlanSummary(每个 plan × 3 type:one_page / medical_record / treatment_chain) | `plan_summaries` |
| `persona_feature` | (W5+)生成 PersonaFeature 描述(复杂特征用 agent) | `persona_features` |
| `ranking` | (将来)排序辅助 | — |
| `plan_analysis` | (将来)Plan 解释 | — |

Agent 输出 PAC 分析编排层统一管理,**不直接作为宿主系统业务动作**。

### 4.4 一期不纳入范围

- 不重构 5i5ya 既有回访任务体系
- 不重构 Friday SaaS 的业务流程
- 不直接替代企微、外呼、SCRM
- 不一次性覆盖所有回访场景
- 不一次性建设完整 CDP
- 不把所有患者运营逻辑一次性 Agent 化
- 不要求 API Pool 1 一次性接入所有业务系统实时 Push
- **不实现**漏诊召回(选项 B-2 需要影像 AI,留 W5+ 接朝厚后)
- **不实现** PAC outbound webhook(host 轮询 PAC API 替代,详见 [host-integration.md §9](host-integration.md#9-pac-outbound-webhook可选--嵌-iframe-时考虑))

一期目标不是缩减项目,而是限定第一阶段业务闭环范围。

---

## 5. PAC 框架核心约束

> 跟 v1 完全一致 — PAC 5 项底层约束。详见 [design.md §5](design.md#5-pac-框架核心约束)。

### 5.1 实时分析是建立 Follow-up Plan 的唯一基础

```text
Plan 不能基于静态名单、一次性导出表格、人工固定标签或历史计划惯性直接生成。
Plan 必须基于 PAC 当前掌握的最新患者事实重新分析后生成。
```

PAC 基础链路:
```
patient_transactions 入库 → parser 衍生 patient_facts 版本流 → 实时重算 Persona →
生成 / 重构 Follow-up Plan → 输出给宿主系统执行
```

### 5.2 Persona 只存储"特征 + 描述 + 证据 + 版本"

```text
Persona = 特征(key) + 特征描述(description) + 证据引用(evidence) + 版本信息(version)
```

**不**把"描述"进一步拆成固定字段(如 value_score / treatment_value / relationship_value / risk_score 等供宿主逐字段消费)。该约束避免 PAC 被宿主反向绑定成一组固定业务字段,也避免为单一场景过早固化画像模型。

(v2 补充)起步 4 个 feature_key:
- `value`(客户价值,规则路径)
- `treatment_chain_status`(治疗链状态,规则路径)
- `recall_risk`(召回风险,规则路径)
- `do_not_contact_status`(不打扰状态,规则路径)

候选扩展 9 个,详见 schema.prisma `PersonaFeature` 注释。

### 5.3 接口 1 与接口 2 必须区分

| 接口 | 定义 | 是否触发重新分析 |
|---|---|---|
| 接口 1 | 患者事实变化接口(patient_transactions 入站) | 是 |
| 接口 2 | Follow-up Plan 执行结果接口(plan_executions 回写) | 否(只驱动 Plan 状态机) |

接口 2 的执行反馈**不进 patient_facts 层**,只反馈到 Plan 状态机:
- 驱动状态转移(active → assigned → completed / abandoned)
- 累积统计(回访次数 / 接通率)
- 触发熔断(达 maxContactAttempts → Plan 自动 abandoned)

(v2 补充)严格"数据流单向"纪律 — Plan / PlanExecution / AI 输出**都不回写 fact 层**,详见 [three-layer-model.md](three-layer-model.md)。

### 5.4 Agent 是受控分析工具

- Agent 不直接写宿主数据 / 不直接创建预约 / 不直接决定业务动作
- Agent 输出必须落地保存(`agent_invocations` 表 append-only)
- Agent 输出必须带版本(`agentVersion` + `modelName`)
- Agent 输出必须关联输入(`inputSnapshot` JSONB + `linkedPatientId/personaId/planId`)
- (W2 末更新)**Agent 调用全部走 AiCall 框架**,统一审计 / 计费 / 缓存;LLM provider 当前 = DeepSeek V4 Pro 直连

### 5.5 证据链与版本化

PAC 输出的每一个 Persona 和 Follow-up Plan 都必须可解释。需要能回答:为什么进入名单 / 为什么优先级高 / 为什么建议现在触达 / 为什么建议这个话术 / 依据哪些 fact / 用了哪个 Persona / Plan 版本 / 哪些规则或 Agent。

实现:`PersonaFeature.evidence` + `FollowupPlan.evidence` JSONB,引用 `factIds` / `agentInvocationIds` / `ruleIds`,两跳可回溯到原始 transaction。

---

## 6. PAC 框架方案

> 跟 v1 大体一致,v2 主要补充三层模型具体表名 + AiCall 框架(直连 DeepSeek)调用链路。

### 6.1 PAC 定义

**PAC,全称 Patient Analyze Center,是集团级患者分析框架**。

PAC 是框架,不是单个业务功能。

PAC 为疗效保障以及后续更多患者运营场景提供统一能力:

```text
患者事实接入 → 患者事实时间轴 → 实时分析 → Persona 画像 →
Follow-up Plan → 输出给宿主系统执行
```

### 6.2 PAC 系统边界

PAC 负责:
- 接收患者事实变化(API Pool 1)
- 保存 transactions / facts 双表 + 时间轴
- 实时分析(Persona engine,event-driven + scheduled + manual 三种触发)
- 生成 Follow-up Plan(scenario 规则 + persona 增强)
- 异步生成 scripts / summaries(BullMQ + AiCall 框架 → DeepSeek)
- 接收执行结果回写(plan_executions)
- 通过 PAC 开放 REST API 提供查询

PAC 不负责:
- 不直接创建宿主预约业务数据
- 不直接替代宿主回访任务体系
- 不直接替代企微 / 外呼 / SCRM
- 不把接口 2 的执行反馈作为患者重新分析的证据
- 不以字段级强契约反向绑定宿主

### 6.3 PAC 总体架构(v2 — 加 AiCall 框架 / Pull-Push 双通道)

```mermaid
flowchart LR
    A[Friday SaaS] -->|Pull 资源 / Push 事件 / 查询使用| P[PAC 框架]
    B[5i5ya] -->|Pull / Push / 查询使用| P
    C[异步 DW / BI / CDP] -->|批量或增量数据| P

    P --> D[patient_transactions<br/>操作账本 append-only]
    D --> D2[patient_facts<br/>事实单元版本流]
    D2 --> E[Persona Engine<br/>eventWatermark 水位]
    E --> F[PlanEngine<br/>scenario 规则 + 优先级]
    F --> G[plan_scripts / plan_summaries<br/>异步 BullMQ]
    G --> AG[AiCall 框架<br/>直连 DeepSeek V4 Pro]

    P -->|开放 REST API| A
    P -->|开放 REST API| B

    A -->|执行回访 / 预约 / 记录| H[业务动作落地]
    B -->|执行回访 / 预约 / 记录| H

    H -->|接口 2:执行结果反馈<br/>POST /plans/.../executions| P
    A -->|接口 1:Pull 资源 + Push 事件| P
    B -->|接口 1:Pull 资源 + Push 事件| P
```

### 6.4 三层核心模型

#### 第一层:患者事实层(v2 双表)

`patient_transactions`(操作账本) → parser → `patient_facts`(事实单元版本流)

接收来自宿主的真实业务变化:患者档案 / 预约 / 到诊 / 诊断 / 治疗 / 收费 / 病历 / 影像 / 触达 / SCRM 跟进等。

详见 [three-layer-model.md](three-layer-model.md)。

#### 第二层:Persona 画像层

PAC 根据 patient_facts active 版本算 features。**画像维度可扩展,不写死**:
- 患者价值画像 ⭐(v1 起步)
- 治疗链状态画像 ⭐(v1 起步)
- 复查风险画像 ⭐(v1 起步)
- 不打扰状态画像 ⭐(v1 起步)
- 未完成治疗 / 沟通偏好 / 客户体验风险 / 家庭关系 / 推荐关系 / 医生关系 / 治疗意向 / 投诉风险(v1 候选,W3+ 按业务方反馈实现)
- engagement 触达活跃度(v1 不实现,留 W5+ host 触达数据接入后)

#### 第三层:Follow-up Plan 层

基于 Persona(可选)+ patient_facts 直接生成召回计划:
- 召回目标(scenario)
- 召回优先级(priorityScore 加权)
- 推荐执行时间 / 角色 / 渠道
- 参考话术(plan_scripts,异步)
- One Page Summary 等(plan_summaries,异步)
- 证据引用(evidence)
- Plan 版本(version + supersededAt)
- 执行状态(active / assigned / completed / abandoned / superseded)

### 6.5 三类 Pool 与分析编排层

```text
API Pool 1(事实输入,Pull + Push)→ patient_transactions / facts
        ↓
分析编排层 → Persona Engine / PlanEngine / Agent(via AiCall 框架)
        ↓
Persona / Plan / Scripts / Summaries → 开放 REST API(API Pool 2)
```

### 6.6 PAC 本地落地的数据资产

| 数据资产 | 对应表 |
|---|---|
| 患者事实账本(append-only)| `patient_transactions` |
| 患者事实单元(canonical 版本流)| `patient_facts` |
| Persona 画像版本 | `personas` + `persona_features` |
| Follow-up Plan 版本 | `followup_plans` |
| Plan 子资产 | `plan_scripts` + `plan_summaries`(异步生成) |
| Plan 执行反馈 | `plan_executions` |
| Agent 调用记录 | `agent_invocations` |
| 同步运行账本 | `sync_logs` |
| Persona 重算账本 | `persona_recompute_logs` |
| Plan 生成账本 | `plan_generation_logs` |
| 接入宿主注册 | `platforms` |

详见 [db-design-v2.md](db-design-v2.md) 和 [`apps/pac-service/prisma/schema.prisma`](../apps/pac-service/prisma/schema.prisma)。

---

## 7. Milestone(v2 对齐 [W1 报告](w1-report.md))

### 7.1 总体节奏

第一个业务可用节点 / 演示节点设定在 **W4(评估节点 1)+ W6(试点接入)**。

| 阶段 | 时间 | 目标 | 状态 |
|---|---|---|---|
| Phase 1 | W1 | PAC 框架搭建 + 评审 closure | ✅ 完成 |
| Phase 2 | W2 | 数据骨架定型 + Mock 数据集 + 数据源对接文档 | 🟡 进行中 |
| Phase 3 | W3 | 数据摄入跑通 + Persona 初版 + 画像页面 v1 | 🎯 计划 |
| Phase 4 | W4 ⭐ | 召回名单 + AI 话术 + 摘要(管委会评估节点 1) | 🎯 计划 |
| Phase 5 | W5 | 客服工作台扩展 + 数据源真实接入启动 | 🎯 计划 |
| Phase 6 | W6 | 演示版 + 1 家试点最小数据接入 | 🎯 计划 |
| Phase 7 | W7+ | 试点跑通(需 DW + 客服培训配合)| ⏳ 待开始 |

### 7.2 Phase 1 ✅:PAC 框架搭建(W1)

**已交付**:
- ✅ PAC 独立服务工程骨架(NestJS + Prisma + PostgreSQL + Redis + Next.js)
- ✅ 数据库结构定型(13 个 model,4 项 raw SQL migration)
- ✅ patient_transactions / patient_facts 双表模型
- ✅ Persona 版本模型(eventWatermark)
- ✅ Follow-up Plan 版本模型(scenario + targetClinicId)
- ✅ PAC 开放 REST API 路由骨架
- ✅ AiCall 框架骨架(W2 完成 DeepSeek 直连)
- ✅ 多租户隔离基线(硬隔离 platform+tenant + 立柱业务字段 clinic_id)
- ✅ 60+ 评审决议 closure
- ✅ [host-integration.md](host-integration.md) 对接契约 v0
- ✅ [scenarios/post_treatment_recall.md](scenarios/post_treatment_recall.md) 召回算法方案 v0

### 7.3 Phase 2 🟡:数据骨架 + Mock + 对接文档(W2)

**目标**:数据源对接文档发出 + Mock 数据集启动 + 数据骨架定型。

**交付内容**:
- 🎯 [host-integration.md](host-integration.md) 发给 DW / 5i5ya / Friday 团队(由 CTO 转交,启动他们排期)
- 🎯 Mock 数据集启动:
   - 协调试点门诊脱敏样本 100-300 个(由 CTO 协调)
   - PAC 团队同时合成 Mock(用于调试,不阻塞)
- 🎯 packages/types 完成对齐新 schema(W1 末已完成 ✅)
- 🎯 数据骨架定型(`scenarios/post_treatment_recall.md` 业务方确认)

**本期 P0 风险**:业务方拍板召回算法策略(详见 [W1 报告 Page 7](w1-report.md))。

### 7.4 Phase 3 🎯:数据摄入跑通 + Persona 初版(W3)

**目标**:从 Mock 数据 → patient_transactions → parser → patient_facts → Persona 跑通,产出画像页面 v1。

**交付内容**:
- sync 模块真实实现(mock-pull adapter + parser pipeline)
- facts 模块真实实现(transaction 入站 + fact 衍生)
- patient 模块(merge-aware timeline 查询)
- persona 模块(4 个起步特征 + eventWatermark 触发)
- 画像页面 v1(100+ mock 患者画像卡片,可点击)
- 业务方点评"画像准不准"

### 7.5 Phase 4 ⭐:召回名单 + AI 话术 + 摘要(W4 — 管委会评估节点 1)

**交付内容**:
- plan 模块真实实现(scenario rules + selector + priorityScore)
- assets 模块(scripts / summaries 异步生成,BullMQ + AiCall 框架 → DeepSeek)
- 召回名单页面 v2(完整业务流可点击)
- 排序解释 + inclusionReason 模板
- AI 参考话术 + One Page Summary
- 浏览器走完一个完整业务流的演示

**评估**:业务方点评算法质量 + 话术质量。

### 7.6 Phase 5 🎯:客服工作台扩展 + 数据源真实接入启动(W5)

**目标**:客服工作台 v3 + 第一个真实 host 接入对接启动。

### 7.7 Phase 6 🎯:演示版 + 1 家试点最小接入(W6)

**目标**:1 家试点门诊真实数据切换 + 角色扮演试点。

### 7.8 Phase 7 ⏳:试点跑通(W7+)

**需要资源**:
- DW 团队 1 人(W3-W6 配合接入,W7+ 持续维护)
- 5i5ya 业务对接人(W5-W8 配合 SOP)
- 客服培训对接人(W7-W8 实施培训)

跨团队协调统一由 CTO 推动,PAC 实施侧专注代码 / 设计 / 演示交付。

### 7.9 Phase 8+:试点优化与第二场景准备(W8+)

可扩展方向:
- 漏诊召回(选项 B-2,接朝厚影像 AI)
- 复查提醒
- 沉睡客户激活
- 高价值病例跟进
- 投诉后安抚

---

## 8. 验收口径(v2 — 跟 schema 双表模型对齐)

一期项目完成时,需要达到以下结果:

1. PAC 可以从 DW / mock / Pull / Push 多通道获取 5 家试点门诊患者事实
2. PAC 可以形成 patient_transactions 操作账本(append-only,source_event_id 幂等)
3. PAC 可以衍生 patient_facts 事实单元版本流(subject_id × version + 4 种 fact_status)
4. PAC 可以对治疗链已完成患者进行实时分析(Persona engine + eventWatermark 水位)
5. PAC 可以生成 Persona(起步 4 个 feature_key)
6. PAC 可以生成 Follow-up Plan(post_treatment_recall scenario + 4 子场景 + 优先级算法)
7. PAC 可以异步生成 plan_scripts(单字段 Markdown 含多子段)+ plan_summaries(3 种 type)
8. 宿主系统可以通过 **PAC 开放 REST API** 查询结果
9. 宿主系统可以回写 plan_executions
10. PAC 可以保存事实、画像、计划、话术、执行结果的版本与证据关系:
    - `patient_facts.transactionIds[]` 引证 transaction
    - `persona_features.evidence` 引用 fact / agentInvocation / rule
    - `followup_plans.evidence` 同上
    - `agent_invocations` 记录每次 AI 调用的 inputSnapshot / output / token / cost
11. PAC 的 Persona 画像按"key + description + evidence + version" 落地,**不对 description 做字段级拆解存储**
12. 试点门诊可以基于该能力进行实际回访执行(W7+)
13. **(v2 新加)** PAC 七层数据可靠性防线落地(幂等 / 水位续传 / 原文留底 / reconcile 对账 / quarantine 兜底 / drift 监控 / 推断 stale)

---

## 9. 组织分工

> 跟 v1 完全一致,详见 [design.md §9](design.md#9-组织分工)。

| 团队 | 主要职责 |
|---|---|
| **PAC 团队**(luoqi)| 框架搭建、API 设计、Agent 链路、Persona / Plan 模型、版本与证据链、系统对接 |
| 5i5ya 团队 | 现有业务对象说明 / DW 口径支持 / 召回结果展示 / 任务承接 |
| Friday SaaS 团队 | POC 经验与规则资产 / 数据口径 / 协助沉淀到 PAC 框架 |
| 运营侧 | 试点门诊执行组织 / 回访人员安排 / 业务反馈收集 / 话术使用反馈 / 结果复盘 |
| **CTO(于总)**(v2 强调)| 跨团队协调 / 资源调度 / 排期推动(所有跨部门沟通统一由 CTO 出面)|

---

## 10. 与现有技术方案的关系(v2 — 已经实施基础)

当前已经执行的技术方案,与本方案在工程方向上本质一致。

本方案不是推翻现有,而是在 [architecture-v2.md](architecture-v2.md) 落地的基础上完成以下补充:

1. 项目名称统一为"疗效保障项目"(原"智能召回 / Recall Service" 仅作技术骨架名)
2. 底层能力统一定义为 PAC 框架
3. 补充 PAC 与疗效保障项目的关系定义
4. 明确患者事实(双表模型)/ Persona / Plan / 证据链 / 执行反馈等边界
5. 一期业务范围明确为"治疗链已完成患者疗效保障召回服务" + 4 个子场景

现有技术方案中以下工程方向继续保留:

| 保留方向 | 说明 |
|---|---|
| 独立服务 | PAC 作为独立分析框架部署,不嵌入某宿主系统内部 |
| 独立数据库 | PAC 本地落地 transactions / facts / personas / plans / executions / agent_invocations 等 |
| 宿主低成本接入 | 通过开放 REST API 接入,3-5 天对接成本 |
| iframe / 独立页面接入 | iframe 主推,npm 组件包后期备 |
| Token Exchange 鉴权 | 宿主换票获 PAC 访问凭证(2h JWT + 一次性 code) |
| 同步引擎 | Pull(主流)+ Push(增强)双路径 |
| 多租户 / 多门诊隔离 | 硬隔离 platform+tenant + 立柱业务字段 clinic_id |
| Scenario 应用层常量(v2 替代 rulesConfig)| 集团统一规则,代码 review + CI 验证 |
| AiCall 框架直连 DeepSeek V4 Pro | scripts / summaries 异步 BullMQ + audit 落 agent_invocations |
| API 文档 | Swagger / OpenAPI / Redoc(详见 [host-integration.md §5](host-integration.md#5-pac-开放-rest-api)) |

```text
现在已经执行的技术方案 = PAC 框架的工程实现基础
本方案 v2 = 在现有工程方向上,补充项目定义、业务边界、PAC 框架约束、一期落地路径、4 个子场景细化
```

调整后的项目关系:

```text
疗效保障项目 = 正式业务项目
PAC 框架 = 疗效保障项目采用的集团级患者分析框架
当前已执行技术方案(v2 重构后)= PAC 框架的工程基础
```

后续执行时,不需要重新推翻技术路线;在 v2 schema + 文档基础上推进落地。
