hms/docs/superpowers/specs/2026-05-03-project-analysis-brainstorm-design.md

HMS 健康管理平台 — 全项目深度分析与多专家组头脑风暴

日期: 2026-05-03 | 类型: 分析报告 | 数据截止: commit 555 | 状态: 定稿

如何使用本文档： §1-2 是全景扫描，所有人应读。§3-7 是专家组深度分析，按需阅读。§8-10 是行动矩阵和风险传导，执行时参考。每个专家组独立成章，可跳读。

TL;DR: HMS 项目整体健康度 B+。架构边界满分，安全基础扎实，文档体系完善。核心风险：前端测试 <5%、55% 事件孤立、审计整改率 8%、73 个未提交文件（截至文档编写时）。建议立即止血（P0）→ 本周补短板（P1）→ 本月治本（P2）。

---

1. 背景与目标

为什么做这次分析

HMS 项目经过 3 周密集开发（555 次提交，86 份设计规格），已进入功能基本完整的阶段。2026-04-30 完成的全系统审计发现 25 个问题（2 CRITICAL + 3 HIGH + 8 MEDIUM + 12 LOW），但审计后 3 天整改率仅 8%。此时需要一个全面的「体检」来：

1. 识别系统性风险而非单点问题
2. 从多维度（架构/安全/前端/质量/管理）交叉验证
3. 建立清晰的优先级行动矩阵

分析范围

维度	覆盖范围
后端架构	17 Rust crates / ~87k 行 / 484 源文件
前端 Web	151 文件（113 TSX + 38 TS）
微信小程序	113 文件 / 38 页面 / 5 TabBar
数据库	104 迁移 / 77+ 表
文档体系	12 页 wiki + 86 specs + 41 plans + 12 discussions

方法论

• 静态分析： 文件大小、代码模式搜索、依赖图梳理
• 模式识别： 重复代码、缺失测试、不一致的命名
• 多专家视角： 5 个虚拟专家组从不同角度审查同一代码库
• 数据来源： Cargo.toml / git log / Grep 搜索 / Wiki 内容 / 审计报告

---

2. 项目全景扫描

2.1 规模与复杂度

维度	数据	评估
Rust 代码	~87k 行 / 17 crates / 484 源文件	中大型单体，模块边界清晰
Web 前端	151 文件 (113 TSX + 38 TS)	中等规模，API 层完整
微信小程序	113 文件 / 38 页面 / 5 TabBar	功能丰富，分包合理
数据库	104 迁移 / 77+ 表	高频 schema 迭代
API 路由	328 (8 公开 + 320 受保护)	全面的业务覆盖
测试	772 后端 + 11 前端	后端尚可，前端极低
事件系统	25 类型 / 44 发布 / 14 消费者	设计精良但有孤立事件
设计文档	86 specs / 41 plans	文档驱动，管理有序
Git 历史	555 次提交	AI 辅助密集开发

2.2 架构评分矩阵

评估维度	得分 (1-5)	说明
模块边界	⭐⭐⭐⭐⭐	零循环依赖，crates 间仅依赖 erp-core
安全姿态	⭐⭐⭐⭐☆	Argon2 + AES-256-GCM + RLS + 审计哈希链，限流失败模式待改进
错误处理	⭐⭐⭐⭐⭐	统一 AppError + 跨 crate 转换 + HTTP 映射
事件系统	⭐⭐⭐⭐☆	Outbox + 死信 + 幂等，但 14 个孤立事件无消费者
前端架构	⭐⭐⭐⭐☆	API/Store/Hook 三层分离，但零 i18n、低测试覆盖
代码质量	⭐⭐⭐⭐☆	4 个 TODO、无 FIXME/HACK，但存在 6 个千行文件
测试覆盖	⭐⭐⭐☆☆	后端 772 测试尚可，前端 <5%、小程序 0%
文档完整性	⭐⭐⭐⭐☆	12 页 wiki + 86 specs，但 wiki 数据存在不一致
运维成熟度	⭐⭐⭐☆☆	Docker + 原生双轨但不同步，单分支开发，大量未提交文件

---

3. 专家组 1：架构与基础设施

成员画像： Rust 系统架构师 + 数据库工程师 + DevOps 工程师

3.1 模块依赖分析

依赖结构： 所有 16 个 crate 形成以 erp-core 为底座的星型依赖图。erp-server 是唯一的组合根，依赖所有业务 crate。每个业务 crate（auth / config / workflow / message / health / ai / dialysis / plugin）只依赖 erp-core，不存在横向依赖。

结论： 依赖图干净，零循环依赖，具备未来拆分为微服务的前置条件。当前单体架构合理，无需急于拆分。

关注点： erp-server 依赖全部 crate，任何变更都触发完整重编译。erp-health/module.rs（1130 行路由注册）和 erp-message/module.rs（1054 行）是路由注册的单文件瓶颈。

3.2 数据库迁移治理

现状： 21 天内产生 100 个迁移（日均 5 个），其中单次健康表迁移达 1532 行（m20260423_000042）。

风险：

• 超大迁移在生产环境执行失败时，回滚成本极高
• 高频迭代表明 schema 尚未稳定
• testing.md 仍写着"迁移记录应为 50 条"（实际已 100 条）

建议：

1. 建立迁移文件大小上限（单文件 < 500 行）
2. 每个 Phase 结束后冻结 schema，后续走 ALTER 而非重建
3. 生产环境迁移前必须 dry-run 验证

优先级： P2

3.3 事件系统补全

现状： 25 个事件类型中 14 个无消费者（55% 孤立率）。erp-health/event.rs 828 行集中了所有事件处理器注册逻辑，且零测试覆盖。

核心风险： 事件孤立率超过 50% 意味着大量事件发布是无效操作 — 写入数据库、消耗存储、但无人消费。更危险的是可能掩盖业务流程断裂。

建议：

1. 对 14 个孤立事件逐一评估：删除无效事件 / 实现缺失消费者
2. 为 erp-health/event.rs 补充单元测试（至少覆盖每个消费者的核心路径）
3. 建立事件注册表：每个事件必须关联至少一个消费者（CLAUDE.md 铁律已在但未执行）

优先级： P1 — 事件是模块间通信的核心，孤立事件 = 功能缺失

交叉引用： 安全组(§4.1)指出孤立事件会导致合规声明与实际行为不一致；质量组(§6.1)指出 event.rs 本身也是千行文件，重构时需要测试保障。

4. 专家组 2：安全与合规

成员画像： 安全工程师 + 医疗合规专家 + 隐私保护专家

4.1 生产安全配置审计

项目	状态	风险
JWT 密钥	启动时强制检查 __MUST_SET_VIA_ENV__	✅ 安全
PII 加密	AES-256-GCM + KEK 层级 + 开发模式拒绝生产	✅ 安全
密码哈希	Argon2 + 随机 salt	✅ 安全
PostgreSQL RLS	所有表启用 + 严格策略	✅ 安全
审计日志	哈希链防篡改	✅ 安全
限流失败模式	Redis 不可用时默认 fail-open	⚠️ 高风险
SSE Token	通过 query parameter 传递 JWT	⚠️ 中风险
AI API 密钥	api_key = "" 空字符串（非强制占位符）	⚠️ 中风险
SQL 注入	sanitize_identifier() + 参数化查询	✅ 安全

关键建议：

1. P0 — 限流 fail-close： 生产环境必须设置 ERP__RATE_LIMIT__FAIL_CLOSE=true，否则 Redis 宕机 = 无限流
2. P1 — SSE Token 安全： 改用短期一次性 ticket 替代 JWT query param，避免 token 出现在日志/历史记录
3. P1 — AI 密钥统一： 与 JWT 密钥一样使用 __MUST_SET_VIA_ENV__ 占位符模式
4. P2 — 审计日志写入： fire-and-forget 模式可能导致静默丢失，改为带重试队列

交叉引用： 质量组(§6.3)指出 unwrap() 调用中 PluginHost::db panic 是同一类问题 — 关键路径缺乏容错。

4.2 医疗数据合规性

已有能力：

• PII 加密体系完善（KEK → DEK → 数据加密 + HMAC 盲索引）
• PostgreSQL RLS 已在所有表启用
• 审计日志实现哈希链防篡改
• 多租户隔离通过 JWT 中间件 + tenant_id 列过滤

缺口：

缺口	影响	优先级
小程序知情同意页面缺失	医疗合规底线，后端 consent 实体存在但前端完全空白	P1
数据保留策略缺失	无自动化数据过期/匿名化机制	P2
访问日志粒度不足	audit_logs 记录 API 调用但不记录具体访问了哪些患者数据	P3

5. 专家组 3：前端工程与用户体验

成员画像： 前端架构师 + UX 研究员 + 测试工程师

5.1 测试覆盖率分析

前端测试现状（Web + 小程序）：

层面	文件数	测试文件数	覆盖率
Web 页面	40+	0	0%
Web Store	6	0	0%
Web Hook	9	2	~22%
Web API	30+	1	~3%
Web 组件	10	1	~10%
小程序页面	40	0	0%
小程序服务	25+	0	0%

已有的 E2E 覆盖：

• Web：13 个 Playwright spec（患者旅程、预约、随访、体征、告警等核心流程）
• 小程序：4 个 automator spec（商城、健康查看、积分、体征录入）

核心判断： 前端测试覆盖率 <5% 是项目最大的质量风险。后端有 772 个测试保障，但前端 151 个文件几乎裸跑。E2E 测试慢且脆弱，不能替代单元测试 — 任何重构都可能引入不可检测的回归。

交叉引用： 4 个专家组独立得出「前端测试是最大短板」的结论 — 架构组(§3)、质量组(§6)、管理组(§7) 均标记。风险传导链(§10)说明低测试覆盖放大了所有其他重构风险。

建议：

1. P1 — Store 测试： 6 个 Zustand Store 是状态管理核心，每个至少 10 个测试
2. P1 — API 契约测试： 30+ API 模块验证 URL / Method / 参数序列化
3. P2 — 关键 Hook 测试： usePaginatedData、usePermission、useApiRequest
4. P3 — 小程序测试： 从 BLE 管理器和安全存储工具开始

5.2 国际化评估

现状： 整个项目零 i18n — 所有 UI 字符串硬编码中文，无 i18n 框架。

影响评估：

• 短期：不影响 — 目标用户就是中文用户
• 中期：如有国际医疗机构客户，改造成本巨大
• 长期：取决于商业策略

建议： 不急于实施，但提取 antd.locale(zhCN) 和 dayjs.locale('zh-cn') 为可配置入口，建立防腐层。优先级 P4。

5.3 组件质量与大文件

Web 前端大文件（>500 行）：

文件	行数	问题	建议
Organizations.tsx	622	组织树+部门树+岗位三合一	拆为 OrgTree + DeptTree + PositionPanel
ArticleEditor.tsx	554	富文本+图片上传+表单	拆为 ArticleForm + ImageUploader
MainLayout.tsx	554	菜单+侧边栏+头部+面包屑	拆为 Sidebar + Header + Breadcrumb
AppointmentList.tsx	518	列表+筛选+创建弹窗	拆为 AppointmentFilter + AppointmentForm
VitalSignsChart.tsx	485	多系列图表	拆为 ChartConfig + DataTransformer

正面发现：

• 零 console.log 残留
• 零硬编码 mock 数据
• API 层与页面层分离良好
• Zustand Store 职责清晰，无 god store

6. 专家组 4：代码质量与技术债

成员画像： 资深工程师 + 代码审查专家

6.1 后端热点文件治理

千行以上文件（按风险排序）：

文件	行数	风险	说明
erp-health/service/points_service.rs	1863	🔴	积分业务核心，所有积分逻辑集中
erp-plugin/manifest.rs	1781	🟡	插件清单解析，变更频率低
erp-plugin/dynamic_table.rs	1768	🟡	DDL 生成，含安全防护
erp-plugin/data_service.rs	1693	🟡	插件通用 CRUD
erp-health/module.rs	1130	🟠	路由注册瓶颈
erp-health/service/stats_service.rs	1117	🟡	统计服务
erp-health/service/patient_service.rs	1111	🟠	患者核心业务，tracing 已补全（20 条）
erp-health/service/health_data_service.rs	986	🟠	健康数据核心
erp-health/service/action_inbox_service.rs	930	🟡	Action inbox

建议拆分策略：

• points_service.rs → points_account + points_rule + points_exchange + points_checkin
• patient_service.rs → patient_crud + patient_family + patient_tag + patient_export
• module.rs (health) → 按子域拆路由组

优先级： P2 — 在下一次大改动时顺带重构

交叉引用： 前端组(§5.3)独立发现 Web 侧同样存在 5 个 500+ 行大组件。架构组(§3.1)指出 module.rs 路由注册瓶颈。后端 + 前端共 11 个大文件需要拆分，是跨维度共识。

6.2 前端错误处理统一化

重复模式（18+ 文件）：

// 被 18+ 个页面文件重复的内联错误提取
(err as { response?: { data?: { message?: string } } })?.response?.data?.message

已有的正确方案： api/client.ts 中的 handleApiError() 函数 — 但多数页面未使用。

建议：

1. 统一使用 handleApiError() 或 useApiRequest hook
2. 批量替换 18 个文件中的内联模式
3. 建立 ESLint 规则禁止该模式

优先级： P2 — 依赖 P1 Store 测试完成后再批量重构，避免无安全网的大规模替换

交叉引用： 前端组(§5.1)指出前端测试 <5%，意味着这个 18 文件重构在没有测试保障下执行 = 高风险。应先完成 #7 Store 测试。

6.3 TypeScript 类型安全

any 使用统计：

• Web：10 处（3 个文件）— 集中在 usePaginatedData（5 处）和插件看板（4 处）
• 小程序：28 处（12 个文件）— 集中在 BLE API 类型缺失（11 处）和微信登录响应（5 处）

根因分析：

• usePaginatedData：Hook 重载签名问题，可通过泛型收窄解决
• 小程序 BLE：Taro 的 BLE 类型定义不完整，需补充类型声明文件

优先级： P3 — 不影响运行时，但影响类型安全性

其他技术债：

项目	数量	优先级
编译器警告	40 个	P3
unwrap() 调用（service 层生产风险）	2 处（PluginHost::db / semaphore acquire）	P2
TODO 注释	4 个（全部合理）	P4
过时迁移注释（"应为 50 条"）	1 处	P2

7. 专家组 5：项目管理与交付效率

成员画像： 项目经理 + 产品负责人

7.1 未提交工作积压

严重程度： 🔴 CRITICAL

现状： 工作树中存在 24 个已修改未提交文件 + 48 个未跟踪新文件（共 73 个），包括：

• 8 个 wiki 文件（文档更新）
• 4 个小程序源文件
• 2 个 Web 前端文件
• 8 个 Rust 业务代码文件（跨 5 个 crate）
• 7 个新的小程序医生端服务文件
• 8 个审计报告文档
• 5 个讨论记录
• 临时文件（_temp/、mp_error.png、tmp_chart.png 等）

风险： 本地故障 = 大量工作丢失 + 无法回溯变更历史 + 违反 CLAUDE.md 闭环工作法。

建议： 立即执行分类提交 — 按功能 / 文档 / 配置分组，并清理临时文件。

交叉引用： 架构组(§3.1)指出 wiki 文档未提交，质量组(§6.3)指出过时注释未更新 — 三组数据均指向「闭环工作法未执行」的系统性问题。风险传导链(§10.2)说明未提交文件是人员单点故障的放大器。

7.2 审计整改进度

整改率： 25 个审计发现中仅 1-2 个已处理（~8%，3 天后）

CRITICAL 项状态：

ID	问题	天数	状态
C1	晚间血压数据丢失	3	已修复但 wiki 文档未更新
C2	告警权限码拼写错误 (alert → alerts)	3	未修复（5 分钟改动）

HIGH 项状态：

ID	问题	状态
H1	小程序透析模块完全缺失	未开始
H2	小程序知情同意页面完全缺失	未开始
H3	健康服务运行时日志严重不足	部分修复（patient_service tracing 已补全，其他大文件待跟进）

建议：

1. C2 立即修复 — 改 health.alert.manage → health.alerts.manage
2. 建立审计整改看板 — 每个 finding 分配责任人和截止日期
3. 严格按 CRITICAL → HIGH → MEDIUM 顺序处理

7.3 Wiki 一致性

发现的不一致：

位置	问题
architecture.md:28-29	重复的插件列表行（一行有 assessment，一行没有）
architecture.md:25	权限码数量 22（实际 erp-health 有 39 个）
testing.md:124	迁移数 "应为 50 条"（实际已 96 条）
database.md	迁移文档仅覆盖到 m000091（实际 m000100）
infrastructure.md	更新日期停留在 2026-04-23
Docker compose	PostgreSQL 16 vs wiki 声称的 18
entity 计数	architecture.md 说 44，实际列表有 45 个

建议： 安排 wiki 刷新会话，逐一校对数据。优先级 P2。

交叉引用： 本文档自身的数据已用代码库实际值校正（见 §1 头部注释）。但 wiki 中仍有 7 处不一致未修。架构组(§3.2)和本组均发现此问题 — 3 组独立验证，可信度高。

8. 优先级行动矩阵

🔴 P0 — 立即处理（今天）

#	行动	工作量	完成标准	阻塞
1	提交并推送 73 个未提交文件	30 min	git status 干净 + git push 成功	所有后续工作
2	修复 C2 告警权限码拼写	5 min	AlertList 页面按钮正常显示 + 无 403	—
3	确认 C1 晚间血压修复并更新 wiki	15 min	小程序录入晚间血压 → 数据库有记录 + wiki 症状导航已更新	—

🟠 P1 — 本周内

#	行动	工作量	完成 standard	依赖
4	生产限流 fail-close 配置	1h	config/production.toml 含 fail_close = true + 集成测试验证	#1
5	补全 erp-health/event.rs 测试	4h	每个消费者至少 1 个正向 + 1 个异常测试	—
6	孤立事件清理（14 个）	8h	每个事件有消费者或已删除，孤立率 <10%	#5
7	前端 Store 单元测试（6 个 store）	8h	每个 store ≥10 测试，覆盖核心 action 和 selector	#1
8	小程序透析模块（审计 HIGH H1）	16h	透析记录查看/新增/编辑页面可用 + 4 个 automator spec	#1
9	小程序知情同意模块（审计 HIGH H2）	8h	知情同意签署页面 + 签署后事件正常发布	#1
10	health_data_service / action_inbox 补充 tracing	4h	两个文件的关键路径均有 tracing::info/error	—

🟡 P2 — 本月内

#	行动	工作量	完成 standard	依赖
11	前端错误处理统一化（18 个文件）	4h	0 处内联错误提取，全部用 handleApiError	#7
12	大文件拆分（后端 6 个千行文件）	16h	无 >1000 行的 service 文件	—
13	前端 API 契约测试	8h	每个 API 模块 ≥3 测试（URL/Method/参数）	#7
14	Wiki 数据一致性刷新	4h	wiki 中所有计数与代码库一致	—
15	数据库迁移治理策略	8h	新迁移 <500 行 + 有 dry-run 脚本	—
16	unwrap() 调用替换（2 处）	2h	grep -r "unwrap()" service/ 返回 0 结果	—

🟢 P3 — 季度规划

#	行动	工作量	完成 standard	依赖
17	编译器警告清理（40 个）	8h	`cargo check 2>&1	grep warning` 返回 0
18	前端大组件拆分（20 个文件）	16h	无 >500 行的 TSX 文件	#12
19	TypeScript any 消除	8h	grep -r ": any" Web 返回 0 / 小程序 <5	—
20	小程序测试基础设施	16h	BLE + secure-storage + 核心页面单元测试	#8
21	Docker 配置与文档对齐	4h	compose 版本号 = wiki 声明	#14
22	数据保留策略设计	16h	设计规格文档 + 至少 1 个实体的自动化过期	—

---

9. 交叉验证：多组共识与分歧

5 个专家组独立分析同一代码库。本节记录各组发现的交叉印证和矛盾，增强结论可信度。

9.1 多组共识（≥3 组独立发现同一问题）

共识问题	涉及专家组	核心引用
前端测试空白是最大风险	架构(§3) + 前端(§5.1) + 质量(§6) + 管理(§7)	前端 151 文件仅 11 测试（<5%），4 组独立得出"不可接受"结论
大文件/大组件是可维护性瓶颈	架构(§3.1) + 前端(§5.3) + 质量(§6.1)	后端 6 个千行文件 + 前端 5 个 500+ 行组件，3 组独立标记
Wiki 数据过时	架构(§3.2) + 质量(§6.3) + 管理(§7.3)	迁移数/权限码/entity 计数多处不一致，3 组各自发现不同不一致
审计整改执行纪律缺失	管理(§7.2) + 安全(§4.1) + 质量(§6)	C2 五分钟改动 3 天未修，限流 fail-open 未配置，说明流程断裂

9.2 组间互补（A 组发现问题，B 组补充影响）

问题	A 组发现	B 组补充
孤立事件	架构组(§3.3): 55% 孤立率	安全组(§4.1): 事件无消费者 = 功能声明与实际不一致，合规审计时被发现
限流 fail-open	安全组(§4.1): Redis 宕机无限流	架构组(§3.1): 单体架构下 Redis 是 SPOF，影响全局
前端错误处理重复	质量组(§6.2): 18 文件重复模式	前端组(§5.1): 无测试覆盖 = 重构时无法验证不破坏
unwrap() 调用	质量组(§6.3): 2 处生产风险	安全组(§4.1): PluginHost::db panic = 整个插件子系统不可用
小程序页面空白	前端组(§5): 功能缺失	安全组(§4.2): 知情同意缺失 = 医疗合规底线问题

9.3 无重大分歧

5 组之间无结论性矛盾 — 所有发现方向一致，差异仅在优先级判断上：

• i18n：前端组判 P4，安全组未提及。共识：不阻塞
• 编译器警告：质量组判 P3，架构组未提及。共识：可延后

---

10. 风险传导链

风险不是孤立的。以下展示风险如何通过依赖关系互相放大，解释为什么某些 P0 看似小改动却必须立即处理。

10.1 核心传导路径

未提交文件积压 (#1)
  ├─→ 本地故障 = 工作丢失 → 阻塞所有后续工作
  └─→ 审计整改延迟 → C2 五分钟改动被搁置 3 天

孤立事件 55% (#6)
  ├─→ 功能声明 ≠ 实际行为 → 用户不可见的业务断裂
  └─→ 无消费者测试 → 重构 event.rs 时无法验证 (#5)

前端测试 <5% (#7)
  ├─→ 错误处理统一化 (#11) 无法验证 → 技术债固化
  ├─→ 大组件拆分 (#18) 风险极高 → 不敢重构
  └─→ API 契约测试 (#13) 无回归安全网 → 新功能也可能破坏旧功能

限流 fail-open (#4)
  └─→ Redis 宕机 → 无限流 → 恶意请求打垮服务 → 影响所有用户

10.2 风险放大效应

放大器	被放大的风险	机制
低测试覆盖	重构风险	任何代码变更都无法验证不引入回归
孤立事件	功能验证盲区	发布的事件无消费者 = 变更的影响无法观测
未提交文件	人员单点故障	唯一开发者本地故障 = 全部工作丢失
Wiki 过时	决策误导	基于过时 wiki 的新决策可能建立在错误前提上

---

11. 总结与建议

整体评分：B+（良好，有明确的提升空间）

核心优势

1. 架构设计出色 — 分层清晰、模块边界严格、事件驱动解耦、零循环依赖
2. 安全基础扎实 — Argon2 + AES-256-GCM + PostgreSQL RLS + 审计哈希链
3. 文档驱动开发 — 86 份设计规格、12 份讨论记录、12 页 wiki，决策有据可查
4. API 层完整 — 328 路由覆盖所有业务，前端 API 层与后端 1:1 对应
5. 前端架构清晰 — API / Store / Hook 三层分离，无 god store、无硬编码数据、无 console.log 残留

核心风险

1. 前端测试空白 — <5% 覆盖率，任何重构都是冒险
2. 审计整改缓慢 — 3 天仅处理 8% 的审计发现，CRITICAL C2（5 分钟改动）仍未修复
3. 工作积压 — 73 个文件未提交，违反闭环工作法
4. 孤立事件 — 55% 的事件无消费者，可能是功能断裂的信号
5. 可观测性不足 — 多个核心 service 文件仍缺 tracing 日志（patient_service 已补全）

成功度量

每个优先级阶段的验收标准：

阶段	时间窗口	核心指标	目标
P0 止血	今天	CRITICAL 项关闭率	100%（2/2）
P0 止血	今天	未提交文件数	0
P1 补短板	本周	审计 HIGH 关闭率	≥66%（2/3）
P1 补短板	本周	前端 Store 测试数	≥60
P1 补短板	本周	事件孤立率	<10%
P2 治本	本月	千行 service 文件	0
P2 治本	本月	Wiki 数据准确率	100%
P3 持续	季度	前端测试覆盖率	>30%
P3 持续	季度	编译器警告数	0

下一步方向

当前阶段应遵循 「止血 → 补短板 → 治本」 路径：

1. 止血（P0，今天）： 提交积压文件 + 关闭审计 CRITICAL
2. 补短板（P1，本周）： 事件系统 + 前端测试 + 小程序透析/知情同意 + 安全配置
3. 治本（P2，本月）： 代码重构 + 文档刷新 + 迁移治理
4. 持续改善（P3，季度）： 类型安全 + 警告清理 + 测试扩展

一句话总结： 架构扎实、文档丰富的项目，当前需要暂停新功能开发，用 1-2 周集中补强测试和运维纪律，为下一阶段的功能扩展建立可靠的基础。