每年毕设季我都要帮忙看几十个题目前往不同方向的技术方案见得最多的就是两类一类是纯管理系统功能单一、算法含量低答辩时很容易被评委一句话问住另一类是纯粹的网页展示看起来花哨但没有实际业务闭环。而今天的这个题目——Django Vue.js 考研分数线预测系统、考研院校推荐系统属于那种“看着不复杂、实际能展开讲很多”的典型。它能做的事情很直接考生输入自己的目标专业、地区、预估分数等条件系统一方面基于历年分数线数据预测今年的国家线、院校线另一方面从数据里筛出匹配的院校并给出推荐排序。对正在准备考研的同学来说这是一套辅助决策工具对正在做毕业设计的学生来说这是一个横跨数据采集、数据清洗、算法建模、前后端开发、系统部署的完整项目。这篇文章我会把整个系统的设计思路、算法细节、实现方案和踩坑过程拆开讲适合正在选毕设题目的本科生也适合想把类似系统做成求职项目的人参考。1. 为什么选这个题目三个核心需求点与毕设适配度分析1.1 分数预测解决“够不够得着”的问题考研和高考有一个很大的不同高考是先出分再填志愿而考研是先填志愿再考试而且只能填一个目标院校。这意味着考生在报名前必须回答一个非常现实的问题——以我的水平报哪所学校更可能考上没有人能给出标准答案但历年分数线一定是最重要的参考维度之一。分数线并不是一条孤立的数字它的波动背后有规律可循。年份、试题难度、报考人数、录取人数、院校热度这些因素都会影响当年分数线。预测模块的核心就是把这些历史数据收集起来提取特征训练出能拟合这种波动规律的模型输出下一年的预测值。对于毕设来说这里天然就有算法深度可以从简单的时间序列均值预测、线性回归一路做到随机森林、LSTM甚至可以对比不同模型的效果差异作为论文里很有说服力的实验章节。对于考生而言预测结果虽然不能替代官方信息但能提供一个相对理性的参考区间。比如系统预测某专业今年的复试线会在350到365之间考生就可以结合自己模考的情况判断“报这所学校风险是否过大”。这就是这个系统实用价值最直接的体现。1.2 院校推荐解决“选哪所”的问题全国有几百所院校开设硕士点每个学校又有不同的专业方向、考试科目、招生人数、报录比、地理位置和就业口碑。考生在没有辅助工具的情况下想快速从这么多信息里找出一批“和自己匹配的学校”非常费时。院校推荐模块解决的就是信息筛选和排序的问题。考生输入偏好条件比如“想在江浙沪”“只要计算机相关专业”“不接受专业课考408”“希望是211及以上”系统先做硬性过滤把所有不满足条件的院校剔除然后对剩余院校做多维度评分排序。推荐结果不是凭空来的每一项都落到数据上历年分数线匹配度、报录比、招生规模、专业课科目重合度、城市发展指数等。这种“规则过滤 加权评分”的思路在工程上是成熟且可解释的非常适合作毕设核心功能同时也很容易在答辩环节讲清楚。1.3 作为毕业设计的评分弹性从哪来一个题目能不能成为好的毕设关键在于评分弹性也就是不同投入程度的同学分别能做到什么水平。基础版本只需要完成数据的展示和查询做一个前后端分离的信息系统具备院校信息维护、分数线查询、用户登录注册这些功能工作量足够撑起一个合格的本科毕设。进阶版本加入预测算法用真实数据训练模型并评估效果论文就有了核心实验章节。高阶版本进一步强化推荐策略引入多因子加权或者更复杂的排序算法再配合数据可视化大屏、后台管理系统、定时数据更新任务整体完成度可以直接对标求职作品集。而且这个题目还有一个天然优势考研是每年都有大量真实需求的社会话题评委不会质疑题目没有应用场景也不用担心业务逻辑太冷门导致答辩时讲不清楚。2. 技术栈选型Django Vue.js 怎么分工以及“大数据”怎么落地2.1 Django做后端ORM、Admin、鉴权一站解决后端选择 Django最核心的原因是开发效率和对数据处理的友好度。Django 自带 ORM定义好模型类之后数据库建表、增删改查都不需要写 SQL这对不熟悉数据库细节的同学非常友好。比如分数线历史表、院校信息表、用户表只需要定义几个 Python 类迁移命令一执行表结构就自动同步到数据库后面改字段也不需要手动去数据库执行 ALTER TABLE。另一个经常被低估的能力是 Django Admin。这个自带的后台管理界面在毕设里几乎等于“白送”一个管理端。维护院校名单、批量导入分数线、管理用户反馈这些操作在 Admin 后台配置一下就能直接用不用额外写前端页面。对于需要给评委演示“系统具有后台管理功能”的毕设来说这个功能节省的时间非常可观。Django 的认证体系也省事。用户注册、登录、会话管理、密码加密都是现成的接入自定义用户模型就可以扩展收藏院校、查询记录这类业务字段。如果从零手写这些功能动辄要多消耗一周的开发时间。2.2 Vue.js做前端组件化与交互体验前端选择 Vue.js主要看中它组件化的组织方式和成熟的生态。页面拆成头部导航、院校列表卡片、分数线趋势图表、推荐结果面板这些独立的 .vue 组件之后各组件只负责自己那一块逻辑不会出现一个文件几千行的问题后期调试和维护的难度会低很多。Vue 的数据绑定非常适合这类信息类系统。以推荐结果页为例用户调整筛选条件后前端把条件参数发给后端接口拿到新的推荐列表之后通过数据响应式机制自动刷新页面渲染。整个链路不需要手动去操作 DOM代码写起来更像是在描述“页面上应该显示什么数据”而不是“一步步怎么操作页面”。生态方面配套的 UI 组件库、状态管理工具、路由管理器都很成熟另外还有专门的图表库可以承接分数线趋势图、预测对比图这类可视化需求。做毕设的时候不需要从零手写复杂图表直接封装组件即可。2.3 “大数据”标签怎么落地才不虚这个系统从数据量级来说一年十几万考生使用、数万条分数线记录确实不算是严格意义上的海量数据。但“大数据毕业设计”这个标签不是指必须上 Hadoop、Spark 集群而是指系统处理的数据规模、数据维度和性能优化方式具备工程化思维。实际落地时我会从三个层面去贴这个标签。第一是数据层面设计合理的数据表结构建立索引用 MySQL 存储结构化数据用 Redis 做热点数据缓存例如高频访问的历年分数线汇总和推荐结果缓存。第二是接口性能层面列表分页、ORM 查询优化、JSON 序列化优化这些手段写进论文里会是非常实际的性能分析章节。第三是任务调度层面设计一个定时更新的数据同步任务定时抓取最新的招生政策和分数线数据让系统具有持续更新的能力。这套组合拳写进论文既能展示对数据链路的理解又不会把自己逼上非要搭分布式集群的绝路。毕设的重心是证明“我理解数据规模上来之后会有什么问题以及怎么解决”而不是非要跑到多大规模才叫大数据。3. 分数线预测模块数据形态、模型选型与误差控制3.1 预测三级别国家线、院校线、专业线分数线预测不能笼统地说“预测考研分数线”因为分数线本身分了好几个层级预测的目标不同数据形态完全不一样。最上层是考研国家线这是考生进入复试的基本分数要求分学术学位和专业学位又分 A 类考生和 B 类考生等不同类别。国家线数据每年每个类别只有一条时间跨度可能只有十几条样本这种数据量适合做长期趋势分析用移动平均、线性回归这类简单模型即可强行上深度学习只会过拟合。中间层是院校线即院校在国家线基础上划定的复试分数线。这部分数据覆盖的学校多、专业多样本量相对充足是预测模块的主战场。比如某高校计算机学院的学硕复试线过去十年每年一条附加上当年的报考人数、招生人数、试题难度等特征之后可以训练一个简单的回归模型。最底层是专业线具体到某个学院某个专业的录取最低分。这个层级最容易出现数据缺失很多院校只公布复试名单或拟录取名单需要手动整理才能得到完整的时间序列。因此专业线的预测通常只对数据条件好的重点专业做。预测时要特别注意“分数线不是一个孤立时间序列”这件事。国家线、院校线、专业线之间有强关联关系而且当年的报考热度、招生规模、试题难度都会导致分数线异常波动。把预测单纯当成“用过去几年分数线预测下一年”就太简单了会让模型在数据波动大的年份产生明显偏差。3.2 特征工程怎么做我见过不少同学一上来就训练模型结果效果很差然后开始怀疑算法选错了。实际上问题往往出在特征上。分数线预测的特征可以从三类数据里去提取趋势类特征最近 N 年的分数线值、移动平均、同比增长率、波动幅度。这类特征反映的是分数线自身的变化惯性。竞争类特征报考人数、录取人数、报录比、推免比例。这类特征反映供需关系对分数线的压力。背景类特征当年的试题难度评估、院校热度排名、地区经济指数、政策变动标记。举个例子某专业过去五年招生人数逐年减少报考人数却在增加报录比从 5:1 涨到 9:1那么即便分数线历史曲线平稳模型也应该给出更高的预测值。这就是竞争类特征存在的意义。特征构造的具体操作上常用滑动窗口的方式把时间序列转成监督学习数据集。比如用前三年的数据预测第四年那么每一条训练样本就由长度为 3 的窗口特征加上一个目标值构成。窗口大小一般取 3 到 5太小了模型学不到长期趋势太大了样本量会被严重削减。3.3 模型对比线性回归、随机森林、LSTM哪家强这里直接给结论毕设阶段不要只做一个模型而是做一组对比实验最后用实验数据说明为什么选某个模型作为最终方案。这套对比本身就是论文的核心实验章节。线性回归是最稳的 baseline它的优势在于可解释性强。训练完之后可以明确看到“报考人数每增加一万人分数线大约会上升多少分”这种结论写进论文非常直观而且评委很容易听懂。随机森林适合处理特征和目标之间存在非线性关系的情况对异常值不像线性回归那么敏感不需要做特别精细的特征缩放属于“省心但不太好解释”的选手。LSTM 是深度学习的代表理论上能捕捉时间序列中的长期依赖。但这类数据通常只有十几到几十条样本LSTM 非常容易过拟合训练出来的效果往往还不如随机森林。这不是 LSTM 本身的问题而是样本量撑不起模型的复杂度。实际对比下来经常会出现“LSTM 在训练集上效果很好在测试集上一塌糊涂”的典型场景。推荐的做法是用线性回归和随机森林作为主要预测模型做参数调优LSTM 作为深度学习方法做对照实验论文里明确写出“由于样本量限制LSTM 未能稳定超越集成模型”这个结论。这反而是数据量不够大的项目中最诚实也最有说服力的实验设计。模型训练过程要格外注意数据泄露问题。特征里如果有“今年的报考人数”和“今年的分数线”同时出现在同一条样本里测试阶段又用未来数据去预测过去评估结果就会虚高。按时间顺序分割训练集和测试集是这类项目的基本纪律比如用前 80% 的时间段训练、后 20% 的时间段验证。模型适合的数据量可解释性实现难度毕设推荐度线性回归15条以上可用强低必做baseline随机森林30条以上效果较好中低主力模型LSTM通常需要数百条弱高对照实验ARIMA20条以上可用中中可做时序对比3.4 模型评估与结果可视化预测结果不能只丢一个数字一定要带上置信区间或波动范围。原因很简单考生需要知道“预测线是 350”更需要知道“这个预测有多可靠”。如果历史数据波动较大模型给出的区间自然就宽如果历年数据很稳定区间就窄。这种表达方式比单一数值更有参考价值。评估指标用 MAE平均绝对误差和 RMSE均方根误差就够了。MAE 的直观含义是“平均预测偏差多少分”比如 MAE 为 6.5 分可以理解为预测线和实际线平均差 6.5 分左右。RMSE 对大误差更敏感如果预测偶尔出现了一次超过 20 分的偏差RMSE 会拉得很高这也是一个很重要的参考信号。可视化方面前端可以用折线图展示历史分数线曲线与预测点的对比用柱状图展示不同院校预测难度的对比用散点图展示实际值与预测值的贴合程度。图表的意义不只是好看更是答辩时最直观的“证据”。我见过很多学生算法讲得不清不楚但图表一亮出来评委马上就能看懂你做了什么、效果怎么样。4. 院校推荐模块硬性筛选 多维加权评分4.1 推荐流程分两步不要混在一起做推荐系统最容易犯的错误是把所有的筛选和排序条件揉在一起最后用户和评委都搞不清楚结果是怎么来的。正确做法是把推荐流程明确拆成前后两个阶段。第一阶段是硬性条件过滤也叫“一票否决”。比如用户要求只接收统考数学的专业那所有考数学二或自命题的专业直接排除用户要求不想去偏远地区那不符合地区条件的院校直接排除。这个阶段不做任何打分条件不满足就出局。硬性条件通常来自用户表单里的下拉选项字段设计得越明确过滤越干净。第二阶段是对剩余院校做多维加权评分。每一所院校先分别计算各个子维度的得分再按权重加权求和得到综合评分最后按综合评分降序排列。排序结果可以按“冲、稳、保”三档标注出来对应预测录取概率的高中低这样考生一眼就能看出哪些学校值得冲一下哪些学校是稳妥选择哪些是保底选择。4.2 评分维度与权重设计评分维度是推荐系统的灵魂。维度设计不合理后面的权重全是白调。以这个系统为例我通常会设计五个核心维度分数匹配度用户预估分数与院校预测线之间的差值差值越接近零且略微超过匹配度越高。这个维度直接决定了“能不能考上的可能性”。报录比竞争度报录比越高说明竞争越激烈得分越低。如果报录比数据缺失就退而求其次用“录取人数”做替代指标。招生规模友好度招生人数多的院校容错空间更大得分适当提升。专业课契合度用户的本科课程和该校考试科目重叠度越高备考成本越低得分越高。发展资源指数包括院校层次、学科评估档次、所在城市发展水平。这部分数据相对稳定可以维护成基础字典表。权重的设置优先用层次分析法或者熵权法来确定而不是拍脑袋定数字。简单做法是设计一张专家打分问卷让几位有经验的学长学姐对维度重要性打分然后构造成对比较矩阵计算权重。这一段写进论文能让推荐算法显得科学很多。评分公式可以简化成综合评分 各项子分数乘以对应权重后求和再把结果缩放映射到 0 到 100 分的区间。子分数的计算逻辑要做到能够解释清楚每一步尤其要避免“黑盒推荐”。提示推荐结果一定要提供“为什么推荐这所学校”的说明比如显示“这所学校近三年分数线与你的预估分数高度匹配且招生人数近年呈扩招趋势”。透明的推荐逻辑比黑盒高分更容易取信用户。4.3 预测和推荐怎么联动分数线预测模块和院校推荐模块不是两个独立的功能而应该是一条完整链路里的两个环节先预测各目标院校的专业分数线再把这些预测结果作为推荐评分的关键输入。具体的联动方式是这样的用户输入预估分数后系统先调预测模块计算该用户所有候选院校的预测分数线然后计算差距。比如某校预测线是 355用户估分是 360两者差距只有 5 分分数匹配度得分就高另一所学校预测线是 380差距 20 分分数匹配度得分就低。预测结果直接参与推荐评分用户在推荐页看到的不只是“往年的分数线”而是“基于模型预测的今年分数线”这个体验比静态查询历史数据要高一个层次。反过来推荐模块的使用行为也能为预测提供反馈数据。用户频繁查看但最终没有选择的院校可能意味着它们热度偏高这个热度信号经过量化后可以作为下一轮预测时的特征输入。这种双向闭环可以写进论文的“系统迭代与后续展望”部分属于很有内容的加分项。5. 数据链路采集、清洗、对齐与入库5.1 公开数据源与采集策略这类系统的数据来源以公开渠道为主教育招生主管部门公示的数据、各院校研究生院官网公布的招生简章与历年复试分数线、考研信息平台上的汇总数据等。采集方式分两种一种是针对页面结构固定的网站写定向爬虫另一种是下载公开的统计文件后做结构化解析。做定向爬虫的时候要注意目标网站的请求频率控制设置合理的访问间隔避免给对方服务器造成压力。另外有些网站有反爬机制验证码和登录限制会给采集带来很大的工作量所以前期评估数据源时要优先选结构公开、访问稳定的站点。如果自身编程经验有限也可以考虑手动整理一部分核心数据。考研核心院校数量控制在几十所每所院校的重点专业分数线手动录入也不是完全不能接受但前提是要有足够的时间和耐心。折中方案是“爬虫采集 人工校对”机器先抓主要字段再人工抽检修正异常值这也是企业里很多数据团队的日常操作方式。5.2 数据清洗和对齐的坑分数线数据的清洗难度被很多人低估了。最常见的坑包括同一所学校在不同年份的数据口径不一致有的年份公布的是复试基本分数线有的年份公布的是拟录取最低分两者之间可以相差几十分直接混在一起训练模型会出大问题。还有专业名称不统一的问题。同一专业在不同院校可能叫“电子与信息”“信息与通信工程”“电子信息”如果不做学科代码对齐推荐系统匹配专业时就会漏掉大量应该出现的院校。缺失值的处理需要分情况。如果某个院校某一年分数线缺失但前后两年都有数据可以用前后均值填充如果某院校近一半的数据都缺失建议直接不把该院校放到预测候选集里而不是强行用填充值污染模型。年份对齐也是老生常谈有些院校用的是入学年份口径有些用的是招生年份口径差一年会导致你的时间序列整体错位这是很隐蔽但影响极大的问题。数据清洗阶段我强烈建议写校验脚本而不是纯手动改 Excel。脚本可以维护一张“院校别名表”和“专业别名表”做自动映射也可以写一份数据质量报告统计每条记录的缺失率、异常值数量方便反复检查调整。5.3 数据库表设计与更新机制表设计上我会分成五张核心表院校信息表、专业方向表、历年分数线表、招生计划表、用户行为表。院校信息表存学校的基础属性专业方向表存学校和专业的关联关系历年分数线表存时间序列数据招生计划表存历年计划招生人数和报考人数用户行为表存收藏、查询记录。这五张表之间的关联关系并不复杂重点是给高频查询字段创建索引。分数线和招生计划都是典型“按院校查、按专业查、按年份查”的结构索引能明显提升查询速度。更新机制方面可以设计一个管理命令或定时任务。每次更新时先抓取新增的分数线数据做差量更新而不是全量覆盖以保留历史数据完整性和变动记录。再配合 Django Admin 提供人工修正入口机器抓取和人工审核结合起来让数据质量可控。6. 从代码到演示核心接口、前端页面与本地跑通6.1 API设计请求与响应约定前后端分离项目的关键是一套约定清晰的接口协议。我通常采用 RESTful 风格统一响应结构。比如推荐接口的设计是前端 POST 用户的筛选条件和预估分数后端经过过滤和评分后返回推荐院校列表每条推荐项包含院校基本信息、预测分数线、各个子维度得分和综合评分。响应结构固定为包含状态码、消息、数据和分页信息的 JSON 格式前端通过状态码判断请求是否成功再用消息字段展示错误提示。这么做的好处是前后端可以并行开发前端根据接口文档 mock 数据后端按文档实现逻辑最后联调时再修正细节。注意接口文档要写清楚每个字段的类型、是否必填、取值范围。推荐接口尤其要说明评分字段的含义比如 score 是 0 到 100 的综合评分rank 是 “冲稳保” 标记以免前端同学看着一堆数字不知道怎么展示。6.2 前端重点页面拆解前端页面不需要做得多花哨但关键路径上的几个页面必须功能完整、逻辑清晰。核心页面包括首页展示系统核心能力入口简单放推荐流程图和数据统计卡片。分数线查询页支持按院校、专业、年份筛选用折线图展示历年分数线变化趋势。预测结果页展示各目标院校预测分数线配置信区间带和模型对比说明。个性化推荐页表单输入偏好和预估分数提交后展示推荐列表卡片式布局展示各维度得分和推荐理由。院校详情页展示某所学校的详细信息、历年分数线表格、招生人数趋势、相关推荐院校。后台管理页复用 Django Admin 定制用于维护院校数据和分数线数据。页面组件化之后公共部分如导航栏、页脚、筛选表单、图表卡片等都做成通用组件不同页面复用代码量能缩减不少。图表组件建议统一封装传入数据格式之后自动渲染折线图、柱状图或散点图保持风格一致。6.3 本地跑通的完整步骤本地把项目跑起来的流程每一步都值得仔细梳理创建虚拟环境并激活避免依赖包和系统环境互相干扰。安装 Python 依赖核心包括 Django、数据库驱动、数据处理库、机器学习库和跨域支持库。前端在项目目录下执行 npm install 安装依赖包。在 MySQL 中创建数据库实例修改 Django 配置里的数据库连接信息注意编码设置成 utf8mb4否则中文数据入库容易乱码。执行数据库迁移生成表结构导入初始化的院校和分数线数据。启动 Django 后端服务先访问接口文档或直接访问某个查询接口确认后端返回正常数据。启动 Vue 开发服务配置本地开发环境的接口地址代理把前端请求转发到后端服务避免跨域问题。用测试账号登录系统完整走一遍“查询分数线 – 查看预测 – 提交推荐条件 – 查看推荐结果”的流程确认页面数据和后端日志都没有报错。第一次跑通之后建议把整套启动命令和注意事项整理成项目根目录里的 README 文件或者直接录制一份演示视频。答辩时如果现场环境出现问题演示视频就是最稳妥的备份方案。7. 实战中的坑性能、过拟合、联调与部署7.1 Django ORM查询与序列化的性能问题Django ORM 用起来省事但默认行为里藏着不少性能陷阱。最常见的是 N1 查询问题遍历院校列表每访问一次关联的专业或分数线就额外执行一次数据库查询列表长度变成 100 时数据库压力就变成 1 100 次查询。解决办法是在查询时用 select_related 和 prefetch_related 提前把关联数据加载进来把多次查询合并成一次大查询。在毕设演示阶段数据量小可能看不出差别但论文里写出这个优化前后的查询时间和内存占用对比就是一笔很扎实的性能优化章节。序列化阶段也要注意。不要把整个关联对象链全部序列化比如某院校关联了三十年的分数线和所有招生计划前端只需要近五年的数据后端就应该在序列化时做字段过滤和切片而不是把全量 JSON 发给浏览器。过大的响应体除了拖慢加载速度还会在演示时被评委当场发现页面半天转不出来。7.2 模型过拟合数据少怎么办时间序列预测和普通分类任务不同样本量天然受限很容易出现训练集效果极好、验证集一塌糊涂的过拟合问题。我的经验是不要硬扛着训练深度学习模型而是采用多种手段降低过拟合的影响。一方面是减少模型复杂度比如线性回归加正则化项随机森林限制最大深度和最小叶子节点数。另一方面是合理做交叉验证时间序列不能随机打乱要用按时间顺序前进式的验证方式。还有一种很实用的思路是把相近专业的分数线合并起来扩充样本比如同属工科门类的几个专业分数线走势具有较强的相关性可以放在同一个数据集里训练让模型学到整个门类的共性规律。预测结果也应该输出区间而不是硬报一个精确值。在预测值基础上加减一倍的预测标准差作为参考区间一方面能规避模型偶尔的较大偏差另一方面也让系统的输出更显专业和可信。7.3 前后端联调与部署的常见问题前后端联调阶段最常见的坑就是跨域配置。本地开发时后端服务运行在 8000 端口前端开发服务运行在 5173 或 8080 端口浏览器会阻止跨源的 Ajax 请求。本地环境的解决方案是配置开发代理把前端请求转发到后端如果已经部署到生产环境则要在后端正确配置允许的跨域来源列表并处理好预检请求。部署环节需要注意的细节更多。首先是生产模式下的静态文件收集Django 需要把所有前端构建产物和自身静态文件集中到一个目录再交给服务软件托管。其次是数据库配置从 SQLite 切到 MySQL 后要重新执行迁移和导入数据别拿着测试库直接上生产。最后一个容易被忽略的问题是环境变量管理。数据库密码、密钥这类敏感信息不要硬编码在配置文件中用环境变量注入是一个好习惯。部署一台最小配置的云服务器使用 Nginx 托管静态文件、使用 Python 应用服务器托管 Django再把前端构建产物放到静态目录下用 Nginx 统一对外提供服务整个链路就通了。这一套部署方案在论文里写清楚项目的完整度会明显提升。8. 我的实操体会与建议我实际带着这类项目走查过很多轮之后最大的感受是这个题目的上限比大多数人想象得高但大多数人没能把上限做出来。原因不在于算法多难、代码多复杂而在于很多人把精力花在了写代码之外的东西上——有的同学花了太多时间纠结某一个院校的推荐权重是不是“绝对合理”其实评分权重本来就是主观设计加客观数据校准的结果能解释清楚逻辑就够了还有的同学把精力花在爬全量数据上导致整个项目周期被数据采集拖垮最后核心系统反而没时间完善。我的建议是把握住一个原则先让主流程完整跑通再谈细节完善。分数线预测跑出一个可解释的效果推荐模块给出透明可理解的排序逻辑前后端联调顺畅这就已经是一个合格且完整的毕设了。在此基础上如果还有时间再去丰富数据维度、优化模型效果、增加部署文档。另外数据分析能力的展示强烈建议别忽略。预测模型的评估图表、推荐结果的可解释理由、数据库与接口的性能优化记录这些内容写到文档和PPT里答辩时的说服力会远远超过放几张页面截图。做这套系统不只是为了毕业把数据采集到展示的每个环节打通之后这份经验放到任何数据产品或后台系统的项目里都能迁移。