这些数字来自某风电企业和某光伏组件制造商的真实运营记录。产线数字化的覆盖率这几年上来了，风机装了传感器，光伏电站上了监控平台，储能项目建了BMS系统。设备联网率达标了，数据采集的硬件基础铺下去了，但管理侧还在用Excel和纸质审批单。
（1）政策窗口已经打开
新能源行业的数字化进程正在被政策推着往前走。2023年，国家能源局发布《关于加快推进能源数字化智能化发展的若干意见》，明确提出到2030年能源系统各环节数字化智能化创新应用体系初步构筑，能源系统运行与管理模式向全面标准化、深度数字化和高度智能化加速转变。2025年9月，国家发展改革委、国家能源局印发《关于推进"人工智能+"能源高质量发展的实施意见》，提出到2027年推动五个以上专业大模型在电网、发电、煤炭、油气等行业深度应用，挖掘十个以上可复制、易推广的重点示范项目，探索百个典型应用场景赋能路径。
2026年的政策密度更高。1月，工信部等八部门联合发布《"人工智能+制造"专项行动实施意见》，明确要求开发光伏、锂电池行业碳管理大模型，融合工业互联网标识解析与能耗预测算法，动态优化设备参数与能源调度。4月，国家发改委等四部门联合印发《关于促进人工智能与能源双向赋能的行动方案》，部署了29项重点任务，提出力争到2030年能源领域人工智能应用水平大幅提升。5月，国家能源局发布首批51个"人工智能+“能源高价值场景清单，涵盖新能源智能运营决策、新能源大基地智能化运维等领域。
政策的密集说明了一个事实：新能源行业的数字化转型已经从"要不要做"进入"怎么做"的阶段。政策文件里反复出现的"场景化”“可复制”"典型应用"这些关键词，指向的正是那些在行业中广泛存在、但长期缺乏系统化解决方案的管理场景。
（2）管理侧的数字鸿沟
每家新能源企业的IT部门都有个排期表，上面列着业务部门提出的各种需求：行政部要一个办公终端管理系统，要一个客诉处理系统，质量部要一个追溯台账，设备部要一个维修记录库。每个需求单独看不复杂，但排期表永远排不满——前面的需求还没做完，后面的需求又堆上来了。
办公终端管理和客诉管理这两个场景在技术层面没有任何难点。数据模型清晰，业务流程明确，权限体系标准。但每个需求的开发都需要完整走一遍工程流程，而新能源企业的IT团队规模有限，外包开发又面临需求沟通成本和交付质量不可控的问题。
这就引出了一个值得讨论的问题：有没有一种方式，让这些管理类场景不再依赖排期，让业务部门能够自己描述需求、快速获得可用的系统？

（3）开发模式的演进路径
先理解一下低代码开发本身是怎么走到今天这一步的。
一代低代码的核心是可视化拖拽。通过组件排列和属性配置来构建页面，把写代码变成拖组件。效率有提升，但门槛仍然存在——用户需要熟悉平台特定的组件库、配置规则、事件绑定方式，遇到复杂逻辑还是要写扩展代码。本质上是一种"手动挡"的效率工具。
二代低代码向SaaS化方向发展，通过预置行业模板和表单组件让用户快速搭建部门级应用。优点是开箱即用，缺点是灵活性有限，模板覆盖不了的场景就束手无策。
三代是AI原生低代码。交互方式从"操作工具"变成了"描述目标"。用户不需要知道用什么组件、配什么属性，只需要用自然语言说清楚想要什么。平台负责理解、拆解和实现。
值得注意的是，政策层面已经关注到这种技术趋势。国家能源局等四部门在《关于促进人工智能与能源双向赋能的行动方案》中明确提出，要培育垂直领域低代码平台、智能体开发平台，以模块化人工智能组件实现行业知识快速封装、自动化任务设计与执行，推动开发从"人工主导"向"智能协同"转变。这一政策表述与AI低代码平台的技术路线形成了直接的呼应。
在这一代的技术路线中，米缀采用了大模型加小模型的协同架构。大模型负责理解自然语言需求、拆解任务、设计方案，小模型负责具体的代码生成、组件匹配、流程配置。两者接力完成从需求到代码的全流程。平台内置的开发知识库基于20年以上企业级开发经验构建，覆盖了多行业的标准数据模型和业务流程模板，AI生成的应用是在行业实践基础上的定制化生成。

（4）办公终端管理：从Excel到全生命周期追踪
回到那张表格里的场景。
某风电企业，全国十多个风电场加上总部和区域办公室，电脑、打印机、移动设备加起来超过两千台。管理方式是Excel加纸质审批单。设备采购进来登记一条记录，之后发生领用、调拨、维修、报废，全靠人工在Excel里手动更新。很多情况下根本来不及更新或者干脆忘了更新。
资产盘点的时候问题集中暴露。账实不符是常态，财务部门每年花大量时间去核对：这台设备在不在、在谁手里、在哪个场站、状态是什么。有时候找到了一台几年前就已经报废但台账里还挂着"在用"标签的设备，得翻查好几年的纸质单据才能核销。
IT部门用平台做了个尝试。没有写需求文档，没有做原型设计，也没有排期。一位IT同事用自然语言输入了这样一段描述：
“我们需要一个办公终端管理系统，管理电脑、打印机、移动设备等终端资产。每台设备需要记录品牌、型号、序列号、采购日期、价格、使用部门、使用人、当前位置。支持设备申请、采购入库、领用登记、调拨审批、维修记录、报废回收全流程。普通员工查看名下设备和提交申请，部门负责人审批本部门申请，IT管理员管理所有设备，财务人员查看资产台账。”
这段描述没有任何格式要求，也不需要技术术语，就是平时沟通业务需求时的口吻。
AI解析后生成了一份结构化的任务清单，列出了数据实体、功能模块、流程节点和角色权限。业务部门确认后，AI开始自动构建——数据库表结构、前后端页面、审批流程、权限体系，全部在数十分钟内生成。
生成的系统同时包含PC端管理界面和移动端审批入口。员工通过企业微信提交设备申请，部门负责人在手机上审批，IT管理员在后台执行分配和状态变更。
上线之后他们又提了几处调整：“在设备列表页面增加按使用部门筛选”“设备详情页显示完整维修历史”“报废审批通过后自动通知财务”。每条都是自然语言描述，AI几分钟内完成修改。
系统运行半年后的数据：设备账实相符率从不足70%上升到98%以上，资产盘点周期从两周压缩到两天，设备从申请到交付的平均时间从五个工作日缩短到一天以内。所有设备变动都有记录可查，财务审计不再需要翻纸质单据。

（5）客诉管理：数据价值的释放
另一个场景来自一家光伏组件制造商。
这家企业的客诉来源很杂：电站投资方质疑组件功率，安装商投诉物流破损，运维方反映售后响应慢。用邮件接收投诉，用Excel记录进度，用邮件分派任务给技术、质量、生产等部门。处理人员在邮件里回复结果，再跟进回访。
整个流程的信息损耗严重。邮件丢失或者被漏看，某个工单的状态就断了。Excel记录的信息和邮件讨论的内容经常不一致。同类问题的客诉分散在不同Excel文件里，没办法做系统性分析。客诉数据原本可以成为质量改进的输入，但实际上大部分数据在被录入Excel之后就再也没有被打开过。
同样是自然语言描述需求：“我们需要一个客诉管理系统，客户通过表单提交投诉，录入后自动生成工单。工单按投诉类型分派给对应部门，每个节点有处理时限，超时自动提醒。处理完成后回访客户，记录满意度。所有客诉数据自动形成台账，支持按产品型号、投诉类型、处理时长等维度统计分析。海外客户较多，界面需要支持中英文切换。”
AI生成的数据模型覆盖了投诉编号、客户信息、产品信息、投诉类型、处理部门、处理状态、处理结果、满意度等字段。分派规则按投诉类型映射到质量、技术、物流、售后等不同部门。时效监控设置了各节点的处理时限。统计分析维度包括产品型号、投诉类型、处理时长、满意度趋势。
系统上线后，客户通过企业微信公众号提交投诉，系统自动生成工单推送对应部门。处理人员在工单中更新进度、上传报告，所有操作留痕。处理完成后工单返回回访，满意度记录同步归档。
两个月的数据变化：客诉平均处理时长从7.5天缩短到3.2天，超期工单占比从35%下降到8%。更重要的是数据质量的变化——所有客诉数据以结构化形式沉淀下来，质量部门可以基于历史数据识别特定型号的共性问题，部门不再需要手工汇总报表。

（6）这种开发方式的底层逻辑
前面用两个例子说明了AI低代码在新能源管理场景中的具体操作路径和效果。现在回到技术层面，拆解一下支撑这套流程的底层机制。
传统开发中，需求描述到代码实现之间的转化是整个流程中信息损耗严重的环节。业务方用自然语言描述需求，产品经理将其转化为PRD，开发人员再根据PRD编写代码。每一次转化都在丢失信息。
平台处理这个问题的路径不同。平台内置的开发知识库包含了一套预训练过的行业数据模型，覆盖了20多个行业的标准数据结构和业务流程模板。当AI解析用户描述时，不是从零开始理解每个词的含义，而是将用户描述与知识库中的行业模型进行匹配和对齐。
以办公终端管理为例。用户描述了"记录每台设备的品牌、型号、序列号、采购日期、价格、使用部门、使用人、当前位置"，AI在知识库中匹配到了对应的"资产档案"数据模型，自动补全了资产状态、供应商信息、维保记录等关联字段。用户没有明确提到的字段，AI根据行业标准模型进行合理推断和补充，并在任务清单中呈现供用户确认。
这种处理方式的核心差异在于：传统开发模式下，业务方需要穷举所有字段和规则，遗漏任何一个细节都可能导致系统缺陷；AI模式下，业务方只需要描述核心的业务实体和流程，AI根据知识库中的行业实践进行补全。
用户确认任务清单的过程是一个关键的反馈闭环。AI生成的方案如果与业务预期有偏差，在代码生成前就可以纠正，避免了传统开发模式下"代码写完了才发现理解有误"的高成本返工。

（7）大模型与小模型的协同分工
采用大模型加小模型的协同架构。这种分工的设计考量在于不同性质的任务对模型能力的要求不同。
大模型处理的任务类型是认知和推理层面的。用户一段自然语言描述可能包含数百个信息点，大模型需要理解上下文、识别隐含假设、推断关联关系，输出一个结构化的方案设计。这类任务需要模型具备广泛的常识知识和推理能力，对大模型的参数量和训练数据规模有要求，调用成本和响应时间也更高。但这类任务在整个开发流程中出现的频率相对较低——一个项目只需做一次需求解析和方案设计，因此大模型被低频调用是合理的。
小模型处理的任务类型是生成和执行层面的。方案确定后，需要生成的代码量可能是数万行，涉及页面渲染、数据模型构建、流程配置、接口生成等具体操作。每个操作都需要快速响应和高精度输出。小模型针对这些具体任务进行了专门训练和优化，在响应速度和输出稳定性上满足要求，调用成本也显著低于大模型。
这种协同机制的价值在于：大模型负责"想清楚"，小模型负责"做到位"。两者之间通过标准化的中间产物进行衔接，形成了一条从需求到代码的自动化工程流水线。
（8）四个核心模块在场景中的实际作用
平台架构由四个核心模块构成，在办公终端管理和客诉管理这两个场景中，每个模块承担了明确的责任。
低代码开发模块处理的是应用界面的生成和多端适配。用户在描述中提到的设备列表页、申请表单页、审批看板、统计报表等，全部由这个模块自动生成。一次建模之后，系统自动适配PC端后台管理界面和移动端审批入口。模块内置的组件库包含了表单、列表、图表、看板等企业级应用所需的全部组件类型，AI根据用户描述的业务场景选择合适的组件组合进行渲染。
流程引擎模块处理的是业务流转。办公终端管理中的申请-审批-执行链条、客诉管理中的录入-分派-处理-回访链条，全部由流程引擎驱动。引擎基于BPMN 2.0标准设计，支持顺序流、并行网关、排他网关、包容网关等核心流程元素。流程引擎同时承担了数据流的编排工作——客诉台账的自动汇总、多维度统计分析的实时计算，由流程引擎中的数据流模块完成。
集成平台模块处理的是系统对接。新能源企业通常已经部署了ERP、OA、财务系统、企业微信等基础设施。办公终端管理应用需要与企业微信打通以实现移动端审批，客诉管理应用需要与微信公众号对接以实现客户自助提交投诉。集成平台通过预置的连接器实现了这些对接，AI在生成应用时识别出"企业微信"“公众号"等关键词后，自动调用了对应的连接器配置。
数据工厂模块处理的是数据资产化。客诉管理系统生成的结构化客诉数据，在数据工厂中被加工为可视化的分析报表——按投诉类型分布的饼图、按处理时长的趋势线、按产品型号的对比柱状图。数据工厂同时支撑了客诉台账自动归档的能力，所有客诉数据不需要人工整理即可形成可查询、可统计的数字化台账资产。
（9）ID化脱敏与数据安全
新能源企业在使用大模型时有一个无法回避的顾虑：业务数据可能包含商业机密、客户信息、设备参数等敏感内容。
ID化脱敏机制处理这个问题的方式是：在与大模型交互之前，系统对用户描述中包含的敏感字段进行自动识别和替换。姓名替换为ID_U001，手机号替换为ID_P001，具体设备序列号替换为ID_E001。大模型接收到的输入是经过脱敏的版本，其中不包含任何真实的企业数据。大模型返回结果后，系统再将ID还原为真实数据，用于应用构建。
这个设计的关键在于：大模型本身不需要知道具体的设备型号或客户姓名，它只需要理解"这里有一个设备实体”"这里有一个客户实体"即可完成需求解析和方案设计。敏感数据不出企业环境，大模型处理的是去标识化后的元数据信息，两者在物理层面实现了隔离。
这种处理方式同时满足了等保三级和GDPR的合规要求，对于需要过等保或处理跨境业务的新能源企业来说，这是一个不具备可商量空间的前提条件。
（10）效率提升的量化维度
从工程效率的角度，AI低代码在新能源管理场景中带来的变化可以从三个维度量化衡量。
交付周期压缩。办公终端管理系统从需求描述输入到可运行应用生成，AI的自动构建阶段用时数十分钟。从需求输入到应用上线，实际总用时约1到2周，主要时间消耗在业务部门的方案确认和上线前的用户测试环节。传统外包开发模式下，一个同等复杂度的管理类系统从需求调研到正式上线，通常需要4到8周。
交付周期压缩带来的间接效果是：排期表的压力显著降低。IT部门不再需要在多个需求之间做复杂的优先级博弈，业务部门提出需求后可以快速获得可用原型并进行验证，需求后续的迭代也通过AI微调完成，不需要重新进入排期队列。
人力结构变化。传统开发模式下，一个管理类系统需要产品经理对接需求、前端工程师开发界面、后端工程师编写API、数据库工程师设计表结构、测试工程师编写用例。即便是中等复杂度的系统，至少需要3到4名不同角色的开发人员投入数周时间。AI模式下，IT部门的一名成员负责需求描述输入和方案确认，AI承担了数据建模、页面生成、流程配置、接口生成等原本需要多个角色分工完成的工作。
迭代响应速度。系统上线后的需求变更是开发中频繁也容易被低估成本的工作。传统模式下，一次需求变更需要经历需求分析、代码修改、联调、测试、部署的完整流程，响应时间以天或周为单位。AI模式下，用户用自然语言描述变更内容，AI识别需要修改的代码位置并完成调整，响应时间以分钟为单位。
（11）适用边界与技术限制
这个技术方案的能力边界和限制需要明确。
适用的场景类型。业务流程相对标准化、数据模型清晰、逻辑复杂度适中的管理类应用，是AI低代码目前处理效果的场景类型。办公终端管理、客诉管理、设备台账、巡检记录、安全生产管理、培训记录、合同管理都属于这个范围。这类场景的数据实体在10到30个之间，流程节点在3到8个之间，需要支持3到6种角色权限，统计查询维度在5到15个之间。
不适用的场景类型。算法密集型应用、实时控制系统、需要大规模分布式架构支撑的业务场景，不在AI低代码的能力范围内。风电场SCADA系统需要毫秒级的数据采集和响应，光伏电站功率预测涉及复杂的物理模型和算法，储能BMS的核心控制模块对可靠性和实时性有严格要求，这些场景需要专门的工程团队进行深度定制开发。同样，需要进行大规模并行计算、实时流数据处理、复杂优化求解的应用，也不在AI低代码的适用范围内。
平台的技术约束。平台支持信创生态适配，兼容国产操作系统和数据库，但具体的适配工作需要在使用前完成验证。多端适配的能力覆盖了PC、移动H5、企业微信小程序，但原生APP层面目前支持有限。
（12）回到表格
开篇那张表格里列出的三个场景，在传统的开发模式下长期处于排期表的末端。不是因为它们不重要，而是因为它们的复杂度不足以支撑一个独立的开发项目立项，但在投入产出比上又不足以让企业专门组建开发团队。
AI低代码提供的是另一种成本结构。一个管理类应用的构建不再需要立项、排期、组建团队、走完整开发流程，而是由业务人员描述需求、AI生成应用、测试验证后即可上线。这种成本结构的变化，使得原本"不值得开发"的管理场景变得值得被系统化解决。
政策层面，《关于促进人工智能与能源双向赋能的行动方案》明确提出培育垂直领域低代码平台的方向；《关于推进"人工智能+"能源高质量发展的实施意见》要求探索百个典型应用场景赋能路径；国家能源局发布的51个高价值场景清单则直接为AI技术在新能源领域的落地划定了具体方向。政策、技术与场景需求正在形成合力。
账实相符率从70%到98%，盘点周期从两周到两天，客诉处理从7.5天到3.2天，超期率从35%到8%。这些改善的起点都是同一个动作：有人用自然语言描述了一个需求，AI把它变成了一个可以运行的系统。
新能源企业的管理侧数字化进程，也许可以从这个动作开始。