Low-code platform script generation method and system based on LLM+RAG

Abstract

The application provides an LLM+RAG-based low-code platform script generation method and system, relates to the technical field of script generation, and comprises the following steps: constructing a semantic graph by analyzing user requirements, retrieving and screening a component combination that can be connected in series, generating an original script by using a large language model, and finally generating an executable script and deploying and running the executable script through control flow analysis and variable initialization. The application realizes the automatic generation of an executable script from a natural language requirement, and improves the development efficiency and code reliability.

Description

Technical Field

[0001] This invention relates to the field of script generation technology, and in particular to a low-code platform script generation method and system based on LLM+RAG. Background Technology

[0002] In the field of low-code development, automating the generation of script code to meet specific business needs is a key direction for improving development efficiency. One common approach in existing technologies is to combine template-based code generation with a rule engine. This method typically relies on a predefined code template library, which corresponds to specific, pre-defined business scenarios or functional modules. When a user inputs a requirement description, the system maps the requirement to the closest template using keyword matching or simple natural language processing techniques. Subsequently, the rule engine, based on a limited set of parameters extracted from the requirement description, performs variable population and simple logical combinations on the selected template to generate the final script code. Another common approach is to utilize traditional retrieval-enhanced generation techniques, which involves retrieving code snippets from a historical codebase that are textually similar to the current requirement description, and then assembling them into a new script through splicing or limited adjustments.

[0003] The aforementioned conventional practices have significant limitations. Template-based methods heavily rely on the completeness and forward-looking design of template libraries, making it difficult to flexibly handle complex, ever-changing, or undefined business logic. When user requirements exceed the template's coverage, the system either cannot process them or generates low-quality code requiring extensive manual modification. Its fundamental flaw lies in the lack of understanding and reasoning ability regarding the deep semantics of requirements, merely performing superficial pattern matching. While traditional search enhancement methods can utilize existing code, their search process is usually based on keywords or shallow syntactic similarity, making it difficult to accurately grasp the semantic core of the requirements, resulting in discrepancies between the retrieved code snippets and the true intent. The assembled scripts are often loosely structured, lacking guaranteed interface compatibility and data flow consistency between components, making them prone to runtime errors. Furthermore, the generated code may contain fundamental defects such as uninitialized variables, requiring developers to invest additional effort in debugging and correction. Summary of the Invention

[0004] This invention provides a low-code platform script generation method and system based on LLM+RAG, which can solve the problems in the prior art.

[0005] A first aspect of this invention provides a low-code platform script generation method based on LLM+RAG, comprising:

[0006] Obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, relationships between entities and business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities.

[0007] Each node in the demand semantic graph is converted into a query vector. Nearest neighbor retrieval is performed in the component vector library of the low-code platform to obtain candidate components whose semantic distance to each node is less than the similarity threshold. Data patterns of the input and output interfaces of each candidate component are extracted. Interface compatibility verification is performed based on the edge relationships in the demand semantic graph to filter out component combination paths that can be chained together.

[0008] The requirement semantic graph, the component combination path, and the calling constraint rules of each component are encoded into a structured context, which is then input into a large language model to generate original script code containing component instantiation and parameter binding logic.

[0009] Control flow analysis is performed on the original script code to identify conditional branch statements and loop statements. The execution condition expressions of each branch are extracted, and it is checked whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate complete executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a triggered event.

[0010] Semantic analysis is performed on the script requirement description to extract business entities, relationships between entities, and business constraints, and a requirement semantic graph is constructed, including:

[0011] The script requirement description is segmented and part-of-speech tagging is performed to identify noun phrases as candidate business entities. For each candidate business entity, its context in the script requirement description is extracted, and the role type of each candidate business entity in the business process is identified through semantic role tagging.

[0012] Based on dependency parsing, verb phrases and prepositional phrases in the script requirement description are identified, and semantic association patterns representing the relationships between entities are extracted. The semantic association patterns include the direction of data flow and the direction of control dependency.

[0013] Based on the conditional clauses and constraint descriptions in the script requirements description, extract the business rule expressions and formalize the business rule expressions into logical constraint conditions.

[0014] Each candidate business entity is mapped to a node in the demand semantic graph, and the semantic association pattern is mapped to a directed edge in the demand semantic graph. Data transmission type and execution timing constraints are labeled on each directed edge, and the logical constraints are attached to the corresponding node or edge as attribute labels to complete the construction of the demand semantic graph.

[0015] Each node in the demand semantic graph is converted into a query vector. Nearest neighbor retrieval is performed in the component vector library of the low-code platform to obtain candidate components whose semantic distance to each node is less than a similarity threshold. Data patterns of the input and output interfaces of each candidate component are extracted. Interface compatibility is verified based on the edge relationships in the demand semantic graph, and component combination paths with connectable interfaces are selected, including:

[0016] Extract the business entity name and role type label of each node in the demand semantic graph, concatenate the business entity name and role type label into a text description, input the text description corresponding to each node into a pre-trained semantic encoder for vectorization encoding, and generate a fixed-dimensional node semantic vector representation.

[0017] In the component vector library, an approximate nearest neighbor search is performed on the semantic vector representation of each node using a vector index structure to retrieve candidate components whose cosine similarity to the semantic vector representation of each node is greater than the similarity threshold.

[0018] For each candidate component, its interface definition document is extracted from the component meta-database of the low-code platform. The interface definition document is parsed to obtain the input parameter list and output parameter list. The data type, data structure and value constraints of each parameter are extracted to construct the data pattern description of the candidate component.

[0019] Traverse each directed edge in the requirement semantic graph, obtain the starting node and the ending node of the edge, and determine whether there is a parameter pair in the output parameter list of the candidate component corresponding to the starting node that matches the data type in the input parameter list of the candidate component corresponding to the ending node. When a matching parameter pair exists, mark the directed edge as a connectable edge.

[0020] Based on the topology of the required semantic graph, all paths from the input node to the output node are searched, and paths where all edges are connectable are selected as the component combination paths that can be connected to the interface.

[0021] Traverse all directed edges in the requirement semantic graph, obtain the start node and end node of the edge, and determine whether there is a parameter pair in the output parameter list of the candidate component corresponding to the start node that matches the data type in the input parameter list of the candidate component corresponding to the end node. When a matching parameter pair exists, mark the directed edge as a connectable edge, including:

[0022] For each directed edge, obtain the output parameter list of the candidate component corresponding to its starting node and the input parameter list of the candidate component corresponding to its ending node. Iterate through each output parameter in the output parameter list and each input parameter in the input parameter list to extract the basic data type identifier of each parameter.

[0023] When the basic data type identifiers of the output parameter and the input parameter are the same, the data structure characteristics of the two are further compared. The data structure characteristics include array dimension, object attribute key set and nesting level depth. When the data structure characteristics meet the compatibility conditions, it is checked whether the value range of the output parameter is a subset of the value constraints of the input parameter.

[0024] When the range of values ​​satisfies the inclusion relationship, the output parameter and the input parameter are determined as a matching parameter pair, and the parameter name mapping relationship of the matching parameter pair is recorded;

[0025] Count the number of all matching parameter pairs corresponding to the directed edge. When the number of matching parameter pairs is greater than the preset minimum matching number threshold, mark the directed edge as a connectable edge and store the parameter name mapping relationship as the connection attribute of the edge.

[0026] The requirement semantic graph, the component composition path, and the calling constraint rules of each component are encoded into a structured context, input into a large language model to generate raw script code containing component instantiation and parameter binding logic, including:

[0027] The requirement semantic graph is serialized into text in graph description language format, and the text contains the identifier of each node, the name of the business entity, and the start and end node identifiers and relationship types of each edge.

[0028] Traverse each component in the component combination path, extract the component name, version identifier and interface signature information of each component, and arrange them according to the execution order in the component combination path to generate a component call sequence description;

[0029] The call constraint rules for each component are queried from the rule base of the low-code platform. The call constraint rules include precondition judgment expressions and resource usage declarations. The call constraint rules are associated with the corresponding components to form annotation information.

[0030] Construct a structured data object containing task description fields, graph structure fields, component sequence fields, and constraint rule fields, and fill the corresponding fields with the text in the graph description language format, the component call sequence description, and the annotation information;

[0031] The structured data object is converted into prompt text in natural language template format, and the syntax specification and code generation instructions of the low-code platform are inserted into the prompt text;

[0032] The prompt text is input into the inference interface of the large language model, and the original script code output by the large language model, which includes component instantiation statements, variable declaration statements and parameter assignment statements, is received.

[0033] Control flow analysis is performed on the original script code to identify conditional branch statements and loop statements. The execution condition expressions for each branch are extracted, and it is checked whether the variables referenced in these expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the variable's data type and business semantics and inserted before the first reference point. This includes:

[0034] The original script code is parsed using an abstract syntax tree to identify conditional decision nodes and loop structure nodes in the abstract syntax tree. For each conditional decision node, the Boolean expression in its child nodes is extracted as the execution condition expression, and the variable reference identifier in the Boolean expression is extracted. For each loop structure node, the loop condition expression and the variable reference identifier in the loop body are extracted.

[0035] Construct a control flow graph of the original script code, where nodes represent basic code blocks and edges represent execution flow directions. Perform data flow analysis on the control flow graph to track the definition and usage status of each variable reference identifier in each basic code block, and mark the defined and undefined sets of each variable at the entry point of each basic code block.

[0036] Traverse the basic code block containing the execution condition expression and check whether the variable reference identifier in the execution condition expression belongs to the undefined set at the entry point of the basic code block;

[0037] When a variable reference identifier is detected to belong to the undefined set, the semantic type of the business entity corresponding to the variable is queried from the requirement semantic graph, and the data type of the variable is determined according to the semantic type.

[0038] Generate a corresponding initialization assignment statement based on the data type, and assign the variable the default safe value of the data type.

[0039] Locate the statement node in the abstract syntax tree where the variable is first referenced, insert the initialization assignment statement before that statement node, update the abstract syntax tree, and generate the complete executable script code.

[0040] A second aspect of this invention provides a low-code platform script generation system based on LLM+RAG, comprising:

[0041] The requirement analysis unit is used to obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, the relationships between entities and the business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities.

[0042] The component matching unit is used to convert each node in the demand semantic graph into a query vector, perform nearest neighbor retrieval in the component vector library of the low-code platform, obtain candidate components whose semantic distance to each node is less than the similarity threshold, extract the data pattern of the input and output interfaces of each candidate component, perform interface compatibility verification based on the edge relationship in the demand semantic graph, and filter out component combination paths whose interfaces can be chained.

[0043] The script generation unit is used to encode the requirement semantic graph, the component combination path and the calling constraint rules of each component into a structured context, input it into the large language model to generate the original script code containing component instantiation and parameter binding logic;

[0044] The code improvement unit is used to perform control flow analysis on the original script code, identify conditional branch statements and loop statements, extract the execution condition expressions of each branch, and detect whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate improved executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a trigger event.

[0045] A third aspect of the present invention provides an electronic device, comprising:

[0046] processor;

[0047] Memory used to store processor-executable instructions;

[0048] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0049] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0050] This method leverages a large language model to generate raw script code, efficiently transforming structured requirement semantic graphs, component paths, and constraint rules into a code framework containing concrete instantiation and parameter binding logic. This process deeply integrates domain knowledge (component constraints) with LLM's code generation capabilities, ensuring that the generated code skeleton is not only syntactically correct but also closely conforms to the specific component calling paradigms of low-code platforms, significantly improving the usability and accuracy of the initial code.

[0051] By performing control flow analysis and variable initialization detection on the original script code, this method can intelligently identify and repair uninitialized variable defects caused by conditional branches or loops. It automatically inserts initialization statements that conform to the data type and business semantics of a variable before its first reference, fundamentally eliminating runtime errors caused by undefined variables. This ensures the robustness and execution reliability of the generated script, achieving a leap from "can be generated" to "can run stably."

[0052] Ultimately, the refined executable script can be directly deployed to the low-code platform runtime environment, achieving end-to-end automated delivery from requirement description to runnable service. This entire process significantly improves script development efficiency, shortens the business requirement response cycle, and ensures the quality of generated code and platform compatibility, enabling even non-professional developers to quickly build complex automated business logic. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating the script generation method for a low-code platform based on LLM+RAG. Detailed Implementation

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

[0055] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0056] Figure 1 This is a flowchart illustrating the script generation method for a low-code platform based on LLM+RAG, as shown below. Figure 1 As shown, the method includes:

[0057] Obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, relationships between entities and business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities.

[0058] Each node in the demand semantic graph is converted into a query vector. Nearest neighbor retrieval is performed in the component vector library of the low-code platform to obtain candidate components whose semantic distance to each node is less than the similarity threshold. Data patterns of the input and output interfaces of each candidate component are extracted. Interface compatibility verification is performed based on the edge relationships in the demand semantic graph to filter out component combination paths that can be chained together.

[0059] The requirement semantic graph, the component combination path, and the calling constraint rules of each component are encoded into a structured context, which is then input into a large language model to generate original script code containing component instantiation and parameter binding logic.

[0060] Control flow analysis is performed on the original script code to identify conditional branch statements and loop statements. The execution condition expressions of each branch are extracted, and it is checked whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate complete executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a triggered event.

[0061] In one optional implementation, semantic analysis is performed on the script requirement description to extract business entities, inter-entity relationships, and business constraints, and a requirement semantic graph is constructed, including:

[0062] The script requirement description is segmented and part-of-speech tagging is performed to identify noun phrases as candidate business entities. For each candidate business entity, its context in the script requirement description is extracted, and the role type of each candidate business entity in the business process is identified through semantic role tagging.

[0063] Based on dependency parsing, verb phrases and prepositional phrases in the script requirement description are identified, and semantic association patterns representing the relationships between entities are extracted. The semantic association patterns include the direction of data flow and the direction of control dependency.

[0064] Based on the conditional clauses and constraint descriptions in the script requirements description, extract the business rule expressions and formalize the business rule expressions into logical constraint conditions.

[0065] Each candidate business entity is mapped to a node in the demand semantic graph, and the semantic association pattern is mapped to a directed edge in the demand semantic graph. Data transmission type and execution timing constraints are labeled on each directed edge, and the logical constraints are attached to the corresponding node or edge as attribute labels to complete the construction of the demand semantic graph.

[0066] In the semantic analysis of the script requirement description, the input text is first segmented using a natural language processing toolchain. The segmentation process employs a hybrid strategy combining dictionary-based and statistical models to divide the continuous text into word units. For each segmented word unit, part-of-speech tagging is performed, assigning a grammatical type label to each word using a Hidden Markov Model or Conditional Random Field Model. From the tagging results, text fragments with part-of-speech tags of nouns or noun phrases are selected as candidate business entities. For example, when the script requirement description is "read customer information from the order table and update inventory quantity," the extracted candidate business entities include "order table," "customer information," and "inventory quantity."

[0067] For each candidate business entity, a window of five words before and after it in the original text is extracted as the context. Semantic role labeling (SLA) is used to analyze this context and identify the semantic role the entity plays in the action structure. SLA is based on a predefined set of role types, including agent, patient, tool, source, and target. By analyzing the argument relationships between verbs and entities, the role type of each candidate business entity in the business process is determined. For example, "order table" acts as the source role in the context for data retrieval operations, while "inventory quantity" acts as the target role for data update operations.

[0068] Based on dependency parsing technology, a syntactic dependency tree for script requirements description is constructed. This dependency tree uses words as nodes and syntactic dependency relationships between words as directed edges. Verb phrase nodes and prepositional phrase nodes are located within the dependency tree; these phrases typically connect multiple business entities, representing the relationships between them. By analyzing the semantic categories of verbs, the type of relationship is identified; for example, the verb "read" represents a data flow relationship, and the verb "trigger" represents a control dependency relationship. For data flow relationships, the transitivity of the verb determines the direction of data flow, from the subject entity to the object entity. For control dependencies, the execution order is determined based on temporal logical lexicalities; for example, in "send a notification after payment is completed," there is a sequential dependency between the "payment" node and the "notification" node.

[0069] Pattern matching technology is used to identify conditional clauses in the script requirements description, matching conditional conjunctions such as "if," "when," and "satisfy," and extracting the subsequent constraint expressions. For numerical constraints, comparison operators and threshold parameters are parsed and converted into inequality forms. For enumerated constraints, the set of allowed values ​​is extracted. For compound constraints, logical connectives "AND," "OR," and "NOT" are identified, and a Boolean expression tree is constructed. These formalized logical constraints are used for subsequent component selection and parameter validation.

[0070] In the construction phase of the requirement semantic graph, a graph node is created for each candidate business entity, carrying the entity name and role type attributes. Based on the extracted semantic association patterns, directed edges are created between related nodes. The direction of the edges follows the data flow direction or control dependency direction. Attribute labels are attached to each directed edge, including data transfer type labels and execution timing constraint labels. The data transfer type label identifies the type of data structure being transferred, such as object references, numeric arrays, or strings. The execution timing constraint label identifies the order of operations, such as synchronous execution or asynchronous callbacks. Extracted logical constraints are attached to the corresponding nodes or edges as constraint attributes, based on their applicable scope. Node constraints limit the value range of the entity, while edge constraints limit the triggering conditions of the relationship. After completing the above mapping operations, a complete requirement semantic graph structure is formed, which includes both static entity and relationship topology and dynamic constraints and timing information.

[0071] In one optional implementation, each node in the demand semantic graph is converted into a query vector. Nearest neighbor retrieval is performed in the component vector library of a low-code platform to obtain candidate components whose semantic distance to each node is less than a similarity threshold. Data patterns of the input and output interfaces of each candidate component are extracted. Interface compatibility verification is performed based on the edge relationships in the demand semantic graph, and component combination paths with chainable interfaces are selected, including:

[0072] Extract the business entity name and role type label of each node in the demand semantic graph, concatenate the business entity name and role type label into a text description, input the text description corresponding to each node into a pre-trained semantic encoder for vectorization encoding, and generate a fixed-dimensional node semantic vector representation.

[0073] In the component vector library, an approximate nearest neighbor search is performed on the semantic vector representation of each node using a vector index structure to retrieve candidate components whose cosine similarity to the semantic vector representation of each node is greater than the similarity threshold.

[0074] For each candidate component, its interface definition document is extracted from the component meta-database of the low-code platform. The interface definition document is parsed to obtain the input parameter list and output parameter list. The data type, data structure and value constraints of each parameter are extracted to construct the data pattern description of the candidate component.

[0075] Traverse each directed edge in the requirement semantic graph, obtain the starting node and the ending node of the edge, and determine whether there is a parameter pair in the output parameter list of the candidate component corresponding to the starting node that matches the data type in the input parameter list of the candidate component corresponding to the ending node. When a matching parameter pair exists, mark the directed edge as a connectable edge.

[0076] Based on the topology of the required semantic graph, all paths from the input node to the output node are searched, and paths where all edges are connectable are selected as the component combination paths that can be connected to the interface.

[0077] After obtaining the demand semantic graph, vectorization is performed on each node to achieve semantic retrieval. Specifically, the business entity name field is extracted from the node attributes of the demand semantic graph. This field records the entity keywords described by the user, such as "order," "customer," and "payment." Simultaneously, the role type label attribute of the node is read. This label identifies the node's functional positioning in the business process, such as "data source," "processor," and "verifier." The extracted business entity name and role type label are concatenated into a string in the format "[entity name]-[role type]" to form a complete node text description. The concatenated text description is input into a pre-trained BERT or Sentence-BERT semantic encoder. This encoder, trained on a large-scale corpus, can map text into a 768-dimensional or 1024-dimensional dense vector. The encoder performs word segmentation, positional encoding, and multi-layer Transformer processing on the input text. The output CLS tag corresponding to the hidden state serves as the semantic vector representation of the node, capturing the node's business semantic features.

[0078] When performing searches in the component vector library, vector index libraries such as FAISS or Annoy are used to achieve fast similarity calculation. The component vector library pre-stores vector representations of all available components on the low-code platform. Each component vector is generated by performing the same semantic encoder processing on its functional description document. For each node semantic vector, the search interface of the index library is called to calculate its cosine similarity with all component vectors in the library. The cosine similarity calculation formula is the dot product of the two vectors divided by the product of their respective magnitudes. A similarity threshold of 0.75 is set. When the cosine similarity between a component vector and a node vector exceeds this threshold, the component is added to the candidate set. Through the pruning strategy of the vector index, highly similar components can be found by calculating only a small number of vectors, and the retrieval efficiency is far superior to a full traversal.

[0079] After obtaining the candidate component set, their interface data patterns need to be extracted for compatibility verification. Access the low-code platform's component metadata database, which stores the interface definition documents of each component in JSON or XML format. Parse the "inputs" field of the document to obtain the input parameter list, and parse the "outputs" field to obtain the output parameter list. For each parameter entry in the parameter list, extract its "name" attribute as the parameter name, the "type" attribute to identify the data type (e.g., String, Integer, Object), the "structure" attribute to describe the internal structure of complex types (e.g., object field definitions or array element types), and the "constraints" attribute to record the value range or format requirements (e.g., minimum and maximum values ​​for numbers or regular expression patterns for strings). Organize this information into a structured data pattern description object to provide a basis for subsequent compatibility judgment.

[0080] Interface compatibility verification is based on the edge relationships in the requirement semantic graph. Each directed edge in the graph, connecting the start and end nodes, indicates that the output of the start node needs to be passed to the end node as input. The output parameter list of the candidate component corresponding to the start node and the input parameter list of the candidate component corresponding to the end node are obtained. Each output parameter of the start component is checked to determine if its data type is consistent with or compatible with the data type of a certain input parameter of the end component. Data type compatibility rules include exact matching of basic types (e.g., Integer vs. Integer) and type promotion rules (e.g., Integer can be converted to Long or Double). For complex types, the field structures of the objects are recursively compared for consistency. When at least one output-input parameter pair with matching types is found, the "connectable" flag is added to the edge's attributes, and the matching parameter pair information is recorded; otherwise, it is marked as an unconnectable edge.

[0081] After completing the compatibility marking of all edges, the path search algorithm is executed. The requirement semantic graph is treated as a directed graph, and nodes with the role type "input source" are identified as the starting point set, and nodes with the role type "output target" are identified as the ending point set. A depth-first search or breadth-first search is used to traverse all possible paths from each starting point to each ending point. During the traversal, expansion is only performed along edges marked as connectable; if an unconnectable edge is encountered, backtracking or pruning is performed. All complete paths that meet the conditions are recorded, and each path is represented as a sequence of nodes and a corresponding sequence of components. These paths are the component combination paths where interfaces can be chained, ensuring that the interfaces of adjacent components on the path can be correctly connected and data can flow smoothly, providing a feasible component orchestration scheme for subsequent script code generation.

[0082] In one optional implementation, the directed edges in the requirement semantic graph are traversed to obtain the starting and ending nodes of the edges. It is then determined whether there exists a parameter pair in the output parameter list of the candidate component corresponding to the starting node that matches the data type in the input parameter list of the candidate component corresponding to the ending node. When a matching parameter pair exists, the directed edge is marked as a connectable edge, including:

[0083] For each directed edge, obtain the output parameter list of the candidate component corresponding to its starting node and the input parameter list of the candidate component corresponding to its ending node. Iterate through each output parameter in the output parameter list and each input parameter in the input parameter list to extract the basic data type identifier of each parameter.

[0084] When the basic data type identifiers of the output parameter and the input parameter are the same, the data structure characteristics of the two are further compared. The data structure characteristics include array dimension, object attribute key set and nesting level depth. When the data structure characteristics meet the compatibility conditions, it is checked whether the value range of the output parameter is a subset of the value constraints of the input parameter.

[0085] When the range of values ​​satisfies the inclusion relationship, the output parameter and the input parameter are determined as a matching parameter pair, and the parameter name mapping relationship of the matching parameter pair is recorded;

[0086] Count the number of all matching parameter pairs corresponding to the directed edge. When the number of matching parameter pairs is greater than the preset minimum matching number threshold, mark the directed edge as a connectable edge and store the parameter name mapping relationship as the connection attribute of the edge.

[0087] During interface compatibility verification, each edge is sequentially selected from the set of directed edges in the requirement semantic graph as the current processing object. For the current edge, the list of candidate components associated with that node is accessed through the identifier of its starting node. The metadata configuration file of that component is read, and a structured description of the output parameter list is parsed from it. This description includes parameter names, data type declarations, and value constraints. Similarly, the list of input parameters for the corresponding candidate component is obtained through the identifier of the terminating node.

[0088] A Cartesian product is performed on the output and input parameter lists to build a comparison matrix of parameter pairs. For each parameter pair in the matrix, the basic data type identifier is first extracted from the parameter declaration. This identifier uses a unified type system definition, including atomic types such as integer, floating-point, string, and boolean. A string comparison method is used to determine if the two type identifiers are completely identical; if the basic types do not match, the parameter pair is skipped.

[0089] When the basic type matches, the data structure feature fields in the parameter declaration are parsed. For array type parameters, their dimension information is extracted; for example, a one-dimensional array records dimension value 1, and a two-dimensional array records dimension value 2. The output parameter's array dimension must be less than or equal to the input parameter's array dimension to satisfy compatibility. For object type parameters, their set of attribute keys is extracted, and set inclusion is used to determine if the output parameter's set of attribute keys is a subset of or equal to the input parameter's set of attribute keys. For nested structures, the maximum nesting depth of the object is calculated. Depth statistics are achieved by recursively traversing the object's sub-objects, ensuring that the nesting depth of the output parameter does not exceed the maximum allowed depth of the input parameter.

[0090] After the data structure features are validated, the metadata constraining the parameter values ​​is further parsed. For numeric parameters, their minimum and maximum value boundaries are read to construct a value range, and it is determined whether the value range of the output parameter falls entirely within the value range of the input parameter. For enumerated parameters, the allowed set of enumerated values ​​is extracted, and it is verified whether the set of enumerated values ​​for the output parameter is a subset of the set of enumerated values ​​for the input parameter. For string parameters, length limits and regular expression patterns are checked to ensure stricter constraints on the output parameter.

[0091] When a parameter pair passes all validation rules, a matching parameter pair record is created. This record contains the mapping relationship between output parameter names and input parameter names and is stored in a temporary mapping table. This mapping table is associated with the current directed edge, and the next parameter pair is processed. After traversal, the total number of records in the mapping table corresponding to the edge is counted and compared with a preset minimum matching number threshold. This threshold is dynamically set according to the component complexity, typically ranging from 1 to 3. When the matching number reaches the threshold, the connectable flag is set to true in the attribute field of the directed edge, and the parameter name mapping table is serialized and stored as the edge's connection attribute for subsequent parameter passing configuration in the script generation stage. For edges that do not reach the threshold, the connectable flag is set to false, and the reason for the mismatch is recorded for debugging purposes.

[0092] In one optional implementation, the requirement semantic graph, the component composition path, and the calling constraint rules of each component are encoded into a structured context, which is then input into a large language model to generate raw script code containing component instantiation and parameter binding logic, including:

[0093] The requirement semantic graph is serialized into text in graph description language format, and the text contains the identifier of each node, the name of the business entity, and the start and end node identifiers and relationship types of each edge.

[0094] Traverse each component in the component combination path, extract the component name, version identifier and interface signature information of each component, and arrange them according to the execution order in the component combination path to generate a component call sequence description;

[0095] The call constraint rules for each component are queried from the rule base of the low-code platform. The call constraint rules include precondition judgment expressions and resource usage declarations. The call constraint rules are associated with the corresponding components to form annotation information.

[0096] Construct a structured data object containing task description fields, graph structure fields, component sequence fields, and constraint rule fields, and fill the corresponding fields with the text in the graph description language format, the component call sequence description, and the annotation information;

[0097] The structured data object is converted into prompt text in natural language template format, and the syntax specification and code generation instructions of the low-code platform are inserted into the prompt text;

[0098] The prompt text is input into the inference interface of the large language model, and the original script code output by the large language model, which includes component instantiation statements, variable declaration statements and parameter assignment statements, is received.

[0099] In the specific implementation, the requirement semantic graph is stored using a directed graph structure, with each node carrying a unique identifier and name attribute for the business entity. During graph serialization, all nodes are traversed to extract their identifiers and business entity names, while all edges are traversed to extract the identifiers of the starting and ending nodes, as well as the relation type attribute annotated by the edges. A graph description language is used to construct the text representation, specifically in the form "Node N1 [Entity: Order Management] -> Edge E1 [Relationship: Data Query] -> Node N2 [Entity: Inventory Check]". Attributes are annotated with square brackets, and directed relationships are indicated by arrows, converting the entire graph structure into linear text that can be understood by a large language model.

[0100] For handling component composition paths, each component object is accessed sequentially according to its order in the path. Metadata for each component is read from the component registry, including the component name string, version identifier, parameter list and types for input interfaces, and return value type for output interfaces. The component information is then concatenated into a serialized description in the path order, using the format "component name@version number(input parameter type list):return type", for example, "DataFetcher@v2.1(String, Integer):List <record>This forms a component call sequence description text that reflects the execution order.

[0101] The constraint rules are retrieved from a pre-established rule base, which stores the constraints of each component using the component identifier as an index. During a query, the corresponding rule item is retrieved based on the component identifier in the component call sequence, and the precondition expression is extracted. This expression defines the necessary conditions for the component to execute, such as "input parameters are not empty and the database connection has been established". At the same time, resource usage declarations are extracted, marking the computing resources or external dependencies required by the component to run, such as "database read permissions are required".

[0102] These constraint rules are associated with the corresponding components in the form of key-value pairs to form annotation information, in the format "ComponentID:{precondition:'expression',resource:'declaration'}".

[0103] When constructing the structured data object, create a data structure containing four fields. The Task Description field contains the original script requirement description text input by the user; the Graph Structure field contains the previously generated graph description language format text; the Component Sequence field contains the component call sequence description; and the Constraint Rules field contains a list structure containing annotation information for all components. This data object is organized in JSON format to ensure a clear hierarchy between fields and ease of parsing.

[0104] When converting to prompt text, the natural language template should include a fixed introductory text and dynamic content slots. The template should begin with "Generate a low-code platform script based on the following requirements," followed by a task description field. Next, it should include "Business entity relationship structure," inserting a graph structure field. Then, it should include "Available components and their calling order," inserting a component sequence field. Finally, it should include "Component usage constraints," inserting a constraint rule field. At the end of the template, append the low-code platform syntax guidelines, explaining the coding rules such as variable declaration format, component instantiation statement format, and parameter passing methods, and add a clear generation instruction: "Please output complete executable script code."

[0105] When invoking the large language model, the constructed prompt text is sent to the model inference service via an HTTP interface. Generation parameters are set, including limiting the maximum output length to a reasonable range and setting the temperature parameter to a low value to ensure output stability. After receiving the response data returned by the model, the code text portion is parsed from the response body. This code text contains component instantiation statements, such as "component1 = new DataFetcher(version='v2.1')", variable declaration statements defining intermediate result storage variables, and parameter assignment statements binding the output of the previous component to the input parameters of the subsequent component, forming complete raw script code for use in subsequent processing stages.

[0106] In one optional implementation, control flow analysis is performed on the original script code to identify conditional branch statements and loop statements, extract the execution condition expressions for each branch, and check whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position, including:

[0107] The original script code is parsed using an abstract syntax tree. Conditional decision nodes and loop structure nodes in the abstract syntax tree are identified. For each conditional decision node, the Boolean expression in its child nodes is extracted as the execution condition expression, and the variable reference identifier in the Boolean expression is extracted.

[0108] For each loop structure node, extract its loop condition expression and variable reference identifiers within the loop body;

[0109] Construct a control flow graph of the original script code, where nodes represent basic code blocks and edges represent execution flow directions. Perform data flow analysis on the control flow graph to track the definition and usage status of each variable reference identifier in each basic code block, and mark the defined and undefined sets of each variable at the entry point of each basic code block.

[0110] Traverse the basic code block containing the execution condition expression and check whether the variable reference identifier in the execution condition expression belongs to the undefined set at the entry point of the basic code block;

[0111] When a variable reference identifier is detected to belong to the undefined set, the semantic type of the business entity corresponding to the variable is queried from the requirement semantic graph, and the data type of the variable is determined according to the semantic type.

[0112] Generate a corresponding initialization assignment statement based on the data type, and assign the variable the default safe value of the data type.

[0113] Locate the statement node in the abstract syntax tree where the variable is first referenced, insert the initialization assignment statement before that statement node, update the abstract syntax tree, and generate the complete executable script code.

[0114] When parsing the original script code using an abstract syntax tree (AST), a recursive descent parser scans the code text line by line, converting the sequence of lexical units into a tree structure. During the traversal of the AST, the parser identifies conditional nodes by node type identifiers; these nodes typically correspond to the syntax structures of if or switch statements. For each conditional node, it extracts nodes of type Boolean expression from its direct children, which contain comparison operators, logical operators, and operands. By matching identifier patterns in the operands using regular expressions, it extracts all variable reference identifiers and records their positions in the code. For loop structure nodes, it identifies the syntax features of for, while, and do-while loops, extracts the loop condition expression from the loop head, and recursively traverses the subtree corresponding to the loop body, collecting all variable reference identifiers within the loop body.

[0115] When constructing the control flow graph, the original script code is divided into several basic code blocks. Each basic code block is a sequentially executed sequence of statements, with only one entry point and one exit point. The basic code block division rule is to split at branch statements, loop statements, and jump statements. The node data structure of the control flow graph includes the start line number, end line number, and statement list of the code block, while the edges carry condition labels for execution flow. During data flow analysis, an iterative algorithm is used to calculate the set of final values ​​for each basic code block. During initialization, the defined set of the entry basic code block is set to an empty set, and the undefined set is set to the set of all variables. For each basic code block, the definition state of variables is updated according to the assignment statements within it, and the variables to be assigned are moved from the undefined set to the defined set. By traversing the predecessor nodes of the control flow graph in reverse, the defined sets at the exits of each predecessor node are merged to obtain the defined set at the entry point of the current node. The undefined set is obtained by the difference operation between the set of all variables and the defined set.

[0116] When traversing the basic code block containing the execution conditional expression, for each variable reference identifier extracted from the conditional judgment node and loop structure node, a search is performed in the undefined set at the entry point of the basic code block. If a variable reference identifier is detected in the undefined set, it indicates that the variable was not assigned a value before being used in the execution conditional expression, which may lead to a runtime error. At this point, the requirement semantic graph is accessed, and the corresponding business entity node is matched based on the variable name. The semantic type attribute of that node is read, which describes the data characteristics of the business entity. The data type of the variable is determined according to the semantic type and the type mapping rules of the low-code platform. For example, a semantic type of "user identifier" maps to a string type, and a semantic type of "amount value" maps to a floating-point type.

[0117] When generating initialization assignment statements, the corresponding default safe value is selected based on the data type: zero for numeric types, false for boolean types, an empty string for string types, and null for object types. The syntax of the initialization assignment statements follows the specifications of the target scripting language; if the data type is an integer, an assignment statement is generated. When locating the first reference position of a variable, all nodes in the abstract syntax tree are traversed in depth-first order, recording the statement node where the variable reference identifier first appears and its parent node. In the list of child nodes of the parent node in the abstract syntax tree, the new node corresponding to the initialization assignment statement is inserted before the first reference statement node, maintaining the relative order of other nodes. After updating the abstract syntax tree, the tree structure is converted back into text-based script code using a code generator, generating complete executable script code to ensure that all variables are initialized before use, eliminating the potential risk of uninitialized variable references.

[0118] A second aspect of this invention provides a low-code platform script generation system based on LLM+RAG, comprising:

[0119] The requirement analysis unit is used to obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, the relationships between entities and the business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities.

[0120] The component matching unit is used to convert each node in the demand semantic graph into a query vector, perform nearest neighbor retrieval in the component vector library of the low-code platform, obtain candidate components whose semantic distance to each node is less than the similarity threshold, extract the data pattern of the input and output interfaces of each candidate component, perform interface compatibility verification based on the edge relationship in the demand semantic graph, and filter out component combination paths whose interfaces can be chained.

[0121] The script generation unit is used to encode the requirement semantic graph, the component combination path and the calling constraint rules of each component into a structured context, input it into the large language model to generate the original script code containing component instantiation and parameter binding logic;

[0122] The code improvement unit is used to perform control flow analysis on the original script code, identify conditional branch statements and loop statements, extract the execution condition expressions of each branch, and detect whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate improved executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a trigger event.

[0123] A third aspect of the present invention provides an electronic device, comprising:

[0124] processor;

[0125] Memory used to store processor-executable instructions;

[0126] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0127] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0128] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0129] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.< / record>

Claims

1. A low-code platform script generation method based on LLM+RAG, characterized in that, include: Obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, relationships between entities and business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities. Each node in the requirement semantic graph is converted into a query vector. Nearest neighbor search is performed in the component vector library of the low-code platform to obtain candidate components whose cosine similarity to the semantic vector representation of each node is less than the similarity threshold. For each candidate component, the data pattern of its input and output interface is extracted. The data pattern includes data type, data structure and value constraints. Based on the edge relationship in the requirement semantic graph, interface compatibility verification is performed to filter out component combination paths that can be chained together. The requirement semantic graph, the component combination path, and the calling constraint rules of each component are encoded into a structured context, which is then input into a large language model to generate original script code containing component instantiation and parameter binding logic. Control flow analysis is performed on the original script code to identify conditional branch statements and loop statements. The execution condition expressions of each branch are extracted, and it is checked whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate complete executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a triggered event.

2. The method according to claim 1, characterized in that, Semantic analysis is performed on the script requirement description to extract business entities, relationships between entities, and business constraints, and a requirement semantic graph is constructed, including: The script requirement description is segmented and part-of-speech tagging is performed to identify noun phrases as candidate business entities. For each candidate business entity, its context in the script requirement description is extracted, and the role type of each candidate business entity in the business process is identified through semantic role tagging. Based on dependency parsing, verb phrases and prepositional phrases in the script requirement description are identified, and semantic association patterns representing the relationships between entities are extracted. The semantic association patterns include the direction of data flow and the direction of control dependency. Based on the conditional clauses and constraint descriptions in the script requirements description, extract the business rule expressions and formalize the business rule expressions into logical constraint conditions. Each candidate business entity is mapped to a node in the demand semantic graph, and the semantic association pattern is mapped to a directed edge in the demand semantic graph. Data transmission type and execution timing constraints are labeled on each directed edge, and the logical constraints are attached to the corresponding node or edge as attribute labels to complete the construction of the demand semantic graph.

3. The method according to claim 1, characterized in that, Each node in the requirement semantic graph is converted into a query vector. Nearest neighbor retrieval is performed in the component vector library of the low-code platform to obtain candidate components whose cosine similarity to the semantic vector representation of each node is less than a similarity threshold. For each candidate component, the data patterns of its input and output interfaces are extracted. These data patterns include data type, data structure, and value constraints. Interface compatibility verification is performed based on the edge relationships in the requirement semantic graph, and component combination paths with chainable interfaces are selected, including: Extract the business entity name and role type label of each node in the demand semantic graph, concatenate the business entity name and role type label into a text description, input the text description corresponding to each node into a pre-trained semantic encoder for vectorization encoding, and generate a fixed-dimensional node semantic vector representation. In the component vector library, an approximate nearest neighbor search is performed on the semantic vector representation of each node using a vector index structure to retrieve candidate components whose cosine similarity to the semantic vector representation of each node is greater than the similarity threshold. For each candidate component, its interface definition document is extracted from the component meta-database of the low-code platform. The interface definition document is parsed to obtain the input parameter list and output parameter list. The data type, data structure and value constraints of each parameter are extracted to construct the data pattern description of the candidate component. Traverse each directed edge in the requirement semantic graph, obtain the starting node and the ending node of the edge, and determine whether there is a parameter pair in the output parameter list of the candidate component corresponding to the starting node that matches the data type in the input parameter list of the candidate component corresponding to the ending node. When a matching parameter pair exists, mark the directed edge as a connectable edge. Based on the topology of the required semantic graph, all paths from the input node to the output node are searched, and paths where all edges are connectable are selected as the component combination paths that can be connected to the interface.

4. The method according to claim 3, characterized in that, Traverse all directed edges in the requirement semantic graph, obtain the start node and end node of the edge, and determine whether there is a parameter pair in the output parameter list of the candidate component corresponding to the start node that matches the data type in the input parameter list of the candidate component corresponding to the end node. When a matching parameter pair exists, mark the directed edge as a connectable edge, including: For each directed edge, obtain the output parameter list of the candidate component corresponding to its starting node and the input parameter list of the candidate component corresponding to its ending node. Iterate through each output parameter in the output parameter list and each input parameter in the input parameter list to extract the basic data type identifier of each parameter. When the basic data type identifiers of the output parameter and the input parameter are the same, the data structure characteristics of the two are further compared. The data structure characteristics include array dimension, object attribute key set and nesting level depth. When the data structure characteristics meet the compatibility conditions, it is checked whether the value range of the output parameter is a subset of the value constraints of the input parameter. When the range of values ​​satisfies the inclusion relationship, the output parameter and the input parameter are determined as a matching parameter pair, and the parameter name mapping relationship of the matching parameter pair is recorded; Count the number of all matching parameter pairs corresponding to the directed edge. When the number of matching parameter pairs is greater than the preset minimum matching number threshold, mark the directed edge as a connectable edge and store the parameter name mapping relationship as the connection attribute of the edge.

5. The method according to claim 1, characterized in that, The requirement semantic graph, the component composition path, and the calling constraint rules of each component are encoded into a structured context, input into a large language model to generate raw script code containing component instantiation and parameter binding logic, including: The requirement semantic graph is serialized into text in graph description language format, and the text contains the identifier of each node, the name of the business entity, and the start and end node identifiers and relationship types of each edge. Traverse each component in the component combination path, extract the component name, version identifier and interface signature information of each component, and arrange them according to the execution order in the component combination path to generate a component call sequence description; The call constraint rules for each component are queried from the rule base of the low-code platform. The call constraint rules include precondition judgment expressions and resource usage declarations. The call constraint rules are associated with the corresponding components to form annotation information. Construct a structured data object containing task description fields, graph structure fields, component sequence fields, and constraint rule fields, and fill the corresponding fields with the text in the graph description language format, the component call sequence description, and the annotation information; The structured data object is converted into prompt text in natural language template format, and the syntax specification and code generation instructions of the low-code platform are inserted into the prompt text; The prompt text is input into the inference interface of the large language model, and the original script code output by the large language model, which includes component instantiation statements, variable declaration statements and parameter assignment statements, is received.

6. The method according to claim 1, characterized in that, Control flow analysis is performed on the original script code to identify conditional branch statements and loop statements. The execution condition expressions for each branch are extracted, and it is checked whether the variables referenced in these expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the variable's data type and business semantics and inserted before the first reference point. This includes: The original script code is parsed using an abstract syntax tree to identify conditional decision nodes and loop structure nodes in the abstract syntax tree. For each conditional decision node, the Boolean expression in its child nodes is extracted as the execution condition expression, and the variable reference identifier in the Boolean expression is extracted. For each loop structure node, the loop condition expression and the variable reference identifier in the loop body are extracted. Construct a control flow graph of the original script code, where nodes represent basic code blocks and edges represent execution flow directions. Perform data flow analysis on the control flow graph to track the definition and usage status of each variable reference identifier in each basic code block, and mark the defined and undefined sets of each variable at the entry point of each basic code block. Traverse the basic code block containing the execution condition expression and check whether the variable reference identifier in the execution condition expression belongs to the undefined set at the entry point of the basic code block; When a variable reference identifier is detected to belong to the undefined set, the semantic type of the business entity corresponding to the variable is queried from the requirement semantic graph, and the data type of the variable is determined according to the semantic type. Generate a corresponding initialization assignment statement based on the data type, and assign the variable the default safe value of the data type. Locate the statement node in the abstract syntax tree where the variable is first referenced, insert the initialization assignment statement before that statement node, update the abstract syntax tree, and then generate the complete executable script code.

7. A low-code platform script generation system based on LLM+RAG, used to implement the method as described in any one of claims 1-6, characterized in that, include: The requirement analysis unit is used to obtain the script requirement description input by the user, perform semantic analysis on the script requirement description, extract the business entities, the relationships between entities and the business constraints, and construct a requirement semantic graph. The nodes of the requirement semantic graph represent business entities, and the edges represent the dependency or calling relationships between entities. The component matching unit is used to convert each node in the requirement semantic graph into a query vector, perform nearest neighbor retrieval in the component vector library of the low-code platform, obtain candidate components whose cosine similarity with the semantic vector representation of each node is less than the similarity threshold, extract the data pattern of the input and output interface of each candidate component, the data pattern includes data type, data structure and value constraints, perform interface compatibility verification based on the edge relationship in the requirement semantic graph, and filter out component combination paths that can be chained together. The script generation unit is used to encode the requirement semantic graph, the component combination path and the calling constraint rules of each component into a structured context, input it into the large language model to generate the original script code containing component instantiation and parameter binding logic; The code improvement unit is used to perform control flow analysis on the original script code, identify conditional branch statements and loop statements, extract the execution condition expressions of each branch, and detect whether the variables referenced in the execution condition expressions have been assigned values ​​on all reachable paths. When uninitialized variables are detected, initialization assignment statements are automatically generated based on the data type and business semantics of the variables and inserted before the first reference position to generate improved executable script code. The executable script code is then loaded into the runtime environment of the low-code platform and executed in response to a trigger event.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images