diff --git a/README.md b/README.md
index 5e63df6..61a47ad 100644
--- a/README.md
+++ b/README.md
@@ -5,9 +5,9 @@
 # 每个人创建自己的分支
 1. 每个表里都要有创建时间、更新时间、逻辑删除字段
 
+---
 
-好嘞，这份需求文档我帮你梳理清楚 + 出技术文档 + 拆6人分工，直接能拿去团队开会用。
-
+# 版本一
 一、需求整理（去冗余、补逻辑）
 
 核心实体关系（ER 简版）
@@ -254,10 +254,249 @@ git checkout -b feature/migration-test   # F
 5. 数据库操作全部走 crud 层，api 层不直接写 SQL
 6. 统计接口复杂查询放 services 层，crud 只做简单读写
 
-四、给你的额外建议
+# 方案二：
+这份需求文档涉及 学生管理、成绩、就业、班级、老师、统计分析 6 大模块，加上数据库设计和后续合并测试，正好适合 6 人小组 按“模块 + 公共基础”的方式分工。下面给你一套可直接落地的分工方案，兼顾开发效率、代码解耦和答辩覆盖度。
 
-1. 今天就能做的事：A（组长）按上面的目录结构建好项目，pip install -r requirements.txt 跑通，push 到 Git，其他人 clone 下来直接开干。
-2. AI依赖（ollama/openai）：需求里没说怎么用，如果老师要求用 AI 功能，可以加一个"智能查询"接口——用自然语言问"帮我找一下Java班成绩最好的学生"，后端调 AI 转成 SQL 执行。
-3. 冗余字段同步：学生改了姓名/班级，就业表的冗余字段要跟着改，这个逻辑放 crud/student.py 的 update 方法里，记得提醒 D 同学配合。
+一、推荐分工方案（6 人）
 
-需要我帮你把某个模块（比如学生管理）的 models + schemas + crud + api 完整代码骨架 写出来，你们直接往里填逻辑吗？
+✅ 原则
+
+• 每人负责 1 个独立模块
+
+• 1 人负责 公共基础 + 数据库 + 项目骨架
+
+• 每人独立分支，最后统一合并
+
+• 答辩时每人都能讲“自己写的代码 + 涉及的设计”
+
+👥 人员分工表
+
+成员 负责模块 核心职责
+
+A（组长/架构） 公共基础 + 数据库设计 项目初始化、数据库建模、BaseModel、异常、依赖、路由聚合、合并分支
+
+B 学生基本信息管理 学生 CRUD、逻辑删除、查询筛选
+
+C 成绩管理模块 成绩录入、修改、删除、学生成绩查询
+
+D 就业管理模块 就业信息增删改查、冗余字段设计
+
+E 班级 & 老师管理模块 班级、老师信息管理、带班关系
+
+F 统计分析模块 所有统计接口（成绩/就业/基本信息统计）
+
+二、每人详细职责说明
+
+👤 A：公共基础 + 数据库设计（非常关键）
+
+职责：
+• MySQL 数据库设计（ER 图、表结构）
+
+• FastAPI 项目骨架搭建
+
+• 公共依赖（数据库 session、分页、权限预留）
+
+• Pydantic 基础模型
+
+• 统一异常处理
+
+• 路由汇总（include_router）
+
+• Git 分支管理与最终合并
+
+产出：
+• models/
+
+• schemas/
+
+• database.py
+
+• dependencies.py
+
+• exceptions.py
+
+• main.py
+
+📌 建议分支：
+
+dev/base
+
+
+👤 B：学生基本信息管理
+
+职责：
+• 学生表设计建议
+
+• 学生增删改查
+
+• 逻辑删除
+
+• 条件查询（编号/姓名/班级）
+
+API 示例：
+• GET /students
+
+• POST /students
+
+• GET /students/{id}
+
+• PUT /students/{id}
+
+📌 分支：
+
+dev/student
+
+
+👤 C：成绩管理模块
+
+职责：
+• 成绩表设计
+
+• 成绩录入、修改、删除
+
+• 单学生成绩查询
+
+API 示例：
+• POST /score/
+
+• GET /score/{stu_id}
+
+• PUT /score/update
+
+• POST /score/delete
+
+📌 分支：
+
+dev/score
+
+
+👤 D：就业管理模块
+
+职责：
+• 就业表设计（含冗余字段）
+
+• 就业信息新增 / 更新
+
+• 多条件查询（公司、薪资范围）
+
+API 示例：
+• GET /employment/students/{id}
+
+• POST /employment/students/{id}
+
+📌 分支：
+
+dev/employment
+
+
+👤 E：班级 & 老师管理模块
+
+职责：
+• 班级表、老师表
+
+• 班级 CRUD
+
+• 老师 CRUD
+
+• 带班关系设计
+
+API 示例：
+• GET /classes
+
+• POST /classes
+
+• GET /teachers
+
+📌 分支：
+
+dev/class-teacher
+
+
+👤 F：统计分析模块
+
+职责：
+• 所有统计 SQL / ORM 查询
+
+• 成绩统计
+
+• 就业统计
+
+• 基本信息统计
+
+API 示例：
+• GET /statistics/xxx
+
+📌 分支：
+
+dev/statistics
+
+
+三、Git 分支与合并策略（强烈建议）
+
+分支结构
+
+ ├── dev/base           （A）
+ ├── dev/student        （B）
+ ├── dev/score          （C）
+ ├── dev/employment     （D）
+ ├── dev/class-teacher  （E）
+ └── dev/statistics     （F）
+
+
+合并流程
+
+1. A 先完成 dev/base
+2. 其他人从 dev/base 拉自己的分支
+3. 每人开发完成后 → PR 到 dev/base
+4. A 负责 code review + 合并
+5. 最后合并到 main
+
+四、数据库设计建议（给 A 的提示）
+
+核心表
+
+• student
+
+• score
+
+• employment
+
+• class
+
+• teacher
+
+• class_teacher（多对多）
+
+冗余字段处理
+
+• 就业表中：
+
+  • student_name
+
+  • class_name
+
+• 插入/更新时同步，查询时直接读
+
+五、答辩 & 抽查应对策略
+
+每人必须能讲清楚
+
+• 自己负责模块的：
+
+  • 表结构
+
+  • API 设计
+
+  • 关键代码逻辑
+
+• 为什么这样设计（尤其是统计 SQL）
+
+组长额外准备
+
+• 项目整体架构
+
+• 数据库 ER 图
+
+• 分支管理
+
+• 合并冲突解决