feat(core): finalize rvw stability updates and pending module changes

Summary:
- Harden RVW prompt protocol handling and methodology review flow with 20-checkpoint coverage, divide-and-conquer execution, and timeout tuning
- Update RVW frontend methodology report rendering to show real structured outputs and grouped checkpoint sections
- Include pending backend/frontend updates across IIT admin, SSA, extraction forensics, and related integration files
- Sync system and RVW status documentation, deployment checklist, and RVW architecture/plan docs

Validation:
- Verified lint diagnostics for touched RVW backend/frontend files show no new errors
- Kept backup dump files and local test artifacts untracked

Made-with: Cursor

docs/03-业务模块/RVW-稿件审查系统/08-技术架构建议/智能审稿终极稳定架构白皮书.md

@@ -0,0 +1,99 @@
+# **智能审稿系统 \- LLM 输出格式隔离与终极稳定架构白皮书**
+
+**文档目的：** 彻底解决大模型“自然语言排版”与“系统结构化解析”之间的抢占与冲突，提供可作为平台底层规范的长期稳定架构方案。
+
+**适用场景：** RVW 智能审稿、AIA 报告生成、ASL 深度检索总结等一切需要“既要系统存数据，又要给用户看报告”的业务。
+
+## **一、 问题本质：为什么大模型总会“格式崩盘”？**
+
+大模型本质上是一个“词汇接龙”的概率引擎。当我们要求它\*\*“既做评判专家（逻辑分析），又做排版文秘（JSON转义与文本排版）”**时，它面临着严重的**职责过载 (Responsibility Overload)\*\*。
+
+1. **Attention（注意力）稀释**：Prompt 中复杂的业务规则（20条标准）占用了大量的注意力权重，导致模型在生成到后半段时，往往会“忘记”输出合规的格式。  
+2. **JSON 转义灾难**：如果采用“将长文本报告塞入 JSON 字段”的做法，模型需要在生成长文本时，对每一个回车换行（\\n）、双引号（\\"）进行严格的转义。一旦模型在几千字中漏掉一个转义符，前端 JSON.parse() 就会直接崩溃。
+
+## **二、 终极演进方向：大模型的 MVC 架构 (LLM-MVC)**
+
+软件工程中解决耦合的终极方案永远是**分层**。我们需要将大模型的工作流拆分为 **Model（数据层）**、**View（展示层）** 和 **Controller（控制层）**。
+
+* **Model (判官)**：彻底剥离排版任务。LLM **只负责**看文章、找问题、打分。强制输出极致精简的、无大段长文本的 JSON 数据。  
+* **View (文秘)**：负责将精简的 JSON 数据，渲染成带有专家个人风格（1/2/3 排版、温暖/严厉口吻）的自然语言报告。  
+* **Controller (系统)**：负责业务调度、存库、进度条控制。
+
+基于这个核心思想，针对贵司当前的基建现状，有以下三套递进的终极解决方案：
+
+## **三、 三套终极解决方案 (按彻底程度递进)**
+
+### **方案 A：底层原生强约束 (Structured Outputs) —— “从 API 层面锁死”**
+
+不要在 Prompt 里写“请输出 JSON”，这是软约束。
+
+各大主流模型（OpenAI, DeepSeek-V3）均已支持底层的结构化输出能力。
+
+* **架构实现**：  
+  1. 在你们后端的 LLMFactory / StreamingService 中，调用模型时强行传入 response\_format: { type: "json\_schema", json\_schema: {...} }。  
+  2. 这个 Schema 由系统通过 Zod 或纯 JSON Schema 严格定义（必须有哪些字段，字段必须是枚举或数字）。  
+  3. 此时，大模型在底层的 Logits 采样阶段就会被加上 Mask（掩码），**它在物理层面上根本无法输出破坏 JSON 结构的 Token**。  
+* **优点**：100% 解决 JSON 解析错误，改造成本极低。  
+* **缺点**：依然没有解决“专家想自定义报告文本排版”的问题，且如果 JSON 中包含超长文本，依然可能导致 Token 浪费和轻微的截断。
+
+### **方案 B：纯数据 JSON \+ Handlebars 动态模板 —— “零幻觉的完美解”**
+
+💡 强烈推荐！我看你们在 ADMIN Phase 3.5.2 中已经实现了 Handlebars，这是最完美的契合点！
+
+完全剥夺大模型的排版权利，大模型只负责提取“缺陷数据”。专家的排版要求，通过 Handlebars 模板在运营后台配置。
+
+* **工作流**：  
+  1. **大模型推理**：输出极其干燥的数据（仅供系统流转）。  
+     {  
+       "score": 80,  
+       "issues": \[  
+         {"code": "ME-01", "name": "未做共线性检验", "suggestion": "补充 VIF 检验"}  
+       \]  
+     }
+
+  2. **专家后台配置 (View 模板)**：主编在运营管理端，像写 Word 模板一样配置：  
+     \#\#\# 方法学预审报告  
+     您好，本次得分：{{score}} 分。  
+     系统发现了以下 {{issues.length}} 个问题：  
+     {{\#each issues}}  
+     {{@index}}. 【{{this.name}}】：建议您 {{this.suggestion}}。  
+     {{/each}}
+
+  3. **系统渲染**：后端将 LLM 吐出的 JSON 喂给 Handlebars 模板，瞬间生成纯净的 Markdown 报告推给前端。  
+* **优点**：  
+  * **彻底解耦**：专家爱怎么改排版就怎么改，永远不会导致系统报错。  
+  * **极致稳定**：LLM 只需要输出极短的 JSON，速度飞快，绝无转义灾难。  
+  * **复用基建**：完美复用你们已有的 PromptService 和 Handlebars 引擎。  
+* **缺点**：要求主编掌握一点点 {{}} 占位符的写法（运营端可提供可视化插入按钮来降低门槛）。
+
+### **方案 C：双轨 Agent 协同管线 (Pipeline/Map-Reduce) —— “高度拟人化的终局”**
+
+如果期刊主编不仅要求格式，还要求极度灵活的语气（例如：“如果得分低于 60，就在开头严厉批评；如果高于 80，就热情表扬”），这就超出了 Handlebars 静态模板的能力。此时需要引入**双 Agent 协同**（类似你们 SSA 模块的 Plan-and-Execute 架构）。
+
+* **工作流**：  
+  1. **Agent 1 (方法学判官 Evaluator)**：搭载复杂的 20 项规则 Prompt，负责深度思考和“找茬”。开启严格的 JSON 模式，只输出结构化问题列表，后台落库。  
+  2. **Agent 2 (撰稿编辑 Writer)**：接到 Agent 1 的 JSON 后被唤醒。它的 Prompt 是主编配置的口吻与格式要求（“请根据以下 JSON 缺陷数据，以极其严厉的专家口吻，按 1/2/3 的格式写一封给作者的退修信”）。  
+  3. **流式输出 (Streaming)**：Agent 2 直接采用流式 SSE 输出纯 Markdown 文本，前端打字机般实时渲染给责编。  
+* **优点**：  
+  * **终极体验**：前端用户看到的是行云流水的打字效果，而后端数据库早已稳稳存下了 Agent 1 的结构化数据。  
+  * **职责单一**：每个 LLM 都在做自己最擅长的事，能力被压榨到极致。  
+* **缺点**：消耗 2 次 LLM 调用，略微增加 Token 成本与耗时。但在多模块并行（Promise.allSettled）架构下，这一点时间是可以被接受的。
+
+## **四、 给 RVW 模块 V4.0 的最终决策建议**
+
+综合考量贵司“敏捷迭代”、“已有基建（Handlebars/PromptService）”和“商业化 SaaS”的诉求，我建议采取 **方案 B 作为核心底座，特定场景引入方案 C** 的融合架构：
+
+#### **第一步：重构 PromptService 的输入输出协议 (落实方案 B)**
+
+1. 运营端页面拆分：将现有的一个大输入框，拆分为\*\*【评判标准库 (Prompt)】**和**【报告展示模板 (Handlebars)】\*\*两个配置区。  
+2. 约束模型：系统底层强制开启模型的 Structured Output (JSON Schema)，LLM 输出只用于落库和填充模板。
+
+#### **第二步：引入双通道确认机制 (类似 SSA Phase IV)**
+
+在责编工作台中，左侧是 AI 找出的【结构化问题卡片】（供责编打勾/忽略），右侧是实时根据勾选状态，利用 Handlebars 重新渲染的【最终意见函预览】。
+
+#### **长期演进**
+
+当遇到需要根据不同分数输出截然不同口吻的高级定制化期刊时，再为该期刊开启 **方案 C (双 Agent 模式)**，把撰写意见函的工作交给 Writer Agent 实时生成。
+
+**总结**：不要试图在一个 Prompt 里用自然语言去“恳求”大模型兼顾结构化和排版。**用底层 API（JSON Schema）锁死结构化数据，用中间层引擎（Handlebars / Writer Agent）解决排版展示**，才是云原生时代的终极稳定架构。

docs/03-业务模块/RVW-稿件审查系统/08-技术架构建议/架构评审报告.md

@@ -0,0 +1,89 @@
+# **RVW 模块方法学解析失败 \- 架构方案评审意见**
+
+仔细阅读了您的分析与解决方案，以及《RVW稿件审查模块 \- 当前状态与开发指南 (v6.1)》，我对您的整体思路表示**高度赞同**。您的分析非常精准地抓住了当前大模型（LLM）工程化落地中的核心痛点：**人类语言的弹性与机器协议的刚性之间的矛盾。**
+
+以下是我对您方案的详细评审，包括我完全认可的部分，以及我认为需要微调或补充的“不认可/需优化”部分。
+
+## **✅ 一、 我完全认可的观点（高度赞同）**
+
+### **1\. 对“为什么必须是 JSON”的业务判定**
+
+**完全认可。** 您的分析一针见血。在 RVW V3.0.1 的架构中，方法学评估并不是一个“终点”，而是流水线的一环。
+
+* 系统依赖解析出 overall\_score 和 methodologyStatus 来更新数据库。  
+* 前端的 MethodologyReport.tsx 和 TaskDetail.tsx 依赖结构化数组（parts\[\]/issues\[\]）来渲染多维度的进度条和增量展示。  
+* 如果退化为纯文本，RVW 模块引以为傲的“4模块并行”、“增量结果持久化”和“结构化 Word 导出”将全线崩溃。
+
+### **2\. 对“核心区别：软约束 vs 硬约束”的定性**
+
+**完全认可。** 仅在 Prompt 中强调“请输出JSON”是典型的**软约束**。业务专家在运营端（PromptService）修改提示词时，往往会引入更多复杂的业务逻辑描述，这极易稀释模型对格式指令的注意力（Attention 偏移），导致模型在输出时“情不自禁”地加上“好的，以下是评估结果：”等前缀，从而破坏 JSON 解析。
+
+### **3\. 将“方案A（Structured Output）”作为最优解**
+
+**完全认可。** 采用 Function Calling 或 Structured Output（Response Format）是当前 LLM 工程界的最佳实践。它将“格式对齐”的工作下沉到了 API 协议层甚至模型的推理采样层（通过 Logits 掩码强制符合 Schema），从而释放了 Prompt 的空间，让 Prompt 可以纯粹服务于业务逻辑。
+
+## **❌ 二、 我不完全认可 / 需要补充完善的观点**
+
+虽然大方向极佳，但从您当前的系统架构（已使用 DeepSeek-V3，具有 LLMFactory 和 PromptService）来看，有几个工程落地的细节我**不完全认可**或认为**需要优化**：
+
+### **1\. 关于“方案B：先自然语言，再二次抽取结构”的定位**
+
+* **您的观点**：这是一个可选方案，增加了修复层。  
+* **我的意见（不推荐）**：在你们当前的 V3.0.1 架构中，极度**不建议**将其作为常规链路。你们的核心指标是“上传到出报告 \< 3分钟（4模块并行）”。如果方法学每次都跑两遍 LLM（甚至第二遍还要等第一遍长文本生成完），不仅 token 成本翻倍，时延也会大幅增加，破坏现有的并发体验。二次抽取**只能**作为万不得已的 Error Retry 兜底，绝不能是主干方案。
+
+### **2\. 关于“schema优先 \+ JSON兜底”的必要性**
+
+* **您的观点**：优先走结构化输出，失败再走 JSON 解析或修复，本质是多层容灾。  
+* **我的意见（略显冗余）**：现在的基座模型（如你们默认的 DeepSeek-V3 和备选的 Qwen3-72B）对 Structured Output / JSON Mode 的支持已经非常成熟。  
+  * 如果您在 API 层面开启了 response\_format: { type: "json\_object" } 或提供了强 Schema，模型返回的一定是格式完好的 JSON 字符串。  
+  * 此时如果解析失败，往往是**模型幻觉导致缺少必填字段**，而不是**JSON格式本身损坏**。因此，容灾的重点不应是“尝试用正则重新抠 JSON”，而应该是直接记录 error\_details（你们已在 V3.0 支持 partial\_completed）并触发基于格式错误的重试逻辑。
+
+### **3\. 遗漏了最核心的系统层解法：“Prompt 动静分离”（关键补充！）**
+
+您的方案主要集中在 LLM 的调用方式上，但忽略了**运营管理端的设计缺陷**。专家修改 Prompt 导致 JSON 崩坏，根本原因是**专家触碰了他们不该触碰的代码约定**。
+
+* **真正的解法**：在您的 PromptService 中，应该将 Prompt 拆分为两部分：  
+  1. **System/Format Prompt（系统保留，研发控制）**：包含严格的 JSON Schema 定义、输出格式要求等。这部分在前端运营管理后台是**隐藏或只读**的。  
+  2. **Business Criteria Prompt（专家可编辑）**：仅包含纯粹的评估标准，如“如何判定T检验误用”、“FINER标准是什么”。  
+  3. **最终组装**：在 MethodologySkill 执行时，由代码自动将两部分拼接发送给 LLM。这样无论专家怎么改业务逻辑，都不会破坏格式指令。
+
+## **🚀 三、 针对 RVW V3.0.1 的具体落地建议**
+
+结合您的现有代码结构（backend/src/modules/rvw/），我建议您按以下三步实施“彻底解决 JSON 崩溃”的方案：
+
+### **Step 1: 在 LLMFactory 中启用 JSON Mode**
+
+修改 @/common/llm/LLMFactory，支持传入 response\_format 或 tools。DeepSeek-V3 原生支持强校验的 JSON 输出。
+
+// 示例：强制要求模型仅返回 JSON  
+const response \= await llmClient.chat.completions.create({  
+  model: 'deepseek-chat',  
+  messages: \[...\],  
+  response\_format: { type: 'json\_object' } // 启用 JSON Mode  
+});
+
+### **Step 2: 实施 Prompt 动静分离 (改造 PromptService)**
+
+在数据库 prompt\_templates 表或 MethodologySkill 中做拆分：
+
+// 在 methodologyService.ts 或 methodologySkill.ts 中组装  
+const formatInstruction \= \`  
+你必须严格按照以下 JSON 结构输出结果，不要包含任何额外的解释文本或 Markdown 标记：  
+{  
+  "overall\_score": 85,  
+  "methodologyStatus": "error" | "warn" | "pass",  
+  "parts": \[  
+    { "name": "统计方法描述", "issues": \[{"severity": "high", "desc": "..."}\] }  
+  \]  
+}\`;
+
+// expertPrompt 是专家在运营管理端配置的内容  
+const finalPrompt \= expertPrompt \+ '\\n\\n' \+ formatInstruction;
+
+### **Step 3: 善用 V3.0 现有的 partial\_completed 兜底**
+
+既然 V3.0 已经实现了 Promise.allSettled 和 error\_details，如果（极小概率下）大模型返回的 JSON 缺少了关键字段导致 Schema 校验失败（比如少了 parts 数组）：
+
+* **不要尝试用正则表达式去猜**。  
+* 直接 throw new Error("Methodology JSON schema validation failed")。  
+* 让外层的 SkillExecutor 捕获，把当前任务标记为 partial\_completed，并在 error\_details 写入原因。前端的“琥珀色警告横幅”会自动提示用户该模块暂时失败，保证系统的绝对健壮性。