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/docs/03-业务模块/DC-数据清洗整理/01-需求分析/总体
+++ b/docs/03-业务模块/DC-数据清洗整理/01-需求分析/总体
@@ -1,34 +1,37 @@
-# **諤ｻ菴<EFBFBD> PRD<52>壼現逍礼ｧ醍<EFBDA7>疲匱閭ｽ謨ｰ謐ｮ貂<EFBDAE>ｴ怜ｹｳ蜿?(The Data Cleaning Platform)**
+# **总体 PRD：医疗科研智能数据清洗平台 (The Data Cleaning Platform)**

-| 譁<EFBFBD>｡｣迚域悽 | V1.0 (蝓ｺ莠主ｷ･蜈ｷ邂ｱ譫ｶ譫? |
+| 文档版本 | V1.0 (基于工具箱架构) |
 | :---- | :---- |
-| **莠ｧ蜩∝ｽ｢諤?* | 莨∽ｸ夂ｺ?Web SaaS 蟷ｳ蜿ｰ |
-| **譬ｸ蠢<EFBFBD>ｻｷ蛟?* | 荳ｺ荳ｴ蠎雁現逕滓署萓?**窶應ｸ遶吝ｼ鞘?* 逧<>焚謐ｮ豐ｻ逅<EFBDBB><E98085>蜉幢ｼ瑚ｧ｣蜀ｳ螟壽ｺ仙ｼよ桷謨ｰ謐ｮ蜷亥ｹｶ髫ｾ縲∫羅蜴<E7BE85>枚譛ｬ謠仙叙髫ｾ縲∫ｻ溯ｮ｡蜑肴ｸ<E882B4>ｴ礼ｹ∫瑞逧<E7919E>ｸ牙､ｧ逞帷せ縲?|
-| **謚譛ｯ譫ｶ譫?* | Node.js \+ React \+ Python/R (扈溯ｮ｡譛榊苅) \+ LLM |
+| **产品形态** | 企业级 Web SaaS 平台 |
+| **核心价值** | 为临床医生提供 **“一站式”** 的数据治理能力，解决多源异构数据合并难、病历文本提取难、统计前清洗繁琐的三大痛点。 |
+| **技术架构** | Node.js \+ React \+ Python/R (统计服务) \+ LLM |

-## **荳縲?鬘ｹ逶ｮ閭梧勹荳守岼譬?(Background & Objectives)**
+## **一、 项目背景与目标 (Background & Objectives)**

 ### **1.1 核心痛点**

-荳ｴ蠎顔ｧ醍<EFBFBD>疲焚謐ｮ逧<EFBFBD>㊥螟<EFBFBD>ｿ<EFBFBD>ｨ具ｼ<EFBFBD>ata Preparation<6F>蛾壼ｸｸ蜊<EFBDB8>謐ｮ謨ｴ荳ｪ遘醍<E98198>泌捉譛溽<E8AD9B>?80% 譌ｶ髣ｴ縲ょ現逕滄擇荳ｴ荳牙､ｧ髦ｻ遒搾ｼ<E690BE>
+临床科研数据的准备过程（Data Preparation）通常占据整个科研周期的 80% 时间。医生面临三大阻碍：
+
+1. **乱 (Messy):** HIS 导出的数据分散在多个 Excel（门诊、住院、检验），ID 对不上，时间线混乱。  
+2. **杂 (Unstructured):** 大量关键信息（如病理诊断、出院小结）存在于文本段落中，无法直接统计。  
+3. **错 (Dirty):** 缺失值、异常值、录入错误频发，不符合统计软件（SPSS/SAS）的格式要求。

-1. **荵?(Messy):** HIS 蟇ｼ蜃ｺ逧<EFBDBA>焚謐ｮ蛻<EFBDAE>淵蝨ｨ螟壻ｸｪ Excel<65>磯葎隸翫∽ｽ城劼縲∵｣鬪鯉ｼ会ｼ栗D 蟇ｹ荳堺ｸ奇ｼ梧慮髣ｴ郤ｿ豺ｷ荵ｱ縲? 
-2. **譚?(Unstructured):** 螟ｧ驥丞<E9A9A5>髞ｮ菫｡諱ｯ<E8ABB1>亥ｦら羅逅<E7BE85>ｯ頑妙縲∝<E7B8B2>髯｢蟆冗ｻ難ｼ牙ｭ伜惠莠取枚譛ｬ谿ｵ關ｽ荳ｭ<E88DB3>梧裏豕慕峩謗･扈溯ｮ｡縲? 
-3. **髞?(Dirty):** 郛ｺ螟ｱ蛟ｼ縲∝ｼょｸｸ蛟ｼ縲∝ｽ募<EFBDBD>髞呵ｯｯ鬚大書<E5A4A7>御ｸ咲ｬｦ蜷育ｻ溯ｮ｡霓ｯ莉ｶ<E88E89><EFBDB6>PSS/SAS<41>臥噪譬ｼ蠑剰ｦ∵ｱゅ?
 ### **1.2 产品目标**

-譫<EFBFBD>ｻｺ荳荳?**窶懈ｵ∫ｨ句喧縲∵匱閭ｽ蛹悶∽ｽ朱葎讒帚?* 逧<>焚謐ｮ貂<EFBDAE>ｴ怜ｹｳ蜿ｰ<E89CBF><EFBDB0>
+构建一个 **“流程化、智能化、低门槛”** 的数据清洗平台：

-* **讓｡蝮怜<EFBFBD>?(Modular):** 蟆<EFBFBD>､肴揩豬∫ｨ区究隗｣荳ｺ荳我ｸｪ迢ｬ遶句ｷ･蜈ｷ<EFBFBD>碁剄菴手ｮ､遏･雍溯差縲? 
-* **蜿ｯ菫｡襍?(Trustworthy):** 騾夊ｿ<EFBFBD>懷曙讓｡蝙矩ｪ瑚ｯ≫晏柱窶懷<EFBFBD>霑<EFBFBD>ｨ玖ｿｽ貅ｯ窶晢ｼ瑚ｧ｣蜀ｳ蟇?AI 逧<>ｿ｡莉ｻ蜊ｱ譛ｺ縲? 
-* **鬮俶ｧ閭ｽ (Performant):** 謾ｯ謖<EFBFBD> 10荳? 陦梧焚謐ｮ逧<EFBDAE>ｵ∝ｼ丞､<E4B89E>炊荳主ｮ樊慮郛冶ｾ代?
-## **莠後?莠ｧ蜩∵ｻ菴捺楔譫<E6A594> (Product Architecture)**
+* **模块化 (Modular):** 将复杂流程拆解为三个独立工具，降低认知负荷。  
+* **可信赖 (Trustworthy):** 通过“双模型验证”和“全过程追溯”，解决对 AI 的信任危机。  
+* **高性能 (Performant):** 支持 10万+ 行数据的流式处理与实时编辑。

-蟷ｳ蜿ｰ驥<EFBFBD>畑 **窶? \+ 3窶?* 譫ｶ譫<EFBDB6>ｨ｡蠑擾ｼ?*1 荳ｪ扈滉ｸ蟾･菴懷<E88FB4>?\+ 3 荳ｪ蝙ら峩謨郁<E8ACA8>蟾･蜈?*縲?
-### **2.1 譫ｶ譫<EFBDB6><E8ADAB>?*
+## **二、 产品总体架构 (Product Architecture)**
+
+平台采用 **“1 \+ 3”** 架构模式：**1 个统一工作台 \+ 3 个垂直效能工具**。
+
+### **2.1 架构图**

 graph TD  
-    User\[荳ｴ蠎雁現逕<EFBFBD>/遘醍<E98198>比ｺｺ蜻禄] \--\> Portal\[譎ｺ閭ｽ謨ｰ謐ｮ貂<EFBDAE>ｴ怜ｷ･菴懷<E88FB4>?(Portal)\]  
+    User\[临床医生/科研人员\] \--\> Portal\[智能数据清洗工作台 (Portal)\]  
      
    subgraph The\_Toolkit \[效能工具箱\]  
        Portal \--\> ToolA\[工具 A: 超级合并器\]  
@@ -37,8 +40,8 @@ graph TD
    end  
      
    subgraph Data\_Flow \[数据流转\]  
-        ToolA \--蜷亥ｹｶ蜷取焚謐?-\> ToolB  
-        ToolB \--扈捺桷蛹匁焚謐?-\> ToolC  
+        ToolA \--合并后数据--\> ToolB  
+        ToolB \--结构化数据--\> ToolC  
        ToolC \--清洗后数据集--\> Analysis\[智能数据分析模块\]  
    end  
      
@@ -52,52 +55,58 @@ graph TD
    ToolB \-.-\> Engine2  
    ToolC \-.-\> Engine3

-### **2.2 讓｡蝮怜ｮ壻ｹ我ｸ手ｾｹ逡?*
+### **2.2 模块定义与边界**

 | 模块名称 | 对应场景 | 核心任务 | 关键产出 | 详细文档 |
 | :---- | :---- | :---- | :---- | :---- |
-| **蟾･菴懷<EFBFBD>?(Portal)** | 蜈ｨ螻蜈･蜿｣ | 莉ｻ蜉｡逶第而縲∬ｵ<E288AC>ｺｧ邂｡逅<EFBDA1>∬ｷｨ蟾･蜈ｷ豬∬ｽｬ | 扈滉ｸ莉ｪ陦ｨ逶?| [PRD\_謨ｰ謐ｮ貂<EFBDAE>ｴ怜ｷ･菴懷床](https://www.google.com/search?q=PRD_%E6%95%B0%E6%8D%AE%E6%B8%85%E6%B4%97%E5%B7%A5%E4%BD%9C%E5%8F%B0.md) |
+| **工作台 (Portal)** | 全局入口 | 任务监控、资产管理、跨工具流转 | 统一仪表盘 | [PRD\_数据清洗工作台](https://www.google.com/search?q=PRD_%E6%95%B0%E6%8D%AE%E6%B8%85%E6%B4%97%E5%B7%A5%E4%BD%9C%E5%8F%B0.md) |
 | **工具 A (Merger)** | 多源合并 | ID 对齐、访视基准合并、时间窗清洗 | 宽表 (Wide Table) | [PRD\_工具A\_超级合并器\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7A_%E8%B6%85%E7%BA%A7%E5%90%88%E5%B9%B6%E5%99%A8_V2.md) |
-| **蟾･蜈ｷ B (AI)** | 譁<EFBFBD>悽謠仙叙 | OCR縲∝ｮ樔ｽ捺署蜿悶<E682B6>嚼遘∬┳謨上∽ｺ､蜿蛾ｪ瑚ｯ?| 扈捺桷蛹門ｭ玲ｮ?| [PRD\_蟾･蜈ｷB\_逞<5F>紙扈捺桷蛹匁惻蝎ｨ莠ｺ\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7B_%E7%97%85%E5%8E%86%E7%BB%93%E6%9E%84%E5%8C%96%E6%9C%BA%E5%99%A8%E4%BA%BA_V2.md) |
-| **蟾･蜈ｷ C (Editor)** | 豺ｱ蠎ｦ貂<EFBFBD>ｴ<EFBFBD> | 郛ｺ螟ｱ蝪ｫ陦･縲∝ｼょｸｸ螟<EFBDB8>炊縲∝序驥剰ｮ｡邂励∝<C280>邂?| 譛扈亥<E68988>譫宣寔 | [PRD\_蟾･蜈ｷC\_遘醍<E98198>疲焚謐ｮ郛冶ｾ大勣\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7C_%E7%A7%91%E7%A0%94%E6%95%B0%E6%8D%AE%E7%BC%96%E8%BE%91%E5%99%A8_V2.md) |
+| **工具 B (AI)** | 文本提取 | OCR、实体提取、隐私脱敏、交叉验证 | 结构化字段 | [PRD\_工具B\_病历结构化机器人\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7B_%E7%97%85%E5%8E%86%E7%BB%93%E6%9E%84%E5%8C%96%E6%9C%BA%E5%99%A8%E4%BA%BA_V2.md) |
+| **工具 C (Editor)** | 深度清洗 | 缺失填补、异常处理、变量计算、分箱 | 最终分析集 | [PRD\_工具C\_科研数据编辑器\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7C_%E7%A7%91%E7%A0%94%E6%95%B0%E6%8D%AE%E7%BC%96%E8%BE%91%E5%99%A8_V2.md) |

-## **荳峨?譬ｸ蠢<EFBDB8>ｸ壼苅豬∫ｨ<E288AB> (Core Workflows)**
+## **三、 核心业务流程 (Core Workflows)**

-### **3.1 蜈ｸ蝙句<EFBFBD>體ｾ霍ｯ蝨ｺ譎?(The "Happy Path")**
+### **3.1 典型全链路场景 (The "Happy Path")**

-蝨ｺ譎ｯ<EFBFBD>壼現逕滓噺髮<EFBFBD>ｺ<EFBFBD> 100 莉ｽ謔｣閠<EFBDA3>噪菴城劼 Excel 蜥檎羅逅<E7BE85>冠蜻?PDF<44>碁怙隕∬ｿ幄｡檎函蟄伜<E89F84>譫舌?
-1. **蜷亥ｹｶ (Step 1):** 蝨?**蟾･菴懷<E88FB4>?* 蜷ｯ蜉ｨ **蟾･蜈ｷ A**縲ゆｸ贋ｼ<E8B48B>窶應ｽ城劼隶ｰ蠖補昜ｸｺ荳ｻ陦ｨ<E999A6>娯懈｣鬪悟黒窶昜ｸｺ霎<EFBDBA>｡ｨ縲らｳｻ扈溷渕莠寂懷<C280>髯｢譌･譛?ﾂｱ7螟ｩ窶晉噪譌ｶ髣ｴ遯暦ｼ悟ｰ<E6829F>｣鬪梧焚謐ｮ謖りｽｽ蛻ｰ菴城劼隶ｰ蠖穂ｸ翫? 
-2. **謠仙叙 (Step 2):** 蜷亥ｹｶ螳梧<EFBFBD>蜷趣ｼ檎せ蜃ｻ窶懈ｵ∬ｽｬ蛻ｰ蟾･蜈ｷ B窶昴?*蟾･蜈ｷ B** 閾ｪ蜉ｨ蜉<EFBDA8>霓ｽ謨ｰ謐ｮ縲ょ現逕滄画叫窶懆ぜ逋檎羅逅<E7BE85>ｨ｡迚遺晢ｼ悟曙讓｡蝙具ｼ<E585B7>eepSeek & Qwen<65>牙ｹｶ蜿第署蜿問懆ち逖､螟ｧ蟆鞘晏柱窶懈ｷ句ｷｴ扈楢ｽｬ遘ｻ窶昴ょ現逕溷惠蜈ｨ譎ｯ鄂第<E98482>ｼ荳ｭ陬∝<E999AC>荳堺ｸ閾ｴ逧<EFBDB4>焚謐ｮ縲? 
-3. **貂<EFBFBD>ｴ<EFBFBD> (Step 3):** 謠仙叙螳梧<EFBFBD>蜷趣ｼ檎せ蜃ｻ窶懈ｵ∬ｽｬ蛻ｰ蟾･蜈ｷ C窶昴?*蟾･蜈ｷ C** 謇灘ｼ郛冶ｾ大勣縲ょ現逕滄夊ｿ<E5A48A>ｾｧ霎ｹ譬丞書邇ｰ窶懆ち逖､螟ｧ蟆鞘晄怏郛ｺ螟ｱ蛟ｼ<E89B9F>御ｸ髞ｮ逕ｨ蝮<EFBDA8>ｼ蝪ｫ陦･<E999A6>帛ｹｶ譁ｰ蠅櫁ｮ｡邂怜<E98282> BMI縲? 
-4. **蛻<EFBFBD>梵 (Step 4):** 謨ｰ謐ｮ貂<EFBFBD>ｴ怜ｮ梧ｯ包ｼ御ｿ晏ｭ倅ｸｺ窶懷<EFBFBD>譫宣寔\_V1窶昴ゆｸ髞ｮ蜿鷹∬<C280>邉ｻ扈溽噪窶懈匱閭ｽ謨ｰ謐ｮ蛻<EFBDAE>梵窶晄ｨ｡蝮苓ｿ幄｡?Kaplan-Meier 逕溷ｭ伜<EFBDAD>譫舌?
-## **蝗帙?蜈ｨ螻髱槫粥閭ｽ髴豎?(Non-Functional Requirements)**
+场景：医生收集了 100 份患者的住院 Excel 和病理报告 PDF，需要进行生存分析。
+
+1. **合并 (Step 1):** 在 **工作台** 启动 **工具 A**。上传“住院记录”为主表，“检验单”为辅表。系统基于“入院日期 ±7天”的时间窗，将检验数据挂载到住院记录上。  
+2. **提取 (Step 2):** 合并完成后，点击“流转到工具 B”。**工具 B** 自动加载数据。医生选择“肺癌病理模版”，双模型（DeepSeek & Qwen）并发提取“肿瘤大小”和“淋巴结转移”。医生在全景网格中裁决不一致的数据。  
+3. **清洗 (Step 3):** 提取完成后，点击“流转到工具 C”。**工具 C** 打开编辑器。医生通过侧边栏发现“肿瘤大小”有缺失值，一键用均值填补；并新增计算列 BMI。  
+4. **分析 (Step 4):** 数据清洗完毕，保存为“分析集\_V1”。一键发送至系统的“智能数据分析”模块进行 Kaplan-Meier 生存分析。
+
+## **四、 全局非功能需求 (Non-Functional Requirements)**

 ### **4.1 用户体验策略 (UX Strategy)**

-* **蜴ｻ蜿ｯ隗<EFBFBD>喧 (De-visualization):** 蟇ｹ莠主ｷ･蜈ｷ A 蜥?B<>御ｸ榊ｱ慕､ｺ蜈ｨ驥<EFBDA8> Excel 鄂第<E98482>ｼ<EFBFBD>碁㊦逕?**窶懷髄蟇ｼ驟咲ｽ?\-\> 鮟醍將螟<E5B087>炊 \-\> 鮟<>≡鬚<E289A1>ｧ遺?* 逧<>ｨ｡蠑擾ｼ碁剄菴取ｵ剰ｧ亥勣貂ｲ譟灘視蜉幢ｼ瑚★辟ｦ扈捺棡縲? 
-* **蜿埼ｦ郁｡･蛛ｿ (Feedback Loop):** 譌｢辟ｶ逵倶ｸ崎ｧ∬ｿ<EFBFBD>ｨ具ｼ悟ｿ<EFBFBD>｡ｻ蠅槫ｼｺ扈捺棡蜿埼ｦ医よｯ丈ｸｪ蟾･蜈ｷ蠢<EFBFBD>｡ｻ謠蝉ｾ幄ｯｦ扈<EFBFBD>噪 **窶懈焚謐ｮ雍ｨ驥乗冠蜻岩?*<2A>亥ｦゑｼ壻ｸ｢蠑<EFBDA2>｡梧焚縲∝<E7B8B2>遯∫紫縲∫ｩｺ蛟ｼ邇<EFBDBC>ｼ峨? 
-* **譛ｬ蝨ｰ莨伜<EFBFBD> (Local-First):** 蟾･蜈ｷ C 驥<>畑 IndexedDB 蟄伜お<EFBFBD>檎｡ｮ菫晉ｼ冶ｾ第桃菴懶ｼ育ｭ幃峨∵崛謐｢<EFBFBD>画裏鄂醍ｻ懷ｻｶ霑溘?
-### **4.2 謨ｰ謐ｮ螳牙<E89EB3>荳朱嚼遘?(Security & Privacy)**
+* **去可视化 (De-visualization):** 对于工具 A 和 B，不展示全量 Excel 网格，采用 **“向导配置 \-\> 黑盒处理 \-\> 黄金预览”** 的模式，降低浏览器渲染压力，聚焦结果。  
+* **反馈补偿 (Feedback Loop):** 既然看不见过程，必须增强结果反馈。每个工具必须提供详细的 **“数据质量报告”**（如：丢弃行数、冲突率、空值率）。  
+* **本地优先 (Local-First):** 工具 C 采用 IndexedDB 存储，确保编辑操作（筛选、替换）无网络延迟。
+
+### **4.2 数据安全与隐私 (Security & Privacy)**
+
+* **PII 脱敏:** 所有发送给 LLM (工具 B) 的数据，**必须**在后端先经过正则脱敏（姓名、身份证、手机号）。  
+* **数据隔离:** 不同用户的数据严格物理隔离（S3 路径 / DB Row Level Security）。

-* **PII 閼ｱ謨<EFBDB1>:** 謇譛牙書騾∫ｻ<E288AB> LLM (蟾･蜈ｷ B) 逧<>焚謐ｮ<E8AC90><EFBDAE>**蠢<>｡ｻ**蝨ｨ蜷守ｫｯ蜈育ｻ剰ｿ<E589B0>ｭ｣蛻呵┳謨擾ｼ亥ｧ灘錐縲∬ｺｫ莉ｽ隸√∵焔譛ｺ蜿ｷ<E89CBF>峨? 
-* **謨ｰ謐ｮ髫皮ｦｻ:** 荳榊酔逕ｨ謌ｷ逧<EFBDB7>焚謐ｮ荳･譬ｼ迚ｩ逅<EFBDA9>囈遖ｻ<E98196><EFBDBB>3 霍ｯ蠕<EFBDAF> / DB Row Level Security<74>峨?
 ### **4.3 性能指标 (Performance SLAs)**

-* **譁<EFBFBD>ｻｶ謾ｯ謖<EFBFBD>:** 蜊穂ｸｪ譁<EFBDAA>ｻｶ謾ｯ謖∵怙螟?**50MB** 謌?**50荳<30>｡<EFBFBD>**縲? 
+* **文件支持:** 单个文件支持最大 **50MB** 或 **50万行**。  
 * **响应速度:**  
-  * 蟾･蜈ｷ A 蜷亥ｹｶ<EFBDB9>?0荳<30>｡鯉ｼ会ｼ喀< 60遘偵? 
-  * 蟾･蜈ｷ B 謠仙叙<E4BB99>亥ｹｶ蜿托ｼ会ｼ壼叙蜀ｳ莠<EFBDB3> Token 驥擾ｼ碁怙謠蝉ｾ幄ｿ帛ｺｦ譚｡縲? 
-  * 蟾･蜈ｷ C 郛冶ｾ大桃蠎費ｼ喀< 100ms縲?
-## **莠斐?謨ｰ謐ｮ譬<EFBDAE>㊥荳取ｵ∬ｽｬ蜊剰ｮ?(Data Standards)**
+  * 工具 A 合并（10万行）：\< 60秒。  
+  * 工具 B 提取（并发）：取决于 Token 量，需提供进度条。  
+  * 工具 C 编辑响应：\< 100ms。
+
+## **五、 数据标准与流转协议 (Data Standards)**

 为了保证三个工具能顺畅协作，必须定义统一的数据交换标准：

-1. **譁<EFBFBD>ｻｶ譬ｼ蠑<EFBFBD>:** 蜀<>Κ豬∬ｽｬ扈滉ｸ菴ｿ逕ｨ **CSV (UTF-8 with BOM)** 謌?**JSON Lines**縲? 
-2. **譌･譛滓<EFBFBD>ｼ蠑<EFBFBD>:** 謇譛牙ｷ･蜈ｷ莠ｧ蜃ｺ逧<EFBDBA>律譛溷<E8AD9B><E6BAB7>悟ｼｺ蛻ｶ譬<EFBDB6>㊥蛹紋ｸｺ YYYY-MM-DD縲? 
-3. **遨ｺ蛟ｼ陦ｨ遉?** 扈滉ｸ菴ｿ逕ｨ null 謌也ｩｺ蟄礼ｬｦ荳?""<22>御ｸ･遖∽ｽｿ逕?"NA", "-" 遲画枚譛ｬ豺ｷ蜈･謨ｰ蛟ｼ蛻励? 
-4. **豬∬ｽｬ蜃ｭ隸<EFBFBD>:** 霍ｨ蟾･蜈ｷ霍ｳ霓ｬ譌ｶ<E8AD8C>碁夊ｿ<E5A48A> URL 蜿よ焚莨<E7849A>騾?assetId (襍<>ｺｧID)<29>梧磁謾ｶ譁ｹ騾夊ｿ<E5A48A> API 闔ｷ蜿匁枚莉ｶ豬<EFBDB6>ｼ梧裏髴蜑咲ｫｯ騾丈ｼ<E4B888>螟ｧ譁<EFBDA7>ｻｶ縲?
-## **蜈ｭ縲?髯<>ｽ包ｼ夂沿譛ｬ隗<EFBDAC><E99A97>?(Roadmap)**
+1. **文件格式:** 内部流转统一使用 **CSV (UTF-8 with BOM)** 或 **JSON Lines**。  
+2. **日期格式:** 所有工具产出的日期列，强制标准化为 YYYY-MM-DD。  
+3. **空值表示:** 统一使用 null 或空字符串 ""，严禁使用 "NA", "-" 等文本混入数值列。  
+4. **流转凭证:** 跨工具跳转时，通过 URL 参数传递 assetId (资产ID)，接收方通过 API 获取文件流，无需前端透传大文件。

-* **Phase 1 (MVP):** 荳顔ｺｿ蟾･菴懷<E88FB4>?\+ 蟾･蜈ｷ A (蝓ｺ遑蜷亥ｹｶ) \+ 蟾･蜈ｷ C (蝓ｺ遑郛冶ｾ<E586B6>)縲ょｷ･蜈?B 證ゆｸ堺ｸ顔ｺｿ縲? 
-* **Phase 2 (Intelligence):** 荳顔ｺｿ 蟾･蜈ｷ B (蜊墓ｨ｡蝙区署蜿?縲ょｷ･蜈?C 蠅槫刈萓ｧ霎ｹ譬冗ｻ溯ｮ｡縲? 
-* **Phase 3 (Trust):** 蟾･蜈ｷ B 蜊<>ｺｧ荳ｺ蜿梧ｨ｡蝙倶ｺ､蜿蛾ｪ瑚ｯ√ょｷ･蜈?A 蜊<>ｺｧ荳ｺ譌ｶ髣ｴ遯怜粋蟷ｶ縲
+## **六、 附录：版本规划 (Roadmap)**
+
+* **Phase 1 (MVP):** 上线工作台 \+ 工具 A (基础合并) \+ 工具 C (基础编辑)。工具 B 暂不上线。  
+* **Phase 2 (Intelligence):** 上线 工具 B (单模型提取)。工具 C 增加侧边栏统计。  
+* **Phase 3 (Trust):** 工具 B 升级为双模型交叉验证。工具 A 升级为时间窗合并。