企业官网建设流程全解析

大约在五年前，我第一次把一套带地源热泵和蓄冷罐的小型冷热电联供系统从仿真推到真实园区时，被运维工程师问住了一个问题：你说这套调度方案是最优的，为什么夏天下午三楼西侧办公室的人喊热，而二楼大厅的人又嫌冷气太足？

当时我下意识想反驳“系统总体成本最低、总供能曲线匹配”，但话到嘴边意识到，传统优化调度里的“满足负荷”其实是个非常粗糙的假设——它默认用户侧只要给了冷/热/电的能量，体验就没问题。但实际建筑里的人不是花洒，开水龙头就有水，他们要的是稳定、舒适、响应跟得上的环境。从那之后，我几乎所有综合能源优化调度的项目里，都主动把“用户舒适度”写进目标函数和约束条件。这篇就借着我最近做完的一个冷热电多能互补系统的调度项目，从头拆一遍：用户舒适度到底怎么量化、怎么塞进优化模型、对调度结果有多大影响，以及落地时那些仿真里完全看不出来的坑。

舒适度这东西，听起来像个“软指标”，好像谁都能说两句，但真让它在优化模型里起作用，就需要一个既能反映人体主观感受、又具备数学上可微可导可线性化的表达。我综合了几个项目的做法，给你一套从衡量指标到目标建模再到约束处理都能直接拿去用的完整链路。

1. 冷热电多能互补系统到底在“补”什么

先说清楚系统本身，不然后面讲调度会觉得跳跃。冷热电多能互补，英文常叫CCHP（Combined Cooling, Heating and Power）或者更广义的MES（Multi-Energy System），核心思路不是简单地把燃气锅炉、电空调、光伏板堆在一起，而是让不同品位、不同来源的能源在时空上相互配合，用一次能源的梯级利用去节省整体成本。

我的原则是，项目开题先画一张能量流拓扑图，手动或工具画都行，但一定要能量守恒写清楚。拿那套我经手的园区系统举例，典型的架构包括：

• 动力设备：天然气驱动的一台小型燃气内燃机（额定功率大约1.2MW），发电的同时产生高温烟气和缸套水，其中烟气进余热锅炉产生蒸汽或热水，缸套水直接进换热站。
• 制冷设备：一台溴化锂吸收式制冷机（利用蒸汽或热水驱动，额定制冷量约1.4MW），两台电驱动离心式冷水机组（每台额定制冷量约0.9MW）。
• 制热设备：燃气热水锅炉做调峰，额定制热量约1.5MW，另外冷凝器侧回收热量也可以直接供热。
• 蓄能设备：一个300m³的蓄冷水罐和一个200m³的蓄热水罐，承担时移峰谷的调蓄作用。
• 可再生能源：屋顶分布式光伏，装机约350kWp。

这套结构里“互补”体现在两个层面：

设备层面互补——内燃机发电产生余热，这是“先电后热”的联产逻辑；但如果电负荷小、热负荷大，内燃机全开会出现电用不完、上网又受限的状况，这时候就得多开燃气锅炉，让热负荷交给锅炉带，内燃机降出力或停机。这个切换不是一个简单的0/1判断，而是要考虑当时电价、气价、设备效率、负载率。更微妙的是制冷侧——溴化锂机用热制冷，电制冷机用电制冷，同一时刻，同样的冷负荷可以由两种完全不同的驱动能源来满足，选谁就得看“热”和“电”此刻谁的边际成本更低，而且还要受到机组部分负荷率下性能衰减的影响。

时间层面互补——白天电价高，冷/热负荷同时高，内燃机发出来的电可以替代高价市电，同时余热又推动了溴化锂制冷，一石二鸟；夜间电价低，电制冷机开起来往蓄冷罐里存冷，燃气锅炉或者电锅炉往蓄热罐里存热，白天电价高的时候蓄能装置再放能，相当于时间套利。

这就是互补调度的底层逻辑：每一台设备承担什么角色，不是拍脑袋定的，而是由一个全局优化决策算出来的。但问题也随之而来——如果优化目标只盯着经济和一次能源消耗，系统会在满足“平均负荷”的情况下，自动选择让所有用户稍微热一点或冷一点来省钱，因为末端温度的微小偏移，在能量平衡方程里可能根本不构成约束。于是我的调度结果交付的是“能量”而不是“舒适”。

你可能会问：负荷预测环节不是都有温度指标吗？那不是间接考虑舒适度了吗？抱歉，那只是预测室内得热的一个输入系数，跟用户真实体感完全是两码事。做预测的行话是“预测的是房间空气温度响应”，而调度模型里若是没有把温度设成状态变量，也没有把温度区间设成约束，那预测做得再准也仅仅是给能量购买数量做了个估计，并不保证室内热环境达不达标。

注意：对于清洁供暖/供冷的项目考核，政府或物业方比较看重室温是否达标，尤其严寒地区冬季“室温不低于18℃”往往会上红头文件。如果你的优化模型完全不约束室温，只盯着成本，那运行结果可能“省了钱，冷了人”，后期投诉和返工成本远超节省的那点电费。

2. 把“舒适度”翻译成数学语言

用户舒适度的量化，学术界最经典的是Fanger的PMV-PPD指标，工程界尤其是暖通空调领域也大量采用。PMV（Predicted Mean Vote）预测平均投票值，把冷热感觉映射成-3到+3之间的刻度；-3代表很冷，+3代表很热，0代表热中性。PPD（Predicted Percentage of Dissatisfied）预测不满意百分数，跟PMV之间有直接的函数关系。这俩指标考虑的因素包括空气温度、相对湿度、平均辐射温度、风速、代谢率、服装热阻。

但直接拿PMV进优化的很少，原因在于PMV方程是非线性的，迭代求解在日内滚动优化里会有时间和稳定性问题。实际工程中常见的是把PMV做线性近似，或者退而求其次直接以室内空气温度区间和相对湿度区间作为舒适度代理指标。我这里偏向后者，同时引入一个基于温度偏离度的软性惩罚项，把“舒适度”从一个刚性跳变约束，变成一个弹性可妥协的劣化代价。

具体建模思路分三步：

第一步：室内温度动态方程

典型做法是用一个一阶等效热容模型描述房间空气温度变化：

C_ind * dT_ind(t)/dt = Q_hvac(t) - (T_ind(t) - T_out(t)) / R_env

其中C_ind是房间等效热容（kWh/℃），T_ind是室内温度（℃），T_out是室外温度（℃），R_env是围护结构等效热阻（℃/kW），Q_hvac是空调系统供给该区域的冷/热量（kW）。为了进混合整数线性规划（MILP），用隐式欧拉或者梯形法做离散化，写成T_ind(t+1)关于T_ind(t)、Q_hvac(t)、T_out(t)的线性递推式。

第二步：舒适度区间约束

设T_s,set(t)为舒适温度设定值，ΔT_comf(t)为允许波动带宽，则约束为：

T_s,set(t) - ΔT_comf(t) ≤ T_ind(t) ≤ T_s,set(t) + ΔT_comf(t)

ΔT_comf怎么取？按照ISO 7730和GB/T 50785-2012《民用建筑室内热湿环境评价标准》，热舒适等级I级对应的温度范围大致是夏季24℃~26℃、冬季22℃~24℃，允许波动通常在±1℃~±1.5℃。如果预算充足、系统能效也够，可以按等级I的严格要求来；如果是为了降低运行费，等级II（温度范围放宽到夏季23℃~28℃、冬季18℃~22℃）也能接受。

第三步：满意度惩罚函数

把舒适度“软化”的常见做法是引入松弛变量，让温度可以在一个硬约束区间之外继续运行，但每偏离一度产生一个惩罚成本。偏离越小越好，但不至于因为一个瞬时扰动导致模型无解。这样优化器就会自行权衡：多花10块钱电费把温度拉回舒适区，跟忍受用户投诉但省下50块钱，哪个更划算——结果往往取决于惩罚系数的标定。

这个惩罚系数的标定我踩过坑：一开始拍脑袋定了个0.5元/℃，结果优化器在电价高峰时段把室内温度整体抬高了2℃，房间热得像蒸笼，成本确实好看，但物业那边炸了锅。后来改成“第一小时偏离30元/℃、第二小时偏离50元/℃、连续偏离超过三小时直接100元/℃”的分段递增罚函数，情况才收敛，系统知道连续背离要比短时波动付出更高代价。

除了温度冷暖，“冷热电”里的“冷”和“热”其实对应的是同一套热力学模型，只是工况不同。夏天空调送冷，Q_hvac取负值带进方程；冬天供热，Q_hvac取正值。这样一套方程就能完成全年四季的舒适度约束。

3. 优化调度的数学建模：目标函数与约束条件怎么搭

有了舒适度的数学表达，下面就可以搭建完整的优化调度模型了。这里我给出一套我在工程中常用的简洁框架，项目上你想单列碳排放或一次能源消耗目标，往这个骨架上加就行。

3.1 目标函数

综合目标写成三部分加权和：

min Σ_t [ C_elec(t) + C_gas(t) + C_battery(t) + C_comf(t) + C_penalty(t) ]

• C_elec(t)：购电成本 = 购电功率 × 实时电价。光伏发电量在这个框架里直接作为负的负荷项处理，或者作为可再生能源优先消纳项，看你习惯。
• C_gas(t)：购气成本 = 燃气消耗功率 × 天然气价格。燃气轮机和燃气锅炉都要算。
• C_battery(t)：蓄能设备使用成本或折旧，通常等于一个很小的单位功率成本乘充电/放电功率，或者按日折旧摊到小时，目的是防止蓄能设备无意义地频繁充放。
• C_comf(t)：舒适度惩罚项 = 各区域温度偏离舒适区程度的加权平方和或分段线性函数。

C_penalty(t)：旋转备用不足惩罚、启停惩罚、功率越限惩罚等，按项目需要追加。

各目标项之间是量纲统一的经济量，所以加权系数就是各物理量到人民币的换算。你不需要太纠结“成本最优”和“舒适最优”怎么平衡，因为暖通里的舒适度本质上是可以货币化的——物业靠满意率收租金、企业靠工位环境保员工效率，这些都能折算成钱。

3.2 关键约束

能量平衡约束：

电功率平衡：

P_gt(t) + P_pv(t) + P_grid_buy(t) + P_discharge(t) = P_load(t) + P_grid_sell(t) + P_charge(t) + P_ec(t) + P_pump(t)

其中P_gt是内燃机发电功率，P_pv是光伏出力（预测值），P_grid_buy/sell是电网购/售电，P_discharge/charge是蓄电或蓄冷/蓄热的等效电功率，P_ec是电制冷机耗电，P_pump是水泵风机等辅助耗电，P_load是用户电负荷。

冷功率平衡：

Q_cool_abs(t) + Q_cool_ec(t) + Q_cool_storage_discharge(t) = Q_cool_load(t) + Q_cool_storage_charge(t)

热功率平衡：

Q_heat_exh(t) + Q_heat_boiler(t) + Q_heat_storage_discharge(t) = Q_heat_load(t) + Q_heat_storage_charge(t)

设备出力约束：

0 ≤ P_gt(t) ≤ P_gt_max P_gt_min ≤ P_gt(t) ≤ P_gt_max（燃气轮机有最低稳定技术出力） 0 ≤ Q_abs(t) ≤ Q_abs_max 0 ≤ Q_boiler(t) ≤ Q_boiler_max

内燃机的热电耦合关系是模型里比较关键的一个：发电功率P_gt和余热回收Q_exh之间不是独立的，通常满足：

Q_exh(t) = η_recover * (1 - η_elec) * P_gt_input(t)

换个形式更常用：给定余热回收系数α，则Q_exh(t) = α * P_gt(t)。这个α是内燃机部分负荷率、环境温度等参数的函数，工程上一线做法是取几组典型工况用线性插值描述，形成分段线性约束。

溴化锂制冷机约束：

Q_abs(t) = COP_abs * Q_exh_to_abs(t)

COP_abs一般取1.3左右，注意别按厂商样本上的额定制冷量/额定耗热量的比值去算部分负荷段，实际部分负荷下的COP会打折，最好用实测数据拟合。

蓄能装置动态约束：

SOC_store(t+1) = SOC_store(t) - Q_discharge(t)/η_discharge * Δt + Q_charge(t) * η_charge * Δt

0 ≤ SOC_store(t) ≤ SOC_store_max 0 ≤ Q_discharge(t) ≤ Q_discharge_max * I_discharge(t) 0 ≤ Q_charge(t) ≤ Q_charge_max * I_charge(t)

I_charge(t) + I_discharge(t) ≤ 1（防止同时充放）

3.3 舒适度相关约束的嵌入方式

在完整的MILP模型里，室内温度约束怎么加？以每个功能区设一个代表性区域，区域编号r = 1, 2, ..., R为例：

T_ind_r(t+1) = a_r * T_ind_r(t) + b_r * (Q_hvac_r(t) + Q_gain_r(t)) + c_r * T_out(t)

其中a_r、b_r、c_r是由围护结构热容、热阻、面积等推导出的常系数。

室温在舒适区间内时，C_comf = 0；一旦越界，惩罚项按分段线性函数加进去。为了让MILP能处理，把温度区间外部分离散成几段斜率递增的线性函数，这比二次函数更受求解器欢迎。

约束软化处理：如果模型在极端天气下完全不满足室温约束，求解器会报不可行。务必将舒适度约束做软约束处理，加入松弛变量s_r^+和s_r^-：

T_ind_r(t) - s_r^+(t) ≤ T_max_r(t) T_ind_r(t) + s_r^-(t) ≥ T_min_r(t) s_r^+(t), s_r^-(t) ≥ 0

在目标函数中给松弛变量一个高额惩罚系数。这样做的意义不光是数学上保证可行解，更重要的是工程上保留了运行人员在极端工况下手动越限的合理性——总有一些时刻，比如极端寒潮和节假日过渡期，必须牺牲短暂舒适度来换取系统安全。

4. 求解策略与落地案例：从MILP到滚动调度

模型建好了，接下来是求解。我这套模型用的是混合整数线性规划（MILP），因为设备启停状态、蓄能罐充放状态、分段报价这些都是整数变量，线性化后交给求解器处理最方便。

4.1 求解工具选型

• 商业求解器：Gurobi、CPLEX，性能和稳定性最好，园区规模的项目（几十个区域、几十台设备、96个时段）通常在几十秒到几分钟内收敛。
• 开源求解器：CBC、SCIP，小规模或教学演示可以用，但复杂模型求解时间会明显拉长，特别是加了蓄能设备后整数变量变多。
• 如果上了非线性舒适度模型（比如直接用PMV），就要用NLP求解器或者启发式算法（粒子群、遗传算法等），但这类算法没法保证全局最优，而且日内滚动调度对耗时敏感，我建议尽量线性化，这件事不能怕麻烦。

4.2 调度策略：日前计划 + 日内滚动校正

实际项目中，我用的是典型的两阶段调度框架：

日前调度（Day-ahead）：基于次日的气象预测、负荷预测、分时电价，以1小时为步长（或根据需要细化为15分钟），优化次日00:00到24:00的设备开停计划。这一步决定大型设备（如内燃机、双工况冷水机组）的启停组合和蓄能罐的目标SOC曲线。

日内滚动校正（Intra-day Rolling）：以15分钟为控制周期，向前滚动优化未来4小时。把日前计划里的设备状态作为边界条件固定下来，只优化连续变量（设备出力、充放功率、室温设定点的微调），用实时状态（实际室温、实际负荷、光伏实发功率）刷新预测，消除日前预测误差。

为什么要滚动？因为用户的舒适度跟“预测是否准确”高度相关。负荷预测往偏了预测，室温就偏；室温偏了，再想拉回来就需要额外的冷/热出力，而这个额外出力可能正好碰上电价峰值时段——如果不滚动，就会连续几个小时室温偏离，用户早就有意见了。

说个实际数据给你体感：同样一套系统，只做日前调度不做日内校正，夏季典型日累计室温偏离舒适区间的时长为47分钟；加上日内滚动后，降到9分钟。看起来不长？但47分钟的偏离往往集中出现在下午3点到4点的电价高峰时段，室内温度能升到28.5℃以上，坐在窗边的人早就开始冒汗了。

4.3 案例：某办公园区的夏季设计日调度

直接上一个我最近调完的案例。

基础参数：

• 地点：北方某市，夏季典型设计日室外温度最高34℃
• 园区：办公+少量商业，空调面积约2.8万m²，分三个区域建模（A栋办公、B栋办公、C栋商业裙楼）
• 电价：峰段1.02元/kWh（8:00-11:00, 18:00-23:00），平段0.63元/kWh（7:00-8:00, 11:00-18:00），谷段0.33元/kWh（23:00-次日7:00）
• 气价：按阶梯折算约2.8元/m³，对应单位热值成本约0.29元/kWh（按天然气低热值10.5 kWh/m³算，锅炉效率0.9）
• 舒适度约束：A/B栋办公按ISO等级II，夏季温度24~28℃；C栋商业裙楼按等级I，24~26℃

优化结果对比：

我跑了两个场景做对照。场景一：不考虑室内温度约束，只保证供冷量满足负荷预测（传统做法）。场景二：完整带室温动态约束和舒适度惩罚。

场景二总成本增加了3.6%，但换来的是末端舒适度的大幅改善。落地运维方和物业对多出来的780块钱完全没意见，反而很满意——因为过去三年夏天他们接到的温度投诉工单平均每周5到8单，那套方案上线那一周，投诉降到0单。

从结果里能看到一个有意思的细节：场景二的溴化锂制冷量占比从34%提升到41%。原因不复杂——溴化锂制冷机虽然单机制冷能效比没有电制冷机高，但它用的是内燃机余热，这部分热量的边际成本很低；只要内燃机在高效区间运行，余热供冷就是给用户房间“免费”降温，系统在满足舒适度区间的前提下可以更多开内燃机，整体购电量反而降了。

这其实就是舒适度约束带来的“连锁反应”：不是简单多花电费去压制温度，而是促使系统调整了运行结构和能量流路径，在相同的能源资源下，既保住了成本可控，又提升了体验。

5. 室内热响应模型怎么建才能不出偏差

讲到这里，很多人会卡在建筑侧建模上。设备侧的模型再复杂，至少厂家手册有参考值，但建筑等效热容、围护结构热阻这些参数，新项目往往没有经过标定，硬套一个模型的话调度结果可能偏差不小。

我推荐的做法是“RC网络模型”，即把每个功能区的热动态等价成电阻-电容网络。一阶RC模型相当于一个房间用一个热容C和一个热阻R描述，适合整个区域当作一个整体来看的情况。如果建筑体量大、不同朝向负荷差异显著，至少拆成两个或三个分区，各分区之间再加入一个耦合热阻。

以常见的二阶RC模型（两个热容分别对应室内空气和围护结构内表面）为例：

C_air * dT_air/dt = (T_wall - T_air) / R_wall + Q_hvac + Q_solar + Q_occ + Q_equip C_wall * dT_wall/dt = (T_out - T_wall) / R_out + (T_air - T_wall) / R_wall

其中T_air是室内空气温度，T_wall是墙体温度，Q_solar是太阳辐射得热，Q_occ是人体散热，Q_equip是设备散热。

这些参数怎么获取？我的经验是三条路：

1. 设计图纸倒推：从建筑设计说明的围护结构传热系数K值表、玻璃的遮阳系数SC、窗墙比等参数计算R和C。优点是前期就能用，缺点是模型和实际运行偏差大，一般有20%~30%的误差。
2. 实测数据辨识：装几个温度传感器，记录一周的室内外温度、设备启停时间、送风温度，用最小二乘法或者卡尔曼滤波辨识R、C参数。这是最靠谱的，误差能压到5%以内。
3. 建筑能耗模拟软件联动：用EnergyPlus或DeST生成多组工况下的室温响应数据，再用这些数据拟合降阶RC模型。精度介于前两者之间，但工作量不小。

我现在基本是“设计图纸初值 + 实测辨识校准”的组合。项目启动第四周就把传感器数据和模型参数优一轮，后续每隔三个月复校一次，应对围护结构性能变化和功能分区调整。

如果你不想手撕RC参数，还有一个土办法：直接从空调系统历史运行数据里反推“供冷量-室内温度”的近似斜率。例如记录过去一周每天10:00到16:00的冷量供给和室温斜率，做一个线性回归：dT/dt ≈ a * Q_hvac + b * (T_out - T_air)。这个方法物理意义不如RC模型强，但胜在快速、低门槛，对一部分粗调度场景也够用了。

6. 落地部署时的几个大坑和实用提醒

模型跑通了、仿真也收得漂亮，但部署到实际系统时才是真正的考验。我在几个园区项目上踩过不少坑，挑几个影响最大的说。

6.1 一定要分时段的舒适度要求不一样

很多人把舒适度约束做成全天一个温度区间，这是不对的。

办公建筑白天需要严格舒适环境，但夜间只有少量加班人员或保安值守，如果还维持在24℃~26℃，那就是巨大的能源浪费。实际调度中把夜间温度区间放宽到20℃~28℃甚至直接让空调进入待机模式，能省不少钱。

还有过渡季（春秋季），室外温度本身就在舒适区间内，空调系统其实应该尽量不启动，靠新风和自然通风就能维持室内热舒适。如果模型里不设置过渡季的舒适度优化模式，系统还会机械地维持空调运行，白白耗能。我现在的做法是让系统每天去匹配当天的气象修正舒适温度——按日平均室外温度自动调整室内目标温度，平滑衔接，避免“今天还24℃，明天突然跳到26℃”的突兀跳变。

6.2 区域差异化舒适度建模

之前把整个园区的室内温度设成一个模型，结果调度结果在A栋很舒适，但C栋阳光直射区域下午热得不行。原因就是不同区域的围护结构条件、人员密度、设备散热差异很大，用一个平均温度代替所有区域的温度，就是把“用户舒适度”做成了“用户平均舒适度”，这等于还是没有以人为本。

所以前面案例里我建了三个区域的分区模型，各用各的RC参数、各用各的舒适度区间。代价是模型规模和数据需求增加了，但从结果看，这个投入很值——物业那边能直观看到“A栋的室温设定和C栋的不同是系统有意为之，不是故障”。

6.3 舒适度惩罚系数要结合业务场景

做园区、写字楼、医院、数据中心，舒适度在目标函数里的权重应该不一样。

医院对温度要求极高并且波动容忍度极低，舒适度权重应该拉很高；写字楼相对有弹性但涉及客户满意度；数据中心里所谓的“舒适度”其实是服务器进风温度限制，惩罚系数要按宕机风险来标定，稍有不慎就是事故级损失。

我在写字楼项目上按“室内温度每偏离舒适区间1℃、持续一小时，惩罚成本 = 该区域一小时平均租金 × 影响面积比例”来标定，理由是租户满意度影响出租率，出租率就是写字楼的收入。这样标定出来的数值，既能在优化器里跟电费气费抗衡，又能在跟业主汇报解释时经得起推敲。

6.4 求解时间和收敛性的工程权衡

前面说过MILP模型尽量线性化，但即便如此，如果区域分了七八个，时间粒度又细化到15分钟，一天96个时段，模型变量数可以轻松到几万个，整数变量几千个，Gurobi跑起来可能超过十几分钟。日前调度还能接受，日内滚动调度15分钟一个周期，求解时间必须控制在一两分钟内，否则没法落地。

几个工程上常用的技巧：

• 时段聚合：把日内滚动的时间粒度拉长到30分钟，或者把24小时的日前模型用1小时粒度，只对近端2小时用15分钟粒度。这叫多分辨率时间建模。
• 变量降维：同型号设备聚合成一台等效设备，减少对称性整数变量。例如三台同型号电制冷机，等效成一台三倍容量的制冷机，代价是失去了单独设备启停的颗粒度，但对整体调度结果影响甚微。
• 解修正：先用松弛整数变量求一次连续最优得到热起步点，再固定启停状态只优化连续变量，作为MIP的热启动，求解速度能提升一大截。
• 限制MIP Gap：设置相对最优间隙为1%~2%，即求解器找到的可行解跟最优下界的差距在1%内就停。对工程场景来说，1%的次优解和最优解之间的差别完全可以接受，但求解时间可能从十几分钟降到两三分钟。

6.5 与末端控制的联动别断了

很多项目做完调度优化就停了，调度下发一个总冷量信号给空调系统，但末端风机盘管、变风量阀怎么配合完全没人管。结果就是调度模型算出来“现在供给这片区域100kW冷量”，末端系统也照做了，但实际上因为某个支路的水力失调，东侧房间实际得到70kW，西侧房间却超量到130kW，室温照样不均匀。

我现在的做法是，调度优化的输出不仅仅是“供水温度 + 总流量”这种粗粒度信号，而是直接下发到区域控制器：每个区域的室温目标值曲线、区域冷量需求、空调系统供水温度设定值。末端控制器再去调节风机盘管或VAV阀位实现区域温度跟踪。调度层的“舒适度约束”和末端控制层的“舒适度实现”必须是一个闭环，否则优化做得再精细都是雾里看花。

6.6 调试验收阶段把满意度做成可观测指标

调度系统上线之前我就跟运维团队一起把“用户舒适度”定义成可量化的KPI，包括：各区域室温实时偏差、室温越限累计时长（按日/周/月统计）、用户投诉工单数量、异常温度事件持续时长。每天定时生成一张“舒适度日报”，运维人员打开就能看到昨天哪些时段哪些区域温度超限，超了多少，是调度原因还是末端故障。

有一次日报发现B栋连续三天下午15:00左右室内温度偏高，调度层面看各项指令都正常。后来查下去，是B栋冷冻水支路电动阀卡滞，每次在下午高温时段开度到了85%就上不去了。如果没有这份日报，这种设备层面的偶发问题可能拖上几周才被用户投诉发现。调度系统不只是“算得准”，还得“看得见”，把抽象的舒适度变成可见的数字和趋势，是运维环节最容易忽视却最有实用价值的一步。

7. 如果做纯学术仿真，哪些地方可以简化

如果说你暂时没有实际项目，只是做课题研究或者写论文，那也不是非得建全套RC网络模型才有价值。学术场景下的简化策略也很清晰。

一个常见做法是直接用文献里已经标定好的建筑模型参数，类似ASHRAE标准里给出的一些典型建筑类型的热工参数代表值，不再做辨识和校验。另一个是把室温动态约束退化成功率约束——比如用“瞬时冷热负荷满足舒适温度对应的冷热需求”，这在仿真里完全可以接受，因为你想研究的是综合能源系统侧的调度策略，不是建筑热响应的精确模拟。

还有就是把舒适度指标换成灵活性指标或者满意率指标，例如定义“用户不满意率”为偏离温度区间的小时数占比，把它做进多目标优化里画帕累托前沿。这类工作学术价值不小，因为工程里一个惩罚系数就解决了的问题，在学术框架里可以用多目标跟运行成本做权衡，更直观也更有解释性。

不过做学术仿真时有一点我建议保留：模型一定要有时变特性——光伏出力曲线、负荷波动、电价波动都别用常数代替，否则优化结果会虚高。因为你研究“冷热电多能互补”本身就是冲着“不确定性下的互补”去的，把所有不确定都抹平，这个问题就不用做了。

以我个人经验，写完初版模型后先拿一组已知结果的基准场景验证模型正确性，再逐步放开约束和复杂度，比一上来就堆复杂建模要高效得多。把每次模型改动前后结果差异记下来，这既是学术报告的基础，也是未来调试的参照。

老话说得好，搞综合能源优化调度，最容易做成了“能源系统优化”而把“人”给忘了。后来我给自己写了一条备忘，每次项目收尾时都会问一遍：室外温度、电价、设备性能这些变量在变，但用户的体感有没有被当作一个动态对象去跟踪、去约束、去优化？如果答案是否定的，那这套调度系统无论经济学指标多漂亮，都只完成了一半的功课。希望这篇拆解里量化舒适度、嵌入优化模型、工程部署避坑的这些细节，能让你在下一个冷热电多能互补项目里少走几段弯路，一上来就能找到那个“既省钱又让人舒服”的调度方案。