7.9 KiB
7.9 KiB
SSA-Pro 智能工作台 V7 vs V8 深度对比与技术选型报告
分析对象： V7 (单流沉浸式 - 方案A) vs V8 (双屏工作台 - 方案C)
编写目的： 为前端研发团队提供 UI/UX 选型依据与技术实现路径指导。
核心结论： 强烈推荐采用 V8（双屏版） 作为 SSA-Pro 的最终形态，并深度复用 AIA 模块已有的双屏组件资产。
1. 核心观点与倾向性建议
我个人的强烈倾向是：选择 V8（双屏版）。
为什么 V8 更符合用户需求？
- 科研场景的天然属性：医生做统计分析，不是为了“聊天”，而是为了“要结果（图/表/代码）”。V7 会把复杂的统计图表挤在狭窄的聊天气泡里，阅读体验极差；而 V8 给了结果最大的展示空间（右侧 60% 屏幕）。
- 多线程工作能力：在 V8 中，用户可以看着右侧的“分析计划书 (SAP)”，在左侧继续对 AI 提出修改意见（“把正态性检验去掉”）。而在 V7 中，一旦继续聊天，计划书就被顶到上面看不见了。
- 专业信任感：V8 的布局极具“现代桌面软件”的既视感（类似于 RStudio、VS Code 或 Notion），这能极大地提升医生对该系统“严谨性”的信任。
2. 体验与需求契合度对比 (UX Comparison)
| 维度 | V7 (单流沉浸式 - 类似 ChatGPT) | V8 (双屏工作台 - 类似 Claude Artifacts) | 胜出者 |
|---|---|---|---|
| 空间利用率 | 低。大量屏幕两侧留白，宽表必须横向滚动。 | 极高。完美适配 1080p 以上宽屏，图表展示极其舒展。 | 🏆 V8 |
| 上下文记忆 | 差。旧卡片会被新消息顶出屏幕。 | 极佳。右侧工作区状态独立，左侧聊天随便滚，右侧不动。 | 🏆 V8 |
| 代码/文档阅读 | 差。需弹窗或在狭窄气泡内阅读。 | 极佳。右侧面板就是完美的文档/代码阅读器。 | 🏆 V8 |
| 移动端适配 | 极佳。天然的移动端流式布局。 | 差。双屏在手机上无法并排显示。 | 🏆 V7 |
| 学习成本 | 极低（所有人都会用微信）。 | 较低（需理解左右协同逻辑）。 | 🏆 V7 |
结论：除非我们首发主打手机端（这在医学统计场景几乎不可能），否则 PC 端的 V8 完胜。
3. 实现难度与技术路径差异 (Implementation Complexity)
最初评估时，V8 的代价是前端开发难度直线上升。但鉴于本平台 AIA 模块（Protocol Agent）已成功交付类似架构，V8 的实际落地成本已大幅降低。
3.1 状态管理 (State Management) 的差异
- V7 (简单)：状态是局部的、线性的。整个页面就是一个 MessageList[] 数组。每个 AI 回复的卡片组件，只需要接收自己那一条的 props 即可渲染，组件之间不需要通信。
- V8 (复杂但已攻克)：状态是全局的、分离的。左侧聊天框里的点击动作必须触发右侧面板的状态切换（跨面板状态同步）。目前可直接复用平台已有的状态管理最佳实践。
3.2 渲染机制 (Rendering Logic) 的差异
- V7 (流式)：新消息永远 push 到列表最下方，浏览器自动处理滚动。
- V8 (插槽式)：右侧是一个动态插槽（Dynamic Slot / View）。需要维护一个 ActiveArtifact 状态，根据左侧的焦点，不断替换右侧挂载的 React 组件（是渲染 SAPViewer 还是 ResultViewer？）。
4. V8 架构所需的核心技术栈与路线 (Tech Stack Support)
要完美实现 V8，前端团队必须引入以下技术路线：
4.1 全局状态管理库 (必须)
- 推荐：Zustand 或 Redux Toolkit。
- 用途：定义一个全局 Store，包含：
interface WorkspaceStore {
chatHistory: Message[]; // 控制左侧
activePane: 'empty' | 'sap' | 'execution' | 'result'; // 控制右侧视图
currentArtifactData: any; // 右侧正在展示的数据 (JSON)
setPane: (pane, data) => void; // 左侧按钮调用的方法
}
4.2 布局伸缩库 (推荐与复用)
- 推荐：直接复用 AIA 模块已实现的 ResizableSplitPane 组件。
- 用途：允许用户拖拽中间的分割线，自由调整左侧（Chat）和右侧（Workspace）的宽度比例（这是高级桌面工具的标配）。
4.3 渲染优化技术 (关键)
- 推荐：React.memo / useMemo。
- 用途：隔离左右两侧的渲染。当左侧用户正在打字时，绝不能导致右侧包含几千个 DOM 节点的复杂数据表格发生不必要的重渲染（Re-render），否则输入会严重卡顿。
5. 跨模块资产复用分析：AIA Protocol Agent 带来的架构红利
通过审查 00-模块当前状态与开发指南.md，我们发现 Protocol Agent 的 V3.1 MVP 已经完美实现了“聊天+文档”的双屏形态。这为 SSA-Pro 的 V8 方案提供了极其宝贵的基础设施。
5.1 Protocol Agent 布局与 SSA V8 布局的对比度
| 核心特性 | Protocol Agent (AIA) 现有实现 | SSA-Pro (V8) 需求期望 | 一致性评估 |
|---|---|---|---|
| 整体架构 | 左侧 Chat + 右侧 DocumentPanel (A4纸张预览) | 左侧 Chat + 右侧 Artifacts (图表/表格/代码) | 🟢 高度一致。同属 "Left Brain, Right Hand" 模式。 |
| 面板控制 | ResizableSplitPane 动态双面板布局，可拖拽调整 | 需要中间可拖拽的分割线调整视窗大小 | 🟢 完全吻合。可 100% 照搬该组件。 |
| 状态联动 | 5阶段流程状态面板折叠/展开 | 计划/执行/结果等阶段状态栏的切换 | 🟡 逻辑相似。基于 Zustand 的联动机制可复用。 |
| 结果导出 | Word 导出服务集成 + 一键下载 | 代码下载 + 报告导出 | 🟢 直接复用。Python 的 pypandoc 导出服务可直接为 SSA 的 SAP 文档导出服务。 |
5.2 复用策略与哪个“更好”？
结论：它们不是互斥的选项，而是“前辈”与“后继者”的关系。复用 Protocol Agent 的架构来实现 V8 是最优解。
- 底层 Layout 无缝复用：前端团队无需从零开发左右分屏和拖拽逻辑，直接将 Protocol Agent 中经过 V3.1 验证的 ResizableSplitPane 提取到 frontend-v2/src/shared/components/Layout 供全局使用。
- 右侧面板 (Right Pane) 的多态化扩展：
- Protocol Agent 的右侧是 DocumentPanel（渲染 Markdown 和 A4 纸效果）。
- SSA-Pro V8 只需要在此基础上扩展右侧面板的内容类型：除了渲染 SAP 文档，新增 ChartPanel（渲染 Base64 图表）和 TablePanel（渲染三线表）即可。
- 消除技术债务与风险：原本 V8 最大的风险在于“复杂的交互状态管理和窗口重绘性能”，既然 AIA 团队已经在 ~8500 行代码的迭代中解决了滚动条显示、状态联动等 Bug，SSA 团队直接站在巨人的肩膀上，将原本需要 2 周的基建时间压缩至 2 天。
6. 最终开发实施建议
- 确立 V8 为唯一方向：全面转向左右双屏架构，放弃气泡内展示复杂图表的念头。
- 组件下沉与复用 (Day 1 任务)：前端负责同学第一步应与 AIA 团队对齐，将 ResizableSplitPane 等双屏布局基建下沉为系统级 Common 组件。
- 组件解耦开发：
- 同学 A 专门负责开发右侧的 ResultTable、PlotViewer、ExecutionTree 组件（只需接收 JSON props 即可，纯展示组件）。
- 同学 B 复用 AIStreamChat 组件负责左侧的指令解析。
- 最后通过全局 Store 将两人拼装在一起。
总结：V8 难在起步的架构搭建，但由于 Protocol Agent 已经替我们蹚平了道路，我们获得了巨大的“后发优势”。实施 V8 架构不仅风险极低，而且能保证整个 AI Clinical Research 平台（从写方案到做统计）的 UI 体验高度统一、专业感拉满。