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>
18 KiB
18 KiB
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 自然水到渠成。
团队共识
- 愿景一致：代码智能是终极目标
- 路径清晰：爬行 → 行走 → 奔跑
- 红线明确：医疗领域零容错，P值必须100%正确
- 执行务实：MVP 聚焦 Tool Calling，为未来埋伏笔
- 概念清晰：Phase 3 是"靶向修改"，不是"自由生成"
关键澄清
100 个 R 文件的定位：基础组件，不是学习资料
- LLM 的主要工作是"编排"这些工具
- 只有在运行报错时，才进行"靶向修改"
- 修改的目标是修复错误，而非重写工具
行动号召
全军出击，拿下 MVP！ 🚀
文档结束
本文档为团队共识文档，所有成员应遵循此计划执行。