夜雨聆风这两年，电力行业谈人工智能的人很多，谈大模型的人更多。很多单位都在建知识库、做智能体、上模型平台、搞样本库，也都能做出一些演示效果。但如果站在电力业务和软件研发的角度看，今天最值得追问的并不是“我们用了什么模型”，也不是“某个场景效果提升了多少个百分点”，而是一个更底层的问题：人工智能到底有没有改变电力研发本身？
如果只是用大模型写几段代码、生成几份文档、辅助测试几个接口，当然有价值，但这只是工具改良；如果只是把一个视觉模型、时序模型或问答模型嵌入原有系统，能够提升局部效率，也值得做，但这仍然是能力增强。真正的范式变化，是研发体系从一开始就按照 AI 的逻辑组织：业务对象怎么定义，数据怎么变成样本，专家经验怎么变成知识和规则，模型怎么嵌入流程，系统能力怎么被智能体调用，错误结果怎么回流，能力怎么持续进化。
这才是“从 AI 工具到 AI 原生”的关键。
电力研发范式大体分成三个层级：L1 是 AI 工具化，L2 是 AI 工程化，L3 是 AI 原生化。三个层级不是简单的技术成熟度划分，而是研发责任边界、交付对象和组织方式的变化。L1 解决“人怎么更快干活”，L2 解决“AI 怎么进入研发流程和业务流程”，L3 解决“电力系统和研发体系能不能按 AI 的方式重新设计”。
一、L1：AI 工具化，提升效率，但不改变研发逻辑
当前大多数单位还处在 L1 阶段。这个阶段最典型的表现，是研发人员把 AI 当成效率工具使用。开发人员用 AI 生成代码、解释报错、写单元测试；产品经理用 AI 整理需求、归纳会议纪要、生成原型说明；测试人员用 AI 生成测试用例、分析日志；项目经理用 AI 起草周报、方案、汇报材料。这些场景很现实，也很有用。
过去一个研发人员写一个普通接口，需要查表结构、看历史代码、找类似实现、拼 SQL、调返回格式。现在 AI 可以快速给出一个初版。过去写测试用例、整理接口说明、生成一批模拟数据，是很耗时间的工作，现在 AI 可以把大量重复劳动压缩掉。对于电力软件研发中大量标准化、模板化、重复性开发工作，L1 阶段的效率提升是明确的。
但 L1 的问题也很明显：AI 提高的是局部效率，不改变项目成败的关键因素。电力系统里的复杂问题，往往不是代码写不出来，而是业务关系没有理清、数据口径没有统一、规则边界没有讲清楚、流程闭环没有设计好。
比如“低电压治理”，如果业务规则没有定义清楚，只知道要做低电压分析，那 AI 生成出来的东西大概率只是指标展示和解释文本。真正有价值的是要把用户、电表、台区、配变、负荷曲线、事件记录、治理措施、整改结果串起来，判断低电压发生在什么时间、影响哪些用户、是否与配变负载有关、是否与末端用户分布有关、是否与三相不平衡有关、过去是否处理过、处理后有没有恢复。没有这些业务结构，AI 只是包装层。
所以 L1 阶段不能被低估，也不能被高估。它能帮助个人提效，能让团队减少低价值劳动，能改善文档、编码、测试、沟通效率。但它并不会自动带来 AI 项目成功，更不会自动形成电力 AI 能力。
L1 的本质是：原来的研发流程不变，只是每个环节多了一个助手。业务还是人定义，方案还是人设计，代码还是人审核，系统还是按传统方式交付。AI 是外挂工具，不是研发体系的一部分。
这也是为什么很多单位用了 AI 编程工具以后，短期感觉效率提高，但项目管理、需求变更、现场交付、模型效果、数据质量这些老问题并没有消失。因为真正制约电力研发效率的，从来不只是代码产出速度，而是复杂业务被结构化、工程化、产品化的能力。
二、L2：AI 工程化，交付对象从“功能”转向“能力”
L2 阶段开始出现真正的变化。AI 不再只是个人工具，而是进入研发过程和业务系统，成为项目交付的一部分。这个阶段最大的特点，是交付对象开始从“功能模块”转向“业务能力”。
传统软件项目交付的是功能。比如建设一个异常分析模块、一个负荷预测页面、一个知识查询入口、一个图像识别功能。功能交付关注的是页面有没有、接口通不通、流程能不能走完、权限是否满足、性能是否达标。
但 AI 项目真正要交付的不是功能，而是能力。比如数据采集异常诊断能力、台区负荷预测能力、知识问答能力、现场语音转写能力。这些能力并不等同于一个页面或一个接口。它背后至少包括数据、样本、标签、模型、规则、知识、评测、服务封装、业务嵌入和反馈回流。
这就是 L2 和 L1 的本质区别。L1 是人在原有流程里使用 AI，L2 是 AI 能力进入工程体系。
这时候项目的关键交付物就不再只是代码，而是“可持续运行的 AI 能力”。功能可以一次上线，能力必须持续运营。
再看数据采集异常自动处理。传统系统可以做规则配置、策略下发、任务调度和结果展示。但如果进入 AI 工程化阶段，就要把采集异常样本、终端健康评价模型、策略智能匹配模型、补召排程模型、主站健康度评价、远程处置动作、工单闭环结果统一起来。这里面有规则，有小模型，有时序数据，有业务流程，有现场反馈。项目管理也不能再只盯开发进度，而要管理样本进度、模型效果、接口封装、现场验证和闭环数据。
L2 阶段还有一个重要变化，就是研发过程本身开始被 AI 重塑。需求分析不能只写自然语言需求，而要逐步沉淀为业务对象、业务规则、输入输出、边界条件和验收指标。测试不能只测功能是否可用，还要测模型效果是否稳定、不同地区数据是否泛化、误判漏判是否可接受、人工复核链路是否清晰。运维不能只看服务是否在线，还要看模型漂移、样本回流、评测结果和版本迭代。
这意味着，AI 工程化不是“算法组训练一个模型，开发组接一个接口”这么简单。它要求软件工程、数据工程、算法工程、业务工程、样本工程同步推进。
L2 阶段最容易踩的坑，是仍然用传统软件项目的管理方式管理 AI 项目。传统软件项目可以把需求、设计、开发、测试、上线拆成阶段；AI 项目也可以拆阶段，但样本和模型的不确定性要大得多。数据可能拿不到，标签可能不稳定，样本分布可能偏，模型效果可能达不到预期，业务现场可能不断变化。如果项目一开始没有把样本、评测、模型迭代和人工复核作为主线纳入计划，后面一定会失控。
所以 L2 的核心，不是做了多少模型，而是有没有形成 AI 工程化交付能力。一个成熟的 L2 团队，应该能回答几个问题：这个场景的业务对象是什么？样本从哪里来？标签谁定义？模型怎么评测？规则怎么兜底？系统怎么调用？结果怎么回写？错误怎么复盘？能力怎么复制到下一个场景？
能回答这些问题，才算真正从 AI 工具走到了 AI 工程。
三、L3：AI 原生化，研发体系围绕业务对象、样本和闭环重构
L3 是更深的一层。到了 L3，AI 不再是被嵌入到现有系统里的能力，而是系统从设计之初就假设 AI 会参与判断、推理、执行和优化。这个阶段不能简单理解为“系统更智能”，而是研发范式发生变化。
过去电力软件研发的底层逻辑，是围绕流程和功能建设系统。业务部门提出需求，研发团队分析流程，设计功能模块，开发页面和接口，最后上线运行。系统的核心是流程固化和数据记录。
AI 原生研发的底层逻辑，是围绕业务对象、证据链、模型能力和行动闭环建设系统。它首先关心的不是页面怎么做，而是业务世界中有哪些稳定对象，这些对象之间是什么关系，运行过程中产生哪些证据，依据什么规则和模型做判断，判断之后触发什么动作，动作执行后结果如何反馈，反馈如何变成新的样本和知识。
这听起来像技术概念，但在电力业务里非常具体。
比如营销业务的基础对象包括供电单位、线路、台区、配变、用户、计量点、终端、电表、负荷资源、工单、作业任务。它们之间有供电关系、计量关系、采集关系、资产关系、责任关系和流程关系。在传统系统里，这些关系往往分散在不同数据表和系统模块中，人可以通过经验理解，但 AI 不理解。到了 L3 阶段，这些对象和关系必须被显式建模，形成业务本体。
这里要特别强调，业务本体不是把所有名词列成清单。工单、事件、缺陷、负荷曲线、处置策略、现场作业任务当然都是重要对象，但它们不是主干。主干应该是供电单位、线路、台区、配变、终端、电表、用户、计量点等稳定实体，以及它们之间的供电、采集、计量、资产和责任关系。事件、工单、缺陷、曲线、策略、图片、日志是挂在这些实体和关系上的状态、证据、过程和动作。只有这样建模，AI 才能沿着业务链条推理，而不是孤立地解释一条告警。
以数据采集异常诊断为例，L3 的系统不是“发现异常后调用模型解释一下”。它应该是：异常事件发生后，系统自动定位关联的用户、电表、终端、台区、主站链路和责任单位；同时拉取表码、电压、电流、事件、召测、通信日志和历史工单；规则引擎先排除确定性问题，小模型识别异常模式，时序模型判断趋势，大模型结合知识库和历史案例生成解释；智能体再根据权限调用远程召测、参数核对、补召排程或工单创建能力；处置结果回写后，系统判断异常是否恢复，并把本次过程沉淀为样本。这个链条里，AI 不是一个按钮，而是业务运行机制的一部分。
这就是 AI 原生和 AI 应用的区别。
L3 阶段还有一个更重要的变化：样本成为研发体系的核心资产。传统软件时代，代码是最核心的资产；AI 原生时代，代码依然重要，但样本、知识、规则、评测集和业务对象模型同样重要，甚至在某些场景中更重要。
为什么？因为 AI 能力不是写出来的，而是训练、评测、反馈和迭代出来的。一个装表接电识别模型，如果没有持续回流的现场图片、缺陷标签、人工复核结果和误判漏判案例，就不可能长期保持效果。一个负荷预测模型，如果没有持续更新的气象、节假日、用户类型、异常日、检修停电、需求响应事件等样本，也不可能适应业务变化。一个计量问策知识库，如果只是上传文件，没有专家校验、案例沉淀、规则抽取和召回测试，也不会变成可靠的专业能力。
所以 L3 阶段的研发流程，不再是简单的“需求—设计—开发—测试—上线”，而应变成“业务问题定义—业务本体建模—数据和样本准备—模型与规则设计—能力封装—业务流程嵌入—效果评测—样本回流—持续迭代”。这个流程不是为了追求形式先进，而是 AI 项目的实际规律决定的。
如果没有业务问题定义，AI 会变成泛泛而谈；如果没有本体建模，AI 不理解对象关系；如果没有样本体系，模型无法训练和评测；如果没有规则约束，模型输出不可控；如果没有能力封装，智能体不能真正行动；如果没有业务流程嵌入，AI 只能停留在演示；如果没有效果评测和样本回流，能力就不能持续进化。
这才是 AI 原生研发的完整逻辑。
四、电力行业为什么不能停留在 L1 和 L2
有人可能会说，L1 已经能提效，L2 已经能做项目，为什么还要追求 L3？原因很简单：电力行业的 AI 价值不在浅层工具，而在复杂业务闭环。
电力行业和互联网行业不同。互联网很多场景可以通过推荐、搜索、生成内容快速验证效果，而电力行业的核心业务高度依赖安全、责任、规则和现场闭环。电力系统里的 AI 不能只给一个“可能是这样”的答案，它必须说明依据是什么，关联哪些对象，是否满足规则，是否需要人工复核，执行动作是否有权限，结果能否追溯。
这也是电力 AI 难做的地方，也是壁垒所在。简单问答、报告生成、代码辅助，通用大模型公司都能做；真正能沉淀行业价值的，是把电力业务对象、数据、规则、模型、流程和执行闭环结合起来。
电力研发如果长期停留在 L1，会变成个人效率工具的使用者；停留在 L2，会做出一批 AI 项目和模型能力，但容易形成场景孤岛；只有走向 L3，才有可能把 AI 变成电力研发体系和业务系统的基础能力。
这里面有一个现实判断：未来电力软件企业之间的差距，不会只体现在谁写代码快、谁页面做得好、谁接了几个模型，而会体现在谁更早建立行业级业务本体，谁积累了高质量样本，谁把系统能力封装成 AI 可调用的服务，谁有持续评测和迭代机制，谁能把 AI 真正嵌入业务闭环。
这不是概念竞争，而是工程能力竞争。
五、研发人员和组织能力也要跟着变化
AI 原生研发改变的不只是技术架构，也改变人的能力结构。
过去电力软件研发中，核心角色是业务专家、需求人员、架构师、开发人员、测试人员和项目经理。未来还会增加几类关键角色：样本工程师、知识工程师、模型工程师、AI 产品经理、能力封装工程师、评测工程师。更重要的是，传统角色本身也要升级。
业务专家不能只提需求，要能定义业务对象、判断规则、样本标签和验收指标。需求人员不能只整理会议纪要，要能把业务问题结构化为对象、关系、输入、输出、边界和闭环。开发人员不能只写页面和接口，要理解模型服务、能力封装、数据链路和智能体调用。算法人员不能只追求指标，要理解业务场景、样本偏差、现场约束和工程部署。项目经理不能只催进度，要能管理样本、模型、规则、评测、现场验证和持续迭代。
这也是我一直强调“高密度认知型团队”的原因。AI 原生研发不是人越多越好，而是要有一批能够同时理解业务、数据、模型和工程的人。这样的人不一定每个方面都做到最深，但必须能把几个专业之间的断点打通。电力 AI 项目最怕的是业务、数据、算法、开发各说各话。业务说“这个不准”，算法说“样本不够”，数据说“字段没有”，开发说“接口没法接”，最后项目变成演示系统。高密度认知型团队的价值，就是减少这些断层。
未来真正有价值的电力 AI 工程师，不是只会调模型的人，也不是只会写代码的人，而是能把一个复杂业务问题拆成业务对象、样本体系、模型任务、系统能力和闭环流程的人。这样的人，才是 AI 原生研发时代的核心人才。
六、结语：AI 原生不是口号，是研发责任边界的重划
从 L1 到 L3，看起来是在谈 AI 技术成熟度，本质上是在谈电力研发责任边界的变化。
L1 阶段，AI 帮人提高效率，责任仍然在人和传统流程上。L2 阶段，AI 成为项目能力的一部分，研发团队开始对样本、模型和能力效果负责。L3 阶段，AI 成为业务系统的原生组成，研发团队不仅要对功能负责，还要对业务对象、证据链、模型效果、行动闭环和持续进化负责。
这对电力行业是一次很大的变化。过去我们习惯于建设系统，系统上线就是项目完成；未来我们要建设能力，能力上线只是运营开始。过去我们重视代码资产，未来还要重视样本资产、知识资产、规则资产、评测资产和模型资产。过去系统主要服务人，未来系统既服务人，也服务 AI；过去流程由人推动，未来部分流程会由智能体在规则和权限约束下推动。
电力 AI 的真正价值，不在于某个大模型回答得多流畅，也不在于某个页面看起来多智能，而在于它能不能把电力业务中的判断、经验、数据和行动沉淀成可复用、可追溯、可进化的能力。
从 AI 工具到 AI 原生，不是换一批工具，也不是多建几个平台，而是研发范式从“功能交付”走向“能力运营”。谁能率先完成这个转变，谁就能在下一阶段电力数字化和智能化竞争中占据主动。
对电力研发来说，未来十年的核心问题不再是“AI 能不能帮我们写代码”，而是“我们能不能按照 AI 的方式重新组织研发”。这个问题，比任何单点模型、单个应用、单次演示都重要。
