iven/hms
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a4732cd2d4191bb4fda7e5a4bd2ceb126e330018
hms/docs/discussions/2026-05-07-expert-brainstorm-session.md
iven df1d85bfde docs: T40 UI 审计报告 + wiki 更新 + Docker 配置 
- T40 UI 审计计划和结果文档（docs/qa/）
- wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新
- 审计 V2 完整报告（docs/audits/v2/）
- 讨论记录文档（docs/discussions/）
- 设计规格和实施计划（docs/superpowers/）
- 角色测试计划和结果（docs/qa/role-test-*）
- Docker 生产部署配置
2026-05-13 23:29:42 +08:00

10 KiB
Raw Blame History

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 数字刷新），在系统可部署的基础上再进行质量加固和产品闭环。

Reference in New Issue View Git Blame Copy Permalink