feat(admin): Add user management and upgrade to module permission system

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
2026-01-16 13:42:10 +08:00
parent 98d862dbd4
commit 66255368b7
560 changed files with 70424 additions and 52353 deletions
--- a/Agent/07-技术债务/IIT
+++ b/Agent/07-技术债务/IIT
@@ -1,31 +1,31 @@
 # IIT Manager Agent 技术债务清单

 **文档版本**: v1.0  
-**鏈€鍚庢洿鏂?*: 2026-01-04  
+**最后更新**: 2026-01-04  
 **当前阶段**: Phase 1.5 完成

 ---

 ## 📋 文档说明

-鏈<EFBFBD>枃妗ｈ<EFBFBD>褰旾IT Manager Agent妯″潡鐨勬妧鏈<EFBFBD>€哄姟锛屽寘鎷<EFBFBD>綋鍓嶇殑涓存椂鏂规<EFBFBD>銆佸凡鐭ラ檺鍒躲€佸緟浼樺寲椤癸紝浠ュ強鏈<EFBFBD>潵鏀硅繘璁″垝銆?
+本文档记录IIT Manager Agent模块的技术债务，包括当前的临时方案、已知限制、待优化项，以及未来改进计划。

 ---

-## 馃幆 鎶€鏈<E282AC>€哄姟浼樺厛绾у畾涔?
+## 🎯 技术债务优先级定义

-| 浼樺厛绾?| 璇存槑 | 澶勭悊鏃舵満 |
+| 优先级 | 说明 | 处理时机 |
 |-------|------|---------|
-| **P0 - 闃诲<EFBFBD>鎬?* | 褰卞搷鏍稿績鍔熻兘锛屽繀椤荤珛鍗冲<E98D97>鐞?| 绔嬪嵆 |
-| **P1 - 楂樹紭鍏堢骇** | 褰卞搷鐢ㄦ埛浣撻獙鎴栨€ц兘锛屽缓璁甈hase 2澶勭悊 | 1涓<EFBFBD>湀鍐?|
-| **P2 - 涓<EFBFBD>紭鍏堢骇** | 鍔熻兘澧炲己锛屽彲鍦≒hase 3澶勭悊 | 3涓<EFBFBD>湀鍐?|
-| **P3 - 浣庝紭鍏堢骇** | 浼樺寲椤癸紝闀挎湡瑙勫垝 | 6涓<36>湀鍐?|
+| **P0 - 阻塞性** | 影响核心功能，必须立即处理 | 立即 |
+| **P1 - 高优先级** | 影响用户体验或性能，建议Phase 2处理 | 1个月内 |
+| **P2 - 中优先级** | 功能增强，可在Phase 3处理 | 3个月内 |
+| **P3 - 低优先级** | 优化项，长期规划 | 6个月内 |

 ---

 ## 🔴 P0 - 阻塞性债务

-**褰撳墠鐘舵€?*: 鉁?鏃燩0绾у€哄姟
+**当前状态**: ✅ 无P0级债务

 ---

@@ -42,7 +42,7 @@

 **影响**:
 - 当用户使用非标准表达时，可能无法正确识别意图
- 渚嬪<EFBFBD>锛?甯<>垜鐪嬩竴涓嬮偅涓?鍙风殑鏁版嵁" 鍙<>兘鏃犳硶璇嗗埆涓篳query_record`
+- 例如："帮我看一下那个7号的数据" 可能无法识别为`query_record`

 **改进方案**:

@@ -51,12 +51,12 @@
 // 使用LLM进行意图分类
 const intentPrompt = `你是意图识别专家。用户消息：${userMessage}

-璇峰垽鏂<EFBFBD>敤鎴锋剰鍥撅紝浠庝互涓嬮€夐」涓<EFBFBD>€夋嫨锛?
-1. query_record - 鏌ヨ<EFBFBD>鐗瑰畾鎮ｈ€呰<EFBFBD>褰?
-2. count_records - 缁熻<EFBFBD>鎮ｈ€呮暟閲?
+请判断用户意图，从以下选项中选择：
+1. query_record - 查询特定患者记录
+2. count_records - 统计患者数量
 3. query_protocol - 查询研究方案文档
 4. project_info - 查询项目信息
-5. general_chat - 鏅<EFBFBD>€氬<EFBFBD>璇?
+5. general_chat - 普通对话

 只返回JSON: {"intent": "xxx", "params": {...}}
 `;
@@ -65,13 +65,13 @@ const intentResult = await llm.chat([{ role: 'user', content: intentPrompt }]);
 ```

 **优势**:
- 鉁?鐞嗚В鑳藉姏寮猴紝鏀<E7B49D>寔澶嶆潅琛ㄨ揪
- 鉁?鏃犻渶缁存姢鍏抽敭璇?
- 鉁?閫傚簲鎬уソ
+- ✅ 理解能力强，支持复杂表达
+- ✅ 无需维护关键词
+- ✅ 适应性好

 **劣势**:
- 鉂?澧炲姞涓€娆<E282AC>LM璋冪敤锛垀1绉掞紝+楼0.0001鎴愭湰锛?
- 鉂?鎬诲搷搴旀椂闂村<E99782>鍔犲埌~6绉?
+- ❌ 增加一次LLM调用（~1秒，+¥0.0001成本）
+- ❌ 总响应时间增加到~6秒

 **方案B: BERT分类模型**
 ```python
@@ -83,36 +83,36 @@ model = BertForSequenceClassification.from_pretrained(
    num_labels=5
 )

-# 璁<EFBFBD>粌鏁版嵁锛?00-200涓<30>爣娉ㄦ牱鏈?
-# 鎺ㄧ悊閫熷害锛?100ms
+# 训练数据：100-200个标注样本
+# 推理速度：<100ms
 ```

 **优势**:
- 鉁?閫熷害蹇<E5AEB3>紙<100ms锛?
- 鉁?鐞嗚В鑳藉姏寮?
- 鉁?鎴愭湰浣?
+- ✅ 速度快（<100ms）
+- ✅ 理解能力强
+- ✅ 成本低

 **劣势**:
- 鉂?闇€瑕佹爣娉ㄨ<E5A889>缁冩暟鎹?
- 鉂?闇€瑕侀儴缃叉ā鍨嬫湇鍔?
- 鉂?闇€瑕佹寔缁<E5AF94>凯浠?
+- ❌ 需要标注训练数据
+- ❌ 需要部署模型服务
+- ❌ 需要持续迭代

 **建议**:
- Phase 2: 鍏堜娇鐢ㄦ柟妗圓锛圠LM鍒ゆ柇锛夛紝蹇<EFBFBD>€熼獙璇佹晥鏋?
- Phase 3: 濡傛灉閲忓ぇ锛屽啀鍒囨崲鍒版柟妗圔锛圔ERT妯″瀷锛?
+- Phase 2: 先使用方案A（LLM判断），快速验证效果
+- Phase 3: 如果量大，再切换到方案B（BERT模型）

-**棰勮<EFBFBD>宸ヤ綔閲?*: 2-3澶?
+**预计工作量**: 2-3天

 ---

 ### 2. 上下文存储迁移到Redis

-**褰撳墠鏂规<EFBFBD>**: 鍐呭瓨缂撳瓨锛圢ode.js Map锛?
+**当前方案**: 内存缓存（Node.js Map）

 **问题**:
- 鈿狅笍 鍗曟満鍐呭瓨锛屼笉鏀<E7AC89>寔鍒嗗竷寮忛儴缃?
+- ⚠️ 单机内存，不支持分布式部署
 - ⚠️ 服务重启后上下文丢失
- 鈿狅笍 鍐呭瓨鍗犵敤鏃犻檺鍒讹紙铏芥湁鑷<E6B981>姩娓呯悊锛屼絾浠嶆湁椋庨櫓锛?
+- ⚠️ 内存占用无限制（虽有自动清理，但仍有风险）

 **影响**:
 - 当后端服务重启时，所有用户的对话上下文会丢失
@@ -144,12 +144,12 @@ export class SessionMemory {
    // 2. 添加消息
    session.messages.push(message);
    
-    // 3. 淇濇寔鏈€杩?杞?
+    // 3. 保持最近3轮
    if (session.messages.length > 6) {
      session.messages = session.messages.slice(-6);
    }
    
-    // 4. 瀛樺洖Redis锛?0鍒嗛挓杩囨湡锛?
+    // 4. 存回Redis（30分钟过期）
    await this.redis.setex(key, this.EXPIRE_TIME, JSON.stringify(session));
  }

@@ -168,54 +168,54 @@ export class SessionMemory {
 ```

 **优势**:
- 鉁?鏀<>寔鍒嗗竷寮忛儴缃?
- 鉁?鏈嶅姟閲嶅惎涓嶄涪澶变笂涓嬫枃
- 鉁?鍐呭瓨鍗犵敤鍙<E695A4>帶
+- ✅ 支持分布式部署
+- ✅ 服务重启不丢失上下文
+- ✅ 内存占用可控

 **劣势**:
- 鉂?澧炲姞Redis渚濊禆
- 鉂?姣忔<E5A7A3>璇诲啓闇€瑕佺綉缁淚O锛垀1-2ms锛?
+- ❌ 增加Redis依赖
+- ❌ 每次读写需要网络IO（~1-2ms）

 **建议**: Phase 2实施，优先级中高

-**棰勮<EFBFBD>宸ヤ綔閲?*: 1澶?
+**预计工作量**: 1天

 ---

-### 3. Dify妫€绱㈢粨鏋滅紦瀛?
+### 3. Dify检索结果缓存

-**褰撳墠鏂规<EFBFBD>**: 姣忔<EFBFBD>閮借皟鐢―ify API妫€绱?
+**当前方案**: 每次都调用Dify API检索

 **问题**:
 - ⚠️ 相同问题重复检索，浪费时间
- 鈿狅笍 Dify API鍝嶅簲鏃堕棿鍗?0%锛?.5-1.7绉掞級
+- ⚠️ Dify API响应时间占30%（1.5-1.7秒）

 **影响**:
- 鍝嶅簲閫熷害鏈夋彁鍗囩┖闂?
- 鐩稿悓闂<EFBFBD><EFBFBD>绗<EFBFBD>簩娆¤<EFBFBD>闂<EFBFBD>粛闇€1.5绉?
+- 响应速度有提升空间
+- 相同问题第二次询问仍需1.5秒

 **改进方案**:

 ```typescript
-// 浣跨敤Redis缂撳瓨Dify妫€绱㈢粨鏋?
+// 使用Redis缓存Dify检索结果
 private async queryDifyKnowledge(query: string): Promise<string> {
-  // 1. 鐢熸垚缂撳瓨key锛坬uery鐨刪ash锛?
+  // 1. 生成缓存key（query的hash）
  const cacheKey = `dify:${md5(query)}`;
  
-  // 2. 灏濊瘯浠庣紦瀛樿幏鍙?
+  // 2. 尝试从缓存获取
  const cached = await redis.get(cacheKey);
  if (cached) {
-    logger.info('Dify妫€绱㈠懡涓<EFBFBD>紦瀛?, { query });
+    logger.info('Dify检索命中缓存', { query });
    return cached;
  }
  
  // 3. 调用Dify API
  const result = await difyClient.retrieveKnowledge(...);
  
-  // 4. 鏍煎紡鍖栫粨鏋?
+  // 4. 格式化结果
  const formattedKnowledge = this.formatDifyResult(result);
  
-  // 5. 缂撳瓨缁撴灉锛?灏忔椂锛?
+  // 5. 缓存结果（1小时）
  await redis.setex(cacheKey, 3600, formattedKnowledge);
  
  return formattedKnowledge;
@@ -223,21 +223,21 @@ private async queryDifyKnowledge(query: string): Promise<string> {
 ```

 **优势**:
- 鉁?鐩稿悓闂<E68293><E99782>鍝嶅簲閫熷害鎻愬崌1.5绉掞紙浠?.8绉掗檷鍒?.3绉掞級
- 鉁?鍑忓皯Dify API璋冪敤娆℃暟
- 鉁?闄嶄綆Dify鏈嶅姟鍣ㄨ礋杞?
+- ✅ 相同问题响应速度提升1.5秒（从4.8秒降到3.3秒）
+- ✅ 减少Dify API调用次数
+- ✅ 降低Dify服务器负载

 **劣势**:
- 鉂?鏂囨。鏇存柊鍚庨渶瑕佹竻闄ょ紦瀛?
- 鉂?缂撳瓨鍗犵敤Redis鍐呭瓨
+- ❌ 文档更新后需要清除缓存
+- ❌ 缓存占用Redis内存

 **缓存失效策略**:
- 鏂囨。涓婁紶/鏇存柊/鍒犻櫎鏃讹紝娓呴櫎瀵瑰簲Dataset鐨勬墍鏈夌紦瀛?
- 缂撳瓨杩囨湡鏃堕棿锛?灏忔椂
+- 文档上传/更新/删除时，清除对应Dataset的所有缓存
+- 缓存过期时间：1小时

-**寤鸿<EFBFBD>**: Phase 2瀹炴柦锛屼紭鍏堢骇涓?
+**建议**: Phase 2实施，优先级中

-**棰勮<EFBFBD>宸ヤ綔閲?*: 1澶?
+**预计工作量**: 1天

 ---

@@ -246,12 +246,12 @@ private async queryDifyKnowledge(query: string): Promise<string> {
 **当前方案**: 每次都调用REDCap API查询

 **问题**:
- 鈿狅笍 REDCap API鍝嶅簲鏃堕棿鍗?5%锛?.2-1.3绉掞級
- 鈿狅笍 鎮ｈ€呭熀鏈<E78680>俊鎭<E4BF8A>彉鍖栭<E98D96>鐜囦綆锛屼笉闇€瑕佹瘡娆″疄鏃舵煡璇?
+- ⚠️ REDCap API响应时间占25%（1.2-1.3秒）
+- ⚠️ 患者基本信息变化频率低，不需要每次实时查询

 **影响**:
- 鍝嶅簲閫熷害鏈夋彁鍗囩┖闂?
- 澧炲姞REDCap鏈嶅姟鍣ㄨ礋杞?
+- 响应速度有提升空间
+- 增加REDCap服务器负载

 **改进方案**:

@@ -260,7 +260,7 @@ private async queryDifyKnowledge(query: string): Promise<string> {
 private async queryRedcapRecord(recordId: string): Promise<any> {
  const cacheKey = `redcap:record:${recordId}`;
  
-  // 1. 灏濊瘯浠庣紦瀛樿幏鍙?
+  // 1. 尝试从缓存获取
  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
@@ -269,7 +269,7 @@ private async queryRedcapRecord(recordId: string): Promise<any> {
  // 2. 调用REDCap API
  const records = await redcap.exportRecords({ records: [recordId] });
  
-  // 3. 缂撳瓨缁撴灉锛?鍒嗛挓锛?
+  // 3. 缓存结果（5分钟）
  await redis.setex(cacheKey, 300, JSON.stringify(records[0]));
  
  return records[0];
@@ -280,37 +280,37 @@ private async queryRedcapRecord(recordId: string): Promise<any> {

 | 数据类型 | 缓存时间 | 原因 |
 |---------|---------|------|
-| 鎮ｈ€呭熀鏈<EFBFBD>俊鎭?| 5鍒嗛挓 | 鍙樺寲棰戠巼浣?|
+| 患者基本信息 | 5分钟 | 变化频率低 |
 | 统计数据 | 1分钟 | 需要较实时 |
 | 项目配置 | 1小时 | 几乎不变 |

 **优势**:
- 鉁?鍝嶅簲閫熷害鎻愬崌1.2绉?
- 鉁?鍑忓皯REDCap鏈嶅姟鍣ㄨ礋杞?
+- ✅ 响应速度提升1.2秒
+- ✅ 减少REDCap服务器负载

 **劣势**:
- 鉂?鏁版嵁鍙<E5B581>兘鏈?鍒嗛挓寤惰繜
+- ❌ 数据可能有5分钟延迟

-**寤鸿<EFBFBD>**: Phase 2瀹炴柦锛岄渶涓庣敤鎴风‘璁ゆ槸鍚︽帴鍙?鍒嗛挓寤惰繜
+**建议**: Phase 2实施，需与用户确认是否接受5分钟延迟

-**棰勮<EFBFBD>宸ヤ綔閲?*: 1澶?
+**预计工作量**: 1天

 ---

 ## 🟡 P2 - 中优先级债务

-### 5. 鏂囨。涓婁紶API寮€鍙?
+### 5. 文档上传API开发

 **当前方案**: 手动通过Dify界面上传文档

 **问题**:
- 鈿狅笍 涓嶆敮鎸佹壒閲忎笂浼?
+- ⚠️ 不支持批量上传
 - ⚠️ 需要登录Dify系统
- 鈿狅笍 鏃犳硶鑷<E7A1B6>姩鍖?
+- ⚠️ 无法自动化

 **影响**:
 - PI无法自助上传研究文档
- 闇€瑕佹妧鏈<EFBFBD>汉鍛樺崗鍔?
+- 需要技术人员协助

 **改进方案**:

@@ -359,24 +359,24 @@ router.get('/projects/:projectId/documents', async (request, reply) => {
 **前端界面**（可选）:
 - 文档上传表单
 - 文档列表展示
- 鏂囨。鐘舵€佽拷韪<EFBFBD>紙uploading 鈫?indexing 鈫?completed锛?
+- 文档状态追踪（uploading → indexing → completed）

-**寤鸿<EFBFBD>**: Phase 3瀹炴柦锛屼紭鍏堢骇涓?
+**建议**: Phase 3实施，优先级中

-**棰勮<EFBFBD>宸ヤ綔閲?*: 2-3澶?
+**预计工作量**: 2-3天

 ---

 ### 6. 用户绑定默认项目

-**褰撳墠鏂规<EFBFBD>**: 鎵€鏈夌敤鎴峰叡浜<EFBFBD>悓涓€涓<EFBFBD>椿璺冮」鐩<EFBFBD>紙`status='active'`锛?
+**当前方案**: 所有用户共享同一个活跃项目（`status='active'`）

 **问题**:
- 鈿狅笍 鏃犳硶鏀<E7A1B6>寔澶氶」鐩?
+- ⚠️ 无法支持多项目
 - ⚠️ 不同用户可能关注不同项目

 **影响**:
- 濡傛灉鏈夊<EFBFBD>涓狪IT椤圭洰锛屾棤娉曞尯鍒嗙敤鎴峰睘浜庡摢涓<EFBFBD>」鐩?
+- 如果有多个IIT项目，无法区分用户属于哪个项目

 **改进方案**:

@@ -395,7 +395,7 @@ model IitUserMapping {
 **ChatService更新**:
 ```typescript
 async handleMessage(userId: string, userMessage: string): Promise<string> {
-  // 1. 鑾峰彇鐢ㄦ埛鐨勯粯璁ら」鐩?
+  // 1. 获取用户的默认项目
  const userMapping = await prisma.iitUserMapping.findFirst({
    where: { wecomUserId: userId }
  });
@@ -413,24 +413,24 @@ async handleMessage(userId: string, userMessage: string): Promise<string> {

 **建议**: Phase 2后期实施，当有多个项目时

-**棰勮<EFBFBD>宸ヤ綔閲?*: 1-2澶?
+**预计工作量**: 1-2天

 ---

 ### 7. Function Calling升级

-**褰撳墠鏂规<EFBFBD>**: 鍏抽敭璇嶆剰鍥捐瘑鍒?鈫?鎵嬪姩璋冪敤宸ュ叿
+**当前方案**: 关键词意图识别 → 手动调用工具

 **问题**:
 - ⚠️ 无法自动决定是否调用工具
- 鈿狅笍 鏃犳硶鏍规嵁涓婁笅鏂囪嚜鍔ㄦ彁鍙栧弬鏁?
+- ⚠️ 无法根据上下文自动提取参数

 **影响**:
- 濡傛灉鐢ㄦ埛闂?7鍙锋偅鑰呭拰8鍙锋偅鑰呭摢涓<E691A2>洿涓ラ噸锛?锛屽綋鍓嶆棤娉曡嚜鍔ㄦ煡璇<E785A1>袱涓<E8A2B1>偅鑰?
+- 如果用户问"7号患者和8号患者哪个更严重？"，当前无法自动查询两个患者

 **改进方案**:

-浣跨敤DeepSeek-V3鐨?*Native Function Calling**:
+使用DeepSeek-V3的**Native Function Calling**:

 ```typescript
 // 定义工具
@@ -456,7 +456,7 @@ const tools = [
    type: 'function',
    function: {
      name: 'query_dify_knowledge',
-      description: '妫€绱㈢爺绌舵柟妗堛€丆RF琛ㄦ牸绛夋枃妗?,
+      description: '检索研究方案、CRF表格等文档',
      parameters: {
        type: 'object',
        properties: {
@@ -487,24 +487,24 @@ if (response.tool_calls) {
 ```

 **优势**:
- 鉁?LLM鑷<EFBFBD>姩鍐冲畾鏄<EFBFBD>惁璋冪敤宸ュ叿
- 鉁?鑷<>姩鎻愬彇鍙傛暟锛堝<E9949B>recordId锛?
- 鉁?鏀<>寔澶氬伐鍏峰苟琛岃皟鐢?
- 鉁?鏇存櫤鑳姐€佹洿鐏垫椿
+- ✅ LLM自动决定是否调用工具
+- ✅ 自动提取参数（如recordId）
+- ✅ 支持多工具并行调用
+- ✅ 更智能、更灵活

 **劣势**:
- 鉂?澧炲姞涓€娆<E282AC>LM璋冪敤
- 鉂?鎬诲搷搴旀椂闂村彲鑳藉<E991B3>鍔犲埌7-8绉?
+- ❌ 增加一次LLM调用
+- ❌ 总响应时间可能增加到7-8秒

-**寤鸿<EFBFBD>**: Phase 3瀹炴柦锛屼綔涓洪珮绾у姛鑳?
+**建议**: Phase 3实施，作为高级功能

-**棰勮<EFBFBD>宸ヤ綔閲?*: 3-5澶?
+**预计工作量**: 3-5天

 ---

 ### 8. 智能引用系统

-**褰撳墠鏂规<EFBFBD>**: Dify杩斿洖鐨勬枃妗ｇ墖娈电洿鎺ユ樉绀?
+**当前方案**: Dify返回的文档片段直接显示

 **问题**:
 - ⚠️ 无法溯源到具体文档和位置
@@ -527,27 +527,27 @@ interface Citation {
  content: string;
 }

-// 2. AI鍥炵瓟涓<EFBFBD>彃鍏ュ紩鐢ㄦ爣璁?
+// 2. AI回答中插入引用标记
 const answer = `根据研究方案[1]和CRF表格[2]，纳入标准包括：
 1. 年龄18-75岁[1]
 2. 符合诊断标准[1][2]
 3. 签署知情同意书[3]

 ---
-馃摎 **鍙傝€冩枃鐚?*
-[1] 馃搫 **鐮旂┒鏂规<EFBFBD>.pdf** - 绗?娈?(鐩稿叧搴?5%)
-    "绾冲叆鏍囧噯锛氬勾榫?8-75宀侊紝绗﹀悎璇婃柇鏍囧噯..."
-[2] 馃搫 **CRF琛ㄦ牸.docx** - 绗?娈?(鐩稿叧搴?2%)
-    "鍩虹嚎璇勪及鍖呮嫭锛氳瘖鏂<EFBFBD>爣鍑嗐€佸叆缁勬椂闂?.."
+📚 **参考文献**
+[1] 📄 **研究方案.pdf** - 第3段 (相关度95%)
+    "纳入标准：年龄18-75岁，符合诊断标准..."
+[2] 📄 **CRF表格.docx** - 第5段 (相关度92%)
+    "基线评估包括：诊断标准、入组时间..."
 `;

 // 3. 前端高亮显示引用
-// 鐐瑰嚮[1]璺宠浆鍒板紩鐢ㄨ<E990A2>鎯?
+// 点击[1]跳转到引用详情
 ```

-**寤鸿<EFBFBD>**: Phase 3瀹炴柦锛屼綔涓轰綋楠屼紭鍖?
+**建议**: Phase 3实施，作为体验优化

-**棰勮<EFBFBD>宸ヤ綔閲?*: 3-4澶?
+**预计工作量**: 3-4天

 ---

@@ -558,7 +558,7 @@ const answer = `根据研究方案[1]和CRF表格[2]，纳入标准包括：
 **当前方案**: 单条记录查询

 **问题**:
- 鈿狅笍 濡傛灉鐢ㄦ埛闂?鎵€鏈夋偅鑰呯殑鍏ョ粍鎯呭喌"锛岄渶瑕佸<E79195>娆℃煡璇?
+- ⚠️ 如果用户问"所有患者的入组情况"，需要多次查询

 **改进方案**:
 - 支持批量查询
@@ -566,68 +566,68 @@ const answer = `根据研究方案[1]和CRF表格[2]，纳入标准包括：

 **建议**: Phase 4实施

-**棰勮<EFBFBD>宸ヤ綔閲?*: 2-3澶?
+**预计工作量**: 2-3天

 ---

 ### 10. 多轮对话优化

-**褰撳墠鏂规<EFBFBD>**: 淇濈暀鏈€杩?杞<><E69D9E>璇?
+**当前方案**: 保留最近3轮对话

 **问题**:
 - ⚠️ 长对话可能丢失重要上下文

 **改进方案**:
- 鏅鸿兘涓婁笅鏂囧帇缂╋紙鎻愬彇鍏抽敭淇℃伅锛?
+- 智能上下文压缩（提取关键信息）
 - 长期记忆（存储重要信息到数据库）

 **建议**: Phase 4实施

-**棰勮<EFBFBD>宸ヤ綔閲?*: 5-7澶?
+**预计工作量**: 5-7天

 ---

 ## 📊 债务优先级总览

-| 鍊哄姟椤?| 浼樺厛绾?| 褰卞搷 | 宸ヤ綔閲?| 寤鸿<E5AFA4>鏃堕棿 |
+| 债务项 | 优先级 | 影响 | 工作量 | 建议时间 |
 |-------|--------|------|--------|----------|
-| 鎰忓浘璇嗗埆鍗囩骇 | P1 | 鍑嗙‘鐜?| 2-3澶?| Phase 2 |
-| 涓婁笅鏂囪縼绉籖edis | P1 | 鍙<EFBFBD>敤鎬?| 1澶?| Phase 2 |
-| Dify缁撴灉缂撳瓨 | P1 | 鎬ц兘 | 1澶?| Phase 2 |
-| REDCap鏁版嵁缂撳瓨 | P1 | 鎬ц兘 | 1澶?| Phase 2 |
-| 鏂囨。涓婁紶API | P2 | 鍔熻兘 | 2-3澶?| Phase 3 |
-| 鐢ㄦ埛缁戝畾椤圭洰 | P2 | 鍔熻兘 | 1-2澶?| Phase 2鍚庢湡 |
-| Function Calling | P2 | 鏅鸿兘鍖?| 3-5澶?| Phase 3 |
-| 鏅鸿兘寮曠敤绯荤粺 | P2 | 浣撻獙 | 3-4澶?| Phase 3 |
-| 鎵归噺鏌ヨ<EFBFBD>浼樺寲 | P3 | 鍔熻兘 | 2-3澶?| Phase 4 |
-| 澶氳疆瀵硅瘽浼樺寲 | P3 | 浣撻獙 | 5-7澶?| Phase 4 |
+| 意图识别升级 | P1 | 准确率 | 2-3天 | Phase 2 |
+| 上下文迁移Redis | P1 | 可用性 | 1天 | Phase 2 |
+| Dify结果缓存 | P1 | 性能 | 1天 | Phase 2 |
+| REDCap数据缓存 | P1 | 性能 | 1天 | Phase 2 |
+| 文档上传API | P2 | 功能 | 2-3天 | Phase 3 |
+| 用户绑定项目 | P2 | 功能 | 1-2天 | Phase 2后期 |
+| Function Calling | P2 | 智能化 | 3-5天 | Phase 3 |
+| 智能引用系统 | P2 | 体验 | 3-4天 | Phase 3 |
+| 批量查询优化 | P3 | 功能 | 2-3天 | Phase 4 |
+| 多轮对话优化 | P3 | 体验 | 5-7天 | Phase 4 |

 ---

 ## 🎯 Phase 2 债务清偿计划

 ### Week 1-2: 性能优化
- [ ] 涓婁笅鏂囪縼绉诲埌Redis锛?澶╋級
- [ ] Dify缁撴灉缂撳瓨锛?澶╋級
- [ ] REDCap鏁版嵁缂撳瓨锛?澶╋級
+- [ ] 上下文迁移到Redis（1天）
+- [ ] Dify结果缓存（1天）
+- [ ] REDCap数据缓存（1天）
 - [ ] 性能测试与调优（1天）

 **预期效果**:
- 鍝嶅簲鏃堕棿浠?.8绉掗檷鍒?-3绉?
- 鏀<EFBFBD>寔鍒嗗竷寮忛儴缃?
+- 响应时间从4.8秒降到2-3秒
+- 支持分布式部署
 - 服务重启不丢失上下文

 ### Week 3-4: 意图识别升级
- [ ] 瀹炵幇LLM鎰忓浘鍒ゆ柇锛?澶╋級
- [ ] A/B娴嬭瘯瀵规瘮锛?澶╋級
- [ ] 涓婄嚎鐏板害鍙戝竷锛?澶╋級
+- [ ] 实现LLM意图判断（2天）
+- [ ] A/B测试对比（1天）
+- [ ] 上线灰度发布（1天）

 **预期效果**:
- 鎰忓浘璇嗗埆鍑嗙‘鐜囦繚鎸?00%
+- 意图识别准确率保持100%
 - 支持复杂自然语言表达

-### Week 5: 澶氶」鐩<EFBFBD>敮鎸?
- [ ] 鐢ㄦ埛缁戝畾榛樿<EFBFBD>椤圭洰锛?澶╋級
+### Week 5: 多项目支持
+- [ ] 用户绑定默认项目（2天）

 **预期效果**:
 - 支持多个IIT项目并行
@@ -638,17 +638,17 @@ const answer = `根据研究方案[1]和CRF表格[2]，纳入标准包括：

 ### 已清偿债务

-| 鍊哄姟椤?| 娓呭伩鏃堕棿 | 鏂规<E98F82> |
+| 债务项 | 清偿时间 | 方案 |
 |-------|---------|------|
 | AI幻觉问题 | 2026-01-03 | RAG数据注入 + 严格System Prompt |
-| 涓婁笅鏂囦涪澶?| 2026-01-03 | SessionMemory锛堟渶杩?杞<>級 |
-| 鍝嶅簲閫熷害鎱?| 2026-01-04 | 浼樺寲鎰忓浘璇嗗埆 + 寮傛<E5AFAE>澶勭悊 |
+| 上下文丢失 | 2026-01-03 | SessionMemory（最近3轮） |
+| 响应速度慢 | 2026-01-04 | 优化意图识别 + 异步处理 |

 ### 进行中债务

-| 鍊哄姟椤?| 璐熻矗浜?| 棰勮<E6A3B0>瀹屾垚 |
+| 债务项 | 负责人 | 预计完成 |
 |-------|--------|----------|
-| 鏃?| - | - |
+| 无 | - | - |

 ### 待处理债务

@@ -658,17 +658,16 @@ const answer = `根据研究方案[1]和CRF表格[2]，纳入标准包括：

 ## 🔗 相关文档

- [IIT Manager Agent 鎶€鏈<EFBFBD>矾寰勪笌鏋舵瀯璁捐<EFBFBD>](../02-鎶€鏈<EFBFBD><EFBFBD>璁?IIT Manager Agent 鎶€鏈<EFBFBD>矾寰勪笌鏋舵瀯璁捐<EFBFBD>.md)
- [Phase1.5-AI瀵硅瘽鑳藉姏寮€鍙戣<EFBFBD>鍒抅(../04-寮€鍙戣<E98D99>鍒?Phase1.5-AI瀵硅瘽鑳藉姏寮€鍙戣<E98D99>鍒?md)
- [MVP寮€鍙戜换鍔℃竻鍗昡(../04-寮€鍙戣<E98D99>鍒?MVP寮€鍙戜换鍔℃竻鍗?md)
+- [IIT Manager Agent 技术路径与架构设计](../02-技术设计/IIT Manager Agent 技术路径与架构设计.md)
+- [Phase1.5-AI对话能力开发计划](../04-开发计划/Phase1.5-AI对话能力开发计划.md)
+- [MVP开发任务清单](../04-开发计划/MVP开发任务清单.md)

 ---

-**鏂囨。缁存姢**: 鎶€鏈<EFBFBD>洟闃? 
-**鏈€鍚庢洿鏂?*: 2026-01-04  
+**文档维护**: 技术团队  
+**最后更新**: 2026-01-04  
 **版本历史**:
- v1.0 (2026-01-04): 鍒濆<EFBFBD>鐗堟湰锛孭hase 1.5瀹屾垚鍚庢暣鐞?
-
+- v1.0 (2026-01-04): 初始版本，Phase 1.5完成后整理