直接讲结论：这个选题放在计算机类毕业设计里，属于性价比很高的一档。它把数据分析、算法模型、后端接口、前端可视化、部署运维全都串起来了，又不要求特别深的数学底子，做完之后论文、PPT、答辩素材都很容易凑齐。我见过不少同学选这个方向，但很多人卡在同一个问题上——不知道分数线预测到底该怎么建模，推荐系统怎么做才不像在糊弄，以及数据从哪来。这篇文章就把我实测过的一整套方案拆开讲，从数据清洗、特征工程、模型选型、接口设计到前端可视化，再到论文写作和答辩应对，尽量把每一步的坑都标出来。
1. 项目定位与技术选型
1.1 题目在解决什么问题
先说清楚这个系统是干嘛的。考研学生报考之前最关心的两件事：一是目标院校某个专业今年的分数线大概会是多少，我的成绩能不能够上；二是我这个背景条件（本科院校层次、专业、目标地区、期望分数）适合报哪些学校。这两个需求对应到技术上，就是分数线预测和院校推荐。
和普通的教务管理系统、博客系统相比，这类项目的优势在于带明显的"数据价值"。你可以天然地把机器学习、数据可视化、统计报表这些东西装进去，而不显得牵强。很多同学做选题容易犯的毛病是"为了用算法而用算法"，把一个XX系统硬套一个分类模型。但这个题目不一样，预测和推荐本身就是题目明确要求的业务功能，算法的存在是合理的。
还有一点很实际：考研是每年都有的大热点，用户场景大家都很熟悉，写需求分析、可行性分析的时候不用编瞎话，前期描述起来顺，答辩评审老师也能快速听懂你做的是什么。
1.2 为什么前端选 Vue.js，后端选 Django
这个组合在毕设圈里几乎是标准答案，但很多人只是跟风，我说下里头的逻辑。
Django 最核心的优势是自带 ORM 和 Admin 后台。考研相关数据表（院校表、专业表、历年分数线表、用户表）之间存在不少外键关联，用 Django 的 ORM 做关联查询非常省事，不用手写 SQL 和对象映射。Admin 后台更是帮了大忙，原始数据录入、校正、增删改查都可以直接通过可视化页面完成，相当于白送了一个管理端。你自己只需要额外做面向用户的端就可以。
Vue.js 的优势在于组件化开发和响应式特性。分数线趋势图、院校对比卡片、推荐结果列表，这些功能拆成组件之后，数据变动页面会自动更新，开发体验比直接用 jQuery 操作 DOM 舒服太多。配 Element UI 这样的组件库，表单、表格、标签、弹窗写起来很快，界面不会像原生页面那样粗糙。
这两个组合还有一个实际好处：前后端通过 JSON 接口通信，天然分离。后期如果把页面换成小程序端或者 App 端，接口可以直接复用；答辩时老师如果问"系统有没有扩展性"，这就是现成的回答点。
1.3 功能模块整体蓝图
我在实际开发时把系统按角色切成了三类功能，这个划分也直接对应数据库设计和论文结构：
- 游客端：查看数据可视化大屏、查看院校分数线趋势、使用分数线预测功能。
- 注册学生端：填写个人背景和偏好问卷，获取院校推荐列表，查看推荐理由，收藏意向院校。
- 管理员端：管理院校信息、专业信息、历年分数线数据、学生账号、预测模型参数。
技术上，前端按页面拆成数据大屏、分数线查询页、预测页、推荐页、个人中心；后端按业务拆成用户模块、数据管理模块、预测模块、推荐模块。二者通过 RESTful 接口对接。
2. 数据层建设：考研数据从哪来、怎么存
2.1 数据的合法获取与整理
先说一个劝退问题：很多同学一开始想的是爬数据，把目标网站的信息爬个几万条，然后开始做分析。实际操作你会发现，爬虫本身不算难，但数据清洗会把人逼疯。
我的建议分两步走。第一步，优先找公开的开源数据集。国内有不少开源项目会定期整理各大院校历年复试基本分数线、录取最低分、招生人数等信息，文件通常是 CSV 或 JSON 格式，用 pandas 读进来就能用。这类数据虽然是二手整理，但字段规范，省掉大量清洗时间，用来做系统 demo 完全够。第二步，只对确实缺失的部分做补充数据采集，而且只采集公开可访问的信息，不碰需要登录、有明显访问限制的渠道。不要动歪脑筋去搞私域、破解接口之类的东西，那已经不是技术问题而是合规问题了。
某位同学做这个题的时候，最初爬了两天拿了大概四万条记录，结果导入数据库后发现编码混乱、字段错位、院校名称一个学校能有三四种写法，光清洗就花了一周。后来换用公开数据集，半天就把 2014 到 2024 年近三万条核心数据准备好了。所以数据源策略很重要，先拿标准数据搭骨架，再按需补充，而不是一开始就想着"爬全网"。
2.2 数据库设计的两张核心表
这套系统的核心数据表按我的经验至少要这五张：
- 院校信息表：存学校名称、所在省份、院校层次（985 / 211 / 双一流 / 普通本科）、是否自划线、院校综合评分。
- 专业信息表：存专业名称、专业门类、专业热门度指数。
- 历年分数线表：核心事实表，存年份、院校外键、专业外键、复试分数线、录取最低分、报考人数、录取人数。
- 学生用户表：存本科院校、专业、目标地区、期望分数、应届/往届。
- 推荐记录表：存每次推荐的输入、输出结果和模型版本。
分数线表是核心中的核心，它需要关联院校和专业两个外键。比如"某东部省份重点高校 + 计算机科学与技术 + 2023年 + 复试线 355"就是一条完整的记录。设计时要把分数线分为学术型硕士和专业型硕士两套字段（如果有的话），因为现在专硕和学硕分数线差距越来越大，混在一列里会让后面的预测模型学到错误规律。
2.3 数据清洗的三个常见坑
数据清洗这块，我只讲三个我实测踩过、几乎每个人都躲不开的坑。
第一个坑是院校名称不一致。"某某理工大学"和"某理工大学教学点"这种属于低级的，高级的是同一学校在历史数据里改过名，比如某学校从"学院"改名为"大学"，不合并的话同一学校会被拆成两条，推荐系统就会出错。处理办法：做一张院校别名映射表，加载数据时统一归一化到最新校名。
第二个坑是缺失值和离群值。有的专业某一年没有招生，分数线会是空值；有的年份复试线异常低，可能是首次招生没人报，也可能是数据录错了。我的做法是：针对连续缺失两年以上的专业直接剔除；针对异常值，用前后两年的均值填充，同时加一个"数据置信度"字段，在预测接口里根据置信度提示用户结果仅供参考。
第三个坑是地区字段的不一致性。建议把省份统一映射到七大地理分区（华东、华北、华南、华中、西南、西北、东北），这个字段后面既要做可视化的地图热力分布，也会作为推荐系统的过滤条件，如果值不统一，视觉和算法都会出问题。
3. 分数线预测模型：核心拆解与落地
3.1 预测目标怎么定义才合理
很多同学一上来就问"用什么模型预测考研分数线"，其实先要想清楚的问题是：预测目标到底是什么。
我建议不要只输出一个具体的分数，比如"预测某校某专业 2025 年分数线是 358"。原因很简单：单点预测误差肯定存在，考生拿着 358 这个数字去比对去年 355 的复试线，心态上就会出偏差。更合理的目标是预测一个区间，比如"预计 350 到 370 之间，中位预测值 360"，同时给出近三年分数线趋势和样本量，让用户自己判断。
技术实现上，模型输出是连续值，所以这不是分类问题，是回归问题。损失函数用均方误差（MSE），评估指标用平均绝对误差（MAE）和决定系数（R²）就够了。目标字段可以是复试线，也可以是录取最低分，取决于你觉得哪个对考生更有参考意义。我用的是录取最低分，因为它比复试线更能反映实际录取难度。
3.2 特征工程比选模型更重要
必须反复强调一件事：考研分数线预测这类数据量不大的场景，特征工程的重要性远大于模型选择。每家院校每个专业每年只有一条分数线记录，历史跨度撑死十年，你要让模型从这么少的数据里学到规律，就得把外部特征补足，让规律更明显。
我自己用的特征分三组。第一组是时间特征，包括年份（转成当年相对基准年的序号）、年份趋势项、是否为"大年"（去年分数异常高则回调概率大）。第二组是院校专业特征，包括院校层次（985/211/双一流/双非映射为分值）、专业热门度指数（按各专业历年报考人数归一化后排序）、院校所在地区竞争热度（用该地区应届考生规模估计）。第三组是数据特征，包括该专业近三年分数线均值、上一年分数、近五年分数标准差。
这组特征喂给模型之后，预测结果是明显好于只用"年份 + 分数线"两列的线性模型的。所以我想强调：花时间做特征，比换一个更复杂的神经网络有价值得多。别一上来就想着深度神经网络，这种小数据场景，复杂模型只会过拟合。
3.3 Django 后端集成的模型代码示例
下面给一个可以直接用在项目里的简化版代码。预测模块我放在 Django 应用下的services/predict_service.py中，先把历史分数线从 ORM 读出来，再交给 scikit-learn 训练。
import pandas as pd from sklearn.ensemble import RandomForestRegressor from sklearn.preprocessing import StandardScaler from .models import ScoreLine class ScorePredictor: def __init__(self, school_id, major_id): qs = ScoreLine.objects.filter( school_id=school_id, major_id=major_id ).order_by('year') self.df = pd.DataFrame(list(qs.values( 'year', 'score_line', 'enroll_num', 'report_num'))) self.model = None self.scaler = StandardScaler() def build_features(self, df): # 年份序号化 df['year_idx'] = df['year'] - df['year'].min() # 近三年均值 df['prev_avg3'] = df['score_line'].rolling(3, min_periods=1).mean().shift(1) # 上一年差值 df['prev_diff'] = df['score_line'].diff().fillna(0) # 近五年标准差 df['prev_std5'] = df['score_line'].rolling(5, min_periods=1).std().shift(1).fillna(0) return df def train(self): df = self.build_features(self.df.dropna()) feature_cols = ['year_idx', 'enroll_num', 'report_num', 'prev_avg3', 'prev_diff', 'prev_std5'] X = df[feature_cols].values y = df['score_line'].values # 按时间顺序切分，不洗牌，防止未来信息泄漏 split = int(len(X) * 0.8) if split < 3: self.model = None return X_train, X_test = X[:split], X[split:] y_train, y_test = y[:split], y[split:] self.scaler.fit(X_train) self.model = RandomForestRegressor( n_estimators=200, max_depth=4, random_state=42) self.model.fit(self.scaler.transform(X_train), y_train) y_pred = self.model.predict(self.scaler.transform(X_test)) self.mae = float(abs(y_pred - y_test).mean()) def predict(self, target_year): if self.model is None or len(self.df) < 5: # 数据不足时，用全国同类专业均值兜底 base = ScoreLine.objects.filter( major_id=self.df['major_id'].iloc[0] ).aggregate(avg_score=Avg('score_line'))['avg_score'] return {'low': int(base - 10), 'high': int(base + 10), 'mid': int(base), 'confidence': 'low'} latest = self.df.iloc[-1].copy() future_df = self.build_features(latest.to_frame().T) future_df['year_idx'] = future_df['year_idx'] + (target_year - latest['year']) feature_cols = ['year_idx', 'enroll_num', 'report_num', 'prev_avg3', 'prev_diff', 'prev_std5'] X_new = self.scaler.transform(future_df[feature_cols].values) mid = int(self.model.predict(X_new)[0]) # 用测试集 MAE 构造区间 width = max(8, int(self.mae * 1.5)) return {'low': mid - width, 'high': mid + width, 'mid': mid, 'confidence': 'medium' if self.mae < 10 else 'low'}注意代码里有几个很关键的设计细节。按时间顺序切分而非随机切分，这是时间序列预测的常识，否则用未来数据训练、过去数据预测，指标会虚高。用测试集 MAE 来生成置信区间，而不是拍脑袋定宽度，这个逻辑在论文里也能写清楚。只有至少五条历史数据才训练本地模型，否则用全国同类专业均值兜底，避免冷启动问题导致输出极端值。
3.4 评估指标怎么看
做模型评估时不要看 TRAINING 集上的效果，训练集 R² 到 0.98 没有意义，要看测试集。我测试后的经验是，这种数据量下随机森林的 MAE 大概在 8 到 14 分之间，也就是预测平均偏差约十分，这个精度对考研参考场景够用，但不适合给用户传达"绝对准确"的概念。
所以前端页面一定加一句话："预测结果基于历史数据建模，仅作择校参考，不构成报考建议。"这不是免责声明的问题，是做产品的基本态度。答辩时老师如果问"预测的可靠性如何"，你就可以把测试集 MAE 摆出来，再说明如何通过区间来表达不确定性，这比回避问题得分高得多。
4. 院校推荐系统：规则托底加评分排序
4.1 推荐策略的选择
推荐系统一上来就搞协同过滤、矩阵分解，在毕设里往往是不讨好的，因为用户冷启动和数据稀疏会让效果看起来匪夷所思。考研院校推荐本质上是一个"高投入、低频次"的决策场景，用户一生可能只填一两次问卷，协同过滤很难积累到足够的用户行为数据。
我的选型是"规则过滤 + 综合评分排序"的混合策略，逻辑清楚，可解释性强，答辩也好聊。第一步先过滤出硬性候选集，第二步对候选项量化打分排序，第三步生成推荐理由。
这个策略的优点是：规则保证了推荐结果不会出现"文科生被推了纯工科专业""目标地区在北方却给你推南方院校"这类低级错误；评分排序保证了结果有区分度；推荐理由可以从打分维度的贡献中直接解释，实现起来比黑盒模型自然很多。
4.2 综合评分公式与权重
评分公式我按 100 分制设计，四个维度加权求和：
- 院校实力分（30%）：985 院校 95 分，211 院校 88 分，双一流 82 分，普通本科 70 分，再叠加软科排名区间加分。
- 录取匹配度（40%）：这个维度最关键。用用户预估的考试分减去该校近三年录取最低分均值。差值为正表示过线把握较大，原则上差 5 到 15 分匹配度最高；差值太大说明该校对考生来说过于保守，差值接近零或者负数说明冲刺性太强。
- 地区偏好分（20%）：用户选择了目标地区，完全命中的给 90 分，相邻地区给 70 分，其他按距离递减。
- 专业热度适配度（10%）：用户意向专业和该校重点学科的匹配程度，以及该专业在目标院校的招生稳定性。
打分之后排序，输出 Top 10。我在实际实现里还在规则层做了一个保护：用户如果选了"只接受 211 以上院校"，那么普通院校直接过滤掉，不参与打分，避免用户为了凑够十个推荐而看一堆自己根本不会报的学校。
4.3 相似考生行为辅助排序
规则打分虽然稳，但容易被老师说"没有算法含量"。为了平衡，我加了一个轻量级的相似考生逻辑：在推荐记录表里存了历史考生的特征向量（本科层次、是否应届、目标地区、预估分数、最后选择的院校专业），新用户进来后计算特征相似度，把相似考生最终选择的院校作为一类附加信号，给同院校叠加一个 5 分的"同路人偏好分"。
相似度用简单的余弦相似度或者加权欧式距离就可以，不需要上复杂的 embedding。这个做法的好处：让推荐逻辑有了"数据驱动"的味道，同时不破坏规则过滤的底线；而且推荐记录是系统自己一点一点积累出来的，跑得越久推荐越贴近真实情况。
4.4 推荐理由怎么生成
推荐理由是整个页面看起来像不像"真产品"的分水岭。很多同学做的推荐页面就是一个列表加一个分数，显得很空。我做了三行字：
- 第一行：综合得分和预估录取概率。
- 第二行：该校近三年分数线走势概览，例如"近三年该专业录取线 345 / 352 / 348，波动较小"。
- 第三行：按贡献最大的两个维度生成具体解释，例如"该校为东部省份重点高校，综合实力较强；结合你的预估分 360，录取匹配度处于合理区间"。
实现方式是按分数维度贡献率排序，取前两名的维度拼接模板字符串。这个细节在答辩展示时观感很好，老师会明显觉得你在产品体验上花了心思。
5. 前后端联通与数据可视化落地
5.1 接口设计：RESTful 风格怎么拆
后端接口我按业务域拆分，主要就这几个：
- 用户相关：
POST /api/register、POST /api/login、GET /api/profile。 - 分数线相关：
GET /api/schools、GET /api/majors、GET /api/score-lines?school_id=&major_id=。 - 预测相关：
POST /api/predict（传入院校、专业、目标年份）。 - 推荐相关：
POST /api/recommend（传入用户问卷），记录每次推荐。 - 可视化相关：
GET /api/trends/overall聚合全国数据用于大屏展示。
接口层我用的是 Django REST Framework，序列化器配合视图集，代码量少，权限控制也方便。预测和推荐接口因为是计算密集型的，我做了简单的响应缓存：同样的请求参数在半小时内直接返回缓存结果，避免模型反复训练影响接口响应速度。
5.2 ECharts 可视化大屏
可视化是这类系统最容易出视觉效果的部分，也是答辩 PPT 里最好看的截图。我做了四个图表：
- 全国各省考研热度地图：用 ECharts 中国地图的省份着色呈现，颜色越深代表报考热度越高。
- 历年分数线趋势折线图：选某个院校专业后，展示近十年分数线变化，配合预测区间的阴影带。阴影带很直观地告诉用户"预测范围在这里"。
- 各院校分数线对比柱状图：用户选择多个心仪院校后横向对比。
- 热门专业分布饼图：统计不同门类专业在数据集中出现的频次。
要注意的是，ECharts 的版本和 Vue 的兼容性。我在项目里用的是 Vue 2 + ECharts 5，init 图表放在mounted生命周期里，数据请求完成后再用setOption更新。有个细节踩过坑：地图需要单独注册 GeoJSON 数据，不注册的话地图区域是空白的。
5.3 前后端联调的三个关键点
第一，跨域问题。开发环境下 Vue 跑在 8080 端口，Django 跑在 8000 端口，前端请求后端必须配置 CORS。我用django-cors-headers解决的，注意要设置CORS_ALLOWED_ORIGINS而不是图省事直接全开，不然答辩时老师问你安全策略你会很难解释。
第二，时间字段的格式统一。Django 返回的 datetime 格式和 JavaScript 期望的格式不一样，建议统一返回YYYY-MM-DD字符串。我在 serializer 里单独处理，而不是前端做转换。
第三，打包后静态文件的路径问题。Vue 打包的 dist 目录要交给 Django 托管时，需要改settings.py里的STATICFILES_DIRS和TEMPLATES的路径配置，否则刷新子路由时 404，或者接口请求地址出错。这里最容易出现的怪问题是：页面能打开但是 CSS 加载不出来，十有八九是静态文件路径写成了绝对路径。
6. 实战中的常见问题与排查心得
6.1 环境与依赖：最浪费时间的隐形杀手
这类项目依赖链很长，Python 有 Django、DRF、pandas、scikit-learn，Node 有 Vue、Vue Router、Element UI、ECharts，随便哪个版本不对都跑不起来。
我强烈建议一开始就用虚拟环境锁定版本，Python 侧用 requirements.txt 锁版本号，Node 侧用 package-lock.json。我见过太多人因为 scikit-learn 版本过新，导致某个 API 废弃，模型代码报错找不到sklearn.preprocessing。另外注意 Django 和 MySQL 的版本兼容性，Django 较低的版本配高版本 MySQL 会报mysqlclient扩展缺失，建议干脆用自带 SQLite 起步，数据量不大的场景完全够用，省心太多。
6.2 模型训练接口首次请求特别慢
预测接口第一次调用时，如果服务端临时训练模型，会明显卡顿。我排查后发现每次都是同一个问题：没有缓存训练好的模型对象。我的解决办法是：模型在服务启动时预加载一次，训练好的随机森林模型通过 pickle 序列化保存到本地文件，第二次起直接读文件。数据更新后通过后台管理页触发手动重新训练，而不是每次请求现学现卖。
这个问题的排查过程也值得记进论文的测试部分，它说明你考虑到了"算法要工程落地"。
6.3 Vue 页面白屏和接口报错的分工排查法
前端联调时白屏和接口报错经常混在一起，我总结了一个固定排查顺序。第一步看浏览器 Network 面板，接口如果报 500，先看 Django 控制台日志，看是不是模型序列化问题；接口如果报 200 但页面没数据，问题在 Vue 的异步渲染时机，检查数据是否在 DOM 渲染后才返回，可能需要加v-if或者默认值。第二步看 console 里的报错关键词，出现undefined is not a function多半是数据字段名对不上，前后端字段命名不一致是联调中最隐蔽的 bug，建议接口返回前用单元测试固定字段格式。
6.4 导入数据时卡死和内存溢出
几万行的 CSV 用 pandas 读入后直接批量往 MySQL 写，会遇到两个问题：一是事务太大导致插入超时；二是内存占用飙升。我的处理是分批写入，每 500 条提交一次事务；另外不要用Model.objects.create一条条插，改用bulk_create，速度能提升好几个数量级。
这个经验在论文的"系统性能优化"一节里能写两页纸，答辩时被问到"你的系统能不能支撑全国数据"，你就可以直接量化回答：单批次 500 条、单表峰值 5 万行场景下，接口平均响应时间多少毫秒。
7. 毕业设计文档、PPT 和答辩准备
7.1 论文文档怎么写才有深度
很多同学做系统花了三周，写论文只花两天，结果被导师批回来改三遍。我的体会是，论文结构其实就是系统的镜子，按章节展开自然就有内容。
需求分析部分详细描述三种角色的使用场景，最好能配一些用例表，比如"游客只查看可视化页"和"学生需要注册后才能使用推荐功能"这些规则。系统设计部分把数据库表的字段罗列清楚，画清楚架构图。核心算法的原理部分，不要抄书上的公式，而是结合你自己的实现讲：为什么用随机森林、为什么评估用 MAE、推荐权重是怎么定出来的。这部分是所有论文里最容易拉开差距的地方。
数据可视化部分也是一个比较好的亮点。不要只截图，要写清楚每个图表解决什么信息获取问题，比如"折线图叠加阴影带，是为了直观表达预测区间的不确定性"，这种描述会让论文显得有思考深度。
7.2 PPT 控制在十五页左右
PPT 我建议做成十五页左右，结构固定：目录页、项目背景、需求分析、技术选型、系统架构、数据来源与清洗、核心算法、功能演示截图、测试结果、创新点总结、不足与展望。
其中功能演示截图页数至少占三页，按"前台可视化 → 分数线预测 → 院校推荐 → 管理后台"顺序放图。算法页不要放满代码，放一张特征列表和一张评估指标表就够了。创新点写三到四个：预测结果采用置信区间输出、推荐系统可解释性、数据可视化大屏、模型周期性重训练机制。这些放大了别人很难模仿的地方。
7.3 答辩高频提问和应对思路
答辩时被问最多的问题基本固定，我提前准备一下答案就可以。
"数据哪来的？"回答：公开整理的数据集加公开渠道补充采集，事先清洗过去重和异常值，数据规模有哪些量级，以及数据置信度如何标记。
"为什么要用随机森林而不是线性回归？"回答思路：先承认线性回归在可解释性上的优势，再说明考研分数线受多因素影响、存在非线性关系；随机森林能捕捉特征交互，且通过限制树深控制过拟合，实测 MAE 比线性回归低多少分。
"推荐系统为什么不用协同过滤？"回答思路：考研决策场景用户行为数据稀疏，协同过滤冷启动严重；现阶段采用规则加评分排序的策略，保证推荐结果可解释，同时通过记录用户决策数据为后续引入协同过滤打底。
"系统有什么不足？"这个问题千万别回答"没有不足"。老老实实说几点：历史数据只有近十年，样本量有限；预测模型尚未考虑单科线政策变化和当年试题难度，存在较大不确定性；推荐评分权重依靠人工预设，没有通过数据训练优化。说完之后补一句"这也是下一步要改进的方向"，整个回答就很完整了。
我个人建议答辩前一天把"预测模型怎么用测试集评估的"这个问题彻底搞清楚，因为它几乎必问，而且能一下区分出系统是不是你自己做的。你用逻辑讲清楚"按时间顺序切分、测试集 MAE 是多少、区间取 MAE 的 1.5 倍"这一套，老师基本不会再追问什么。
这个项目做完之后，我最大的感悟是：好的毕业设计不是功能多花哨，而是你清楚地知道自己为什么这样设计，以及每一步取舍背后的代价是什么。如果你正在做或者准备做这个题目，我上面写的这些经验，尤其是特征里包含近三年均值和上一年差值的处理方式，以及推荐理由生成的三个层次，都是立刻能给你省时间的干货。
