论电力数字化转型

电力系统的数字化转型，究竟要改变什么？我的理解是：不只是把纸质材料搬进计算机，也不只是增加一套平台，而是利用数据、模型和软件，改善观察系统、形成判断、组织工作和实施控制的方式。

新技术提供了更多工具，但需求不会因此变得次要。我的一些工程经历，使我尤其关注那些不够醒目、却每天消耗现场人员时间的问题：设备名称查不到，量测质量说不清，模型版本对不上，同样的故障反复排查，算法有了却没有人维护。解决这些问题，也可能创造很大的价值。

本文保留原文关于工程创新的主旨，但不再以几年前的企业竞争格局、个别产品体验或未经核实的行业数字判断今天。对于人工智能，也应区分已经验证的能力、合理的研究方向和仍待验证的设想。

1. 创新不能只看新颖性，也不能只看眼前利润

工程创新、科学发现、发明和商业成功相互联系，却不是同一个概念。OECD/Eurostat《奥斯陆手册》强调，创新需要形成显著不同的产品或过程，并进入提供给用户或实际使用的阶段；其基本定义并不要求创新最终取得商业成功。[1]

因此，“没有立即盈利就不算创新”过于苛刻，“有论文、专利或演示就已经完成工程创新”又过于宽松。评价时应先说清楚讨论的是知识贡献、技术原型、生产应用，还是可持续的产品业务。

对于电力工程项目，我更关心三组问题：解决了什么真实问题，效果有什么证据，长期由谁承担成本和责任。经济性当然重要，但安全、韧性、环境和公共服务价值也需要纳入评价，不能把所有项目都简化为短期投资回收期。

基础研究与工程应用也不应被对立起来。基础研究可以在尚无明确产品时拓展方法，工程反馈则可能提出新的研究问题。两者需要不同的评价尺度，也需要能够共同工作的接口。仅凭学历、年龄、是否使用某种语言，不能判断一个团队的工程能力。

2. 从现场问题出发，而不是为工具寻找题目

我早期在变电站工作时，设备台账的整理和查询需要大量人工劳动。把信息电子化、可检索化，本身就能改善工作。但当电子化已经完成，继续增加录入字段或展示页面，未必还会带来同样的收益。

一个更具体的需求是设备检索。运行人员可能只记得设备的简称、旧名或相关线路，也可能需要在紧急情况下迅速定位一次接线图。此时，统一设备标识、名称映射、模糊检索和权限内的上下文跳转，往往比再增加一张综合大屏更有帮助。

另一个需求是关键量测的可信度。AGC、AVC等控制功能依赖量测质量，但具体使用原始遥测、滤波结果还是估计值，取决于系统设计和时间尺度，不能一概而论。需要解决的是：量测是否新鲜，通道是否异常，冗余来源是否真正独立，质量下降后控制如何降级，而不是只给整个系统一个笼统的“数据准确率”。

这些例子来自工程问题的归纳，不针对某个单位或产品。不同系统的版本、配置、运行规程和用户熟练程度不同，一次使用体验不足以推出对供应商整体能力的判断。

对于研发，我建议先给问题设一个可观察的基线：查询任务原来需要多久，数据错误导致多少返工，某类异常多久能发现，哪些风险还没有覆盖。完成改造后，在相近条件下再次测量，才能知道投入是否真正改变了工作。

3. 数据平台的基础，是语义和责任

把数据集中起来，并不等于数据已经可以共同使用。电力系统数据至少涉及设备身份、拓扑连接、运行时标、量纲与标幺基准、正负号约定、质量标志、模型版本和访问权限。

例如，同名设备未必是同一设备；同一设备的规划参数、竣工参数和运行修正参数，也未必可以相互替代。量测属于一个时刻，开关状态却属于另一个时刻，把它们拼成的断面可能没有一致的物理含义。

因此，数字化平台首先需要回答谁产生数据、谁校验数据、谁有权修改、谁可以使用，以及修改后哪些应用需要重新计算。CIM等信息模型有助于形成共同语义，但标准名称本身不会自动消除各系统的扩展差异和数据质量问题。[2]

数据开放也不等于无条件互联。可开放的接口、数据使用权、模型知识产权、安全分区和运维责任，需要在技术方案及合同中写清楚。对生产控制相关系统，安全防护必须进入规划、建设和运行全周期，而不是平台建成以后再补一个边界设备。[3]

4. 模型是工程判断的工具，不是精确性的装饰

我曾在业余时间尝试使用稀疏矩阵和高性能数值计算方法改造传统程序。这段经历让我认识到，算法、数据结构和计算工具的改进可以互相促进。但某次程序运行更快，并不意味着它背后的物理假设也更准确。

数字化转型应当把模型假设显式化。例如，常规机电暂态模型中忽略定子磁链的快速微分项，是与研究频段、时间尺度和其他近似相配合的建模选择；不能因为软件把网络写成代数方程，就反过来认为物理系统必须如此。换用电磁暂态模型，也需要相应的参数和验证数据。

同样，仿真结果多出几位小数，不等于工程决策更可靠。应分别检查数值误差、模型误差、参数误差和量测不确定性，并分析这些误差是否会改变决策。理论证明、解析算例、对比仿真和现场数据各有价值，不能用其中一种证据包办全部问题。

对于复杂优化问题，简单模型可能更便于求解、解释和维护，但必须保留影响目标的重要约束。所谓实用性，不是允许结果违反物理规律，而是在说明适用范围的前提下，选择足以支持决策的方法。

5. AI应按任务和风险评价，而不是按口号评价

大语言模型、预测模型、视觉识别和运筹优化不是同一种技术。大语言模型也不能因为擅长生成文本，就直接被当作已经实现通用人工智能的工程系统。讨论应用时，应具体到任务、输入、输出和错误后果。

在资料检索、规程辅助查询、报表整理、代码草拟和知识归纳中，AI可能减少重复劳动。对负荷、新能源功率或设备状态的预测，也可以比较不同方法在真实数据上的效果。但评价需要使用与实际部署一致的数据切分和场景，避免把时间泄漏、重复样本或只在正常工况上的高分，误认为工程能力。

规程问答尤其需要显示原始出处、适用设备、版本和生效时间。检索增强生成可以帮助引用资料，但不能保证检索结果完整，更不能保证生成内容没有误解。模型应允许拒答和升级给专业人员，而不是在缺少证据时仍然给出确定的操作建议。

对于安全分析，AI可以参与算例排序、预筛选或候选控制方案生成，但必须评价整个流程的漏判风险。即使最后一步使用经过验证的物理求解器，前面错误排除关键故障，也会损害整体可靠性。因此，不能说机器学习只影响速度、与最终安全结论毫无关系。

对于直接影响生产控制的功能，我主张先明确权限边界，再讨论自动化程度。独立校核、约束检查、日志追溯、异常阻断和回退机制，不能由一段“请谨慎回答”的提示词代替。NIST的AI风险管理框架可作为识别、评价和管理风险的参考；它不是电力生产控制功能的准入证明。[4]

6. 私有部署不等于安全，专业语料不等于低成本

行业应用可以采用检索增强、已有模型适配或专门训练等路径。哪一种合适，应比较任务效果、数据权限、算力、延迟、运维和生命周期成本，而不是先假定必须从头训练一个行业大模型。

电力文本较规范，有利于整理知识，却不意味着训练和验证一定便宜。规程版本冲突、设备差异、图纸和表格解析、错误样本不足、专业标注，以及罕见异常场景的评价，都可能成为主要成本。

本地或私有云部署有助于控制部分数据流向，但不会自动解决账户权限、漏洞、供应链、提示注入、工具调用权限和备份恢复问题。OT系统还必须考虑物理过程、可用性、实时性和安全后果，不能照搬一般办公系统的部署习惯。[5]

截至本次修订，相关设计还应遵守自2025年1月1日起施行的《电力监控系统安全防护规定》。业务分区、防护边界和接入条件，应按实际功能确定，不能因为系统冠以“云”“AI”或“应用商店”就绕过要求。[3]

7. 开放架构：让专业分工与持续改进相互支持

原文把研发关系概括为几个先后阶段。更准确的说法是，运营单位自主研发、供应商提供产品、双方联合开发和开放生态等模式可以长期并存，并不遵循所有单位都相同的单一路线。

运营单位了解现场目标与约束，供应商掌握产品实现和工程化方法，高校与研究机构可以提供理论、方法和独立研究。这些能力相互补充。合作中的主要风险，不在于哪一方天然优越，而在于需求、数据、接口和技术责任是否清楚。

一个可演化的平台，可以把相对稳定的基础功能与变化较快的业务应用分离。业务人员提出需求，开发人员实现功能，双方通过仿真、测试和运行反馈共同修正。但开放接口不是任意注入代码，尤其不能把AI生成的脚本未经审查就放入生产控制环境。

更可行的路径是：先在隔离的开发和仿真环境中验证，再按风险等级进入试运行和正式发布；同时保留版本控制、权限管理、回归测试和撤回能力。是否允许某类应用进入某个安全区，必须服从相应管理要求，而非由开发便利性决定。

8. 把方法落实为四项工作

原文的读书笔记使我重视四个方向：澄清问题、控制复杂性、形成系统联系、沉淀经验。下面保留这些方向，但不再用未经逐页核对的长段引语代替自己的论证。

把模糊问题说明白。 不只写“提升智能化水平”，而要说明谁在什么场景下遇到什么困难，目标与约束是什么，怎样判断改进有效。

把不必要的复杂性减下来。 架构、平台和中间件应服务于业务。是否采用微服务、容器编排或大规模分布式系统，需要看独立部署、容量、可靠性和团队维护能力，不能只按技术流行程度选择。

把分散的问题联系起来。 电网、发电、储能和负荷的协调可能带来收益，也可能增加耦合风险。系统集成并不天然保证“整体大于部分之和”；收益需要在约束、成本和异常场景下验证。孤立系统也可以稳定运行，只是必须具有与自身运行方式相匹配的调节和保护能力。

把经验沉淀为可检查的工作产品。 经验可以转化为用例、规则、参数、故障库和培训材料。AI可以辅助整理，但经验中的适用条件与例外也要保存。将一条经验写进软件，并不等于它已经成为普遍规律。

结语

我仍然认为，数字化转型给电力工程师提供了更大的发挥空间。理解物理系统、能够建模计算、熟悉现场约束，又愿意与不同专业协同，是值得持续培养的能力。

但技术进步不会自动替我们完成判断。工具更强以后，问题定义、验证证据和责任边界反而更重要。电力数字化转型的成果，不应只看增加了多少系统、模型和界面，而应看是否让真实工作更有效，让系统风险更可知，让改进能够持续。

参考资料与修订说明

[1] OECD/Eurostat. Oslo Manual 2018，关于创新的实施要求、定义与结果评价。

[2] IEC. IEC 61970-301:2020+AMD1:2022，CIM基础模型，引用官方公开范围说明。

[3] 国家发展改革委2024年第27号令：发布公告；司法部：《电力监控系统安全防护规定》全文，特别是业务分区、安全管理与全生命周期责任的规定。

[4] NIST. AI Risk Management Framework.

[5] NIST. SP 800-82 Rev. 3: Guide to Operational Technology Security，官方摘要所说明的OT性能、可靠性与安全约束。

2026年修订：重组创新、数据、模型、AI与研发协同的论述；删除过时的竞争判断、未经证实的行业成本和人物轶事；将负面个案改为不指向具体单位或个人的问题分析。本文讨论工程方法，不替代具体系统的审批、试验和运行规程。