# SSA-Pro 智能化演进共识与 MVP 执行计划

**文档版本：** v1.1  
**创建日期：** 2026-02-20  
**最后更新：** 2026-02-20（澄清 Phase 3 靶向修改概念）  
**文档性质：** 团队共识文档 & 执行计划  
**参与讨论：** 产品团队、架构团队、开发团队  

---

## 一、背景与讨论历程

### 1.1 讨论起因

在 SSA-Pro 智能统计分析模块的开发过程中，团队就"智能化"的实现路径产生了深入讨论：

- **愿景设计**：《SSA-Pro 理想状态与智能化愿景设计》提出了"代码智能"范式
- **架构审查**：开发团队对愿景进行了多轮审查，提出了安全性和工程可行性的关切
- **最终共识**：经过充分讨论，团队在愿景与落地之间找到了平衡点

### 1.2 关键讨论文档

| 文档 | 核心观点 |
|------|---------|
| 《SSA-Pro 理想状态与智能化愿景设计》 | 代码智能范式，LLM 动态修改代码 |
| 《架构审查反馈与智能化路径讨论》 | 区分工具调用 vs 代码智能，明确产品定位 |
| 《终极架构共识与智能化演进备忘录》 | 提出"受限代码生成"桥梁方案 |
| 《智能化演进路径评估报告》 | Tool Calling vs Agentic Code Gen 对比 |
| 《智能化演进阶梯》 | Phase 2 是 Phase 3 的基础 |

---

## 二、最终共识

### 2.1 产品定位共识

> **SSA-Pro 的终极目标是 Level 3：颠覆性的智能分析助手**
>
> 让不懂统计的医生，能够完成专业级的统计分析。

### 2.2 技术路径共识

| 共识点 | 说明 |
|--------|------|
| **代码智能是正确的终点** | 100个R脚本作为基础组件，LLM 编排调用，报错时靶向修改 |
| **Tool Calling 是必经的起点** | MVP 阶段必须先把工具调用做到极致 |
| **分阶段实现是务实选择** | 爬行 → 行走 → 奔跑 |
| **医疗领域零容错** | P值必须100%正确，安全红线不可逾越 |

### 2.3 关键澄清：Phase 3 的"靶向修改"

> ⚠️ **重要澄清：Phase 3 不是让 LLM 自由发挥写代码，而是"靶向修改"**

**错误理解 ❌**

| 误解 | 说明 |
|------|------|
| 100个R文件是"学习资料" | LLM 从中学习后自由生成代码 |
| LLM 自由发挥写代码 | 从零开始生成统计代码 |
| 漫无目的地改代码 | 没有明确目标的代码修改 |

**正确理解 ✅**

| 正解 | 说明 |
|------|------|
| 100个R文件是"基础组件" | 经过专家验证的固定工具 |
| LLM 主要工作是"编排" | 串联多个工具形成分析流程 |
| 只在报错时"靶向修改" | 根据错误信息针对性调整代码/参数 |
| 修改范围有限 | 修复错误，而非重写工具 |

**Phase 3 执行流程图：**

```
用户提问
    │
    ▼
LLM 串联 N 个工具（基于 100 个固定工具）
    │
    ▼
依次执行每个工具
    │
    ├── 成功 → 继续执行下一个工具 → 全部完成 → 输出结果
    │
    └── 报错 → 捕获【错误日志 + 用户数据片段】
                    │
                    ▼
              反馈给 LLM 分析错误原因
                    │
                    ▼
              LLM 针对性修改该工具的代码/参数
              （不是重写，是修复）
                    │
                    ▼
              重新执行该工具 → 成功则继续
```

**本质区别：**

| 维度 | 自由生成（错误理解） | 靶向修改（正确理解） |
|------|---------------------|---------------------|
| **触发条件** | 每次都生成新代码 | 只在报错时修改 |
| **修改范围** | 整个代码 | 出错的部分 |
| **代码来源** | LLM 凭空生成 | 基于现有工具代码 |
| **目标** | 生成新功能 | 修复运行错误 |

### 2.4 关键认知修正

| 原有观点 | 修正后观点 |
|---------|-----------|
| MVP 就应该做代码智能 | MVP 必须先把 Tool Calling 打透 |
| 100个R代码让 LLM 自由修改 | 核心统计代码必须锁死，只有数据清洗可放开 |
| 宏工具方案与目标不兼容 | 宏工具是通往代码智能的必经之路 |

### 2.5 安全红线

| 风险 | 说明 | 应对措施 |
|------|------|---------|
| **RCE 漏洞** | 动态执行 LLM 生成的代码存在远程代码执行风险 | Phase 3 前必须有 MicroVM 级别隔离 |
| **统计学幻觉** | LLM 可能生成"看似正确实则谬误"的统计代码 | 核心统计代码必须使用专家验证的固定脚本 |
| **不可复现** | 动态生成的代码每次可能不同 | MVP 阶段使用固定工具保证 100% 可复现 |

---

## 三、三阶段演进路线图

```
┌─────────────────────────────────────────────────────────────────────────┐
│                    SSA-Pro 智能化演进路线图                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  Phase 1/2: 爬行期 (MVP) ─────────────────────────────────────────────  │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  目标：打透 Tool Calling，建立用户信任                          │   │
│  │  机制：100个工具作为固定API，LLM 做智能调度                     │   │
│  │  AI角色：高级调度员 / 全科主任医师                              │   │
│  │  交付：V11 UI + 工具编排 + 论文级输出                           │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                              │                                          │
│                              ▼                                          │
│  Phase 2.5: 行走期 ───────────────────────────────────────────────────  │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  目标：引入受限的代码智能                                       │   │
│  │  机制：                                                          │   │
│  │    - 数据清洗：允许 LLM 生成 dplyr 代码（白名单 AST 检查）      │   │
│  │    - 核心统计：仍然强制使用固定工具                              │   │
│  │  AI角色：数据清洗实习生 + 统计调度员                            │   │
│  │  交付：自愈型数据处理 + 错误反馈机制                            │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                              │                                          │
│                              ▼                                          │
│  Phase 3: 奔跑期 (终极愿景) ──────────────────────────────────────────  │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │  目标：自愈型靶向代码修改                                        │   │
│  │  前提：MicroVM 沙箱、AST 安全检查、充分的黄金数据集             │   │
│  │  机制：                                                          │   │
│  │    - LLM 串联多个工具执行                                        │   │
│  │    - 运行成功 → 直接返回结果                                     │   │
│  │    - 运行报错 → 错误日志+数据反馈给 LLM → 靶向修改代码/参数     │   │
│  │    - 重新执行 → 直到成功                                         │   │
│  │  AI角色：全能数据科学家 / AI 统计学家                           │   │
│  │  关键：不是自由生成代码，而是基于现有工具的靶向修复             │   │
│  │  交付：颠覆性的智能分析体验                                      │   │
│  └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
```

---

## 四、MVP 阶段执行计划

### 4.1 核心目标

> **把 Tool Calling 做到极致，让 LLM 成为最聪明的"全科主任医师"**

- 准确理解医生意图
- 精准选择工具组合
- 正确编排执行顺序
- 输出论文级结果

### 4.2 具体任务清单

#### 任务 1：Planner Prompt 重构 🔴 最高优先级

**目标：** 改变 LLM 的"世界观"，从"接线员"升级为"数据科学家"

**当前 Prompt（接线员思维）：**
```
你是一个工具选择器，从以下列表中选择合适的工具...
```

**目标 Prompt（数据科学家思维）：**
```
你是一位顶尖的临床数据科学家，拥有以下能力：

1. 深刻理解医学研究的统计学需求
2. 精通各类统计方法的适用场景和前提条件
3. 能够诊断数据特征并选择最优分析路径

你现在拥有一个包含 100+ 专家级统计算法的代码库。
每个算法都经过统计学专家的严格验证，确保结果的权威性。

请理解医生的研究意图，诊断数据特征，从代码库中选择最合适的工具组合，
并制定完整的分析计划。你的目标是帮助医生产出可以直接用于 SCI 论文的统计结果。
```

**工时估计：** 0.5 天

---

#### 任务 2：向量库增强（为 Phase 3 埋伏笔）

**目标：** 在 `tools_library.xlsx` 中增加字段，为未来的代码智能铺路

| 新增字段 | 用途 | 示例 |
|---------|------|------|
| `core_code_snippet` | R脚本的核心代码片段 | `t.test(x, y, paired = FALSE)` |
| `typical_error_patterns` | 常见报错及处理方式 | `"non-numeric argument" -> 检查数据类型` |
| `data_requirements` | 数据格式要求 | `需要两列数值型数据` |
| `statistical_assumptions` | 统计前提条件 | `正态分布、方差齐性` |

**工时估计：** 1 天

---

#### 任务 3：执行沙箱强化

**目标：** 建立健壮的错误捕获和日志系统

| 子任务 | 说明 |
|--------|------|
| 错误捕获管道 | R stderr → 结构化 JSON → 可被 LLM 理解 |
| 超时机制 | 单次执行超过 30s 自动终止 |
| 资源限制 | CPU/内存使用上限 |
| 日志记录 | 完整记录每次调用，积累黄金数据集 |

**工时估计：** 2 天

---

#### 任务 4：工具编排能力

**目标：** 实现多工具串联执行

```
用户："帮我做一个完整的组间比较分析"

LLM 生成的执行计划：
─────────────────────────────────────
步骤 1: ST_DATA_CHECK      → 数据校验
步骤 2: ST_MISSING_REPORT  → 缺失值检测
步骤 3: ST_NORMALITY_TEST  → 正态性检验
步骤 4: ST_LEVENE_TEST     → 方差齐性检验
步骤 5: ST_T_TEST_IND      → 独立样本T检验（或根据前提选择非参数）
步骤 6: ST_EFFECT_SIZE     → 效应量计算
步骤 7: ST_CONCLUSION      → 结论生成
```

**工时估计：** 3 天

---

#### 任务 5：前端 SAP 卡片增强

**目标：** 展示完整的工具调用链，增加用户信任

```
┌─────────────────────────────────────────────────────────────┐
│  📋 统计分析计划                                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  研究目的：比较两组患者的疗效差异                           │
│  数据特征：连续变量，两组比较，样本量 n=120                 │
│                                                             │
│  系统将按以下步骤为您完成分析：                             │
│                                                             │
│  ✅ 步骤 1：数据校验 (ST_DATA_CHECK)                        │
│  ✅ 步骤 2：缺失值检测 (ST_MISSING_REPORT)                  │
│  ✅ 步骤 3：正态性检验 (ST_NORMALITY_TEST)                  │
│  ✅ 步骤 4：方差齐性检验 (ST_LEVENE_TEST)                   │
│  ✅ 步骤 5：独立样本T检验 (ST_T_TEST_IND)                   │
│  ✅ 步骤 6：效应量计算 (ST_EFFECT_SIZE)                     │
│  ✅ 步骤 7：结论生成 (ST_CONCLUSION)                        │
│                                                             │
│  预计耗时：约 30 秒                                         │
│                                                             │
│  [确认执行]  [修改计划]                                     │
└─────────────────────────────────────────────────────────────┘
```

**工时估计：** 1 天

---

#### 任务 6：Critic Agent 论文级输出

**目标：** 升级结论生成，符合医学期刊规范

**输出模板：**
```
## 统计方法
采用独立样本 t 检验比较两组患者的 [指标名称] 差异。
统计分析使用 R 4.3.0 完成，P < 0.05 认为差异有统计学意义。

## 结果
[实验组/对照组] 的 [指标名称] 为 [均值 ± 标准差]，
两组间差异 [有/无] 统计学意义 (t = [值], P = [值])。

## 效应量
Cohen's d = [值]，表明效应量为 [小/中/大]。
```

**工时估计：** 1 天

---

### 4.3 任务优先级排序

| 优先级 | 任务 | 工时 | 依赖 |
|--------|------|------|------|
| 🔴 P0 | Planner Prompt 重构 | 0.5 天 | 无 |
| 🔴 P0 | 执行沙箱强化 | 2 天 | 无 |
| 🟡 P1 | 工具编排能力 | 3 天 | 沙箱强化 |
| 🟡 P1 | 向量库增强 | 1 天 | 无 |
| 🟢 P2 | 前端 SAP 卡片增强 | 1 天 | 工具编排 |
| 🟢 P2 | Critic Agent 论文级输出 | 1 天 | 无 |

**总工时估计：** 8.5 天

---

## 五、为 Phase 3 埋下的伏笔

虽然 MVP 阶段使用 Tool Calling 范式，但我们要为未来的"靶向修改"能力做好准备：

| 伏笔 | Phase 3 用途 | MVP 阶段行动 |
|------|-------------|-------------|
| **Prompt 世界观** | LLM 理解自己可以修改代码 | 在 Prompt 中强调代码库概念 |
| **向量库代码片段** | LLM 理解工具代码，便于靶向修改 | 存入核心代码片段 |
| **黄金数据集** | 学习"什么错误如何修复" | 完整记录每次调用（含报错） |
| **错误捕获管道** | 将错误信息结构化反馈给 LLM | 建立结构化错误日志 |
| **前端分步展示** | 展示修复过程，支持人机协同 | UI 已支持步骤级展示 |

### 5.1 错误捕获管道的重要性

Phase 3 的核心能力是"遇错自愈"，这依赖于高质量的错误反馈：

```
工具执行报错
    │
    ▼
错误捕获管道（MVP 阶段建设）
    │
    ├── 捕获 R stderr 原始错误
    │
    ├── 解析为结构化 JSON
    │   {
    │     "error_type": "non-numeric argument",
    │     "line_number": 45,
    │     "problematic_column": "blood_pressure",
    │     "sample_data": ["120", "130", "未知", "125"]
    │   }
    │
    └── 反馈给 LLM 进行靶向修复
```

这个管道在 MVP 阶段就要建设完成，为 Phase 3 打好基础。

---

## 六、成功标准

### MVP 阶段验收标准

| 指标 | 目标 |
|------|------|
| 工具选择准确率 | ≥ 95% |
| 参数填充正确率 | ≥ 98% |
| 执行成功率 | ≥ 90%（标准数据集） |
| 结果可复现性 | 100% |
| 用户满意度 | ≥ 4.0 / 5.0 |

### Phase 2.5 进入条件

| 条件 | 说明 |
|------|------|
| MVP 稳定运行 3 个月 | 验证基础架构稳定性 |
| 积累 1000+ 成功调用记录 | 黄金数据集基础 |
| 错误捕获管道完善 | 支持结构化错误反馈 |
| AST 白名单检查机制就绪 | 数据清洗代码安全保障 |

---

## 七、总结

### 一句话总结

> **代码智能是正确的终点，但 Tool Calling 是必经的起点。**
>
> **先把 100 个工具的调度做到极致，积累黄金数据集，Phase 3 自然水到渠成。**

### 团队共识

1. **愿景一致**：代码智能是终极目标
2. **路径清晰**：爬行 → 行走 → 奔跑
3. **红线明确**：医疗领域零容错，P值必须100%正确
4. **执行务实**：MVP 聚焦 Tool Calling，为未来埋伏笔
5. **概念清晰**：Phase 3 是"靶向修改"，不是"自由生成"

### 关键澄清

> **100 个 R 文件的定位：基础组件，不是学习资料**
>
> - LLM 的主要工作是"编排"这些工具
> - 只有在运行报错时，才进行"靶向修改"
> - 修改的目标是修复错误，而非重写工具

### 行动号召

> **全军出击，拿下 MVP！** 🚀

---

*文档结束*

*本文档为团队共识文档，所有成员应遵循此计划执行。*