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
28 KiB
下一阶段行动计划 V2.1 - 10个Schema完整版
计划周期: 2025-11-07 至 2025-12-06(4周)
核心目标: 10个Schema隔离完整实施 + 代码分层 + ASL核心功能
制定时间: 2025-11-07
版本: V2.1(10个Schema完整版)
最后更新: 2025-11-09
💡 核心变化亮点
🎯 决定:直接实施10个Schema,不分阶段!
为什么?
- ✅ 额外成本仅6小时(5个空Schema无数据迁移)
- ✅ 现在是测试系统,最佳实施时机
- ✅ 架构一次到位,避免二次迁移
- ✅ Week 1有7天,时间完全够用
变化:
- 从"5个核心+5个预留" → 10个全部实施
- 从"分阶段迁移" → 一次性完成
- 新增SSA(智能统计分析)和ST(统计分析工具)两个Schema
🎯 V2.1 vs V2.0 的关键调整
| 项目 | V2.0 | V2.1(完整版) | 原因 |
|---|---|---|---|
| Schema数量 | 8个全做 | ✅ 10个全部实施 ⭐ | 额外成本仅6小时,一次到位 |
| 独立部署 | Week 2实施 | ❌ 暂不实施 | 当前重点是云端系统 |
| Docker化 | Week 2做 | ❌ 暂不做 | 不是当前重点 |
| Monorepo | 未提及 | ❌ 暂不采用 | 目录分层已够用 |
| 总时长 | 5周 | 4周 ⭐ | 去掉独立部署实施,节省1周 |
📊 整体规划 - 四周四阶段
Week 1(Schema基础) Week 2(代码架构) Week 3-4(ASL开发)
10个Schema全部隔离 → 代码分层+LLM网关 → 标题摘要初筛+全文复筛
| 阶段 | 时间 | 核心任务 | 交付成果 | 优先级 |
|---|---|---|---|---|
| 阶段1 | Week 1 | 10个Schema全部隔离 ⭐ | 10个Schema完成 | P0 ⭐⭐⭐ |
| 阶段2 | Week 2 | 代码分层+LLM网关 | 三层架构+LLM网关 | P0 ⭐⭐⭐ |
| 阶段3 | Week 3 | ASL标题摘要初筛 | 双模型筛选功能 | P0 ⭐⭐ |
| 阶段4 | Week 4 | ASL全文复筛+测试 | 完整筛选流程 | P0 ⭐⭐ |
🚀 阶段1:10个Schema完整隔离(Week 1)
时间: 2025-11-07 至 2025-11-13(7天)
目标: 一次性完成10个Schema的完整隔离,架构一步到位
核心原则:一次到位 ⭐⭐⭐
全部创建的Schema(10个):
详细设计+迁移(3个)⭐ Week 1重点
1. platform_schema - 平台基础
- 迁移现有的users表(~10条数据)
- 为平台基础服务预留
2. aia_schema - AI智能问答 ⭐ 现有功能
- 迁移5个表:projects, conversations, messages, general_conversations, general_messages
- 数据量:~20个项目,~50条对话,~500条消息
3. pkb_schema - 个人知识库 ⭐ 现有功能
- 迁移2个表:knowledge_bases, documents
- 数据量:~5个知识库,~30个文档
只创建空Schema(7个)📋 命名空间预留
4. asl_schema - AI智能文献
- 📋 Week 3开发前再详细设计
- 避免现在过度设计,需求更明确时再做
5. common_schema - 通用能力
- 📋 需要时再创建表(LLM使用记录、Feature Flags)
6. dc_schema - 数据清洗 7. rvw_schema - 审稿系统 8. admin_schema - 运营管理 9. ssa_schema - 智能统计分析 ✨ 10. st_schema - 统计分析工具 ✨
为什么采用"3详细+7空"策略?⭐⭐⭐
核心原则:聚焦当前,架构预留
成本分析:
- Week 1只处理3个Schema的迁移
- 其余7个只是
CREATE SCHEMA(几秒钟) - 总工作量从2天降低到1.5天 ✅
收益分析:
- ✅ 聚焦当前需求 - Week 1专注架构和迁移
- ✅ 避免过度设计 - ASL等模块需求未最终确定
- ✅ Just-in-time设计 - 开发前再详细设计,更准确
- ✅ 架构完整 - 10个命名空间已预留,随时扩展
- ✅ 降低返工风险 - Week 3需求可能调整
Day 1-2:Schema迁移准备(聚焦3个)
Day 1上午:10个Schema架构规划
任务:规划完整的10个Schema架构
- 绘制10个Schema的完整架构图(架构层面)
- 明确3个需要迁移的Schema
- 明确7个空Schema的用途
- 编写Schema架构文档
输出文档:
09-架构实施/01-Schema隔离架构设计(10个).md
Schema依赖关系:
业务模块Schema(AIA/PKB/ASL/DC/RVW/ADMIN/SSA/ST)
↓ 引用
Common Schema(通用数据,暂为空)
↓ 引用
Platform Schema(用户、权限)
Day 1下午-Day 2上午:3个Schema详细设计 ⭐ 核心工作
只详细设计需要迁移的3个Schema:
1. platform_schema(平台基础)
CREATE SCHEMA platform_schema;
-- 用户表(从public.users迁移)
CREATE TABLE platform_schema.users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
name VARCHAR(255),
avatar_url VARCHAR(500),
role VARCHAR(50) NOT NULL DEFAULT 'user',
status VARCHAR(50) DEFAULT 'active',
kb_quota INT DEFAULT 3, -- 知识库配额
kb_used INT DEFAULT 0, -- 已使用
trial_ends_at TIMESTAMP,
is_trial BOOLEAN DEFAULT true,
last_login_at TIMESTAMP,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
说明: 用户表是所有Schema的基础,其他Schema的user_id都引用platform_schema.users。
2. aia_schema(AI智能问答) ⭐ 现有功能迁移
CREATE SCHEMA aia_schema;
-- 项目管理(从public.projects迁移)
CREATE TABLE aia_schema.projects (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL, -- 引用platform_schema.users
name VARCHAR(255) NOT NULL,
background TEXT DEFAULT '',
research_type VARCHAR(50) DEFAULT 'observational',
conversation_count INT DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
deleted_at TIMESTAMP
);
-- 对话(从public.conversations迁移)
CREATE TABLE aia_schema.conversations (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL,
project_id UUID REFERENCES aia_schema.projects(id) ON DELETE CASCADE,
agent_id VARCHAR(100) NOT NULL,
title VARCHAR(255) NOT NULL,
model_name VARCHAR(50) DEFAULT 'deepseek-v3',
message_count INT DEFAULT 0,
total_tokens INT DEFAULT 0,
metadata JSONB,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
deleted_at TIMESTAMP
);
-- 消息(从public.messages迁移)
CREATE TABLE aia_schema.messages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
conversation_id UUID REFERENCES aia_schema.conversations(id) ON DELETE CASCADE,
role VARCHAR(20) NOT NULL, -- user/assistant
content TEXT NOT NULL,
model VARCHAR(50),
metadata JSONB,
tokens INT,
is_pinned BOOLEAN DEFAULT false,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 通用对话(从public.general_conversations迁移)
CREATE TABLE aia_schema.general_conversations (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL,
title VARCHAR(255) NOT NULL,
model_name VARCHAR(50),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
deleted_at TIMESTAMP
);
-- 通用消息(从public.general_messages迁移)
CREATE TABLE aia_schema.general_messages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
conversation_id UUID REFERENCES aia_schema.general_conversations(id) ON DELETE CASCADE,
role VARCHAR(20) NOT NULL,
content TEXT NOT NULL,
model VARCHAR(50),
metadata JSONB,
tokens INT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
3. pkb_schema(个人知识库) ⭐ 现有功能迁移
CREATE SCHEMA pkb_schema;
-- 知识库(从public.knowledge_bases迁移)
CREATE TABLE pkb_schema.knowledge_bases (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL, -- 引用platform_schema.users
name VARCHAR(255) NOT NULL,
description TEXT,
dify_dataset_id VARCHAR(255) NOT NULL, -- Dify知识库ID
file_count INT DEFAULT 0,
total_size_bytes BIGINT DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
-- 文档(从public.documents迁移)
CREATE TABLE pkb_schema.documents (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
kb_id UUID REFERENCES pkb_schema.knowledge_bases(id) ON DELETE CASCADE,
user_id UUID NOT NULL,
filename VARCHAR(255) NOT NULL,
file_type VARCHAR(50) NOT NULL,
file_size_bytes BIGINT NOT NULL,
file_url TEXT NOT NULL,
dify_document_id VARCHAR(255) NOT NULL, -- Dify文档ID
status VARCHAR(50) DEFAULT 'uploading', -- uploading/processing/completed/failed
progress INT DEFAULT 0,
error_message TEXT,
segments_count INT,
tokens_count INT,
-- Phase 2: 全文阅读模式字段
extraction_method VARCHAR(50), -- pymupdf/nougat/mammoth/direct
extraction_quality FLOAT, -- 0-1质量分数
char_count INT,
language VARCHAR(20), -- chinese/english
extracted_text TEXT,
uploaded_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
processed_at TIMESTAMP
);
Day 2下午:7个空Schema创建SQL 📋
只需创建空Schema,不设计表结构:
-- 创建7个空Schema(命名空间预留)
CREATE SCHEMA IF NOT EXISTS asl_schema; -- AI智能文献,Week 3开发前再设计
CREATE SCHEMA IF NOT EXISTS common_schema; -- 通用能力,需要时再创建表
CREATE SCHEMA IF NOT EXISTS dc_schema; -- 数据清洗
CREATE SCHEMA IF NOT EXISTS rvw_schema; -- 审稿系统
CREATE SCHEMA IF NOT EXISTS admin_schema; -- 运营管理
CREATE SCHEMA IF NOT EXISTS ssa_schema; -- 智能统计分析
CREATE SCHEMA IF NOT EXISTS st_schema; -- 统计分析工具
说明:
- ✅ 只需几秒钟执行完成
- ✅ 命名空间已预留,不会冲突
- ✅ 需要时随时可以在对应Schema中创建表
- ✅ Prisma配置中可以先预留,暂不定义模型
Day 2下午:迁移脚本编写 ⭐
任务:
- 编写创建10个Schema的SQL脚本(3个详细+7个空)
- 编写3个Schema的数据迁移脚本
- 编写数据验证脚本
- 在本地测试环境验证
迁移策略:
- 创建10个新Schema(3个详细+7个空,一次性)
- 在3个Schema中创建表结构并迁移数据
- 验证数据完整性
- 清理public schema旧表(可选,因为是测试系统)
输出脚本(5个):
| 脚本 | 说明 | 工作量 |
|---|---|---|
001-create-all-10-schemas.sql |
创建10个Schema ⭐ | 5分钟 |
002-migrate-platform.sql |
迁移users表到platform_schema | 15分钟 |
003-migrate-aia.sql |
迁移5个表到aia_schema | 30分钟 |
004-migrate-pkb.sql |
迁移2个表到pkb_schema | 20分钟 |
005-validate-all.sql |
验证数据完整性 | 10分钟 |
总工作量: ~1.5小时 ✅
Day 3:执行3个Schema迁移 ⭐
上午:执行迁移
- 备份当前数据库(虽然是测试数据,但还是备份)
- 执行001脚本:创建10个Schema(3详细+7空)
- 执行002-004脚本:迁移3个Schema的数据(platform/aia/pkb)
- 执行005脚本:验证数据完整性
下午:验证现有功能
- 测试AI智能问答功能(使用aia_schema)
- 测试知识库功能(使用pkb_schema)
- 验证10个Schema全部创建
- 修复发现的问题
验收标准:
- ✅ 10个Schema全部创建成功
- ✅ 7个空Schema验证通过(ASL/Common/DC/RVW/ADMIN/SSA/ST)
- ✅ 现有功能(AIA、PKB)正常运行
- ✅ 数据迁移100%成功(~10条用户 + 50+对话 + 30+文档)
预计时间: 2-3小时 ✅
Day 4-5:Prisma Schema更新 + 补充文档
Day 4上午:Prisma多Schema配置(3个详细+7个预留)
任务:
- 更新Prisma配置支持10个Schema
- 为3个Schema创建完整的Prisma模型(Platform/AIA/PKB)
- 为7个空Schema预留配置(只配置Schema名,无模型)
- 生成Prisma Client
- 单元测试
Prisma配置示例:
// schema.prisma
generator client {
provider = "prisma-client-js"
previewFeatures = ["multiSchema"]
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
schemas = [
"platform_schema", // ✅ 已迁移,有模型
"aia_schema", // ✅ 已迁移,有模型
"pkb_schema", // ✅ 已迁移,有模型
"asl_schema", // 📋 空Schema,Week 3再定义模型
"common_schema", // 📋 空Schema,需要时再定义
"dc_schema", // 📋 空Schema
"rvw_schema", // 📋 空Schema
"admin_schema", // 📋 空Schema
"ssa_schema", // 📋 空Schema
"st_schema" // 📋 空Schema
]
}
// ===== 1. Platform Schema(平台基础)=====
model User {
id String @id @default(uuid())
email String @unique
passwordHash String @map("password_hash")
name String?
avatarUrl String? @map("avatar_url")
role String @default("user")
status String @default("active")
kbQuota Int @default(3) @map("kb_quota")
kbUsed Int @default(0) @map("kb_used")
trialEndsAt DateTime? @map("trial_ends_at")
isTrial Boolean @default(true) @map("is_trial")
lastLoginAt DateTime? @map("last_login_at")
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @updatedAt @map("updated_at")
@@map("users")
@@schema("platform_schema")
}
// ===== 2. AIA Schema(AI智能问答 - 迁移现有表)=====
model Project {
id String @id @default(uuid())
userId String @map("user_id")
name String
description String?
createdAt DateTime @default(now()) @map("created_at")
conversations Conversation[]
@@map("projects")
@@schema("aia_schema")
}
// ... 其他AIA模型
// ===== 3. PKB Schema(个人知识库 - 迁移现有表)=====
model KnowledgeBase {
id String @id @default(uuid())
userId String @map("user_id")
name String
description String?
difyDatasetId String @map("dify_dataset_id")
fileCount Int @default(0) @map("file_count")
totalSizeBytes BigInt @default(0) @map("total_size_bytes")
createdAt DateTime @default(now()) @map("created_at")
updatedAt DateTime @updatedAt @map("updated_at")
documents Document[]
@@map("knowledge_bases")
@@schema("pkb_schema")
}
model Document {
id String @id @default(uuid())
kbId String @map("kb_id")
userId String @map("user_id")
filename String
fileType String @map("file_type")
fileSizeBytes BigInt @map("file_size_bytes")
fileUrl String @map("file_url")
difyDocumentId String @map("dify_document_id")
status String @default("uploading")
progress Int @default(0)
errorMessage String? @map("error_message") @db.Text
segmentsCount Int? @map("segments_count")
tokensCount Int? @map("tokens_count")
// Phase 2: 全文阅读字段
extractionMethod String? @map("extraction_method")
extractionQuality Float? @map("extraction_quality")
charCount Int? @map("char_count")
language String?
extractedText String? @map("extracted_text") @db.Text
uploadedAt DateTime @default(now()) @map("uploaded_at")
processedAt DateTime? @map("processed_at")
knowledgeBase KnowledgeBase @relation(fields: [kbId], references: [id], onDelete: Cascade)
@@map("documents")
@@schema("pkb_schema")
}
说明:
- ✅ 只为3个已迁移的Schema定义模型
- 📋 7个空Schema已在schemas列表中,但暂无模型
- 📋 ASL模型将在Week 3开发前定义
- 📋 Common模型需要时再添加
Day 4下午:补充AIA和PKB设计文档 ⭐ 新增任务
任务:为已迁移的2个模块补充完整设计文档
1. 创建AIA数据库设计文档
- 创建
03-业务模块/AIA-AI智能问答/02-技术设计/01-数据库设计.md - 基于已迁移的5个表编写完整文档
- 包括:表结构、字段说明、索引设计、关系说明
2. 创建PKB数据库设计文档
- 创建
03-业务模块/PKB-个人知识库/02-技术设计/01-数据库设计.md - 基于已迁移的2个表编写完整文档
- 重点说明Phase 2全文阅读相关字段
工作量估算: 各1小时,共2小时 ✅
为什么现在补充?
- ✅ 趁着对表结构熟悉,立即文档化
- ✅ 为Week 2代码重构提供文档支持
- ✅ 与ASL保持一致的文档结构
Day 5上午:代码适配 + API文档补充
任务1:更新代码以使用新Schema
- 更新所有数据库查询代码
- 使用新的Prisma Client
- 更新API路由
- 运行集成测试
任务2:补充API设计文档
- 创建
03-业务模块/AIA-AI智能问答/02-技术设计/02-API设计规范.md - 创建
03-业务模块/PKB-个人知识库/02-技术设计/02-API设计规范.md - 基于现有API routes整理文档
验收标准:
- ✅ 所有API正常工作
- ✅ 测试通过
- ✅ 现有功能无回归
- ✅ AIA和PKB模块文档完整(数据库+API)
Day 5下午:Week 1总结 + Week 2准备
任务:
- 验证10个Schema全部创建
- 验证3个详细Schema数据迁移完整
- 更新文档:记录迁移过程和结果
- 编写Week 1总结报告
- 规划Week 2代码重构细节
Week 1交付物检查清单:
- ✅ 10个Schema全部创建(3详细+7空)
- ✅ Platform/AIA/PKB数据100%迁移
- ✅ Prisma模型更新完成(3个详细Schema)
- ✅ 现有功能正常运行
- ✅ AIA和PKB完整文档(数据库+API)
- ✅ 迁移脚本文档化
Week 2:代码分层重构(2025-11-14 至 2025-11-20)
重点: 建立清晰的代码分层架构,为模块化开发打好基础
目标
- 建立3层代码结构(Platform/Common/Business)
- 完成现有代码重构
- 建立代码规范和最佳实践
Day 6-7:Platform层和Common层重构
任务:
- 提取平台基础服务(认证、权限)
- 提取通用能力(LLM调用、文件处理)
- 建立统一的错误处理
- 建立统一的日志系统
代码结构:
backend/src/
├── platform/
│ ├── auth/ # 认证服务
│ ├── permissions/ # 权限管理
│ └── users/ # 用户管理
├── common/
│ ├── llm/ # LLM网关
│ ├── files/ # 文件处理
│ └── utils/ # 工具函数
└── modules/
├── aia/ # AI智能问答
├── pkb/ # 个人知识库
└── asl/ # AI智能文献(准备)
Day 8-10:Business模块重构
任务:
- 重构AIA模块代码
- 重构PKB模块代码
- 建立模块间调用规范
- 完善单元测试
验收标准:
- ✅ 代码分层清晰
- ✅ 模块边界明确
- ✅ 测试覆盖率 > 80%
- ✅ 现有功能无回归
Week 3-4:ASL模块开发(2025-11-21 至 2025-12-04)
重点: 完成AI智能文献核心功能
Week 3 Day 1-2:ASL详细设计 ⭐ 此时再设计
任务:
- 详细设计asl_schema表结构
- 编写ASL数据库设计文档
- 编写ASL API设计文档
- 创建ASL表结构
- 更新Prisma模型(添加ASL模型)
为什么Week 3再设计?
- ✅ Week 1-2架构已搭好,有了清晰的参考
- ✅ 需求经过Week 1-2的思考更加明确
- ✅ 避免Week 1过度设计和返工
- ✅ Just-in-time设计,更高效
Week 3 Day 3-5:ASL Phase 1核心功能
功能1:文献项目管理
- 创建/编辑/删除项目
- PICO配置
- 项目列表展示
功能2:文献导入
- CSV导入
- 批量导入
- 数据验证
功能3:AI双模型筛选
- 集成2个大模型
- 并行筛选
- 结果对比
Week 4:ASL Phase 1完善
功能4:筛选结果管理
- 结果展示
- 人工复核
- 导出功能
功能5:测试和优化
- 完整功能测试
- 性能优化
- 用户体验优化
Week 5-6:DC和RVW模块规划(2025-12-05 至 2025-12-18)
重点: 根据ASL开发经验,规划后续模块
数据清洗模块(DC)设计
此时根据需求再设计dc_schema:
- 清洗任务管理
- 规则引擎
- 清洗结果
审稿系统模块(RVW)设计
此时根据需求再设计rvw_schema:
- 审稿项目管理
- 审稿任务分配
- 审稿意见管理
说明: 这两个模块的详细Schema设计推迟到开发前,避免现在过度设计。
后续规划(Week 7+)
ADMIN模块(运营管理)
- 设计admin_schema
- 组织管理
- 订阅管理
- 使用统计
SSA和ST模块(智能统计)
- 根据需求设计ssa_schema和st_schema
- 统计分析引擎
- 分析工具集成
📊 工作量总结(务实版)
| 阶段 | 原计划 | 新计划 | 节省 |
|---|---|---|---|
| Week 1 Schema迁移 | 2天(5个详细) | 1.5天(3个详细) | ✅ 0.5天 |
| Week 1 文档补充 | 0 | 0.5天(AIA/PKB文档) | 新增 |
| Prisma模型 | 5个详细 | 3个详细 | ✅ 简化 |
| ASL设计 | Week 1 | Week 3(推迟) | ✅ 避免返工 |
| 总Week 1工作量 | 2天 | 2天 | 相同,但更合理 |
关键优势:
- ✅ Week 1聚焦架构和迁移,不做新设计
- ✅ ASL设计推迟到开发前,需求更明确
- ✅ AIA和PKB文档补充,与ASL保持一致
- ✅ 7个空Schema预留,随时可扩展
- ✅ 降低返工风险,提高开发效率
🎯 下一步行动
- 立即开始Week 1 Day 1:规划10个Schema架构
- Day 1-2:编写3个Schema的详细设计和迁移脚本
- Day 3:执行迁移,验证功能
- Day 4:更新Prisma,补充AIA/PKB数据库文档
- Day 5:代码适配,补充AIA/PKB API文档,Week 1总结
记住:架构预留 + Just-in-time设计 = 高效务实! ⭐⭐⭐
附录:Week 1详细交付物清单
交付物:
- ✅ 10个Schema全部创建(3详细+7空)
- ✅ 完整的Schema架构设计文档
- ✅ Prisma Schema更新完成(3个详细Schema模型)
- ✅ 现有功能(AIA、PKB)迁移完成(7个表)
- ✅ AIA和PKB完整文档(数据库+API)
- ✅ 7个空Schema创建完成(ASL/Common/DC/RVW/ADMIN/SSA/ST)
验收标准:
- ✅ 10个Schema全部创建成功
- ✅ 数据迁移100%成功(platform/aia/pkb三个Schema)
- ✅ 现有功能正常运行(AI智能问答、知识库)
- ✅ Prisma Client正常工作(支持10个Schema)
- ✅ AIA和PKB文档完整
- ✅ 7个空Schema验证通过(架构预留)
🔧 阶段2:代码分层 + LLM网关(Week 2)
时间: 2025-11-14 至 2025-11-20(7天)
目标: 建立三层代码架构 + 实现LLM网关
务实策略:只做云端统一系统 ⭐
做什么:
- ✅ 三层目录结构(platform/common/modules)
- ✅ 代码迁移和重构
- ✅ LLM网关实现
- ✅ 模块化API路由
暂不做:
- ❌ 模块独立部署配置
- ❌ Docker文件
- ❌ 独立运行脚本
原因: 当前重点是云端系统开发,独立部署在Week 7+再考虑
Day 6-7:三层目录重构
任务:
- 创建三层目录结构
- 迁移现有代码到新结构
- 重构为清晰的分层
目录结构:
backend/src/
├── platform/ # L1:平台基础层
│ ├── auth/ # 认证(JWT、Session)
│ ├── permissions/ # 权限管理(RBAC)
│ └── users/ # 用户服务
├── common/ # L2:通用能力层
│ ├── llm/ # LLM网关
│ ├── files/ # 文件处理
│ └── utils/ # 工具函数
└── modules/ # L3:业务模块层
├── aia/ # AI智能问答
├── pkb/ # 个人知识库
└── asl/ # AI智能文献(准备)
Day 8-9:LLM网关实现
核心功能:
-
多模型支持
- DeepSeek
- OpenAI
- Claude
- 统一接口
-
Feature Flags
- 模型开关
- 功能开关
- 配额管理
-
使用记录
- Token统计
- 费用计算
- 日志记录
交付:
- LLM网关核心代码
- 配置文件
- 使用文档
Day 10:Week 2验收
验收标准:
- ✅ 三层代码架构清晰
- ✅ LLM网关稳定可用
- ✅ API路由模块化
- ✅ ASL可以开始开发
🎯 阶段3-4:ASL核心功能开发(Week 3-4)
时间: 2025-11-21 至 2025-12-04(2周)
目标: 完成ASL Phase 1 - 文献初筛功能
Week 3 Day 1-2:ASL详细设计 ⭐
任务:
- 详细设计asl_schema表结构
- 编写ASL数据库设计文档
- 编写ASL API设计文档
- 创建ASL表结构
- 更新Prisma模型
为什么Week 3再设计?
- Week 1-2架构已搭好
- 需求更加明确
- 避免过度设计
Week 3 Day 3-5:ASL Phase 1核心功能
功能1:文献项目管理
- 创建/编辑/删除项目
- PICO配置
- 项目列表
功能2:文献导入
- CSV导入
- 批量导入
- 数据验证
功能3:AI双模型筛选
- 集成2个大模型
- 并行筛选
- 结果对比
Week 4:ASL Phase 1完善
功能4:筛选结果管理
- 结果展示
- 人工复核
- 导出功能
功能5:测试和优化
- 完整功能测试
- 性能优化
- 用户体验优化
📊 关键调整总结
V2.1版(3详细+7空)vs V2.0版(5详细+5空):
| 项目 | V2.0 | V2.1 | 变化 |
|---|---|---|---|
| 详细Schema | 5个 | 3个 | ✅ 聚焦现有 |
| 空Schema | 5个 | 7个 | ✅ 更完整预留 |
| Week 1工作量 | 2天 | 1.5天 | ✅ 降低 |
| ASL设计时机 | Week 1 | Week 3 | ✅ 推迟 |
| 文档补充 | 无 | AIA/PKB | ✅ 新增 |
核心策略:
- ✅ 聚焦当前(只迁移现有数据)
- ✅ 架构预留(10个命名空间)
- ✅ Just-in-time设计(开发前再详细设计)
- ✅ 文档完整(与ASL保持一致)
🎯 成功标准
Week 1成功标准
- ✅ 10个Schema全部创建(3详细+7空)
- ✅ Platform/AIA/PKB数据100%迁移
- ✅ Prisma模型更新(3个详细)
- ✅ 现有功能正常运行
- ✅ AIA和PKB文档完整
Week 2成功标准
- ✅ 三层代码架构清晰
- ✅ LLM网关稳定可用
- ✅ API路由模块化
- ✅ ASL可以开始开发
Week 3-4成功标准
- ✅ ASL标题摘要初筛完成
- ✅ ASL全文复筛完成
- ✅ 用户可以完整使用ASL功能
📝 关于Monorepo的决策
决定:暂不采用Monorepo ✅
理由:
- 目录分层已经足够清晰(platform/common/modules)
- Monorepo工具(lerna、nx)增加复杂度
- 单人开发,收益不明显
- 等未来真正需要独立部署时再考虑
制定人: AI助手
版本: V2.1(3详细+7空 - 务实版)
最后更新: 2025-11-09
核心调整:
- ✅ 3个Schema详细迁移(Platform/AIA/PKB)
- ✅ 7个空Schema预留(ASL/Common/DC/RVW/ADMIN/SSA/ST)
- ✅ ASL设计推迟到Week 3
- ✅ 补充AIA/PKB完整文档
- ✅ 架构预留 + Just-in-time设计 = 高效务实 ⭐