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 可视化与前端方案的取舍
可视化部分，我用的是ECharts+Ajax的前后端分离方案，但这要看你自己的前端基础来定。
方案一：后端Jinja2模板渲染。把数据在Python里处理好，直接传给模板，用ECharts在页面中绘图。优点是代码量少，不用跨域，适合前端不太熟练的同学。
方案二：前后端分离。Vue或原生HTML+Ajax请求后端接口，后端返回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）：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | INT | 主键 |
| name | VARCHAR | 景区名称 |
| city | VARCHAR | 所在城市 |
| level | VARCHAR | 景区等级（5A/4A） |
| category | VARCHAR | 景区类型（自然/人文） |
游客量表（tourist_flow）：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | INT | 主键 |
| spot_id | INT | 关联景区ID |
| visit_date | DATE | 日期 |
| visitor_count | INT | 游客量 |
| weather | VARCHAR | 天气状况 |
| temperature | FLOAT | 平均气温 |
| is_holiday | TINYINT | 是否节假日 |
数据清洗的重点有三个方面。
第一，日期格式统一。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'] # 按景区筛选（示例取景区ID=1） df_spot = df[df['spot_id'] == 1][['ds', 'y']].sort_values('ds') # 构建并配置模型 model = Prophet( yearly_seasonality=True, # 年周期性：淡旺季 weekly_seasonality=True, # 周周期性：周末效应 daily_seasonality=False, # 游客量按天统计，无需日内季节 changepoint_prior_scale=0.1, # 趋势拐点灵活度 seasonality_prior_scale=8.0, # 季节项强度 holidays_prior_scale=8.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(periods=60) 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', index=False) 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, initial='365 days', period='30 days', horizon='90 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/spots | GET | 获取景区列表，下拉框用 |
| /api/history/<spot_id> | GET | 获取指定景区历史游客量 |
| /api/forecast/<spot_id> | GET | 获取指定景区预测数据 |
| /api/stats/summary | GET | 获取总览统计（总游客量、同比、环比） |
| /api/agent/query | POST | 大模型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', default=30, type=int) forecast_df = model.predict(model.make_future_dataframe(periods=days)) # 只返回日期和预测值，控制响应体积 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, days=30): key = (spot_id, days) if key not in cache: model = load_model(spot_id) forecast_df = model.predict(model.make_future_dataframe(periods=days)) 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}?days=30`) .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的意义在于展示你懂最新的技术趋势，又不会喧宾夺主——它只是一个扩展模块，基础平台仍然是Flask+Prophet。
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_ascii=False)}" 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_seasonality=True，而把yearly_seasonality=False，不然模型会把年周期拟合成一个极小值； - 检查
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”，而是从问题出发：“景区不知道未来会有多少游客，导致周末排班困难、淡季资源浪费。所以我要做一个平台，输入历史客流量，自动给出未来预测，并在可视化大屏上直观展示，帮助决策者提前准备。”先把痛点说出来，再讲技术方案，再来展示预测效果。这样讲，哪怕代码有一些不足，老师对你的整体印象也会非常好。
如果你后续还有时间，可以考虑把平台往实时数据更新方向扩展：每天早上定时抓取前一天实际客流，自动追加到数据库，再自动重训练模型。这个功能做成后，整个系统就是一个真正能“自我进化”的预测平台，含金量会再上一个台阶。先按这篇文章把基础版做扎实吧，有问题随时回来交流。
