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.2 KiB
5.2 KiB
架构委员会独立审查报告：SSA-Pro QPER 智能化主线 (V3.0)
审查对象： 《10-QPER架构开发计划-智能化主线.md》(v3.0)
审查时间： 2026-02-21
总体评级： 🌟 S+ 级 (极度卓越，可作为创业公司 AI Agent 标杆)
核心裁决： 绿灯放行（Green Light）。该计划完美融合了学术界前沿理论与极简工程实践，准予立即进入编码攻坚阶段。
一、 为什么这份计划能拿 S+？(三大高光决策)
- “断舍离”的顶级理解 (延后配置中台)：
在只有 10 个工具的 MVP 阶段，强行开发一套 Excel 导入和专家配置后台是极其浪费资源的。直接在 Node.js 中用 10 个静态 JSON 对象来充当“决策表”，把工时从 2 周压缩到了 2 天，极大地加速了核心引擎的验证。 - Q 层的结构化降维 (防幻觉槽位)：
让 IntentParser 只输出 goal, y, x, design 这四个核心维度，而不是直接输出统计方法。这彻底阻断了 LLM “瞎编统计方法”的可能，把智能体最容易出错的环节卡死了。 - 清晰的 5 大验收场景 (TDD 导向)：
文档最后给出的 5 个核心验收场景（差异、相关、预测、描述、追问）极其精准。这相当于给测试团队（QA）和 Prompt 工程师画好了靶子，开发不再是盲人摸象。
二、 必须预先防范的 3 个工程隐患 (Hidden Engineering Risks)
计划的宏观架构已经无懈可击，但在具体写 Node.js 代码时，请务必规避以下三个暗礁：
🚨 隐患 1：DataProfiler 的“重复运算”与资源浪费
- 设计现状：在 Q 层，IntentParser -> DataProfiler -> Clarifier。
- 物理现实：DataProfiler 需要调用 Python 的 Tool C 去解析 20MB 的 CSV。如果用户在同一个会话里，先问了“比较血压”（触发一次 Profiler），又接着问“那年龄呢？”（又触发一次 Profiler），会导致极大的延迟和服务器 CPU 浪费。
- 架构强制要求 (Caching)：
必须在 Node.js 的 Session 级别实现 DataProfile 缓存。
用户上传文件后，DataProfiler 只执行一次，并将结果（轻量级 Schema JSON）存入 Redis 或内存 Session 中。后续的 Q 层循环直接读取缓存，实现毫秒级响应。
🚨 隐患 2：QPER 的“异步状态机”面条代码风险 (Spaghetti Code)
- 设计现状：系统存在 Clarifier (等用户回复) 和 Reflection (捕获异常重试) 两种中断/循环逻辑。
- 物理现实：如果纯用 if-else 和嵌套 while 循环来写这种带“人机交互中断（HITL）”的工作流，Node.js 代码会迅速劣化为难以维护的面条代码。
- 架构强制要求 (State Machine)：
后端开发必须采用显式状态机 (Explicit State Machine) 来管理会话状态。定义一个标准的 ExecutionStatus 枚举：
PENDING_INTENT -> CLARIFYING -> PLANNING -> EXECUTING -> REFLECTING -> COMPLETED。
当状态为 CLARIFYING 时，立刻中断执行并向前端发送卡片，等待下一次 HTTP 请求恢复状态。
🚨 隐患 3：UI 感知盲区 (The UX Blackhole during Reflection)
- 设计现状：R 层（Reflection）在后台捕获错误、修改参数、重新执行。
- 物理现实：这个过程可能长达 15-20 秒。如果在双屏 V8 UI 上，用户只看到一个 Spinner 在转，他们会以为系统死机了。
- 架构强制要求 (SSE Trace Streaming)：
Node.js 的编排器必须将 Q-P-E-R 的每一次状态跃迁，通过 SSE (Server-Sent Events) 推送给前端。
前端必须能渲染出这样的日志：
[Executor] 正在计算 T 检验...
[Executor] ❌ 失败：变量存在完全共线性。
[Reflection] 🧠 AI 正在反思并修正分析计划...
[Executor] 🔄 重新执行：已剔除共线变量...
这种“展示 AI 工作和纠错过程 (Show your work)”的体验，是智能体产品的核心爽点。
三、 对 Prompt 工程师的战术指导
由于你们取消了配置中台，所有的智能压力都来到了 Prompt 工程师肩上。请遵循以下最佳实践：
- Prompt 文件化隔离：
千万不要把长达百行的 Prompt 用反引号 (``) 直接硬编码在 .ts 业务代码里！请在项目中建立一个 src/prompts/ 文件夹，将 Prompt 写在 .md 文件中（如 intent_parser.md），利用 fs.readFileSync 运行时加载。这方便以后无缝迁移到数据库配置中心。 - Few-Shot 示例至高无上：
在 IntentParser 的 Prompt 中，不要花大量篇幅解释什么是“差异”，直接给它 10 个经典的医生问句和对应的 JSON 答案。在医疗统计领域，10 个高质量的 Few-Shot，胜过 1000 字的逻辑说教。
四、 结语
你们的 V3.0 计划展现了极高的业务理解力和工程克制力。你们没有被“大厂花哨的架构”带偏，而是用最务实的手段构建了最核心的智能壁垒。
请带着这份审查报告召开项目启动会（Kick-off Meeting）。
让前端准备对接 SSE 状态流，让后端搭好状态机框架，让 R 工程师专注跑通工具。SSA-Pro 的第一场硬仗，可以开始了！