A program code refactoring self-checking method, device and computer readable storage medium

Abstract

This invention discloses a program code refactoring self-testing method, device, and computer-readable storage medium. The method includes: constraining and guiding a large model to generate refactoring code for the current device through a preset physical directory; before sending the refactoring code to the device for testing, injecting a dataset of real physical mappings corresponding to the device into the refactoring code through a preset virtual sandbox, and collecting expected physical responses; verifying the expected physical responses based on the real physical responses in the dataset, and after successful verification, sending the refactoring code to the device for testing. This achieves a more reliable program code refactoring self-testing scheme, avoiding the risk of collisions with real-world devices when generating code from a large model, and ensuring the determinism and maintainability of industrial software architecture.

Description

Technical Field

[0001] This invention relates to the field of industrial automation technology, and in particular to a program code refactoring self-testing method, device, and computer-readable storage medium. Background Technology

[0002] In existing technologies, with the rapid development of artificial intelligence and large language models, multi-agent code generation based on large models for refactoring and translating legacy software has become widely used. In traditional pure software or web development fields, code generated by large models is usually verified and self-checked through manual review, static syntax checking, and pre-written unit tests. However, in the field of industrial automation, such as the host computer software of precision dispensing, vision inspection, and motion control equipment, the following drawbacks exist when large models are applied to code refactoring: First, the cost and safety risks of physical trial and error are extremely high. The code of industrial software directly drives physical hardware such as servo motors and robotic arms. However, when large models generate code, due to illusions or a lack of understanding of physical boundaries, if the generated logic is wrong, such as incorrect coordinate calculations or reversed I / O timing, it will lead to serious mechanical collisions, deadlocks, or even personal injury if it is run and tested directly on actual physical machines. Second, there is a lack of closed-loop self-checking mechanism for physical actions; traditional unit tests can only verify whether the input and output strings of pure software logic match, but cannot verify whether the physical position, motion trajectory, and IO hardware status corresponding to the generated control commands are absolutely accurate under complex time series. Third, the generated code is difficult to meet the requirements of strong industrial structure. The code generated by large models is often divergent and tends to couple logic into a large file. However, industrial software requires extremely strict file directory division for later maintenance and real-time performance. For example, vision, motion, and communication must be physically isolated. Existing code generation tools lack strong constraints on such physical directory levels. In summary, when reconstructing industrial automation programs based on large models, the lack of a secure and automated verification mechanism for physical behavior may lead to issues such as the generated code being unable to be safely deployed to real physical devices, or the generated code having a chaotic architecture and not conforming to industry standards. Summary of the Invention

[0003] In order to overcome the shortcomings of the prior art, the present invention aims to provide a program code refactoring self-testing method, device and computer-readable storage medium to solve the problem that when refactoring industrial automation programs based on large models, the lack of a safe and automatic verification mechanism for physical behavior may lead to the generated code being unable to be safely deployed to real physical devices, or the generated code having a chaotic architecture and not conforming to industry standards.

[0004] This invention proposes a self-checking method for program code refactoring, the method comprising: The system uses a pre-defined physical directory constraint to guide the generation of refactoring code for the current device from a large model. Before the refactoring code is distributed to the device for testing, a dataset of the real physical mapping corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical response is collected. The expected physical response is verified based on the actual physical response in the dataset, and after the verification is passed, the refactoring code is sent to the device for testing.

[0005] Optionally, before generating refactoring code from the large model by constraining it through a preset physical directory, the process includes: The equipment executes standard production tasks according to the original program, and records the input status of the upper-layer software and the actual physical response of the lower-layer system. The input states and actual physical responses are bound together according to a time series, and formatted according to preset key-value pairs to obtain the dataset of the actual physical mapping.

[0006] Optionally, the step of generating the current device's reconstruction code by constraining and guiding the large model through a preset physical directory specifically includes: The preset physical folder directory tree structure serves as the physical directory during reconstruction, and the preset format to be followed is defined in the system prompts given to the large model; Based on the physical directory and the format, the large model modules are constrained and guided to generate the refactoring code.

[0007] Optionally, the step of generating the current device's reconstruction code by constraining and guiding the large model through a preset physical directory further includes: After the large model generates code, a preset script intercepts and scans the code path and code structure of the currently generated code before compilation, and determines whether there are any paths in the code path that are not classified into their respective physical directories, and whether there are any directories that are directly called across directories in the code structure. If the code path contains paths that are not categorized into their respective physical directories, or if the code structure contains directories that are directly called across directories, the script will refuse to save the currently generated code and will revert to the large model to regenerate the code.

[0008] Optionally, the step of injecting a dataset of the real physical mappings corresponding to the device into the reconstruction code through a preset virtual sandbox and collecting the desired physical response specifically includes: The refactoring code is deployed in the virtual sandbox without a real hardware connection, and the input states are injected into the refactoring code according to the time series. The target location and / or target state determined by the reconstructed code are collected as the desired physical response.

[0009] Optionally, the step of verifying the expected physical response based on the actual physical responses in the dataset specifically includes: A tolerance comparison is performed between the actual physical response and the expected physical response; The percentage of tasks that pass and / or the error distribution are determined based on the results of the tolerance comparison.

[0010] Optionally, the step of verifying the expected physical response based on the actual physical responses in the dataset further includes: By statistically analyzing the task ratio and / or the error distribution, an accuracy score for the reconstructed code is obtained. Determine whether the accuracy score is greater than a preset safety test threshold. If the accuracy score is greater than the preset safety test threshold, then send the reconstructed code to the device for testing.

[0011] Optionally, determining whether the accuracy score is higher than a preset safety measurement threshold further includes: If the accuracy score is less than or equal to the preset safety test threshold, the error context and deviation magnitude will be fed back to the large model to perform targeted iterative repair of the reconstructed code.

[0012] The present invention also proposes a program code refactoring self-testing device, the device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the program code refactoring self-testing method as described in any of the preceding claims.

[0013] The present invention also proposes a computer-readable storage medium storing a program code refactoring self-test program, which, when executed by a processor, implements the steps of the program code refactoring self-test method as described in any of the preceding claims.

[0014] The present invention provides a program code refactoring self-testing method, device, and computer-readable storage medium. It constrains and guides a large model to generate refactoring code for the current device through a preset physical directory. Before distributing the refactoring code to the device for testing, a dataset of real physical mappings corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical responses are collected. The expected physical responses are verified based on the real physical responses in the dataset. After successful verification, the refactoring code is then distributed to the device for testing. This achieves a more reliable program code refactoring self-testing scheme, avoiding the risk of collisions between large model-generated code and actual devices, and ensuring the determinism and maintainability of industrial software architecture. Attached Figure Description

[0015] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart of the first embodiment of the self-test method for program code refactoring of the present invention; Figure 2 This is a flowchart of the second embodiment of the self-test method for program code refactoring of the present invention; Figure 3 This is a flowchart of the third embodiment of the self-test method for program code refactoring of the present invention; Figure 4 This is a flowchart of the fourth embodiment of the self-test method for program code refactoring of the present invention; Figure 5 This is a flowchart of the fifth embodiment of the self-test method for program code refactoring of the present invention; Figure 6 This is a flowchart of the sixth embodiment of the self-test method for program code refactoring of the present invention; Figure 7 This is a flowchart of the seventh embodiment of the self-test method for program code refactoring of the present invention; Figure 8 This is the control logic diagram of data acquisition and sandbox self-testing for the self-testing method of program code refactoring in this invention; Figure 9 This is the control logic diagram of the physical directory strong constraint and script interception of the self-checking method for program code refactoring in this invention. Detailed Implementation

[0016] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0017] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0018] Example 1 Figure 1 This is a flowchart of the first embodiment of the program code refactoring self-checking method of the present invention. A program code refactoring self-checking method, the method comprising: S1. Generate the reconstruction code for the current device by constraining the preset physical directory and guiding the large model; S2. Before the refactoring code is sent to the device for testing, a dataset of the real physical mapping corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical response is collected. S3. Verify the expected physical response based on the actual physical response in the dataset, and after the verification is passed, send the reconstructed code to the device for testing.

[0019] In this embodiment, before refactoring the code based on the large model, firstly, mature legacy software is run on existing machines to collect the issued instructions and corresponding real physical feedback in real time to construct a real physical mapping dataset. Then, under the constraints of a strong physical directory architecture, the large model is guided to generate refactoring code in modules, and interception and parsing are performed through pre-compiled scripts. After the refactoring code is generated, it is run in a virtual digital sandbox driven by the dataset input, and self-checking is performed using a tolerance-based comparison algorithm. When the comparison accuracy meets a preset threshold, the refactoring code is then deployed to a real physical system for subsequent testing or application.

[0020] Please refer to Figure 8 The diagram illustrates the control logic for data acquisition and sandbox self-testing. During the data acquisition phase, the data acquisition and set construction module collects and synchronizes input commands and underlying physical response data during the old software's operation, generating a real physical mapping dataset in a preset format (e.g., JSON format, a lightweight data structure). A large model constraint generation agent, specifically including a directory rule engine and pre-compiled scanning scripts, sends a Prompt containing schema constraints to the large model and performs physical-level interception and mandatory verification of the generated code structure and its file path. During the sandbox self-testing phase, the sandbox closed-loop self-testing module implements virtual operation independently of the physical hardware. This module reads the dataset input and drives the reconstructed code execution. A comparison algorithm with preset tolerances is then used to determine whether the expected coordinate output highly matches the actual physical coordinates. Finally, the safety-responsible release controller compares the accuracy score output by the sandbox self-testing module with a preset threshold to control whether the reconstructed code is sent to the actual industrial machine.

[0021] In this embodiment, a closed-loop self-checking mechanism based on historical real physical data is used to construct a dataset by collecting the mapping relationship between input instructions and output physical actions of existing stable software on real machines. This dataset is then used as the sole evaluation criterion for reconstructing code in a virtual sandbox, achieving secure isolation of physical control logic that can be verified without touching the actual machine.

[0022] In this embodiment, the generation control architecture based on strong physical directory constraints sets mandatory physical file directory structure limitations when generating code using a large model. The code generated by the large model must fall precisely into the corresponding directory. Code that does not conform to the directory tree structure will be intercepted and reconstructed, thereby converging the divergence of the large model.

[0023] In this embodiment, based on a hierarchical and progressive automated acceptance and tolerance self-inspection strategy, the machine testing permission is only granted when the output matching accuracy of the refactored code on the historical dataset in a pure digital sandbox (e.g., with the introduction of physical space tolerance epsilon) reaches an extremely high threshold (e.g., above 99.8%).

[0024] In this embodiment, compared to the existing method of using large models to automatically generate front-end or back-end test cases or test code based on abstract syntax trees or prompt words to improve test coverage, the test dataset in this embodiment does not rely on large model generation at all. Instead, it comes from the physical feedback data (i.e., Ground Truth) of the historical operation of real machines. The code is verified by replaying the physical mapping relationship, thus avoiding the illusionary risk of large models creating their own performances from the root.

[0025] In this embodiment, compared to the existing method of translating old Java / C++ IT system code using large models and relying on traditional unit tests to verify logical correctness, this embodiment introduces a tolerance-based sandbox physical location comparison algorithm based on the characteristics of the industrial physical world. This allows for minor errors in the underlying floating-point calculations of different languages, greatly improving the industrial practicality of self-testing.

[0026] In this embodiment, compared to existing code refactoring methods that rely heavily on the context management of the large model itself, this embodiment is based on a strong constraint of physical directory and a pre-compiled script interception mechanism. It forces the large model to output code on a specific path according to a strict industrial physical isolation architecture (e.g., vision, motion, and IO layering). Code that does not conform to the directory structure is directly intercepted outside the sandbox.

[0027] The beneficial effects of this embodiment are as follows: by constraining and guiding a large model through a preset physical directory, the refactoring code for the current device is generated; before the refactoring code is sent to the device for testing, a dataset of real physical mappings corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical response is collected; the expected physical response is verified based on the real physical response in the dataset, and after the verification is passed, the refactoring code is sent to the device for testing; a more reliable self-checking scheme for program code refactoring is achieved, avoiding the risk of collision with the actual machine when the code is generated by the large model, and ensuring the determinism and maintainability of the industrial software architecture.

[0028] Example 2 Figure 2 This is a flowchart of the second embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, before generating refactoring code by constraining the large model through a preset physical directory, the process includes: S01. Execute standard production tasks on the device according to the original program, and record the input status of the upper-level software and the actual physical response of the lower-level system. S02. Bind the input state and the actual physical response according to the time sequence, and format it according to the preset key-value pairs to obtain the dataset of the actual physical mapping.

[0029] In this embodiment, before constructing the real physical mapping dataset, standard production tasks are first executed on industrial physical equipment equipped with mature legacy software that needs to be refactored.

[0030] In this embodiment, during the execution of standard production tasks, the input status of the upper-layer software and the actual physical response of the lower-layer system are recorded synchronously. The input status of the upper-layer software includes operator instructions, sensor trigger signals, timestamps, etc., while the actual physical response of the lower-layer system includes the actual arrival coordinate position of the servo motor, acceleration and deceleration curve characteristics, IO port level status, motor pulse count, etc.

[0031] In this embodiment, the above inputs are bound to the actual physical responses in a time-series correspondence and formatted as key-value pairs (e.g., the JSON format described above), forming a standardized dataset of real physical mappings; for example: { "timestamp": 1682345001, "input": {"sensor_A_status": 1, "task_id":"T01"}, "output": {"motor_X_pos": 100.5, "motor_Y_pos": 200.0, "valve_io":true}}; where timestamp is the timestamp, input is the input command, sensor_A_status is the position of sensor A, task_id is the task number, and output is the actual physical response.

[0032] The beneficial effect of this embodiment is that by executing standard production tasks on the device according to the original program, the input state of the upper-layer software and the actual physical response of the lower-layer system are recorded; the input state and the actual physical response are bound by time sequence and formatted according to preset key-value pairs to obtain the dataset of the actual physical mapping; thereby realizing a closed-loop self-checking mechanism based on historical real physical data, that is, by collecting the mapping relationship between input instructions and output physical actions of existing stable software on real machines to construct a dataset, which is used as the sole evaluation standard for reconstructing code in the virtual sandbox, and realizing the safe isolation of verifying physical control logic without touching the actual machine.

[0033] Example 3 Figure 3 This is a flowchart of the third embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, the step of generating the refactoring code for the current device by constraining and guiding the large model through a preset physical directory specifically includes: S11. A preset directory tree structure of the physical folder is used as the physical directory during reconstruction, and a preset format to be followed is defined in the system prompts given to the large model; S12. Based on the physical directory and the format, constrain and guide the large model sub-modules to generate the reconstruction code.

[0034] In this embodiment, a large model generation framework with strong physical directory constraints is established, specifically including: on the one hand, a mandatory physical folder directory tree structure for the reconstructed software is predefined, for example: src / motion contains only motion control logic, src / vision contains only vision processing logic, and src / io contains only hardware communication; on the other hand, the output in the System Prompt given to the large model is forced to follow a specific JSON Schema format, including file_path (code path) and code_content (code content).

[0035] The beneficial effect of this embodiment is that by using a preset physical folder directory tree structure as the physical directory during reconstruction, and defining a preset format that the output must follow in the system prompts given to the large model; based on the physical directory and the format, the large model is constrained and guided to generate the reconstruction code in modules; thereby realizing a generation control architecture with strong physical directory constraints, and implementing mandatory physical file directory structure constraints when generating code using the large model.

[0036] Example 4 Figure 4 This is a flowchart of the fourth embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, the step of generating the refactoring code for the current device by constraining and guiding the large model through a preset physical directory further includes: S13. After the large model generates code, a preset script is used to intercept and scan the code path and code structure of the currently generated code before code compilation, and to determine whether there are any paths in the code path that are not classified into their respective physical directories, and whether there are any directories that are directly called across directories in the code structure. S14. When there are paths in the code path that are not classified into their respective physical directories, or when there are directories that are directly called across directories in the code structure, the script refuses to save the currently generated code and rolls back to the large model to regenerate the code.

[0037] Please refer to Figure 9 The diagram illustrates the strong constraints of the physical directory and the script interception mechanism. In this embodiment, after the large model generates code, an automated parsing script intercepts and scans the generated file_path before compilation. If it finds that the code path is not correctly classified into the specified physical directory, or if it detects illegal cross-directory direct calls in a certain directory (e.g., severe coupling), the script will refuse to save the code and automatically return the error message and requirements to the large model, requiring it to regenerate the code until the regenerated code meets the constraints of the above architecture.

[0038] The beneficial effect of this embodiment is that, after the code is generated from the large model, a preset script intercepts and scans the code path and code structure of the currently generated code before compilation, and determines whether there are any paths in the code path that are not classified into their respective physical directories, and whether there are any directories that are directly called across directories in the code structure. When there are any paths in the code path that are not classified into their respective physical directories, or directories that are directly called across directories in the code structure, the script refuses to save the currently generated code and reverts to the large model to regenerate the code. Thus, based on the above-mentioned mandatory physical file directory structure limitation, the code generated by the large model must fall precisely into the corresponding directory, and code that does not conform to the directory tree structure will be intercepted and reconstructed, thereby converging the divergence of the large model.

[0039] Example 5 Figure 5 This is a flowchart of the fifth embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, the step of injecting a dataset of the real physical mapping corresponding to the device into the refactoring code through a preset virtual sandbox and collecting the expected physical response specifically includes: S21. Deploy the refactoring code in the virtual sandbox without a real hardware connection, and inject the input state into the refactoring code according to the time sequence; S22. Collect the target location and / or target state determined by the reconstructed code as the desired physical response.

[0040] In this embodiment, a pure software sandbox is used for digital self-testing and tolerance comparison. Specifically: First, the refactoring code that has passed the constraint check is deployed in a pure digital virtual sandbox without any real hardware connection; then, the input states in the dataset established above are injected into the refactoring code in sequence; finally, the expected physical response calculated by the refactoring code is collected, which is the position or state that the refactoring code believes the hardware should reach.

[0041] The beneficial effect of this embodiment is that by deploying the refactoring code in the virtual sandbox without a real hardware connection, and injecting the input state into the refactoring code according to the time sequence, the target position and / or target state determined by the refactoring code are collected as the desired physical response; thereby avoiding direct testing of the refactoring code on a real device and reducing the risk of damage to the real device.

[0042] Example 6 Figure 6 This is a flowchart of the sixth embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, the step of verifying the expected physical response according to the actual physical response in the dataset specifically includes: S31. Perform a tolerance comparison between the actual physical response and the expected physical response; S32. Determine the proportion of tasks that pass and / or the error distribution based on the results of the tolerance comparison.

[0043] In this embodiment, the expected physical response is compared and verified with the actual physical response in the dataset. To accommodate minor errors in floating-point calculations between different programming languages, a position deviation tolerance value $\epsilon$ (e.g., $\epsilon = 0.01mm$) is introduced. Specifically, for the calculated expected coordinates (X_new, Y_new) and the actual coordinates $(X_{real}, Y_{real})$, if the absolute difference |X_new-X_real|≤ϵ_x and $|Y_{new}-Y_{real}| \le \epsilon_y$, or if the Euclidean distance formula is used for judgment, and the IO logical boolean values ​​are strictly equal, then the actions are considered consistent, avoiding only fixed pure string comparisons.

[0044] The beneficial effect of this embodiment is that by comparing the actual physical response with the expected physical response with tolerance, and determining the proportion of tasks that pass and / or the error distribution based on the tolerance comparison results, a hierarchical and progressive automated acceptance and tolerance self-checking strategy is realized. When the output matching accuracy of the refactored code on the historical dataset in a pure digital sandbox (e.g., introducing physical space tolerance epsilon) reaches an extremely high threshold (e.g., above 99.8%), the actual machine testing permission is automatically granted.

[0045] Example 7 Figure 7 This is a flowchart of the seventh embodiment of the self-checking method for program code refactoring of the present invention. Based on the above embodiment, the step of verifying the expected physical response according to the actual physical response in the dataset further includes: S33. Calculate the task ratio and / or the error distribution to obtain the accuracy score of the reconstructed code; S34. Determine whether the accuracy score is greater than the preset safety measurement threshold. S35. If the accuracy score is greater than the preset safety test threshold, the reconstructed code will be sent to the device for testing.

[0046] S36. If the accuracy score is less than or equal to the preset safety test threshold, the error context and deviation magnitude are fed back to the large model to perform targeted iterative repair of the reconstructed code.

[0047] In this embodiment, the proportion of tasks that have passed the comparison and the error distribution are statistically analyzed to calculate the overall accuracy score; then it is determined whether the accuracy score is higher than the preset safety test threshold (e.g., 99.8%); if it is not reached, the error context and deviation magnitude are fed back to the large model for targeted iterative repair; if it is reached, the system automatically generates a release certificate, allowing the refactored code to be packaged and sent to the actual industrial machine for physical testing.

[0048] The beneficial effect of this embodiment is that, by statistically analyzing the task ratio and / or the error distribution, the accuracy score of the reconstructed code is obtained; it is determined whether the accuracy score is greater than a preset safety test threshold. If the accuracy score is greater than the preset safety test threshold, the reconstructed code is then sent to the device for testing; if the accuracy score is less than or equal to the preset safety test threshold, the error context and deviation magnitude are fed back to the large model for targeted iterative repair of the reconstructed code; thereby realizing a safe real-device delivery strategy based on an accuracy threshold, completely eliminating the risk of code generation crashes on real devices.

[0049] In this embodiment, the combined application of the above solutions achieves two key benefits: First, it completely eliminates the risk of code generation colliding with real-world machines. By introducing a historical real-world physical mapping dataset as a verification medium, a one-to-one replication verification of physical behavior at the digital level is completed in a sandbox. This ensures that the unknown large-scale model code receives physical-level reliability verification before contacting real mechanical structures, greatly improving safety. Second, it guarantees the determinism and maintainability of the industrial software architecture. Specifically, strong constraints from the physical directory and automated interception and parsing scripts constrain the free-flowing nature of the large model, ensuring that the reconstructed code possesses a high degree of modularity. The system offers several advantages: 1) Maintainability; 2) Tolerance for reasonable errors and improved self-test pass rate. Specifically, the self-test algorithm incorporates position deviation tolerance and specific difference calculation mechanisms, effectively resolving misjudgments caused by differences in the precision of underlying floating-point calculations in different languages, making industrial-grade refactoring verification more scientific and reasonable; 3) Establishing a closed-loop trust mechanism for the final implementation of AI (Artificial Intelligence), solving not only the problem of how to write code for large models, but also the trust challenge of using AI-written code in the field of hard technology manufacturing, paving the way for the automated refactoring of outdated industrial programs.

[0050] Example 8 Based on the above embodiments, the present invention also proposes a program code refactoring self-testing device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the program code refactoring self-testing method as described in any of the above embodiments.

[0051] It should be noted that the above-described device embodiments and method embodiments belong to the same concept. The specific implementation process can be found in the method embodiments, and the technical features in the method embodiments are also applicable to the device embodiments, which will not be repeated here.

[0052] Example 9 Based on the above embodiments, the present invention also proposes a computer-readable storage medium storing a program code refactoring self-test program, wherein the program code refactoring self-test program, when executed by a processor, implements the steps of the program code refactoring self-test method as described in any of the above embodiments.

[0053] It should be noted that the above-described medium embodiments and method embodiments belong to the same concept. The specific implementation process can be found in the method embodiments, and the technical features in the method embodiments are also applicable to the medium embodiments, which will not be repeated here.

[0054] The present invention provides a program code refactoring self-testing method, device, and computer-readable storage medium. It constrains and guides a large model to generate refactoring code for the current device through a preset physical directory. Before distributing the refactoring code to the device for testing, a dataset of real physical mappings corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical responses are collected. The expected physical responses are verified based on the real physical responses in the dataset. After successful verification, the refactoring code is then distributed to the device for testing. This achieves a more reliable program code refactoring self-testing scheme, avoiding the risk of collisions between large model-generated code and actual devices, and ensuring the determinism and maintainability of industrial software architecture.

[0055] It should be noted that, in this document, 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 a 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.

[0056] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0057] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0058] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A self-checking method for program code refactoring, characterized in that, The method includes: The system uses a pre-defined physical directory constraint to guide the generation of refactoring code for the current device from a large model. Before the refactoring code is distributed to the device for testing, a dataset of the real physical mapping corresponding to the device is injected into the refactoring code through a preset virtual sandbox, and the expected physical response is collected. The expected physical response is verified based on the actual physical response in the dataset, and after the verification is passed, the refactoring code is sent to the device for testing.

2. The program code refactoring self-checking method according to claim 1, characterized in that, Before the process of constraining the large model through a preset physical directory and guiding the generation of refactoring code includes: The equipment executes standard production tasks according to the original program, and records the input status of the upper-layer software and the actual physical response of the lower-layer system. The input states and actual physical responses are bound together according to a time series, and formatted according to preset key-value pairs to obtain the dataset of the actual physical mapping.

3. The program code refactoring self-checking method according to claim 1, characterized in that, The process of generating reconstruction code for the current device by constraining and guiding the large model through a preset physical directory specifically includes: The preset physical folder directory tree structure serves as the physical directory during reconstruction, and the preset format to be followed is defined in the system prompts given to the large model; Based on the physical directory and the format, the large model modules are constrained and guided to generate the refactoring code.

4. The program code refactoring self-checking method according to claim 1, characterized in that, The step of generating reconstruction code for the current device by constraining and guiding the large model through a preset physical directory further includes: After the large model generates code, a preset script intercepts and scans the code path and code structure of the currently generated code before compilation, and determines whether there are any paths in the code path that are not classified into their respective physical directories, and whether there are any directories that are directly called across directories in the code structure. If the code path contains paths that are not categorized into their respective physical directories, or if the code structure contains directories that are directly called across directories, the script will refuse to save the currently generated code and will revert to the large model to regenerate the code.

5. The program code refactoring self-checking method according to claim 2, characterized in that, The process of injecting a dataset of real physical mappings corresponding to the device into the reconstruction code through a preset virtual sandbox and collecting the expected physical response specifically includes: The refactoring code is deployed in the virtual sandbox without a real hardware connection, and the input states are injected into the refactoring code according to the time series. The target location and / or target state determined by the reconstructed code are collected as the desired physical response.

6. The program code refactoring self-checking method according to claim 1, characterized in that, The step of verifying the expected physical response based on the actual physical responses in the dataset specifically includes: A tolerance comparison is performed between the actual physical response and the expected physical response; The percentage of tasks that pass and / or the error distribution are determined based on the results of the tolerance comparison.

7. The program code refactoring self-checking method according to claim 6, characterized in that, The step of verifying the expected physical response based on the actual physical responses in the dataset further includes: By statistically analyzing the task ratio and / or the error distribution, an accuracy score for the reconstructed code is obtained. Determine whether the accuracy score is greater than a preset safety test threshold. If the accuracy score is greater than the preset safety test threshold, then send the reconstructed code to the device for testing.

8. The program code refactoring self-checking method according to claim 7, characterized in that, The step of determining whether the accuracy score is higher than a preset safety measurement threshold further includes: If the accuracy score is less than or equal to the preset safety test threshold, the error context and deviation magnitude will be fed back to the large model to perform targeted iterative repair of the reconstructed code.

9. A program code refactoring self-testing device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the program code refactoring self-test method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an application code refactoring self-test program, which, when executed by a processor, implements the steps of the application code refactoring self-test method as described in any one of claims 1 to 8.

Images