机器学习天气预测实战：特征工程、时间序列评估与可视化全解析

简介：一份面向课程设计与期末大作业的Python机器学习天气预测与数据可视化完整源码，适合已有基础Python知识的学生参考与复用。项目从天气数据获取、清洗与特征处理，到模型训练、预测评估与图表可视化形成完整链路，代码内含详细注释，安装依赖后简单部署即可运行；整体功能模块完整，操作界面直观，管理便捷，具备较高的实际应用价值。资源包共24个文件，主要包含4个Python源码脚本（爬虫获取、数据预处理、模型训练与主程序入口）、4份CSV训练与测试数据、训练好的模型pkl文件、HTML天气数据页面、12张效果截图及说明文档，压缩包大小约1.42MB，目录组织清晰，便于按模块对照学习。目前已有409人学习下载，可直接作为高分大作业的完整方案，也可借助其中的爬虫、预处理与可视化代码快速搭建同类预测项目；各模块之间通过清晰的目录结构相互衔接，方便二次开发。

1. 天气预测这个“满分项目”，难点从来不在模型

用 Python 做机器学习天气预测，再配上数据可视化面板，这几乎是课程设计里最经典的“满分项目”类型。但真正把这类项目做完的人都会有个共识：难点不在模型选得多深，而在三件事——观测数据怎么整理成监督学习样本、时间序列的验证方式是否严谨、预测结果能不能用图表把话说清楚。很多人把天气数据丢进随机森林跑出一个 MAE 就收工，结果答辩时被问一句“你这个预测是不是用了未来数据”就直接翻车。本文按一套完整源码的落地路径，把数据清洗、特征工程、模型选型、多步评估和可视化逐段讲透，适合零基础起步的学生，也适合想用公开气象数据练手的数据工程师。

2. 天气预测的数据从哪来：把气象观测整理成监督学习样本

先说一个关键认知：天气预测本质上是回归问题，不是“时序预测问题”。机器学习库里的回归模型不认识时间戳，它们只认表格——每一行是某一天的气象观测，每一列是一个特征，你要预测的那一列叫目标变量。所以整个项目的第一步，是把逐日或逐小时的气象观测记录，重构成一张X -> y的监督学习表。这一步做不好，后面所有模型都是在垃圾上跳舞。

一套完整的天气预测源码里，数据管线通常占掉一半的工作量。它一般由四个模块组成：数据获取、清洗对齐、特征构造、样本切分。下面从数据来源和清洗讲起。

2.1 先明确任务：预测温度是回归，预测降水是分类

拿到气象数据后，第一件事不是写模型，而是决定“预测什么”。最常见的两个任务：

• 预测明后天的平均气温：这是回归任务，目标变量是连续值，评估用 MAE / RMSE。
• 预测明天下不下雨：这是二分类任务，目标变量是 0/1，评估用准确率、F1 或 AUC。

两者在特征工程上的思路几乎一样，差别只在目标变量和损失函数。本文以“预测未来 1 到 7 天的日平均气温”为主线展开，因为连续值回归更容易暴露评估上的坑，也更适合做可视化。

千万不要一上来就预测“降水的具体毫米数”。降水分布极度偏斜，晴天占大多数，直接回归会得到一个“永远预测无雨”的模型，而且 MAE 看起来还很小，极具欺骗性。如果项目要求包含降水，建议退化成晴雨分类，或者把降水量取对数后再回归。

2.2 数据来源与核心字段：选择比清洗更重要

气象数据的获取有几个常见渠道：本地气象站自采数据、公开数据集、以及用爬虫抓公开天气接口。公开数据集通常包含逐小时或逐日的气象要素，字段比较规整。这里不纠结具体来源，关键是选对字段。做气温预测，核心字段一张表就能说清楚：

选字段的原则是“宁可少而干净，不要多而残缺”。理想的数据长度是连续 3 年以上，因为要构造滞后 7 天的特征，一年以内的数据会让滞后特征大量缺失。如果数据量少于 500 天，后面提到的 LightGBM 和 LSTM 都不太建议上，老老实实用线性模型加少量滞后特征更稳。

2.3 最小可复现：加载、清洗与第一张可视化图

拿到原始 CSV 后，先做三件事：解析日期、按时间排序、处理缺失值。缺失值处理是气象数据里最烦的一步，常见三类情况：目标变量缺失、单字段偶发缺失、连续多日整段缺失。下面这份代码是能直接跑通的最小清洗逻辑：

import pandas as pd import numpy as np import matplotlib.pyplot as plt # 假设你已经导出了逐日气象观测 CSV，字段名按下表对齐 df = pd.read_csv("weather_station_daily.csv", parse_dates=["date"]) df = df.sort_values("date").reset_index(drop=True) # 只保留建模需要的字段，过滤掉质量标记等冗余列 keep_cols = ["date", "temp_mean", "temp_max", "temp_min", "humidity", "pressure", "wind_speed", "precipitation"] df = df[keep_cols].copy() # 目标变量不允许留空：直接删行 df = df.dropna(subset=["temp_mean"]) # 湿度偶发缺失：用线性插值补，方向设为双向，避免开头结尾仍为空 df["humidity"] = df["humidity"].interpolate(limit_direction="both") # 气压连续多日缺失：用 7 天滑动均值填充，比直接删行更稳 df["pressure"] = df["pressure"].fillna( df["pressure"].rolling(7, min_periods=1).mean() ) # 画出目标变量的时间序列，先判断是否平稳、有没有明显的年周期 fig, ax = plt.subplots(figsize=(12, 4)) ax.plot(df["date"], df["temp_mean"], lw=0.8, color="#2b6cb0") ax.set_title("Daily Mean Temperature") ax.set_xlabel("date") ax.set_ylabel("temp_mean (C)") plt.tight_layout() plt.savefig("01_raw_series.png", dpi=150)

这段代码做了什么：先按日期排序，这是时间序列建模的前提——索引乱序会让后续的滞后特征全部失效。keep_cols保留了八列核心字段，去掉了站点编号、观测质量标记这类对预测无直接作用的列。

参数说明里有几个值得注意的点。interpolate(limit_direction="both")解决的是“首尾缺失”问题，默认的线性插值只填充中间部分，首尾会留下 NaN，如果不加这个参数，后续建模时这些行会被直接丢光。rolling(7, min_periods=1)的窗口大小不是拍脑袋定的，气象上气压的短周期波动大约是 3 到 7 天，7 天均值能抹平短波又不会过度平滑。min_periods=1表示窗口内至少有 1 个有效值就参与计算，这是为了让开头 6 天不因为窗口不足而消失。

做完这一步，你就有了一个干净的、按时间排序的 DataFrame。下一章要做的，是把这张“宽表”变成机器学习能直接吃的“特征表”。

3. 特征工程与模型选型：滞回特征、随机森林与 LightGBM 的取舍

数据清洗完，第二个大坑来了：气象观测是天然的时间序列，但 sklearn 和 LightGBM 的模型接口只认“每一行独立”的表格数据。如果你直接把“今天的湿度、气压、风速”作为特征去预测“明天的气温”，模型完全不知道昨天发生了什么。所以特征工程的核心任务是：把历史信息显式地编码进当前行。

这一章同时解决两个问题：特征怎么造，模型怎么选。这两个问题其实是绑定的——你用滞后特征，模型就具备了时间记忆能力；你选树模型还是线性模型，取决于特征和目标的真实关系长什么样。

3.1 核心特征：滞后值、滚动窗口与周期编码

天气预测特征工程有三板斧：滞后特征、滚动统计特征、周期编码。三者的作用各不相同。

滞后特征是最重要的一类。所谓lag_k，就是“k 天前”的目标值。比如lag_1是昨天的平均气温，lag_7是上周同一天的平均气温。为什么 lag_7 重要？因为气温有很强的星期效应和天气过程周期，7 天前的气温对今天有参考意义。

滚动统计特征描述的是“最近一段时间的状态”。比如最近 3 天的平均气温、气温标准差。标准差能反映天气是否剧烈波动，这在预测转折天气时很有用。

周期编码处理的是季节性。直接丢一个“月份”整数特征给树模型，模型会把 12 月和 1 月当成完全无关的两个数，但实际气温在 12 月到 1 月是平滑过渡的。常见做法是构造dayofyear的正弦和余弦值，把“一年的第几天”映射到圆上，让 1 月 1 日和 12 月 31 日在编码上相邻。

下面这个make_features函数是完整源码里的核心模块，直接粘贴可用：

def make_features(df, target="temp_mean", lags=(1, 2, 3, 7), win=3): """把时间序列 DataFrame 转成监督学习特征表。""" out = df.copy() # 滞后特征：用目标变量过去的值作为当前特征 for lag in lags: out[f"lag_{lag}"] = out[target].shift(lag) # 滚动特征：必须先 shift 再 rolling，否则会混入当天数据 out["rolling_mean"] = out[target].shift(1).rolling(win).mean() out["rolling_std"] = out[target].shift(1).rolling(win).std() # 周期编码：dayofyear 的 sin/cos，建模季节性平滑过渡 dayofyear = out["date"].dt.dayofyear out["season_sin"] = np.sin(2 * np.pi * dayofyear / 365) out["season_cos"] = np.cos(2 * np.pi * dayofyear / 365) # 差分特征：前一天到今天的温度变化，描述趋势惯性 out["diff_1"] = out[target].diff(1) # 删除前几行：滞后/滚动特征在序列开头必然是 NaN return out.dropna().reset_index(drop=True) feat = make_features(df) print(feat.shape, feat.columns.tolist())

这段代码里最需要强调的是一个细节：rolling统计之前先做了shift(1)。这个顺序极其重要——如果不 shift，rolling_mean会包含“今天”的目标值，相当于让模型偷看了今天答案去预测明天，训练时 MAE 会低得离谱，上线后立刻崩溃。这是时间序列特征工程里最高频的翻车原因。

win=3是滚动窗口大小，表示用“昨天、前天、大前天”三天来做平均。窗口可以调，但别超过 7——窗口越大，特征对短期变化的响应越迟钝。lags=(1,2,3,7)意味着同时保留昨天、前天、三天前和一周前的温度，这四个滞回值基本覆盖了短期惯性、近期趋势和星期周期三个信息维度。

3.2 模型选型三档：先跑基线，再上树模型

特征表做好之后，模型选择遵循一个原则：先跑简单的，再跑强的。下面这张表是实践中一轮轮筛出来的经验之谈：

天气预测的真实规律是：温度变化高度依赖昨天、前天的状态，这个关系是强非线性的（冷锋过境、晴空辐射冷却），所以岭回归只能作为“下限检验器”。如果岭回归的 MAE 比随机森林还好，说明你的特征工程有问题，大概率是泄漏了未来信息，而不是模型越简单越好。

随机森林和 LightGBM 之间，我一般先用随机森林打底，因为它对超参数不敏感，不需要归一化，几百棵树跑出来就是一个能看的成绩。等随机森林的误差稳定了，再换 LightGBM 去压榨最后的零点几度。

3.3 用 TimeSeriesSplit 训练与验证：别让 shuffle 毁掉一切

模型训练的代码其实很简单，难的是验证方式。很多人在这一步用train_test_split(random_state=42)，这是时间序列项目里最典型的错误——随机切分会让训练集里混入“未来”的数据，模型相当于穿越回去做了预测。

正确做法是用TimeSeriesSplit，它按时间顺序切分训练集和验证集，验证集永远在训练集之后。切分时再留一个gap，避免训练集末尾和验证集开头因为滞后特征而产生信息重叠：

from sklearn.ensemble import RandomForestRegressor from sklearn.model_selection import TimeSeriesSplit, cross_val_score # 特征列：排除 date 和 target 本身 feature_cols = [c for c in feat.columns if c not in ("date", "temp_mean")] X = feat[feature_cols] y = feat["temp_mean"] # 5 折时间序列验证，gap=7 防止滞后特征跨切分点泄漏 tscv = TimeSeriesSplit(n_splits=5, gap=7) model = RandomForestRegressor( n_estimators=200, max_depth=10, min_samples_leaf=3, random_state=42 ) # scoring 用负 MAE，因为 cross_val_score 的约定是“越大越好” scores = cross_val_score(model, X, y, cv=tscv, scoring="neg_mean_absolute_error") print("MAE:", -scores.mean())

这段代码的核心逻辑在于TimeSeriesSplit(n_splits=5, gap=7)。n_splits=5表示把数据按时间切成 5 段，每次用前 4 段训练、最后 1 段验证；gap=7的意义是训练集末尾和验证集开头空出 7 天，否则验证集第一天的lag_7特征会引用训练集最后一天的目标值，造成轻微泄漏。

参数选择上，max_depth=10和min_samples_leaf=3是一组保守值：树太深容易记住训练集的偶然波动，min_samples_leaf强制每片叶子至少有 3 个样本，起正则化作用。n_estimators=200对日级数据足够，再多只是增加训练时间，精度提升很有限。

4. 多步预测的评估：滚动验证、MAE 与三个必调参数

很多人做完上面的单步验证就觉得项目完成了。但天气预测在真实场景里要回答的问题不是“明天多少度”，而是“未来七天每天多少度”。单步验证的 MAE 是 1.5 度，不代表第七天的预测误差还是 1.5 度，误差会随预测步长累积。这章解决两件事：怎么正确评估多步预测，以及哪些参数最值得调。

4.1 单步与多步：评估策略先想清楚

单步评估的实质是“用已有的历史数据，只预测下一天”，每一步都用真实值做特征。这在技术竞赛里很常见，因为它实现简单、误差可控。但它的结果是乐观的——真实使用中你没有“明天的真实温度”来更新特征，只能把预测值喂回模型继续往下推。

所以完整的源码里，评估模块应该包含两套指标：单步 MAE 和多步滚动 MAE。多步评估才能真正反映模型在“预报员”岗位上的水平。两者差距越大，说明模型对历史信息的依赖越强，也就是模型越“不敢”做长期预测。

4.2 递归多步预测：六行代码看清误差累积

多步预测最直接的实现是递归法：预测出明天，把明天的预测值写回滞后特征，再预测后天。下面的代码演示的就是这个过程：

def recursive_forecast(model, feat_df, feature_cols, target="temp_mean", horizon=7): """递归多步预测：预测值写回目标列，重算滞后特征。""" df_work = feat_df.copy() preds = [] for _ in range(horizon): # 取最后一行作为当前输入 X_last = df_work[feature_cols].iloc[[-1]] p = model.predict(X_last)[0] preds.append(p) # 把预测值追加到目标列末尾，重算所有滞后特征 next_idx = df_work.index[-1] + 1 df_work.loc[next_idx, target] = p df_work.loc[next_idx, "date"] = df_work.loc[next_idx - 1, "date"] + pd.Timedelta(days=1) df_work["lag_1"] = df_work[target].shift(1) df_work["lag_2"] = df_work[target].shift(2) df_work["lag_3"] = df_work[target].shift(3) df_work["lag_7"] = df_work[target].shift(7) return preds # 用训练好的模型做未来 7 天递归预测 future_preds = recursive_forecast( model, feat.tail(30), feature_cols, horizon=7 ) print("未来 7 天预测温度：", [round(v, 1) for v in future_preds])

这段代码的逻辑链是：每一轮先拿当前窗口的最后一行做预测，得到的预测值p并不立即输出，而是写入目标列的新行，然后重算所有lag特征。下一轮迭代时，lag_1用的已经是上一轮的预测值，而不是真实历史值——真实场景里没有后悔药，预测错了也要继续往下推。

这里有个容易困惑的点：为什么只用feat.tail(30)而不传全量数据？因为递归预测只需要最近 7 行历史来填满lag_7，30 行是余量，防止特征计算时出现边界空值。实际封装时把这段逻辑放进独立的predict_future.py模块，和训练模块分开，是完整源码的标准结构。

4.3 三个必调参数：误差不降时先动这些

如果你的模型跑完，MAE 卡在一个不上不下的位置，调参别漫无目的地瞎试，优先动下面三个参数。

第一个是滞后窗口lags。默认(1,2,3,7)是对日平均气温的稳妥选择。如果预测目标是“最高温”，建议把 lag_1 换成temp_max_lag_1，否则模型会因目标变量和自己历史值的错位而多出一截误差。第二个是滚动窗口win。它对趋势型天气敏感，如果在春秋季换季时误差特别大，把win从 3 调到 5 通常能吸收一部分天气过程的惯性。第三个是树模型的max_depth。随机森林里深度从 10 调到 15，误差可能下降，但超过 18 后基本只会过拟合。

调参时记住一个原则：每次只动一个参数，记录下训练 MAE 和验证 MAE 的变化。如果训练 MAE 降了但验证 MAE 涨了，那是过拟合，回退这个改动。用表格记录每组实验的参数和两个 MAE，比在代码里反复改数字可靠得多。

5. 天气预测避坑清单：时间泄漏、未来数据污染与雨日偏差

这一章是完整源码里最容易被忽视但又最值钱的部分。下面五条坑，是我见过的高频翻车现场，每一条都按“现象 → 原因 → 解决”的格式写清楚。

5.1 训练 MAE 很低，验证 MAE 很高

• 现象：训练集上 MAE 只有 0.8 度，验证集上变成 2.5 度，且差距不随数据量增加而缩小。
• 原因：特征里混入了目标变量的“未来值”。最常见的是滚动特征构造时忘了shift(1)，或者做归一化时用全量数据的均值和标准差去缩放训练集。
• 解决：检查所有滚动特征是否先 shift 再 rolling；检查归一化是否在TimeSeriesSplit内部完成，也就是“只用在训练段上 fit 出来的 scaler 去转换当前折的数据”。

5.2 预测精度高得离谱，MAE 低于 0.5

• 现象：日平均气温的 MAE 只有 0.3 度，远低于合理范围（通常 1.2 到 2.0 度）。
• 原因：这不是好消息，而是未来数据污染。最常见的写法是用当天的temp_max或temp_min去预测当天的temp_mean，这三者本质上是同一天同一组观测的不同统计量。
• 解决：审查特征列里是否包含“预测时刻之后才能观测到”的变量。预测 t+1 天时，能用的信息截止到 t 天，任何标号为 t+1 的输入特征都是泄漏。

5.3 预测曲线整体滞后一天

• 现象：把预测值和真实值画在同一条轴上，预测曲线的峰和谷总比真实晚一天，像平移了一个采样间隔。
• 原因：索引错位。训练时用了dropna()或reset_index()，但验证时没有按date对齐，导致预测结果和真实值的日期错位了一天。
• 解决：预测时始终显式带上date列，在输出结果时用日期去 merge 或 join，而不是用行号对齐。这是数据可视化时最容易暴露的问题。

5.4 晴天预测很准，下雨天集体拉胯

• 现象：总体 MAE 看着不错，但把误差按天气状况拆分，雨天的 MAE 是晴天的两倍。
• 原因：样本不均衡。晴天的样本量远大于雨天，模型学会了“把一切预测为晴天”的偷懒策略。这在降水类特征参与建模时尤其明显。
• 解决：增加滞后降水特征，比如precipitation_lag_1；或者把目标拆成两个阶段——先用分类模型预测是否下雨，再用回归模型仅在雨天样本上预测温度。

5.5 站点迁移后模型突然失效

• 现象：同一份源码，换了另一个城市的数据，训练出来的模型在本地验证集上表现正常，一部署到新站点就完全不能用。
• 原因：气象观测数据的分布随地理位置改变，海滨城市和内陆城市的湿度、气温日较差差异巨大；也可能是新站点数据里有大量连续的缺测段，插值策略不合适。
• 解决：跨站点使用前，先按新站点的数据单独做一次 EDA，确认缺失率、气温分布和原站点是否接近。模型参数可以沿用，但特征构造里的win和lags最好按新站点的自相关曲线重新选。

6. 数据可视化落地：从 Matplotlib 静态图到 Flask + ECharts 面板

最后一环是数据可视化，这也是标题里“完整源码”最直观的加分项。可视化分两个层次：第一层是写论文和答辩用的静态图，第二层是能交互的 Web 面板。两层的工具选择完全不同。

静态图推荐 Matplotlib 加 Seaborn。最有说服力的三张图是：真实值与预测值的对比曲线、残差分布直方图、特征重要性条形图。这三张图分别回答三个问题：预测准不准、误差长什么样、模型靠什么做判断。对比曲线要选最近 90 天的数据来画，太长了线条挤在一起反而看不清；残差图要看是否零均值、宽尾还是尖峰，宽尾说明存在系统性误判。

交互面板则用 Flask 加 ECharts，通过 pyecharts 在 Python 里直接生成 ECharts 配置。如果你只是交课程设计，其实不需要启动 Flask，pyecharts 直接渲染一个 HTML 文件就够了；如果要展示“输入日期 → 返回未来七天预测”的能力，再套一层 Flask 路由。

from pyecharts.charts import Line from pyecharts import options as opts # dates 是最近 90 天的日期列表，y_true 是实测值，y_pred 是同步预测值 line = ( Line() .add_xaxis(dates) .add_yaxis("实测温度", y_true, is_smooth=True, symbol="none") .add_yaxis("预测温度", y_pred, is_smooth=True, symbol="none") .set_global_opts( title_opts=opts.TitleOpts(title="最近 90 天温度预测效果"), tooltip_opts=opts.TooltipOpts(trigger="axis"), datazoom_opts=[opts.DataZoomOpts(range_start=0, range_end=100)], ) ) line.render("weather_forecast.html")

这里symbol="none"去掉数据点标记，90 个点带标记会显得杂乱；is_smooth=True让折线更接近真实温度变化的连续感。DataZoomOpts是关键配置，它让查看者可以拖拽缩放，专注看某一段天气过程。生成 HTML 后直接双击用浏览器打开，不需要启动任何服务。

我自己在交付这类项目时有一个习惯：可视化不是最后才画的，而是在数据清洗完就画第一张图，特征工程完成后再画第二张，模型跑完再画对比图。这样每一步的结果都在眼前，出问题能第一时间发现，而不是等所有代码写完再回头找坑。这个习惯帮我避开过多次“数据处理错位但直到最后可视化才暴露”的翻车事故。希望这篇文能帮你把完整的天气预测项目顺畅落地，少走几步弯路。

本文还有配套的精品资源，点击获取