这两年只要打开毕设相关的群或者论坛十屏里有八屏都在刷“旅游大数据分析平台”“舆情监测系统”这类题目。说实话这题火了不是没道理的——它把当下最吃香的几个词全占了Python、Flask、大数据、可视化、大模型、agent。对计算机专业的毕业生来说这几乎是一个“怎么选都不会错”的方向既好出活、又好答辩、还能往简历上写几行亮眼的技术栈。但好题目不等于好作品我见过太多人抱着同一个标题最后交出来一个只会读csv画柱状图的三无系统。这篇文章就不讲虚的了直接把“Python旅游客流与舆情监测分析平台”这个题目拆开揉碎从选题价值、技术选型、数据设计、后端模块、可视化方案到大模型和agent到底怎么落地一步步告诉你这个平台应该怎么做、为什么这么做、答辩时老师会问什么。无论你是正在纠结毕设题目的学生还是想快速搭一个旅游数据分析demo的开发者这篇文章都值得收藏。1. 为什么说这个题目是毕设圈的“最优解”先想清楚价值再动手如果只看表面这个题目就是“爬点旅游数据、画几个图表、部署个网页”。但真正答辩拿高分的作品绝对不是这种水平。你要先把这篇毕设的核心价值拆明白才知道力气往哪里使。1.1 技术覆盖面决定了你的答辩下限一个旅游客流与舆情分析平台天然需要处理三件事数据从哪来、数据怎么分析、结果怎么展示。这三件事正好对应了大学四年课程里的核心板块——数据采集用Python爬虫或者API对接数据清洗和存储涉及Pandas、MySQL、Redis这些常规武器分析层如果你不想只做平均值、占比这种“小学统计”就得上分词、情感分析、聚类这些偏算法的内容展示层用Flask做后端服务配合ECharts做可视化大屏。如果再把大模型加进去做自动报告生成、智能问答你的系统就立刻从“数据分析作业”升级成“智能分析平台”。老师看一份毕设首先看的是你做了什么、用了什么技术。这个题目的好处在于你的工作量是可以分层级展示的——基础版能做统计分析进阶版能上NLP舆情分析高阶版能接大模型和agent。选这个题等于给了自己一条清晰的升级路径绝不至于没东西写。1.2 旅游领域的数据天然适合做“故事化展示”纯技术如果不是和具体业务结合很容易写成“工具说明书”。而旅游客流和舆情分析有一个其他领域比不上的优势数据本身就有故事。比如全国热门景区的客流量变化春节和暑假就是两个完全不同的故事比如突发舆情对某个景区口碑的影响从负面评论出现到官方回应、再到情绪平复整个生命周期都能用数据画出来。这类分析结论直观、好解释、可视化之后效果非常震撼答辩时你可以直接对着大屏讲故事老师一听就明白你这系统是干什么的、有什么价值。这一点是很多纯技术项目比不了的。2. 数据是平台的燃料客流与舆情的采集方案怎么落地很多人第一步就死在数据上。网上能找到的现成旅游数据集大多是几年前的、字段残缺的灌水csv拿来做毕设很容易被老师一句话问住。这里我分享两套数据方案一套是“真爬虫路线”一套是“混合数据路线”你根据自己情况选。2.1 客流数据公开API为主、爬虫为辅附字段设计客流数据不建议去爬携程、去哪儿这种大平台反爬机制重、法律风险也大。更稳的是这两个来源政府公开数据平台很多省市文旅厅会定期发布重点景区游客接待量格式虽然是静态报表但胜在干净、可溯源答辩时你可以理直气壮说“数据来自官方公开渠道”。第三方旅游平台的开放接口或指数类数据比如某些OTA平台提供的景区热度指数这类数据偏趋势型适合做“客流预测”和“热度排名”。如果你确实想自己爬建议把目标放在景区官网的公告页、天气预报网站的景区天气页这些站点反爬机制极低。展示一下最简单的爬虫思路import requests from bs4 import BeautifulSoup # 以某个景区官网公告页为例只取标题和发布时间 def crawl_scenic_news(url): headers {User-Agent: Mozilla/5.0} resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) items [] for li in soup.select(.news-list li): title li.a.get_text(stripTrue) date li.span.get_text(stripTrue) items.append({title: title, date: date}) return items无论数据从哪个渠道来客流数据落到数据库里的核心字段建议这样设计字段名类型说明idBIGINT主键自增scenic_nameVARCHAR(64)景区名称province / cityVARCHAR(32)所在省市用于地图下钻visitor_countINT当日客流/接待量travel_dateDATE日期weatherVARCHAR(16)当日天气用于关联分析source_typeTINYINT数据来源标记1-官方 2-爬虫注意日期景区名一定要做联合唯一索引否则数据清洗时去重会非常痛苦。2.2 舆情数据评论采集与RSS订阅双通道舆情这块主流做法是采集旅游平台的游客评论比如马蜂窝景点点评、携程目的地攻略下的用户反馈。这些页面结构规律强翻页参数好找爬虫写起来不算难。但评论区数据量巨大且夹杂大量垃圾信息清洗工作才是大头。我的建议是走两条路并行采集评论数据用于训练情感分析模型或做统计分析接入新闻类网站和论坛的RSS订阅、关键词搜索接口用于监测突发性舆情事件。舆情数据落到MongoDB或者MySQL的json字段里都可以字段建议包含内容、发布时间、来源、情感标签、主题标签、景区关联ID。如果你想让平台显得更有“大数据感”可以把舆情数据量做到十万条级别配合Pandas做分批处理效果会非常直观。3. Flask后端模块设计分析平台的中枢神经该怎么搭数据有了接下来就是平台的心脏——后端服务。很多学生做Flask项目习惯“一个py文件写完所有路由”这在小demo里没问题但做毕设平台老师一看这种结构就会皱眉。推荐的分层结构我用一个实际项目的目录来展示。3.1 项目目录结构与核心依赖travel_analysis/ ├── app.py # 应用入口注册蓝图 ├── config.py # 配置文件数据库、Redis、模型API Key ├── requirements.txt ├── models/ # 数据库模型 │ ├── scenic.py │ └── review.py ├── services/ # 业务逻辑层 │ ├── traffic_service.py # 客流统计服务 │ ├── sentiment_service.py # 舆情情感分析服务 │ └── report_service.py # 大模型报告生成服务 ├── api/ # 接口层蓝图 │ ├── traffic_api.py │ ├── sentiment_api.py │ └── dashboard_api.py └── utils/ # 工具函数 ├── db_helper.py └── auth.py依赖方面核心这几项就够了Flask、Flask-SQLAlchemy、Flask-CORS、Pandas、pymysql、requests、jieba、snownlp或者更重的transformers、openai调大模型用。排序组合一下写进requirements.txt答辩时老师问“你的环境怎么部署”你直接把这份文件亮出来就是加分项。3.2 核心接口设计一切为可视化服务后端的接口设计一定要跟着前端可视化走我的经验是先想清楚大屏上有几个图表再定接口。一个典型的大屏至少需要这几个接口/api/traffic/overview总客流量、同比增长率、热门景区Top5返回汇总卡片数据/api/traffic/trend按日/周的客流趋势返回两个数组日期、人数直接喂给ECharts折线图/api/traffic/map按省份聚合的客流数据返回对象列表用于地图下钻/api/sentiment/stats正面/中性/负面评论占比返回饼图数据/api/sentiment/wordcloud高频关键词词频表返回词云数据/api/report/generate调用大模型接口传入分析结果返回生成的报告文本。一个推荐的写法是接口层只负责参数校验和响应包装真正的统计逻辑写在service里。比如客流趋势查询# services/traffic_service.py def get_trend_data(start_date, end_date, scenic_idNone): query db.session.query( TrafficRecord.travel_date, func.sum(TrafficRecord.visitor_count).label(total) ) if scenic_id: query query.filter(TrafficRecord.scenic_id scenic_id) query query.filter( TrafficRecord.travel_date start_date, TrafficRecord.travel_date end_date ).group_by(TrafficRecord.travel_date) result query.all() return { dates: [str(r[0]) for r in result], counts: [int(r[1]) for r in result] }这样写的好处是接口层很薄逻辑清晰是其一更关键的是换数据源时不需要动接口定义。毕设里“规划得很干净”和“代码一堆乱麻”放在一起对比分数差距立刻拉开。3.3 用Redis做缓存让系统有“高性能”的谈资如果前端每次刷新都去打MySQL做聚合查询几万条数据的时候MySQL还能扛几十万条的时候接口延迟就上来了。这里引入Redis做缓存是有实际意义的不只是为了简历上写一行。import redis, json r redis.Redis(hostlocalhost, port6379, db0) def get_trend_cached(start_date, end_date): cache_key ftrend:{start_date}:{end_date} cached r.get(cache_key) if cached: return json.loads(cached) data get_trend_data(start_date, end_date) r.setex(cache_key, 300, json.dumps(data)) # 缓存5分钟 return data热点数据缓存5分钟既保证了新鲜度又避免了重复计算。老师问“你是怎么做性能优化的”你把这个设计讲出来比你说一百句“我的系统很流畅”都有说服力。4. 舆情监测的核心算法从分词到情感分析的完整链路舆情分析是这个平台区别于普通“客流统计系统”的关键点也是很多学生最容易糊弄过去的部分。有的同学加载一个snownlp就直接丢给前端了流程图都没有答辩时一问“你的负面评论是怎么识别的”就卡壳。这里我把完整的舆情处理链路展开讲。4.1 文本预处理的三个必要步骤舆情数据是典型的“脏数据”直接分析等于自杀。标准流程是去重评论数据爬下来会有大量重复比如机器人评论、同内容多次发布用hash值或者内容MD5做去重是最快的清洗去掉URL、用户、表情符号、无意义短文本比如“哈哈哈”这种长度小于5的句子分词与停用词过滤用jieba分词同时维护一个针对旅游领域的停用词表把“我们”“这个”“什么”这类虚词全部滤掉。分词代码看起来很简单但领域词表才是关键。比如“长隆”“迪士尼”“欢乐谷”这些词如果不加进自定义词典jieba会把它们切开导致后续词频统计和情感分析出现偏差。记得在加载时加上自己的领域词表import jieba jieba.load_userdict(travel_dict.txt) # 每行一个词支持自定义权重4.2 情感分析怎么选型才不容易被老师挑刺情感分析最稳妥的方案是“基础模型兜底关键场景升级”。什么意思呢对十万条评论做全量情感分类用snownlp或者SnowNLP这种轻量级库速度快、零成本虽然精度一般但作为趋势分析足够对负面评论再走一层更精确的判别逻辑引入一个简单的规则引擎比如评论里出现“差评”“太差”“再也不来”“浪费时间”等关键词时强制标记为负面这样可以极大修正纯模型误判。如果你想让毕设更有亮点还可以用大模型API做高精度情感复核——抽500条评论送给大模型让它返回JSON格式的情感标签和原因和模型结果对比出一个偏差率这组数据放论文里直接就是实验分析章节。这个进阶方案在后面讲大模型集成时还会仔细说。4.3 主题聚类与词云让舆情分析“有结论”而非“有图表”很多系统的词云就是简单的高频词展示但高手的做法是给词云赋予语义信息。比如用jieba分词后按词性过滤只保留名词和形容词再按TF-IDF提取每个景区的关键词这样“人挤人”“门票贵”“风景美”这类代表真实评价的词才会浮出来而不是一堆“我”“的”“了”。主题聚类用LDA或者BERTopic都行但如果数据量只有几万条LDA就够用了。把评论分成几类比如“交通吐槽”“门票价格”“景区服务”“自然风光”再统计每一类的占比和情感分布。这一组数据出来以后你的平台就有一个非常核心的卖点——“自动识别游客关注什么话题对这些话题的态度”这在行业里叫“游客画像”写到论文里很有分量。5. 可视化大屏如何把分析结果变成答辩时的加分表演到了可视化这个环节很多人的做法是找一个现成的后台模板改改数据就完了。这种做法不是不行但如果你想在答辩时让老师眼前一亮大屏的布局和交互设计就得动脑子。5.1 大屏布局的经典公式我观察过很多高分毕设作品大屏布局基本都遵循这个规律顶部标题栏核心指标滚动卡片今日客流、累计舆情总数、正面率、预警事件数左侧省份客流地图或者景区热度Top10横向条形图中间客流趋势折线图按日/周切换右侧舆情情感占比环形图词云图底部最新舆情滚动列表热点事件时间线。这套布局的信息密度很高数据之间的联动关系也讲得通。最关键是全部用ECharts实现自己可控性最强不需要依赖任何收费组件。5.2 ECharts数据对接的小技巧ECharts对接Flask接口这块有几个细节值得注意接口返回的日期字符串一定格式化好例如“2024-08-01”不要在js里二次处理减少出bug的概率地图数据要用中国地图GeoJSONecharts 4的china.js或者自行加载GeoJSON如果只做省内分析就加载省份GeoJSON文件体积更小构建图表实例时设置resize监听浏览器窗口变化时大屏不错位。// 折线图数据对接示例 fetch(/api/traffic/trend?start2024-08-01end2024-08-31) .then(res res.json()) .then(data { trendChart.setOption({ xAxis: { data: data.dates }, series: [{ data: data.counts, type: line, areaStyle: {} }] }) })如果你的精力够还可以给大屏加一个楼层交互点击省份地图上的某个省右侧的舆情榜和词云同步刷新为该省数据。这种“数据联动”效果在答辩现场演示时非常有冲击力而且实现逻辑并不复杂就是前端监听chart的click事件再重新请求带省份参数的接口。5.3 词云实现的两个坑词云实现最常用的方案是ECharts词云扩展echarts-wordcloud。这个库有两个很容易踩坑的地方词云词频数据如果包含小数或者负数渲染会报错。处理接口数据时保证词频是正整数比如向上取整词过多时超过200渲染会卡顿所以后端在返回词频数据时就做好截断保留频率前150的词即可。6. 大模型和agent怎么融入毕设从“人工智障”到“智能分析助手”如果只是把大模型API的返回值打印到页面上老师会直接说“这不就是调了个接口吗”。要让大模型真正成为平台的亮点得把agent的思路用起来——让大模型能根据平台里的数据自动生成分析报告、回答用户关于旅游的问题。6.1 报告自动生成用结构化数据喂给大模型这个功能的核心在于“输入”的设计。不要直接把一堆json丢给大模型让它写报告那样输出内容会发散很不稳定。我的做法是把统计分析结果整理成结构化的“事实摘要”再把摘要和写作指令一起发给大模型。举个例子系统先把下列内容整理成自然语言描述8月份全国重点景区总客流为xxx万人次环比上升x%排名前三的景区是xxx、xxx、xxx本月负面舆情占比x%主要集中在“门票价格”和“排队时间长”两个话题。然后把这段话发给大模型要求它生成一份500字左右的暑期旅游市场分析简报格式包含“总体概况—热点景区—舆情风险—建议”。这样做大模型产出的报告是有数据依据的不会胡编答辩展示时逻辑非常通顺。from openai import OpenAI client OpenAI(base_url你的模型服务地址, api_key你的Key) def generate_report(summary_text): prompt 你是旅游数据分析专家。请根据以下事实数据生成一份文旅市场分析简报要求 1. 结构包含总体概况、热点景区、舆情风险、提升建议 2. 字数500字左右语言客观专业 3. 只能使用提供的数据不得编造。\n\n数据摘要\n summary_text resp client.chat.completions.create( model你的模型名称, messages[{role: user, content: prompt}], temperature0.3 ) return resp.choices[0].message.content注意温度参数要低否则报告会有很多废话。另外建议把生成按钮设计成“手动触发”不要自动跑因为大模型API的响应时间不稳定放在页面里容易卡UI。6.2 做一个简单的“景区问答agent”本质是检索生成毕设里做agent不需要像工业级那样搞复杂的记忆和反思机制一句话总结就是“先查数据再让大模型对着数据说话”。我把它设计成两步第一步用户提问“上周哪个景区人最多”系统先从数据库查出来结果这一步叫工具调用、检索、或者function calling都行第二步把查询结果嵌入prompt让大模型组织成自然语言答案返回给用户。这样实现的agent在答辩演示时讲工作流会非常清晰用户输入问题→意图识别判断是想查客流还是查舆情→调用对应数据库查询工具→把查询结果交给大模型→生成回答。每一个环节都有具体代码支撑老师不会觉得你在吹牛。如果想让这条路再深一点可以引入工作流引擎的概念把“客流分析→舆情分析→报告生成→预警推送”串成一个自动化Pipeline。比如每天定时跑一次任务自动抓取最新舆情、自动更新情感分析结果、自动生成当天的日报推送给管理员。这个设计在论文里写“平台实现了舆情监测与日报生成的自动化闭环”说服力远大于堆砌技术名词。6.3 大模型接本地还是接API我的建议毕设有两种接法接大模型API部署简单、效果稳定适合绝大多数同学。缺点是答辩时如果没网或者演示环境受限可能出现意外。本地部署开源模型比如用Ollama跑一个几B的小模型优点是答辩现场断网也能跑显得“全栈”能力更强缺点是很吃电脑配置而且小模型生成报告的质量和稳定性明显不如商业API。我的建议是“混合方案”平时开发用API答辩前把关键功能做一个本地模型的降级版备着。如果时间不够就老老实实用API在所有调用处做好异常兜底——模型服务不可用就返回预先准备好的模板报告保证系统演示不翻车。7. 踩坑清单这些坑我见过太多人踩了做这类毕设有几个问题极其高频提前避雷能给你省下至少一周时间。7.1 数据库乱建模中期改起来痛不欲生常见错误是把所有数据一股脑塞进一个大宽表比如把客流、天气、评论全放一张表。分析时SQL越写越复杂JOIN越来越乱。正确做法是客流表和评论表分开建模通过景区ID关联天气信息单独一张字典表分析时再关联。宁可多建两张表不要贪图一时省事。7.2 爬虫数据没有保存原始报文出问题无法溯源特别是舆情数据如果只存清洗后的结果而不存原始内容后面发现清洗逻辑有bug时你只能重新爬。正确做法是原始数据存一份、清洗后的分析数据存一份两表之间用ID对应。数据回溯能力很重要答辩时老师问“你这个清洗规则是怎么验证的”你能拿出原始数据对比就有底气。7.3 图表组件版本不匹配导致白屏ECharts 5和echarts-wordcloud插件存在版本兼容性差异前者要求插件是配套构建版本如果直接用npm装最新版很容易出现“词云不显示”或者“整个大屏白屏”的诡异问题。解决方法是锁版本在package.json里固定echarts和wordcloud的版本号不要用“latest”这种宽泛声明。7.4 答辩前才想起来没有测试数据这是最大的坑。我见过有人系统功能全正常但因为没有准备好演示数据打开大屏全是空图表后面代码写得再好也没用。建议在开发初期就用脚本批量生成一批规模可观至少几个月的趋势数据、几万条评论数据的模拟数据入库注意生成时要让数据有波峰波谷比如节假日前后客流上升这样图表才有看头演示才有故事可讲。8. 论文和答辩的准备做成什么样才算高分最后聊点过来人的经验。平台做出来只是成功了一半论文和答辩的把控同样重要。论文的章节建议按“需求分析→系统设计→数据库设计→功能模块实现→系统测试→总结”来写每一章都要有截图和数据支撑。记得把技术选型的对比过程写进去比如为什么不选Django而选Flask、为什么用Redis做缓存、为什么情感分析选了轻量级方案而不是重型深度学习模型。这种“选型理由”是老师很爱看的内容也是拉开分数差距的地方。答辩PPT不需要花哨按这个结构走就非常稳项目背景与意义1-2页→系统架构图1页→数据库设计1页→核心功能演示截图配上关键代码截图3-4页→大模型Agent工作流1-2页→总结与展望1页。老师最爱问的几个问题提前准备好答案你的数据是真实采集的吗——答部分是官方公开渠道采集部分为教学演示数据但字段结构和量级贴近真实场景你的情感分析准确率是多少——答用小规模人工标注的测试集测评过句级别准确率约xx%负面评论经过规则兜底后召回率明显提升大模型生成的内容如果出现幻觉怎么办——答限制了只能基于平台数据生成并且在prompt里要求“不得编造”同时在系统层面设置人工审核入口你的系统最大的创新点和不足是什么——创新点是舆情分析和客流预测的联动、以及大模型自动报告不足可以诚恳地说是数据量还不够大模型精度有提升空间。整套组合拳打下来这个毕设基本就是高分预定。说实话做这类平台项目最忌讳的就是闷头写代码、不思考“为什么这么做”。你把这篇文章的结构吃透了带着“先设计、后实现、再讲清楚”的思路去推进这个题目做出来不仅能拿高分还会让你真正理解一个数据分析平台从0到1的完整链路。最后再分享一个小技巧把开发过程中踩过的坑和解决办法记录下来放进论文“系统测试与问题分析”章节比任何空话都更真实、更有力。
Python旅游客流与舆情监测分析平台：从数据采集到大模型Agent的完整实践
这两年只要打开毕设相关的群或者论坛十屏里有八屏都在刷“旅游大数据分析平台”“舆情监测系统”这类题目。说实话这题火了不是没道理的——它把当下最吃香的几个词全占了Python、Flask、大数据、可视化、大模型、agent。对计算机专业的毕业生来说这几乎是一个“怎么选都不会错”的方向既好出活、又好答辩、还能往简历上写几行亮眼的技术栈。但好题目不等于好作品我见过太多人抱着同一个标题最后交出来一个只会读csv画柱状图的三无系统。这篇文章就不讲虚的了直接把“Python旅游客流与舆情监测分析平台”这个题目拆开揉碎从选题价值、技术选型、数据设计、后端模块、可视化方案到大模型和agent到底怎么落地一步步告诉你这个平台应该怎么做、为什么这么做、答辩时老师会问什么。无论你是正在纠结毕设题目的学生还是想快速搭一个旅游数据分析demo的开发者这篇文章都值得收藏。1. 为什么说这个题目是毕设圈的“最优解”先想清楚价值再动手如果只看表面这个题目就是“爬点旅游数据、画几个图表、部署个网页”。但真正答辩拿高分的作品绝对不是这种水平。你要先把这篇毕设的核心价值拆明白才知道力气往哪里使。1.1 技术覆盖面决定了你的答辩下限一个旅游客流与舆情分析平台天然需要处理三件事数据从哪来、数据怎么分析、结果怎么展示。这三件事正好对应了大学四年课程里的核心板块——数据采集用Python爬虫或者API对接数据清洗和存储涉及Pandas、MySQL、Redis这些常规武器分析层如果你不想只做平均值、占比这种“小学统计”就得上分词、情感分析、聚类这些偏算法的内容展示层用Flask做后端服务配合ECharts做可视化大屏。如果再把大模型加进去做自动报告生成、智能问答你的系统就立刻从“数据分析作业”升级成“智能分析平台”。老师看一份毕设首先看的是你做了什么、用了什么技术。这个题目的好处在于你的工作量是可以分层级展示的——基础版能做统计分析进阶版能上NLP舆情分析高阶版能接大模型和agent。选这个题等于给了自己一条清晰的升级路径绝不至于没东西写。1.2 旅游领域的数据天然适合做“故事化展示”纯技术如果不是和具体业务结合很容易写成“工具说明书”。而旅游客流和舆情分析有一个其他领域比不上的优势数据本身就有故事。比如全国热门景区的客流量变化春节和暑假就是两个完全不同的故事比如突发舆情对某个景区口碑的影响从负面评论出现到官方回应、再到情绪平复整个生命周期都能用数据画出来。这类分析结论直观、好解释、可视化之后效果非常震撼答辩时你可以直接对着大屏讲故事老师一听就明白你这系统是干什么的、有什么价值。这一点是很多纯技术项目比不了的。2. 数据是平台的燃料客流与舆情的采集方案怎么落地很多人第一步就死在数据上。网上能找到的现成旅游数据集大多是几年前的、字段残缺的灌水csv拿来做毕设很容易被老师一句话问住。这里我分享两套数据方案一套是“真爬虫路线”一套是“混合数据路线”你根据自己情况选。2.1 客流数据公开API为主、爬虫为辅附字段设计客流数据不建议去爬携程、去哪儿这种大平台反爬机制重、法律风险也大。更稳的是这两个来源政府公开数据平台很多省市文旅厅会定期发布重点景区游客接待量格式虽然是静态报表但胜在干净、可溯源答辩时你可以理直气壮说“数据来自官方公开渠道”。第三方旅游平台的开放接口或指数类数据比如某些OTA平台提供的景区热度指数这类数据偏趋势型适合做“客流预测”和“热度排名”。如果你确实想自己爬建议把目标放在景区官网的公告页、天气预报网站的景区天气页这些站点反爬机制极低。展示一下最简单的爬虫思路import requests from bs4 import BeautifulSoup # 以某个景区官网公告页为例只取标题和发布时间 def crawl_scenic_news(url): headers {User-Agent: Mozilla/5.0} resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) items [] for li in soup.select(.news-list li): title li.a.get_text(stripTrue) date li.span.get_text(stripTrue) items.append({title: title, date: date}) return items无论数据从哪个渠道来客流数据落到数据库里的核心字段建议这样设计字段名类型说明idBIGINT主键自增scenic_nameVARCHAR(64)景区名称province / cityVARCHAR(32)所在省市用于地图下钻visitor_countINT当日客流/接待量travel_dateDATE日期weatherVARCHAR(16)当日天气用于关联分析source_typeTINYINT数据来源标记1-官方 2-爬虫注意日期景区名一定要做联合唯一索引否则数据清洗时去重会非常痛苦。2.2 舆情数据评论采集与RSS订阅双通道舆情这块主流做法是采集旅游平台的游客评论比如马蜂窝景点点评、携程目的地攻略下的用户反馈。这些页面结构规律强翻页参数好找爬虫写起来不算难。但评论区数据量巨大且夹杂大量垃圾信息清洗工作才是大头。我的建议是走两条路并行采集评论数据用于训练情感分析模型或做统计分析接入新闻类网站和论坛的RSS订阅、关键词搜索接口用于监测突发性舆情事件。舆情数据落到MongoDB或者MySQL的json字段里都可以字段建议包含内容、发布时间、来源、情感标签、主题标签、景区关联ID。如果你想让平台显得更有“大数据感”可以把舆情数据量做到十万条级别配合Pandas做分批处理效果会非常直观。3. Flask后端模块设计分析平台的中枢神经该怎么搭数据有了接下来就是平台的心脏——后端服务。很多学生做Flask项目习惯“一个py文件写完所有路由”这在小demo里没问题但做毕设平台老师一看这种结构就会皱眉。推荐的分层结构我用一个实际项目的目录来展示。3.1 项目目录结构与核心依赖travel_analysis/ ├── app.py # 应用入口注册蓝图 ├── config.py # 配置文件数据库、Redis、模型API Key ├── requirements.txt ├── models/ # 数据库模型 │ ├── scenic.py │ └── review.py ├── services/ # 业务逻辑层 │ ├── traffic_service.py # 客流统计服务 │ ├── sentiment_service.py # 舆情情感分析服务 │ └── report_service.py # 大模型报告生成服务 ├── api/ # 接口层蓝图 │ ├── traffic_api.py │ ├── sentiment_api.py │ └── dashboard_api.py └── utils/ # 工具函数 ├── db_helper.py └── auth.py依赖方面核心这几项就够了Flask、Flask-SQLAlchemy、Flask-CORS、Pandas、pymysql、requests、jieba、snownlp或者更重的transformers、openai调大模型用。排序组合一下写进requirements.txt答辩时老师问“你的环境怎么部署”你直接把这份文件亮出来就是加分项。3.2 核心接口设计一切为可视化服务后端的接口设计一定要跟着前端可视化走我的经验是先想清楚大屏上有几个图表再定接口。一个典型的大屏至少需要这几个接口/api/traffic/overview总客流量、同比增长率、热门景区Top5返回汇总卡片数据/api/traffic/trend按日/周的客流趋势返回两个数组日期、人数直接喂给ECharts折线图/api/traffic/map按省份聚合的客流数据返回对象列表用于地图下钻/api/sentiment/stats正面/中性/负面评论占比返回饼图数据/api/sentiment/wordcloud高频关键词词频表返回词云数据/api/report/generate调用大模型接口传入分析结果返回生成的报告文本。一个推荐的写法是接口层只负责参数校验和响应包装真正的统计逻辑写在service里。比如客流趋势查询# services/traffic_service.py def get_trend_data(start_date, end_date, scenic_idNone): query db.session.query( TrafficRecord.travel_date, func.sum(TrafficRecord.visitor_count).label(total) ) if scenic_id: query query.filter(TrafficRecord.scenic_id scenic_id) query query.filter( TrafficRecord.travel_date start_date, TrafficRecord.travel_date end_date ).group_by(TrafficRecord.travel_date) result query.all() return { dates: [str(r[0]) for r in result], counts: [int(r[1]) for r in result] }这样写的好处是接口层很薄逻辑清晰是其一更关键的是换数据源时不需要动接口定义。毕设里“规划得很干净”和“代码一堆乱麻”放在一起对比分数差距立刻拉开。3.3 用Redis做缓存让系统有“高性能”的谈资如果前端每次刷新都去打MySQL做聚合查询几万条数据的时候MySQL还能扛几十万条的时候接口延迟就上来了。这里引入Redis做缓存是有实际意义的不只是为了简历上写一行。import redis, json r redis.Redis(hostlocalhost, port6379, db0) def get_trend_cached(start_date, end_date): cache_key ftrend:{start_date}:{end_date} cached r.get(cache_key) if cached: return json.loads(cached) data get_trend_data(start_date, end_date) r.setex(cache_key, 300, json.dumps(data)) # 缓存5分钟 return data热点数据缓存5分钟既保证了新鲜度又避免了重复计算。老师问“你是怎么做性能优化的”你把这个设计讲出来比你说一百句“我的系统很流畅”都有说服力。4. 舆情监测的核心算法从分词到情感分析的完整链路舆情分析是这个平台区别于普通“客流统计系统”的关键点也是很多学生最容易糊弄过去的部分。有的同学加载一个snownlp就直接丢给前端了流程图都没有答辩时一问“你的负面评论是怎么识别的”就卡壳。这里我把完整的舆情处理链路展开讲。4.1 文本预处理的三个必要步骤舆情数据是典型的“脏数据”直接分析等于自杀。标准流程是去重评论数据爬下来会有大量重复比如机器人评论、同内容多次发布用hash值或者内容MD5做去重是最快的清洗去掉URL、用户、表情符号、无意义短文本比如“哈哈哈”这种长度小于5的句子分词与停用词过滤用jieba分词同时维护一个针对旅游领域的停用词表把“我们”“这个”“什么”这类虚词全部滤掉。分词代码看起来很简单但领域词表才是关键。比如“长隆”“迪士尼”“欢乐谷”这些词如果不加进自定义词典jieba会把它们切开导致后续词频统计和情感分析出现偏差。记得在加载时加上自己的领域词表import jieba jieba.load_userdict(travel_dict.txt) # 每行一个词支持自定义权重4.2 情感分析怎么选型才不容易被老师挑刺情感分析最稳妥的方案是“基础模型兜底关键场景升级”。什么意思呢对十万条评论做全量情感分类用snownlp或者SnowNLP这种轻量级库速度快、零成本虽然精度一般但作为趋势分析足够对负面评论再走一层更精确的判别逻辑引入一个简单的规则引擎比如评论里出现“差评”“太差”“再也不来”“浪费时间”等关键词时强制标记为负面这样可以极大修正纯模型误判。如果你想让毕设更有亮点还可以用大模型API做高精度情感复核——抽500条评论送给大模型让它返回JSON格式的情感标签和原因和模型结果对比出一个偏差率这组数据放论文里直接就是实验分析章节。这个进阶方案在后面讲大模型集成时还会仔细说。4.3 主题聚类与词云让舆情分析“有结论”而非“有图表”很多系统的词云就是简单的高频词展示但高手的做法是给词云赋予语义信息。比如用jieba分词后按词性过滤只保留名词和形容词再按TF-IDF提取每个景区的关键词这样“人挤人”“门票贵”“风景美”这类代表真实评价的词才会浮出来而不是一堆“我”“的”“了”。主题聚类用LDA或者BERTopic都行但如果数据量只有几万条LDA就够用了。把评论分成几类比如“交通吐槽”“门票价格”“景区服务”“自然风光”再统计每一类的占比和情感分布。这一组数据出来以后你的平台就有一个非常核心的卖点——“自动识别游客关注什么话题对这些话题的态度”这在行业里叫“游客画像”写到论文里很有分量。5. 可视化大屏如何把分析结果变成答辩时的加分表演到了可视化这个环节很多人的做法是找一个现成的后台模板改改数据就完了。这种做法不是不行但如果你想在答辩时让老师眼前一亮大屏的布局和交互设计就得动脑子。5.1 大屏布局的经典公式我观察过很多高分毕设作品大屏布局基本都遵循这个规律顶部标题栏核心指标滚动卡片今日客流、累计舆情总数、正面率、预警事件数左侧省份客流地图或者景区热度Top10横向条形图中间客流趋势折线图按日/周切换右侧舆情情感占比环形图词云图底部最新舆情滚动列表热点事件时间线。这套布局的信息密度很高数据之间的联动关系也讲得通。最关键是全部用ECharts实现自己可控性最强不需要依赖任何收费组件。5.2 ECharts数据对接的小技巧ECharts对接Flask接口这块有几个细节值得注意接口返回的日期字符串一定格式化好例如“2024-08-01”不要在js里二次处理减少出bug的概率地图数据要用中国地图GeoJSONecharts 4的china.js或者自行加载GeoJSON如果只做省内分析就加载省份GeoJSON文件体积更小构建图表实例时设置resize监听浏览器窗口变化时大屏不错位。// 折线图数据对接示例 fetch(/api/traffic/trend?start2024-08-01end2024-08-31) .then(res res.json()) .then(data { trendChart.setOption({ xAxis: { data: data.dates }, series: [{ data: data.counts, type: line, areaStyle: {} }] }) })如果你的精力够还可以给大屏加一个楼层交互点击省份地图上的某个省右侧的舆情榜和词云同步刷新为该省数据。这种“数据联动”效果在答辩现场演示时非常有冲击力而且实现逻辑并不复杂就是前端监听chart的click事件再重新请求带省份参数的接口。5.3 词云实现的两个坑词云实现最常用的方案是ECharts词云扩展echarts-wordcloud。这个库有两个很容易踩坑的地方词云词频数据如果包含小数或者负数渲染会报错。处理接口数据时保证词频是正整数比如向上取整词过多时超过200渲染会卡顿所以后端在返回词频数据时就做好截断保留频率前150的词即可。6. 大模型和agent怎么融入毕设从“人工智障”到“智能分析助手”如果只是把大模型API的返回值打印到页面上老师会直接说“这不就是调了个接口吗”。要让大模型真正成为平台的亮点得把agent的思路用起来——让大模型能根据平台里的数据自动生成分析报告、回答用户关于旅游的问题。6.1 报告自动生成用结构化数据喂给大模型这个功能的核心在于“输入”的设计。不要直接把一堆json丢给大模型让它写报告那样输出内容会发散很不稳定。我的做法是把统计分析结果整理成结构化的“事实摘要”再把摘要和写作指令一起发给大模型。举个例子系统先把下列内容整理成自然语言描述8月份全国重点景区总客流为xxx万人次环比上升x%排名前三的景区是xxx、xxx、xxx本月负面舆情占比x%主要集中在“门票价格”和“排队时间长”两个话题。然后把这段话发给大模型要求它生成一份500字左右的暑期旅游市场分析简报格式包含“总体概况—热点景区—舆情风险—建议”。这样做大模型产出的报告是有数据依据的不会胡编答辩展示时逻辑非常通顺。from openai import OpenAI client OpenAI(base_url你的模型服务地址, api_key你的Key) def generate_report(summary_text): prompt 你是旅游数据分析专家。请根据以下事实数据生成一份文旅市场分析简报要求 1. 结构包含总体概况、热点景区、舆情风险、提升建议 2. 字数500字左右语言客观专业 3. 只能使用提供的数据不得编造。\n\n数据摘要\n summary_text resp client.chat.completions.create( model你的模型名称, messages[{role: user, content: prompt}], temperature0.3 ) return resp.choices[0].message.content注意温度参数要低否则报告会有很多废话。另外建议把生成按钮设计成“手动触发”不要自动跑因为大模型API的响应时间不稳定放在页面里容易卡UI。6.2 做一个简单的“景区问答agent”本质是检索生成毕设里做agent不需要像工业级那样搞复杂的记忆和反思机制一句话总结就是“先查数据再让大模型对着数据说话”。我把它设计成两步第一步用户提问“上周哪个景区人最多”系统先从数据库查出来结果这一步叫工具调用、检索、或者function calling都行第二步把查询结果嵌入prompt让大模型组织成自然语言答案返回给用户。这样实现的agent在答辩演示时讲工作流会非常清晰用户输入问题→意图识别判断是想查客流还是查舆情→调用对应数据库查询工具→把查询结果交给大模型→生成回答。每一个环节都有具体代码支撑老师不会觉得你在吹牛。如果想让这条路再深一点可以引入工作流引擎的概念把“客流分析→舆情分析→报告生成→预警推送”串成一个自动化Pipeline。比如每天定时跑一次任务自动抓取最新舆情、自动更新情感分析结果、自动生成当天的日报推送给管理员。这个设计在论文里写“平台实现了舆情监测与日报生成的自动化闭环”说服力远大于堆砌技术名词。6.3 大模型接本地还是接API我的建议毕设有两种接法接大模型API部署简单、效果稳定适合绝大多数同学。缺点是答辩时如果没网或者演示环境受限可能出现意外。本地部署开源模型比如用Ollama跑一个几B的小模型优点是答辩现场断网也能跑显得“全栈”能力更强缺点是很吃电脑配置而且小模型生成报告的质量和稳定性明显不如商业API。我的建议是“混合方案”平时开发用API答辩前把关键功能做一个本地模型的降级版备着。如果时间不够就老老实实用API在所有调用处做好异常兜底——模型服务不可用就返回预先准备好的模板报告保证系统演示不翻车。7. 踩坑清单这些坑我见过太多人踩了做这类毕设有几个问题极其高频提前避雷能给你省下至少一周时间。7.1 数据库乱建模中期改起来痛不欲生常见错误是把所有数据一股脑塞进一个大宽表比如把客流、天气、评论全放一张表。分析时SQL越写越复杂JOIN越来越乱。正确做法是客流表和评论表分开建模通过景区ID关联天气信息单独一张字典表分析时再关联。宁可多建两张表不要贪图一时省事。7.2 爬虫数据没有保存原始报文出问题无法溯源特别是舆情数据如果只存清洗后的结果而不存原始内容后面发现清洗逻辑有bug时你只能重新爬。正确做法是原始数据存一份、清洗后的分析数据存一份两表之间用ID对应。数据回溯能力很重要答辩时老师问“你这个清洗规则是怎么验证的”你能拿出原始数据对比就有底气。7.3 图表组件版本不匹配导致白屏ECharts 5和echarts-wordcloud插件存在版本兼容性差异前者要求插件是配套构建版本如果直接用npm装最新版很容易出现“词云不显示”或者“整个大屏白屏”的诡异问题。解决方法是锁版本在package.json里固定echarts和wordcloud的版本号不要用“latest”这种宽泛声明。7.4 答辩前才想起来没有测试数据这是最大的坑。我见过有人系统功能全正常但因为没有准备好演示数据打开大屏全是空图表后面代码写得再好也没用。建议在开发初期就用脚本批量生成一批规模可观至少几个月的趋势数据、几万条评论数据的模拟数据入库注意生成时要让数据有波峰波谷比如节假日前后客流上升这样图表才有看头演示才有故事可讲。8. 论文和答辩的准备做成什么样才算高分最后聊点过来人的经验。平台做出来只是成功了一半论文和答辩的把控同样重要。论文的章节建议按“需求分析→系统设计→数据库设计→功能模块实现→系统测试→总结”来写每一章都要有截图和数据支撑。记得把技术选型的对比过程写进去比如为什么不选Django而选Flask、为什么用Redis做缓存、为什么情感分析选了轻量级方案而不是重型深度学习模型。这种“选型理由”是老师很爱看的内容也是拉开分数差距的地方。答辩PPT不需要花哨按这个结构走就非常稳项目背景与意义1-2页→系统架构图1页→数据库设计1页→核心功能演示截图配上关键代码截图3-4页→大模型Agent工作流1-2页→总结与展望1页。老师最爱问的几个问题提前准备好答案你的数据是真实采集的吗——答部分是官方公开渠道采集部分为教学演示数据但字段结构和量级贴近真实场景你的情感分析准确率是多少——答用小规模人工标注的测试集测评过句级别准确率约xx%负面评论经过规则兜底后召回率明显提升大模型生成的内容如果出现幻觉怎么办——答限制了只能基于平台数据生成并且在prompt里要求“不得编造”同时在系统层面设置人工审核入口你的系统最大的创新点和不足是什么——创新点是舆情分析和客流预测的联动、以及大模型自动报告不足可以诚恳地说是数据量还不够大模型精度有提升空间。整套组合拳打下来这个毕设基本就是高分预定。说实话做这类平台项目最忌讳的就是闷头写代码、不思考“为什么这么做”。你把这篇文章的结构吃透了带着“先设计、后实现、再讲清楚”的思路去推进这个题目做出来不仅能拿高分还会让你真正理解一个数据分析平台从0到1的完整链路。最后再分享一个小技巧把开发过程中踩过的坑和解决办法记录下来放进论文“系统测试与问题分析”章节比任何空话都更真实、更有力。