基于Kmeans的光伏时间序列聚类：从特征工程到功率预测应用

做光伏数据分析这一年多，我最大的感受是：光伏功率序列根本不是“一条曲线”，而是十几条长得完全不同的曲线叠在一起。晴天是一条光滑的倒U型，多云天是一条锯齿状曲线，阴雨天直接打成一条贴近零的波动线。我第一次用Kmeans聚类算法去拆解光伏时间序列时，本意只是想给数据分分类，结果却意外打通了后续预测、运维、报表生成一整条链路。这篇文章就围绕“基于Kmeans的光伏时间序列聚类”这条主线，把我踩过的坑和现在沉淀下来的方法完整写出来，给正在做光伏数据挖掘、超短期光伏功率预测或者时序聚类的朋友做个参考。

先说结论：光伏功率时间序列非常不适合“拿到什么就聚什么”。Kmeans虽然是聚类里最朴素的一种，但放在光伏数据上能跑出非常清晰的业务含义，前提是必须先解决特征工程、数据清洗和K值验证这三个问题，否则聚出来的簇只能算是数学上的分割，不能对应到真实天气场景。

1. 光伏功率序列为什么要“先聚类再预测”

这句话听起来像流程层面的老生常谈，但实际做预测模型的人应该都有同感——光伏功率并不是一个单一时间序列分布，它本质上是多种天气工况的混合体。

1.1 混合工况会让预测模型学到一条“缝合线”

我以前在一个分布式光伏项目上做功率预测时，偷懒把所有历史日的功率序列直接丢给模型训练。模型用LSTM结构，输入前几个小时的功率和气象预报数据，输出未来4小时功率。晴天测试效果很好，MAPE能做到5%以内，但一到多云天，误差直接飙到20%以上。后来我把预测误差高的日子调出来看，发现模型犯的错误很有规律：它总是倾向于预测一个介于“晴”和“阴”之间的中间形态，既没有云遮时的剧烈波动，也没有晴天该有的高值平台。

原因其实很简单。模型在训练时把晴天、多云、雨天、阴天的样本混在一个batch里，梯度在多个方向上反复拉扯。模型为了最小化整体损失，学出来的映射关系自然被“平均化”了，晴天有云的样本都会被压向中间。我在日志里看loss曲线，训练集和验证集都在降，但分场景评估就是不稳定，这就是分布混叠的典型特征。

所以后来我把聚类作为预测流水线的前置步骤。先把日功率曲线按照形态分成若干簇，每一个簇对应一类稳定天气工况，再在分簇数据上单独训练预测模型。单个模型只需要拟合一种形态，学习负担小很多，预测误差自然降下来。

1.2 聚类并不只是为了预测，它本身就能回答业务问题

做功率预测只是其中一条应用线，聚类结果本身就有很强的业务解释能力。

一个很直接的应用是运维异常识别。光伏电站难免会遇到限电、逆变器降额、组串离线这些情况，这些状态产生的功率曲线和自然天气曲线会有显著差异。聚类时模型会把形状相似的日曲线聚合到一起，如果某一天功率曲线和它所在簇的类中心偏差很大，多半就是设备或通信状态出了问题。比单纯看日发电量阈值要灵敏很多，因为曲线形态包含了“时段分布”的信息。

另一个应用是数据治理。光伏数据经常会出现某段时间数据传输中断、补数逻辑不当、辐照度缺失等情况，这类坏数据会聚成一个特征很奇怪的簇，或者单独跳出来变成离群点。聚类完成之后做一次离群筛选，可以顺带完成数据质量的批量清洗，比逐日人工排查效率高很多。

1.3 本文实验的基本路径

下面所有内容，基于我常用的一套光伏数据样本：单站装机容量约3MW，数据采样间隔为15分钟，单日序列长度96点，总共覆盖春夏秋冬四个季节约两年历史功率数据。处理路径是：先做数据清洗和日序列切片，再对每日序列做特征提取，然后在特征空间上运行Kmeans，用多种指标选定K值，最后把簇中心映射回时间轴去解释天气类型，并将聚类结果接入预测环节。

2. Kmeans与时间序列结合方式：直接聚类还是特征化之后聚类

我刚接触这个问题时，第一个想法其实很简单粗暴：Kmeans就需要输入一个向量，那我直接把每天96个点拉平成一个96维向量，然后喂给聚类不就行了？实验下来结果很糟糕，后来才理解为什么不行。

2.1 直接拿原始日序列做Kmeans为什么不好用

第一个问题是维度偏高。96维空间里样本会变得非常稀疏，欧氏距离在稀疏高维空间中区分度下降，不同日期的序列都会被拉成中等的距离，聚类结果不稳定。虽然96维相比图像领域动辄上千维并不算高，但Kmeans的分簇逻辑严重依赖球形簇假设，原始曲线之间存在明显的形变、时间平移、幅值缩放，距离度量根本代表不了“形状上相似”。

第二个问题是时间错位。光伏功率序列有一个天然特性：每天太阳升起的时间不一样。冬季比夏季晚近一个半小时，即使同一天气类型，曲线形态在时间轴上也有整体平移。如果直接比原始序列的对应位置，上午十点的晴天曲线很可能被算成和上午九点的晴天曲线“不相似”。以前有人会用动态时间规整距离代替欧氏距离，让Kmeans能识别时间轴上的伸缩形变，但DTW的迭代计算量在样本量大时会非常可观，而且Kmeans每次更新都需要重新计算所有簇心，等于把一个简单算法变成了一个计算负担很重的工程，不值当。

第三个问题是幅值干扰。一个夏季晴天和一个春季晴天，如果只从曲线形态看，非常接近，但两者的绝对功率高度差很多。直接以原始数值做欧氏距离时，夏季样本会被单独拉出去成一簇，而真正需要区分的晴、多云、阴三态反而会被混到一起，因为幅值差异大过了形态差异。

2.2 特征提取方案：把96维序列压缩成7维结构化表示

既然直接送原始序列不合理，我选择先把日功率序列转成一组固定维度的特征向量。特征的选择原则是：每一种特征都要有物理含义，且能覆盖光伏曲线的典型维度的信息，避免模型只依赖全面总数的一一个特征。

我实际使用的特征集合如下：

• 日均利用小时数： 日发电量 除以 装机容量，代表当天的整体资源水平
• 峰值功率值： 当天最大出力，归一化到装机容量
• 峰值时刻： 峰值功率发生的时间，转换为0到1的小数；太阳能电站的峰值大多在正午前后，但阴雨天可能提前或滞后，这本身就有信息区分能力
• 波动强度指数： 对归一化后的相邻时间点差分绝对值的均值，用来量化云的间歇遮挡程度
• 早晨爬坡斜率： 从日出后到上午阶段的最大平均爬坡速度，表征清晨天空遮蔽状态
• 傍晚下降斜率： 午后到日落期间最大下降速度，有助于区分稳定晴天和午后热对流积云出现的天气
• 有效日照时长： 功率大于某个阈值的时间占比

上面7个特征里，日均利用小时数和峰值功率体现的是“能量尺度”，峰值时刻与日照时长体现的是“时间几何”，波动强度指数体现的是“云况”，两个斜率体现的是“日内变动态势”。它们合在一起，基本把一个96点的日序列压缩成7个有效维度，Kmeans跑起来非常稳定。

特征提取的代码实现也不复杂，单日序列处理大致如下：

python复制import numpy as np

def extract_features(day_series, rated_power, sample_interval_min=15):
    series = np.asarray(day_series, dtype=float)
    n = len(series)
    p_max = series.max()

    energy_yield = series.sum() / rated_power  # 日均利用小时
    peak_value = p_max / rated_power
    peak_idx = np.argmax(series) / n  # 归一化到[0,1]
    normalized = series / p_max if p_max > 0 else series

    # 波动强度：相邻点差分绝对值的均值
    diff = np.abs(np.diff(normalized))
    fluctuation = diff.mean()

    # 早晨爬坡：按采样间隔折算成等效分钟斜率后取最大值
    minutes_per_step = sample_interval_min / 60.0
    slope = np.diff(normalized) / minutes_per_step
    morning_slope = np.max(slope[:int(n * 0.35)]) if p_max > 0 else 0.0
    evening_slope = np.abs(np.min(slope[-int(n * 0.35):])) if p_max > 0 else 0.0

    # 有效日照时长占比：功率大于峰值5%的时间
    sunlight_ratio = (series > 0.05 * p_max).mean() if p_max > 0 else 0.0

    return np.array([
        energy_yield,
        peak_value,
        peak_idx,
        fluctuation,
        morning_slope,
        evening_slope,
        sunlight_ratio
    ])

需要注意，有效日照时长我用的是站内实测功率超过峰值5%的时间占比，而不是靠经纬度去算理论日照时长。原因是实测门槛能直接反映出云的遮挡程度，晴天约在0.5到0.6之间，阴天只有0.2到0.3。这和基于天文计算的日出日落时长是两个概念，后者更适合做理论发电量估算，不适合做天气状态表征。

2.3 为什么最终选择Kmeans而不是DBSCAN或层次聚类

并不是说Kmeans在算法上更先进，实际上它反而是最“笨”的一个。但放在这个场景里，它的优点刚好踩中需求。

DBSCAN适合发现任意形状的簇，并且能在没有先验簇数的情况下自动识别噪声点，这在通用聚类里很有吸引力。但光伏日序列经过特征化之后，晴、多云、阴、雨这些天气状态在特征空间里的分布基本近似于几个团聚在一起的“云团”，彼此有交叠但中心相对明确。此时DBSCAN的密度半径参数非常难调，调小了连晴天都会往外冒噪声，调大了云和阴会被合并。而且DBSCAN的产出结果里没有“簇中心”这样的天然代表，后续做在线预测状态识别时很难为一个新样本找到快速归属方式。

层次聚类可以画出树状图，直观展示天气形态的层级结构，分析阶段做一轮挺有价值。我初期也用它来观察数据，树状图能清楚看到“晴天组-均值高-波动小”和“阴雨组-均值低-波动大”的顶层二分。但层次聚类的计算复杂度在样本量过万后迅速上升，而且没有可保留的簇心，工程化阶段不太顺手。

Kmeans的质心机制反而是最大的工程优势。训练完成之后簇心就是若干条典型天气曲线的特征向量，在线场景中来了一条新曲线，只需要计算它和所有簇心的欧氏距离，选最近的那个作为工况标签，成本是一次轻量矩阵运算，非常适合放到实时功率预测服务里。

3. 清洗与日切片：聚类结果好坏七成在预处理

这句话不是夸张，是真金白银试出来的。我第一次跑到最终聚类结果，发现有一簇全是“清晨满发、午后骤停”的曲线，百思不得其解，后来才发现是逆变器下午过温降额导致的数据，属于设备事件不是天气事件。从那以后，预处理流程变得格外严格。

3.1 功率序列里的“假平坦区”会生成幽灵簇

光伏功率数据最常见的脏特征分四类。

一是夜间零值。太阳能电站夜间不出力，这部分零值本身是有效数据，但如果把每天24小时完整纳入日序列，零值区间会占到一半以上，而零值长短随季节变化很大，最终会严重干扰聚类。处理方式是将序列切片限定在有效出力时段，而不是把全天24小时直接加入聚类样本。

二是通信断点与补数异常。SCADA系统偶尔会断传，有的补数逻辑会用上一时刻的数据填充，结果形成一段实际功率恒定不变的“假平坦区”。这在真实天气里几乎不会出现，表现为斜率骤变为零的极平直线。聚类时会自动形成一个天数不多但特征很独特的簇，需要人工辨析。

三是逆变器降额与停机保护。辐照度并不高但温度过高或电网电压超限时，逆变器限制输出，曲线变为“水平切割”的形态，好像是日最大出力被压平。这种工况本质上和云无关，要单独标注。

四是弃光限电。这个在分布式电站中相对少见，但在集中式电站里很普遍，一大片时段的功率呈水平线状态，并非正常出力。限电片段既不能当作真实自然天气数据训练，也不能简单删除，因为限电行为本身对电力交易业务有意义，不能让真实出力的后续预测把限电事件当成预测目标。

处理建议是为每天的序列维护一个质量标记，例如status字段记录“正常”或“含限电”或“含停机”，并设置对应的峰线特征在后续建模中保留或剔除。并不是所有坏天都要删除，关键是不要让设备工况混入天气工况而污染聚类。

3.2 按日出日落动态切片比固定0到24点更稳

光伏功率在夜间没有物理意义，所以我的日序列切片默认不取完整的0点到24点，而是每天从“首次连续1小时功率超过起步阈值”的时间点开始，截到“末尾连续1小时功率低于起步阈值”的时间点截止。这样每个样本都不是标准等长序列，最后通过提取出固定维的特征来避免维度不一致的问题。

代码上，我用pandas按天分组后判断活动区间，再进行特征提取：

python复制def active_segment_stats(day_df, threshold_ratio=0.02):
    power = day_df["power"].values
    rated = day_df.attrs.get("rated_power", day_df["power"].max())
    threshold = threshold_ratio * rated
    on_mask = power > threshold
    # 找出连续为True的区间
    idx = np.where(on_mask)[0]
    if len(idx) == 0:
        return None
    groups = np.split(idx, np.where(np.diff(idx) != 1)[0] + 1)
    main = max(groups, key=len)
    return day_df.iloc[main[0]:main[-1] + 1]

只取主要一个连续活动区间可以避免把早上日出前和傍晚日落后那些零散跳变纳入计算。实际验证下来，同一月份不同日期的有效段长度变化不大，真正差异集中在跨季节上，这一步避免冬季样本被大量无效夜间前导零拉进温度型分组中。

3.3 归一化必须放在特征后而不是原始序列前

很多教程会在原始功率序列上先做一次min-max归一化再聚类，目的是消除幅值影响。但这个方法用在光伏上有一个副作用：它会自动把阴雨天噪声放大。

雨天功率曲线本身是一条贴近0的值，最大值可能只有几十kW。min-max缩放后，即使微小的仪表波动也会被放大成相对显著的曲线抖动，这样雨天和晴天的“波动强度”几乎一样高，聚类效果大打折扣。

我的做法是：在特征提取环节，把波动强度、斜率和峰值时刻都放在日内部归一化后进行计算，而能量类特征保留绝对尺度。特征向量形成之后，对7个维度做一次StandardScaler标准归一化，目的是消除不同特征单位之间的偏置，然后再输入Kmeans。这是一个很关键的细节，属于不影响结果形态的先后顺序差异，建议不要跳过。

用sklearn做标准化的代码片段如下：

python复制from sklearn.preprocessing import StandardScaler
from sklearn.cluster import KMeans

feature_matrix = np.array([extract_features(s, rated_power) for s in day_series_list])
scaler = StandardScaler()
X = scaler.fit_transform(feature_matrix)

4. 选K值时我实测过的几种方法：不能只用轮廓系数

Kmeans有一个绕不开的环节就是到底选几个簇。这个问号在光伏场景里会让人格外头疼，因为天气类型不是严格离散的，每一个K值都各有道理。我最后采用“定量指标+稳定性检查+业务解释”三件套，而不是单拿一个什么系数来说话。

4.1 肘部法则的实测过程

我先把K从2到10跑了一遍，记录每个K对应的SSE，也就是簇内平方误差和。在sklearn里就是KMeans对象的inertia_属性。

以我某次典型实验数据为例，跑出来的结果约等于这样：

SSE下降在K=4附近出现明显变缓，这个“拐点”其实并不尖锐，只能说有一个可识别的肘部。K从3到4时，SSE下降了1650；K从4到5只下降了660；继续向上更是边际递减。如果只按照物理规律，通常会倾向K=4或者5之间。

但机械按SSE找肘部有风险。因为光伏数据里天然存在季节性，如果样本连续时间很长，跨季节后SSE曲线往往更平滑，不存在清晰拐点。所以肘部只是辅助信号，不能作为拍板的唯一依据。

4.2 轮廓系数与DBI怎么看

轮廓系数是一种经典的评价方式。系数取值范围在[-1,1]之间，越接近1说明同簇样本越紧密、跨簇区分越明显。但当样本有重叠，轮廓系数往往会给出一个看似合理的数值，不一定能反映天气内部结构的可用性。在我上面的一次实验里，K=2和K=4的轮廓系数几乎没有差别，都接近0.45，可业务含义完全不一样。K=2是一刀切分“有光”和“没光”，对预测无效；K=4才能真正支撑分型预测。所以轮廓系数高并不代表这个聚类结果是业务上能用得上。

Davies-Bouldin指数则衡量簇内离散之和与簇间距离的比值。DBI越小，说明簇内紧凑、簇间距大。它的表现与轮廓系数并不一致，K=4时DBI最小，达到1.09。和轮廓系数联合看，K=4至少在两个指标上都占优。

我给自己定了一个原则：当指标发生矛盾时，业务解释优先，指标用来做交叉验证。K值从生产角度来看通常就是4到5个天气类型，因为光伏电站的运维习惯把天气分成晴、多云、阴、雨四类，这早已是行业里默认分法。如果算法在4到5之间纠结，不妨把业务分类习惯纳入投票权重。

4.3 稳定性校验：换个时间段结果还一样吗

有一个我特别看重的检验：把样本按月份分成两半，一半用1到6月，一半用7到12月，分别独立跑一次K=4的Kmeans，然后查看两个模型分出的簇心在特征空间里是否大致对应。如果两次聚类出来的簇中心数量一致，且彼此距离很近，说明K=4是一个结构稳定状态，不是某段时期偶然产生的分割。

我实际跑过一次发现，春季和秋季单独聚类时都能稳定出4类，但冬季单独聚类时会退化成一个问题：真正有意义上的“晴天”样本太少，算法会把不少弱光日合并成同一簇，K=4时的第4簇几乎是某个灾害离群簇，只包含很少几天。遇到这个情况，更好的方案是不要全局一套聚类参数走全年，而是按季节或按季度分别建聚类模型。这个点我在后面第5节会展开细讲。

K值确认之后，还有一个步骤必做：固定随机种子，尽可能让聚类结果可复现，否则后续每次离线重跑都可能得到不同的簇排序，簇标签会变成无意义的编号。我一般在代码里指定random_state为固定值，同时设置n_init=20来规避局部最优解。

python复制kmeans = KMeans(n_clusters=4, random_state=42, n_init=20)
kmeans.fit(X)

5. 簇中心对应回时间轴：从“聚类编号”到“典型天气日”

聚类完成之后拿到一堆编号本身毫无意义，只有把簇中心逆向还原成功率曲线并和真实日期对应上，才知道算法到底替我们分了什么“天气”。

5.1 K=4时需要看中心点回放而不是只看中心值

如果我只盯着7维特征向量的统计值，很难直观感受到每一类的差别。我通常会把每个簇的所有日序列按原始时间轴叠在一起，求出每个时刻的中位数和四分位带，画一条“典型日带”。这种做法能将特征空间里的抽象描述还原成功率曲线形状，便于给非数据分析背景同事做解释。

在K=4实验里，四个簇中心的典型曲线形态大致是这样：

第一个簇是典型的夏季晴天：出力从早晨开始快速爬升，中午维持在较高平台，午后有轻微波动，但整体平滑，有效日照时间长，日发电量最大。

第二个簇是“高基值+频繁波动”型：日均利用小时数并不低，但波动强度特征是所有簇中最高的，午后频繁出现上下剧烈抖动，这是典型晴间多云天气，云层来回遮挡。

第三个簇的峰值明显偏低且平滑，波动较小，日照长度短，对应阴天或者多云偏阴，卫星云图上通常是均匀厚重的云层。

第四个簇贴近零值，几乎没有明显的峰形，是全天有效出力很少的雨天或大雨天气。这种天气下即使短期的云层稍薄也没有形成大面积有效出力。

把簇中心日期直接拉出来和气象观测记录对比，例如随机挑出50个被分到第2簇的日子，对照气象站小时级总云量数据，多数日子里云量都处在40%到80%之间且变化频繁。这个对照能证明聚类结果和实际物理天气具有明显对齐关系。

5.2 季节性漂移：同一个K不能全年一用到底

聚类完成一年数据之后，我注意到一个普遍问题：第二簇和第三簇在春夏季区别很清晰，但到了冬季界线急剧模糊。冬季太阳高度角低，组件辐照度总体偏弱，再加上雨雪天气多，很多天的曲线形态都落在一个很相似的“弱光区”内，Kmeans即便强行分成四个簇，也会出现“上午出力正常、下午阴雨”这种时间片段性簇，而不是完整的天气型日簇。

对这个问题的处理，我更推荐对数据进行季节分层再聚类。比如12月、1月、2月作为冬季组，6月、7月、8月作为夏季组，其他月份作为过渡组，分别跑一次聚类。这样做出来的簇中心会更有代表性，也避免冬季弱出力样本被夏季大能量样本带偏。代价是模型数量和维护成本都会上升，预测系统的分型路由逻辑也要对应加一层季节判断。但从结果看收益远远大于成本。

5.3 离群点并不全是脏数据，保留并打标签

Kmeans不会把很难归类的离群点剔除出局，它只会硬分到某个簇然后拉偏簇中心。所以我一般会在聚类前或者聚类后用一遍统计规则识别离群样本，对每个特征维度找到5%到95%分位数区间，把落在区间外的样本单独列出来。

后来发现这里大多数不是坏数据，而是有故事的好数据。比如早春突降大雪造成的整日零出力，或雷暴过境时功率在几分钟内骤升骤降，这些特殊事件在正常天气簇里必然离群。我会把这些日期单独维护一份“特殊事件清单”，既不会让它们进去污染簇中心，也不把它从数据集中删掉，它们后续在做极端天气案例复盘时反而价值很高。

还有极少数是属于逆变器零功率输出但通信未中断的情况，例如夜间的机组抢修。这种数据要直接删除或标记，避免聚类模型学习到“全天零出力也算一个天气类型”的错误映射。

6. 聚类结果落地到超短期功率预测的实操链路

聚类本身只是手段。真正让它发挥价值的地方，是作为功率预测算法链路上的一个环节。下面讲两种我自己常用的落地方式，都是把Kmean从离线的分析工具变成在线系统的一部分。

6.1 做法一：分簇训练+实时簇判定

这种模式是在离线阶段把历史日序列分成若干簇，例如K=4。每个簇对应一个日天气类型，然后在每个簇内部训练独立的预测模型。模型可以是LSTM、GRU、XGBoost或者物理加统计修正方法，都可以。关键是每个预测模型只见过一种天气形态的样本，不会跨形态学习。

在线预测时，首先根据当前时刻之前的一段时间窗口功率曲线，计算出一个实时特征向量，然后通过计算特征向量与各个簇心的欧氏距离，找到距离最小的簇。把这个簇标签作为当前工况，路由到对应簇的预测模型去生成未来4小时功率曲线。整个过程只需要在内存里做一次非常轻量的向量比较，延迟几乎可以忽略。

分簇模型在遇到“当前这段时间天气正在转折”时会比较尴尬，比如上午还是晴空，下午突然一大块云移过来。若只在硬分配单一簇模型做预测，误差会立刻扩大。解决思路是用软隶属度。对距离中心的远近算出一个权重，例如新样本距离第2簇中心为0.3，距离第1簇中心为0.8，那么两簇的预测结果按相似度反比做加权融合。第2簇占权重高，第1簇占权重低，这样在天气拐点时段避免了从一个模型硬切到另一个模型的跳变。

6.2 做法二：簇标签作为模型的附加输入

另一种更轻量的做法不是为每个簇单独建立模型，而是把聚类得到的簇标签当做一个天气状态编码特征，放入统一的预测模型。具体操作为：模型输入除了历史功率、气压、温度、湿度等之外，再拼接上当前功率片段距离每个簇中心过程的相似度向量，例如长度为K的欧氏距离数组。模型通过学习自行决定这些工况信息何时重要。实践下来，给模型增加的输入维度不多，但对晴天与多云天的转换边界处预测精度有正向帮助。

还需要注意，在预测模型输入到输出的整个时间跨度里，簇的判定最好保持滑动更新。比如每15分钟滚动重算一次特征和簇归属，而不是早晨算了一次就管一天，因为天气本身就是动态变化的。

6.3 聚类模型的更新节奏：不要陷入“全量重训”

聚类数据跨度越大，季节漂移越明显，甚至同一个电站组件清洗、热斑老化后，整体发电特性也会慢慢改变。所以我建议每隔1到3个月用最近期间数据重新训练一次聚类模型，更新时间选择月初，用固定随机种子做冷启动即可，没有必要对旧质心做增量更新。增量更新一般不适合Kmeans这种目标函数对样本分布比较敏感的场景。跨季换模型会造成簇标签对应天气的编码不稳定，所以预测装置里需要存一个新旧质心的映射表，保证同一种天气在新的标签体系下对应各自的模型和可视化兼容。

每次更新完成后，要及时把新旧簇中心做一次对照，映射出上一版本的标签与这一版本标签的对应关系，否则会出现前三个月是晴天簇，后三个月是另一个簇，业务报表里的“晴天”变成一个闪烁说法。聚类不是一次性任务，它的价值建立在持续维护的工程管道上。

就个人经验来说，第一次跑聚类时，建议先把数据可视化做透，把每一天的曲线和天气状态有一个主观感觉，再跑到Kmeans有明确预期，业务判断比总指标更可靠百倍。用聚类去处理光伏时间序列这件事，最大的意义不是把数据拆开，而是让机器和人都能用同一套语言讨论到底今天是哪类天气。