每年三四月，总有一批做毕业设计的同学来找我参谋。今年出现频率最高的题目，就是这种“Django + Vue.js + 考研分数线预测 + 院校推荐”的组合。一个题目里塞了三四个技术点，第一眼看上去挺唬人，但拆开看，它其实就是典型的“前后端分离 + 机器学习回归模型 + 推荐算法 + 可视化报表”四合一项目。
这类选题之所以受欢迎，是因为它能一次性覆盖毕业设计要求里的“架构、算法、数据、系统、文档”五个维度：架构上有成熟的前后端分离范式，算法上有一个能讲清楚原理的预测模型，数据上有真实公开的考研历史分数线，系统上有完整的用户登录、查询、管理闭环。不管你是打算自己从零写，还是拿到的参考代码想二次开发，这篇文章我都会把每个模块的核心思路和实操坑点拆给你看，帮你省掉从选题到答辩之间最容易走弯路的那段时间。
1. 项目整体拆解：这个毕设到底做了什么
1.1 一个题目背后的三条业务主线
先说清楚这个系统解决的实际问题。考研学生最关心两件事：第一，我这个分数到底能不能上目标院校；第二，我的分数和背景到底适合报哪些学校。这个毕设系统就是围绕这两件事展开的。
从功能上拆，系统至少包含三条主线。第一条是分数线预测线，输入某个院校某个专业的历史复试分数线，预测未来一年的分数区间；第二条是院校推荐线，考生输入自己的预估分数、目标地区、专业方向，系统返回一批匹配度从高到低的院校列表；第三条是数据管理线，包括院校信息管理、分数线数据维护、用户注册登录、预测记录留存，这部分通常是加分项，也是文档里“系统完整性”的重要佐证。
如果你是第一次接触这类题目，不要被“大数据”三个字吓住。真正的分布式大数据组件，比如 Hadoop、Spark，在这个项目里绝大多数情况下是不需要用的。毕设意义上的“大数据”，指的是数据获取、清洗、分析、可视化的完整处理链路。原始分数线数据几百几千条，用 Pandas 处理完全够，MySQL 存储也没有任何压力。关键是让这条链路完整跑通，能讲清楚每一步在干什么。
1.2 为什么是 Django + Vue.js，而不是其他组合
技术选型是论文和答辩里必问的一个点，所以选型逻辑必须能自圆其说。
后端用 Django，核心原因是“一切内置”。用户认证、ORM 数据库操作、Admin 后台、安全性设置，这些在 Flask 或 FastAPI 里都需要花不少时间手动搭的东西，Django 开箱即用。对于毕业设计来说，这意味着能把更多时间留给业务功能本身，而不是跟数据库连接池、session 管理这些基础设施较劲。
前端用 Vue.js + Element UI（或 Element Plus），解决了两个问题。一个是页面交互的响应速度，前端路由跳转不需要整页刷新，体验远好过传统的 Django 模板渲染；另一个是工程化结构，组件化开发让代码看起来更有组织，符合现在企业对前端的基本认知。Vue 生态里的 axios 做接口请求、ECharts 做图表可视化，都是现成方案，文档齐全，遇到问题一搜就有答案。
这套组合还有个隐藏优势：前后端分离的架构天然适合写成“两套完整代码”。Django 只提供 JSON 接口，Vue 只消费接口数据，两边职责清晰。我在指导学生改代码的时候，这种模式最容易排查问题，也最容易在论文里画架构图。面试官或答辩老师看到“前后端分离、RESTful API、SPA 应用”这些关键词，基本都会认同选题的技术含量。
1.3 系统模块全貌：别漏掉这些基础功能
很多同学拿到一个参考项目，第一反应是去翻预测算法和推荐算法，然后用一周时间把所有注意力放在模型调参上，结果忽略了系统基本盘的完整性。最后答辩时老师问“用户怎么注册登录”“数据怎么录入”“后台怎么管理”，答不上来，非常吃亏。
一个合格的完整系统，模块划分大致如下：
- 用户模块：注册、登录、Token 鉴权、个人信息查看
- 院校数据模块：院校名称、所在省份、主管部门、院校类型（985/211/双一流/普通）、专业开设情况
- 分数线数据模块：院校、专业、年份、考试科目门类、复试线分数
- 预测模块：选择院校和专业，生成预测分数区间和趋势图
- 推荐模块：填写预估分和偏好，返回可冲、稳妥、保底三档院校
- 数据管理模块：后台维护院校和分数线数据，支持导入导出
- 可视化模块：按省份、年份、分数段做统计图表，用于展示数据价值
这七个模块不需要每个都做得很重，但一个都不能缺。它们共同构成了系统功能的“闭环”，也是文档目录结构的最好参考。接下来我把其中最关键的两个模块——分数预测和院校推荐——单独拿出来讲，这里面的技术含量才是整个项目的灵魂。
2. 分数线预测模块：从数据采集到模型调优的完整链路
2.1 数据从哪里来，怎么清洗才算合格
分数线预测的第一步是拿数据。考研复试分数线属于公开数据，每年国家线、各院校复试线在网上都能找到。实际操作中，数据来源一般有三个渠道：
- 从公开统计网站按院校、专业逐条整理
- 从历年考研辅导机构整理的数据集中提取
- 用爬虫抓取公开页面，再用脚本清洗入库
这里我要给一个忠告：毕设项目里，不要过度执着于上爬虫。爬虫本身不是难点，难的是目标网站经常改版、反爬策略复杂，你花两天写完的爬虫可能第二天就失效了。我带的同学里，十个有八个最后都改成了“半人工整理 + 脚本辅助清洗”。你只需要保证数据字段完整、来源真实、数量够用就行。一份包含近 10 年、覆盖 100 所以上院校、每个院校 3 到 5 个热门专业的分数线数据，已经足以支撑整个系统。
数据清洗是容易被忽略但实际最花时间的环节。你需要处理的问题包括：同一院校不同年份改名或合并；专业名称口径不一致，比如“计算机技术”和“计算机科学与技术”该不该算同一专业；分数线有空缺值的年份如何处理；异常值比如某年分数突然暴涨暴跌是否需要平滑。这些在论文里都可以作为“数据预处理”一章的重点写，反而是加分项。清洗后的数据建议统一以 CSV 格式保存一份，后续无论是训练模型还是测试接口，都用这份标准数据，避免反复从数据库里拉数据还要重新处理。
2.2 模型选型：为什么我不建议直接上深度学习
预测分数线，本质上是一个回归问题：根据历史年份数据和相关特征，预测下一年的分数线数值。很多同学一看到“预测”两个字就想上 LSTM、GRU 这类神经网络，我强烈不建议。原因有三个：
第一，数据量不够。神经网络要出效果，动辄需要成千上万条样本，而你的数据充其量只有几百条，强行上 LSTM 只会过拟合，训练集表现很好，测试集一塌糊涂，答辩时被问住很难收场。
第二，解释性差。答辩老师大概率会问“为什么选这个模型”“特征对结果的影响是什么”，用随机森林你可以拿出特征重要性列表，用线性回归你可以直接说每个特征的系数含义，但神经网络的权重很难直观解释。
第三，实现成本高。在 Django 里集成 TensorFlow 或者 PyTorch，打包部署时会遇到一堆兼容性问题，而用 scikit-learn 的模型，一个 pickle 文件就能搞定。
在实际项目里，效果和解释性最平衡的方案是这几种：多元线性回归适合做基线模型，证明你的特征有效；随机森林回归适合做主模型，对非线性关系拟合好，不需要大量调参；ARIMA 时间序列模型适合做对比实验，体现你对时序数据的理解；如果数据量稍微充足一点，XGBoost或LightGBM可以作为加分项。我在指导这个项目时，标准配置是“线性回归做基线 + 随机森林做主预测 + ARIMA 做对比”，三组实验结果放进论文里非常有说服力。
这里顺带解释一下特征工程。如果只用“年份”一个特征去预测分数，那本质上就是拿历史数据做趋势外推，精度很差。合理的做法是构造多个维度的特征：
- 年份序号（数值型）
- 该专业近 3 年的平均分（滑动平均特征）
- 该专业近 3 年的分数标准差（波动特征）
- 该院校近 5 年的总体录取平均分（院校层级特征）
- 国家线同年份数值（外部宏观特征）
- 是否 985/211/双一流（院校类型标签）
把这些特征拼成一个表格，训练一个随机森林回归模型，预测结果会明显比单纯按年份外推要合理。特征构造的思路也是论文里的重要篇幅。
2.3 具体实现：训练脚本和数据持久化
我用一个简化示例来说明核心代码的思路。第一步是用 Pandas 构造特征矩阵：
import pandas as pd df = pd.read_csv('score_data.csv') df = df.sort_values(['school_id', 'major_id', 'year']) # 滑动平均和滑动标准差 df['avg_3y'] = df.groupby(['school_id', 'major_id'])['score'].transform( lambda x: x.rolling(window=3, min_periods=1).mean() ) df['std_3y'] = df.groupby(['school_id', 'major_id'])['score'].transform( lambda x: x.rolling(window=3, min_periods=1).std().fillna(0) ) # 院校层级标签 df['is_985'] = df['school_level'].apply(lambda s: 1 if s == '985' else 0) df['is_211'] = df['school_level'].apply(lambda s: 1 if s == '211' else 0) features = ['year_seq', 'avg_3y', 'std_3y', 'national_score', 'is_985', 'is_211'] X = df[features] y = df['score']第二步是训练模型并存成文件，这样 Django 后端调用时不需要重新训练：
from sklearn.ensemble import RandomForestRegressor import joblib model = RandomForestRegressor(n_estimators=200, max_depth=6, random_state=42) model.fit(X_train, y_train) joblib.dump(model, 'ml_model/score_predictor.pkl') joblib.dump(features, 'ml_model/feature_list.pkl')模型文件生成好之后，在 Django 的预测接口里直接加载使用：
import joblib from rest_framework.views import APIView from rest_framework.response import Response class PredictScoreView(APIView): def post(self, request): school_id = request.data.get('school_id') major_id = request.data.get('major_id') target_year_seq = request.data.get('target_year_seq') # 构造预测样本的特征向量，这里需要从数据库查历史数据做实时特征组装 sample = build_feature_vector(school_id, major_id, target_year_seq) model = joblib.load('ml_model/score_predictor.pkl') pred = model.predict([sample])[0] return Response({'predicted_score': round(float(pred), 1)})这里有个实操细节很多同学会踩：模型训练用的特征向量顺序，必须和接口里构造的 sample 特征顺序完全一致。我见过因为调整了特征顺序、忘记同步两次导致预测结果离谱的案例，排查了半天才发现是特征错位。解决方法是把 feature_list.pkl 存好，在构造 sample 时严格按这个列表逐项生成。养成这个习惯，能少踩很多坑。
2.4 预测结果的评价指标怎么算
论文里写完模型训练，必须跟上模型评估部分。预测类题目最常用的三个指标是：
- MAE（平均绝对误差）：预测值和真实值差的绝对值的平均值，越接近 0 越好
- RMSE（均方根误差）：对大误差更敏感，能体现预测的稳定性
- R²（决定系数）：模型解释了多少比例的数据波动，越接近 1 越好
实操的时候，把数据集按年份做时间序列切分，比如用前 8 年数据训练，后 2 年数据测试，而不是随机切分。这一点特别重要，因为时序数据用随机切分会把未来信息泄露进训练集，导致评估结果虚高。用前几年训练、后几年测试，才能真实反映模型的泛化能力。我一般会要求学生在论文里把这三种指标的计算结果用表格呈现，并简单分析“哪个模型表现最好、可能原因是什么”，这就足够撑起“实验分析”这一节了。
3. 院校推荐模块：从规则匹配到评分排序
3.1 推荐的两种思路：先定方向再选策略
推荐模块的设计很容易做成“伪需求”，也就是看起来做了个列表，实际上没有任何算法含量。为了避免这种情况，我们要把推荐逻辑拆成两层。
第一层是条件过滤，也叫硬性筛选。用户填了目标省份、专业方向、院校类型（985/211/普通），系统就把不满足条件的院校全部剔除。这一层没有任何算法难度，但它是推荐真正有用的前提。
第二层是匹配度计算，即对筛选后的院校按某种策略排序。这里有两条路线可选：
- 规则评分法：预设若干指标（历年分数线差值、报录比、院校排名档位、地理因素），按权重加权求和得到一个综合得分
- 协同过滤法：根据“分数相近的用户选择了哪些院校”来推荐
我强烈建议毕设项目优先选择规则评分法。协同过滤需要大量用户行为数据，比如很多人的报考记录和录取结果，这类数据在毕设场景下很难获取，做了也是冷启动，推荐效果无法体现。规则评分法则完全可控，每个评分项都能向答辩老师解释“为什么这样打分”，这比黑箱式的协同过滤更适合展示你的设计思路。
3.2 评分公式怎么定才合理
规则评分法的核心是匹配度公式。我给出的一个典型设计如下，实际项目里可以根据数据情况调整。
match_score = w1 * historical_fit_score + w2 * level_score + w3 * region_score + w4 * competition_score每个子分数都映射到 0 到 100 区间：
- historical_fit_score（历史拟合度）：用户输入的预估分与院校近 3 年复试线平均值的差值，差值越小分数越高。比如预估分 360，某校近 3 年平均线 355，差值是 5 分，映射到 80 分；另一个学校平均线 340，差值 20 分，映射到 95 分
- level_score（院校层次）：985 给 100 分，211 给 80 分，双一流给 70 分，普通院校给 60 分
- region_score（地区热度）：一线城市可以给 100 分，新一线 85 分，其他地区 60 分，这部分体现“想不想去”
- competition_score（竞争强度）：用报录比或近 3 年分数线波动幅度来衡量，波动越大给分越低，代表不确定性越高
权重 w1 到 w4 分别设置为 0.5、0.2、0.15、0.15。为什么这个权重分配合理？因为对考生来说，能否考上是第一优先级，所以历史拟合度权重最高；院校层次代表“值不值得去”但不能掩盖考不上的风险；地区热度和竞争强度是调节因素。这个理由在论文里写出来就是完整的“算法设计依据”。
3.3 三个梯度：冲、稳、保的关键逻辑
推荐结果不能只给一个排序列表，要按梯度分组，这才是真正贴近用户需求的设计。我的实现思路是：
- 预估分高于院校近 3 年平均复试线 10 分以上，判定为“保（保底）”
- 预估分与平均线差值在正负 5 分之间，判定为“稳（稳妥）”
- 预估分低于平均线 10 到 20 分，判定为“冲（冲刺）”
每个梯度最多展示 5 所学校，按匹配度从高到低排列。这个分组逻辑很简单，但产品体验会非常好，考生一眼就能看懂自己处于什么位置。有同学想要更复杂的“冲刺程度计算”，我建议不要在这里过度设计，因为梯度分组的价值在于清晰和可解释，而不是算法炫技。
前端展示这部分，推荐用卡片式布局，每张卡片包含院校名称、层次标签、地区、近 3 年复试线、匹配度分数，点击卡片可以跳转到详情页查看历年趋势图。用 Vue 组件封装一个 SchoolCard，数据由推荐接口返回，整体开发效率很高。
4. 前端和后端联调的关键细节
4.1 接口设计规范：一个 ViewSet 搞定常用操作
前后端分离项目里，接口设计直接影响开发效率和后期维护。我建议用 Django REST Framework 的 ViewSet 加 ModelViewSet 组合，能省掉大量重复代码。
from rest_framework.viewsets import ModelViewSet from .models import School, ScoreRecord from .serializers import SchoolSerializer, ScoreRecordSerializer class SchoolViewSet(ModelViewSet): queryset = School.objects.all().order_by('id') serializer_class = SchoolSerializer class ScoreRecordViewSet(ModelViewSet): queryset = ScoreRecord.objects.select_related('school', 'major').all() def get_serializer_class(self): if self.action == 'list': return ScoreRecordListSerializer return ScoreRecordSerializer这样写好之后，前端通过/api/schools/、/api/scores/就能拿到分页数据。配合 DRF 自带的PageNumberPagination，前端传?page=1&page_size=10就能分页查询。如果你拿到的源码里接口风格不一致，最重要的改造顺序是：先统一主资源的 CRUD 接口，再统一下拉框、选项类数据的接口，最后处理自定义的预测和推荐接口。
4.2 Vite 或 webpack 代理配置与跨域
前后端分离开发中最经典的坑就是跨域。Django 跑在 8000 端口，Vue 跑在 5173 端口，浏览器直接互相请求会因为 CORS 策略被拦。解决办法有两个，开发阶段用 Vite 代理，生产阶段用 Nginx 反向代理。
Vite 配置非常直接，在 vite.config.js 里加一段：
server: { proxy: { '/api': { target: 'http://localhost:8000', changeOrigin: true } } }原理是让 Vue 的开发服务器把 /api 开头的请求转发给 Django，浏览器以为请求是同源的，就不会触发 CORS。生产环境下，如果前后端打包到同一个服务器，一般用 Nginx 把/api路径转发到 Django 所在端口。这里给一个典型的配置片段：
server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /media/ { alias /path/to/project/media/; } }注意try_files $uri $uri/ /index.html;这一行，它的作用是解决 Vue Router 的 history 模式刷新页面时 404 的问题。很多同学第一次部署时忘记这行，导致从首页点进详情页后一按 F5 就白屏，非常尴尬。
4.3 用户登录鉴权：JWT 还是 Session
传统 Django 默认用 Session 登录，但前后端分离项目更推荐用 JWT。原因是移动端、浏览器端分离场景下，JWT 的状态管理更灵活。具体实现用djangorestframework-simplejwt包，配置好之后只需要在视图里加权限类：
from rest_framework.permissions import IsAuthenticated class UserHistoryView(APIView): permission_classes = [IsAuthenticated] def get(self, request): user = request.user # 返回当前用户的预测记录前端在 axios 拦截器里统一带上 token：
axios.interceptors.request.use(config => { const token = localStorage.getItem('access_token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; });这里有一个实用的避坑经验：access token 有效期不要设得太长。默认 5 分钟太短，频繁刷新体验不好；你把它改成 30 分钟到 1 小时即可。refresh token 有效期可以设 7 天，配合用户无感刷新，既保证安全性又不会让用户天天重新登录。在 Django settings.py 里：
from datetime import timedelta SIMPLE_JWT = { 'ACCESS_TOKEN_LIFETIME': timedelta(minutes=30), 'REFRESH_TOKEN_LIFETIME': timedelta(days=7), }5. 毕设避坑手册：从开发到答辩的实用经验
5.1 数据量和冷启动问题怎么处理
做预测模块时最常遇到的问题是：某所学校某个专业的历史数据只有三四年，不足以训练随机森林模型。遇到这种情况，不要硬着头皮做全校一个模型，而是采用混合模型策略。
我的做法是：先按专科类别（工科、理科、经管、文科）训练分类模型作为底座，再把特定院校的历史数据通过滑动平均叠加偏移量修正。比如某专业只有 3 年数据，就用该专业所属门类的全量数据训练基础模型，输出一个基准预测值，然后与该专业近 3 年实际平均线做差值修正。这样即使数据少，预测结果也不会太离谱，而且代码逻辑很容易在论文里解释成“小样本场景下的自适应修正策略”。
推荐模块的冷启动问题主要出现在新用户没有任何操作记录时。解决方案是让用户在一开始就填写“预估分数、目标地区、目标专业、倾向院校层次”，把冷启动问题转化成一次结构化的信息录入，然后直接用规则评分法计算推荐结果。这也是我前面强调规则评分法的另一个重要原因：它天然不需要历史行为数据。
5.2 模型指标不好看时，先用简单方案兜底
每次到了中期检查或论文初稿阶段，总有人跑来说“模型预测误差超过 20 分，怎么办”。如果你也遇到类似问题，先别急着换模型，按顺序排查三个方向。
第一个方向是数据本身的问题。分数线数据里有没有录入错误？比如把 2021 年的 340 录成了 430。用 Pandas 的 describe 和可视化箱线图，先看数据分布是否合理。第二个方向是特征构造是否有问题。预测目标本身高度依赖专业冷热度，但年份序号和滑动均值能不能体现出专业热度的变化？可以考虑加入“该专业当年报考人数”或者“该专业的学科评估等级”这样的强相关特征。第三个方向才是换更复杂的模型。
这里还想说一句：如果实在无法把误差压到新闻里宣传的“精准预测”水平，也不要焦虑。分数线预测本质是一个高度不确定性的问题，毕设考察的是你有没有规范的建模流程、能否合理解释误差来源。论文里写“由于公开数据缺乏报考人数等关键特征，模型当前误差在 8 到 12 分之间，后续可通过补充特征和扩大数据规模进一步提升”，这是完全合理的表述。关键是你的分析过程要严谨，而不是预测数字要绝对准确。
5.3 文档和 PPT 组织：跟着模块结构走
这类项目的文档，最忌讳的是按时间流水账写“先学了什么，再做了什么”。最理想的目录结构跟系统模块对齐，让老师一眼看出你的工作重心。我建议的章节组织顺序是：绪论（背景和意义）→ 相关技术介绍 → 需求分析 → 系统设计（架构图、功能模块图、数据库设计）→ 核心算法设计与实验（预测和推荐）→ 系统实现（前后端功能截图和说明）→ 系统测试。
PPT 则控制在 15 到 20 页以内，演示顺序遵循“需求痛点 → 解决方案 → 技术亮点 → 运行效果 → 总结展望”，尽量在现场演示里跑通三个核心流程：注册登录、发起一次分数线预测、发起一次院校推荐。这三个流程跑通，会比讲二十页原理更有说服力。
5.4 时间排期建议：最少需要多少周
我给带过的同学排过很多次时间表，如果是从拿到源码开始做二次开发和深度改造，大致周期如下：
- 第 1 周：梳理源码结构，跑通前后端，弄懂每个接口对应哪个页面
- 第 2 周：完成数据整理和清洗，把预测模型和推荐算法代码吃透并调试一遍
- 第 3 周：补充自己风格的改动，比如增加可视化图表、修改页面布局、新增一个功能点
- 第 4 周：写论文初稿，重点是系统设计和核心算法章节
- 第 5 周：测试完善、论文修改、准备 PPT
如果是纯从零开发，时间要翻一倍，至少 8 到 10 周。所以我的建议永远都是：不要想着从零手写所有代码，也不要想着拿到的参考代码一字不改。正确姿势是理解它的架构，保留主干，替换和优化你最有把握讲清楚的部分，这样既保证工作量，又保证你能应对答辩老师的提问。
说了这么多，最后分享一点我个人带毕设项目时最深的体会：考研分数线预测与院校推荐这个题目，最大的价值不在于算法有多前沿，而在于它非常完整地覆盖了一个软件项目从数据到模型、从后端到前端、从功能到部署的全部环节。你做完它，简历上能写的东西、答辩时能讲的东西、甚至以后面试时能聊的东西，都会比单纯做个管理系统的同学丰富不少。认真把它吃透，真正理解每一行核心代码为什么这么写，这个过程本身比那份源码值钱得多。
