第02篇-把GB-T44260当需求文档读

引言：把两个"宜"字抄成了常量

想起第一次把 GB/T 44260-2024 摊在桌上，干了一件现在回想起来挺蠢的事：把带"应"字的句子抄进需求文档，把带"宜"字的句子按字面数字写进代码。

5.2 说代理期限"宜不小于 1 个月"，我就把 1 个月写成校验常量。5.9(c) 说调节容量"宜不低于 1MW"，我就在资源准入里卡死 1MW 这条线。

看着挺严谨，但是挖了两个坑。第一个坑：属地规则的门槛和标准不一样，运营要往上提一点或往下放一点，我得改代码、发版、回归——一个本该配置化的参数，被我做成了版本。第二个坑更贵：该被我盯住的"应"，反而漏了。5.3 的地理范围、5.4 的通信四能力，它们是约束，不是功能，挂在需求文档里找不到位置。等评审会上有人问我"你的资源池凭什么能参与主网调峰"，我才回去把这两条补上。

还有一件更要紧的事，我当年也搞混了：GB/T 是推荐性国家标准，通常自愿采用；被法规规章引用、企业公开声明采用，或被合同约定为交付依据之后，才产生相应约束。换句话说，先回答"这个项目采不采用这本标准、在哪一层声明符合"，再谈哪几条是硬要求——顺序反了，后面全是无用功。

先把对象说清楚。GB/T 44260-2024《虚拟电厂资源配置与评估技术规范》2024 年 7 月 24 日发布、2025 年 2 月 1 日实施，由全国电力需求侧管理标准化技术委员会（SAC/TC 575）归口。它要解决的问题一句话说完：一个虚拟电厂该配什么资源、配多少、怎么证明配得对？。

普通人读国标看到的是条文，开发者读国标应该看到三样东西：实体、字段、算法。读标准的功底也不在读得懂，在分清三类东西：条文的强度（应还是宜）、国标的效力（推荐性，看你采不采用）、工程的实现方式（参数化还是写死）。这三样混在一起，我开头那两个坑就是这么来的。

这一篇不复述条款，也不逐条平推——12 条里挑对系统有约束力的展开，追踪表共 12 行，覆盖第 5 章的 9 条（5.2/5.3/5.4/5.6/5.9/5.10/5.11）加第 3 章术语与第 6 章评估各一组；本篇未展开的条款是 5.1 应用要求、5.5 运行安全、5.7 成本测算、5.8 指标测算、5.12 电能量交易场景——它们要么是方案级的管理与流程要求，要么本期没做代码落点，所以既不展开、也不放进追踪表（5.7 的建造成本、运行成本是经济性指标，评估口径另算）。

我把这本标准当一份需求规格说明书读了一遍，读完拿到两样东西：一张覆盖标准全部技术性指标的 ResourceCapability（资源能力）领域模型，一套下次拆任何电力标准都能用的"标准 → 代码"翻译范式。

阅读约定：本文严格区分三个层次——

• 【标准原文】：GB/T 44260-2024 的条款引用，条款编号以标准正式文本为准（作者已对照公开出版文本逐条核验）；
• 【作者解释】：作者对条款的工程理解，属解读而非标准内容；
• 【工程选择】：本专栏示例工程的具体落地方式，同一条款完全可能有别的实现。 凡条款编号或表述作者未能核实的，一律标注「待核」，不臆造文号。

一、拿到标准先干三件事

一本薄薄的国标，从第一页老老实实读到最后一页，每个字都认识，合上书却落不到一张表上。这个坑踩过，后来改成先干三件事：摸章节骨架、找实体、找算法。

骨架先摆出来吧。

【标准原文】44260 的正文结构非常规整（共 6 章 + 1 个资料性附录，前两章为范围与规范性引用文件，从略），恰好把一件事从配置要求走到了评估结论：

【作者解释】其中最硬核的是附录 A 的技术性评估指标——7 个指标中 6 个在正文第 3 章给了术语定义（“发电量”只有附录公式），附录 A 给了全部 7 个的计算公式（A.1～A.7）。术语定义 + 公式，就是算法的验收标准。下面把配置要求和评估指标分别拆开。

二、第 5 章的配置要求，怎么变成系统里的约束

第 5 章共 12 条：5.1～5.8 是通用要求，5.9～5.12 按调峰、调频、备用、电能量市场 4 个场景分别给出配置要求。按对系统的影响，我把它们分成四组。

资源档案：5.6 写的就是建表清单

【标准原文】条款 5.6：虚拟电厂资源配置应收集虚拟电厂资源的基本信息，包括分布式电源装机容量、负荷额定功率、储能容量、地理位置或电气位置、设备型号等。

【作者解释】这一条读起来像句废话——"收集基本信息"，谁不知道要收集。换个读法就变了：它是资源档案表的完整字段清单。少一个字段会怎样？评估引擎跑不出结果，报告也交不出来。

【工程选择】直接翻译成实体，条文清单逐项都能对上（示例工程还多一个 gridAccountId，用于排他性校验，属业务约定）：

/** * 资源档案 —— 对应 GB/T 44260-2024 第 5.6 条 * 每类资源（光伏/储能/充电桩/空调）继承此基类 */publicabstractclassResourceProfile{private String resourceId;      // 资源唯一标识private ResourceType type;      // DG 分布式电源 / ES 储能 / FL 可调负荷private BigDecimal capacity;    // 装机容量/额定功率/储能容量 (kW)private String geoLocation;     // 地理位置（省/市/台区）private String electricalNode;  // 电气位置（并网电压等级/馈线）private String deviceModel;     // 设备型号private Long operatorId;        // 所属聚合主体private LocalDate contractEnd;  // 代理协议到期日 —— 对应第 5.2 条"最小时间期限"}

【作者解释】真正要留神的是最后一个字段 contractEnd。它来自条款 5.2"满足电力调度或交易机构对虚拟电厂资源代理的最小时间期限要求，宜不小于 1 个月"。标准里这句话是"宜"，本工程把它落成一条签约有效期校验——签约时校验，调度前再查一次。它不是常量，是默认值，这就是我开头挖的第一个坑。示例工程源码里那条注释写得更直接：代理期限"宜"不小于 1 个月，但实现按"拒绝建档"处理——那是把推荐值当硬门槛用的工程取舍（属地另有要求时按属地调），别读成标准原文。

代理期断了、资源还挂在可调名单里，出事不算技术故障，算结算争议。那时候再补校验规则，账已经算完了。

地理范围：最容易漏掉的那个过滤条件

【标准原文】条款 5.3：虚拟电厂资源配置应根据电网运行的不同层级应用，确定纳入虚拟电厂的资源地理或电气位置范围。对于主网调峰、调频或电能量交易，应在省域范围内确定；对于配网层级应用，应根据相应电压等级和配网范围确定。

【作者解释】这一条对聚合引擎是个硬约束：参与主网调峰的资源池只能聚合本省资源；参与配网应用的要按电气位置圈定。

【工程选择】落到查询上，就是资源筛选 SQL 里永远带着 geo_location 和 electrical_node 两个过滤条件。现状要诚实说：聚合引擎（第 14 篇）的分组逻辑按出清节点圈电气位置，这一半已经落地；省域这一半还没做，追踪表里 5.3 那一行标的就是"部分实现"。它不是可以往后放的功能，是属地交付时最容易漏掉的验收项。

把一条省外的资源混进主网调峰池，算法没错，每个字段都对，错的只有范围——申报环节被驳回来，一个申报窗口就这么过了。所以这类问题不难避免，缺的是把"应"字条款也放进验收项里的习惯。

接入四能力：这张表就是接入层验收清单

【标准原文】条款 5.4：虚拟电厂资源应具备数据采集、双向信息通信、数据传输加密及校核能力。

【作者解释】这一条是物联接入篇章的验收标准，四项能力缺一项就不符合 5.4 的完整能力要求。【工程选择】翻译过来就是接入层要实现四项能力：

在 openvpp-demo 里，这四项的测试覆盖要如实说：只有数据采集这一项有真正的链路验证（openvpp-gateway 的 MqttIngestServiceTest，走公共 broker 的明文 tcp:// 回环，1 项），数据校核的认证逻辑有较完整单测（openvpp-iot 的 DeviceAuthTest，16 项，覆盖错密钥、重放、改正文），但 DeviceAuthFilter 目前尚未接进 openvpp-gateway 的报文入口，属"逻辑已验证、链路未接线"；双向通信的下行通道、传输加密（TLS）、CRC/完整性校核三项还没有端到端测试。标准条文的每一条，都应该能对应至少一个可执行的测试——测试不会替你判断业务，但它会替你守住"这条我到底做没做"。这四项缺一项，就无法证明接入层具备完整的可调能力。

场景决定资源类型：策略规则的源头

【标准原文】条款 5.9（调峰/需求响应）：虚拟电厂可参与电力系统调峰或需求响应，基于聚合资源的上下可调特性，调节自身总出力，维持电网电力平衡；应具有响应一种或多种时间尺度调峰需求的功率调节能力（含日前、日内、小时级、分钟级）；典型资源配置宜以可调节负荷为主，配置部分分布式储能及可调分布式电源；调节容量宜不低于 1MW。条款 5.10（调频）：典型资源配置宜以分布式储能、电动汽车充电桩为主，配置部分可调分布式电源（如小型燃气机组等）；应具备在秒级到 1 min 以内及时做出调整的能力；宜配置负反馈控制环节，降低调节偏差率。条款 5.11（备用）：虚拟电厂可为电力系统提供备用容量；典型资源配置宜以具备确定性的功率调节容量的资源为主，如储能、电动汽车换电站或可调分布式电源等。

【作者解释】这三条是业务规则最密集的三条（5.12 电能量交易场景偏流程要求，本篇不展开）：不同应用场景对资源类型、响应时间的侧重点不同，资源池必须按场景分组。

两点必须说清楚。第一，"为主"不是"只允许"。 5.10(d) 的原文是"宜以分布式储能、电动汽车充电桩为主，配置部分可调分布式电源"——它是推荐配置构成，不是排他准入；读成"只准储能和充电桩进"就加重了条款。本篇教学实现在这一点上走了另一个方向：openvpp-demo 的 RuleEngine 把调频收窄为只放行储能（ES），那是一条教学默认规则，比标准更严，不是标准口径；生产形态按属地规则配。

第二，调峰不是"分钟级"一个尺度。 5.9(a) 要求的是覆盖日前、日内、小时级、分钟级的一种或多种时间尺度，把它压成"分钟级"会把日前和小时级品种挡在门外。

这张表就策略引擎里规则 DSL 的业务源头——"场景决定资源类型、响应时间设上限"这两条教学默认规则的上游依据就在这里。

顺带说一句业务账：场景划分不是分类爱好，它决定你手上的资源能不能报进那个品种。调频是这几类场景里对响应能力要求最硬的一档，配置够不上，那块市场你进不去——账面容量再大也只能看着。

三、7 个指标，就是算法接口的入参表

【标准原文】技术性评估指标是 44260 的算法核心：第 3 章术语 3.6～3.11 给出 6 个指标的术语定义（发电容量、调节容量、响应时间、爬坡率、调节偏差率、发电持续时间），"发电量"不在术语章；附录 A.1 给出 7 个指标的计算公式（A.1～A.7）。

【工程选择】我们把定义和公式摊开看一遍，会发现它们全部能收进一张能力评估结果表：

/** * 资源能力评估结果 —— 对应 GB/T 44260-2024 第 3 章术语 3.6~3.11、附录 A.1 * 每个资源每个评估周期产出一条记录 */publicclassResourceCapability{private String resourceId;private LocalDateTime assessTime;    // 评估时刻// —— 7 个技术性指标（术语 3.6-3.11 / 附录 A.1.1-A.1.7） ——private BigDecimal genCapacity;      // 3.6 发电容量：输出有功功率最大值（附录 A.1.1）private BigDecimal annualEnergy;     // 年发电量（附录 A.1.2）private BigDecimal adjustCapacity;   // 3.7 调节容量：最大与最小输出功率之差（附录 A.1.3）private Long responseTimeMs;         // 3.8 响应时间：指令到功率变化超阈值的耗时（附录 A.1.4）private BigDecimal rampRate;         // 3.9 爬坡率：每分钟单方向功率变化占调节容量百分比（附录 A.1.5）private BigDecimal deviationRate;    // 3.10 调节偏差率：实际与目标变化量差值占比（附录 A.1.6）private Long sustainSeconds;         // 3.11 发电持续时间：达标维持时长（附录 A.1.7）// —— 衍生字段（供聚合与策略使用） ——private Scenario applicableScenario; // 适用场景：PEAK_SHIFT / FREQ_REG / RESERVEprivate BigDecimal confidence;       // 置信度折扣（工程实践扩展，非标准内容）}

【作者解释】这张表是评估引擎、聚合引擎、策略引擎共同的输入。指标算错不是算法分低，是报出去的容量不可信，调度不敢用。公式本身都不复杂，难的是三个地方。挑三个最容易算错的指标细说。

调节容量：一个差值，两种陷阱

【标准原文】术语 3.7（附录 A.1.3）的定义是：根据指令可达到的最大输出功率与最小输出功率的差值，并注明"虚拟电厂消耗功率时，输出功率为负值"。

【作者解释】这句话意味着，对储能这类双向资源，调节容量 = 最大放电功率 − 最大充电功率（负值），跨度是满充到满放。代码里最常见的 bug 是只算单方向——把充电桩的"最大充电功率"当调节容量，忽略了它还能反向放电——不过这条要加限定：只有具备双向充放电能力的充电桩才放得出电，车网互动（Vehicle-to-Grid，V2G）是要硬件支撑的，不是桩就能放。

【工程选择】符号约定必须在 ResourceCapability 层面统一：输出为正、输入为负。为什么要在模型层面就定死呢？因为聚合是求和。符号混了，正负相消，容量池直接算崩——报出去的容量是虚的，执行的时候交不出货，考核自己认。

响应时间：公式里藏着监控埋点

【标准原文】术语 3.8（附录 A.1.4）的公式：T_re = t_action − t_order。标准并注明：阈值根据当地实际情况进行设定。

【作者解释】这个公式看着简单，落地时全是活：t_order 是平台发出指令的时间（应用日志里有），但 t_action 是"输出功率按指令方向变化至超出阈值"的时间——本文工程从设备侧遥测取这个时刻（时序数据链路要支持"指令发出后，在该设备的遥测流里检索首次功率变化超阈值的时刻"，第 8 篇专门有一段讲这个检索怎么高效实现：按设备 + 时间窗口索引，不能全表扫）；生产系统也可以按计量边界取数，标准只规定了"功率变化至超出阈值"这一刻，没限定取数字段。

顺带注意标准那句话的分量：A.1.4 里的阈值只是响应起算的判定参数（功率变化超过多少才算"开始动作"），它不改变 5.10(a) 给的 1 min 响应上限。阈值定得不准，响应时间就是个虚数——而评估报告是要交到电网和投资方手上的，虚数过不了那一关。

调节偏差率：调频市场的入场券

【标准原文】术语 3.10（附录 A.1.6）定义：虚拟电厂实际功率变化量与目标功率变化量的差值占目标功率变化量的百分比。配合配置要求 5.10(b) 的"宜配置负反馈控制环节，降低调节偏差率"。

【作者解释】这两个条款要分开读：5.10(c) 说虚拟电厂"应满足调节容量、响应时间、爬坡率、调节偏差率等指标要求"，这是硬门槛；5.10(b) 的负反馈是达到这个门槛的推荐实现——"宜"，不是第二道门槛。

【工程选择】做调频业务的平台不能只"下发指令就完事"，偏差监测和二次修正回路值不值得投，取决于你要不要吃调频这块市场；直控型与邀约型 VPP 在这条链路上的投入差别也主要落在这里。附录追踪表里 5.10(b) 那一行的"指令链路偏差监测模块"，就是这条推荐要求的落点。偏差率压不住，门槛最硬的品种报进去也守不住，考核条款会替客户把账算回来。

四、综合评估：标准定框架，运营定参数

【标准原文】条款 6.4：评估宜根据预期服务的应用场景，选取对应的技术性指标和经济性指标，基于计算结果进行综合评估；附录 A.3.1 给出应用场景与评估指标的对应关系（表 A.1），A.3.2 给出设定值达成判据（表 A.2），A.3.3 规定可将指标均达成设定值的方案作为备选，再结合年净收益与年投资回报率选取最终方案。

【作者解释】6.4 给的是流程主干，配上附录 A.3 就是三步："场景选指标 → 逐项对设定值判定 → 指标均达标的方案里比经济账"。

【工程选择】按这个框架，评估代码该分两层：

/** 第一层：达标门禁 —— 标准路径，逐项对设定值判定，不达标即出局 */publicinterfaceAssessGate{booleaneligible(ResourceCapability capability, Scenario scenario);}/** 第二层：方案比选 —— 备选方案之间比年净收益与年投资回报率，对应 A.3.3 */publicinterfacePlanComparator{Plan pick(List<Plan> eligiblePlans);}/** * 附带的加权评分 —— 非标准扩展 * 标准没给加权评分法；加权只用于同场景内的资源排序与择优推荐， * 不能替代上面的达标门禁，也不能用来"算总分绕过设定值判定" */publicinterfaceAssessStrategy{doublescore(ResourceCapability capability, Scenario scenario);}

必须诚实交代一句：本篇示例工程目前只落到接口层，AssessStrategy 有接口无实现、权重也没有配置化——加权评分是"标准定框架、运营定参数"里属于运营的那一半，生产形态才需要真正落地；标准路径（达标门禁 + 经济比选）反而是更该先补的一层。

另外提醒一个源码里的措辞坑：AssessStrategy 的注释曾把附录 A 的综合评估写成"加权评分法"，那是工程扩展的自我描述，不是标准方法——标准 A.3 给的是场景与指标的对应关系（表 A.1）和设定值达成判据（表 A.2），路径是判定，不是打分。

【标准原文】条款 6.5：虚拟电厂资源配置方案应出具评估报告，评估报告包括但不限于以下内容——(a) 虚拟电厂预期服务的应用场景；(b) 资源配置方案，包括纳入虚拟电厂的资源类型、数量、基本参数、历史运行数据、建设成本、运行成本、地理或电气位置等；(c) 选取的评估指标及计算结果，包括技术性指标和经济性指标；(d) 综合评估结论，确定推荐方案；(e) 评估人员及评估日期。

【工程选择】这几项内容就是一个报告模板加渲染服务，技术上没有难度。但它是聚合商与电网、投资方之间的正式交付物——标准此处用的是"应"，字段按方案配齐，属地评审要求更细时按属地补。缺字段的代价不是技术故障，是评审阶段返工，拖的是投资决策的节奏。

附带说明两点：其一，标准这条列了 a~e 五项，其中 (d) 项同时包含"综合评估结论"与"确定推荐方案"，(e) 项是评估人员及评估日期；上面的条文清单与追踪表都是这个口径。其二，报告是"按方案"出具，不是"按资源"出具——评估对象是资源配置方案，(c) 项要求同时给出技术性指标与经济性指标的计算结果。

五、四步范式：下次拿到任何标准都能这么拆

把本文的做法总结一下，这也是后面所有标准类文章的固定范式：

1. 找实体：条文里的名词（资源、方案、指标、报告）→ 领域模型类；
2. 找字段：条文里的"包括但不限于"清单 → 表字段，一条不落；
3. 找规则：条文里的"应/宜" → 两套落点（"应"是符合性要求，"宜"是推荐做法，"不低于"这类数值要结合前面的强度词判断）；
4. 找算法：条文里的公式 → 算法接口的入参与出参，公式注释里标标准条款号。

四步走完，标准就从一叠纸变成了能拿去评审的表。

先说清适用前提：44260 是推荐性国家标准，通常自愿采用；被法规规章引用、企业公开声明采用，或被合同约定为交付依据后，才产生相应约束。所以第 3 步要问的第一个问题不是"该怎么实现"，而是"这个项目采不采用、在哪一层声明符合"。

第 3 步展开一下，它是这套范式里最容易做错的一步：

（这张表只讲标准怎么落到工程；至于要不要再把它变成市场准入或合同验收条件，由适用法规、市场规则和合同约定决定，不在这张表的考虑内。）

心法就一句：项目采用本标准并声明符合之后，"应"是符合性验收项，"宜"是推荐做法——数值型"宜"可以落成可配置默认值，非数值型"宜"（比如 5.10(b) 的负反馈控制）要落成设计决策 + 偏离理由，不能硬塞一个默认值了事。整个 44260 里能被直接写成数字的门槛，我只找到三处——5.2 代理期限宜不小于 1 个月、5.9(c) 调节容量宜不低于 1MW、5.10(a) 调频响应应做到秒级到 1 min。前两个是"宜"，属地可以按适用规则调成自己的门槛；第三个是"应"，1 min 是标准给出的响应上限，采用本标准时不得放宽到 1 min 以外，但适用规则可以进一步收紧，工程上要建模的是响应时间上限（maxResponseTimeMs），不是"属地准入参数"。别把它和附录 A.1.4 的阈值混成一个东西：A.1.4 里那个可以按当地情况设定的阈值，是判定 t_action（响应起算时刻）用的功率变化阈值（actionPowerThreshold），调的是"从哪一刻算响应开始"，不是"允许多慢"。这两个参数在代码里是两回事：响应上限有字段也有值（DispatchRule.maxResponseTimeMs，调频取 60s），而功率变化阈值在示例工程里没有落点。另外那三个数字（1 个月、1MW，以及 1 min 的工程换算 60s）眼下散在三个模块硬编码：ResourceLedgerService（plusMonths(1)）、AdmissionThreshold、RuleEngine，谁都没有属地参数化；AdmissionThreshold 只是其中一个常量类，别把它读成统一收口。改成真正的属地配置属于生产扩展条件，也是我当年那两个坑留下的账。

附录：条款—需求—设计—测试—证据追踪表

把本文引用的条款汇成一张追踪表。

【工程选择】需求评审和验收测试时就拿它对。关键在于表里的证据必须真实存在——我在上一版稿子里把想要有的测试当成已经有了（ContractValidatorTest、AdmissionTest 这类名字是我顺手编的），这版一律只写跑得到的类名，没实现的直接标"待实现"：

说明：「强度」一列以标准原文用语为准（"应/宜"）；"定义+公式"指该行为术语定义与附录公式，属算法验收依据而非流程条款。统计口径：12 行中 1 行按标准路径已实现（5.10(a)）、8 行部分实现或教学收窄、3 行待实现（5.10(b)、6.4、6.5）；6 行有直接相关测试（5.2、5.3、5.4、5.6、5.10(a)、5.10(d)），其中 5.11(c) 的测试只验证规则已注册、不验证资源类型。另有 1 项表外工程缺口——库表建表脚本（不单列成行）。注意"部分实现"不等于合规——5.3 的省域过滤、5.4 的三项端到端、5.9(c) 的判据单测都还是缺口。"待实现"不是遗憾清单，是后续篇章与工程补齐的输入。 计数口径：本表"（N 项）"为该测试类在冻结快照上的用例数；

结语：标准管框架，剩下的归你

这篇的结论收成三句：

一、分清强度，再谈效力。 "应/宜"决定条文强度，推荐性国标决定它对你有没有约束力；顺序是先确认项目采不采用，再谈哪几条当硬要求。未经适用规则、合同或项目决策，就把"宜"直接做成拒绝逻辑、把"为主"读成"只允许"，是坑——反过来说，像本项目这样明确把 5.2 的 1 个月当硬门槛，属于有依据的工程决策，不是误读标准。

二、模型是落点，不是抄写。 5.6 的清单变 ResourceProfile 的字段，3.6~3.11 和附录 A.1 变 ResourceCapability 的七项指标——条文里的名词、清单、公式，各自落到实体、字段、算法，标准才从一叠纸变成能评审的东西。

三、证据必须真实。 追踪表里写下的每个类名、每项结果，都要能在工程里跑出来。这份表里还留着 3 个"待实现"，外加 1 项表外缺口（资源档案的库表建表脚本），它们不是遗漏，是后面篇章的输入。

44260 解决的是"资源怎么配、能力怎么评"。但一个平台光有资源能力还不够——系统的功能架构、安全分区、通信要求由谁定？答案是 GB/T 47241-2026《虚拟电厂技术导则》，2026 年 9 月 1 日实施。它比 44260 厚得多，因为它要定义的是整个平台。

下一篇我们用同样的四步范式拆 47241，画出专栏的平台全景架构图——接入层、网络层、平台层、应用层，每一层对应标准里哪一章、系统里哪个服务，一次说清。