# **架构委员会独立审查报告：QPER 智能化主线开发计划**

**审查对象：** 《10-QPER架构开发计划-智能化主线.md》

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

**总体评级：** 🌟 **S级 (战略与战术高度统一)**

**核心裁决：** 完全同意将此文档作为 MVP 的绝对主线。该架构已达到当前医疗 AI Agent 的工业界最佳实践水平。

## **一、 值得全团队起立鼓掌的 3 大亮点 (What You Did Exceptionally Well)**

### **1\. 极其克制的 MVP 范围管理 (The Power of 7\)**

放弃 100 个工具，死磕 7 个最核心的工具（描述、T检验、秩和、卡方、相关、线回、Logistic）。

**架构师点评：** 这是最英明的决定。这 7 个工具覆盖了 80% 的临床医学基础论文需求。如果 QPER 架构连这 7 个都跑不顺，跑 100 个只会是灾难。

### **2\. P层（规划层）的“规则先行”策略 (Rule-First Strategy)**

在 Planner 中设计了 规则匹配 (决策表) \-\> LLM 兜底 的机制。

**架构师点评：** 这是对抗大模型“幻觉”的杀手锏。医学统计是有硬性定理的（比如：Y是二分类，就必须用 Logistic 回归，容不得 AI 自由发挥）。用硬编码的决策表管住核心逻辑，用 LLM 处理模糊边缘，完美平衡了“严谨”与“智能”。

### **3\. Q层（理解层）引入 Tool C (DataProfiler)**

**架构师点评：** 将原本纯后端的意图识别，与真实的物理数据探测（Python Tool C）结合。这意味着 AI 不再是“盲人摸象”，它在写计划前，就已经知道了数据的缺失率、极值和真实分布。

## **二、 必须警惕的 3 个工程暗礁 (Critical Issues to Address)**

虽然架构图很完美，但在写代码时，以下三个地方极容易导致系统崩溃或用户体验翻车：

### **🚨 暗礁 1：Q层到 P层的“Token 爆炸” (The Context Window Trap)**

* **计划现状**：Query 层输出 dataProfile，并传给 Planner。  
* **致命隐患**：如果用户的 CSV 有 100 列，Tool C 跑出来的 dataProfile JSON 可能会长达 50KB。如果把这 100 列的详细信息（均值、方差、频数分布）全部塞进 Planner (DeepSeek) 的 System Prompt 里，不仅会导致响应极慢，还会让 LLM 发生“注意力涣散（Lost in the middle）”。  
* **修正建议**：  
  在 DataProfiler 和 Planner 之间加一个 **“按需截取 (Lazy Fetch / Pruning)”** 逻辑。  
  * Planner 只需要看 Schema（列名、数据类型）。  
  * 只有当 IntentParser 明确识别出用户想分析 Age 和 BP\_Change 时，后端才从完整的 dataProfile 中提取这**两列**的详细统计特征，喂给 Planner。

### **🚨 暗礁 2：R层（反思层）的“无限死循环” (The Infinite Loop of Doom)**

* **计划现状**：遇到 R 报错 \-\> AutoFixer 修改参数 \-\> 重新 Execute。  
* **致命隐患**：如果报错是因为“奇异矩阵（Singular Matrix，多重共线性导致）”，LLM 可能会盲目地反复调整 conf.level 或换个无关紧要的参数重试，导致系统在后台疯狂请求 API，最后超时。  
* **修正建议**：  
  必须在 Node.js 的 orchestrator 中建立**严格的状态机与短路机制**：  
  1. 强制设定 MAX\_RETRIES \= 2。  
  2. 如果 R 返回的错误包含 system is computationally singular 或 not enough observations，**直接阻断**，跳过 AutoFixer，直接交由 Critic 生成一封“诊断失败报告”给用户（如：“您的数据存在严重共线性，建议删除X变量”）。

### **🚨 暗礁 3：Clarifier (澄清器) 的“傻瓜式连问”体验**

* **计划现状**：信心度 \<0.7 时，追问澄清。  
* **致命隐患**：如果用户输入“帮我看看”，AI 问“你的目标是？”；用户回“看血压”，AI 又问“你想用什么方法？”…… 这种填表式的追问会让医生崩溃。  
* **修正建议**：  
  Clarifier 必须是 **“带选项的封闭式提问”**，而不是开放式聊天。  
  * **错误示范**：“请问您想分析哪两列？”  
  * **正确示范**（配合前端 UI）：“我发现数据包含\[年龄\]和\[血压\]，您是想做：👉\[差异比较\] 👉\[相关性分析\]？”（前端渲染为可点击的快捷 Tag）。

## **三、 架构师对开发顺序的微调建议 (Roadmap Tweaks)**

你们的 3 个 Phase 划分很合理，但我建议在内部执行时，微调一下测试策略：

### **🛠️ 建议：采用“硬编码探路法 (Hardcoded Tracer Bullet)”**

在 **Phase 1** 开发 Q 和 P 时，**千万不要等前端界面和真实的 R 服务！**

后端开发人员应该写一个简单的 test.js 脚本：

// 模拟前端传入  
const userQuery \= "看看吃药对血压的影响";  
const mockDataProfile \= { columns: { "Drug": "categorical", "BP": "numeric" } };

// 测 Q 层  
const parsed \= await IntentParser.run(userQuery, mockDataProfile);  
console.log(parsed); // 应该输出: { goal: "difference", Y: "BP", X: "Drug" }

// 测 P 层  
const plan \= await Planner.run(parsed);  
console.log(plan); // 应该命中决策表，输出: ST\_T\_TEST\_IND

**为什么这样做？** 只要后端用纯 JSON 把 Q 和 P 串通了，你们的智能化就成功了 80%。剩下的 R 执行和 UI 渲染只是体力活。

## **四、 最终结论**

这是一份可以**直接拿去向管理层汇报、向投资人路演**的技术蓝图。

QPER 不仅仅是一个架构，它是 AI Data Scientist 的标准灵魂。

请团队立刻以此文档为唯一灯塔，废弃之前所有零散的 MVP 规划，**全力冲刺 QPER 第一版！** 🚀