3.9 KiB
3.9 KiB
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）：
- 无数据咨询 (The "No-Data" Problem)：
- 如果按照旧的 V1.3 思维，代码可能会写成 if (!file) throw Error("请上传文件")。
- 引入“双引擎”概念后，后端代码会写成 if (!file) return PlannerService.consult()。
- 这就是唯一的区别：允许 Planner 独立工作。
- 专家配置 (The "Config" Problem)：
- V1.3 计划里，工具的 Prompt 可能是写死在代码里的。
- V2.0 强调配置中心，提醒我们把 Prompt 放到数据库里，让专家能改。
4. 最终执行建议：如何使用现有的 5 个文档？
请直接使用之前的 5 个文档进行开发，但在实施时遵循以下 3 条“解耦原则”：
- 后端开发原则：
- 不要把 Planner 的逻辑和 Executor 的逻辑混在一个 Class 里。请创建 src/modules/ssa/planner/ 和 src/modules/ssa/executor/ 两个文件夹。
- 前端开发原则：
- 不要假设用户一定上传了文件。Chat 界面初始化时，允许 file 为空。
- 专家配置原则：
- 按原计划优先使用 Excel 导入配置。这是最快落地的方案，不需要改架构。
一句话总结：
架构不需要大改。V1.3 的开发计划是稳健的。所谓的“架构调整”，只是要求开发人员在写代码时，“手起刀落”把逻辑拆得更干净一点，方便未来复用，仅此而已。