如果你的毕业设计题目同时出现了Django、LLM、大数据、推荐系统这几个关键词，那咱们可以好好聊一聊。这个组合几乎把计算机专业毕设的加分项叠满了：Django提供完整可靠的后端工程框架，LLM让系统具备真正的智能对话和个性化生成能力，数据分析与可视化又让论文里不缺图表和结论。但叠加归叠加，最难的地方在于：如何把这几个技术栈真正串起来，而不是各写各的demo最后硬拼到一起。
我去年带过几个做旅游推荐方向的本科生，见过太多"推荐系统只有协同过滤+静态数据库"或者"LLM只会套一个聊天窗口"的半成品。这篇博文就以Django + LLM大模型智能路线规划与个性化推荐系统为例，从架构设计、数据建模、推荐算法、LLM集成、可视化分析到踩坑实录，完整拆一遍。内容面向两类人：一是正在选毕设题目的同学，想评估这个题目到底难不难、值不值得做；二是已经定了这个题目但不知道从哪下手的同学，可以直接照着思路复现。
1. 为什么是Django配LLM大模型：这个选题背后的技术逻辑
先说选题。旅游路线推荐系统本身不新鲜，传统做法是分词加协同过滤，或者干脆按评分排序硬推。问题在哪？用户输入的自然语言需求（比如"我想周末从杭州出发去千岛湖，人少风景好，自驾两天一夜"），传统的B2C型推荐系统根本解析不出来，只能靠打标签强行匹配。而LLM大模型恰好擅长把自然语言意图结构化，这是近几年推荐系统最有价值的变化：把用户表达里的隐性约束抽出来，比如出行时间、出发点、同行人类型、偏好强度，再交给规划引擎去排路线。
Django在这套架构里的角色也很明确。它解决的不是算法问题，而是工程化问题。旅游路线推荐系统要落地，必须有用户体系、景点数据库、行程管理、浏览记录、收藏夹、后台管理，这些功能Django的ORM和Admin站点几乎开箱即用。再加上Django自带的认证系统、会话管理、模板渲染，你不需要额外搭前端框架就能出一个能演示的完整系统。对于毕业设计的开发周期来说，这是决定性的优势——选一个你三天就能搭好骨架的框架，把省下来的时间砸在算法和大模型集成上。
大数据成分怎么体现？很多同学听到"大数据"就以为要上Hadoop或者Spark集群，其实对于本科毕设，真正有区分度的是数据量和数据维度。这个系统的数据源可以拆成三层：景点基础数据（爬公开数据或公开数据集）、用户行为数据（收藏、浏览、评分、搜索日志）、以及LLM生成的偏好标签数据。当这些数据叠加后，你可以在论文里做真实的数据分析：热门景点时段分布、用户兴趣聚类、路线热度排名。
我的建议：把题目拆成三个独立可验证的模块——数据层（采集、清洗、分析）、推荐层（传统CF + LLM增强）、交互层（Django展示 + 路线生成）。只要每个模块都有独立的技术亮点，答辩时就有东西可讲。
2. 系统架构与数据模型设计：先搭好骨架再谈智能
很多同学一上来就调API、写Prompt，等发现数据表设计不合理，又回头重构，白白浪费时间。我强烈建议先把架构图和ER图画好，再动手写代码。
2.1 整体架构：五层设计
这套系统的架构我建议至少分五层：
| 层级 | 模块 | 技术选型 |
|---|---|---|
| 数据采集层 | 景点爬虫、公开数据集导入 | requests + BeautifulSoup / CSV批量导入 |
| 数据存储层 | MySQL主库 + Redis缓存 | Django ORM / django-redis |
| 推荐计算层 | 协同过滤、热度统计、LLM候选生成 | Python + LLM API |
| 应用服务层 | 用户、收藏、行程、订单等业务模块 | Django App |
| 展示层 | 后台数据看板、前端交互页面 | Django Templates + pyecharts + Bootstrap |
架构上有一个细节值得注意：LLM调用应该抽成独立的Service层，而不是散落在View里。因为大模型API响应慢、会超时、有token消耗，如果直接写在视图函数里，一旦API出问题整个页面都会卡死。我在项目里统一封装了一个llm_service.py，对外只暴露generate_route(preferences)和explain_recommendation(route_id)两个方法，底层用异步任务去调外部接口或本地模型，网页端先返回缓存结果或者"生成中"状态，等异步任务完成后再推送结果。
2.2 核心数据表设计
Django的数据模型是整个项目的根，我先给出一版可以直接用的核心模型：
# models.py 核心模型简化版 from django.db import models from django.contrib.auth.models import User class ScenicSpot(models.Model): name = models.CharField(max_length=100, verbose_name="景点名称") city = models.CharField(max_length=50, db_index=True, verbose_name="所属城市") category = models.CharField(max_length=50, verbose_name="类型(自然/人文/主题乐园)") rating = models.FloatField(default=0.0, verbose_name="评分") play_duration = models.IntegerField(default=3, verbose_name="建议游玩时长(小时)") lat = models.FloatField(verbose_name="纬度") lng = models.FloatField(verbose_name="经度") description = models.TextField(blank=True, verbose_name="简介") tags = models.JSONField(default=list, verbose_name="标签列表") class Meta: db_table = "scenic_spot" indexes = [ models.Index(fields=["city", "category"]), ] class UserBehavior(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name="用户") spot = models.ForeignKey(ScenicSpot, on_delete=models.CASCADE, verbose_name="景点") behavior_type = models.CharField(max_length=20, verbose_name="行为类型(浏览/收藏/评分)") score = models.IntegerField(null=True, blank=True, verbose_name="评分(1-5)") timestamp = models.DateTimeField(auto_now_add=True, verbose_name="行为时间") class Meta: db_table = "user_behavior" indexes = [ models.Index(fields=["user", "behavior_type"]), ] class TravelRoute(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE, verbose_name="创建用户") title = models.CharField(max_length=200, verbose_name="路线标题") route_data = models.JSONField(verbose_name="路线详情(景点列表+顺序+时间安排)") generated_by = models.CharField(max_length=20, default="LLM", verbose_name="生成方式(LLM/协同过滤/手动)") create_time = models.DateTimeField(auto_now_add=True, verbose_name="生成时间")几个设计上容易踩坑的点集中说明一下：
第一，ScenicSpot.lat和lng一定要用FloatField，不要用DecimalField，否则后续做地理距离计算时类型转换会非常痛苦。我在第一次建模时图省事用了Decimal，结果做"周边景点查找"功能时被精度问题折磨了两个晚上，最后还是改回Float。
第二，tags字段建议用Django 3.1以上支持的JSONField，不要用逗号分隔字符串省事。因为LLM返回的偏好标签、分析模块生成的聚类标签最终都是列表结构，JSONField可以配合PostgreSQL做更高级的查询，即使你用MySQL，也至少能省掉一层split处理。
第三，TravelRoute.route_data是整个系统的心脏，我建议内部结构固定为：
{ "days": [ { "day": 1, "date": "2024-06-01", "spots": [ {"id": 12, "name": "千岛湖中心湖", "start": "09:00", "end": "12:00", "note": "早到避开人流"}, {"id": 15, "name": "天屿山观景台", "start": "14:00", "end": "16:00", "note": "日落时段更佳"} ] } ], "total_distance": 86.5, "transport": "自驾" }结构化保存有两个好处：前端直接渲染；论文里可以统计路线规划算法的时间复杂度和空间利用率。
2.3 数据来源与采集方案
数据层是很多同学头疼的地方。我的做法是组合方案：如果目标是省事，直接找一个公开的景区数据集（例如中国5A景区名录、大众点评开放数据）导入MySQL作为基础数据；如果想体现爬虫能力，用 requests 爬公开网页上的景点公共信息。
这里必须强调合规：只爬取景区名称、地址、开放时间、简介等公开信息，控制请求频率加延时，不采集任何个人隐私数据，爬取后用于个人学习和毕设展示没有问题。最稳妥的方式是公开数据集 + 少量爬虫补充，论文里注明数据来源和处理流程即可。
3. 核心推荐算法与LLM集成：路线规划从"能用"到"好用"
这个部分是系统的灵魂，也是答辩时评审老师最可能深挖的地方。
3.1 推荐链路：三段式设计
不要把所有推荐逻辑都压给大模型。大模型适合做语义理解和语义约束下的答案生成，但不擅长精确的数值计算和多目标排序（比如"距离不超过200公里"这种硬约束，LLM经常算错）。所以我的设计是三段式：
输入用户偏好描述 ↓ ① 规则解析 + 关键词抽取（Django层） ↓ 得到结构化约束条件 ② 基于协同过滤候选召回（数据库层检索） ↓ 得到候选景点池 ③ LLM生成路线 + 行程安排（LLM Service层）第一步，从用户输入的自然语言里抽取约束。比如"从杭州出发去黄山，轻松一点，两天，风景好"要解析出：
- 出发地：杭州
- 目的地：黄山
- 出行天数：2天
- 偏好标签：轻松、风景好(自然风光)
第二步，用协同过滤召回Top-N。我推荐先写一个基于物品的协同过滤，因为比基于用户的好解释，且不需要处理数据稀疏到没法算相似度的尴尬。核心逻辑：找用户评价很高的景点，再看还有哪些用户同时收藏了这些景点，把"经常一起出现"的景点推给当前用户。这一层只负责从几十个景点里捞出一个20个左右的候选集，不需要太精确。
第三步，把候选集连同约束条件一起发给LLM，让模型生成路线。Prompt设计是整个项目最关键的技术细节，我单独开一节讲。
3.2 Prompt设计与Token优化
大模型社区流传过一句话："token的三个点是——Key：我是谁；Query：我在找什么；Value：我能提供什么"。放在推荐系统里再贴切不过：
- System Prompt（Key）：告诉模型它是旅游规划专家，擅长根据用户约束生成合理安排，必须按照JSON格式输出。
- User Prompt（Query）：把用户需求 + 候选景点列表作为输入，明确输出约束。
- Expected Output（Value）：模型需要提供的是路线数据，而不是废话。
我实际用的Prompt模板长这样：
system_prompt = """ 你是资深旅游规划师。请根据用户偏好和候选景点列表，安排一条可行路线。 要求： 1. 按天组织行程，每天景点不超过4个 2. 景点间距离合理，避免绕路 3. 输出必须是JSON，字段：days(列表)，每个day包含day(序号)、spots(列表)、notes(出行提示) 4. 不要输出JSON之外的任何说明 """ user_prompt = f""" 用户需求：{preferences_text} 出发地：{start_city} 出行天数：{days}天 候选景点列表：{candidate_spots_text} 请生成路线。 """有几个经验：
第一，候选景点列表不要超过20个，否则token开销大、模型容易"看花眼"，输出质量反而下降。第二，强制JSON格式输出，如果模型偶尔输出格式错误，代码里要做一次容错：捕获JSON解析异常后重试一次，或者用正则抽取JSON块。第三，控制输出token量，有些模型允许设置max_tokens，路线规划场景固定设置600~800就够，太多反而容易加无意义的描述。
关于API选型：我建议用国内大模型平台的在线API（比如通义千问、DeepSeek、智谱GLM），开发方便、免费额度够用；如果不想依赖外部网络，可以用Ollama在本地跑一个7B左右的模型，但生成质量和速度会打折，更适合作为论文里"本地化部署"的小亮点。两种方式在代码里只差一个请求base_url，统一封装在llm_service.py里即可。
3.3 路线优化：旅行商问题的实用解法
不少同学看到"路线规划"就紧张，觉得是不是要写一个标准的TSP求解器。实际上，对于旅游推荐场景，景点数量很小（一天3~4个），贪心算法足够用，更重要的是让路线看起来"有逻辑"。
我的做法是：先用贪心按地理距离排序（每天起点取上一个景点，按距离最近的候选点作为下一个），然后在Prompt里把"已经排序好的序列"交给LLM做合理性润色（比如要考虑游玩时长、开放时间、用餐点）。这样既避免了算法上的复杂度，又能用LLM的自然语言能力弥补纯算法路线的机械感。
如果想让论文更有深度，可以加一个"路线评分函数"：
def route_score(route, user_tags): """ 评估一条路线的综合得分 """ total_rating = sum(spot.rating for spot in route.spots) tag_match = sum(1 for tag in user_tags if tag in spot_tags(route)) distance_penalty = max(0, route.total_distance - 200) return total_rating * 0.6 + tag_match * 5 - distance_penalty * 0.05用这个函数对LLM生成的路线打分，如果两条路线得分接近，优先选LLM输出更详细注记的那条。答辩时这个"评分+生成"的混合机制，比单纯说"我调了大模型API"高级很多。
4. 数据采集与可视化分析：让毕设看起来有"大数据"含量
推荐系统里很大一块内容是"结果展示"，但毕业设计里数据的分析和可视化往往是拉开差距的地方。一个只有推荐列表的系统，和一个附带完整数据分析看板的系统，答辩印象完全不同。
4.1 数据分析维度怎么选
基于这个项目的数据，我推荐做四类分析：
| 分析主题 | 使用数据 | 图表类型 | 洞察价值 |
|---|---|---|---|
| 景点热度分级 | 收藏、浏览、评分行为 | 柱状图/热力图 | 找出热门景点与冷门优质景点 |
| 城市旅游竞争力 | 景点数量、平均评分、类型分布 | 雷达图/地图 | 推荐城市排序依据 |
| 用户偏好聚类 | 用户标签、行为类型 | 散点图/折线图 | 为协同过滤提供画像依据 |
| 路线行程耗时分布 | 路线表、景点游玩时长 | 漏斗图/箱线图 | 优化路线规划规则 |
这些分析用pyecharts在Django后台渲染成独立看板页面，或者用ECharts前端绘制。注意一点：图表不能只是"有"，论文里要有对图表结论的文字解读，比如"从热度分布可以看出，自然类景点的收藏量在周末显著上升，与推荐系统在周五生成的周末路线点击率正向吻合"，这种因果衔接才是数据分析的加分项。
4.2 数据清洗的几个细节
我从实际采集的数据里总结一个通用清洗流程：
# 数据清洗核心步骤 import pandas as pd df = pd.read_csv("raw_spots.csv") df.drop_duplicates(subset=["name", "city"], keep="first", inplace=True) df["rating"] = pd.to_numeric(df["rating"], errors="coerce").fillna(4.0) df["play_duration"] = df["play_duration"].clip(1, 12) df["category"] = df["category"].replace({"自然": "景区", "山水": "景区"}) # 归类统一 df.to_csv("clean_spots.csv", index=False)有几个坑我要说清楚：
第一，重复数据。同一个景点在不同数据源里名称不完全一致，比如"喀纳斯风景区"和"喀纳斯景区"，按name+city去重后会误判为两条。稳妥做法是加一个"别名检查"：把名称里"景区/风景/名胜"等通用后缀去掉后再比较。
第二，经纬度数据的可靠性。网上爬下来的景点经纬度经常指向景区服务中心而不是核心景区，距离计算误差可能到5~10公里。如果项目对路线距离有要求，建议用高德或百度的地理编码API统一校正一次，或者接受这个误差并在论文里说明。
第三，行为数据的模拟。刚开发完系统时肯定没有真实用户，怎么办？我在项目里写了一个generate_fake_behaviors.py脚本，为测试用户随机生成浏览和收藏记录，再用Faker库生成用户画像标签。这样协同过滤算法和推荐看板立刻就有数据可跑。答辩时你要强调这是"模拟用户行为数据用于方法验证"，不能当作真实运营数据，这个诚实性在学术上很重要。
4.3 可视化引擎集成
pyecharts是目前国内毕设最常用的方案。在Django里集成有个小技巧：pyecharts生成的HTML片段，通过模板渲染的方式嵌到页面里，同时打开Django的X_FRAME_OPTIONS或者直接用一个iframe加载独立视图。我实际用的代码模式是：
from django.http import HttpResponse from pyecharts import options as opts from pyecharts.charts import Bar def hot_spot_chart(request): # 数据获取 spots = ScenicSpot.objects.all().order_by("-rating")[:10] c = ( Bar() .add_xaxis([s.name for s in spots]) .add_yaxis("平均评分", [s.rating for s in spots]) .set_global_opts(title_opts=opts.TitleOpts(title="热门景点评分TOP10")) ) return HttpResponse(c.render_embed())render_embed()方法会把ECharts的JS依赖全部内联到HTML里，这样模板不用额外引CDN，离线演示也能正常显示。
5. Django实战中的那些坑：从开发到部署的排查实录
这一节写几个我实际踩过、也帮学生排查过的典型问题。每一个都谈不上高级，但碰上就是半天起步。
5.1 ORM查询优化：N+1问题
景点列表页、路线列表页，这是整个系统最容易出现N+1查询的地方。一开始我的代码是：
routes = TravelRoute.objects.filter(user=request.user) for route in routes: print(route.route_data["spots"]) # 查询一次route只有一层循环还好，但如果你在模板里遍历route又遍历spots再调景点信息，三次循环嵌套，Page Query轻松破百。解决方式简单粗暴：
routes = TravelRoute.objects.filter(user=request.user).select_related("user").prefetch_related("route_spots")但要注意，route_data是JSONField，里面存的spot列表没法直接prefetch_related，只能要么反范式多建一张路由详情表，要么一次性查出来候选景点再内存聚合。我的建议是普通列表页直接values()取值降到一次查询，只有详情页才允许连表大查询。
5.2 Django创建App与模块边界
很多人习惯只建一个app叫tourism，把所有模型都塞进去，到后期改一个字段冒出一堆bug。我的分法是这样：
django-admin startproject travel_project python manage.py startapp users python manage.py startapp spots python manage.py startapp routes python manage.py startapp analytics四个app各管一摊：用户和认证、景点数据、路线生成、数据分析。LLM调用放routes里的services/llm_service.py，这个文件只被route view调用，不会被users引用。这样做论文结构也好写：一个系统拆成四个功能模块，各模块之间的依赖关系清清楚楚。
5.3 LLM异步调用与超时处理
LLM接口的响应时间通常在2~10秒，如果同步调用，前端会转圈半天甚至超时。我的方案是Celery + Redis：视图函数收到用户请求后，先把任务交给Celery，页面立刻返回"路线规划中"的占位状态；Celery worker异步调LLM，完成后写回数据库；前端用轮询或WebSocket的方式刷新结果。
# tasks.py from celery import shared_task import json from .services import llm_service @shared_task def generate_route_task(user_id, preferences, candidate_ids): route_data = llm_service.generate_route(preferences, candidate_ids) TravelRoute.objects.create( user_id=user_id, route_data=route_data, generated_by="LLM" )如果不想引入Celery，也有简单方案：在Django View里把同步调用包一层，用threading.Thread跑后台线程，前端隔3秒拉一次结果。这个方案能应付演示场景，但对论文的技术含量弱一点，看你自己取舍。
5.4 大模型API的容错机制
LLM API的稳定性并不如传统数据库查询。我要求代码里必须做三层容错：
- 超时重试：单次请求超时设为15秒，最多重试2次，重试间隔指数退避。
- JSON解析失败重试：模型偶尔输出多行解释文字，导致
json.loads失败。捕获异常后把内容喂回模型一次，请求它"只输出修正后的JSON"。 - 降级策略：如果连续3次请求失败，直接把候选景点按评分倒序生成一个"无LLM版本"的路线，保证页面不出错。
这个降级逻辑答辩时一定要讲，评审最关心的就是"你处理工程异常的能力"。
5.5 部署环节的常见问题
本地开发跑得好好的，部署就崩，这是毕设学生的通病。最大的坑是static文件和数据库迁移。
我的建议是：用Docker Compose一键部署，里面编排三个容器——web(Django + uWSGI)、db(MySQL)、cache(Redis)。数据库迁移必须执行两遍：
python manage.py makemigrations python manage.py migrate很多同学第一次migrate在本地，第二次在服务器时忘记把迁移文件提交到代码仓库，结果服务器上导入不了数据。另外一个坑是时区配错，Django默认是UTC，用户行为时间戳差了8小时，导致"高峰时段"分析图表完全不对。务必在settings.py里设置：
TIME_ZONE = "Asia/Shanghai" USE_TZ = True6. 从功能完成到毕业设计答辩：评审老师最看重的几点
代码写完只是第一步，怎么把项目讲清楚才是验收的关键。
6.1 论文结构怎么搭
基于我指导学生写论文的经验，目录结构可以参考这样：
- 绪论（选题背景、国内外研究现状、主要工作）
- 相关技术概述（Django、LLM、协同过滤、数据分析）
- 系统需求分析与设计（功能需求、架构设计、数据库设计）
- 核心算法设计（偏好解析、CF召回、LLM路线生成、优化评分）
- 系统实现（主要功能模块的页面与代码说明）
- 数据分析与实验评估（数据集介绍、分析图表、推荐效果对比）
- 总结与展望
核心章节是第四章和第六章。第四章要把LLM集成和路线规划算法讲透，第六章必须有对比实验：比如"纯协同过滤" vs "协同过滤+LLM生成"的推荐满意度对比。我的做法是邀请20个测试用户对生成的路线打分（5分制），两种方法各生成20条路线，最后算平均分和方差。
6.2 答辩现场最容易遇到的问题
根据我实际参加毕设答辩的观察，老师常问这几类问题：
- "LLM推荐相比传统推荐到底好在哪？"回答思路：传统协同过滤对语义理解弱，用户说"想避开很多人、风景好"这种模糊需求基本无法处理；LLM可以把这种描述转成可量化的约束条件（低拥挤度、高评分、自然类别），并能在候选集基础上生成连贯的路线。准备一张对比表，从语义理解、冷启动、可解释性三个维度说明。
- "如果大模型API挂了怎么办？"直接回答降级策略：页面不报错，回到协同过滤+评分排序的老路径；系统维护一个降级状态位，论文里可以写"双引擎容错架构"。
- "你的数据量有多大，大数据体现在哪？"建议准备一个数据量表格：景点数、行为记录数、用户数、路线数。如果行为数据是模拟的，明确指出模拟生成的方法和规模。这个阶段"大数据"更多是数据分析和可视化处理的丰富性，论文里如实描述即可。
6.3 加分的小功能点
如果时间和精力允许，这几个功能是低成本高回报的：
- 推荐解释模块：LLM生成路线时，让它在JSON的
note字段里输出"为什么推荐这个景点"，前端路线卡片直接展示，这是可解释推荐最直观的体现。 - 路线对比功能：同一个用户需求，生成"紧凑型"和"舒适型"两条路线，页面并排比较，路线评分函数会算出两条路线分别的得分。答辩时可以现场演示"你看，同一条需求，两条路线的总分差在哪里一目了然"。
- 历史路线收藏/复现：用户收藏的路线，一键导出为PDF或通过微信分享链接的形式展示。这个功能实现难度很低，但给老师演示时有很强的完成度感。
根据我个人做项目和带毕设的经验，毕设最怕的不是技术难，而是做出来"跟教程一模一样"没有自己的思考。这套系统的核心思想并不复杂：把Django负责的工程能力、LLM负责的语义理解能力、数据分析负责的评估能力分工清楚，然后每一个环节都做到"能解释、能演示、能写进论文"。按照上面的架构和步骤走下来，无论最终答辩结果如何，你不会再觉得毕业设计只是糊弄一个系统出来，而是会发现自己真的把一个复杂的业务需求拆解、实现并验证了一遍。
