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
4.8 KiB
4.8 KiB
PRD：Tool B - 病历结构化机器人 (The AI Structurer)
| 文档版本 | V2.0 (双模型交叉验证版) |
| 产品形态 | Web 端工具（批处理 + 全景验证网格） |
| 核心价值 | 利用 双大模型（DeepSeek & Qwen）交叉验证 技术，将非结构化病历文本转化为高可信度的结构化数据，解决 AI 幻觉问题。 |
| 目标用户 | 需要处理出院小结、病理报告的医生（对数据准确性要求极高） |
一、 产品流程图 (User Flow)
数据导入(上传/流转) -> 健康体检 -> 智能模版配置 -> 双盲提取与交叉验证 -> 全景网格裁决 -> 结果导出
二、 核心功能需求 (Functional Requirements)
1. 步骤一：数据装载与体检 (Injection & Health Check)
- P0: 数据源接入： 支持本地 Excel 上传，或接收来自工具 A 的流转文件。
- P0: 智能体检 (Health Check)：
- 用户选定“文本源列”后，系统立即扫描前 100 行。
- 拦截规则： 若空值率 > 80% 或平均字符数 < 10，提示“该列不适合提取”，防止误操作浪费 Token。
- 成本预估： 根据字符数实时预估 Token 消耗量。
2. 步骤二：智能模版配置 (Smart Schema) —— V2 核心升级
- P0: 场景化模版选择：
- 一级分类（疾病）： 肺癌、高血压、糖尿病等。
- 二级分类（报告）： 病理报告、入院记录、门诊病历、手术记录。
- P0: 动态字段定义：
- 选择模版后，自动加载预设字段列表（如“肺癌病理”自动加载：肿瘤大小、淋巴结转移、分化程度）。
- 支持用户手动 增/删/改 字段定义。
- P1: Prompt 预览： 实时展示系统将发送给 AI 的 Prompt 结构，增强专业用户信任感。
3. 步骤三：双盲提取引擎 (Double-Blind Extraction) —— V2 核心升级
- P0: 双模型并发：
- 系统同时调用 DeepSeek-V3 (Model A) 和 Qwen-Max (Model B) 对同一段文本进行提取。
- P0: 交叉验证算法 (Cross-Validation)：
- 完全一致： 若 A 与 B 结果相同，标记为 Clean (可信)。
- 冲突： 若 A 与 B 结果不同，标记为 Conflict (待裁决)。
- P0: 隐私脱敏： 强制执行 PII 脱敏（正则替换姓名、身份证号）。
4. 步骤四：全景验证网格 (Verification Grid) —— 交互重构
不再使用单条划动的 Tinder 模式，改为更高效的 Excel 列表模式。
- P0: 验证列表 (The Grid)：
- 列结构： 序号 | 原文摘要 | [字段1] | [字段2] ... | 状态。
- 原文列： 显示前 50 字，鼠标悬停显示 Tooltip。
- P0: 冲突可视化与裁决：
- 一致单元格： 显示绿色/白色背景，展示单一值。
- 冲突单元格： 背景标黄/红。内部并列显示
DS: 值A
与QW: 值B
。 - 一键采纳： 用户点击 A 或 B，该值即被采纳，单元格转为已解决状态。支持双击手动输入修正。
- P0: 侧边栏原文 (Context Drawer)：
- 点击表格任一行，右侧滑出侧边栏。
- 展示病历全文，方便用户溯源核对。
- P1: 批量操作： 支持“剩余冲突全部采纳 Model A”或“导出当前进度”。
5. 结果输出
- P0: 导出 Excel： 包含最终采纳的结构化数据。
- P0: 流转到编辑器： 一键发送到 工具 C 进行后续清洗（如缺失值填补）。
三、 界面原型概念 (UI Sketch)
- 体检页： 选中列后显示红绿灯卡片：“健康度优秀，预计消耗 45k Token”。
- 配置页： 下拉选择“肺癌”+“病理报告”，下方自动列出 5 个关键指标。
- 处理页： 进度环显示“双模型提取中...”，下方日志滚动“DeepSeek 完成... Qwen 完成... 正在交叉比对”。
- 验证页 (核心)：
- 顶部：统计条“共 100 条，发现 12 条冲突”。
- 主体：类 Excel 表格。冲突单元格内有两个按钮供选择。
- 侧边栏：展示当前行的完整病历文本。
四、 技术可行性与约束
- 模型选型：
- 主模型 (Model A)： DeepSeek-V3 (性价比高，擅长中文医疗)。
- 辅助模型 (Model B)： Qwen-Max 或 GPT-4o-mini (用于校验)。
- 冲突判定逻辑：
- 字符串完全匹配或基于语义相似度（Embedding Cosine Similarity > 0.95）判定为一致。
- 数值提取需进行单位归一化后再比对（如 3cm vs 3.0 cm 视为一致）。
- 性能要求： 双倍 API 调用会导致成本和时间增加，需在界面上明确告知用户并显示进度。