HaHafeng
66255368b7
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
112 lines
6.5 KiB
Markdown
112 lines
6.5 KiB
Markdown
# **壹证循科技 \- 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%不出内网。 |
|
||
| **单机版** | (个人医生) 提供**可安装的桌面应用(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），在保护隐私的前提下尽力提高准确率。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|