hms/docs/discussions/2026-05-07-expert-brainstorm-session.md

HMS 多专家组头脑风暴 — 系统成熟度评审

日期: 2026-05-07 | 数据截止: commit 786f57c | 参与者: 架构/安全/质量/产品/运维 五位虚拟专家 关联: 三维度分析主文档

背景

基于三维度深度分析（后端 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 数字刷新），在系统可部署的基础上再进行质量加固和产品闭环。