Code generation method, power line loss anomaly diagnosis method, electronic device, storage medium, and program product

Abstract

The embodiment of the application provides a code generation method, a power line loss anomaly diagnosis method, an electronic device, a storage medium and a program product. In the embodiment of the application, code generation requirement information including power data file input requirements, line loss anomaly diagnosis rule text and diagnosis result output requirements is input into a code generation agent, and initial line loss anomaly diagnosis code is automatically generated; then, in combination with a unit test case, a code error correction agent performs unit testing and automatic error correction on the line loss anomaly diagnosis code, and finally, high-reliability line loss anomaly diagnosis code is generated. Therefore, the code generation agent and the code error correction agent cooperate with each other, end-to-end automatic construction from natural language rules to executable line loss anomaly diagnosis code is realized, and safe, efficient and landable technical support is provided for power system line loss intelligent analysis.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a code generation method, a power line loss anomaly diagnosis method, electronic equipment, storage medium and program product. Background Technology

[0002] Line loss is an unavoidable energy loss during power transmission, directly affecting the economic benefits of power supply companies and the operational efficiency of the power grid. Currently, line loss monitoring systems can calculate the input and output power of each line and transformer substation in real time during power transmission, perform line loss accounting based on the difference between the input and output power, and issue timely alerts when abnormal line loss is detected.

[0003] However, if a specific analysis is needed to determine the exact cause of abnormal line loss in a line or transformer area, it mainly requires professionals to rely on their personal experience to diagnose the anomaly, which is inefficient and inaccurate. Summary of the Invention

[0004] This application provides a code generation method, a power line loss anomaly diagnosis method, an electronic device, a storage medium, and a program product, which provide a way to generate power line loss anomaly diagnosis code based on power line loss anomaly diagnosis rule text, and then use the power line loss anomaly diagnosis code to achieve automated and efficient power line loss anomaly diagnosis.

[0005] This application provides a code generation method, including: inputting code generation requirement information into a code generation agent to trigger the agent to generate line loss anomaly diagnosis code; the code generation requirement information includes power data file input requirements, line loss anomaly diagnosis rule text, and diagnosis result output requirements; inputting the line loss anomaly diagnosis code and unit test cases into a code correction agent to trigger the agent to perform unit testing on the line loss anomaly diagnosis code using the unit test cases, obtaining unit test results, and correcting the line loss anomaly diagnosis code if the unit test results fail, thereby obtaining a target line loss anomaly diagnosis code, which is used to diagnose line loss anomalies in the power object to be diagnosed.

[0006] This application also provides a method for diagnosing abnormal power line losses, including: obtaining the filename of the power data file of the power object to be diagnosed; calling the power line loss anomaly diagnosis intelligent agent to input the filename as an actual parameter into the target line loss anomaly diagnosis code, and running the target line loss anomaly diagnosis code after the actual parameter input, so as to perform line loss anomaly diagnosis on the power object to be diagnosed, and obtain the line loss anomaly diagnosis result of the power object to be diagnosed.

[0007] This application also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; the processor coupled to the memory for executing the computer program to perform steps in a code generation method or a power line loss anomaly diagnosis method.

[0008] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in a code generation method or a power line loss anomaly diagnosis method.

[0009] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to implement the steps in a code generation method or a power line loss anomaly diagnosis method.

[0010] In this embodiment, by inputting code generation requirements, including power data file input requirements, line loss anomaly diagnosis rule text, and diagnosis result output requirements, into the code generation agent, initial line loss anomaly diagnosis code is automatically generated. Then, combined with unit test cases, the code correction agent performs unit testing and automatic error correction on the line loss anomaly diagnosis code, ultimately generating highly reliable line loss anomaly diagnosis code. Thus, the code generation agent and the code correction agent collaborate to achieve end-to-end automated construction from natural language rules to executable line loss anomaly diagnosis code, providing secure, efficient, and practical technical support for intelligent line loss analysis in power systems. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0012] Figure 1 An exemplary application scenario diagram provided for an embodiment of this application;

[0013] Figure 2 A flowchart illustrating an exemplary code generation method provided in this application embodiment;

[0014] Figure 3 This application provides a schematic diagram illustrating the process of generating code for collaborative execution by intelligent agents.

[0015] Figure 4 A flowchart illustrating an exemplary method for diagnosing abnormal power line losses, provided in an embodiment of this application;

[0016] Figure 5 This is a schematic diagram of the structure of an exemplary electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] First, some terms used in the embodiments of this application will be introduced:

[0019] AI Agent: A software or hardware entity that has the ability to autonomously perceive its environment, make decisions, and execute actions, with the aim of completing specific tasks or achieving goals in a simulated or real world.

[0020] A language model (LM) is a model that learns general language structures and knowledge through unsupervised or self-supervised pre-training on large-scale text data. Language model architectures include, but are not limited to: bidirectional encoder representation from transformers (BERT), autoregressive language models, and generative pre-trained transformers (GPT). The Transformer module is a neural network structure based on a self-attention mechanism, which significantly improves model performance through parallel processing and self-attention.

[0021] Large Language Models (LLMs), also known as large-scale language models, refer to a class of natural language processing models with an extremely large number of parameters. LLMs are typically based on deep learning architectures, especially the Transformer architecture, which learns the complex structure of language and rich contextual information through pre-training on massive amounts of text data. The Transformer architecture addresses the bottleneck problem of traditional neural network models when processing long sequences by introducing a self-attention mechanism, and its highly parallelizable nature greatly improves training efficiency. The Transformer architecture includes either an encoder or a decoder.

[0022] Power lines refer to the conductor systems and their ancillary facilities (such as poles, insulators, fittings, cable trenches, and protective devices) used to transmit and distribute electrical energy. They are physical channels connecting power generation, transmission, transformation, distribution, and consumption, forming an important component of the power system. In line loss diagnosis scenarios, power lines mainly refer to medium-voltage distribution lines (such as 10kV feeders). Power lines typically include multiple transformer substations, which are the smallest unit for line loss assessment and user management.

[0023] The technical solution of this application and how it solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0024] Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application. See also... Figure 1 As shown in section 1.1, during the code generation phase, when it is necessary to convert the line loss anomaly diagnosis rule text into a line loss anomaly diagnosis program, the developer can trigger the terminal device 10 to send code generation requirement information to the server 30; see also Figure 1 As shown in section 1.2, server 30 calls the code generation agent to perform code generation operations, obtaining the line loss anomaly diagnosis program; see also Figure 1 As shown in 1.3, server 30 calls the code correction agent to perform unit testing and code correction operations to obtain the final line loss anomaly diagnosis program, thus completing the task of generating the line loss anomaly diagnosis program.

[0025] See Figure 1 As shown in section 1.4, during the line loss anomaly diagnosis phase, power maintenance personnel can trigger terminal device 20 to send relevant information about the power object to be diagnosed (such as a power line or a transformer substation) to server 30. See also... Figure 1 As shown in 1.5 and 1.6, the server 30 uses the power line loss anomaly diagnosis agent to run the line loss anomaly diagnosis program to perform line loss anomaly diagnosis, obtain the line loss anomaly diagnosis results, and return the line loss anomaly diagnosis results to the terminal device 20 for power maintenance personnel to view, thus completing the line loss anomaly diagnosis task.

[0026] In practical applications, terminal device 10 or terminal device 20 can be any terminal device capable of initiating requests and interacting with the server. Terminal devices include, but are not limited to, desktop computers, personal computers, smartphones, tablets, in-vehicle devices, or Internet of Things (IoT) devices. Of course, terminal devices can also be applications installed on terminal devices, and there are no restrictions on this.

[0027] In practical applications, server 30 includes, but is not limited to: a single server, a distributed server cluster consisting of multiple servers, a cloud server, a virtual server, a containerized server, or an edge server.

[0028] It should be noted that, Figure 1 The application scenario shown is only an example; in actual applications, there are no restrictions on specific application scenarios.

[0029] Figure 2 A flowchart illustrating an exemplary code generation method provided in this application embodiment. See also... Figure 2 The method may include the following steps:

[0030] 201. Input the code generation requirement information into the code generation agent to trigger the code generation agent to generate line loss anomaly diagnosis code.

[0031] Specifically, the code generation agent is an agent with NL2Code (Natural Language to Code) functionality, which can understand programming requirements expressed in natural language and automatically generate executable program code.

[0032] In this embodiment, it is necessary to obtain the relevant information required for code generation (which can be referred to as code generation requirement information). The relevant information required for code generation includes, but is not limited to, the following: power data file input requirements information, line loss anomaly diagnosis rule text, and diagnosis result output requirements information.

[0033] The power data file input requirements information describes the requirements for the power data file used as input data for line loss anomaly diagnostic codes. This typically includes the storage directory path of the power data file, table structure parsing requirements, etc. Examples of power data files include, but are not limited to: "Monthly Line Loss Data for Distribution Area.xlsx", "User Input / Output Power Consumption Details for Distribution Area.xlsx", and "Meter Replacement Event List for Distribution Area.xlsx".

[0034] For example, the input requirements for manually written power data files are as follows: "The storage directory path of the power data file is / workspace / input / , where the fields to be parsed in 'Monthly Line Loss Data for Distribution Areas.xlsx' include: Distribution Area Number (string type, unique identifier of the distribution area); Month (date type, format YYYY-MM); Power Supply (kWh) (numerical type, unit: kilowatt-hour); Electricity Sales (kWh) (numerical type, unit: kilowatt-hour); Line Loss Rate (%)."

[0035] The table file "User Input / Output Electricity Consumption Details.xlsx" requires parsing the following fields: Substation ID (string type); User ID (string type); Username (string type); Month (date type, format YYYY-MM); Input Electricity (kWh) (numerical type, usually 0, only users at power supply points have non-zero values); Output Electricity (kWh) (numerical type, representing the user's actual electricity consumption); Comprehensive Multiplier (numerical type, default value is 1.0, used for electricity conversion).

[0036] The "Meter Replacement Event List.xlsx" spreadsheet file requires parsing the following fields: User ID (string): The unique user code of the electricity meter to which the replacement operation occurred; Old electricity meter asset number (string): The asset number of the electricity meter before replacement; New electricity meter asset number (string): The asset number of the newly installed electricity meter after replacement; Replacement date (date type, format YYYY-MM-DD): The actual date the electricity meter was replaced; Reason for replacement (string): Such as "fault", "periodic rotation", "electricity theft investigation", "meter burnout", etc.; Overall ratio (before replacement) (numerical type): The overall ratio of the current / voltage transformer corresponding to the old meter; Overall ratio (after replacement) (numerical type): The overall ratio corresponding to the new meter.

[0037] Line loss anomaly diagnosis rule text is a rule description information written in natural language by professionals in the power field to guide the diagnosis of line loss anomalies in power objects such as power lines or transformer substations. Line loss anomaly diagnosis rule text includes, but is not limited to: line loss anomaly diagnosis rule text related to full-code power calculation errors, line loss anomaly diagnosis rule text related to transformer replacement events, line loss anomaly diagnosis rule text related to metering device failures, etc.

[0038] For example, the diagnostic rule text for line loss anomalies related to full-code power calculation errors is: "If a user has a full-code event, and the user's input power after verification is not equal to the difference between the original input power and the correction value, then the user's full-code power calculation is determined to be incorrect, which may lead to abnormal line loss rates in the distribution area. The user's power data needs to be recalculated, and its impact on line loss calculation needs to be eliminated."

[0039] For example, the diagnostic rule text for line loss anomalies related to full-code power consumption calculation errors is: "If a user experiences a transformer replacement event within the statistical period, but the system does not update the multiplier parameter synchronously, resulting in a significant deviation between the calculated power consumption and the actual power consumption, it is determined that the transformer multiplier has not been updated in a timely manner, which may cause abnormal line loss in the distribution area. The metering record change record should be checked, the multiplier should be corrected, and the power consumption should be recalculated."

[0040] For example, the text of the line loss anomaly diagnosis rule related to metering device failure is: "If the user's electricity meter freezes zero or remains constant for several consecutive days, and there is no record of power outage events, it is determined that the metering device may have stopped, crashed, or had a wiring fault, resulting in missed electricity charges, which in turn causes negative or high losses in the distribution area. On-site verification or replacement of the meter should be arranged, and the missing electricity charges should be recorded."

[0041] The diagnostic result output requirement information is the requirement information for the output results of the constraint line loss anomaly diagnostic code described in natural language. The diagnostic result output requirement information includes, but is not limited to, text-based and tabular-based diagnostic result output requirement information.

[0042] The requirement for outputting diagnostic results in text format aims to ensure that the diagnostic information is clearly structured, complete, and stored in a standardized manner, facilitating subsequent analysis, archiving, or automated processing. The information required for outputting diagnostic results in text format typically includes, but is not limited to: the storage directory path of the text file storing the diagnostic results, the file name of the text file, and the information items that the text file must include. These information items may include, but are not limited to: a problem description (e.g., "User's full power calculation is incorrect"), the power-related objects (e.g., location number "02×06"), diagnostic conclusions (e.g., "Please investigate other causes" or specific error types), and processing suggestions, etc.

[0043] The tabular format diagnostic result output requirements aim to achieve standardized storage and efficient utilization of diagnostic results through standardized file paths, naming rules, and field structures. The information required for tabular format diagnostic result output typically includes, but is not limited to: the storage directory path of the table file containing the diagnostic results, the table file name, and the fields (columns) that the table file must include. For example, the tabular format diagnostic result output requirements are as follows: the storage directory path of the table file is / workspace / output; the specific fields required for "List of Abnormal Users in Transit Area.xlsx" and "Results After Correction of Transit Area Line Loss Rate.xlsx".

[0044] In practical applications, appropriate prompts can be designed to trigger the code generation agent to perform code generation operations based on the input requirements of the power data file, the text of the line loss anomaly diagnosis rules, and the output requirements of the diagnosis results. This results in line loss anomaly diagnosis codes, which are program codes capable of diagnosing anomalies in various power objects such as power lines or transformer substations.

[0045] In some optional embodiments, the trigger code generation agent generates line loss anomaly diagnostic code by: the trigger code generation agent performing the following operations: parsing the power data file input requirement information to obtain the task information of the data input task, which instructs the reading of the power data file of the power object to be diagnosed from the power data folder; parsing the line loss anomaly diagnostic rule text to obtain the task information of multiple operation step tasks in the line loss anomaly diagnostic task, which instructs the line loss anomaly diagnosis based on the power data file of the power object to be diagnosed, and obtaining the line loss anomaly diagnostic result of the power object to be diagnosed; parsing the diagnostic result output requirement information to obtain the task information of the data output task, which instructs the output of the line loss anomaly diagnostic result of the power object to be diagnosed to the diagnostic result folder; and generating line loss anomaly diagnostic code according to the task information of the data input task, the multiple operation step tasks, and the data output task, wherein the line loss anomaly diagnostic code includes the code block corresponding to the data input task, the code block corresponding to the multiple operation step tasks, and the code block corresponding to the data output task.

[0046] Specifically, the input requirement information of the power data file is parsed to extract the task information for the data input task. This task information includes, but is not limited to: the storage directory path of the folder containing the power data file (i.e., the power data folder), placeholder variables corresponding to the filenames of the power data files, and a list of fields that must be included in the power data files. This task information guides the code generation agent in generating the input code for line loss anomaly diagnosis; the input code is the code block corresponding to the data input task.

[0047] The placeholder variable corresponding to the filename of the power data file can be regarded as a formal parameter in the code block. When the line loss anomaly diagnosis code runs, the placeholder variable will be filled with the actual parameter. This design makes the input code universal and flexible, supporting data loading from any power line or transformer area, providing a stable and consistent data entry point for subsequent line loss anomaly diagnosis, and adapting to the diagnosis tasks of different power objects without having to write separate reading logic for each power object, significantly improving code reusability and automation.

[0048] For example, ` / workspace / input / ` is the storage directory path corresponding to the power data folder, and the placeholder variable corresponding to the filename of the power data file is `district_id`. In the generated input code, this placeholder variable is used as a shape in the file path construction. For example, the line of code corresponding to the file path in the input code is as follows:

[0049] file_path=f" / workspace / input / user_electricity_{district_id}.xlsx";

[0050] When the line loss anomaly diagnosis code runs, the specific transformer substation number (such as "02X06") is passed in as the actual parameter, thereby dynamically generating a complete file path pointing to the real power data file, for example, file_path=f" / workspace / input / user_electricity_{02X06}.xlsx".

[0051] Specifically, when the code generation agent parses the text of the line loss anomaly diagnosis rules, it first performs intent understanding to accurately identify the diagnostic objectives, judgment conditions, and diagnostic logic expressed in the text. Next, based on the intent understanding results, it performs task planning. The task planning results include, but are not limited to, flowchart information of the line loss anomaly diagnosis process and detailed step information for each operation step within the process. The flowchart information reflects the execution order and jump logic between the various operation steps; the detailed step information describes the specific function, input / output requirements, execution conditions, and dependencies of each operation step. The code generation agent maps each operation step to an independent task, referred to as the operation step task, and uses the corresponding detailed step information as the task information for that operation step task. The task information of multiple operation step tasks guides the code generation agent in generating key data processing code for the line loss anomaly diagnosis code. These multiple operation step tasks are organized according to diagnostic logic to form a complete line loss anomaly diagnosis task. The line loss anomaly diagnosis task is used to instruct the line loss anomaly diagnosis based on the power data file of the power object to be diagnosed, and to obtain the line loss anomaly diagnosis result of the power object to be diagnosed.

[0052] Specifically, after receiving the diagnostic result output requirement information, the code generation agent first performs semantic parsing and structure extraction to obtain the task information for the data output task. This task information guides the code generation agent in generating the output code within the line loss anomaly diagnostic code; the output code is the code block corresponding to the data output task. The task information describes how to output the line loss anomaly diagnostic results for the power object to be diagnosed. This task information includes, but is not limited to, the file type of the diagnostic result file, the storage directory path, file naming rules, and content structure requirements.

[0053] The diagnostic results file is used to record the diagnostic results of line loss anomalies. The file type of the diagnostic results file is, for example, a text file or a spreadsheet file. The storage directory path is the folder path where the diagnostic results file is located, for example, / workspace / output / . The file naming rules define how the diagnostic results file is named. The content structure requirements describe the specific fields that the diagnostic results file should include.

[0054] In this embodiment, by parsing the power data file input requirement information, the line loss anomaly diagnosis rule text, and the diagnosis result output requirement information, the task information of the data input task, multiple operation step tasks, and data output task is extracted respectively, and a clear and modular line loss anomaly diagnosis code is generated accordingly. This improves the development efficiency of the line loss anomaly diagnosis code and realizes end-to-end automated generation from natural language line loss anomaly diagnosis rule text to executable program code.

[0055] In practical applications, the code generation agent can generate corresponding code blocks as needed based on the task information of each task, according to the execution order of data input tasks, multiple operation step tasks, and data output tasks. The code blocks corresponding to the data input tasks, multiple operation step tasks, and data output tasks are organized into line loss anomaly diagnosis code.

[0056] In some optional embodiments, the method for generating line loss anomaly diagnostic code based on the task information of the data input task, multiple operation step tasks, and data output tasks is as follows: Organize the data input task, multiple operation step tasks, and data output tasks sequentially to obtain a task orchestration result; sequentially take one task from the task orchestration result as the current task and repeat the following steps until all tasks in the task orchestration result have been processed: call the code generation tool to generate the code block for the current task based on the task information of the current task, and run the code block for the current task in the sandbox environment to obtain the execution result of the code block for the current task; if the execution result of the code block for the current task is a failure, locate and repair the first abnormal code block that caused the code block for the current task to fail, until the execution result of the code block for the current task is a success; generate line loss anomaly diagnostic code based on the code blocks corresponding to all tasks in the task orchestration result.

[0057] Understandably, for each current task, the following steps are performed: "The code generation tool is called to generate a code block for the current task based on the task information of the current task, and the code block for the current task is run in the sandbox environment to obtain the running result of the code block for the current task; if the running result of the code block for the current task is a failure, the first abnormal code block that caused the code block for the current task to fail is located and repaired until the running result of the code block for the current task is a success."

[0058] Specifically, the code generation agent achieves automated generation of highly reliable and executable line loss anomaly diagnosis code from task information through a closed-loop mechanism of task orchestration, calling code generation tools to generate code blocks, sandbox operation, and automatic repair, thereby improving the functional correctness, operational stability, and development automation level of the line loss anomaly diagnosis code.

[0059] Through task orchestration, the code generation agent can structurally organize data input tasks, multiple operational steps, and data output tasks in the line loss anomaly diagnosis process according to their logical dependencies and execution order, forming a clear, orderly, and executable task sequence (i.e., the task orchestration result). The task orchestration result clarifies the execution order and data flow of each task, ensuring that the output of the preceding task can serve as valid input for the following task, effectively supporting the generation of code blocks task by task.

[0060] The code generation agent invokes a code generation tool to generate code blocks for each task based on the task orchestration results, improving code development efficiency and accuracy. A code generation tool is a tool capable of generating code based on natural language descriptions; one type of code generation tool is, for example, the MCP (Model Context Protocol) tool.

[0061] The sandbox environment provides a secure, isolated, controlled, and safe execution environment. Running the code block of the current task within the sandbox environment allows for precise capture of the code block's execution results. The execution result of the code block of the current task may be successful or fail. Successful execution indicates that the code block completes execution smoothly in the sandbox environment without syntax errors or unhandled exceptions, but this only means that the code block "can run," and it cannot yet confirm whether its code logic is correct. Execution failure indicates that an error occurred during the execution of the code block in the sandbox environment, such as a syntax error, runtime exception, or timeout, meaning that the code block "cannot run." The failure of the code block of the current task may be related to the code block itself or to historical code blocks preceding the current task.

[0062] If the code block of the current task runs successfully, then the code block of the current task is directly used as part of the line loss anomaly diagnosis code. If the code block of the current task runs unsuccessfully, then the first abnormal code block that caused the code block of the current task to fail needs to be located and repaired, and the "repair and run" process is repeated until the code block of the current task runs successfully. The code block of the current task that runs successfully is then used as part of the line loss anomaly diagnosis code.

[0063] In practical applications, relevant personnel can be notified to directly locate and repair the first abnormal code block that caused the code block of the current task to fail to run, or the code generation agent can call the language model to directly locate and repair the first abnormal code block that caused the code block of the current task to fail to run.

[0064] In some optional embodiments, if the execution result of the code block of the current task is a failure, the first abnormal code block that caused the code block of the current task to fail is located and repaired until the execution result of the current task is a success. This includes: if the execution result of the code block of the current task is a failure, locating the first abnormal code block that caused the code block of the current task to fail based on the execution results and error information of the code blocks of the current task and previous historical tasks, and generating a code failure repair suggestion for the first abnormal code block; and calling a first code repair tool in a sandbox environment to repair the first abnormal code block according to the code failure repair suggestion for the first abnormal code block until the execution result of the code block of the current task is a success.

[0065] Specifically, the code generation agent analyzes the execution results of code blocks in the current task and previous historical tasks, as well as error messages from failed code blocks in the sandbox. It automatically identifies the first abnormal code block causing the current task's code block failure and generates targeted code failure repair suggestions. Then, it calls a first code repair tool in the sandbox environment to repair the first abnormal code block, repeating the "repair and run" process until the current task's code block runs successfully. The successfully run code block of the current task is then used as part of the line loss anomaly diagnostic code. This effectively improves the reliability and automated generation quality of the line loss anomaly diagnostic code.

[0066] It is worth noting that if there is only one first abnormal code block, the first abnormal code block is repaired one by one. After each first abnormal code block is repaired, the modified first abnormal code block is run. If the run is successful, the next first abnormal code block is repaired. If the run fails, the code generation agent analyzes the running results of the currently failed first abnormal code block and the code blocks of previous historical tasks, as well as the error messages of the code blocks that failed to run in the sandbox, to locate the new first abnormal code block. The new first abnormal code block is repaired one by one until the code block of the current task runs successfully before the code block generation stage of the next task begins.

[0067] The first code repair tool is a tool that repairs code with the goal of successfully executing code blocks. For example, the tool type of the first code repair tool is the MCP tool.

[0068] 202. Input the line loss anomaly diagnosis code and unit test cases into the code correction agent to trigger the code correction agent to perform unit tests on the line loss anomaly diagnosis code using the unit test cases, obtain the unit test results, and correct the line loss anomaly diagnosis code if the unit test results fail, to obtain the target line loss anomaly diagnosis code. The target line loss anomaly diagnosis code is used to diagnose line loss anomalies in the power object to be diagnosed.

[0069] Specifically, the code correction agent is an agent with unit testing and code correction capabilities. It can design appropriate prompts to trigger the agent to perform unit testing on the line loss anomaly diagnosis code using unit test cases. Based on the unit test results, it decides whether to correct the line loss anomaly diagnosis code. If the unit test passes, the line loss anomaly diagnosis code is directly used as the final target line loss anomaly diagnosis code. If the unit test fails, the line loss anomaly diagnosis code is corrected to obtain the target line loss anomaly diagnosis code, which is then used to diagnose line loss anomalies in the power object to be diagnosed.

[0070] In some optional embodiments, the triggering code correction agent uses unit test cases to perform unit tests on the line loss anomaly diagnosis code to obtain unit test results, including: the triggering code correction agent performs the following steps: obtaining the target file name and expected line loss anomaly diagnosis result corresponding to the target power object from the unit test cases, wherein the target file name is the file name of the power data file of the target power object; inputting the target file name as an actual parameter into the line loss anomaly diagnosis code, running the line loss anomaly diagnosis code after the actual parameter input in the sandbox environment to obtain the actual line loss anomaly diagnosis result of the target power object; determining the unit test result based on the consistency analysis results between the expected line loss anomaly diagnosis result and the actual line loss anomaly diagnosis result of the target power object.

[0071] Specifically, the sandbox environment ensures the safety and repeatability of the unit testing process, effectively supporting the automated testing of line loss anomaly diagnostic code.

[0072] Unit test cases include test data and expected line loss anomaly diagnosis results. The test data includes the target file name corresponding to the target power object. The target file name is the file name of the power data file of the target power object. The target power object is the power object participating in the unit test (such as power lines or transformer substations). The expected line loss anomaly diagnosis results are the standard diagnostic conclusions that the target power object should reach under the given test data, that is, the standard line loss anomaly diagnosis results.

[0073] The target filename is passed as an argument to the line loss anomaly diagnosis code. After running the line loss anomaly diagnosis code with the input argument in the sandbox environment, the power data file of the target power object can be obtained from the power data folder according to the file path corresponding to the target filename. Line loss anomaly diagnosis is then performed on the power data file of the target power object to obtain the actual line loss anomaly diagnosis result of the target power object. A consistency analysis is performed on the expected line loss anomaly diagnosis result and the actual line loss anomaly diagnosis result of the target power object. If the expected line loss anomaly diagnosis result and the actual line loss anomaly diagnosis result of the target power object are consistent, the unit test result is passed; if the expected line loss anomaly diagnosis result and the actual line loss anomaly diagnosis result of the target power object are inconsistent, the unit test result is failed.

[0074] For example, if the semantics of the text in the expected line loss anomaly diagnosis result of the target power object are consistent with the semantics of the text in the actual line loss anomaly diagnosis result, the unit test result is passed; if the semantics of the text in the expected line loss anomaly diagnosis result of the target power object are different (i.e. inconsistent) from the semantics of the text in the actual line loss anomaly diagnosis result, the unit test result is failed.

[0075] For example, if the field information in the expected line loss anomaly diagnosis result table file of the target power object is consistent with the field information in the actual line loss anomaly diagnosis result table file, then the unit test result is determined to be passed; if the field information in the expected line loss anomaly diagnosis result table file of the target power object is different from the field information in the actual line loss anomaly diagnosis result table file, then the unit test result is determined to be failed.

[0076] In some optional embodiments, the unit test result is determined based on the consistency analysis results between the expected line loss anomaly diagnosis result and the actual line loss anomaly diagnosis result of the target power object. This includes: if the semantics of the line loss anomaly diagnosis result text in the expected line loss anomaly diagnosis result of the target power object are consistent with the semantics of the line loss anomaly diagnosis result text in the actual line loss anomaly diagnosis result, and the field information of the line loss anomaly diagnosis result table file in the expected line loss anomaly diagnosis result of the target power object is consistent with the field information of the line loss anomaly diagnosis result table file in the actual line loss anomaly diagnosis result, then the unit test result is determined to be passed; if there is a difference between the semantics of the line loss anomaly diagnosis result text in the expected line loss anomaly diagnosis result of the target power object and the semantics of the line loss anomaly diagnosis result text in the actual line loss anomaly diagnosis result, and / or, there is a difference between the field information of the line loss anomaly diagnosis result table file in the expected line loss anomaly diagnosis result of the target power object and the field information of the line loss anomaly diagnosis result table file in the actual line loss anomaly diagnosis result, then the unit test result is determined to be failed.

[0077] Specifically, the text format records the line loss anomaly diagnosis results, while the table format records them. The table format includes field information such as field names (column names), field values, and the number of fields. Multi-dimensional unit testing is performed based on the semantic comparison of the text and the table structure comparison of the table format to ensure that the generated line loss anomaly diagnosis code meets both the accuracy and standardization requirements of the power industry scenario, thus providing support for reliable line loss anomaly diagnosis.

[0078] In this embodiment, if the code correction agent determines that the unit test result of the line loss anomaly diagnosis code has failed, it indicates that there is a code logic error in the line loss anomaly diagnosis code. With the goal of fixing the code logic error in the line loss anomaly diagnosis code, the code correction agent corrects the line loss anomaly diagnosis code to obtain the target line loss anomaly diagnosis code.

[0079] In some optional embodiments, if the unit test fails, the line loss anomaly diagnosis code is corrected to obtain the target line loss anomaly diagnosis code. This includes: if the unit test fails, locating a second abnormal code block in the line loss anomaly diagnosis code that has a code logic error, and generating a code logic repair suggestion for the second abnormal code block; calling a second code repair tool in a sandbox environment to repair the second abnormal code block according to the code logic repair suggestion to obtain a new code block, thereby completing the error correction of the line loss anomaly diagnosis code and obtaining the target line loss anomaly diagnosis code.

[0080] Specifically, the code correction agent can analyze the execution results of each code block in the line loss anomaly diagnosis code, locate the second abnormal code block with logical errors based on error messages, and automatically generate code logic repair suggestions for the second abnormal code block. In the sandbox environment, the second code repair tool is invoked to repair the code logic of the second abnormal code block. This process not only ensures the safety and verifiability of the repair operation but also achieves a leap from "running successfully" to "running correctly," improving the logical accuracy, execution reliability, and automated generation quality of the line loss anomaly diagnosis code.

[0081] The second code repair tool is a tool designed to repair code to ensure its logical correctness. For example, the tool type of the second code repair tool might be an MCP tool. In some optional embodiments, the second code repair tool is invoked in a sandbox environment to repair the second abnormal code block according to its logic repair suggestions, resulting in a new code block. This process corrects the line loss anomaly diagnostic code and yields the target line loss anomaly diagnostic code. The steps include: invoking the second code repair tool in the sandbox environment to repair the second abnormal code block according to its logic repair suggestions, resulting in a new code block; using the new code block as the current code block, running the current code block in the sandbox environment, and obtaining the execution result of the current code block; if the execution result of the current code block is a failure, then... The execution results and error messages of the code block and the preceding code blocks are used to locate the third abnormal code block that caused the current code block to fail, and a code execution failure repair suggestion for the third abnormal code block is generated. In the sandbox environment, the first code repair tool is called to repair the third abnormal code block according to the code execution failure repair suggestion for the third abnormal code block until the current code block runs successfully. The next code block in the line loss anomaly diagnosis code in the current code block is taken as the new current code block, and the steps of running the current code block in the sandbox environment and its subsequent steps are repeated until the current code block is the last code block in the line loss anomaly diagnosis code.

[0082] Specifically, the second exception code block is an exception code block with a logical error, and the third exception code block is an exception code block that is located that caused the current code block to fail. Exception code blocks are different from normal code blocks and need to be repaired.

[0083] For each current code block, if the execution result of the current code block is failure, perform the following steps: run the current code block in the sandbox environment to obtain the execution result of the current code block; if the execution result of the current code block is failure, locate the third abnormal code block that caused the execution failure of the current code block based on the execution results and error messages of the current code block and the previous code blocks, and generate code execution failure repair suggestions for the third abnormal code block; call the first code repair tool in the sandbox environment to repair the third abnormal code block according to the code execution failure repair suggestions for the third abnormal code block, until the current code block runs successfully.

[0084] Specifically, after fixing the third exception code block, the current code block can be run again. If the current code block runs successfully after this second run, the processing of the next code block can proceed. If the current code block fails after this second run, the process repeats: "Run the current code block in the sandbox environment to obtain the result; if the result is failure, locate the third exception code block that caused the failure based on the results and error messages of the current and previous code blocks, and generate a code failure repair suggestion for the third exception code block; call the first code repair tool in the sandbox environment to repair the third exception code block according to the code failure repair suggestion, until the current code block runs successfully."

[0085] The code correction agent can design reasonable prompt words and use the prompt words to call the capabilities of the large language model to perform the following operations: locate the third abnormal code block that caused the current code block to fail based on the execution results and error information of the current code block and generate code failure repair suggestions for the third abnormal code block.

[0086] Specifically, by collaboratively calling a first code repair tool focused on operational feasibility and a second code repair tool focused on logical correctness within a sandbox environment, a layered, progressive, and closed-loop iterative intelligent error correction mechanism was constructed. This mechanism not only achieves dual repair of code logic errors and operational failures but also relies on the sandbox environment to ensure secure isolation and reliable results throughout the entire process, thereby improving the logical accuracy, execution reliability, and automated generation quality of the line loss anomaly diagnosis code.

[0087] In some optional embodiments, there are multiple unit test cases. The triggering code correction agent uses the unit test cases to perform unit tests on the line loss anomaly diagnosis code, obtains the unit test results, and corrects the line loss anomaly diagnosis code to obtain the target line loss anomaly diagnosis code if the unit test results fail. This includes: sequentially using one of the multiple unit test cases as the current unit test case, repeating the following steps until all unit test cases have been tested, and obtaining the final target line loss anomaly diagnosis code; the triggering code correction agent uses the current unit test case to perform unit tests on the line loss anomaly diagnosis code, obtains the unit test results, and corrects the line loss anomaly diagnosis code to obtain the target line loss anomaly diagnosis code, using the target line loss anomaly diagnosis code as the new line loss anomaly diagnosis code, and repeating the step of sequentially using one of the multiple unit test cases as the current unit test case until all unit test cases have been tested, and obtaining the final target line loss anomaly diagnosis code.

[0088] Specifically, for each current unit test case, the following operations are performed: The code correction agent is triggered to perform unit testing on the line loss anomaly diagnosis code using the current unit test case, obtain the unit test results, and if the unit test results fail, correct the line loss anomaly diagnosis code to obtain the target line loss anomaly diagnosis code. This target line loss anomaly diagnosis code is then used as the new line loss anomaly diagnosis code. Of course, if the current unit test case is the last unit test case, the new line loss anomaly diagnosis code obtained through correction is the final target line loss anomaly diagnosis code.

[0089] Specifically, iterative unit testing using multiple unit test cases can cover different power objects (such as power lines or transformer substations) and various types of line loss anomalies. The code correction agent uses each unit test case as a verification standard to perform refined testing and repair on the line loss anomaly diagnosis code. Whenever the current unit test fails, a targeted error correction process is triggered, generating the repaired target line loss anomaly diagnosis code as input for the next round of testing. Through this closed-loop mechanism of verification by test case and progressive optimization, the logical accuracy, execution reliability, and automated generation quality of the line loss anomaly diagnosis code are improved.

[0090] The technical solution provided in this application involves inputting code generation requirement information, including power data file input requirements, line loss anomaly diagnosis rule text, and diagnosis result output requirements, into a code generation agent to automatically generate initial line loss anomaly diagnosis code. Then, combined with unit test cases, a code correction agent performs unit testing and automatic error correction on the line loss anomaly diagnosis code, ultimately generating highly reliable line loss anomaly diagnosis code. Thus, the code generation agent and the code correction agent collaborate to achieve end-to-end automated construction from natural language rules to executable line loss anomaly diagnosis code, providing secure, efficient, and practical technical support for intelligent line loss analysis in power systems.

[0091] Figure 3 This is a schematic diagram illustrating the process of generating code for intelligent agent collaboration, as provided in an embodiment of this application. See also... Figure 3 Users input code generation requirements on the interactive interface. These requirements include, for example, power data file input requirements, line loss anomaly diagnosis rule text, and diagnosis result output requirements. After receiving the user's code generation requirements, the code generation agent performs task orchestration operations. The task orchestration results include data input tasks, multiple operation step tasks, and data output tasks.

[0092] The code generation agent invokes the code generation tool to generate code blocks for each task sequentially. For the current task's code block, it runs in a sandbox environment. If the current task's code block fails, the first code repair tool is invoked to locate and repair the abnormal code block causing the failure, continuing until the current task's code block runs successfully, and then proceeding to the next task's code block generation phase. After all task code blocks have been generated, the line loss anomaly diagnosis code is obtained. This code includes multiple code blocks, such as code block 1, code block 2, ..., code block n, where n is a positive integer.

[0093] After code generation is complete, the unit testing and error correction phase begins. The code correction agent receives input test requirements, which may include line loss anomaly diagnosis code and multiple unit test cases. Each unit test case is used to perform unit testing on the line loss anomaly diagnosis code. If the unit test results do not meet expectations (i.e., fail), it indicates a logical error in the line loss anomaly diagnosis code. The code correction agent locates the faulty code block within the line loss anomaly diagnosis code, calls a second code repair tool to fix the faulty code block, and obtains a new code block. This new code block and subsequent code blocks are then run sequentially in a sandbox environment. If the currently running code block fails in the sandbox environment, the first code repair tool is called to locate and repair the faulty code block causing the current task's failure, until the currently running code block succeeds, and the process moves to the next code block. Once the new code block and subsequent code blocks have all run successfully, the final line loss anomaly diagnosis code is obtained.

[0094] In practical applications, after the code generation agent and the code correction agent collaborate to obtain the target line loss anomaly diagnosis code, the target line loss anomaly diagnosis code can be saved for use in the line loss anomaly diagnosis stage. The following describes a method for diagnosing power line loss anomalies.

[0095] Figure 4 A flowchart illustrating an exemplary method for diagnosing abnormal power line losses, provided in an embodiment of this application. See also... Figure 4 The method may include the following steps:

[0096] 401. Obtain the filename of the power data file of the power object to be diagnosed.

[0097] 402. Call the power line loss anomaly diagnosis intelligent agent, input the file name as an actual parameter into the target line loss anomaly diagnosis code, and run the target line loss anomaly diagnosis code after the actual parameter input to perform line loss anomaly diagnosis on the power object to be diagnosed, and obtain the line loss anomaly diagnosis result of the power object to be diagnosed.

[0098] Specifically, the intelligent agent for diagnosing power line loss anomalies can call the target power line loss anomaly diagnosis code corresponding to different power line loss anomaly diagnosis rule texts. The power object to be diagnosed can be a power line or a transformer substation, and the number of power data files can be one or more.

[0099] When the filename of the power data file of the power object to be diagnosed is input into the power line loss anomaly diagnosis intelligent agent, the intelligent agent uses the filename of the power data file of the power object to be diagnosed as an actual parameter to input the target line loss anomaly diagnosis code, and runs the target line loss anomaly diagnosis code after the actual parameter input to perform line loss anomaly diagnosis on the power object to be diagnosed, and obtains the line loss anomaly diagnosis result of the power object to be diagnosed. In this way, the automation, efficiency and accuracy of line loss anomaly diagnosis are improved.

[0100] Taking a specific transformer substation as an example, the power data file for a transformer substation includes a table file titled "Dealer Substation User Input / Output Power Details.xlsx" and a table file titled "Dealer Substation Monthly Line Loss Data.xlsx". The line loss anomaly diagnosis results for a transformer substation include a table file titled "Dealer Substation Anomaly User List.xlsx", a table file titled "Dealer Substation Monthly Line Loss Report.xlsx", and a text-based diagnostic conclusion.

[0101] For example, the diagnostic conclusion in text form is: "Through intelligent analysis, a certain transformer (transformer area number: 52**61) has a full-code power calculation error; the user with the full-code calculation error is: a certain user (user number: 03**77). The meter value is normal and full-code, the correct output power is 36.58 kWh, and the output power is under-counted by 363**.68 kWh; the system error calculation caused the total under-counted combined input power of the transformer area to be 0 kWh, and the total under-counted combined output power of the transformer area to be 36.68 kWh. The corrected combined input power of the front-end transformer area is 1285.87 kWh, the corrected combined output power of the front-end transformer area is 85485.16 kWh, and the corrected combined line loss rate of the front-end transformer area is 3.48%; the corrected combined input power of the back-end transformer area is 1285.87 kWh, the corrected combined output power of the back-end transformer area is 1218.84 kWh, and the corrected combined line loss rate of the back-end transformer area is 5.0%; the corrected line loss rate does not exceed the upper and lower limits of the line loss assessment, so the status is qualified."

[0102] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. "At least one" means one or more, and "more than one" means two or more. "And / or" describes the access relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following associated objects are in an "or" relationship. In addition, in the embodiments of this application, "first," "second," "third," etc., are only used to distinguish the content of different objects and have no other special meaning.

[0103] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0104] Figure 5 This is a schematic diagram of an exemplary electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device includes: a memory 51 and a processor 52;

[0105] Memory 51 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0106] The processor 52, coupled to the memory 51, is used to execute the computer program in the memory 51 for: executing steps in a code generation method or a power line loss anomaly diagnosis method.

[0107] Optional, such as Figure 5 As shown, the electronic device also includes other components such as a communication component 53, a display 54, a power supply component 55, and an audio component 56. Figure 5 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 5 The components shown. Additionally... Figure 5 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a desktop computer, laptop computer, or smartphone, it may include... Figure 5 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 5 The component within the dashed box.

[0108] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0109] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G (2nd Generation), 3G (3rd Generation), 4G (4th Generation) / LTE (long Term Evolution), 5G (5th Generation), or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0110] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0111] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0112] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0113] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium may be volatile, non-volatile, or a combination thereof, and may be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium.

[0114] Accordingly, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor is able to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0115] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0116] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A code generation method characterized by, include: Input the code generation requirement information into the code generation agent to trigger the code generation agent to generate line loss anomaly diagnosis code. The code generation requirement information includes power data file input requirement information, line loss anomaly diagnosis rule text, and diagnosis result output requirement information. The line loss anomaly diagnosis code and unit test cases are input into the code correction agent to trigger the code correction agent to perform unit tests on the line loss anomaly diagnosis code using the unit test cases, obtain the unit test results, and correct the line loss anomaly diagnosis code if the unit test results fail, thereby obtaining the target line loss anomaly diagnosis code. The target line loss anomaly diagnosis code is used to diagnose line loss anomalies in the power object to be diagnosed. The process of triggering the code generation agent to generate line loss anomaly diagnostic code includes: triggering the code generation agent to perform the following operations: The power data file input requirement information is parsed to obtain the data input task information, which is used to instruct the reading of the power data file of the power object to be diagnosed from the power data folder. The text of the line loss anomaly diagnosis rule is parsed to obtain task information of multiple operation steps in the line loss anomaly diagnosis task. The line loss anomaly diagnosis task is used to instruct line loss anomaly diagnosis to be performed based on the power data file of the power object to be diagnosed, and to obtain the line loss anomaly diagnosis result of the power object to be diagnosed. The diagnostic result output requirement information is parsed to obtain the task information of the data output task, which is used to instruct the output of the abnormal line loss diagnostic result of the power object to be diagnosed to the diagnostic result folder. Based on the task information of the data input task, the multiple operation step tasks, and the data output task, the line loss anomaly diagnosis code is generated. The line loss anomaly diagnosis code includes the code block corresponding to the data input task, the code block corresponding to the multiple operation step tasks, and the code block corresponding to the data output task.

2. The method of claim 1, wherein, Based on the task information of the data input task, the multiple operation step tasks, and the data output task, the line loss anomaly diagnosis code is generated, including: The data input task, the multiple operation step tasks, and the data output task are organized sequentially to obtain the task arrangement result. Take one task from the task orchestration result as the current task and repeat the following steps until all tasks in the task orchestration result have been processed: The code generation tool is invoked to generate a code block for the current task based on the task information of the current task, and the code block for the current task is run in the sandbox environment to obtain the execution result of the code block for the current task; If the execution result of the code block of the current task is failure, then locate and repair the first abnormal code block that caused the code block of the current task to fail, until the execution result of the code block of the current task is success. The line loss anomaly diagnosis code is generated based on the code blocks corresponding to all tasks in the task orchestration result.

3. The method according to claim 2, characterized in that, If the execution result of the code block of the current task is a failure, then locate and repair the first abnormal code block that caused the execution failure of the code block of the current task, until the execution result of the current task is a success, including: If the execution result of the code block of the current task is a failure, then based on the execution results and error information of the code blocks of the current task and the previous historical tasks, locate the first abnormal code block that caused the code block of the current task to fail, and generate a code failure repair suggestion for the first abnormal code block. In the sandbox environment, the first code repair tool is invoked to repair the first abnormal code block according to the code execution failure repair suggestions of the first abnormal code block, until the execution result of the code block of the current task is successful.

4. The method of claim 1, wherein, The trigger code correction agent uses the unit test cases to perform unit tests on the line loss anomaly diagnosis code, and obtains the unit test results, including: The code correction agent is triggered to perform the following steps: Obtain the target file name and expected line loss anomaly diagnosis result corresponding to the target power object from the unit test cases, wherein the target file name is the file name of the power data file of the target power object; The target file name is used as an actual parameter to input the line loss anomaly diagnosis code. The line loss anomaly diagnosis code after the actual parameter input is run in the sandbox environment to obtain the actual line loss anomaly diagnosis result of the target power object. The unit test results are determined based on the consistency analysis between the expected line loss anomaly diagnosis results and the actual line loss anomaly diagnosis results of the target power object.

5. The method of claim 4, wherein, Based on the consistency analysis results between the expected line loss anomaly diagnosis results and the actual line loss anomaly diagnosis results of the target power object, the unit test results are determined, including: If the semantics of the text in the expected line loss anomaly diagnosis result of the target power object are consistent with the semantics of the text in the actual line loss anomaly diagnosis result, and the field information of the table file in the expected line loss anomaly diagnosis result of the target power object is consistent with the field information of the table file in the actual line loss anomaly diagnosis result, then the unit test result is determined to be passed. If the semantics of the text in the expected line loss anomaly diagnosis result of the target power object differs from the semantics of the text in the actual line loss anomaly diagnosis result, and / or, the field information in the table file of the expected line loss anomaly diagnosis result of the target power object differs from the field information in the table file of the actual line loss anomaly diagnosis result, then the unit test result is determined to be unsuccessful.

6. The method of claim 1, wherein, If the unit test fails, the line loss anomaly diagnostic code is corrected to obtain the target line loss anomaly diagnostic code, including: If the unit test fails, locate the second abnormal code block in the line loss anomaly diagnosis code that has a code logic error, and generate a code logic repair suggestion for the second abnormal code block; In the sandbox environment, the second code repair tool is invoked to repair the second abnormal code block according to the code logic repair suggestions of the second abnormal code block to obtain a new code block, so as to complete the error correction of the line loss anomaly diagnosis code and obtain the target line loss anomaly diagnosis code.

7. The method of claim 6, wherein, In the sandbox environment, the second code repair tool is invoked to repair the second abnormal code block according to the code logic repair suggestions of the second abnormal code block, thereby obtaining a new code block to complete the error correction of the line loss anomaly diagnosis code and obtain the target line loss anomaly diagnosis code, including: In the sandbox environment, a second code repair tool is invoked to repair the second abnormal code block according to the code logic repair suggestions of the second abnormal code block, resulting in a new code block; The new code block is used as the current code block, and the current code block is run in the sandbox environment to obtain the execution result of the current code block; If the execution result of the current code block is a failure, then based on the execution results and error information of the current code block and the previous code blocks, locate the third abnormal code block that caused the failure of the current code block, and generate a code execution failure repair suggestion for the third abnormal code block. In the sandbox environment, the first code repair tool is invoked to repair the third abnormal code block according to the code execution failure repair suggestions of the third abnormal code block, until the current code block runs successfully; The next code block in the current code block is taken as the new current code block, and the steps of running the current code block and its subsequent steps in the sandbox environment are repeated until the current code block is the last code block in the line loss anomaly diagnosis code.

8. The method according to any one of claims 1 to 7, characterized in that, The number of unit test cases is multiple. The triggering code correction agent uses these unit test cases to perform unit tests on the line loss anomaly diagnosis code, obtains the unit test results, and corrects the line loss anomaly diagnosis code if the unit test results fail, resulting in the target line loss anomaly diagnosis code including: By sequentially selecting one unit test case from a pool of unit test cases as the current unit test case, the following steps are repeated until all unit test cases have been tested, resulting in the final target line loss anomaly diagnostic code: The trigger code correction agent uses the current unit test case to perform unit testing on the line loss anomaly diagnosis code, obtains the unit test results, and corrects the line loss anomaly diagnosis code if the unit test results fail, thereby obtaining the target line loss anomaly diagnosis code, and uses the target line loss anomaly diagnosis code as the new line loss anomaly diagnosis code.

9. A power line loss abnormality diagnosis method characterized by comprising: include: Obtain the filename of the power data file of the power object to be diagnosed; The power line loss anomaly diagnosis intelligent agent is invoked to input the file name as an actual parameter into the target power line loss anomaly diagnosis code, and the target power line loss anomaly diagnosis code after the actual parameter input is run to perform power line loss anomaly diagnosis on the power object to be diagnosed, and obtain the power line loss anomaly diagnosis result of the power object to be diagnosed; The target line loss anomaly diagnostic code is obtained by the method according to any one of claims 1 to 8.

10. An electronic device, comprising: include: Memory and processor; The memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1-9.

11. A computer readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-9.

12. A computer program product, characterised in that, Includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1-9.

Images