企业官网建设流程全解析

做新能源功率预测这几年，我最常被同行问的一句话是：你们用的气象数据是哪家的？分辨率多少？预报时效拉到多长？以前我习惯拿公开再分析数据做复盘，但真到业务侧就发现不够用——场站要排检修计划、电网要上报次日出力曲线，手里只有日级或小时级数据，建模时总是差一口气。后来接触到“未来15天、15分钟分辨率”这套全要素预报数据，很多之前憋着的问题才算真正解开。

这篇文章我不打算只贴一张下载链接，而是把这套气象数据的完整脉络理一遍。风、温、湿、云、辐照五个要素怎么用、字段字典怎么读、数据落地之后怎么做质量检查、实际业务里有哪些坑，我都会写清楚。对做光伏功率预测、风电功率预测、农业气象服务、户外活动风险预警的朋友来说，这套数据属于可以直接拿来当底料的级别，建议收藏后慢慢看。

1. 为什么15分钟精度的15天预报数据成了刚需

1.1 从日级到分钟级的粒度跃迁

早几年的数值天气预报产品，公开渠道能拿到的大多是3小时甚至6小时一个时次。3小时间隔对看天气趋势够用，但放到新能源功率预测场景里就很尴尬。光伏电站的出力曲线跟云量变化强相关，夏天午后一片积云飘过来，辐照能在十几分钟内从900W/m²掉到300W/m²，如果气象数据间隔3小时，建模时根本捕捉不到这种剧烈波动。风电场也好不到哪去，阵风过程往往持续几十分钟，小时级数据会把峰值抹平，预测出来的功率曲线自然偏保守。

15分钟分辨率解决的就是这个问题。它把时间维度上的锯齿磨平了不少，让功率预测模型能从气象侧拿到更细的输入特征。有人会问，15分钟和1小时差别真有那么大吗？我举个例子：一个50MW的光伏电站，夏天午后辐照快速变化时段，用15分钟辐照数据做输入，模型预测的分钟级出力曲线跟实际曲线的相关系数能到0.95以上，换小时级数据可能只有0.8左右。对调度考核来说，这个差距直接影响罚没电费，不是可有可无的精度提升。

1.2 十五天时效覆盖了哪些业务窗口

预报时效从7天延长到15天，最直接的价值是让“中期预测”从模糊走向可用。电力交易市场里，新能源场站需要在中长期时间尺度上报发电能力曲线，15天刚好覆盖一个完整的交易窗口。现在很多省份的中长期交易是按周、按旬组织的，气象数据能报到第15天，交易策略的制定就有了锚点。

另一个典型场景是检修窗口的排定。风电场做风机年度检修、光伏电站做逆变器维护，都需要在低发电时段进行。提前10天到15天知道哪天风速小、哪天云量大，就能把检修计划排到损失发电量最小的日子。这一项一年下来给场站省下的机会成本很可观。农业场景也类似，打药、灌溉、收割都需要一个相对长一些的天气窗口，15天的预报时效让农事安排不再靠赌。

1.3 高分辨率的底气：多源融合与降尺度

15分钟分辨率不是简单把小时数据插值出来的，插值只会让曲线变平滑，不会增加任何真实信息。靠谱的做法是拿全球数值模式的输出，叠加区域高分辨率模式、地面站点观测、雷达反演和卫星反演数据，做多源融合和统计降尺度，再用站点实测做偏差订正。这套流程走下来，每个格点上的时间序列才有物理意义。

理解这一点很重要，因为市面上不少所谓分钟级数据就是线性插值凑出来的，看着密，实际信息量没增加。拿风功率预测来说，如果风数据是插值出来的，风机轮毂高度处的湍流特征根本体现不出来，预测结果自然好不了。所以我拿到一套高时间分辨率数据，第一件事就是看它是不是真跑过降尺度，而不是看网格密度和时次数量。

2. 五个核心要素逐个拆解：风、温、湿、云、辐照

2.1 风：10米风与轮毂高度风各有用途

风要素通常是数据包里最基础也最常用的变量。水平风一般用U/V分量存储，分别代表东西方向和南北方向的风速分量，这样存储的好处是方便做矢量运算，比如算风速大小和风向角度。如果只想用风速和风向，可以用以下公式换算：

风速 = sqrt(U² + V²)

风向 = arctan(U / V) 再根据象限做矫正

但实际业务里，10米风往往不够用。风力发电机轮毂高度在80到120米，这个高度的风速跟10米处差异很大，尤其在地形复杂的区域。所以优质数据集里会同时给多个高度层，或者提供风切变指数让用户自己换算。千万别直接把10米风速塞进风功率预测模型，除非你的模型已经做了高度订正，否则误差会非常明显。

叶片结冰、风机切出风速等场景，也需要精细的风要素配合温度、湿度综合判断。比如气温在0℃附近、相对湿度超过85%，风机叶片就有结冰风险，这时候哪怕风速很大，也可能要限功率运行。这种情况下，风、温、湿三个要素必须联合使用，单独看一个都容易出事。

2.2 温度：2米气温与地表温度要区分

气温最常用的是2米气温，也就是气象标准观测高度上的温度，几乎所有业务场景都会用到。但有些数据包还会给地表温度或土壤温度，这跟2米气温是两回事。光伏组件的发电效率跟组件表面温度直接相关，而组件温度又跟环境温度、辐照、风速都有关系，所以做光伏功率预测时，除了2米气温，最好还能拿到地表温度或者直接用辐照、气温、风速去推算组件温度。

温度要素对功率预测的影响有两种路径。一种是直接影响，比如低温会让光伏组件输出电压升高、电流下降，整体效率会有一个温度系数修正；另一种是间接影响，比如温度影响空气密度，空气密度又影响风机出力。风电功率密度跟空气密度成正比，同样的风速，冬天空气密度大，发电量会比夏天高几个百分点。细节虽小，但对精度要求高的场景必须算进去。

2.3 湿度：相对湿度与露点温度背后的门道

湿度要素常见的有相对湿度、比湿、露点温度三个量。相对湿度是预报里最容易拿到的，但它对温度很敏感，温度升1℃，相对湿度可能降几个百分点。真正在物理上有更多含义的是露点温度，它直接反映了空气中水汽的绝对含量。判断有没有大雾、有没有凝结风险时，重点看露点与气温的差值，差值越小说明空气越接近饱和。

对新能源场景来说，湿度主要影响几个方面：一是光伏组件的表面积灰和清洗决策，高湿环境容易让灰尘粘附，降低发电效率；二是风机叶片结冰风险；三是输电线路的污闪风险，高湿度加上污染物会让绝缘子表面泄漏电流增大。农业用户更关心湿度对病害发生的影响，持续高湿是很多真菌性病害的诱发条件。

2.4 云量：总云量、低云量和云底高度

云量是光伏预测里权重最高的要素之一。数据包一般会提供总云量，有的还会细分低云量、中云量、高云量。对地面辐照影响最大的是低云，尤其是积云和层云。一片低云遮住太阳，辐照可能瞬间掉一半；高云的影响则小得多，只是让辐照略微打折。

做光伏功率预测时，光看总云量还不够，最好能拿到云底高度或者云的垂直结构。云底高度决定了云影在地面上的移动速度，结合风速可以推算一个站点什么时候会被云遮挡。这一块已经从单纯的统计建模走向物理过程模拟了，数据里有云底高度会比较加分。如果没有，至少要有低/中/高云量分层，这样还能做简单的地面辐照衰减估算。

2.5 辐照：GHI、DNI、DHI三个量缺一不可

辐照数据是光伏场的核心输入，通常包含三个变量：水平总辐照GHI、法向直接辐照DNI、水平散射辐照DHI。三者的关系是GHI等于DNI乘以太阳高度角的正弦值加上DHI。固定倾角的光伏组件发电主要靠GHI，带跟踪支架的组件对DNI更敏感，聚光光热系统则基本只看DNI。

所以拿到数据包之后，先确认它给的是哪几个辐照量。有些简化数据只给GHI，这用于固定式光伏没问题，但如果你要做双面组件、跟踪支架或者光热项目，缺了DNI和DHI就没法建模。另外注意辐照数据的时间积分口径，15分钟分辨率的数据，辐照一般指该时刻的瞬时值或15分钟平均辐照通量，单位是W/m²；如果要做能量结算，需要自己换算成辐照量，单位是kWh/m²。这个换算很多人栽过跟头，后面我会专门说。

3. 字段字典与数据格式：解码这套数据的关键

3.1 字段字典：拿到手先看懂这张表

一套数据值不值钱，字段字典占一半。没有字段字典的数据就是一堆裸数字，连单位都要靠猜，用起来提心吊胆。下面我整理一份这套数据常见的字段字典，按实际业务中比较常见的结构来写，具体以你拿到的版本为准。

这份字典是我按业务里常见的实际字段整理出来的，不一定和原数据100%一致，但逻辑几乎一样。建议正式使用前，先把单位统一好。我见过有人把开尔文温度直接当摄氏度用，模型输出直接偏了20多度，排查了半天才发现是单位问题。

3.2 时间坐标与空间坐标：时区是最大的坑

气象数据的时间标准几乎都是UTC，这一点看着简单，实际特别容易翻车。如果你在北京，UTC时间加8小时才是本地时间。做功率预测时要跟电网的考核时段对齐，电网报的是北京时间，如果直接用UTC时间建模，每天8点变成0点，时序特征全乱了。

我的习惯是，数据落地后立刻把UTC时间转成北京时间，并且新建一列存储本地时间，后续所有分析都基于本地时间进行。同时要处理好日期边界，比如UTC 2025-06-01 18:00对应的北京时间是2025-06-02 02:00，跨天了。日期字段和时间字段如果分开存储，这种跨天数据最容易在分组统计时被切碎。

空间坐标也要看清是规则网格还是站点数据。网格数据一般用经度、纬度二维坐标标识，站点数据可能只有站号或者一条经纬度记录。如果做区域分析，比如把整个省的光伏出力汇总，就要先把网格数据映射到具体站点，再按装机容量加权。映射过程要用到反距离权重插值或者最近邻算法，注意选择合适的方法，不要拿网格数据生套站点坐标。

3.3 单位、质量控制码与缺失值处理

质量控制码是另一个必须处理的字段。常规取值0、1、2，分别代表原始值、订正值、缺测或无效值。不要不管三七二十一全部拿来建模，先把qc_flag不等于2的样本筛掉，对等于1的值要想清楚是否使用了订正后的数值。在风电功率预测这类场景里，风向突变时段的数据经常会被标记为订正值，如果模型训练集里混入了大量订正值，推理时就容易失真。

缺失值的处理策略要分情况。短期预测场景，可以用前后时次的线性插值把缺口补上；如果是长期统计或做极端天气分析，直接丢弃缺测样本更稳妥。切忌在功率预测模型训练时用均值填充气象特征，那会把特征方差压小，导致预测值趋中、极端情况预测不到。这一点踩过坑的人应该都懂。

4. 实操记录：从取数到可视化的一次完整流程

4.1 数据获取方式与格式选择

这套数据常见的获取方式有两种。一种是文件下载，通常提供NetCDF或者CSV格式，适合离线分析；另一种是API接口，按需拉取，适合自动化业务系统。文件方式适合做历史回测和研究分析，API方式适合生产环境里每天定时拉最新预报。

如果你拿到的数据是NetCDF格式，推荐用Python的xarray库读取，它天然支持多维数组切片。CSV格式则用pandas处理就行，但要注意文件可能很大，15天96个时次，如果覆盖多个经纬度网格点，一个站点一天就有96行数据，整个文件可能有上百万行，读取时最好分块处理。

生产环境通常走API，推送频率一般是每天更新一次，也有6小时或12小时更新一次的版本。更新频率越高，越能捕捉到最新的天气系统演变，但数据量和成本也会上升。我的建议是，功率预测系统每天至少拉一次最新预报，最好选择半夜或凌晨更新，这样早上出日报告时数据就是最新的。

4.2 用Python快速加载并检查数据

下面我用一段代码演示拿到NetCDF数据后怎么快速检查。假设文件名为weather_15d_15min.nc，里面有t_2m、ghi、ws_10m等变量。

import xarray as xr import pandas as pd import matplotlib.pyplot as plt # 读取数据 ds = xr.open_dataset('weather_15d_15min.nc') print(ds) # 看变量列表和属性 print(ds.variables) print(ds['t_2m'].attrs) # 选取北京周边一个格点 beijing = ds.sel(latitude=39.9, longitude=116.4, method='nearest') print(beijing['t_2m'][:10].values)

这段代码能帮你在10秒内确认数据里有哪些变量、每个变量属性和单位是否正确。拿到数据的第一时间别急着建模，先跑一遍数据检查，确认时间范围、时间间隔、经纬度范围跟预期一致。检查完时间维，再做一次缺失统计：

# 统计每个变量的缺测数量 for var in ['t_2m', 'ghi', 'ws_10m']: missing = ds[var].isnull().sum(dim='time').values print(f"{var} missing count: {missing}")

如果某一天的某要素缺测比例超过5%，那一天的预测结果就要谨慎使用。特别是云端、台风这类强对流过程，数值模式经常出现局部缺测，这些时段恰恰是功率预测最容易出大偏差的时候。

4.3 辐照数据的单位换算与图表验证

拿到辐照数据后，先做一次单位换算和合理性验证。假设你的ghi单位是W/m²，要换算成kWh/m²做日发电量估算，计算公式是：

# 假设时间间隔为15分钟 interval_h = 15 / 60 ghi_kwh = ds['ghi'].mean(dim='time') * interval_h / 1000

但这里有个细节：如果是瞬时辐照值，应该先对全天瞬时值做积分，再除以1000；如果数据本身就是15分钟平均辐照，那可以直接用平均值乘以时间间隔。两种数据口径不同，直接套公式会得到两套差异很大的结果。最好先看一眼字段说明里的统计口径。

画一条辐照日曲线能快速验证数据是否合理。日出前应该接近0，正午达到峰值，阴雨天曲线会明显偏低并且抖动频繁。代码很简单：

df = beijing[['ghi']].to_dataframe().reset_index() df_hour = df.set_index('valid_time').resample('h').mean() plt.figure(figsize=(12, 5)) plt.plot(df_hour.index, df_hour['ghi'], linewidth=1) plt.title('GHI - Beijing grid point (hourly mean)') plt.ylabel('W/m²') plt.grid(alpha=0.3) plt.show()

如果画出来的曲线出现正午断崖式下跌或者夜间不为零，说明数据有问题，先排查清楚再继续用。这种视觉检查看起来土，但比任何统计检验都直观。

4.4 数据落地存储与定时调度建议

业务系统里建议用数据库存近30天的数据，历史数据归档成Parquet或者NetCDF文件。数据库选型上，时序数据库比如InfluxDB、TDengine在处理高频气象数据时效率远高于关系型数据库，查询15分钟间隔的数据做时间范围聚合非常快。如果团队没有时序数据库，也可以用PostgreSQL加TimescaleDB插件，效果接近。

定时调度建议用Apache Airflow或者纯Cron脚本都行，关键是建好检查机制。每天数据拉取完成后，先做三件事：检查数据时效性，确认最新时次已经更新到预期时间；检查数据覆盖范围，看有没有缺测区域；检查关键要素的数值范围，防止接口返回异常值。任何一步不过就告警，宁可不更新也不要让脏数据流进模型。

5. 数据质量排查与实用避坑指南

5.1 常见的数据异常类型及处理办法

用这套数据时间久了，遇到的异常大概可以归成几类：

第一类是辐照夜间不为零。这个问题多半是太阳高度角计算边界没处理好，或者数据源里混入了散射模型误差。处理办法是设置太阳高度角阈值，当太阳高度角低于一定值比如0.5度时，强制把GHI、DNI、DHI置零。

第二类是风速长时间恒定不变。如果某个站点风速连续6小时以上完全不变，很可能是数据被插值平滑了。这种数据用来训练模型会严重低估风速变化性，需要对比周边站点判断是否合理。如果周边风速都在变化而当前点恒定，建议直接剔除该站点。

第三类是气温跳变。一个时次比前一个时次突然高或低10℃以上，大概率是数据质量码标记异常。遇到这种情况先看qc_flag，如果标记非0，果断用前后时次插值或者干脆用邻近格点替换。

第四类是云量和辐照矛盾。总云量接近100%，但GHI依然长时间维持高值，这肯定是数据源不一致导致的。同一套数据内部应当具备物理一致性，出现这种矛盾的时候要优先复查云量数据。

5.2 预报时效边界：第15天数据只能当参考

15天预报时效里，前3天误差最小，4到7天可用性尚可，8天以后误差迅速放大。这不是数据供应商的问题，是目前数值天气预报的物理极限。大气是混沌系统，超过7天预报就偏向气候态意义了。所以我做业务时会按时效分层处理：前3天用于短期功率预测，直接进模型；4到7天用于交易策略和运维计划；8到15天只用于趋势判断，不做精细化预测。

如果你要做中长期电量预测，最好把多套数据源做集成，别只押一套。比如拿这套15天数据跟气候模式产品做对比，取加权平均或者分位数区间，给出一个预测区间而不是单点值。这样虽然不能保证每次都准，但在趋势判断上会稳很多。

5.3 我的一些实操心得

5.3 我对这套数据的实操心态

用这套数据做了将近一年业务，我最大的感受是：数据本身的价值只占一半，另一半在于你怎么把它接进业务流程。字段字典拿到手之后，我做的第一件事不是跑模型，而是把所有字段从头到尾看一遍，把单位、时间口径、坐标系统全部换算成内部统一标准，并且写进团队的数据字典文档。这一步花掉半天时间，后面省下来的排查成本不止半天。

第二个心得是小步快跑。不要指望一次把15天、96个时次、几十个变量的全部信息都用上，而是先挑核心变量，比如GHI、风速、温度做一版简单模型出来，验证数据能吃透之后再逐步加入云量、湿度、DNI这些辅助变量。项目上线之后的迭代速度，比一步到位的完美方案更重要。

第三个心得是重视可视化。每次数据接口更新，我都会把典型站点、典型日的气象要素曲线打出来看一遍，尤其是辐照和风速这两条曲线。曲线看起来舒服，数据大概率没问题；曲线一出现毛刺、突变，立刻去查原始日志。这种习惯帮我拦截过好几次接口返回错位的数据事故，比任何自动检查都管用。

最后分享一个小经验：预报数据落地时，不要只存最终订正后的值，最好把原始值、订正标志一起存下来。因为数据供应商的订正算法可能会升级，如果你只有订正后的值，算法升级后就无法回溯历史场景。留一份原始值，后续做模型回测和数据一致性分析时，你会感谢自己当初这个决定。