4、核心功能模块（上）：用户管理、资源管理、合同管理、基线计算
好，咱们进入正题。前面几章我们把需求响应聚合平台的顶层设计和数据流捋清楚了。从这章开始，我要带你把平台的几个核心功能模块一个个拆开来看。
说白了，一个聚合平台能不能跑起来，就看这四个模块硬不硬：用户管理、资源管理、合同管理、基线计算。我习惯把这四个模块称为平台的「四梁八柱」。你想想看，没有用户，平台就是个空壳；没有资源，拿什么去响应？没有合同，权责利怎么分？没有基线，响应效果怎么算？
嗯，咱们一个一个来过。
4.1 用户管理：不只是注册登录那么简单
用户管理，很多新手觉得就是做个登录注册。我在项目中遇到过，一开始也这么想，结果上线第一天就出问题了——用户类型搞混了。
聚合平台的用户，至少分三类：
- 资源用户：比如工厂、楼宇、充电桩运营商。他们是实际提供可调负荷的。
- 聚合商：就是我们自己，或者我们的下游代理商。
- 监管方：电网公司、政府能源局。他们要看数据，但不操作资源。
这三类用户的权限、界面、数据范围完全不同。我建议你从一开始就用角色-权限-资源三层模型来设计。
核心设计要点：
- 用户注册时，必须绑定「组织」和「角色」
- 权限控制要细到「按钮级」，比如「查看基线」和「修改基线」是两回事
- 用户状态机：待审核 → 激活 → 冻结 → 注销，每个状态都要有对应的业务逻辑
举个例子，我曾经帮一个客户做改造，他们原来的系统里，一个工厂用户能看到所有工厂的用电数据。这还得了？商业机密全漏了。后来我加了一层「数据域隔离」，每个用户只能看到自己组织下的资源数据。这个坑，你千万别踩。
4.2 资源管理：你的「可调兵力」都在这里
资源管理，说白了就是管好你手头有多少「兵」可以调。这里的资源，指的是具体的可调负荷设备或系统。
常见的资源类型有：
| 资源类型 | 典型设备 | 响应特点 |
|---|---|---|
| 空调系统 | 中央空调、VRV多联机 | 可短时关停，恢复快 |
| 储能系统 | 锂电池储能柜 | 响应速度快，可双向调节 |
| 充电桩 | 交流慢充、直流快充 | 可调功率，可中断充电 |
| 工业负荷 | 空压机、水泵、电炉 | 调节幅度大，但需提前通知 |
每个资源接入平台时，需要登记几个关键参数：
- 额定功率：最大能调多少
- 可调范围：比如空调只能降30%，不能全关
- 响应延迟：从收到指令到开始执行，需要几秒
- 持续时长：能保持这个状态多久
我的经验：资源管理模块一定要做「资源画像」。就是把每个资源的历史响应数据记录下来，形成它的「性格」。有的资源响应快但持久性差，有的慢但稳。调度的时候，根据画像来匹配不同的响应任务，效率能提升一大截。
4.3 合同管理：把「权责利」写清楚
合同管理，是平台里最容易扯皮的地方。我见过太多因为合同条款没写清楚，最后闹到打官司的案例。
聚合平台里的合同，主要分两类：
- 聚合商与资源用户的合同：约定响应容量、补偿价格、违约责任
- 聚合商与电网的合同：约定响应指标、考核标准、结算方式
合同的生命周期管理，我建议至少包含这几个状态：
- 草稿：双方还在谈，没定稿
- 待签署：条款已定，等电子签章
- 生效中：合同正在执行
- 到期：自然到期，可续签
- 终止：提前解约
注意：合同里的「基线计算方式」必须写清楚。是用历史平均法？还是用相似日法？还是用机器学习预测法？不同的算法，算出来的基线可能差很多，直接影响补偿金额。我建议在合同模板里直接嵌入算法选择项，避免事后扯皮。
嗯，这里多说一句。合同管理模块最好能自动生成「履约报告」。比如每次响应任务结束后，系统自动算出来：你实际响应了多少、基线是多少、偏差多少、该补偿多少钱。把这个报告推送给双方，透明公开，能省掉很多沟通成本。
4.4 基线计算：最核心也最容易被挑战
基线计算，是整个需求响应里最核心的技术环节，也是最容易产生争议的地方。
什么是基线？说白了，就是「如果你不参与响应，你本来会用多少电」。这个「本来」的值，谁也拿不出来，只能靠算。
常用的基线计算方法有：
- 历史平均法：取前N天同一时段的用电平均值。简单，但遇到节假日、天气突变就失灵。
- 相似日法：找天气、日期类型都相似的历史日来算。比平均法准一些。
- 回归模型法：用温度、湿度、生产计划等变量做回归。精度更高，但需要数据积累。
- 机器学习法：用LSTM、XGBoost等模型预测。我目前在项目里主推这个，效果确实好。
我画了一张图，帮你理解基线计算在整个响应流程中的位置：
你看，基线计算不是孤立的，它贯穿了整个响应流程。从数据采集到最终结算，每一步都离不开它。
避坑指南：我曾经在一个项目里，用了历史平均法算基线，结果遇到一个工厂临时停产三天，历史数据全是零。基线算出来极低，导致工厂「响应」效果看起来特别好，多拿了几十万补偿。后来我们加了「异常工况检测」模块，遇到停产、检修等特殊情况，自动切换算法。这个教训，花了我三个月时间才补上。
关于基线计算，还有几个关键参数要设置：
- 窗口期：取前多少天的数据？我一般建议30天，太短波动大，太长反应慢
- 校准机制：响应前15分钟的实际负荷，要不要用来修正基线？行业内争议很大，我个人倾向于「部分校准」
- 偏差容忍度：实际负荷偏离基线多少算「有效响应」？通常设定在5%-10%之间
嗯，这四个模块讲下来，内容确实不少。用户管理是入口，资源管理是家底，合同管理是规矩，基线计算是核心。这四个模块做好了，平台的基本骨架就搭起来了。
你在实际搭建的时候，我建议先做基线计算模块，因为这个最难，也最需要反复调优。用户管理和合同管理，市面上有成熟的框架可以借鉴。资源管理嘛，关键是把数据接入的标准化做好，后面扩展起来就快了。