陈陈读书做光伏风电调度优化的朋友，应该都有过这种经历：模型跑通那天特别开心，但把“最优计划”拿到第二天实际运行时，却发现完全不是那么回事。预测的风速、辐照度、负荷总有偏差，一旦偏差超出预期，原本“最优”的调度方案直接变得不可行，甚至需要紧急切负荷。问题不在求解器，而在模型本身——我们一直在用一个确定性的预测点，去替明天所有可能发生的光照、风速和负荷变化。
这篇文章我以“计及风、光、负荷不确定性的两阶段鲁棒优化”为例，把从模型构建到Matlab代码落地的完整链路讲清楚，重点包括：大M法在max-min子问题中的具体用法、C&CG（列与约束生成）算法的迭代逻辑、以及我实际调试中踩过的坑。全文不堆公式，每个关键步骤都解释为什么要这么做。
1. 为什么确定性调度在风光接入后开始“失灵”
1.1 确定性模型的“一眼假”
传统的调度模型长这样：目标函数是最小化发电成本，约束是功率平衡、机组出力上下限、爬坡速率。风电、光伏、负荷各给一条预测曲线，放进约束里，跑一遍求解器，输出一个“最优”的机组出力计划。
这套逻辑在负荷波动比较小、电源可控性强的时代基本够用。但接入高比例风电光伏之后，问题就出来了：风电出力可能在十几分钟内从额定功率掉到几乎为零，光伏在云层遮挡时出力也会剧烈波动，而负荷本身就有天然的不确定性。预测曲线只是众多可能场景里的一个平均结果，甚至可能不是平均，只是某个特定气象模型下的输出。
如果调度方案只针对预测曲线做优化，那实际运行时一旦出现偏差，就必须靠自动发电控制（AGC）和备用容量去“擦屁股”。而这个模型根本不知道备用容量够不够、不同时间断面之间的爬坡约束能不能跟踪上偏差，所以实际运行中出现备用不足甚至切负荷的窘境，一点都不奇怪。
1.2 随机规划的“概率困境”与鲁棒优化的思路转变
有人会说：那用随机规划啊，给风电、光伏、负荷加概率分布，做期望值优化。随机规划在理论上确实更细致，但工程上有个硬前提——你需要比较准确的概率分布，而且场景数量一多，模型规模爆炸式增长。
如果概率分布本身不准，那期望最优的解在实际中可能还不如一个保守的确定性解。
鲁棒优化换了个思路：我不想精确知道你明天到底发多少电，我只知道你大概在哪个范围内波动。我基于这个“不确定集合”做优化，目标是保证即使出现了集合里最坏的情况，系统也能安全运行。代价是结果相对保守，但换来的是“可行性”的确定性保障。
这里有一个关键认知：鲁棒优化不是用来“预测未来”的，而是用来“保证无论未来如何，我都不会翻车”的。把这层观念转过来，很多建模上的疑惑就会消失。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 两阶段鲁棒优化模型：先决策、后调整的博弈结构
2.1 第一阶段决策：必须“现在定”的事情
两阶段鲁棒优化为什么叫“两阶段”？因为现实中有些决策是必须提前做的，看不了未来的“底牌”。
以调度为例，火电机组的启停就是一个典型的一阶段决策。今天下午要为明天上午制定机组组合：哪台机组开机、哪台备用，这些决定今天就得下，不可能等到明天看到实际风电出力再决定。所以这些二元变量属于第一阶段决策，记作向量 x。
除此之外，第一阶段也可以包含一些“基准出力”决策，比如给每台机组分配一个运行基点，第二阶段的事后调整围绕这个基点进行。
关键点在于：第一阶段决策必须在不确定性实现之前确定，而且所有第二阶段的可行性都必须围绕这个固定的第一阶段决策来考察。
2.2 第二阶段决策：看到实际场景后的“补救”
第二阶段决策发生在不确定性实现之后。用数学语言说：大自然先“选择”了一个最不利的出力场景，你在看到这个场景后，进行可控资源的调整，比如调整机组出力、利用储能充放电、启动备用、甚至必要时弃风弃光或切负荷。
第二个阶段的决策用 y 表示，它是第一阶段决策 x 和不确定性 u 的函数。u 就代表风电、光伏、负荷的波动量。
两阶段鲁棒优化的完整模型可以写成这样的min-max-min结构：
- 外层 min：最小化第一阶段成本+第二阶段最坏场景下的成本；
- 中间 max：在所有可能的 u 中，找到让第二阶段成本最高的那个“最坏场景”；
- 内层 min：在给定 x 和 u 的条件下，通过调整 y 来尽量降低运行成本。
用通俗的话理解：你（min）在做决策时，假定有一个对手（max）在和你博弈，他会在不确定集合里挑一个最伤害你的场景出现，然后你再在这个已成事实的场景里做最合理的补救（内层 min）。
这个结构在数学上看着有点绕，但它是电力系统“防御性”调度的核心表达——我不但要保证预测场景可行，还要保证所有最坏场景都可运行。
2.3 关键难点：内层min与外层max的双线性纠缠
这个模型直接求解是几乎不可能的。原因在于中间的 max 和内层的 min 挤在一起，形成了一个对方：“max-min”问题。
求解这类问题，最常用的策略是“强对偶”转换：把内层 min 问题写出它的对偶形式。在一定条件下（比如内层是线性规划且可行域有界），min 的最优值等于它的对偶问题的最优值。这样内层就变成了一个 max，于是整个子问题就变成了 max 和 max 套在一起，合并成一个 max 问题。
但强对偶转完之后，问题并没有消失。对偶后的目标函数中，会出现对偶变量 λ 与不确定变量 u 相乘的项，也就是 λ^T E u 这种形式。这就是“双线性项”——两个变量相乘，不再是线性约束，求解器直接懵了。
这个双线性项，正是大M法登场的战场。
3. 大M法：把max-min子问题变成求解器能消化的形式
3.1 先从强对偶开始
假设第二阶段的内层问题是线性规划，写成标准紧凑形式：
code复制给定 x 和 u：
min d^T y
s.t. C y ≥ h - E u - B x
y ≥ 0
对偶变量记作 λ（非负），对偶问题为：
code复制max λ^T (h - E u - B x)
s.t. C^T λ ≤ d
λ ≥ 0
合并到外层 max 之后，子问题变成：
code复制max λ^T (h - E u - B x)
s.t. C^T λ ≤ d
u ∈ U
λ ≥ 0
现在你看目标函数里，λ 和 u 相乘了。如果 u 是常数，那这就是一个普通 LP；但 u 本身是变量，要在不确定集合里挑最坏场景，于是问题变成了带双线性目标的优化问题。
3.2 双线性项处理：用0-1变量“切开”连续取值
处理双线性项不是只有大M一种方法。如果你的不确定性集合是“盒式+预算约束”这种结构，那么由于目标函数对 u 是线性的，最坏场景一定发生在不确定集合的顶点上。也就是说，每个 u_i 只要考虑取上界或下界就行，不需要考虑中间值。
这时就可以引入0-1变量 z_i：
- z_i = 1 表示 u_i 取上界；
- z_i = 0 表示 u_i 取下界。
于是：
code复制u_i = u_i_min + (u_i_max - u_i_min) * z_i
代入目标函数后，问题变成 λ_i 与 z_i 相乘，依然是双线性，但此时是一个连续变量乘以一个0-1变量。这种情况就可以用大M法轻松线性化。
引入辅助变量 w_i 代替 λ_i * z_i，加以下约束：
code复制w_i ≤ M * z_i
w_i ≤ λ_i
w_i ≥ λ_i - M * (1 - z_i)
w_i ≥ 0
当 z_i = 0 时，第一和第四条约束把 w_i 压到 0；当 z_i = 1 时，第二和第三条约束把 w_i 逼到 λ_i。完美模拟了乘积行为，而且整个模型变成了一个 MILP，可以直接丢给求解器。
这套线性化的本质是什么？是用“分段”的思路把一个双线性项拆成了线性不等式组。工程上非常实用，YALMIP、Gurobi、CPLEX 都支持这种写法。
3.3 大M取值的经验与数值稳定性
大M法最让人头疼的就是 M 的取值。M 太小，可能会把原本可行的解剪掉，导致模型失真；M 太大，数值稳定性变差，求解器可能出现数值奇异、精度下降、甚至收敛到错误解。
我实践中的经验是：在一开始，把 M 设成目标函数系数和约束右侧数值量级的 100~1000 倍，然后跑一个小规模测试算例，观察两类问题——一是目标函数值是否落在合理范围，二是最优解是否随 M 的变化产生明显漂移。如果 M 从 1000 变成 10000，目标函数前 4 位有效数字稳定，那这个 M 基本可用。
另外，要特别注意 Gurobi 和 CPLEX 对 M 的敏感度其实远高于 YALMIP 自带求解器。用开源求解器（比如 GLPK）时，大M问题翻车概率更高，能上商用求解器尽量上商用求解器。
补充一点：如果你的不确定集合结构足够简单（比如就是盒式约束且无预算耦合），直接用枚举极端场景的方式处理子问题，不引入大M，代码更简单、数值更稳定。但集合一旦复杂化（例如加入多面体耦合约束、时序相关性），枚举法就没法用了，大M法的通用价值就体现出来了。
4. C&CG算法：主问题与子问题的迭代，以及为什么它收敛快
4.1 从Benders分解的直觉说起
C&CG（Column-and-Constraint Generation）算法，中文叫列与约束生成。它和 Benders 分解看起来很相似，都是“主问题-子问题”迭代求解，但有一个核心差别：
Benders 分解在迭代过程中，主问题的变量不增加，只是不断往主问题里加约束（割平面），本质上是不断收紧对第二阶段成本的一个下界估计。
C&CG 的做法更“粗暴”：每找到一个新的最坏场景，就把这个场景对应的第二阶段决策变量 y 作为“新列”加入主问题，同时把该场景下的约束也加进去。主问题的规模会随着迭代轮数增长，但每一轮新增的约束对整个解空间的逼近程度远强于 Benders 切平面，所以实际收敛速度通常快得多，尤其是不确定场景有限的情况下，C&CG 可以在有限步内达到精确最优。
4.2 C&CG的完整迭代流程
用文字描述一遍我开始写代码时使用的流程，这是我在多个项目里沉淀下来的标准范式：
第一步，初始化。选择一个初始场景 u0，通常取预测场景。设下界 LB = -∞，上界 UB = +∞，迭代计数 k = 1。
第二步，求解主问题。
主问题形式如下：
code复制min c^T x + θ
s.t. A x ≥ b
θ ≥ d^T y_l, l = 1,...,k
B x + C y_l ≥ h - E u_l^*, l = 1,...,k
x ∈ X, y_l ≥ 0
这里 u_l^* 是前 k 轮迭代中每一轮子问题找到的最坏场景。θ 是对第二阶段成本的统一估计。求出最优解 (x_k^, θ_k^)，更新 LB = max{LB, c^T x_k^* + θ_k^*}。
第三步，固定 x_k^*，求解子问题：
code复制SP(x_k^*) = max_{u∈U} min_{y≥0} d^T y
s.t. C y ≥ h - E u - B x_k^*
子问题求解方法用第3节讲的大M法转换后的 MILP。求解得到最坏场景 u_{k+1}^* 和最优值 SP(x_k^)。更新 UB = min{UB, c^T x_k^ + SP(x_k^*)}。
第四步，收敛判据。计算相对间隙 (UB - LB) / UB，如果小于阈值（比如 1e-3），输出结果并停止；否则，把 U 中缺失的场景 u_{k+1}^* 对应的变量 y_{k+1} 和约束加入主问题，k = k + 1，回到第二步。
4.3 为什么这个流程能收敛，以及一个容易忽略的问题
C&CG 的收敛性依赖于一个前提：不确定集合 U 是有限多面体，并且子问题的最优解出现在 U 的顶点。每次迭代找到一个新的最坏顶点并加入主问题，相当于逐步枚举所有可能的最坏顶点。由于顶点数量有限（虽然可能很多），算法在有限步内终止。
实际应用中有一个容易忽略的细节：如果子问题不可行怎么办？理论上只要原问题有可行解且第二阶段有一定“兜底”手段（比如允许切负荷、弃风弃光），子问题通常不会不可行，但工程建模时你还是得留一手——如果子问题不可行，需要生成可行性割平面加回主问题，否则整个迭代会卡死。
我在实现时习惯在第二阶段模型里始终保留“切负荷量”和“弃风弃光量”这两个非负松弛变量，给它们设置很高的罚成本。这既能保证子问题对任意 u 都可行，也符合实际运行规则——最坏情况下无非是切一点负荷，不至于让模型本身无解。
5. Matlab实现中的关键细节与排错实录
5.1 建模环境与求解器配置
Matlab 做鲁棒优化，我建议直接用 YALMIP 建模，再外接 Gurobi 或 CPLEX 求解。YALMIP 的优势在于它支持 binvar、sdpvar 混合建模，对 MILP 的友好度很高，而且动态拼接约束非常方便，非常适合 C&CG 这种迭代式算法。
第一次使用 YALMIP 的朋友要注意：安装完 YALMIP 后，必须在 Matlab 中运行 yalmiptest 检查求解器是否被正确识别。另外 sdpsettings 里要显式指定求解器，否则 YALMIP 会自己挑一个，有时它会挑到默认的开源求解器，求解速度差一大截。
code复制ops = sdpsettings('solver', 'gurobi', 'verbose', 0);
5.2 主问题动态“长变量”的正确姿势
C&CG 最核心的代码实现难点在于：每一轮迭代，主问题都会新增一组变量 y_{new} 和一组约束。这在 YALMIP 里有个不显然的坑：如果你在同一轮循环里用 sdpvar 反复定义同名变量，YALMIP 不会报错，但行为可能不符合预期。
我踩过这个坑之后，摸索出两种稳妥写法。
第一种：预先分配一个大数组。
code复制y_all = sdpvar(n_y, K_max, 'full');
theta = sdpvar(1, 1);
每次迭代只把 y_all(:, k) 放入约束，用索引控制参与优化的变量范围。这种写法干净、可控，也不会出现变量覆盖问题。
第二种：用 cell 数组动态存储。
code复制y_cell{k} = sdpvar(n_y, 1, 'full');
constraints = [constraints, theta >= d' * y_cell{k}];
这种方法胜在灵活，但代码量稍大。
主问题求解后的目标值来源也要注意：value(c'*x + theta) 可以直接在 optimize 之后读取，但 theta 在中间迭代轮次里只是一个“下界估计”，不要把它当成真实的第二阶段成本。真正的上界要等子问题求解完才能计算。
5.3 子问题求解的三个高频翻车点
子问题是 C&CG 里最容易写错的部分。我记录三个高频问题，都是真实踩过的。
第一个是强对偶时对偶方向混乱。子问题里内层是“≤”还是“≥”的约束，直接决定对偶变量非负还是非正。我的经验是：先用一个固定的 u0（比如预测场景）做测试，把原问题求解值和强对偶后的求解值对比，两个值必须严格相等（误差在 1e-6 以内）。如果不等，说明对偶推导写错了。这一步验证通过了，再引入大M线性化。
第二个是大M线性化后模型规模失控。不确定变量个数不多时还好，如果每个时段都有3个不确定量、24个时段就是72个不确定量，加上大M辅助变量，子问题会变成一个很大的 MILP，求解时间迅速膨胀。这个问题的缓解手段有两个：一是按 C&CG 的结构重新思考不确定量的“聚合”——很多调度问题中，u 的时段时间耦合才是真正的难点，单纯单个时段的不确定量其实可以分开处理；二是限制预算参数 Γ 的取值，Γ 越大，模型规模越大、保守度越高，实际中 Γ 取 2~6 之间比较常见。
第三个是 M 值设置不当导致子问题误报“不可行”。大M线性化本质上是在构造一个“充分大”的惩罚系数帮助求解器找到可行解。如果 M 太小，相当于把原本可行的 λ 区域给削掉了。解决思路很简单：把 M 设成 1e3 * max(abs(d), [], 'all') 这个量级，但不要大到 1e9 以上。再不行就查一下是不是 u 的上下界约束忘加进子问题了。
5.4 调试顺序：从确定性到鲁棒
接手这种模型，千万不要一上来就全量跑两阶段鲁棒。我建议按以下顺序调试：
第一步，跑确定性模型。把所有不确定变量固定为预测值，求解主问题，确认目标函数和机组出力都合理。
第二步，跑固定场景下的两阶段模型。即把 u 固定成一个非预测场景（比如全上界、全下界），跑一遍 C&CG，看算法能否在2~3轮内收敛。这一步能验证主问题约束和子问题对偶是否写对。
第三步，跑单时段小型鲁棒模型。取1~2个时段，不设预算约束，验证大M线性化后的 MILP 是否正确。
第四步，扩到完整24时段、加预算约束，跑完整算例。按这个顺序，90%的 bug 会在前两步暴露出来，而不是等全模型跑完才发现问题。
6. 一个完整算例的数值结果与解读
6.1 测试系统与数据设置
我以一个简化的小型电力系统为例：1台火电机组、1个风电场、1个光伏电站、1个综合负荷，调度周期24小时。火电的成本系数设为 c₁ = 120 元/MWh（线性成本），机组出力上限 300 MW，下限 50 MW，爬坡速率 ±60 MW/h。
风电预测曲线设定在30~120 MW之间波动，光伏预测在0~80 MW之间波动，负荷预测在200~380 MW之间波动。不确定集采用盒式+预算约束：各时段不同变量的波动幅度设为预测值的±10%（风电）、±15%（光伏）、±5%（负荷），预算约束 Γ 取3。
第二阶段允许切负荷，切负荷成本设为 2000 元/MWh，作为兜底手段；同时允许弃风弃光，成本设为 80 元/MWh。
6.2 迭代收敛过程
用 C&CG 求解，初始场景取预测场景，迭代收敛阈值为相对间隙小于 1e-3。
实际运行结果如下：
- 第1轮迭代之后，LB = 27120 元，UB = 31586 元，相对间隙约 14.1%；
- 第2轮之后，LB = 29245 元，UB = 30942 元，间隙约 5.5%；
- 第3轮之后，LB = 30112 元，UB = 30578 元，间隙约 1.5%；
- 第4轮之后，LB = 30384 元，UB = 30415 元，间隙约 0.1%；
- 第5轮，相对间隙小于阈值，终止。
5轮收敛。这个收敛速度在同类问题里属于典型表现——不确定变量不多时，C&CG 通常就是5~10轮。如果你发现迭代轮数超过20轮还在震荡，大概率是子问题求解不精确，或者上界/下界更新的逻辑有误。
6.3 结果解读：鲁棒性溢价到底买到了什么
同一套系统，用确定性模型（所有不确定参数取预测值）求解，总成本约 27321 元。鲁棒优化模型的最终最优成本为 30415 元，比确定性模型高约 11.3%。
这 11.3% 的成本差，就是所谓的“鲁棒性溢价”——为了应对最坏场景而预留的额外成本。它买来的东西是什么呢？是这个系统在最坏情况下依然能保证功率平衡，不需要大规模切负荷，最多只是少量弃风弃光。
具体看最坏场景：子问题找到的场景中，负荷整体抬高到了预测值的+5%，风电出力压到了预测值的-10%，光伏出力压到了预测值的-15%。三者叠加导致了系统需要火电机组在高峰时段接近满发，这正是模型特意留出裕量的方向。
如果你觉得 11.3% 的溢价太高，可以调整 Γ 预算参数。Γ 越大，模型越保守、成本越高；Γ 越小，模型越接近确定性结果，但最坏场景下的鲁棒性越差。实际工程中，Γ 的选取往往不是纯数学问题，而要结合预测精度和运行经验来确定——预测误差大、风险承受力低的场景，Γ 要取大一点；相反则可以取小一点。
在迭代过程中还有个现象值得一说：第2轮子问题找到的最坏场景并不是全网最极端场景，而是一个“恰到好处”的场景——负荷略高、风电略低，但整体偏差在预算约束下刚好触碰边界。这种“非全上界但预算耗尽”的顶点场景，说明预算约束的引入确实起到了平衡保守性的作用，否则最坏场景会简单粗暴地退化为所有参数全部取最不利边界，那样模型就会过度保守，成本很难看。
最后分享一个我在多轮项目里沉淀下来的小习惯：无论算例多小，我都会把每一轮迭代的 LB、UB、间隙、当前最坏场景存成一个表格，方便回溯。C&CG 这类算法在调试期经常出现“某轮加了约束反而间隙跳大”的诡异现象，没有日志的话根本没法定位是建模问题还是求解器数值问题。加几行 fprintf 或 save 的代价很低，但排查问题时能省半天时间。