# 三端联调深度审计报告

> 日期: 2026-05-01 | 参与者: Claude + iven
> 目标: 记录项目最真实的状况，从全局/用户/管理者三重角度审视系统

---

## 1. 基础设施状态

### 1.1 编译与构建

| 检查项 | 状态 | 详情 |
|--------|------|------|
| `cargo check` | 通过（修复后） | 修复了 2 个编译错误：`HealthError::DatabaseError` → `DbError`，`approval_status` move 问题 |
| `cargo test --workspace` | **失败** | `erp-plugin` 测试编译失败：`parse_manifest` 未导入（`#[cfg(test)]` 缺少 `use crate::manifest::parse_manifest`） |
| `pnpm build` (Web) | 通过 | 耗时 33.67s，antd chunk 1.5MB 过大 |
| `pnpm build:weapp` (小程序) | 通过 | Sass @import deprecation 警告，pkg-health 分包 352KB 超限 |

### 1.2 数据库数据分布

| 表 | 记录数 | 评估 |
|----|--------|------|
| patient | 32 | 有测试数据 |
| doctor_profile | 8 | 有测试数据 |
| appointment | 12 | 有测试数据 |
| doctor_schedule | 15 | 有测试数据 |
| follow_up_task | 12 | 有测试数据 |
| follow_up_record | 3 | 较少 |
| consultation_session | 4 | 有测试数据 |
| consultation_message | 7 | 有测试数据 |
| article | 5 | 有测试数据 |
| alert_rules | 10 | 有测试数据 |
| ai_prompt | 4 | 有测试数据 |
| offline_event | 7 | 有测试数据 |
| health_record | 1 | 极少 |
| lab_report | 2 | 较少 |
| ai_analysis | 0 | **空表** |
| ai_suggestion | 0 | **空表** |
| alerts | 0 | **空表** |
| daily_monitoring | 0 | **空表** |
| device_readings | 0 | **空表** |
| critical_alert | 0 | **空表** |
| dialysis_prescription | 0 | **空表** |
| patient_family_member | 0 | **空表** |
| patient_tag_relation | 0 | **空表** |
| medication_reminder | 0 | **空表** |
| medication_record | 0 | **空表** |
| domain_events | 1166 | 大量事件堆积 |

**关键发现**: 32 个表中 12 个完全空表（37.5%），说明很多功能从未被端到端使用过。

---

## 2. 后端完整性

### 2.1 API 路由统计

| 模块 | 路由端点数 | CRUD 完整领域数 |
|------|-----------|----------------|
| erp-health | 98 | 15/15 全部完整 |
| erp-ai | 13 | 管理类全覆盖 |
| erp-dialysis | 8 | 2/2 完整 |
| **总计** | **119** | — |

### 2.2 后端已实现但无前端 UI 的端点（功能孤岛）

| 分类 | 端点数 | 具体内容 |
|------|--------|---------|
| AI 分析 SSE 触发 | 4 | lab-report/trends/checkup-plan/report-summary，无管理界面入口 |
| 危急值告警体系 | 4 | 列表/详情/确认/阈值配置，Web 端完全无页面 |
| 行动收件箱 | 2 | 列表/线程查看，无前端消费 |
| 统计数据 | 5 | dashboard/lab-reports/appointments/vital-signs-report-rate/health-data |
| 趋势生成 | 1 | `POST /trends/generate` 无手动触发入口 |
| **合计** | **16** | **约 13% 的后端路由为"死端点"** |

### 2.3 Service 层健康度

- Service → Handler → Router 映射链路: **100% 完整**
- 内部 Service（定时任务/事件消费者/工具函数）: 均有合理调用方
- 所有实体领域达到完整 CRUD 覆盖

---

## 3. Web 前端完整性

### 3.1 路由与页面

- 健康管理路由: **30 条**
- 基础 ERP 路由: **17 条**
- 健康模块共享组件: **11 个**
- API 服务文件: **12 个 health + 4 个 AI**

### 3.2 页面功能抽样评审

| 页面 | 完整度 | 关键缺陷 |
|------|--------|---------|
| PatientList | 8/10 | 缺空状态、批量操作未实现 |
| PatientDetail | 9/10 | 作为核心枢纽页表现优秀 |
| AppointmentList | 8/10 | 无法编辑预约内容 |
| AlertList | 7/10 | 搜索未传后端、resolve 无入口、权限码拼写错误已修 |
| FollowUpTaskList | 7/10 | 负责人筛选器空、无法编辑任务 |
| AiAnalysisList | 7/10 | 无患者关联导航、无法触发分析 |
| DialysisManageList | 8/10 | 无 PatientDetail 入口 |
| ConsultationList | 7/10 | 缺患者搜索 |

### 3.3 跨页面导航（功能关联性）

**当前关联度: 中等偏低（50%）**

| 导航路径 | 状态 |
|----------|------|
| PatientList → PatientDetail | ✅ 行点击 |
| ConsultationList → ConsultationDetail | ✅ 行点击 |
| AlertList → PatientDetail | ✅ 单向 Link |
| PatientDetail → AppointmentList | ❌ 无入口 |
| PatientDetail → ConsultationList | ❌ 无入口 |
| PatientDetail → DialysisManageList | ❌ 无入口 |
| AiAnalysisList → PatientDetail | ❌ 只显示截断 ID |
| PatientDetail → 全局随访任务 | ❌ 无跳转 |

### 3.4 死 API（已定义但无页面使用）

| API 方法 | 文件 |
|----------|------|
| `patientApi.manageTags` | patients.ts |
| `patientApi.listFamilyMembers/createFamilyMember/updateFamilyMember/deleteFamilyMember` | patients.ts (4个) |
| `alertApi.resolve` | alerts.ts |
| `articleApi.view` | articles.ts |
| `suggestionApi.getComparison` | suggestions.ts |

---

## 4. 微信小程序完整性

### 4.1 规模

- 主包页面: 15 个路由
- 分包页面: 约 47 个路由
- **页面总计: 约 62 个**
- Service 文件: 17 个（患者端 14 + 医护端 7）
- TabBar: 4 个（首页/健康/消息/我的）

### 4.2 患者端核心流程覆盖

| 核心流程 | 覆盖度 |
|----------|--------|
| 微信登录 → 手机号绑定 | 100% |
| 建档（就诊人管理） | 100% |
| 体征录入（8 种指标） | 95% |
| 趋势图 | 80%（Web 有更丰富图表） |
| 蓝牙设备同步（BLE） | 100%（**Web 端没有**） |
| 预约挂号 | 100% |
| 随访管理 | 100% |
| 在线咨询 | 100% |
| 积分系统 | 100% |
| AI 分析 | 100% |
| 健康资讯 | 100% |
| 线下活动 | 100% |
| 通知 Tab | **0%（空壳，数据写死空数组）** |

### 4.3 小程序独有功能

| 功能 | 说明 |
|------|------|
| BLE 蓝牙设备同步 | 血压计/血糖仪/小米手环 3 种适配器 |
| 微信一键登录 | wx.login + getPhoneNumber |
| 微信订阅消息 | 5 种模板消息推送 |

---

## 5. 系统统一性分析

### 5.1 功能孤岛效应

从全局角度审视，系统存在以下孤岛效应：

**A. AI 分析 — "有脑无手"**
- 后端 4 个 SSE 分析端点 + 建议审批 + 行动收件箱 全部就绪
- 前端只有"查看历史"能力，无法触发分析
- AI 分析 → 建议 → 审批 → 行动 的闭环在后端完整，前端断裂
- **影响**: AI 模块的投资回报率极低，能力已实现但无法被用户触及

**B. 危急值告警 — "有声无窗"**
- 后端告警引擎 + 规则配置 + 阈值管理 + 危急值确认 全部就绪
- Web 前端只有普通告警列表，危急值体系完全无 UI
- 小程序有告警查看但无危急值专属页面
- **影响**: 医疗安全相关功能缺口，危急值发现后可能无法及时处理

**C. 统计仪表盘 — "有数无图"**
- 后端 9 个统计端点就绪（患者/咨询/随访/化验/预约/体征上报率/透析等）
- Web 前端只有 `StatisticsDashboard` 一个页面，仅消费了部分端点
- 小程序只有医护仪表盘（6 指标卡片），无完整统计
- **影响**: 管理者视角缺失，无法通过数据驱动决策

**D. 患者详情 — "有门无路"**
- PatientDetail 作为核心枢纽页有 8 个 Tab，数据展示完善
- 但从 PatientDetail 无法跳转到预约、咨询、透析、全局随访等关联功能
- AI 分析列表也不提供到 PatientDetail 的导航
- **影响**: 用户需要在多个页面间手动切换，无法形成工作流闭环

### 5.2 数据一致性

| 问题 | 严重度 | 说明 |
|------|--------|------|
| domain_events 堆积 1166 条 | LOW | outbox 模式未清理已消费事件 |
| 12 个空表 | MEDIUM | 大量功能未被端到端验证 |
| 通知 Tab 空壳 | HIGH | 小程序消息页"通知"Tab 数据写死空数组 |
| erp-plugin 测试编译失败 | MEDIUM | `parse_manifest` 在 `#[cfg(test)]` 中未导入 |

### 5.3 过度开发 vs 欠开发

**过度开发（后端就绪但无前端）：**
- 危急值告警体系（4 端点）— 后端完整，前端零页面
- AI SSE 分析（4 端点）— 后端完整，前端零触发
- 行动收件箱（2 端点）— 后端完整，前端零消费
- 统计数据（5 端点）— 后端完整，前端部分消费

**欠开发（设计目标未达成）：**
- 小程序通知系统 — 完全未实现（空壳）
- 患者详情关联导航 — 跨功能跳转缺失
- 家属管理 UI — 4 个 API 就绪但无页面

---

## 6. 三端覆盖度矩阵

| 功能领域 | 后端 | Web 前端 | 小程序 | 完整度 |
|----------|------|---------|--------|--------|
| 患者 CRUD | 100% | 100% | 100% | ✅ 完整 |
| 体征数据 | 100% | 90% | 95% | ✅ 基本完整 |
| 化验报告 | 100% | 100% | 100% | ✅ 完整 |
| 健康档案 | 100% | 100% | 100% | ✅ 完整 |
| 预约排班 | 100% | 95% | 100% | ✅ 基本完整 |
| 随访管理 | 100% | 90% | 100% | ✅ 基本完整 |
| 咨询管理 | 100% | 95% | 100% | ✅ 基本完整 |
| 健康资讯 | 100% | 100% | 100% | ✅ 完整 |
| 积分商城 | 100% | 100% | 100% | ✅ 完整 |
| 线下活动 | 100% | 100% | 100% | ✅ 完整 |
| 告警系统 | 100% | 70% | 80% | ⚠️ Web 缺危急值/resolve |
| AI 分析 | 100% | 40% | 60% | ❌ SSE 无触发入口 |
| 危急值告警 | 100% | 0% | 0% | ❌ 完全无 UI |
| 统计仪表盘 | 100% | 50% | 30% | ⚠️ 端点就绪但消费不足 |
| 行动收件箱 | 100% | 0% | 0% | ❌ 完全无 UI |
| 设备管理 | 100% | 60% | 100% | ⚠️ Web 端缺 BLE 能力 |
| 透析管理 | 100% | 80% | 100% | ✅ 基本完整 |
| 通知系统 | 80% | 50% | 0% | ❌ 小程序空壳 |
| 家属管理 | 100% | 0% | 0% | ❌ API 就绪无 UI |

---

## 7. 优先行动建议

### P0 — 功能断裂（影响核心用户体验）

1. **AI 分析闭环打通** — 在患者详情或独立页面增加"发起 AI 分析"按钮，让 SSE 能力被触及
2. **患者详情关联导航** — 增加"查看该患者预约/咨询/透析"快捷入口
3. **小程序通知 Tab** — 对接后端通知 API，不再写死空数据

### P1 — 医疗安全

4. **危急值告警 Web UI** — 至少增加危急值列表页 + 确认操作
5. **erp-plugin 测试修复** — 补充 `use crate::manifest::parse_manifest` 导入

### P2 — 管理者视角

6. **统计仪表盘完善** — 消费已就绪的 5 个统计端点
7. **家属管理 UI** — 在 PatientDetail 增加"家庭成员"Tab
8. **AI 建议前后对比** — 集成 `suggestionApi.getComparison`

---

## 8. 实际验证发现的修正（2026-05-01 浏览器 + 代码验证）

### 8.1 报告修正

| 原报告结论 | 实际验证结果 | 修正 |
|-----------|-------------|------|
| 登录页标题"HMS" | 登录页显示 **"HMR Platform"**，与侧边栏 "HMS 健康" 不一致 | 新增：品牌命名不统一 |
| 患者数据 32 条 | 30 条是 E2E 自动化测试生成的 `E2E患者_*`，仅 2 条真实数据 | 修正：系统几乎没有被真实使用过 |
| 统计端点"部分覆盖" | API 验证患者统计、化验报告统计、预约统计、体征上报率、仪表盘统计 **全部返回正常数据** | 修正：后端统计能力完整，仅前端消费不足 |
| 危急值告警"后端完整" | `GET /health/critical-alerts` 返回 **500 Internal Server Error** | 修正：危急值端点有 bug，后端也不完整 |
| 透析管理"完整 CRUD" | `GET /health/dialysis-records` 返回 405（只接受 POST），必须按患者查询 | 修正：透析记录没有全局列表，必须先选患者 |
| 小程序咨询"100% 覆盖" | 首页/健康页/个人中心 **均无入口** 跳转到在线咨询页 | 修正：咨询功能是"页面孤岛"，用户无法发现 |
| AI SSE "无触发入口" | `POST /ai/analyze/lab-report` 端点存在且返回验证错误（需真实数据） | 确认：端点可用但前端无调用入口 |
| 行动收件箱"0 数据" | API 返回 total=0 ✅ | 确认 |

### 8.2 新发现（验证前未识别）

**A. 品牌一致性**
- 登录页标题 "HMR Platform"，侧边栏 "HMS 健康"，版权 "HMR Platform · ©汕头市智界科技有限公司"
- 产品名称在 HMR/HMS 之间摇摆

**B. 数据质量 — 测试污染**
- 32 个患者中 30 个是 E2E 自动化测试创建的 `E2E患者_*`
- domain_events 表堆积 1166 条未清理
- 建议清理测试数据或建立独立测试租户

**C. 小程序 AI 建议跳转错误**
- 健康页 AI 建议卡片识别出 `appointment`/`followup` 类型建议后
- 点击统一跳转到 **设置页**（`/pages/pkg-profile/settings/index`）
- 而非预期的预约创建页或随访详情页 — 设计缺陷

**D. 小程序咨询功能完全孤立**
- `/pages/consultation/index` 已注册，页面存在
- 但首页/健康页/个人中心均无入口指向它
- 唯一入口在消息 Tab 的"咨询"子 Tab
- 用户极难发现这个功能

**E. Web 告警页面已存在但侧边栏无入口**
- `/health/alerts` 可直接 URL 访问，页面功能完整
- 但侧边栏菜单中 **没有告警管理入口**（未出现在菜单配置中）
- 同理 `/health/alert-dashboard` 和 `/health/alert-rules` 也无菜单入口

**F. Web 侧边栏缺少多个页面入口**

| 已注册路由 | 侧边栏入口 | 状态 |
|-----------|-----------|------|
| `/health/alerts` | 无 | 需手动输入 URL |
| `/health/alert-dashboard` | 无 | 需手动输入 URL |
| `/health/alert-rules` | 无 | 需手动输入 URL |
| `/health/dialysis` | 有（"透析管理"） | ✅ |
| `/health/devices` | 有（"设备管理"） | ✅ |
| `/health/articles` | 有（"资讯管理"） | ✅ |

---

## 9. 总结

**项目整体完成度评估: 75%（实际验证后从 78% 下调）**

- **后端** (93%): 119 个路由、CRUD 全覆盖，但危急值告警端点有 500 错误
- **Web 前端** (68%): 核心页面功能完整，但存在隐性问题：告警页面有路由无菜单入口、AI/统计孤岛、跨模块导航断裂
- **小程序** (80%): 患者端覆盖度高，但咨询功能孤立（用户无法发现）、AI 建议跳转错误、通知空壳
- **数据质量** (35%): 30/32 患者为 E2E 测试数据，12/32 表完全空，系统几乎未经真实使用

**最突出的矛盾**: 后端能力远超前端消费速度，约 13% 的路由为"死端点"。而已经暴露给用户的功能中，又有多个存在导航断裂和入口缺失，形成了"有能力但不可达"的双重问题。

**新发现的系统性问题**:
1. **品牌不一致** — HMR/HMS 混用
2. **菜单配置缺失** — 告警相关 3 个页面有路由无菜单
3. **小程序导航断裂** — 咨询功能孤立、AI 建议跳转到设置页
4. **测试数据污染** — E2E 测试未清理导致数据不可信

---

## 变更记录

| 日期 | 变更 |
|------|------|
| 2026-05-01 | 初始版本 — 三端联调深度审计 |
| 2026-05-01 | 实际验证修正 — 浏览器+API+代码分析，6 项报告修正 + 6 项新发现，完成度从 78% 下调至 75% |