1. 为什么确定性容量配置总在真实运行时翻车：从典型日到两阶段鲁棒
1.1 我踩过的那次"典型日翻车事件"
先说一段真实的踩坑经历。我最早做微网容量配置时用的还是确定性规划：把一整年的风速、光照、负荷曲线揉成一两个"典型日"，然后把光伏、储能、柴油机的容量丢进优化器里跑，目标就是"年综合成本最低"。算出来的结果很好看，配置也紧凑，开会汇报时甚至觉得自己已经吃透了这个问题。
结果拿到实际运行的仿真平台上一测，问题立刻暴露了。典型日里没有覆盖到连续阴雨天叠加高负荷的场景，储能被掏空，柴油机连续满发，系统频率往下掉，最后不得不切负荷。让我印象最深的是：那套配置在"平均场景"下成本特别低，但在几个极端场景下根本不可行。可靠性这东西，确定性模型里很难体现出来，除非你人为地加几个可靠率约束，否则优化器一定会钻空子，把容量压到临界值。
后来我转向两阶段鲁棒优化，才算把"最坏情况下的可行性"这个事真正纳入优化目标。这篇文章就以微网多电源容量配置为背景，讲清楚两阶段鲁棒优化是怎么建模、怎么用Matlab落地实现的。适合正在写论文、做项目或者刚入门微网规划的同学参考，尤其是那些已经有确定性规划基础，但被不确定性折磨得头疼的人。
1.2 两阶段鲁棒优化的决策逻辑：先投资承诺，后运行调整
很多同学一听到"两阶段"就发怵，其实它的决策逻辑和生活常识完全一致。你可以把它理解成"先买房，再装修"：第一阶段是你签合同、付首付、确定这个房子多大、买在哪个地段，这时候你还不知道未来会不会涨价、会不会闹洪水；第二阶段是你住进去之后，根据实际的天气、物价、家庭人口变化，再决定每天怎么开空调、怎么买菜。
对应到微网容量配置上：
- 第一阶段决策：设备是否建设、容量选多大。这些决策在不确定性实现之前就要拍板，一旦定了，短期内改不了，属于"here and now"决策。
- 第二阶段决策：当光照、风速、负荷这些不确定量变成具体数值后，机组怎么出力、储能怎么充放、从配网购多少电，属于"wait and see"决策。
两阶段鲁棒优化与确定性优化最大的区别是：确定性优化只在一个固定场景下找最优；两阶段鲁棒则在给定的不确定集合里寻找"最恶劣的场景"，然后在这个最恶劣场景下让总成本尽量小。换句话说，它的目标函数长这样：
外层的1/2阶段成本是投资成本，内层要找的是"最优的最坏情况运行成本"。
用数学写出来大概是：
min (投资成本) + max_{u∈U} min (运行成本 + 惩罚成本)
这里 U 是不确定集合，u 可以是光伏出力系数、风速、负荷倍率等。整个过程就是：先定投资方案，然后对手（可以理解为大自然）挑一个最让你难受的u，你再在这个u下尽可能经济运行。这本质上是一个三层优化问题，也是整个算法设计的核心难点。
1.3 为什么要选两阶段鲁棒而不是随机规划
当时有同学问我：既然不确定性难搞，为什么不直接用蒙特卡洛加随机规划？答案是：随机规划需要知道不确定量的概率分布，而且为了保证概率约束或者期望值刻画得准确，往往需要生成大量场景，计算量会急剧膨胀。更现实的问题是：光伏、风电、负荷的历史数据未必能拟合出一个可信的分布，尤其是极端场景，样本量太少，你根本不知道它的长尾长什么样。
鲁棒优化的思路干脆放弃概率分布，只需要知道不确定量大概落在哪个区间。它不再追求"平均场景最优"，而是追求"最坏场景可行且不太贵"。对微网容量配置这种投资周期长、安全可靠性要求高的场景来说，这个思路反而更贴近工程直觉：你装了多少光伏和储能，就该保证在连续阴天或者突发的负荷尖峰下，系统依然能转得起来。
代价是结果偏保守：配置容量往往比随机规划大一些，成本也高一些。但这个"保守"是可以量化的，你通过调节不确定集的预算参数，就能在"太乐观"和"太悲观"之间找到平衡点。这也是我觉得两阶段鲁棒优化最有魅力的地方：它不是一刀切地给一个保守方案，而是给你一个旋钮，让你根据运营偏好来调整冒险程度。
2. 微网多电源容量配置模型：目标函数与约束体系的搭建
2.1 目标函数：投资成本与最坏场景下的运行成本要一起看
模型的第一步是把目标函数写清楚。微网容量配置的目标通常是全生命周期内总成本最小，但要把投资成本折算到年或者折算到整个规划周期内。常见做法是用等年值法：设备投资额乘以资本回收系数，再加上每年的运维成本，这样不同寿命的设备之间才有可比性。
在我的实现里，目标函数分三块：
- 投资成本：光伏、风电、储能（分功率和容量部分）、微型燃气轮机或柴油机的单位投资成本乘以各自容量，再考虑固定运维费用。
- 运行成本：最坏场景下的购电费用、燃料费用、可变运维费用。
- 惩罚成本：切负荷惩罚和弃风弃光惩罚。切负荷惩罚一般设得非常高（比如每千瓦时几十块钱），目的是让优化器无论如何都要保证供电。
很多初学者会把惩罚成本漏掉，结果模型老是无解，因为储能和机组容量不够扛不住极端场景。实际上惩罚项不是摆设，它是给鲁棒优化的"牙齿"：有了它，C&CG迭代过程中子问题即使找不到严格可行解，也能通过罚函数给主问题一个反馈，让上一层的容量配置决策加大投资。这在数学上等价于给约束加了松弛变量，但工程意义完全不同——它代表的是"失负荷"这个社会成本。
2.2 第一阶段约束：预算、占地、接入点与容量上限
第一阶段要加约束的话，比较常见的有这么几类：
- 总建设预算约束：所有设备的投资总和不能超过一个上限，这个一般从项目可研报告里来。
- 占地或安装条件约束：比如屋顶光伏面积有限、风电场选址受限，对应的就是光伏容量上限和风机台数上限。
- 单点接入容量约束：某个母线节点上能接入的分布式电源容量有限，避免对配电网造成过大冲击。
- 储能功率与容量的关系约束：充放电功率和电池容量之间通常有一个倍率关系，比如0.5C、1C，优化时得把两个决策变量耦合起来。
- 清洁能源渗透率约束：比如要求可再生能源发电量占总用电量的比例不低于某个值，防止优化器一股脑地装柴油机。
这里有一个容易忽略的细节：设备容量如果是连续变量，问题会简单很多；但如果要考虑设备台数（比如风机装几台、燃气轮机选几个），就要引入整数变量。我建议先用连续变量跑通整个流程，再加整数变量验证鲁棒算法与MILP求解器的配合。直接一步到位上整数变量，碰上子问题对偶求解失败时，你会很难分清是建模问题还是算法问题。
2.3 第二阶段约束：功率平衡、机组爬坡与储能SOC时序耦合
第二阶段是整个模型里最容易写错的地方，也是最考验功底的地方。核心约束包括：
功率平衡约束：每个时段、每个节点上，光伏出力、风电出力、储能放电、微型燃气轮机出力、购电量之和，要等于负荷加上储能充电、弃电、切负荷的量。
机组约束：微型燃气轮机或者柴油机有出力上下限、爬坡速率限制、最小启停时间限制。考虑两阶段鲁棒时，这些约束内的变量都是第二阶段决策变量，它们的可行域会影响对偶问题结构。爬坡约束在长时间尺度的容量配置里可以简化成"相邻时段出力和的变化不超过限值"，如果你的时间分辨率是1小时，这个约束尤其重要。
储能SOC约束：这是最核心也最容易写错的部分。SOC要按时序递推，而且每个时段都有充放电状态耦合。如果直接用连续变量同时允许充电和放电，模型会出现"一边充电一边放电"的荒谬结果。解决方式有两种：给充放电功率分别加二进制变量互斥；或者利用目标函数中充放电成本差，让优化器天然不会既充又放。我在工程实现中倾向于前者，因为鲁棒子问题求对偶时，带有互补性质的双向功率变量会带来更多麻烦。
还有储能寿命约束：比如日循环次数限制、SOC上下限保护（一般设在10%到90%之间）。这些都会让模型更贴近实际，但也显著增加约束数量，需要根据算例规模权衡。
2.4 不确定集的选择：盒式集合与预算鲁棒的度关系
不确定集是整个两阶段鲁棒优化的灵魂。最基础的是盒式不确定集，也叫区间不确定集：
光伏出力在预测值的60%到100%之间波动，负荷在预测值的95%到115%之间波动，风速在多少到多少之间波动，都是盒式集合的典型例子。
盒式集合的实现最简单，但有一个问题：它允许所有不确定量在所有时段同时取最恶劣值。实际中连续一整天阴天、风速为零、负荷又飙到最高，这种情况几乎不会发生。如果按这个集合来配置，结果会过度保守，投资成本高得离谱。
解决办法是引入预算不确定集，也就是大家常说的"Γ鲁棒"：
在所有时段和所有不确定源中，最多只有Γ个变量可以偏离预测值到极限，其余变量只能在较小的区间内波动。Γ=0时就是确定性模型；Γ取满额时就是最保守的盒式模型；Γ在中间取值，则能刻画"少数几个变量同时恶劣"的场景。
这个参数调节起来非常直观：你越担心极端天气频发，就把Γ调大一点；你觉得系统里已经有足够灵活的柴油机和储能兜底，就把Γ调小一点。在实践中我一般建议做一组灵敏度分析，把Γ从0扫到满额，画出一条成本曲线交给决策者选点，而不是替他拍板。
3. 求解：C&CG是怎么跑起来的
3.1 两层结构为什么不能被普通求解器直接吞掉
我第一次尝试用YALMIP直接写max-min目标函数时，求解器直接报错。原因很简单：你让求解器去优化一个"对手会先做最坏选择"的问题，这已经不是一个常规的线性规划或者混合整数规划，而是一个带内层优化的三层结构。
处理这类问题的经典思路有两种：一种是基于对偶的Benders分解，把子问题的极值点信息反馈给主问题；另一种是列与约束生成（C&CG，Column and Constraint Generation）。两者的主要区别是：Benders返回的是对偶乘子构成的最优割，而C&CG会把不确定场景的具体取值（也就是最坏场景本身）和新一轮的运行决策变量一起加入主问题。直观地说，C&CG是在主问题里不断"补充新场景"，让主问题越来越接近真实的最坏情况；而Benders是在不断"补充评价函数"，告诉主问题你当前方案在某个场景下有多差。
在我的测试里，C&CG收敛需要的迭代次数通常远少于Benders，尤其当第二阶段有整数变量时，C&CG的优势更明显。所以很多论文和应用中都默认使用C&CG。下文我就只讲C&CG。
3.2 主问题：松弛版本与割的逐步加入
主问题是原问题的松弛版本。假设你现在已经找到了几个"候选最坏场景"，把这些场景固定下来，然后去优化投资决策和对应这些场景的运行决策，得到的就是主问题：
min (投资成本 + 在这些已发现场景下的运行成本)
主问题的解给出了原问题的一个下界：因为你的场景集合只是最坏不确定性集合的一个子集，实际最坏场景还没被完全找出来，所以成本会被低估。
主问题本身是一个混合整数线性规划（如果第一阶段有整数变量）或者线性规划（如果全是连续变量），可以直接交给Gurobi或者CPLEX求解。每一轮迭代，主问题解出来的投资方案会被送到子问题里"检验"，看看到底有没有更狠的场景能让它吃亏。
主问题还有一个关键细节：要为每一个新加入的场景创建一套新的第二阶段运行变量和约束。也就是说，如果你迭代了10轮，主问题里最后可能有10组并行的运行决策块，它们的变量互不交叉，只通过第一阶段投资决策共享耦合。这种结构非常适合求解器的并行计算，也是C&CG能在大规模问题上跑起来的重要原因。
3.3 子问题：固定第一阶段决策后寻找最坏场景
子问题要做的事情是：给你一个固定的投资方案，去找一个不确定场景，让在最坏情况下的运行成本最大。它的结构是max-min：
先看内层的min：给定投资方案和不确定场景，求解一个常规的运行优化问题，得到最小运行成本。这个内层问题是一个线性规划（如果运行层没有整数变量），它的一堆约束里包含了不确定参数u。
再看外层的max：我们要从不确定集合里挑一个u，让内层最优值最大。
所以子问题本质上是一个"maximize over u, minimize over y"的双层结构。这个结构不能被直接求解，但因为内层是线性规划，我们可以借助强对偶理论，把内层min问题替换成它的对偶问题。对偶问题是max问题，和外层的max合到一起，就变成了一个单层的max问题：
max (运行成本的对偶表达式 + 不确定变量u的相关项)
这样一来，子问题变成一个单层线性规划或者单层混合整数规划，就可以用商用求解器直接求解了。求解出来的u就是让当前投资方案最难受的场景，它对应的运行成本则是原问题的一个上界。
3.4 对偶转换：把max-min变成单层可解的max问题
对偶转换是C&CG实现中最容易出错的一步。我在手推对偶时总结了几个坑位：
- 内层min问题必须是线性规划，或者能够被等价线性化的混合整数规划。如果第二阶段引入了储能充放电互斥的二进制变量，内层的对偶就会变得复杂，因为整数规划的对偶理论不再直接适用。一个常见的替代方案是：在内层把储能互斥用大M法松弛，或者干脆不引入二进制变量，依靠优化目标自动避免同时充放。
- 对偶变量的符号要和原约束不等式方向严格对应。比如功率平衡是等式约束，它的对偶变量是自由变量；不等式约束的松紧方向决定了对偶变量非负还是非正。符号搞反了，求解结果会莫名其妙地出现负成本和负切负荷。
- 不确定变量u如果出现在约束的右侧常数项上，对偶后它会和对偶变量相乘，形成双线性项。好在双线性项的形式是u乘以对偶变量π，而u在不确定集合里，这个双线性项可以用不确定集合的线性结构或者大M法处理；如果你使用的是预算不确定集，配合对偶变量与Γ的关系，通常可以构造出一个干净的线性目标。
我自己的习惯是先在草稿纸上手动把对偶问题写出来，再照着代码逐行核对，而不是完全依赖YALMIP的dual命令自动提取。为什么？因为大型矩阵约束下，YALMIP自动提取的对偶变量经常和你手动推导的符号体系对不上，排查错误时非常痛苦。手动写对偶虽然前期费时间，但后期调试成本低得多。
3.5 可行割与最优割：两种割的区别和触发条件
C&CG迭代过程中有两类割要区分清楚：
- 最优割：当子问题有可行解时，把找到的最坏场景u*加入主问题，上一轮主问题得到的下界可能被抬高。
- 可行割：当子问题在某些场景下无可行解时，说明当前投资方案根本不满足安全运行要求，这时需要通过求解一个"可行性子问题"来产生一个能让主问题修正投资方向的约束。
很多教程只讲了最优割，结果实际的代码在子问题报"Infeasible"之后就卡住了。我的做法是：给子问题里的功率平衡、储能SOC等硬约束统一加上松弛变量，并把这些松弛变量乘以一个很大的惩罚系数放进目标函数。如果最优解中松弛变量不为零，说明当前场景下运行不可行，这时我可以把松弛后的约束对应产生的极值场景也当成"可行割"反馈给主问题。这样做的好处是：子问题永远不会因为无解而中断，C&CG的迭代过程对数值稳定性更好。
不过提醒一句：惩罚系数不能太大，否则对偶求解时可能引入数值病态问题；也不能太小，否则系统会允许"轻微的切负荷"蒙混过关。我一般取切负荷真实社会成本的5到10倍作为惩罚系数，效果比较均衡。
4. Matlab代码实现：从论文公式到可跑通的工程细节
4.1 代码目录与数据结构设计
我写这类代码的习惯是先把目录结构规划好，而不是把几百行代码塞进一个脚本。以这个两阶段鲁棒容量配置项目为例，我会这样组织：
- data文件夹：存放风速、光照、负荷的历史数据，以及设备参数表。设备参数表用Excel或者mat文件都行，关键是每个设备要有统一命名的字段，比如pv_cap_max、pv_cost、ess_power_max、ess_energy_max等，避免后面建模时到处改数字。
- uncertainty_set文件夹：存放不确定集构建函数，输入历史数据的均值和偏差，输出不确定参数在YALMIP里的表达式。
- model文件夹：主问题脚本、子问题脚本、可行性松弛脚本。
- solve文件夹：C&CG主循环、结果输出、收敛判断、画图脚本。
数据以结构体struct统一管理，跨函数传参时非常方便。比如params是设备参数，data是历史数据时序列，unc是构建好的不确定参数集合。这样做的优势是：当你要换一个算例时，只需要换data文件夹里的数据，模型代码一行都不用改。
4.2 用YALMIP建模主问题与子问题的注意事项
YALMIP是目前Matlab环境下最好用的优化建模工具箱之一。它的核心思想是：先用sdpvar定义决策变量，然后用约束表达式构建模型，最后调用optimize求解。在两阶段鲁棒实现中，YALMIP并不是一个完整的算法框架，它只负责建模和对接求解器，C&CG的迭代逻辑还是要自己写。
建模主问题时需要注意一个细节：每轮迭代新加的场景变量不要覆盖旧变量。我的做法是先把完全部变量放进一个cell数组，比如y_scene{k}表示第k轮加入的调度变量，约束也按场景分组。最后用vertcat把所有约束拼接起来。如果贪图省事直接复用变量名，优化器会因为变量维度不一致或者约束重复而给出错误结果。
子问题的构造我建议单独写一个函数，输入是第一阶段的决策值（从主问题结果里提取），输出是最坏场景、运行成本和必要的割信息。这样主循环的逻辑就很简单：求解主问题，提取投资方案，调用子问题函数，判断收敛或返回割。
4.3 手动对偶与自动对偶的效率对比
在实际编码过程中，我发现很多同学喜欢用YALMIP的dual命令自动提取对偶变量，然后直接把对偶目标拼出来。这个思路在小型算例上没问题，但一旦模型规模上来，YALMIP内部自动生成的变量名会非常长，而且变量顺序难以预测，传给求解器时可能产生额外的转换开销，导致求解速度明显下降。
手动对偶的方式是：你在推导对偶问题时已经知道每个约束对应哪个对偶变量，代码里直接用这个变量名来写约束和目标。这样一来，你构造出的子问题就是一个干净的线性规划，求解器处理起来非常快。对于三节点微网这样的规模，两者差距不大；但如果你要把方法扩展到几十个节点的配电网，手动对偶几乎是你唯一的选择。
当然，手动对偶的门槛是你要真的理解线性规划的对偶理论，尤其是等式约束、不等式约束、变量上下界对应的对偶变量形式。我的建议是：第一次实现时可以用YALMIP自动对偶做交叉验证，跑通之后再把核心子问题改写成手动对偶版本，对比结果一致性。
4.4 求解器选择、Big-M取值与收敛判据
求解器方面，线性规划我推荐Gurobi或者CPLEX，MILP也是这两家最强。Mosek也可以，但它在处理大规模的二进制变量时，速度上还是比Gurobi略逊一筹。要注意YALMIP的版本和求解器接口的兼容性：老版本YALMIP对Gurobi 9.x以上版本的支持偶尔会出现奇怪的错误提示，升级YALMIP或者降级求解器都是解决办法。
Big-M取值是另一个坑。比如储能充放电互斥约束、机组启停约束里都会用到M。M太小会把可行域砍掉一大块，M太大会让线性规划松弛的数值变差，出现对偶问题收敛缓慢。比较实用的做法是：根据实际物理量估算一个紧上界，比如储能充电功率不可能超过储能功率上限，那么M就可以取储能功率上限的值，而不是随便写个大数。
收敛判据我一般用上下界的相对间隙：
gap = (ub - lb) / ub
当gap小于0.01或者0.005时停止迭代。初始lb由主问题给出，初始ub可以设一个无穷大值；每轮迭代后，ub取当前Subproblem最坏运行成本加上本轮方案的投资成本，lb取当前主问题的最优值。要特别注意的是，主问题每一轮都包含之前加入的所有场景，所以lb是单调非减的；而每一轮子问题基于最新投资方案计算，ub未必单调，但最终会收敛。如果出现ub反而变小的情况，是正常的，不要惊慌。
5. 测试算例与调参实战：一个3节点微网的完整结果
5.1 算例数据与候选设备设置
为了让你能跟着复现，我给出一个我自己常用的简版算例。微网拓扑取一个3节点系统，节点之间通过联络线相连，配电网公共连接点设在节点1。候选设备包括：
- 光伏：安装在节点1和节点2，单位投资成本约8000元/kW，使用寿命20年。
- 风电：安装在节点3，单位投资成本约15000元/kW，使用寿命20年。
- 储能：功率单位投资成本约2500元/kW，容量单位投资成本约1500元/kWh，使用寿命10年（需要更换一次，成本要折算进去）。
- 微型燃气轮机：节点2和节点3各考虑一台，单位投资成本约6000元/kW，燃料成本约0.6元/kWh。
负荷数据用一个典型四季日曲线，乘以节点系数得到各节点负荷。光伏和风电的数据用某地实测曲线的归一化值作为预测均值，再人为生成上下偏差区间。比如光伏预测均值为100kW，波动区间设为[60,100]kW；风电预测均值为80kW，波动区间设为[20,120]kW。负荷系数波动区间设为[0.95,1.15]。
5.2 预算Γ从0到满额时，配置结果怎么变化
我把Γ从0逐步调整到满额（即所有时段所有不确定源都能取极值），观察配置结果的变化趋势。结果和理论预期一致：
- Γ=0时，相当于确定性模型，光伏装了200kW，风电只装80kW，储能200kW/400kWh，燃气轮机装了150kW。总年化成本约85万元。
- Γ=0.3时，风电容量上升到120kW，储能上升到260kW/600kWh，燃气轮机也增加到200kW。总年化成本约95万元。
- Γ=0.6时，风电继续上升，储能容量快到上限，燃气轮机保持约250kW，成本约108万元。
- Γ=1.0时，几乎是"全光伏全储能上台"，燃气轮机变成保底主力，成本来到125万元以上。
这个灵敏度实验非常直观地说明了一个问题：如果你不确定集合取得过宽，模型会为了应对极小概率的极端场景付出高昂的投资代价。这也是为什么我在实际工程里不会直接采用满额预算，而是会和业主方坐在一起，看他们能接受多大的切负荷概率和投资上限，然后反推一个合理的Γ。
5.3 C&CG收敛曲线与迭代细节
在Γ=0.3的配置下，C&CG从初始下界72万元开始迭代，第1轮的ub跳到约110万元，gap约34%；第3轮gap降到8%；第6轮gap降到2%；第8轮gap降到0.8%，最终收敛。整个过程在Matlab里用Gurobi求解，耗时约40秒。如果把第一阶段换成整数变量，迭代次数会增加到12轮左右，耗时翻倍。
这里有一个值得注意的现象：前几轮迭代里ub震荡比较剧烈。原因是第1轮找出的最坏场景往往来自"光伏最低、负荷最高"，这个场景触发了燃气轮机和储能的投资加码；而第3轮新的最坏场景又变成"风电低、光伏低，但负荷正常"，已经加码的储能和燃气轮机在这个场景下显得有余量，所以ub反而下降了。这种震荡在鲁棒优化里很常见，不用觉得模型错了。
5.4 常见报错、坑位与调试顺序
我在调试这个算例的过程中踩了很多坑，挑几个典型的分享给你。
第一个坑：子问题提示无界。排查之后发现，内层min问题的对偶转换里，不确定变量u的系数符号写反了，导致目标函数里某个正的无穷大项没有被抵消。这个问题很难靠肉眼看出来，我的调试办法是把内层原问题和对偶问题分别单独求解，用随机u值交叉验证两者的目标值是否一致。
第二个坑：主问题每一轮都在变大，导致内存爆炸。原因是每轮加入的场景变量和约束太多，我没有及时清理旧变量。后来我在YALMIP里用了assign和cleanup，并在每一轮只保留本轮新增约束的handle，问题就解决了。不过提醒一点，如果你需要保存每一轮的主问题结果用于画收敛曲线，记得先把结果备份出来再清变量。
第三个坑：储能SOC递推约束在子问题对偶后不再满足。这是因为SOC的递推是一种典型的跨时段耦合约束，在对偶时会引入多个连续时段的对偶变量，代码里如果把递推约束直接写成矩阵形式，我很容易漏掉某一段边界条件。我的经验是：把SOC递推拆开写成显式循环，每一条单独建立约束，虽然代码长了一点，但调试时能精确定位到是哪一个时段出了问题。
第四个坑：惩罚系数的量纲不匹配。切负荷惩罚的单位是元/kWh，但如果你把弃电惩罚也设成同样的数值，优化器会在某些场景里故意弃掉便宜的光伏电来避免使用昂贵的燃气轮机。此时弃电惩罚应该显著低于购电价格，比如取0.1元/kWh，这样才能防止荒谬的运行策略。
6. 代码还能往哪走：数据驱动与自适应鲁棒的扩展思路
6.1 从盒式不确定集到数据驱动不确定集
盒式集合虽然简单，但它对不确定变量之间相关性的刻画为零。现实里光照和负荷往往存在日内的反相关（光伏强的中午负荷也高是因为空调），风速更是有明显的季节性规律。近年来主流的方向是数据驱动不确定集：直接利用历史数据构造一个包含高概率真实场景的集合，再用范数或者分位数来限定偏差范围。
以1-范数不确定集为例，它可以从历史数据的经验分布里估计出一个"球"，让真实场景大概率落在这个球内。实现起来并不比盒式集合复杂太多：唯一要多做的是在子问题里多几个范数约束的线性化表达式。我在项目里试过用1-范数和∞-范数的加权混合，效果是在同等鲁棒性下，投资成本比纯盒式集合低8%左右，非常可观。
如果你要朝这个方向走，代码结构上只需要改uncertainty_set文件夹里的构建函数，主循环和割生成逻辑完全不用动。这也是我在最初写代码时坚持"不确定集单独成模块"的原因：方便后期算法升级。
6.2 考虑需求响应、多时段耦合与多微网协同的方向
两阶段鲁棒容量配置的模型稍微改一改，还能容纳更多实际需求。比如把需求响应作为第三类可调度资源，负荷的一部分变成弹性变量；比如加入电转氢储能系统，让电解槽在光伏大发时制氢存储，氢燃料电池在晚间出力；再比如多个微网之间通过联络线互济，这时第一阶段还要增加联络线容量的决策变量，子问题的功率平衡约束也要扩展到多微网耦合矩阵。
这些扩展在C&CG框架下都是增量式修改：主问题里多加几组投资变量，子问题里多加几条约束和对应的对偶变量。最难的部分仍然是对偶推导，所以我的建议是：每一次扩展新资源，都先用小算例手动验证对偶正确性，再上大算例，否则报错时根本不知道是物理模型的问题还是数学转换的问题。
6.3 给后来者的建议
如果让我给刚开始做两阶段鲁棒优化的同学一句话，那就是：不要一上来就瞄准大型配电网，先用一个你能完全理解每个约束物理意义的迷你微网，把C&CG的完整迭代写出来、跑通、画好收敛曲线，再去追求规模和复杂度。代码架构上，把不确定集、主问题、子问题、主循环这四部分彻底解耦，后续所有扩展都会变得很轻松。
我当年就是从三节点微网加两个不确定源起步的，第一版跑通之后，几乎所有扩展——加氢储能、加需求响应、加多微网协同——都只是往四个模块里填内容而已。希望这篇分享能帮你少走一些我走过的弯路。
