Source code adaptive repair method and related device
By using a layered verification engine to perform multi-layered in-depth verification and adaptive repair of AI-generated source code, the quality and reliability issues of AI code generation tools are resolved, achieving efficient and reliable code repair, which is applicable to fields such as finance, aviation, and healthcare.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUOSEN SECURITIES
- Filing Date
- 2026-04-15
- Publication Date
- 2026-06-05
AI Technical Summary
The quality of code generated by existing AI code generation tools is difficult to guarantee, traditional testing methods lack sufficient verification depth, the fixing process is inefficient and easily introduces new bugs, and cannot meet the needs of high reliability fields such as finance, aviation, and healthcare.
A layered verification engine is used to perform multi-layered in-depth verification of the source code generated by AI, including syntax checking, contract testing, static security, dynamic testing and model checking, generating counterexamples and repair instructions to form an adaptive closed-loop repair mechanism.
Through multi-layered in-depth verification and adaptive repair, the code is ensured to meet system-level properties on all execution paths, improving code reliability and efficiency, reducing the introduction of new bugs, and making it suitable for high-reliability domains.
Smart Images
Figure CN122153892A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software technology, specifically to a source code adaptive repair method and related equipment. Background Technology
[0002] Most mainstream AI code generation applications currently exist at the level of code assistance or code snippet generation. Although AI code generation tools can greatly improve the efficiency of developers, the code generated by AI may contain various errors. Currently, the discovery and fixing of these errors are done manually by developers.
[0003] To address the quality issues of AI-generated code, some studies have proposed a Generate-then-Test pipeline model. In this model, AI-generated code is automatically submitted to a test pipeline for unit tests, integration tests, and so on. If a test fails, the failure information is fed back to the developers, or the AI is regenerated. While this model achieves a degree of automation, it suffers from two fundamental problems: 1. Insufficient verification depth: Traditional dynamic testing (such as unit testing) can only cover a limited number of execution paths and cannot exhaust all possible situations. For high-reliability fields such as finance, aviation, and healthcare, this sampling-based verification method cannot provide sufficient quality assurance and cannot detect advanced errors caused by complex state interactions.
[0004] 2. Inefficient and blind repair process: When a test fails, simply sending the entire error log to the AI often leads to extensive and unnecessary code modifications by the AI. It may even introduce a new bug while fixing an old one, resulting in ineffective repair and poor code reliability. Summary of the Invention
[0005] In view of the above problems, embodiments of the present invention provide a source code adaptive repair method and related equipment to solve the problems existing in the prior art.
[0006] According to one aspect of the present invention, an adaptive source code repair method is provided, the method comprising: The source code generated by the AI code generation model is verified in multiple layers through a layered verification engine. These layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The model checking layer verifies whether all execution paths in the source code satisfy the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined based on the business operations of the target system, expressed using temporal logic, and constrained to be satisfied by the target system on all execution paths. If any execution path does not satisfy the system-level attribute, a specific execution path that does not satisfy the system-level attribute is generated as a counterexample. A first repair instruction is generated based on the counterexample and sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. If the verification of any layer other than the model checking layer in the multi-layer structure fails, a structured verification report is generated, a second repair instruction is generated based on the verification report, and the second repair instruction is sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. After repairing the source code, the repaired source code will undergo multi-level in-depth verification until it passes all multi-level in-depth verification in one go. The source code that passes all multi-level in-depth verification in one go will be output as qualified source code.
[0007] In one alternative approach, the layered verification engine performs multi-layered, in-depth verification of the source code generated by the AI code generation model, including: The source code is subjected to the verification of the syntax checking layer, which includes compiling or parsing the source code to check for code structure and semantic errors; After the syntax checking layer passes the verification, the contract testing layer verifies the source code, including verifying whether the source code meets the predefined specifications. After the contract testing layer verification passes, the static security layer verification is performed on the source code. The static security layer verification includes scanning the source code using a predetermined static analysis tool to find standard-defined security vulnerabilities. After the static security layer verification passes, the dynamic test layer verification is performed on the source code. The dynamic test layer verification includes automatically generating and executing a large number of test cases to test the robustness of the source code. After the dynamic testing layer passes the verification, the model checking layer is used to verify the source code.
[0008] In an alternative approach, the predefined specification further includes: Define the business operations of the target system, specify the preconditions and postconditions for each business operation, and define the data model of the target system and the invariants attached to the data model; The verification of the contract testing layer further includes: obtaining the preconditions, the postconditions, and the invariants; automatically generating diverse input data that satisfies the preconditions through a constraint solver or a data generation library; executing the corresponding function under test based on the input data; and checking whether the return value and system state satisfy the postconditions and the invariants.
[0009] In one alternative approach, the first repair instruction and the second repair instruction include a minimum difference repair strategy, which instructs the source code to be repaired with minimal code changes to preserve the already verified portions of the source code.
[0010] In one alternative approach, generating the first repair instruction based on the counterexample includes: Convert the state transition sequence in the counterexample into a natural language description of the violation path. Extract the source code location and related variables involved in the description of the violation path, and assemble the description of the violation path, source code location, related variables and minimum difference repair strategy into the first repair instruction according to the predefined repair instruction template.
[0011] In an alternative approach, the validation of the model checking layer further includes: The behavior of the source code is abstracted into a finite state model; The model checking algorithm exhaustively checks whether all execution paths of the finite state model satisfy the system-level properties of the target system.
[0012] In one alternative approach, the verification report includes a layer identifier, the reason for the verification failure, the problem code, and the problem code location information; the second repair instruction includes the reason for the verification failure, the problem code, a reference to security specifications, and guidance on repair strategies.
[0013] According to another aspect of the present invention, an adaptive source code repair apparatus is provided, the apparatus comprising: The verification module is used to perform multi-layered and in-depth verification of the source code generated by the AI code generation model through a layered verification engine. The layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The verification of the model checking layer includes verifying whether all execution paths in the source code meet the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined according to the business operations of the target system, expressed using temporal logic, and constrained by the target system in all execution paths. The first generation module is used to generate a specific execution path that does not meet the system-level attribute as a counterexample if there is an execution path that does not meet the system-level attribute, generate a first repair instruction based on the counterexample, and send the first repair instruction to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. The second generation module is used to generate a structured verification report if the verification of any layer other than the model checking layer in the multi-layer structure fails, generate a second repair instruction based on the verification report, and send the second repair instruction to the artificial intelligence code generation model so that the artificial intelligence code generation model can repair the source code. The output module is used to perform multi-level in-depth verification on the repaired source code after it has been repaired, until it passes the multi-level in-depth verification in one go, and output the source code that passes the multi-level in-depth verification in one go as qualified source code.
[0014] According to another aspect of the present invention, a computer device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform the method described above.
[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method described above.
[0016] This invention employs a layered verification engine to perform multi-layered, in-depth verification of the source code generated by an AI code generation model. The last layer of each layer is a model checking layer. If an execution path does not meet system-level attributes, a specific execution path indicating the non-compliance is generated as a counterexample, and a first repair instruction is generated based on this counterexample. If any layer other than the model checking layer fails verification, a structured verification report is generated, and a second repair instruction is generated based on the verification report. The first and second repair instructions are used by the AI code generation model to repair the source code. After repairing the source code, the repaired source code undergoes further multi-layered, in-depth verification until it passes verification on the first attempt. The verified source code is then output as qualified source code. Unlike traditional generation and testing models, source code verification is a sequential process from shallow to deep. Simple errors are quickly discovered and fixed in the early stages. High-quality code that has passed each layer of verification enters the model inspection layer verification stage, which can cover all execution paths as much as possible and exhaust all possible situations, greatly improving efficiency and reliability. In addition, when any layer of verification fails, it can automatically generate repair instructions based on the failure feedback, guiding the AI to self-correct, forming an adaptive closed loop of generation, verification, and repair. This overcomes the fundamental defects of current AI code generation technologies, such as the generation being the end, lack of strict quality assurance, and lack of self-correction capabilities, and provides a guarantee for the development of highly reliable and secure software systems.
[0017] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the source code adaptive repair method provided in an embodiment of the present invention is shown; Figure 2 As shown Figure 1 The diagram shows a multi-layered, in-depth verification structure. Figure 3 A schematic diagram of the source code adaptive repair device provided in an embodiment of the present invention is shown; Figure 4 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation
[0019] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.
[0020] Figure 1 A flowchart of the source code adaptive repair method provided in an embodiment of the present invention is shown, as follows: Figure 1 As shown, the method includes the following steps: Step 10: Perform multi-layered and in-depth verification of the source code generated by the AI code generation model through a layered verification engine. The layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The verification of the model checking layer includes verifying whether all execution paths in the source code meet the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined based on the business operations of the target system, expressed using temporal logic, and constrained to be met by the target system on all execution paths.
[0021] The target system refers to the software system to be developed. The source code of the target system is generated by calling an artificial intelligence code generation model. After the source code is generated, in order to improve the reliability of the source code generated by AI, a layered verification engine is used to perform multi-layered and in-depth verification of the source code. The layered verification engine contains multiple layers organized in a specific order with verification capabilities from shallow to deep. It is used to perform sequential and multi-dimensional automated verification of the generated source code, including a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer.
[0022] The final layer of the layered verification engine is the model checking layer. The model checking layer verifies whether all execution paths in the source code satisfy the system-level attributes of the target system corresponding to the source code. These system-level attributes are predefined based on the business operations of the target system, expressed using temporal logic, and specify the security and compliance attributes that the target system must satisfy on all execution paths. An execution path can be a sequence of transitions from one state to another during the operation of the target system. For example, in a payment transaction, the states sequentially include pending payment, payment in progress, payment successful, and payment failed. The path from pending payment to payment in progress is one execution path, and the paths from payment in progress to payment successful or payment failed are two other execution paths. Temporal logic focuses on the relationships and patterns of events and states in a time sequence. It allows the use of temporal logic languages to express complex regulatory rules involving time order in the target system. For example, a pending payment must be made within ten minutes. System-level attributes can include temporal logic formulas, which support global operators G, final operators F, next-state operators X, until-the-end operators U, and recursive combinations of implied operators. For example, for payment transactions, system-level attributes can be expressed as: G(payment.initiated->F(payment.completed|payment.failed)), which means globally, once a payment is initiated, it must eventually reach either a payment completed or payment failed state.
[0023] The verification of the model checking layer further includes: The behavior of the source code is abstracted into a finite state model; The model checking algorithm exhaustively checks whether all execution paths of the finite state model satisfy the system-level properties of the target system.
[0024] Among them, the finite state model is a mathematical model that describes the transitions of a target system between different states. It clarifies what states the target system has, under what conditions state changes are triggered, and what the target system does after state changes.
[0025] Abstracting the behavior of source code into a finite state model includes: Analyze the variables related to the target system's entities in the source code (such as Order.status, Account.balance, etc.), identify all assignment statements and conditional branches that affect these variables; enumerate the combinations of these variable values into a set of states, where each state corresponds to a specific set of variable values; extract the function call paths and conditional branch logic that change these variables into state transition relationships, with each transition corresponding to a triggering event and its resulting state change; map atomic propositions in system-level attributes (such as order.status==FILLED) to labeled functions on the states, thereby constructing a complete finite state model. The finite state model includes all possible behavioral information from the source code, including the set of states, state transition relationships (describing how a state changes to another state), and labeled functions associated with the set of atomic propositions for each state. For example, the `status` field of the `Order` entity has a value space of {NEW, PARTIALLY_FILLED, FILLED, CANCELLED}, with each value constituting a dimension of the state set; modifications to the `filled_quantity` of the `match_orders` trading pair constitute state transitions; and the logical conditions in the `status_consistency` invariant are mapped to atomic propositions on each state. A finite-state model is a standardized, formalized behavioral model that translates complex software systems into mathematically readable and analytically valid models for verification tools, enabling automated conversion of machine-executable mathematical verification. In this embodiment, the purpose of generating the finite-state model is to provide input for automated verification of source code. AI-generated source code is a concrete program, while verification tools need to process abstract mathematical models. Therefore, the finite-state model is a crucial bridge connecting source code and verification theory.
[0026] Furthermore, to address the state space explosion problem, this embodiment introduces the following optimization mechanism during the construction of the finite state model: when the size of the state set exceeds a preset state threshold, the CEGAR method of abstract refinement guided by counterexamples is used to reduce the state space of the finite state model. Specifically, firstly, a coarse-grained abstract model of the source code is constructed, and the abstract model is checked; if a counterexample is found, it is checked whether the counterexample is a false counterexample (i.e., unreachable in the concrete model); if it is a false counterexample, the abstract model is refined based on the counterexample, adding necessary state distinctions, and then the check is repeated; this process is iterated until a true counterexample is found or the system-level property is proven to be true. In addition, partial order reduction techniques can be combined to reduce the exploration of equivalent cross-execution sequences in concurrent systems, further reducing the state space.
[0027] Model checking algorithms (such as SPIN and NuSMV) are used to exhaustively explore all execution paths of the finite state model and check whether system-level properties hold true in all execution paths.
[0028] This embodiment exhaustively explores the finite state model to prove whether the behavior of the generated source code strictly satisfies the system-level properties under all possible execution paths. If the multi-layered verification passes, the source code can be output as qualified; if the multi-layered verification fails, such as the model check layer verification, the source code is unqualified.
[0029] Furthermore, a layered verification engine is used to perform multi-layered, in-depth verification of the source code generated by the AI code generation model, including: The source code is subjected to the verification of the syntax checking layer, which includes compiling or parsing the source code to check for code structure and semantic errors; After the syntax checking layer passes the verification, the contract testing layer verifies the source code, including verifying whether the source code meets the predefined specifications. After the contract testing layer verification passes, the static security layer verification is performed on the source code. The static security layer verification includes scanning the source code using a predetermined static analysis tool to find standard-defined security vulnerabilities. After the static security layer verification passes, the dynamic test layer verification is performed on the source code. The dynamic test layer verification includes automatically generating and executing a large number of test cases to test the robustness of the source code. After the dynamic testing layer passes the verification, the model checking layer is used to verify the source code.
[0030] Among them, such as Figure 2 As shown, the multi-layered validation, arranged from shallowest to deepest, includes a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. First, the source code is checked for structural and semantic errors to ensure it conforms to the programming language's syntax rules, such as missing semicolons, mismatched parentheses, and spelling errors. Then, the types of variables, expressions, and function calls are checked for consistency. If the source code is syntactically correct and types match, the syntax checking layer passes; otherwise, it fails.
[0031] Then, the contract testing layer is validated. The specifications of the target system are predefined, and the source code is verified to meet these specifications. Specifically, the source code adaptive repair method further includes: The business operations of the target system are defined as the preconditions and postconditions corresponding to each business operation specification. The data model of the target system and the invariants attached to the data model are also defined. The preconditions, postconditions, and invariants are specifications. The contract testing layer verification further includes: acquiring the preconditions, postconditions, and invariants; automatically generating diverse input data that satisfies the preconditions using a constraint solver or data generation library; wherein the constraint solver, based on the constraint expressions in the preconditions, uses satisfiability modular theory to solve for multiple sets of input values that satisfy the constraints, supplemented by boundary value analysis and equivalence class partitioning strategies to enhance the diversity of input data; executing the corresponding function under test based on the input data (the function under test is the corresponding function in the source code); and checking whether the return value and system state satisfy the postconditions and invariants. If the postconditions and invariants are satisfied, the contract testing layer verification passes; otherwise, the verification fails.
[0032] Next, a static security layer verification is performed. This involves using static analysis tools to analyze the source code structure and data flow without running the source code, in order to find common security vulnerabilities. If no vulnerabilities are found, the static security layer verification passes; otherwise, it fails.
[0033] Next, the dynamic testing layer is validated, automatically generating and executing a large number of test cases, especially for boundary values and abnormal inputs, and performing stress tests to test the robustness of the source code. If no new crashes or exceptions are found, the dynamic testing layer validation passes; otherwise, it fails.
[0034] Step 20: If any execution path does not satisfy the system-level attribute, a specific execution path that does not satisfy the system-level attribute is generated as a counterexample. A first repair instruction is generated based on the counterexample and sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code.
[0035] In the model checking layer verification process, if a violation of system-level properties is found on any possible execution path, a counterexample is generated. The counterexample is a specific execution path that precisely shows the execution path from the initial state, through which state transitions ultimately led to the violation of the system-level properties—that is, how the violation occurred. This embodiment can use this counterexample to automatically generate a highly targeted first repair instruction and feed it back to the AI code generation model, guiding it to self-correct the source code so that all system-level properties are satisfied, thus forming an automated closed-loop repair mechanism. When verification fails, this embodiment can not only point out the error but also precisely locate the specific path where the error occurred, providing direct input for subsequent closed-loop repair.
[0036] Further, based on the counterexample, a first repair instruction is generated, including: Convert the state transition sequence in the counterexample into a natural language description of the violation path. Extract the source code location (such as file name, line number) and related variables involved in the violation path description, and assemble the violation path description, source code location, related variables and minimum difference repair strategy into the first repair instruction according to the predefined repair instruction template.
[0037] The structure of the repair instruction template is as follows: "[Problem Type]: A violation of [Attribute Name] was detected on line [Line Number] of [File Name], violation path: [State Sequence Description], involved variables: [Variable List], repair strategy: repair the above problem with minimal code changes, retaining the verified code." This repair instruction is sent to the AI model to guide it to self-correct the source code.
[0038] Step 30: If the verification of any layer other than the model checking layer in the multi-layer structure fails, a structured verification report is generated, a second repair instruction is generated based on the verification report, and the second repair instruction is sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code.
[0039] If any layer in the multi-layered system, excluding the model checking layer, fails verification (e.g., the syntax checking layer, contract testing layer, static security layer, or dynamic testing layer fails verification), a structured verification report is generated. The verification report includes the layer identifier of the layer that failed verification, the reason for the failure, the problematic code (e.g., a vulnerable code snippet or a test case that triggered the exception), and the location information of the problematic code (e.g., file name, line number, column number). Based on the verification report, a second repair instruction is generated. The second repair instruction includes the problematic code, a reference to security specifications, an error description, and guidance on repair strategies. The second repair instruction is sent to the AI code generation model, which repairs the source code, thus forming an adaptive closed loop of generation, verification, and repair.
[0040] Furthermore, the first repair instruction and the second repair instruction include a minimum difference repair strategy, which instructs to repair the source code with minimal code changes, that is, to repair only the problematic code, so as to retain the parts of the source code that have been verified, thereby achieving efficient automatic correction of code defects and reducing the risk of introducing new defects.
[0041] Step 40: After repairing the source code, perform multi-level in-depth verification on the repaired source code until it passes the multi-level in-depth verification in one go, and output the source code that passes the multi-level in-depth verification in one go as qualified source code.
[0042] After the source code is repaired in any instance of this embodiment, multi-level in-depth verification is performed again, that is, starting from the syntax check layer, and then passing through the verification of the contract test layer, static security layer, dynamic test layer, and model check layer. If the number of repair iterations does not exceed the preset threshold, continuous iteration is performed until the multi-level in-depth verification is passed at one time. If the multi-level in-depth verification is passed at one time, the source code is qualified. If the number of repair iterations reaches the preset threshold (for example, 10 times) and the verification is still not passed, the source code with a verification failure mark and the cumulative verification report are output. The cumulative verification report includes the verification failure layer identifier, failure reason, code differences before and after repair, and verification results of each layer for each iteration, etc.
[0043] In the embodiment of the present invention, a multi-level in-depth verification is performed on the source code generated by the artificial intelligence code generation model through a hierarchical verification engine. The last layer of the multi-level is the model check layer; if there is an execution path that does not meet the system-level attributes, a specific execution path indicating that the system-level attributes are not met is generated as a counterexample, and a first repair instruction is generated based on the counterexample; if the verification fails in any layer other than the model check layer in the multi-level, a structured verification report is generated, and a second repair instruction is generated based on the verification report. The first and second repair instructions are used for the artificial intelligence code generation model to repair the source code; after the source code is repaired, the repaired source code is subjected to multi-level in-depth verification again until the verification is passed at one time, and the source code that passes the verification is output as qualified source code. Different from the traditional generation and testing mode, the source code verification in the embodiment of the present invention is a sequential process from shallow to deep. Simple errors are quickly discovered and repaired in the early stage, and high-quality code that has passed layer-by-layer verification in the later stage enters the model check layer verification stage, which can cover all execution paths as much as possible and exhaust all possible situations. It is particularly suitable for high-reliability fields such as finance, aviation, and healthcare with many interactions and complex states, greatly improving the efficiency and reliability. In addition, when the verification fails in any layer, a repair instruction can be automatically generated based on the failure feedback to guide the AI to perform self-correction, forming an adaptive closed loop of generation, verification, and repair, overcoming the fundamental defects of the current AI code generation technology that generally ends with generation, lacks strict quality assurance, and self-correction ability, and providing a guarantee for developing high-reliability and high-security software systems.
[0044] Exemplarily, taking the target system as a dark pool trading system, the system-level attribute of "price improvement" is predefined, and the data invariant of the Order entity ("order.quantity>0") and the pre- and post-conditions of the "matchOrder" function are also defined.
[0045] AI-generated source code: The AI code generation model generated version 1 of the source code for "matching_engine.py".
[0046] 1. Syntax checking layer L1 validation and repair: The v1 code is first submitted to the L1 validation layer: Validation: The syntax checking layer L1 found a spelling error in the source code (e.g., "qunatity", the correct word should be "quantity"), and the validation failed.
[0047] Fix: Analysis revealed a simple syntax error, generating the fix instruction: "Identifier "qunatity" is not defined. Did you mean "quantity"?". This instruction was sent to the AI code generation model, which corrected the spelling error and generated version 2 code.
[0048] The multi-layered, in-depth verification process restarted, and the v2 version code was submitted to the syntax checking layer L1, where it was found to be grammatically correct.
[0049] 2. Contract testing layer L2 verification and fix: Submit the v2 version code to the contract testing layer L2 first. The contract validator in the L2 contract testing layer (a property-based testing tool) begins working, automatically generating a large number of random "Order" objects to call the "matchOrder" function. During the test, an order with a quantity of -100 is generated, violating the data invariant "order.quantity>0" in the specification, causing the L2 contract testing layer validation to fail.
[0050] The code generation tooltip reads: "The 'matchOrder' function failed to handle an illegal input where 'quantity' is negative. Please add a check for 'order.quantity' at the function entry point; if it is less than or equal to 0, throw an exception." Upon receiving the tooltip, the AI code generation model added input validation logic at the beginning of the function and generated version 3 code.
[0051] The multi-layered, in-depth verification process was restarted, and the v3 version code was submitted to the syntax checking layer L1 and the contract testing layer L2 for verification, both of which passed.
[0052] 3. Static security layer L3 verification and fix: Submit the verified v3 version code to the static security layer L3. Verification: The static application security testing tool SAST scans the v3 version code. If it finds that user input is directly concatenated into the log string when implementing a certain logging function, thus constituting a "log injection" vulnerability, then the static security layer L3 verification fails.
[0053] Remediation: Generate a verification report (including vulnerability type, file name, line number 100, dangerous code snippets, etc.), and generate a remediation instruction: "A log injection vulnerability was detected on line 100 of the file 'matching_engine.py'. Please use parameterized logging or perform strict cleanup of user input. Do not directly concatenate the data." The AI code generation model receives the remediation instruction, modifies the logging code, uses a secure logging framework, and generates v4 version code.
[0054] The multi-layered, in-depth verification process was restarted. The v4 version code was verified starting from L1 and successfully passed the L1, L2, and L3 verifications.
[0055] 4. Dynamic Testing Layer (L4) and Model Checking Layer (L5) Validation and Repair: The v4 version code was submitted to the Dynamic Testing Layer (L4) for validation. Extensive stress testing was performed on the source code, and no new crashes or exceptions were found. Dynamic Testing Layer (L4) validation passed. Finally, the code entered the most stringent Model Checking Layer (L5) for validation.
[0056] Validation: Convert the behavior of the v4 version code into a finite state model and use the "price improvement" system-level property to validate the finite state model. Assume that there is a concurrency flaw in the v4 version code: in a multi-threaded environment, when one thread is updating the median price, another thread may read an outdated median price to perform a matching, causing the "price improvement" system-level property to be violated at a certain execution sequence.
[0057] The model's L5 checking layer detected this illegal path, thus the verification failed, and a counterexample was output, accurately describing this timing problem: (1) Thread A reads the median price as 10.00; (2) Thread B updates the median price to 9.98; (3) Thread A uses the outdated mid-price of 10.00 to match a buy order at a price of 10.00, while the fair price should be 9.98, which violates the "price improvement" principle.
[0058] After capturing this counterexample, a fix instruction was generated: "There is a race condition between reading the median price and performing the matching operation. The matchOrder function needs to be protected to ensure the atomicity of the operation. Please use a threading.Lock to fix this."
[0059] This fix instruction was sent to the AI code generation model, which generated the corrected v5 version code, adding a locking mechanism to the matchOrder function in the v5 version code.
[0060] The multi-layered, in-depth verification process restarted, with the v5 code undergoing verification starting from L1. It successfully passed verifications at L1, L2, L3, and L4. Due to the presence of locks, the model inspection layer L5 could not find any execution paths violating the "price improvement" rule, thus the verification passed. The final output was a verified and fixed v5 code version that met compliance and security requirements.
[0061] As can be seen from this example, this embodiment guides the artificial intelligence code generation model to produce a software system that meets compliance and security requirements and has high reliability requirements through rigorous verification and precise feedback and repair.
[0062] Figure 3 A schematic diagram of the source code adaptive repair device according to an embodiment of the present invention is shown. Figure 3 As shown, the device includes: The verification module 301 is used to perform multi-layered and in-depth verification of the source code generated by the artificial intelligence code generation model through a layered verification engine. The multi-layered verification includes a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The verification of the model checking layer includes verifying whether all execution paths in the source code meet the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined according to the business operations of the target system, expressed using temporal logic, and constrained by the target system in all execution paths. The first generation module 302 is used to generate a specific execution path that does not meet the system-level attribute as a counterexample if there is an execution path that does not meet the system-level attribute, generate a first repair instruction based on the counterexample, and send the first repair instruction to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. The second generation module 303 is used to generate a structured verification report if the verification of any layer other than the model checking layer in the multi-layer is failed, generate a second repair instruction based on the verification report, and send the second repair instruction to the artificial intelligence code generation model so that the artificial intelligence code generation model can repair the source code. The output module 304 is used to perform multi-level in-depth verification on the repaired source code after repairing it, until it passes the multi-level in-depth verification in one go, and output the source code that passes the multi-level in-depth verification in one go as qualified source code.
[0063] The embodiments of the source code adaptive repair device are basically the same as those of the above-described source code adaptive repair method, and can be referred to the above embodiments.
[0064] Figure 4 The diagram shows a structural schematic of an embodiment of the computer device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computer device.
[0065] like Figure 4 As shown, the computer device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.
[0066] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other computer devices, such as clients or other server network elements. The processor 402 executes program 410, specifically performing the relevant steps described above in the computer device embodiment.
[0067] Specifically, program 410 may include program code, which includes computer-executable instructions.
[0068] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.
[0069] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0070] Specifically, program 410 can be called by processor 402 to cause the computer device to perform the following operations: The source code generated by the AI code generation model is verified in multiple layers through a layered verification engine. These layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The model checking layer verifies whether all execution paths in the source code satisfy the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined based on the business operations of the target system, expressed using temporal logic, and constrained to be satisfied by the target system on all execution paths. If any execution path does not satisfy the system-level attribute, a specific execution path that does not satisfy the system-level attribute is generated as a counterexample. A first repair instruction is generated based on the counterexample and sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. If the verification of any layer other than the model checking layer in the multi-layer structure fails, a structured verification report is generated, a second repair instruction is generated based on the verification report, and the second repair instruction is sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. After repairing the source code, the repaired source code will undergo multi-level in-depth verification until it passes all multi-level in-depth verification in one go. The source code that passes all multi-level in-depth verification in one go will be output as qualified source code.
[0071] In one alternative approach, the layered verification engine performs multi-layered, in-depth verification of the source code generated by the AI code generation model, including: The source code is subjected to the verification of the syntax checking layer, which includes compiling or parsing the source code to check for code structure and semantic errors; After the syntax checking layer passes the verification, the contract testing layer verifies the source code, including verifying whether the source code meets the predefined specifications. After the contract testing layer verification passes, the static security layer verification is performed on the source code. The static security layer verification includes scanning the source code using a predetermined static analysis tool to find standard-defined security vulnerabilities. After the static security layer verification passes, the dynamic test layer verification is performed on the source code. The dynamic test layer verification includes automatically generating and executing a large number of test cases to test the robustness of the source code. After the dynamic testing layer passes the verification, the model checking layer is used to verify the source code.
[0072] In an alternative approach, the predefined specification further includes: Define the business operations of the target system, specify the preconditions and postconditions for each business operation, and define the data model of the target system and the invariants attached to the data model; The verification of the contract testing layer further includes: obtaining the preconditions, the postconditions, and the invariants; automatically generating diverse input data that satisfies the preconditions through a constraint solver or a data generation library; executing the corresponding function under test based on the input data; and checking whether the return value and system state satisfy the postconditions and the invariants.
[0073] In one alternative approach, the first repair instruction and the second repair instruction include a minimum difference repair strategy, which instructs the source code to be repaired with minimal code changes to preserve the already verified portions of the source code.
[0074] In one alternative approach, generating the first repair instruction based on the counterexample includes: Convert the state transition sequence in the counterexample into a natural language description of the violation path. Extract the source code location and related variables involved in the description of the violation path, and assemble the description of the violation path, source code location, related variables and minimum difference repair strategy into the first repair instruction according to the predefined repair instruction template.
[0075] In an alternative approach, the validation of the model checking layer further includes: The behavior of the source code is abstracted into a finite state model; The model checking algorithm exhaustively checks whether all execution paths of the finite state model satisfy the system-level properties of the target system.
[0076] In one alternative approach, the verification report includes a layer identifier, the reason for the verification failure, the problem code, and the problem code location information; the second repair instruction includes the reason for the verification failure, the problem code, a reference to security specifications, and guidance on repair strategies.
[0077] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on a computer device, causes the computer device to perform any of the above-described method embodiments.
[0078] This invention provides a computer program that can be invoked by a processor to cause a computer device to execute any of the above-described method embodiments.
[0079] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform any of the above-described method embodiments.
[0080] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages is for the purpose of disclosing the best mode of implementation of the invention.
[0081] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0082] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.
[0083] Those skilled in the art will understand that modules in the computer device of the embodiments can be adaptively modified and placed in one or more computer devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or computer device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.
[0084] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.
Claims
1. A source code adaptive repair method, characterized in that, The method includes: The source code generated by the AI code generation model is verified in multiple layers through a layered verification engine. These layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The model checking layer verifies whether all execution paths in the source code satisfy the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined based on the business operations of the target system, expressed using temporal logic, and constrained to be satisfied by the target system on all execution paths. If any execution path does not satisfy the system-level attribute, a specific execution path that does not satisfy the system-level attribute is generated as a counterexample. A first repair instruction is generated based on the counterexample and sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. If the verification of any layer other than the model checking layer in the multi-layer structure fails, a structured verification report is generated, a second repair instruction is generated based on the verification report, and the second repair instruction is sent to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. After repairing the source code, the repaired source code will undergo multi-level in-depth verification until it passes all multi-level in-depth verification in one go. The source code that passes all multi-level in-depth verification in one go will be output as qualified source code.
2. The method according to claim 1, characterized in that, The process of performing multi-layered and in-depth verification of the source code generated by the AI code generation model using a layered verification engine includes: The source code is subjected to the verification of the syntax checking layer, which includes compiling or parsing the source code to check for code structure and semantic errors; After the syntax checking layer passes the verification, the contract testing layer verifies the source code, including verifying whether the source code meets the predefined specifications. After the contract testing layer verification passes, the static security layer verification is performed on the source code. The static security layer verification includes scanning the source code using a predetermined static analysis tool to find security vulnerabilities defined by the standard. After the static security layer verification passes, the dynamic test layer verification is performed on the source code. The dynamic test layer verification includes automatically generating and executing a large number of test cases to test the robustness of the source code. After the dynamic testing layer passes the verification, the model checking layer is used to verify the source code.
3. The method according to claim 2, characterized in that, The predefined specifications include: Define the business operations of the target system, specify the preconditions and postconditions for each business operation, and define the data model of the target system and the invariants attached to the data model; The verification of the contract testing layer further includes: obtaining the preconditions, the postconditions, and the invariants; automatically generating diverse input data that satisfies the preconditions through a constraint solver or a data generation library; executing the corresponding function under test based on the input data; and checking whether the return value and system state satisfy the postconditions and the invariants.
4. The method according to claim 1, characterized in that, The first repair instruction and the second repair instruction include a minimum difference repair strategy, which instructs to repair the source code with minimal code changes to preserve the parts of the source code that have already been verified.
5. The method according to claim 4, characterized in that, The generation of the first repair instruction based on the counterexample includes: Convert the state transition sequence in the counterexample into a natural language description of the violation path. Extract the source code location and related variables involved in the description of the violation path, and assemble the description of the violation path, source code location, related variables and minimum difference repair strategy into the first repair instruction according to the predefined repair instruction template.
6. The method according to claim 1, characterized in that, The validation of the model checking layer further includes: The behavior of the source code is abstracted into a finite state model; The model checking algorithm exhaustively checks whether all execution paths of the finite state model satisfy the system-level properties of the target system.
7. The method according to claim 1, characterized in that, The verification report includes the layer identifier, the reason for the verification failure, the problem code, and the problem code location information; the second repair instruction includes the reason for the verification failure, the problem code, the security specification reference, and the repair strategy guidance.
8. A source code adaptive repair device, characterized in that, The device includes: The verification module is used to perform multi-layered and in-depth verification of the source code generated by the AI code generation model through a layered verification engine. The layers include a syntax checking layer, a contract testing layer, a static security layer, a dynamic testing layer, and a model checking layer. The verification of the model checking layer includes verifying whether all execution paths in the source code meet the system-level attributes of the target system corresponding to the source code. The system-level attributes are security and compliance attributes that are predefined according to the business operations of the target system, expressed using temporal logic, and constrained by the target system in all execution paths. The first generation module is used to generate a specific execution path that does not meet the system-level attribute as a counterexample if there is an execution path that does not meet the system-level attribute, generate a first repair instruction based on the counterexample, and send the first repair instruction to the artificial intelligence code generation model for the artificial intelligence code generation model to repair the source code. The second generation module is used to generate a structured verification report if the verification of any layer other than the model checking layer in the multi-layer structure fails, generate a second repair instruction based on the verification report, and send the second repair instruction to the artificial intelligence code generation model so that the artificial intelligence code generation model can repair the source code. The output module is used to perform multi-level in-depth verification on the repaired source code after it has been repaired, until it passes the multi-level in-depth verification in one go, and output the source code that passes the multi-level in-depth verification in one go as qualified source code.
9. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method as described in any one of claims 1-7.