企业官网建设流程全解析

考研选校这件事，经历过的人都懂——看着近千所高校、几百个专业方向，分数出来以后全世界都在替你焦虑，唯独没有人能拍着胸脯告诉你：“就报这个，稳。”信息差是最大的问题，而这个项目就是冲着解决信息差去的。用Python+Django搭一个考研院校推荐与分数线预测系统，让考生输入自己的本科院校、专业、目标地区、预估分数，系统基于历史数据和协同过滤算法，推荐适合的院校，同时对目标院校的分数线做预测。对计算机专业的学生来说，这是一个标准的大数据方向的毕业设计选题，有算法、有数据、有Web系统，论文和答辩都有东西可写。

这篇文章会把整个项目的设计思路、数据来源、推荐算法、预测模型的实现细节、Django的完整搭建过程、以及答辩准备时需要避开的坑，全部拆开讲一遍。无论你是正在选毕设题目的在校生，还是想复现类似系统的开发者，这篇内容都能帮你少走很多弯路。

1. 项目整体定位：为什么“推荐+预测”是毕设好选题

毕设选题最怕两件事：一是太空，做出来像玩具，撑不起论文；二是太偏，算法研究难度过高，写到中期就想放弃。考研院校推荐系统这个题目恰好卡在一个非常舒适的位置——既有真实业务场景，又有算法落地空间，还有Web展示部分，属于典型的“数据+算法+工程”三段式结构，每一段都能独立展开成论文的章节。

1.1 考研选校的真实痛点

考研和高考最大的区别在于，高考是先出分再报志愿，有明确的分段参考，而考研是先报学校后考试，只能依靠往年数据做预判。这就导致考生在做选择时极度依赖经验信息——学长学姐的反馈、贴吧论坛的碎片帖子、考研机构的付费咨询。信息源分散且滞后，大部分人实际上是在信息不充分的情况下做了一个影响未来两三年的重要决策。

系统要解决的痛点很清楚：把院校招生数据、历年分数线、报录比、考试科目、地区分布等信息结构化，再结合考生个人的偏好和客观条件，给出量化的推荐结果。不需要考生一篇一篇翻经验帖，输入几个条件就能拿到一份按匹配度排序的候选院校列表，同时对每所学校的录取概率给出参考区间。这比单纯提供数据查询多了一层“决策辅助”的价值，也正是论文立意的核心卖点。

1.2 推荐系统和预测系统合一的优势

很多同类毕设只做推荐，不做预测；或者只做分数线展示，不做推荐。这个项目把两者合并，好处不只是功能丰富，而是算法层面可以互相支撑。推荐系统用的是“历史考生行为数据”——大量考生最终选择了哪所学校；分数线预测用的则是“院校本身的招生数据”——历年分数线、招生人数、报考热度等。两个模块数据来源不同、算法逻辑不同，但在系统架构上共享同一套数据库和用户体系，这正好构成了一个完整的数据产品闭环。

从论文写作角度来说，推荐和预测各成章节，既能展示协同过滤、推荐算法这类传统机器学习内容，又能引入时间序列回归、特征工程等预测模型内容，两个方向都有深度可挖。工作量也合理——一个人在一个毕业设计周期内完全可以完成。如果只做推荐，算法部分会显得单薄；如果只做预测，又会缺少用户交互的亮点。两者合一，既保证工作量，又保证叙事完整性。

1.3 为什么选Python+Django而不是其他技术栈

Django在这个场景下几乎是量身定做的选择。第一，Python本身就是数据挖掘和机器学习的首选语言，pandas、numpy、scikit-learn直接无缝集成到项目里，不需要跨语言调用。第二，Django自带Admin后台，院校数据、考生数据、分数线数据可以直接通过后台管理界面维护，省掉大量手写管理页面的时间。第三，Django的ORM能让数据库表结构设计非常直观，model类定义好以后，迁移命令一键建表，对不熟悉SQL的同学也很友好。

换个角度对比一下，如果用Java+Spring Boot，算法部分得靠Python脚本单独跑完再导数据，工程链路变长，调试麻烦；如果用纯Flask，灵活性强但很多功能需要自己搭，开发效率不如Django高。毕设也好，实际项目也罢，追求的是用最少的成本把事情做完且做好，Django总体上是性价比最优的路线。

2. 数据层设计：喂给系统的“营养”从哪来

一个推荐系统和预测系统，算法只是骨架，数据才是血肉。这个项目能不能做出效果，七成取决于数据质量。很多同学做类似的题目，算法写得很漂亮，一跑数据就露馅，根源就是数据没准备好。所以我把数据层放到最前面讲，这是整个项目的地基。

2.1 数据来源与构成

考研相关数据本身是半公开的，主要来源有几个方向：研招网公布的招生目录（每年更新）、各高校研究生院官网发布的历年复试分数线、各类考研论坛整理的报录比信息，以及电商平台或培训机构公开的历年真题和分数统计。不需要爬得太野，直接用Python写爬虫爬取公开页面即可，重点是要覆盖足够多的年份和院校，时间跨度至少3到5年，否则预测模型没有足够的历史样本可学。

项目的数据大致分为四类：院校基础信息表（学校名称、所在省份、城市、院校层次如985/211/双一流/普通本科、是否为自主划线院校）、专业招生信息表（学校+学院+专业、考试科目、拟招生人数、学硕/专硕类型）、历年分数线表（政治、英语、数学、专业课单科线、总分线、国家线/校线）、考生行为表（匿名化的考生模拟数据：考生本科层次、目标地区偏好、专业方向、预估分数、最终选择的学校）。前三种是有公开来源的真实数据，第四种在真实场景中属于隐私数据，毕设里可以用构造数据代替——例如设计一批模拟考生画像，再结合真实院校数据生成“行为记录”。

构造考生行为数据时要注意合理性。比如“本科985、目标北京地区、计算机专业、预估380分”的考生，最终选择清北或北航的权重应该高一些，而不是随机分配给一个西部普通高校，否则协同过滤学出来的推荐结果会很荒谬。这一步没有技术含量，但直接影响后续算法的表现，值得花时间仔细设计。

2.2 数据清洗与处理

数据爬下来以后直接喂给模型是不现实的，至少要做这几步处理：

格式统一。各网站的专业名称五花八门，“计算机技术”、“计算机科学与技术”、“电子信息”在不同学校可能对应完全不同的考试科目和代码。需要制定一套标准专业映射表，把同义专业名归一到统一ID上，避免推荐系统把同一个专业当成两个专业处理。

缺失值处理。往年分数线偶尔会缺某个单科数据，处理策略一般是按同一学校相邻年份的均值填充，或者直接剔除该条记录。如果缺的是整年数据，那就剔除；如果只是某一个单科，用同校其他年份的同科目平均分填充比直接填0好得多。

异常值过滤。偶尔会有某校某专业分数线出现明显异常波动（比如大小年效应），但这类波动在考研数据里本身携带信息量，不能粗暴当作噪声删除。做法是保留但打标签，让预测模型把“年份”和“地区竞争热度”作为特征自行学习这些波动规律。

数据标准化。预测模型对数值型特征的尺度敏感，尤其是考研分数区间每个科目差异很大——政治满分100、数学满分150、专业课满分150或300，直接拼接输入模型会导致高量纲特征主导权重。分数特征要除以各科目满分做归一化，或使用StandardScaler标准化，才能让模型学到合理的特征权重。

2.3 数据库表结构设计

Django的ORM让表结构设计这件事变得很直观。核心表设计如下：

User表存储考生基础信息（用户名、密码哈希、本科院校层次、专业方向），UserPreference表存考生的筛选偏好（目标省份、目标城市级别、院校层次倾向、可接受的最远距离），School表存院校基础信息（学校名称、省份、城市、类型、是否为985/211/双一流、自主划线标志），Major表存专业信息（学校外键、专业名称、所属学科门类、考试科目），ScoreLine表存历年分数线（学校外键、专业外键、年份、政治分数、英语分数、数学分数、专业课分数、总分、报考人数、录取人数），RecommendResult表存推荐结果缓存，PredictionResult表存预测结果缓存。

用Django的ForeignKey关联学校-专业-分数线三张表时，查询会非常顺手，例如School.objects.filter(city__contains="北京").filter(is_985=True)这种链式查询在后台管理、API接口、算法调用三个层面都能复用同一套ORM逻辑，不需要为算法模块单独写SQL。

数据库选型建议直接用SQLite起步，等数据量到了几十万条再切MySQL。毕设级别的数据量用SQLite完全够用，而且不需要额外配置数据库服务，提交项目时别人拉下来就能跑，避免评审老师因为环境问题打低分。

3. 推荐系统核心逻辑：协同过滤与多因素加权

推荐系统的本质是“猜你喜欢”，但考研选校和商品推荐的逻辑有区别——商品推荐错了无非是换个商品，学校选错了影响的是人生轨迹，所以系统在算法层面要兼顾“个性化”和“稳妥性”。换句话说，既要参考相似考生做了什么样的选择，又不能把赌注全压在协同过滤上面。

3.1 推荐算法的选型思路

当前主流的推荐算法无非三类：基于内容的推荐、协同过滤、混合推荐。在这个项目里，基于内容的推荐可以靠“筛选条件”完成——考生选了省份、专业、院校层次，系统直接按条件从库里筛选，这部分逻辑简单可靠，作为保底方案。协同过滤是让系统具备“预测偏好”能力的关键——找到和自己相似的考生，看他们最终选择了哪些学校，把这些学校加权推荐给当前用户。

两个方案合起来就是混合推荐策略：先用基于内容的筛选缩小候选集（比如用户要北京+计算机，就从几百所学校里挑出符合条件的十几个），再在这个候选集上用协同过滤计算相似度得分，排序输出Top-N推荐列表。

单纯只用协同过滤的问题在于冷启动——新用户没有历史行为，系统无法判断“和谁相似”。筛一遍内容以后，即使协同过滤失效，也至少能按热度给出推荐结果，不会被数据稀疏问题打穿。这就是混合策略的工程意义。

3.2 基于用户的协同过滤实现

基于用户的协同过滤（User CF）的核心假设是：和我选择了相似学校的人，他们的其他选择我也可能喜欢。算法分三步：

构建用户-学校评分矩阵。行是考生，列是学校，值是考生对该校的“偏好程度”。真实场景中可以用“是否申请/报考该校”的0/1值，或者用“该校排名除以考生最终排名”构造一个加权分数。在模拟数据里，我给“考生最终选择的学校”打3分，给“与最终选择同城的学校”打2分，给“同层次的学校”打1分，这样矩阵比纯0/1矩阵携带更多梯度信息，相似度计算更平滑。

计算用户相似度。使用余弦相似度公式：sim(u,v) = (u·v) / (|u| * |v|)。这个公式在稀疏矩阵下的表现比较稳定，计算量可控。向量u和v分别表示两个考生的打分向量，点积越大，夹角越小，说明他们在学校选择上的口味越接近。需要注意：如果两个考生同时打分过的学校交集为空，余弦值直接为0，这时需要靠内容筛选的兜底逻辑补位。

生成推荐结果。对目标用户u，找到最相似的K个用户（K一般取20~50之间），把他们打分过的、但u没打分过的学校，按相似度加权汇总。得分公式为：score(i) = Σ sim(u,v) * rating(v,i)。最后对得分做归一化，加上院校热度权重（比如报考人数、录取比例加权），输出Top-N列表。

协同过滤关键的瓶颈在相似度计算的时间复杂度，用户量一大就是O(n²)，但在毕设数据量（几千考生几百所学校）下这个计算量完全无压力，甚至可以用pandas矩阵运算一次性算完。

3.3 结合考生画像的多因素加权策略

纯协同过滤在考研场景下有一个明显盲区：它只看见“别人选了什么”，看不见“这个选择对用户来说靠不靠谱”。所以最后一步要在协同过滤得分的基础上叠加考生画像匹配度。

画像特征包括以下几个维度：考生本科层次与目标院校层次之间的匹配（985考生报考双非院校加分，双非考生报考985减分，因为考研调剂市场的“逆向选择”风险偏高）、地域偏好（考生是否明确要求省内或特定城市圈）、专业相似度（目标专业与本专业的跨度大小，跨专业报考需要额外加分惩罚）。把这些维度做成特征权重，对协同过滤得分做加权修正，最终的推荐排序才能既有个性化，又有合理性。

这里分享一个参数调优过程中的心得：权重不要全部堆到算法里硬调，而是在后端做成配置项，允许用户在页面上调整“求稳程度”——把滑杆拉向“冲”时，系统提高院校层次权重，推荐偏高目标；拉向“稳”时，提高录取概率权重，推荐保守目标。这个交互设计在实际答辩时非常加分，因为它体现了系统从“算法Demo”到“产品功能”的转化思维。

4. 分数线预测：机器学习模型怎么落地

预测模块是这个项目的另一个半边天。推荐做的是“给你看”，预测做的是“告诉你概率多少”。分数线预测本质上是一个回归问题——给定某学校某专业在往年若干年的分数线、招生人数、报考热度等特征，预测下一年的分数线区间。

4.1 预测目标与特征工程

预测目标的定义需要拆细。院校分数线分为总分线和单科线（政治、英语、数学、专业课），考生最终能不能进复试取决于是否同时满足所有单科线和总分线。一句话总结就是“木桶效应”——单科受限的淘汰率远高于总分不够的比例，所以系统不能只预测总分线，要各科单科线和总分线分别建模预测，最后在前端合并展示。

特征工程是决定模型上限的环节，我整理了一套实际效果不错的特征集：

年份特征：年份本身是输入特征。因为考研热度和分数线存在周期性波动，把年份换算成相对基准年的序号（如2018=0，2019=1……），让模型捕捉时间趋势。

院校层次特征：985/211/双一流/普通四档，用One-Hot编码。因为不同层次的院校分数线走势差异很大——985院校更多是政策敏感型的分数波动，双非院校则更受报考人数驱动。

专业热度特征：用“该专业全国报考人数变化率”或“该专业在该校历年报录比”衡量热度。报录比是核心特征——它直接反映竞争激烈程度，对分数线有显著驱动作用。

单科试题难度特征：每科每年的难度不一样，例如某年数学一全国平均分大幅低于往年，当年的数学单科线自然会被压低。用全国平均分偏离度这一维度解决“大小年”的识别问题。

前一年分数值：上一年的分数线是天然的有效特征，用滞后一期的真实值进入特征集，相当于给了模型一个基准锚点。

4.2 模型选择与训练评估

分数线预测的常用模型有几种：线性回归、随机森林回归、XGBoost、时间序列ARIMA、LSTM。考虑到样本量有限（每个学校每个专业的历史数据往往只有5~10条），深度模型容易过拟合，效率也不划算，实际项目中推荐用随机森林和线性回归做基准模型，再尝试XGBoost。

XGBoost在这个场景的几点优势：能自动处理特征间的非线性交互（例如年份特征与专业热度特征之间对分数线的影响并非独立相加）；对缺失值有内置处理逻辑，代码里不用额外写填充逻辑；可以输出特征重要度，答辩时用来支撑“哪些因素主要影响分数线”的结论非常好讲。

训练和评估时要注意：考研数据本质上是时间序列，不能用普通的随机划分方式去切训练集和测试集，否则会“时空穿越”——用2022年的数据训练，再拿2022年的数据来测试，模型学到的其实是未来信息。正确做法是用时间前向验证：比如用截止到某年的数据训练，预测后续年份，滚动外推评估。评估指标用MAE（平均绝对误差）比较直观——预测分数线与实际分数线平均差几分，分数线的合理容差控制在5分以内。

4.3 预测结果的可视化展示

预测系统跑出来的数据不能只是一堆数字，要在前端给考生直观的决策参考。Django的模板引擎加ECharts就能完成整个可视化方案，不需要额外引入复杂的前端框架。

页面结构大致是：考生输入目标院校、专业和年份，系统返回三个区域——历年分数线折线图（展示真实分数线和预测分数的对比曲线）、预测区间条（例如预计总分线370±8分，并附置信区间说明）、录取风险评估卡片（综合报录比、预测分数线、考生预估分的差距，给出“冲、稳、保”评级）。

评估卡片的具体计算逻辑是：预估分减去预测总分线，差值大于15分给“稳”，5到15分给“较稳”，-5到5分给“冲”，小于负5分给“难”。这个评级不是什么高深算法，就是业务规则的直观落地，但它对用户体验的提升非常明显——考生不用看原始数字费劲分析，系统直接告诉他答案。

5. Django系统实现：从算法到Web的完整闭环

Django部分的价值是把前面所有的算法和数据连接成用户可用的系统。别小看这个环节，有太多算法跑通了但系统做不出来的人，最终答辩时只能放截图和录屏，观感大打折扣。

5.1 项目结构与核心模块

推荐的项目目录结构如下：

kaoyan_system/ ├── manage.py ├── requirements.txt ├── apps/ │ ├── users/ # 用户注册、登录、个人信息 │ ├── schools/ # 院校、专业、分数线数据管理 │ ├── recommend/ # 推荐算法模块 │ ├── predict/ # 预测算法模块 │ └── dashboard/ # 可视化图表与前端页面 ├── static/ # CSS、JS、ECharts库 ├── templates/ # 模板文件 └── data/ # 爬虫脚本和数据集

准确定义各APP的边界很重要，这是Django项目结构好与坏的分界线。users只管用户生命周期，schools管数据，recommend和predict只暴露算法接口给他们调用，dashboard负责渲染和路由。这样划分的好处是每个模块的职责单一，后面要替换算法或者加新功能不会互相牵连。

算法模块不要直接写在视图函数里，而是封装成独立的service类，例如：

# apps/recommend/services.py class RecommenderService: def __init__(self, user_id): self.user_id = user_id def get_similar_users(self, k=30): # 用余弦相似度找TopK相似用户 ... def build_scores(self): # 计算协同过滤得分 + 画像修正 ... def get_recommendations(self, top_n=10): # 输出最终推荐列表 ...

视图层只负责接收HTTP请求、调用service、把结果传给模板。这样写的好处是算法调试可以不经过Web请求，直接在Django shell里调用service类测试，开发效率高很多。

5.2 用户登录与个人偏好收集

推荐系统要个性化，前置条件是系统认识用户是谁。Django自带的认证框架处理注册和登录基本够用，直接用django.contrib.auth。但要在User表上扩展本科院校层次、专业方向等额外字段，方式是用OneToOneField扩展Profile模型，不修改Django自带的User表。

偏好采集是整个产品设计的点睛之笔，形式是注册后的“选校偏好问卷”——目标省份、目标城市类型（省会/一线/普通地级市）、院校层次倾向（985/211/双一流/不限）、专业方向、对跨考的态度（接受/不接受）、求稳倾向（冲一冲/求稳为主）。这些选项全部保存到UserPreference表，推荐算法启动时先读取这些字段做内容筛选，再进入协同过滤流程。

注意偏好问卷页面的交互细节：选项不要超过一屏，不要有需要手动输入的长表单，全部用单选或多选控件完成，降低用户填写成本。否则注册流程太长，用户容易流失。这个细节在答辩时能体现产品思维。

5.3 推荐结果展示与交互

推荐结果页面是这个系统给用户的核心交付，展示策略要精心设计。页面布局分两列：左列是候选院校卡片列表，按推荐分数降序排列，每张卡片包含学校Logo、名称、城市、院校层次标签、最近一年分数线、录取率、推荐理由摘要；右列是当前选中的学校的详细数据面板，包括历年分数走势图、考试科目、专业招生人数、以及和当前用户画像的匹配度进度条。

每个卡片上的“推荐理由摘要”是最提产品完成度的功能。比如系统会给出一条形如“根据与你相似的考生的选择，以及你在地域和求稳程度上的偏好，这所学校匹配度较高。近三年分数线涨幅在5分以内，录取率在中等水平。”这样的自动生成文本。这段文本不需要NLP生成，只需要做好模板字符串拼接，把算法计算的几个关键指标填进去。但就是这一点，让页面看起来从“数据查询工具”升级到了“智能推荐助手”。

5.4 管理员后台与数据管理

Django Admin在毕设中经常被忽略，但其实它是最省时间的管理功能。注册School、Major、ScoreLine这三大核心模型后，后台自动获得增删改查界面。论文里可以专门写一节“系统利用Django自带Admin后台，实现了院校和专业数据的可视化管理，管理员无需编写代码即可维护系统基础数据”，这部分工作量极小但叙述价值很高。

额外的进阶操作是把推荐算法和预测模型的“重新计算”按钮集成到Admin后台的Action里——管理员在后台修改完某条分数线数据后，选中对应院校点一下Action按钮，系统自动重新训练预测模型并更新缓存结果。这个功能让系统的运维链路变成闭环，彻底展示工程完整性，答辩时如果有评委问“数据改了以后推荐结果怎么办”，这一条就能直接回应。

6. 毕设答辩与文档：LW、PPT、讲解视频怎么准备

很多技术能力很强的同学，到最后栽在论文和答辩上，非常可惜。代码写得好是硬实力，把做的事情有效表达出来也是一种硬实力。以下是一些高校毕业设计流程中非常实用的准备经验。

6.1 论文写作重点

论文结构一般走“绪论-相关技术-需求分析-系统设计-系统实现-测试-总结”的老路线，但这不代表内容可以流水账。“相关技术”章不是抄概念，而是要有取舍地解释为什么用这些技术——比如为什么要用余弦相似度而不是皮尔逊相关系数，为什么用XGBoost而不是深度学习，这类比较性内容才是导师真正想看的东西。

“系统设计”章要放核心算法的公式和流程说明。论文里给出协同过滤得分公式，给出特征工程表，说明训练集测试集的时间划分方式——这些会直接支撑“系统实现”章里的效果展示。

工作量证明是另一个评审重点：数据爬虫的字段说明、数据库E-R图、核心类图、关键代码片段、测试用例表，一个都不能少。宁可贴代码截图说明逻辑，也不要只写“使用XX算法实现了XX功能”——后者会被认为是概念拼凑而非系统完成。

6.2 PPT与答辩演示

PPT页数建议控制在12到16页之间，不要贪多。最有效的结构是：背景与痛点1页、系统功能场景1页、技术架构1页、数据库设计1-2页、推荐算法原理2页、预测模型原理2页、系统界面展示4-5页、测试结果1页、总结与展望1页。

答辩演示时要避免一个经典失误：只跑页面，不解释逻辑。演示推荐页面时，要说清楚“这个用户画像是什么”“为什么系统推荐了这三所学校”“加权因子怎么影响排序”三个问题，这样才能把评委的注意力从“页面效果”带向“算法机制”，展示出你对系统的深度理解。

另外一定记得准备一段“如果数据量扩大、并发量提升，系统将如何演进”的回答，比如：当前用SQLite可平滑迁移到MySQL；用户量超过10万时相似度计算可改用离线预计算加缓存；协同过滤冷启动问题可以用热门榜兜底。这些回答不需要真的实现，但能体现架构视野，是拉开档次的关键。

6.3 讲解视频的录制思路

录制讲解视频时，一个常见误区是照本宣科讲功能清单，全程念PPT，看起来很闷。正确的思路是按“用户故事”走：从考生注册、填写偏好问卷开始，输入目标条件，得到推荐列表，点击某校查看预测详情，最后看到冲稳保评级和分数线区间——整个视频就是一次完整的用户走查，全程配旁白解释每一步背后的数据和算法逻辑。

录制时用OBS加系统桌面分辨率，建议视频控制在10到15分钟。剪掉所有停顿和口误的片段。如果现场条件允许，用麦克风录音比笔记本内置麦克风好非常多——讲得再清楚，音质差都会让人觉得不专业。

7. 踩坑实录与避坑建议

项目从零到一跑通的路上，有几个地方几乎是一定会出问题的，提前知道能省下大量排查时间。

7.1 数据量不足的尴尬

第一次跑协同过滤的时候，我造了500个模拟考生、50所学校的数据，效果惨不忍睹——大部分用户的相似用户列表是空的，因为矩阵太稀疏，两两之间共同打分过的学校交集太少了。这是个典型的数据稀疏问题。

解决思路有三条：一是增加数据密度，模拟考生数量至少扩到2000到3000，同时把评分从0/1改成0/1/2/3多级制，增加非零值密度；二是缩小候选集，先做一轮严格的内容筛选，把候选院校压缩到10到20所，再在缩小后的矩阵内计算相似度；三是引入“学校层次/城市/学科类型”的相似度兜底——如果用户和用户的直接相似度为零，就改为看他们在“同层次学校集合”上的偏好分布是否相似，间接计算相似度。

实测下来，最有效的还是第一条加数据量的土办法。算法层面对数据稀疏的容忍度很有限，老老实实扩充模拟数据的数据量，比任何花哨的调参都管用。

7.2 国线与校线的关系处理

第一次做预测模型时，我把国家线和校线当成两个完全独立的序列分别建模，结果某年国家线大幅上涨的年份，校线预测值明显偏低——模型不知道那年国家线是硬约束，导致预测失真。

后来在特征集里加入了“当年国家线”和“该校线与国家线的差值”两个特征，效果立刻好转。这个案例说明了一个很朴素的道理：业务知识比模型技巧更重要。同一个模型，特征里多放一个业务强相关变量，效果比换更复杂的算法好得多。

7.3 Django部署环境不一致的坑

在本地跑得好好的项目，换一台电脑就崩，最常见的原因是Python版本或依赖库版本不一致。解决办法是提交一个requirements.txt，锁定所有依赖版本，例如：

Django==4.2 pandas==2.0.3 numpy==1.24.3 scikit-learn==1.3.0 openpyxl==3.1.2 requests==2.31.0

另外用SQLite数据库时，直接把db.sqlite3文件一起提交，别人拉下来就能跑，不需要初始化数据过程。这一点对答辩前的部署至关重要——千万不要让演示现场变成环境调试现场。

7.4 模板继承与静态文件路径的坑

Django的模板继承机制非常强大，但如果模板之间引用CSS/JS的路径写死为绝对路径，项目迁移到别的环境时静态文件就会打不开。正确的做法是模板开头加{% load static %}，所有资源引用一律用{% static 'css/style.css' %}形式生成路径。这个坑几乎每个人都会踩一次，提前注意能省掉大量线上文件404的时间。

7.5 不确定性表达：预测不能给“唯一答案”

最后是一条设计层面的建议：预测结果永远不要只给一个值，一定要给区间。打分和录取的关系本就充满不确定性，单点预测值会给人一种虚假的确定感。

在我的项目里，预测模块输出的是均值加减标准差区间，例如“预计2024年该专业总分线为368分，波动区间为358-378分，置信度约75%”。同时用不同颜色区分不同风险等级的区间段，让用户在心理上把预测当成参考区间而非绝对答案。

这种“不确定性可视化”的设计，从产品层面保护了用户决策的安全边际，在论文里是一个小而亮的创新点。答辩评委问到“预测不准怎么办”时，这个设计本身就是最好的回应。

做这个项目前后折腾了快两个月，最大的感受是：考研选校推荐这个选题的价值不在算法难度，而在它对真实问题的回应能力。推荐算法的成熟方案已经太多了，但这个系统被需要，是因为每年都有上百万人站在选择的岔路口，缺少一个能帮他们梳理信息的工具。作为毕设，它技术覆盖面足够广、逻辑闭环完整、业务故事清晰，是性价比非常高的一次完整工程实践。如果你正在做类似的项目，数据和业务逻辑的打通比算法调优更值得投入时间——数据合理，业务自洽，系统整体自然立得住。