Service scaffold generation method and device based on rule engine, and electronic equipment

Abstract

The invention discloses a service scaffold generation method and device based on a rule engine and electronic equipment, and relates to the field of financial science and technology or other related technical fields, and the method comprises the steps: after a user demand text is received, extracting a transaction model, a base class path and a class name in the user demand text through the rule engine, a structured parameter tuple is obtained through combination, a service scaffold conforming to constraint specifications is generated through a large language model based on the structured parameter tuple and the business demand prompt information, and the constraint specifications are generated based on a pre-constructed base class template and historical service typical cases pre-stored in a target knowledge base. The technical problem that in the related technology, in the financial system software development process, a thing processing mode depends on direct coding of a development end, and the development efficiency is low is solved.

Description

Technical Field

[0001] This invention relates to the field of financial technology or other related fields, and more specifically, to a service scaffolding generation method and apparatus, and electronic device based on a rules engine. Background Technology

[0002] In the development of modern financial software systems, transaction management is a crucial component for ensuring data consistency and system stability. This is especially true in distributed online service environments, where the correctness and efficiency of transactions directly impact business operations and user experience. Current transaction processing methods rely on direct coding by developers. This approach not only results in long development cycles and a heavy workload of manually writing basic code, complex business logic, and innovative features, but also easily leads to unclear transaction boundary definitions and improper exception handling, particularly in high-concurrency and cross-service scenarios. Furthermore, developing transaction models using rule engines suffers from a lack of private domain knowledge within the financial industry, resulting in code with lower compliance rates in terms of transaction models and layered specifications.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a service scaffolding generation method, apparatus, and electronic device based on a rules engine, to at least solve the technical problem of low development efficiency in the development of financial system software where transaction processing relies on direct coding by the development end.

[0005] To achieve the above objectives, according to one aspect of this application, a service scaffolding generation method based on a rule engine is provided, comprising: upon receiving user requirement text, extracting transaction model, base class path, and class name from the user requirement text using a rule engine, and combining them to obtain a structured parameter tuple, wherein the transaction model includes a set of strategies that meet data consistency requirements in a distributed system, and the base class path includes the location of a specified base class defined in the project; and generating a service scaffolding conforming to constraint specifications using a large language model based on the structured parameter tuple and business requirement prompt information, wherein the constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in a target knowledge base.

[0006] Optionally, the step of extracting the transaction model, base class path, and class name from the user requirement text using a rule engine and combining them to obtain a structured parameter tuple includes: extracting keyword combinations and default value rules related to the transaction model from the user requirement text using a rule engine, and determining the transaction model based on the keyword combinations and default value rules; obtaining a specified base class by matching the base class path in the user requirement text using a rule engine; and combining the transaction model, the specified base class, and the class name to obtain the structured parameter tuple.

[0007] Optionally, after extracting the transaction model, base class path, and class name from the user requirement text through the rule engine and combining them to obtain a structured parameter tuple, the method further includes: searching for example code using the transaction model and the specified base class, and determining typical historical service cases based on the example code; determining base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions based on the typical historical service cases and the business requirements input by the code development end; and generating the business requirement prompt information based on the typical historical service cases, base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions.

[0008] Optionally, after generating a service scaffold conforming to the constraint specifications through a large language model based on the structured parameter tuples and business requirement prompts, the method further includes: performing a preset syntax check on the service scaffold; if the syntax check passes, performing base class inheritance verification and transaction annotation verification on the service scaffold, wherein the base class inheritance verification includes: performing base class inheritance rule verification on a specified base class, and the transaction annotation verification includes: annotation existence verification, annotation parameter verification, and transaction boundary consistency verification; if both the base class inheritance verification and the transaction annotation verification pass, performing naming specification matching on the service scaffold using a regular expression validator to obtain a naming specification matching result; if the naming specification matching result meets the naming requirements, outputting the service scaffold.

[0009] Optionally, after outputting the service scaffold, the method further includes: recording the generated service scaffold by embedding data points to obtain the number of lines of code generated and the class names in the service scaffold; retrieving the same class names in the target knowledge base based on the recorded class names in the service scaffold, wherein the target knowledge base includes modified code fed back by the code development end and the actual code entered into the knowledge base; comparing the code indicated by the class names in the service scaffold with the code indicated by the same class names in the target knowledge base to determine a discrepancy list, wherein the discrepancy list includes at least: the number of lines of code actually entered into the target knowledge base; comparing the number of generated code lines with the number of lines of code actually entered into the target knowledge base to obtain the actual entry rate; evaluating the code generation quality parameters based on the actual entry rate, and adjusting the business requirement prompt information in conjunction with the code generation quality parameters.

[0010] Optionally, after determining the discrepancy list, the method further includes: obtaining code modification information from the code development end through the discrepancy list; determining the final example code based on the code modification information, and storing the final example code as a typical service case in the target knowledge base; extracting the new transaction rules from the final example code, and updating the rule base in the rule engine based on the new transaction rules.

[0011] Optionally, the rule base in the rule engine stores: base class matching rules and transaction judgment rules; the target knowledge base pre-stores multiple base class templates and multiple sample code corresponding to historical service typical cases.

[0012] According to another aspect of the present invention, a service scaffolding generation apparatus based on a rule engine is also provided, comprising: a rule engine extraction unit, configured to, upon receiving user requirement text, extract transaction model, base class path, and class name from the user requirement text using a rule engine, and combine them to obtain a structured parameter tuple, wherein the transaction model includes a set of strategies that meet data consistency requirements in a distributed system, and the base class path includes the location of a specified base class defined in the project; and a service scaffolding generation unit, configured to, based on the structured parameter tuple and business requirement prompt information, generate a service scaffolding conforming to constraint specifications using a large language model, wherein the constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in a target knowledge base.

[0013] Optionally, the rule engine extraction unit includes: a rule engine extraction module, used to extract keyword combinations and default value rules of associated transaction models in the user requirement text through the rule engine, and determine the transaction model based on the keyword combinations and default value rules; a base class matching module, used to obtain a specified base class by matching the base class path in the user requirement text through the rule engine; and a combination module, used to combine the transaction model, the specified base class, and the class name to obtain the structured parameter tuple.

[0014] Optionally, the service scaffolding generation device based on the rule engine further includes: an example code search unit, used to search for example code using the transaction model and the specified base class after extracting the transaction model, base class path and class name from the user requirement text through the rule engine and combining them to obtain a structured parameter tuple, and to determine typical historical service cases based on the example code; a rule determination unit, used to determine base class inheritance rules, transaction annotation rules, naming conventions and coding conventions based on the typical historical service cases and the business requirements input by the code development end; and a requirement prompt generation unit, used to generate the business requirement prompt information based on the typical historical service cases, base class inheritance rules, transaction annotation rules, naming conventions and coding conventions.

[0015] Optionally, the service scaffolding generation device based on the rule engine further includes: a syntax checking unit, used to perform a preset syntax check on the service scaffolding after generating a service scaffolding conforming to the constraint specification through a large language model based on the structured parameter tuples and business requirement prompts; a verification unit, used to perform base class inheritance verification and transaction annotation verification on the service scaffolding if the syntax check passes, wherein the base class inheritance verification includes: base class inheritance rule verification on a specified base class, and the transaction annotation verification includes: annotation existence verification, annotation parameter verification, and transaction boundary consistency verification; a naming convention matching unit, used to perform naming convention matching on the service scaffolding through a regular expression validator if both the base class inheritance verification and transaction annotation verification pass, to obtain a naming convention matching result; and a scaffolding code output unit, used to output the service scaffolding if the naming convention matching result meets the naming requirements.

[0016] Optionally, the service scaffolding generation device based on the rule engine further includes: a code tracking unit, used to track and record each generated service scaffolding after it is output, to obtain the number of generated code lines and the class names in the service scaffolding; a class name retrieval unit, used to retrieve the same class names in the target knowledge base based on the recorded class names in the service scaffolding, wherein the target knowledge base includes modified code fed back by the code development end and the actual code entered into the database; a code difference determination unit, used to compare the code indicated by the class names in the service scaffolding with the code indicated by the same class names in the target knowledge base, to determine a difference list, wherein the difference list includes at least: the number of code lines actually entered into the target knowledge base; a code entry rate determination unit, used to compare the number of generated code lines with the number of code lines actually entered into the target knowledge base, to obtain the actual entry rate; and a prompt information adjustment unit, used to evaluate the code generation quality parameters based on the actual entry rate, and adjust the business requirement prompt information in conjunction with the code generation quality parameters.

[0017] Optionally, the service scaffolding generation device based on the rule engine further includes: a code modification information acquisition unit, used to acquire code modification information fed back by the code development end through the difference list after determining the difference list; a final example code determination unit, used to determine the final example code based on the code modification information, and store the final example code as a typical service case in the target knowledge base; and a new transaction rule extraction unit, used to extract the new transaction rules in the final example code, and update the rule base in the rule engine based on the new transaction rules.

[0018] Optionally, the rule base in the rule engine stores: base class matching rules and transaction judgment rules; the target knowledge base pre-stores multiple base class templates and multiple sample code corresponding to historical service typical cases.

[0019] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the service scaffolding generation method based on the rule engine described above.

[0020] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the rule engine-based service scaffolding generation method described above.

[0021] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the rule engine-based service scaffolding generation method described above.

[0022] In this disclosure, after receiving the user's requirement text, the transaction model, base class path, and class name are extracted from the user's requirement text through a rule engine and combined to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project. Based on the structured parameter tuple and business requirement prompts, a service scaffolding that conforms to the constraint specification is generated through a large language model. The constraint specification is generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base.

[0023] Based on the above-mentioned information, the automatic generation of service scaffolding can be achieved through the collaboration of rule engine and large language model. By automatically generating transaction processing code, the tedious process of manually coding transaction logic on the development side can be saved, greatly improving development efficiency, shortening scaffolding generation time, and reducing development cycle. This solves the technical problem of low development efficiency in the development of financial system software where transaction processing methods rely on direct coding on the development side. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0025] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a service scaffolding generation method based on a rules engine is shown.

[0026] Figure 2 This is a flowchart of an optional service scaffolding generation method based on a rule engine according to an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram of an optional distributed online service scaffolding generation method based on rule engine and large model collaboration according to an embodiment of the present invention;

[0028] Figure 4 This is a schematic diagram of an optional layered result verification according to an embodiment of the present invention;

[0029] Figure 5 This is a schematic diagram illustrating an optional method for automatically adjusting the knowledge base based on code modifications on the development side, according to an embodiment of the present invention.

[0030] Figure 6 This is a schematic diagram of an optional service scaffolding generation device based on a rule engine according to an embodiment of the present invention;

[0031] Figure 7 This is a structural block diagram of an electronic device that executes a service scaffolding generation method based on a rule engine, according to an embodiment of this application. Detailed Implementation

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

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0035] A rule engine is a software system that judges and makes decisions based on a pre-set rule base. In this invention, the rule engine is used to transform financial development specifications into executable rules, thereby automatically generating code, ensuring that the code conforms to specific business rules and specifications, and improving the compliance and consistency of the code.

[0036] Transaction Mode (TM) is a strategy used in distributed systems to ensure data consistency across multiple services or database operations.

[0037] Long-running transactions, or Saga for short, are a distributed transaction management pattern that achieves transaction consistency across services by combining a series of local transactions (i.e., sub-transactions).

[0038] TCC, or Try-Confirm-Cancel, is a distributed transaction pattern that achieves data consistency by dividing transactions into three phases: try, confirm, and cancel. The try phase reserves resources, the confirm phase executes business logic, and the cancel phase rolls back changes. Its purpose is to ensure the atomicity and consistency of business operations in a distributed environment.

[0039] Scaffolding code is a predefined code template used to quickly build service infrastructure. It provides a starting framework for service development, and developers can add specific business logic to this code. Its purpose is to accelerate the development process, standardize service structure, and improve code quality and development efficiency.

[0040] It should be noted that the rule engine-based service scaffolding generation method and apparatus disclosed herein can be used in the field of fintech for the generation of distributed online service scaffolding based on the collaboration of rule engines and large language models, and can also be used in any field other than fintech for the generation of distributed online service scaffolding based on the collaboration of rule engines and large language models. This disclosure does not limit the application field of the rule engine-based service scaffolding generation method and apparatus.

[0041] It should be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected in this public disclosure are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0042] It should be noted that in this disclosure, customer information is collected and analyzed, and users are provided with corresponding operation entry points to choose whether to agree to or reject the automated decision-making results; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0043] The following embodiments of the present invention can be applied to various systems / applications / devices based on rule engine-based service scaffolding generation. The present invention can be applied to the development of online service scaffolding under distributed systems and microservice architectures in financial software development scenarios. For example, in scenarios involving cross-service transaction operations, the present invention can automatically select a transaction model (such as SAGA or TCC) according to business requirements and generate corresponding transaction management code to ensure transaction consistency and atomicity.

[0044] The present invention will now be described in detail with reference to various embodiments.

[0045] Example 1

[0046] According to an embodiment of the present invention, an embodiment of a service scaffolding generation method based on a rule engine is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0047] The service scaffolding generation method based on a rule engine provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a rules engine-based service scaffolding generation method is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA)) is shown as 102a, 102b, ..., 102n. It also includes a memory 104 for storing data and a transmission device 106 for communication functions. In addition, it may include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0048] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0049] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the rule engine-based service scaffolding generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned rule engine-based service scaffolding generation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0051] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0052] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for generating service scaffolding based on a rules engine is shown. Figure 2 This is a flowchart of an optional service scaffolding generation method based on a rule engine according to an embodiment of the present invention, such as... Figure 2As shown, the method includes the following steps:

[0053] Step S201: After receiving the user requirement text, the transaction model, base class path and class name in the user requirement text are extracted by the rule engine and combined to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project.

[0054] In this embodiment, after receiving the user's request text, the rule engine parses the text to identify keyword combinations highly correlated with the transaction model. Taking into account default value rules, a suitable set of transaction model strategies is determined based on this. It should be noted that the transaction model strategy set in this embodiment can cover various technical strategies for ensuring data consistency in distributed systems, such as SAGA (long-lived transactions) and TCC (try-confirm-cancel), which helps ensure that the generated code can correctly handle data transactions in a distributed environment, meeting the stringent data consistency requirements of the financial industry.

[0055] Optionally, the step of extracting the transaction model, base class path, and class name from the user requirement text using a rule engine and combining them to obtain a structured parameter tuple includes: extracting keyword combinations and default value rules related to the transaction model from the user requirement text using a rule engine, and determining the transaction model based on the keyword combinations and default value rules; obtaining a specified base class by matching the base class path in the user requirement text using a rule engine; and combining the transaction model, the specified base class, and the class name to obtain a structured parameter tuple.

[0056] The rule engine intelligently identifies specific keyword combinations in user request texts. These combinations point to different transaction processing needs, such as "positive / negative transaction" + "compensation," indicating the use of the SAGA model. This helps to accurately match the transaction model, reduce manual intervention, and accelerate code generation. Based on information in the user request text, the rule engine searches for and matches the locations of already defined base classes in the project to determine the correct base class. This mechanism ensures that the generated code follows the project's architectural hierarchy; for example, service classes in the high-level transaction service layer should inherit from specific base classes, which helps maintain a clear and consistent code structure. Subsequently, the transaction model, base class path, and class name can be encapsulated into a structured parameter tuple by the rule engine. This tuple serves as the basic input for generating code from the large model, containing not only key information about transaction processing but also clearly defining the goals and context of code generation. This helps the large model adhere to established specifications and frameworks during the generation process, enhancing the applicability and accuracy of the code.

[0057] Optionally, the rule base in the rule engine stores: base class matching rules and transaction judgment rules; the target knowledge base pre-stores multiple base class templates and historical service typical cases corresponding to multiple sample codes.

[0058] The rule base in the rule engine pre-stores a series of base class matching rules and transaction judgment rules. These base class matching rules define how to select the most suitable base class based on specific service characteristics and business requirements. The accuracy and comprehensiveness of the base class matching rules help ensure that the service scaffolding follows the established framework and patterns in its architectural design, effectively improving code reusability and consistency, and reducing development difficulties caused by inappropriate base class selection. Transaction judgment rules are used to parse and determine the transaction model in the service. Based on the business characteristics and technical specifications of the financial industry, they can accurately identify transaction processing requirements in service needs, such as the choice between SAGA or TCC models. This helps establish clear transaction boundaries before code generation, ensuring the consistency and reliability of the service in a distributed environment.

[0059] Furthermore, the target knowledge base pre-stores multiple base class templates. These templates cover various typical service architectures in financial system development and can serve as reference blueprints for code generation, helping to quickly build the basic framework of services while ensuring the standardization and normalization of code structure. In addition to the base class templates, the target knowledge base also includes a large number of sample codes corresponding to them. These codes are a summary of best practices in past service development, reflecting the functional implementation and technical challenges in actual business scenarios. By learning from and referencing these typical historical service cases, the practicality and innovation of code generation can be enhanced, ensuring that the generated service scaffolding not only meets basic functional requirements but also can handle complex business logic and optimization needs.

[0060] Step S202: Based on the structured parameter tuples and business requirement prompts, a service scaffold conforming to the constraint specifications is generated through a large language model. The constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base.

[0061] To further improve efficiency and standardization, this embodiment employs a dynamic knowledge injection mechanism. This involves integrating the rule engine's output (transaction model, base class path, and class name) along with relevant historical best practice examples into the prompts of the large model in real time. This ensures that the large language model can access the latest base class templates and historical service cases during code generation. The goal is to build a strongly constrained generation environment, enabling the large model to reference the latest transaction processing rules and project specifications while also drawing on past successful cases. The generated code not only meets current requirements but also follows best practices, thus improving code quality.

[0062] In this embodiment, the type of large language model is not limited. Based on structured parameter tuples and detailed business requirements, the model can generate a service scaffolding that conforms to the specifications. The generation process takes into account the diversity of business logic and follows financial-grade development specifications, which helps to quickly build the basic framework of the service and thus shorten the development cycle.

[0063] The constraints and specifications are formed based on two key sources: pre-built base class templates and historical service case studies from the target knowledge base. The base class templates provide the basic structure and functionality of the code, ensuring that the newly generated scaffolded code remains consistent with the existing framework in terms of architecture and functionality. Historical service case studies, on the other hand, provide rich reference materials for the large language model, allowing the model to learn best practices in specific business scenarios. This results in more intelligent and practical code, improving code quality and reducing the workload of later modifications and adjustments.

[0064] Through the above steps, after receiving the user's requirement text, the rule engine extracts the transaction model, base class path, and class name from the user's requirement text and combines them to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet data consistency requirements in the distributed system, and the base class path includes the location of a specified base class defined in the project. Based on the structured parameter tuple and business requirement hints, a service scaffold conforming to constraint specifications is generated through a large language model. The constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base. In this embodiment, the rule engine and the large language model can work together to automate the generation of service scaffolds. By automatically generating transaction processing code, the tedious process of manually coding transaction logic on the development side is saved, improving development efficiency, shortening scaffold generation time, and reducing the development cycle. This solves the technical problem in related technologies where transaction processing in financial system software development relies on direct coding by the development side, resulting in low development efficiency.

[0065] In this embodiment, the prompts from the large language model are not limited to structured parameter tuples and business requirements, but can also include specific business rules, exception handling methods, and performance optimization suggestions. The generation of intelligent prompts helps developers better understand the generated code framework, and can also guide developers on how to further develop and extend the code based on the scaffolding code, thereby improving development efficiency and code quality. The following is a detailed explanation of each prompt.

[0066] Optionally, after extracting the transaction model, base class path, and class name from the user's requirement text through the rule engine and combining them to obtain a structured parameter tuple, the process further includes: searching for example code that uses the transaction model and a specified base class, and determining typical historical service cases based on the example code; determining base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions based on the typical historical service cases and the business requirements input by the code development end; and generating business requirement prompt information based on the typical historical service cases, base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions.

[0067] In this embodiment, the rule engine not only extracts the transaction model, base class path, and class name to form structured parameter tuples, but also performs deep knowledge retrieval, searching for example code using the same transaction model and specified base class. Based on the retrieved example code, this embodiment can identify a set of typical historical service cases, covering best practices and solutions in past business scenarios. Subsequently, using these typical cases, a series of targeted rules can be extracted, including base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions. The formulation of these rules helps to build a more complete and specific generation framework, ensuring that the generated code not only conforms to the choice of transaction model and base class at the macro level, but also follows past best practices at the micro level, thereby improving the code's standardization and readability.

[0068] After defining the above rules, this embodiment continues to move forward. Based on typical historical service cases and business requirements input by the code development team, customized business requirement prompts are generated. These prompts include guidance on base class inheritance rules, transaction annotation rules, naming conventions, and coding standards. They not only inform the large language model how to construct the code structure and layout but also provide specific examples and patterns, thereby guiding the model-generated code to better align with business needs while adhering to industry development standards and specifications. By incorporating details from typical historical service cases into the business requirement prompts, this embodiment can generate more personalized code suggestions. For example, if a typical money transfer service case contains specific transaction annotations and exception handling logic, this information will be explicitly communicated to the large language model, allowing it to be replicated and optimized in the generation of new services. This helps to quickly establish a service framework that conforms to the business scenario while reducing the time developers spend exploring and making decisions on details.

[0069] Past cases can form a dynamic knowledge base for rule making. As more historical service cases are analyzed and organized, this embodiment can continuously adjust and optimize the generated rules to more accurately match the code specifications under different business needs. This means that the generated code in the future will be more in line with the latest industry standards and best practices, which will help improve the overall quality and stability of the code.

[0070] Optionally, after generating a service scaffold conforming to the constraint specifications through a large language model based on structured parameter tuples and business requirement prompts, the process further includes: performing a pre-defined syntax check on the service scaffold; if the syntax check passes, performing base class inheritance verification and transaction annotation verification on the service scaffold, wherein the base class inheritance verification includes: verifying the base class inheritance rules for a specified base class, and the transaction annotation verification includes: verifying the existence of annotations, verifying annotation parameters, and verifying the consistency of transaction boundaries; if both the base class inheritance verification and the transaction annotation verification pass, performing naming convention matching on the service scaffold using a regular expression validator to obtain the naming convention matching result; if the naming convention matching result meets the naming requirements, outputting the service scaffold.

[0071] In this embodiment, after generating the initial service scaffolding, a series of automatic checks and verification mechanisms are set up to ensure the quality and compliance of the code. First, a preset syntax check is performed to help detect and avoid syntax errors in the code early, ensuring that the code can be compiled and run at the most basic level. Specifically, through integrated development environment plugins or independent code analysis tools, the generated code can be automatically checked for syntax errors or non-compliant structures according to the syntax rules of the programming language. For example, it can check whether all methods have correct return type declarations, whether variable names conform to language conventions, or whether there are any unclosed code blocks.

[0072] For base class inheritance validation, it ensures that the generated service scaffolding correctly inherits the base class specified in the structured parameter tuple. By comparing the inheritance relationship in the code with the definition in the rule base, it can avoid functional deficiencies or compatibility issues caused by incorrect base class inheritance. Annotation existence validation includes checking whether the generated code contains necessary transaction processing annotations. These annotations are crucial in financial-grade development, used to mark the start, end, and rollback points of transactions, ensuring transaction integrity and data consistency. Annotation parameter validation verifies whether the annotation parameters are set correctly, such as transaction timeout and isolation level, which helps avoid transaction configuration errors and ensures that transactions execute normally under expected conditions. Transaction boundary consistency validation verifies that the scope of transactions in the code matches the boundary definition of the transaction model, preventing problems such as excessively wide or narrow transaction scopes that affect data processing efficiency and security.

[0073] If the syntax and transaction logic validations pass, this embodiment can use a regular expression validator to check the naming conventions of the service scaffolding and obtain the naming convention matching results. Following a unified naming convention helps improve the readability and maintainability of the code. Through this check, it can be ensured that the class names, method names, and variable names in the code conform to the established naming rules, such as using camelCase or underscore concatenation.

[0074] By automating the verification and generation process, this embodiment significantly reduces the manual verification burden on developers, allowing them to focus more on the development and innovation of business logic, which helps to quickly iterate products and services and improve the productivity of the entire development team.

[0075] Optionally, after outputting the service scaffold, the process further includes: recording the generated service scaffold by tracking the generated code lines and class names in the service scaffold; retrieving the same class names in the target knowledge base based on the recorded class names in the service scaffold, wherein the target knowledge base includes modified code fed back by the code development team and the actual code entered into the knowledge base; comparing the code indicated by the class names in the service scaffold with the code indicated by the same class names in the target knowledge base to determine a discrepancy list, wherein the discrepancy list includes at least: the actual number of code lines entered into the target knowledge base; comparing the generated code lines with the actual number of code lines entered into the target knowledge base to obtain the actual entry rate; evaluating the code generation quality parameters based on the actual entry rate, and adjusting the business requirement prompt information in conjunction with the code generation quality parameters.

[0076] In this embodiment, after the service scaffold is output, a feedback mechanism is introduced to quantitatively evaluate the quality of code generation and adjust business requirement prompts based on the evaluation results, thereby achieving continuous optimization and intelligent upgrades of the code generation process. Each generated service scaffold is recorded using event tracking. By integrating event tracking functionality into the code generation system, the number of lines of code and class names generated each time can be automatically recorded. This data is stored, which helps in collecting key information such as the number of lines of code and class names generated.

[0077] Based on the class names recorded in the service scaffolding, this embodiment can retrieve the same class names in the target knowledge base. The target knowledge base contains modified code fed back by the code development team and the actual code entered into the base. By comparing the code indicated by the class names in the service scaffolding with the code versions of the same class names in the target knowledge base, a discrepancy list is determined. The discrepancy list includes at least the number of lines of code actually entered into the target knowledge base, reflecting the extent of code modification and helping to evaluate the accuracy and usability of the generated code.

[0078] By comparing the number of lines of code generated with the number of lines of code actually entered into the target knowledge base, this embodiment can calculate the actual entry rate. The actual entry rate is a key indicator that reflects the degree of matching between the generated code and the final application code. Based on the actual entry rate, code generation quality parameters can be evaluated, including but not limited to the accuracy, applicability, and standardization of the generated code. This helps the system understand the limitations and areas for improvement in code generation, providing direction for subsequent code optimization.

[0079] Based on the evaluation results of code generation quality parameters, the system can intelligently adjust business requirement prompts, optimize the guidance and accuracy of code generation, and ensure that the code generation system can continuously learn and evolve, becoming increasingly aligned with the actual needs of code developers and industry standards. By analyzing the discrepancy list and actual inclusion rate, the system can identify common problems or frequently modified points in code generation under specific business scenarios or requirements, and adjust the business requirement prompts accordingly. This helps reduce future code modifications and improve the first-pass yield rate of code generation.

[0080] The feedback mechanism in this embodiment is not limited to single evaluations and adjustments, but rather forms a closed loop of continuous optimization through continuous data collection and analysis. Over time, the system's code generation capabilities are expected to significantly improve, more intelligently adapting to changing business needs and development standards. By reducing the number of code modifications and shortening the development cycle, the code generation system in this embodiment helps improve the efficiency and satisfaction of the development team, allowing them to focus more on innovation and the implementation of business logic, rather than writing and adjusting basic code.

[0081] In this embodiment, the process after determining the difference list further enhances the system's learning ability and self-optimization mechanism. Through in-depth analysis of code modification information fed back by the code development team, more accurate and applicable code generation rules are extracted. Optionally, after determining the difference list, the process also includes: obtaining code modification information fed back by the code development team through the difference list; determining the final example code based on the code modification information and storing the final example code as a typical service case in the target knowledge base; extracting the new transaction rules from the final example code and updating the rule base in the rule engine based on the new transaction rules.

[0082] The discrepancy list automatically extracts all modifications made to the service scaffolding by the development team during actual application. This information includes, but is not limited to, code structure adjustments, logic corrections, and performance optimizations, reflecting the actual usage of the code and the development team's modification preferences. Based on the collected code modification information, the system can determine the final example code that has been verified in real-world applications. Archiving this final example code in the target knowledge base as part of typical service cases not only enriches the knowledge base's content but also provides a practical and verified example for subsequent code generation, helping to improve the quality and accuracy of code generation.

[0083] From the final example code, the system can automatically identify and extract any newly added transaction rules. These rules may be optimizations for specific business scenarios or supplements to existing transaction models, reflecting the latest trends and needs in industry development. The extracted new transaction rules are integrated into the rule engine to update the internal rule base, enhancing the rule engine's decision-making capabilities and adaptability. This allows it to better match emerging development standards and complex business logic, further optimizing the code generation guidance strategy.

[0084] In this embodiment, the target knowledge base and rule engine can gradually master more industry-specific development standards and best practices through continuous learning and iteration. Each code generation is based on richer and more accurate intelligent decisions, which helps to improve the overall code quality and reduce manual intervention during the development phase.

[0085] By storing the optimized service scaffolding as a typical case, we not only provide a more practical reference for subsequent code generation, but also promote compliance with industry standards by the code development team, reduce code rework, thereby improving development efficiency and enhancing code standardization and maintainability.

[0086] The following describes in detail another optional implementation method.

[0087] To address the issues of low code compliance, high repetitive workload, and insufficient business logic flexibility in financial system development, this implementation method, in the distributed online service scaffolding generation scenario, achieves complementary advantages between the rule engine and the large model through a layered collaboration mechanism, forming a hybrid architecture of rule constraint framework + free creation of large model.

[0088] Figure 3 This is a schematic diagram of an optional distributed online service scaffolding generation method based on rule engine and large model collaboration according to an embodiment of the present invention, as shown below. Figure 3 As shown, the process includes: parsing user requirements, then using the rule engine layer to implement transaction model judgment, base class matching, and service naming processing; outputting structured parameters, then injecting base class templates, injecting naming conventions, and generating class implementation code through the large model layer, outputting complete scaffolding code, and finally achieving closed-loop optimization processing through feedback from the development end.

[0089] The distributed online service scaffolding generation method based on rule engine and large model collaboration provided in this invention can be applied to financial software development systems. These systems can include: development scenario plugins, rule bases, and knowledge bases. The development scenario plugins collect development scenarios (e.g., identifying @Service annotations as online services). The rule base stores transaction judgment rules and base class matching rules in JSON format. The knowledge base stores base class templates and historical best practices in a vector database.

[0090] The embodiments of the present invention will now be described in detail with reference to each collaborative level.

[0091] The first layer is the rules engine layer.

[0092] Core task: To transform financial-grade development specifications into machine-executable rules;

[0093] Input: The user's original request text;

[0094] Output: A structured parameter tuple (transaction model, base class path, class name);

[0095] Provide a code implementation example:

[0096] #Transaction type determination (rule engine example)

[0097] TRANSACTION_RULES = {

[0098] ("Positive and negative transactions", "Compensation"): "SAGA", # Keyword combination judgment

[0099] ("Resources Reserved", "Frozen"): "TCC",

[0100] ("Single Service",): "NON_TRANSACTION" # Default value rule

[0101] };

[0102] # Base class matching (JSON rule base query)

[0103] BASE_CLASS_DB = [

[0104] {"Hierarchy": "ATS", "Transaction Type": "SAGA", "Base Class": "AbstractSagaATSClass"},

[0105] {"Hierarchy": "ACS", "Transaction Type": "TCC", "Base Class": "TccAtomicServiceBase"} ]

[0107] def match_base_class(layer: str, trans_type: str) -> str:

[0108] return next(

[0109] (item["base class"] for item in BASE_CLASS_DB)

[0110] If item["layer"] == layer and item["trans_type"] == trans_type),

[0111] "DefaultServiceBase" # Default base class

[0112] ).

[0113] The second layer is the large language model layer.

[0114] Core task: To complete the code implementation within the constraints of the rules;

[0115] Input: Tuples output by the rules engine + details of user requirements;

[0116] Output: A Java class implementation that conforms to the specification.

[0117] Key design considerations for prompt word engineering:

[0118] ## Role

[0119] You are a senior development engineer for the xxx bank's business system and are required to strictly adhere to development standards when generating code.

[0120] ## Constraints (from the rule engine)

[0121] 1. Transaction Model : {transaction_type};

[0122] 2. base class : {base_class} ;

[0123] 3. Class Name : {class_name};

[0124] 4. Layered Specifications The ATS layer must not contain database operations.

[0125] ## Historical Best Practices (Knowledge Base Injection)

[0126] Java

[0127] / / Excellent money transfer service case

[0128] public class VaN_ATS_TransferProcessor extends AbstractSagaATSClass {

[0129] @Override

[0130] protected void execute() {

[0131] / / STEP1 Pre-check of Credit Accounts

[0132] checkDebitAccount();

[0133] / / STEP2 Call the core accounting service

[0134] invokeCoreBookingService();

[0135] }

[0136] }

[0137] Business requirements:

[0138] {user_query}

[0139] Generation requirements:

[0140] 1. Inheritance {base_class} Base class;

[0141] 2. The class name must be {class_name};

[0142] 3. Implement the execute() method according to the ATS layered specification.

[0143] Real-time collaboration case demonstration:

[0144] User input :

[0145] "To develop a credit card transfer service, it is necessary to support forward and reverse transactions, perform lender pre-checks, and register channel logs."

[0146] Rule engine output :

[0147] json

[0148] {

[0149] "transaction_type": "SAGA",

[0150] "base_class": "AbstractSagaATSClass",

[0151] "class_name": "VaN_ATS_CardTransferProcessor"

[0152] }

[0153] Large language model generation code:

[0154] / / pseudocode

[0155] / / Generated scaffolding code (compliant with all constraints)

[0156] public class VaN_ATS_CardTransferProcessor extendsAbstractSagaATSClass {

[0157] @Override

[0158] protected void execute() {

[0159] / / Pre-check of credit accounts (as required by the rules)

[0160] performDebitPreCheck();

[0161] / / Core transfer logic (generated freely from a large model)

[0162] processCardTransfer();

[0163] / / Channel log registration (requirement response)

[0164] recordChannelLog();

[0165] }

[0166] / / Custom method for automatic generation of large models

[0167] private void processCardTransfer() {

[0168] / / Intelligently generated business logic...

[0169] }

[0170] }

[0171] Figure 4 This is a schematic diagram of an optional hierarchical result verification according to an embodiment of the present invention, such as... Figure 4 As shown, after generating the scaffolding code, an ATS (Advanced Transaction Services) syntax check can be performed, followed by base class inheritance verification, transaction annotation verification, and naming convention matching. If all checks pass, the final scaffolding development code is output.

[0172] Figure 5 This is a schematic diagram illustrating an optional method for automatically adjusting the knowledge base based on code modifications on the development side, according to an embodiment of the present invention. Figure 5 As shown, after receiving the modified scaffolding development code from the development team, the newly added transaction rules in the modified code can be extracted to update the rule engine's rule base. At the same time, the code pattern to be optimized can be determined by modifying the code, and the optimized code pattern can be added to the historical best practice library / historical service typical code case in the knowledge base.

[0173] Through the above implementation methods, the combined effect of the rule engine and the large model can generate code that better conforms to the development standards of the financial industry, effectively improving code compliance rates, reducing subsequent code remediation work, and helping to ensure the security and stability of financial services. At the same time, the service scaffolding code generation method in this embodiment can significantly shorten code writing time from the traditional 15 minutes / service to 2 minutes / service, helping to quickly respond to market changes and business needs, and accelerating product iteration and launch.

[0174] The large model in this embodiment can generate complex business logic under rule constraints without sacrificing code structure standardization and transaction consistency. This helps adapt to changing financial business scenarios and supports business innovation and customization needs. By quantitatively evaluating the actual data entry rate, this embodiment can adjust business requirement prompts and optimize code generation quality parameters, thereby continuously improving the accuracy and applicability of code generation and contributing to the construction of high-quality, low-maintenance software systems.

[0175] This embodiment employs a rule-based pre-filtering and layered result verification mechanism to ensure code consistency in transaction models, base class matching, naming conventions, and other aspects, helping to reduce financial risks caused by code errors. By reducing the number of code modifications and shortening the development cycle, the development team can focus more on optimizing business logic rather than writing basic code, which helps improve the overall development process's satisfaction and efficiency.

[0176] The following is a detailed description with reference to another embodiment.

[0177] Example 2

[0178] The service scaffolding generation device based on a rule engine provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in the above embodiment 1. The specific implementation method and beneficial effects can be referred to the aforementioned method embodiment, and will not be repeated here.

[0179] Figure 6 This is a schematic diagram of an optional service scaffolding generation device based on a rule engine according to an embodiment of the present invention, such as... Figure 6 As shown, the service scaffolding generation device based on the rule engine may include: a rule engine extraction unit 61 and a service scaffolding generation unit 62.

[0180] The rule engine extraction unit 61 is used to extract the transaction model, base class path and class name from the user requirement text after receiving the user requirement text, and combine them to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project.

[0181] The service scaffolding generation unit 62 is used to generate service scaffolding that conforms to the constraint specifications through a large language model based on structured parameter tuples and business requirement prompts. The constraint specifications are generated based on pre-built base class templates and pre-stored historical service typical cases in the target knowledge base.

[0182] The aforementioned service scaffolding generation device based on a rule engine can extract the transaction model, base class path, and class name from the user's requirement text via the rule engine extraction unit 61 after receiving the text. These are then combined to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet data consistency requirements in a distributed system, and the base class path includes the location of a specified base class defined in the project. The service scaffolding generation unit 62 then generates a service scaffolding conforming to constraint specifications based on the structured parameter tuple and business requirement prompts using a large language model. The constraint specifications are generated based on a pre-built base class template and pre-stored historical service case examples in the target knowledge base. In this embodiment, the rule engine and large language model can work together to achieve automated service scaffolding generation. Automated transaction processing code generation saves the tedious process of manually coding transaction logic on the development side, greatly improving development efficiency, shortening scaffolding generation time, and reducing the development cycle. This solves the technical problem of low development efficiency in financial system software development where transaction processing relies on direct coding by the development side.

[0183] Optionally, the rule engine extraction unit includes: a rule engine extraction module, used to extract keyword combinations and default value rules related to the transaction model in the user requirement text through the rule engine, and determine the transaction model based on the keyword combinations and default value rules; a base class matching module, used to obtain the specified base class through the rule engine based on the base class path matching in the user requirement text; and a combination module, used to combine the transaction model, the specified base class, and the class name to obtain a structured parameter tuple.

[0184] Optionally, the service scaffolding generation device based on the rule engine further includes: a sample code search unit, used to search for sample code using the transaction model and a specified base class after extracting the transaction model, base class path and class name from the user requirement text through the rule engine and combining them to obtain a structured parameter tuple, and to determine typical historical service cases based on the sample code; a rule determination unit, used to determine base class inheritance rules, transaction annotation rules, naming conventions and coding conventions based on typical historical service cases and business requirements input by the code development end; and a requirement prompt generation unit, used to generate business requirement prompt information based on typical historical service cases, base class inheritance rules, transaction annotation rules, naming conventions and coding conventions.

[0185] Optionally, the service scaffolding generation device based on the rule engine further includes: a syntax checking unit, used to perform a preset syntax check on the service scaffolding after generating a service scaffolding conforming to the constraint specification through a large language model based on structured parameter tuples and business requirement prompts; a verification unit, used to perform base class inheritance verification and transaction annotation verification on the service scaffolding if the syntax check passes, wherein the base class inheritance verification includes: base class inheritance rule verification on a specified base class, and the transaction annotation verification includes: annotation existence verification, annotation parameter verification, and transaction boundary consistency verification; a naming convention matching unit, used to perform naming convention matching on the service scaffolding through a regular expression validator if both the base class inheritance verification and the transaction annotation verification pass, to obtain the naming convention matching result; and a scaffolding code output unit, used to output the service scaffolding if the naming convention matching result meets the naming requirements.

[0186] Optionally, the service scaffolding generation device based on the rule engine further includes: a code tracking unit, used to track and record code points for each generated service scaffolding after outputting the service scaffolding, obtaining the number of generated code lines and the class names in the service scaffolding; a class name retrieval unit, used to retrieve the same class names in the target knowledge base based on the recorded class names in the service scaffolding, wherein the target knowledge base includes modified code fed back by the code development end and the actual code entered into the knowledge base; a code difference determination unit, used to compare the code indicated by the class names in the service scaffolding with the code indicated by the same class names in the target knowledge base, and determine a difference list, wherein the difference list includes at least: the number of code lines actually entered into the target knowledge base; a code entry rate determination unit, used to compare the number of generated code lines with the number of code lines actually entered into the target knowledge base, and obtain the actual entry rate; and a prompt information adjustment unit, used to evaluate the code generation quality parameters based on the actual entry rate, and adjust the business requirement prompt information in combination with the code generation quality parameters.

[0187] Optionally, the service scaffolding generation device based on the rule engine further includes: a code modification information acquisition unit, used to acquire code modification information fed back by the code development end through the difference list after determining the difference list; a final example code determination unit, used to determine the final example code based on the code modification information and store the final example code as a typical service case in the target knowledge base; and a new transaction rule extraction unit, used to extract the new transaction rules in the final example code and update the rule base in the rule engine based on the new transaction rules.

[0188] Optionally, the rule base in the rule engine stores: base class matching rules and transaction judgment rules; the target knowledge base pre-stores multiple base class templates and historical service typical cases corresponding to multiple sample codes.

[0189] The aforementioned service scaffolding generation device based on a rule engine may also include a processor and a memory. The rule engine extraction unit 61, the service scaffolding generation unit 62, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0190] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, a distributed online service scaffolding generation can be achieved collaboratively based on a rule engine and a large language model.

[0191] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0192] Example 3

[0193] Embodiments of this application may provide an electronic device. Figure 7 This is a structural block diagram of an electronic device for executing a rule engine-based service scaffolding generation method according to an embodiment of this application. Figure 7 As shown, the electronic device may include: one or more ( Figure 7 (Only one is shown) processor 702, memory 704, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0194] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the rule engine-based service scaffolding generation method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned rule engine-based service scaffolding generation method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0195] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: After receiving the user requirement text, the processor extracts the transaction model, base class path, and class name from the user requirement text through a rule engine and combines them to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project. Based on the structured parameter tuple and business requirement prompts, the processor generates a service scaffold that conforms to the constraint specification through a large language model. The constraint specification is generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base.

[0196] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.

[0197] Those skilled in the art will understand that all or part of the steps in the various rule engine-based service scaffolding generation methods of the above embodiments can be implemented by a program instructing the hardware of the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0198] Example 4

[0199] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the rule engine-based service scaffolding generation method provided in Embodiment 1.

[0200] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute any one of the rule engine-based service scaffolding generation methods in Embodiment 1 above.

[0201] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0202] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the service scaffolding generation method based on a rule engine as described in various embodiments of this application.

[0203] This application also provides a computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the service scaffolding generation method based on a rule engine described in various embodiments of this application.

[0204] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0206] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0207] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0208] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0209] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0210] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A rule engine based service scaffolding generation method, characterized in that, include: After receiving the user's requirement text, the transaction model, base class path and class name are extracted from the user's requirement text through the rule engine and combined to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project. Based on the structured parameter tuples and business requirement prompts, a service scaffold conforming to the constraint specifications is generated through a large language model. The constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base.

2. The service scaffolding generation method according to claim 1, characterized in that, The steps of extracting the transaction model, base class path, and class name from the user requirement text using a rule engine and combining them to obtain a structured parameter tuple include: The rule engine extracts the keyword combinations and default value rules of the associated transaction model in the user requirement text, and determines the transaction model based on the keyword combinations and default value rules. The specified base class is obtained by matching the base class path in the user's request text using the rule engine; The structured parameter tuple is obtained by combining the object model, the specified base class, and the class name.

3. The service scaffolding generation method according to claim 2, characterized in that, After extracting the transaction model, base class path, and class name from the user requirement text using the rule engine and combining them to obtain a structured parameter tuple, the following is also included: Search for example code that uses the transaction model and the specified base class, and determine typical cases of historical services based on the example code; Based on the typical historical service cases and the business requirements input by the code development end, the base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions are determined. Based on the aforementioned historical service typical cases, base class inheritance rules, transaction annotation rules, naming conventions, and coding conventions, the aforementioned business requirement prompt information is generated.

4. The service scaffolding generation method according to claim 3, characterized in that, After generating a service scaffold conforming to the constraint specifications using a large language model based on the structured parameter tuples and business requirement hints, the process further includes: Perform a preset syntax check on the service scaffolding; If the syntax check passes, the service scaffold is subjected to base class inheritance verification and transaction annotation verification. The base class inheritance verification includes: base class inheritance rule verification for a specified base class. The transaction annotation verification includes: annotation existence verification, annotation parameter verification, and transaction boundary consistency verification. If both the base class inheritance validation and the transaction annotation validation pass, the service scaffold is matched for naming conventions using a regular expression validator to obtain the naming convention matching result. If the naming convention matching result meets the naming requirements, the service scaffolding is output.

5. The service scaffolding generation method according to claim 4, characterized in that, After outputting the service scaffolding, the following is also included: Each time the service scaffold is generated, a data entry point is recorded to obtain the number of lines of code generated and the class name in the service scaffold. Based on the class names recorded in the service scaffolding, retrieve the same class names in the target knowledge base, wherein the target knowledge base includes modified code fed back by the code development end and the actual code entered into the database; By comparing the code indicating the class name in the service scaffold with the code indicating the same class name in the target knowledge base, a discrepancy list is determined, wherein the discrepancy list includes at least: the number of lines of code actually entered into the target knowledge base; By comparing the number of generated lines of code with the actual number of lines of code that enter the target knowledge base, the actual entry rate is obtained. The code generation quality parameters are evaluated based on the actual inbound rate, and the business requirement prompt information is adjusted in conjunction with the code generation quality parameters.

6. The service scaffolding generation method according to claim 5, characterized in that, After determining the list of differences, the following is also included: Obtain code modification information from the code development team through the difference list; Based on the code modification information, the final example code is determined and stored in the target knowledge base as a typical service case. Extract the new transaction rules from the final example code, and update the rule base in the rule engine based on the new transaction rules.

7. The service scaffolding generation method according to any one of claims 1 to 6, characterized in that, The rule base in the rule engine stores: base class matching rules and transaction judgment rules; the target knowledge base pre-stores multiple base class templates and multiple sample code corresponding to historical service typical cases.

8. A service scaffolding generation device based on a rule engine, characterized in that, include: The rule engine extraction unit is used to extract the transaction model, base class path and class name from the user requirement text after receiving the user requirement text, and combine them to obtain a structured parameter tuple. The transaction model includes a set of strategies that meet the data consistency requirements in the distributed system, and the base class path includes the location of the specified base class defined in the project. The service scaffolding generation unit is used to generate a service scaffolding that conforms to the constraint specifications through a large language model based on the structured parameter tuples and business requirement prompts. The constraint specifications are generated based on a pre-built base class template and pre-stored historical service typical cases in the target knowledge base.

9. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the service scaffolding generation method based on any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the service scaffolding generation method based on any one of claims 1 to 7.

Images