hms/docs/discussions/2026-06-25-analysis/00-INDEX.md

HMS 健康管理平台 — 项目负责人决策简报

日期: 2026-06-25 | 分支: feat/media-library-banner | 阶段: V1 CONDITIONAL GO（上线临门一脚） 范围: 9 维度评分 → TOP 12 痛点收敛为 TOP 5 决策项 → 6 主题战略 → 4 阶段路线图 → TOP 7 行动建议 面向: V1 上线后 6-12 个月演进，不重复上线前就绪度讨论 证据口径: 所有论断附 文件路径:行号 或 grep 结果，基于 feat/media-library-banner 分支实测

---

一、执行摘要

HMS 是一个工程完成度相当高的医疗 SaaS 平台：后端架构分层严格（L1/L2/L3 + 无环依赖图 + Outbox 事件总线 + 双层多租户），PII 加密与 V2 审计 CRITICAL 修复已达企业级，AI 模块 4 Provider + ReAct + RAG 工程完成度高，前端架构成熟、小程序并发治理扎实。综合评分 6.8 / 10（B），处于「可支撑 V1 上线，但距生产级品质与主动关怀引擎定位还差关键闭环」的阶段。

本次分析发现的核心张力是：多处宣称已完成的自动化链路实际断裂，且真相源（wiki）与代码系统性漂移，叠加支撑层（DevOps 4.2 / 测试 5.5）严重缺位，使上层可靠性无护栏兜底。最尖锐的 4 个 CRITICAL 级问题中，3 个是「文档说已修复、代码说没有」——死信重试从未接线（PP-01）、AI 分析队列只入队不消费（PP-05）、RLS 误记 FORCE（PP-07）；第 4 个是生产 Redis 密码明文进 git 追踪的 wiki（PP-03）。叠加 2026-09-01 确定性硬截止的 device_readings 分区过期（PP-02），HMS 当前处于「能上线，但上线后 3 个月内有 4 个定时炸弹」的状态。

决策层结论：V1 可按计划上线，但上线前必须完成 Phase 0 护航清单（≤2 周），否则上线后 MTTR 不可控、客户基于错误假设运营、AI 主动关怀承诺空转。

---

二、综合评分

综合分: 6.8 / 10 (B)

加权规则：后端架构 / 安全合规 / 数据层 权重高（×1.3）；后端业务 / Web / 小程序 / AI 权重中（×1.0）；测试 / DevOps 低分但权重中（×0.9，避免低分区过度拉低但保留短板信号）。

维度评分表

#	维度	分数	一句话定位
1	后端架构	8.0	全系统最扎实：L1/L2/L3 分层严格 + 无环依赖（Kahn 拓扑）+ Outbox 持久化 + 双层多租户；扣分在死信未接线（events.rs:382 零调用）+ module.rs 918 行超限 + 4/8 模块 register_event_handlers 空壳
2	后端业务实现	7.5	CAS 并发控制与事务边界扎实（积分/库存/排班/签到全部 update_many+version）；扣分在 check-then-insert 竞态 + 状态白名单不一致 + VersionMismatch 无重试 + points/alert/stats 无单测
3	数据层	7.3	schema/软删除/UUIDv7/SQL 注入防护优秀，JSONB GIN 在 risk_service 落地；扣分在分区无自愈（PP-02）+ RLS 缺 FORCE（PP-07）+ 连接池 SET 串扰（PP-08）+ pg_trgm 装了没用 + m000109 down 迁移静默失效
4	安全合规	7.3	PII 加密（AES-256-GCM + KEK/DEK + HMAC 盲索引）企业级 + V2 CRITICAL 已修；硬伤：Redis 密码泄露（PP-03）+ token 黑名单非分布式 + 患者姓名明文（PP-12）+ 无数据导出
5	AI 能力	6.5	4 Provider + ReAct + RAG + 引用溯源工程完成度高（17.7k LOC/196 测试）；半成品自动化（AnalysisQueue 死存储 PP-05 + SSE token len/4 计量失真 + 无主动触达）
6	Web 前端	7.2	架构成熟（routeConfig + DEV 校验 + 6 store + token 预刷新 + any 16→1）；僵尸 UI（6 条 navigate 死链 PP-09 + value=0 占位）+ i18n 全缺 + AuthButton 仅 28%
7	小程序端	7.0	并发治理/AES 缓存/BLE 离线缓冲生产级；扣分在告警角标写错 Tab（PP-06）+ 11 页缺 elder-mode（与 wiki 不符）+ setTimeout 未治理 + BLE 基础设施 0 单测
8	DevOps 与可观测性	4.2	备份加密 + Prometheus 指标 + TLS + 安全头已加固；三支柱全残（无 Alertmanager/Grafana/日志聚合/追踪 PP-04）+ 无 CD + 单副本 + 迁移在启动路径
9	测试与质量保障	5.5	1031 测试函数 + 真实 PG 集成测试是基线；金字塔失衡（无覆盖率工具 + CI 不跑 E2E + CI 集成仅覆盖 erp-server + erp-health 29 service 零内联测试 PP-10）

核心张力： 架构层（8.0）与支撑层（DevOps 4.2 / 测试 5.5）落差达 3.8 分——「上层的可靠性没有底层的护栏兜底」，这正是潜伏故障（PP-01/PP-05）能流入仓库的根因，也是历史 24% fix 提交率的系统性成因。

---

三、TOP 5 最紧迫痛点（决策优先级排序）

从 TOP 12 收敛为决策层必须亲自盯的 5 项。每项标注「为什么是决策项而非技术项」。

PP-03 [CRITICAL/立即] 生产 Redis 密码明文进 git 追踪的 wiki（含公网 IP），凭据已实际泄露

wiki/infrastructure.md:35/57 直接写明 redis://:redis_KBCYJk@129.204.154.246:6379，git ls-files 确认被追踪。影响： Redis 承载限流 token bucket、DEK 缓存、微信 session_key、token 黑名单——接管 Redis = 绕过限流暴破 + 解密微信手机号 + 登出失效。这是唯一一个「已在进行中」的合规事件，每拖一天风险递增，医疗 SaaS 凭据泄露触发等保三级 / 个保法合规事件。为什么是决策项： 触碰 CLAUDE.md §3.7「密钥禁止硬编码」铁律，且凭据已暴露给所有仓库访问者（含未来成员/外包），需立即轮换 + git filter-repo 清洗历史，是法律层面的强制义务。

PP-02 [CRITICAL/立即] device_readings 分区硬编码到 2026-08，2026-09-01 起 BLE 数据上传全线中断（确定性硬截止）

migration/m20260426_000073_create_device_readings.rs:42-47 静态建 4 个分区，全仓 grep PARTITION OF/create_partition/pg_partman 无任何未来分区自动创建机制。影响： 这是确定性故障而非概率性 bug——今天 2026-06-25 距硬截止仅 ~10 周，发生在 V1 上线后 3 个月、客户已依赖数据时点。Veepoo M2 管线是患者端核心卖点，中断即产品不可用，且影响信任度与续约。为什么是决策项： 时间窗固定、影响面 100% 患者端、客户感知度极高，必须在上线前或上线后 2 周内补建未来分区。

PP-01 [CRITICAL/立即] 死信重试函数从未接线，业务关键链路「死信即终点」

crates/erp-core/src/events.rs:382 定义了 retry_dead_letters，但 grep 全 crates/ 该符号仅命中定义处，erp-server/src/tasks.rs 未注册调度。影响： 危急值告警 / 积分发放 / 预约提醒 / article 推送 / follow_up 触发积分——任一因瞬时故障（DB 超时、网络抖动）失败即永久滞留 dead_letter_events 表，wiki 还误记为「每小时定时任务已修复」。为什么是决策项： 触碰 CLAUDE.md「每个事件必须有消费者」铁律，文档与代码漂移使团队基于错误假设运营，事故发生时无告警无重试无人工介入流程，MTTR 不可控。

PP-04 [CRITICAL/立即] 可观测性三支柱全残缺，生产处于「盲飞」状态

docker/prometheus/alerts.yml 有 12 条告警规则但 docker/ 下 grep alertmanager/loki/jaeger 0 命中——规则只写入 TSDB 无任何通知出口；docker/grafana/provisioning/ 为空目录；日志仅 stdout 无聚合；30+ 文件含 tracing:: 宏但无 trace_id 贯穿。影响： 配合 PP-01/PP-02/PP-05 等潜伏故障，数据库宕机、5xx 飙升、Redis 不可达等 critical 告警完全无人知晓，事故发生到客户投诉之间团队毫无察觉，跨模块医疗业务无 trace_id 无法还原请求路径。为什么是决策项： 这是 DevOps 4.2 分的根本原因，也是 V1 上线后 6-12 个月最大的运营风险，决定上线后「是睡觉还是救火」。

PP-09 [HIGH/立即] Web 工作台 4 个 Dashboard 共 6 条 navigate 指向不存在路由 + value={0} 占位

AdminDashboard.tsx:51 navigate('/health/follow-ups')、DoctorDashboard 同样指向 /health/lab-reports//health/vital-signs、OperatorDashboard:69 等 3 处 navigate('/health/points')——对照 App.tsx:296-359 路由表均不存在，PrivateRoute 未匹配前缀默认 403；叠加 AdminDashboard.tsx:88 value={healthDataStats ? 0 : 0} 死代码占位。影响： 影响 100% 角色、100% 用户、上线即暴露——管理员/医生/运营/护士首屏点击核心数据卡片全部跳 403，「咨询待回复」「线下活动」恒显示 0。医疗管理后台展示假数据是信任度致命伤。为什么是决策项： 这是当前未提交改动（统计仪表盘重构）引入的新缺陷，必须在合并前修复，否则首日客户演示即翻车。

---

四、6 主题一句话战略

#	主题	一句话战略
T1	稳定性与上线护航	以「确定性故障自愈」为核心（PP-01 死信接线 + PP-02 分区补建 + PP-05 AI 队列通电），配合迁移解耦启动路径 + cron_heartbeat 进就绪门禁 + Alertmanager 三级告警，把「上线即救火」变成「上线即睡觉」。详见 01-stability.md
T2	技术债与架构演进	把五类结构性缺陷（事件契约/模块边界/后台任务/多租户隔离/schema 演进）从「文档约定 + 人肉记忆」升级为「编译期/CI 可校验的类型契约 + 机制层防护」（FORCE RLS + SET LOCAL + TaskRegistry + Schema 注册表），为 2-3 年后微服务化打下「可演进而非可重写」的地基。详见 02-architecture.md
T3	AI 智能化纵深	以「闭合已存在但空转的能力」为第一性原理分三步走——通电（PP-05 AnalysisQueue 消费者）→ 可信（双层记忆 + 引用溯源 + RAG 评估集）→ 可度量（真实 token 成本 + 建议转化率仪表盘），把 HMS 从「医生敲回车才出报告」进化为「感知→推理→行动→复盘」的主动关怀引擎。详见 03-ai-depth.md
T4	多端体验统一	以「行为契约一致」取代「像素级对齐」作为多端度量：同一份设计 Token 单源 + 同一份交互契约 + 同一类语义组件（AlertCard/EmptyState/VitalCard），先根治 PP-09 死链与 PP-06 角标错位（0.5 人日/项速赢），再以 CI 可校验的硬约束让设计系统从审美问题升级为医疗可见性错误防线。详见 04-multidevice-ux.md
T5	医疗合规与数据治理	把 HMS 从「修漏洞式合规」升级为「可举证的持续合规闭环」：以 PII 加密对称（患者姓名加密 PP-12）+ 数据分类分级引擎 + 数据主体权利履行通道（个保法 §45/§47 + 病历 15 年留存）+ 审计哈希链接线（verify_hash_chain 零调用修复）为四大支柱，输出机器可验证的合规证据链。详见 05-compliance.md
T6	商业增长与 SaaS 规模化	缝合现有但分散的半成品（ai_usage 配额引擎 + points 6 表 + EventBus + AnalysisQueue）为三根商业主线——统一计量计费中枢 + 配置化交付蓝图（实施周期 3-5 人天降小时级）+ 主动关怀行为飞轮，在签第 2-5 个客户前确立计量与分层的数据基础，避免陷入「每客户一份定制合同」的项目制泥潭。详见 06-saas-growth.md

---

五、分阶段路线图

Phase 0 — 上线护航（0-2 周，T-0 到 T+2w）

目标：消灭 4 个 CRITICAL 定时炸弹，确保上线即不崩。

• PP-03 Redis 凭据应急轮换 — 立即改 .env.production 注入新密码 + 重建 Redis 数据 + git filter-repo 清洗历史 + 通知仓库访问者 + 审计 Redis 访问日志（1 人日止血，filter-repo 留待正常窗口）
• PP-01 死信重试接线 — erp-server/tasks.rs 注册 start_retry_dead_letters 每小时调度（复用已实现 events.rs:382）+ 补集成测试 + 修正 wiki 误记（2-3 人日，代码已实现 90% 差最后 10% 接线）
• PP-02 分区自愈 — 短期：手动写 m000170 用 generate_series 补建 2026_09~2027_06 分区（2 人日，确定性硬截止解除）；中期：引入 pg_partman 或 start_partition_maintenance 定时任务
• PP-09 工作台死链修复 — 修正 4 个 Dashboard 的 navigate 路径（如 /health/follow-ups → /health/follow-up-tasks）+ 清理 value={0} 占位 + routeConfig 增加 DEV 期 navigate 目标存在性校验（0.5 人日，影响 100% 角色）
• PP-07 RLS 补 FORCE — 单个迁移 ALTER TABLE ... FORCE ROW LEVEL SECURITY 遍历所有 tenant_id 表（沿用 m000088 DO 块模板，1 人日，立即堵死 owner-bypass 路径）
• wiki 真相源全量校正 — 至少修正 PP-01/PP-07(RLS FORCE)/长者模式 83%(实非 100%)/Testcontainers(实本地 PG) 四处误记 + cron_heartbeat 进 /health/ready（速赢，2-3 人日）

Phase 1 — 稳固期（1-3 个月，T+1M 到 T+3M）

目标：建立可观测性与测试门禁，让生产「可见」、回归「可防」。

• PP-04 可观测性三件套 — Alertmanager + 企微/钉钉 webhook 通知路由（先只开 SEV-1 避免狼来了）+ Grafana provisioning（DB/Redis/HTTP/EventBus 4 个 dashboard）+ Loki 日志聚合 + trace_id 贯穿（4-6 人日）
• PP-10 覆盖率门禁 — tarpaulin 接入 CI + service 层 ≥60% 门禁 + erp-health 29 service 补内联单测 + E2E 进 CI + erp-health/tests/ 进 CI（4-6 周）
• PP-06 告警角标修复 — useAlertPolling 改按 pagePath 动态查找 Tab 索引 + 补 elder-mode 11 页缺失 + setTimeout 统一走 useSafeTimeout + BLE 基础设施补单测（5-7 人日）
• PP-08 多租户连接池串扰修复 — 会话变量改 SET LOCAL 事务作用域 或 per-request 连接 + 跨租户并发集成测试（2.5 周，机制层消灭跨租户泄漏窗口）
• PP-05 AI 队列消费者 MVP — claim_next 参数化 + SKIP LOCKED 加固 + 至少实现健康告警→AI 评估→患者推送 1 条完整链路（先 truncate 历史积压避免 Ollama OOM）
• PP-11 迁移解耦启动路径 — 独立 migrate 子命令（从 main.rs:233 剥离）+ 30 分钟回滚能力 + 破坏性 DDL expand/contract 三步走（8-12 人日）

Phase 2 — 深化期（3-6 个月，T+3M 到 T+6M）

目标：从「被动工具」跨越到「主动关怀引擎」，补齐合规通道。

• AI 主动关怀闭环 — 5 条 AnalysisQueue 链路全部接消费者（告警/化验/透析/巡护/高风险）+ 每日扫描主动触达患者 + Orchestrator 上下文压缩 + SSE token 精确计量 + 双层长期记忆（11 周，AI 主题举措 1-2）
• PP-12 合规通道 — 患者数据导出 API（个保法 §45）+ 删除/留存策略引擎（病历 15 年 vs 个保法 §47 法律冲突的 anonymize 中间态）+ 患者姓名加密 + name_hash 盲索引 + DEK 轮换闭环（12-15 人日）
• PP-11 CD pipeline — GitHub Actions build/push/deploy workflow + 蓝绿/灰度发布 + 双副本（+30% 资源成本）+ PG advisory lock 选主（防后台任务多副本重复执行）
• 性能索引治理 — pg_trgm 索引在患者/医生姓名模糊搜索落地 + JSONB GIN 覆盖率从 5% 提到关键查询 80% + 慢查询监控 + 物化视图（Dashboard DB CPU 降 50%+）
• 多端体验统一 — 设计 Token 单源（DTCG JSON 代码生成）+ 跨端语义组件契约（AlertCard/EmptyState/VitalCard）+ Web i18n 框架（187 处硬编码文案）+ AuthButton 28%→70% + Web Vitals 监控

Phase 3 — 规模化（6-12 个月，T+6M 到 T+12M）

目标：多副本 HA + 分布式安全 + SaaS 计量化 + 医疗合规认证就绪。

• 高可用与分布式安全 — 应用多副本 + PG 主从 + Redis 哨兵/集群 + 满足 99.9% SLA + token 黑名单迁 Redis + DB/Redis 连接 TLS + 会话密钥分布式存储 + 密钥轮换自动化
• 统一计量计费中枢（SaaS 主题） — Metering Hub（每 AI 分析/告警/咨询/上传可计量可计费）+ 配置化交付蓝图（Tenant Blueprint + Onboarding，实施周期降小时级）+ 套餐分层 Feature Gating
• 医疗合规认证 — ICD 编码校验 + 药品编码 + 等保三级测评准备 + 个保法合规审计 + 病历留存策略引擎 + 数据分类分级引擎（字段级 ABAC）+ 审计哈希链完整性举证
• AI 能力深化 — ReAct Agent 多轮工具调用稳定化 + Function Calling 双层记忆 + 知识库 V2 + 多模态（化验单图像识别）+ RAG 评估闭环 + Provider FC 集成测试 + 成本真相化
• 生态扩展预留 — 白标皮肤（branding_json + 主题注入）+ 开放 API（API Key 吊销/轮换/审计）+ ISV 生态接入基础

---

六、TOP 7 行动建议（给项目负责人）

可执行、有优先级、有截止时点、有负责人。

1. 【今天】启动 Redis 凭据泄露应急响应（PP-03） — 立即轮换密码 + 改 .env.production 注入 + 重建 Redis 数据 + git filter-repo 清洗历史 + 通知所有仓库访问者 + 审计 Redis 访问日志。这是唯一一个「已在进行中」的合规事件，每拖一天风险递增，属法律层面强制义务。负责人：安全/DevOps。

2. 【本周】修复 3 个 CRITICAL 定时炸弹（PP-01/PP-02/PP-07） — 死信重试接线 + 分区补建迁移 + RLS 补 FORCE。这三项均「代码已实现 90%，差最后 10% 接线」，投入小、收益大，且能立即修正 wiki 真相源漂移。负责人：后端架构。

3. 【本周】冻结统计仪表盘重构分支合并，直到 PP-09 修复 — 当前未提交改动（AdminDashboard/DoctorDashboard/OperatorDashboard/NurseDashboard x4）引入了 6 条死链 navigate + value={0} 占位，合并前必须通过「navigate 目标存在性」DEV 校验。影响 100% 角色首屏，上线即暴露。负责人：前端。

4. 【本月】做一次 wiki 真相源全量校正 + cron_heartbeat 进就绪门禁 — 至少修正 4 处误记（retry_dead_letters/RLS FORCE/长者模式 100%/Testcontainers），并在 CI 增加 doc-vs-code 一致性校验；cron_heartbeat 接入 /health/ready（>2×周期返回 503 触发 nginx 摘流）是所有后续观测/告警的门禁基线，零依赖 1-2 人日。负责人：架构。

5. 【Phase 1】把可观测性三件套（PP-04）列为上线后第一优先 — Alertmanager + Grafana + Loki，这是 DevOps 4.2 分的根本短板，也是 PP-01/PP-02/PP-05 这类潜伏故障能在生产盲飞数月的直接原因。先只开 SEV-1 避免告警风暴。负责人：DevOps。

6. 【Phase 1】建立测试覆盖率门禁（PP-10） — tarpaulin + service 层 ≥60% 门禁 + E2E 进 CI + erp-health/tests/ 进 CI。历史 24% fix 提交率的根因是回归防护薄弱，没有门禁则 6-12 个月演进速度被测试债务持续拖累，AI Agent/Provider/SSE 链路演进尤其危险。负责人：测试。

7. 【Phase 0-1】把 PP-05 AI 队列消费者作为「主动关怀引擎」承诺的兑现起点 — claim_next 参数化（消除 format! 拼 tenant_id 的 SQL 注入铁律违反）+ 至少打通 1 条「健康告警→AI 评估→患者推送」完整链路。客户基于「主动关怀」承诺付费，目前 AnalysisQueue 是死存储，这是续约与口碑的核心，也是从「分析工具」到「主动关怀」产品跨越的根因。负责人：AI。

---

七、主题章节索引

本简报为决策层入口，各主题详细分析（愿景/举措/速赢/风险/工作量估算）见对应章节文件：

主题	文件	核心举措数
T1 稳定性与上线护航	01-stability.md	5 举措 + 3 速赢 + 7 风险
T2 技术债与架构演进	02-architecture.md	5 举措 + 4 速赢 + 6 风险
T3 AI 智能化纵深	03-ai-depth.md	5 举措 + 4 速赢 + 8 风险
T4 多端体验统一	04-multidevice-ux.md	5 举措 + 4 速赢 + 9 风险
T5 医疗合规与数据治理	05-compliance.md	4 举措 + 3 速赢 + 8 风险
T6 商业增长与 SaaS 规模化	06-saas-growth.md	5 举措 + 3 速赢 + 8 风险

---

附录 A：决策张力图谱

架构层（8.0）─────────────────────── 可靠性上层
   │
   ├── 后端架构 8.0   ← 最扎实（无环依赖 + Outbox + 双层多租户）
   ├── 后端业务 7.5       （CAS 并发控制扎实，但 check-then-insert 竞态）
   ├── 数据层   7.3       （schema 优秀，但分区无自愈 + RLS 缺 FORCE）
   └── 安全合规 7.3       （PII 加密企业级，但 Redis 凭据已泄露）
            │
            ↓  落差 3.8 分（上层可靠性无底层护栏兜底）
            │
支撑层（4.2-5.5）─────────────────── 护栏底层
   ├── 测试    5.5   ← 回归防护薄弱（PP-01/PP-05 流入根因，24% fix 提交率）
   └── DevOps  4.2   ← 可观测性盲飞（PP-04 是最大运营风险）

核心张力：上层的可靠性没有底层的护栏兜底。
决策方向：Phase 0 拆炸弹 + Phase 1 补护栏 = 让可靠性「可见、可防、可回滚」。

附录 B：跨维度主题（系统性模式）

本次分析识别出 10 个跨维度系统性主题，是「症状」背后的「模式」，需作为演进期间的持续治理对象：

1. 文档与代码漂移 — wiki 多处「已修复」与代码不符（PP-01/PP-07/长者模式/Testcontainers），真相源失真是 V1 上线后最隐蔽的系统性风险。
2. 「半成品自动化」模式 — retry_dead_letters 未接线（PP-01）+ AnalysisQueue 死存储（PP-05）+ ai.dialysis.kdigo_requested 空 no-op + 32 个 FIRE-AND-FORGET 事件无消费者，系统停留在「被动工具」而非「主动关怀引擎」。
3. 测试金字塔失衡 + 覆盖率工具缺失（PP-10） — 历史根因，是所有潜伏故障流入仓库的共同成因。
4. 「有代码无数据」僵尸 UI（PP-09） — value={0} 占位 + 死链 navigate，医疗后台展示假数据是信任度致命伤。
5. 多租户隔离多层防御可信度不足（PP-07/PP-08） — RLS 缺 FORCE + 连接池 SET 串扰，医疗数据跨租户泄漏是合规红线。
6. 凭据与密钥管理散落 — Redis 密码泄露（PP-03）+ Redis/PG 无 TLS + token 黑名单非分布式 + HS256 对称密钥，阻塞水平扩展。
7. 可观测性近乎为零（PP-04） — DevOps 4.2 分核心短板，决定上线后「是睡觉还是救火」。
8. 生产发布与回滚能力缺失（PP-11） — 无 CD + 无灰度 + 单副本 + 迁移在启动路径，6-12 个月演进速度核心瓶颈。
9. 性能索引黑洞 — pg_trgm 装了没用 + JSONB GIN 覆盖率 ~5%，数据膨胀后成性能黑洞。
10. 硬编码与配置散落 — TabBar 索引（PP-06）+ 分区日期（PP-02）+ value={0}（PP-09），配置未集中治理。

---

本简报基于 9 维度并行分析汇编，所有论断均附证据（文件路径:行号或 grep 结果），已在各主题章节展开。决策层如需深挖单项，直接跳转对应主题章节文件。