1. 先聊聊痛点：毕业设计管理为啥需要系统化？
在动手之前，我们得先搞清楚要解决什么问题。传统的毕业设计管理，很多学校还停留在 Excel 表格、微信群和邮件往来的阶段，这里面槽点实在太多了：
- 选题冲突严重：学生和导师之间信息不对称，经常出现'一个课题多人抢'或者'好导师被秒光'的情况，全靠手速和关系，很不公平。
- 过程进度黑盒：开题、中期、答辩这些关键节点，学生提交了啥材料，导师批阅意见是什么，管理员很难全局掌握，催进度基本靠吼。
- 权限管理混乱：学生误操作了导师的审核界面，管理员不小心删了数据，角色权限划分不清晰，容易出乱子。
- 文档版本灾难：论文、报告反复修改，不同版本的文件散落在各个聊天记录和邮箱里，查找和归档简直是噩梦。
所以，我们的系统核心目标就是：流程线上化、操作透明化、权限精细化、文档集中化。
2. 技术选型：为什么是 FastAPI + SQLAlchemy？
确定了目标，接下来就是选择趁手的工具。这里主要对比了两个主流方案：
Web 框架：Django vs FastAPI
- Django：大而全，自带 Admin 后台、ORM、用户认证，开箱即用。如果追求快速搭建一个管理后台，Django 非常合适。但它的'全家桶'模式有时也显得笨重，灵活性稍差，对于需要精细控制 API 行为和性能的场景，可能不是最轻量的选择。
- FastAPI：现代、异步优先、性能极高，并且自动生成交互式 API 文档（Swagger UI）。我们的系统核心是提供清晰的 RESTful API 给前端（比如 Vue/React），FastAPI 的声明式依赖注入系统让实现 JWT 认证、角色权限检查变得异常优雅和模块化。最终我选择了 FastAPI，看中的就是它的高性能、清晰的代码结构以及对 OpenAPI 的原生支持。
数据库：关系型 vs 文档型
- 关系型数据库（如 PostgreSQL/MySQL）：数据结构规整，存在明确的导师、学生、课题、任务、提交记录等实体，且它们之间关联复杂（一对一、一对多、多对多）。事务性要求高（比如确保学生选题和导师确认的原子性）。因此，关系型数据库是更自然的选择。
- 文档型数据库（如 MongoDB）：虽然存储如论文草稿这样的半结构化数据很方便，但对于强一致性要求和复杂关联查询的业务，优势不大。
所以，我们选择 PostgreSQL 作为主数据库，配合 SQLAlchemy ORM 来操作。SQLAlchemy 的强大之处在于其表达能力和灵活性，可以清晰地定义模型关系。
3. 核心模块实现细节与 AI 助攻点
整个系统围绕几个核心模块展开，这里分享几个关键部分的实现，以及 AI 工具如何帮我'偷懒'。
3.1 用户角色与 JWT 鉴权
系统有三类用户：学生、导师、管理员。权限设计是关键。我使用 fastapi-jwt-auth 库来处理 JWT。
首先，定义角色枚举和用户模型：
from enum import Enum
from sqlalchemy import Column, Integer, String, Enum as SQLEnum
from app.database import Base
class UserRole(str, Enum):
STUDENT = "student"
TEACHER =
ADMIN =
():
__tablename__ =
= Column(Integer, primary_key=, index=)
username = Column(String(), unique=, index=, nullable=)
hashed_password = Column(String(), nullable=)
full_name = Column(String())
role = Column(SQLEnum(UserRole), nullable=)
