这两年计算机毕设选题里旅游和景点相关的题目热度一直很高但很多同学做着做着就变成“展示景点信息的管理系统”核心的人流量预测反而成了摆设。Python景点人流量智能预测系统这类题目真正的主线是把Django后端、机器学习算法、数据可视化打通做成一套从数据到预测再到展示的完整闭环。这篇就把这套系统的设计思路、核心代码、踩坑点一次性讲透帮你从框架搭建到答辩都能拿得出手。1. 项目到底做什么选题定位与实用价值拆解1.1 这类系统的核心需求到底是什么景区人流量预测本质上是时间序列预测问题。系统通过历史的人流量数据结合日期特征节假日、星期几、月份、天气特征温度、降雨、风力、甚至是淡旺季因子训练出一个模型来计算未来某天或某个时段景区会有多少游客。这个需求在现实里是真实存在的。景区运营方需要提前预判人流高峰来安排安保力量、调配接驳车辆、做限流预警文旅管理部门需要根据流量数据做区域调度。所以这类题目天然有业务逻辑支撑不是凭空捏造的“作业系统”答辩时评委问“你这个东西有什么用”你完全可以给出落地场景。从毕设角度看这类题目的优势在于技术栈覆盖面广但深度可控。Django是web后端必备技能线性回归属于机器学习入门算法可视化用ECharts等图表库实现一个项目把大学四年主要课程都串联起来了。比起纯管理系统“只有增删改查没含金量”的尴尬处境这种带算法模块的项目会好答辩很多。1.2 为什么选线性回归而不是神经网络很多人在选题时纠结要不要上深度学习用LSTM预测时间序列是不是更“高级”我的建议是毕设阶段优先考虑线性回归。首先是可解释性问题线性回归的每个特征都有对应系数评委问“为什么工作日流量就低”你能直接说出“因为工作日特征项的权重是负的”换成神经网络黑盒模型很难讲清楚决策依据。其次是数据量问题深度学习需要海量数据训练大多数毕设拿到的景区数据就几百上千条这个量级喂给神经网络大概率过拟合。线性回归处理这类问题还有计算开销低的优势。训练时间秒级完成一台普通笔记本就能跑不用折腾GPU环境。而且在实际开发中先用线性回归做基线模型baseline是业界标准做法——如果最简单的模型效果都不差说明特征工程做得到位这是个不小的加分点。后面如果真的想升级可以把回归替换成Prophet、LightGBM甚至LSTM系统架构不用大改这就是“算法替换”的设计思想。1.3 适合谁学习和参考如果你是计算机、软件工程、数据科学相关专业的学生正处于毕设选题阶段或者想知道这类系统怎么实现这篇内容都可以给你一个相对完整的参考。文章会从技术架构、数据集构造、模型实现、可视化展示几个环节依次展开每一部分都会给出可直接跑的方案。我个人建议在读这篇文章的时候不要只看代码更要琢磨每一个设计决策背后的原因。比如为什么数据集要自己构造而不是去爬真实数据为什么模型要用均方误差做损失函数这些想明白了你答辩时的底气会完全不一样。2. 系统架构设计Django框架下的模块划分与数据流2.1 整体功能与目录结构这套系统的功能可以拆成四个大模块用户管理、数据管理、预测算法、可视化展示。用户管理走Django自带的认证体系扩展一个角色字段区分管理员和普通游客数据管理负责接收并存储历史入流量数据支持手动录入也可以批量导入CSV预测算法的核心是特征工程加线性回归模型通过接口接收请求返回预测结果可视化页面用ECharts渲染各类图表。项目的目录结构和命名建议这样设计scenic_flow/ ├── manage.py ├── requirements.txt ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── user/ # 用户模块 │ ├── data_manage/ # 流量数据管理 │ ├── prediction/ # 预测算法模块 │ └── dashboard/ # 可视化展示模块 ├── static/ │ ├── css/ │ ├── js/ │ └── echarts/ └── templates/ ├── base.html ├── login.html ├── dashboard.html └── data_manage.html用apps目录把业务拆分成独立应用是为了保证模块间低耦合。数据管理模块只管读写数据库预测模块只负责训练和推理两个之间通过数据模型传递信息。后期如果想换算法只需要修改prediction应用内部代码其他模块完全不用动。2.2 数据模型的字段设计流量数据表是整套系统的根基字段设计直接决定特征工程能不能顺利开展。我建议至少包含以下几项日期DateField记录流量对应的日期时段CharField一天分四个统计时段上午、中午、下午、晚间人流量IntegerField该时段的游客数量天气状况CharField晴/多云/小雨/大雨等枚举值温度FloatField当天平均气温是否节假日BooleanField标记当天是否是法定节假日有的同学会问天气数据怎么来的真实项目可以从天气API拉取历史数据毕设阶段可以用模拟数据替代。但字段类型一定要设计到位这就好比数据库的schema一旦定了后面再改就很麻烦。用户表直接用Django内置的AbstractUser扩展一个role字段就行没有太多特殊设计。管理员可以录入和修改流量数据普通用户只能查看。2.3 前后端数据交互的接口约定前后端分离已经是主流做法即使Django自带模板渲染也不建议把数据和HTML硬耦合在一起。我的做法是Django端提供JSON接口前端用Ajax拉取数据渲染交给ECharts。这里给出一个典型的JSON响应结构{ code: 0, msg: success, data: { date: 2024-04-15, predicted_flow: 15820, actual_flow: null, confidence_interval: [14300, 17340] } }统一code/msg/data三层的响应格式是为了让前端异常处理逻辑清晰。查询成功返回code0参数错误返回code400模型未训练完成返回code500。前端拿到非0的code直接弹出错误提示不用关心具体业务逻辑。接口设计遵循RESTful风格主要接口如下GET /api/flow/history?days30获取最近30天的景区人流量历史数据POST /api/flow/create新增一条景区人流量记录GET /api/predict/next_day预测明天分时段人流量POST /api/predict/date预测指定日期的人流量GET /api/statistics/overview获取可视化大屏所需的统计数据2.4 Django ORM查询的优化细节写这类系统的后端接口时最容易被忽略的就是ORM查询性能。流量数据表一旦积累到几千条遍历查询就会变慢。推荐做法是视图函数里只查当前视图需要的数据不要一次性把所有字段都加载进来用only()或values()限定字段需要对日期做分组统计时直接用Django的TruncDate配合annotate完成数据库层面的聚合而不是把数据全捞到Python内存再处理。from django.db.models.functions import TruncDate from django.db.models import Sum daily_flow ( FlowRecord.objects .filter(date__gtestart_date) .annotate(dayTruncDate(date)) .values(day) .annotate(totalSum(visitor_count)) .order_by(day) )这段代码查询出按天分组的总人流量整个过程发生在数据库端性能比逐条加载高效得多。3. 机器学习核心线性回归模型的原理、实现与优化3.1 线性回归模型的数学原理线性回归的基本假设是目标变量和特征变量之间存在线性关系。放在景点人流量这个场景里要预测的就是当天的总流量特征变量可能有星期几、是否节假日、平均温度、上月同期流量等。模型表达式就是y w1*x1 w2*x2 ... wn*xn b其中w1到wn就是每个特征的权重b是偏置项。训练的过程就是找到一组权重让预测值和真实值之间的误差最小。这里用到的损失函数叫均方误差MSEMSE (1/n) * Σ(y_true - y_pred)^2为什么用MSE而不是绝对误差因为MSE在误差大时产生的梯度也大反向传播时能更快速地修正权重的方向收敛更快。另一方面MSE在误差为0处是可导的方便使用梯度下降法求解。3.2 特征工程是模型效果的分水岭线性回归模型本身很简单它的上限完全取决于特征做得好不好。同样一份数据有人把日期直接丢进去训练出来的模型$R^2$可能只有0.2有人做了完整的特征工程$R^2$可以到0.8以上。这就是经验差距所在。我的特征工程方案是这样做的从原始数据中衍生出这些特征星期几0到6。景区人流量有很强的周周期性周一少、周末多是否周末0或1。在星期几的基础上再强化一下是否节假日0或1。法定节假日是流量暴增的主要因子月份1到12。旅游淡旺季的区分温度。对自然风景区影响很大天气评分。把晴、多云、阴、小雨、大雨映射为5、4、3、2、1分前一日的流量。时序数据里昨天的流量和今天通常高度相关这些特征组合在一起组成了模型进入训练前最终的特征矩阵。要注意的是类别特征不能直接当作数字喂给线性回归比如天气的“晴”“多云”是类别不能映射时用5、4、3这种有序整数吗可以映射但这种做法隐含了一个假设晴到多云的“距离”和多云到阴的“距离”是相等的。这个假设不完全成立时就需要用独热编码One-Hot Encoding。但在毕设级别的项目里天气映射成有序整数通常效果不差而且保持特征维度小。3.3 训练集与验证集划分的注意事项毕设里最常见的错误就是直接用全部数据训练模型然后用同一份数据算精度。这在学术上叫数据泄漏结果虚高答辩时评委问你泛化能力的时候会露馅。正确的做法是拿最近20%的数据做验证集前80%做训练集。原因很简单时间序列数据的训练集必须是验证集之前的数据不能随机打乱——预测未来你用未来的数据训练这个逻辑本身就说不通。下面是模型训练核心代码建议搭一个独立的model_service.py文件不要让训练逻辑散落在视图函数里import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.preprocessing import StandardScaler from sklearn.metrics import mean_squared_error, r2_score import joblib def train_flow_model(df): # df包含原始流量记录date, visitor_count, is_holiday, weather_score, temperature等字段 # 构造特征 df[date] pd.to_datetime(df[date]) df[weekday] df[date].dt.weekday df[is_weekend] df[weekday].apply(lambda x: 1 if x 5 else 0) df[month] df[date].dt.month df[prev_day_flow] df[visitor_count].shift(1) # 去掉缺失行 df df.dropna() features [weekday, is_weekend, is_holiday, weather_score, temperature, month, prev_day_flow] X df[features] y df[visitor_count] train_size int(len(df) * 0.8) X_train, X_test X.iloc[:train_size], X.iloc[train_size:] y_train, y_test y.iloc[:train_size], y.iloc[train_size:] model LinearRegression() model.fit(X_train, y_train) y_pred model.predict(X_test) mse mean_squared_error(y_test, y_pred) r2 r2_score(y_test, y_pred) # 保存权重文件和模型方便后续加载 joblib.dump(model, flow_model.pkl) return model, mse, r2有同学会问train_test_split不是自带shuffle参数吗我是不是直接shuffleFalse就行也可以但直接按位置切片更直观一眼就能看出前80%是训练集、后20%是测试集答辩的时候讲起来也清晰。3.4 从Sklearn切换到Statsmodels做统计分析如果你的答辩老师比较较真会追问“你的模型系数有什么统计学意义”这时候只跑Sklearn就不够看了。建议你额外用statsmodels库跑一遍同样的线性回归它会输出每个特征的p值和置信区间。特征p值如果大于0.05说明这个特征对目标变量的影响不显著你就可以解释说“我基于统计显著性筛选了核心特征”。这个方法在毕设里是很有辨识度的亮点大部分学生只会调包你如果会说“我通过p值剔除了不显著特征”在答辩时给人感觉专业很多。import statsmodels.api as sm X_const sm.add_constant(X_train) # 添加截距项 sm_model sm.OLS(y_train, X_const).fit() print(sm_model.summary())3.5 数据集构造从模拟数据到真实数据真实景区的流量数据并不容易获取有很多景区根本不会对外公开历史客流数据。与其去爬那些不完整的公开数据不如自己构造一套基于真实分布规律的模拟数据——这样做的另一个好处是你可以完全控制趋势变化验证模型是否学到了你设计的模式。构造模拟数据的逻辑也很简单先设计一个基础函数包含年度季节性5月到10月旺季高12月到2月淡季低、周周期性周末高工作日低、节假日暴涨五一、国庆翻2到3倍再叠加受天气影响的随机浮动。最后加一点随机噪声模拟真实波动。import pandas as pd import numpy as np from datetime import datetime, timedelta def generate_synthetic_data(start_date, end_date): date_list [] flow_list [] np.random.seed(42) for d in pd.date_range(start_date, end_date): month d.month # 基础流量7-8月暑假旺季11-12月淡季 season_factor 1.2 if month in [7, 8] else 0.7 if month in [11, 12] else 1.0 # 周末效应周五到周日流量高于工作日 weekday_factor 1.3 if d.weekday() 4 else 0.85 # 节假日效应 holiday_factor 1.8 if d in pd.to_datetime([2024-10-01, 2024-10-02, 2024-10-03]) else 1.0 base_flow 8000 * season_factor * weekday_factor * holiday_factor # 加入天气扰动和随机噪声 weather_effect np.random.uniform(0.85, 1.1) noise np.random.normal(0, 500, 1)[0] flow max(500, int(base_flow * weather_effect noise)) date_list.append(d) flow_list.append(flow) df pd.DataFrame({date: date_list, visitor_count: flow_list}) return df这种构造方法背后的逻辑是你在给模型“出题”的时候就已经埋好了答案如果特征因子都设置到位模型理应在验证集上表现不错如果你的特征工程缺失了某个关键因子比如忘了节假日那你就能直观地看到预测误差集中出现在节假日附近——排查问题的线索一下就清楚了。4. 可视化大屏的实现从数据到图表的最佳实践4.1 可视化模块的设计原则景区人流量预测系统的可视化部分核心目标是让观者一眼看懂三个问题历史流量走势如何模型预测值是多少历史预测和真实流量的偏差多大。切忌一股脑儿堆图表每张图表都要有明确的信息承载任务。我建议的可视化大屏布局是顶部区域放总览卡片显示今日实时流量、明日预测流量、本周日均流量和本月累计流量中间主体区域放本周流量趋势折线图同时叠加预测值和真实值的双线对比右侧放时段分布热力图展示一天四个时段上午、中午、下午、晚间的流量分布底部放节假日效应柱状图对比2024年各节假日的流量差异。4.2 Django视图传递JSON数据给ECharts先说后端怎么组织数据。预测模块训练出的模型文件flow_model.pkl在Django启动时懒加载——第一次调用预测接口时加载模型后续直接复用。视图函数大体长这样import json import joblib from django.http import JsonResponse from django.views.decorators.http import require_GET from .model_service import prepare_features, build_next_day_features _model None def get_model(): global _model if _model is None: _model joblib.load(prediction/flow_model.pkl) return _model require_GET def predict_next_day(request): model get_model() # 构造明天的特征今天日期加1天 tomorrow datetime.now() timedelta(days1) features build_next_day_features(tomorrow) pred_value model.predict([features])[0] pred_value int(round(pred_value)) return JsonResponse({ code: 0, data: { date: tomorrow.strftime(%Y-%m-%d), predicted_flow: pred_value } })前端用JavaScript获取接口数据并渲染。下面是ECharts折线图的关键部分$.getJSON(/api/predict/next_day, function (res) { if (res.code 0) { // 更新预测卡片 $(#predictedFlow).text(res.data.predicted_flow.toLocaleString()); // 刷新趋势图 trendChart.setOption({ series: [{ data: res.data.trend_data }] }); } else { toast.error(获取预测数据失败 res.msg); } });需要注意的是ECharts的setOption默认是值替换模式直接重新赋值时旧数据会丢掉。如果希望保持动画过渡效果要在设置之前加上trendChart.clear()或者使用merge: true参数。这个细节看起来小但实际图表显示异常时很多同学会一头雾水。4.3 核心图表的配置要点折线图适合趋势展示但要注意两个细节。第一数据点标签不要全显示否则数据一多图上密密麻麻全是数字非常劝退。我用label: { show: false }隐藏标签只在鼠标悬浮时通过tooltip展示具体数值。第二x轴数据如果太密集一定要加dataZoom组件支持拖拽缩放这是大数据可视化最基本的交互能力。热力图用ECharts的heatmap系列实现。x轴放日期y轴放时段上午、中午、下午、晚间色块颜色从浅蓝到深红渐变直观看出哪几天哪个时段是客流高峰。这里有个小坑ECharts热力图的数据格式是[x, y, value]三元组x和y需要是索引数字而不是字符串所以后台要把日期和时段先map成索引或者在前端做一次转换否则图表会空白。4.4 大屏适配与小屏兼容的处理毕业设计演示时很多同学是在自己的笔记本上进行的屏幕小、分辨率不确定。如果可视化页面按固定像素写死换一台电脑就会错位。我的做法是页面容器使用百分比布局ECharts实例初始化时读取容器宽度同时监听window的resize事件。window.addEventListener(resize, function () { trendChart.resize(); heatmapChart.resize(); });如果时间允许建议用rem单位做字体适配让整体大屏在不同尺寸的屏幕上保持视觉比例。实测下来1680和1920宽度的显示器上效果都还可以。5. 完整实操过程从环境搭建到跑通第一版预测5.1 环境准备与依赖安装先把运行环境交代清楚。Python版本建议用3.9或3.10新版3.12偶尔有依赖包还没适配的情况没必要冒险。用virtualenv或者conda建一个独立环境再安装依赖pip install django4.2 pip install pandas numpy scikit-learn matplotlib pip install statsmodels joblib pip install requests关于版本Django 4.2是目前比较稳妥的长线支持版本和Python 3.10搭配没有兼容问题。数据库直接用Django默认的SQLite就行几千条记录完全够用不要过度设计去上MySQL给自己增加部署负担。5.2 创建项目和应用目录django-admin startproject scenic_flow cd scenic_flow python manage.py startapp user python manage.py startapp data_manage python manage.py startapp prediction python manage.py startapp dashboard创建完成后在settings.py里的INSTALLED_APPS注册四个应用顺带配一下模板路径和静态文件路径。到这里基本的项目框架就搭起来了。5.3 定义数据模型并迁移数据库数据模型的完整代码建议这样的字段设计from django.db import models class FlowRecord(models.Model): date models.DateField(verbose_name日期) period models.CharField(max_length10, choices[ (morning, 上午), (noon, 中午), (afternoon, 下午), (evening, 晚间) ], verbose_name时段) visitor_count models.IntegerField(verbose_name人流量) weather models.CharField(max_length10, verbose_name天气) temperature models.FloatField(verbose_name温度) is_holiday models.BooleanField(defaultFalse, verbose_name是否节假日) class Meta: db_table flow_record ordering [date, period]定义好之后运行python manage.py makemigrations python manage.py migrate5.4 编写数据导入脚本系统上线后管理员可以在页面上手动录入数据但开发测试阶段一条条录效率太低。写一个management command批量导入CSVfrom django.core.management.base import BaseCommand from data_manage.models import FlowRecord import csv class Command(BaseCommand): help 批量导入人流量CSV数据 def add_arguments(self, parser): parser.add_argument(csv_file, typestr) def handle(self, *args, **kwargs): with open(kwargs[csv_file], r, encodingutf-8) as f: reader csv.DictReader(f) count 0 for row in reader: FlowRecord.objects.create( daterow[date], periodrow[period], visitor_countint(row[visitor_count]), weatherrow[weather], temperaturefloat(row[temperature]), is_holidayrow[is_holiday] 1 ) count 1 self.stdout.write(self.style.SUCCESS(f导入成功{count} 条))执行方式python manage.py import_flow_data path/to/flow_data.csv。5.5 模拟数据生成与模型训练接口为了让系统在演示时有数据可跑我写了一个generate_demo_data的管理命令内部调用之前那个generate_synthetic_data函数生成365天的流量数据并写入数据库。然后用Django的ping命令触发训练或者直接在管理后台加一个“训练模型”按钮点击后调用train_flow_model并展示MSE和$R^2$指标。一个值得注意的点是这些管理命令本身就是很好的演示素材。答辩时可以现场跑一遍命令看到生成数据和训练输出的整个日志过程比单纯对着已经生成好的界面讲更有说服力。6. 常见问题与避坑指南6.1 时间序列数据泄漏问题在写码过程中我最常看到的问题是同学直接用train_test_split(X, y, test_size0.2)而不加shuffleFalse。Sklearn里的train_test_split默认会打乱数据用在时间序列上就是灾难——训练集里有未来数据验证集里有过去数据模型是在“作弊”。判断方法很简单训练完成后打印验证集预测值和真实值的对比表如果误差极小比如几十以内而训练集误差也差不多你就要警觉是不是数据泄漏了。一旦确认立即改成按时间切分的方式。6.2 特征尺度不一致影响模型效果温度动辄30多度星期几只有0到6这些特征量纲差异巨大。线性回归内部计算时量纲大的特征会对损失函数产生不成比例的影响梯度下降会比较震荡。必须做标准化处理。scaler StandardScaler() X_train_scaled scaler.fit_transform(X_train) X_test_scaled scaler.transform(X_test)注意fit的标准scaler是只在训练集上拟合的测试集只调用transform不能重新fit。否则测试集的均值方差参与计算又是一种信息泄漏。在模型保存时要连scaler一起保存。这样才能保证web接口在接收到新数据特征时用同一套标准化参数处理。6.3 Django更新数据后模型没重新训练的bug系统在开发测试阶段你会频繁改模拟数据或者补充真实数据。如果模型只在第一次启动时训练一次之后新增的数据永远不会被学习到预测结果始终是旧模型给出的。解决方案是在数据管理后台的“新增记录”操作里加一个异步训练触发器。数据量小的时候直接同步调train_flow_model就行不过要注意给线程加锁否则多个请求同时触发训练会写出脏数据。数据量大时可以用Django-Celery做异步任务队列。6.4 节假日特征提取的边界坑判断某天是不是节假日绝对不能只靠周末判断。五一、国庆、春节这种长假期间工作日的流量可能比普通周末还高。我建议在模拟数据生成时显式指定节假日列表而不是靠爬虫或者硬编码。如果你希望更通用可以使用chinese_calendar这个库它内置了每年的法定节假日安排包括调休上班日一行代码就能判断import chinese_calendar def is_legal_holiday(dt): if chinese_calendar.is_holiday(dt): return True if chinese_calendar.is_workday(dt): return False return False # 非工作日但也非法定假日一般是普通周末6.5 模型泛化能力不足的补救如果验证集$R^2$只有0.3左右先不要急着换模型按顺序排查这三件事特征是否完整覆盖了已知的流量影响因素节假日有没有进来天气有没有进来数据是否有明显的异常值比如某天因为景区关闭流量为0这种记录要剔除训练集和验证集划分是否合理前80%和后20%的数据分布是否差异过大比如验证集刚好覆盖了黄金周。如果排查完还是不行这时候才考虑升级算法。建议按这个顺序尝试先加多项式特征PolynomialFeatures再试随机森林回归最后才上Prophet或LSTM。毕设不需要一步到位能证明你具备完整的优化思路就够了。7. 扩展升级从毕业设计到可落地的智能预测系统7.1 从线性回归到Prophet和LightGBM如果你的题目带有“大数据”或“大模型”关键词或者你希望在项目中展示更多算法对比建议在现有线性回归基础上增加一个对比实验模块。我实测过的方案是Facebook Prophet它对节假日建模非常友好自带节假日和季节性组件在处理时间序列预测方面几乎是为这个场景量身定制的。Prophet的使用方式不多展开核心思路是把数据构造成ds日期和y流量两列然后调用Prophet().fit(df)一行代码完成训练。如果你在论文里准备写“本文对比了线性回归和Prophet模型的预测效果”那现有的架构几乎不需要改动只要在prediction应用里加一个新的service文件就可以。LightGBM这类树模型也可以考虑它处理非线性交互特征能力更强但对时间序列的外推预测不一定比线性模型好需要实际对比。7.2 引入多维数据源的接入设计真实景区人流预测还会考虑更多数据景区门票预约量、酒店入住率、周边交通拥堵指数、历史同期数据、网络搜索热度。如果后续要做改进可以考虑在模型的特征矩阵里增加这些变量然后把数据源接入模块单独抽象出来统一走接口拉取。这样做的好处是你的系统从“单一历史数据预测”变成了“多源数据融合预测”在技术难度和业务价值两个维度上同时提升。毕设里可以做一个模拟数据源管理页面用表单配置外部数据源的地址和更新频率。7.3 从人流量预测到区域承载预警另一个值得扩展的方向是预测结果的分级预警。将预测值映射到景区承载率区间——绿色承载率低于60%、黄色60%到85%、红色超过85%。当预测流量超过阈值时系统自动向管理员推送预警消息页面上也会高亮显示。实现本身并不复杂在预测接口返回的数据里加一个alert_level字段就行。关键是这个功能把预测结果和景区安全管理实际业务串联起来答辩时讲“我不仅预测了流量还对接了管理决策”是一个很加分的叙事。8. 实操体验这套系统的运行效果与个人心得全部模块写完后跑起来的效果大概是这样的登录系统进入可视化大屏顶部显示出本周的预测流量数字折线图上真实流量和预测流量两条曲线基本贴合在节假日附近有明显抖动。切换不同日期范围趋势图和数据卡片会同步刷新。我印象比较深的是节假日预测的偏差调整环节。最初版本的模型没有把“五一前两天”这种节前效应考虑进去结果4月30日这种日期预测值明显偏低。后来在特征里加了“距最近节假日天数”这个变量误差立刻降了一截。这类细节才是真正体现算法调优能力的地方也是答辩时可以细讲的故事。还有个体会是管理命令在调试中的价值。我习惯把所有耗时操作都写成management command比如导入数据、训练模型、生成演示数据这样不仅能自动化测试而且每当需求变化时只需要在原有命令上增加参数不用到处修改页面入口。这套工作习惯同样适用于以后的企业开发。最后提个建议代码里所有注释都写清楚为什么这么做而不是“这一段实现什么功能”。深层次的注释对后续代码维护的帮助会大很多。答辩时你可以理直气壮地说“我不只写出来了我还知道自己每一步为什么这么写。”这才是计算机毕业设计最应该达到的高度。