做毕业设计选题目，最怕的就是“看起来高大上，实际上无从下手”。“考研院校推荐系统 + 考研分数线预测系统”这个题目，用到的技术正好是 Python + Django，既能体现出机器学习、数据分析的能力，又能落地成一个完整的Web应用，代码量和技术含量都够，成了很多计算机专业同学毕业设计的首选项目之一。它要解决的核心问题很简单：考生想根据自身情况（比如本科院校层次、专业、期望地区、目标分数）找到适合自己的考研院校，同时预测心仪院校未来一年的复试分数线，避免“高分落榜”或者“低分高报”。我直接说结论：这个系统的难点不在 Django 框架本身，而在数据的清洗整理、预测模型的选取、推荐策略的设计上。网上成型方案不少，但能一次性跑通、数据干净、预测结果能写进论文里的版本真的不多。这篇文章适合正在选毕业设计题目、或者已经选了同类题目的同学，以及想用 Python 完整走一遍“数据分析 + Web开发 + 算法落地”全流程的学习者。我会把整体设计思路、核心功能拆解、实操步骤和踩坑记录全部捋一遍。
1. 系统全貌：题目拆解与技术选型
1.1 别被题目唬住，这个系统本质上是三件事
刚看到题目时，我第一反应也是“这得写多少代码”。但把题目拆开，它无非是三件事：一个院校信息管理的后台，一个基于历史数据的预测模块，一个根据考生画像做排序的推荐模块，再加一层 Django 的 MTV 架构把它们黏合起来。标题里的“大数据毕业设计”更多是指数据处理的完整流程，而不是真的处理海量数据。认清这一点，难度预期就准了。我给自己定的工作量评估是：数据清洗占四成，算法与模型调优占三成，页面工程化与文档占三成。
为什么会是这种比例？因为考研数据不像电商数据那样规整。不同院校发布时间不同，专业名称混乱，“计算机技术”和“计算机科学与技术”在数据里往往同时存在；分数线偶尔还有异常波动；报录比字段大量缺失。把这些脏数据理干净，后面建模才不会翻车。很多同学一上来就写模型代码，结果数据质量不过关，预测误差大到没法解释，回头又要重做数据，白白浪费时间。
1.2 技术选型：为什么是 Django 而不是 Flask 或 Spring
我说一个很实在的理由：毕业设计选技术栈，不是为了显得潮，而是为了“能跑通、能讲清楚、能放在论文里”。Django 自带 Admin 后台、ORM、用户认证、表单处理、静态资源管理，这些功能如果全部自己写，工作量至少翻一倍。相比之下 Flask 虽然轻，但很多配套设施得自己搭；Spring 体系更重，而且 Java 生态里做数据分析、机器学习不如 Python 顺手。
这个项目里还有一个隐藏需求：模型训练和预测要用 pandas、scikit-learn、statsmodels 这类库。如果 Web 框架也选 Python 系，清洗、训练、预测、展示就能在一个语言生态里闭环。我用 Django 时，通常把数据清洗和模型训练写成独立脚本，模型结果序列化成文件，Django 启动时加载；也可以在视图里直接调 pandas 读取结果表，两种模式都试过，都很稳。
1.3 模块划分与数据流向
我在动手前会把项目结构想成四个模块，目录从一开始就按这个划分，避免后期混乱：
- 用户模块：注册登录、用户画像填写（本科层次、意向地区、目标专业、期望分数）。
- 数据管理模块：院校信息维护、专业信息维护、历年分数线导入。
- 预测模块：读取历史序列，训练或加载模型，输出预测分与区间。
- 推荐模块：读取用户画像和院校特征，计算匹配度，输出 TopN。
数据流向是这样的：原始 CSV → 清洗脚本 → 数据库表 → Django ORM → 预测服务和推荐服务 → JSON 接口 → 前端图表和推荐卡片。这个流向在我画系统架构图时完全照搬，答辩时按这个顺序讲五分钟，整个系统的逻辑就闭环了。
2. 数据是这套系统的灵魂
2.1 数据到底长什么样，需要哪些字段
先说一句：这个项目如果数据做得干净，整个系统就成功了一半。以复试分数线表为例，我建议设计这些字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| school_id | 院校ID，外键 | S001 |
| school_name | 院校名称 | 示例理工大学 |
| major_name | 专业/学科名称 | 计算机科学与技术 |
| category | 学科门类 | 工学 |
| year | 年份 | 2023 |
| score_line | 复试分数线 | 320 |
| enrollment_num | 统考录取人数 | 45 |
| applicants_num | 报考人数 | 320 |
| report_ratio | 报录比 | 7.1 |
| avg_score | 录取平均分 | 348 |
| province | 所在省份 | 某省 |
院校表还需要院校层次字段，一般用编码表示：1代表985类，2代表211类，3代表双一流，4代表普通一本。专业表需要学科评级字段，比如 A 类、B 类。这些都是做推荐和预测的原材料，不要嫌字段多，后续做相关性分析、画特征热力图都需要它们。
2.2 数据从哪来，如何整理出一份干净的数据集
说到数据来源，我需要先打个预防针：真实公开数据无法保证完整性。复试线可以查到，但“报考人数”“录取平均分”这类字段经常缺失。我的做法是“公开字段用真实数据，缺失字段按统计规律合成，并在论文中如实说明”。这听起来像取巧，但毕业设计的重点是方法的完整性，你只要把数据来源、清洗规则、填充方法写明白，完全站得住脚。
清洗脚本通常做五件事：
- 统一学校名称，解决不同来源中名称写法不一致的问题。
- 统一专业名称，按学科门类归并同类专业。
- 缺失值处理，报录比缺失时用“报考人数除以录取人数”估算，再不行用近三年均值。
- 异常值处理，分数线低于100或高于500的记录直接剔除，并记录剔除原因。
- 年份对齐，保证每个院校专业都有连续年份的数据，缺失年份用线性插值。
我在这里踩过一个坑：用整体均值填充一个连续上涨的时间序列，结果预测值直接偏低。后来改成用前后年份线性插值，误差明显下降。这个细节后来写进论文，成了实验分析一个亮点。
2.3 ORM 建模与数据导入
Django 模型我建议至少设计五张表：School（院校）、Major（专业）、ScoreInfo（分数线）、UserProfile（用户画像）、RecommendRecord（推荐记录）。字段命名尽量和论文保持一致，答辩时可以直接把模型代码贴进 PPT。模型示例：
class School(models.Model): school_id = models.CharField(max_length=20, primary_key=True) name = models.CharField(max_length=100) level = models.IntegerField() province = models.CharField(max_length=50) category = models.CharField(max_length=50) class ScoreInfo(models.Model): school = models.ForeignKey(School, on_delete=models.CASCADE) major = models.ForeignKey(Major, on_delete=models.CASCADE) year = models.IntegerField() score_line = models.FloatField() enrollment_num = models.IntegerField() applicants_num = models.IntegerField()数据导入不要写在视图里，而是写成 Django 自定义管理命令，比如python manage.py import_data。用 pandas 读取 CSV 后，转成 Django ORM 批量创建对象。比起一行一行读文件，效率高一个数量级，而且命令行脚本可以反复执行，调试时很舒服。
提示：开发初期用 SQLite 没问题，但如果数据量涨到几万条，建议中期切到 MySQL。切换本身只需要改 settings.py 的数据库配置，真正麻烦的是数据迁移和重新导入，所以不要拖到答辩前才换。
2.4 数据清洗里那些最容易被答辩老师追问的细节
答辩时数据这块是老师最爱追问的区域，我特意总结过几个高频问题以及对应的说法：
- 缺失值比例：要能报出具体数字。“报考人数字段缺失率约18%，我用了近三年同专业均值和招生计划数回归补全。”这句话说明你有量化意识。
- 为什么用均值填充：不能只说“方便”，要说“该字段不随年份有明显趋势，均值填充对分布影响小；而分数线这种有趋势的字段，我用线性插值而不是整体均值。”
- 数据泄漏：老师说到底就是担心你用未来数据预测过去了。我会强调：训练集只包含某一年之前的数据，预测目标是未来年份；lag特征全部由历史值生成，没有用到未来信息。
这三个问题答上来，数据这一关基本稳过。
3. 分数线预测模块的实现思路
3.1 预测需求和指标定义
预测模块的用户场景是：用户打开某院校某专业详情页，系统显示“2024年复试线预测：325分左右，置信区间320-345”。这是一次典型的回归预测。评价指标我建议用 MAE 和 RMSE。
为什么不用 R2？因为 R2 的值范围不够直观，而 MAE 可以直接翻译成“预测值与真实值平均差多少分”。我设计的目标是 MAE 控制在6分以内。你如果论文里写出“平均误差5.8分，对考研参考有实用价值”，老师很容易接受。相比之下，吹嘘“准确率95%”那种说法太脆弱，经不起追问。
3.2 算法选型：ARIMA 打底，回归做融合
可选算法很多，我的建议是分梯队考虑：
- ARIMA：单变量时间序列模型，只用分数线序列，优点是简单，缺点是忽略了招生人数、报录比等信息，精度有限，但是很好的基线。
- 多元线性回归：把年份、前一年分数线、报考人数、招生人数等作为特征，能解释“哪些因素影响分数线”，论文里好写。
- 随机森林/XGBoost：能捕捉非线性关系，在特征有限的小数据集上表现稳定，适合做主力模型。
- LSTM：听起来高级，但小样本（往往只有个位数年份）非常容易过拟合，毕业设计不建议选它，除非你愿意花大量时间调参。
我的真实方案是“随机森林 + 线性回归融合”，ARIMA 作为对照模型。融合权重我设为 0.6 和 0.4，理由在线性回归能抓住长期趋势，随机森林能抓住非线性波动。论文里的描述是“多模型融合策略既保留了线性趋势解释力，又增强了非线性拟合能力”。一句话就能让模型听起来有思考含量。
3.3 代码落地：训练、预测与结果保存
下面是我试验过的代码路径，关键部分说明思路，可以直接在此基础上改：
import pandas as pd from sklearn.ensemble import RandomForestRegressor from sklearn.linear_model import LinearRegression df = pd.read_csv("score_info.csv") df["year"] = df["year"].astype(int) df["lag1"] = df.groupby(["school_id", "major_id"])["score_line"].shift(1) df["lag2"] = df.groupby(["school_id", "major_id"])["score_line"].shift(2) df = df.dropna(subset=["lag1", "lag2"]) train = df[df["year"] < 2023] test = df[df["year"] == 2023] features = ["year", "lag1", "lag2", "enrollment_num", "applicants_num", "report_ratio"] rf = RandomForestRegressor(n_estimators=200, random_state=42) lr = LinearRegression() rf.fit(train[features], train["score_line"]) lr.fit(train[features], train["score_line"]) test["rf_pred"] = rf.predict(test[features]) test["lr_pred"] = lr.predict(test[features]) test["final_pred"] = 0.6 * test["rf_pred"] + 0.4 * test["lr_pred"]训练完成后，把预测结果写入一张 PredictionResult 表，前端只管读表展示。这一步看起来简单，但既是“模型生效”的标志，也是论文中“系统闭环”的证据。我建议在论文实验部分附上预测值与真实值的对比表，几行数据就能体现效果。
提示：ARIMA 建模有一套固定流程。先做平稳性检验，p值大于0.05就做一阶差分；然后看 ACF 和 PACF 图定阶；最后拟合并输出预测。这套流程写进“实验方法”章节，能显著提升专业感。
3.4 预测结果怎么展示才有说服力
千万不要只显示一个数字。最有效的展示是历史折线图加预测区间：用 ECharts 画历年分数线折线，最后一年画一个预测点，再用不同颜色的阴影带表示置信区间。用户一看就知道预测值在时间轴上的位置是否合理。
实现上，前端接口/api/predict返回{years: [...], actual: [...], pred_year: 2024, pred_value: 325, pred_low: 320, pred_high: 345}，页面收到后渲染折线图。我在实际开发中把置信区间设为上下10分，这是根据训练集 MAE 放大1.5倍得到的，论文里可解释为“基于平均绝对误差构造的经验置信区间”。
4. 院校推荐模块的实现思路
4.1 推荐策略：从规则筛选到加权打分
推荐模块最怕做成“什么都能查”，然后一本正经地说“这是查表”。我的思路是分两阶段：先硬性筛选，再加权打分。硬性条件包括地区意向、院校层次、专业是否开设。不满足硬性条件的直接剔除；满足的进入打分环节。
打分维度可以这样设计：
- 院校层次：985 类 100 分，211 类 90 分，双一流 85 分，普通一本 70 分。
- 学科评级：A 类 95 分，B 类 85 分，C 类 70 分。
- 分数线匹配度：用户目标分与往年复试线差值越小，得分越高。
- 报录比：越低越匹配，满分 100，按比例扣分。
- 地区匹配：目标地区命中得 100 分，未命中根据距离降权。
权重放在后台配置，而不是写死在代码里。这一处设计在论文中值得写一句“系统支持推荐权重重配置，满足不同考生偏好”，老师会觉得你考虑了扩展性。
4.2 相似度计算和用户画像
为了让“推荐”这两个字有算法含量，我在加权打分后还会计算一个余弦相似度。思路是：把用户画像向量化，再和院校画像向量算相似度，最后把相似度和加权得分各占一半权重合成最终排序。
用户画像向量包括：目标地区编码、学科门类编码、期望院校层次、目标分数。院校画像向量包括：所在省份编码、专业学科评级、历年分数线均值、历年报录比均值。数值型特征归一化到 0-1，类别型特征做 One-Hot 编码，然后计算余弦相似度：
from sklearn.preprocessing import StandardScaler, OneHotEncoder from sklearn.metrics.pairwise import cosine_similarity # user_vec 和 school_vec 分别为特征向量 sim = cosine_similarity([user_vec], [school_vec])[0][0] # 最终得分 = 0.5 * 加权得分 + 0.5 * sim这一段代码虽然量不大，但能让论文从“基于规则的筛选系统”升级成“基于内容过滤和属性加权的混合推荐模型”，技术含量完全不同。
4.3 推荐结果的可解释性设计
答辩时候老师最爱问的其实是：“为什么推荐这所学校？”如果回答“因为分数高”，会显得很苍白。我建议每条推荐都带上理由标签，例如：
- “该专业复试线低于你的目标分12分，录取概率较高。”
- “该校报录比 9:1，竞争激烈，建议谨慎。”
- “该专业学科评级为 A，与你的专业偏好匹配。”
- “该校所在省份与你意向地区一致。”
实现上，推荐接口返回每个院校的得分明细和理由列表，前端直接渲染成卡片底部的标签。可解释性不仅是给用户看的，也是给自己答辩的“答题线索”，你照着理由标签讲，不会卡壳。
5. 前后端联调与系统集成
5.1 视图层与接口设计
项目接口我建议简单、直接、可演示。三个核心接口分别负责推荐、预测、历史数据：
/api/recommend：接收用户画像参数，返回推荐列表。/api/predict：接收院校ID和专业ID，返回预测值、区间。/api/history：返回历年分数线，给前端画图用。
视图层我用函数式视图，配合@csrf_exempt和 JSON 响应。每个接口都做参数校验，比如地区参数为空时返回“请选择意向地区”的提示。答辩演示时，最怕的就是填了个空值，页面直接报错。参数校验这个细节，能让你避开很多尴尬。
5.2 前端页面与交互流程
前端用 Bootstrap 加原生 JavaScript 加 ECharts，我不用 React/Vue，原因有两个：一是毕业设计重点不在前端，二是引入大框架后构建流程会变得复杂，反而掩盖了系统核心逻辑。页面交互设计成三步走：
第一步，注册登录后进入个人中心，填写或修改用户画像。第二步，点击“开始推荐”，跳转推荐页，看到 TopN 院校卡片，每张卡片有匹配理由。第三步，点击某张卡片进入详情页，看到院校信息、历年分数线折线和预测值。
实操中我踩过一个典型坑：ECharts 在 DOM 未渲染完成时初始化会得到空白图表。解决办法是把图表初始化放到接口数据返回后再执行，例如在then回调里写initChart()，避免在页面加载时直接调用。
5.3 演示环境的一站式部署
答辩的现场环境没法预料，最稳妥的做法是全部本地化，不依赖外网，数据库用预置好数据的 SQLite，模型文件放在项目目录，静态资源全部打包好。演示前我习惯按这个流程走一遍：
- 创建虚拟环境，安装 requirements.txt。
- 执行
python manage.py migrate建表。 - 执行
python manage.py import_data导入预置数据。 - 启动
python manage.py runserver 0.0.0.0:8000。 - 用测试账号登录，走一遍“推荐-预测”主流程。
这几步写成一篇“环境部署说明”放进文档，论文里再写一句“系统支持一键初始化部署”，答辩老师对工程完成度的印象分直接拉满。
6. 常见问题与排错实录
6.1 数据导入报错
最常见的是 CSV 编码问题。Windows 下导出的 CSV 默认 GBK 编码，pandas 用 UTF-8 读取就会报 UnicodeDecodeError。解决办法是指定encoding='gbk'，或者另存为 UTF-8 with BOM。另一个经常出现的问题是一列数据里混进了空格，比如" 2023 "，这类字段不清理干净，后面所有运算都会出错，轻则结果异常，重则模型直接不收敛。清洗脚本里加一个统一的.strip()是非常值得的。
6.2 预测结果与真实值差异过大
如果预测值比真实值高出一大截，或者呈现不合理的直线趋势，先不要怀疑算法，先检查数据泄漏。判断方法很简单：训练集是不是只用了历史年份？LAG 特征是不是由未来值生成的？分数线缺失值是不是用整体均值填充的？
我自己就翻过车。我用的数据只有六七年，2015年的分数结构和2022年差异很大，模型把年份当成主特征之后，预测值直接变成线性外推，误差大得没法看。最后我把 LAG 特征做成了“前一年分数差”，即lag_diff = score_line - score_line.shift(1)，模型不再直接拟合绝对分数，而是拟合年度变化量，效果立刻稳定了。这个技巧写进论文的优势在于，它体现了你对时间序列本质的理解。
6.3 推荐结果不符合预期
推荐结果出现明显不合理时，先检查两件事：第一，权重设置。如果高目标用户总被推荐报录比特别高的院校，说明数据库权重偏高，要把“分数线匹配度”和“报录比”权重调高。第二，硬性筛选是否过严。我在初版把“地区不符合就剔除”作为硬条件，结果把很多匹配但地区不理想的院校直接删掉了。后来我改成“硬条件只做院校层次和专业开设筛选，地区不匹配改成低权重扣分”，推荐结果的人性化程度明显提升。
6.4 答辩演示的准备工作
项目交付物包含代码、文档、PPT、讲解视频，这几样东西的准备各有讲究。论文四个方面一定要写透：技术选型动机、数据来源与清洗规则、模型评价指标、系统测试用例。我有一次旁听答辩，发现不少同学论文里连“训练集年份区间”都没写，被老师一问就愣住。实验数据这页 PPT 用一张“历年预测误差表”就够了，但表格要能说明每一年的预测值和误差。
PPT 控制在 20 页左右，重点放系统架构图、数据库 ER 图、预测效果对比表、推荐效果截图，代码不要大段贴，贴关键函数就行。讲解视频不用追求精剪，但流程要完整：从注册登录，到填写画像，到推荐列表，到详情页图表，最后落到预测结果，全程操作流畅，不卡壳。视频时间控制在 8-12 分钟，基本能满足要求。
最后再分享一个小技巧：整套系统做完以后，把“数据清洗记录”和“模型误差表”单独导出两份 Excel，不只是为了写论文，更重要的是你自己心里有底。我带过的一些项目里，凡是能把数据问题讲清楚的，答辩基本都顺利；反而是那种急着跑模型、数据一塌糊涂的，往往在提问环节被追到无话可说。如果你也在做这个题目，我的建议是先花充足时间把数据整理好，再谈算法，再谈页面，项目就会顺很多。祝各位毕业设计顺利上岸。
