An ai programming exception repair method based on multi-source engineering feedback

Abstract

This invention relates to the field of AI programming technology, specifically to an AI programming anomaly repair method based on multi-source engineering feedback. The method includes: constructing test cases for AI-generated code and conducting tests, then collecting test data to generate a feedback set; extracting features from the feedback set and classifying them to generate anomaly categories and scores; determining corresponding target actions based on the anomaly classifications; and controlling the AI ​​programming assistance system to generate a repair scheme based on the target actions. Addressing the problem of ineffective repairs during code verification and repair in existing AI programming schemes, this method extracts features from and classifies the test feedback set to determine the anomaly categories in the code, selects target actions for repair, and further generates a repair scheme. During multiple rounds of repair, corresponding correction information is selectively generated based on the selected target actions to adjust the target actions and avoid ineffective repairs.

Description

Technical Field

[0001] This invention relates to the field of AI programming technology, and specifically to a method for repairing AI programming anomalies based on multi-source engineering feedback. Background Technology

[0002] AI-assisted programming typically refers to programming methods based on large language models. By providing relevant code, program logic, and algorithms as prompts, it interacts with the large language model in a text-based manner. This allows the model to understand the business logic and, combined with relevant variables and API definitions, directly generate corresponding code snippets, thereby improving development efficiency. In practical applications, AI programming is also used in various stages of development, including business code generation, code inspection, test case generation, and test report analysis.

[0003] For example, patent application CN202511434263.8 discloses an AI-driven method and apparatus for automatically generating front-end components for low-code platforms. This method significantly lowers the barrier to entry for low-code platforms by supporting the automatic generation of front-end components from natural language, achieving a high degree of intelligence. Combined with AST verification and template completion mechanisms, the generated components are syntactically correct and logically complete, ensuring code reliability. At the same time, runtime monitoring and dynamic optimization are introduced, enabling components to maintain efficient rendering even in large-scale data scenarios. With the help of feedback mechanisms, the generation quality can be continuously improved, achieving self-learning and personalized customization, thus possessing continuous evolution capabilities. In addition, it has wide applicability and can be applied in various scenarios such as low-code platforms, front-end development IDEs, and intelligent programming assistants.

[0004] For example, patent application CN202510455171.1 discloses a model-based code generation method to improve code generation efficiency, relating to the field of Artificial Intelligence (AI) technology. Given a requirements document, an AI model analyzes the business processes within the document and represents them using a state machine. This enables an interactive interface that represents the business processes based on states, and interactive actions that represent the business processes based on events that trigger state transitions. The AI ​​model further analyzes the state machine representation to automatically generate code, eliminating the need for manual coding and improving efficiency. Furthermore, leveraging the AI ​​model's language understanding capabilities, complex business processes are first converted into concise and structurally simple state machine representations, which are then converted into code. This multi-step decomposition of complex tasks allows the AI ​​model to more accurately understand the actual business processes during code generation, resulting in more accurate code.

[0005] However, in actual implementation, the inventors found that such technical solutions usually process the build output, test failure information, dependency resolution results and interface signature comparison results separately, and usually only perform local repairs based on a single error message or a single failure phenomenon. This leads to low repair efficiency and easily causes the problem of invalid code stacking. Summary of the Invention

[0006] To address the aforementioned problems in existing technologies, a method for repairing AI programming anomalies based on multi-source engineering feedback is provided.

[0007] The specific technical solution is as follows: An AI programming anomaly repair method based on multi-source engineering feedback includes: Step S1: For each round of AI-generated code output by the AI ​​programming assistance system, construct test cases and conduct tests, then collect test data to generate a feedback set; Step S2: Extract features from the feedback set and classify them to generate anomaly classification and anomaly score; Step S3: Determine the corresponding target action based on the anomaly classification; Step S4: Control the AI ​​programming assistance system to generate a repair plan based on the target action, and then use the repair plan as the AI ​​generated code for this round, and return to step S1 until the repair is completed; Furthermore, during the execution of step S4, multiple rounds of error messages are also evaluated, and corrective information is generated to adjust the target action in the next round.

[0008] On the other hand, before the first execution of step S1, the following is also included: Step S01: Receive the defect repair task from the outside, extract the defect repair information and concatenate it with the prompt word template, and then input it into the AI ​​programming assistance system.

[0009] On the other hand, step S1 includes: Step S11: Extract test key points from the AI-generated code according to the preset extraction template, and automatically generate test cases for the test key points; The key test points include at least one of variables, APIs, and functions; Step S12: Test the constructed AI-generated code based on the test cases to obtain the test data; Step S13: Collect related information based on the test data and generate the feedback set; The associated information includes at least one of the following: build logs, error codes, test failure items, dependency resolution results, interface signature comparison results, and constraint verification results.

[0010] On the other hand, step S2 includes: Step S21: Perform structured processing on the feedback set and extract the corresponding abnormal features according to the extraction rules; Step S22: Match the abnormal features according to the classification rules to obtain the corresponding abnormal classification; Step S23: Calculate the matching degree for each of the anomaly categories and calculate the anomaly score by weighting the results; In step S23, the matching degree is composed of error code matching degree, log keyword matching degree, test failure correlation degree, interface difference matching degree, and historical repetition degree. Different anomaly classifications correspond to different weight combinations.

[0011] On the other hand, step S22 includes: Step S221: Match the abnormal features sequentially using each of the classification rules to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed to step S223; If not, output the anomaly classification corresponding to the hit rule, and then proceed to step S23; Step S223: Determine the highest priority hit rule according to the priority of the hit rules, and output the anomaly classification corresponding to the highest priority hit rule, and then proceed to step S23.

[0012] On the other hand, step S22 includes: Step S221: Match the abnormal features sequentially using each of the classification rules to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed with the rule-based judgment process; If not, directly output the anomaly classification corresponding to the hit rule, and then proceed to step S23; The rule-based discrimination process includes: Step A231: For each of the above-mentioned hit rules corresponding to the above-mentioned anomaly classification, calculate the corresponding anomaly score respectively; Step A232: Sort the anomalies according to the anomaly scores, and use the anomaly category with the highest output score as the actual anomaly category.

[0013] On the other hand, during the execution of step A232, the score difference between the anomaly classification with the highest score and the second highest score is also calculated. When the score difference is less than a preset score difference threshold, the abnormality is classified as a composite abnormality.

[0014] On the other hand, step S3 includes: Step S31: Extract the corresponding action set and applicable conditions according to the anomaly category; Step S32: Extract the corresponding candidate repair actions from the action set according to the applicable conditions; Step S33: Calculate the corresponding action priority value for the candidate repair action, and select the target action for this round according to the action priority value.

[0015] On the other hand, the corrective information adjusts the selected target action by adding corresponding penalty and reward items for the target action.

[0016] On the other hand, step S4 includes: Step S41: Control the AI ​​programming assistance system to generate the repair plan based on the target action; Step S42: The repair scheme is judged in combination with multi-round cache information to generate error change relationship; Step S43: Determine whether the error reporting change relationship or the corresponding target action occurs multiple times; If so, generate the correction information and then return to step S1; If not, return to step S1.

[0017] The above technical solution has the following advantages or beneficial effects: To address the issue of ineffective code verification and repair in existing AI programming solutions, this paper proposes a new approach. By extracting and classifying features from the test feedback set, the paper identifies the anomaly categories within the code, selects target actions for repair, and generates a repair plan. During multiple rounds of repair, corresponding correction information is selectively generated based on the selected target actions to adjust them and prevent ineffective repairs. Attached Figure Description

[0018] Embodiments of the invention will be described more fully with reference to the accompanying drawings. However, the drawings are for illustration and explanation only and do not constitute a limitation on the scope of the invention.

[0019] Figure 1 This is an overall schematic diagram of an embodiment of the present invention; Figure 2 This is a schematic diagram of step S01 in an embodiment of the present invention; Figure 3 This is a schematic diagram of step S1 in an embodiment of the present invention; Figure 4This is a schematic diagram of step S2 in an embodiment of the present invention; Figure 5 This is a schematic diagram of step S22 in an embodiment of the present invention; Figure 6 This is a schematic diagram of step S22 in another embodiment of the present invention; Figure 7 This is a schematic diagram of the rule discrimination process in an embodiment of the present invention; Figure 8 This is a schematic diagram of step S3 in an embodiment of the present invention; Figure 9 This is a schematic diagram of step S4 in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0022] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0023] This invention includes: An AI programming anomaly repair method based on multi-source engineering feedback, such as Figure 1 As shown, it includes: Step S1: For each round of AI-generated code output by the AI ​​programming assistance system, construct test cases and conduct tests, then collect test data to generate a feedback set; Step S2: Extract features from the feedback set and classify them, and generate anomaly classifications and anomaly scores; Step S3: Determine the corresponding target action based on the anomaly classification; Step S4: Control the AI ​​programming assistance system to generate a repair plan based on the target action, then use the repair plan as the AI ​​generated code for this round, return to step S1, until the repair is completed; Furthermore, during the execution of step S4, multiple rounds of error messages are evaluated, and corrective information is generated to adjust the target action for the next round.

[0024] Specifically, addressing the issue of ineffective repairs during code verification and repair in existing AI programming solutions, this paper proposes a method that extracts and categorizes features from the test feedback set to identify anomaly categories in the code. Target actions for repair are then selected, and repair schemes are generated. During multiple rounds of repair, corresponding correction information is selectively generated based on the selected target actions to adjust them and avoid ineffective repairs.

[0025] In practice, the above-mentioned AI programming anomaly repair solution is mainly configured in the computer system as a software implementation, such as as a code repair proxy service, to work with the AI ​​programming assistance system to complete code generation and repair.

[0026] AI-assisted programming systems are code generation systems built on large-scale language models. They can predict and generate corresponding code snippets based on the information provided, including existing code, variable definitions, functions, API interfaces, user-input business logic or algorithm implementation logic, and prompt word template constraints. These snippets are then added to the corresponding positions in the code lines via IDE plugins.

[0027] For each round of AI-generated code output by the AI ​​programming assistance system, corresponding test cases are automatically written and expanded using the corresponding test case generation rules. Then, the tests are conducted, and various data generated during the test process, including error codes, are collected to generate a feedback set.

[0028] Then, features in the feedback set are extracted according to specific rules, and then matched with corresponding classification rules to generate corresponding anomaly classifications and anomaly scores to characterize the confidence of the anomaly classifications. Based on this, target actions for fixing the bugs detected in the test are extracted under the corresponding anomaly classifications, including adjusting variables, changing logical relationships, changing references, etc., and then input into the AI ​​programming assistance system in combination with prompt word templates for repair, and a new round of verification process is carried out.

[0029] During the multi-round verification process, the system also caches the records of multiple rounds of repair, and when the corresponding judgment conditions are met, such as the same anomaly recurring or the same target action recurring, the system generates and adds the corresponding correction information to adjust the target action selected in the next round of repair.

[0030] In one embodiment, such as Figure 2 As shown, the procedure before the first execution of step S1 also includes: Step S01: Receive the defect repair task from the outside, extract the defect repair information and concatenate it with the prompt word template, and then input it into the AI ​​programming assistance system.

[0031] Specifically, in practical applications, the system can receive defect repair tasks submitted externally. Defect repair tasks typically include fault-related information submitted by the user. By performing tag matching on the structured text, the aforementioned defect repair information is obtained, including specified code segments, fault reproduction information, fault description information, etc. It is then concatenated with pre-configured prompt word templates and input into the AI ​​programming assistance system.

[0032] At this point, the AI ​​programming assistance system will output the modified code. The corresponding code repair agent service will maintain the execution record of the current task. The execution record will include at least the task identifier, target module, task constraints, completion criteria, and historical repair records.

[0033] In one embodiment, such as Figure 4 As shown, step S1 includes: Step S11: Extract test key points from the AI-generated code according to the preset extraction template, and automatically generate test cases for the test key points; Key testing points include at least one of the following: variables, APIs, and functions; Step S12: Test the constructed AI-generated code based on test cases to obtain test data; Step S13: Collect relevant information based on the test data and generate a feedback set; The associated information includes at least one of the following: build logs, error codes, test failures, dependency resolution results, interface signature comparison results, and constraint verification results.

[0034] Specifically, for AI-generated code, test key points can be extracted in advance according to a preset extraction template, including at least one of variables, APIs, and functions, to identify potential fault points in the AI-generated code and generate test cases according to the corresponding process.

[0035] For example, regarding variable definition, test cases for each variable can be formed by generating different types of input variables and defining normal output boundaries, and a series of test cases can be obtained by expanding the key values ​​and corresponding output boundaries. For APIs, test cases can be formed by providing different types of input and output information and defining corresponding feedback actions. For function calls, corresponding function inputs and expected outputs can be generated, and corresponding test cases can be assembled.

[0036] The test cases mentioned above can be automatically generated and expanded by extracting key test points from the template and then feeding them into a large language model.

[0037] Then, test the AI-generated code based on test cases to obtain test data and collect related data, including build logs, error codes, test failures, dependency resolution results, interface signature comparison results, and constraint verification results. The above results are then combined into a feedback set for output.

[0038] In one embodiment, such as Figure 4 As shown, step S2 includes: Step S21: Perform structured processing on the feedback set and extract the corresponding abnormal features according to the extraction rules; Step S22: Match the abnormal features according to the classification rules to obtain the corresponding abnormal classification; Step S23: Calculate the matching degree for each anomaly category and calculate the anomaly score by weighting the results; In step S23, the matching degree consists of error code matching degree, log keyword matching degree, test failure correlation degree, interface difference matching degree, and historical repetition degree; Different anomaly classifications correspond to different weight combinations.

[0039] Specifically, to achieve better analysis results, in this embodiment, the original error information in the feedback set is first processed in a structured manner, including finding the corresponding content according to the corresponding tags, and then extracting the data of each category according to the extraction rules and storing them to obtain abnormal features, including construction features, test features, interface features, constraint features and historical repair features.

[0040] Among them, the build characteristics include at least compilation error codes, unresolved symbols, missing classes or methods, missing resource files, dependency version conflicts, and task execution stage identifiers; Test characteristics should include at least the name of the failed test case, the type of assertion failure, the keywords of the exception stack trace, the location of the failed module, and whether it is a regression failure. Interface characteristics include at least the following: differences in interface signature, differences in the number of parameters, differences in parameter types, missing field names, mismatched field types, and changes in return value structure. Constraint features must include at least static scan violation types, code style check failures, coverage failures, and performance threshold exceedances. Historical repair features include at least the repair action used in the previous round, the result status after the action was executed, the number of consecutive failed rounds, and the number of times the same type of error was repeated.

[0041] Then, the abnormal features are matched according to the preset classification rules to obtain the corresponding abnormal classification.

[0042] Preset rule examples include: When the build characteristics show missing dependency packages, unresolved external library symbols, dependency version conflicts, or missing dependencies in the build script, it is considered a dependency exception. When the interface features mismatch in the number of function parameters, mismatch in parameter types, missing field names, incorrect field mapping relationships, or inconsistent return value structures, it is determined to be an interface exception; When the build passes but an assertion fails, the business result does not meet expectations, or the logical branch enters an abnormal path, it is judged as a logical exception. When a constraint feature contains a static scan violation, a code style check failure, a coverage rate lower than the set threshold, or a performance metric exceeding the limit, it is judged as a constraint anomaly or a test coverage anomaly.

[0043] Finally, the matching degree is calculated for each anomaly category, and the anomaly score is obtained by weighting the results. For example: Anomaly category score = a × error code matching degree + b × log keyword matching degree + c × test failure correlation degree + d × interface difference matching degree + e × historical repetition degree, where a, b, c, d, and e are preset weights, and different categories correspond to different weight combinations.

[0044] For example, for interface anomalies, increase the weight of interface difference matching; for logic anomalies, increase the weight of test failure correlation.

[0045] In one embodiment, such as Figure 5 As shown, step S22 includes: Step S221: Match the abnormal features using each classification rule in turn to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed to step S223; If not, output the exception classification corresponding to the hit rule, and then proceed to step S23; Step S223: Determine the highest priority hit rule according to the priority of the hit rules, and output the exception classification corresponding to the highest priority hit rule, then proceed to step S23.

[0046] Specifically, in the actual matching process, there may be a situation where the same set of abnormal features conforms to multiple classification rules. In this embodiment, each matched classification rule is marked as a hit rule. Then, it is determined whether there are multiple hit rules. If so, the highest priority hit rule is determined according to the priority of each hit rule. Then, the abnormal classification corresponding to the highest priority hit rule is used as the actual output abnormal classification.

[0047] If there is only one hit rule, output it directly.

[0048] In one embodiment, such as Figure 6 As shown, step S22 includes: Step S221: Match the abnormal features using each classification rule in turn to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed with the rule-based judgment process; If not, directly output the exception category corresponding to the hit rule, and then proceed to step S23; like Figure 7 As shown, the rule-based discrimination process includes: Step A231: For each anomaly category corresponding to a hit rule, calculate the corresponding anomaly score; Step A232: Sort the anomalies according to their scores, and use the anomaly category with the highest score as the actual anomaly category.

[0049] Specifically, in the actual matching process, there may be a situation where the same set of abnormal features conforms to multiple classification rules. In this embodiment, each matched classification rule is marked as a hit rule. Then, it is determined whether there are multiple hit rules. If so, in step S23, for each abnormal category corresponding to a hit rule, the corresponding abnormal score is calculated. Then, the abnormal scores are sorted, and the abnormal category with the highest score is output as the actual abnormal category.

[0050] If there is only one hit rule, output it directly.

[0051] In one embodiment, during the execution of step A232, the score difference between the highest-scoring and second-highest-scoring anomaly categories is also calculated. When the score difference is less than the preset score difference threshold, the abnormality will be classified as a compound abnormality.

[0052] Specifically, in order to achieve a more accurate classification process for anomalies, this embodiment further calculates the score difference between the anomaly classification with the highest score and the second highest score during the anomaly score calculation process. Then, the score difference is compared with a preset score difference threshold, and cases with too small a difference are marked as composite anomalies, thereby achieving a more accurate classification process.

[0053] In one embodiment, such as Figure 8 As shown, step S3 includes: Step S31: Extract the corresponding action set and applicable conditions based on the anomaly category; Step S32: Extract the corresponding candidate repair actions from the action set according to the applicable conditions; Step S33: Calculate the corresponding action priority value for the candidate repair actions, and select the target action for this round according to the action priority value.

[0054] Specifically, to achieve accurate extraction of repair actions, this embodiment first extracts the corresponding action set and applicable conditions based on the anomaly category. This action set and applicable conditions are pre-maintained by the system, for example: Dependency completion is applicable when there are dependency exceptions and the logs show missing packages, missing classes, version conflicts, or undeclared dependencies. Interface adaptation actions are applicable when the interface is abnormal and there are clear differences in the interface signature, field mapping, parameter type, or return value structure. Local logic rewriting is applicable when there is a logical exception and the test failure has been located to a specific method, branch, or condition judgment. Constraint correction actions are applicable when there are constraint anomalies or test coverage anomalies, and the failure points are concentrated in specification, coverage, or performance constraints. Version rollback is applicable when the same action fails after multiple consecutive rounds, or when the current action is of high risk. Manual confirmation is applicable to complex anomalies, high-risk changes, unstable main anomaly scores, or conflicting candidate actions.

[0055] Subsequently, based on the mapping table between anomaly categories and repair actions, multiple candidate repair actions are obtained from the anomaly categories. Examples of the mapping table include: Dependency exceptions are mapped to dependency completion actions by default. API exceptions are mapped to API adaptation actions by default. Logical exceptions are mapped to local logic rewriting actions by default. Constraint anomalies are mapped to constraint correction actions by default. Composite anomalies are ranked among multiple candidate actions based on the main anomaly score, historical success rate, and risk level.

[0056] Then, the action priority value is calculated for the repair candidate actions, for example: Action priority value = m × category matching degree + n × historical success rate - p × action risk value - q × consecutive failure penalty value.

[0057] Among them, the category matching degree represents the degree of fit between the current action and the main exception category; Historical success rate represents the percentage of times the action was successful under the same or similar anomalies; Action risk value represents a comprehensive measure of the scope of code changes, the number of modules affected, and the potential regression risk of an action; The consecutive failure penalty value represents the penalty for an action that has been repeatedly executed but failed in recent rounds.

[0058] Finally, the repair action with the highest priority value is selected as the target action for this round.

[0059] In one embodiment, the corrective information adjusts the selected target action by adding corresponding penalty and reward items to the target action.

[0060] Specifically, for the above formula, the target action output can be changed by adjusting the corresponding penalty and reward terms during the subsequent generation of corrective actions.

[0061] In one embodiment, such as Figure 9 As shown, step S4 includes: Step S41: Control the AI ​​programming assistance system to generate a repair plan based on the target action; Step S42: Determine the repair plan by combining multiple rounds of cache information and generate error change relationships; Step S43: Determine whether the error-reporting change relationship or the corresponding target action occurs multiple times; If so, generate correction information and return to step S1; If not, return to step S1.

[0062] Specifically, after selecting the target action, the AI ​​programming assistance system is first controlled to generate a repair plan based on the target action and add it to the AI-generated code. For example, when the exception type is a dependency exception, dependency completion is executed first; when the exception type is an interface exception, field mapping adjustment or interface adaptation modification is executed first; when the exception type is a logic exception, local code rewriting is executed first; when multiple rounds of repair fail to meet the completion standard, version rollback or manual confirmation can be triggered.

[0063] Then return to step S1 to continue the corresponding verification and testing process.

[0064] Meanwhile, the system establishes multiple feedback link records for the same repair task, and saves at least the following information in the most recent N rounds of repair process: the exception category, error code set, log keyword set, failed test item set, interface difference item set, selected repair action, verification result after the repair action is executed, and code modification scope and affected modules for each round.

[0065] The system compares the current feedback with the previous or multiple previous feedback rounds to determine which of the following multi-round states the current state belongs to: The same type of error persists, meaning that the exception category in this round is the same as the previous round and the core error code or failed test item appears repeatedly; Error migration type, which means that the main exception type in this round is different from the previous round, but the failure location is related to the code area modified in the previous round; Local improvement type, which means that the anomaly category has not completely disappeared in this round, but the number of errors has decreased, the number of failed test items has been reduced, or the severity of errors has decreased; Completely ineffective type, meaning the feedback in this round is basically the same as the previous round; Risk expansion type, which means that this round adds new failed modules, new failed test items, or the scope of impact expands.

[0066] The aforementioned multi-round states will also be stored in the cache.

[0067] Based on this, the repair scheme is judged by combining multi-round cache information to generate error change relationships, such as whether the aforementioned multi-round states have changed.

[0068] Then, it is determined whether the error-reporting change relationship or the corresponding target action occurs multiple times. This is reflected in multiple judgment conditions: The same type of error occurs consecutively, reaching the threshold for the first round; The same repair action was executed consecutively until the second round threshold was reached, but the verification still failed. This round has resulted in either a migration-type error or a risk amplification scenario. The current action priority value has dropped below the set threshold; The change in the main anomaly category score compared to the previous round exceeded the set threshold.

[0069] Once the aforementioned discrimination conditions are triggered, correction information needs to be generated. This correction information is generated through rule matching, for example: If the current action fails consecutively, a penalty factor is added to the candidate action ranking to reduce the priority of the current action; If the current active dependency completion fails repeatedly, switch to interface adaptation or partial logic rewriting; if the current active partial rewriting causes error migration, switch to version rollback or manual confirmation. If the problem is found to have spread, the scope of the next round of code modifications will be limited to modules, functions, or fields directly related to the main exception. If a risk escalation state occurs and the number of newly added failures exceeds the threshold, the current round of modifications will be revoked and the system will be restored to the previous stable state before the repair actions are recalculated. If the composite anomaly persists, or the candidate action score is close to or has reached the maximum number of automatic repair rounds, then automatic repair is stopped, and structured manual processing suggestions are output.

[0070] After the correction information appears, in the next round of repair, when selecting the target action in step S3, the calculation of the action priority value will introduce an additional factor: Corrected action priority value = Original action priority value - Consecutive failure penalty - Problem spread penalty + Local improvement reward.

[0071] Among them, the consecutive failure penalty is positively correlated with the number of consecutive failures of the same action; the problem propagation penalty is positively correlated with the number of newly added failed modules and the number of newly added failed test items. The incentives for local improvements are positively correlated with the decrease in the number of errors and the reduction in the proportion of failed tests.

[0072] Based on this, the candidate actions are reordered, and a new target repair action is selected to perform the next round of repairs.

[0073] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for repairing AI programming anomalies based on multi-source engineering feedback, characterized in that, include: Step S1: For each round of AI-generated code output by the AI ​​programming assistance system, construct test cases and conduct tests, then collect test data to generate a feedback set; Step S2: Extract features from the feedback set and classify them to generate anomaly classification and anomaly score; Step S3: Determine the corresponding target action based on the anomaly classification; Step S4: Control the AI ​​programming assistance system to generate a repair plan based on the target action, and then use the repair plan as the AI ​​generated code for this round, and return to step S1 until the repair is completed; Furthermore, during the execution of step S4, multiple rounds of error messages are also evaluated, and corrective information is generated to adjust the target action in the next round.

2. The AI ​​programming anomaly repair method according to claim 1, characterized in that, The procedure before performing step S1 for the first time also includes: Step S01: Receive the defect repair task from the outside, extract the defect repair information and concatenate it with the prompt word template, and then input it into the AI ​​programming assistance system.

3. The AI ​​programming anomaly repair method according to claim 1, characterized in that, Step S1 includes: Step S11: Extract test key points from the AI-generated code according to the preset extraction template, and automatically generate test cases for the test key points; The key test points include at least one of variables, APIs, and functions; Step S12: Test the constructed AI-generated code based on the test cases to obtain the test data; Step S13: Collect related information based on the test data and generate the feedback set; The associated information includes at least one of the following: build logs, error codes, test failure items, dependency resolution results, interface signature comparison results, and constraint verification results.

4. The AI ​​programming anomaly repair method according to claim 1, characterized in that, Step S2 includes: Step S21: Perform structured processing on the feedback set and extract the corresponding abnormal features according to the extraction rules; Step S22: Match the abnormal features according to the classification rules to obtain the corresponding abnormal classification; Step S23: Calculate the matching degree for each of the anomaly categories and calculate the anomaly score by weighting the results; In step S23, the matching degree is composed of error code matching degree, log keyword matching degree, test failure correlation degree, interface difference matching degree, and historical repetition degree. Different anomaly classifications correspond to different weight combinations.

5. The AI ​​programming anomaly repair method according to claim 4, characterized in that, Step S22 includes: Step S221: Match the abnormal features sequentially using each of the classification rules to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed to step S223; If not, output the anomaly classification corresponding to the hit rule, and then proceed to step S23; Step S223: Determine the highest priority hit rule according to the priority of the hit rules, and output the anomaly classification corresponding to the highest priority hit rule, and then proceed to step S23.

6. The AI ​​programming anomaly repair method according to claim 4, characterized in that, Step S22 includes: Step S221: Match the abnormal features sequentially using each of the classification rules to obtain the hit rules; Step S222: Determine if there are multiple hit rules; If so, proceed with the rule-based judgment process; If not, directly output the anomaly classification corresponding to the hit rule, and then proceed to step S23; The rule-based discrimination process includes: Step A231: For each of the above-mentioned hit rules corresponding to the above-mentioned anomaly classification, calculate the corresponding anomaly score respectively; Step A232: Sort the anomalies according to the anomaly scores, and use the anomaly category with the highest output score as the actual anomaly category.

7. The AI ​​programming anomaly repair method according to claim 6, characterized in that, During the execution of step A232, the score difference between the highest and second-highest score of the anomaly category is also calculated; When the score difference is less than a preset score difference threshold, the abnormality is classified as a composite abnormality.

8. The AI ​​programming anomaly repair method according to claim 1, characterized in that, Step S3 includes: Step S31: Extract the corresponding action set and applicable conditions according to the anomaly category; Step S32: Extract the corresponding candidate repair actions from the action set according to the applicable conditions; Step S33: Calculate the corresponding action priority value for the candidate repair action, and select the target action for this round according to the action priority value.

9. The AI ​​programming anomaly repair method according to claim 8, characterized in that, The corrective information adjusts the selected target action by adding corresponding penalty and reward items.

10. The AI ​​programming anomaly repair method according to claim 1, characterized in that, Step S4 includes: Step S41: Control the AI ​​programming assistance system to generate the repair plan based on the target action; Step S42: The repair scheme is judged in combination with multi-round cache information to generate error change relationship; Step S43: Determine whether the error reporting change relationship or the corresponding target action occurs multiple times; If so, generate the correction information and then return to step S1; If not, return to step S1.

Images