Files
AIclinicalresearch/docs/03-业务模块/SSA-智能统计分析/00-系统设计/SSA-Pro_架构一致性与调整分析.md

57 lines
3.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# **SSA-Pro 架构一致性与调整分析报告**
**分析对象:** PRD V2.0 "智能分析模式" vs. V1.3 开发计划套件 (5文档)
**分析结论:** **核心逻辑完全一致,无需重构,仅需解耦接口。**
## **1\. 核心结论:我们绕弯路了吗?**
**没有。我们只是把“隐性”的逻辑“显性化”了。**
* **V1.3 计划(原计划)**:设计了一个“串联”系统。
* 逻辑:用户上传 \-\> 系统规划(Planner) \-\> 系统执行(Executor) \-\> 结果
* **现状**:这正是 PRD V2.0 中的 **“流程一:智能分析模式”**。这是用户 90% 的使用场景。
* **V2.0 架构(新概念)**:提出了“双引擎”概念。
* 逻辑:把上述串联系统中的 规划 和 执行 两个步骤,定义为两个可以**独立调用**的模块。
**结论:**
**V1.3 的开发计划代码、Docker、数据库依然是 100% 可用的基础。** 我们不需要推翻它,只需要在写代码时,注意把 Planner 和 Executor 的代码写在不同的 Service 文件里,不要写死在一个大函数里即可。
## **2\. 详细对比与复用策略**
我们来看之前的 5 个文档,看看哪些可以直接用,哪些需要微调。
| 原文档 | V1.3 内容 | V2.0 架构要求 | 调整建议 |
| :---- | :---- | :---- | :---- |
| **02-R服务开发指南** | 定义了 R Docker、Wrapper、护栏、混合数据协议。 | 需要一个独立的计算引擎。 | **无需调整 (0%)**。 R 服务本身就是 Executor它生来就是被调用的不关心是谁调用的。 |
| **03-后端开发指南** | 定义了 RClientService (执行) 和 PlannerService (规划)。 | 需要 Planner 和 Executor 解耦。 | **微调接口 (10%)**。 原计划中可能有一个 runAnalysis() 函数把两步连起来写了。**调整为:** 写两个函数 plan() 和 execute(),然后在 Controller 层串联它们。 |
| **04-前端开发指南** | 定义了 PlanCard, ExecutionTree, ResultCard。 | 需要支持“咨询模式”和“执行模式”。 | **微调路由 (10%)**。 增加一个 /consult 页面(复用 Chat 组件。PlanCard 增加一个“仅下载方案”的按钮。 |
| **00/01 计划任务** | 定义了开发里程碑。 | 强调 Planner 先行。 | **无需调整**。 原计划也是先做 RAG/Planner再做 Executor。顺序本就一致。 |
## **3\. 为什么“双引擎”概念依然重要?(即使流程没变)**
既然流程一样,为什么还要提“双引擎”?是为了解决 **边界情况Corner Cases**
1. **无数据咨询 (The "No-Data" Problem)**
* 如果按照旧的 V1.3 思维,代码可能会写成 if (\!file) throw Error("请上传文件")。
* 引入“双引擎”概念后,后端代码会写成 if (\!file) return PlannerService.consult()。
* **这就是唯一的区别:允许 Planner 独立工作。**
2. **专家配置 (The "Config" Problem)**
* V1.3 计划里,工具的 Prompt 可能是写死在代码里的。
* V2.0 强调配置中心,提醒我们把 Prompt 放到数据库里,让专家能改。
## **4\. 最终执行建议:如何使用现有的 5 个文档?**
**请直接使用之前的 5 个文档进行开发,但在实施时遵循以下 3 条“解耦原则”:**
1. **后端开发原则**
* 不要把 Planner 的逻辑和 Executor 的逻辑混在一个 Class 里。请创建 src/modules/ssa/planner/ 和 src/modules/ssa/executor/ 两个文件夹。
2. **前端开发原则**
* 不要假设用户一定上传了文件。Chat 界面初始化时,允许 file 为空。
3. **专家配置原则**
* 按原计划优先使用 **Excel** 导入配置。这是最快落地的方案,不需要改架构。
**一句话总结:**
**架构不需要大改。V1.3 的开发计划是稳健的。所谓的“架构调整”,只是要求开发人员在写代码时,“手起刀落”把逻辑拆得更干净一点,方便未来复用,仅此而已。**