An AI-based closed-loop generation-testing-repair system for fully automated Spring Boot programming and its multi-node collaborative operation method

Abstract

This invention discloses an AI-powered closed-loop generation-testing-repair system for fully automated Spring Boot programming. It includes modules for architecture compliance governance, automatic compilation and testing, automatic log condensation, multi-layered context construction, hierarchical syntax repair, dual-track quality assessment and version management, expert solution finding, automatic / manual registration of persistent issues, dynamic multi-model routing, and multi-node collaborative programming scheduling. This invention enables fully / semi-automatic backend project code generation, compliance rectification, compilation and testing, error location, layered repair, version control, and adaptive model switching—all operating in a fully closed-loop, unmanned manner. Furthermore, building upon fully automated programming, this invention achieves multi-machine, multi-node collaborative programming, realistically replicating the collaborative programming practices of large software development teams, significantly improving the efficiency of AI programming.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence software engineering technology, and in particular to an AI closed-loop generation-testing-repair system for fully automated programming with Spring Boot and its multi-node collaborative programming operation method. Background Technology

[0002] In AI-assisted programming, existing technologies mostly employ a "hint-and-generate" model or a basic proxy loop. While performing well on single tasks, they suffer from four major drawbacks in enterprise-level full-stack automated development:

[0003] First, there is a lack of architectural compliance governance: the model lacks awareness of architectural constraints, often writing SQL in the business layer or placing it in the wrong file directory, causing "engineering pollution", and it is impossible to automatically correct such high-level violations.

[0004] Second, there is a lack of closed-loop quality assessment and anti-degradation mechanisms: the verification granularity is coarse, which can easily lead to avalanche effect (one fix makes many mistakes), dead loop oscillation (repeated jumps) and version pollution, and there is a lack of a "zero degradation" defense line that is precise to the method level.

[0005] Third, error handling lacks hierarchical scheduling: all kinds of compilation errors are submitted to the model indiscriminately, resulting in a sharp drop in the repair rate, and there is a lack of isolated repair mechanisms based on type and priority.

[0006] Fourth, lack of dynamic multi-model routing and disaster recovery: fixed use or manual switching of models, and in the event of continuous failures, it is impossible to automatically switch to a better model, causing the task to become stuck.

[0007] There is an urgent need to build a closed-loop system with self-healing architecture, quality access control, hierarchical repair and dynamic routing capabilities to automate the entire process of "generation-verification-evaluation-repair-convergence". Summary of the Invention

[0008] The purpose of this invention is to solve the problems existing in the prior art, and to propose an AI closed-loop generation-testing-repair system for fully automated programming of Spring Boot and its multi-node collaborative programming operation method. It can realize fully automated / semi-automatic generation of backend project code, fully automated / semi-automatic compliance rectification, fully automated / semi-automatic compilation and testing, fully automated / semi-automatic error location, fully automated layered repair, fully automated version control, and fully automated / semi-automatic model adaptive switching in a fully closed-loop unmanned operation.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] An AI-powered closed-loop generation-testing-repair system for fully automated Spring Boot programming includes an architecture compliance governance module, an automatic compilation and testing module, an automatic log condensation module, a multi-layer context construction module, a hierarchical syntax repair module, a dual-track quality assessment and version management module, an automatic / manual expert solution finding module, an automatic / manual stubborn problem registration module, a dynamic multi-model routing module, and a multi-node collaborative programming scheduling module.

[0011] The architecture compliance governance module is used to perform time-space judgment and cleaning of AI-generated code and JDBC architecture red line detection, automatically correct file directories, and migrate non-compliant SQL statements to the MyBatis Mapper.xml file; (see...) Figure 2 )

[0012] The automatic compilation and testing module is used to automatically trigger incremental compilation and unit test execution after code changes, and to capture compilation errors and runtime exceptions; (see...) Figure 4 )

[0013] The automatic log condensation module is used to clean and intelligently condense the original operation logs, and calls a lightweight large model to extract the top 3 error root causes; (see...) Figure 10 )

[0014] The multi-layered context construction module is used to reverse trace and construct a complete five-layer source code context (Test→Controller→Service→Dao→Mapper.xml / JPA) from the exception stack trace in one go, and to perform post-event compensation and completion of non-standard strings in MyBatis; (see...) Figure 5 )

[0015] The hierarchical syntax repair module is used to classify compilation errors into five levels, from Step 0 to Step 4, and perform isolation repair and incremental coverage according to priority; (see...) Figure 6 )

[0016] The dual-track quality assessment and version management module is used for dual quantitative assessment based on "unit test pass rate" and "log error score", and performs "zero degradation" version anti-lock and anti-shock rollback; (see...) Figure 7 )

[0017] The automatic / manual expert solution search module is used to automatically retrieve historically successful repair solutions from the local knowledge base when a runtime error occurs; (see...) Figure 9 )

[0018] The automatic / manual registration module for persistent problems is used to automatically register problems that remain unresolved after exceeding a preset number of retries into the database and trigger an alarm; (see...) Figure 6 , Figure 7)

[0019] The dynamic multi-model routing module is used to achieve seamless hot switching of multiple models without interrupting the main process, based on a threshold of consecutive failures; (see...) Figure 8 , Figure 11 )

[0020] The multi-node collaborative programming scheduling module is used to split tasks through the Domain master control, distribute them to the Node cluster via LAN RPC, and continuously repair each node's sandbox under controlled polling until 100% success or a circuit breaker is triggered to exit. Then, the master control reclaims the code and forcibly pushes the merged data to the remote repository. (See...) Figure 12 )

[0021] Data flow relationships between modules: After the architecture compliance governance module completes code pre-inspection, the automatic compilation and testing module captures exceptions and triggers a two-stage divide-and-conquer repair based on the exception type: If a compilation error exists, the hierarchical syntax repair module is triggered first to perform syntax-level isolation repair and incremental coverage; if compilation passes but a runtime exception exists, the automatic log condensation module is triggered to extract the root cause and drive the multi-layer context construction module to build a five-layer context and compensate for it; then, AI prompt words are constructed and handed over to the AI ​​big model to modify the abnormal program source code. During the repair process, the automatic / manual search is called. The expert solution module reuses its strategy. If a repair fails, the automatic persistent problem registration module registers an alarm. The entire process is quantitatively evaluated and version controlled by the dual-track quality assessment and version management module. In the event of consecutive failures, the dynamic multi-model routing module is triggered to perform a seamless hot switch. Finally, when the code repaired by the multi-node cluster meets the dual-track quality assessment and all compilation tests are passed, the master node of the multi-node collaborative programming scheduling module uniformly reclaims the code repaired by all nodes, completes code merging and verification, and after verification, forcibly pushes the merged code to the remote code repository, completing a single fully automatic programming closed loop.

[0022] Preferably, the multi-layer context construction module includes a MyBatis XML / JPA post-compensation completion unit. When regular expression matching fails, this unit reverse-engineers the class name and method name from the Dao layer code string, traverses the project XML file, matches by namespace and id, and completes the corresponding SQL nodes. (See...) Figure 5 )

[0023] Preferably, the hierarchical syntax repair module performs an incremental overwrite operation: after the repair is completed, only the change in the number of errors of the same type is compared; if the number decreases, the new code is overwritten back into the reference directory as the benchmark for the next round of repair. (See...) Figure 6 )

[0024] Preferably, the anti-vibration rollback in the dual-track quality assessment and version management module adopts the isLastBanBen=true strategy, which skips the most recent inferior version and directly reverts to an earlier healthy version when two consecutive inferior versions occur. (See...) Figure 7 )

[0025] Preferably, the switching trigger condition for the dynamic multi-model routing module is a positive integer where ContinuousRollbackCount ≥ M1, and M1 is a positive integer representing the dynamic system configuration. (See...) Figure 11 )

[0026] This invention also discloses an AI-based closed-loop generation-testing-repair multi-node collaborative programming method for fully automated Spring Boot programming, applied to the aforementioned system, comprising the following steps:

[0027] S101: AI generates initial business logic code for a Spring Boot project;

[0028] S102: The architecture compliance governance module performs architecture compliance pre-check, completes spatiotemporal judgment cleaning and JDBC architecture red line detection;

[0029] S103: Save a version snapshot of the code after compliance processing;

[0030] S104: The automatic compilation and testing module automatically triggers incremental compilation and executes project unit tests, capturing compilation errors and runtime exceptions;

[0031] S105: The automatic log condensation module completes the automatic condensation of the operation log and conducts a dual-track quality quantification assessment;

[0032] S106: If the quality assessment result does not meet the standard, determine the error type: If there is a compilation error, proceed to step S107; If the compilation is successful but there is a runtime exception, complete the error type classification, and the multi-layer context construction module will construct a complete five-layer code context at once, while completing the MyBatis XML statement\JPA post-compensation and completion (specific process: extract string --> reverse extract class name and method --> search by ID and force completion).

[0033] S107: The hierarchical syntax repair module performs hierarchical syntax isolation repair according to the priority of compilation error level. After the repair is completed, it performs incremental coverage iteration and returns to step S103 to trigger automatic testing after the compilation error is cleared to enter the runtime error repair branch.

[0034] S108: The automatic / manual expert solution search module automatically retrieves the local expert solution library to match the corresponding repair strategy. If there is no matching solution and the repair fails, the automatic / manual stubborn problem registration module automatically registers the stubborn problem and triggers an alarm.

[0035] S109: Determine whether the number of consecutive rollbacks has reached a preset threshold. If the threshold is reached, the dynamic multi-model routing module will perform dynamic multi-model seamless hot switching.

[0036] S110: Execute circuit breaker judgment and resource reclamation: Determine whether the number of repair loops or the execution time of a single child process exceeds the extreme threshold: If a single execution times out, force KILL to hang the child process and reclaim resources, and count the loop as a failure; If the cumulative number of loops exceeds the extreme threshold, break out of the controlled polling loop, trigger a full code rewrite as a fallback operation, or downgrade and suspend for manual intervention; If the threshold is not exceeded, return to step S103 to continue the closed-loop repair process;

[0037] S111: Multi-node Sandbox Fusion Scheduling: The Domain master splits tasks and distributes them to the Node cluster via LAN RPC. Each node sandbox continues to repair under controlled polling until it passes 100% or triggers a circuit breaker to exit. Then, the master reclaims the code and forcibly pushes it to the remote repository.

[0038] Preferably, in step S106, the five-layer complete source code context construction process is as follows: extract the source code content of the test layer, control layer, business service layer, data access layer, and MyBatis mapping file layer in sequence by reverse tracing from the exception stack.

[0039] Preferably, in step S107, compilation errors are divided into five levels, namely general syntax errors, interface contract errors, ORM mapping errors, data type mismatch errors, and dependency management errors, and only the highest priority error type is repaired at a time.

[0040] Preferably, in step S108, when searching the local expert solution library, the hash value of the error type and the root cause summary of the error is used as the search key, and historical repair solutions with a confidence level higher than a preset threshold are directly reused.

[0041] Preferably, in step S109, dynamic multi-model hot switching is achieved by modifying the routing configuration, and the switching process does not interrupt the main loop workflow or restart the service process.

[0042] Preferably, in step S106, a five-layer call chain reverse tracing and post-compensation completion function is adopted to solve the problem of missing context in complex exception diagnosis. The system starts from the runtime exception stack and reverses through the five-layer call chain through the parser to extract the source code of the test class, controller, business layer to data access layer in sequence. When the extraction reaches the DAO layer, for the standard MyBatis namespace, the Mapper.xml node is directly located. For old projects or non-standard strings in JDBC style (such as the inline getSqlSession.selectOne fully qualified name call), the "post-compensation" mechanism is triggered: the class name and method name are reverse parsed using custom regular expressions, and then the mapperInfoMap is forcibly searched by ID to extract the corresponding SQL tag. Finally, the five-layer source code and the SQL fragment extracted by compensation are aggregated by the context splicer and fully injected into the large model to repair the Prompt, completely eliminating the repair blind spot and ensuring accurate troubleshooting.

[0043] Preferably, in step S111, the multi-node sandbox fusion scheduling (distributed task topology design) is jointly operated by the Domain master, Node cluster, and remote repository, forming a "split-melt-unify" closed loop: the master node acts as the central hub, parsing the requirements and splitting them into modules, and accurately distributing tasks to Node nodes via local area network RPC. Node nodes execute steps S103-S110 in a controlled polling manner within their local sandbox. The master process monitors the execution of child processes for timeouts and performs forced kill recycling to prevent resource exhaustion. When the module pass rate reaches 100% or triggers an extreme rewrite threshold, the polling ends. After achieving the target, the master node reclaims the code and merges it, then forcibly pushes the merged code to the remote repository for unified delivery via Git API. This design ensures absolute reliability of single-module repair through sandbox isolation, achieves parallel acceleration through distributed scheduling, and, combined with forced achievement and forced merging mechanisms, ensures the quality and efficiency of the delivered code. (See...) Figure 12 )

[0044] Preferably, compilation errors are repaired in four stages (Step 0-4) by the hierarchical syntax repair module, and runtime errors are traced in five layers of context by the multi-layer context construction module. The two are parallel decision branches.

[0045] Compared with the prior art, the beneficial effects of this invention are as follows:

[0046] 1. In this invention, the "cleaning-free" access of AI-generated code is achieved through the architecture compliance governance module, eliminating low-level build errors caused by JDBC violations and disordered file placement. It is expected to reduce manual code cleaning work by at least 80%-100%, thereby improving the quality of the engineering architecture and development efficiency.

[0047] 2. In this invention, the dual-track quantitative evaluation and anti-degradation mechanism ensures that the health status of the codebase is monotonically increasing, transforming uncontrollable AI behavior into a controllable deterministic convergence process, and achieving deterministic convergence of code quality.

[0048] 3. In this invention, the hierarchical error isolation and incremental coverage repair mechanism avoids the "avalanche effect" of mutual interference between multiple types of errors, significantly improves the AI's ability to handle complex engineering compilation problems, and greatly improves the success rate of repairing complex compilation errors.

[0049] 4. In this invention, the precise feeding of "automatic log condensation" and "five-layer context one-time construction" can reduce invalid log token consumption by 90%, thereby reducing token consumption and repair delay.

[0050] 5. In this invention, the system is equipped with self-disaster recovery capability through dynamic multi-model hot switching routing, breaking the dead loop of failure that may be caused by a single model, and enhancing the system's resilience and resource utilization.

[0051] 6. In this invention, by automatically / manually registering persistent problems and finding expert solutions, the system can accumulate an experience knowledge base, providing a data foundation for continuous optimization of subsequent versions and establishing the system's self-evolution capability. Attached Figure Description

[0052] Figure 1 This is the overall architecture diagram of the AI ​​closed-loop generation-testing-repair system for fully automated programming with Spring Boot.

[0053] Figure 2 This is a schematic diagram of the overall process of the AI ​​closed-loop generation-testing-repairing and running method for fully automated programming in Spring Boot.

[0054] Figure 3 This is the core workflow diagram of the system (closed-loop feedback and self-healing process).

[0055] Figure 4 This is a diagram illustrating the automatic compilation and syntax correction process;

[0056] Figure 5 A schematic diagram illustrating the module construction process for multi-layered contexts;

[0057] Figure 6 Logic diagram for fixing level 5 syntax errors (Step 0 to Step 4);

[0058] Figure 7 A schematic diagram of the dual-track quality assessment and anti-degradation version management process;

[0059] Figure 8This is a routing logic diagram for dynamic multi-model hot switching;

[0060] Figure 9 A flowchart illustrating the process of automatically / manually finding expert solutions;

[0061] Figure 10 This is a schematic diagram of the log condensation and root cause extraction process provided in an embodiment of the present invention;

[0062] Figure 11 This is a schematic diagram of the dynamic multi-model hot-switching routing process based on a failure threshold.

[0063] Figure 12 A schematic diagram of the topology for multi-node sandbox fusion scheduling and multi-node distributed task scheduling;

[0064] Figure 13 The logic diagram for the architecture's compliance pre-inspection and defensive cleaning procedures. Detailed Implementation

[0065] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0066] 1. Overall architecture and overall process:

[0067] Reference Figures 1-13 This document describes an AI-powered closed-loop generation-testing-repair system for fully automated Spring Boot programming. It includes an architecture compliance governance module, an automatic compilation and testing module, an automatic log condensation module, a multi-layer context construction module, a hierarchical syntax repair module, a dual-track quality assessment and version management module, an automatic / manual expert solution finding module, an automatic / manual stubborn problem registration module, a dynamic multi-model routing module, and a multi-node collaborative programming scheduling module. After the architecture compliance governance module completes code pre-inspection, the automatic compilation and testing module captures exceptions, triggering the automatic log condensation module to extract root causes. This then drives the multi-layer context construction module to build and compensate for five layers of context. Subsequently, the hierarchical syntax repair module performs hierarchical repair and incremental coverage. During the repair process, the automatic / manual expert solution finding module reuses its strategy. If failure occurs, the automatic stubborn problem registration module registers alarms. The entire process is quantitatively evaluated and version controlled by the dual-track quality assessment and version management module. In the event of consecutive failures, the dynamic multi-model routing module performs seamless hot switching. (See...) Figure 1 , Figure 2 )

[0068] 2. Architecture Compliance and Governance Module

[0069] The architecture compliance governance module uses a two-dimensional verification process to achieve architecture governance and file correction. First, it traverses the project source code directory tree, calculating the time difference between file creation and the current time: if it's less than 10 minutes, it's considered a newly generated AI file and precisely relocated by type—Test.java is moved to the correct package path in src / test / java, Mapper.xml is moved to the resources / mapper directory, and miscellaneous files are temporarily stored in the sandbox area; if the criteria are not met, it's considered a historical file, and erroneous backups are physically deleted to prevent contamination, while the rest are skipped. After file ownership is determined, an architecture red line scan is initiated: Regular expressions are used to match the content of DaoImpl.java. If SQL keywords such as SELECT or PreparedStatement are detected, a JDBC violation red line is triggered, compilation is refused, and the AI ​​is forced to migrate the SQL to Mapper XML; if the rule-compliant pre-check passes, it's allowed to proceed, ensuring code layering standards and zero pollution in the project structure; (see...) Figure 13 )

[0070] 3. Automatic compilation and testing module

[0071] The automatic compilation and testing module is used to automatically trigger incremental compilation and unit test execution after code changes, capturing compilation errors and runtime exceptions. This module triggers incremental compilation upon code changes, calling Maven to perform the compilation operation. If a compilation error is detected, the hierarchical syntax repair engine is started, executing Step 0 to Step 4 in priority order, and recompiling to obtain the current level error count. If the current level error count decreases, the reference directory is incrementally overwritten to refresh the AI ​​memory; if it does not decrease, a version rollback is performed to discard the current repair. When all compilation errors are cleared, it indicates that the code has passed the syntax phase governance, and the system exits the hierarchical syntax repair loop, triggering automatic testing to enter the runtime exception diagnosis process (S106); if it enters an extreme infinite loop, the repair process is forcibly terminated. All repair paths ultimately converge into the runtime testing phase, achieving closed-loop governance of automatic compilation error capture and repair; (see...) Figure 4 )

[0072] Two-stage divide-and-conquer repair mechanism (isolated governance during compilation and runtime):

[0073] In traditional software development, compilation errors and runtime errors are mutually exclusive. However, in the AI-generated fully automated programming loop, the code generated by AI often contains a complex mix of "incomplete syntax" and "business logic errors." If these are not isolated, AI is highly susceptible to compilation failures due to syntax errors when fixing runtime errors, which in turn triggers a controlled polling loop for the repair logic.

[0074] To this end, this system creatively adopts a "two-stage divide-and-conquer" strategy, setting the hierarchical syntax repair module and the multi-level context construction module as condition-triggered parallel decision branches:

[0075] Syntax-first interception (compile-time governance): In each iteration of the closed loop, the system prioritizes the compilation operation (S104). If a compilation error is caught, the system forcibly locks into the hierarchical syntax repair module (S107) for loop repair. At this time, the five-level context tracing is not triggered. Only when all compilation errors are cleared and the code is runnable is it allowed to enter the testing phase.

[0076] Runtime deep diagnostics (test-phase governance): The system triggers automatic log condensation (S105) and multi-layer context construction module (S106) only when compilation is successful and unit tests throw runtime exceptions. At this time, since the code has been compiled, the exception stack information is complete and reliable, and the system can accurately reverse trace the five-layer call chain of Test→Controller→Service→Dao→Mapper.xml to implement deep logic repair.

[0077] This isolation mechanism of "first ensuring compilation success, then ensuring correct execution" completely eliminates the avalanche of repair caused by the cross-interference of syntax and logic problems in AI, and is the cornerstone of the system's fully automatic deterministic convergence.

[0078] 4 Automatic Log Condensation Module

[0079] The automatic log condensation module cleans and intelligently condenses raw runtime logs, calling a lightweight large model to extract the top 3 error root causes. This module cleans the raw runtime logs (tens of thousands of lines) using LogFilterTool regular expressions to generate concise logs. If the length of the cleaned logs exceeds the Token threshold, the DeepSeek API lightweight large model is called to extract the top 3 error root causes (exception type / assertion location) and structure them into JSON; if the threshold is not exceeded, the module directly proceeds to the metadata input stage. Finally, the metadata is injected into the main model's prompt words, achieving a Token consumption reduction of over 90% and efficiently completing log condensation and root cause extraction; (see...) Figure 10 )

[0080] 5-level context construction module

[0081] The multi-layered context construction module is used to reverse trace and construct a complete five-layer source code context (Test→Controller→Service→Dao→Mapper.xml) from the exception stack in one go, and perform post-event compensation for non-standard MyBatis strings. This module starts with the runtime exception stack and uses an exception stack parser to reverse-path through the five-layer call chain, extracting the source code from the test class, controller, business layer to the data access layer in sequence. When extracting to the Dao layer, for standard MyBatis namespaces, the Mapper.xml node is directly located; however, for older projects or JDBC-style non-standard strings (such as the inline getSqlSession.selectOne fully qualified name call), a "post-event compensation" mechanism is triggered: a custom regular expression is used to reverse-parse out the class name and method name, and then a forced search is performed in the mapperInfoMap by ID to extract the corresponding SQL tags. Finally, the five-layer source code and the compensated SQL fragments are aggregated by the context splicer and fully injected into the large model to repair the Prompt, completely eliminating repair blind spots and ensuring accurate troubleshooting; (see...) Figure 5 )

[0082] The multi-layer context constructor module contains the MyBatis XML / JPA post-completion completion unit. This unit, when regular expression matching fails, reverse-engineers the class and method names from the Dao layer code string, traverses the project XML file, matches by namespace and id, and completes the corresponding SQL nodes; (see...) Figure 5 )

[0083] Explanation of the implementation logic for "customized regular expression reverse parsing to extract class name and method name":

[0084] The "customized regular expression reverse parsing" of this invention is not a single, fixed regular expression, but a set of combined dynamic parsing and reverse derivation strategies designed for multi-source heterogeneous data (such as non-standard exception logs, incomplete call stacks, etc.). Its core logic is implemented through the following three mechanisms working together:

[0085] 1. Dynamic Anchor Point Extraction Mechanism Based on Exception Stack Features: Faced with irregularly embedded call information in lengthy exception logs, the system employs dynamically constructed custom regular expressions for feature extraction.

[0086] Class name extraction: Based on the naming suffix features of the target level (such as Controller, Test, etc.), regular expressions are dynamically generated using boundary constraint rules to reverse the long string of fully qualified names, filter out package name interference, and accurately locate the class name of the target level.

[0087] Method name extraction: Based on the fixed formatting syntax of exception stack traces, it uses a double anchor point consisting of a specific keyword and a dynamically passed-in extracted class name, along with wildcard rules to skip intermediate package name paths and capture the method identifier immediately following the anchor point. This mechanism effectively solves the extraction failure problem caused by inconsistent heterogeneous log formats.

[0088] 2. Reverse derivation mechanism of mapping relationship when DAO layer is broken

[0089] When the call chain tracing is broken at the persistence layer (DAO) and the Mapper mapping cannot be directly identified, the system abandons the traditional deep syntax tree dependency and instead adopts reverse inference logic based on framework constraints:

[0090] Extract the Dao method identifier of the current broken call chain node. Utilize the implicit contract in persistence layer frameworks (such as Mybatis) that "interface method names and XML configuration tag identifiers must strictly match" to perform reverse equality matching in the global XML mapping table. Once a match is found, the corresponding SQL statement is automatically appended to the end of the call chain, achieving "post-event compensation" from Java code to database operations.

[0091] 3. Multi-level degradation fault-tolerant parsing mechanism for non-standard strings

[0092] For the numerous non-standard strings (such as incomplete spellings, abbreviations, etc.) present in older systems, hard regular expressions often fail. The system incorporates a multi-level degradation fuzzy parsing strategy:

[0093] Class name tolerance: A fallback strategy of "feature inclusion priority + similarity algorithm as a backup" is adopted. After exact matching fails, feature substring inclusion matching is performed first. If it still fails, a string similarity algorithm (such as a variant of the edit distance algorithm) is introduced to filter out the candidate class with the highest similarity within the set tolerance threshold.

[0094] Method name tolerance: A four-level progressive degradation pipeline is established, consisting of "exact matching → feature prefix matching → feature substring matching → global similarity matching". When faced with incomplete or deformed method names, the system gradually relaxes the matching conditions along the pipeline. Even when the method name is severely distorted, the system can still reverse-parse the most likely call chain by relying on the low-frequency degradation strategy, ensuring the robustness of context extraction.

[0095] 6-level syntax repair module

[0096] The graded syntax repair module is used to classify compilation errors into five levels, from Step 0 to Step 4, and to isolate, repair, and incrementally cover them according to priority.

[0097] The error classification is explained in the table below:

[0098] Step 0 General syntax error Missing semicolons, mismatched parentheses, incomplete sentences Step 1 Interface contract error ServiceImpl does not implement the methods defined in the Service interface. Step 2 ORM mapping error The Mapper interface method does not match the SQL ID in the XML, or the parameterType class cannot be found. Step 3 Type mismatch Error converting between String and Integer, error assigning value to DTO / Entity type Step 4 Package / Import / Lambda Error Missing import statement, incorrect class name capitalization, lambda variable not being a finite variable

[0099] The graded syntax correction module performs incremental coverage: after a correction is complete, it only compares the change in the number of errors of the same type. If the number decreases, the new code is overwritten back into the reference directory as the baseline for the next round of corrections. (See...) Figure 6 )

[0100] 7. Dual-track quality assessment and version management module

[0101] The dual-track quality assessment and version management module performs dual quantitative evaluation based on "unit test pass rate" and "log error score," and implements "zero degradation" version anti-lock and anti-shock rollback. The anti-shock rollback uses the `isLastBanBen=true` strategy, skipping the most recent version and directly reverting to an earlier healthy version when two consecutive poor-performing versions occur. This module starts by writing AI-generated code to a temporary sandbox area. It first performs a format screening: if the first line is not a `package` statement or contains garbled characters, it is intercepted and discarded within milliseconds; otherwise, it proceeds to the compilation and testing phase. After successful compilation and test report generation, the quality adjudicator performs a dual-track evaluation: at the micro level, it verifies whether the number of unit test pass rates for the new version is not lower than that of the old version; at the macro level, it verifies whether the log error score for the new version is lower than that of the old version. When either the micro or macro metric is worse than the old version, a rollback mechanism is triggered; if the micro metric meets the standard but the macro metric does not, a rollback is also determined. During rollback, the `isLastBanBen` state is read: if it's false, a normal rollback to the previous version is performed; if it's true (two consecutive poor versions), a cross-version jump is executed, forcibly pulling an earlier healthy version to physically interrupt the controlled polling repair loop. Finally, based on version determination, the healthy version is directly merged into the main branch, or a temporary poor version is discarded, achieving "zero degradation" anti-lock and anti-shock rollback, ensuring continuous improvement in code quality. (See...) Figure 7 )

[0102] 8. Automatic / manual expert solution search module and automatic / manual registration of stubborn problems module

[0103] The automatic / manual expert solution search module is used to automatically retrieve historically successful repair solutions from the local knowledge base when a runtime error occurs. This module starts with a runtime error trigger and enters the retrieval layer to search the local expert database. If a solution is found with a confidence level ≥ 0.8, the solution is applied directly, ending the process; if the confidence level is insufficient, the module enters the repair layer to attempt repair using a larger model. If the repair is successful, the process ends; if it fails, a help package is assembled and marked as requiring manual intervention. Simultaneously, the registration layer records persistent problems. If retries are ≤ 5 times, the repair loop continues; if the 5-retry limit is reached, the problem is written to the problem database and an alarm is sent, awaiting manual review. After manual intervention, the expert database is updated to supplement new solutions, forming a closed loop of "retrieval-repair-registration-manual intervention," achieving automatic error handling and dynamic iteration of the knowledge base. (See...) Figure 9 )

[0104] 9. Dynamic Multi-Model Routing Module

[0105] The dynamic multi-model routing module enables seamless hot-switching of multiple models without interrupting the main workflow, based on a threshold of consecutive failures. The switching trigger condition for this module is a multiple of ContinuousRollbackCount (M1), where M1 is a positive integer configured dynamically by the system. This module starts by entering the repair loop, initializing `modelName` to `GLM` and setting the failure count to 0, then invoking the current model to perform AI repair. The repair results are evaluated: if quality improves, the failure count is reset to zero and the code is retained; if quality deteriorates or is ineffective, the failure count is incremented by 1. When the failure count is ≥3, a circuit breaker switch is triggered, recording the current model failure and selecting a backup model from the model pool (Kimi / GLM / DeepSeek / Qwen). Selection strategies include using the highest historical win rate or sequential polling. After updating `modelName` and resetting the failure count, the loop continues. If the repair is successful, the quality is improved, and the continuous rollback count is reset to zero; if it fails, the count is incremented by 1. When the continuous rollback count is ≥3 and a multiple of M1, AIModelSmartSwitcher is called to record and recommend a new model, passing in the business module name, the current model, and the number of repair attempts. Internally, it marks the current model as having failed 3 times consecutively, selects a new model (e.g., kimi-k2.5) based on historical win rate or cooldown time, updates modelName, and continues the loop, achieving seamless hot switching and dynamic routing of multiple models. (See...) Figure 8 Figure 11 )

[0106] A multi-node collaborative programming scheduling module (multi-node distributed task scheduling)

[0107] Multi-node collaborative programming scheduling module: The master controller splits tasks and distributes them to the Node cluster via RPC; after the nodes are repaired in a sandbox cycle to 100%, the master controller reclaims and forcibly pushes and merges them into the remote repository. This module uses the Domain master node as the command center. The business requirement parser breaks down macro requirements into independent modules, which are then precisely distributed to each Node node (such as Node 01 processing module A, Node 02 processing module B, etc.) via LAN RPC / Socket communication through the MultiNodeTaskDispatcher task splitting and distribution engine. Each Node has a closed pipeline of "continuous polling repair engine + local Maven sandbox + version snapshot repository": the continuous polling repair engine (such as startAModuelCodeGenerator) continuously generates and self-tests code, the Maven sandbox provides an isolated compilation environment, and the version snapshot repository temporarily stores iteration products until the module compilation and testing are 100% successful before it can be released to the repository. A global status dashboard polls and monitors the pass rate of each module, providing a basis for scheduling decisions. After achieving the required standards, the snapshot repository artifacts from each node are sent back to the master GitGitee API code recycling and merging machine. This merges the parallel results from multiple branches and forces a push to the Gitee remote repository for unified delivery via the Git API. This design uses sandbox isolation to ensure absolute reliability of single-module repairs, distributed RPC scheduling to accelerate parallel processing, and a forced achievement and forced merging mechanism to ensure the quality and efficiency of delivered code. (See...) Figure 12 )

[0108] Process-level circuit breaking and forced termination / recovery mechanisms:

[0109] While the "continuous polling self-healing engine" in this system logically manifests as a loop of continuous retries, its engineering implementation incorporates strict resource management and circuit breaker mechanisms, completely eliminating process hangs or resource exhaustion issues caused by unsolvable bugs. Its core safeguard logic is as follows:

[0110] Multi-process / multi-thread sandbox isolation: Automatic compilation, automatic testing, and AI repair calls in the system are all started in the Maven sandbox as independent child processes or isolated threads. The main control process runs as an independent "guardian" and is not affected by the abnormal state of the child processes.

[0111] Timeout Circuit Breaker and Forced Kill: The master process sets a strict timeout threshold for each repair round. If a child process times out due to an unsolvable architectural error or deadlock, the master process will proactively trigger the circuit breaker, directly sending a kill signal to the timed-out child process to forcibly reclaim system resources (CPU / memory) and prevent resource exhaustion.

[0112] Abnormal Degradation and Safe Exit: When a single repair is forcibly terminated, the system marks the error in that round as "timeout unresolved" and automatically registers it as a stubborn problem, triggering an alarm, in conjunction with step S108. At the same time, the system will determine whether the current number of polling attempts exceeds the extreme threshold (step S110). If it does, the system will directly exit the polling loop, triggering a full code rewrite as a fallback or suspending the process until manual intervention.

[0113] Through the closed-loop management of "isolation operation - timeout forced kill - downgrade exit" described above, this system can achieve fully automatic high-intensity repair while ensuring the absolute security of host machine resources and the industrial-grade availability of the system.

[0114] 11 Overall Process

[0115] This invention also discloses an AI-based closed-loop generation-testing-repair multi-node collaborative programming method for fully automated Spring Boot programming, applied to the aforementioned system, including the following steps: (see...) Figure 1 Architecture diagram Figure 2 flow chart)

[0116] S101: AI generates initial business logic code for a Spring Boot project;

[0117] S102: The architecture compliance governance module performs architecture compliance pre-checks, completes spatiotemporal judgment cleaning, and JDBC architecture red line detection;

[0118] S103: Save a version snapshot of the code after compliance processing;

[0119] S104: The automatic compilation and testing module automatically triggers incremental compilation and executes project unit tests, capturing compilation errors and runtime exceptions;

[0120] S105: The automatic log condensation module completes the automatic condensation of the operation logs and conducts a dual-track quality quantification assessment;

[0121] S106: If the quality assessment result does not meet the standard, the error type is determined: if there is a compilation error, proceed to step S107; if the compilation is successful but there is a runtime exception, the error type classification is completed, and the multi-layer context construction module constructs a five-layer complete code context at once, while completing the MyBatis XML statement / JPA post-compensation completion (specific process: extract string --> reverse extract class name and method --> search by ID and force completion). The five-layer complete source code context construction process is as follows: reverse trace from the exception stack to extract the source code content of the test layer, control layer, business service layer, data access layer, and MyBatis mapping file layer in sequence.

[0122] S107: The hierarchical syntax repair module performs hierarchical syntax isolation repair according to the priority of the compilation error level. The compilation errors are divided into five levels, namely general syntax errors, interface contract errors, ORM mapping errors, data type mismatch errors, and dependency management errors. Only the highest priority error type is repaired in a single step. After the repair is completed, incremental coverage iteration is performed. After the compilation errors are cleared, the module returns to step S103 to trigger automatic testing to enter the runtime error repair branch.

[0123] S108: The automatic / manual expert solution search module automatically retrieves the local expert solution library to match the corresponding repair strategy. When searching the expert solution library, the hash value of the error type and the root cause summary of the error is used as the search key. Historical repair solutions with a confidence level higher than the preset threshold are directly reused. If there is no matching solution and the repair fails, the automatic / manual stubborn problem registration module automatically registers the stubborn problem and triggers an alarm.

[0124] S109: Determine whether the number of consecutive rollbacks has reached the preset threshold. If the threshold is reached, the dynamic multi-model routing module will perform dynamic multi-model seamless hot switching. Dynamic multi-model hot switching is achieved by modifying the routing configuration. The switching process does not interrupt the main loop workflow or restart the service process.

[0125] S110: Execute circuit breaker judgment and resource reclamation: Determine whether the number of repair loops or the execution time of a single child process exceeds the extreme threshold; if a single execution times out, force KILL to hang the child process and reclaim resources, and count the loop as a failure; if the cumulative number of loops exceeds the extreme threshold, break out of the controlled polling loop, trigger a full code rewrite fallback operation, or downgrade and suspend for manual intervention; if the threshold is not exceeded, return to step S103 to continue the closed-loop repair process;

[0126] S111: Multi-node Sandbox Fusion Scheduling: The Domain master splits tasks and distributes them to the Node cluster via LAN RPC. Each node sandbox continues to repair under controlled polling until it passes 100% or triggers a circuit breaker to exit. Then, the master reclaims the code and forcibly pushes it to the remote repository.

[0127] Detailed description of the work process:

[0128] This invention discloses an AI closed-loop generation-testing-repair system and its operation method for fully automated programming with Spring Boot, implemented on a computer-readable storage medium and device. The computer-readable storage medium is a hard disk / USB flash drive / ROM / remote database, storing the AI ​​closed-loop generation-testing-repair system for fully automated programming with Spring Boot. When the processor executes the system program, it automatically implements the AI ​​closed-loop generation-testing-repair operation method for fully automated programming with Spring Boot.

[0129] The present invention will be further described below through a specific working process:

[0130] Before the AI-generated code is written to disk or compiled, this system enforces an architecture compliance check. The core workflow is a closed-loop, controlled polling repair cycle of "generation → automatic compilation → automatic testing → automatic log condensation → quantitative assessment → tiered repair → version selection". Specifically:

[0131] 1. Architecture compliance governance and defensive code cleanup mechanisms

[0132] AI code generation: Users input business requirements (such as "User Management Module: CRUD operations"), and the system schedules the current model to generate a complete set of code including Controller, Service, DaoImpl, unit tests, and Mapper.xml.

[0133] The MisplacedCodeCleaner performs a time-space cleanup: the system traverses the project source code directory and obtains file creation timestamps. If a file is created within a preset threshold (an M3 system configuration variable, such as 10 minutes), it is determined to be a newly generated file to be processed by AI and automatically moved to the correct directory based on its content characteristics (e.g., if it contains the @Test annotation, it is moved to the / test / java directory). If a file times out, it is determined to be a historical junk file and deleted. This mechanism solves the build failure problem caused by misplaced files.

[0134] The system performs a JDBC architecture red line check (CheckIfJdbcProgram): Using regular expressions, the system scans Java files such as DaoImpl to detect SQL keywords or JDBC-specific classes (such as PreparedStatement). If a violation is detected, an architecture violation is identified, forcibly triggering a code refactoring process. SQL statements are then migrated to the MyBatis Mapper.xml file to ensure the purity of the layered architecture. Once the architecture compliance check passes, a version snapshot is saved.

[0135] 2. Automated compilation, automated testing, and automated log summarization

[0136] The system automatically triggers the following operations after each code change, forming the basic data for a feedback loop:

[0137] Automatic compilation: The system calls the APIs of build tools such as Maven / Gradle to perform real-time incremental compilation, captures and parses the structured error information returned by the compiler (including error type, file location, and error line number), builds a list of compilation errors in memory, and directly enters the error category if the compilation fails, and enters automatic unit testing if the compilation succeeds.

[0138] Automated Testing: After successful compilation, the system automatically scans the test classes in the project and executes all or affected unit tests through the APIs of testing frameworks such as JUnit / TestNG. The system captures the execution status (pass / fail), execution duration, and standard error / output stream of each @Test method in real time, forming passedFunctionList (a list of passed methods) and failedFunctionList (a list of failed methods).

[0139] 3 Automatic Log Condensation

[0140] For the captured raw runtime logs (which may be tens of thousands of lines long), the system first uses LogFilterTool to apply regular expressions to clean redundant information (such as timestamps, thread IDs, and irrelevant DEBUG information). If the cleaned logs still exceed a preset token threshold, the system calls a lightweight large model (such as the DeepSeek API) to further condense the logs. The instruction is: "Extract the top 3 error root causes, exception types, and the location of the first assertion failure in the code." This model returns a structured JSON object containing fields such as root_causes, exception_type, and failed_assertion_line. This structured signal serves as the metadata input for subsequent repair models, rather than the raw long logs, thereby reducing the log token consumption in the alert words by more than 90%.

[0141] 4. Multi-level context construction module

[0142] Multi-layer context one-time construction (five-layer call chain reverse tracing and MyBatis XML / JPA post-event compensation): Upon capturing a compilation error or runtime exception, the system immediately triggers MethodCallChainAnalyzerTools. This tool automatically executes the following reverse tracing process by parsing the exception stack trace (such as at com.example.controller.UserController.getUser(UserController.java:25)) and combining it with the static structure of the project source code directory:

[0143] Step 1: Locate the "source" method that triggered the error in the stack (usually the innermost stack).

[0144] Step 2: Analyze the fully qualified name of the method (package name + class name + method name) to determine which layer it belongs to (Controller / Service / Dao / Test, etc.).

[0145] Step 3: Use string parsing and regular expression matching to trace the call chain backwards. For example, trace backwards from UserDaoImpl.selectUserById() to UserService.getUser(), then backwards to UserController.queryUser(), and finally find the test method UserControllerTest.testGetUser();

[0146] Step 4: Following this call chain, the complete source code of each class file is read at once and encapsulated into a FiveLayerContext object. This object contains five fields: {test_code, controller_code, service_code, dao_code, mapper_xml}. For MyBatis' mapper.xml, the system uses a "post-compensation completion" algorithm: even if non-standard fully qualified name strings are used in the Dao layer code (such as getSqlSession().selectOne("com.example.dao.UserDao.selectById")), after the regular expression match fails, the system will reverse-engineer com.example.dao.UserDao and selectById from the string, then traverse the mapper nodes in the project's XML file, match by namespace, and search for the corresponding SQL fragment by id under that mapper, forcibly completing it into the context. After this "five-layer context" object is constructed in the system memory, it will be directly serialized into a string and injected into all the prompts of the subsequent model repair, fundamentally eliminating the "illusion" caused by the AI's lack of a global perspective.

[0147] 5. Hierarchical syntax error isolation and incremental coverage repair engine

[0148] The system abandons the "one-size-fits-all" approach and implements a tiered repair mechanism similar to the compiler front-end Pass:

[0149] Error triage: Compilation errors are automatically categorized into 5 levels (Step 0-Step 4):

[0150] Step 0: General syntax (missing semicolons, mismatched parentheses);

[0151] Step 1: Interface Contract (ServiceImpl does not implement interface methods);

[0152] Step 2: ORM mapping (parameterType class not found in Mapper / XML, ID mismatch);

[0153] Step 3: Type mismatch (DTO / Entity / Model assignment or conversion error);

[0154] Step 4: Dependency management (missing package / Import statements, non-final Lambda expression variables).

[0155] Isolation Repair and Incremental Coverage: The repair loop `SyntaxErrorProcesser` enters a `while(anyErrorList.size() >= 1)` loop. The loop body performs the following atomic operations:

[0156] a. Priority routing: Starting from the lowest number (Step0), check the corresponding ErrorStepXList and retrieve the set of errors with the highest priority in this batch;

[0157] b. Specific prompt word invocation: Invoke the corresponding repairer (such as AICommondSyntaxStep0), which only concatenates the error message of "this type" and the relevant source code fragment in FiveLayerContext into a prompt word and invokes the large model;

[0158] c. Atomic code replacement: The fixes returned by the large model are applied to the file system;

[0159] d. Incremental recompilation: The system executes runBianYi() (incremental compilation), generating a temporary ErrorStepXListTemp;

[0160] e. Comparison of individual error types: The system only compares the change in the number of errors of the same type in ErrorStepXList (old) and ErrorStepXListTemp (new);

[0161] f. Progressive Adoption and Coverage: If the number of errors of this type decreases (e.g., Step 0: 2 → 0), the system executes `copyJavaAndXmlFiles()` to overwrite the "References Directory" with the newly fixed code files, serving as the baseline for the next round of processing other types of errors (e.g., Step 1). If the number of errors of this type remains unchanged or increases, `rollbackToPrevious` is executed to roll back to the best local version. This "incremental coverage" process ensures that the AI's perspective is always based on the cleaned "clean code," fundamentally eliminating the risk of breaking one error while fixing another.

[0162] Fallback mechanism: When ContinuousRollbackCount > N or SyntaxErrorCount > N (N is a positive integer, the specific value of which is determined by the average number of repeated calls), the system determines that the current code is "complex and tangled," abandons local repair, and directly calls Step6GenerateSpringBootCode.main and Step9GenerateSpringBootWebTestCode.main to completely rewrite the Controller / Service / Dao / Test of that module.

[0163] 6. Dual-track quantitative quality assessment and anti-degradation version management

[0164] The system establishes a finite state machine, using two insurmountable "anti-degradation locks" to determine the fate of new code versions:

[0165] Micro-level method-level locking: The system calls the `runTestAndFilterLogForBusiness` function to obtain the current version's `hasPassedFunctionListFinalySize` (the number of passed methods) and performs an atomic comparison with the `hasPassedFunctionListSize` of the previous best version stored in the version manager. If `hasPassedFunctionListFinalySize` < `hasPassedFunctionListSize`, even if the overall number of errors decreases, as long as any previously passed test method turns red, the system directly determines "quality regression".

[0166] Macro-log level lock (testFilterScoreAndRollbackIfNeeded): The system automatically condenses the structured error signals generated by the logging process and maps them to a quantified "error score" (e.g., NPE scores 10 points, SQL exception scores 8 points, and ordinary assertion failure scores 5 points). This score is stored along with the version snapshot. If the new version's newScore > the previous best version's prevScore, it is considered a "macro-quality regression."

[0167] Anti-degradation and version rollback: If a "quality regression" is detected, the system immediately triggers RollbackToBestVersion to revert to the local best version. The system has a ContinuousRollbackCount counter. When ContinuousRollbackCount reaches a threshold (e.g., 2 times), the rollback will use the isLastBanBen=true strategy, that is, calling WebTestCodeVersionManager.rollbackToPrevious(true) to skip the most recently saved inferior version and directly restore to an earlier healthy version. Algorithmically, the version manager maintains a versionChain linked list. rollbackToPrevious(true) will move the currentVersion pointer forward by two nodes. Of course, there is a pointer out-of-bounds check to prevent null pointer exceptions. Any code that fails the double anti-degradation lock verification is discarded in a temporary memory buffer and is prohibited from being persisted to disk or written to the Git repository, thus ensuring the absolute purity of the main branch.

[0168] 7. Automatic / manual expert solution search and automatic / manual registration mechanism for persistent problems

[0169] Automatic / Manual Expert Solution Search: When the system fails to return `runTestAndFilterLogForBusiness` in `HasNotYuFaErrorStep3_Step8` (runtime error repair process), it first queries the local database `expert_solution_db`. The query key is the hash value of `error_type` + `root_cause_summary`. If a historically successful repair solution (including the repaired code diff) with a confidence level higher than the threshold (e.g., 0.8) exists, the system directly applies the solution, skipping the current large model repair call. If no solution is found, the large model is called for analysis. If the large model repair fails, the system automatically prepares a complete "help package," including `FiveLayerContext`, condensed logs, a list of attempted repair solutions, and the instruction file for this repair. The status is changed to "requires manual intervention," and the current module task is paused, awaiting external input.

[0170] Automatic registration of persistent issues: The system has a StubbornProblemRegistry. Whenever an error issue (uniquely identified by error_type + error_location) remains unresolved after a preset maximum number of retries (e.g., the M2 configuration variable or 5 times), the registry automatically serializes the issue and its complete context (same as the "help package" above) into JSON format, writes it to the local "stubborn issue database" stubborn_issues.jsonl, and sends an alert message via a pre-configured webhook (e.g., DingTalk, Slack, WeChat Work). This issue database allows developers to review the system offline and insert the corresponding solutions as new records into expert_solution_db, enabling the system to self-evolve.

[0171] 8. Dynamic multi-model hot-swap routing based on failure threshold

[0172] The system abstracts multiple large models (such as Kimi, GLM, DeepSeek, Qwen) into pluggable "dry batteries" and implements an automatic backup switching and intelligent optimization guarantee mechanism through unified adapter layer calls.

[0173] Circuit breaker monitoring: AIModelSmartSwitcher continuously monitors ContinuousRollbackCount. At the end of the startAModuelCodeGenerator loop, a decision is executed: if (ContinuousRollbackCount % M1 == 0 && ContinuousRollbackCount >= M1) (if M1 is a configuration variable or 3 times).

[0174] Dynamic routing: After a switch is triggered, the scheduler modifies the `modelName` variable in memory within milliseconds (e.g., from "glm" to "kimi-k2.5"). Without interrupting the main `while` loop or restarting the JVM process, when the next loop execution reaches the code generation branch, `if(modelName.equals("kimi"))` takes effect, and subsequent requests are seamlessly routed to `MoonshotKimiClient`. Internally, the system maintains a `ModelPerformanceRecord` that records win rates by dimension (`businessModule`, `modelName`), enabling intelligent selection and load balancing based on historical win rates.

[0175] This process can monitor the number of consecutive model failures, seamlessly switch to a backup model within milliseconds once the target is reached, and record the historical performance of each model to intelligently select the optimal model, ensuring that the code generation service is uninterrupted, stable and efficient.

[0176] 9. Dynamic Multi-Model Routing Module

[0177] This module begins by entering the repair loop, initializing the local variable `modelName` to 'glm' and `ContinuousRollbackCount` to 0. It then calls the current model through the unified adapter layer to execute the AI ​​repair task. When evaluating the repair results, if the quality improves, it's considered a pass; `ContinuousRollbackCount` is reset to zero, and the code is preserved. If the quality deteriorates or the repair is ineffective, it's considered a failure; `ContinuousRollbackCount` is incremented by 1. When `ContinuousRollbackCount` ≥ 3, a circuit breaker switching mechanism is triggered. The failure status of the current model for this module is recorded, and a backup model is selected from the model pool (Kimi / GLM / DeepSeek / Qwen). The selection strategy includes using the highest historical win rate or sequential polling. `modelName` is updated, the failure count is reset to zero, and the repair process continues in a loop.

[0178] If the repair is successful, the quality is improved, and the consecutive rollback count is reset to zero. If it fails, the count is incremented by 1. When the consecutive rollback count is ≥3 and a multiple of M1, the `recordAndRecommend` method of the singleton `AIModelSmartSwitcher` is called, passing in detailed context (business module name, current model, number of repairs). The internal logic first marks the current model as having failed 3 times consecutively for this module, then selects a new model (e.g., kimi-k2.5) based on historical win rate or cooldown time, returns the new model name string and overwrites the local variable `modelName`, achieving seamless hot switching between multiple models.

[0179] The switching trigger condition for this module is a multiple of ContinuousRollbackCount ≥ M1, where M1 is a dynamically configured positive integer. The specific value at runtime is dynamically adjusted based on the average of multiple generated program quality scores. This dynamic adjustment mechanism ensures the rationality of the switching threshold, avoiding over-switching or under-switching issues caused by a fixed threshold. By recording model failure states and selection strategies, this module can achieve seamless hot-switching of multiple models without interrupting the main workflow, improving the success rate of repairs.

[0180] Ultimately, this module employs a dynamic multi-model routing mechanism to automatically switch models when the number of consecutive failures reaches a threshold, while maintaining the continuity of the main workflow. By recording model failure states and selection strategies, this module can achieve seamless hot-switching of multiple models without interrupting the main workflow, improving the success rate of repairs. This mechanism not only improves repair efficiency but also enhances the robustness and adaptability of the system.

[0181] 10+ Node Sandbox Fusion Scheduling (Multi-Node Distributed Task Scheduling)

[0182] This module uses the Domain master node as the command center. The business requirement parser breaks down macro-level requirements into independent modules, which are then precisely distributed to each Node (e.g., Node 01 processes module A, Node 02 processes module B, etc.) via LAN RPC / Socket communication through the MultiNodeTaskDispatcher task splitting and distribution engine. Each Node has a closed pipeline consisting of a continuous polling and repair engine, a local Maven sandbox, and a version snapshot repository: the continuous polling and repair engine (e.g., startAModuelCodeGenerator) continuously generates and self-tests code, the Maven sandbox provides an isolated compilation environment, and the version snapshot repository temporarily stores iterative artifacts until the module compilation and testing are 100% successful before it can be released. A global status dashboard polls and monitors the pass rate of each module, providing a basis for scheduling decisions. After the target is met, the snapshot repository artifacts of each node are sent back to the master's Git Gitee API code recycling and merging machine, which merges the parallel results of multiple branches and forcibly pushes them to the Gitee remote repository for unified delivery via the Git API. The design uses sandbox isolation to ensure absolute reliability of single-module repair, distributed RPC scheduling to achieve parallel acceleration, and a mandatory compliance and forced merging mechanism to ensure the quality and performance of delivered code.

[0183] In the actual operation, the master node first receives business requirements, breaks down complex requirements into independently processable modular tasks using a business requirement parser, and then the MultiNodeTaskDispatcher allocates tasks based on node load and task characteristics, accurately distributing tasks to each Node node via local area network RPC / Socket communication. After receiving a task, each Node node starts its corresponding continuous polling and repair engine (such as startAModuelCodeGenerator), which continuously generates code and performs self-testing to ensure the correctness and completeness of the code. Simultaneously, a local Maven sandbox environment provides isolated compilation and testing environments, avoiding mutual interference between different modules. A version snapshot repository temporarily stores iteration artifacts in real time, recording every code modification and test result.

[0184] When a module's compilation and testing pass 100%, the artifacts in the version snapshot repository are marked as qualified and sent back to the Git Gitee API code recycling and merging unit on the master node. This merger is responsible for fusing qualified code from different nodes, ensuring code consistency and integrity. Subsequently, a forced push is performed via the Git API to merge the code into the Gitee remote repository, achieving unified code delivery. A global status dashboard plays a crucial role in this process, polling and monitoring the pass rate of each module, providing a basis for the master node's scheduling decisions, and ensuring efficient task execution and reasonable resource allocation.

[0185] During module repair, the continuous polling repair engine runs continuously, constantly generating and testing code until a 100% pass rate is achieved. This process ensures the absolute reliability and stability of the code. Simultaneously, the isolation features of the local Maven sandbox environment prevent mutual interference between different modules, improving the accuracy and efficiency of the repair process. The version snapshot repository's staging function allows each iteration of the code to be recorded and traced, facilitating subsequent code reviews and troubleshooting. The Git Gitee API code recycling and merging machine on the master node is responsible for integrating the qualified code from each node, ensuring code consistency and integrity, and finally forcibly pushing the merge to the remote repository via the Git API, achieving unified code delivery.

[0186] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An AI closed-loop generation-testing-repair system for fully automated programming in Spring Boot, characterized in that, It includes an automatic log condensation module, a multi-layer context construction module, a dual-track quality assessment and version management module, and a multi-node collaborative programming scheduling module; The automatic log condensation module is used to clean and intelligently condense the original operation logs, and call a lightweight large model to extract the top 3 error root causes. The multi-layer context construction module is used to reverse trace and construct a complete five-layer source code context (Test→Controller→Service→Dao→Mapper.xml) from the exception stack in one go, and to perform post-event compensation and completion of non-standard strings in MyBatis\JPA. The dual-track quality assessment and version management module is used to perform dual quantitative assessment based on "unit test pass rate" and "log error score", and to perform "zero degradation" version anti-lock and anti-shock rollback. The multi-node collaborative programming scheduling module is used to split tasks through the Domain master control, distribute them to the Node cluster via LAN RPC, and each node sandbox continuously repairs itself in a controlled polling state until it passes 100% or triggers a circuit breaker to exit. Then, the master control reclaims the code and forcibly pushes it to the remote repository.

2. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes an architecture compliance governance module, which is used to perform time and space judgment and cleaning of AI-generated code and JDBC architecture red line detection, automatically correct file directories and migrate non-compliant SQL statements to MyBatis's Mapper.xml file.

3. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes an automatic compilation and testing module, which automatically triggers incremental compilation and unit test execution after code changes, and captures compilation errors and runtime exceptions.

4. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes a graded syntax repair module, which classifies compilation errors into five levels, from Step 0 to Step 4, namely general syntax errors, interface contract errors, ORM mapping errors, data type mismatch errors, and dependency management errors. It performs isolation repair and incremental overwrite according to priority, and only repairs the highest priority error type at a time.

5. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes an automatic / manual expert solution search module, which is used to automatically / manually retrieve historical successful repair solutions from the local knowledge base when a runtime error occurs; during the search, the hash value of the error type and the root cause summary is used as the search key, and historical repair solutions with a confidence level higher than a preset threshold are directly reused.

6. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes an automatic / manual registration module for stubborn problems, which automatically registers problems that have not been resolved after more than a preset number of retries into the database and triggers an alarm.

7. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, The multi-layer context construction module includes a MyBatis XML\JPA post-compensation and completion unit. When regular expression matching fails, this unit reverse-engineers the class name and method name from the Dao layer code string, traverses the project XML file, matches by namespace and id, and completes the corresponding SQL nodes.

8. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, The anti-vibration rollback in the dual-track quality assessment and version management module adopts the isLastBanBen=true strategy, which skips the most recent inferior version and directly reverts to an earlier healthy version when two consecutive inferior versions appear.

9. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 1, characterized in that, It also includes a dynamic multi-model routing module, which is used to achieve seamless hot switching of multiple models based on a threshold of consecutive failures. The seamless hot switching trigger condition is that ContinuousRollbackCount ≥ M1 and is a multiple of M1, where M1 is a positive integer in the dynamic system configuration. The switching is achieved by modifying the routing configuration, without interrupting the main loop workflow or restarting the service process.

10. The AI ​​closed-loop generation-testing-repair system for fully automated programming in Spring Boot according to claim 4, characterized in that, The hierarchical syntax repair module performs incremental coverage: after the repair is completed, it only compares the change in the number of errors of the same type. If the number decreases, the new code is overwritten back to the reference directory as the benchmark for the next round of repair.

11. A fully automated AI-based closed-loop generation-testing-repair multi-node collaborative programming method for Spring Boot, applied to the system described in any one of claims 1-10, characterized in that... Includes the following steps: S101: AI generates initial business code for each node of a Spring Boot project; S102: Perform pre-check of architecture compliance, complete spatiotemporal judgment cleaning and JDBC architecture red line detection; S103: Save a version snapshot of the code after compliance processing; S104: Automatically triggers incremental compilation and executes project unit tests, capturing compilation errors and runtime exceptions; S105: The automatic log condensation module completes the automatic condensation of the operation logs and conducts a dual-track quality quantification assessment; S106: If the quality assessment result does not meet the standard, determine the error type: If there is a compilation error, proceed to step S107; if the compilation is successful but there is a runtime exception, complete the error type classification, and the multi-layer context construction module will build a complete five-layer code context at once, while completing the MyBatis XML statement\JPA post-compensation and completion. The five-layer complete source code context construction process is as follows: reverse trace from the exception stack to extract the source code content of the test class, controller, business service layer, data access layer, and MyBatis mapping file layer in sequence; S107: Perform hierarchical syntax isolation repair according to the priority of compilation error level. After the repair is completed, perform incremental coverage iteration and return to step S103 after the compilation error is cleared to trigger automatic testing to enter the runtime error repair branch. S108: Automatically retrieves the local expert solution library to match the corresponding repair strategy. If no matching solution is found and the repair fails, it automatically registers the stubborn problem and triggers an alarm. S109: Determine whether the number of consecutive rollbacks has reached a preset threshold. If the threshold is reached, perform dynamic multi-model seamless hot switching. S110: Execute circuit breaker judgment and resource reclamation: Determine whether the number of repair loops or the execution time of a single child process exceeds the extreme threshold: If a single execution times out, force KILL to hang the child process and reclaim resources, and count the loop as a failure; If the cumulative number of loops exceeds the extreme threshold, break out of the controlled polling loop, trigger a full code rewrite as a fallback operation, or downgrade and suspend for manual intervention; If the threshold is not exceeded, return to step S103 to continue the closed-loop repair process; S111: Multi-node Sandbox Fusion Scheduling: The Domain master splits tasks and distributes them to the Node cluster via LAN RPC. Each node sandbox continues to repair under controlled polling until it passes 100% or triggers a circuit breaker to exit. Then, the master reclaims the code and forcibly pushes it to the remote repository.

12. The AI ​​closed-loop generation-testing-repair multi-node collaborative programming method for fully automated Spring Boot programming as described in claim 11, characterized in that, In step S111, the multi-node sandbox fusion scheduling is coordinated by the Domain master, Node cluster, and remote repository to form a "split-melt-unify" closed loop: the master node parses the requirements and splits them into modules, and distributes the module tasks to the Node nodes via RPC. The Node nodes execute steps S103-S110 in a controlled polling manner in the local sandbox. The master process monitors the execution of child processes for timeouts and performs forced kill recycling to prevent resource exhaustion. When the module pass rate reaches 100% or triggers an extreme rewrite threshold, the polling ends. After the target is met, the master node reclaims the code and merges it.

Images