docs: complete documentation system (250+ files)

- System architecture and design documentation - Business module docs (ASL/AIA/PKB/RVW/DC/SSA/ST) - ASL module complete design (quality assurance, tech selection) - Platform layer and common capabilities docs - Development standards and API specifications - Deployment and operations guides - Project management and milestone tracking - Architecture implementation reports - Documentation templates and guides
2025-11-16 15:43:55 +08:00
parent 0fe6821a89
commit e52020409c
173 changed files with 46227 additions and 11964 deletions
--- a/docs/00-项目概述/壹证循科技
+++ b/docs/00-项目概述/壹证循科技
@@ -0,0 +1,86 @@
+# **壹证循科技 \- AI科研产品需求文档 (PRD)**
+
+文档版本: 1.0  
+日期: 2025年11月5日  
+致： 产品部、市场部、销售部、技术部及全体同仁
+
+## **1\. 文档目的**
+
+本需求文档 (Product Requirements Document, PRD) 旨在清晰定义“壹证循科技AI科研产品”的核心功能、目标用户及关键的非功能性需求。
+
+本文档是跨部门协作的基石，用于确保技术实现、产品设计与市场策略保持高度一致，特别是应对我们复杂的商业模式和多样的客户部署需求。
+
+## **2\. 产品愿景与目标**
+
+产品愿景：  
+打造一个覆盖临床科研全生命周期、AI驱动的一站式智能科研平台。  
+核心目标：  
+赋能临床医生和科研人员，通过AI与自动化工具，极大地提升科研效率、数据处理质量和文献分析深度，缩短从数据到洞察的周期。
+
+## **3\. 目标用户画像 (User Personas)**
+
+1. **临床医生/研究者**：  
+   * **画像**：三甲医院的科室主任、主治医师、研究生。  
+   * **痛点**：有科研项目（如国自然、GCP、回顾性研究）压力，但临床工作繁忙，缺乏专业统计和数据处理时间。  
+   * **需求**：需要“开箱即用”的工具，快速处理院内数据、分析文献、完成统计、撰写论文。**极其关注患者数据隐私与安全**。  
+2. **医院科室/IT部门**：  
+   * **画像**：医院的科研管理科室、信息中心。  
+   * **痛点**：需要为全院提供合规、可控的科研工具；希望科研数据（尤其是HIS、LIS数据）保留在院内。  
+   * **需求**：采购的工具必须支持**私有化部署**，且安全、稳定、易于管理。
+
+## **4\. 核心功能需求 (Functional Requirements)**
+
+产品功能矩阵共分为7大核心模块，共同构成科研全流程闭环。
+
+| 模块ID | 模块名称 | 核心功能描述 |
+| :---- | :---- | :---- |
+| **F1** | **智能统计分析 (SSA)** | 提供3条核心分析路径：队列研究、预测模型、RCT研究。实现从数据上传、质控、分析到报告导出的完整流程。 |
+| **F2** | **统计分析工具 (ST)** | 提供一个包含100+种轻量化统计工具的工具箱，满足即时、小型的分析需求。 |
+| **F3** | **AI智能回答 (AIA)** | 提供10+个专业AI智能体，覆盖科研关键节点：选题评价、PICO梳理、样本量计算、研究方案制定、文章润色与翻译等。 |
+| **F4** | **AI智能文献 (ASL)** | 提供AI驱动的文献工作流：智能检索、标题摘要初筛、全文复筛、信息提取，并支持Meta分析、证据图谱等应用。 |
+| **F5** | **个人知识库 (PKB)** | 允许用户创建私人文献库（如每个库50篇），并能基于库内文献进行AI问答（RAG）。 |
+| **F6** | **数据清洗整理 (DC)** | **(核心难点)** 提供专业工具，处理医院导出的海量（百万行级）、多表格（10+张）的Excel数据，实现两大功能： 1\. **表格ETL**：将多张散乱的流水表，按“患者ID”和“时间”重组为一张干净的分析宽表。 2\. **文本提取(NER)**：从病理报告、住院小结等大段文本中，自动提取结构化的关键字段（如TNM分期）。 |
+| **F7** | **个人中心 (UAM)** | 提供账户管理、版本信息、帮助中心、订单管理等基础支撑功能。 |
+
+## **5\. 关键非功能性需求 (Non-Functional Requirements)**
+
+这是本产品在商业推广中**最复杂、最核心**的需求，是技术架构必须解决的关键挑战。
+
+### **NFR-1: 部署模式灵活性 (Deployment Flexibility)**
+
+产品必须支持以下四种部署形态，以满足不同客户（尤其是医院）对数据安全和合规性的严苛要求。
+
+| 部署形态 | 描述 | 关键要求 |
+| :---- | :---- | :---- |
+| **云端SaaS版** | (默认) 产品部署在公有云，用户通过浏览器按需订阅使用。 | 必须支持多租户、高可用。 |
+| **私有化部署** | (医院/机构) 将**整个平台**或**指定模块**（如DC, SSA）部署在客户的内网服务器上。 | 必须提供容器化（Docker/K8s）的一键部署方案。数据100%不出内网。 |
+| **混合部署** | (私有化客户) 客户在内网使用“私有化”的DC/SSA模块，同时能调用我们“云端”的ASL/AIA模块。 | 平台必须支持这种“本地+云端”的混合调用模式，前端需智能路由。 |
+| **单机版** | (个人医生) 提供**可安装的桌面应用(Windows/Mac)**，针对DC、SSA、ASL等核心模块。 | **数据100%本地化**。文献、病例原始文件严禁上传。必须支持离线运行（如DC, SSA）。 *(例外：ASL模块可受控调用云端LLM，但仅限发送“摘要”而非“原文”)* |
+
+### **NFR-2: 商业模式可配置 (Commercial Flexibility)**
+
+产品架构必须支持销售和市场策略的灵活性。
+
+1. **SaaS多版本 (Tiered SaaS)**  
+   * **需求**：云端SaaS版必须支持至少三个等级：**专业版、高级版、旗舰版**。  
+   * **实现**：后端需具备完善的\*\*功能开关(Feature Flag)\*\*系统，能按版本限制用户可用的功能模块、使用次数、AI模型等。  
+2. **模块化售卖 (Modular Sales)**  
+   * **需求**：任何一个功能模块（如F4: AI智能文献）都**必须能**被独立打包，作为单独的产品进行售卖。  
+   * **实现**：技术架构必须是“松耦合”的，确保模块间没有硬依赖。  
+3. **AI成本可控 (Configurable AI)**  
+   * **需求**：为应对不同客户的成本敏感度，平台必须支持**动态切换**后端的大语言模型。  
+   * **实现**：例如，专业版用户默认调用成本较低的DeepSeek，旗舰版用户可调用更高质量的Claude或GPT。
+
+### **NFR-3: 平台与性能 (Platform & Performance)**
+
+1. **平台兼容性**：  
+   * Web版：必须支持所有现代浏览器（Chrome, Edge, Firefox, Safari）。  
+   * 单机版：必须支持 **Windows 10 (64位)及以上** 和 **macOS (Intel & Apple Silicon)**。  
+   * **【重点】明确不支持**：为保证产品稳定性和数据安全，单机版**不支持**任何32位操作系统及Windows 7等已停止服务的系统。  
+2. **数据处理性能 (DC模块)**：  
+   * 产品（尤其是单机版）必须能稳定处理百万行级别的多表Excel数据，**严禁**因内存溢出而导致程序崩溃。  
+   * 产品（服务器版）在处理相同数据时，应追求极致效率，在数分钟内完成处理。  
+3. **文本提取质量 (DC模块)**：  
+   * 产品必须能提供高准确率的医学文本提取。  
+   * **服务器版（最优解）**：应使用SOTA（业界顶尖）的LLM（如Claude 3）以保证最高质量。  
+   * **单机版（妥协解）**：为保证数据隐私，必须使用100%本地运行的NLP模型（如spaCy），在保护隐私的前提下尽力提高准确率。
--- a/docs/00-项目概述/壹证循科技AI科研产品
+++ b/docs/00-项目概述/壹证循科技AI科研产品
@@ -0,0 +1,234 @@
+# **壹证循科技AI科研产品 \- 技术架构白皮书**
+
+## **1\. 执行摘要 (Executive Summary)**
+
+本文档为“壹证循科技”AI科研产品套件提供了一个统一的技术架构方案。
+
+**核心战略**：采用\*\*“演进式架构”**。以**“模块化单体”**（Modular Monolith）启动，快速迭代；并为未来向**“微服务”\*\*（Microservices）架构的平滑过渡做好充分准备。
+
+**核心原则**：
+
+1. **平台与产品分离**：严格划分“底层通用模块”（如用户中心）和“上层业务模块”（如统计分析）。  
+2. **一个架构，多种部署**：设计一套灵活的架构，通过“容器化”和“逻辑重组”，同时支持**①云端SaaS**、**②医院私有化部署**、**③混合部署**和**④医生个人单机版**。  
+3. **技术异构（Polyglot）**：采用“用最合适的工具做最合适的事”的原则，允许Node.js、R、Python、Java等技术栈在微服务架构中共存。
+
+**技术路径**：
+
+* **云端/私有化**：采用 Docker(容器) \+ Kubernetes(编排) \+ API网关 的标准微服务部署方案。  
+* **单机版**：采用 **Electron** 框架，**100%复用前端UI代码**，并通过 Node.js主进程 \+ 本地子进程(R/Python) 的方式重组后端逻辑，实现数据100%本地化。
+
+## **2\. 业务需求与架构挑战**
+
+### **2.1 产品功能矩阵 (7大模块)**
+
+1. **智能统计分析 (SSA)**  
+2. **统计分析工具 (ST)**  
+3. **AI智能回答 (AIA)**  
+4. **AI智能文献 (ASL)**  
+5. **个人知识库 (PKB)**  
+6. **数据清洗整理 (DC)**  
+7. **个人中心 (UAM)**
+
+### **2.2 复杂的商业与部署挑战**
+
+1. **多版本 (SaaS)**：云端版分为专业版、高级版、旗舰版。  
+2. **模块化售卖**：任何模块（如AI智能文献）都可能独立售卖。  
+3. **私有化部署**：医院要求将数据敏感模块（如SSA、DC）部署在内网服务器。  
+4. **混合部署**：医院本地使用SSA，同时又调用云端的ASL。  
+5. **单机版部署**：医生需要在个人电脑(Windows/Mac)上离线运行SSA、DC、ASL等模块，确保数据（文献、病例）不出本地。
+
+## **3\. 核心架构：API网关 \+ 微服务**
+
+为满足以上所有需求，我们推荐一个解耦的、面向服务的架构。
+
+* **客户端 (Clients)**：包括Web浏览器、PC单机版(Electron)、移动端。  
+* **API网关 (API Gateway)**：所有流量的统一入口。负责：  
+  * **认证**：校验用户Token。  
+  * **路由**：将请求转发给正确的后端微服务（如 /api/stats \-\> SSA服务）。  
+  * **聚合**：(未来)合并多个服务的数据。  
+* **后端服务 (Services)**：真正执行业务逻辑的单元。
+
+## **4\. 服务模块划分 (平台 vs 产品)**
+
+这是架构解耦的第一步。
+
+### **4.1 底层通用模块 (平台层)**
+
+这些是所有产品共用的“地基”，必须稳固、统一。
+
+1. **用户与权限中心 (UAM)**  
+   * **功能**：管理用户、角色、租户（医院）、权限。  
+   * **价值**：实现SaaS多版本（专业版/高级版）的功能开关(Feature Flag)控制。  
+2. **AI大模型网关 (LLM Gateway)**  
+   * **功能**：统一管理所有对大模型的调用（DeepSeek, Claude等）。  
+   * **价值**：根据SaaS版本、成本考量动态切换模型。是AI功能的核心中枢。  
+3. **账户/个人中心**：管理用户配置、订单、帮助文档。  
+4. **通知服务**：邮件、站内信。
+
+### **4.2 独立业务模块 (产品层)**
+
+这些是可插拔的“积木”，对应你们的7大功能，每个都应设计为**独立的服务**。
+
+1. **智能统计 (SSA) 服务** (可包含统计工具ST)  
+2. **AI问答 (AIA) 服务**  
+3. **AI文献 (ASL) 服务**  
+4. **知识库 (PKB) 服务**  
+5. **数据清洗 (DC) 服务** (详见第6节)
+
+## **5\. 推荐技术栈 (技术异构)**
+
+我们允许“用最合适的工具做最合适的事”。
+
+| 领域 | 推荐技术 | 理由 |  
+| 前端 (UI) | React 或 Vue | 1\. 现代SPA框架。 2\. 可100%复用于Web版和Electron单机版。 |  
+| API网关 & 粘合层 | Node.js | 1\. 高并发I/O性能。 2\. 作为“总指挥”粘合R/Python非常成熟。 3\. Electron单机版后端复用。 |  
+| 统计分析 (SSA) | R 语言 | 统计分析的王者。通过 Plumber 包暴露为API，或通过子进程调用。 |  
+| AI/数据清洗 (DC) | Python | 强大的Pandas、Scikit-learn、NLP生态。通过 FastAPI 暴露API，或通过子进程调用。 |  
+| 数据库 | PostgreSQL \+ Vector DB | PostgreSQL处理结构化数据；向量数据库支持知识库(PKB)的RAG。 |  
+| 部署方案 | Docker \+ Kubernetes | 现代云原生的唯一标准，实现弹性和多环境部署。 |  
+| 单机版方案 | Electron | 唯一能原生支持Node.js后端、复用Web前端UI的跨平台方案。 |
+
+## **6\. 模块深度解析：(DC) 数据清洗整理服务**
+
+“数据清洗整理 (DC)” 模块是连接原始数据与有效分析的桥梁，技术挑战分为两部分：
+
+1. **海量表格ETL**：处理百万行、多表格的结构化数据，执行高效的连接(Join)、重组(Pivot)和排序。  
+2. **非结构化文本NER**：从病理、出入院小结等大段文本中，提取结构化字段（如TNM分期、肿瘤大小）。
+
+针对不同的部署场景，我们采用两种实现方案：
+
+### **6.1 方案一：服务器最优版 (Cloud-Optimal)**
+
+此方案用于**云端SaaS版**和**私有化部署**，目标是追求极致的**效率、准确率和质量**（假设数据已脱敏）。
+
+* **技术栈**：Python (FastAPI) \+ Polars \+ LLM API (Claude/GPT) \+ PostgreSQL  
+* **工作流**：  
+  1. **API接收**：FastAPI (Python) 服务接收用户上传的多个Excel文件。  
+  2. **ETL (Polars)**：  
+     * **放弃Pandas**，采用Polars库。Polars基于Rust，天生**多线程并行**，内存效率极高。  
+     * 在服务器的大内存中（如64GB+），Polars能以**数秒或数十秒**的速度，在内存中完成200万行数据的多表JOIN、GROUP BY等操作，速度是Pandas的10-100倍。  
+  3. **NER (LLM API)**：  
+     * FastAPI 服务**并行调用** AI大模型网关（见4.1节）。  
+     * 使用 **Claude 3** 或 **GPT-4o** 等SOTA模型，配合JSON Mode，从病理报告中提取结构化信息。  
+     * **优势**：准确率极高，能理解复杂上下文，无需训练模型。  
+  4. **交付**：清洗完成的Polars DataFrame被存入PostgreSQL结果表，前端可在线浏览或导出。  
+* **架构融合**：此 FastAPI \+ Polars 服务，**就是**白皮书架构中的“数据清洗 (DC) 微服务”，由“Node.js API网关”负责调用。
+
+### **6.2 方案二：单机版 (Desktop-Offline)**
+
+此方案用于**医生个人电脑**，目标是**100%数据隐私**和**离线可用性**，是对性能和准确率的**必要妥协**。
+
+* **技术栈**：Electron (Node.js) \+ Python (Pandas) \+ SQLite \+ spaCy (本地NLP)  
+* **工作流**：  
+  1. **总指挥 (Node.js)**：Electron的主进程作为总指挥，调度Python子进程。  
+  2. **ETL (SQLite)**：  
+     * **严禁**将200万行数据一次性读入内存（会导致用户电脑崩溃）。  
+     * Python脚本被调用，使用Pandas的chunksize参数，**分块**读取Excel，**逐行**写入一个本地**SQLite**数据库文件 (.db)。  
+     * **关键**：利用 **SQLite 数据库引擎**（而不是Pandas内存）来执行所有繁重的JOIN和GROUP BY。这是在低内存电脑上处理大数据的唯一稳定方案。  
+  3. **NER (本地 spaCy)**：  
+     * **严禁**将原始病例（PHI）发送到任何云端API（重大违规）。  
+     * Python脚本被调用，加载 **spaCy** 等**100%本地运行**的NLP模型，在用户电脑上提取实体。  
+     * **劣势**：spaCy准确率有限，无法处理复杂语义，效果远不如LLM。  
+  4. **交付**：所有结果被写回本地 SQLite 数据库。Electron前端通过分页从SQLite中读取数据展示，或导出为Excel。  
+* **架构融合**：此方案**就是**白皮书【7.4 场景四：医生单机版】的具体实现。
+
+## **7\. 关键路径：多部署模式实现**
+
+同一套代码库，如何支持所有商业场景？
+
+### **7.1 场景一：云端SaaS版 (标准微服务)**
+
+* **架构**：所有服务（UAM, SSA, ASL...）和数据库都在云端，通过K8s管理。  
+* **客户端**：用户通过浏览器访问。
+
+### **7.2 场景二：医院本地化部署 (私有化)**
+
+* **架构**：将数据敏感的服务（如 SSA服务、DC服务）及其数据库打包为Docker容器。  
+* **部署**：使用K8s或更轻量的K3s，在医院内网服务器上“一键部署”。  
+* **数据**：数据100%留在医院内网。
+
+### **7.3 场景三：混合部署**
+
+* **架构**：在场景二的基础上，前端应用被智能配置。  
+* **流程**：  
+  * 用户访问 .../stats \-\> 前端调用**医院内网API** (http://192.168.x.x/api/stats)。  
+  * 用户访问 .../literature \-\> 前端调用**云端公网API** (https://api.yizhengxun.com/api/lit)。
+
+### **7.4 场景四：医生单机版 (Electron)**
+
+这是技术上最关键的“过渡”，它不是“打包”，而是\*\*“架构重组”\*\*。
+
+云端版架构:  
+\[浏览器UI\] \<-- (HTTP网络) \--\> \[云端Node.js API\] \<-- (HTTP) \--\> \[云端R/Python服务\]  
+单机版架构:  
+\[Electron UI (复用)\] \<-- (IPC本机通信) \--\> \[Electron主进程 (Node.js复用)\] \<-- (Child Process本机调用) \--\> \[本地R/Python脚本\]  
+**实现路径：**
+
+1. **新建Electron项目**。  
+2. **移植前端 (UI复用)**：将云端版的React/Vue**编译后的静态文件** (dist目录) 完整复制到Electron中。  
+3. **重组后端 (逻辑复用)**：  
+   * 云端版的 **Node.js API逻辑**，被移植到 **Electron的主进程(main.js)** 中。  
+   * 云端版的 **R 和 Python 脚本**，被作为**本地文件**打包进安装包。  
+   * main.js (Node.js) 通过 child\_process.spawn（子进程）来**本地调用**这些R/Python脚本。（具体实现见第6.2节）  
+4. **数据交换**：Node.js、R、Python之间通过 stdin/stdout 和 **JSON** 字符串进行数据交换。  
+5. **本地AI功能 (ASL模块)**：  
+   * Node.js (fs模块) 读取本地文献夹中的PDF。  
+   * Node.js (用 pdf-parse) 在**本地**提取摘要文本。  
+   * Node.js (用 axios) **只将“摘要文本”发送给云端LLM API** (如DeepSeek) 进行分析。（注意：这与DC模块的原始病例处理不同）。  
+   * **文献原文件 (.pdf) 100% 不离开用户电脑**。  
+6. **本地存储**：使用 **SQLite**（通过 npm install sqlite3）在本地存储文献的元数据、分析结果等。
+
+## **8\. 工程化与兼容性 (必读)**
+
+### **8.1 单机版的“全家桶”挑战**
+
+单机版的工程挑战不是开发，而是**打包**。
+
+* 您的 .exe (Windows) 和 .dmg (Mac) 安装包必须是一个“全家桶”。  
+* 您需要使用 electron-builder 等工具，将以下所有内容捆绑进一个安装包：  
+  1. 您的Electron应用 (Node.js \+ 前端UI)。  
+  2. 一个**嵌入式的 Python 运行时**及所有依赖 (pandas, spaCy等)。  
+  3. 一个**嵌入式的 R 运行时**及所有依赖 (jsonlite等)。  
+* 这会使安装包体积变大（如500MB+），这对于专业软件是完全可以接受的。
+
+### **8.2 必须放弃：Win 7 与 32位系统**
+
+**这是一个商业和安全决策，不是技术选项。**
+
+**必须声明：** 您的单机版最低系统要求是 **Windows 10 (64位)**。
+
+**理由：**
+
+1. **稳定性的“崩溃”问题**：32位系统有4GB内存上限，APP最多用2-3GB。您的**R语言统计分析**和**数据清洗**都是内存消耗大户，处理真实数据时**不是变卡，而是会直接崩溃闪退**，导致用户数据丢失。  
+2. **安全性的“漏洞”问题**：微软已放弃Win 7。现代Electron, Node.js, Python, R生态已**全部停止支持32位和Win 7**。强行兼容意味着您必须使用5年前、充满已知安全漏洞的“古董”技术栈来处理敏感医疗数据，这是不可接受的。
+
+## **9\. 分阶段实施路线图 (Roadmap)**
+
+作为初创公司，我们必须务实。
+
+### **9.1 阶段一：云端MVP (0-6个月) \- “模块化单体”**
+
+* **目标**：快速上线云端SaaS版，验证市场。  
+* **架构**：一个代码仓库 (Monorepo)，一个主后端服务（如Node.js）。  
+* **关键纪律 (打地基)**：  
+  1. **代码隔离**：在代码目录上，严格按“平台模块”和“业务模块”划分。  
+  2. **数据隔离**：在同一个PostgreSQL数据库中，**严格使用不同的Schema** (如 uam\_schema, stats\_schema) 来隔离数据。这是未来拆分微服务的生命线。  
+  3. **全员Docker**：从第一天起，所有开发、测试、生产环境都必须基于 Docker 和 docker-compose。
+
+### **9.2 阶段二：首次部署 (6-18个月) \- “首次拆分”**
+
+* **触发点**：迎来第一个“私有化部署”客户，或“单机版”需求。  
+* **架构**：  
+  1. **引入K8s**：在云端正式启用Kubernetes进行服务编排。  
+  2. **引入API网关**：在K8s集群前部署Nginx或Kong。  
+  3. **执行首次拆分**：将 SSA 和 DC 模块（连同它们的 stats\_schema）从主应用中**物理拆分**出来，打包成第一个独立的微服务（采用6.1节的“最优版”架构）。  
+  4. **开发单机版**：启动第一个Electron项目，按照【7.4】中的路径进行“重组”（采用6.2节的“单机版”架构）。
+
+### **9.3 阶段三：全面微服务 (18个月+)**
+
+* **目标**：支持灵活的业务组合和团队扩张。  
+* **架构**：随着业务发展，将 ASL, PKB 等其他成熟模块也逐步拆分为独立的微服务，实现最终的“乐高积木式”的灵活架构。
+
+## **10\. 结论**
+
+本架构方案的核心是\*\*“演进”\*\*。它在初期（阶段一）通过“模块化单体”保证了初创公司的迭代速度，同时通过“代码/数据隔离”和“全面Docker化”的纪律，为未来（阶段二、三）向复杂微服务和多部署形态的平滑过渡打下了坚实的地基，避免了未来推倒重来的灾难性成本。
--- a/docs/00-项目概述/文档梳理与差异分析.md
+++ b/docs/00-项目概述/文档梳理与差异分析.md
@@ -0,0 +1,498 @@
+# AIclinicalresearch 文档梳理与差异分析
+
+> **文档版本：** v1.0  
+> **创建日期：** 2025-11-06  
+> **维护者：** 项目团队  
+> **最后更新：** 2025-11-06
+
+---
+
+## 📋 执行摘要
+
+本文档对AIclinicalresearch项目下的所有文档进行了系统梳理,并重点对比了**最新需求文档**（壹证循科技 AI科研产品需求文档.md 和 技术架构白皮书.md）与**现有文档**之间的差异。
+
+### 🎯 核心发现
+
+**最新需求文档（2025-11-05）反映了产品战略的重大调整：**
+
+1. **产品定位变化：** 从单一的"AI科研助手"扩展为**7大模块的综合性AI科研平台**
+2. **商业模式变化：** 从简单SaaS模式扩展为**4种部署形态**（云端SaaS、私有化、混合部署、单机版）
+3. **技术架构变化：** 从"模块化单体"演进为**微服务架构**，支持模块化售卖
+4. **目标用户变化：** 从科研人员扩展到**医院机构**（强调数据安全和私有化部署）
+
+---
+
+## 📚 文档结构梳理
+
+### 1. 00-项目概述 文件夹
+
+| 文档名称 | 状态 | 版本日期 | 核心内容 | 是否符合最新需求 |
+|---------|------|---------|---------|----------------|
+| **壹证循科技 AI科研产品需求文档.md** | ✅ 最新 | 2025-11-05 | 7大模块功能矩阵、4种部署模式、商业模式 | ✅ 基准文档 |
+| **壹证循科技AI科研产品 - 技术架构白皮书.md** | ✅ 最新 | 2025-11-05 | 微服务架构、技术异构、Electron单机版 | ✅ 基准文档 |
+| 产品需求文档(PRD).md | ⚠️ 旧版 | 2025-10-10 | 仅包含AI问答、知识库、项目管理 | ❌ **需要更新** |
+| 技术架构总览.md | ⚠️ 旧版 | 2025-10-10 | 基于Dify+LobeChat的简化架构 | ❌ **需要更新** |
+| AI智能文献PRD（1）-产品概览.md | ⚠️ 部分旧 | 2025-10-21 | 6大模块（研究方案、检索、初筛、复筛、提取、分析） | ⚠️ **部分符合，需整合** |
+| AI智能文献PRD（2）-初筛与复筛.md | ⚠️ 部分旧 | 2025-10-21 | 初筛和复筛详细设计 | ⚠️ **部分符合，需整合** |
+| AI智能文献PRD（3）-提取与分析模块.md | ⚠️ 部分旧 | 2025-10-21 | 提取和分析详细设计 | ⚠️ **部分符合，需整合** |
+| 系统总体架构设计.md | ⚠️ 占位 | 2025-10-29 | 占位文档，待完善 | ❌ **需要重写** |
+| 设计文档完成总结.md | ⚠️ 旧版 | 2025-10-10 | 基于旧版PRD的总结 | ❌ **需要更新** |
+
+### 2. 01-设计文档 文件夹
+
+| 文档名称 | 状态 | 版本日期 | 核心内容 | 是否符合最新需求 |
+|---------|------|---------|---------|----------------|
+| 数据库设计文档.md | ⚠️ 旧版 | 2025-10-10 | 基于AI问答+知识库的数据库设计 | ❌ **缺少DC、SSA、ASL模块表** |
+| API设计规范.md | ⚠️ 旧版 | 2025-10-10 | 基于AI问答+知识库的API设计 | ❌ **缺少新模块API** |
+| 平台前端架构设计/01-前端总体架构设计.md | ⚠️ 部分旧 | 2025-10-29 | 7个模块的顶部导航设计 | ⚠️ **架构正确，但缺少部署模式考虑** |
+| 平台前端架构设计/02-导航结构设计.md | ⚠️ 部分旧 | 2025-10-29 | 导航详细设计 | ⚠️ **架构正确，但缺少部署模式考虑** |
+| 系统架构/01-系统总体架构设计.md | ⚠️ 占位 | 2025-10-29 | 占位文档 | ❌ **需要重写** |
+| 系统架构/04-运营管理端架构设计.md | ⚠️ 占位 | 2025-10-29 | 占位文档 | ❌ **需要重写** |
+| 系统架构/05-部署架构设计.md | ⚠️ 占位 | 2025-10-29 | 占位文档 | ❌ **需要重写（关键）** |
+
+### 3. AI智能文献 文件夹
+
+| 文档名称 | 状态 | 版本日期 | 核心内容 | 是否符合最新需求 |
+|---------|------|---------|---------|----------------|
+| 所有文档 | ⚠️ 部分旧 | 2025-10-29 | 基于Web版的AI智能文献设计 | ⚠️ **缺少单机版、私有化部署考虑** |
+
+### 4. 07-部署文档 文件夹
+
+| 文档名称 | 状态 | 版本日期 | 核心内容 | 是否符合最新需求 |
+|---------|------|---------|---------|----------------|
+| 本地化部署方案.md | ⚠️ 占位 | 2025-10-29 | 占位文档 | ❌ **需要重写（关键）** |
+| 模块独立部署指南.md | ⚠️ 占位 | 2025-10-29 | 占位文档 | ❌ **需要重写（关键）** |
+
+### 5. 05-每日进度 文件夹
+
+| 状态 | 说明 |
+|------|------|
+| ⚠️ 历史记录 | 记录了AI问答+知识库的开发历史（Day04-Day31），基于旧版PRD |
+
+---
+
+## 🔍 关键差异分析
+
+### 差异1：产品功能范围
+
+#### 旧版文档（产品需求文档(PRD).md）
+```
+核心功能：
+1. 项目/课题管理
+2. AI智能体（12个智能体）
+3. 个人知识库
+4. 历史记录
+5. 运营后台
+```
+
+#### 最新需求（壹证循科技 AI科研产品需求文档.md）
+```
+7大核心模块：
+F1. 智能统计分析 (SSA) - ❌ 旧文档完全缺失
+F2. 统计分析工具 (ST) - ❌ 旧文档完全缺失
+F3. AI智能回答 (AIA) - ✅ 对应旧文档的"AI智能体"
+F4. AI智能文献 (ASL) - ⚠️ 有独立PRD，但未整合
+F5. 个人知识库 (PKB) - ✅ 对应旧文档的"个人知识库"
+F6. 数据清洗整理 (DC) - ❌ 旧文档完全缺失（核心难点）
+F7. 个人中心 (UAM) - ✅ 对应旧文档的"个人中心"
+```
+
+**影响：**
+- ❌ 旧版数据库设计缺少 SSA、ST、DC、ASL 模块的表结构
+- ❌ 旧版API设计缺少这些模块的接口
+- ❌ 旧版前端架构虽然预留了导航位置，但缺少详细设计
+
+---
+
+### 差异2：部署模式
+
+#### 旧版文档（技术架构总览.md）
+```
+部署模式：
+- 云端SaaS版（唯一模式）
+- 基于Docker部署
+- 单一租户架构
+```
+
+#### 最新需求（技术架构白皮书.md）
+```
+4种部署形态（NFR-1核心要求）：
+1. 云端SaaS版 - 多租户、高可用
+2. 私有化部署 - 整个平台或指定模块部署在客户内网
+3. 混合部署 - 本地使用DC/SSA，云端调用ASL/AIA
+4. 单机版 - Electron桌面应用（Windows/Mac），数据100%本地化
+```
+
+**影响：**
+- ❌ 旧版架构设计**完全不支持**私有化部署和单机版
+- ❌ 旧版前端架构设计未考虑**混合部署**的路由策略
+- ❌ 缺少**Electron单机版**的技术方案和开发计划
+- ❌ 缺少**容器化（K8s）**的部署架构设计
+
+---
+
+### 差异3：商业模式
+
+#### 旧版文档
+```
+商业模式：
+- 简单的SaaS订阅模式
+- 未明确版本分级
+```
+
+#### 最新需求（NFR-2核心要求）
+```
+商业模式（NFR-2）：
+1. SaaS多版本：专业版、高级版、旗舰版
+   - 需要完善的Feature Flag系统
+2. 模块化售卖：任何模块可独立打包售卖
+   - 技术架构必须松耦合
+3. AI成本可控：动态切换LLM模型
+   - 专业版用DeepSeek，旗舰版用Claude/GPT
+```
+
+**影响：**
+- ⚠️ 旧版前端架构设计已考虑版本权限控制，但**未实现Feature Flag系统**
+- ❌ 旧版架构设计未考虑**模块独立售卖**的技术实现
+- ⚠️ 旧版已支持多模型切换，但未与版本权限绑定
+
+---
+
+### 差异4：技术架构
+
+#### 旧版文档（技术架构总览.md）
+```
+技术架构：
+- 前端：React + Vite + LobeChat组件
+- 后端：Node.js + Fastify + Prisma
+- 数据库：PostgreSQL
+- RAG：Dify（仅用于知识库）
+- LLM：DeepSeek-V3 + Qwen3
+- 架构：模块化单体（Monolith）
+```
+
+#### 最新需求（技术架构白皮书.md）
+```
+技术架构（演进式）：
+- 阶段一（0-6个月）：模块化单体 ✅ 与旧版一致
+- 阶段二（6-18个月）：首次拆分（SSA、DC微服务）+ Electron单机版
+- 阶段三（18个月+）：全面微服务架构
+
+核心技术栈（技术异构）：
+- 前端：React/Vue（Web + Electron复用）
+- API网关：Node.js
+- 统计分析（SSA）：R语言 + Plumber API ❌ 旧文档缺失
+- 数据清洗（DC）：Python + Polars/Pandas + FastAPI ❌ 旧文档缺失
+- 部署：Docker + Kubernetes ⚠️ 旧文档仅Docker
+- 单机版：Electron + 本地R/Python子进程 ❌ 旧文档完全缺失
+```
+
+**影响：**
+- ❌ 旧版架构设计**未考虑R语言和Python微服务**的集成
+- ❌ 旧版架构设计**未考虑Kubernetes编排**
+- ❌ 旧版架构设计**完全缺少Electron单机版**的技术方案
+- ❌ 旧版架构设计**未考虑API网关**的引入
+
+---
+
+### 差异5：数据清洗模块（DC）- 核心难点
+
+#### 旧版文档
+```
+状态：完全缺失
+```
+
+#### 最新需求（技术架构白皮书第6节）
+```
+数据清洗整理 (DC) 模块：
+1. 海量表格ETL：处理百万行、多表格的Excel数据
+2. 非结构化文本NER：从病理报告中提取结构化字段
+
+两种实现方案：
+方案一：服务器最优版（云端/私有化）
+- Python + Polars（替代Pandas，10-100倍速度）
+- LLM API（Claude 3/GPT-4o）进行NER
+- PostgreSQL存储结果
+
+方案二：单机版（Desktop-Offline）
+- Electron + Python子进程
+- SQLite（避免内存溢出）
+- spaCy本地NLP模型（100%隐私保护）
+```
+
+**影响：**
+- ❌ 旧版数据库设计**完全缺少DC模块的表结构**
+- ❌ 旧版API设计**完全缺少DC模块的接口**
+- ❌ 旧版技术栈**未包含Python微服务**
+- ❌ 旧版架构设计**未考虑Polars、SQLite、spaCy**等关键技术
+
+---
+
+### 差异6：AI智能文献模块（ASL）
+
+#### 旧版文档（AI智能文献PRD系列）
+```
+状态：有独立PRD文档（2025-10-21）
+内容：6大模块（研究方案、检索、初筛、复筛、提取、分析）
+架构：基于Web版的设计
+```
+
+#### 最新需求（壹证循科技 AI科研产品需求文档.md）
+```
+F4. AI智能文献 (ASL)：
+- 提供AI驱动的文献工作流
+- 智能检索、标题摘要初筛、全文复筛、信息提取
+- 支持Meta分析、证据图谱等应用
+- 必须支持单机版（文献原文100%不离开用户电脑）
+```
+
+**影响：**
+- ⚠️ 现有AI智能文献PRD文档**内容基本符合**，但需要：
+  1. ❌ 补充**单机版实现方案**（Electron + 本地PDF解析）
+  2. ❌ 补充**私有化部署方案**
+  3. ⚠️ 整合到**7大模块**的整体架构中
+
+---
+
+### 差异7：智能统计分析模块（SSA）
+
+#### 旧版文档
+```
+状态：完全缺失
+```
+
+#### 最新需求
+```
+F1. 智能统计分析 (SSA)：
+- 3条核心分析路径：队列研究、预测模型、RCT研究
+- 数据上传、质控、分析、报告导出
+- 必须支持私有化部署（医院内网）
+- 必须支持单机版（数据100%本地化）
+
+技术实现（白皮书）：
+- R语言 + Plumber API（服务器版）
+- R语言 + Electron子进程（单机版）
+```
+
+**影响：**
+- ❌ 旧版文档**完全缺少SSA模块的PRD**
+- ❌ 旧版数据库设计**完全缺少SSA模块的表结构**
+- ❌ 旧版技术栈**未包含R语言**
+- ❌ 旧版架构设计**未考虑R语言微服务**的集成
+
+---
+
+## 📊 文档符合度评分
+
+| 文档类别 | 符合度 | 说明 |
+|---------|-------|------|
+| **产品需求文档** | 30% | 仅覆盖3/7模块（AIA、PKB、UAM） |
+| **技术架构文档** | 40% | 基础架构正确，但缺少微服务、Electron、K8s |
+| **数据库设计** | 35% | 仅覆盖3/7模块的表结构 |
+| **API设计** | 35% | 仅覆盖3/7模块的接口 |
+| **前端架构** | 60% | 导航结构正确，但缺少部署模式考虑 |
+| **部署文档** | 0% | 完全缺失（占位文档） |
+| **AI智能文献** | 70% | 内容基本符合，但缺少单机版和私有化方案 |
+
+**总体符合度：约 40%**
+
+---
+
+## 🚨 关键缺失内容清单
+
+### 1. 产品需求层面
+
+- [ ] **SSA模块完整PRD**（队列研究、预测模型、RCT研究）
+- [ ] **ST模块完整PRD**（100+种统计工具）
+- [ ] **DC模块完整PRD**（表格ETL + 文本NER）
+- [ ] **4种部署模式的详细需求说明**
+- [ ] **模块化售卖的商业模式设计**
+- [ ] **Feature Flag系统的需求定义**
+
+### 2. 技术架构层面
+
+- [ ] **微服务架构设计**（API网关 + 服务拆分）
+- [ ] **R语言微服务集成方案**
+- [ ] **Python微服务集成方案**（Polars + FastAPI）
+- [ ] **Kubernetes部署架构设计**
+- [ ] **Electron单机版完整技术方案**
+- [ ] **混合部署的路由策略设计**
+- [ ] **私有化部署的容器化方案**
+
+### 3. 数据库设计层面
+
+- [ ] **SSA模块表结构**（研究项目、数据集、分析结果）
+- [ ] **ST模块表结构**（工具配置、使用记录）
+- [ ] **DC模块表结构**（清洗任务、ETL配置、NER结果）
+- [ ] **ASL模块表结构**（文献项目、筛选记录、提取数据）
+- [ ] **多租户数据隔离设计**（Schema隔离）
+
+### 4. API设计层面
+
+- [ ] **SSA模块API**（数据上传、分析执行、报告生成）
+- [ ] **ST模块API**（工具列表、工具执行）
+- [ ] **DC模块API**（文件上传、ETL执行、NER执行）
+- [ ] **ASL模块API**（文献导入、筛选、提取）
+- [ ] **API网关路由配置**
+
+### 5. 前端架构层面
+
+- [ ] **Electron单机版前端架构**
+- [ ] **混合部署的前端路由策略**
+- [ ] **Feature Flag前端实现**
+- [ ] **模块独立打包方案**
+
+### 6. 部署文档层面
+
+- [ ] **云端SaaS部署方案**（K8s + 多租户）
+- [ ] **私有化部署方案**（Docker + K3s）
+- [ ] **混合部署方案**（本地+云端）
+- [ ] **Electron单机版打包方案**（Windows + Mac）
+- [ ] **模块独立部署指南**
+
+---
+
+## 📝 建议的文档更新优先级
+
+### 🔴 P0 - 立即更新（阻塞开发）
+
+1. **系统总体架构设计.md** - 重写，基于技术架构白皮书
+2. **部署架构设计.md** - 重写，详细说明4种部署模式
+3. **数据库设计文档.md** - 补充SSA、ST、DC、ASL模块表结构
+4. **产品需求文档(PRD).md** - 重写，整合7大模块
+
+### 🟠 P1 - 近期更新（影响规划）
+
+5. **DC模块PRD** - 新建，详细说明ETL和NER需求
+6. **SSA模块PRD** - 新建，详细说明3条分析路径
+7. **ST模块PRD** - 新建，详细说明100+工具
+8. **Electron单机版技术方案** - 新建，详细说明实现路径
+9. **API设计规范.md** - 补充新模块API
+
+### 🟡 P2 - 后续更新（优化完善）
+
+10. **前端总体架构设计.md** - 补充部署模式考虑
+11. **AI智能文献PRD系列** - 补充单机版和私有化方案
+12. **技术架构总览.md** - 重写，基于技术架构白皮书
+13. **本地化部署方案.md** - 详细说明私有化部署
+14. **模块独立部署指南.md** - 详细说明模块化售卖
+
+---
+
+## 🎯 下一步行动建议
+
+### 建议1：明确开发阶段
+
+根据技术架构白皮书的分阶段实施路线图：
+
+**阶段一（0-6个月）：云端MVP - "模块化单体"**
+- ✅ 可以继续使用现有架构（Node.js + Fastify + PostgreSQL）
+- ⚠️ 但必须严格遵循"代码隔离"和"数据隔离"（Schema隔离）
+- ❌ 暂不开发Electron单机版和私有化部署
+
+**阶段二（6-18个月）：首次拆分**
+- 引入K8s和API网关
+- 拆分SSA和DC为独立微服务
+- 开发Electron单机版
+
+### 建议2：模块开发优先级
+
+基于商业价值和技术复杂度：
+
+**第一优先级（核心差异化）：**
+1. **DC模块（数据清洗整理）** - 核心难点，差异化竞争力
+2. **ASL模块（AI智能文献）** - 已有PRD，可快速推进
+
+**第二优先级（完善产品矩阵）：**
+3. **SSA模块（智能统计分析）** - 需要R语言团队
+4. **ST模块（统计分析工具）** - 相对简单
+
+**第三优先级（已完成）：**
+5. AIA模块（AI智能回答） - ✅ 已完成
+6. PKB模块（个人知识库） - ✅ 已完成
+7. UAM模块（个人中心） - ✅ 已完成
+
+### 建议3：文档更新策略
+
+**立即行动（本周）：**
+1. 创建 `系统总体架构设计.md`（基于白皮书）
+2. 创建 `部署架构设计.md`（4种部署模式）
+3. 更新 `数据库设计文档.md`（补充新模块表结构）
+
+**近期行动（本月）：**
+4. 创建 `DC模块PRD.md`
+5. 创建 `SSA模块PRD.md`
+6. 创建 `Electron单机版技术方案.md`
+
+**持续行动：**
+7. 随着开发进展，持续更新API设计、前端架构等文档
+
+### 建议4：技术选型确认
+
+**需要与团队确认的关键技术决策：**
+
+1. **是否引入R语言？**
+   - SSA模块需要R语言（统计分析的王者）
+   - 需要评估团队能力和学习成本
+
+2. **是否引入Python微服务？**
+   - DC模块需要Python + Polars/Pandas
+   - 需要评估与现有Node.js架构的集成复杂度
+
+3. **是否立即规划Electron单机版？**
+   - 白皮书建议在阶段二（6-18个月）开发
+   - 需要确认市场需求的紧迫性
+
+4. **是否立即引入K8s？**
+   - 白皮书建议在阶段二引入
+   - 阶段一可以继续使用Docker Compose
+
+---
+
+## 📌 总结
+
+### 核心问题
+
+**旧版文档与最新需求的核心差异：**
+
+1. **产品范围扩大：** 从3个模块扩展到7个模块
+2. **部署模式复杂化：** 从单一云端SaaS扩展到4种部署形态
+3. **技术架构演进：** 从模块化单体演进到微服务架构
+4. **商业模式升级：** 从简单订阅到模块化售卖 + 多版本 + 多部署
+
+### 关键建议
+
+**务实的推进策略：**
+
+1. **阶段一（当前）：** 继续使用现有架构，专注于**云端SaaS版**的7大模块开发
+2. **严格纪律：** 必须遵循"代码隔离"和"数据Schema隔离"，为未来拆分打基础
+3. **优先级：** 先开发DC和ASL模块（差异化竞争力）
+4. **文档先行：** 立即更新P0级文档，指导后续开发
+
+**避免过度设计：**
+
+- ❌ 不要在阶段一就引入K8s和API网关（增加复杂度）
+- ❌ 不要在阶段一就开发Electron单机版（分散精力）
+- ✅ 专注于云端SaaS版的功能完善和市场验证
+- ✅ 为未来的架构演进打好基础（代码和数据隔离）
+
+---
+
+**文档维护者：** 项目团队  
+**最后更新：** 2025-11-06  
+**下次审查：** 2025-11-13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
--- a/docs/00-项目概述/最新需求与技术方案深度评估.md
+++ b/docs/00-项目概述/最新需求与技术方案深度评估.md
--- a/docs/00-项目概述/现有系统技术摸底报告.md
+++ b/docs/00-项目概述/现有系统技术摸底报告.md
--- a/docs/00-项目概述/系统总体架构设计.md
+++ b/docs/00-项目概述/系统总体架构设计.md
@@ -0,0 +1,50 @@
+# 系统总体架构设计
+
+> **文档版本：** v1.0  
+> **创建日期：** 2025-10-29  
+> **维护者：** 架构团队  
+> **最后更新：** 2025-10-29
+
+---
+
+## 📋 文档说明
+
+本文档描述AI科研平台的系统总体架构设计，包括：
+- 整体系统架构
+- 用户端架构
+- 运营管理端架构
+- 部署架构
+- 模块化设计
+- 安全性设计
+
+---
+
+## ⏳ 待完善
+
+本文档内容待规划完善，目前仅作为占位文档。
+
+---
+
+**文档版本：** v1.0  
+**最后更新：** 2025-10-29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+