Code deployment verification method, device, equipment, medium and program product

Abstract

The embodiment of the specification provides a code deployment verification method, device, equipment, medium and program product, wherein the code deployment verification method comprises the following steps: retrieving a historical logical function unit in a vector knowledge base based on a code generation requirement, inputting the historical logical function unit into a large language model to generate a to-be-verified code; compiling the to-be-verified code into a target file, and incrementally loading the target file to a running environment; in the running environment, performing a test on the target file to obtain a verification result; in the case that the verification result is passed, generating an updated logical function unit based on the to-be-verified code, and updating the vector knowledge base based on the updated logical function unit. A closed-loop automatic evolution mechanism from code generation, hot deployment to verification optimization is established, and the problem that the generated business logic is disconnected with the actual running environment is alleviated.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and in particular to a code deployment verification method, apparatus, device, medium, and program product. Background Technology

[0002] With the rapid development of artificial intelligence and large language model technology, software systems have an increasing demand for automated generation and dynamic updating of business functions, and traditional development models are struggling to meet the requirements of high-frequency iterative business responses.

[0003] Existing code generation solutions mostly rely on static deployment or manual intervention, lacking a mechanism to seamlessly integrate the generated code into the running system, and cannot continuously optimize the generation quality based on actual running feedback. This results in the generated business logic being disconnected from the actual running environment, making it difficult to achieve a closed-loop automated evolution from code generation and hot deployment to verification and optimization. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a code deployment verification method. One or more embodiments of this specification also relate to a code deployment verification apparatus, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0005] According to a first aspect of the embodiments of this specification, a code deployment verification method is provided, comprising: Based on the code generation requirements, historical logical functional units are retrieved from the vector knowledge base, and the historical logical functional units are input into the large language model to generate code to be verified. The code to be verified is compiled into an object file, and the object file is incrementally loaded into the runtime environment; In the runtime environment, tests are performed on the target file to obtain verification results; If the verification result is successful, an update logic function unit is generated based on the code to be verified, and the vector knowledge base is updated based on the update logic function unit.

[0006] According to a second aspect of the embodiments of this specification, a code deployment verification apparatus is provided, comprising: The retrieval module is configured to retrieve historical logical functional units from the vector knowledge base based on code generation requirements, and input the historical logical functional units into the large language model to generate code to be verified. The compilation module is configured to compile the code to be verified into object files and incrementally load the object files into the runtime environment; The testing module is configured to perform tests on the target file in the runtime environment to obtain verification results; The update module is configured to generate an update logic function unit based on the code to be verified if the verification result is passed, and then update the vector knowledge base based on the update logic function unit.

[0007] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above-described code deployment verification method.

[0008] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the code deployment verification method described above.

[0009] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the code deployment verification method described above.

[0010] One embodiment of this specification implements the following: retrieving historical logical functional units from a vector knowledge base based on code generation requirements; inputting the historical logical functional units into a large language model to generate code to be verified; compiling the code to be verified into an object file and incrementally loading the object file into the runtime environment; performing tests on the object file in the runtime environment to obtain verification results; if the verification results are satisfactory, generating updated logical functional units based on the code to be verified, and updating the vector knowledge base based on the updated logical functional units.

[0011] By retrieving historical logical functional units from the vector knowledge base and inputting them into a large language model to generate code to be verified, seamless integration between the generated code and the running system is achieved. Dynamic updates are supported by compiling the code to be verified into object files and incrementally loading them into the runtime environment. Verification results are obtained by executing tests in the runtime environment, and when verification is successful, updated logical functional units are generated based on the code to be verified to update the vector knowledge base. This establishes a closed-loop automated evolution mechanism from code generation, hot deployment to verification optimization, alleviating the problem of the disconnect between generated business logic and the actual running environment. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating a code deployment verification method provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating the processing procedure of a code deployment verification method provided in one embodiment of this specification; Figure 3This is a schematic diagram of the structure of a code generation, deployment, and verification closed-loop automated system provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the workflow of a code generation, deployment, and verification closed-loop automated system provided in one embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a code deployment verification device provided in one embodiment of this specification; Figure 6 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0013] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0014] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0015] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0016] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0017] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0018] Operator: In the fields of artificial intelligence and deep learning, an operator is the smallest functional unit that performs a specific computational task. Its input and output are usually tensors, which are used to implement basic or complex mathematical operations such as matrix multiplication, convolution, and activation functions. It is a core component of building the computational graph of a neural network model.

[0019] As enterprise application systems continue to expand in scale and business iterations accelerate, Java, as a mainstream backend development language, faces severe challenges in terms of code development efficiency, maintainability, and high availability. Traditional manual coding methods are no longer sufficient to meet the high-frequency and ever-changing business needs, necessitating the use of automation to improve the efficiency of Java code generation and deployment flexibility.

[0020] Against this backdrop, the industry has placed higher demands on Java code automation generation technology: it must not only support rapid response to business changes and generate functional code that conforms to specifications, but also have high reusability, hot update capability and reliable verification mechanism to ensure that the system can complete functional evolution without downtime and continuously optimize the generation quality.

[0021] Current automation solutions attempt to generate Java code using template engines, rule engines, or large language model-based technologies, which can reduce manual coding workload to some extent and output specific functional modules through predefined structures.

[0022] However, existing Java code generation systems still have significant technical shortcomings: the generated code is mostly one-time code, only matching the current single task scenario and lacking general reusability; code updates depend on system shutdown and restart, which can easily cause business interruptions and cannot meet the requirements of high availability scenarios; the generation accuracy is insufficient, making it difficult to accurately match the actual business logic, and often requiring a lot of manual adjustments before it can be put into use; the testing process is cumbersome, requiring the separate writing and execution of unit test cases, which is inefficient and prone to missing boundary scenarios and multi-unit linkage issues; more importantly, the system lacks a closed-loop optimization mechanism—test results cannot be effectively fed back to the code generation stage, making it difficult to continuously iterate and improve the generation quality, and at the same time, it is impossible to obtain actual usage feedback of the generated code, and cannot optimize subsequent generation logic based on user usage.

[0023] This specification provides a code deployment verification method, and also relates to a code deployment verification device, a computing device, a computer-readable storage medium, and a computing program product, which will be described in detail in the following embodiments.

[0024] See Figure 1 , Figure 1 This is a flowchart of a code deployment verification method provided in one embodiment of this specification, specifically including the following steps 102-108.

[0025] Step 102: Based on the code generation requirements, retrieve historical logical functional units from the vector knowledge base, and input the historical logical functional units into the large language model to generate code to be verified.

[0026] Code generation requirements are natural language or structured instructions that describe the functionality of the task to be implemented. These instructions trigger the system to match relevant historical logical functional units in the vector knowledge base. For example, a user input such as "Implement an HTTP request encapsulation operator that supports timeout retries" constitutes a code generation requirement.

[0027] Historical logical functional units are reusable functional operators that have been verified and stored in the vector knowledge base within the system. Each operator corresponds to a code snippet with clearly defined input / output interfaces and internal implementation logic. For example, a "JSON parsing and validation operator" or an "asynchronous task scheduling operator" that has completed testing can be retrieved and referenced as a historical logical functional unit.

[0028] In practical applications, the system first receives the code generation request submitted by the user, performs semantic parsing and vectorization on the request, and generates a corresponding query vector. Then, the system performs a similarity search in the vector knowledge base based on this query vector, returning one or more historical logical functional units that are semantically closest to the current task. These historical logical functional units not only contain code content but also include meta-information such as their functional descriptions, interface definitions, and usage context. The system assembles the retrieved historical logical functional units along with the original code generation request into input prompts for the large language model. The historical logical functional units serve as contextual examples or reference templates, guiding the model to generate verification code that conforms to system specifications and existing architectural styles.

[0029] For example, in a Java microservice development task, the developer submits a code generation requirement: "Create a remote call operator with a circuit breaker mechanism." After vectorizing this requirement, the system retrieves three highly similar historical logical functional units from the vector knowledge base: the first is a "basic HTTP client encapsulation operator," the second is a "circuit breaker state management operator," and the third is a "service degradation response construction operator." The system concatenates the complete code and functional descriptions of these three operators into a context, which, together with the original requirement, forms a prompt-word input large language model. Based on this, the model generates a new operator code that integrates HTTP call, circuit breaker judgment, and degradation logic. This code reuses the exception handling mode and configuration reading method of the existing operator and follows the unified logging specifications of the project. The generated code does not directly copy any historical operator, but rather combines and adapts them to form structurally consistent and interface-compatible code to be verified, laying the foundation for subsequent compilation and hot deployment.

[0030] Furthermore, based on the code generation requirements, historical logical functional units are retrieved from the vector knowledge base, including: obtaining the code generation requirements; filtering out redundant information in the code generation requirements to obtain pure requirement text; calling a text vectorization model to convert the pure requirement text into requirement semantic vectors, wherein the requirement semantic vectors are used to represent the semantic features of the code generation requirements; and retrieving at least one historical logical functional unit from the vector knowledge base that meets the similarity threshold with the semantic features based on the semantic features.

[0031] Pure requirement text consists of the core functional instructions retained after removing modifiers, repetitive expressions, and non-functional descriptions from the original code-generated requirements. For example, the statement "Generate a filter operator for me. The input is all currently recalled published content, including video and image / text types. The logic is to filter out all image / text published content and keep only video published content" becomes "Filter published content, keep video type, remove image / text type" after redundant information filtering, which is the pure requirement text.

[0032] The requirement semantic vector is a high-dimensional numerical representation obtained by encoding pure requirement text through a text vectorization model. It is used to accurately characterize the functional semantic features of code generation requirements in vector space. For example, the 1024-dimensional floating-point array generated after encoding the pure requirement text through the BGE-M3 model is the requirement semantic vector.

[0033] In practical applications, the system first receives the code generation requirements submitted by the user and calls the pre-built text cleaning module to perform redundant information filtering, removing colloquial expressions, punctuation marks, example data, and contextual descriptions irrelevant to the function, outputting a clear and pure requirement text. Subsequently, the system calls a text vectorization model to encode this pure requirement text, generating a corresponding requirement semantic vector. Next, using this requirement semantic vector as the query anchor, the system calculates its cosine similarity with the semantic vectors of all historical logical functional units in the vector knowledge base, and selects candidate units with similarity values ​​greater than or equal to a preset threshold (e.g., 0.85) as the search results. For the step "retrieving from the vector knowledge base based on semantic features," one option is to use a brute-force search to compare all vectors one by one to ensure recall completeness; another option is to perform an approximate nearest neighbor search based on the HNSW index, controlling the retrieval latency to within 10 milliseconds while ensuring a recall rate of over 95%.

[0034] In the embodiments of this specification, through two-level processing of redundancy filtering and semantic vectorization, the retrieval process focuses on the functional essence rather than the surface wording, which significantly improves the ability to accurately match historical logical functional units.

[0035] For example, in the development task of a content recommendation system, the developer submits a code generation requirement: "Generate a filtering operator, the input of which is all published content with current recall, the published content types include video and text / image, the logic is to filter all published content of text / image type and retain all published content of video type." The system first performs redundant information filtering, identifying and removing redundant phrases such as "with current recall" and "published content types include", as well as the repeated subject "published content", to obtain the pure requirement text "filter published content, retain video, remove text / image". Next, the system calls the locally deployed text-embedding-v3 model to convert the pure requirement text into a 768-dimensional requirement semantic vector. Subsequently, the system performs a similarity search in a vector knowledge base containing 320 verified operators, setting a threshold of 0.82. The search returns two historical logical functional units that meet the conditions: the first is a "multimedia content type filter operator", with a similarity of 0.91, whose original function description is "filter video resources by the content_type field"; the second is a "general list element conditional filter operator", with a similarity of 0.84, which supports custom predicate expressions. Both operators are incorporated into the context input of the subsequent large language model. The first operator with high similarity serves as the main reference template, guiding the model to generate new filtering operator code that conforms to the existing content processing pipeline interface specifications, thus avoiding the need to build type judgment logic from scratch.

[0036] Furthermore, before retrieving historical logical functional units from the vector knowledge base based on code generation requirements, the process includes: scanning multiple logical functional unit code files in the code base that conform to the preset logical functional unit specifications, where each logical functional unit code file is an independent functional unit that implements the target business logic; extracting the original materials of each logical functional unit code file, where the original materials include the logical functional unit source code, code comments, and associated functional description documents, which are used to fully represent the semantic information of the corresponding logical functional unit; using a text vectorization model to convert the logical functional unit source code, code comments, and associated functional description documents of each logical functional unit code into logical functional unit semantic vectors; associating the logical functional unit semantic vectors of each logical functional unit with the logical functional unit identifier and storing them in the vector database, and establishing an index to obtain the vector knowledge base.

[0037] The raw material is a collection of multimodal information extracted from the code files of logical functional units to fully characterize their functional semantics, including the source code ontology, inline comments, and externally associated functional description documents. For example, the method implementation code in VideoContentFilter.java, Javadoc comments, and the video_filter_spec.md document stored in the docs directory together constitute the raw material of this operator.

[0038] In practical applications, the system first scans the code repository according to predefined logical functional unit specifications (such as interface contracts, naming rules, and directory structures) to identify all logical functional unit code files that meet the criteria. For each identified file, the system automatically parses and extracts its original materials: reading the source code text, parsing comment blocks, and locating the associated functional description document based on the file path or metadata index. Subsequently, the system concatenates these three types of original materials into a unified semantic input and calls a text vectorization model to generate the corresponding logical functional unit semantic vector. Finally, the system binds this semantic vector to the unique identifier of the logical functional unit (such as a file hash or registration ID), writes it into the vector database, and builds an efficient retrieval index, thereby completing the initialization or incremental update of the vector knowledge base. For the step "converting the original materials into semantic vectors," one option is to encode the source code, comments, and documents separately and then weightedly fuse them to preserve the semantic contributions of each modality; another option is to concatenate the three types of materials into a single text sequence according to a fixed template and then encode them as a whole to capture cross-modal contextual relationships.

[0039] In the embodiments described in this specification, normalized scanning and multi-source semantic fusion are used to ensure that each historical operator in the vector knowledge base has a complete, accurate and searchable semantic representation, laying a data foundation for subsequent accurate matching.

[0040] For example, when building the vector knowledge base of the content recommendation system, the system scans all Java files in the codebase that implement the ContentFilter interface and finds that VideoContentFilter.java conforms to the preset logical functional unit specification. The system then extracts its original materials: the source code contains the type judgment logic if (content.getType() ==ContentType.VIDEO); the Javadoc comments state that "only video type content is retained, and images and other formats are filtered"; the associated document video_filter_spec.md further explains that this operator is suitable for the recall stage, supports batch processing, defines input and output fields, and specifies performance constraints. The system concatenates these three parts in the format "[CODE]...[COMMENT]...[DOC]..." and inputs them into the text-embedding-v3 model to generate a 768-dimensional logical functional unit semantic vector. This vector is associated with the identifier filter:video:v2.1 and stored in the Milvus vector database and included in the HNSW index. When developers subsequently submit code generation requests for "filtering published content, retaining videos, and removing images and text," the system can accurately target this operator through the aforementioned retrieval process, because its semantic vector fully carries the core intent of type filtering and the project context, rather than relying solely on code keyword matching.

[0041] Furthermore, the historical logical functional units are input into the large language model to generate code to be verified, including: obtaining system instructions, wherein the system instructions are used to define the basic rules that the generated logical functional unit code must follow; obtaining output requirements defined by the front end, wherein the output requirements are used to constrain the generation method of the code to be verified; obtaining historical generation feedback information, wherein the historical generation feedback information consists of test results obtained from testing the historical generated code and the historical generated code; concatenating the system instructions, code generation requirements, historical logical functional units, output requirements, and historical generation feedback information in a preset order as model input; and inputting the model input into the large language model to generate code to be verified.

[0042] System instructions are a set of predefined global rules used to define the architectural specifications, security guidelines, and coding styles that must be followed when generating logical functional unit code. For example, "all filtering operators must implement the ContentFilter interface, logging using System.out is prohibited, and input parameters must be validated for non-empty values" are specific examples of system instructions.

[0043] The output requirements defined by the front-end are code generation constraints explicitly specified by the user or upstream system in the interactive interface, used to control the structure, language version, or delivery format of the code to be verified. For example, "generate Java 17 code, return type List, and include unit test methods" is an output requirement.

[0044] Historical generation feedback information consists of test verification records and the original code text of code generated in the past for the same or similar code generation requirements. It is used to provide positive and negative samples to the model to avoid repeating errors. For example, if a null pointer exception occurred when generating a "video content filter" in the last time due to the failure to handle null type fields, the failure test result and the corresponding error code constitute historical generation feedback information.

[0045] In practical applications, the system first loads pre-configured system instructions to ensure that the generation behavior conforms to the platform's basic specifications. Simultaneously, it receives output requirements from the front end, clarifying the specific delivery standards for this generation. Next, it retrieves historical generation feedback information from the feedback storage that is semantically similar to the current code generation requirements, extracting test result summaries and problematic code snippets. Subsequently, the system concatenates these parts into a structured model input in a fixed order: "system instructions → code generation requirements → historical logical functional units → output requirements → historical generation feedback information." Finally, this model input is fed into a large language model, which comprehensively understands the specifications, requirements, reference operators, format constraints, and historical lessons learned to generate the expected code to be verified. For the step "concatenating into model input in a preset order," one option is to use delimiters to explicitly distinguish each semantic block to enhance the model's ability to parse context; another option is to convert each part into a key-value pair JSON structure input to improve the structure alignment accuracy of multi-source information.

[0046] In the embodiments described in this specification, by integrating four contexts—system-level rules, user-level constraints, historical references, and error correction feedback—the large language model is made to possess standardization, adaptability, and evolutionary potential when generating code to be verified, significantly improving the quality of the first generation.

[0047] For example, in a content recommendation system, after a developer submits a code generation requirement to "filter published content, retain videos, and remove images and text," the system retrieves the historical logical functional unit "VideoContentFilter v2.1." The system then obtains the system instructions: "Implement the ContentFilter interface, disable reflection, and add the @Nullable annotation"; obtains the front-end output requirements: "Java 17, method name filterVideos, return ImmutableList"; and extracts the failure record from the feedback library when generating the same operator last time: "Test case testNullContentType failed, reason: null value protection for content.getType() was not implemented, throwing a NullPointerException." The system concatenates the above five parts into a complete prompt in a preset order, with the historical generation feedback information embedded in the form of "[Historical Error Warning] The last generated code caused an NPE because it did not check whether the return value of getType() was null. Please be sure to add null value checks." The new code generated by the large language model not only implements the core logic of video filtering, but also automatically adds defensive code such as `if (content== null || content.getType() == null) return ImmutableList.of();`, strictly adhering to the interface signature and immutable collection return requirements. After this code entered the testing phase, the previously failed null type test cases passed successfully, increasing the verification pass rate from 83% to 100%, effectively avoiding the cost of repeated debugging.

[0048] Furthermore, before concatenating system instructions, code generation requirements, historical logical functional units, output requirements, and historical generation feedback information into model input in a preset order, the process includes: selecting a logical functional unit code template matching the code generation requirements from a preset logical functional unit template library as supplementary reference information; obtaining preset logical functional unit specification information, wherein the logical functional unit specification information is obtained by parsing the logical functional unit framework specification document and is used to constrain the structure and interface of the generated logical functional unit code; concatenating system instructions, code generation requirements, historical logical functional units, output requirements, and historical generation feedback information into model input in a preset order, including: based on the logical functional unit specification information, concatenating system instructions, code generation requirements, historical logical functional units, supplementary reference information, and output requirements into model input information in a preset order; and providing the model input information to the large language model to generate verification code that conforms to the structure and interface constrained by the logical functional unit specification information.

[0049] The logical function unit code templates are pre-built skeleton code sets matched to specific business scenarios, stored in the template library. They include standard class structures, necessary annotations, and placeholder method bodies to provide a populateable code paradigm. For example, for the "content filtering" requirement, the template library contains AbstractContentFilterTemplate.java, which already defines implementsContentFilter, the @Component annotation, and filter(List <content>The method signature is empty except for the core judgment logic. This file is the code template for the logical function unit.

[0050] The logical functional unit specification information consists of structured constraint rules automatically parsed from the framework documentation (such as ContentFilter_Framework_Guide.md), which clearly define mandatory clauses such as interface contracts, lifecycle hooks, and exception handling requirements. For example, after parsing, items such as "all filters must override the validateInput() method", "the return value cannot be null", and "I / O operations are prohibited within the filter method" constitute the logical functional unit specification information.

[0051] In practical applications, before assembling the model input, the system first matches the most relevant code template in the logical functional unit template library as supplementary reference information based on the semantic features of the code generation requirements. Simultaneously, it loads and parses the currently effective logical functional unit framework specification document to extract the latest specification information. Subsequently, using the logical functional unit specification information as the top-level constraint benchmark, the system organizes system instructions, code generation requirements, historical logical functional units, supplementary reference information, and output requirements into structured model input information in a preset order, ensuring that each part conforms to the code structure and interface contract defined by the specification. Finally, this model input information is fed into the large language model, ensuring that it strictly follows the template skeleton and specification clauses during the generation process, producing verifiable code that conforms to the platform integration standards. For the step "assembling model input based on logical functional unit specification information," one option is to convert the specification information into validation rules and embed them in the prompt word header, forcing the model to comply first; another option is to merge the specification information and template into a complete, annotated example code block, implicitly passing constraints through contextual demonstration.

[0052] In the embodiments of this specification, by introducing dynamically matched templates and real-time parsed specification information, the generation behavior of the large language model is anchored to the actual engineering requirements of the current technology stack, avoiding structural errors caused by knowledge lag or generalization bias.

[0053] For example, in a content recommendation system, when a developer submits a code generation requirement to "filter published content, retain videos, and remove images and text," the system, in addition to retrieving the historical operator VideoContentFilter v2.1, also matches AbstractContentFilterTemplate.java from the template library as supplementary reference information; simultaneously, it parses the latest version of ContentFilter_Framework_Guide.md to obtain specification information: "From v3.0 onwards, the filter method must return ImmutableList" and "A new preFilterHook() lifecycle method has been added." The system places the above specification information at the forefront of the model input, and then sequentially concatenates system instructions, code generation requirements, historical logic functional units, template code, and front-end output requirements. The code to be verified generated by the large language model not only reuses the video judgment logic of the historical operator, but also automatically inherits the @Component annotation and the implements ContentFilter declaration in the template, and strictly implements the empty preFilterHook() method and the return encapsulation of ImmutableList.copyOf() according to the v3.0 specification. In subsequent automated tests, the code passed both interface compatibility checks and lifecycle hook call verification on the first try, without requiring rework or modification due to framework upgrades.

[0054] Furthermore, obtaining historical generation feedback information includes: obtaining historical verification results obtained by performing tests on historically generated code; if the historical verification result characterization test fails, using the failure details in the verification result and the historically generated code as historical generation feedback information; if the historical verification result characterization test succeeds, updating the original material of the historically generated code to the vector knowledge base.

[0055] Historical verification results are structured judgment data obtained after executing automated test suites on historically generated code. They include pass / fail status, exception stack traces, assertion failure information, and coverage metrics. For example, for a particular generated VideoContentFilter code, a test framework returning "FAIL: testNullContentType - Expected noexception but got NullPointerException at line 42" is a historical verification result.

[0056] Failure details are diagnostic information extracted from historical validation results to pinpoint the root cause of the problem, including the error type, triggering condition, relevant line number, and context variable status. For example, the failure details for the NullPointerException mentioned above can be interpreted as "content was not validated as null before the content.getType() call, triggered when the input list contains empty elements".

[0057] In practical applications, the system first obtains historical verification results from testing the historically generated code. If the result indicates a test failure, the system automatically extracts the failure details and the corresponding original text of the historically generated code, combining them into historical generation feedback information for use as a negative sample warning during subsequent code generation. If the result indicates a test success, the historically generated code is treated as a high-quality logical functional unit, and its source code, comments, and related documents are extracted again and updated to the corresponding semantic vector record in the vector knowledge base, ensuring that the knowledge base always reflects the latest and verified implementation version. For the step "using the failure details and historically generated code in the verification results as historical generation feedback information," one option is to retain only the most recent N failure records to control the length of the prompt words; another option is to cluster the summary by error type to avoid repetitive and redundant descriptions of the same defects.

[0058] In the embodiments of this specification, by establishing a closed-loop mechanism of "feedback upon failure and entry into the database upon success", the code generation system has both error avoidance capability and knowledge self-evolution capability, continuously improving the generation quality and the freshness of the knowledge base.

[0059] For example, in a content recommendation system, after a developer submitted a requirement to "filter published content, retain videos, and remove images and text," the system generated the VideoContentFilter v2.1 code. After automated testing, historical verification results showed that the "testNullContentType" test case failed, with the failure details explicitly stating that "line 42, content.getType(), did not have null value protection." The system then packaged this failure detail along with the original v2.1 code into historical generation feedback information, injecting it into the model input during the next generation of similar requirements, prompting the new code to add null checking logic. Subsequently, the fixed VideoContentFilter v2.2 passed all test cases, and historical verification results indicated success. The system immediately extracted the complete original materials for v2.2 (including the newly added null value validation code, the updated Javadoc, and the synchronously revised video_filter_spec.md), re-vectorized it, and overwrote the semantic records of the original v2.1 in the vector knowledge base. When there is a need for "video content filtering" again, the retrieved version will be the verified and semantically complete v2.2, which avoids the reproduction of historical NPE errors and ensures the engineering reliability of reusable code.

[0060] Step 104: Compile the code to be verified into an object file and incrementally load the object file into the runtime environment.

[0061] The code to be verified is the source code of a program generated by a large language model that has not yet been tested at runtime; its syntactic and logical correctness needs to be confirmed. For example, a Java class source code containing circuit breaker and retry logic is the code to be verified.

[0062] The target file is a binary or bytecode file generated by compiling the code to be verified, which can be directly loaded and executed in a virtual machine or runtime environment. For example, the .class file or the packaged .jar fragment generated after compiling Java source code is a target file.

[0063] In practical applications, after receiving the code to be verified, the system first calls the compiler to perform syntax checks and bytecode conversion, generating the corresponding target file. If compilation fails, the system sends error information to the code generation module to trigger regeneration; if compilation succeeds, it enters the incremental loading phase. The system dynamically loads the target file into the currently running process space through the runtime environment's class loading mechanism or modular hot-swap interface, replacing or adding corresponding functional operator instances without stopping or restarting the entire service.

[0064] For example, in a continuously running order processing system, the system generates Java operator code to be verified, used to optimize inventory deduction logic. The compilation module executes `javac` to compile the code, generating the corresponding `.class` object file and verifying its dependency integrity. Subsequently, the system injects the `.class` file into the JVM of the order service through a pre-configured hot deployment agent. Since this operator implements the same interface contract as the original inventory operation, the hot deployment agent registers it as the new implementation version and routes all subsequent inventory deduction tasks to the newly loaded object file. The entire process does not trigger a service restart, nor does it affect other order requests that are being processed. The original old version operator is safely unloaded after confirming there are no active references, and the new version operator immediately participates in the actual task execution, providing the test module with a real runtime context, enabling the verification results to accurately reflect its behavior in the production environment.

[0065] Furthermore, before incrementally loading the target file into the runtime environment, the process includes: encapsulating the target file into an independent loading package and generating a loading package identifier for the independent loading package; and transferring the independent loading package to a storage area accessible to the runtime environment.

[0066] A standalone loading package is a self-contained unit that encapsulates the target file and its necessary metadata (such as dependency declarations, checksums, and version numbers). It has integrity verification and self-description capabilities, ensuring that it can be independently parsed and loaded in any compatible runtime environment. For example, for a newly generated VideoContentFilter v2.2.java, the system packages it along with its corresponding interface definition, annotation processor configuration, and SHA-256 checksum into a video-filter-v2.2.lpkg file, which is the standalone loading package.

[0067] The load package identifier is a globally unique string assigned to each individual load package, used for precise indexing in the storage area, version management, and runtime referencing. For example, the system generates the identifier lpkg:content-filter / video / 2.2 / a1b2c3d4 based on the content hash and timestamp; this identifier is the load package identifier.

[0068] In practical applications, before incrementally loading the target file into the runtime environment, the system first encapsulates the target file, along with its minimum runtime dependencies and metadata, into an independent loading package. A unique loading package identifier is then generated based on the package content or business semantics. Subsequently, this independent loading package is uploaded to a shared storage area accessible to the runtime environment (such as object storage, NFS mount directories, or container image repositories), using the loading package identifier as a storage key or path component to ensure that subsequent loading operations can quickly and accurately retrieve the corresponding package body through the identifier. For the step "transferring the independent loading package to a storage area accessible to the runtime environment," one option is to use an atomic write mechanism (writing a temporary file first and then renaming it) to avoid package corruption caused by transmission interruptions. Another option is to trigger an event notification in the storage area after transmission is complete, allowing the runtime environment to actively pull the package instead of passively waiting, thus improving loading timeliness.

[0069] In the embodiments described in this specification, encapsulation and identification preprocessing enable the transmission and loading process of the target file to be atomic, traceable, and environmentally independent, laying the foundation for subsequent safe and reliable incremental loading.

[0070] For example, in a content recommendation system, after VideoContentFilter v2.2.java passes verification, the system encapsulates it along with the ContentFilter interface v3.0 definition, @Component annotation processor configuration, and build metadata into a separate loading package, video-filter-v2.2.lpkg, and generates a loading package identifier lpkg:content-filter / video / 2.2 / a1b2c3d4. Subsequently, the system atomically uploads this package to the shared OSS bucket of the runtime environment, with the storage path / runtime-packages / lpkg:content-filter / video / 2.2 / a1b2c3d4. When the runtime environment receives an incremental loading instruction, it only needs to pull the complete and verified .lpkg file from OSS based on this identifier, without needing to concern itself with the underlying Java source file path or manually handle dependencies. Even if multiple service instances concurrently execute loading, they can obtain a completely consistent package body through the same identifier, completely avoiding class loading anomalies caused by scattered files, version inconsistencies, or incomplete transmission, ensuring that the new filter takes effect synchronously and correctly on all nodes.

[0071] Furthermore, incrementally loading the target file into the runtime environment includes: obtaining an independent loading package from the storage area based on the loading package identifier; creating an independent class loader, loading the target file contained in the independent loading package through the independent class loader to obtain a logical functional unit instance, wherein the independent class loader is used to load new logical functional unit classes without affecting existing classes in the runtime environment; and incrementally integrating the logical functional unit instance into the runtime environment without interrupting existing services in the runtime environment.

[0072] An independent class loader is a custom class loader instance dedicated to loading a single, independent package. Its parent loader delegation strategy is configured to delegate only to core JDK classes and framework basic interfaces, while prioritizing loading business logic classes from within its own package. This achieves namespace isolation from the runtime environment's main class loader. For example, for video-filter-v2.2.lpkg, the system creates a FilterClassLoader@v2.2 instance. This loader only delegates java.* and com.platform.core.ContentFilter interfaces to its parent loader; all other classes are loaded autonomously from within the package, ensuring that new filter classes do not overwrite or interfere with already loaded v2.1 versions.

[0073] A logical functional unit instance is an executable object that conforms to the target interface contract, instantiated through reflection using an independent class loader, and possesses a complete lifecycle and runtime behavior. For example, after FilterClassLoader@v2.2 loads VideoContentFilter.class, the VideoContentFilter v2.2 object created through newInstance() is a logical functional unit instance, which has passed interface type checking and can safely participate in the content filtering chain.

[0074] In practical applications, the system first retrieves the corresponding independent loading package from the storage area based on the loading package identifier. Then, it dynamically creates a dedicated independent class loader for the package, and uses this loader to parse and load the target files within the package, generating a logical functional unit instance. Finally, without pausing or restarting any existing services in the runtime environment, the instance is registered to the service orchestration container or policy manager in a plug-in manner, completing incremental integration. For the step "incrementally integrating logical functional unit instances into the runtime environment without interrupting existing services," one option is to utilize the framework's hot-swappable SPI mechanism to dynamically add instances to the processor chain at runtime; another option is to push routing rule changes through the configuration center, ensuring that new instances only handle specified traffic while old instances continue to process existing requests, achieving seamless switching.

[0075] In the embodiments described in this specification, zero-downtime hot updates of logical functional units are achieved through class loader isolation and non-blocking instance injection, which not only ensures the continuity and stability of online services, but also supports fine-grained version evolution and rapid rollback in case of failure.

[0076] For example, in a content recommendation system, when the validated VideoContentFilter v2.2 needs to be deployed, the system pulls video-filter-v2.2.lpkg from the OSS storage based on the loading package identifier lpkg:content-filter / video / 2.2 / a1b2c3d4; then, it creates a FilterClassLoader@v2.2 independent class loader, loads VideoContentFilter.class from the package, and instantiates it to obtain a v2.2 logical functional unit instance. At this time, the v2.1 instance still handles all content filtering requests normally in the runtime environment, and the service is stable without any fluctuations. The system registers the v2.2 instance as a backup processor through the hot-swappable API of the content filtering framework and updates the routing policy synchronously: newly published text and image content still goes through v2.1, while video content is automatically routed to the v2.2 instance. The entire process does not trigger a JVM restart, does not interrupt any ongoing filtering tasks, and v2.1 and v2.2 are independent of each other due to class loader isolation. If unforeseen issues are subsequently discovered in v2.2, simply uninstalling FilterClassLoader@v2.2 and removing the routing rules will allow for a near-instant rollback to v2.1, with no disruption to the entire business process.

[0077] Step 106: In the runtime environment, perform tests on the target file to obtain verification results.

[0078] The verification result is the pass or fail judgment and associated diagnostic information obtained after executing preset test cases on the target file in the runtime environment. For example, a test returning "assertion successful, response time 85 milliseconds, no exception stack" constitutes a complete verification result.

[0079] In practical applications, after the target file is incrementally loaded, the system automatically triggers the test suite associated with that operator. The test suite includes various types of tests, such as unit tests, integration tests, and contract tests, covering normal paths, boundary conditions, and abnormal scenarios. The system instantiates the operator object corresponding to the target file in the current runtime context, injects simulated or real upstream and downstream dependencies, executes each test case sequentially, and captures the execution trajectory, return values, exception information, and performance metrics. All test results are aggregated into structured verification results to determine whether the operator meets the deployment criteria.

[0080] For example, in an e-commerce order fulfillment system, a newly loaded inventory deduction operator target file is automatically included in the testing process. The system first loads 30 test cases corresponding to the operator from the test resource library, including scenarios such as regular deduction, overselling protection, concurrency competition, and cache invalidation back to origin. The test engine creates an independent test context in the current JVM process, injects a mock database connection pool and message queue client, and executes the test cases one by one. 28 test cases pass the assertion, 1 test case fails due to an overly strict timeout threshold, and another test case triggers an unexpected null pointer exception. The system marks these three types of results as pass, configuration alert, and code defect, respectively, and attaches detailed execution logs and stack information. The testing process does not block the main business thread, nor does it modify any production data. The final verification result clearly indicates that the operator cannot be directly enabled at present and the null pointer exception must be fixed and the timeout parameters adjusted before entering the next round of verification.

[0081] Furthermore, in the runtime environment, tests are performed on the target file to obtain verification results, including: generating test cases for the code to be verified using a large language model; deploying the test cases to the runtime environment and initiating integration tests on the target file; collecting the output logs generated by the target file during the integration tests; and comparing the actual execution results reflected in the output logs with the preset expected outputs to obtain verification results.

[0082] Test cases are executable verification scripts automatically generated by the large language model based on the semantics of the code to be verified, interface contracts, and historical failure feedback. They include input construction, assertion conditions, and exception boundary coverage. For example, for VideoContentFilter v2.2, the model generates VideoContentFilterIntegrationTest.java, which includes test methods such as "the input list of videos containing null elements should return an empty ImmutableList" and "preFilterHook() must be called before filter()".

[0083] The output log is a structured execution trace captured in real time by the runtime environment during the integration test execution, including method call stacks, return value snapshots, exception stacks, and framework event notifications. For example, during test execution, entries such as "[INFO] preFilterHook invoked at 10:36:01.234" and "[DEBUG] filter returnedImmutableList(size=0) for input with null content" are collected.

[0084] In practical applications, the system first utilizes a large language model to generate targeted test cases based on the code to be verified, its associated specification information, and historical generation feedback information. Then, the test cases are deployed to the runtime environment along with the code to be verified (reusing the aforementioned independent class loader mechanism), triggering integration test execution. During testing, the system collects the output logs of the target file in real time through a log interceptor or AOP aspect. Finally, the actual execution results extracted from the logs (such as method call order, return type, and exception type) are compared in a structured manner with the preset expected output (derived from specification information and test case assertions), generating a verification result containing pass / fail status and details of the differences. For the step "comparing the actual execution results reflected in the output logs with the preset expected output," one option is to use regular expressions to extract key fields from the unstructured logs before comparison; another option is to embed log markers in the test cases, giving the output logs a naturally comparable structured format, improving comparison accuracy.

[0085] In the embodiments of this specification, by using the closed loop of test generation and runtime log comparison driven by LLM, automated and high-precision verification of the code to be verified in the real integration context is achieved. This not only makes up for the blind spots of static analysis, but also avoids the cost and omissions of manual testing.

[0086] For example, in a content recommendation system, when VideoContentFilter v2.2.java enters the verification phase as code to be verified, the system calls the large language model, combines the specifications in ContentFilter_Framework_Guide.md such as "from v3.0 onwards, the filter method must return ImmutableList" and "a new preFilterHook() lifecycle method has been added", and the historical generation feedback information of NPE caused by the failure to handle null content in v2.1, and automatically generates the VideoContentFilterIntegrationTest.java test case. This test case is deployed to the runtime environment, and the v2.2 code is loaded by FilterClassLoader@v2.2 to execute integration tests. During the test, the system collects the output logs: "[LIFECYCLE] preFilterHook called before filter" "[RETURN] ImmutableList.copyOf() wrapped result, size=0 for null-containing input". The system parses the logs and compares them with the expected output: confirming that the preFilterHook call sequence is correct, the return type is ImmutableList, null input processing is error-free, all assertions match, and the verification result is "PASS". If the logs show "filter returned ArrayList" or "preFilterHook not invoked", the comparison fails, the verification result is marked as "FAIL" with specific differences, and the subsequent historical feedback information generation process is triggered.

[0087] Furthermore, after performing tests on the target file in the runtime environment and obtaining verification results, the process also includes: obtaining feedback information if the verification result is unsuccessful; calling the large language model and generating a correction logic function unit based on the feedback information; generating the updated code to be verified based on the correction logic function unit, and returning to execute the step of compiling the code to be verified into a target file.

[0088] The feedback information is a collection of diagnostic data extracted from the verification results to guide code correction, including details of failed assertions, actual output log snippets, references to relevant specification clauses, and records of similar historical errors. For example, when the VideoContentFilter v2.2 integration test fails because "the filter method returns an ArrayList instead of an ImmutableList", the feedback information includes: "Assertion failed: expected ImmutableList but got ArrayList" "Log line: [RETURN] new ArrayList<>(filtered)" "Specification basis: ContentFilter_Framework_Guide.md §4.3 'From v3.0 onwards, filter() must return an ImmutableList'" "Historical reference: v2.1 was rejected because the return value was not wrapped".

[0089] The corrected logic functional unit is a semantically correct and specification-compliant logical implementation description generated by the large language model based on feedback information. It is usually expressed in the form of pseudocode, structured comments, or corrected instructions, rather than direct source code. For example, the model output corrected logic functional unit is: "At the end of the filter() method, wrap the existing ArrayList result with ImmutableList.copyOf() before returning it; ensure that all early return paths also apply this wrapping".

[0090] The updated code to be verified is a new version of the source code obtained by precisely modifying the original code to be verified based on the corrected logical functional units. The original structure is retained and only the defective parts are replaced to ensure minimal changes and traceability. For example, the system replaces `return filtered;` in the v2.2 code with `return ImmutableList.copyOf(filtered);`, and simultaneously corrects other `return` statements, generating `VideoContentFilter v2.3.java` as the updated code to be verified.

[0091] In practical applications, when the verification result is unsuccessful, the system automatically extracts structured feedback information. Then, it calls the large language model, inputting this feedback information along with the original code to be verified, associated specification information, and historically generated feedback information to generate a correction logic functional unit. Next, based on this correction logic functional unit, targeted modifications are made to the original code to generate updated code to be verified. Finally, this updated code is used as the new code to be verified, and the system returns to the step of "compiling the code to be verified into an object file," restarting the verification loop. For the step "generating updated code to be verified based on the correction logic functional unit," one option is to use an AST-level code transformation tool to ensure syntactic correctness and format consistency. Another option is to have the large language model directly output the complete corrected code snippet, and then have the system verify whether its diff with the original file strictly matches the correction logic functional unit, preventing excessive modification.

[0092] In the embodiments described in this specification, by constructing an automated error correction closed loop of "failure → feedback → correction → re-verification", the system is equipped with the ability to learn autonomously from runtime errors and accurately repair them, which significantly improves the first-pass yield of code generation and the reliability of engineering.

[0093] For example, in a content recommendation system, the integration test of VideoContentFilter v2.2 failed, with the verification result "FAIL: returnTypeMismatch". The system immediately extracted feedback information, including assertion messages, actual return type logs, the original text of ContentFilter_Framework_Guide.md §4.3, and historical feedback information generated for similar errors in v2.1. After calling the large language model, the corrected logic function unit was obtained: "All filter() exit points must use ImmutableList.copyOf() to wrap the return value". Based on this, the system performed an AST transformation on the v2.2 source code, replacing all return...; statements with return ImmutableList.copyOf(...);, generating VideoContentFilterv2.3.java as the updated code to be verified. This code was then recompiled into video-filter-v2.3.lpkg, deployed to the runtime environment, and the integration test was executed again. This time, the test log showed "[RETURN] ImmutableList.copyOf() applied, size=0", which was a perfect match to the expectation, and the verification result was "PASS".

[0094] Step 108: If the verification result is successful, generate an update logic function unit based on the code to be verified, and update the vector knowledge base based on the update logic function unit.

[0095] The update logic functional unit is a standardized functional operator that conforms to the system specifications and is transformed from the code to be verified after testing and verification. It has complete metadata and searchable semantic representation. For example, a piece of HTTP call code with circuit breaking that has passed all tests is encapsulated as a "circuit breaking remote request operator", which is the update logic functional unit.

[0096] A vector knowledge base is a structured retrieval space that stores historical logical functional units and their semantic vectors, supporting similarity matching based on natural language or code snippets. For example, an index containing 500 verified operators and their corresponding embeddings constitutes a vector knowledge base.

[0097] In practical applications, when the verification results show that the code to be verified meets all preset pass conditions, the system automatically initiates the knowledge accumulation process. First, the code to be verified is standardized, including supplementing interface documentation, extracting input and output signatures, labeling applicable scenarios, and encapsulating it into an update logic functional unit that conforms to the platform's operator standards. Then, the system jointly vectorizes the functional description and code structure of this update logic functional unit to generate a new semantic vector. Next, the system writes the complete content of the update logic functional unit to persistent storage and inserts the newly generated semantic vector into the vector knowledge base, while maintaining version association and dependency indexes to ensure that subsequent searches accurately retrieve the latest results.

[0098] For example, in a code generation task of an intelligent operations and maintenance platform, a generated "log masking and filtering operator" passed all 12 security and functional tests. The system then reads the code to be verified, automatically parses its method signature, parameter types, and return value structure, and generates a metadata document containing usage descriptions, usage restrictions, and configuration item descriptions based on a pre-set template. Next, the system combines the code and metadata into a complete update logic functional unit object and calls the platform's unified operator registration interface to complete the database entry. At the same time, the system extracts the functional summary text and core code snippets of the operator and inputs them into a multimodal embedding model to generate a 768-dimensional semantic vector. This vector, along with the operator's unique identifier, is appended to the HNSW index of the existing vector knowledge base without rebuilding the entire index structure. After the update is completed, when developers submit similar requests such as "implementing sensitive information masking processing," the system can retrieve this newly entered log masking and filtering operator within milliseconds and input it as a high-quality reference context into the large language model, avoiding generation from scratch and significantly improving response efficiency and output quality.

[0099] Furthermore, before updating the vector knowledge base based on the updated logical functional unit, the process includes: displaying the verification results and the generation process information of the code to be verified through a visual management interface; responding to the confirmation operation triggered by the target object on the visual management interface, executing the step of updating the vector knowledge base based on the verification results; or, responding to the modification operation triggered by the target object on the visual management interface, obtaining the adjustment instruction, adjusting the code to be verified according to the adjustment instruction, and re-executing the test based on the adjusted logical functional unit code.

[0100] The visual management interface is a graphical user terminal that provides a transparent view of the entire code generation process and interactive decision-making capabilities. It integrates verification result summaries, source code to be verified, a generation process traceability graph, and operation controls. For example, for VideoContentFilter v2.2, the left side of the interface displays "Verification Status: FAIL | Reason for Failure: filter() returns ArrayList", the right side highlights line 47 of the v2.2 source code, return filtered;, and the bottom presents the time consumption and input / output snapshots of each stage of "template matching → LLM generation → compilation → integration testing" in a timeline format.

[0101] The confirmation operation is an interactive action in which the target object, after reviewing the verification results and generation process, explicitly authorizes the system to write the current verification conclusion (whether it passes or fails) as valid feedback into the vector knowledge base. For example, if an auditor confirms that the failure of v2.2 is indeed due to a violation of the §4.3 specification, clicking the "Confirm Archive" button will trigger the confirmation operation.

[0102] The modification operation is an interactive action that proactively intervenes to adjust the code logic when the target object determines that the current code to be verified has a problem that the model cannot correct itself. The adjustment instructions triggered by this action include specific modification intentions or directly edited code snippets. For example, if an auditor finds that v2.2 returns the correct type but omits null protection for the video duration field, and this requirement is not reflected in the current specification document, the auditor can directly edit the code on the interface to add `if (video.getDuration()== null) return ImmutableList.of();` and click "Submit Modification" to trigger the modification operation and obtain adjustment instructions.

[0103] In practical applications, after obtaining the verification results, the system does not immediately update the vector knowledge base. Instead, it first pushes the verification results and the complete generation process information of the code to be verified to the visual management interface for the target object to review. If the target object triggers a confirmation operation, the system executes the step of updating the vector knowledge base based on the verification results, incorporating the structured experience of this generation-verification closed loop into the knowledge system. If the target object triggers a modification operation, the system parses the adjustment instructions, makes corresponding adjustments to the code to be verified, obtains the adjusted logical functional unit code, and re-executes the "compile the code to be verified into an object file" and subsequent testing and verification steps based on this code until the target object confirms or the maximum number of manual intervention rounds is reached. For the step "adjust the code to be verified according to the adjustment instructions", one option is to support the target object to edit the code inline in the interface, with the system performing real-time syntax verification and automatically generating a diff preview. Another option is to allow the target object to describe the modification intent in natural language, with the large language model combining the current code context to generate an adjustment patch, which is then applied after secondary confirmation by the target object, balancing flexibility and security.

[0104] In the embodiments of this specification, by setting up manual review and intervention nodes before knowledge updates, a reliable closed loop of "machine generation - automatic verification - manual decision-making - knowledge accumulation" is constructed. This not only ensures the accuracy and business alignment of the vector knowledge base, but also gives the target object the ability to respond instantly to edge scenarios and policy changes, thus achieving an organic unity of automation efficiency and human controllability.

[0105] For example, in a content recommendation system, after the integration test of VideoContentFilter v2.2 failed, the system automatically displayed on the visual management interface: the verification result was "FAIL: returnTypeMismatch". The generation process information showed that the code was generated by "ContentFilter_Template_v3.ftl" + "v2.1 failure feedback", and the test log clearly indicated that line 47 returned an ArrayList. After reviewing the code, the reviewer believed that this failure was indeed a violation of the specification, but also noticed that v2.2 did not handle the edge case where the video duration was null—this issue was not recorded in the existing specification document, and there had been no similar feedback before. The reviewer then manually added null value protection logic in the interface code editor and clicked "Submit Modification". The system received the adjustment instruction, generated VideoContentFilter v2.2.1.java as the adjusted logical functional unit code, and automatically recompiled, deployed, and executed the integration test. This test passed, and the verification result was "PASS". The reviewer reviewed the v2.2.1 code and the new verification result again, and clicked "Confirm Archive" after confirming that there were no errors. Only then does the system combine the "v2.2.1 success code + null value protection practice + original v2.2 failure feedback" into new historical generation feedback information and update it to the vector knowledge base. Afterward, when generating video content filters again, the model will not only adhere to the ImmutableList return specification but will also automatically include duration null value protection logic, achieving a positive cycle from single-time manual intervention to long-term knowledge enhancement.

[0106] One embodiment of this specification achieves seamless integration between the generated code and the running system by retrieving historical logical functional units from the vector knowledge base and inputting them into a large language model to generate code to be verified. Dynamic updates are supported by compiling the code to be verified into object files and incrementally loading them into the runtime environment. Verification results are obtained by executing tests in the runtime environment, and updated logical functional units are generated based on the code to be verified to update the vector knowledge base when verification passes. This establishes a closed-loop automated evolution mechanism from code generation and hot deployment to verification optimization, alleviating the problem of the generated business logic being disconnected from the actual running environment.

[0107] The following is in conjunction with the appendix Figure 2 Taking the code verification deployment method provided in this manual as an example of its application in the automated generation of deployment verification development agents in Java, this paper further explains the code verification deployment method. Figure 2 This is a flowchart illustrating the processing steps of a code deployment verification method provided in one embodiment of this specification, specifically including the following steps.

[0108] Step 202: Construct an operator knowledge base.

[0109] Specifically, the existing business logic is transformed and decomposed into atomic functional operators (an operator is a Java class that inherits from a specific base class) through an operator-based code construction module, and the logic is executed through an operator scheduling framework. Then, the system scans the code library, combines the complete Java code, code comments, and functional documentation of each operator into raw materials, generates vectors through a text vectorization model, and builds a searchable vector database (operator knowledge base).

[0110] Step 204: Retrieval Enhancement Generation.

[0111] Specifically, the AI ​​Agent automatic generation module receives the user's natural language development requirements, parses and quantifies them using NLP technology, and retrieves highly similar existing operators from the operator knowledge base as reference context. Then, it combines the user requirements, reference context, and a system prompt that defines the framework rules into a complete instruction, submits it to the large language model, and generates accurate and compliant target operator code.

[0112] Step 206: Hot Deployment and Testing.

[0113] Specifically, the system requests a large model to automatically generate test cases for new operators. The hot deployment scheduling module incrementally updates and hot-deploys the newly generated operators and test cases using an independent class loader without interrupting system services. Subsequently, the automated testing module executes integration tests concurrently in batches, comparing the actual output with the expected output to verify the results.

[0114] Step 208: Closed-loop feedback optimization.

[0115] Specifically, the data storage and feedback module stores all relevant data. When a test fails, the results are presented to the developers for manual intervention; when an operator passes verification, the system automatically updates it to the operator knowledge base through a code scanning mechanism, thus forming a closed-loop optimization system to continuously improve the quality of future code generation.

[0116] Steps 202-208 above can be applied to a closed-loop automated system for code generation, deployment, and verification. See [link to relevant documentation]. Figure 3 As shown, Figure 3 This is a schematic diagram of a code generation, deployment, and verification closed-loop automated system provided in one embodiment of this specification. This system can be deployed on a physical server or a cloud server. Recommended hardware configuration: Intel Xeon E5-2680v4 CPU or higher, 32GB or higher memory, 1TB SSD or higher hard drive, and 100Mbps or higher network bandwidth. It supports single-machine and cluster deployments; in cluster deployment, high availability and scalability can be achieved through load balancing.

[0117] Deploy the open-source dedicated vector database Milvus locally. Remotely access the Claude-4.5-sonnet or higher large model API via local network. Deploy a Python (3.11 or higher) and Java (version 21 or higher) environment locally. Install the sentence-transformers library in the Python environment.

[0118] User clients must have IntelliJ IDEA 2023.3.8 or later installed. IDEA-based Agent plugins can be installed.

[0119] See Figure 3 As shown, the entire system comprises the following modules: The first module is the operator library module for system initialization. The goal of this module is to build a searchable operator vector knowledge base.

[0120] First, define and scan operators: Define an "operator" as a Java class that inherits from a specific framework base class and implements core business methods. Configure the root directory of the operator library; the system recursively traverses this directory, filtering out all Java files that conform to the specifications.

[0121] Secondly, the raw material is extracted: For each scanned operator, the system extracts its complete Java source code, all comments in the code, and any associated external functional description documents. The combination of these three is defined as the raw material of that operator.

[0122] Then, vectorization and storage: The raw material for each operator is processed using a general text vectorization model (the Embedding model all-MiniLM-L6-v2 in the sentence-transformers library) to generate normalized semantic vectors.

[0123] Finally, the index is built: Connecting to the Milvus vector database, the unique identifier (such as class name) of each operator and its corresponding semantic vector are batch-stored into a pre-defined set. An efficient vector index is then constructed using the HNSW algorithm for subsequent fast retrieval. KV storage is also set up, with the unique identifier of each operator linked to its original material.

[0124] The second module is the AI ​​Agent automatic generation module, which is responsible for intelligently generating new operator code based on user needs.

[0125] First, initialize the system configuration (basic preparation). This step is a prerequisite for the process, and its core is to load and calibrate four types of configurations to provide a unified standard for subsequent processes: Load the operator template library (basic general template, business scenario template library).

[0126] The operator framework documentation and the current project documentation are parsed to extract core specifications (interface requirements, annotation usage, code style, dependency information) and store them in a structured manner. Initialize the Prompt splicing format, determine the fixed structure of "system instructions → user requirements → similar operator reference → output requirements → previously generated content and test results", and clarify the splicing rules for each part.

[0127] Verify the integrity of the configuration and cache valid configurations to improve the efficiency of subsequent processes.

[0128] Secondly, user needs need to be machine-understandable. This involves converting user descriptions into vectors (semantic representations).

[0129] Receive user natural language descriptions, perform preprocessing (remove invalid information, segment words, filter stop words), and convert them into plain text; The sentence-transformers class loads the adapted Embedding model all-MiniLM-L6-v2 and configures the vector normalization parameters. The preprocessed text is input into the model to generate high-dimensional semantic vectors. After verifying the validity of the vectors, they are cached for later use.

[0130] Furthermore, based on the vector search for the most similar operator (similarity matching), reference samples are obtained through vector retrieval to improve the quality of operator generation: Load the pre-built Milvus vector library of operators (semantic vectors of existing engineering operators and operator templates), which has been built with an efficient HNSW index; Configure search parameters (return the top 3 similarity operators, similarity threshold 0.7), and perform retrieval based on user demand vector using cosine similarity calculation; Select similar operators that meet the criteria, extract their core information (name, function, structure, hot deployment adaptation status), and cache them after structuring and organizing them.

[0131] Then, the context is pieced together (information integration). This integrates various types of information to provide complete input support for the large model: Extracting core information: user requirements, similar operator references, hot deployment + engineering specifications, and Prompt system commands; The code is concatenated in a pre-defined Prompt format, consisting of: "System instructions (requiring the generation of a code segment) → User requirements (user input) → Similar operator references (original materials of operators retrieved from S3) → Output requirements (other requirements, which can be customized by the user, such as whether to use a specific library) → Content generated last time and test results (if any)".

[0132] A complete prompt includes: system instructions, i.e., general code generation instructions, such as "Please generate a piece of Java code that can be run directly according to the following requirements: the code must be complete, standardized, runnable, clearly commented, and free of redundancy"; user requirements, i.e. user requirements described in natural language, such as "Filter all input notes according to conditions, filtering out those with exposure greater than a configured value and those with likes less than another configured value. The configuration value is read from the configuration center"; similarity operator references, i.e. other similar operators, such as "Operator A, described as filtering according to the number of notes collected, the code is as follows..."; output requirements, which can be customized by the user, such as "Use a thread pool to filter in batches to speed up the process"; and the results of the last generation, i.e. the errors and inputs / outputs of the code generated in the last compilation and execution, such as "Code compilation error, ClassNotFoundException...".

[0133] Finally, the large model is requested to generate operator results (core output). S5 completes operator code generation and standardized output: initializing the large model (Claude-4.5-sonnet), configuring inference parameters (temperature 0.2, maximum generation length 2048); sending the concatenated context request, monitoring the request status (network, timeout, retry); calling the large model to perform preliminary verification of the operator code returned by the model (format, content, compliance), and generating it again if it fails; calling the large model to optimize the code (formatting, adding comments, syntax correction), supporting multiple output formats such as .java source files and JSON configuration files, and storing the feedback to the user.

[0134] The third module consists of a hot deployment scheduling module and an automated testing module. The specific execution steps are as follows: First, prepare for packaging and remote deployment of the new operator code. Once the operator code is generated, execute the packaging command using Maven / Gradle tools to package the code containing only the modified operators and related dependencies into a standalone JAR file (not a full JAR, to reduce transmission size). A unique identifier for the JAR file (MD5 value + operator version number) is automatically generated after packaging. Upload this JAR file to a remote file server and wait for the graph scheduling framework to read and execute the latest operator.

[0135] Then, execute the test cases and return the results to the user. Execute user-defined integration test cases. Use standard output (stdout) logging, through a log monitoring component (custom OutputStream monitor), to collect output logs (including input parameters, execution steps, output results, exception information, etc.) in real time during the execution of remote operators; and return the collected content to the user.

[0136] The original data collection logs and judgment results are returned to the user and simultaneously synchronized to the AI ​​Agent module. If the test fails, the failure details and the inputs and outputs of the modified operator are used for operator code optimization. If the test succeeds, the user can confirm that the generated operator is added to the vector database according to the aforementioned method.

[0137] See Figure 3 , combined Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the workflow of a code generation, deployment, and verification closed-loop automated system according to one embodiment of this specification. Figure 4 This document demonstrates the workflow of a closed-loop automated system for code generation, deployment, and verification, divided into three vertical areas: IDEA code generation agent plugin processing, platform-side logic, and the debugging environment. On the IDEA side, the agent plugin first automatically generates code; then, it calls the MCP to push the code to a remote branch; next, it calls the MCP to access the platform and prepare the remote debugging environment; then, it uses the current operator as context input to the large model to generate debug test cases; finally, it calls the MCP to trigger a debug request. Upon receiving the request, the platform builds the remote branch, uploads the built artifacts to the remote directory, and issues deployment instructions to the debugging environment; after deployment, the platform sends a debug request to the debugging environment; upon receiving the instruction, the debugging environment performs hot loading (first performing hot loading, then after hot loading is complete), and then executes the request; the execution result is collected by the debugging environment and returned to the platform; the platform then feeds back the result to the IDEA-side "verify result and return result" module, thus forming a complete closed loop from code generation → push → build → deployment → hot loading → test execution → result collection → feedback verification. All steps are implemented through MCP (Message Communication Protocol) to achieve cross-module interaction, ensuring coordinated operation of all links.

[0138] according to Figures 2-4 In this embodiment, the actual interaction flow between the user and the system can be as follows: Step 1: User input, "Generate a filter operator. The input is all notes currently being recalled. The note types include video and text / image. The logic is to filter all text / image notes and retain all video notes."

[0139] Step 2: The system converts the above description into a vector and searches the known operator library. Assuming an operator is found, it filters notes based on their category. The logical description is: filter all sports-related notes and retain notes from other categories.

[0140] Step 3: Combine the content of the found operators with the relevant documents and user requests to create a large model.

[0141] Step 4: Output the generated operators and test cases from the large model. Call the local MCP to apply the changes locally (operators and test cases).

[0142] Step 5: The large model calls the local MCP, executes `git commit` and `git push` to push the local changes to the remote branch, and initiates debugging.

[0143] Step 6: After the debugging environment is deployed, the local plugin uses test cases to call the platform. Wait for the test results and collected logs to be returned.

[0144] Step 7: Return the test results and collected logs to the user.

[0145] Step 8: If the user confirms that the input does not meet expectations, they should re-enter the information and return to Step 2.

[0146] Step 9: If the user confirms that it meets expectations, the system will convert the operator description into a vector and store the operator and the operator vector into the operator library.

[0147] Combination Figures 2-4 By breaking down business logic into independent, reusable functional operators and combining AI technology to automatically generate or modify these operators, the system can seamlessly integrate new operators into the runtime environment via hot deployment, completing updates without downtime and effectively ensuring business continuity and high availability.

[0148] During the generation process, the system introduces a Retrieval Enhanced Generation (RAG) mechanism, utilizing an internal knowledge base to provide contextual guidance for the large model, significantly improving the matching degree between the generated code and actual business requirements and its initial usability. Simultaneously, the accompanying automated testing module can automatically complete test case generation, concurrent execution, and result verification, achieving end-to-end automation from code generation to integration verification, effectively covering boundary scenarios and multi-unit linkage issues. More importantly, the system constructs a full-link closed-loop optimization system, continuously feeding test results and usage feedback back to the code generation and operator matching stages, driving the continuous evolution of the Agent generation logic and knowledge base content, thereby achieving continuous improvement in code quality.

[0149] In addition, the system is equipped with a visual management interface that intuitively presents the operating status of each stage and supports users to manually intervene in the generation or testing process when necessary. It balances automation capabilities with operational flexibility, significantly reduces the threshold for use, and is suitable for development teams with different technical levels.

[0150] Corresponding to the above method embodiments, this specification also provides embodiments of a code deployment verification device. Figure 5 This is a schematic diagram of the structure of a code deployment verification device provided in one embodiment of this specification. Figure 5 As shown, the device includes: The retrieval module 502 is configured to retrieve historical logical functional units from the vector knowledge base based on code generation requirements, and input the historical logical functional units into the large language model to generate code to be verified.

[0151] Compiler module 504 is configured to compile the code to be verified into an object file and incrementally load the object file into the runtime environment.

[0152] Test module 506 is configured to perform tests on the target file in the runtime environment to obtain verification results.

[0153] The update module 508 is configured to generate an update logic function unit based on the code to be verified if the verification result is passed, and update the vector knowledge base based on the update logic function unit.

[0154] Optionally, the retrieval module 502 is further configured to obtain code generation requirements, perform redundant information filtering on the code generation requirements to obtain pure requirement text; call a text vectorization model to convert the pure requirement text into requirement semantic vectors, wherein the requirement semantic vectors are used to characterize the semantic features of the code generation requirements; and, based on the semantic features, retrieve at least one historical logical functional unit in the vector knowledge base that meets the similarity threshold with the semantic features.

[0155] Optionally, the code deployment verification device further includes a construction module configured to scan multiple logical function unit code files in the code repository that conform to a preset logical function unit specification, wherein the logical function unit code file is an independent functional unit that implements the target business logic; extract the original materials of each logical function unit code file, wherein the original materials include the logical function unit source code, code comments, and associated functional description documents, and the original materials are used to fully represent the semantic information of the corresponding logical function unit; use a text vectorization model to convert the logical function unit source code, code comments, and associated functional description documents of each logical function unit code into logical function unit semantic vectors; associate the logical function unit semantic vectors of each logical function unit with the logical function unit identifier and store them in a vector database, and establish an index to obtain a vector knowledge base.

[0156] Optionally, the retrieval module 502 is further configured to: obtain system instructions, wherein the system instructions are used to define the basic rules that the generated logical functional unit code must follow; obtain output requirements defined by the front end, wherein the output requirements are used to constrain the generation method of the code to be verified; obtain historical generation feedback information, wherein the historical generation feedback information consists of test results obtained from testing historically generated code and historically generated code; concatenate the system instructions, code generation requirements, historical logical functional units, output requirements, and historical generation feedback information in a preset order to form model input; and input the model input into the large language model to generate the code to be verified.

[0157] Optionally, the retrieval module 502 is further configured to select a logical function unit code template matching the code generation requirements from a pre-set logical function unit template library as supplementary reference information; obtain pre-set logical function unit specification information, wherein the logical function unit specification information is obtained by parsing the logical function unit framework specification document and is used to constrain the structure and interface of the generated logical function unit code; based on the logical function unit specification information, concatenate system instructions, code generation requirements, historical logical function units, supplementary reference information, and output requirements in a preset order to form model input information; and provide the model input information to the large language model to generate verification code that conforms to the structure and interface constrained by the logical function unit specification information.

[0158] Optionally, the retrieval module 502 is further configured to obtain historical verification results obtained by performing tests on historical generated code; if the historical verification result characterization test fails, the failure details and historical generated code in the verification result are used as historical generation feedback information; if the historical verification result characterization test succeeds, the original material of the historical generated code is updated to the vector knowledge base.

[0159] Optionally, the code deployment verification apparatus also includes a loading module configured to encapsulate the target file into an independent loading package and generate a loading package identifier for the independent loading package; and to transfer the independent loading package to a storage area accessible by the runtime environment.

[0160] Optionally, the loading module is further configured to retrieve an independent loading package from the storage area based on the loading package identifier; create an independent class loader, load the target file contained in the independent loading package through the independent class loader to obtain a logical functional unit instance, wherein the independent class loader is used to load a new logical functional unit class without affecting existing classes in the runtime environment; and incrementally connect the logical functional unit instance to the runtime environment without interrupting existing services in the runtime environment.

[0161] Optionally, the test module 506 is further configured to generate test cases for the code to be verified using a large language model; deploy the test cases to the runtime environment and initiate integration tests on the target file; collect the output logs generated by the target file during the integration test; and compare the actual execution results reflected in the output logs with the preset expected outputs to obtain the verification results.

[0162] Optionally, the code deployment verification device also includes a correction module, configured to obtain feedback information when the verification result is unsuccessful; call the large language model to generate a correction logic function unit based on the feedback information; generate the updated code to be verified based on the correction logic function unit, and return to the execution compilation module 504.

[0163] Optionally, the code deployment verification device also includes a front-end adjustment module, configured to display the verification results and the generation process information of the code to be verified through a visual management interface; in response to a confirmation operation triggered by the target object on the visual management interface, execute the step of updating the vector knowledge base based on the verification results; or, in response to a modification operation triggered by the target object on the visual management interface, obtain adjustment instructions, adjust the code to be verified according to the adjustment instructions, and re-execute the test based on the adjusted logical functional unit code.

[0164] This code deployment and verification device, through the collaborative work of its modules, constructs a closed-loop automated evolution mechanism for code generation, hot deployment, and verification optimization. First, the retrieval module 502, based on current code generation requirements, searches for similar historical logical functional units in the vector knowledge base and uses them as context input to the large language model, thereby generating code to be verified that fits the existing system's semantics and structure, effectively improving the compatibility between the generated content and the running system. Then, the compilation module 504 compiles the code to be verified into an object file and loads it incrementally into the runtime environment, achieving dynamic updates without downtime and ensuring service continuity. Next, the testing module 506 performs tests on the object file in the real runtime environment, obtaining verification results reflecting actual behavior. If the verification result is successful, the update module 508 generates new logical functional units based on the code to be verified and writes them into the vector knowledge base, completing knowledge accumulation and iteration. Thus, through the orderly linkage of modules 502–508, the device achieves a complete closed loop from semantically aligned code generation and seamless hot deployment to feedback-driven knowledge base updates, significantly alleviating the problem of the disconnect between automatically generated business logic and the actual runtime environment.

[0165] The above is an illustrative scheme of a code deployment verification device according to this embodiment. It should be noted that the technical solution of this code deployment verification device and the technical solution of the above-described code deployment verification method belong to the same concept. For details not described in detail in the technical solution of the code deployment verification device, please refer to the description of the technical solution of the above-described code deployment verification method.

[0166] Figure 6 A structural block diagram of a computing device 600 according to one embodiment of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0167] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0168] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0169] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0170] The processor 620 is used to execute the following computer program / instructions, which, when executed by the processor, implement the steps of the above code deployment verification method.

[0171] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computing device embodiments are basically similar to the code deployment verification method embodiments, so the description is relatively simple; relevant parts can be referred to in the description of the code deployment verification method embodiments.

[0172] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the code deployment verification method described above.

[0173] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiment is described simply because it is substantially similar to the code deployment verification method embodiment; relevant parts can be found in the description of the code deployment verification method embodiment.

[0174] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the code deployment verification method described above.

[0175] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the code deployment and verification method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the code deployment and verification method described above.

[0176] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0177] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0178] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0179] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0180] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.< / content>

Claims

1. A code deployment verification method, characterized in that, include: Based on the code generation requirements, historical logical functional units are retrieved from the vector knowledge base, and the historical logical functional units are input into the large language model to generate code to be verified. The code to be verified is compiled into an object file, and the object file is incrementally loaded into the runtime environment; In the operating environment, tests are performed on the target file to obtain verification results; If the verification result is successful, an update logic function unit is generated based on the code to be verified, and the vector knowledge base is updated based on the update logic function unit.

2. The method according to claim 1, characterized in that, The process of retrieving historical logical functional units from the vector knowledge base based on code generation requirements includes: Obtain code generation requirements, perform redundant information filtering on the code generation requirements, and obtain pure requirement text; The text vectorization model is invoked to convert the pure requirement text into a requirement semantic vector, wherein the requirement semantic vector is used to characterize the semantic features of the code generation requirement; Based on the semantic features, at least one historical logical functional unit that meets the similarity threshold with the semantic features is retrieved from the vector knowledge base.

3. The method according to claim 2, characterized in that, Before retrieving historical logical functional units from the vector knowledge base based on code generation requirements, the method further includes: Scan the code library for multiple logical function unit code files that conform to the preset logical function unit specification, wherein the logical function unit code file is an independent functional unit that implements the target business logic; Extract the original materials from the code files of each logical functional unit, wherein the original materials include the source code of the logical functional unit, code comments, and associated functional description documents, and the original materials are used to fully characterize the semantic information of the corresponding logical functional unit; The source code, code comments, and associated functional description documents of each logical functional unit are converted into semantic vectors of the logical functional units using a text vectorization model. The semantic vectors of each logical functional unit are associated with and stored in the vector database along with the identifiers of the logical functional units, and an index is created to obtain the vector knowledge base.

4. The method according to claim 1, characterized in that, The step of inputting the historical logical functional units into the large language model to generate code to be verified includes: Obtain system instructions, wherein the system instructions are used to define the basic rules that must be followed when generating logical functional unit code; Obtain the output requirements defined by the front end, wherein the output requirements are used to constrain the generation method of the code to be verified; Obtain historical generation feedback information, wherein the historical generation feedback information consists of test results obtained by testing historically generated code and the historically generated code itself; The system instructions, the code generation requirements, the historical logical function units, the output requirements, and the historical generation feedback information are concatenated into the model input in a preset order; The model is input into a large language model to generate code to be verified.

5. The method according to claim 4, characterized in that, Before concatenating the system instructions, code generation requirements, historical logical function units, output requirements, and historical generation feedback information into the model input in a preset order, the method further includes: Select a logical function unit code template that matches the code generation requirements from the pre-set logical function unit template library as supplementary reference information; Obtain preset logical function unit specification information, wherein the logical function unit specification information is obtained by parsing the logical function unit framework specification document, and is used to constrain the structure and interface of the generated logical function unit code; The step of concatenating the system instructions, code generation requirements, historical logical functional units, output requirements, and historical generation feedback information into model input in a preset order includes: Based on the logical functional unit specification information, the system instructions, the code generation requirements, the historical logical functional units, the supplementary reference information, and the output requirements are concatenated into model input information in a preset order. The model input information is provided to the large language model to generate verification code that conforms to the structure and interface constraints of the logical functional unit specification information.

6. The method according to claim 4, characterized in that, The acquisition of historical generated feedback information includes: Obtain historical verification results obtained by performing tests on historically generated code; In the event that the historical verification result indicates a test failure, the failure details in the verification result and the historical generation code will be used as the historical generation feedback information. If the historical verification result characterization test is successful, the original material of the historical generated code will be updated to the vector knowledge base.

7. The method according to claim 1, characterized in that, Before incrementally loading the target file into the runtime environment, the method further includes: The target file is encapsulated into an independent loading package, and a loading package identifier is generated for the independent loading package; The independent loading package is transferred to a storage area accessible by the runtime environment.

8. The method according to claim 7, characterized in that, The step of incrementally loading the target file into the runtime environment includes: The independent loading package is retrieved from the storage area based on the loading package identifier; An independent class loader is created, and the target files contained in the independent loading package are loaded through the independent class loader to obtain a logical functional unit instance. The independent class loader is used to load new logical functional unit classes without affecting existing classes in the runtime environment. Without interrupting existing services in the operating environment, the logical functional unit instances are incrementally connected to the operating environment.

9. The method according to claim 1, characterized in that, The verification results obtained by performing tests on the target file in the operating environment include: The large language model is used to generate test cases for the code to be verified; Deploy the test cases to the runtime environment and initiate integration tests on the target file; Collect the output logs generated by the target file during the integration test; The actual execution results reflected in the output logs are compared with the preset expected outputs to obtain the verification results.

10. The method according to claim 1, characterized in that, After obtaining verification results by performing tests on the target file in the operating environment, the process further includes: If the verification result is unsuccessful, obtain feedback information; The large language model is invoked, and a correction logic functional unit is generated based on the feedback information. Based on the correction logic function unit, generate the update code to be verified, and return to execute the step of compiling the code to be verified into an object file.

11. The method according to claim 1, characterized in that, Before updating the vector knowledge base based on the update logic functional unit, the method further includes: The verification results and the generation process information of the code to be verified are displayed through a visual management interface. In response to a confirmation operation triggered by the target object on the visual management interface, the step of updating the vector knowledge base based on the verification result is executed; or, In response to a modification operation triggered by the target object on the visual management interface, an adjustment instruction is obtained, and the code to be verified is adjusted according to the adjustment instruction. The test is then re-executed based on the adjusted logical functional unit code.

12. A code deployment verification device, characterized in that, include: The retrieval module is configured to retrieve historical logical functional units from the vector knowledge base based on code generation requirements, and input the historical logical functional units into the large language model to generate code to be verified. The compilation module is configured to compile the code to be verified into an object file and incrementally load the object file into the runtime environment; The testing module is configured to perform tests on the target file in the runtime environment to obtain verification results; The update module is configured to generate an update logic function unit based on the code to be verified if the verification result is passed, and update the vector knowledge base based on the update logic function unit.

13. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the code deployment verification method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, It stores a computer program / instruction that, when executed by a processor, implements the steps of the code deployment verification method according to any one of claims 1-11.

15. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the steps of the code deployment verification method according to any one of claims 1-11.

Images