HaHafeng
371e1c069c
Implement the full QPER intelligent analysis pipeline: - Phase E+: Block-based standardization for all 7 R tools, DynamicReport renderer, Word export enhancement - Phase Q: LLM intent parsing with dynamic Zod validation against real column names, ClarificationCard component, DataProfile is_id_like tagging - Phase P: ConfigLoader with Zod schema validation and hot-reload API, DecisionTableService (4-dimension matching), FlowTemplateService with EPV protection, PlannedTrace audit output - Phase R: ReflectionService with statistical slot injection, sensitivity analysis conflict rules, ConclusionReport with section reveal animation, conclusion caching API, graceful R error classification End-to-end test: 40/40 passed across two complete analysis scenarios. Co-authored-by: Cursor <cursoragent@cursor.com>
5.9 KiB
架构审查报告：Phase 2A 智能化核心开发计划
审查对象： 《07-Phase2A-智能化核心开发计划.md》
审查时间： 2026-02-20
审查结论： 🌟 极度卓越 (S级计划)。战略聚焦精准，架构切分合理。准予作为下阶段最高优先级执行，但需注意防范三大工程暗礁。
一、 架构师的高度赞同 (What You Did Exceptionally Well)
1. 极其明智的“断舍离” (Postponing the Config Center)
把“配置中台”和“100个工具的量产”延后，是整个计划最亮眼的一笔。
在核心编排逻辑（Orchestration）跑通之前，去开发配置中台的 UI 是纯粹的浪费。在 Phase 2A 阶段，“配置即代码 (Configuration as Code)” 是最佳实践。直接用 TypeScript/JSON 文件来硬编码这 7 个工具的配置，速度最快，修改成本最低。
2. 五大组件的精妙解耦 (The 5-Component Agentic Pipeline)
你们将原本耦合的 Planner 拆分成了 Data Profiler -> Intent Parser -> Tool Router -> Plan Generator -> Result Synthesizer。
这是教科书级别的 大模型工作流 (LLM Workflow) 设计！大模型在处理单一、确定性任务时幻觉极低。将一个庞大的 Prompt 拆分成 5 个职能单一的微型 Prompt，是保证系统每次都能输出稳定 SAP 计划的唯一解。
3. 完美的“7 剑客”工具选型 (The Golden 7 Tools)
选出的 7 个工具（基线表、正态、T检验、秩和、卡方、相关、线回）不是随便挑的，它们恰好构成了一个完整的**“临床基线分析 + 单因素推断”**的业务闭环。如果能把这 7 个串联好，已经能解决医学研究生 60% 的毕业论文统计需求。
二、 工程暗礁与避坑预警 (Critical Warnings & Gotchas)
计划虽好，但在具体写代码时，这 5 大组件和多工具串联极容易在以下三个地方“翻车”：
🚨 暗礁 1：Result Synthesizer 的“上下文爆炸” (Context Window Blowup)
- 计划描述：将多个工具的执行结果收集起来，交给 Result Synthesizer (LLM) 生成综合结论。
- 潜在灾难：R 语言跑出来的原始 JSON 可能极大。比如做线性回归，如果把几百个残差值（Residuals）或者巨大的离群值数组都打包成 JSON 发给大模型，会导致 LLM Token 超载，响应极慢甚至直接报错。
- 架构强制要求：
在封装这 7 个 R 工具时，必须严格限制 R 脚本的输出规模。R 脚本返回的 JSON 只能包含：P值、统计量 (t/F/chi-sq)、置信区间、核心系数 和 前端渲染图表所需的精简坐标点。绝对禁止返回包含原始全量数据的长数组。
🚨 暗礁 2：Data Profiler 的“Node.js 内存刺客” (The Node.js OOM Trap)
- 计划描述：Data Profiler 需要提取数据特征（如均值、缺失率）。
- 潜在灾难：如果由后端的 Node.js 去遍历解析 50MB 的 CSV 来算均值和缺失率，Node.js 极易发生 OOM（内存溢出）导致容器崩溃。
- 架构强制要求 (已修正为 Python 方案)：
不要在 Node.js 里做重度数据探测！强烈建议复用团队现有的“工具C (Python 智能数据清洗模块)” 来充当 Data Profiler 的物理执行层。
工作流应该是：用户上传数据 -> Node.js 调起 Tool C 的 Python 微服务 执行高并发的数据探测 -> 快速返回各列的数据类型、缺失率、枚举值分类 -> 将这个轻量级的 Schema JSON 喂给 LLM 规划师。
(注：Tool C 的 Pandas/Polars 在处理数十 MB CSV 的 I/O 和基础统计上，性能远超 R，且完全复用了团队已有的异步架构与性能优化资产，完美实现了“Python 主内搞数据，R 主外做统计”的分工。)
🚨 暗礁 3：多工具编排中的“半路崩盘” (Partial Failure Handling)
- 计划描述：Plan Generator 制定好顺序（如：正态检验 -> T检验），然后依次执行。
- 潜在灾难：如果第一步“基线表”跑成功了，第二步“T检验”因为某个极端数据报错了，整个流程是全部崩溃，还是能保留基线表的结果？
- 架构强制要求：
在设计流程执行器（Executor）时，必须采用 “容错管道 (Fault-Tolerant Pipeline)”。
任何一个工具报错，不应该导致整个 Workspace 崩溃。系统应该能在右侧 UI 渲染出：
✅ 基线表 (执行成功, 点击查看)
❌ T检验 (执行失败: 方差为0, 点击查看原因)
让用户依然能拿到部分成果，这才是顶级商业软件的体验。
三、 对 Phase 2A 代码落地的一点补充建议
为了配合 V11 双屏前端原型的“魔法效果”，建议在后端的串联逻辑中加入 “Server-Sent Events (SSE) 状态推送”：
当后端正在顺序执行这 7 个工具时，不要让前端傻等 10 秒钟。后端执行完一个工具，就通过 SSE 往前端推一个状态：
- {"status": "running", "step": "ST_TABLE1", "msg": "正在绘制基线特征表..."}
- {"status": "running", "step": "ST_NORMALITY", "msg": "正在执行 Shapiro-Wilk 正态性检验..."}
- {"status": "completed", "final_report": {...}}
前端接收到这些状态后，就能在 V11 原型的 ExecutionViewer（那个黑色的终端日志框）里一行行打出逼真的执行日志，这不仅安抚了用户的等待焦虑，更把系统的“专业AI感”直接拉满。
四、 总结
你们的 Phase 2A 计划是一份直指问题核心的“作战地图”。
去掉了“配表”的枯燥，直面“AI 编排”的挑战，并且聪明地联动了已有的 Python 资产。只要在数据探测和结果回传上做好数据量的裁剪（卡死 Token 上限），这个 Phase 2A 交付后，SSA-Pro 将真正在技术上具备叫板主流数据分析 AI Agent 的底气。
同意按此计划全面打响 Phase 2A 战役！祝团队旗开得胜！