# **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 写入原因。前端的“琥珀色警告横幅”会自动提示用户该模块暂时失败，保证系统的绝对健壮性。