A code generation method and device, a storage medium and an electronic device

Abstract

The specification discloses a code generation method and device, a storage medium and an electronic device, wherein the method comprises: in response to a service check rule request input for a target platform service, performing scene identification on the service check rule request to obtain a target service scene; based on the target service scene, matching target interface semantic information corresponding to the service check rule request in a service interface semantic knowledge base corresponding to the target platform service; based on the target interface semantic information, constructing a code generation constraint prompt word for the service check rule request to generate a check rule script code by using a code generation large language model. By introducing a service interface semantic knowledge base to form a strong constraint, the logical accuracy of the generated check rule script code is improved by using the embodiments of the specification.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a code generation method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the increasing complexity of modern platform service architectures and the agile iteration of transaction service requirements, the platform services maintained by the platform (such as shopping platform services, physical platform services, user financial services, and public service platform services) contain a large number of frequently changing service verification rules (such as status compliance checks, data validity verification, and service mathematical constraint verification). These rules need to be quickly implemented into underlying executable code. Traditional methods heavily rely on developers manually coding based on business rules described in natural language. This approach not only has a long development and delivery cycle but is also prone to code logic errors due to misunderstandings of the underlying service interface semantics between business personnel and technical developers. Furthermore, it results in high maintenance costs and difficulty in coping with the needs of large-scale service evolution. Summary of the Invention

[0003] This specification provides a code generation method, apparatus, storage medium, and electronic device, the technical solution of which is as follows: Firstly, this specification provides a code generation method, which includes: In response to a service verification rule request input for a target platform service, the service verification rule request is used to identify the target service scenario. Based on the target service scenario, the semantic information of the target interface corresponding to the service verification rule request is matched in the service interface semantic knowledge base corresponding to the target platform service. Based on the semantic information of the target interface, code generation constraint prompts are constructed for the service verification rule request. Based on the code generation constraint prompts, a large code generation language model is used to generate verification rule code to obtain the verification rule script code.

[0004] Secondly, this specification provides a code generation apparatus, the apparatus comprising: The scene recognition module is used to respond to the service verification rule request input for the target platform service, and to perform scene recognition on the service verification rule request to obtain the target service scene; The information matching module is used to match the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario. The code generation module is used to construct code generation constraint prompts for the service verification rule request based on the semantic information of the target interface, and to perform verification rule code generation processing using a code generation large language model based on the code generation constraint prompts to obtain the verification rule script code.

[0005] Thirdly, this specification provides a computer storage medium storing at least one instruction adapted for loading by a processor and executing method steps of one or more embodiments of this specification.

[0006] Fourthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

[0007] Fifthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the method steps of one or more embodiments of this specification.

[0008] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In one or more embodiments of this specification, by accurately identifying the scene of service verification rule requests in natural language form, and using this as an anchor point to extract target interface semantic information from a pre-built service interface semantic knowledge base, the information is dynamically assembled into code generation constraint prompts with high-density logical boundary restrictions. This ultimately guides the code generation big language model to deduce the verification rule script code. This solves the problems of long development cycles and high maintenance costs of traditional manual coding, as well as code errors caused by the lack of prior interface knowledge when directly using a general big language model to generate underlying service code. It bridges the semantic gap between natural language requests and executable code, improves the logical accuracy, interface call compliance, and delivery availability of the target verification rule script code, and enhances the development efficiency and iteration efficiency of the platform system service rules. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of a code generation system provided in this manual; Figure 2This is a flowchart illustrating a code generation method provided in this manual; Figure 3 This is a flowchart illustrating a knowledge matching process provided in this manual; Figure 4 This is a flowchart illustrating a code generation process provided in this manual; Figure 5 This is a flowchart illustrating a code verification process provided in this manual; Figure 6 This is a schematic diagram of the structure of a code generation device provided in this specification; Figure 7 This is a schematic diagram of the structure of an electronic device provided in this specification. Detailed Implementation

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

[0012] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0013] While Large Language Models (LLMs) have shown potential in automated code generation, their lack of prior knowledge regarding the business semantics of platform-specific private microservice interfaces (such as the business meaning of specific input parameters, the deep logic of complex return fields, and state enumeration) leads to fatal flaws in the code generated by directly inputting natural language rules into them. These flaws include parameter misuse and contextual disconnect. This results in extremely low usability of the generated script code, requiring significant manual intervention for logic checks and secondary corrections. Consequently, it fails to fundamentally bridge the semantic gap between "natural language rules" and "accurate executable code," making it difficult to achieve true automated R&D efficiency improvements in platform service scenarios.

[0014] The present specification will now be described in detail with reference to specific embodiments.

[0015] Please see Figure 1 This is a schematic diagram of a code generation system provided in this specification. Figure 1 As shown, the code generation system may include at least a client cluster and a service platform 100.

[0016] The client cluster may include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0017] Each client in a client cluster can be an electronic device with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, electronic device, wireless communication device, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0018] The service platform 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; or it can be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services independently. The independent provision of services can be understood as not requiring the assistance of other servers.

[0019] In one or more embodiments of this specification, the service platform 100 can establish a communication connection with at least one client in the client cluster, and complete the data interaction during the code generation process based on the communication connection; Optionally, in the actual application scenarios of the embodiments in this specification, the client mainly provides users with a graphical user interface (GUI) or a command-line interface (CLI). The client is used to receive service verification rule requests for the target platform service input by the terminal operator (such as system developers or platform maintenance personnel). The service verification rule request is usually expressed as a text instruction in natural language, used to describe specific compliance checks, status verification, or data comparison logic, etc. The client is responsible for encapsulating the collected service verification rule requests and sending them to the service platform 100 through the aforementioned communication network. At the same time, the client is also used to receive the target verification rule script code returned by the service platform 100 after the code generation workflow is completed, or the quality inspection anomaly feedback information generated during the closed-loop quality inspection process, and to visualize it on the terminal display for the user to conduct final code review or status confirmation.

[0020] Optionally, the service platform 100 integrates or connects to multiple underlying intelligent execution engines via high-speed intranet communication. These engines mainly include a multi-node large language model cluster (such as the first large language model for execution scenario recognition, the code generation large language model for execution code deduction, and the quality inspection large language model for multi-dimensional logic review) and a pre-fixed service interface semantic knowledge base.

[0021] Optionally, after receiving a service verification rule request from the client, the service platform 100, acting as a central scheduling node, sequentially triggers pipeline processing steps such as scene recognition, knowledge base penetration matching, prompt word domain construction, and controlled code generation. Through frequent interactions between the aforementioned large language model cluster and the service interface semantic knowledge base, the service platform 100 transforms unstructured natural language requests into feature data with strong constraint context, ultimately deriving the target verification rule script code and performing machine-level cross-checking.

[0022] It should be noted that the service platform 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0023] Furthermore, the code generation system embodiments provided in this specification and the code generation methods described in one or more embodiments belong to the same concept. It should be noted that the automatic code generation method provided in the embodiments of this specification is generally executed by the service platform 100. Accordingly, the automatic code generation device or computer program instructions that execute this method are generally deployed and stored in the storage medium of the service platform 100. However, in certain specific implementation scenarios with edge computing capabilities, if the client has sufficient computing power and model running environment, all or part of the steps of this method can also be executed independently by the client locally, or by the client and the service platform 100 in a distributed manner. The embodiments of this specification do not uniquely limit the specific hardware execution boundary, which is determined based on the actual application environment. The implementation process of the code generation system embodiments can be found in the following method embodiments, which will not be repeated here.

[0024] based on Figure 1 The following is a detailed description of the code generation method provided by one or more embodiments of this specification, as illustrated in the scene diagram.

[0025] Please see Figure 2This document provides a flowchart illustrating a code generation method according to one or more embodiments. This method can be implemented using a computer program and can run on a code generation device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The code generation device can be an electronic device.

[0026] Specifically, the code generation method includes: S102: In response to a service verification rule request input for a target platform service, perform scenario identification on the service verification rule request to obtain the target service scenario; The target platform service refers to the underlying basic functional service module or service cluster deployed on the service platform to support the operation of a specific transaction service system. The target platform service is not limited here.

[0027] Service verification rule requests refer to natural language requests triggered by users (such as administrators), which are described in natural language, semi-structured text, and other formats to verify and judge service requirements such as data compliance and service mathematical constraints in platform services.

[0028] The target service scenario refers to the specific transaction service domain, functional module, and system operating environment identifier to which the above service verification rule request belongs in the platform service architecture, after scenario identification and analysis.

[0029] To illustrate, when an electronic device receives a service verification rule request for a target platform service, it calls a pre-defined natural language processing toolkit to perform data cleaning, word segmentation, and stop word filtering on the text corresponding to the request, in order to extract keyword feature sequences that reflect core user needs. The keyword feature sequences are then input into a text classification network model, which performs feature mapping and fully connected classification calculations on the keyword feature sequences based on its internal weight parameters. The model outputs a probability distribution vector for a pre-defined set of standard business scenarios, extracts the classification dimension with the largest value from the probability distribution vector, and determines the business scenario label corresponding to that classification dimension as the target service scenario.

[0030] In one feasible implementation, the process of identifying the target service scenario from the service verification rule request can be performed as follows: Step S2: Input the service verification rule request into the scene recognition large language model, extract semantic features and parse intent of the service verification rule request to obtain target intent features; Scene recognition large language model: refers to a large language model (LLM) for natural language processing built on a deep neural network architecture (such as the Transformer architecture) and pre-trained and fine-tuned on a corpus of the target platform's service domain. This scene recognition large language model is specifically designed for deep semantic understanding, intent boundary delineation, and classification prediction of unstructured input text.

[0031] Target intent features refer to high-dimensional hidden layer feature vectors and structured intent labels extracted by the scene recognition big language model from the original natural language form of service verification rule requests. These features accurately represent the core service verification requests of the operating subject, the object entity, and the verification logic.

[0032] Step S4: Control the scene recognition big language model to perform keyword matching processing between the target intent features and the preset standard business scene set to obtain the target service scene.

[0033] The preset standard business scenario set refers to the data set of classification tags or scenario keyword dictionaries that are configured during the initialization or operation and maintenance phase of the target platform service and cover all business service domains that can be supported by the target platform service.

[0034] Indicatively, steps S2-S4 are executed. Before calling the scene recognition language model, a context prompt word template containing dynamic instruction prefixes and global directory information of a preset standard business scenario set is pre-constructed. The received service verification rule request is embedded in this prompt word template and fed into the scene recognition language model as a complete input tensor. The scene recognition language model is controlled to perform intent parsing within a highly restricted context boundary, that is, to transform the original unstructured verification rule text into a feature representation containing core logic assertions and system calls, and to accurately determine the target intent features. On this basis, since mandatory constraints are applied at the prompt word level in advance, the scene recognition language model directly performs cross-validation and internal keyword comparison calculations on the inferred target intent features and the scene directories provided in the prompt word template during its neural network decoding stage to obtain the target service scenario. This can be understood as outputting the target service scenario that can form a mapping relationship with the above intent features at the end of the model inference process. This end-to-end processing method reduces data flow communication latency and improves the platform processing throughput in concurrent scenarios.

[0035] For example, suppose the target platform service is a comprehensive e-commerce order management system. Platform maintenance personnel input a service verification rule request through the client, the text of which is: "Verify whether the order status of the user who initiated the after-sales application is in a completed state, and simultaneously determine whether the total refund amount requested is less than or equal to the original total payment amount of the order." Upon receiving this request, the above natural language request is input into a scene recognition big data model for deep semantic feature extraction. The big data model accurately extracts the joint intent features implied by the after-sales application, order status, total refund amount, and total payment amount. The extracted intent feature vector is then compared with the standard scene vectors in the knowledge base to calculate spatial similarity. The result shows that the request has the highest cosine similarity to a preset order after-sales flow scenario. Based on this, the scene recognition big data model outputs the order after-sales flow and fund settlement scenario as the target service scenario.

[0036] Optionally, the scene recognition large language model is not an unprocessed general natural language base model, but a vertical domain large language model generated by fine-tuning instructions using a corpus specific to the target platform's service domain. The following illustrates a model fine-tuning training process for a scene recognition large language model: 1) Construction and preprocessing of training sample set The system acquires a massive amount of verification rule text accumulated in the historical business processes of the target platform service, as well as the real business service domain node tags attached to each rule verification request text in the actual system, to construct an original training corpus. The original training corpus is then cleaned and desensitized to filter out abnormal characters and privacy features.

[0037] Using a data construction standard with fine-tuning instructions, the cleaned corpus is transformed into training pairs of prompt words: "input request - preset output label". For example, a single training sample is constructed as follows: Input feature instruction: "Please identify the underlying system scenario to which the following business verification rules belong: verify whether the order status of the user who initiated the after-sales application is completed"; Expected output label: order after-sales flow scenario. Through the above transformation, a scenario mapping sample dataset is constructed and divided into training and validation sets according to a preset ratio.

[0038] 2) Base model acquisition and network structure initialization stage A large language model LLM (such as a deep neural network model with hundreds of billions of parameters based on the Transformer architecture) that has converged before being trained on a large-scale general corpus is selected as the initial base model. In order to significantly reduce the computational cost of the training process and avoid the model losing its general language ability (catastrophic forgetting), this embodiment can use a low-rank adaptive LoRA parameter efficient fine-tuning algorithm.

[0039] Specifically, an initialized trainable low-rank matrix (including a reduced-dimensional matrix and an increased-dimensional matrix) is injected as a bypass into the self-attention layers of the initial base model. At the same time, most of the original network weight parameters in the initial base model are frozen, and only the parameters of the bypass-injected low-rank matrix are set to a differentiable and updatable trainable state to obtain the initial scene recognition large language model.

[0040] 3) Model Iteration Fine-tuning and Error Loss Calculation Process During the model training phase, the training pairs of prompt words in the training set are divided into multiple batches and sequentially input into the initialized initial scene recognition large language model. The model is then controlled to perform forward propagation calculations and output the predicted scene classification probability distribution vector.

[0041] The system calls a pre-defined model loss calculation function (such as cross-entropy loss function, Euclidean distance loss function, etc.) to calculate the prediction error loss value between the predicted scene classification probability distribution vector and the true output label vector in the training samples. Backpropagation is performed based on a gradient descent algorithm (such as the AdamW optimization algorithm), the gradient is calculated based on the prediction error loss value, and the trainable parameters in the low-rank matrix are dynamically updated according to a pre-defined initial learning rate, completing a single round of iterative training. Multiple rounds of iterative training are then performed until the model training ends. The weight parameters of the fine-tuned and converged low-rank matrix are extracted and tensor-merged with the frozen original weight parameters of the initial base model, ultimately generating a large-scale scene recognition language model that can run offline. This model can then handle real-time natural language verification rule requests and output high-precision target service scenes.

[0042] After each round of training iterations, the model training termination condition is checked to see if it is met, and the training process ends if the condition is met. Optionally, the model training termination condition may include, for example, the loss function value being less than or equal to a preset loss function threshold, or the number of iterations reaching a preset threshold. The specific model training termination condition can be determined based on the actual situation and is not specifically limited here.

[0043] S104: Based on the target service scenario, match the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service; A service interface semantic knowledge base refers to a structured data set pre-built and persistently stored within a platform service, used to record the underlying microservice interface technical specifications and their mapping relationship with natural language business meanings. In the embodiments of this specification, this knowledge base typically includes a progressively layered scenario layer, an interface metadata layer, and a return semantic layer, or it can be a data structure presented as a service entity relationship graph.

[0044] The target interface semantic information refers to the underlying dataset extracted from the aforementioned knowledge base through a retrieval engine or graph computing algorithm, used to support the execution of the current service verification rule request. Optionally, this information includes, but is not limited to, technical features such as the interface class name, method signature, and input parameter types required for machine execution, and may also include business service-related constraint rules such as the state enumeration dictionary and return value addressing path.

[0045] In a schematic manner, the service interface semantic knowledge base can be used as a preset service entity relationship graph for graph data structure reading. Multiple target service entity nodes associated with the target service scenario are retrieved from the service entity relationship graph, and graph mining algorithms are used to extract the edge dependency features between these target service entity nodes. Subsequently, based on the edge dependency features, the system calls a path addressing algorithm to calculate the microservice interface concatenation path required for the service verification rule request. Based on the sequential dependency order of interface calls in the microservice interface concatenation path, a target routing topology model corresponding to the target service scenario is constructed. After the topology model is constructed, the system sequentially performs loop information query processing on each topology service entity node in the scenario layer, interface metadata layer, and return semantic layer of the service interface semantic knowledge base, following the topological flow of the target routing topology model. This process extracts the interface call metadata and return value business dictionary of each node along the route, and structures and encapsulates the multidimensional data features extracted from all nodes along the route according to temporal dependencies. Finally, target interface semantic information, including complex multi-interface call chains and their context constraint dictionaries, is generated.

[0046] S106: Based on the semantic information of the target interface, construct code generation constraint prompts for the service verification rule request, and use a code generation large language model to process the verification rule code to obtain the verification rule script code.

[0047] Code generation constraint prompts refer to a concatenated text sequence with a strict internal data structure and contextual context. These prompts deeply bind the unstructured natural language validation requirements with the machine's underlying strict interface data structure, limiting the scope of code generation by large language models and preventing the generation of illusionary code that deviates from the system's actual infrastructure.

[0048] Large Language Model for Code Generation refers to a large language model (LLM) that has been pre-trained and optimized on massive multilingual code libraries and platform-specific software engineering code corpora. This model can understand the technical limitations in the code generation constraint prompts and output high-level script code that conforms to the syntax of specific programming languages ​​(such as Groovy, Python, Java, etc.) based on an autoregressive mechanism.

[0049] Verification rule script code refers to computer program code that is generated from the code of a large language model and ultimately deduced and output, and can be directly compiled, interpreted and executed by the rule execution engine in the target platform service.

[0050] In one feasible implementation, the original service verification rule request and discrete target interface semantic information are uniformly input into a code generation language model with autonomous intelligent agent planning capabilities in the form of an initial global context. After receiving the input features, the code generation language model autonomously executes the prompt word construction task during its internal reasoning stage. That is, it uses a multi-head attention mechanism to extract and assemble elements from the input information, automatically extracting the interface call signature, input parameter data specifications, and state enumeration dictionary, and dynamically concatenating them in the model's context memory to generate code generation constraint prompt words with strong constraint logic and standardized structure. The code generation language model can switch to the code inference task stage directly based on the code generation constraint prompt words without external system intervention or re-calling. It sequentially infers and generates parameter instantiation code blocks, service call code blocks, return data parsing code blocks, and logical assertion code blocks. Then, the model's underlying decoder performs syntactic-level integration of the above code blocks and outputs executable verification rule script code, realizing an end-to-end monolithic model automated closed loop from autonomous internalization of constraints to direct output of target code.

[0051] This specification describes a method for accurately identifying service verification rule requests in natural language format. Using this as an anchor, target interface semantic information is extracted from a pre-built service interface semantic knowledge base. This information is then dynamically assembled into code generation constraint prompts with high-density logical boundary restrictions. Ultimately, this guides a large language model to deduce the verification rule script code. This method solves the problems of long development cycles and high maintenance costs associated with traditional manual coding, as well as code errors caused by a lack of prior interface knowledge when directly generating underlying service code using a general large language model. It bridges the semantic gap between natural language requests and executable code, improving the logical accuracy, interface call compliance, and delivery availability of the target verification rule script code, thereby enhancing the development efficiency and iteration efficiency of the platform system's service rules.

[0052] Optional, please see Figure 3 , Figure 3 This is a schematic diagram of a knowledge matching process proposed in one or more embodiments of this specification. Specifically, the process of matching the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario can be performed as follows: S202: Based on the target service scenario, information query processing is performed in the scenario layer, interface meta-information layer and return semantic layer of the service interface semantic knowledge base to obtain scenario verification interface information, interface meta-information and return object semantic information; The scenario layer refers to the index structure in the service interface semantic knowledge base, which is mainly used to store the mapping relationship between business service scenarios and the underlying specific microservice interface set.

[0053] The interface metadata layer refers to the intermediate logical structure in the service interface semantic knowledge base. It is mainly used to store the static technical specifications of each microservice interface, including but not limited to the interface's Uniform Resource Locator, the method signature of the application programming interface, the protocol type, and the technical tags of the input parameter variables.

[0054] The returned semantic layer refers to the underlying data mapping structure in the service interface semantic knowledge base. It is mainly used to store the business parsing rules of the interface response message, including the nested field hierarchy of the returned data object, the data extraction addressing path, and the state enumeration dictionary between the underlying machine status code and the natural language business status.

[0055] Scene verification interface information refers to a collection or list of one or more mandatory microservice interfaces that are specifically used to support the completion of verification tasks in the current target service scene, obtained by querying in the scene layer.

[0056] The semantic information of the returned object refers to the rule description data extracted from the returned semantic layer, which is used to guide the subsequent large language model on how to dimensionality-reduced parse of complex returned messages and perform business assertions.

[0057] In a schematic manner, using the target service scenario as the primary key, precise matching and retrieval are performed in the scenario layer of the service interface semantic knowledge base built using a relational database to first obtain the scenario verification interface information, including scenario ID, scenario category, scenario description, and the list of interfaces required for scenario verification. Then, based on the scenario verification interface information, the list of interface calls bound to the target service scenario is extracted as the scenario verification interface information. Each interface identifier in the scenario verification interface information is traversed and sequentially entered into the interface meta-information layer for structured query processing. Parameters such as request method specifications, parameter type restrictions, and message header requirements corresponding to each interface are extracted, and the parameters are merged to obtain the interface meta-information. For each of the above interface identifiers, the return semantic layer is accessed to selectively extract the data mode description of the return data body, field hierarchy addressing rules, and business status enumeration mapping dictionary corresponding to each interface, and combine them to obtain the semantic information of the return object. S204: Generate the target interface semantic information corresponding to the service verification rule request based on the scenario verification interface information, scenario interface meta information, and returned object semantic information.

[0058] After completing the above three-layer data extraction, the scenario verification interface information, the interface meta information, and the returned object semantic information are hierarchically encapsulated and serialized according to the standard data exchange format, and finally the target interface semantic information containing complete call context constraints and which can be directly parsed and read by a large language model is generated.

[0059] This specification demonstrates how the aforementioned method enables targeted, penetrating queries to accurately extract interface semantic information such as method signatures, parameter specifications, and state enumerations. This eliminates the interface illusion and parameter misuse problems caused by the lack of private prior interface knowledge in large language models. Simultaneously, the dynamic assembly of multi-dimensional features into target interface semantic information establishes a technical boundary for subsequent code derivation, bridging the semantic gap between natural language and underlying machine code, and ensuring that the final generated script code possesses high logical accuracy and engineering executability.

[0060] In one feasible implementation, the information query processing based on the target service scenario, performed in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base, can be carried out in the following manner: S302: Retrieve multiple target service entity nodes associated with the target service scenario in the preset service entity relationship graph, and extract the edge dependency features between the target service entity nodes; A service entity relationship graph refers to a networked data structure pre-built within the platform using a graph database. This structure globally describes the intricate call and dependency relationships between (micro)service components, business service domain models, and data tables. In this graph, nodes represent service entities (such as specific microservices or data objects), and edges represent the interaction relationships between entities.

[0061] Edge dependency features refer to the attribute data implied by the connections between different service entity nodes in the above graph. They not only reflect whether there are calling relationships between nodes, but also define the direction of data flow, temporal constraints, conditional triggering mechanisms, and permission dependency levels.

[0062] S304: Determine the microservice interface concatenation path required for the service verification rule request based on the edge dependency characteristics, and construct the target routing topology model corresponding to the target service scenario based on the interface call dependency order in the microservice interface concatenation path; The microservice interface chain path refers to the link trajectory of a series of underlying microservice interfaces that must be called in a specific order to complete a complex and comprehensive business verification rule.

[0063] Target routing topology model: refers to the directed acyclic graph (DAG) structure model derived from the above-mentioned serial paths, used to guide machines or large language models to execute tasks strictly in sequential or parallel logic. It strictly defines the upstream and downstream dependency boundaries of interface calls from a mathematical perspective.

[0064] S306: Based on the topology flow direction of the target routing topology model, perform information query processing on each topology service entity node in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base.

[0065] Topology flow refers to the unidirectional network flow path in the target routing topology model, in which data and control commands are transmitted from the upstream root node (pre-dependent service) to the downstream leaf node (post-target service).

[0066] Indicatively, steps S302-S306 are executed to map the identifier of the target service scenario to a preset service entity relationship graph. A graph traversal algorithm is used to hit one or more target service entity nodes. By calculating the threshold between the in-degree and out-degree of adjacent nodes, the edge dependency features between these target service entity nodes whose in-degree and out-degree are less than the threshold are extracted. The edge dependency features are input into a preset shortest path addressing algorithm to calculate the microservice interface chain path that needs to be traversed from the initial authentication entity to the final data entity. Based on the interface call dependency order of the front and back interfaces reflected in the microservice interface chain path, a directed acyclic graph composed of nodes and directed edges is instantiated and constructed in combination with the edge dependency features. This graph is used as the target routing topology model corresponding to the target service scenario. After the target route topology model is generated, the penetration query engine is started to perform a depth-first traversal along the topology flow of the target route topology model. For each topology service entity node currently traversed, a penetration query is performed sequentially in the service interface semantic knowledge base. That is, first, the microservice cluster bound to the node is locked at the scenario layer to obtain the scenario verification interface information, then the interface meta-information layer is drilled down to extract the interface meta-information such as the input parameters and method signature of the node, and finally the return semantic layer is drilled down to extract the return object semantic information such as the state enumeration and return nesting structure of the node. Finally, the three layers of information queried from each node are spliced ​​and assembled according to the topology sequence to form the target interface semantic information of the global type with time series constraints.

[0067] In this specification, considering the complex verification scenarios involving multiple services across business service domains with strict sequential or conditional dependencies in the platform architecture (such as the comprehensive judgment of risk control, coupons, and inventory that need to be verified sequentially), the flat query method can only obtain discrete interface information and ignores the upstream and downstream data inheritance and execution sequence between interfaces. Therefore, the above-mentioned approach is adopted, and by introducing a service entity relationship graph and a directed acyclic graph (DAG) topology routing model, the dependency paths and topology flow of multiple interface calls can be accurately identified before code derivation. This global semantic information with time-series constraints is then input into the large language model, fundamentally avoiding the fatal defects of the large model fabricating the call order out of thin air due to the lack of a global time sequence concept, resulting in uninitialized variables or logical deadlocks. This ensures that even in a highly complex microservice architecture, the automatically generated script code still has correct execution logic and engineering-level high availability.

[0068] In one feasible implementation, the following diagram illustrates the process of building a service interface semantic knowledge base: First, the data collection step is initiated. Using a pre-set scheduled crawler script or open interface, scenario description texts for each business domain are extracted from the product requirement management system as scenario data. Simultaneously, signature specifications and data dictionaries for all microservice interfaces are extracted from the abstract syntax tree and API gateway configuration of the code repository as interface data. Next, the data mapping step is executed. Based on pre-set business domain binding rules and manual verification, the collected discrete data is assembled into a three-layer structure: In the scenario layer, the mounting relationship between scenario identifiers and the interface list is established; in the interface metadata layer, class names, method names, and input parameter business semantics are filled in; and in the return semantics layer, the return field types are anchored. The underlying enumeration values ​​are used to form a structured JSON or XML mapping tree. A data vectorization step is then performed, inputting the scene title and description from the scene layer, the parameter business semantics from the interface meta-information layer, and the enumeration meanings from the return semantic layer into a text embedding model in a related technology, outputting a set of semantic representation vectors corresponding to each dimension of data. Finally, a knowledge base solidification step is performed, storing the plaintext data of the three-layer mapping tree structure in a relational database, and simultaneously storing the set of semantic representation vectors in a vector retrieval database, establishing a primary key index association between the two databases, thereby completing the construction of the service interface semantic knowledge base.

[0069] Optional, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating a code generation process. Specifically, it involves constructing code generation constraint prompts based on the semantic information of the target interface for the service verification rule request. Then, based on these constraint prompts, a large language model for code generation is used to generate verification rule code, resulting in the verification rule script code, including: S402: Inject the semantic information of the target interface into the preset prompt word template to construct code generation constraint prompt words; Preset prompt word templates refer to pre-defined structured instruction frameworks used to guide large language models in code generation. In some embodiments, they are typically divided into a system role setting area, a background knowledge injection area, a task objective description area, and an output format limitation area.

[0070] The code generation constraint prompts include a strong constraint context. This strong constraint context refers to the technical boundary constructed for the large language model by injecting deterministic underlying microservice specifications (i.e., target interface semantic information) into the aforementioned preset prompt template. Under this technical boundary constraint, the large language model is prohibited from freely fabricating interface names and parameter types; it can only perform strict translation and deduction based on the given context.

[0071] In a schematic manner, the string replacement and template rendering engine is invoked to inject the semantic information of the target interface (including the extracted class name, method signature, parameter constraints and return status enumeration) as a context variable into the background knowledge injection area of ​​the preset prompt word template. Combined with the service verification rule request, the task target description area and the output format limitation area are filled and adjusted to generate code generation constraint prompt words. S404: Input the code generation constraint prompt into the code generation large language model to control the code generation large language model to execute the code generation logic sequentially, including generating the first code constructed based on the interface parameters according to the code generation constraint prompt, generating the second code for the target interface call based on the code generation constraint prompt, generating the third code for obtaining and parsing the interface return value based on the code generation constraint prompt, and generating the fourth code for defining the verification logic in combination with the service verification rule request; Code generation logic: refers to the internal logic of the large language model (code generation) that transforms unstructured natural language constraints and interface semantics into dimensionality reduction and deduction algorithms that conform to the syntax rules of the target scripting language (such as variable declarations, function calls, and conditional control) according to prompts.

[0072] The first code refers to the set of computer instructions generated by the large language model based on the input parameter constraints in the semantic information of the target interface, used to initialize request variables, assemble business data, and instantiate parameter objects.

[0073] The second code refers to the execution statement generated by the large language model based on the instantiation parameters generated by the first code, combined with the method signature and routing address of the target interface, to initiate remote calls to microservices or application interface requests.

[0074] The third code refers to the parsing statements generated by the large language model, assuming that the second code executes successfully and obtains a response message, for deserializing message objects and extracting core business field data according to a preset hierarchical path.

[0075] The fourth code refers to the conditional control statements that combine the large language model with the original service verification rule request (i.e., the rules described in natural language), call the Boolean operation or assertion syntax of the target scripting language, and perform legality, threshold, or status comparison on the field data parsed by the third code.

[0076] In one feasible implementation, code generation constraint prompts are injected into the context memory of a large code generation language model. The large code generation language model is then controlled to decode the technical boundary constraint domain in the prompts based on an autoregressive attention mechanism. First, the input parameter specifications of the interface call are locked, and the variable declaration and parameter assignment statements are output using the next lexical prediction mechanism to obtain the first code. The large code generation language model retains the variable identifier generated by the first code in the current local scope context. Based on the method signature information in the prompts, the system-level network call function carrying the variable identifier is deduced to obtain the second code. Based on the return semantic layer data mapping dictionary in the prompts, the large code generation language model deduces the hierarchical decomposition and deserialization addressing statements for the returned object of the second code, and assigns the extracted underlying status code or data field to the new local variable to obtain the third code. The large code generation language model shifts its attention weight to the original service verification rule request contained in the prompts, extracts the operators and thresholds required by the business rules, and deduces the conditional branches and return judgment statements for the new local variables to obtain the fourth code. This completes the sequential dependency code deduction under a single text stream.

[0077] In one feasible implementation, the code generation logic is executed sequentially by the code generation large language model, specifically: first code constructed based on the code generation constraint prompts and interface parameters; second code generated based on the code generation constraint prompts and target interface call; third code generated based on the code generation constraint prompts and interface return value acquisition and parsing; and fourth code generated in conjunction with the service verification rule request to define verification logic. This can be achieved by referring to the following approach: Step A2: Control the code generation large language model to extract service object features, and perform feature matching between the service object features and the call parameter features in the scene interface meta-information of the target interface semantic information to obtain the interface parameter mapping relationship, and generate parameter code based on the interface parameter mapping relationship to obtain parameter instantiation code blocks as the first code; Service object characteristics refer to entity nouns, data objects, or attribute identifiers (such as colloquial descriptions of the current user's account, the amount of this order, etc.) extracted by the large language model from unstructured service verification rule requests, representing the core requirements of this business operation.

[0078] Call parameter characteristics refer to the data types, variable naming conventions, and field constraint rules that are explicitly specified in the semantic information of the target interface and are enforced by the underlying microservice interface when it is invoked.

[0079] Interface parameter mapping relationship refers to the data association relationship formed after bidirectional binding and type conversion matching of the above-mentioned service object characteristics with colloquial language and machine-level call parameter characteristics.

[0080] The parameter instantiation code block (first code) refers to the initial code snippet generated by the large language model and conforming to the syntax of the target scripting language. This code snippet is mainly used to declare variables and initialize objects in computer memory, and to assign the extracted business feature values ​​to the corresponding interface input parameter variables through legal syntax.

[0081] In a schematic manner, based on prompt words, the code generation language model utilizes its underlying self-attention mechanism to perform word-level weight calculations on the natural language request sequence, accurately capturing and extracting noun phrase sequences representing the core operational objects as service object features. The code generation language model transforms the extracted service object features into high-dimensional semantic vectors and performs spatial cosine similarity calculations with the vector representations of the various call parameter features listed in the scenario interface metadata of the target interface semantic information. Parameter pairs with similarity scores reaching a pre-set confidence threshold are selected, thereby establishing an interface parameter mapping relationship between fuzzy business terms and precise system variables. After the interface parameter mapping relationship is established, the code generation language model activates a streaming decoder and utilizes the next word prediction mechanism, strictly following the object-oriented programming specifications of the target scripting language (such as Groovy), to autoregressively generate computer execution statements including type declarations, memory allocation (such as using the new keyword to initialize collections or objects), and data boxing assignments. At this point, a complete parameter instantiation code block is obtained as the first code.

[0082] Step A4: Based on the interface parameter mapping relationship and the scenario interface metadata, generate service call code blocks as the second code; Indicatively, after the first code completes the instantiation of the parameter object, the code generation language model reads the interface parameter mapping relationship in its context cache to clarify the input parameter variable identifiers that have been assigned values ​​in the current scope. The code generation language model performs syntax tree parsing on the method signature recorded in the interface meta-information of the scenario, extracting the Remote Procedure Call (RPC) class name and execution function name corresponding to the target microservice. Through the code generation language model using an autoregressive decoding mechanism, within the syntax framework of the target scripting language, the above-mentioned input parameter variable identifiers are filled into the parentheses of the execution function as actual parameters, and an object declaration statement to receive the service return value is generated simultaneously. To ensure the robustness of the generated platform execution script, the code generation language model automatically configures standard exception handling blocks (such as try-catch statements) during the deduction to handle possible network timeouts and service degradation exceptions. Finally, a service call code block containing complete lifecycle control and strong type constraints is generated as the second code.

[0083] Step A6: Based on the semantic information of the returned object of the target interface semantic information, generate data parsing code to obtain the returned data parsing code block as the third code; In a schematic manner, after obtaining the original response object returned by the target interface, the system controls the code generation language model to read the semantic information of the returned object in the semantic information of the target interface. The language model parses the field hierarchy features recorded in the information, identifies the absolute addressing path of the target business data in the response message tree, and deduces the code statement that calls the platform's built-in path parsing engine based on the dynamic parsing characteristics of the target scripting language as the main third code. Optionally, in order to ensure the availability of the generated platform execution script under high concurrency, the code generation language model will automatically nest defensive programming logic on the outer layer of the above parsing statement, that is, generate null pointer checks and default value assignment statements for the original response object and intermediate level nodes, and finally obtain the return data parsing code block as the third code.

[0084] Step A8: Combine the service verification rule request to extract the business status descriptor, and perform semantic matching in the status enumeration dictionary of the target interface semantic information to obtain the target enumeration value. Based on the target enumeration value and the judgment operation syntax of the target scripting language, the judgment logic code is generated to obtain the logical assertion code block as the fourth code.

[0085] Business status descriptors refer to business adjectives or business status nouns extracted from the original natural language request, which cannot be directly recognized by the underlying database or interface (e.g., activated, frozen, in normal use, etc.).

[0086] A state enumeration dictionary refers to a pre-mapped translation table in a knowledge base, which defines the mapping relationship between natural language and machine-level state codes.

[0087] Target enumeration value: refers to the underlying system unique identifier or machine instruction key value that is equivalent to the business status description after translation by the above dictionary.

[0088] In a schematic manner, the extracted business state description words are transformed into semantic vectors by a code generation large language model, and the target enumeration value is determined by high-dimensional feature space comparison in the state enumeration dictionary. Then, according to the standard structure of Boolean operation of the target scripting language, the target enumeration value is concatenated with the actual data variables parsed in the previous steps to form an instruction set. A logical assertion code block containing a complete conditional branch control system and standard response return message is deduced and output as the fourth code, thereby completing the full-link closed-loop action of this automated code generation pipeline.

[0089] S406: Control the code generation large language model to perform code synthesis processing on the first code, the second code, the third code and the fourth code to obtain the verification rule script code.

[0090] In a schematic manner, the code is controlled to generate a large language model for code synthesis processing. After deriving the above four local logic code blocks, these code blocks are processed by variable scope alignment and text concatenation techniques according to the control flow syntax of the target scripting language (such as Groovy or Python).

[0091] In this specification, through S402-S406, the target interface semantics are injected into the template to form a strongly constrained context. The complex code deduction is innovatively decomposed into four standardized micro-subtasks: parameter construction, interface calling, data parsing, and logical assertion. This reduces the logical complexity and error probability of a single inference, ensures that the generated script code has industrial-grade high availability and physical execution compliance, and achieves efficient transformation from natural language business requirements to the platform's underlying execution logic with zero human intervention.

[0092] In one or more embodiments of this specification, the code generation large language model is not a general-purpose large language model without business constraints, but a domain-specific large language model that has undergone deep alignment with the target platform's private interface corpus and has been fine-tuned with customized instructions for the "pipeline generation logic". The specific training process of this code generation large language model includes the following steps: 1) A large number of manually written and stably running real verification scripts were extracted from the historical code repository of the target platform service. Combined with the platform's API documentation gateway, the underlying interface specifications upon which these scripts depend were extracted in reverse engineering to construct an original code corpus pool. Subsequently, structured prompt word engineering was used to reconstruct the original corpus, encapsulating it into instruction fine-tuning data pairs of context constraints and step-by-step code output. Specifically, the input sequence contains a natural language description of the verification rules and structured target interface semantic information (scene metadata, method signature, state enumeration); the target output sequence is strictly labeled or decomposed into four consecutive code segments according to a preset lifecycle: the first code with annotations (parameter instantiation), the second code (remote call), the third code (return parsing), and the fourth code (logic assertion). In this way, a chain-like logic fine-tuning dataset of hundreds of thousands of lines with mandatory temporal constraints was constructed and divided into training and test sets.

[0093] 2) Obtain general-purpose large-scale code language models that have been pre-trained on a massive number of cross-language programming languages ​​(such as Java, Groovy, Python, etc.) (e.g., code generation base models with billions of parameters based on the Transformer decoder architecture, such as the Claude series, Gemini series, Qwen-Coder series, etc.). To retain their massive underlying general syntax tree (AST) inference capabilities while enabling them to quickly adapt to the platform's proprietary interface specifications, high-efficiency parameter fine-tuning techniques (PEFT) such as Low-Rank Adaptive (LoRA) or Prompt Word Fine-Tuning (P-Tuning v2) are employed.

[0094] Optionally, most or all of the pre-trained weights of the feedforward neural network (FFN) and self-attention mechanism layer in the general code-generating large language model used as the base model are frozen, and only a pre-set trainable feature matrix of a very small dimension is injected into the side path of each layer, which is used as the only updatable parameter set in the current training stage, thereby creating the initial code-generating large language model.

[0095] 3) During the supervised fine-tuning phase, the chain-logic fine-tuning dataset is lexicalized and then input into the initialized initial code generation language model in batches. The initial code generation language model is controlled to predict the output code sequence word by word based on the context input using an autoregressive mechanism.

[0096] When calculating the error during the backpropagation training process, based on the predicted output code sequence and the output code sequence labels configured for the input data, a preset loss calculation function (such as the cross-entropy loss function or the Euclidean distance loss function) is called to calculate the model loss value. Based on the model loss value, the model parameters of the initial code generation large language model are adjusted until the model reaches the end of training conditions, and the trained code generation large language model is obtained.

[0097] Optionally, the model's training termination conditions may include, for example, the loss function value being less than or equal to a preset loss function threshold, or the number of iterations reaching a preset threshold. Specific training termination conditions can be determined based on actual circumstances and are not specifically limited here.

[0098] Optional, such as Figure 5 As shown, Figure 5 This is a flowchart illustrating the code verification process. After executing the verification rule script code, you can also refer to the following methods: S502: Input the verification rule script code into the quality inspection language model, and control the quality inspection language model to call the code compiler tool to perform syntax correctness verification on the verification rule script code, and obtain the first verification result; The quality inspection large language model refers to a model independent of the aforementioned code generation models, which uses code review instruction sets and defensive programming corpora to specifically fine-tune and train the large language model (LLM) in related technologies. This quality inspection large language model acts as an automated code reviewer, possessing the ability to call external testing tools and reverse engineer code logic.

[0099] Indicatively, after obtaining the verification rule script code, it is input as a text tensor into the quality inspection language model, and the quality inspection language model is controlled to call the code compiler tool in the sandbox environment through the application programming interface (API) to perform pre-compilation of the script code and capture warnings or error stacks in the compilation log. If there are no syntax-level errors in the compilation log, the first verification result is returned as passed. If a syntax-level error is found in the compilation log, the first verification result is returned as "failed". S504: Parse and extract the verification rule script code to obtain the actual interface call features, and perform interface and parameter consistency verification between the actual interface call features and the baseline interface call features in the target interface semantic information to obtain the second verification result; Actual interface call characteristics refer to the features extracted from the validation rule script code, such as the underlying class name, method name, and input parameter list data that the code actually needs to execute.

[0100] The baseline interface call characteristics refer to the physical interface call technical specifications provided by the service interface semantic knowledge base that must be strictly followed.

[0101] Indicatively, the system controls the large language model for quality inspection to call the code compiler tool through the application programming interface to perform a complete pre-compilation of the script code, capturing warnings or error stacks in the compilation log. If there are no syntax-level fatal errors, the first verification result is returned as passed. Subsequently, the system calls the Abstract Syntax Tree (AST) parsing engine to perform static destructuring of the script code, traversing the network call nodes and parameter encapsulation nodes to extract the actual interface call features. These features are then compared field by field with the baseline interface call features that are forcibly agreed upon in the semantic information of the target interface to verify whether there are serious illusions such as missing parameters, type out-of-bounds errors, or interface name tampering. If they are completely consistent, the second verification result is returned as passed. S506: Perform a logical consistency check between the code verification logic in the verification rule script code and the input rule logic features in the service verification rule request to obtain a third verification result; Input rule logical features refer to the verification judgment conditions (such as greater than or equal to, including), threshold values, and logical operators (such as AND, OR) contained in the original natural language service verification rule request.

[0102] In a schematic way, the control quality inspection big language model compares the code verification logic of the verification rule script code with the input rule logic features extracted from the original service verification rule request to determine whether a logical offset has occurred. If the matching result is less than or equal to the matching threshold, the third verification result is returned as pass; otherwise, if the matching result is greater than the matching threshold, the third verification result is returned as fail. S508: If the first verification result, the second verification result, and the third verification result all pass, then output the verification rule script code.

[0103] As an illustration, if the first, second, and third verification results are all found to be passed, the verification rule script code is output.

[0104] In this specification, executing S502-S508 involves rigorous syntax validation via the code compiler, completely eliminating the risk of compilation errors and runtime crashes at the physical level. By comparing the actual call characteristics with the knowledge base benchmark characteristics, it accurately intercepts parameter mispassing and unauthorized call vulnerabilities caused by the illusion of a large language model. Through reverse engineering of the code logic and semantic comparison with the original request, it ensures that the execution logic aligns with the original business intent. This eliminates the possibility of inferior scripts entering the execution engine, reducing the cost of manual code review while ensuring that the final output validation rule script code possesses high engineering usability and business security.

[0105] In one feasible implementation, the quality inspection large language model is not a general dialogue model, but rather an expert-level vertical model specifically designed for automated code verification and logic error detection. This model is trained using a Large Language Model (LLM) with rigorous code review instruction set fine-tuning and rule-based reinforcement learning alignment. The specific training process of this quality inspection large language model includes the following steps: 1. Obtain high-quality verification rule code accumulated from the target platform's service history as positive samples. Subsequently, invoke a preset abstract syntax tree mutation engine to automatically perform data augmentation and defect injection on the positive samples, generating negative samples containing syntactic incompleteness (e.g., unclosed parentheses), misuse of interface specifications (e.g., mismatched input parameter types, missing required parameters), and business logic deviations (e.g., changing greater than to less than or equal to). Configure standard quality inspection prompt word pairs for the above positive and negative samples, and configure expected output labels for each positive and negative sample. For example, the input instruction includes: "Constraint context + script code to be tested, please verify its syntax, interface, and logic consistency"; the expected output label is a structured review report: "Verification result: Failed; Anomaly feature: The direction of the logic operator in line X is incorrect, expected to be PASS_01, actual comparison is FAIL_00". Through the above defect injection and formatting combination, a quality inspection instruction fine-tuning dataset containing a massive code-diagnostic report mapping relationship is constructed.

[0106] 2. Obtain a large language model (LLM) pre-trained on a large-scale cross-language code review corpus as the code base model. Inject a trainable low-rank adaptive (LoRA) weight matrix into the bypass of its multilayer perceptron (MLP) network layer, and freeze most or all of the parameters of the original base model to obtain the initial quality inspection large language model.

[0107] During the supervised fine-tuning phase, the quality inspection instruction fine-tuning dataset is input into the initial quality inspection language model in batches. The initial quality inspection language model is controlled to perform forward propagation calculations, outputting predicted code review diagnostic sequences. The cross-entropy loss function is used to calculate the error value between the predicted diagnostic sequences and the true expected output labels. A gradient descent optimizer is used to perform backpropagation, dynamically updating the trainable parameters of the LoRA weight matrix, enabling the initial quality inspection language model to gradually acquire the basic ability to accurately locate code defects and output structured anomaly features. This process continues until the initial quality inspection language model meets the model termination conditions, resulting in a trained quality inspection language model.

[0108] In one feasible implementation, the following approach may also be referenced: Step B2: If at least one of the first verification result, the second verification result, and the third verification result fails the verification, the output action of the verification rule script code is intercepted. Interception refers to defensive control actions that forcibly terminate the flow of substandard verification rule script code to the downstream production execution engine through methods such as software interruption or gateway routing drop.

[0109] Step B4: Determine the quality inspection anomaly characteristics corresponding to the failure of result verification; Quality inspection anomaly features refer to structured diagnostic data that accurately describes code errors. These can include low-level compilation error stack traces, missing input parameter variable names, XOR errors in business logic operators, and so on.

[0110] Step B6: Convert the quality inspection anomaly features into negative feedback penalty prompts, and append the negative feedback penalty prompts to the code generation constraint prompts. Re-trigger the code generation large language model to perform the verification rule code generation process to obtain the verification rule script code.

[0111] Indicatively, if at least one of the first, second, and third verification results fails the verification, a circuit breaker mechanism is triggered to intercept the output of the verification rule script code and clean up its memory residue in the sandbox; a preset exception log parsing engine is invoked to extract specific error information based on the type of failed verification. For example, if the first verification fails, the line number of the syntax error thrown by the compiler and the stack trace are extracted; if the second verification fails, the actual interface call feature name that is missing or mismatched is extracted. These concrete error messages are serialized into the quality inspection exception features; and a preset penalty template engine is used to convert the quality inspection exception features into natural language. The negative feedback penalty prompt (such as "Your last generated code had an error Y in line X, please be sure to correct it") is used as an appended context boundary and forcibly appended to the end of the original code generation constraint prompt. Then, the step in S106, which uses the code generation constraint prompt to generate validation rule code based on the code generation large language model, is executed to obtain the validation rule script code. In other words, it is sent back to the code generation large language model as a brand new input, forcing the model to re-execute attention calculation and code deduction in a context containing error memory, until the output validation rule script code can successfully pass the entire quality inspection process.

[0112] This specification effectively solves the technical problems of traditional large language models lacking reflective ability in single generation and heavily relying on manual debugging after errors by forcibly intercepting inferior code when multi-dimensional quality checks fail and accurately extracting abnormal features such as compilation errors or specification deviations. These features are then transformed into negative feedback penalty prompts with a strong constraint tone and added to the next inference context of the large model. This closed-loop solution can guide the large language model to perform targeted self-correction and iterative retry based on clear error boundaries. Without any manual intervention, it endows the entire R&D pipeline with strong system self-healing and fault tolerance capabilities, thereby ensuring the final delivery availability of automated script code in complex business scenarios.

[0113] The following will combine Figure 6 This manual provides a detailed description of the code generation device provided. It should be noted that... Figure 6 The code generation apparatus shown is used to execute this specification. Figures 1-5 The methods of the embodiments shown are illustrated only in connection with this specification for ease of explanation. For specific technical details not disclosed, please refer to this specification. Figures 1-5 The example shown.

[0114] Please see Figure 6This diagram illustrates the structure of the code generation device described in this specification. The code generation device 1 can be implemented as all or part of a device through software, hardware, or a combination of both. According to some embodiments, the code generation device 1 includes a code generation module 11, a code generation module 12, and a code generation module 13, specifically used for: Scene recognition module 11 is used to respond to a service verification rule request input for a target platform service, and to perform scene recognition on the service verification rule request to obtain the target service scene; Information matching module 12 is used to match the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario. Code generation module 13 is used to construct code generation constraint prompts for the service verification rule request based on the semantic information of the target interface, and to perform verification rule code generation processing using a code generation large language model based on the code generation constraint prompts to obtain verification rule script code.

[0115] Optionally, the step of matching the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario includes: Based on the target service scenario, information query processing is performed in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base to obtain scenario verification interface information, interface meta-information, and return object semantic information. Based on the scenario verification interface information, scenario interface metadata, and returned object semantic information, the target interface semantic information corresponding to the service verification rule request is generated.

[0116] Optionally, the step of performing information query processing based on the target service scenario in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base includes: Retrieve multiple target service entity nodes associated with the target service scenario in the preset service entity relationship graph, and extract the edge dependency features between the target service entity nodes; Based on the edge dependency characteristics, the microservice interface concatenation path required for the service verification rule request is determined, and based on the interface call dependency order in the microservice interface concatenation path, a target routing topology model corresponding to the target service scenario is constructed. Based on the topology flow direction of the target routing topology model, information query processing is performed on each topology service entity node in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base.

[0117] Optionally, the step of constructing code generation constraint prompts for the service verification rule request based on the semantic information of the target interface, and using a code generation large language model to generate verification rule code based on the code generation constraint prompts to obtain verification rule script code includes: The semantic information of the target interface is injected into a preset prompt word template to construct code generation constraint prompt words; The code generation constraint prompt is input into the code generation large language model to control the code generation large language model to execute the code generation logic in sequence, which generates the first code constructed based on the interface parameters according to the code generation constraint prompt, the second code generated based on the code generation constraint prompt to call the target interface, the third code generated based on the code generation constraint prompt to obtain and parse the interface return value, and the fourth code generated in combination with the service verification rule request to define the verification logic. The code generation language model is controlled to perform code synthesis processing on the first code, the second code, the third code, and the fourth code to obtain the verification rule script code.

[0118] Optionally, the control of the code generation large language model to sequentially execute code generation logic includes: first code constructed based on the code generation constraint prompts to generate interface parameters; second code generated based on the code generation constraint prompts to generate target interface calls; third code generated based on the code generation constraint prompts to obtain and parse the interface return value; and fourth code generated in conjunction with the service verification rule request to define verification logic. The code generation large language model is controlled to extract service object features, and the service object features are matched with the call parameter features in the scene interface meta information of the target interface semantic information to obtain the interface parameter mapping relationship. The parameter code is generated according to the interface parameter mapping relationship to obtain the parameter instantiation code block as the first code. Based on the interface parameter mapping relationship and the scenario interface metadata, call code is generated to obtain a service call code block as the second code; Based on the semantic information of the returned object of the target interface semantic information, data parsing code is generated to obtain a returned data parsing code block as the third code; The service verification rules request is used to extract business status descriptors, and semantic matching is performed in the status enumeration dictionary of the target interface semantic information to obtain the target enumeration value. Based on the target enumeration value and the judgment operation syntax of the target scripting language, judgment logic code is generated to obtain a logical assertion code block as the fourth code.

[0119] Optionally, after obtaining the verification rule script code, the method further includes: The verification rule script code is input into the quality inspection language model, and the quality inspection language model is controlled to call the code compiler tool to perform syntax correctness verification on the verification rule script code to obtain the first verification result; The actual interface call features are obtained by parsing and extracting the verification rule script code, and the actual interface call features are then compared with the baseline interface call features in the target interface semantic information to verify the consistency of the interface and parameters, thus obtaining a second verification result. The code verification logic in the verification rule script code is logically consistent with the input rule logic features in the service verification rule request to obtain a third verification result. If the first verification result, the second verification result, and the third verification result all pass, then the verification rule script code is output.

[0120] Optionally, the device further includes: If at least one of the first verification result, the second verification result, and the third verification result fails the verification, the output action of the verification rule script code is blocked. Identify the quality inspection anomalies that caused the results to fail verification. The quality inspection anomaly features are converted into negative feedback penalty prompts, which are then appended to the code generation constraint prompts. This triggers the code generation language model to re-process the verification rule code generation, resulting in the verification rule script code.

[0121] Optionally, the step of obtaining the target service scenario by performing scenario identification on the service verification rule request includes: The service verification rule request is input into the scene recognition large language model, and semantic feature extraction and intent parsing are performed on the service verification rule request to obtain the target intent feature; The scene recognition big language model is controlled to perform keyword matching processing between the target intent features and a preset set of standard business scenarios to obtain the target service scenario.

[0122] It should be noted that the code generation device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the code generation method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the code generation device and the code generation method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0123] The serial numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0124] This specification also provides a computer storage medium capable of storing multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-5 The code generation method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0125] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-5 The code generation method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0126] Please refer to Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this specification. The electronic device in this specification may include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, memory 1020, input device 1030, and output device 1040 may be connected to each other via the bus 1050.

[0127] Processor 1010 may include one or more processing cores. Processor 1010 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 1020, and by calling data stored in memory 1020. Optionally, processor 1010 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 1010 may integrate one or more of a central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 1010 and may be implemented separately through a communication chip.

[0128] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets.

[0129] The input device 1030 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 1040 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In this embodiment, the input device 1030 can be a temperature sensor for acquiring the operating temperature of the electronic device. The output device 1040 can be a speaker for outputting audio signals.

[0130] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WIFI) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0131] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0132] exist Figure 7 In the electronic device, the processor 1010 can be used to call a program stored in the memory 1020 and execute it to implement the code generation method as described in the various method embodiments of this specification.

[0133] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0134] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, data, and information involved in this specification were all obtained under full authorization.

[0135] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A code generation method, characterized in that, The method includes: In response to a service verification rule request input for a target platform service, the service verification rule request is used to identify the target service scenario. Based on the target service scenario, the semantic information of the target interface corresponding to the service verification rule request is matched in the service interface semantic knowledge base corresponding to the target platform service. Based on the semantic information of the target interface, code generation constraint prompts are constructed for the service verification rule request. Based on the code generation constraint prompts, a large code generation language model is used to generate verification rule code to obtain the verification rule script code.

2. The method according to claim 1, wherein matching the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario includes: Based on the target service scenario, information query processing is performed in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base to obtain scenario verification interface information, interface meta-information, and return object semantic information. Based on the scenario verification interface information, scenario interface metadata, and returned object semantic information, the target interface semantic information corresponding to the service verification rule request is generated.

3. The method according to claim 2, wherein the information query processing based on the target service scenario in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base includes: Retrieve multiple target service entity nodes associated with the target service scenario in the preset service entity relationship graph, and extract the edge dependency features between the target service entity nodes; Based on the edge dependency characteristics, the microservice interface concatenation path required for the service verification rule request is determined, and based on the interface call dependency order in the microservice interface concatenation path, a target routing topology model corresponding to the target service scenario is constructed. Based on the topology flow direction of the target routing topology model, information query processing is performed on each topology service entity node in the scenario layer, interface meta-information layer, and return semantic layer of the service interface semantic knowledge base.

4. The method according to claim 1, characterized in that, The step involves constructing code generation constraint prompts for the service verification rule request based on the semantic information of the target interface. Then, based on these constraint prompts, a large language model for code generation is used to generate the verification rule code, resulting in the verification rule script code, including: The semantic information of the target interface is injected into a preset prompt word template to construct code generation constraint prompt words; The code generation constraint prompt is input into the code generation large language model to control the code generation large language model to execute the code generation logic in sequence, which generates the first code constructed based on the interface parameters according to the code generation constraint prompt, the second code generated based on the code generation constraint prompt to call the target interface, the third code generated based on the code generation constraint prompt to obtain and parse the interface return value, and the fourth code generated in combination with the service verification rule request to define the verification logic. The code generation language model is controlled to perform code synthesis processing on the first code, the second code, the third code, and the fourth code to obtain the verification rule script code.

5. The method according to claim 4, characterized in that, The control mechanism for the large language model to sequentially execute code generation logic includes: first code constructed based on the code generation constraint prompts and interface parameters; second code generated based on the code generation constraint prompts and target interface call; third code generated based on the code generation constraint prompts and interface return value acquisition and parsing; and fourth code generated in conjunction with the service verification rule request to define verification logic. The code generation large language model is controlled to extract service object features, and the service object features are matched with the call parameter features in the scene interface meta information of the target interface semantic information to obtain the interface parameter mapping relationship. The parameter code is generated according to the interface parameter mapping relationship to obtain the parameter instantiation code block as the first code. Based on the interface parameter mapping relationship and the scenario interface metadata, call code is generated to obtain a service call code block as the second code; Based on the semantic information of the returned object of the target interface semantic information, data parsing code is generated to obtain a returned data parsing code block as the third code; The service verification rules request is used to extract business status descriptors, and semantic matching is performed in the status enumeration dictionary of the target interface semantic information to obtain the target enumeration value. Based on the target enumeration value and the judgment operation syntax of the target scripting language, judgment logic code is generated to obtain a logical assertion code block as the fourth code.

6. The method according to claim 1, characterized in that, After obtaining the verification rule script code, the process also includes: The verification rule script code is input into the quality inspection language model, and the quality inspection language model is controlled to call the code compiler tool to perform syntax correctness verification on the verification rule script code to obtain the first verification result; The actual interface call features are obtained by parsing and extracting the verification rule script code, and the actual interface call features are then compared with the baseline interface call features in the target interface semantic information to verify the consistency of the interface and parameters, thus obtaining a second verification result. The code verification logic in the verification rule script code is logically consistent with the input rule logic features in the service verification rule request to obtain a third verification result. If the first verification result, the second verification result, and the third verification result all pass, then the verification rule script code is output.

7. The method according to claim 6, characterized in that, The method further includes: If at least one of the first verification result, the second verification result, and the third verification result fails the verification, the output action of the verification rule script code is blocked. Identify the quality inspection anomalies that caused the results to fail verification. The quality inspection anomaly features are converted into negative feedback penalty prompts, which are then appended to the code generation constraint prompts. This triggers the code generation language model to re-process the verification rule code generation, resulting in the verification rule script code.

8. The method according to claim 1, characterized in that, The step of obtaining the target service scenario by performing scenario identification on the service verification rule request includes: The service verification rule request is input into the scene recognition large language model, and semantic feature extraction and intent parsing are performed on the service verification rule request to obtain the target intent feature; The scene recognition big language model is controlled to perform keyword matching processing between the target intent features and a preset set of standard business scenarios to obtain the target service scenario.

9. A code generation device, characterized in that, The device includes: The scene recognition module is used to respond to the service verification rule request input for the target platform service, and to perform scene recognition on the service verification rule request to obtain the target service scene; The information matching module is used to match the target interface semantic information corresponding to the service verification rule request in the service interface semantic knowledge base corresponding to the target platform service based on the target service scenario. The code generation module is used to construct code generation constraint prompts for the service verification rule request based on the semantic information of the target interface, and to perform verification rule code generation processing using a code generation large language model based on the code generation constraint prompts to obtain the verification rule script code.

10. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method as claimed in any one of claims 1 to 8.

11. A computer program product storing at least one instruction, said at least one instruction being loaded by a processor and executing the steps of the method as claimed in any one of claims 1 to 8.

12. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as described in any one of claims 1 to 8.

Images