df1d85bfde
- T40 UI 审计计划和结果文档（docs/qa/） - wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新 - 审计 V2 完整报告（docs/audits/v2/） - 讨论记录文档（docs/discussions/） - 设计规格和实施计划（docs/superpowers/） - 角色测试计划和结果（docs/qa/role-test-*） - Docker 生产部署配置
199 lines
10 KiB
Markdown
199 lines
10 KiB
Markdown
# HMS 多专家组头脑风暴 — 系统成熟度评审
|
||
|
||
> 日期: 2026-05-07 | 数据截止: commit 786f57c | 参与者: 架构/安全/质量/产品/运维 五位虚拟专家
|
||
> 关联: [三维度分析主文档](2026-05-07-three-dimension-analysis.md)
|
||
|
||
## 背景
|
||
|
||
基于三维度深度分析（后端 579 Rust 文件 / 前端 283 Web + 118 小程序 / 文档 47 规格 + 49 计划），召集五位虚拟专家从不同视角对 HMS 系统进行独立评审。每位专家给出评分、优劣势分析和"如果只能做一件事"的建议。
|
||
|
||
---
|
||
|
||
## 专家 A：架构专家
|
||
|
||
**评分：7.5 / 10（B+）**
|
||
|
||
### Top 3 优势
|
||
|
||
1. **模块边界设计优秀** — 18 个 crate 间零直接业务依赖，ErpModule trait 统一生命周期管理（注册/启动/关闭/健康检查），天然支持未来微服务拆分。这是教科书级的模块化单体架构。
|
||
2. **事件驱动架构成熟** — 31 个事件类型 + 23 个幂等消费者 + PostgreSQL Outbox + LISTEN/NOTIFY + 死信队列，保证了事件不丢失、不重复处理。
|
||
3. **多租户从第一天内置** — `tenant_id` 列过滤 + JWT 中间件注入 + PostgreSQL RLS 策略三层纵深，非事后补丁。
|
||
|
||
### Top 3 风险
|
||
|
||
1. **erp-health 巨石模块失控** — 179 文件 / 35,750 行，占全部代码 38%。搭载 12 个业务子域，4 个 service 文件超过 1,000 行。如果继续堆叠功能，维护成本将指数级增长。
|
||
2. **事件系统治理不足** — 事件类型从初始设计到现在持续膨胀，但缺乏版本管理、schema 注册、消费者健康监控。care_plan 等模块的事件存在悬空消费者。
|
||
3. **冻结策略增加架构复杂度** — 7 个模块冻结但代码仍存在，路由仍注册，数据库表仍占用。每次查询、权限检查、菜单渲染都需要考虑"是否冻结"逻辑。
|
||
|
||
### "如果只能做一件事"
|
||
|
||
将 erp-health 按业务子域拆分为 3-4 个 crate（patient-core、health-data、appointment-scheduling、care-management），先从最大的 service 文件开始拆分。
|
||
|
||
---
|
||
|
||
## 专家 B：安全专家
|
||
|
||
**评分：7.0 / 10（B）**
|
||
|
||
### Top 3 优势
|
||
|
||
1. **PII 加密体系完善** — AES-256-GCM 加密 + KEK/DEK 分层密钥管理 + HMAC 盲索引搜索，949 行 patient_service 全链路加密。在同类医疗 SaaS 中属于领先水平。
|
||
2. **审计响应速度快** — V1 的 2 个 CRITICAL 和 V2 的 CRITICAL（SQL 注入、FHIR 越权）均已快速修复。
|
||
3. **多租户隔离纵深防御** — JWT 中间件注入 → SeaORM 自动过滤 → PostgreSQL RLS 策略三层隔离。
|
||
|
||
### Top 3 风险
|
||
|
||
1. **安全漏洞绕过代码审查** — V2 仍发现 SQL 注入（`format!` 拼接 SQL）和 FHIR 越权（`allowed_patient_ids` 未强制执行）。CRITICAL 级别漏洞不应在事后审计才发现，说明 code review 流程存在安全盲区。
|
||
2. **安全测试套件缺失** — 772 个后端测试中没有专门的安全测试。SQL 注入 fuzzing、多租户隔离破坏、FHIR 访问控制等均无系统性测试。当前是"发现一个修一个"的被动模式。
|
||
3. **514 个 unwrap() 调用** — erp-plugin 113 个、erp-ai 77 个。生产环境中 panic 意味着服务中断，医疗系统的服务中断可能影响患者及时获取告警。
|
||
|
||
### "如果只能做一件事"
|
||
|
||
建立安全测试套件（`crates/erp-security-tests/`），包含 SQL 注入 fuzzing、多租户隔离破坏测试、FHIR 访问控制测试、PII 加密边界测试。每个安全修复必须附带回归测试。
|
||
|
||
---
|
||
|
||
## 专家 C：质量专家
|
||
|
||
**评分：6.0 / 10（C+）**
|
||
|
||
### Top 3 优势
|
||
|
||
1. **后端测试基础扎实** — 772 个测试函数（611 单元 + 153 集成 + 8 多模块），97.5% 通过率。erp-health 的 303 个测试覆盖了完整业务链路。
|
||
2. **CI/CD 双平台** — GitHub Actions + Gitea Actions 双保险，覆盖编译/测试/clippy/fmt/TypeScript/安全审计。
|
||
3. **Web 测试基础设施完善** — MSW mock + 测试工厂模式 + Page Object + Playwright E2E，质量工具链齐全。
|
||
|
||
### Top 3 风险
|
||
|
||
1. **前端/小程序测试覆盖极差** — Web 283 文件对 62 测试（1:4.5），小程序 118 文件对 4 测试（1:30）。小程序几乎无测试覆盖，任何改动都是高风险回归。
|
||
2. **pre-commit hooks 缺失** — ESLint 配置了但无本地强制执行，代码可以不经检查就提交。514 个 unwrap() 和硬编码中文就是明证。
|
||
3. **代码质量债务累积** — 514 个 unwrap()、TypeScript `any` 类型残留（Web 10 / 小程序 28）、前端文本全量硬编码中文无国际化准备。
|
||
|
||
### "如果只能做一件事"
|
||
|
||
配置 pre-commit hooks（husky + lint-staged），每次提交前自动运行 cargo fmt/clippy + eslint + vitest --related。这是成本最低、收益最高的质量门禁。
|
||
|
||
---
|
||
|
||
## 专家 D：产品专家
|
||
|
||
**评分：6.5 / 10（B-）**
|
||
|
||
### Top 3 优势
|
||
|
||
1. **医疗业务功能覆盖全面** — 12 个活跃功能域覆盖患者全生命周期：建档 → 体征 → 预约 → 随访 → 咨询 → AI 分析 → 告警 → 积分激励 → 内容教育。
|
||
2. **多角色工作台设计** — 5 角色定制化工作台（admin/doctor/nurse/health_manager/operator），独立仪表盘和操作流程，面向 B 端医疗市场的正确策略。
|
||
3. **双端覆盖** — Web 管理端覆盖医护管理场景，小程序覆盖患者和医护移动端。BLE 设备集成为未来 IoT 场景打下基础。
|
||
|
||
### Top 3 风险
|
||
|
||
1. **7 个冻结模块造成产品残缺感** — 护理计划、班次管理、透析管理等在 UI 有入口但被守卫拦截，用户会困惑"为什么存在但不能用"。
|
||
2. **AI 分析无前端入口** — 4 个 SSE 分析端点完整实现但无 UI 触发入口。AI 智能分析是核心差异化卖点，但用户无法使用。
|
||
3. **国际化完全缺失** — 所有前端文本硬编码中文，限制市场范围。虽然当前目标是国内体检中心，但中长期多语言是刚需。
|
||
|
||
### "如果只能做一件事"
|
||
|
||
补全 AI 分析前端 UI 入口。后端 4 个 SSE 端点已完整实现（缓存/队列/预校验），只需前端接入层 + 结果展示页。完成后核心差异化功能完整呈现给用户。
|
||
|
||
---
|
||
|
||
## 专家 E：运维专家
|
||
|
||
**评分：5.0 / 10（C）**
|
||
|
||
### Top 3 优势
|
||
|
||
1. **Docker Compose 配置存在** — PostgreSQL 16 + Redis 7 容器化配置完整，带健康检查和资源限制。
|
||
2. **一键启动脚本** — dev.ps1 管理前后端生命周期，自动清理端口残留进程，开发者体验良好。
|
||
3. **配置外部化到位** — 敏感配置通过 `ERP__` 环境变量覆盖 TOML，8 个必设变量标记为 `__MUST_SET_VIA_ENV__`。
|
||
|
||
### Top 3 风险
|
||
|
||
1. **零生产部署方案** — Docker 仅覆盖数据库层，无应用镜像（Rust 后端 + React 前端）。无 Kubernetes/Docker Swarm 配置。692 次提交、85% 完成度，但无法部署到任何服务器。
|
||
2. **可观测性几乎为零** — 无 Prometheus metrics 端点、无 Grafana 仪表盘、无分布式追踪、无结构化日志聚合。医疗系统的告警延迟、AI 响应时间、预约并发冲突都需要实时监控。
|
||
3. **根目录污染严重** — 日志文件、测试令牌、截图、OCR 数据（3.4MB）、Python 遗留脚本散落在根目录，反映运维规范缺失。
|
||
|
||
### "如果只能做一件事"
|
||
|
||
创建生产级 Dockerfile（多阶段构建：Rust 编译 → 精简运行时镜像 + Nginx 托管 React 静态文件），配合 docker-compose.production.yml。从"能跑"到"能部署"的关键一步。
|
||
|
||
---
|
||
|
||
## 综合评审
|
||
|
||
### 评分雷达
|
||
|
||
| 维度 | 评分 | 等级 |
|
||
|------|------|------|
|
||
| 架构 | 7.5 | B+ |
|
||
| 安全 | 7.0 | B |
|
||
| 产品 | 6.5 | B- |
|
||
| 质量 | 6.0 | C+ |
|
||
| 运维 | 5.0 | C |
|
||
| **综合** | **6.4** | **B-** |
|
||
|
||
### 风险矩阵
|
||
|
||
| 风险 | 概率 | 影响 | 等级 | 缓解措施 |
|
||
|------|------|------|------|---------|
|
||
| 无生产部署能力 | 高 | 阻塞 | **CRITICAL** | Dockerfile + 部署文档 |
|
||
| 安全漏洞绕过 code review | 高 | 高 | **HIGH** | 安全测试套件 + review checklist |
|
||
| erp-health 维护失控 | 中 | 高 | **HIGH** | 子域拆分 |
|
||
| 小程序回归风险 | 高 | 中 | **HIGH** | 测试框架搭建 |
|
||
| 事件系统治理缺失 | 中 | 中 | **MEDIUM** | 事件注册表 + 版本化 |
|
||
| 文档过时降低效率 | 高 | 低 | **MEDIUM** | wiki 数字刷新 |
|
||
|
||
### 优先级行动清单
|
||
|
||
**P0 — 止血（本周）：**
|
||
|
||
| 行动 | 领域 | 工作量 | 预期收益 |
|
||
|------|------|--------|---------|
|
||
| 生产级 Dockerfile | 运维 | 8h | 从"能跑"到"能部署" |
|
||
| pre-commit hooks | 质量 | 4h | 最低成本质量门禁 |
|
||
| AI 分析前端 UI | 产品 | 16h | 核心差异化功能完整呈现 |
|
||
|
||
**P1 — 加固（两周内）：**
|
||
|
||
| 行动 | 领域 | 工作量 | 预期收益 |
|
||
|------|------|--------|---------|
|
||
| 安全测试套件 | 安全 | 24h | 从被动修复到主动防御 |
|
||
| erp-health 子域拆分 Phase 1 | 架构 | 40h | 控制巨石模块膨胀 |
|
||
| 可观测性基础设施 | 运维 | 16h | metrics 端点 + 结构化日志 |
|
||
|
||
**P2 — 提升（一个月内）：**
|
||
|
||
| 行动 | 领域 | 工作量 | 预期收益 |
|
||
|------|------|--------|---------|
|
||
| 小程序测试框架 | 质量 | 16h | 消除 1:30 的回归风险 |
|
||
| 事件注册表与版本化 | 架构 | 16h | 事件治理体系化 |
|
||
| 冻结模块 UI 优化 | 产品 | 8h | 消除产品残缺感 |
|
||
| 根目录清理 | 运维 | 4h | 基础卫生 |
|
||
|
||
### 路线图建议
|
||
|
||
**Phase 0：部署就绪（2 周）**
|
||
- 生产级 Dockerfile + docker-compose.production.yml
|
||
- Nginx 反向代理 + 环境变量模板
|
||
- 基本 Prometheus metrics 端点
|
||
|
||
**Phase 1：质量门禁（2 周）**
|
||
- pre-commit hooks 配置
|
||
- 安全测试套件建立
|
||
- 千行 service 文件拆分
|
||
- P0 文档更新
|
||
|
||
**Phase 2：产品闭环（4 周）**
|
||
- AI 分析前端 UI 补全
|
||
- 工作台 v2 优化（AI 洞察面板）
|
||
- 冻结模块 UI 优雅处理
|
||
- 前端测试覆盖率提升到 50%+
|
||
|
||
---
|
||
|
||
## 结论
|
||
|
||
HMS 系统在**架构设计和业务建模**上表现出色（B+），但在**运维能力和测试覆盖**上存在明显短板（C/C+）。项目功能完整度已达 85%，但生产就绪度仅约 55%。最关键的差距不是功能缺失，而是**从开发环境到生产环境的跨越能力**。
|
||
|
||
建议立即启动 Phase 0（部署就绪），同步推进文档更新（wiki 数字刷新），在系统可部署的基础上再进行质量加固和产品闭环。
|