feat(ssa): Complete SSA-Pro MVP development plan v1.3

Summary: - Add PRD and architecture design V4 (Brain-Hand model) - Complete 5 development guide documents - Pass 3 rounds of team review (v1.0 -> v1.3) - Add module status guide document - Update system status document Key Features: - Brain-Hand architecture: Node.js + R Docker - Statistical guardrails with auto degradation - HITL workflow: PlanCard -> ExecutionTrace -> ResultCard - Mixed data protocol: inline vs OSS - Reproducible R code delivery MVP Scope: 10 statistical tools Status: Design 100%, ready for development Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-18 21:58:37 +08:00
parent f9ed0c2528
commit 8137e3cde2
19 changed files with 5756 additions and 98 deletions
--- a/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
+++ b/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
@@ -0,0 +1,118 @@
+# **SSA-Pro V1.2 终极审查与发令报告**
+
+**审查对象：** SSA-Pro MVP 开发计划套件 (v1.2)
+
+**审查时间：** 2026-02-18
+
+**审查结论：** 🟢 **通过 (Green Light)** \- 准予启动开发
+
+**风险等级：** 低 (Low)
+
+## **1\. 核心改进验证 (Verification of Fixes)**
+
+针对上一轮（V1.1）指出的致命问题，V1.2 已完成修复：
+
+| 检查项 | 状态 | 证据 |
+| :---- | :---- | :---- |
+| **混合数据协议一致性** | ✅ **已修复** | **R指南**: utils/data\_loader.R 增加了 load\_input\_data 函数，支持 OSS 下载。 **后端指南**: RClientService 实现了 buildDataSource 逻辑，自动判断 \<2MB 和 \>2MB。 |
+| **OSS 内网穿透** | ✅ **已修复** | **R指南**: Dockerfile 引入了 OSS\_ENDPOINT 环境变量，不再硬编码。 |
+| **代码生成可维护性** | ✅ **已修复** | **R指南**: 引入 glue 包和 templates/ 目录，告别了 paste0 硬拼接。 |
+| **大样本护栏误杀** | ✅ **已修复** | **R指南**: guardrails.R 增加了 LARGE\_SAMPLE\_THRESHOLD (5000)，大样本启用抽样检验。 |
+
+**评价：** 团队响应迅速，核心架构隐患已消除。
+
+## **2\. 深度风险挖掘 (Deep Dive Risks)**
+
+虽然逻辑闭环，但在**高并发**和**运维**层面仍有 4 个隐形深坑：
+
+### **2.1 Node.js 的“内存刺客” (Memory Spike)**
+
+* **位置**：DataParserService.ts  
+* **问题**：使用 xlsx 库读取 Excel。该库会将整个文件读入内存。如果用户并发上传 10 个 20MB 的 Excel，Node.js 内存可能瞬间飙升 500MB+，导致 OOM (Out of Memory)。  
+* **建议**：  
+  * **MVP 阶段**：在 SAE 设置 Node.js 内存上限为 2GB+。  
+  * **长期方案**：改用 exceljs 的流式读取 (Stream Reader)，或将解析任务卸载给 Python (Tool C) 处理。
+
+### **2.2 R 服务的“僵尸进程” (Zombie Process)**
+
+* **位置**：R Docker  
+* **问题**：tryCatch 虽然捕获了错误，但如果底层的 C++ 库（如 read.csv 读取畸形文件）导致 Segmentation Fault，R 进程会直接 Crash 退出。SAE 虽然会重启容器，但会导致该请求直接 502 Bad Gateway，且没有明确的错误日志。  
+* **建议**：  
+  * 配置 SAE 的 **Liveness Probe** (存活检查)，确保挂掉的容器能被立刻重启。  
+  * 后端 RClientService 增加对 **HTTP 502/504** 的特殊处理，返回给用户：“服务繁忙或数据异常，请稍后重试”。
+
+### **2.3 开发环境的“网络孤岛”**
+
+* **位置**：本地 Docker  
+* **问题**：开发人员在本地跑 R Docker 时，试图下载阿里云 OSS 的文件。如果公司的 VPN 或网络环境不稳定，OSS 下载会超时，导致本地开发受阻。  
+* **建议**：  
+  * 在 tests/fixtures 中，除了 CSV，**增加一个模拟的 OSS Downloader**（Mock）。  
+  * 在 data\_loader.R 中增加一个 DEV\_MODE 开关，如果是开发环境且 OSS 不通，允许直接读取本地文件模拟下载。
+
+### **2.4 代码交付的“环境依赖”**
+
+* **位置**：用户下载的 .R 代码  
+* **问题**：用户下载代码后在自己的电脑运行，大概率会报错 Error: there is no package called 'ggplot2'。  
+* **建议**：  
+  * 在生成的代码头部，自动注入一段 **“依赖检查与安装脚本”**：  
+    \# 自动安装依赖  
+    required\_packages \<- c("jsonlite", "ggplot2", "car")  
+    new\_packages \<- required\_packages\[\!(required\_packages %in% installed.packages()\[,"Package"\])\]  
+    if(length(new\_packages)) install.packages(new\_packages)
+
+## **3\. "最后一公里" 优化建议**
+
+### **3.1 增加 "Debug 模式"**
+
+在 POST /execute 接口增加一个 debug: true 参数。
+
+* **效果**：R 服务不删除 /tmp 下的中间文件（CSV、Plot），并返回这些文件的 OSS 地址。  
+* **价值**：极大方便 QA 和开发人员排查“为什么这张图画不出来”。
+
+### **3.2 强化 P 值展示 (APA 格式)**
+
+目前的 p\_value\_fmt 很好了，但建议补充 **显著性星号**。
+
+* **建议**：R 返回结果增加 significance\_stars 字段 (\*\*\*, \*\*, \*, ns)，前端直接展示，显得更专业。
+
+### **3.3 预埋 "用户反馈" 埋点**
+
+在结果卡片下方增加 👍 / 👎 按钮。
+
+* **价值**：收集用户对 AI 解释（Critic）的满意度，用于后续微调 Prompt。
+
+### **4.1 R 代码生成的维护成本 (High)**
+
+* **现状：使用 `glue` 模板技术。**  
+* **挑战：你需要维护 两套逻辑 —— 一套是 R Wrapper 里的真实执行逻辑，另一套是 `templates/*.R` 里的字符串模板。**  
+* **风险：如果修改了 Wrapper 的逻辑（比如换了 `leveneTest` 包），但忘了改模板，用户下载的代码就跑不通了。这需要极强的开发纪律。**
+
+### **4.2 护栏机制的调试 (Medium)**
+
+* **挑战：如何设定正态性检验的阈值？**  
+* **细节：对于 N=5000 的数据，Shapiro 检验极易显著（P\<0.05），导致 T 检验被误杀。**  
+* **对策：需要在 `guardrails.R` 中加入基于样本量的动态策略（例如：N \> 3000 时跳过正态性检查，直接使用 T 检验，依据中心极限定理）。**
+
+### **4.3 异步交互的体验优化 (Medium)**
+
+* **挑战：后端虽然是同步 API，但如果计算耗时 30秒，前端用户会焦虑。**  
+* **对策：`ExecutionProgress` 组件虽然做了模拟进度条，但最好能让后端支持 Server-Sent Events (SSE) 推送真实进度（如“正在进行第 500 次置换...”）。MVP 阶段可以暂缓，但 Phase 3 建议补上。**
+
+## **4\. 潜在的其他问题 (Remaining Issues)**
+
+### **5.1 隐私保护的漏网之鱼**
+
+* **问题：`DataParserService` 在提取 Schema 时计算了 Min/Max。**  
+* **场景：如果某列数据是“HIV感染状态”，虽然是分类变量，但如果某一类只有 1 个人，`uniqueValues` 也会暴露隐私。**  
+* **建议：在 `DataParserService` 中增加逻辑：如果某列的唯一值计数 \< 5 且总行数 \> 10，仅返回 "Masked" 或不返回具体值给 LLM。**
+
+### **5.2 错误信息的“黑盒化”**
+
+* **问题：R 报错信息（如 `system is computationally singular`）对用户极其不友好。**  
+* **建议：建立一个 R 错误码字典。Wrapper 捕获错误后，尽量映射为 `E00x` 业务错误码。前端根据错误码显示“多重共线性警告”等人话，而不是原始报错。**
+
+### **5.3 代码运行环境的一致性**
+
+* **问题：用户下载代码在本地跑，本地没有装 R 包怎么办？**  
+* **建议：在下载的代码包里，除了 `.R` 文件，最好附带一个 `install_dependencies.R` 脚本，一键安装所有依赖包。**
+
--- a/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
+++ b/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
@@ -0,0 +1,124 @@
+# **SSA-Pro 方案深度审查与风险评估报告**
+
+**审查对象：** SSA-Pro MVP 开发计划套件 (v1.1)
+
+**包含文档：** MVP计划总览、任务清单、R服务指南、后端指南、前端指南
+
+**审查时间：** 2026-02-18
+
+**总体评级：** **A- (优秀，但存在关键一致性漏洞)**
+
+## **1\. 🚨 关键一致性漏洞 (Critical Inconsistency)**
+
+**这是当前计划中最大的风险点，必须在开工前修复。**
+
+### **漏洞：混合数据传输协议在 R 指南中缺失**
+
+* **架构定义 (V4.1)**：明确定义了“混合数据传输协议”，即 \<1MB 走 Inline JSON，1-20MB 走 OSS 引用。  
+* **后端指南 (Doc 03\)**：正确实现了 data\_source 逻辑，会发送 OSS Key。  
+* **R 服务指南 (Doc 02\)**：❌ **严重缺失**。  
+  * 在 5.2 Wrapper 实现 示例代码中，依然假设 input$data 直接就是数据对象：  
+    \# 错误代码 (Doc 02\)  
+    df \<- tryCatch(as.data.frame(input$data), ...)
+
+  * **后果**：如果后端发来的是 OSS Key，R 服务会直接报错或崩溃，导致 1MB 以上文件无法处理。
+
+### **🛠️ 修正建议**
+
+在 R 服务开发指南中，必须增加一个标准化的 **Data Loader** 工具函数，并在所有 Wrapper 入口处调用：
+
+\# utils/data\_loader.R  
+load\_input\_data \<- function(input\_json) {  
+  \# 兼容旧协议（纯数据）和新协议（data\_source 对象）  
+  if (\!is.null(input\_json$data\_source)) {  
+    source \<- input\_json$data\_source  
+    if (source$type \== "inline") {  
+      return(as.data.frame(source$content))  
+    } else if (source$type \== "oss") {  
+      \# ⬇️ 必须实现 OSS 下载逻辑  
+      return(download\_and\_read\_oss(source$key))  
+    }  
+  }  
+  \# Fallback  
+  return(as.data.frame(input\_json$data))  
+}
+
+## **2\. 架构层面的潜在风险 (Architecture Risks)**
+
+### **2.1 R 服务的“单线程阻塞”风险**
+
+* **现状**：R 语言是单线程的。Plumber 默认也是同步处理。  
+* **场景**：假设 SAE 分配了 1 个实例。用户 A 提交了一个需要跑 10 秒的 Bootstrap 任务。此时用户 B 提交了一个简单的 T 检验。  
+* **后果**：用户 B 的请求会被阻塞 10 秒，甚至超时。HTTP 接口没有排队机制，体验极差。  
+* **建议**：  
+  1. **SAE 层面**：设置较激进的扩容策略（并发数 \> 2 即扩容）。  
+  2. **应用层面**：考虑在 Plumber 中使用 future 包将长任务丢到后台 Promise 中运行（虽然这会增加复杂度），或者简单粗暴地在 Docker 容器中启动多个 R 进程（利用 PM2 管理 Rscript）。**MVP 阶段建议至少部署 2 个 SAE 实例做负载均衡。**
+
+### **2.2 OSS 内网穿透的配置陷阱**
+
+* **现状**：文档强调了使用“VPC 内网 Endpoint”。  
+* **风险**：  
+  * 开发环境（本地 Docker）通常不在 VPC 内，无法访问内网 Endpoint。  
+  * 生产环境（SAE）在 VPC 内，必须访问内网 Endpoint。  
+* **建议**：  
+  * R 代码中的 OSS Endpoint **必须通过环境变量注入**，绝不能硬编码。  
+  * docker-compose.yml (开发) 注入公网 Endpoint。  
+  * SAE 环境变量 (生产) 注入内网 Endpoint。
+
+## **3\. 工程细节的优化建议 (Engineering Improvements)**
+
+### **3.1 代码生成的“可维护性”问题**
+
+* **现状**：在 R 代码中使用 glue 拼接字符串。  
+* **问题**：将大量的 R 代码（如下载逻辑、绘图逻辑）以字符串形式写在 Wrapper 里，不仅难写，而且**没有语法高亮，容易拼错**。  
+* **建议**：  
+  * 采用 **"模板文件分离"** 策略。  
+  * 在 templates/ 目录下存放完整的 .R 文件（如 t\_test\_template.R），在其中用 {{variable}} 占位。  
+  * Wrapper 只负责读取文件并替换变量，不要在代码里写大段字符串。
+
+### **3.2 统计结果的“精度陷阱”**
+
+* **现状**：R 返回的 p\_value 是浮点数。  
+* **问题**：JSON 序列化时，极小的 P 值（如 1.23e-16）在前端 JavaScript 中可能会显示不友好，或者精度丢失。  
+* **建议**：  
+  * R 服务在返回 JSON 前，建议增加一个格式化后的字段，如 p\_value\_fmt: "\< 0.001"，由 R 来决定如何科学计数显示，而不是让前端去猜。
+
+### **3.3 护栏（Guardrails）的“一刀切”风险**
+
+* **现状**：正态性检验失败 \-\> 自动降级。  
+* **问题**：对于大样本（N \> 5000），Shapiro-Wilk 检验过于敏感，哪怕极微小的偏态也会 P \< 0.05。但实际上大样本下 T 检验是鲁棒的（中心极限定理）。  
+* **建议**：  
+  * 优化 guardrails.R 逻辑：当 N \> 500 时，放宽正态性检验的阈值，或者直接跳过 Shapiro 检验，改用 Q-Q 图的峰度/偏度判断（虽然这很难自动化）。  
+  * **MVP 修正**：至少加上 if (N \> 5000\) return PASS 的逻辑，避免大样本被错误降级。
+
+## **4\. 测试数据的缺失 (Missing Test Data)**
+
+文档中提到了“端到端测试”，但缺少\*\*“标准测试数据集 (Golden Datasets)”\*\*。
+
+* **问题**：怎么证明你的 T 检验算得是对的？  
+* **建议**：  
+  * 建立一个 tests/fixtures 目录。  
+  * 准备几组 **“标准答案”**：  
+    1. normal\_data.csv (R 算出来应该是 P=0.042)  
+    2. skewed\_data.csv (应该触发护栏降级)  
+    3. missing\_data.csv (应该报错或自动剔除)  
+  * 在 CI/CD 流程中，自动跑这几组数据，比对结果是否与标准答案一致。
+
+## **5\. 结论与修正计划**
+
+### **✅ 总体评价**
+
+方案架构设计合理，技术栈选型（Node+R+Plumber）成熟。只要修复数据协议的不一致，MVP 成功率极高。
+
+### **📝 需立即执行的修正 (Must-Do)**
+
+1. **修正 Doc 02 (R 开发指南)**：  
+   * \[ \] 增加 utils/data\_loader.R 模块，实现混合协议解析。  
+   * \[ \] 修改 Dockerfile 和 Env 配置，支持 OSS\_ENDPOINT 动态注入。  
+   * \[ \] 修改 Wrapper 模板，使用 load\_input\_data() 替代直接读取。  
+2. **修正 Doc 03 (后端指南)**：  
+   * \[ \] 确认 RClientService 发送给 R 的 Payload 结构与 R 端的解析逻辑完全匹配。  
+3. **补充测试资源**：  
+   * \[ \] 准备 3-5 个涵盖边缘情况（空值、单行、非正态）的标准 CSV 文件。
+
+**建议项目经理（PM）将上述 3 点加入 "Phase 1: 骨架搭建" 的首要任务。**
--- a/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
+++ b/docs/03-业务模块/SSA-智能统计分析/06-开发记录/SSA-Pro
@@ -0,0 +1,119 @@
+# **SSA-Pro 方案深度审查与风险评估报告**
+
+**审查对象：** SSA-Pro V4.1 架构及配套开发计划 (v1.0)
+
+**审查视角：** 系统架构、工程落地、安全性、可维护性
+
+**审查结论：** **总体优秀 (A-)**，架构逻辑清晰，但 R 服务工程化细节存在隐患，需在开发前修正。
+
+## **1\. 架构层面的潜在风险 (Architecture Risks)**
+
+### **1.1 R 服务并发瓶颈 (The Single-Threaded Bottleneck)**
+
+* **现状**：设计采用同步 HTTP (Plumber) 调用 R。  
+* **问题**：R 是**单线程**的。虽然 MVP 限制了数据量，但如果 SAE 实例配置为单进程，当一个 T 检验正在计算（耗时 2秒）时，第二个请求会被阻塞。如果并发量稍大（如 20 人同时点击），请求会排队导致超时。  
+* **建议**：  
+  1. **SAE 弹性策略**：必须配置 SAE 的自动扩容策略（例如 CPU \> 60% 或 并发数 \> 5 时扩容）。  
+  2. **Plumber 配置**：在生产环境，建议使用 future 包或在 Docker 中配置多个 R Worker 进程（利用 pm2 或类似工具管理多个 R 进程端口，前端 Nginx 做负载均衡），而不仅仅依赖 SAE 的容器级扩容。
+
+### **1.2 "网络隔离"与"OSS下载"的矛盾**
+
+* **现状**：  
+  * 架构文档提到：R 容器配置 Egress Deny（禁止外网）。  
+  * 数据协议提到：R 服务需要从 OSS 下载大于 1MB 的文件。  
+* **问题**：如果 OSS 是公网 Endpoint，配置 Egress Deny 后 R 服务将**无法下载数据**，导致系统瘫痪。  
+* **建议**：  
+  * 务必使用阿里云 OSS 的 **VPC 内网 Endpoint**（oss-cn-beijing-internal.aliyuncs.com）。  
+  * 网络策略应配置为：**Deny All Public Internet**，但 **Allow VPC Internal Traffic**。
+
+### **1.3 临时文件堆积 (Storage Leak)**
+
+* **现状**：R 服务会生成临时图片 (tempfile) 和下载 OSS 数据。  
+* **问题**：文档中未提及**清理策略**。长期运行后，/tmp 目录会爆满，导致 Docker 容器崩溃。  
+* **建议**：  
+  * 在 plumber.R 中添加 on.exit(unlink(tmp\_files)) 逻辑。  
+  * 或者在 Docker 启动脚本中添加定时清理任务（Cron）。
+
+## **2\. R 工程化细节审查 (R Engineering Review)**
+
+### **2.1 代码生成方式过于脆弱 (Fragile Code Gen)**
+
+* **现状**：02-R服务开发指南.md 中使用 code\_lines \<- c(..., paste0(...)) 进行字符串拼接。  
+* **问题**：  
+  * 这种硬编码方式非常**难以维护**。一旦需要修改代码模板，很容易拼错引号或括号。  
+  * 生成的代码缺乏缩进和格式化，用户下载后可读性差。  
+* **建议**：  
+  * 引入 **模板引擎**（如 R 的 glue 包或 whisker）。  
+  * 将代码模板存为独立的 .R 模板文件（如 templates/t\_test.R.template），运行时读取并填充参数。  
+  * **强力推荐**：使用 styler 包在生成代码后自动美化格式。
+
+### **2.2 依赖包管理的隐患 (Dependency Hell)**
+
+* **现状**：Dockerfile 中通过 install.packages 安装了一堆包。  
+* **问题**：100 个工具可能依赖 50+ 个包。如果不锁定版本，下个月重新构建镜像时，某个包升级（如 ggplot2 API 变动）可能导致整个服务挂掉。  
+* **建议**：  
+  * 使用 **renv** 进行包管理。生成 renv.lock 文件，确保生产环境安装的包版本与开发环境完全一致。  
+  * 或者使用 RStudio Public Package Manager (P3M) 的**快照日期源**（已在指南中提及，需严格执行）。
+
+### **2.3 错误处理的颗粒度**
+
+* **现状**：Wrapper 使用 tryCatch 捕获所有错误并返回 message。  
+* **问题**：R 的报错信息（如 object 'x' not found）对 LLM 来说可能不够明确，或者包含了系统路径等敏感信息。  
+* **建议**：  
+  * 在 Wrapper 中区分 **"业务错误"**（如列名不存在、数据类型不对）和 **"系统错误"**。  
+  * 对于业务错误，返回特定的 error\_code，方便 Planner 进行针对性的参数自愈。
+
+## **3\. 后端逻辑审查 (Backend Review)**
+
+### **3.1 LLM 生成 JSON 的稳定性**
+
+* **现状**：依赖 Prompt 让 LLM 输出 JSON。  
+* **问题**：DeepSeek 虽然强，但偶尔也会输出 Markdown 包裹的 JSON，或者 JSON 格式错误（如末尾多逗号）。单纯的 JSON.parse 很容易挂。  
+* **建议**：  
+  * 引入 json-repair 库或使用正则表达式提取 JSON 块。  
+  * 或者使用 **Structured Output (JSON Mode)** 如果模型支持。  
+  * 增加一层 **Schema Validation (Zod)**：在收到 LLM 的 Plan 后，先用 Zod 校验参数结构是否符合 tools\_library 中的定义，如果不符合，直接触发重试，不要发给 R。
+
+### **3.2 数据 Schema 提取的隐私风险**
+
+* **现状**：DataParserService 计算数值列的 Min/Max/Mean。  
+* **问题**：对于罕见病或小样本数据（N\<10），极值（Min/Max）可能导致患者身份泄露（如：年龄=102岁）。  
+* **建议**：  
+  * 增加 **隐私阈值**：如果行数 \< 10，不计算 Min/Max，或者进行模糊化处理（如向下取整）。
+
+## **4\. 前端交互审查 (Frontend Review)**
+
+### **4.1 大图与多图渲染**
+
+* **现状**：R 返回 Base64 图片。  
+* **问题**：如果图片很大（高DPI），或者一次返回 10 张图（如相关性矩阵拆解），Base64 字符串会极大，导致 HTTP 响应慢，且前端卡顿。  
+* **建议**：  
+  * 对于复杂图表，R 服务应将图片上传到 OSS，返回 **URL** 而不是 Base64。  
+  * Base64 仅限于 MVP 阶段的小图预览。
+
+### **4.2 长连接与超时**
+
+* **现状**：同步 HTTP，超时 60s。  
+* **问题**：虽然大部分 T 检验很快，但如果是 Bootstrap 或 MCMC，很容易超过 60s。前端 Nginx 或浏览器可能会提前断开连接。  
+* **建议**：  
+  * 前端 axios 请求需显式设置 timeout: 120000 (2分钟)。  
+  * 增加 **"正在计算..."** 的动态文案（如：正在进行第 500 次置换检验...），这需要 R 支持流式日志输出（SSE），但在同步架构下较难实现。MVP 阶段至少要有一个假的进度条动画，缓解焦虑。
+
+## **5\. 补充的任务清单 (Missing Items)**
+
+在当前的开发计划中，缺少以下关键任务，建议补充进 Phase 2 或 3：
+
+1. **🔍 审计日志查看器**：后台管理端（ADMIN）需要一个界面查看 execution\_logs，方便运营人员排查 AI 为什么规划错了。  
+2. **🧹 自动清理任务**：编写 CronJob，定期清理 R 容器的 /tmp 和 OSS 中的临时数据文件（24小时过期）。  
+3. **📊 资源监控**：在运营看板中增加 R 服务的内存/CPU 监控，防止内存泄漏导致的 OOM。  
+4. **📚 帮助文档生成**：不仅是 R 代码生成 JSON，还需要一个脚本将 R 的注释自动生成前端可见的“工具说明书”，展示在 Chat 的侧边栏或悬停提示中。
+
+## **6\. 最终修订建议**
+
+**请研发团队在开工前，重点落实以下 3 点变更：**
+
+1. **R 代码生成**：放弃 paste0 拼接，改用 glue 模板技术。  
+2. **网络配置**：确认 SAE 与 OSS 的内网连通性，配置精确的 ACL。  
+3. **JSON 容错**：后端增加 LLM 输出的 JSON 修复与 Zod 强校验层。
+
+**总评：** 方案非常扎实，以上问题属于“精益求精”的工程细节。解决这些问题后，SSA-Pro 将具备极高的鲁棒性。