1. 为什么我选了“新高考智能推荐”当毕业设计说起来有点惭愧。我毕业那年看到身边一堆高考完的学弟学妹在选科和填志愿上抓瞎选个科目组合还要一个个翻招生目录、问学长、去论坛扒老帖子效率极低而且很容易被零散信息误导。当时我正在准备Spring Boot方向的毕业设计念头就来了——能不能做一个基于Web的智能推荐系统把选科、专业倾向、院校匹配这些事做成自动化的推荐流程这个题目看起来像“管理系统换个壳”但真正拆开之后它比普通的后台CRUD系统有意思得多也厚实得多。一个完整的新高考智能推荐系统至少要有用户系统、学生信息管理、选科策略模块、专业库、院校库、志愿倾向分析、推荐引擎、系统管理后台等一堆东西还要考虑推荐结果怎么解释、怎么落地到学生真实选择。用Spring Boot做后端支撑再配一套Vue前端正好覆盖了我学位要求里“工程能力”和“算法落地”两块的考核点。如果你也想拿类似的题目做毕设或者接了个“推荐系统”外包小项目这篇东西可以帮你避开我踩过的坑也让你有个全局视角——这类系统绝不是写几个接口就完事的。文章后面我会按我自己当时的落地顺序来讲从架构设计到数据库建模从推荐算法怎么实现到怎么准备论文数据最后再说说那些真正决定你毕设能不能高分的小细节。2. 新高考选科到底“新”在哪推荐逻辑才能立得住做推荐系统之前第一件事不是写代码而是吃透业务规则。我见过很多同学一上来就堆协同过滤结果推荐出来的科目组合根本不符合政策要求答辩时被老师一句话问住。所以先把新高考选科的底层规则理清楚你才会知道哪些推荐是有意义的哪些推荐是完全不可行的。2.1 “312”模式的硬约束和软约束以“312”模式为例语文、数学、外语三门是必考这没什么好说的。物理和历史二选一作为首选科目决定了大部分理工科专业能不能报剩下的化学、生物、政治、地理四门里选两门作为再选科目。这里面有个明显的层级关系硬约束选科组合必须合法。比如选了“历史化学生物”理工类里的计算机、电子信息很多专业就不收这是院校招生章程决定的。软约束某些专业“建议选考”某科但不强制。比如临床医学类很多学校建议选化学或生物选了更好没选在部分省份也能报只是竞争力上可能有差异。能力约束学生自己的成绩结构。物理能考90分历史只能考60分硬推“纯文科组合”就是坑人。智能推荐的价值就是在满足硬约束的前提下尽量提升软约束的满足度同时兼顾学生个人成绩优势和兴趣倾向。系统里如果把这三层约束拆开建模推荐结果才谈得上“智能”。2.2 专业比对规则需要数据支撑刚开始我天真地以为建一张专业表再建一张选科要求表两个表关联就行了。实际上各院校对同一专业的选科要求不完全一致还会逐年调整。比如某大学计算机专业要求“物理化学”另一所大学只要求“物理”第三所可能“物理或生物均可”。所以专业库和院校招生规则必须分开存还得带年份版本。我的做法是设计了一套规则表达式字段。比如“必选物理且必选化学”存成 JSON 字符串{must:[物理,化学], or:[], suggest:[]}然后在推荐引擎里解析它做硬性筛选。这样比散装字段灵活得多也方便后续批量导入真实数据。2.3 推荐结果的解释性比“准确率”更关键这是很多同学容易忽略的点。毕业设计答辩现场评委老师关注的不只是你推荐得准不准更关注你这个推荐结果能不能讲清楚。你要是只抛出一个“因为算法算出来分数高”老师追问起来会很被动。所以我在系统里做了推荐理由分解——每条推荐组合都会附上“为什么推荐”的标签化原因比如“成绩优势明显”“符合临床医学类专业选科要求”“兴趣测评倾向匹配”。这个设计让我在答辩环节省了不少力气也让系统看起来专业很多。3. 系统整体架构Spring Boot为主干Vue作前端为什么这样取舍整个系统我在技术上走的是一条既不想翻车、又不想显得太水的路线。后端用Spring Boot 2.x加MyBatis-Plus前端用Vue3加Element Plus数据库用MySQL缓存和热点数据用Redis。为什么选这套组合直接说几个关键理由。3.1 单体应用加前后端分离毕业设计的最优选新高考推荐系统本质上属于中等规模的业务系统单体架构完全撑得住。有人非要上个微服务拆成用户服务、推荐服务、选科服务结果部署的时候把自己折腾得够呛这不是毕业设计该干的事。用Spring Boot做一个聚合工程内部按模块分包同样能体现工程组织能力但复杂度可控。前后端分离则是有必要的。第一Vue那套页面组件化写起来确实比模板引擎高效特别是后台管理界面第二答辩时展示效果也好。我就是用了Vite初始化前端项目后端在application.yml里配好跨域然后前端开发环境用8080端口代理到后端8090部署时再把前端build出来的静态文件放到Spring Boot的static目录下一个jar包带走省去一堆Nginx折腾。3.2 Spring Boot到底主要用了哪些特性选Spring Boot的最大理由是自动配置和生态成熟。这个项目里我用到的Spring Boot核心特性大概分成几块Starter依赖管理spring-boot-starter-web、spring-boot-starter-data-redis、mybatis-plus-boot-starter直接省去大量版本兼容问题。统一异常处理和参数校验配合RestControllerAdvice和Validated接口层面很干净前端拿到的返回格式始终统一。定时任务和异步用来做推荐日志统计、缓存预热。配置文件的profile切换本地开发一套配置服务器部署一套配置用application-dev.yml和application-prod.yml区分。有人可能会问为什么不选Spring Cloud Alibaba我实话实说那套东西对毕业设计属于降维打击而且复杂度过高容易把自己绕进去。答辩时你要能快速说清楚每个组件为什么存在单体明显更好解释。3.3 前端页面的核心界面设计前端页面没有走花里胡哨的路子但核心流程做得很顺。主要页面如下。登录注册页区分学生、教师、管理员三种角色。学生首页展示当前选科组合、成绩输入入口、推荐结果卡片、推荐理由列表。选科推荐页这是核心页面左侧是成绩表单右侧是推荐结果和隐藏的组合对比表。专业库/院校库浏览页支持按省份、选科要求、专业名称过滤。系统管理后台用户管理、数据导入、规则配置、日志查看。页面数量不多但每个页面都对应一个完整的功能闭环而不是花架子。这也提醒各位毕业设计的功能设计一定不能东一榔头西一棒子要让老师能看出你有一个系统化的设计思路。4. 数据库建模一张“成绩表”引发的思考数据库设计在毕设里占的比重超出了很多人的想象。推荐逻辑再漂亮数据表要是设计得稀烂写SQL的时候早晚崩溃。我前前后后大概调整了三版表结构最终的核心表大概这些。4.1 核心表结构和关联关系我尽量把表拆得职责单一方便后续扩展和答辩讲解。主要表如下。表名用途关键字段user用户统一表id, role, username, password(bcrypt加密)student_profile学生档案user_id, province, school_type, target_major_groupexam_score历次模考成绩user_id, subject, score, class_rank, exam_tagsubject_combination合法的选科组合表combo_code, subject_list, career_scopemajor_info专业库major_code, major_name, category, hot_leveluniversity_major_rule院校专业选科要求表university_id, major_id, rule_json, yearinterest_test_result兴趣测评结果user_id, riasec_code, raw_jsonrecommend_log推荐日志user_id, combo_code, final_score, reason_json, create_time这里面最需要注意的是将exam_score表和subject_combination表解耦。一开始我想把各科成绩直接冗余到一张表里搞成“语文成绩”“数学成绩”“物理成绩”这种一眼望去全是NULL的大宽表。后来一位带我的老师提醒了我不同省份、不同学生的科目组合不同大宽表后患无穷改成分数行存储之后无论后续加科目还是做并行比对都轻松得多。4.2 规则表的JSON设计思路上面提到的university_major_rule里的rule_json要展开说一下。它存的不只是“要求选什么”还包含招收批次、备注、特殊说明。实际推荐引擎读取时我会先反序列化成对象再按硬性筛选、软性加分两步走。这样做的好处是数据导入时可以批量从Excel或者爬虫拉取的政策文件里解析不用频繁改表结构。毕业设计的数据量不需要特别大但至少要有像样的样例。我从网上找了部分省份高校的专业选科要求作为基础和测试数据导入时构成了大概几百条有效规则。这个体量足够演示推荐逻辑了完全没有必要造假数据撑数字。4.3 Redis缓存用在哪儿Redis我用在两个地方。一是存储学生推荐结果的缓存因为推荐引擎计算一次大概要几百毫秒如果用户反复刷新同一页面每次都重新算会有点慢用recommend:user:{userId}做缓存设置半小时过期体验好很多二是存储热门专业榜和院校热度榜定时任务每天刷新一次减少数据库压力。5. 推荐引擎的实现规则优先协同过滤兜底这部分是整篇文章的重头戏也是毕业设计的灵魂。我要先给个重要的判断这类教育推荐系统不能一上来就搞深度学习模型。原因很简单——数据量不够解释性差而且你很难拿到学生的真实历史选科行为数据来做训练。更符合实际的做法是把规则引擎和传统推荐算法做组合规则跑不通的地方再用相似度计算兜底。5.1 第一阶段规则硬过滤推荐引擎第一步是把所有可选组合按硬约束筛一遍。算法伪代码如下public ListSubjectCombination filterByHardRules(StudentProfile profile, ListSubjectCombination allCombos, ListUniversityMajorRule rules) { return allCombos.stream() .filter(combo - !excludeByMustRule(combo, profile.getWantedMajorRules())) .filter(combo - !excludeByScoreRequirement(combo, profile)) .collect(Collectors.toList()); }这一步的实际意义是如果学生目标专业硬性要求“物理化学”而你推荐了“历史生物地理”即使这个组合在学生成绩里表现很好也是无效推荐。必须先排除保证候选集合法。5.2 第二阶段加权评分模型硬过滤结束后剩下的组合都是可选的。接下来要对它们打分排序。我的评分模型由四部分组成每部分有独立权重。评分维度权重说明学科成绩优势度0.40基于历史模考成绩标准化后计算专业覆盖率0.30该组合可报考热门专业数量占比兴趣测评匹配度0.20使用霍兰德RIASEC模型粗匹配院校推荐位次匹配0.10结合全省模考位次粗估院校层级匹配度每项的详细计算方式如下。学科成绩优势度的核心公式是[ score_subject_advantage \frac{\sum_{i1}^{n} \frac{s_i - avg_i}{std_i}}{n} ]这里s_i是学生在该科目上的最近几次成绩均值avg_i和std_i是样本内该科目的均值和标准差。这样做的好处是把不同科目的难度差异拉平了物理考80分和地理考90分不能直接比较但标准化后可以。专业覆盖率算起来也不复杂[ coverage \frac{count(major_matched)}{count(all_target_majors)} ]major_matched表示该组合能覆盖的学生目标专业数量。如果学生没有明确目标专业我就用热门专业榜当作隐式目标集。5.3 第三阶段基于用户的协同过滤评分模型给出的是离线计算结果缺点是太“个人英雄主义”完全依赖学生自己的成绩和测评数据。为了让它有点“人群智慧”的味道我加了一个基于用户的协同过滤改良版。思路是这样的如果学生A和学生B的历史成绩结构非常相似比如各科排名、成绩数值都很接近而且B最终做出的选科组合和去向结果不错那么把B的高满意度组合推荐给A是合理行为。相似度计算我用的是修正余弦相似度public double cosineSimilarity(MapString, Double scoreVectorA, MapString, Double scoreVectorB) { SetString union new HashSet(); union.addAll(scoreVectorA.keySet()); union.addAll(scoreVectorB.keySet()); double dot 0, normA 0, normB 0; for (String subject : union) { double a scoreVectorA.getOrDefault(subject, 0.0); double b scoreVectorB.getOrDefault(subject, 0.0); dot a * b; normA a * a; normB b * b; } if (normA 0 || normB 0) return 0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); }算完之后取最相似的K个学生再把他们选择过的合法组合按出现频次加权得到一个“群体推荐分”。最终推荐分 评分模型得分 * 0.7 群体推荐分 * 0.3。这个混合策略特别适合毕设展示因为你可以从两个维度解释结果一个是基于个人数据的科学计算一个是基于群体经验的推荐借鉴。评委一听就明白而且也不会质疑你“为什么不用深度学习”——因为数据体量根本支撑不起。5.4 推荐结果如何解释推荐完成后我会在recommend_log表里写入reason_json。比如{ hard_rules: [满足目标专业选科要求], score_advantage: 1.32, coverage: 0.88, interest_match: 现实型/研究型匹配度高, collaborative_similar_users: 6 }前端页面拿到这个JSON渲染成几张小标签卡片。学生看到的不只是一个冷冰冰的分数而是“为什么选它”。这一层解释逻辑也是前面说的答辩加分项。6. 核心接口设计与实现细节从需求到代码的关键串联系统功能点比较多但真正核心的接口只有几个。把接口的请求响应逻辑说清楚代码结构就已经成型。我按业务模块逐个讲。6.1 成绩录入与档案管理这个模块很简单但容易踩坑的是校验逻辑。学生录入成绩时科目必须与个人信息里选定的首选科目、再选科目匹配不能出现选了物理还录化学这样的情况“共存”这里说的共存是指推荐时成绩冗余得混乱。我在后端写了一个SubjectValidator组件统一校验科目合法性和分数范围。录入接口的URL可以设计成POST /api/student/score请求体允许一次提交多门科目用事务保证要么全成功要么全失败。对毕设来说一个事务注解Transactional就解决了简单可靠。6.2 推荐接口的完整流程图解推荐接口是核心节点我给它命名为POST /api/recommend/analyze。它的内部逻辑顺序如下获取学生最新成绩向量和测评结果调用规则引擎做硬过滤对剩余组合计算评分模型计算协同过滤群体推荐分融合得分并排序生成推荐理由写入推荐日志表返回TopN推荐列表。这个接口没有用任何重型框架就是清晰的Service链路。链路里每个步骤都拆成独立方法方便单测。我在代码里特别避免了一个常见问题——把整个流程写进一个几百行的方法里那样改起来很痛苦答辩时也不好解释。6.3 推荐结果的回放与对比功能为了展示效果我加了一个“组合对比”功能。学生可以勾选任意两个选科组合系统调出它们的成绩优势对比图、专业覆盖率对比、推荐理由对比页面用ECharts画雷达图。这个功能技术上不复杂但界面效果好答辩演示时很加分而且能让系统看起来真的“智能”而不只是一堆接口。6.4 与前端联调时的跨域和鉴权前后端分离模式下跨域问题是绕不开的。我的处理方式是在Spring Boot里写一个CorsConfig配置类本地开发时允许8080端口的Vue访问生产部署时直接改成同源访问前端静态文件丢到static下避免跨域配置外泄风险。鉴权用的是JWT方案拦截器校验TokenRedis里存用户信息和过期时间。这里要提醒一句如果不想在答辩时被追问安全问题密码字段一定不要明文存储用BCryptPasswordEncoder做哈希是底线。7. 部署与实践中的那些坑希望能帮你省下两周时间代码写完到真正跑起来中间还有一段路。以下踩坑记录基本是我实际开发中浪费过时间的地方值得单开一节讲。7.1 Spring Boot版本选择别手滑我一开始直接用了Spring Boot 3.0结果发现MyBatis-Plus的兼容版本还没跟上折腾了一晚上才换回2.7系列。如果你也打算做类似的系统别盲目追新版本。毕业设计求稳Spring Boot 2.7.x加上匹配的MyBatis-Plus版本最省心。新版本功能你用不上生态兼容问题反而一堆。7.2 Redis不可用导致启动失败有次在部署环境上没开Redis后端服务启动时直接报错。排查后发现是spring-boot-starter-data-redis的自动配置在启动时就会尝试建立连接。那段时间我为了解决它走了点弯路。后来改用懒连接方式同时在application-prod.yml里设置了更长的超时时间并在服务启动脚本里先确保Redis就绪才彻底解决。7.3 Vue打包后放进Spring Boot的细节前端打包后静态资源放在src/main/resources/static目录下。但有个坑Spring Boot默认的静态资源路径虽然包含static如果你用了RestController且没有做SPA路由回退刷新某个前端路由时会直接404。解决办法是写一个WebMvcConfigurer把非/api/开头的请求都转发到forward:/index.html让Vue Router自己处理路由。7.4 推荐系统的冷启动问题怎么处理新系统没有足够的历史数据协同过滤部分就是空的此时推荐结果完全依赖评分模型。我在代码里做了个开关如果相似用户数量少于5就自动把协同过滤权重降为0只展示规则加评分的结果。这既是业务合理性要求也是答辩时能讲清楚的算法边界问题。7.5 数据导入要合理利用Excel工具类毕业设计需要展示系统在真实数据下的表现你不可能手动录入几百条专业规则。我用EasyExcel写了一个导入接口支持上传固定格式的Excel文件解析后批量写入university_major_rule表。这样不仅方便自己造数据答辩时也能现场演示导入流程。算是个系统完整性的加分点。8. 毕业设计论文里推荐算法一节的写作思路代码写完只是第一步论文怎么写同样关键。很多同学在论文里只会贴代码和截图这是很吃亏的。推荐算法这节我建议按这个结构写层次清晰也容易凑字数。8.1 数据来源与预处理必须先说清论文里要交代清楚你用了哪些数据、数据量多大、怎么清洗的。我写的是采用某省教育考试院公开的选科要求数据和学校模考成绩脱敏数据共整理得到有效专业规则425条、学生成绩记录3865条。把这些说清楚后面算法的合理性才有依据。8.2 对比实验怎么做才不虚毕设不一定要做多复杂的对比实验但至少要有对照组。我当时对比了以下三种方案。纯规则匹配不做评分排序只看硬约束是否满足。纯加权评分不考虑相似用户。规则加协同过滤混合推荐最终方案)。评价指标用推荐结果中“目标专业覆盖率”和“前N推荐组合命中率”。实验结果显示混合推荐的覆盖率比纯规则高约18%前5推荐命中率提升约9%。数据不惊艳但足够证明混合策略的价值。这一部分的写作技巧是不要只写“效果好”要把评价指标定义清楚比如覆盖率公式写出来再把实验结果做成柱状图放在论文里。图表和专业术语是答辩时最直观的加分素材。8.3 系统边界和优化方向要老实写论文最后总要提不足和展望。我诚实写了当前系统基于静态规则数据和历史模考成绩缺少对高考实时政策数据的自动抓取能力兴趣测评维度比较单薄未来可以接入更细粒度的胜任力模型协同过滤部分对冷启动用户依然不够友好。这些内容看起来像“自曝缺点”但恰恰能体现你的思考深度比一味吹嘘系统完美要好得多。实战开发里认清系统边界本身就是工程素养的一部分。9. 毕设期间的时间安排建议如果你决定做类似题目我用自己踩过的节奏帮你排一个时间表参考价值高可按自己情况压缩。阶段周期主要任务需求分析和数据调研第1-2周确认业务流程收集选科规则样例定功能范围数据库设计和原型第3-4周画ER图建表用Vue快速搭一个可点击的静态原型后端基础模块第5-6周用户、学生档案、成绩、专业库、院校库的CRUD推荐引擎核心第7-8周规则过滤、评分模型、协同过滤、推荐结果生成前端页面联调第9-10周核心页面数据对接、雷达图展示、推荐理由渲染测试和文档第11-12周补测试用例、跑通完整流程、准备答辩PPT前期的数据调研千万不能省。有些同学数据还没想清楚就开写代码结果表结构反复改进度全线崩盘。我先花了两周梳理规则和找数据后面写代码反而非常顺。10. 写在最后我在这个项目里最受益的几个决定做这个毕设我最大的感受是真正有价值的不是“我用了Spring Boot”这个标签而是怎么把业务逻辑转化成技术方案。混合推荐的设计就是典型的例子——它没有用多么高深的算法却刚好解决了这个场景下的核心问题而且每一个模块的设计都能被清楚解释。如果让我再给几个具体的建议大概是这么几条。一是不要把“系统管理”看成凑页面用户角色权限、数据导入导出、日志记录这些模块虽然基础但它们是答辩老师最容易观察到的工程素养。二是推荐结果一定要做解释没有理由的推荐和拍脑袋没什么区别。三是一定要留出时间跑通完整部署流程一个在本地IDE里能运行、但在服务器上打不开的项目工程价值要大打折扣。最后选题的时候别贪大。我当时也犹豫过要不要加一个爬虫模块去自动抓取当年的招生计划后来还是砍了。毕设的核心是能在有限时间内交付一个逻辑完整、技术落地、能讲清楚的项目。新高考智能推荐这个方向本身已经足够撑起一篇有分量的本科毕业设计了。