hms/docs/qa/expert-brainstorming-v1-release-final.md

HMS V1 测试版本 — 专家头脑风暴综合评估报告

评估日期: 2026-05-20 | 评估方式: 5 个并行 Agent 专家独立评估 | 评估基准: 代码审查 + API 测试结果 + 架构文档

---

1. 综合评分

1.1 六维度雷达图数据

维度	评分	等级	专家
架构	7.6/10	B+	架构专家
产品	7.3/10	B+	产品专家
安全	7.0/10	B	安全专家
UX	7.6/10	B+	UX 专家
测试	4.1/10	D+	测试专家
DevOps	3.8/10	D	依据 wiki 系统分析数据
综合	6.2/10	B-	加权平均

1.2 综合评估结论

HMS V1 测试版本在架构设计和产品功能方面表现优秀（均超 7.0），安全基线达到医疗系统基本要求（7.0），UX 设计成熟度高（7.6）。主要短板在测试充分性（4.1）和DevOps 成熟度（3.8）。

一句话总结： 产品功能和架构设计扎实，安全和 UX 达标，但测试覆盖率和 DevOps 能力是短板，需要在中期迭代中重点投入。

---

2. 产品专家评估 — 7.3/10 (B+)

评估人: 产品专家 Agent | 详细维度评分: 功能完整性 7.5 / 用户价值 8.0 / MVP 边界 7.0 / 数据完整性 7.5 / 产品成熟度 6.5

2.1 核心优势

• 医疗业务闭环完整：患者建档 → 体征录入 → 化验报告 → 医生查看 → AI 分析 → 咨询回复 → 随访管理，全链路覆盖
• AI 能力差异化：化验单解读、趋势分析、报告摘要、智能对话，超越传统 HIS 的被动管理
• 多角色支持到位：Admin/Doctor/Nurse/Health Manager/Operator/患者 6 角色各有独立工作视角
• 积分商城+线下活动：运营工具完整，提高患者粘性

2.2 主要问题

• 积分商城路由缺失：前端页面存在但后端 5 个 API 返回 404，用户看到空页面
• 小程序功能残缺：部分页面功能未连通，BLE 设备同步体验差
• AI 分析结果展示粗糙：纯文本输出，缺少结构化卡片、图表联动
• 报表能力不足：缺少自定义报表、数据导出、PDF 生成

2.3 行动建议

优先级	建议	预期收益
P0	修复积分商城路由或冻结模块	避免用户看到空页面
P1	AI 分析结果结构化展示	提升分析结果可读性
P2	报表导出（PDF/Excel）	满足医疗合规要求
P2	小程序功能连通性优化	提升患者端体验

---

3. 架构专家评估 — 7.6/10 (B+)

评估人: 架构专家 Agent | 详细维度评分: 模块化 8.5 / 可扩展性 8.0 / 数据架构 7.5 / 错误处理 8.0 / 技术债 7.0 / 生产就绪度 6.5

3.1 三大架构亮点

1. ErpModule trait + ModuleRegistry 模块化体系（8.5/10）

• ErpModule trait 定义了 name / dependencies / on_startup / on_shutdown / permissions 等生命周期钩子
• ModuleRegistry 使用 Kahn 算法拓扑排序，支持循环依赖检测
• 17 个 crate 之间零直接依赖，仅通过 erp-core trait 和事件通信
• 添加新模块成本极低：创建 crate → 实现 ErpModule → 注册

2. Outbox + Dead Letter + 幂等消费的事件可靠性链

• EventBus::publish 两阶段提交：先持久化 pending → 内存广播 → 更新 published
• consume_with_retry 幂等检查 + dead-letter 兜底
• outbox relay LISTEN/NOTIFY + 30s 兜底轮询 + 自动重连

3. 多租户双重隔离（应用层 + PostgreSQL RLS）

• 应用层所有查询强制带 tenant_id 过滤
• PostgreSQL RLS 策略 SET app.current_tenant_id 做数据库层兜底
• 即使应用层遗漏，数据库层也能防止跨租户数据泄漏

3.2 三大架构风险

1. EventBus 单进程限制（可扩展性瓶颈） broadcast::channel(1024) 纯内存广播。多实例部署时只有持有 outbox relay 连接的实例会处理 pending 事件。需引入 Redis Pub/Sub 做跨实例事件分发。

2. main.rs God File（维护性风险） 1021 行集中了模块初始化、AI Provider 构建、路由组装、安全检查、定时任务启动等。应将各模块初始化逻辑下沉到 on_startup 钩子。

3. 生产监控深度不足（运维风险） 缺少 OpenTelemetry 分布式追踪、数据库自动备份、结构化健康检查端点。Prometheus 指标有基础覆盖但缺少 SLO/SLI 定义。

3.3 行动建议

优先级	建议	预期收益
P1	拆分 main.rs 到各模块 on_startup	可维护性提升
P1	EventBus 扩展支持 Redis Pub/Sub	水平扩展前置条件
P2	补充 OpenTelemetry 追踪	生产可观测性
P2	健康检查端点深入探测 DB/Redis	运维可靠性

---

4. 安全专家评估 — 7.0/10 (B)

评估人: 安全专家 Agent | 详细维度评分: 认证与授权 7.5 / 数据保护 8.0 / 输入验证 7.0 / 网络安全 5.5 / 多租户安全 8.0 / 生产安全 5.0

4.1 安全亮点

• PII 加密成熟：AES-256-GCM + KEK/DEK 双层密钥管理，敏感字段（身份证、手机号、地址）自动加密存储
• 多租户双重隔离：应用层 + PostgreSQL RLS 策略双重保障，即使代码遗漏也不会泄漏
• 速率限制完善：IP 级 5/min 登录 + 账户锁定 + 用户级 300/min API + 网关 60/min
• 安全响应头全量覆盖：X-Frame-Options / X-Content-Type-Options / X-XSS-Protection / Referrer-Policy
• 默认密钥拒绝启动：JWT/DB/Redis/Wechat 默认密钥在生产环境直接拒绝

4.2 安全风险

• 网络安全（5.5/10）：缺少 HSTS header、CSP 策略不严格、无 WAF 前置
• 生产安全（5.0/10）：无数据库自动备份、无密钥轮换机制、无安全审计日志导出
• 输入验证（7.0/10）：空标签名导致 500、未来出生日期未拒绝、page_size 无上限

4.3 行动建议

优先级	建议	预期收益
P0	修复空标签名 500 错误	输入验证完整性
P1	添加 HSTS header	传输安全
P1	数据库自动备份策略	数据安全兜底
P2	密钥自动轮换机制	降低密钥泄漏风险
P2	CSP 策略加固	XSS 防护深化

---

5. 测试专家评估 — 4.1/10 (D+)

评估人: 测试专家 Agent | 详细维度评分: 覆盖广度 4.5 / 测试深度 4.0 / 自动化水平 3.5 / 测试质量 5.0 / 风险覆盖 3.0 / 可维护性 5.5

5.1 当前测试状态

指标	值	评价
后端测试函数	943 个	中等 — 但多为单元测试，集成测试少
前端单元测试	62 文件/~693 断言	中等
E2E 测试	17 spec/~64 断言	不足 — 覆盖率约 30%
小程序测试	0	严重缺失
API 集成测试	少量	不足 — 大量端点未覆盖
负载/性能测试	无	缺失

5.2 关键问题

• 测试覆盖率不足：943 个后端测试多为 Service 层单元测试，Handler 层和端到端 API 集成测试严重不足
• 自动化水平低：E2E 测试仅 17 个 spec，无法形成有效的回归保护网
• 小程序零测试：161 个文件 / 60 页面无任何自动化测试
• 性能测试缺失：无负载测试、无压力测试、无性能基准线
• 测试数据管理差：测试数据硬编码在测试文件中，无独立的 fixture/seed 管理

5.3 行动建议

优先级	建议	预期收益
P0	API 集成测试覆盖核心链路	关键业务回归保护
P1	E2E 测试扩展到 30+ spec	前端回归保护
P1	小程序核心流程 E2E 测试	患者端质量保障
P2	性能基准测试框架搭建	性能回归检测
P2	测试数据 fixture 管理	测试可维护性

---

6. UX 专家评估 — 7.6/10 (B+)

评估人: UX 专家 Agent | 详细维度评分: 设计一致性 8.0 / 信息架构 7.5 / 交互可用性 7.5 / 响应式适配 6.5 / 可访问性 8.0 / 视觉品质 8.0

6.1 UX 亮点

• 设计系统成熟：11 级字号 Token + 12 结构 Token，75 页面 SCSS 全量接入 var(--tk-*)
• 长者模式 100% 覆盖：58/58 页面字号 ≥ 22px，CSS 变量级联覆盖
• UI 合规审计 95/100：T40 审计 60 页面全覆盖，HIGH×2 + MEDIUM×6 全部修复
• Ant Design 6 统一风格：组件库使用一致，无自定义组件与 antd 风格冲突
• 权限引导清晰：无权限页面有友好提示，非白屏

6.2 UX 问题

• 响应式适配不足（6.5/10）：部分页面窄屏下布局错乱，表格横向滚动体验差
• 空状态处理不一致：部分列表空时显示空白，部分有 Empty 组件
• 加载状态不统一：部分页面有 Skeleton，部分直接 Spinner，部分无加载态
• 移动端体验缺失：Web 端未做移动端适配，仅依赖小程序覆盖移动场景

6.3 行动建议

优先级	建议	预期收益
P1	统一空状态/加载状态组件	体验一致性
P1	表格窄屏响应式优化	桌面端体验提升
P2	骨架屏统一应用	加载感知优化
P2	错误页面设计系统化	异常场景体验

---

7. 六维度交叉分析与 TOP 10 行动清单

7.1 维度交叉分析

维度	架构	产品	安全	测试	UX	DevOps
架构	-	模块化支撑快速迭代	双重隔离是安全基石	模块化降低测试范围	组件架构支撑设计系统	需改进部署模型
产品	模块化支持扩展	-	安全是医疗产品硬门槛	测试保障产品质量	UX 决定用户留存	CI/CD 影响交付速度
安全	RLS 是架构优势	安全增强产品信任	-	安全测试不足	安全提示需UX优化	安全运维缺失
测试	架构清晰利于测试	测试验证产品需求	安全需专项测试	-	UI 测试自动化弱	自动化测试需CI集成
UX	组件架构支撑UI	设计服务产品目标	安全与体验需平衡	无障碍测试缺失	-	性能影响体验
DevOps	部署架构需优化	交付效率影响产品	安全运维是短板	CI/CD 保障测试执行	CDN 影响加载体验	-

7.2 TOP 10 行动清单

#	行动项	维度	优先级	预估工作量
1	修复空标签名 500（DTO 校验）	安全	P0	0.5h
2	修复媒体库路由冲突	架构	P0	1h
3	积分商城路由补全或冻结	产品	P0	0.5h（冻结）/ 4h（实现）
4	出生日期合理性校验	安全	P1	0.5h
5	拆分 main.rs God File	架构	P1	4h
6	API 集成测试核心链路	测试	P1	2-3 天
7	添加 HSTS + CSP 加固	安全	P1	2h
8	统一空状态/加载状态	UX	P1	1 天
9	EventBus 支持 Redis Pub/Sub	架构	P2	2-3 天
10	补充 OpenTelemetry 追踪	DevOps	P2	2-3 天

---

8. Go/No-Go 建议

8.1 评估结论

条件	状态
核心医疗业务可用	PASS — 患者/咨询/内容/预约/AI 通过率 75-100%
安全基线达标	PASS — 认证/授权/加密/隔离/限流全部到位
前端功能正常	PASS — 8 页面手动验证通过
无 CRITICAL 安全漏洞	PASS — 安全验证全量通过
API 通过率 ≥ 95%	FAIL — Health 模块 63%（含未实现路由）
CRITICAL 问题 ≤ 0	FAIL — 2 个 CRITICAL（空标签名 500 + 路由冲突）

8.2 最终建议: CONDITIONAL GO

V1 测试版本可以有条件发布，条件如下：

1. 必须修复（预计 2h）：

   • 空标签名 500 → DTO 校验（0.5h）
   • 媒体库路由冲突 → 调整注册顺序（1h）
   • 积分商城 → 标记为冻结模块（0.5h）

2. 发布后 1 周内修复：

   • 出生日期校验
   • 随访记录 405
   • 告警规则字段不匹配

3. 下一迭代优先：

   • API 集成测试覆盖
   • HSTS + CSP 加固
   • main.rs 拆分

8.3 风险提示

• 积分商城功能不完整，如需上线则需额外 1-2 周实现
• 测试覆盖率不足以支撑频繁发布，建议建立 CI/CD 质量门禁
• 生产监控深度不足，上线后需密切关注异常指标