分布式能源选址定容的双层优化：从配电网规划到粒子群实现

1. 分布式能源选址定容问题与整体设计思路

1.1 选址定容为什么是配电网规划的第一道难题

做配电网规划的人心里都清楚，分布式光伏和储能不是随便找个空地装上就完事。装在哪、装多大，直接决定配电网的电压分布、线损水平、设备利用率和投资回收周期。我在实际项目中就遇到过这样的案例：一个工业园区的屋顶光伏项目，业主为了多装容量，几乎把每个可用的屋顶都铺满了组件，结果馈线末端电压越限，逆变器频繁降额运行，发电量损失了将近15%。这就是典型的选址定容没做好。

从数学本质上看，选址定容是组合优化问题。配电网的节点数量动辄几十上百个，每个节点都有"装或不装""装多大"的离散决策，加上光伏和储能两类设备的不同容量档位组合，解空间爆炸式增长。如果纯靠人工经验或者等步长遍历，基本不可能在合理时间内给出最优方案。这就是为什么需要优化算法介入，用计算机在解空间里高效搜索。

更麻烦的是，这类问题还不是单层优化，而是"投资决策—运行调度"两层决策耦合在一起。你在规划期决定在某个节点安装的容量，会影响未来二十年每天的运行方式；反过来，每天光伏出力、负荷变化、储能充放电的运行状态，又会影响规划方案的经济性评估。两件事必须同时算，这就是双层优化的用武之地。

1.2 双层优化框架如何避免"一锤子买卖"式决策

我见过很多人在项目里只做单层优化，目标函数里写上"年综合费用最小=投资折算费用+年网损费用"，一次性算出容量配置，然后直接拿来用。这种做法的问题在于：它假设所有运行时刻都是平均化的，忽略了光伏出力的波动性和负荷的时序特性，结果往往偏乐观。

双层优化框架的逻辑不一样。上层解决的是"在哪里安装、安装多大"的规划问题，下层解决的是"给定配置方案后，系统如何经济安全运行"的调度问题。两层通过一组耦合变量连接起来，上层每给出一组候选方案，下层就进行一次严格的运行优化，返回这个方案在真实运行场景下的成本、网损、电压质量等信息，上层再根据这些反馈调整方案。整个过程反复迭代，最终得到的是一个"规划—运行"联合最优的方案，而不是纸上谈兵的单层结果。

我实际跑下来的感受是，双层的优势不光体现在数学严谨性上，还体现在方案鲁棒性上。同样一套投资预算，双层优化给出的配置在晴雨交替、冬夏负荷变化等不同场景下都能保持电压合格率在95%以上，而单层优化方案在极端场景下电压越限的概率高出很多。这一点在项目汇报和评审时非常加分，因为专家问的第一个问题往往是"这个方案在极端工况下能不能扛得住"。

1.3 为什么不直接单层混合整数规划

刚接触双层优化的人通常会问：能不能把选址定容和运行调度合并成一个单层混合整数规划（MIP）问题，用求解器一把梭？理论上可以，把每个小时的运行状态都建模成约束条件，配上潮流方程的二阶锥松弛，就能转化成标准MIP。但实际操作起来有几个致命问题。

首先，约束规模爆炸。一个IEEE 33节点系统，如果按8760小时精细建模，约束条件动辄几十万条，求解时间以小时甚至天计。即使做了典型日场景压缩到几十个时段，矩阵规模依然很大，普通教学版求解器根本跑不动。其次，MIP里的整数变量非常多——每个节点、每档容量选择都是0-1变量，分枝定界的搜索树非常深，求解稳定性差，经常在算例规模稍微扩大后就不收敛。

而双层优化把"规划"和"运行"解耦开，上层只管几个整数变量和容量变量，下层是连续变量的运行优化问题，数学性质好很多。下层可以用成熟的非线性求解器快速求到最优，上层用元启发式算法（比如粒子群PSO、遗传算法GA）或者整数搜索处理离散变量。这样每一层的问题规模都小，求解效率高，而且模块化程度高——后期换个求解器、改个目标函数，都只动对应的模块，不需要推倒重来。

2. 双层优化模型的核心数学表达与配置逻辑

2.1 上层模型：经济目标与决策变量

上层模型的核心是"花最少的钱，办最多的事"。我把上层目标函数定义为年综合费用最小，包含以下四个部分：

1. 光伏年均投资成本：单位容量投资成本乘以安装容量，再乘以资金回收系数折算到每年。公式是CRF = r(1+r)^n / [(1+r)^n - 1]，其中r是贴现率，n是设备寿命。我习惯取r = 8%，光伏寿命25年，储能寿命10年。

2. 储能年均投资成本：同样用CRF折算。注意储能还要考虑替换成本，因为它的寿命比光伏短，20年周期里可能换一到两次。这个成本如果不算进去，算出来的储能容量会偏大。

3. 年运维成本：包括光伏组件的清洗、逆变器维护、储能电池的日常管理。运维成本我通常按初投资的2%到3%估算，具体看项目的运维模式。

4. 年网损费用：这是配电网规划的核心关注点之一，需要从下层潮流计算结果中获取。

决策变量包括：光伏在哪些节点安装（0-1变量）、每个节点的光伏安装容量（连续变量，区间限制）、储能在哪些节点安装（0-1变量）、每个节点的储能额定容量和额定功率。

这里有个细节容易被忽视，就是容量的离散化处理。实际工程中光伏容量按组件功率整数倍选取，储能容量按电池模组整数倍选取，但为了简化计算，很多东西在论文里用连续变量处理。我在工程落地时会在上层优化结束后做一个"归整"处理，把连续容量匹配到最接近的商用规格，再跑一次下层验证。这个处理放在下层验证后，比直接约束为整数方案效率高得多。

2.2 下层模型：潮流计算与运行目标

下层模型要回答的问题是：给定一套选址定容方案，系统在一年中各种场景下怎么运行最经济。

我采用的是最优潮流框架，以典型日场景为基础，目标函数是年运行费用最小，包含购电费用和储能运行损耗费用。约束条件包括：

• 潮流方程约束：每个节点每个时刻的有功和无功功率平衡。配电网一般用DistFlow方程建模，忽略支路并联导纳，用支路首端电压和支路功率表示相邻节点关系，计算效率比完整牛顿-拉夫逊法高很多。

• 节点电压约束：光伏接入位置不合理会导致电压抬升，储能充电可以吸收功率抑制电压抬升，所以电压约束是下层模型中检验光伏储能协调效果的重要指标。常见约束是0.93到1.07倍额定电压。

• 支路电流约束：导线载流量限制，防止过载。

• 光伏出力约束：光伏最大出力取决于光照和温度，实际运行在0到最大出力之间连续可调。需要注意的是，在做规划时不考虑逆变器无功调节能力，或者单独加一个逆变器功率因数范围约束，看你想研究到哪个程度。

• 储能运行约束：充放电功率限制、SOC（荷电状态）上下限约束、储能电量平衡约束。SOC一般限制在10%到90%，避免过充过放损伤电池。

下层用多个典型日场景代表全年的运行状态。我常用的是春、夏、秋、冬各选一个典型日，每个典型日分24个时段。如果算力允许，可以多分几个场景，比如用K-means聚类把全年8760小时的数据聚成若干个典型场景，这个我在后面详细讲。

2.3 约束条件分类与处理细节

我在建模时习惯把约束分成三类，分别用不同方式处理：

第一类是潮流硬约束。这类约束必须满足，不满足意味着系统崩溃或设备损坏。在编程实现时，如果潮流不收敛，我会直接给这个配置方案一个很大的惩罚值，让上层算法自动放弃这个方案。

第二类是电压、电流越限约束。这类约束可以用罚函数处理，电压越限量和电流越限量的平方乘以一个较大的惩罚系数加入目标函数。罚函数的好处是不用改变问题结构，代码实现简单。但惩罚系数不能太小，太小约束等于摆设；也不能太大，太大会让目标函数数值呈现病态，影响算法收敛。我试过几个量级，最终发现罚系数在目标函数基准值的100到1000倍之间比较合适。

第三类是逻辑约束。比如"如果节点不装光伏，那么安装容量必须为0"——这本质上是0-1变量与连续变量的耦合约束，可以用不等式关系表达：容量上限乘上安装标志变量，容量不超过上限乘以标志。还有储能"先充后放""非同时充放"等逻辑约束，在连续时间框架下用线性不等式处理即可。

2.4 光伏出力与储能运行的不确定性处理

光伏的间歇性和随机性是整个规划中最让人头疼的部分。一天中光照曲线变化快，中午前后出力高，晨昏出力低，夏季和冬季的日照水平差异巨大。如果只用理想曲线算，方案在真实天气下很容易"水土不服"。

我在项目中处理不确定性的方法分两级。第一级是典型日场景生成，收集项目所在地一年的历史光照、温度、风速、负荷数据，用K-means聚类算法把8760个小时聚成春夏秋冬四个季节性片段，再从每个片段里选出最接近聚类中心的日曲线作为典型日场景。第二级是场景削减，如果聚类选出的典型日场景数量偏少，我会用蒙特卡洛抽样产生大量场景，再用后向削减算法（快速前向选择）缩减到10个左右，既能覆盖不确定性的主要分布，又不至于让计算量爆炸。

储能的作用在这里就体现出来了。光伏出力高峰时储能充电，把多余电量储存起来；光伏出力不足或负荷高峰时储能放电，平抑功率波动。下层的运行策略用的是规则充放电加优化的混合模式——先按"低储高放"的简单规则确定储能的充放电区间，再在最有可能工作的时段参与优化调度，这样求解稳定性比一开始就让储能参与所有时段优化好很多。

3. Matlab代码实现与完整求解流程

3.1 代码目录结构与模块划分

我用Matlab写了一套完整的双层优化程序，代码结构清晰拆成五个模块。刚开始写的时候只有三个脚本，耦合在一起，调试一次要跑二十分钟，改一个参数全盘重跑，效率极低。下定决心重构之后，调试效率提升非常明显。

code复制distribution_optimization/
│
├── main.m                 % 主程序入口
├── config/
│   ├── system_data.m      % 配电系统参数（IEEE 33节点）
│   ├── pv_data.m          % 光伏出力时序数据
│   ├── load_data.m        % 负荷时序数据
│   └── algorithm_config.m % 算法参数配置
│
├── upper_level/
│   ├── pso_optimize.m     % 上层粒子群算法
│   ├── initialize_particles.m
│   ├── evaluate_fitness.m % 适应度评估
│   └── update_particles.m
│
├── lower_level/
│   ├── power_flow.m       % 前推回代潮流计算
│   ├── opf_solve.m        % 下层最优潮流求解
│   ├── battery_model.m    % 储能运行约束
│   └── objective_func.m   % 下层目标函数
│
├── scenarios/
│   ├── generate_scenarios.m  % 历史数据读取与典型日生成
│   ├── kmeans_scenario.m     % K-means聚类
│   └── scenario_reduction.m  % 场景削减
│
└── result/
    ├── plot_results.m     % 结果可视化
    └── save_results.m     % 结果数据导出

主程序main.m的流程是：配置初始化→生成场景→上层算法迭代→每轮调用下层评估适应度→迭代结束→后处理与可视化。我在主函数里设置了一个tic/toc计时，每次完整迭代都能看到耗时，方便算法参数调优时对比。

3.2 求解器与优化算法的选型对比

在Matlab生态里，做双层优化可以从三个技术路线里选：

路线一：完全用自带工具。上层用全局优化工具箱的ga或particleswarm，下层用quadprog或fmincon。优点是不用装额外工具，代码可移植性最好；缺点是fmincon处理非凸最优潮流时容易陷入局部最优，而且求解速度一般。

路线二：上层Matlab、下层YALMIP+CPLEX（或Gurobi）。这是目前电力系统学术界的标准配置。YALMIP负责建模封装，把下层的优化问题描述成约束和目标，然后调用高性能商业求解器求解。我实测下来，CPLEX在求解线性化后的最优潮流问题时速度比fmincon快20倍左右，而且稳定性高很多。缺点是YALMIP和CPLEX需要额外下载安装，另外学术使用有授权限制。

路线三：完全用开源工具箱。Matlab平台内可以用MATPOWER做潮流计算，上层用自定义的PSO。MATPOWER的潮流计算非常成熟，各种收敛性处理细节都替你考虑到了。我早期用MATPOWER验证过潮流计算的正确性，后来为了灵活调整目标函数才改为自己写DistFlow方程。

三种路线我都跑过，最终的项目落地选择是：上层用自定义PSO（因为粒子群对边界约束和离散变量的处理比较方便，不容易超界），下层用YALMIP+CPLEX（LP/QP问题求解快，而且能直接读取对偶变量，方便后续做灵敏度分析）。如果你手上没有CPLEX，完全可以用开源求解器代替，比如IPOPT，在二阶锥规划场景下性能也可圈可点。

3.3 关键代码片段：上层粒子群与下层潮流

上层的粒子群算法我简化了标准PSO的实现，核心就三步：初始化、评估、更新。PSO的参数我固定用学习因子c1=c2=1.5，惯性权重从0.9线性递减到0.4，种群规模取30，最大迭代次数100。

matlab复制function [best_pos, best_fit] = pso_optimize(problem)
    % problem包含决策变量边界、约束处理函数、场景数据等
    
    pop_size = 30; max_iter = 100;
    c1 = 1.5; c2 = 1.5;
    w_max = 0.9; w_min = 0.4;
    
    % 初始化粒子位置（0-1变量加连续变量混合）
    n_var = length(problem.ub);
    positions = init_particles(pop_size, n_var, problem.lb, problem.ub);
    velocities = zeros(pop_size, n_var);
    
    % 适应度评估会调用下层优化
    fitness = zeros(pop_size, 1);
    for i = 1:pop_size
        fitness(i) = evaluate_fitness(positions(i,:), problem);
    end
    
    pbest = positions; pbest_fit = fitness;
    [gbest_fit, idx] = min(fitness);
    gbest = positions(idx, :);
    
    for iter = 1:max_iter
        w = w_max - (w_max - w_min) * iter / max_iter;
        for i = 1:pop_size
            r1 = rand(1, n_var); r2 = rand(1, n_var);
            velocities(i,:) = w * velocities(i,:) + ...
                c1 * r1 .* (pbest(i,:) - positions(i,:)) + ...
                c2 * r2 .* (gbest - positions(i,:));
            
            % 越界处理：速度钳制 + 位置反射回可行域
            velocities(i,:) = max(min(velocities(i,:), problem.vmax), -problem.vmax);
            positions(i,:) = positions(i,:) + velocities(i,:);
            positions(i,:) = enforce_bound(positions(i,:), problem);
            
            % 重新评估
            fitness(i) = evaluate_fitness(positions(i,:), problem);
            if fitness(i) < pbest_fit(i)
                pbest_fit(i) = fitness(i); pbest(i,:) = positions(i,:);
            end
        end
        [min_fit, idx] = min(pbest_fit);
        if min_fit < gbest_fit
            gbest_fit = min_fit; gbest = pbest(idx, :);
        end
        fprintf('Iter %d: best fitness = %.4f\n', iter, gbest_fit);
    end
end

这里有个容易踩的坑是：0-1变量在粒子群更新中往往会变成0.6、0.35这种中间值，直接四舍五入会导致搜索在整数边界附近震荡。我的处理方法是把连续变量和0-1变量分成两个维度段处理，0-1变量部分在每次更新后随机取整，但保留一个概率阈值——比如0.7以上取1、0.3以下取0、中间值以概率随机取，增加探索性。这个方法虽然简单，实测比直接四舍五入收敛速度快了不少。

下层的潮流计算我用前推回代法，这是辐射状配电网最经典的潮流算法。核心思路是先假定各节点电压为额定值，从末端向首端逐段累加功率损耗求得支路功率，再从首端向末端逐段计算电压降落，迭代到收敛。

matlab复制function V = backward_forward_power_flow(branch, node, P_load, Q_load, P_gen, Q_gen)
    % 输入：支路数据、节点数据、负荷与分布式电源注入功率
    % 输出：各节点电压幅值（标幺值）
    
    max_iter = 100; tol = 1e-6;
    n_node = size(node, 1);
    V = ones(n_node, 1); % 平启动
    
    for iter = 1:max_iter
        V_old = V;
        
        % 前推：计算支路功率
        S_branch = zeros(size(branch, 1), 2); % [有功, 无功]
        for k = size(branch, 1):-1:1
            head = branch(k, 1); tail = branch(k, 2);
            % 汇集下层节点的功率
            P_sum = P_load(tail) - P_gen(tail);
            Q_sum = Q_load(tail) - Q_gen(tail);
            % 加上以tail为起点的所有支路功率
            for j = 1:size(branch, 1)
                if branch(j, 1) == tail
                    P_sum = P_sum + S_branch(j, 1);
                    Q_sum = Q_sum + S_branch(j, 2);
                end
            end
            S_branch(k, 1) = P_sum;
            S_branch(k, 2) = Q_sum;
        end
        
        % 回代：计算电压降落
        R = branch(:, 3); X = branch(:, 4);
        for k = 1:size(branch, 1)
            head = branch(k, 1); tail = branch(k, 2);
            V_tail = V(head) - (R(k) * S_branch(k, 1) + X(k) * S_branch(k, 2)) / V(head);
            V(tail) = V_tail;
        end
        
        if max(abs(V - V_old)) < tol
            break;
        end
    end
end

前推回代法处理辐射状配电网非常高效，单次潮流计算在33节点系统上只需要几十毫秒。但要注意它天然假设网络是辐射状的，如果配电网结构是环网，就需要改成牛顿-拉夫逊法。实际项目中很多工业园区配电网是环网结构，这点需要在建模前确认清楚。

4. 关键参数设置与算例验证

4.1 IEEE 33节点系统基准数据

我用的是IEEE 33节点标准算例，这是配电网规划研究中使用最广泛的基准系统。系统额定电压12.66kV，总有功负荷3715kW，无功负荷2300kvar，有33个节点、32条支路，拓扑结构为辐射状。

几张关键参数表：

节点电压基准和负荷数据我直接引用了IEEE官方数据，接入光伏和储能后的改造方案是在原始数据基础上做的。需要特别注意的是，原始算例的基准功率是10MVA，所有数据都需要转换到标幺值体系，这个转换出错的概率非常高，我建议写一个单独的参数转换脚本，把有名值转标幺值的过程自动化。

4.2 光伏和储能参数如何标定

光伏系统参数按照目前商用主流组件标定。单块组件的峰值功率我取550Wp，组串式逆变器效率取98%，光伏阵列的效率（考虑灰尘遮挡、温度损耗、线损等）取0.85。光伏安装的上限我设置为节点峰值负荷的50%，这个限制来自配电网接纳能力的常规判断——超过这个比例，即使有储能配合，电压调节压力也会很大。

光伏出力的时序曲线我采用的是典型城市（北方地区）的实际气象数据，把年辐照度换算成等效利用小时数大约1300小时。换算方法很简单：年发电量等于峰值日照小时数乘以光伏装机容量，而峰值日照小时数在北方平原地区大约在1100到1500小时之间。换算成出力曲线后，再叠加温度对组件效率的影响修正。

储能电池我按磷酸铁锂路线标定。单体电芯额定电压3.2V，系统直流侧效率95%，PCS变流器效率97%，因此储能系统的综合效率在92%左右，这是充放电双向都含的效率。储能SOC工作范围取10%到90%，循环寿命按6000次考虑，DOD（放电深度）80%条件下。

4.3 三种配置方案的结果对比

我设计了三个方案对比：方案一是无分布式能源的原始网络；方案二是只装光伏不装储能；方案三是光伏和储能双层优化配置。

这个结果很有代表性。只装光伏时，光伏装机容量虽然大，但网损降低效果不如"光伏+储能"的协同方案，而且电压支撑能力有限，年综合费用反而高。双层优化配置的优势体现在：适当减小光伏容量，用储能来抬升夜间低谷电压、削减中午光伏出力高峰的反向潮流，用更少的投资实现了更好的运行效果。

投资收益对比方面我还额外算了一个指标——单位投资网损降低量。原始光伏方案每万元投资降低约8.4MWh网损，双层优化方案每万元投资降低约15.3MWh网损，接近两倍的效益提升。这个指标在给工业园区做方案汇报时特别有用，财务人员一听就能理解。

5. 实际项目中的常见问题与排查技巧

5.1 求解不收敛与迭代震荡

双层优化最常见的问题是迭代不收敛或者收敛曲线呈现锯齿状震荡。我最初调试PSO参数时，连续几代目标函数值来回跳动，花了半天时间排查发现原因在上层粒子越界后的处理方式太粗暴。

直接钳制粒子位置到边界上，会导致大量粒子聚集在边界附近，种群的多样性迅速下降，后续迭代基本丧失搜索能力。正确的做法是采用反射机制：粒子越界后以边界为镜面反射回可行域，保持粒子在空间中的分布特性。另外，对速度的钳制也非常重要，速度上限我取变量范围宽度的20%到30%，过高会导致粒子飞出太远，过低会导致搜索停滞。

还有一个稳定性问题来自下层求解器偶发不收敛。下层的最优潮流问题虽然凸化后易于求解，但在某些特殊的储能SOC状态或光伏出力组合下，可能因为松弛过紧导致求解失败。我的处理是在下层求解外层套一个try-catch结构，返回一个标识位。上层遇到下层无解时将该粒子的适应度设为一个极大值，相当于淘汰这个方案，同时记录日志方便定位问题在哪里。

5.2 场景削减导致结果失真

场景削减的粒度直接决定结果的准确度。我曾经只用4个季节性典型日（春夏秋冬各一个）来模拟全年运行，跑出来的网损降低比例比用真实8760小时数据低了不少。原因是典型日抹平了日内天气波动，特别是夏季多云天气下光伏出力的剧烈波动被完全忽略了，储能的实际调节需求被低估。

后来我改用K-means聚类加后向削减法处理场景数据：先把全年数据按小时特征聚类成20个候选场景，再用快速前向选择算法缩减到10个场景。缩减后的场景集合能覆盖95%以上的真实出力分布，计算时间只增加了一倍，结果精度大幅提升。

在做场景削减时有一个关键细节：不同特征变量的量纲差异极大。光照辐照度数值在0到1kW/m2之间，负荷在几十到几百千瓦之间，如果不做标准化直接聚类，距离度量几乎被负荷数值主导，光伏特征就白聚类了。我处理此类问题都会先做z-score标准化，聚类结束后再反变换回实际物理量。

5.3 储能SOC越界与容量配置不匹配

储能SOC越界问题是我在实际复现中踩过的一个深坑。下层的储能运行约束虽然设置了SOC上下限，但由于我最初用的是SOC线性近似模型——把电量平衡写成SOC(k+1) = SOC(k) + P_cheta_chdt - P_dis/eta_dis*dt，忽略了电池容量随时间衰减的因素，长时间仿真后SOC出现了缓慢漂移，最终在第600多个小时越界。

排查后发现问题的根源在储能容量衰减模型缺失。规划周期按20年考虑，储能电池在前5年的容量保持率大约是95%，到第10年可能衰减到80%以下。如果规划阶段不考虑容量衰减，算出的储能容量在运行后期实际可用容量不足，SOC就容易顶到上限。

修正方案是在储能模型中引入容量衰减系数，用年衰减率0.8%线性近似，并在上层目标函数中增加储能更换成本的期望值。这样算出来的储能配置容量比不考虑衰减时高了约10%，但这个容量才是真正能跑完整个项目周期的可靠值。

5.4 参数调优的几个工程经验

做了这么多轮实验，总结几条实打实的参数调优经验：

第一，罚系数的标定要结合目标函数量纲。不同算例的目标函数数值量级不同，固定的罚系数在33节点系统上可能有效，换到123节点系统可能就失效。保险的做法是先跑一次不罚约束的松弛解，看目标函数量级，按这个量级的100倍设罚系数初始值。

第二，粒子群的速度边界要配合边界处理策略。反射机制下速度上限可以放宽到变量范围的40%，钳制机制下建议20%到30%。过高的速度上限配合钳制机制会导致粒子在边界附近来回弹跳，浪费大量迭代次数。

第三，下层的求解精度不用设太高。规划阶段的误差在1%以内对上层方案影响很小，但求解时间会显著缩短。我把CPLEX的MIP Gap设为1%，双层的单次完整迭代从40秒缩到12秒，整体方案基本不变。这个思路在工程场景下特别实用。

第四，结果的可视化不能省。我每次跑完都把电压分布图、各节点接入容量图、时序功率曲线和SOC曲线画出来，一张图按节点排序检查接入方案是否有邻接节点同时部署的情况——如果有两个相邻节点同时装光伏，大概率可以合并成一个节点，这是优化器经常给出的"不经济方案"，从工程视角看并不合理，需要在后处理里人工修正。

最后说几句实在话

这套双层优化框架我从第一版跑到现在，最大的体会是：模型不是越复杂越好，而是越贴合实际问题越好。刚开始时我刻意加了很多细节——负荷不确定性、光伏预测误差、储能寿命衰减、需求响应，模型越来越庞大，结果反而越来越难解释，评审老师的质疑也越来越多。后来我学会做"层次化"的模型建立，先跑通基础版本，验证核心思路，再逐步叠加场景和约束，每一步都对比加细节前后的结果差异，这样才能清楚知道每个模型环节到底贡献了多少优化空间。

另外一个给新人的建议是：做这类项目，电网基础比算法重要。我见过很多同学把PSO、遗传算法写得花团锦簇，但对配电网潮流、电压调节、逆功率保护的物理含义理解不够，导致优化结果虽然数学上最优，工程上却没有实施价值。做分布式能源规划，不仅要懂优化，更要懂电网——这也是这个方向比较稀缺的复合能力。

如果你正在做类似课题，建议先从IEEE 33节点系统入手，把双层框架跑通，再逐步替换成实际工程数据。数据格式上多花点心思，做一次标准化处理，后续扩展案例会省很多时间。这套代码我已经在多个项目里复用过了，框架改起来非常灵活，如果你想在一个具体方向深入，随时可以沿着我上面说的某个模块继续挖下去。