1. 项目概述1.1 这个项目到底是做什么的很多计算机专业的朋友在做毕业设计的时候都会在选题上纠结很久——既要能体现技术含量又要有完整的业务逻辑还得保证自己能在期限内做完。有些经典题目比如“图书管理系统”“学生选课系统”确实容易做出来但答辩时老师一问就露馅了因为业务太简单技术点几乎没有创新。如果你正在为这种问题发愁我建议你从头到尾看一下这篇文章。这里说的“基于时间序列的旅游数据预测平台”简单来说就是把某个景区或者某座城市的历史游客量数据采集进来用Prophet算法训练出预测模型预测未来一段时间的游客到访量然后把预测结果和历史折线图一起放在网页上展示。整个项目用Flask作为后端框架用MySQL或者SQLite存历史数据配合ECharts或者Plotly做可视化前端还能提供简单的交互查询功能。标题里提到的agent和大模型在实际设计的时候可以作为扩展点比如做一个基于大模型的自然语言问答入口用户直接输入“下周哪个景区人最多”系统自动调用预测结果回答。1.2 能解决什么问题适合什么人群做参考这个题目能解决的实际问题很清晰。旅游行业里的景区别墅管理、酒店排房、交通调度都很依赖游客量的预测。旺季来了人扎堆服务质量会下降淡季没人来运营成本又收不回来。一套能预测未来游客量的平台能够帮运营者提前调配资源也能帮游客避开人流高峰。这正是你毕业设计答辩时可以用来讲“应用价值”的地方——它不是空中楼阁而是有真实场景支撑的。适合参考这个题目的人群主要有三类计算机、软件工程专业的本科生需要完成毕业设计想要一个技术栈完整、工作量合理、答辩有料可控的题目数据分析方向的研究生侧重点可以放在Prophet与ARIMA、LSTM的对比实验上增加模型评估部分转行做数据分析、准备作品集的初学者这个项目麻雀虽小五脏俱全覆盖了数据采集、清洗、建模、后端接口、前端展示的完整链路写进简历里非常有说服力。我自己在实际带项目的时候最常听到的反馈是“感觉自己学了很多东西但不知道串起来能做什么”。这个题目恰恰就是把Python数据分析、Web开发、机器学习三个方向串起来的典型。接下来我会把整个项目的设计思路、核心代码、踩坑记录全部拆开讲透尽量让你照着操作就能复现出来。2. 整体架构设计与技术选型思路2.1 后端框架为什么选Flask而不是Django很多教程一上来就甩代码不讲选型逻辑。我这里先解释清楚选Flask的原因后面你用起来才会更顺手。Flask是一个微框架核心非常轻量一个应用可以只用一个文件启动。而Django是重量级框架自带ORM、Admin后台、认证体系适合大而全的项目。对于毕业设计这个体量Flask有明显的优势上手成本低路由写法直观装饰器一看就懂不需要理解Django的中间件、App概念灵活自由数据库用SQLAlchemy还是原生SQL模板用Jinja2还是前后端分离都由你决定不会被框架束缚部署方便服务器上只需要装Python环境和依赖包用gunicorn就能挂起来云服务器配置要求也不高模型集成自然Prophet训练好的模型用joblib或pickle保存Flask里直接加载调用预测结果以JSON格式返回前后端交互非常顺。有些人会在知乎上争论Flask和FastAPI谁更好。说实话FastAPI的异步性能和自动文档确实强但如果你要体现传统Web开发的完整性Flask的生态更成熟参考代码也更多出问题更容易搜到解决方案。毕业设计求稳Flask是最不容易翻车的选择。2.2 时序预测模型为什么选Prophet游客量数据是典型的时间序列数据——每天一个值构成一条按日期排序的序列。时间序列预测的方法非常多常见的可以分成以下几类方法适用场景优缺点ARIMA单序列、平稳趋势参数调优麻烦对节假日特征处理弱LSTM大数据量、非线性关系需要大量样本训练慢GPU要求高Prophet有周期性、有节假日效应的业务数据开箱即用可解释性强内置节假日支持这个项目选Prophet是经过实际对比的。首先游客量数据有明显的季节周期和节假日效应比如国庆假期游客量暴涨、寒假期间北方景区淡季。Prophet把时间序列分解为趋势项、季节项、节假日项三部分正好命中这些特征。其次Prophet由Facebook开源API设计得非常友好一个DataFrame两列ds为日期、y为数值就能训练pandas的数据结构直接兼容。第三Prophet的预测结果自带置信区间画图时能直接输出上下界这在展示的时候非常加分——观众一看就知道预测是有不确定性范围的而不是拍脑袋给个数。标题里还提到了LSTM但说实话对于毕业设计体量的数据一般只有几百条到两三千条LSTM很难发挥作用。数据量不够LSTM容易过拟合反而效果不如Prophet。如果你想让项目显得更有探索深度可以把LSTM作为对比模型写进论文里结论是“在数据量有限的情况下Prophet的泛化表现更优”这就既体现了工作量又站得住脚。2.3 可视化与前端方案的取舍可视化部分我用的是EChartsAjax的前后端分离方案但这要看你自己的前端基础来定。方案一后端Jinja2模板渲染。把数据在Python里处理好直接传给模板用ECharts在页面中绘图。优点是代码量少不用跨域适合前端不太熟练的同学。方案二前后端分离。Vue或原生HTMLAjax请求后端接口后端返回JSON。优点是结构清晰你的项目可以同时体现“接口设计”和“前后端协作”的能力。缺点是代码量多了一些。我推荐你选方案二因为毕业设计答辩时“Restful API设计”是个非常值得讲的亮点而且浏览器访问接口能看到JSON数据演示效果也很直观。前端不用上Vue全家桶一个静态HTML页面配上ECharts的CDN就能搞定图表类型包括折线图、热力图、柱状图。页面做三块历史趋势图、预测结果图、数据统计卡片再多就喧宾夺主了。2.4 项目目录结构与数据流设计一个整洁的目录结构不仅让自己开发时头脑清醒也是答辩时展示“工程素养”的一部分。我常用的结构如下travel-forecast/ ├── app.py # Flask主入口注册蓝图 ├── config.py # 配置文件数据库、模型路径等 ├── models/ │ ├── __init__.py │ └── database.py # SQLAlchemy模型景区表、游客量表 ├── routes/ │ ├── __init__.py │ ├── forecast.py # 预测相关接口 │ └── stats.py # 数据统计接口 ├── services/ │ ├── data_loader.py # 数据加载与清洗 │ ├── forecaster.py # Prophet模型封装 │ └── agent.py # 大模型agent扩展可选 ├── static/ │ ├── css/ │ └── js/ ├── templates/ │ └── index.html ├── data/ │ ├── raw/ # 原始采集数据 │ └── processed/ # 清洗后数据 ├── models_saved/ # 已训练模型存放目录 └── requirements.txt数据流向大概是这样的原始数据爬虫或Excel导入→ 数据清洗统一日期格式、处理缺失值 → 存入MySQL → 训练脚本读取数据训练Prophet模型 → 模型保存为pkl文件 → Flask启动时加载模型 → 前端请求预测接口 → 返回JSON给ECharts渲染。这条链路每一步都是可以展示的面试或答辩时可以按这条链路讲非常清晰。3. 数据获取、清洗与特征工程3.1 数据从哪儿来合法合规地获取毕业设计的项目数据获取这块一定要谨慎。旅游数据有几个安全又可靠的来源公开数据集比如一些城市数据开放平台会公开景区客流数据、旅游收入数据可以直接下载CSV国泰安、知网论文附件很多研究旅游经济的论文会在附件里放核心数据下载后注明来源即可自己模拟生成如果实在找不到合适的真实数据可以按季节规律随机噪声的方式生成一条仿真游客序列在论文里写清楚“数据为仿真验证用”。这个方法最省事也不存在版权和合规问题。我不建议在毕业设计里去爬携程、马蜂窝这种商业网站的数据。一方面反爬机制复杂你花大量时间在反反爬上偏离了项目核心另一方面商业网站的游客量数据往往不是真实客流而是“热度指数”之类的指标做预测没有实际意义。如果真想练爬虫可以在合法合规的前提下爬公开的天气预报历史数据作为特征或者爬公开平台上的景点评论数量做相关分析。3.2 数据字段设计与预处理细节数据库我建议设计两张表景区表和游客量表。景区表scenic_spots字段名类型说明idINT主键nameVARCHAR景区名称cityVARCHAR所在城市levelVARCHAR景区等级5A/4AcategoryVARCHAR景区类型自然/人文游客量表tourist_flow字段名类型说明idINT主键spot_idINT关联景区IDvisit_dateDATE日期visitor_countINT游客量weatherVARCHAR天气状况temperatureFLOAT平均气温is_holidayTINYINT是否节假日数据清洗的重点有三个方面。第一日期格式统一。Prophet要求时间列必须是ds且为datetime类型。实际数据里常见的坑是“2024/1/5”“2024-01-05”“20240105”三四种格式混在一起必须在加载时用pd.to_datetime统一处理并设置错误参数为coerce把无法解析的置为NaT再删除。第二缺失值处理。游客量单日缺失我建议用前后七天的平均值填充不要用整个序列的均值因为冬季和夏季的游客量差异非常大全局均值填充会把季节性规律冲淡。连续多天缺失的话直接删除这些日期或者用插值法如interpolate(linear)补上。第三异常值甄别。比如某天突然爆出一个平时10倍的数据很可能是录入错误或者特殊事件。先画出箱线图和序列曲线把明显偏离的点标记出来再决定是剔除还是保留。有一种情况要特别注意如果异常值恰好落在国庆节当天那可能不是错误而是真实的人流高峰这种情况不要盲目删除。3.3 特征工程让模型更懂旅游业务Prophet原生只吃日期和数值两列但这不意味着特征工程不重要。你可以通过增加回归变量add_regressor让模型学到更多信息这也是答辩时的加分项。常用的外部特征有三个节假日期特征把是否节假日转换成一个0-1变量作为额外回归因子。Prophet本身有自带的节假日参数但如果你的数据是按“某省份”或者“某景区”维度统计的自定义节假日列表会更准确。天气特征温度、降雨量对游客量影响明显。雨天游客量骤降这个是常识模型如果不知道这个规律预测的雨天数据就会偏大。把天气状况量化成数值如降雨量mm、最高气温℃传入add_regressor效果提升非常明显。滞后特征比如前一天的游客量因为出行计划往往有惯性今天人多明天大概率也不少。不过要注意加了滞后特征之后预测未来数据时需要递归地生成滞后值稍微复杂一些。建议初学者先不加把基础版本跑通后再考虑。4. Prophet建模与预测核心实现4.1 Prophet模型原理快速理解展开讲Prophet内部复杂的贝叶斯推理显然不现实我用一个通俗的类比来解释Prophet认为任何一条时间序列都可以拆成一个“长期大趋势”加“季节性波动”再加“节假日脉冲”最后附上一点随机噪声。其中长期大趋势是类似“今年比去年游客多”的总体方向Prophet用分段线性函数去拟合它并且允许在特定“拐点”改变斜率。季节性波动包括以年为周期的旅游淡旺季、以周为周期的周末效应。节假日脉冲就是像五一、国庆这种突然拉高的尖峰。这种分解方式的好处是透明可解释。咱们平时说“黑盒模型”预测完你不知道为什么是这个数。Prophet则会把趋势分量、季节分量、节假日分量分别输出你能清楚地看到本周六预测值的构成这在写论文分析结果时极其方便。4.2 核心训练代码实战先把最核心的Prophet训练脚本写出来这份代码我实际跑过很多次可以直接复用import pandas as pd from prophet import Prophet from prophet.diagnostics import cross_validation, performance_metrics import joblib # 加载并准备数据 df pd.read_csv(data/processed/tourist_flow.csv) df[ds] pd.to_datetime(df[visit_date]) df[y] df[visitor_count] # 按景区筛选示例取景区ID1 df_spot df[df[spot_id] 1][[ds, y]].sort_values(ds) # 构建并配置模型 model Prophet( yearly_seasonalityTrue, # 年周期性淡旺季 weekly_seasonalityTrue, # 周周期性周末效应 daily_seasonalityFalse, # 游客量按天统计无需日内季节 changepoint_prior_scale0.1, # 趋势拐点灵活度 seasonality_prior_scale8.0, # 季节项强度 holidays_prior_scale8.0, # 节假日项强度 ) # 加入自定义节假日 holidays pd.DataFrame({ holiday: china_holiday, ds: pd.to_datetime([2024-10-01, 2024-10-02, 2024-10-03, 2024-05-01, 2024-05-02, 2024-05-03, 2024-02-10, 2024-02-11, 2024-02-12]), lower_window: 0, upper_window: 0, }) model model.add_holidays(holidays) # 训练 model.fit(df_spot) # 预测未来60天 future model.make_future_dataframe(periods60) forecast model.predict(future) # 保留最近实际数据 预测数据方便画图 result forecast[[ds, yhat, yhat_lower, yhat_upper]].tail(90) # 保存模型 joblib.dump(model, models_saved/spot_1.pkl) result.to_csv(data/processed/forecast_spot_1.csv, indexFalse) print(模型训练完成预测结果已保存)这里有几个参数值得展开说明一下。changepoint_prior_scale控制趋势拐点的敏感程度默认是0.05。如果你觉得预测曲线太僵硬没有跟上数据突变的节奏就调大一些如果觉得曲线震荡太厉害出现过拟合就调小一些。我实测景区数据设成0.1比较合适因为近年来旅游市场整体波动较大。seasonality_prior_scale控制季节项强度默认10.0设成8.0是希望模型不要过于相信历史季节性规律防止把随机噪声也当成季节信号。节假日权重我设得比较高因为国内假期对旅游影响是决定性的春节、国庆前几天必然爆量。4.3 模型评估预测结果到底准不准答辩时老师一定会问“你的模型效果怎么样”。所以评估这一步绝不能省。Prophet的标准做法是交叉验证# 初始训练量取前365天预测未来90天每30天滚动一次 cv_df cross_validation(model, initial365 days, period30 days, horizon90 days) metrics performance_metrics(cv_df) print(metrics[[horizon, mse, mae, mape]])重点看MAPE平均绝对百分比误差。假设MAPE是12%意思是平均来看预测值和真实值偏差在12%左右。对于旅游客流预测来说这个精度已经相当可用。如果你发现MAPE超过25%优先检查是不是节假日没有配好或者特征数据本身有大量缺失。还有一点要提醒交叉验证需要模型重新训练多次比较耗时。如果数据量不大跑一遍大概一两分钟数据量大时建议在开发机上跑不要放在Flask启动时跑。4.4 多景区模型管理策略一个正经平台不可能只预测一个景区。后台通常有几十上百个景区每个景区一条游客序列训练方式有两种全量一条序列加景区ID作为回归器优点是只用训练一个模型管理简单缺点是不同景区规律差异大一个模型很难拟合所有序列预测精度下降。每个景区单独训练一个模型精度最高但模型文件多训练时间线性增长。好在Prophet单模型训练速度很快几百条数据通常几秒就完成。我推荐第二种“一景区一模型”然后用命名规则spot_{id}.pkl存到目录里Flask在首个请求到达时懒加载对应模型并缓存到内存中。这样既保证了精度又不需要启动时把所有模型一次性加载内存占用可控。5. Flask后端接口与前端可视化实现5.1 核心API接口怎么设计后端接口是整个平台的中枢。按照Restful风格设计至少包含以下接口接口路径方法功能说明/api/spotsGET获取景区列表下拉框用/api/history/spot_idGET获取指定景区历史游客量/api/forecast/spot_idGET获取指定景区预测数据/api/stats/summaryGET获取总览统计总游客量、同比、环比/api/agent/queryPOST大模型Agent自然语言查询入口以预测接口为例核心代码大概长这样from flask import Blueprint, jsonify from services.forecaster import load_model, get_forecast_data forecast_bp Blueprint(forecast, __name__, url_prefix/api) forecast_bp.route(/forecast/int:spot_id, methods[GET]) def forecast(spot_id): # 懒加载模型已加载的直接从缓存取 model load_model(spot_id) days request.args.get(days, default30, typeint) forecast_df model.predict(model.make_future_dataframe(periodsdays)) # 只返回日期和预测值控制响应体积 data forecast_df[[ds, yhat, yhat_lower, yhat_upper]].tail(days) result { code: 0, data: { dates: data[ds].dt.strftime(%Y-%m-%d).tolist(), yhat: data[yhat].round(0).tolist(), lower: data[yhat_lower].round(0).tolist(), upper: data[yhat_upper].round(0).tolist(), } } return jsonify(result)这里有个细节我踩过坑Prophet预测出来的yhat是浮点数但游客量理论上应该是整数。如果你直接round(0)处理前端展示确实干净了但要注意在计算评估指标时一定要用未取整的原始数值否则误差评估会有偏差。5.2 Flask接口响应速度优化预测接口涉及加载模型和推理首次请求可能耗时1到2秒用户会感觉“转圈转半天”。优化的核心手段是缓存。具体来说把spot_id对应的预测结果在第一次计算时存放进内存字典后续请求直接读缓存只要缓存没过期就不需要重新预测。cache {} def get_forecast_cached(spot_id, days30): key (spot_id, days) if key not in cache: model load_model(spot_id) forecast_df model.predict(model.make_future_dataframe(periodsdays)) cache[key] forecast_df[[ds, yhat, yhat_lower, yhat_upper]].tail(days) return cache[key]一般来说预测未来30天或60天的结果在一天内不会变所以缓存有效期设24小时完全没问题。如果你连历史数据的查询都变慢了检查一下数据库索引给visit_date加个普通索引就能快很多。5.3 ECharts前端展示与交互联动前端页面布局我推荐一个典型的“大屏交互”结构顶部是标题和统计卡片中间主体是历史趋势折线图右侧是预测结果带置信区间的面积图底部是各景区游客量排行柱状图。整套页面用Flex布局一行代码都不用写UI框架。核心的ECharts配置预测图需要用两条线加一个置信区间带let chartForecast echarts.init(document.getElementById(forecastChart)); fetch(/api/forecast/${spotId}?days30) .then(res res.json()) .then(res { let dates res.data.dates; chartForecast.setOption({ tooltip: { trigger: axis }, legend: { data: [预测值, 置信区间下界, 置信区间上界] }, xAxis: { type: category, data: dates }, yAxis: { type: value, name: 游客量人次 }, series: [ { name: 预测值, type: line, data: res.data.yhat, smooth: true, lineStyle: { width: 3 }, }, { name: 置信区间下界, type: line, data: res.data.lower, lineStyle: { opacity: 0 }, stack: confidence, symbol: none, }, { name: 置信区间上界, type: line, data: res.data.upper, lineStyle: { opacity: 0 }, stack: confidence, symbol: none, areaStyle: { color: rgba(64, 158, 255, 0.2) }, } ] }); });这个Stack技巧的意思是下界序列和上界序列的差值区域在绘图时表现为阴影带既方便观察预测区间宽度又不用额外做数据处理。ECharts用Stack属性把两个序列叠起来视觉上正好形成一个管道预测的置信区间一目了然。前端交互方面景区下拉框切换后重新请求三个接口联动刷新所有图表。还可以加一个日期范围选择器让用户自定义查看历史数据的时间段这个功能做起来不难但是交互体验提升很多。6. 大模型Agent扩展让平台“会说话”6.1 为什么要给平台加Agent能力标题里特意提到了“agent”和“大模型”这是当前科研和工程的热点也完全可以作为你毕业设计的差异化亮点。传统的可视化平台是“人找数据”用户要先选景区、再选图表、再看数字整个流程是被动式的。而大模型Agent可以做的是“数据找人”用户用一句自然语言提问比如“未来一周哪个景区游客量最高”或者“国庆期间北京各大景区预测客流对比”系统自动解析意图、查询数据库、调用预测结果再生成一段中文回答。对于毕业设计而言Agent的意义在于展示你懂最新的技术趋势又不会喧宾夺主——它只是一个扩展模块基础平台仍然是FlaskProphet。6.2 Agent模块的轻量实现思路不需要从零训练大模型量级大且没必要。直接用现成的大模型API配合套路化的提示词工程就能实现。核心流程分三步意图识别与参数提取用户输入“未来7天杭州西湖游客量预测”用正则或者调用大模型API提取出时间窗口7天、地点杭州西湖两个关键参数数据查询根据参数调用平台的内部接口拿到预测结果和历史对比数据答案生成把数据结果拼接成JSON塞进提示词让大模型生成一段有分析结论的自然语言回复。代码层面的骨架大概是这样的import requests import json def agent_query(user_input): # 1. 调用LLM提取结构化参数 prompt f从用户问题中提取时间范围和地点以JSON输出{user_input} params call_llm(prompt) # 返回 {days: 7, spot: 西湖} # 2. 查询平台内部数据 spot_id get_spot_id_by_name(params[spot]) forecast_data get_forecast_cached(spot_id, params[days]) # 3. 生成分析回复 answer_prompt f以下是预测数据JSON请用口语化总结给用户{json.dumps(forecast_data, ensure_asciiFalse)} answer call_llm(answer_prompt) return answer如果你不想在毕业设计里依赖外部API费用可以做一个简化版使用预置的模板回复把“未来7天游客量预测约为X人次峰值为X人次出现在X日”的模板填好。在答辩时说明“这里如果接入大模型API即可升级为自然语言问答Agent目前系统内置了结构化查询作为降级方案”老师会觉得你很懂系统的工程弹性。6.3 Agent与大模型的坑和注意事项如果决定接入真实的大模型API注意两条。第一API Key千万不要硬编码提交到Git仓库里用环境变量方式读取。第二用户输入中的直接查询语句要过滤避免用户利用prompt injection绕过你的提示词要求大模型输出系统配置之类的信息。在毕业设计演示中展示正常查询功能即可不需要把安全边界做得特别复杂但论文里可以提一两句防护思路显得你有安全意识。7. 开发过程常见问题与排查技巧7.1 Prophet安装失败怎么办Prophet在Windows上安装容易出问题最典型的是编译报错提示缺cmdstanpy或者compilers。现在新版本推荐走conda安装conda install -c conda-forge prophet如果你坚持用pip先升级pip和依赖再装python -m pip install --upgrade pip pip install prophet装完之后先跑一个最小测试from prophet import Prophet能导入成功就说明没问题。我在给学生排查的时候发现很多报错是因为Python版本太新比如3.12以上的某些版本对Prophet依赖的fbprophet相关包支持不好这时候直接用conda建一个3.9或者3.10的环境最省心。7.2 预测结果全部为一条直线怎么回事新手最常遇到的诡异情况是训练和预测都执行成功但预测未来的曲线是一条水平直线完全没有季节性波动。排查思路分三步检查数据时间跨度如果只有两三个月的冬季数据模型确实学不出年季节性检查yearly_seasonality设置如果数据只有周维度波动可以考虑只保留weekly_seasonalityTrue而把yearly_seasonalityFalse不然模型会把年周期拟合成一个极小值检查changepoint_prior_scale如果设置成0.001这种极端小的值趋势就是一条直线自然没有任何变化。解决办法是调整seasonality_prior_scale到10到15之间让季节项权重更大。多数情况下把季节项权重大一点曲线就会“活”过来。7.3 明明节假日人很多预测却低估了节假日效应预测偏低几乎每个人都遇到过。核心原因在于节假日列表不够完整。Prophet只会根据你传入的holiday日期去拟合脉冲如果你只把法定假日加进去而实际数据里还包含“暑假”这种长周期高峰不是法定节假日但游客量大模型自然学不到这个规律。你可以处理这个问题的一个好办法是为暑假、寒假分别创建两条holiday记录把日期区间内的每一天都列进去lower_window和upper_window设置为0。这样模型就能把“7月到8月”识别成一个长周期脉冲预测高峰会更贴合现实。7.4 前端图表数据多了卡顿怎么办如果你把整个景区历史的每天数据都在同一张折线图里展示数据量上万条时ECharts渲染会掉帧。解决办法是数据降采样后端查询时按周聚合返回每周平均值而不是每天的值。游客量按周聚合本身也有业务意义一周总量反映的趋势更平滑。具体SQL写GROUP BY YEARWEEK(visit_date)即可。当然如果你用到了前端大屏轮播或者缩放功能可以用ECharts的dataZoom组件先加载全量数据让用户自己缩放查看效果也更高级。7.5 模型文件越来越大部署到云服务器太慢Prophet模型的pkl文件通常有几MB到几十MB不等。如果你训练几十个景区总体积会很大上传到云服务器就比较痛苦。一个对策是在服务器上直接跑训练脚本不把模型文件从本地上传。换句话说把训练阶段放到服务器上的定时任务里每天凌晨自动更新模型本地只保留数据脚本。这个方案部署链路确实比上传模型复杂一些但生产环境绝大多数平台都是这么做的能体现你对“持续更新模型”这个工程问题的理解。8. 一些想补充给你的实操心得整篇文章写到这儿核心链路已经全部展开从数据清洗到Prophet训练从Flask接口到ECharts可视化再到Agent扩展已经是一个完整可落地的“基于时间序列的旅游数据预测平台”。最后说几句我在实际带项目过程中的体会。第一个心得是“先跑通再优化”。很多同学一开始就把目标定得很大又想做多模型对比又想做用户登录系统又想做权限管理结果三个月过去连一条预测曲线都没画出来。正确顺序是先用一份干净的数据把Prophet训练出来出图交给老师看再逐步加Flask接口、加页面、加扩展功能。最小可行版本MVP永远是第一优先级。第二个心得是“答辩时的演示脚本比论文更重要”。期末考试和答辩的时候最容易翻车的不是代码而是现场操作。预测接口返回太慢、前端图表没加载出来、模型文件路径在答辩机器上找不到——这些我都见过。建议答辩前一天在答辩用的电脑上完整跑一遍启动命令和页面操作流程确认所有依赖都装好了模型文件路径是相对路径而不是你开发机的绝对路径。第三个心得是“把项目讲成故事”。不要一上来就说“我用了Flask和Prophet”而是从问题出发“景区不知道未来会有多少游客导致周末排班困难、淡季资源浪费。所以我要做一个平台输入历史客流量自动给出未来预测并在可视化大屏上直观展示帮助决策者提前准备。”先把痛点说出来再讲技术方案再来展示预测效果。这样讲哪怕代码有一些不足老师对你的整体印象也会非常好。如果你后续还有时间可以考虑把平台往实时数据更新方向扩展每天早上定时抓取前一天实际客流自动追加到数据库再自动重训练模型。这个功能做成后整个系统就是一个真正能“自我进化”的预测平台含金量会再上一个台阶。先按这篇文章把基础版做扎实吧有问题随时回来交流。