企业官网建设流程全解析

居民负荷调度这个方向，我做过的项目不算少，但第一次在Matlab里把非合作博弈和双层鲸鱼算法揉到一个模型里的时候，还是踩了不少坑。这个标题里的三个关键词——“双层鲸鱼算法”“非合作博弈”“居民负荷分层调度”——每一个单拎出来都是能写一整篇文章的方向，组合在一块的逻辑链条其实非常清晰：先有分层调度的实际需求，再引入博弈论来描述用户之间的利益冲突，最后用双层智能算法来求解这个“上层定价格规则、下层做用电决策”的嵌套优化问题。

这篇文章我想以一套完整的Matlab代码实现为线索，把从建模到仿真的全过程拆开讲清楚。不追求把每个数学推导都穷尽，重点放在“这个模型为什么长这样”“双层鲸鱼算法是怎么把博弈解出来的”以及“代码层面到底该怎么落地”这三件事上。适合电力系统方向的研究生、做需求响应的工程师，以及所有正准备用智能算法求解双层优化的同学参考。

1. 先理清需求：居民负荷调度为什么非要“分层”还要“博弈”

1.1 集中式调度的尴尬：算得动但没人听

很多刚开始接触负荷调度的同学，第一反应是做一个集中式优化：把所有居民的所有用电设备都收上来，全局求一个“最优解”，让整个小区的负荷曲线最平、成本最低。模型很漂亮，约束也容易写，但一到实际落地就发现问题——没有任何一个居民愿意把自己的空调、洗衣机、电动汽车完全交给电网去控制。你算出来的“全局最优”也许是好的，但它牺牲了某些用户的用电体验，人家凭啥听你的？

所以居民侧的负荷调度，本质上不是一个纯技术优化问题，而是一个多方利益博弈的问题。每家每户都是独立的决策主体，都有自己的用电偏好和成本诉求。这个时候再用集中式优化的思路，就有点“算得动但没人听”的意思了。

1.2 非合作博弈的适用场景

非合作博弈这个概念听着唬人，落实到居民负荷调度里其实就三句话：

• 每个居民是一个独立的参与者；
• 每个参与者的目标只有一个——在给定电价规则下，最小化自己的用电成本；
• 参与者之间不结盟、不共享策略，每个人的用电决策都会影响电网负荷，进而影响下一轮的电价或激励信号，所有人都在这种相互影响中反复调整。

典型的非合作博弈求解目标是纳什均衡：每个用户当前的用电策略都是在别人策略不变时的最佳响应，此时没有任何一个用户愿意单方面改变自己的用电计划。这个均衡概念特别契合居民负荷调度——你要的不是“强制大家听电网的”，而是设计一套价格或激励规则，让用户在追求自己利益最大化的过程中，客观上把整个小区的负荷曲线给削峰填谷了。

1.3 分层调度的“层”到底指什么

标题里的“分层”不是指电压等级那套物理分层，而是从决策和功能角度把调度问题拆成三层：

• 电网/售电公司层（上层）：制定分时电价或激励信号，目标通常是削峰填谷、提高新能源消纳率、或者保证售电收益；
• 居民用户层（中层）：收到电价信号后，调整自家各设备的工作时段和功率；
• 设备层（底层）：具体到洗衣机、洗碗机、空调、电动汽车充电桩这些可调度设备的时间窗口和功率约束。

上层和下层的目标不完全一致，甚至直接冲突。售电公司想削峰填谷，居民想省电费，这两者之间不是上下级命令关系，而是“你出价格、我出响应”的博弈关系。这种结构天然适合用优化问题来描述和求解，而且是一个需要嵌套求解的双层优化——上层算一次电价，下层就要针对这个电价做一轮居民最优响应。

从数学上看，这个结构和主从博弈（Stackelberg博弈）是一一对应的。标题里强调的“非合作博弈”主要指居民层内部的关系，而居民和售电公司之间的主从关系，则是双层优化的核心来源。

2. 模型构建：把一个居民小区变成可以编程求解的数学问题

在动手写代码之前，必须把模型里的所有要素都明确下来。我下面的设定是一个典型的居民小区场景，你可以把它当成一个标准模板，后续替换数据即可复用。

2.1 负荷分类与可调节能力建模

居民负荷千差万别，但从调度角度看，只需要按“可调节能力”分成三类：

我在代码实现里把每户的负荷定义成结构体数组，每个用户包含以下字段：

% 用户数据结构定义示例 user.id = 1; % 用户编号 user.P_base = zeros(1, 96); % 刚性负荷功率，96个时段（每15分钟一个） user.appliance.doable = []; % 可转移负荷集合 user.appliance.interruptible = []; % 可中断负荷集合 user.ever = []; % 是否配置电动汽车 user.charge = []; % 储能参数，如果没有则留空

2.2 分层模型的上层：售电公司优化目标

上层决策变量是分时电价向量，维度是调度周期的时段数。如果用15分钟一个时段，一天就是96个时段。电价不是随便变的，需要设置合理的上下限，通常在基础电价的±30%范围内浮动，保证居民的接受度。

上层的目标函数我一般写成：

$$J_{up} = \omega_1 \cdot \frac{\sum_t (P_{load}(t) - P_{avg})^2}{T} + \omega_2 \cdot \frac{\sum_t \left( C_{buy}(t) - C_{sell}(t) \right)}{T}$$

第一项是负荷曲线的方差，削峰填谷的核心评价指标；第二项是售电公司收益，保证模型不只是把负荷拍平，还要兼顾经济效益。$\omega_1$、$\omega_2$是权重，需要根据仿真实验手动调节。

下层决策变量是每户的用电计划，也就是各时段各设备的功率分配。实际代码里，内层的最终输出是每个用户的总负荷曲线 ${P_{u,t}}$，汇总到电网层就形成了系统总负荷。

2.3 下层模型：居民的收益函数与约束

每个居民用户 $u$ 的目标函数如下：

$$\min \quad C_u = \sum_t price(t) \cdot P_{u,t}^{buy} + \lambda \cdot \sum_t \left( P_{u,t}^{dev} - P_{u,t}^{ref} \right)^2$$

其中 $price(t)$ 是上层给定的实时电价，$P_{u,t}^{buy}$ 是用户从电网购电的功率，$P_{u,t}^{ref}$ 是用户期望的原始用电舒适度曲线，$P_{u,t}^{dev}$ 是调度后的实际功率。$\lambda$ 是舒适度惩罚系数——调度不是无限度地把用户的负荷搬来搬去，而是要尊重用户的舒适度底线。

用户的约束条件包括：

• 可转移负荷的调度时间窗约束：洗衣机只能在用户设定的时间窗内运行；
• 可中断负荷的功率和温度约束：空调调节范围不能超出舒适度温度区间；
• 储能设备的SOC（荷电状态）约束：充放电功率限制、容量限制、调度周期末SOC状态约束；
• 购电功率上限约束：用户进户线容量限制。

如果用户配置了屋顶光伏或储能，还需要把发用电功率平衡方程写进去：任意时段，光伏出力+购电+放电功率 = 刚性负荷+可调度负荷+充电功率。

2.4 非合作博弈的纳什均衡表达

把上下层合在一起看，整个模型可以写成一个双层优化问题：

$$\begin{aligned} \min_{price} \quad & J_{up}(price, P^(price)) \ \text{s.t.} \quad & price_{min} \le price(t) \le price_{max} \ & P^= (P_1^, \dots, P_N^) \text{ 满足：} \ & \quad P_u^* \in \arg\min_{P_u} C_u(P_u, P_{-u}^*, price), \quad \forall u \end{aligned}$$

内层的 $P_u^*$ 就是每个居民在给定电价和其他人策略后的最优响应。全系统达到纳什均衡时，没有任何人能通过单方面改变自己的用电计划来降低成本。这个问题的求解难点在于：内层不能用一个解析公式直接算出来，因为用户目标函数是非线性的、约束带不等式、决策变量维度高（一天96个时段，多个设备），只能靠数值优化算法。

这就解释了为什么标题里用到双层鲸鱼算法——外层鲸鱼搜电价，内层鲸鱼搜用电计划，两层算法互相嵌套迭代，这也是目前求解这种主从博弈最通用的做法。

3. 双层鲸鱼算法：内外两层到底怎么配合

3.1 回顾标准鲸鱼优化算法的核心机制

鲸鱼优化算法（WOA）是模拟座头鲸捕食行为的元启发式算法，主要有三种位置更新机制：

包围捕食机制：

D = abs(C .* X_best - X); X_new = X_best - A .* D;

其中 $A = 2 a \cdot r - a$，$C = 2 r$，$a$ 从2线性递减到0，$r$ 是 $[0,1]$ 随机数。

气泡网攻击机制（螺旋更新）：

D_prime = abs(X_best - X); X_new = D_prime .* exp(b .* l) .* cos(2 * pi * l) + X_best;

随机搜索机制：

X_rand = pop(randi(N), :); D_rand = abs(C .* X_rand - X); X_new = X_rand - A .* D_rand;

三种机制按概率 $p$ 和系数 $|A|$ 的大小切换。这套算法在连续优化问题上表现不错，而且参数少、实现简单，特别适合改成双层嵌套结构。

3.2 为什么用双层框架而不是“一揽子”求解

有人可能会问：能不能把所有决策变量（电价+所有用户的用电计划）拼成一个超大向量，用单层算法一起优化？理论上可以，但实践结果通常很差。原因很直接：

• 决策变量维度爆炸。假设50个用户、每个用户60个决策变量，加上96个时段的电价，总维度超过3000，元启发式算法在这种超大规模高维空间里几乎找不到真正的最优解；
• 约束结构被破坏。上下层的约束是耦合的，内层用户的决策必须是对价格信号的最优响应，如果放在同一个优化问题里，无法保证解的博弈合理性——算出来的可能是一个“数学上可行但毫无博弈意义”的点；
• 无法利用问题的天然分块结构。内层每个用户的优化是相对独立的，在单层框架里这种独立性完全体现不出来。

双层框架把问题拆成“上层不断调整电价”和“下层在给定电价下各自优化”两个相对简单的子问题，配合鲸鱼算法迭代求解，是目前兼顾效率和可解释性的最优方案。

3.3 外层鲸鱼算法：搜索电价策略

外层鲸鱼种群里的每个个体，代表一条完整的96时段的电价曲线。个体编码如下：

% 外层个体维度：96个时段 % 取值范围约束：price_min ~ price_max nTime = 96; price_min = 0.3 * ones(1, nTime); price_max = 1.5 * ones(1, nTime); % 初始化种群 for i = 1:N_pop_out pop_out(i, :) = price_min + (price_max - price_min) .* rand(1, nTime); end

计算外层适应度的流程是：把当前个体的电价向量传给内层，调用内层求解每个居民的最优用电计划，再把所有居民的负荷曲线汇总回电网层，计算峰谷差和售电收益的加权和。这个“内层寻优 + 外层评估”的循环，正是双层优化的核心计算瓶颈。

3.4 内层鲸鱼算法：求居民最优响应

内层问题的输入是电价向量，输出是每个用户的用电计划。实际操作中，内层循环不用每个用户单独跑一遍完整算法，我通常采用分层策略：

• 使用同一种鲸鱼算法框架，但针对不同用户结构，每个用户内部的决策变量维度不同；
• 同一电价下，不同用户之间是并行的，可以用Matlab的parfor并行计算；
• 对每个用户，外层给出电价信号后，内层鲸鱼个体编码为该用户所有可调度设备的启停和功率分配。

内层鲸鱼个体的编码方式需要和用户设备结构匹配。举例来说，假设一个用户有洗衣机、洗碗机、空调和储能四类可调度设备，每个设备有96个时段的启停/功率变量：

% 内层个体编码示意（以一户为例） % 洗衣机：96维0-1变量（开关） % 洗碗机：96维0-1变量（开关） % 空调：96维功率变量（0~P_max） % 储能：96维充放电功率变量（-P_dis~P_ch） % 拼接：totalDim = 96 * 4

内层目标函数需要先解码出每个设备的功率曲线，然后叠加刚性负荷，计算购电费用和舒适度惩罚。注意，内层的“最优响应”，是在电价和其他用户的策略都固定时，求这个用户的最优解。我把其他用户的策略固定为上一轮迭代结果，这样每个用户的子问题就可以独立求解，这也是非合作博弈中求最佳响应动力的标准做法。

3.5 完整迭代流程：双层鲸鱼算法的整体框架

整个求解流程用伪代码描述如下：

初始化外层鲸鱼种群（电价向量） while iter <= maxIter_out: for each 外层个体: 把电价曲线下发给内层 for each user u: 用内层鲸鱼算法求解 u 的最优用电计划 （输入：电价 + 其他用户上轮的策略） 返回用户u的负荷曲线 汇总所有用户负荷曲线，形成系统总负荷 计算外层适应度（峰谷差 + 售电收益） 外层鲸鱼更新位置（包围捕食 / 螺旋更新 / 随机搜索） iter = iter + 1 输出最优电价和对应的用户用电计划

内外层迭代比例需要经验性设置。我常用的组合是外层迭代200次、内层迭代100次，整体计算量已经不小。如果每个用户都用parfor并行，在8核电脑上一轮完整仿真的耗时大约10-20分钟，完全可接受。如果再想加快，可以内层只迭代30-50次，先保证外层电价空间被充分探索，后面再加密内层迭代数。

4. Matlab代码实现：从伪代码到能跑通的项目

4.1 整体代码结构设计

为了不把代码写成“一坨”，我通常把整项目拆成以下模块：

residential_scheduling/ ├── main.m % 主程序入口 ├── init_params.m % 初始化小区参数、用户参数、算法参数 ├── generate_users.m % 生成用户负荷数据 ├── load_default_price.m % 载入初始分时电价 ├── woa_outer.m % 外层鲸鱼算法主循环 ├── woa_inner.m % 内层鲸鱼算法（单用户） ├── objective_inner.m % 内层用户目标函数 ├── objective_outer.m % 外层目标函数 ├── format_price.m % 电价约束处理 ├── repair_schedule.m % 约束修复函数 ├── plot_results.m % 结果可视化 └── compare_algorithms.m % 与PSO/GA对比实验

4.2 外层鲸鱼算法的核心代码

外层代码不算复杂，重点在于每个个体都要调用一次内层求解，这是性能瓶颈的真正所在。

function [best_price, best_fitness] = woa_outer(params) % 初始化 nPop = params.nPopOuter; maxIter = params.maxIterOuter; nTime = params.nTime; % 96 dim = nTime; % 种群初始化 lb = repmat(params.priceMin, nPop, 1); ub = repmat(params.priceMax, nPop, 1); pop = lb + (ub - lb) .* rand(nPop, dim); % 计算初始适应度 fitness = zeros(nPop, 1); for i = 1:nPop fitness(i) = objective_outer(pop(i, :), params); end [best_fitness, idx] = min(fitness); best_price = pop(idx, :); % 迭代过程 for iter = 1:maxIter a = 2 - 2 * iter / maxIter; % 线性递减控制参数 for i = 1:nPop r1 = rand(); r2 = rand(); p = rand(); A = 2 * a * r1 - a; C = 2 * r2; if p < 0.5 if abs(A) < 1 % 包围捕食 D = abs(C .* best_price - pop(i, :)); new_pos = best_price - A .* D; else % 随机搜索 rand_idx = randi(nPop); D_rand = abs(C .* pop(rand_idx, :) - pop(i, :)); new_pos = pop(rand_idx, :) - A .* D_rand; end else % 螺旋更新 l = -1 + 2 * rand(); D_prime = abs(best_price - pop(i, :)); new_pos = D_prime .* exp(params.bConst .* l) .* cos(2 * pi * l) + best_price; end % 边界修复并重新评估适应度 new_pos = max(min(new_pos, ub(i, :)), lb(i, :)); new_fit = objective_outer(new_pos, params); if new_fit < fitness(i) pop(i, :) = new_pos; fitness(i) = new_fit; end end [cur_best, cur_idx] = min(fitness); if cur_best < best_fitness best_fitness = cur_best; best_price = pop(cur_idx, :); end end end

4.3 内层目标函数的写法与约束处理

内层目标函数是整个模型的核心。我见过不少同学在这个函数上写得一团乱，导致内层算法收敛极慢或者根本找不到可行解。设计时建议按“先解码、再功率平衡、再计算费用和惩罚”的顺序写：

function cost = objective_inner(x, user, price, params) % 解码：把鲸鱼个体分解成各设备功率 [P_wm, P_dw, P_ac, P_ev, P_battery] = decode_individual(x, user, params); % 设备功率合成 P_dev = P_wm + P_dw + P_ac + P_ev + P_battery; % 功率平衡 P_grid = user.P_base + P_dev; % 不考虑光伏时 % 如果配置光伏： % P_grid = user.P_base + P_dev - user.P_pv; % 负值表示反向馈网 % 购电费用 energy_cost = sum(price .* P_grid) * params.dt; % dt为时段长度(h) % 舒适度惩罚：空调设定温度偏差、可转移负荷时间偏移等 comfort_penalty = params.lambda_ac * sum(abs(P_ac - user.P_ac_ref)) ... + params.lambda_trans * sum(abs(P_wm - user.P_wm_ref)) ... + params.lambda_shift * sum(abs(P_ev - user.P_ev_ref)); cost = energy_cost + comfort_penalty; end

必须注意的地方是时段长度和功率单位的统一。如果时段是15分钟，最终耗电量是“功率×0.25小时”。很多初学Matlab的同学在算电费时直接对功率求和再乘以电价，算出来的费用比实际多了4倍，结果分析阶段全乱套。

约束处理上，我用的不是硬约束裁切，而是罚函数法+修复机制的双保险：

• 对连续变量（电池功率、空调功率），边界越界时直接裁切；
• 对开关量（洗衣机启停），不做连续化近似，而是用二进制映射处理——鲸鱼算法的连续输出经过sigmoid函数后以概率决定0/1状态；
• 对时间窗约束（洗衣机必须在18点以后开始），解码时直接把窗口外的变量置零。

4.4 主程序入口的调用逻辑

clear; clc; rng(42); %% 初始化参数 params = init_params(); % 时间参数、小区参数、算法参数 params.users = generate_users(params); % 生成用户数据 params.priceBase = load_default_price(params); % 初始分时电价 %% 求解双层优化 tic; [best_price, result] = woa_outer(params); elapsed = toc; fprintf('计算耗时: %.2f 秒\n', elapsed); fprintf('最优适应度: %.4f\n', result.best_fitness); %% 结果可视化 plot_results(best_price, result, params);

4.5 仿真参数的建议取值

经过大量调试，我给出一套在普通实验场景下能很好收敛的参数配置：

5. 仿真结果分析：纳什均衡怎么验证、算法效果怎么看

5.1 均衡验证：判断收敛点是否真的是纳什均衡

用双层鲸鱼算法跑完一轮，得到一个“最优解”，但这还不能证明它是纳什均衡。在正式写报告或论文之前，必须做一步单边偏离验证：

对每个用户 $u$，固定其他用户的用电策略和电网层电价，单独改变用户 $u$ 的用电计划，重新计算该用户的用电成本 $C_u$。如果 $C_u$ 在当前策略下不大于任何偏离后的成本，说明该用户没有单方面改变策略的动机，这个点在博弈论意义上确实是一个纳什均衡点。

我实现的验证代码逻辑如下：

function isEquilibrium = verify_equilibrium(best_price, user_schedules, params) % 计算当前状态下所有用户的成本 current_costs = zeros(params.nUsers, 1); for u = 1:params.nUsers current_costs(u) = calculate_user_cost(u, best_price, user_schedules, params); end % 对每个用户进行单边偏离检验 for u = 1:params.nUsers % 保持其他用户策略不变 other_schedules = user_schedules(u, 'ignore'); % 用内层算法重新求用户u在给定价格下的最优响应 new_schedule = woa_inner(best_price, other_schedules, params, u); % 如果最优响应明显低于当前成本，说明当前点不是均衡 new_cost = calculate_user_cost(u, best_price, new_schedule, params); if new_cost < current_costs(u) - 1e-3 isEquilibrium = false; return; end end isEquilibrium = true; end

这一部在实际项目中很容易被忽略，但审稿人或验收专家偏偏最爱挑这个毛病。真正跑过一遍你会发现，单边偏离优化后成本几乎没有下降，说明双层鲸鱼算法确实把均衡点找出来了，这个结果是立得住的。

5.2 双层鲸鱼算法与PSO、遗传算法的对比实验

做对比实验不是为了炫技，是为了证明“双层鲸鱼”不是拍脑袋选的算法。我在同一套模型参数下，分别用双层粒子群（外层PSO+内层PSO）、双层遗传算法（外层GA+内层GA）和双层鲸鱼算法各跑20次，统计结果如下：

在这个典型场景下，双层鲸鱼算法的削峰填谷效果最好，峰谷差从原来的128.5kW压到68.7kW，大约削减了46.5%，比双层PSO和双层GA都好上一些，收敛速度也略有优势。用户平均电费从52.3元降到45.9元，说明居民也拿了好处——这种“电网和居民双赢”的结果，正是设计博弈模型想要的效果。

5.3 优化前后负荷曲线的实际形态

画出优化前后的负荷曲线，会发现一个典型特征：高峰时段的负荷明显被削掉，平段和低谷时段被填起来。一部分洗衣机、洗碗机和电动汽车充电被转移到深夜谷时，空调在午高峰时段稍微降了一点功率，但温度偏差基本在可接受的舒适度范围内。

如果小区配置了光伏，优化后的曲线还会在午间出现一个“谷”被填平的现象——光伏出力最大的时候，智慧储能系统会吸收多余电量，供晚间峰时放电使用，这就是分层调度在设备层发挥的作用。

5.4 电价曲线的演化过程

观察外层算法的收敛过程，最有意思的是电价曲线的变化。初始随机生成的电价曲线乱得很，随着迭代推进，电价逐渐呈现出“低谷时段拉低、高峰时段抬高、平段适度居中”的形态。这说明算法确实找到了能引导用户主动错峰用电的信号结构。

同时需要说明：价格优化的幅度要有限制。如果为了削峰把峰时电价抬得过高，居民电费暴涨，舒适度惩罚又上来了，外层适应度反而变差——这就是权重$\omega_1$和$\omega_2$之间需要平衡的地方。

6. 调试过程中踩过的六个坑，以及对应处理办法

这一部分我原本没打算写，但这类模型真正难的地方从来不在数学推导，而在让代码稳定跑出合理结果。下面这些坑都是我实际调试时踩过的，每一条都对应具体代码写法或算法实现细节。

6.1 内层单用户无解：罚函数和修复机制必须同时上

刚开始内层目标函数只用罚函数法处理约束，结果有些用户在某些电价下会出现“完全找不到可行解”的问题。原因是个体解码后的设备功率叠加刚性负荷后超出进户线容量。

解决办法是双管齐下：先用修复函数把明显违反硬约束的个体直接修到可行域内，再在目标函数里加罚函数兜底。修复函数我推荐“按优先级裁剪”的策略——先保证刚性负荷不动，再保空调（舒适度影响大），最后才动储能和可转移设备。

6.2 开关量连续化的边界问题

鲸鱼算法本身擅长处理连续变量，对设备启停这种0/1变量并不友好。我最初试验直接把设备开关量设为连续变量，结果算法输出0.47、0.83这类值，没法直接解释。

用sigmoid把它映射成0/1状态是一种常见方法：

prob = 1 ./ (1 + exp(-x)); % 映射到(0,1) u = rand(size(x)); op_state = double(u < prob); % 以概率形式确定开关

这里有个额外好处——这相当于给鲸鱼算法的连续探索和最终离散决策之间搭了一座桥，而且sigmoid的概率特性还能在前期保留随机探索能力，后期逐渐向确定性状态收敛。

6.3 双层迭代的振荡与不收敛现象

外层算法跑着跑着，适应度曲线不降反升，甚至来回震荡。排查后发现：内层求解精度不够，每次返回的用户响应差异很大，外层看到的适应度信号噪音太大，优化就变成“瞎子爬山”了。

解决办法是给内层算法增加迭代次数和种群规模，同时把内层的随机种子固定。另一个技巧是：在外层迭代前期用较小的内层精度，后期逐渐加密，类似课程学习的思路，既能省时间又能提高收敛质量。

6.4 多次运行结果波动大、复现性差

智能优化算法天生有随机性，但同一个项目跑三次，三次结果差异超过10%，就说明稳定性不够。我统计过，问题通常出在种群初始化上——如果初始化只用均匀随机分布，很容易把初始种群集中在一个很差的区域。

改进方法：

• 在初始化种群时，把一组可行解（比如原来的分时电价或人工指定的合理用电计划）作为初始种群的一个个体放进去；
• 运行多次取最优或取平均；
• 统一用rng(固定种子)保证测试环境可复现。

6.5 计算时间太长：优化计算瓶颈的几个手段

双层嵌套算法最怕的就是跑一晚上还没结果。我的优化顺序是：

• 首先用parfor对内层用户做并行，这是最立竿见影的一步；
• 其次，如果用户设备结构高度相似，可以考虑提前用向量化重写内层目标函数，避免循环叠加；
• 最后，对不重要的外层个体可以提前终止内层迭代——反正它们的适应度大概率不会被选为最优。

我实测过，8核工作站上用parfor能缩短约50%的时间，这是一个对双层嵌套算法来说非常大的收益。

6.6 Matlab版本差异带来的兼容性问题

这个项目里我用了较新的函数语法和工具库。如果你还在用早期版本，有几个兼容性要点可以提前避坑：

• parfor在并行计算工具箱（Parallel Computing Toolbox）里可用，但要注意用户结构体传入后不能被修改，否则Matlab会提示无法并行化；
• 建议使用struct和table时注意不同版本对字段名和数据类型的处理差异；
• 老版本对R2016a以前的datetime类型支持不完整，如果做时间轴可视化要注意这一点。

我在本地用的版本是MATLAB R2022b，同时也会在项目目录里加一段版本检查脚本，实际上团队里有人用老版本时，脚本会自动提示哪些函数需要改写法。

结语和一点个人体会

研究这类模型时，我一直坚持一个原则：算法要有物理含义，模型要能自洽。“非合作博弈”不是把“博弈”两个字往PPT上一放就完了，而是要能回答“每个参与者真的有独立的利益诉求吗”以及“存在一个稳定的均衡状态吗”；“双层鲸鱼算法”也不是“用两个循环套一下就万事大吉”，而是要让外层搜出来的电价真正能引导内层用户的理性行为。

从代码实现角度看，这个项目最花时间的往往不是算法本身，而是数据的组织、约束的处理和代码的稳定性调优。把这几块基础打好，再去换用户数据、换算法细节、换目标函数，整个框架都能轻松复用。

最后再分享一个小建议：拿到这个模型后，先不要急着套复杂数据，用20个用户、96个时段的小规模场景把代码调通，确认算法和均衡验证都正常，再逐步扩大仿真规模。在所有实验记录里，附上每次仿真的随机种子和参数配置，这对后续复现、对比和写报告都有意想不到的好处。