Python+AI大模型旅游路线推荐系统毕设实战：从协同过滤到智能规划

每年四五月份，总有一批学弟学妹拿着一模一样的题目来问我：Python + AI大模型 + 旅游路线推荐系统，这个毕业设计到底该怎么做？说实话，这个题在计算机毕业设计里属于典型的“技术栈全覆盖”型选题，既有 Python 数据分析，又有关联规则和推荐算法，还能蹭上大模型的热点，再加上路线规划里的路径规划算法，工作量有了，亮点也有了，答辩时也很容易讲出东西。但反过来，正因为技术点太多，很多同学做出来的东西往往四不像——推荐模块和路线规划模块完全是割裂的，大模型又只是套壳调用，根本没有形成“个性化推荐 → 智能规划 → 内容生成”的完整闭环。这篇文章我就用我的实战经验，完整拆解这个毕设系统该怎么做，从数据清洗到推荐算法再到大模型融合，每一步都给你讲透。

先给这个项目定个位：这不是一个纯算法研究题，也不是一个纯网页开发题，而是一个以数据为中心的智能应用系统。核心价值在于把“用户想看什么、适合玩什么”变成“实际可执行的一日/多日旅游路线”，并且用自然语言把路线推荐理由讲清楚。它适合计算机科学与技术、软件工程、大数据、人工智能方向的学生，也适合想入门推荐系统和大模型应用开发的从业者照着练手。

1. 项目定位与系统架构拆解

1.1 从“推荐景点”到“推荐路线”的问题跃迁

很多同学对这个题目的理解停留在“给用户推荐几个旅游景点”的层面，如果仅仅做到这样，这个项目就失去了灵魂。真实场景里，游客打开旅游App最终要的不是一个景点列表，而是“我明天到了这个城市，应该怎么安排一整天，上午去哪儿、中午在哪儿吃饭、下午去哪儿，晚上住哪个区域方便”。所以这个系统的核心问题其实是两个：

• 推荐问题：从海量POI（兴趣点）里，为用户筛选出符合他偏好的候选景点集合。
• 规划问题：在候选集合之上，考虑地理位置、游玩时长、开放时间、交通耗时、用餐休息等约束，生成可行且体验良好的游览路线。

这两个问题必须连成一个整体。以前见过有同学把推荐做成了独立模块，路线规划也做成了独立模块，最后只是硬凑到同一个界面上，用户选了推荐景点后，路线规划完全不考虑推荐结果，这个在答辩时属于致命伤。正确做法是推荐引擎的输出直接作为规划器的输入，规划器的目标函数里又要体现用户偏好分数，形成“召回 → 排序 → 规划 → 生成”的流水线。

1.2 技术选型背后的真实考量

技术栈我建议用一套非常“毕业设计友好”的组合，不要盲目追求微服务或者深度学习大模型。

先说为什么推荐算法不直接上一个 DeepFM、DIN 之类的深度模型。毕业设计的核心是逻辑自洽、可解释、可复现。传统的协同过滤和基于内容的推荐，你可以把相似度矩阵打印出来给评委看，可以把每一个推荐理由追溯到用户行为，但深度推荐模型在高稀疏数据下往往不如传统方法稳定，而且调参和训练会占用大量时间。当然，如果你本身对深度学习很熟，做一个浅层模型作对比实验是很好的加分项，但不要依赖它撑起整个系统的主链路。

再看大模型的使用方式。这里要特别强调：大模型在这个系统里是“增强层”，不是“计算核心”。推荐计算和路线规划必须由可解释的传统算法完成，大模型负责的是理解用户的模糊表达、把推荐结果用自然语言串成一篇让人信服的推荐理由，以及将“我想轻松一点，别太赶”这种口语化需求解析成结构化约束参数。这样做的好处是，即使大模型API偶尔不可用或者返回错误，推荐和规划主流程依然能跑通，系统鲁棒性高，答辩时也是一个能讲清楚的“降级兜底”设计。

1.3 整体架构与数据流向设计

这个系统的整体架构可以分成五层：

1. 数据接入层：初始导入景点POI数据、模拟用户行为数据；运行时接收用户注册、浏览、收藏、搜索等交互数据。
2. 特征构建层：对原始数据进行清洗、去重、缺失填充，构建用户画像和景点画像，生成“用户-景点”行为矩阵。
3. 推荐引擎层：多路召回（协同过滤、内容相似、热门榜单、地域过滤），然后加权融合排序，输出Top-N候选集合。
4. 路线规划层：以候选景点集合为基础，读取地理位置、开放时间、建议游玩时长等约束，调用规划算法生成路线序列。
5. 智能交互层：调用大模型API，解析用户输入的口语化偏好，生成路线推荐理由，支持多轮问答式交互。

数据流动的方向是从底层往上层单向传递，每一层都输出结构清晰的数据对象。比如推荐引擎输出的是带分数的景点列表，路线规划层接收这个列表后回传“规划后的行程序列”，智能交互层再把这个序列加上每个景点的关键信息和推荐理由，拼接成对话式文案。这个流向设计我建议在论文和答辩PPT里画一张清晰的分层图，因为这是评委理解你系统逻辑最快的方式。

2. 数据处理与特征工程实战

2.1 数据获取与预处理方案

很多同学以为数据处理这部分没什么好写的，实际上恰恰相反，旅游数据脏乱差的程度在所有领域里都算得上数一数二。首先是数据源问题，我不建议去爬取真实平台的数据，原因一是版权和合规风险，原因二是真实数据往往包含大量敏感的用户信息。更好的办法是半合成数据策略：

• 景点POI数据：使用开放数据集或公开API的基础POI信息（名称、类别、经度纬度、评分、点评数、参考游玩时长、开放时间），可以以某旅游城市为样例，也可以自建几十个虚拟景点。
• 用户数据：设计一个人口统计学规则生成器，模拟不同年龄段、同行人类型、旅行偏好组合，生成500-1000个虚拟用户。
• 行为数据：基于用户偏好和景点属性，按泊松分布生成浏览、收藏、搜索行为，保证行为分布有“长尾效应”，更接近真实情况。

数据清洗这一步有几个非常典型的坑。第一个是经纬度异常：我见过某条数据经度写成 104.06 但纬度写成 3042.5，明显是纬度恰好拼接错了，这种数据出现在训练集里会直接污染距离计算。处理办法是设置经纬度范围的合法区间过滤，超出中国范围内的一律剔除或重新纠正。第二个是开放时间格式混乱：有的景点写“08:00-17:30”，有的写“8：00-17：30”，有的写“全天开放”甚至写“周一至周五 09:00-16:00 周末延长至18点”，这些都要解析成结构化的“一周七天每天开放时段”字段。第三个是游玩时长缺失：真实POI数据里建议游玩时长经常为空，一个简单的处理办法是根据景点类别填充，比如博物馆类默认2小时，自然风光类默认3小时，主题乐园类默认4小时以上。

注意：千万不要把“智能路线规划”做成“完全不考虑开放时间的伪规划”。如果路线里某景点周一闭馆，系统却推荐用户周一去，这在演示时是极其尴尬的场景，评委很可能突然问一句“你算过这个景点今天开不开门吗？”

2.2 用户画像与景点画像构建

画像特征是后续所有算法的地基，这一步做扎实了，后面会非常顺。

用户画像建议包含这几个维度：出行类型偏好（自然风光、历史文化、主题乐园、美食购物、城市休闲）、同行人类型（独自、情侣、亲子、朋友、老人）、预算等级（经济型、舒适型、豪华型）、日均游玩节奏偏好（紧凑型、标准型、轻松型）。这些维度一部分来自用户注册时填写的资料，另一部分来自行为数据推导。

景点画像建议包含这几个维度：基础属性（类别、所在城市/区域、经纬度、门票价格）、口碑属性（评分、点评数、热度指数）、时间属性（建议游玩时长、开放时段、适合游玩的最优季节）、体验属性（是否适合亲子、是否适合长辈、体力消耗等级、拥挤程度）。体验属性比较难直接获得，我建议设计一个简单的规则评分表，比如有“儿童设施”关键词就提高亲子适合度。

这块内容在论文里可以画一张表，把每个特征的数据类型、取值范围、来源方式列清楚，这也是“数据分析”这个关键词在题目里的体现。评委看到你做了特征探索分析并形成了结构化画像，就会认可你的数据工程能力。另外注意，做特征分析时不要只画饼状图和柱状图，至少画一张景点分类占比图、一张评分分布直方图、一张评论数的高度热力散点图，这些可视化材料有助于撑起“数据分析”在论文中的篇幅。

2.3 数据存储结构与行为矩阵设计

数据库表不要设计得太复杂，但要完整。我建议至少包含以下核心表：

• 用户表：用户ID、昵称、年龄区间、同行人类型等注册信息。
• 景点表：景点ID、名称、类别、经度、纬度、评分、评论数、门票价格、建议游玩时长、开放时间JSON字段。
• 用户行为表：用户ID、景点ID、行为类型（浏览/收藏/搜索/分享）、行为时间戳、行为对应的会话ID。
• 用户画像表：预计算的用户偏好标签，用逗号分隔或者JSON存储。
• 推荐结果表：用于记录某次推荐请求输出的景点列表和相关分数。

在内存计算时，需要把行为表转化为“用户-景点评分矩阵”，这个矩阵不一定要变成稠密矩阵，用三元组形式存储效率更高。行为行为转评分的加权策略很重要，我实测下来比较通用的权重是：搜索加1分、浏览加1.5分、收藏加3分、分享加4分，同时按行为时间做衰减，越近的行为权重越高。衰减系数可以用指数衰减：

$$ w(t) = \exp(-\lambda \cdot \Delta t) $$

其中 $\Delta t$ 是行为发生时间距今的天数，$\lambda$ 可以取 0.05 左右，这样一个月前的浏览行为权重会降到原来的0.22左右，既保留历史兴趣又突出近期变化。

3. 个性化推荐系统的核心实现

3.1 协同过滤召回：UserCF与ItemCF的组合策略

推荐系统的召回层，我建议同时实现基于用户的协同过滤和基于物品的协同过滤，不要二选一，因为两者的适用场景不同。UserCF更适合发现“同类型人群的新景点”，适合做探索性推荐；ItemCF更擅长“看过A的人还会看B”，适合做相似景点的挖掘。

基于用户的协同过滤实现思路很清晰：对目标用户，计算他与所有其他用户的余弦相似度，取TopK相似用户，将相似用户有正向行为的景点按相似度加权聚合，过滤掉用户已经去过或浏览过的景点后，得到候选集合。

# 用户余弦相似度计算示意 user_item_matrix = build_matrix(user_actions) # 稀疏矩阵 def user_similarity(u1, u2): s1 = user_item_matrix[u1] s2 = user_item_matrix[u2] common = s1.multiply(s2) numerator = common.sum() denom = sqrt(pow(s1, 2).sum() * pow(s2, 2).sum()) return numerator / (denom + 1e-9)

基于物品的协同过滤则反过来。先建立物品相似度矩阵，然后根据用户的历史正向行为，找到与这些历史物品最相似的候选物品。这里有一个细节：物品相似度矩阵如果直接暴力计算，在景点数量几千条时还好，但如果达到几万条建议用“行为共现物品对”的近似方法计算，否则 O(n²) 的内存和耗时直接跑崩。

3.2 基于内容的推荐：让冷门景点有机会被看见

协同过滤有一个先天缺陷：如果某个景点只有个位数用户访问过，它很难被推荐出去。但旅游场景里很多优质小众景点恰恰是数据稀疏的，这时候基于内容的推荐就能补上这个短板。实现方式就是：把景点画像中的类别、标签、简介文本转化为向量，计算与用户偏好向量的相似度。

文本向量化这里有一个选择：可以用 TF-IDF，也可以用预训练的 Sentence Transformer 或小型 Embedding 模型。对于毕业设计，TF-IDF 最大的优点是可解释、稳定、无需外部依赖；Embedding 的优点是语义理解更强，比如“看海”和“海边度假”能匹配上。我建议两个都实现，最终在加权层融合。为了体现大模型的参与感，也可以用大模型接口批量把景点简介编码成向量，但这会增加接口调用成本，需要控制批量大小和缓存策略。

3.3 排序融合：别小看权重调参

多路召回后，每一路都会给出候选景点及其相似度或分数。排序层的任务是把这些分数统一量纲后加权求和。我实际用的公式是：

$$ score = w_1 \cdot norm(usercf_score) + w_2 \cdot norm(itemcf_score) + w_3 \cdot norm(content_score) + w_4 \cdot norm(popularity) $$

其中norm()是归一化函数，通常使用最小-最大归一化或者Z-score。popularity是热度分，可以用评论数取对数再归一化，相当于给系统加一个“大家都认这个景点”的兜底信号。

权重设定在初始阶段可以简单用w1=0.35, w2=0.25, w3=0.25, w4=0.15，然后在验证集上调整。我建议至少做一次简单的网格搜索或者手动对比，把权重变化对推荐结果的覆盖率、命中率的影响记录进论文。这里给个提醒：权重参数不是拍脑袋决定的，你要能解释为什么上调某一路的权重。比如冷启动阶段用户行为少，协同过滤不可信，就应降低 w1、w2，提高 w3 和 w4。

3.4 AI大模型在推荐里的真实角色与接法

关于大模型和推荐系统的关系，我看到太多人在这个点上走了弯路。明确一点：不要让大模型直接输出推荐结果。原因很简单：大模型内部没有真实的POI数据库，它记忆中的景点可能与你的数据集中景点不一致，而且深度模型的推荐结果无法追溯、无法计算评估指标。正确做法是把大模型定位成自然语言处理和生成工具。

第一个角色是用户偏好意图解析。传统偏好获取方式是让用户填一堆复选框，交互太生硬。用大模型做一个对话式引导：用户说“我想带爸妈去，预算不高，喜欢看自然风景，不要太累”，大模型返回一个JSON格式的结构化偏好：

// 大模型返回的结构化偏好示例 { "travel_type": ["natural_scenery", "city_leisure"], "companion": "elderly", "budget_level": "economic", "pace": "relaxed", "avoid_crowded": true }

程序解析这个JSON后，直接映射到用户画像特征向量，从而参与推荐计算。这一步做得好，你的系统就实现了“自然语言交互 + 结构化计算”的双引擎架构，在答辩里非常出彩。

第二个角色是推荐理由生成。推荐结果和规划路线是结构化数据，但直接展示一堆景点卡片显得很干瘪。我们可以把路线结果、每个景点的评分、特点、开放时间等结构化信息拼装成Prompt，让大模型生成一段自然语言描述。这里必须做检索增强式约束，把所有事实数据放进Prompt，并且明确要求模型“只能基于以下数据描述，不能编造门票价格、距离或营业时间”。这样既保证了真实感，又避免了大模型幻觉这个最容易被评委挑战的问题。

4. 智能路线规划算法的设计与实现

4.1 把路线规划问题形式化

路线规划模块是这个题目里算法含量最高、也最容易拉开差距的部分。先把问题用数学语言描述：给定候选景点集合 $P = {p_1, p_2, ..., p_n}$，每个景点有游玩时长 $d_i$、开放时间窗 $[open_i, close_i]$、经纬度坐标、推荐分数 $s_i$，目标是在总游玩时间约束 $T$ 内，寻找一个访问序列，使得总推荐分数最大化，同时满足每个景点的开放时间窗约束以及景点之间的交通时间 $t_{ij}$。

这本质上是带时间窗的旅行商问题变体（TSPTW），众所周知这是一个NP难问题。在毕业设计里把这个问题的数学模型写清楚，本身就是一段很扎实的论文章节。别担心它难，正因为难，你才可以用启发式算法来做，并且有理有据。

4.2 从贪心基线到遗传算法的对比实现

我强烈建议按“贪心算法 → 状态压缩DP → 遗传算法”三步走来做，每一步都在论文里留下对比数据。

贪心算法是基底：每一步从未访问景点中，选择一个“单位时间分数最大”的景点加入路线，即最大化 $\frac{s_i}{d_i + t_{ij}}$，同时检查时间窗约束。贪心很快，但容易陷入局部最优，不适合作为最终方案。

状态压缩DP适合景点数不超过10的小规模场景。用集合S表示已访问的景点，dp[S][i] 表示当前处于景点i的路线最大分数，转移方程为：

$$ dp[S][i] = \max_{j \notin S}\left(dp[S \setminus {i}] [j] + w_{ji} \right) $$

其中 $w_{ji}$ 表示从 j 到 i 带来的分数增量（包括游玩分数减去交通成本）。DP的好处是能够找到精确最优解，作为评价启发式算法效果的“理论最优参考值”。

遗传算法是重点展示的模块，因为它的流程长、参数多、可讲的空间大。编码方式采用“景点编号排列”的整数编码，种群初始化时生成若干乱序排列。适应度函数要综合考虑推荐分数、交通时间成本和时间窗惩罚：

$$ fitness = \sum_i s_i - \alpha \sum_{i,j} t_{ij} \cdot [当前为相邻] - \beta \cdot (迟到总时长) $$

其中 $\alpha$ 是交通时间惩罚系数，$\beta$ 是时间窗违例惩罚系数。交叉操作可以用部分映射交叉（PMX），变异操作用随机交换两个位置或者反转一段子路径。

实际实现中我发现一个容易被忽略的细节：初始种群不能完全随机生成，否则最终收敛质量很差。建议用贪心算法生成几条高质量路径放入初始种群，剩下的再用随机排列填充，让群体在启动阶段就带着“好基因”。经过实验，纯随机初始种群平均比经过贪心注入的种群晚30代左右收敛，最终适应度也偏低。

4.3 约束细节：时间、距离和用餐时段的工程化处理

理论上讲算法很漂亮，但工程实现时各种约束会让代码变得复杂。这里分享几个我用过的处理技巧：

距离计算用 Haversine 公式，直接用经纬度算球面距离，返回单位是公里。然后用一个函数estimate_travel_time(distance, mode)估算交通时间，默认按自驾/打车速度 30km/h 估算，如果两个景点在同一个区域且距离小于2公里，可以给一个“步行替代”的选项，默认按步行速度 4km/h，再加上导航实际可能绕路的系数。你不需要接入任何地图API来做基础计算，这样可以在答辩时说明“交通时间采用经验模型预估”，更注重算法层面的实现。

时间窗约束要做成软硬结合。硬约束是景点在闭园后绝对不能安排，软约束则是如果到达时间略晚于最佳入园时间，会产生惩罚但不会直接淘汰路径。这个设计很贴合真实场景，因为在开放时间段内的任何时间入园都是允许的，但太晚可能影响体验，用软约束就是这种语义化的体现。

还有一个细节是午餐和休息时段。一条一日游路线如果安排得满满当当，没有自然的午餐休息时间，用户会觉得根本不实用。建议在规划时做一种“午餐锚点”处理：在 11:30-13:30 之间，检查当前所在位置附近是否有合适的餐饮POI或者适合休息的广场/公园，如果有，就在路线中插入一个休息节点。这样生成的路线从上午武侯祠→中午锦里吃饭→下午宽窄巷子→傍晚人民公园，这类真实感非常足，也就是评委口中“可用性强”的体现。

注意：路线规划时不要贪婪地塞满所有高分景点。宁可选3个体验舒适的景点，也不要排7个赶路赶得喘不上气的景点。因此我建议总游玩时长约束要留有25%-30%的缓冲时间，用“有效游玩时间占比”作为体验评估指标之一。

5. 系统开发与联调全流程

5.1 后端模块化设计与API细节

后端我采用 FastAPI 搭建，推荐引擎、规划引擎、大模型模块全部独立成服务，通过接口互相调用。这样做的好处是答辩阶段可以针对任意模块单独给评委演示，而不是把所有代码糊在一个文件里说不清楚。

核心API设计如下：

这里有一个工程上的关键点：推荐和规划要串行调用，但API设计上要允许分步返回前端展示。前端先调用/api/recommend展示推荐景点卡片，用户选定景点后调用/api/plan生成路线。虽然内部有依赖关系，但每一步都有独立反馈，用户交互体验更好。

建议把推荐理由生成做成异步任务：规划完成以后先返回基础路线，同时后台调用大模型生成推荐文案，前端轮询获取结果。这样用户不用干等大模型两三秒的延迟，系统“足够快”在毕业设计演示现场很重要。

5.2 前端可视化与交互设计

前端用 Vue 3 + Element Plus 搭管理后台风格界面，再加一个可视化大屏页面。大屏上展示三块内容：左侧是推荐景点卡片列表，每一张卡片都有评分、标签、推荐理由；中间是地图组件，按路线顺序把景点位置连线；右侧是时间轴形式的行程安排，每段行程包含时间、交通距离、地点描述、参考费用。这三块联动的效果是：点击左侧某个景点，地图自动缩放到对应位置，右侧时间轴高亮对应行程。

路线可视化不需要做得太复杂，但地图上连线要能体现“顺序关系”和“交通耗时”。可以在连线旁边标注“车程约18分钟”或“步行约800米”，这个细节能直接提升系统的专业感。数据可视化部分用 ECharts 展示景点分类占比、热度排行、评分分布、推荐命中率等，这部分是为题目中“数据分析”量身定做的。

5.3 性能优化与部署

不要一上来就想微服务、部署到云服务器，毕设系统的首要目标是稳定运行、流畅演示。推荐结果缓存能解决大部分性能问题。热门路线和热门用户群体的推荐结果可以按城市+偏好维度缓存到 Redis，缓存命中时直接返回，省掉重新跑协同过滤的时间。

路线规划遗传算法虽然整体复杂度不大，但在请求并发较高时也会成为瓶颈。建议把规划引擎独立为一个线程池执行，避免阻塞API主线程。如果路线景点数小于等于8个，直接用状态压缩DP求最优解，比遗传算法快且准，大于8个再用遗传算法。这个“规模自动切换”本身也是工程优化能力的一个体现。

部署方案上，Docker Compose 一键部署是最合适的：后端一个容器，前端 Nginx 容器，MySQL 和 Redis 各一个容器。在答辩现场用 Docker 启动项目，不光显得专业，也免去了评委电脑环境不一致导致的各种幺蛾子。

6. 常见问题与排查技巧实录

6.1 冷启动：新用户没有行为数据怎么办

新用户登录后系统没有任何可以依赖的历史行为，这是推荐系统经典问题。我的处理方案是三层兜底：

• 第一层：注册时通过大模型对话收集偏好，转化为结构化标签。
• 第二层：根据城市热度榜和综合评分榜，给用户推荐该城市的Top景点。
• 第三层：等用户产生真实行为后，再逐步增加个性化推荐占比。

实际测试下来，这套策略能让新用户的推荐结果在几次交互后就明显有针对性，并且可以把这个过程做长截图放进论文，作为“系统冷启动解决方案”的实证。

6.2 数据稀疏和相似度矩阵过拟合

协同过滤最大的痛点就是行为矩阵太稀疏。表现在结果上就是：少数热门景点总是出现在所有推荐里，长尾景点几乎不被触达。此时需要做几个调整：推荐时的过滤条件加上“排除最近7天内用户已经浏览过的景点”；计算相似度时，对共现次数少于3的物品对直接置为零，减少偶然共现带来的虚假相似；用户相似度计算时，如果公共交互景点少于2个，相似度直接置低。

另外可以检验一个数学细节：余弦相似度在处理布尔向量时跟向量中零的个数无关，但处理评分向量时，均值中心化会显著影响结果。建议在计算前对评分矩阵做均值中心化，让相似度聚焦于“相对偏好差异”而非绝对分数。

6.3 大模型幻觉问题与“事实约束”机制

这是整个系统里最容易被答辩老师挑战的环节。大模型生成了推荐理由，但编造了一个“开车10分钟就能到”的虚假距离，或者把某景点门票说成了“免费”但实际是收费的，这就是幻觉。解决办法是严格实现事实约束生成模式：

构建Prompt时，把所有的事实数据（景点名称、评分、参考游玩时长、开放时间、交通时间、门票价格）逐条列出，然后用系统提示词明确要求“只许基于给定事实进行表达，不要补充任何额外数据”。程序设计上，模型输出的文案在渲染前还要做一次敏感信息过滤，如果探测到“元”、“¥”、“分钟”这几个关键词周围出现的数字与输入事实不一致，就采用模板化文案兜底。

6.4 路线规划结果看起来“不聪明”的几种原因

我发现不少同学跑出来的路线，景点本身推荐得不错，但顺序很别扭：上午跑东边，中午又跑回西边，下午再跑去东边，同一区域被反复横跳。这通常是两方面的原因：一是推荐候选集里景点全部分散在整个城市，没有任何区域聚类；二是规划目标函数里的交通时间惩罚权重设得过低。解决办法是在进入规划算法前先按距离做“区域预聚类”，把同片区的景点按区域块组合成候选子路线，再由规划算法做组间选择；同时把交通惩罚系数适当提高，论文里可以给出调参前的“绕路率”和调参后的数据对比，这也是一个可以写进论文的实验结论。

6.5 答辩时关于“为什么选择”的话术准备

答辩现场老师几乎必问“为什么选这个算法”“为什么不用更新潮的方案”。这里给一个可以背下来的答题框架：首先要承认你在算法选型时比较过哪些方案，然后给出两个关键理由：一是可解释性，传统算法能精确知道推荐依据；二是稳定性，在数据稀疏场景下表现更可控，并且大模型已经承担了增强层职责。最后补一句“如果你建议引入图神经网络，后续可以在这几个方向扩展”，既表明你了解前沿，又体现了完整的思考深度。

最后再分享一个我实际带过多次项目的经验：整套系统做完以后，一定在所有代码模块里补齐异常处理分支，尤其是大模型调用失败、Redis连接失败、经纬度缺失这三类异常；然后在答辩前一天，把整套流程从头到尾跑三遍，确保演示时每一项功能都一次通过。这个题目之所以是好的毕业设计，是因为它既有算法深度，又有工程广度，还有技术热点的加持，只要把数据、推荐、规划、生成这四层真正打通，它就是一篇高质量、高完成度、强说服力的毕业设计作品。