Files

HaHafeng 371e1c069c feat(ssa): Complete QPER architecture - Query, Planner, Execute, Reflection layers

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>

2026-02-21 18:15:53 +08:00

6.0 KiB

Raw Blame History

架构委员会独立审查报告：SSA-Pro 智能化愿景与落地策略

审查对象： 《SSA-Pro 理想状态与智能化愿景设计》、《愿景与开发计划对比分析》

审查时间： 2026-02-20

核心裁决： 🟢 愿景极度认可，🔴 反对开发计划的推翻重来。建议采用“宏工具（Macro-Tool）降维打击”策略。

1. 核心审查结论 (Executive Summary)

愿景评估 (Vision)：提出“医生要的是完整流程，而不是单个统计工具”的洞察极其精准，这是 SSA-Pro 未来能在市场上降维打击竞品的核心壁垒。
差距评估 (Gap)：文档中指出的现有 MVP 计划与理想状态的差距是客观存在的（单节点执行 vs 多节点编排）。
落地路径评估 (Execution) - 🚨 警告：文档建议“新增 Phase 1.5，耗时 12-18 天开发流程执行引擎”，我作为架构师坚决反对。在底层原子工具（T检验、卡方等）尚未经受生产环境大规模数据考验时，去构建一个复杂的 DAG（有向无环图）流程编排引擎，会导致项目陷入无底洞，MVP 交付将遥遥无期。

2. 为什么坚决反对现在做“流程执行引擎”？(架构风险剖析)

团队文档中低估了“多方法流程编排 (Workflow Orchestration)”的技术复杂度：

状态爆炸与数据流转 (Data Pipeline)：
- 如果 Node.js 作为流程引擎，执行 A(数据清洗) -> B(特征筛选) -> C(T检验)。这意味着 R 容器执行完 A 后，要将几百 MB 的中间态数据回传给 Node/OSS，Node 再传给步骤 B的 R 容器。这会带来巨大的 IO 延迟和序列化灾难。
错误处理灾难 (Error Recovery)：
- 流程走到第 4 步报错了，怎么回滚？UI 上怎么展示？用户修改参数后，是从第 4 步断点续传，还是从头重跑？
前端 UI 极度复杂化：
- 我们刚刚通过 V11 稳定了双屏 UI，如果引入流程节点，右侧面板需要变成类似 ComfyUI 或 Coze 的节点连线界面，工作量是按“月”计算的。

3. 破局之道：以“大工具 (Macro-Tool)”降维打击

我们既要满足用户的终极愿景（一键生成论文级完整报告），又要保住现有的工程架构（单方法执行）。

解决思路：将“流程编排的复杂度”从 Node.js / 前端下沉到 R 代码内部。

不要在 Node.js 中编排流程，而是定义一批 “复合型宏工具 (Macro-Tools)”。

举个例子对比：

愿景文档的思路（沉重的引擎）：
Node.js 引擎调度 -> 调用基础基线表工具 -> 等待 -> 调用缺失值填补工具 -> 等待 -> 调用T检验工具 -> 等待 -> 调用多因素回归工具 -> 合并输出。
架构师建议的思路（轻量级宏工具）：
1. 在配置中台中，除了配置基础的“T检验 (ST_T_TEST)”，新增一个超级工具叫 “RCT 临床试验全流程标准分析 (ST_MACRO_RCT_PIPELINE)”。
2. 这个超级工具对应一段长达 200 行的 R 脚本 (rct_pipeline.R)。
3. 这段 R 脚本在一次容器运行中，顺序执行：画 Table 1 -> 数据清洗 -> 分组比较 -> 敏感性分析 -> 统一输出为 Markdown 或一个巨大的 JSON。
4. Node.js 和前端完全不需要改架构，在它们眼里，这依然只是一次普通的“工具调用”。

这种方案的巨大红利：

维度	构建通用流程引擎 (不推荐)	构建 R 宏工具脚本 (推荐)
开发工时	3 - 4 周 (前后端全改)	2 - 3 天 (写几段 R 聚合脚本即可)
性能损耗	极高 (不断的容器启停和 IO)	极低 (一次 R 进程内全内存计算)
智能理解	LLM 需要输出复杂的 DAG JSON	LLM 只需要路由到该“宏工具”
用户体验	看到复杂的节点执行	点击执行后，一键输出终极报告 (符合预期)

4. 对现有开发计划的微调建议 (Action Items)

结论：不要推翻原有的《00-MVP开发计划总览.md》，原计划完全有效，只需做以下三点微调：

调整 1：扩展“配置中台”的概念 (Phase 1)

在开发基础统计工具（T检验、卡方等）的同时，由数据分析师/R工程师编写 3-4 个**“场景化宏脚本”**。例如：

ST_SCENARIO_SURVIVAL (生存分析标准全流程：KM曲线 + Log-rank + 单因素Cox + 多因素Cox)
ST_SCENARIO_CLINICAL_TRIAL (临床试验疗效评估标准流程：Table1 + 主效应检验 + 亚组森林图)

调整 2：增强 Planner 智能体的路由能力 (Phase 2)

修改 Planner (大模型) 的 System Prompt：

"当用户的问题非常具体且单一（如：比较这两列的均值），请推荐基础统计工具（如 ST_T_TEST）。当用户的问题是一个宏大的研究目标（如：看看新药有没有效、帮我分析这批高血压数据），请直接推荐场景化宏工具（如 ST_SCENARIO_CLINICAL_TRIAL）。"

调整 3：UI 展示层的包容性 (与 V11 完美契合)

V11 的双屏 UI 已经完美支持这种宏大结果的展示。宏工具执行完毕后，返回的是一个包含了多个表格和多张图表的复杂 JSON。右侧工作区利用 ResultViewer 顺序渲染这些组件即可，这正是双屏设计大显身手的地方。

5. 架构师致团队的总结寄语

向提出智能化愿景的团队成员致敬！你们看到了星辰大海。

但软件工程的艺术在于**“用最简单的结构解决最复杂的问题”。我们通过把复杂的流程固化为 R 脚本模板（宏工具）**，成功地避免了造一个沉重的 Node.js 工作流引擎的陷阱。

无需推翻重来！请团队按照原定 MVP 计划继续冲刺，只需在 R 代码库中增加几个“全家桶套餐”级别的脚本，我们就能在 MVP 阶段交付你们渴望的“智能化愿景”！

6.0 KiB Raw Blame History Unescape Escape