基于 LightGBM 的山东高考智能择校推荐系统设计与实现

说明：本文按通用本科毕业论文模板假设撰写，用于预答辩初稿。学校名称、院系名称、指导教师、最终题目、格式细则、图表编号样式、参考文献条数等内容需按所在学校模板进一步调整。

中文摘要

本章目标

给出论文研究对象、研究问题、实现方法与主要成果概述，为后续章节建立统一研究语境。

本章正文

随着山东省新高考改革的持续推进，考生志愿填报过程由传统的院校优先、批次优先逐步转变为更加重视位次、选科约束、招生计划与历年投档数据综合匹配的复杂决策问题。在此背景下，仅依赖人工经验或静态分数线进行择校推荐，已难以满足考生个性化、多因素、可解释的填报需求。为解决上述问题，本文设计并实现了一套基于 LightGBM 的山东高考智能择校推荐系统。

系统以 Flask 为后端开发框架，结合 Flask-Login、Flask-SQLAlchemy、Bootstrap、ECharts、pandas、scikit-learn 与 LightGBM 等技术，构建了集数据同步、历史趋势可视化、智能推荐、志愿清单管理、教师班级指导和管理员模型运维于一体的 Web 平台。系统面向考生、教师和管理员三类角色提供服务。其中，考生端支持资料完善、推荐生成、推荐结果查看与志愿清单保存；教师端支持班级创建、学生 Excel 导入导出、班级分析与学生指导；管理员端支持官方数据同步、模型训练、任务日志查看及健康检查。

在推荐方法上，系统以山东新高考场景为约束，使用 $2022\text{-}2025$ 年改革后真实历史数据构建训练样本，并以目标年份、近三年最低位次、最低分、招生计划数、选科要求数量及年度变化趋势等特征为输入，分别预测目标专业在下一年度的预测门槛位次与预测门槛分数。随后，结合考生当前分数、位次、选科条件与计划信息，构建匹配度评分模型，并按“冲、稳、保”三类桶进行院校筛选，形成总规模为 $96$ 的平行志愿推荐结构。该方法兼顾了工程可实现性、结果可解释性与实际业务场景可用性。

本文围绕系统的需求分析、总体设计、关键实现和测试方案展开论述。研究结果表明，该系统在架构设计、业务闭环、角色协同与推荐逻辑方面具备较好的完整性，能够为山东高考志愿填报提供一个面向真实业务场景的智能辅助方案。由于当前阶段仍处于毕业设计实现与预答辩准备阶段，部分性能指标和大规模在线测试数据尚待补充，但系统已经具备完整的功能原型、可运行代码基础和后续优化空间。

关键词： 新高考；志愿填报；LightGBM；Flask；推荐系统；数据可视化

本章小结

本摘要概括了论文研究背景、系统目标、技术路线、推荐方法和阶段性成果，为后续章节展开详细论述提供了总览。

待确认项

• 论文最终题目是否需要按学校模板调整为“设计与实现”或“研究与实现”口径。
• 摘要字数、关键词数量是否需要严格控制在学校模板规定范围内。

目录

1. 绪论
2. 相关技术与理论基础
3. 需求分析
4. 系统设计
5. 系统实现
6. 系统测试
7. 总结与展望
8. 参考文献
9. 自检说明

第1章 绪论

1.1 本章目标

阐明课题的研究背景、研究意义、国内外相关研究发展情况、本文的研究内容及论文结构安排，明确本项目的研究定位。

1.2 研究背景与意义

高考志愿填报既是教育资源分配的重要环节，也是考生升学决策中最关键的步骤之一。山东省实行“$3+3$”新高考模式后，考生选科组合差异、院校专业选科要求、年度招生计划波动以及历年投档位次变化共同影响志愿填报效果。与传统以固定分数线为主的判断方式相比，新高考场景下的填报问题具有更强的数据依赖性、动态性和个体差异性。

从现实应用角度看，考生和家长往往存在以下痛点：一是对历年数据缺乏统一整理，难以同时关注分数、位次、专业和选科要求；二是人工比对信息成本高，难以在有限时间内完成多院校、多专业的综合评估；三是志愿结构搭配缺少量化依据，容易出现“冲刺过多”或“保底不足”等风险。从学校和教师视角看，面对班级学生批量志愿指导任务，仅靠线下经验难以及时掌握学生志愿结构与风险分布。

因此，设计一套面向山东新高考场景、能够融合历史数据、选科要求、计划信息和机器学习预测能力的智能择校推荐系统，具有较强的理论意义与实践价值。理论上，该系统将推荐算法、教育数据处理和 Web 工程实现相结合，为新高考志愿辅助领域提供可复核的工程案例；实践上，该系统能够提升考生志愿填报效率，增强教师指导的针对性，并为后续教育数据平台建设提供可扩展原型。

1.3 国内外研究现状

当前围绕教育推荐与升学决策支持的研究主要集中在以下几个方向。

第一，基于规则和统计分析的志愿推荐方法较早得到应用。此类方法通常以历年录取分数线、位次区间和院校层次为基础，通过经验规则完成候选院校筛选。其优点是逻辑直观、实现简单，但在面对多特征耦合问题时，往往难以准确表达考生个体差异。

第二，数据挖掘与机器学习方法被逐步引入教育决策系统。部分研究使用决策树、随机森林、梯度提升树等方法预测录取概率或推荐候选结果。与纯规则方法相比，机器学习方法更适合处理非线性关系和高维特征问题，能够在保留一定可解释性的同时提升预测灵活性。

第三，Web 化与平台化成为教育信息系统的重要发展趋势。现代推荐系统不再局限于算法模型本身，而是更强调数据采集、业务流程、角色协同、结果展示与后续运维的整体闭环。换言之，真正可用于教学管理或升学指导的系统，必须同时解决数据获取、模型训练、推荐落地与角色协同管理等问题。

综合来看，现有研究已为本课题提供了较好的理论基础，但仍存在两方面不足：其一，针对山东新高考场景的选科约束、计划波动与志愿结构化输出的系统化实现案例相对有限；其二，部分研究只关注模型效果而忽略业务协同与系统工程实现。基于此，本文从完整平台落地角度出发，将数据同步、趋势可视化、LightGBM 推荐、三端协同与志愿清单管理集成到统一系统中。

1.4 研究内容

本文的主要研究内容包括以下几个方面。

1. 对山东新高考志愿填报业务进行分析，明确考生、教师、管理员三类角色的核心需求。
2. 构建基于 Flask 的三端协同 Web 系统，实现数据可视化、推荐生成、志愿清单管理和教师指导功能。
3. 基于 $2022\text{-}2025$ 年历史数据构造推荐训练样本，使用 LightGBM 回归模型预测目标年度专业门槛位次与门槛分数。
4. 设计融合位次差、分数差、计划数与选科要求的匹配度计算方法，并生成“冲、稳、保”三级志愿结果。
5. 对系统的数据库结构、模块分层、功能流程与测试方案进行总结，形成可用于预答辩阶段的完整论文初稿。

1.5 论文结构安排

全文共分为七章。第一章介绍研究背景、意义和研究内容；第二章阐述系统使用的相关技术和理论基础；第三章对系统需求进行分析；第四章给出系统总体架构、数据库和模块设计；第五章说明关键功能实现；第六章设计系统测试方案并给出测试表；第七章对全文进行总结并提出后续改进方向。

1.6 本章小结

本章从新高考志愿填报场景出发，分析了本课题的研究背景和现实意义，归纳了相关研究的发展脉络，并明确了本文的主要研究内容与结构安排。

1.7 待确认项

• 是否需要根据学校要求增加“研究方法”或“创新点”小节。
• 国内外研究现状部分是否需要补充更多近五年中文文献综述。

第2章 相关技术与理论基础

2.1 本章目标

介绍本系统实现所依赖的关键技术与理论，包括 Web 框架、数据可视化、ORM、数据处理、机器学习模型以及推荐评分方法，为系统设计与实现提供理论支撑。

2.2 Flask 框架

Flask 是一种轻量级 Python Web 框架，具备结构清晰、组件灵活、便于快速原型实现等特点。本文系统采用应用工厂模式组织项目结构，在 create_app() 中完成配置加载、扩展初始化、蓝图注册、目录创建、数据库建表和演示数据注入。该模式有利于将鉴权、配置、路由和服务逻辑分层组织，提高代码可维护性。

2.3 Flask-Login 与 SQLAlchemy

系统使用 Flask-Login 实现登录态管理与角色权限控制。通过统一用户实体与角色字段，系统能够根据当前登录用户跳转到考生端、教师端或管理员端，并对无权限访问请求进行统一处理。

数据库访问层采用 Flask-SQLAlchemy 和 SQLAlchemy 实现。ORM 映射技术将业务实体抽象为 Python 类，使用户、学生、教师、院校、专业、推荐任务、志愿清单等对象关系能够以结构化方式组织。与直接编写大量 SQL 相比，ORM 能够提高实体管理一致性，降低复杂业务的维护成本。

2.4 Bootstrap 与 ECharts

前端展示层采用 Bootstrap 完成页面布局、表单、卡片和模态框的响应式呈现，使系统能够在常见桌面浏览器环境中保持较好的界面一致性。ECharts 用于展示历史分数线趋势、推荐结构和班级统计信息。数据可视化的引入，使原本抽象的招生数据、推荐结果和风险分布具有更直观的表达方式。

2.5 pandas 与数据处理

系统使用 pandas 处理 Excel 导入、结构化表格转换和训练数据准备等任务。在教师端，Excel 文件用于班级学生信息的批量导入导出；在训练阶段，历史招生数据被转换为监督学习样本，为模型训练提供结构化输入。

2.6 LightGBM 理论基础

LightGBM 是基于梯度提升决策树的高效机器学习框架，适合处理中等规模结构化表格数据。与传统线性模型相比，LightGBM 更擅长建模复杂非线性关系；与更重的深度学习方案相比，其在结构化特征场景下具有较好的训练效率和可用性，符合本课题毕业设计阶段对工程落地和可解释性的综合要求。

系统中分别训练两个回归器，用于预测目标专业在下一年度的最低录取位次与最低录取分数。若运行环境中没有安装 LightGBM，则系统可退化为基于梯度提升回归器的兼容方案，但正式设计口径仍以 LightGBM 为核心。

2.7 特征构造与匹配度理论

2.7.1 特征向量定义

系统从近三年历史记录中提取核心特征，构造输入向量 $x$：

$$x=[target\_year,history\_count,prev1\_min\_rank,prev1\_min\_score,prev2\_min\_rank,prev2\_min\_score,prev3\_min\_rank,prev3\_min\_score,prev1\_plan\_count,prev2\_plan\_count,required\_count,rank\_trend\_1y,score\_trend\_1y{]}^{\mathrm{T}}$$

其中，近一年位次变化量与分数变化量定义为：

$$rank\_trend\_1y=prev1\_min\_rank-prev2\_min\_rank$$

$$score\_trend\_1y=prev1\_min\_score-prev2\_min\_score$$

2.7.2 预测模型

系统分别建立位次预测模型和分数预测模型：

$$\hat{r}=f_{\mathrm{rank}}(x)$$

$$\hat{s}=f_{\mathrm{score}}(x)$$

其中，$\hat{r}$ 表示预测门槛位次，$\hat{s}$ 表示预测门槛分数，$f_{\mathrm{rank}}$ 与 $f_{\mathrm{score}}$ 均由 LightGBM 回归模型学习得到。

2.7.3 差值与匹配度计算

设考生当前位次为 $r_u$，当前分数为 $s_u$，则位次差与分数差定义为：

$$\Delta r=\hat{r}-r_u$$

$$\Delta s=s_u-\hat{s}$$

为保持不同量纲下评分的平滑性，系统使用双曲正切函数构造位次与分数分量：

$$C_r=50+50\cdot \tanh \left(\frac{\Delta r}{18000}\right)$$

$$C_s=50+50\cdot \tanh \left(\frac{\Delta s}{15}\right)$$

若招生计划数为 $p$，选科要求数量为 $q$，则计划分量和选科分量分别为：

$$C_p=\{\begin{array}{ll}55,& p\text{ 未知}\\ 45+\frac{\min (p,120)}{120}\times 55,& p\text{ 已知}\end{array}$$

$$C_q=\max (72,100-6q)$$

最终匹配度写为：

$$M=\mathrm{clamp}\left(0.52C_r+0.28C_s+0.12C_p+0.08C_q,0,100\right)$$

其中，$\mathrm{clamp}(\cdot )$ 表示将结果限制在 $[0,100]$ 区间内。该设计与系统代码实现保持一致，体现了对位次因素的最高权重关注。

2.8 本章小结

本章介绍了系统所依赖的 Flask、SQLAlchemy、Bootstrap、ECharts、pandas 和 LightGBM 等关键技术，并结合代码实现归纳了特征构造、门槛预测与匹配度评分公式，为后续需求分析与系统设计奠定了理论基础。

2.9 待确认项

• 学校是否要求增加“开发工具”小节，如 PyCharm、Postman、MySQL Workbench 等。
• 第二章是否需要补充更多关于梯度提升树和回归评价指标的理论推导。

第3章 需求分析

3.1 本章目标

从业务角色和系统边界出发，分析系统需要解决的问题、功能需求、非功能需求以及核心业务流程。

3.2 可行性分析

从技术可行性看，Flask 与 SQLAlchemy 足以支撑中小型信息系统开发，LightGBM 能较好适配结构化招生数据场景，pandas 能支持 Excel 与表格数据处理，整体技术方案具有较高实现可行性。

从经济可行性看，本系统主要依赖开源技术栈，部署门槛较低，默认 SQLite 即可运行，适合毕业设计、课程展示与中小规模原型演示。

从操作可行性看，系统以 Web 页面为主要交互界面，考生、教师和管理员均可通过浏览器完成主要操作，学习成本较低。

3.3 角色需求分析

3.3.1 考生端需求

考生端需要完成个人分数、位次、选科组合及偏好信息维护，并基于历史数据和模型结果生成志愿推荐。系统应支持查看推荐结果、理解“冲稳保”结构并将推荐结果保存为志愿清单。

3.3.2 教师端需求

教师端需要管理班级与学生数据，支持 Excel 批量导入和导出，查看班级整体志愿结构，针对学生最新志愿清单进行指导，并记录风险标记与指导状态。

3.3.3 管理员端需求

管理员端需要维护数据底座和模型版本，能够触发官方数据同步、启动模型训练、查看同步日志和健康检查结果，以保证系统持续可用。

3.4 功能需求分析

系统主要功能需求可归纳如下：

1. 用户注册登录与角色访问控制。
2. 历史数据可视化展示。
3. 考生资料维护与推荐生成。
4. 志愿清单保存与管理。
5. 教师班级管理、学生导入导出与指导分析。
6. 管理员数据同步、模型训练与任务日志查看。

3.5 非功能需求分析

3.5.1 可用性需求

系统应具备较清晰的页面导航与角色分流逻辑，使不同角色在登录后能够快速进入对应工作台。

3.5.2 可维护性需求

系统需要采用模块化分层设计，将蓝图、服务层、数据模型和静态资源分离，便于后续扩展。

3.5.3 安全性需求

系统应提供基本的登录鉴权、角色权限控制和会话管理能力，避免未授权访问不同角色页面。

3.5.4 可扩展性需求

系统应支持 SQLite 与 MySQL 双数据库模式切换，并允许后续扩展更多同步任务、模型版本和推荐规则。

3.6 核心业务流程分析

3.6.1 推荐业务流程

3.6.2 教师指导流程

3.7 本章小结

本章从角色、功能和非功能三个维度分析了系统需求，并给出了推荐与教师指导两个核心业务流程。需求分析结果表明，本系统不仅要实现推荐算法，还必须覆盖数据展示、角色协同与管理运维功能。

3.8 待确认项

• 是否需要在本章增加“用例图”或“数据流图”。
• 是否需要在功能需求中单列“政策资讯”模块说明。

第4章 系统设计

4.1 本章目标

从总体架构、模块分层、数据库设计和关键接口关系等方面说明系统设计方案。

4.2 总体架构设计

系统采用单体 Web 架构，前后端模板在同一仓库中管理，逻辑上可分为表示层、业务层、数据层与模型层。

4.3 模块划分设计

系统主要由以下模块构成：

1. auth 模块：负责注册、登录、退出登录及访问控制。
2. main 模块：负责首页、角色工作台入口和历史可视化页面。
3. student 模块：负责考生资料维护、推荐生成、推荐结果与志愿清单。
4. teacher 模块：负责班级创建、学生导入导出、班级分析与学生指导。
5. admin 模块：负责数据同步、模型训练、任务日志和健康检查。
6. services 模块：负责推荐算法、模型训练、同步任务与图表数据计算。

4.4 数据库设计

4.4.1 概念结构设计

系统围绕用户、学生、教师、院校、专业、推荐任务和志愿清单构建数据模型，各实体关系如图所示。

4.4.2 逻辑结构说明

1. user_account 统一管理登录账号、手机号、角色、状态等基础信息。
2. student_profile 存储考生年份、分数、位次、选科组合、偏好和毕业学校等数据。
3. teacher_profile 与 class_group 共同管理教师和班级关系。
4. institution、major、admission_plan、subject_requirement、admission_score_line 共同构成招生数据底座。
5. model_version、recommendation_task、recommendation_item 支撑模型版本与推荐结果管理。
6. volunteer_plan、volunteer_plan_item 和 guidance_record 支撑志愿清单与教师指导记录。

4.5 推荐设计

推荐设计分为四个阶段：

1. 候选筛选：根据考生分数、位次、选科条件在历史数据中筛选候选院校专业。
2. 特征构造：从近三年记录中提取最低分、最低位次、计划数与趋势特征。
3. 门槛预测：调用 LightGBM 预测目标年份门槛分数与位次。
4. 结果分桶：按挑战性、平衡性和保底性进行排序，生成“冲、稳、保”三类院校集合。

4.6 部署设计

系统默认采用单进程 Flask 启动方式，适合本地演示与课程交付；数据库默认使用 SQLite，部署简单；若面向多人访问或长期运行，可通过环境变量切换为 MySQL。系统运行过程中会自动创建 instance、downloads 与 models 目录，用于保存数据库文件、原始下载文件和模型文件。

4.7 本章小结

本章完成了系统总体架构、模块划分、数据库关系与推荐流程设计说明，明确了系统从数据底座到角色页面再到模型服务的整体结构。

4.8 待确认项

• 学校模板是否要求补充表结构字段说明表。
• 是否需要增加“接口设计”小节，对管理员 API 和推荐接口进行单独说明。

第5章 系统实现

5.1 本章目标

结合项目代码说明系统的关键实现路径，突出应用初始化、角色控制、推荐生成、教师指导与管理员运维等核心内容。

5.2 应用初始化实现

系统入口文件 run.py 通过 create_app() 创建应用实例。应用工厂在启动时完成配置加载、数据库扩展初始化、登录管理初始化、蓝图注册、运行目录创建以及数据库建表和演示数据灌入。该设计使系统在首次运行时即可完成基础可用环境准备，降低了演示和交付成本。

5.3 登录鉴权与角色分流实现

系统通过 Flask-Login 管理登录用户，并在不同蓝图页面上结合角色装饰器实现权限控制。未登录用户访问受限页面时将被重定向到登录页；已登录但角色不匹配时，系统会根据当前身份跳转到对应工作台，从而保证考生、教师和管理员三端的访问边界清晰。

5.4 考生端实现

考生端主要包括资料维护、推荐生成、结果查看和志愿清单保存四部分。

1. 资料维护：考生可提交分数、位次、选科组合、偏好地区与专业类别等信息。
2. 推荐生成：系统校验考生核心信息是否完整，然后调用推荐服务生成结果。
3. 结果查看：系统对推荐任务进行序列化，输出匹配度、风险级别、历史趋势摘要与提示说明。
4. 志愿清单保存：系统可从推荐结果中抽取代表性项，形成志愿清单并保存到数据库。

5.5 推荐服务实现

推荐服务是系统实现的核心。其主要过程如下：

1. 基于考生成绩和位次构建候选窗口。
2. 对候选院校专业进行选科约束校验。
3. 提取近三年趋势数据并构造特征快照。
4. 使用已激活模型预测下一年度门槛位次和门槛分数。
5. 计算匹配度并进行院校去重。
6. 生成“冲、稳、保”三类结果集合，每类默认输出 $32$ 所院校。

如果系统中尚未存在可用模型，推荐服务会先触发模型训练，再执行推荐任务。这种设计保证了系统首次运行后的功能闭环。

5.6 教师端实现

教师端实现围绕班级管理与指导流程展开：

1. 教师可创建班级并维护年级信息。
2. 系统支持通过 Excel 导入学生信息，同时可导出已管理学生数据。
3. 班级分析页统计冲稳保结构分布与指导状态。
4. 学生指导页展示学生最新志愿清单、风险标记与指导意见输入区域。
5. 指导记录会回写数据库，形成可追踪的指导留痕。

5.7 管理员端实现

管理员端负责系统底座维护。其实现重点包括：

1. 手动触发官方数据同步任务。
2. 训练或激活模型版本。
3. 查看同步任务日志与模型版本信息。
4. 通过 /admin/health 接口执行健康检查。

管理员端为系统的数据可持续更新与模型迭代提供了工程支撑，使系统不再只是一次性静态展示，而具备一定的运维能力。

5.8 历史可视化实现

系统通过可视化服务聚合改革前和改革后的历史数据，在首页与历史可视化页面中展示平均分、平均位次和院校趋势信息。通过 ECharts，用户能够直观观察不同年份的变化趋势，从而为志愿决策和模型训练口径提供背景支持。

5.9 本章小结

本章结合项目代码，对系统初始化、角色访问控制、考生端推荐、教师端指导、管理员端同步训练以及可视化展示等关键实现内容进行了说明，展现了系统从数据到页面、从模型到业务闭环的工程落地过程。

5.10 待确认项

• 是否需要在正式论文中增加关键代码截图或函数级说明。
• 是否需要补充训练脚本、同步脚本的运行截图作为实现佐证。

第6章 系统测试

6.1 本章目标

给出系统测试环境、测试策略、测试用例和待补充指标，为预答辩阶段的质量说明提供依据。

6.2 测试环境

本文测试环境按当前仓库运行条件给出如下描述：

• 操作系统：Windows / macOS / Linux 均可部署
• 后端语言：Python
• Web 框架：Flask
• 数据库：SQLite（默认）或 MySQL（可选）
• 浏览器：Chrome、Edge 等现代浏览器

说明：由于当前阶段重点在系统原型与业务闭环实现，压力测试和长时运行测试数据尚未系统整理，后续需结合学校模板补充完整测试截图和统计结果。

6.3 测试策略

1. 功能测试：验证登录、推荐生成、班级导入、模型训练等关键功能是否可正常运行。
2. 集成测试：验证推荐服务、数据库和前端页面之间的数据交互是否完整。
3. 兼容性测试：验证系统在不同桌面浏览器及不同操作系统上的可运行性。
4. 安全性测试：验证角色隔离、未授权访问拦截和会话控制逻辑。

6.4 测试用例设计

以下表格为预答辩初稿阶段的测试用例设计，实际执行结果、截图与性能数据需在终稿前补充。

用例编号	模块	测试项	前置条件	测试步骤	预期结果	实际结果	状态
TC-001	登录模块	正常登录	演示账号已存在	输入管理员账号密码登录	成功进入管理员控制台	待补充	待确认
TC-002	考生端	推荐生成	已填写分数、位次和选科	提交推荐生成请求	生成推荐任务并展示结果页	待补充	待确认
TC-003	考生端	志愿清单保存	已有推荐结果	在结果页保存志愿清单	系统生成并保存志愿清单	待补充	待确认
TC-004	教师端	学生导入	教师账号已登录	上传 Excel 文件并绑定班级	成功导入学生数据	待补充	待确认
TC-005	教师端	指导记录提交	班级内学生已有志愿清单	填写指导意见并提交	成功保存指导记录	待补充	待确认
TC-006	管理员端	数据同步	管理员账号已登录	手动执行同步任务	生成同步日志并反馈状态	待补充	待确认
TC-007	管理员端	模型训练	历史数据已准备	触发模型训练	产生模型版本记录	待补充	待确认
TC-008	运维接口	健康检查	服务已启动	访问 /admin/health	返回状态正常 JSON	待补充	待确认

6.5 测试结果分析

从系统结构和代码逻辑看，当前实现已经具备完整的功能测试入口与关键流程闭环，适合在预答辩阶段展示原型完整性。需要说明的是，系统测试章节中尚缺少以下正式材料：

1. 页面运行截图和操作链路截图。
2. 压力测试响应时间与吞吐量指标。
3. 不同浏览器兼容性对照表。
4. 部分异常场景下的错误提示截图。

因此，当前测试章节更适合作为“测试设计与待补充执行结果”的初稿版本。在正式答辩前，应补齐至少一轮基于真实运行环境的执行记录。

6.6 本章小结

本章从测试环境、测试策略和测试用例三个方面给出了系统质量验证方案，明确了预答辩阶段已具备的测试基础和仍需补充的实证材料。

6.7 待确认项

• 学校模板是否要求加入性能测试表和截图编号。
• 是否需要在终稿中加入缺陷修复记录表。

第7章 总结与展望

7.1 本章目标

总结本文已完成的研究与实现工作，分析系统不足，并提出后续优化方向。

7.2 全文总结

本文围绕山东新高考志愿填报场景，设计并实现了一套基于 LightGBM 的智能择校推荐系统。系统以 Flask 为核心开发框架，集成了历史数据可视化、推荐生成、志愿清单保存、教师指导、数据同步和模型训练等关键功能，形成了面向考生、教师和管理员三类角色的完整业务闭环。

在方法层面，本文结合 $2022\text{-}2025$ 年历史数据构造推荐特征，使用 LightGBM 回归模型预测目标专业在下一年度的门槛分数与门槛位次，并依据位次差、分数差、招生计划和选科要求构建匹配度评分，最终生成“冲、稳、保”三级志愿推荐结果。该设计兼顾了可实现性、解释性和业务可操作性。

在工程层面，系统采用模块化分层组织，支持 SQLite 与 MySQL 双数据库模式，可用于本地演示、毕业设计展示和后续扩展。整体实现证明，基于真实招生数据和机器学习模型构建志愿辅助系统具有较强的应用潜力。

7.3 不足分析

尽管系统已具备完整原型，但仍存在以下不足：

1. 测试章节中的性能数据、兼容性截图和实测指标尚未完全补齐。
2. 推荐模型当前主要依赖结构化历史数据，尚未融合更丰富的外部特征。
3. 当前系统主要适配山东场景，跨省份推广仍需重构数据源和规则体系。
4. 推荐结果的可解释性虽然已有提示文本，但仍可进一步增强。

7.4 展望

后续工作可从以下方向继续推进：

1. 扩展更多年份和更多批次的结构化招生数据，提高模型训练样本规模。
2. 引入特征重要性展示、规则解释与个性化原因分析，增强结果透明度。
3. 增加志愿清单导出、通知提醒和多轮志愿模拟功能，提升业务完整性。
4. 在正式部署中接入更稳定的生产级 WSGI 服务和反向代理，提高系统可靠性。
5. 结合学校模板补齐实验截图、图表编号、参考文献和附录材料，形成终稿。

7.5 本章小结

本章总结了本文在系统设计、推荐方法和工程实现方面的工作成果，并指出了当前系统在测试数据、功能深度和推广范围方面的不足，同时提出了后续优化方向。

7.6 待确认项

• 是否需要在总结部分增加“创新点”或“个人工作总结”。
• 是否需要在展望部分结合导师意见补充更多与教育场景相关的延伸内容。

参考文献

说明：以下参考文献为初稿版，正式提交前需按学校模板统一著录格式，并补充近五年中文文献与网络资源。

[1] Ke G, Meng Q, Finley T, et al. LightGBM: A Highly Efficient Gradient Boosting Decision Tree[J]. Advances in Neural Information Processing Systems, 2017, 30: 3146-3154.

[2] Friedman J H. Greedy Function Approximation: A Gradient Boosting Machine[J]. The Annals of Statistics, 2001, 29(5): 1189-1232.

[3] Pedregosa F, Varoquaux G, Gramfort A, et al. Scikit-learn: Machine Learning in Python[J]. Journal of Machine Learning Research, 2011, 12: 2825-2830.

[4] McKinney W. Data Structures for Statistical Computing in Python[C]. Proceedings of the 9th Python in Science Conference, 2010: 56-61.

[5] Grinberg M. Flask Web Development[M]. Sebastopol: O’Reilly Media, 2018.

[6] Bayer M. SQLAlchemy Documentation[EB/OL]. https://docs.sqlalchemy.org/ .

[7] Pallets. Flask Documentation[EB/OL]. https://flask.palletsprojects.com/ .

[8] Apache ECharts Team. Apache ECharts Documentation[EB/OL]. https://echarts.apache.org/ .

[9] 山东省教育招生考试院. 山东省普通高校招生相关公开信息[EB/OL]. 待补充.

[10] 教育部. 普通高等学校招生考试相关政策文件[EB/OL]. 待补充.

[11] 王某某. 新高考背景下高校志愿填报辅助决策研究[J]. 待补充.

[12] 李某某. 面向教育数据分析的推荐系统设计与实现[D]. 待补充.

[13] 张某某. 基于机器学习的高考志愿推荐模型研究[J]. 待补充.

[14] 陈某某. Web 信息系统设计与实现[M]. 待补充.

[15] 刘某某. 数据可视化技术在教育信息系统中的应用[J]. 待补充.

自检说明

本章目标

对当前初稿进行结构、公式、事实一致性和后续补充项的自查，便于预答辩前进一步完善。

本章正文

1. 结构完整性：本文已包含摘要、目录、绪论、相关技术、需求分析、系统设计、系统实现、系统测试、总结与展望、参考文献和自检说明。
2. 事实一致性：正文尽量以当前仓库代码和 README 为依据，涉及训练窗口、角色功能、数据范围和部署方式的描述均按代码现状表述。
3. 公式规范性：全文公式统一采用 $...$ 与 $$...$$ 形式，未使用 \(...\) 记法。
4. 风险提示：测试结果、学校模板细节、正式文献条数、截图编号、性能指标等内容尚待补充，不宜在终稿前直接作为已完成结论提交。
5. 后续完善建议：补充系统运行截图、测试截图、班级分析图表截图、数据同步日志截图，并将参考文献扩展到学校要求数量。

本章小结

当前文稿已达到预答辩阶段可展示的论文初稿要求，具备完整章节结构和与代码一致的技术描述，但正式提交前仍需补齐学校模板细则与实测材料。

待确认项

• 参考文献是否需要统一转为学校指定格式。
• 是否需要增加英文摘要、致谢和附录。