HaHafeng
428a22adf2
Phase 2A: WorkflowPlannerService, WorkflowExecutorService, Python data quality, 6 bug fixes, DescriptiveResultView, multi-step R code/Word export, MVP UI reuse. V11 UI: Gemini-style, multi-task, single-page scroll, Word export. Architecture: Block-based rendering consensus (4 block types). New R tools: chi_square, correlation, descriptive, logistic_binary, mann_whitney, t_test_paired. Docs: dev summary, block-based plan, status updates, task list v2.0. Co-authored-by: Cursor <cursoragent@cursor.com>
427 lines
18 KiB
Markdown
427 lines
18 KiB
Markdown
# 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！** 🚀
|
||
|
||
---
|
||
|
||
*文档结束*
|
||
|
||
*本文档为团队共识文档，所有成员应遵循此计划执行。*
|