# **SSA-Pro 终极架构共识与智能化演进备忘录**

**文档性质：** 架构争论复盘与终极演进路线图

**审查对象：** 团队反馈文档《SSA-Pro 架构审查反馈与智能化路径讨论》

**审查时间：** 2026-02-20

**核心定调：** 🟢 完全认同团队的终极愿景；🔴 对“动态执行生成代码”的安全与稳健性提出最高级别警告；🤝 提出“受限代码生成”作为完美桥梁。

## **一、 架构师的“认错”与全面致敬 (What I Completely Agree With)**

首先，我要向团队致敬。你们指出的核心分歧点——**“高级版的 SPSS 菜单（Tool Calling）” vs “真正的 AI 数据分析师（Code Intelligence）”**，一针见血。

1. **认同“静态参数的局限性”**：  
   你们是对的。临床数据极其肮脏和复杂（需要衍生变量、按条件过滤、合并清洗）。如果只依赖简单的 JSON 参数映射，一旦用户说“帮我把年龄大于 60 岁的人挑出来，再把血压分为高低两组，然后做个生存分析”，基于 Tool Calling 的架构会瞬间瘫痪，因为它无法在参数里表达这种动态的数据操作。  
2. **认同“100 个 R 脚本的真实定位”**：  
   将这 100 个脚本视为\*\*“可学习的范例库（Knowledge Base / Code Templates）”\*\*，而不是死板的 API 工具，这是一个认知上的巨大飞跃。这让系统的天花板从“自动化”提升到了“智能化”。  
3. **认同“三阶段演进策略”**：  
   你们提出的 Phase 1 (工具调用兜底) \-\> Phase 2 (宏脚本执行) \-\> Phase 3 (代码智能) 是极其成熟的务实主义。我们不仅没有分歧，反而达成了高度的战略共识。

## **二、 架构师的“红线”警告 (Where I Strongly Push Back / Warn)**

作为对系统稳定性负责的架构师，针对你们心心念念的 **“Phase 3: Code Intelligence (执行 LLM 动态生成的代码)”**，我必须亮出工程红线。

这是整个业界（包括 OpenAI）都在面临的最难的骨头，切不可低估其危险性。

### **🚨 风险 1：动态代码执行的“核弹级”安全漏洞 (RCE Vulnerability)**

* **团队设想**：LLM 生成 R 代码 \-\> 在沙箱中执行。  
* **残酷现实**：如果在常规的 Docker 容器中直接使用 R 的 eval(parse(text=llm\_code)) 或者将生成的代码写入文件运行，哪怕你做了所谓的文件权限限制，**这本质上依然是一个合法的 RCE (远程代码执行) 后门**。  
* **后果**：大模型极易被“提示词注入（Prompt Injection）”攻击，生成类似于窃取环境变量、发起内网 DDoS 或占用全部 CPU 资源的恶意代码。  
* **架构底线**：在没有引入 **Firecracker 级别的微虚拟机（MicroVM）** 或严格的 **eBPF 系统调用拦截**之前，**绝对禁止**在生产环境中执行 LLM 自由发挥生成的 R 代码。

### **🚨 风险 2：统计学的“幻觉谬误”与合规灾难**

* **团队设想**：LLM 可以根据数据特征动态修改/组合统计代码。  
* **残酷现实**：LLM 在写 Python 的 pandas 时很强，但在写深度的医学统计 R 代码时，非常容易产生“看似合理实则谬误”的幻觉（比如错误地设置了随机效应项，或者用错了极大似然估计方法）。  
* **后果**：系统生成了 P 值，用户信了，发了论文，最后发现统计算法是错的。在医疗领域，这是致命的声誉打击。  
* **架构底线**：涉及 P 值计算的核心统计引擎（如 wilcox.test 的参数配置），必须保留经过人类专家验证的“硬护栏”，绝不能任由大模型自由发挥。

## **三、 破局方案：“受限代码生成”范式 (The Architect's Bridge)**

为了兼顾你们想要的“灵活性（处理复杂数据操作）”和我要的“安全性（护栏与可审计）”，我提出 **“受限代码生成 (Constrained Code Generation)”** 架构。这是连接 Phase 1 和 Phase 3 的完美桥梁。

### **核心思想：把代码切分为“安全区”和“高危区”**

我们将用户的分析诉求分为两截：**【数据加工 (Data Wrangling)】** 和 **【核心检验 (Core Stats)】**。

#### **1\. 安全区：数据加工 (允许大模型自由发挥)**

* **场景**：过滤、重命名、衍生变量（如算 BMI）。  
* **机制**：允许 LLM 基于 dplyr 生成 R 代码（这部分代码就算有幻觉，最多就是报错，不会产生错误的 P 值）。  
* **安全措施**：使用 R 的 AST (抽象语法树) 解析器，在执行前扫描这段生成的代码，**白名单制**仅允许 mutate, filter, select, group\_by 等数据操作函数，发现任何可疑函数直接阻断。

#### **2\. 高危区：核心检验 (大模型仅能“填空”)**

* **场景**：跑 T 检验、画 KM 曲线。  
* **机制**：LLM **不被允许**生成核心检验代码。它必须从你们那 100 个脚本库中，把“专家写好的模板”检索出来，然后把第一步处理好的数据输入进去。

### **💡 “受限代码智能”工作流示例**

1. **用户输入**：“把年龄大于 60 岁的人挑出来，算一下男女的血压差异。”  
2. **LLM 理解与检索**：  
   * 检索到专家模板：ST\_T\_TEST\_IND.R。  
3. **LLM 生成混合计划 (Hybrid Plan)**：  
   {  
     "data\_wrangling\_code": "df\_filtered \<- df %\>% filter(Age \> 60)",  
     "core\_tool": "ST\_T\_TEST\_IND",  
     "core\_params": { "group\_col": "Gender", "val\_col": "BloodPressure" }  
   }

4. **Executor 执行**：  
   * 在沙箱内，先行安全校验并执行 data\_wrangling\_code。  
   * 将清洗后的 df\_filtered 送入经过专家配置、带有强护栏的 ST\_T\_TEST\_IND 工具中执行。

**为什么这个方案好？**

它给了大模型处理复杂现实数据的\*\*“手脚”（数据清洗代码生成）**，但牢牢锁住了大模型的**“嘴巴”（核心统计检验的绝对严谨性）\*\*。

## **四、 针对 MVP 阶段的具体行动建议 (Action Items for NOW)**

既然我们对“三阶段演进”达成了共识，那么在眼下的 MVP 阶段，请务必执行以下微调：

### **1\. 改变 Prompt 的“世界观”**

在构建 Planner 的 Prompt 时，不要对 LLM 说“你是一个从列表里挑工具的接线员”，而是对它说：

"你是一个顶尖的数据科学家。你现在有一个包含 100 个高级统计算法的**专家代码库**。请理解用户意图，从代码库中找出最合适的代码模板，并制定数据传入策略。"

*(即便它现在只能输出 JSON 参数，这种世界观设定也会极大地提高它的推理质量。)*

### **2\. 构建向量库时，保留“代码片段”**

在专家填写 Excel 配置表时，不仅仅存入“工具名”和“适用场景”，把那 100 个 R 脚本的\*\*核心源代码片段（Core Snippet）\*\*也存入向量库。

在 RAG 检索时，把这些代码片段丢给 LLM。这为未来平滑过渡到 Phase 3 埋下伏笔。

### **3\. 先不碰动态代码执行**

MVP 阶段（乃至整个 Phase 2），请严格克制住“让 LLM 动态写代码并执行”的冲动。用我们确定的“混合模式（智能分析 \+ 宏脚本）”打透核心业务流，验证 PMF（产品市场契合度）。

## **五、 最终建议**

作为系统架构师，我必须为您详细拆解为什么在现阶段（MVP及打透核心业务流阶段）必须**严格克制**这种冲动：

### **1\. 安全层面的“达摩克利斯之剑”（RCE 风险）**

让 LLM 动态写代码并执行，本质上是在您的服务器上开了一个 **RCE（远程代码执行）** 的后门。

* 即使我们有那 100 个安全的脚本作为“参考库”，LLM 在修改时，极易受到恶意用户的“提示词注入（Prompt Injection）”攻击。  
* 比如用户在上传的 CSV 数据里或者需求里藏入恶意指令，诱导 LLM 生成 `system("rm -rf /")` 或者窃取服务器环境变量的代码。如果没有极其昂贵和复杂的微虚拟机（MicroVM，如 Firecracker）做硬件级隔离，普通的 Docker 容器一旦被攻破，后果不堪设想。

### **2\. 医学统计的“静默谬误”（幻觉与合规灾难）**

在医疗和临床科研领域，**“跑通了”不等于“算对了”**。

* LLM 生成的代码哪怕语法完全正确，没有报错（Bug-free），它在统计学逻辑上也可能产生“幻觉”。  
* 例如，它在拼接两段代码时，可能忘记了检查数据是否符合正态分布，或者搞错了混合效应模型的随机截距项。  
* 这种错误极其隐蔽（静默谬误），系统会依然输出一个漂亮的 P 值。如果医生拿着这个错误的 P 值去发论文、做临床决策，一旦被查出，将会对您的平台声誉造成毁灭性打击。

### **3\. 运维与排错的“无底洞”（不可复现性）**

* 如果系统是由预设的“宏脚本”和“固定工具”组成的，当用户报 Bug 时，您可以立刻定位：“哦，是 T 检验的脚本第 45 行出错了”，您可以轻松修复。  
* 如果代码是 LLM 每次**动态生成**的，那么每次执行的代码都是“阅后即焚”的孤品。一旦报错，您根本无法复现当时的场景，调试和维护成本将呈现指数级爆炸。

---

### **为什么我坚持用“混合模式（智能分析 \+ 宏脚本）”？**

因为这是一种 **“用大模型的智商，用人类专家的底线”** 的降维打击策略：

1. **大模型只做决策（不动手）**：让 LLM 做它最擅长的事——理解医生意图，阅读列名，从这 100 个工具里**选出最合适的一个或几个**，并把参数（JSON）填好。  
2. **人类专家代码执行（守底线）**：真正跑计算的，是您的 R 工程师和统计专家精心打磨过、经过千百次测试的固定脚本（包括把多个固定脚本串联起来的“宏脚本套餐”）。  
3. **用户体验完美**：在用户看来，他依然是“说了一句话，AI 帮他搞定了一切（哪怕是极度复杂的全流程）”，用户体验并没有打折，但背后的工程安全性提升了一万倍。

**总结来说：** 将那 100 个代码文件作为“可供 LLM 学习和动态修改的范例库”，这是极其超前的愿景，我们可以把它放在 **Phase 3（未来的终极形态）** 去探索。

但在眼下，我们要**打透核心业务流、让产品安全上线并赢得医生信任**，就必须将这 100 个文件视为“不可篡改的执行组件”。大模型可以作为调度员指挥它们，但绝不能赋予大模型在手术台上“随意切改代码”的权力。