HaHafeng
83e395824b
Deliver the RVW V4.0 journal configuration center across backend, frontend, migration, and docs with zh/en editorial baseline support and tenant-level prompt/template overrides. Unify tenant login to /:tenantCode/login and auto-enable RVW module when tenant type is JOURNAL to prevent post-login access gaps. Made-with: Cursor
76 lines
5.5 KiB
Markdown
76 lines
5.5 KiB
Markdown
# **RVW V4.0 期刊配置中心 MVP 开发计划 \- 架构与工程审查报告 (V2.0 战略更新版)**
|
||
|
||
**审查目标：** 评估《RVW V4.0 期刊配置中心 MVP 开发计划 v1.0》的技术可行性、与平台多业态（临床/药企/期刊）演进架构的对齐度，以及潜在的生产环境风险。
|
||
|
||
**审查结论：** 计划整体逻辑清晰，**前端独立拆分模块（FE-1, FE-2）的战略方向极具前瞻性**。但在 **底层业态标识、数据库平滑迁移、防呆设计缺失** 等方面存在 5 个关键问题，需在进入开发前紧急修正。
|
||
|
||
## **🟢 核心架构亮点 (Architecture Gold Standard)**
|
||
|
||
### **1\. 优秀的前端解耦：独立的期刊配置中心**
|
||
|
||
* **计划现状**：任务 FE-1 和 FE-2 提出要“新增左侧一级模块（期刊配置中心）”和“新增列表页”。
|
||
* **审查意见**：**极度赞同！** 随着平台演进，医院、药企、期刊的配置诉求将天差地别。将期刊配置从拥挤的通用 TenantDetailPage 中剥离出来，建立独立的沉浸式工作台，是极其健康的 SaaS 演进路线。
|
||
* **⚠️ 后端防坑提醒**：虽然前端页面拆分了，但**后端绝对不能拆分新建独立的期刊租户表**。接口必须深度复用 GET /api/admin/tenants，通过下文提到的 tenant\_type 参数进行动态过滤。
|
||
|
||
## **🔴 高风险项 (P0级 \- 影响系统稳定与架构基线)**
|
||
|
||
### **2\. 业态类型缺失：如何从底层区分“期刊”与“医院”？**
|
||
|
||
* **计划现状**：将所有配置加在了全局的 tenants 表关联中，但没有明确区分租户种类的字段。
|
||
* **冲突点**：前端要实现独立的“期刊列表页（FE-2）”，后端数据库中现有的临床租户和期刊租户目前混在一起，无法高效过滤。
|
||
* **修正建议**：
|
||
在 platform\_schema.tenants 表中，**必须**新增一个业态分类枚举字段：
|
||
enum TenantType {
|
||
CLINICAL
|
||
PHARMA
|
||
JOURNAL
|
||
}
|
||
// 在 tenants 表中新增：
|
||
tenantType TenantType @default(CLINICAL)
|
||
|
||
只有 tenantType \=== 'JOURNAL' 的租户才会出现在期刊配置中心的列表中。
|
||
|
||
### **3\. 数据库迁移雷区：向已有表强加非空字段导致 Migrate 崩溃**
|
||
|
||
* **计划现状**：计划 4.2 A 节要求向已有的 platform\_schema.tenants 表新增 journal\_language 和 journal\_full\_name，且要求非空。
|
||
* **冲突点**：线上数据库中 tenants 表已经存在历史数据（主站租户、IIT租户等）。如果直接执行 ALTER TABLE ADD COLUMN journal\_language TEXT NOT NULL，Prisma 会因为历史记录缺少该字段的默认值而直接报错中断。
|
||
* **修正建议**：
|
||
在 BE-1 的迁移策略中必须指明平滑过渡方案，建议二选一：
|
||
* **方案 A（推荐）**：在 Schema 中将该字段设为必填并给定默认值 @default("ZH")，或对于非期刊租户允许其具有特定默认值。
|
||
* **方案 B**：设为可选字段 String?，在业务代码（Controller/Zod层）强制要求对于 tenantType \=== JOURNAL 的记录非空拦截。
|
||
|
||
## **🟡 中风险项 (P1级 \- 影响开发体验与业务闭环)**
|
||
|
||
### **4\. 致命防呆设计丢失：Handlebars“测试渲染”预览功能被遗漏**
|
||
|
||
* **计划现状**：任务 FE-3 仅规划了“每个维度 Prompt \+ Handlebars Template 文本框”。
|
||
* **冲突点**：让运营人员在干巴巴的文本框里盲写 Handlebars 代码是灾难性的。一旦写错括号 {{ 导致线上渲染白屏，客诉极大。
|
||
* **修正建议**：
|
||
必须在 FE-3 中加回 **“测试渲染 (Test Render)”** 按钮。要求前端复用 ADMIN 现有的 PromptEditorPage 中的 Mock 预览机制，在右侧提供实时 Markdown 预览面板。（此功能是 All-in-Prompt 架构的风控底线）。
|
||
|
||
### **5\. API 事务一致性风险：跨表更新未强调 Transaction**
|
||
|
||
* **计划现状**：任务 BE-3 设计了 PUT /.../basic-info 和 PUT /.../rvw-config。
|
||
* **冲突点**：在“保存并发布”时，如果前端提交了一个大表单，同时修改了主表 tenants（如：期刊名称）和关联表 tenant\_rvw\_configs（如：方法学 Prompt）。若分开调用接口或在 Service 层不使用事务，极易造成数据不一致。
|
||
* **修正建议**：
|
||
在 BE-3 任务描述中增加硬性约束：**涉及跨 tenants 与 tenant\_rvw\_configs 表的同时写入操作，必须使用 Prisma $transaction 包裹，确保原子性。**
|
||
|
||
## **🟢 低风险项 (P2级 \- 细节补齐)**
|
||
|
||
### **6\. OTHER 语言的枚举映射与回退机制**
|
||
|
||
* **计划现状**：计划 3.2 提到“英文/其他 \-\> en”。
|
||
* **建议补充**：在后端 SkillExecutor 的合并逻辑中（BE-4），明确将这一点写进代码注释：
|
||
// 当 journalLanguage 为 OTHER 时，强制 fallback 到 EN 基线，以通用 SCI 标准兜底
|
||
const langBase \= tenantConfig.editorialBaseStandard ??
|
||
(tenant.journalLanguage \=== 'ZH' ? 'zh' : 'en');
|
||
|
||
## **🚀 最终行动建议 (Next Steps)**
|
||
|
||
请开发团队在实施前对计划文档作如下微调：
|
||
|
||
1. **推进独立前端**：落实 FE-1 和 FE-2，确保期刊业务拥有纯净的管理体验。
|
||
2. **底层数据扩充**：在 Prisma Schema 中补齐 tenant\_type 枚举，并为 journal\_language 设定 @default 兜底（或允许为空）以解决数据迁移报错风险。
|
||
3. **安全防线**：务必补上前端的 **“Handlebars 实时预览”** 按钮和后端的 **$transaction 事务一致性** 约束。
|
||
|
||
完成以上 3 点修正后，该 MVP 计划可立即进入研发阶段。 |