企业官网建设流程全解析

微电网两阶段鲁棒优化经济调度：MATLAB 实现探索

做电力系统优化的人，基本都绕不过微电网经济调度这个话题。而最近几年，两阶段鲁棒优化在微电网调度中的应用越来越火，几乎成了研究热点中的热点。原因很简单：微电网里的风光出力、负荷需求全是变量，传统确定性的调度方法在面对这些不确定性时，往往显得力不从心。很多人在读文献的时候看到“两阶段鲁棒优化”、“列与约束生成（C&CG）算法”、“盒式不确定集合”这些词，感觉每一个字都认识，但连在一起完全不知道该怎么落地到MATLAB代码里。

这篇文章就是我实际用MATLAB实现微电网两阶段鲁棒优化经济调度的一次完整记录。我会从模型怎么建、不确定性怎么描述、C&CG算法怎么迭代，到代码怎么写、常见的坑怎么避，尽量把整个链条讲清楚。无论你是刚接触鲁棒优化的研究生，还是已经在做微电网调度但卡在算法实现阶段的工程师，这篇文章应该都能给你一些实在的参考。

1. 项目全貌与思路拆解

1.1 两阶段鲁棒优化到底在优化什么

要理解两阶段鲁棒优化，先得理解“两阶段”这三个字。说白了，就是把调度决策分成两类：一类是必须在不确定性发生之前就做好的决策，叫“here-and-now”决策；另一类是可以等不确定性实现之后，再根据实际情况调整的决策，叫“wait-and-see”决策。

放在微电网经济调度这个场景里，第一阶段决策通常就是各台机组（比如柴油发电机、微型燃气轮机）的开停机状态和启停计划，这些决策需要提前确定，因为机组的启停需要时间，没法等风况、光照都确定了再临时开机。第二阶段决策则是各机组的实际出力功率、储能系统的充放电功率、与主网交互的购售电功率等，这些可以在实际的不确定性实现之后进行调整。

这么做的好处非常明显：传统确定性调度把风光出力和负荷都当作已知的固定值，一旦实际值偏离预测值，调度方案就可能不经济甚至不安全。而两阶段鲁棒优化考虑的是“最恶劣场景”——也就是在所有可能出现的风光出力、负荷组合中，找那个让运行成本最高的场景，然后在这个最恶劣场景下做优化决策。这样就保证了无论实际情况如何，方案都可行且成本可控。

这种“先决策，后调整，再对抗最恶劣情况”的思路，本质上是在经济性和鲁棒性之间做一个平衡。鲁棒性越强，意味着系统应对不确定性的能力越强，但经济性会相应下降，因为你要为最恶劣的情况预留更多的调节空间和备用容量。

1.2 为什么用列与约束生成算法而不是Benders分解

两阶段鲁棒优化模型的求解，最经典的算法是Benders分解和C&CG算法。很多初学者一上来就翻文献，看到Benders分解的相关文章特别多，就想着直接用Benders分解来解。我在一开始也走过这条路，但实际做下来发现C&CG算法在求解两阶段鲁棒优化问题时，表现要好得多，尤其是对于微电网这种规模的模型。

C&CG算法的核心思想是：主问题（MP）先只考虑有限数量的恶劣场景，求出当前最优解；然后把主问题得到的解传递给子问题（SP），子问题在这个给定解下寻找新的最恶劣场景；如果新场景带来的约束违反了主问题的可行性或最优性，就把这个场景对应的约束和变量加入到主问题中，再次求解。如此循环迭代，直到子问题找到的最恶劣场景不再导致主问题目标函数明显变化为止。

这个算法的优势在于，每一轮迭代都会在主问题中增加一组完整的决策变量和约束，使得主问题越来越接近原问题。相比之下，Benders分解通过不断添加割平面来逼近原问题，但割平面法在处理整数变量时效率会下降。实际测试下来，对于微电网模型，C&CG算法通常只需要几次迭代就能收敛，而Benders分解可能需要几十次甚至上百次。这也是为什么现在大多数两阶段鲁棒优化的研究论文都采用C&CG算法。

从工程实现的角度看，C&CG算法的代码结构也更清晰，主问题和子问题各自独立求解，逻辑分离，便于调试和排查问题。流程图看多了容易晕，我建议先理解核心逻辑：主问题给出一个方案，子问题负责找茬，找到茬就反馈给主问题，让主问题改方案，直到找不出茬为止。

初始化：LB=-inf，UB=+inf，k=0，初始最恶劣场景集合=空集 while (UB-LB)/UB > ε: k = k+1 求解MP问题，得到最优解(x*, η*)，更新LB 将x*传递给SP问题 求解SP问题，得到最恶劣场景u_k*和最优值f* 更新UB = min{UB, c'x* + f*} if (UB-LB)/UB ≤ ε: 收敛，退出 否则：将场景u_k*对应的一组约束和变量添加到MP中 end

上面这个逻辑就是C&CG的骨架，后面所有代码都是围绕这个框子展开的。

2. 数学模型搭建：从物理问题到数学规划

2.1 目标函数与两阶段结构的展开

微电网经济调度的核心目标很简单：让整个系统在一个调度周期内的总运行成本最小。这个总成本主要包括三大块：燃料成本、启停成本、以及与主网交互的购售电成本。

用数学语言来说，目标函数可以写成一个min-max-min的结构：

第一层min对应第一阶段决策，也就是机组启停，尽量降低固定成本。第二层max对应不确定性，也就是在最恶劣场景下系统可能面临的最高成本。第三层min则是在最恶劣场景确定后，系统可以做出的最优经济响应，也就是调整各机组出力、储能充放电、购售电功率，来最小化运行成本。

很多初学者看到这个min-max-min结构就开始头晕，脑子里全是“反过来倒过去”的混乱逻辑。但其实这个结构描述的场景非常自然：你作为微电网调度员，先把机组开停方案定下来（第一层min），然后大自然或者说上帝会跟你作对，把最恶劣的风光、负荷情况扔给你（第二层max），你在接受了这个最恶劣现实之后，还是得赶紧调整出力计划，把损失降到最低（第三层min）。

这三层结构各自对应着实际物理过程中的不同决策层级和时间尺度。机组启停属于慢时间尺度的决策，通常在日前就确定了；不确定性场景是客观环境，没法控制；第三层的出力调整是快时间尺度的决策，需要系统在实时运行中快速响应。

具体到约束条件，微电网的约束可以分为三大类：功率平衡约束、机组运行约束、储能系统约束。功率平衡约束要求任意时刻所有电源出力加上储能放电、购电，等于负荷加上储能充电、售电。机组运行约束包括出力上下限、爬坡速率限制、最小启停时间等。储能系统约束则包括充放电功率限制、SOC状态转移以及SOC上下限。

这里有个非常关键的细节：第一阶段和第二阶段决策通过约束联系在一起。比如机组一旦决定启动，第二阶段才能允许它出力；储能系统在第一阶段的SOC状态会影响第二阶段可用的充放电空间。这种耦合关系正是两阶段模型的精髓所在，也是算法实现中比较难处理的部分。

2.2 不确定性集合的建模细节

两阶段鲁棒优化里，不确定性怎么建模，直接决定了模型的复杂度和求解难度。最常见的做法是盒式不确定集合，也就是给每个不确定参数设定一个区间，比如光伏出力在预测值的±20%范围内波动，负荷在预测值的±10%范围内波动。

盒式集合的表达很简单：

U = {u: u_min ≤ u ≤ u_max}

但这种集合把所有参数的极端情况都考虑了，会导致结果过于保守。因为在实际中，光伏出力不可能同时都达到下限，总有些互补性。为了控制保守程度，常用的方法是在盒式集合的基础上加入预算约束，也就是限制不确定参数偏离预测值的总量不能超过某个阈值。

加入预算约束后的不确定集合是微电网两阶段鲁棒优化的经典配置，基本可以覆盖大多数实际需求。在做MATLAB实现时，我是用YALMIP工具箱来定义这个集合的，配合CPLEX或者Gurobi求解器。YALMIP提供了比较友好的建模接口，可以直接用约束的形式把不确定集合表达出来，不用自己去写对偶转换的矩阵推导代码。

在不确定集合里，还有个细节需要留意：风光出力和负荷的不确定性通常是耦合的。比如风速高的时候光伏出力可能为零（因为多云遮挡），温度和光照的关联也会影响光伏出力和负荷的峰谷关系。在建模时可以先假设这些不确定性参数是独立的，后续再根据实际数据分析它们的相关性并逐步改进模型。

2.3 两阶段模型为什么会自然变成一个多面体形式的鲁棒问题

这个细节值得单独拿出来说。从数学形式上看，两阶段鲁棒优化模型中的第二阶段问题是线性规划（LP），而第一阶段包含整数变量。对于给定的第一阶段解，第二阶段问题就是一个参数化的线性规划。线性规划的最优值函数在参数空间中是凸的分片线性函数，而这个函数的“峰”——也就是最恶劣场景——必然在不确定集合的某个极点处取得。

这个性质非常重要，它直接决定了C&CG算法为什么能够收敛。因为最恶劣场景一定在有限个极点中，所以主问题每增加一个极点场景的约束，就能不断收紧对最恶劣情况的近似。这就是为什么C&CG算法在有限的迭代次数内一定能收敛到最优解。

从代码实现的角度说，这个数学性质也给了我们一个验证算法的思路：可以随机生成大量场景，验证子问题找到的最恶劣场景是否总是在这些随机场景中对应成本最高的那个。如果是，就说明算法正确；如果不是，就要检查对偶转换或者C&CG迭代过程中是否有bug。

3. MATLAB实现全过程

3.1 环境配置与工具箱选型

这部分的实际经验想先说在前面，因为很多人卡在了环境配置这一步。实现两阶段鲁棒优化的MATLAB环境，核心需求本质上只有两条：一是能方便地建模混合整数线性规划问题，二是有能求解MILP的高性能求解器。

先说建模工具箱。我用的是YALMIP，这是一个自由开源的MATLAB优化建模工具箱，支持多种求解器的调用。YALMIP的优势在于语法简洁，能用接近数学表达式的形式直接建模，尤其适合鲁棒优化这种需要反复迭代、动态修改约束和变量的场景。比直接调用CPLEX或者Gurobi的MATLAB接口写矩阵形式的模型要省心得多，不太容易在矩阵维度匹配上出错。

再说求解器。对于MILP问题，我的建议是优先用Gurobi或者CPLEX，两者在性能上差别不大，Gurobi的学术授权申请更方便一些。如果实在装不上商用求解器，可以用MATLAB自带的intlinprog函数作为备选，但小规模算例还能撑住，稍微大一点的微电网模型就比较吃力了。

求解器配置这块，有两点容易踩坑。第一，YALMIP在调用求解器时会自动设置一些默认参数，但有些默认参数并不适合鲁棒优化场景。比如YALMIP默认的MIP gap可能相对宽松，我在跑迭代算法时一般会手动设置更严格的gap，确保内层求解精度足够，避免外层迭代不收敛。第二，如果用的是新版Gurobi，要在MATLAB里设置license路径，否则会报license error，启动日志里也会各种报错。这个在Gurobi和MATLAB的版本配套上需要花点时间处理。

3.2 主问题的MATLAB实现

主问题（MP）在C&CG算法中扮演的角色是：在已知一部分恶劣场景的情况下，求解第一阶段决策和对应的最小总成本。主问题中既包含第一阶段的整数变量，也包含与每个已识别恶劣场景对应的第二阶段连续变量。

在YALMIP里实现主问题的时候，人们最常犯的错误是试图用一个大大的约束矩阵把所有场景一次性表达出来。这样做不仅代码冗余，而且场景多的时候非常容易出错。我的做法是：用一个for循环迭代场景，每个场景单独定义自己的第二阶段变量，然后把目标函数中与场景相关的部分累加起来。

光这样还不够，实际运行中我发现，用场景单独定义变量确实逻辑清晰，但每增加一个场景就意味着增加一组变量和约束，主问题的规模会随着迭代次数的增加而变大。如果初始的微电网模型节点比较复杂，C&CG迭代到第5、6次时主问题的规模可能会膨胀得比较明显，求解时间也会相应变长。这时候可以结合实际情况，看是否需要对模型做简化，或者调整收敛精度。

主问题的目标函数可以写成：

% 第一阶段成本（机组启停成本等） objective = sum(sum(UCost .* u)) + eta; % 加上每个已识别场景下的第二阶段运行成本 for k = 1:K objective = objective + sum(operatingCost(:, k)); end

这里的eta是一个很有意思的变量。在两阶段鲁棒优化的标准形式中，主问题会用一个大写的eta来表示对最恶劣场景成本的估计值，约束条件则要求对于每个已识别的场景，eta必须大于等于该场景的实际运行成本。也就是说，eta是主问题对未来可能成本的一个“上限估计”，C&CG的迭代过程会让这个估计越来越紧，最终与真实的次优解逼近。

在实际建模中，eta用YALMIP的sdpvar定义，并加上一组约束：对于场景k，eta >= sum(operatingCost(:，k))。等所有场景的约束都加完了，再求解主问题。主问题求解完之后，第一阶段最优解x*就拿到了，这个x*将作为参数传递给子问题。

3.3 子问题的KKT转换与对偶实现

子问题（SP）是C&CG算法里最核心、也最复杂的部分。子问题要做的事情是：给定第一阶段决策x*，在所有可能的不确定场景中，找到让运行成本最大的那个场景，同时还要能给出这个场景下最优的第二阶段响应。

直接求解这个max-min问题是不可行的，因为内层的min本身就是一个优化问题，嵌套在外层的max里。标准做法是把内层的min问题通过KKT条件或者对偶理论转化为等价的更易处理的形式。由于第二阶段问题通常是线性规划，最常见的方式是取对偶，把min换成max，这样原来的max-min就变成了max-max，可以直接合并成一个max问题来求解。

在这个对偶转换过程中，有个细节特别容易出错：对偶变量的符号和约束方向和原问题的关系。尤其是当原问题中有等式约束（如功率平衡约束）时，对偶变量是自由变量（无符号限制），转换时要格外小心。YALMIP有一个很方便的功能叫做dualize，可以直接把LP问题转换成对偶问题，省去手写对偶推导的麻烦。但这里有个前提：你定义子问题时必须严格用YALMIP的约束和变量格式，不能混入传统的矩阵操作，否则dualize可能会报错。

另外还有一个常见做法是：不直接对子问题取对偶，而是利用KKT条件，把内层min问题的最优性条件作为约束加入到外层max问题中。这个做法会产生一组互补松弛条件（complementary slackness），这组条件是非线性的，需要通过大M法线性化。在我的实践中，对偶方法比KKT方法简单许多，代码也更好调试，所以推荐对偶路线。

至于子问题中如何处理不确定性集合，我是这样做的：把不确定性参数定义成YALMIP的binvar或者sdpvar，把盒式和预算约束直接写进子问题的约束列表中。这样做的效果是，子问题的优化变量不仅包含决策变量，也包含不确定性参数，优化时会同时搜索最恶劣的场景和该场景下的最优响应。这个做法非常直观：把大自然也当成一个“优化者”，它的目标是最大化成本，而调度员紧随其后目标是最小化成本。

3.4 迭代逻辑与收敛判断

主问题和子问题都准备好了，剩下的就是C&CG的迭代主循环了。这个循环的代码不长，但每一步都值得仔细检查。

整个迭代过程可以按照我之前列出的骨架逻辑来写：先初始化下界LB = -inf、上界UB = +inf，以及一个空的最恶劣场景集合。然后进入循环，求解主问题得到当前最优解和eta，更新LB；把第一阶段解代入子问题，求解子问题得到最恶劣场景和对应的最优成本，更新UB；判断(UB-LB)/UB是否小于设定的收敛阈值（比如0.01或0.001），如果满足就退出循环，否则把新找到的场景对应的变量和约束加入主问题，继续迭代。

这里要特别说明一个判断标准的问题。很多初学者会疑惑：什么时候该用绝对间隙，什么时候该用相对间隙？我的经验是：微电网调度问题的目标函数值通常是几千到几万元这个量级，绝对间隙设0.1元太苛刻，设100元又太宽松。所以核心要看相对间隙，一般设到0.01左右已经能保证方案的经济性误差在可接受范围内。如果你追求严谨的学术结果，可以设到0.001，但相应的迭代次数会增加，求解时间会显著变长。

在实际跑迭代的时候，我发现另一个非常隐蔽的问题：子问题求出的obj_SP是单阶段的运营成本，但主问题目标函数里的eta是针对每个已识别场景的“总成本”。这两者在数量级上如果对不上，就会导致LB和UB的更新逻辑出错，甚至导致收敛判断失效。所以我建议在实现时，把第一阶段启停成本和第二阶段运行成本分开统计，然后在UB上加上第一阶段的固定成本，这样收敛判断才是正确的。这个问题我在这里特别提出来，就是因为我在最初的实现中踩过这个坑，花了一整天才排查出来。

4. 算例演示：一天的调度结果

4.1 参数设置与数据准备

把理论讲了一堆，下面进入实操。我以一个典型的低压微电网为例，看看代码跑出来到底是啥样。这个微电网包含一台柴油发电机、一台微型燃气轮机、一套储能系统，以及光伏和风电，还有与大电网的联络线。

调度周期取24小时，时间步长为1小时。光伏出力和负荷的预测曲线都是典型的日变化形态：光伏在中午达到峰值，负荷在白天和傍晚出现两个高峰。柴油发电机的容量是200kW，燃气轮机是150kW，储能系统容量是300kWh，最大充放电功率是60kW。

关于不确定性参数的设置，我做了两个场景的对比测试：

这个对比设计的目的，是观察预算约束对调度方案保守程度的影响。理论上，加了预算约束之后，最恶劣场景的选择范围被压缩了，总成本应该比纯盒式集合要低。

在设置机组参数时，有一些数据需要仔细处理。比如柴油发电机的燃料成本系数，通常用二次函数aP^2+bP+c来描述，但在MILP中无法直接处理二次项，需要分段线性化。YALMIP没有现成的函数帮你自动做这个分段线性化，所以需要手动构造一组分段线性约束。我的做法是：把出力范围分成10段，每段用线性的斜率逼近二次函数。这个分段数量的选择会影响精度：段数太多会增加约束数量，延后求解速度；段数太少，成本函数的拟合误差会偏大。实测下来10段这个平衡点还不错，能满足大部分论文的精度需求。

4.2 运行结果与调度规律解读

用上面的参数和C&CG算法，我把程序跑起来了。以下是一次典型的运行结果：

第一轮迭代：主问题在没有任何恶劣场景的情况下，得到一个比较乐观的方案，LB约等于2300元。把这个方案代入子问题后，子问题找到了一个让光伏出力非常低、负荷又非常高的恶劣场景，对应成本约为3100元，UB更新为3100元。

第二轮迭代：把第一轮找到的恶劣场景加入主问题后，主问题需要调整机组启停方案来应对这种情况，LB上升到2800元。再代入子问题，新场景的成本为2950元，UB更新到2950元。

第三轮迭代：主问题LB达到2890元，子问题找到的场景成本为2910元，此时(2910-2890)/2910 ≈ 0.69%，小于收敛阈值1%，迭代结束。最终最优调度成本约为2910元。

从迭代过程中可以看到，C&CG算法的收敛速度确实很快，三轮就搞定了。而且每一轮迭代，LB在上升、UB在下降，从两侧逼近真实最优解，最终差距不到1%。这种收敛行为正是C&CG算法的优势所在。

看一下最终的调度方案，有一些规律很有意思。在光伏出力较高的中午时段，柴油发电机基本处于最低技术出力状态，光伏承担主要供电任务，多余的电能会存入储能系统或者卖给大电网。到了晚上光伏出力下降、负荷仍然偏高的时候，储能系统开始放电，燃气轮机启动补足电力缺口。这种调度逻辑和直观想象是一致的，但数字上能精确算出什么时候该让哪台机组启停、储能系统充放电功率该调到多少，这就是优化的价值。

对比场景A和场景B的结果也很有意思：场景A（纯盒式集合）的总成本约为3050元，场景B（加了预算约束）的总成本降至2910元，下降了约4.5%。这说明预算约束在几乎不损失鲁棒性的前提下，能显著提升经济性。原因也很直观：纯盒式集合要求系统在最恶劣情况下也要百分百保障运行，而预算约束允许一些不确定性参数不同时取极端值，相当于给了系统一定的弹性空间。在写论文做对比分析时，这个差异是一个很好的切入点。

5. 常见问题与排查技巧实录

5.1 MATLAB实现中常见的报错与解决方案

在实际编写和调试代码的过程中，有几个错误是我反复遇到的，相信很多做两阶段鲁棒优化的人也都碰到过。这里整理成一个速查表，希望能帮大家少走弯路。

第二个问题值得展开说说。在对偶方法中，如果子问题包含了机组出力与启停状态的乘积项（比如u*P），这本质上是一个双线性项，没法直接对偶。标准的处理方式有两种：一种是引入大M约束，把u*P线性化；另一种是把第一阶段决策看作是外部参数，在子问题中只把连续变量作为优化变量，从而避免乘积项。我推荐第二种方式，因为实现起来更简单，逻辑上也更简洁。

5.2 调试技巧与性能优化经验

调试两阶段鲁棒优化的代码是一个系统工程，这里分享几个我觉得特别有用的技巧。

第一个技巧是步进式调试。我在调试阶段会先固定一个简单场景，比如用确定性模型（即所有不确定参数取预测值）跑一遍，确保约束和目标函数本身没有bug。然后再加入不确定性集合，用C&CG跑两轮，观察第一轮和第二轮的调度方案变化是否符合直觉。如果方案出现剧烈的、没有道理的变化，那一定是约束或目标函数写错了。这种分阶段验证的方法比直接上完整模型要有效得多。

第二个技巧是检查对偶问题的正确性。C&CG的核心依赖于对偶转换的正确性。怎么验证？一个简单粗暴的方法是对比强对偶定理：取一个随机场景，直接求原问题的最优解，再取对偶问题的最优解，看两者的目标函数值是否相等。如果不等，说明对偶推导有误。这个验证我在代码里写成独立的测试函数，每次改完模型都会跑一遍，非常可靠。

第三个技巧是善用多核并行。C&CG的每一次迭代中，主问题求解和子问题求解之间存在依赖关系，没法并行。但如果微电网模型里有多个独立子区域，或者需要对多个场景并行求解子问题，则可以用MATLAB的parfor在这些场景之间做并行计算。我在处理一个含三个微电网互联的扩展算例时，用了parfor把子问题求解时间减少了接近一半。

关于性能优化，还有一个细节：不要每次都从零构建主问题。MATLAB里YALMIP的建模开销不可忽视，尤其在主问题规模变大之后。我采用的方式是：每次迭代都重新构建主问题的约束和变量，因为场景集合变了，新增变量的引入和旧变量的维护变得复杂。实测下来，对于微电网这种规模的问题，重新构建的开销完全可以接受。但如果你面对的是大规模输电网问题，那可能需要设计增量式的约束添加，这里就不展开了。

5.3 求解器选择与参数调优的心得

关于求解器，这里多说几句。Gurobi和CPLEX都是非常优秀的MILP求解器，但在两阶段鲁棒优化的场景里，我的实际体验是：Gurobi在默认参数下通常比CPLEX快一些，尤其是当MILP模型包含大量二进制变量时更为明显。但这不意味着CPLEX不行，它在前置处理（presolve）方面有时比Gurobi更激进，对于某些特定结构的模型反而更快。我的建议是：如果你要写论文做大量算例分析，时间充裕的话可以把两个求解器都跑一遍，选择最快的那个；如果只是验证算法可行性，选一个顺手的就是了。

求解器参数上，还有两个细节提醒一下。MIP gap的默认值一般是1e-4，但如果你在跑C&CG的外层迭代，内层MIP的求解精度不用太高，因为外层迭代本身就会不断修正近似解。设成1e-2或5e-3就可以显著缩短每次内层求解的时间。此外，Gurobi的TimeLimit参数建议务必设置一个合理的值（比如300秒），否则当模型规模变大时，单次求解可能会卡住很久，整个迭代过程看起来就像死循环了。

6. 进阶扩展：从单微电网到多微电网与市场环境

两阶段鲁棒优化这个方法并不局限于单个微电网的经济调度。我做过的一个成功扩展，是将它应用到多个微电网互联的场景。在这个扩展中，每个微电网保留自己的本地决策变量和目标函数，微电网之间通过公共联络线进行功率交换。两阶段的结构依然适用：第一阶段决定各微电网的机组启停计划和联络线功率声明，第二阶段在不确定性场景下调整内部出力并交互功率。

另外一个有意思的扩展方向是考虑需求响应。需求响应可以看作是把一部分负荷从被动的确定值变为可调度的柔性资源。在鲁棒优化的框架下，这需要在第二阶段决策中加入负荷削减或转移的决策变量，并为其设置相应的成本参数。这样做的效果是，当遇到恶劣场景时，除了调整电源出力和储能充放电之外，还可以通过削减可中断负荷来平衡功率，相当于多了一个约束维度上的自由度。

还有一个方向是把两阶段和三阶段结合进来。不过在实际算例中我发现，多阶段模型带来的求解复杂度是指数级增长的，除非业务需求特别明确，否则不建议轻易尝试。先把两阶段的模型吃透，再做简单扩展即可。

7. 写在最后：踩坑多时的几点体会

整个项目从最开始的文献调研，到数学模型推导，到MATLAB代码实现，再到完整的算例分析，我断断续续花了两周左右的时间。回头看，有几个体会想最后分享。

第一个体会是：两阶段鲁棒优化的难点既不在于数学推导，也不在于编程技巧，而在于对物理问题的理解深度。模型中的每一个变量、每一个约束，都要能对应到实际的物理对象和运行要求。如果物理问题想清楚了，数学建模自然水到渠成。

第二个体会：调试优化代码和调试普通程序的思路完全不同。普通程序追求“不报错”，而优化代码不仅要“不报错”，还要“结果合理”。我在调试过程中遇到的大部分问题，最终都不是语法或求解器的问题，而是模型的某个约束写得和物理逻辑相悖。

第三个体会：YALMIP和Gurobi的组合，对于做微电网鲁棒优化研究来说，是一个相当顺手且高效的工具链。但工具永远只是放大器，真正决定一个调度方案质量高低的，还是你对微电网系统本身的理解以及对鲁棒优化理论本质的把握。

最后再分享一个我自己常用的小技巧：在做完C&CG迭代得到最终调度方案后，我会额外写一个验证脚本，随机生成数百个场景，逐一计算实际运行成本，看看是否超过UB。这样做能直观检验调度方案的鲁棒性，也方便在写论文时给出统计性的验证图表。这个小步骤花不了多少时间，但能让结果分析的说服力上一个台阶。