AI-assisted low-code platform building method and system

Abstract

The application discloses an AI-assisted low-code platform building method and system, relating to the field of platform building, which first performs topological analysis on a business flowchart, accurately identifies upstream data sources and downstream data destinations of a target node. Based on this dependency relationship, a structured node data contract specification object is automatically constructed, which clearly defines the input data mode that the target node must follow and the output data mode that should be generated. Subsequently, this contract object is provided as a strong constraint context to the large language model together with the user's intention, guiding it to generate code that meets the data flow requirements and ensuring compliance through final contract verification. This method changes the AI generation process from unstructured guessing to a verifiable fulfillment, solving the problem of mismatched node data contracts caused by lack of global awareness, ensuring the connectivity and reliability of the entire business process.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of platform building, and more specifically, to an AI-assisted low-code platform building method and system. BACKGROUND

[0002] With the rapid development of software development, low-code platforms greatly reduce the threshold of application construction and improve development efficiency through their visual and modular characteristics. In order to further improve the automation and intelligence level of the platform, integrating artificial intelligence (especially large language models) into low-code platforms and using natural language to drive code generation have become an important technical development trend. Through this integration, users can more intuitively describe business requirements, and AI can assist in generating functional code for business logic nodes, thereby significantly simplifying the development process and allowing business personnel without a professional programming background to participate in application building.

[0003] However, in existing technical practices, AI-assisted functions are often atomized. This means that when AI models process a single business node, they usually only generate code based on the local description of the node, lacking global awareness of the entire business flowchart topology. Specifically, when AI generates code for a target node, it does not structurally know the output data patterns of its upstream nodes and the input data patterns of its downstream nodes. This lack of contextual information makes the AI generation process like a blind man feeling an elephant, only able to make guesses based on its general knowledge and probabilities, and unable to ensure the accuracy of data interaction between nodes.

[0004] This atomized and contextually unaware generation method directly leads to a serious data contract mismatch problem. Due to the probabilistic nature of large language models, even for the same semantic requirements, the generated code may differ in data structure (such as field name, data type, or hierarchy). When the output data generated by an upstream node cannot be matched with the expected input data of a downstream node in terms of format, the entire business process will fail due to interrupted data flow at runtime. This not only makes AI-generated code fragments difficult to integrate effectively, but also seriously weakens the reliability and practicality of AI-assisted low-code platforms, making them unable to truly realize end-to-end automated business process construction, which is a bottleneck that needs to be addressed in current technical development. SUMMARY

[0005] To solve the problems in the background art, according to an aspect of the present application, a low-code platform building method based on AI assistance is provided, which includes: obtaining a business flowchart input by a user and a target node ID specified by the user.

[0006] The business flowchart and the target node ID are subjected to business flowchart analysis and dependency relationship extraction to obtain an upstream node list and a downstream node list.

[0007] Based on the upstream node list, the downstream node list, and the node mode library, a node data contract specification object is generated.

[0008] The node data contract specification object is input into a large language model to obtain generated code.

[0009] Code static analysis and contract verification are performed on the generated code and the node data contract specification object to obtain a verification result.

[0010] In response to the verification result being passed, the generated code is associated with the target node ID.

[0011] According to another aspect of the present application, an AI-assisted low-code platform building system is provided, which includes a user information acquisition module configured to acquire a business process graph input by a user and a target node ID specified by the user.

[0012] A business process graph analysis module is configured to perform business process graph analysis and dependency extraction on the business process graph and the target node ID to obtain an upstream node list and a downstream node list.

[0013] A specification object generation module is configured to generate a node data contract specification object based on the upstream node list, the downstream node list, and a node mode library.

[0014] A code generation module is configured to input the node data contract specification object into a large language model to obtain generated code.

[0015] A verification module is configured to perform code static analysis and contract verification on the generated code and the node data contract specification object to obtain a verification result.

[0016] An association module is configured to associate the generated code with the target node ID in response to the verification result being passed.

[0017] Compared with the prior art, the AI-assisted low-code platform building method and system provided by the present application introduces a mechanism of first contract and then generation to solve the context missing problem in AI code generation. Before requesting a large language model to generate code, a topological analysis is first performed on a business process graph to accurately identify the upstream data sources and downstream data destinations of a target node. Based on this dependency relationship, a structured node data contract specification object is automatically constructed, which clearly defines the input data mode that the target node must follow and the output data mode that should be generated. Subsequently, this contract object is used as a strong constraint context to guide the AI code generation process, and the generated code is associated with the target node ID. The AI-assisted low-code platform building method and system provided by the present application can effectively solve the context missing problem in AI code generation, and can improve the accuracy and efficiency of AI code generation. Figure OneAnd provide to the large language model, guide it to generate the code that meets the data flow requirement, and ensure its compliance through the final contract verification. This method changes the generation process of AI from unbound guess to reliable performance, solves the problem of data contract mismatch between nodes caused by lack of global awareness, and guarantees the connectivity and reliability of the entire business process. BRIEF DESCRIPTION OF DRAWINGS

[0018] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description thereof taken in conjunction with the accompanying drawings.

[0019] Figure 1 Flow chart of the AI-assisted low-code platform building method according to an embodiment of the present application.

[0020] Figure 2 Data flow diagram of the AI-assisted low-code platform building method according to an embodiment of the present application.

[0021] Figure 3 Flow chart of step 3 in the AI-assisted low-code platform building method according to an embodiment of the present application.

[0022] Figure 4 Flow chart of step 4 in the AI-assisted low-code platform building method according to an embodiment of the present application.

[0023] Figure 5 Flow chart of step 5 in the AI-assisted low-code platform building method according to an embodiment of the present application.

[0024] Figure 6 Block diagram of the AI-assisted low-code platform building system according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] Embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. It should be understood that the accompanying drawings and embodiments of the present disclosure are only for exemplary purposes, and are not intended to limit the scope of protection of the present disclosure.

[0026] Based on the above deficiencies in the technical field, the present application proposes an AI-assisted low-code platform building method. Figure 1 Flow chart of the AI-assisted low-code platform building method according to an embodiment of the present application. Figure 2 Data flow diagram of the AI-assisted low-code platform building method according to an embodiment of the present application. As Figure 1 And Figure 2As shown, the AI-assisted low-code platform building method according to the embodiment of the present application comprises: step 1, obtaining a business process diagram input by a user and a target node ID specified by the user; step 2, performing business process diagram analysis and dependency relationship extraction on the business process diagram and the target node ID to obtain an upstream node list and a downstream node list; step 3, generating a node data contract specification object based on the upstream node list, the downstream node list, and a node mode library; step 4, inputting the node data contract specification object into a large language model to obtain generated code; step 5, performing code static analysis and contract verification on the generated code and the node data contract specification object to obtain a verification result; and step 6, in response to the verification result being passed, associating the generated code with the target node ID.

[0027] In step 1, a business process diagram input by a user and a target node ID specified by the user are obtained. It should be understood that, in the prior art, the AI-assisted code generation function lacks perception of the global topology of a business process, which leads to difficulty in ensuring data contract consistency between nodes of generated code fragments, thereby causing the risk of interruption of a business process. To solve this problem, in the present application, comprehensive cognition of the position of a target node in the entire business process and the data dependency relationship thereof is first established. Therefore, obtaining a business process diagram input by a user and a target node ID specified by the user can capture the most original and complete context information required for subsequent dependency relationship extraction and data contract construction, thereby providing an indispensable global perspective for subsequent AI code generation and ensuring that the finally generated code can seamlessly integrate into an existing business process, thereby solving the data mismatch problem.

[0028] In a feasible solution, step 1 can be implemented as follows: the business process diagram input by the user is a kind of graph data structure used to describe business logic flow, which internally contains a plurality of business nodes node and directed edges edge defining data flow between nodes. This data structure is stored and transmitted in a standardized format, for example, in JSON format. Each node object contains a globally unique node ID, node type, node name, and other business attributes. The target node ID specified by the user is a unique identifier of a node selected by the user during interactive operation on the visual interface and expected to be generated by the artificial intelligence-assisted code generation function. This acquisition process is completed in the graphical user interface of the low-code platform. The user builds a complete business process diagram through drag-and-drop components, configuration attributes, and other methods. When the user needs to generate logic code for a specific node, the user will specify the node through clicking, selecting, and other interactive actions. This interactive event triggers the front-end application to pass the complete business process diagram data structure on the current canvas and the ID of the selected node as parameters to the back-end processing logic.

[0029] The following is an example of a specific order processing flow. The flow contains five core nodes: an order information acquisition node (ID node_A), a user discount query node (ID node_D), an order total price calculation node (ID node_B), a shipping notification generation node (ID node_C), and a financial system update node (ID node_E). The data flow is designed such that order information and user discount information are simultaneously fed into the order total price calculation node, and after the calculation is complete, the result is respectively fed to the shipping notification generation and financial system update two subsequent nodes. When the user completes the drawing of this flowchart in the visual editor, it is decided to generate code for the order total price calculation node, i.e., node_B. At this time, the user clicks on the interface to select the node.

[0030] The operation triggers the data acquisition process. First, the platform front end serializes the entire business process graph into a JSON object. For example: {"nodes":[{"id":"node_A","type":"data acquisition","name":"order information acquisition","properties":{"source":"database"}},{"id":"node_B","type":"business logic","name":"order total price calculation","properties":{}},{"id":"node_C","type":"message notification","name":"delivery notification generation","properties":{"channel":"email"}},{"id":"node_D","type":"data query","name":"user discount query","properties":{"source":"crm"}},{"id":"node_E","type":"system integration","name":"financial system update","properties":{"target":"erp"}}],"edges":[{"id":"edge_1","source":"node_A","target":"node_B"},{"id":"edge_2","source":"node_B","target":"node_C"},{"id":"edge_3","source":"node_D","target":"node_B"}{"id":"edge_4","source":"node_B","target":"node_E"}]} The above JSON object is the business process graph that needs to be acquired. At the same time, due to the user's click operation, the platform front end captures the unique identifier of the selected node, which is the string "node_B". This string is the target node ID specified by the user.

[0031] In step 2, the business process graph and the target node ID are parsed and dependency relationship is extracted to obtain an upstream node list and a downstream node list. Accordingly, in order to overcome the problem of data contract mismatch caused by the lack of global context in the prior art AI code generation, the accurate data input source and data output destination of the target node need to be provided for the code generation process of the target node. Obtaining the complete business process graph is not enough to form directly usable constraint information. Therefore, the business process graph needs to be parsed and dependency relationship extracted to accurately identify and separate the upstream data supply nodes and downstream data consumption nodes directly connected to the target node from the complex global topology data. Thus, the global view is transformed into a local and strongly related context, providing structured and directly related node information for subsequent data contract construction, which is a key link for context-aware generation.

[0032] In one possible solution, step 2, the business process graph and the target node ID are parsed and dependency relationship is extracted to obtain an upstream node list and a downstream node list, including: step 21, traversing all directed edges in the business process graph to filter out all edges ending with the target node ID to obtain an upstream node list; step 22, traversing all directed edges in the business process graph to filter out all edges starting with the target node ID to obtain a downstream node list.

[0033] In the above scheme, step 2 can be implemented as follows: first, the extraction process of the upstream node list is performed. The core of this process is to traverse the edges directed edge array in the business process graph data structure. For each edge object in the array, it is checked whether the value of its target end point field completely matches the input target node ID, i.e. node_B. In the business process graph JSON, the edges array contains two objects. The processor checks these two objects one by one. The first edge object edge_1 has the structure {"id":"edge_1","source":"node_A","target":"node_B"} and its target field value is node_B, which matches the target node ID. Therefore, the value of the source start point field of this edge object, i.e. node_A, is extracted and stored in a temporary set. Then the second edge object edge_2 is checked, and its target field value is node_C, which does not match the target node ID, so this edge object is ignored. The third edge object edge_3 is then checked, which has the structure {"id":"edge_3","source":"node_D","target":"node_B"} and its target field value is also node_B, which satisfies the matching condition, so the value of its source start point field, i.e. node_D, is also extracted. The last edge object edge_4 has a target field value of node_E, which does not match, and is ignored. After traversing all edge objects, all ID elements in the temporary set are collected to form the upstream node list. In this example, the list contains two elements, i.e. ["node_A","node_D"].

[0034] Next, the extraction process of the downstream node list in step 22 is performed. This process also traverses the edges array, but its filtering logic is to check whether the value of the source field of each edge object matches the target node ID node_B. The handler again traverses the edges array from the beginning. When checking the first edge object edge_1, the value of its source field is node_A, which does not match the target node ID, and is ignored. When checking the second edge object edge_2, the value of its source field is node_B, which satisfies the matching condition. Therefore, the value of the target field of this edge object, i.e., node_C, is extracted and stored in another temporary set. The handler continues to check the third edge object edge_3, the value of its source field is node_D, which does not match, and is ignored. Finally, the fourth edge object edge_4 is checked, which has the structure {"id":"edge_4","source":"node_B","target":"node_E"}, and the value of its source field is also node_B, which also satisfies the matching condition, so the value of its target field, i.e., node_E, is also extracted. After traversal, all ID elements in the temporary set are collected to form the downstream node list. In this example, the list is ["node_C","node_E"].

[0035] In step 3, a node data contract specification object is generated based on the upstream node list, the downstream node list, and the node schema library. It can be understood that after identifying the direct data dependency relationship of the target node, these abstract node identifiers themselves cannot provide the specific data structure information required by the artificial intelligence model to generate code. In order to enable the large language model to understand the format of the input data it processes and the format of the output data it needs to generate, it is necessary to convert these dependencies into an accurate, structured machine-readable specification. Therefore, the present application generates a node data contract specification object based on the upstream node list, the downstream node list, and the node schema library to build a comprehensive context constraint that clearly defines the input and output contracts of the target node code.

[0036] In a feasible solution, Figure 3 The flowchart of step 3 in the method of building an AI-assisted low-code platform according to an embodiment of the present application. As Figure 3As shown, in step 3, the node data contract specification object is generated based on the upstream node list, the downstream node list and the node schema library, including: in step 31, based on the node schema library, the upstream input contract is aggregated based on the upstream node list to obtain the aggregated input contract; in step 32, based on the node schema library, the downstream output contract is inferred and constructed based on the downstream node list and the user intent description to obtain the constructed output contract; in step 33, the aggregated input contract, the constructed output contract and the user intent description are assembled to obtain the node data contract specification object.

[0037] In the above scheme, step 3 can be implemented as follows: first, step 31 is performed to aggregate the upstream input contract. In a feasible scheme, step 31, based on the node schema library, the upstream input contract is aggregated based on the upstream node list to obtain the aggregated input contract, including: in step 311, each upstream node ID in the upstream node list is used as a key to query the node schema library to obtain the upstream node output schema set; in step 312, the upstream node output schema set is aggregated to obtain the aggregated input contract.

[0038] Specifically, the node schema library is a key infrastructure. It is a persistent storage, such as a key-value database or a document database, for centralized management of input and output data schemas of all configured nodes in the low-code platform. When a user creates a node in the platform and defines its function, the output data structure (i.e. schema) of the node will be standardized and stored in the library with the unique ID of the node as the key. This schema is described in a standardized format such as JSONSchema, a language based on JSON format to define data structure specifications, which defines the field name, data type, whether it is required, and nested structure, etc. in the data object in detail.

[0039] The first step is to query the output schema set of the upstream nodes. The process takes the list of upstream nodes ["node_A", "node_D"] as input. The program iterates through each node ID in the list. For the first ID "node_A", the program queries the node schema repository with this key. Upon successful query, the pre-configured output schema of "node_A" (order information retrieval node) is obtained. For example, the schema defines the core information of an order with the following structure: {"type":"object","properties":{"orderId":{"type":"string"},"items":{"type":"array","items":{"type":"object","properties":{"productId":{"type":"string"},"quantity":{"type":"integer"},"price":{"type":"number"}}}},"customerInfo":{"type":"object","properties":{"userId":{"type": "string"},"address":{"type":"string"}}}}}. In this schema structure, the type field defines the data type, such as object or array; the properties field describes the attributes of the object; orderId represents the order identifier, which is a string; items is an array containing the product items in the order, each product item is an object containing productId, quantity, and price; customerInfo is an object containing userId and address. This schema object is added to the upstream node output schema set. Next, the program processes the second ID "node_D". Similarly, the node schema repository is queried with "node_D" as the key, and the output schema of "node_D" (user discount query node) is obtained. For example, the schema defines the user's discount information with the following structure: {"type":"object","properties":{"userId":{"type":"string"},"discountRate":{"type":"number","minimum":0,"maximum":1}}}.This schema object defines a userId user identifier and a discountRate discount rate, where the data type of the discount rate is number, and minimum and maximum constraints are attached. This schema object is also added to the upstream node output schema set. If a corresponding schema does not exist in the resource library for a certain upstream node ID during the query process, an empty schema object `{}` is associated with it to ensure the robustness of subsequent processing.

[0040] The second step is to aggregate the upstream node output schema set after completing the schema query of all upstream nodes in step 312. This aggregation process aims to integrate the scattered output schema associated with each upstream node into a single structured input contract object for the target node. The aggregated input contract is a JSON object whose key is the ID of the upstream node and the value is the output schema corresponding to the node. Based on the schema set queried in the last step, the generated aggregated input contract is as follows: {"node_A":{"type":"object","properties":{"orderId":{"type":"string"},"items":{"type":"array","items":{"type":"object","properties":{"productId":{"type":"string"},"quantity":{"type":"integer"},"price":{"type":"number"}}}},"customerInfo":{"type":"object","properties":{"userId":{"type":"string"},"address":{"type":"string"}}}}},"node_D":{"type":"object","properties":{"userId":{"type":"string"},"discountRate":{"type":"number","minimum":0,"maximum":1}}}}. This JSON object is the aggregated input contract. It clearly indicates to the subsequent steps that the target node "node_B" will receive two independent data input sources from "node_A" and "node_D", and specifies the data structure of each input source in detail.

[0041] Then, the step 32 of inferring and constructing the output contract is performed. In one possible implementation, the step 32 infers and constructs the output contract based on the node schema repository, the list of downstream nodes and the user intent description to obtain a constructed output contract, including: step 321, querying the node schema repository with each downstream node ID in the list of downstream nodes as a key to obtain a required schema; step 322, in response to the required schema being empty or the fields being incomplete, inferring the implicit requirements based on the user intent description and the list of downstream nodes to obtain a suggested schema; and step 323, merging the required schema and the suggested schema to obtain the constructed output contract.

[0042] The first step is step 321. With the list of downstream nodes ["node_C", "node_E"] as input, each node ID in the list is traversed and used as a key to query the node schema repository for its predefined input schema. For the shipment notification generation node with ID "node_C", the input schema is queried and a JSON Schema requiring an orderId order identifier, a finalAmount final amount, and a shippingAddress shipping address can be obtained. For the financial system update node with ID "node_E", the input schema is queried and a JSON Schema requiring an orderId order identifier, a totalAmount total amount, and a discountApplied applied discount can be obtained. Then, the input schemas required by all downstream nodes are merged to form a unified required schema. During the merging, all required fields are collected together, and if there are fields with the same semantics but different names (such as finalAmount and totalAmount), normalization processing can be performed according to a preset synonym library or rules, and here they are unified as finalAmount. The final required schema is a JSON Schema object that specifies that the output of the target node node_B must contain the four fields of orderId, finalAmount, shippingAddress, and discountApplied to ensure that the direct data requirements of all downstream nodes can be met.

[0043] The second step 322 suggests an implicit requirement inference process of the schema. The natural language intent description provided by the user for the target node "node_B" is obtained, which is directly entered by the user in the attribute configuration interface of the target node through a dedicated text input box, for example: "Calculate the total order price, apply user discount, and output the final payment amount, order details, and delivery address for subsequent use". The triggering condition of this process is that the mandatory schema fails to fully cover the user's intent, for example, the user's intent description mentions order details, and this field does not appear in the mandatory input of any downstream node. At this time, inference needs to be made based on the user intent description and the set of downstream node types, i.e. ["message notification", "system integration"]. The inference process first extracts noun phrases from the user intent description through natural language processing techniques, or selects relevant terms from a pre-defined business domain vocabulary library, to generate a series of candidate fields k. Then, a scoring formula is used to evaluate the rationality of a series of candidate output fields. In a feasible solution, step 322, in response to the mandatory schema being empty or the field being incomplete, performs implicit requirement inference based on the user intent description and the list of downstream nodes to obtain the suggested schema, including: in response to the mandatory schema being empty or the field being incomplete, performing implicit requirement inference based on the user intent description and the list of downstream nodes to obtain the suggested schema, using the following formula: ; wherein, is the key, represents the output field of type , and are configurable weights, is the user intent description, is the set of all node types in the list of downstream nodes, is a relevance function for evaluating and the user intent description , is a necessity function for evaluating for the set of downstream node types , is a rational value. In this formula, k represents the key, i.e. the name of the candidate output field. It is a string used to identify an attribute in the output data object. For example, in the business concept of order details, k may be the string "itemsDetail"; for the final amount, k is "finalAmount". Tk represents the inferred data type associated with the key k. It defines the data format that the field k should carry. For example, if k is "itemsDetail", its corresponding data type Tk may be "array", i.e. an array, because order details usually contain multiple items. If k is "finalAmount", Tk may be "number", i.e. a number. and are configurable weights to balance the importance of user intent and downstream node type constraints, which are empirically tuned on validation set to achieve the best inference results or pre-set by platform administrators according to business policies, and their sum is 1. For example, one can set = 0.6, = 0.4, indicating more emphasis on meeting the user's explicit description. is a relevance function to evaluate the semantic relevance between candidate field k and user intent I. This function can be implemented based on a pre-trained text embedding model with Transformer architecture (such as BERT). The specific architecture of this model consists of multiple stacked Transformer encoder layers, each of which contains a multi-head self-attention mechanism and a feed-forward neural network. Its processing process is as follows: candidate field k and user intent I are constructed into a specific input format (such as [CLS] k [SEP] I [SEP]), and input into the model. The model uses its multi-head self-attention mechanism to capture complex intra-text and inter-text dependencies in parallel, and integrates information through deep network structure, finally extracts a fixed dimension embedding vector that can capture deep semantics from a specific output position of the top encoder (such as the output corresponding to the [CLS] marker). Then the cosine similarity between the two vectors is calculated to quantify their relevance, and finally a score between 0 and 1 is output. is a necessity function that evaluates the general necessity of field k for the set of downstream node types. This function can be implemented based on a specially trained classification model, such as a multi-layer perceptron (MLP) network that contains an input layer, several hidden layers with activation functions, and an output layer. The specific architecture of this network includes an input layer for receiving the featureized input, where the candidate field k and the set of downstream node types can be converted into numerical vectors (e.g., through one-hot encoding or embedding vectors); one or more hidden layers that use a non-linear activation function (e.g., ReLU) to perform layer-by-layer abstraction and combination transformation on the input features; and an output layer that uses a Sigmoid activation function to produce a probability score between 0 and 1. This network is trained through supervised learning on a large amount of historical low-code application data, with its weight and bias parameters iteratively optimized through the backpropagation algorithm and an optimizer (e.g., Adam) to minimize the loss (e.g., binary cross-entropy loss) between the predicted value and the true label. During inference, the candidate field k and each type in the set of downstream node types are input as features, and the model outputs a probability score evaluating the necessity of k for that type of node. Finally, these scores are combined to obtain a general necessity evaluation value between 0 and 1. Taking the order details as an example, the field name k is "itemsDetail", and the calculation result of Fintent("itemsDetail", I) may be 0.9 because the order details are explicitly mentioned in the intent description. At the same time, the calculation result of Ftype("itemsDetail", ["message notification", "system integration"]) may be 0.7 because it is common business practice to include order details in notifications and financial records. Therefore, the final score of this field is S("itemsDetail", "array") = 0.6 * 0.9 + 0.4 * 0.7 = 0.82. The handler generates a series of candidate fields and calculates their scores, then filters out all scores greater than a preset threshold, which is empirically determined by evaluating the model performance on a validation dataset to achieve the best balance between suggestion accuracy and coverage, such as 0.75. Since 0.82 is greater than 0.75, "itemsDetail", "array", i.e., the field "itemsDetail" and its inferred type (array type), are adopted, forming the suggestion pattern.

[0044] In particular, after the necessary schema is aggregated by the input schema of the downstream nodes, it can only cover the explicit defined, hard data integration requirements in the business process. However, the real business intention of the user is often more abundant, which may contain some implicit data outputs that are not explicitly required in any downstream node, such as intermediate variables for debugging or detailed records for subsequent analysis. If only relying on the necessary schema, the code generated by artificial intelligence may be incomplete in function. Simply relying on natural language processing models to understand user intentions to make up for this deficiency, although flexible and generalizable, may produce suggestions that are semantically similar but not standardized in naming or irrelevant to the structure of the business process. Conversely, simply relying on structured knowledge based on rules, although accurate in recommendations, is weak in generalization and cannot handle novel requirement patterns. Therefore, scene-aware semantic-structure fusion field inference can establish an advanced decision-making mechanism that intelligently combines the flexibility of user natural language intentions with the certainty of business process structured constraints, thereby inferring a comprehensive suggestion schema that meets the user's implicit requirements and conforms to the overall business logic.

[0045] In a feasible preferred solution, step 322, in response to the necessary schema being empty or the field being incomplete, implicit requirement inference based on the user intention description and the downstream node list is performed to obtain the suggestion schema, including: extracting the relevance between the kth candidate field and the user intention description from the business domain vocabulary library to obtain the relevance, and calculating the necessity between the kth candidate field in the user intention description and the set of downstream node types to obtain the necessity value. First, for each candidate field k, a preliminary quantitative evaluation is performed from the semantic and structural dimensions to obtain the basis score for all subsequent calculations. Specifically, first, the relevance between the candidate field k and the user intention description I is calculated by natural language processing technology, and the relevance is obtained . This function can be obtained by a pre-trained natural language processing model, for example, by calculating the cosine similarity between the embedding vector of the candidate key k and the embedding vector of the user intention I, and the result is a continuous probability value in the interval. The relevance function can capture semantic associations, but may also produce semantically similar but non-standardly named candidates, for example, if the user intention is to create a work order, the model may give a higher score to the work order topic, work order item, release name, etc. However, it is very sensitive to the semantic context of the user intention and has strong generalization ability, and can understand business terms that are not seen in the training data. At the same time, based on the set of downstream node types , the necessity value of the candidate field k is calculated by querying the pre-defined rule library or knowledge graph, and the necessity value is obtained The result of this function is usually a discrete deterministic value, such as {0: irrelevant, 0.5: suggested, 1: required}, representing the domain knowledge and hard constraints that the system has learned from the past, so when the rule matches, its recommended field is almost always correct, but its generalization ability is weak, and it cannot handle new node types or new demand patterns outside the rule base. In particular, and The calculation process is the same as the calculation process in the above feasible ways, so it is not specifically described.

[0046] The relevance and necessity values are modulated using an enhancement function to obtain a modulated reasonable value. Then, in order to solve the deficiency of directly linearly adding relevance and necessity values, a nonlinear gating enhancement mechanism is introduced, so that structurally necessary fields can obtain a score advantage far exceeding linearity. In specific implementation, a nonlinear enhancement function is introduced, and the modulated reasonable value is calculated using the following formula : In this formula, is a hyperparameter greater than zero, used to control the enhancement intensity, which can be set according to experience, for example, set to 2.0. When a field is required ( ), its enhancement factor is , and the final score of the structurally required field will be exponentially magnified, so it can easily surpass other only semantically related fields in ranking; when the field is irrelevant ( ), the enhancement factor is 1, and the score is completely determined by the relevance , without enhancement or inhibition, thereby ensuring that in the absence of structured knowledge, exploratory suggestions can still be relied on natural language processing models; when the field is at the suggestion level ( ), it obtains moderate enhancement. In this way, by modulating with , it is more in line with the intelligent decision-making mode of structure priority and semantic assistance.

[0047] A structural certainty coefficient is introduced, and the relevance and necessity values are constrained based on the structural certainty coefficient to obtain a constrained reasonable value. Then, the inference model is given scene awareness ability, which can adaptively adjust the trust weight of the two information sources of semantics and structure according to the explicit or fuzzy degree of the current business process. In specific implementation, first introduce the structural certainty coefficient , which is used to quantify the explicitness of the downstream node contract, and its calculation formula is: wherein is the set of downstream nodes, is an indicator function that returns 1 if the node has a defined non-empty input mode, otherwise returns 0, is the total number of downstream nodes. The value range is [0,1]. Then, based on this coefficient, the reasonable constraint value is calculated using the following formula. : This demonstrates scenario adaptability. That is, if under strong constraints, all downstream nodes have a defined output pattern, then... Approaching 1, at which point the domain rules are fully trusted, effectively avoiding the creative illusions of natural language processing models; however, under weak constraints, all downstream nodes are general nodes, then... Approaching zero, this approach relies entirely on the user's natural language intent, maximizing the flexibility of the natural language processing model. This makes the inference engine more robust to different business processes, allowing it to intelligently adjust its decision-making strategy based on the certainty of the current process.

[0048] A weighted fusion of the modulation reasonable value and the constraint reasonable value is performed to obtain a reasonable value. Then, the two scoring strategies, each with its own advantages, are integrated to obtain a more robust final score that possesses both nonlinear enhancement capabilities and scene adaptability. In specific implementation, the modulation reasonable value is... and constrained reasonable values Perform a weighted sum to obtain the final reasonable value: Reasonable value = ,in, and It is a preset weight, and + =1, used to balance the contributions of the two strategies. For example, it can be set to... It is 0.5. A value of 0.5 indicates that both strategies are equally important.

[0049] Based on the reasonable value, the inferred type of the k-th candidate field is obtained. That is, for the same candidate field key k, there may be multiple candidate data types (such as string, number, array). The inference process calculates the final reasonable value for each possible type and selects the type with the highest reasonable value as the final inferred type for that field. All candidate fields with a final score higher than a preset threshold and their inferred types together constitute the final suggested pattern. In particular, this process is the same as the processing in the feasible solutions described above.

[0050] The third step, step 322, involves merging the required and suggested schemas. The required and suggested schemas obtained in the previous step are merged. This merging operation generates a new, more complete JSON schema that includes all fields from both schemas. This final schema is the completed output contract. It not only ensures compatibility with downstream nodes but also supplements the implicit business requirements in the user's intent through intelligent inference.

[0051] Finally, step 33 is performed. Object assembly is performed on the aggregated input contract, the built output contract, and the user intent description. First, the aggregated input contract JSON object is assigned to the inputContract key in the new object in its entirety. Second, the built output contract JSON Schema object is assigned to the outputContract key in the new object in its entirety. Finally, the original natural language description string input by the user, i.e., "Calculate the total order price, apply user discount, and output the final payment amount, order details, and shipping address for later use," is assigned to the intent key in the new object. Through the above assembly, the final generated node data contract specification object is a JSON object with clear structure and complete information. The complete example structure is as follows: The outermost layer of the object contains three key-value pairs. The first key is inputContract, and its value is an object with two upstream node IDs, node_A and node_D, as keys, and their respective values are JSON Schemas that describe the data structures in detail. The second key is outputContract, and its value is a single JSON Schema object, which is defined as an object type through the type field, and the properties field describes all the fields that the target node must output, including orderId, finalAmount, shippingAddress, discountApplied, and itemsDetail, which is inferred. The type of itemsDetail is defined as an array, and the items array member is defined as an object. The third key is intent, and its value is the complete natural language description string input by the user.{"inputContract":{"node_A":{"type":"object","properties":{"orderId":{"type":"string"},"items":{"type":"array","items":{"type":"object","properties":{"productId":{"type":"string"},"quantity":{"type":"integer"},"price":{"type":"number"}}}},"customerInfo":{"type":"object","properties":{"userId":{"type":"string"},"address":{"type":"string"}}}},"node_D":{"type":"object","properties":{"userId":{"type":"string"},"discountRate":{"type":"number"}}}},"outputContract":{"type":"object","properties":{"orderId":{"type":"string"},"finalAmount":{"type":"number"},"shippingAddress":{"type":"string"},"discountApplied":{"type":"number"},"itemsDetail":{"type":"array","items":{"type":"object"}}}},"intent":"Calculate the total price of the order, apply the user discount if necessary, and output the final payment amount, order details, and shipping address for subsequent use"}.

[0052] In step 4, the node data contract specification object is input into the large language model to obtain generated code. It should be understood that after a complete and structured node data contract specification object is constructed through the previous steps, the object already contains all the context information required for generating code, including precise input and output data formats and explicit business logic descriptions. However, this specification object itself is a high-level specification, not directly executable program code. Therefore, the present application inputs this specification object into the large language model to obtain generated code in order to utilize the powerful natural language understanding and code generation capabilities of artificial intelligence models to automatically translate this machine-readable, structured business specification into specific, effective, and contract-constrained underlying functional code, thereby achieving automated construction from business requirements to executable logic.

[0053] In a feasible solution, Figure 4 The flowchart of step 4 in the AI-assisted low-code platform building method according to an embodiment of the present application is shown. As shown in Figure 4 Step 4, inputting the node data contract specification object into the large language model to obtain generated code, includes: step 41, serializing the node data contract specification object to obtain a serialized node data contract specification object; step 42, embedding the serialized node data contract specification object into a user prompt word template to obtain a final prompt word template; and step 43, inputting the final prompt word template into the large language model to obtain generated code.

[0054] In the above solution, step 4 can be implemented as follows: first, step 41 is performed to serialize the node data contract specification object. In this process, the node data contract specification object generated in the previous embodiment and existing in the memory in the form of a JSON object is converted into a standard string representation. This conversion is completed by calling the built-in JSON processing library in the programming language, such as converting it into a compact or formatted JSON string, to flatten the structured data object into a pure text format, so as to be seamlessly embedded into the text prompt word template in the next step. The result of serialization is a single long string containing all input contracts, output contracts, and user intent information.

[0055] Next, the process of embedding the serialized node data contract schema object into the user prompt template is performed in step 42. The user prompt template is a pre-designed text structure that guides the large language model to perform tasks in a specific way through carefully arranged instructions and placeholders. This template is designed and optimized through prompt engineering methods, that is, through repeated trials and evaluations to determine the text framework that can most stably and accurately guide the model to generate code that meets the requirements. The template contains settings for the role of the model, a clear description of the task, format specifications for input and output, and placeholders for dynamic content filling. In this embodiment, a pre-set user prompt template can look like this: "You are a professional software engineer who is good at writing high-quality JavaScript functions according to strict data contracts. Your task is to write a function body that receives an input object containing the output of multiple upstream nodes and returns an object that strictly adheres to the specified output contract. Please complete the coding according to the context information provided below: 1. Input Contract: The data structure that the function will receive is as follows: {{SERIALIZED_INPUT_CONTRACT}}; 2. Output Contract: The data structure that the function must return is as follows: {{SERIALIZED_OUTPUT_CONTRACT}}; 3. Business Intent: The specific business logic that needs to be implemented is: {{SERIALIZED_INTENT}}; Please only return the JavaScript code inside the function body, do not include the function signature or any additional explanatory text." The processing program will replace the {{SERIALIZED_INPUT_CONTRACT}}, {{SERIALIZED_OUTPUT_CONTRACT}} and {{SERIALIZED_INTENT}} placeholders in the template with the strings serialized in the previous step according to their content. After the replacement is completed, a complete final prompt template containing all the specific context information is obtained.

[0056] Finally, the process of inputting the final prompt template into a large language model to generate the code is performed in step 43. The large language model is a deep learning model based on the Transformer architecture, using a decoder-decoder or only decoder structure, and pre-trained on a massive corpus of text and code. Its core architecture consists of multiple layers of stacked Transformer modules, each containing a multi-head self-attention mechanism and a feed-forward neural network. The weights and biases of these models are learned from data during the pre-training phase through unsupervised learning, enabling them to have a deep understanding of natural language and programming language. They can further improve their performance by fine-tuning on specific task data. The processing process is as follows: First, the final prompt template string generated in the previous step is tokenized, i.e., converted into a sequence of numerical identifiers. Then, this sequence is input into the large language model. The model captures long-range dependencies between various parts of the prompt through its multi-head self-attention mechanism, such as associating the intent of user discount with the discountRate field in the input contract and the discountApplied field in the output contract. After a deep semantic understanding of the entire input prompt, the model begins to generate tokens of the output code in a self-recursive manner. Each generated token is used as new context to predict the next most likely token. This generation process continues until the model produces a special token indicating the end of the sequence.Finally, the generated token sequence is reversed to convert back to a text string, and the required code snippet is obtained. The generated code is the final output, which accurately uses the data defined in the input contract, implements the calculation logic described by the user's intent, and generates an object that fully complies with the structure of the completed output contract, such as: "const orderData = input.node_A; const discountData = input.node_D; let totalOriginalPrice = 0; for (const item of orderData.items) { totalOriginalPrice += item.price * item.quantity;} const discountRate = discountData.discountRate || 0; const discountApplied = totalOriginalPrice * discountRate; const finalAmount = totalOriginalPrice - discountApplied; return { orderId: orderData.orderId, finalAmount: finalAmount, shippingAddress: orderData.customerInfo.address, discountApplied: discountApplied, itemsDetail: orderData.items};". This code calculates the final payment amount of an order based on the input order data and discount information. First, it iterates through all the items in the order, multiplies the price of each item by the quantity, and accumulates the total original price. Then, it obtains the discount rate from the discount information (if none, it is considered as 0), calculates the actual discount amount, and deducts it from the original total price to obtain the final payment amount. Finally, it returns a structured order result containing the order number, final amount, shipping address, discount amount, and item details, which can be used for subsequent payment, delivery, or record processes.

[0057] In step 5, static code analysis and contract verification are performed on the generated code and node data contract specification objects to obtain verification results. Correspondingly, although the large language model generates code based on a highly structured specification object, its inherent probabilistic nature means that the generated results cannot guarantee 100% accuracy and compliance. Directly integrating the generated code into the business process carries the risk of introducing syntax errors or potential contract violations, which may lead to runtime failures. Therefore, this application establishes an automated quality assurance checkpoint before code execution by performing static code analysis and contract verification on the generated code and node data contract specification objects. This rigorously reviews the syntactic correctness of the code and its adherence to predefined data contracts in a programmatic manner, ensuring that only verified and reliable code is ultimately adopted.

[0058] In one feasible solution, Figure 5 This is a flowchart of step 5 in the AI-assisted low-code platform construction method according to an embodiment of this application. Figure 5 As shown, step 5 involves performing static code analysis and contract verification on the generated code and node data contract specification object to obtain verification results. This includes: step 51, using a code parser to convert the generated code into an abstract syntax tree; step 52, based on the aggregated input contract in the node data contract specification object, performing input contract compliance verification on the abstract syntax tree to obtain an input breach report; and step 53, based on the constructed output contract in the node data contract specification object, performing output contract compliance evaluation on the abstract syntax tree to obtain an output compliance report.

[0059] In the above scheme, step 5 can be implemented as follows: First, perform step 51 to convert this human-readable text code into a tree data structure that is convenient for programmatic structural analysis and traversal using a code parser. A code parser is a program that follows the syntax specifications of a specific programming language (in this case, JavaScript). It reads the source code string and performs lexical analysis (breaking it down into a series of meaningful units called tokens) and syntax analysis (organizing tokens into a hierarchical structure according to the language's grammar rules). Specifically, first, according to the scripting language adopted by the low-code platform, select a corresponding code parser that conforms to industry standards (such as the ESTree specification), for example, acorn or esprima. Then, call the core parsing method of the parser and pass the code string to be processed as a parameter. After receiving the code string, the parser starts reading from the beginning character by character and processes it according to the syntax rules of JavaScript. For example, when it reads the line const orderData=input.node_A; it recognizes that const is a keyword, orderData is an identifier, = is an assignment operator, input.node_A is a member expression, and';'is a statement terminator. Based on these recognitions, it constructs a tree node representing a variable declaration. The node contains child nodes representing the type of variable (constant), variable name, and value assigned to it (a member expression node). This process is recursively applied to the entire code string until all code is represented as tree nodes and branches. If the code is completely correct in syntax, the parser will successfully complete its task and output a complete abstract syntax tree object. This object is a complex, nested JSON structure that accurately reflects the logical structure of the original code. For example, for the line const orderData=input.node_A; the corresponding abstract syntax tree fragment may look like this: {"type":"VariableDeclaration","declarations":[{"type":"VariableDeclarator","id":{"type":"Identifier","name":"orderData"},"init":{"type":"MemberExpression","object":{"type":"Identifier","name":"input"},"property":{"type":"Identifier","name":"node_A"}}}],"kind":"const"}.If, on the other hand, the generated code contains a syntax error (e.g., a missing parenthesis or an invalid keyword), the parser will fail to match any valid syntax rule during the process, and it will throw an exception. The exception will be caught and wrapped into a structured parse error object. This error object will contain detailed error information, such as the error description, the line and column number where the error occurred. In this case, the parse error object will be the output of this step, and the subsequent contract verification process will be terminated, with the error result being directly used for the final verification verdict.

[0060] Next, the input contract compliance check is performed on the abstract syntax tree in step 52. First, a set of legal access paths is generated based on the aggregated input contract. This set is used to store the full path strings of all data fields that are allowed to be read in the code. The handler recursively parses the input contract JSON object. In this embodiment, the input contract contains two top-level keys, node_A and node_D. The parser starts from a preset root object name, such as input, and traverses each level in the contract. For the orderId field under node_A, its legal path is input.node_A.orderId. For nested objects, such as the userId under customerInfo, its path is input.node_A.customerInfo.userId. For arrays, such as items, its path is input.node_A.items, and since array elements can be accessed in loops, the paths of their internal elements are also generalized, for example, input.node_A.items[].productId. After the complete parsing of the entire input contract, a set containing all legal path strings is generated, for example: {"input.node_A.orderId", "input.node_A.items", "input.node_A.items[].productId", "input.node_A.items[].quantity", "input.node_A.items[].price", "input.node_A.customerInfo.userId", "input.node_A.customerInfo.address", "input.node_D.userId", "input.node_D.discountRate"}. Next, a depth-first traversal of the abstract syntax tree object is performed. The traverser visits each node in the tree to check its type and content. During the traversal, the check logic focuses on identifying all nodes representing data read operations. In the abstract syntax tree of JavaScript, such operations are mainly represented by MemberExpression (member expression, such as a.b or a[b]) and Identifier (identifier, when it is read as a variable) types of nodes. When the traverser visits a MemberExpression node, such as orderData.items in the code, the check program starts from this node and backtracks its parent nodes in the syntax tree to reconstruct its full access path in the code.Since the variable orderData is assigned to input.node_A in the code, the program can resolve orderData.items to its original, full path relative to the root input object, input.node_A.items, through the symbol table or simple variable substitution logic. Similarly, for discountData.discountRate, it will be resolved to input.node_D.discountRate. After reconstructing the full path string for each data access, it will immediately be compared against the set of legal access paths generated earlier. If the reconstructed path string, such as input.node_A.items, exists in the set of legal paths, the access is considered legal and the verification continues. If the path does not exist in the set, it means that the code is trying to access a variable or attribute that is not defined in the input contract. For example, if the generated code has a typo and writes orderData.customer_info.address (with customerInfo misspelled as customer_info), the reconstructed path input.node_A.customer_info.address will not be found in the set of legal paths. At this point, the verification program will create a violation record object. This object will contain detailed error information, such as {path: "input.node_A.customer_info.address", line: 5}, where the path field records the illegal access path and the line field records the line number in the original code where the illegal access is located. This location information can be obtained from the loc attribute of the abstract syntax tree node. This violation record object will be added to a list called the input violation report. The traversal process will continue until all nodes in the abstract syntax tree have been visited. At the end of the traversal, the final input violation report list is the output. If the generated code fully complies with the input contract, this list will be empty. If there are any illegal data accesses, the list will contain all the violation records found. In this example, since the generated code is correct, the final output of the input violation report is an empty list, []. This report will be passed to the subsequent validation decision-making stage as an important basis for evaluating the quality of the code.

[0061] Finally, the output contract compliance assessment is performed in step 53. First, the processing program locates the ReturnStatement node in the input abstract syntax tree object in the code logic block. By traversing the syntax tree, the node representing the code return {...}; is found. Once located, the program further parses the argument of the ReturnStatement node, which is an ObjectExpression node representing the returned JavaScript object literal. Next, by traversing the properties list of the ObjectExpression node, the actual data schema returned by the code, i.e., the actual schema, is constructed. For each property node in the list, the program extracts the name of its key, which is a string. At the same time, the program analyzes the node type of its value to infer the data type of the field. For example, if the value node is an Identifier, such as finalAmount, the program traces back to find the declaration of the identifier and infers its type as number by analyzing its assignment source, such as totalOriginalPrice - discountApplied, which is a subtraction of two numbers. If the value node is a MemberExpression, such as orderData.items, the program traces back to the source of orderData and infers its type as array by combining the input contract. By analyzing all the properties in the returned object, an actual schema object representing the actual output structure of the code is finally constructed. In this embodiment, the actual schema constructed is: {orderId: "string", finalAmount: "number", shippingAddress: "string", discountApplied: "number", itemsDetail: "array"}. At the same time, the processing program extracts the expected schema from the input built output contract. The expected schema defines the data structure that the code should return. According to the output of step 3.2, the expected schema is: {orderId: "string", finalAmount: "number", shippingAddress: "string", discountApplied: "number", itemsDetail: "array"}. After obtaining the actual schema and the expected schema, the compliance calculation begins. The calculation process is divided into several parts. First, the key set Keys_actual of the actual schema and the key set Keys_expected of the expected schema are extracted, respectively.In this example, both sets are {"orderId", "finalAmount", "shippingAddress", "discountApplied", "itemsDetail"}. Then, the similarity on structure, i.e. Jaccard similarity coefficient J, is calculated. This coefficient is calculated by dividing the size of the intersection of the two key sets by the size of the union. The formula is J = |Keys_actual∩Keys_expected| / |Keys_actual∪Keys_expected|. In this example, the size of the intersection and the union are both 5, so J = 5 / 5 = 1.0. Next, the type matching degree T is calculated. This calculation is only done for the keys in the intersection of the two key sets. For each key k in the intersection, the program compares its data type in the actual schema and the expected schema. If they are the same, the indicator function I returns 1, otherwise it returns 0. The sum of the indicator function results for all intersection keys is divided by the total size of the intersection, which gives the type matching degree. The formula is T = (ΣI(Type(k)_actual==Type(k)_expected)) / |K|, where K is the intersection. In this example, the types of all 5 common keys are perfectly matched, so T = (1+1+1+1+1) / 5 = 1.0. Finally, the final compliance score C is calculated. This score is a weighted average of the structure similarity J and the type matching degree T, with the formula C = α*J+β*T. The weights α and β are pre-set parameters that adjust the importance of structure and type in the final score, and α+β=1. For example, one can set α=0.6 and β=0.4, indicating that the structure completeness is slightly more important than the type matching. In this example, the final compliance score is C = 0.6 *1.0+0.4*1.0 = 1.0. After calculating the compliance score, the program compares it with a pre-set threshold τ. This threshold τ, which is set to 0.95 for example, is an empirical value determined based on the platform's requirements for code quality and experiments on a large number of test cases, and is used to determine whether the generated code is good enough to be accepted. At the same time, the program also generates a specific difference report. This report is obtained by set operations: the missing key set is Keys_expected-Keys_actual, the redundant key set is Keys_actual-Keys_expected. For type-mismatched keys, those indicator functions that are 0 and their type-mismatched type pairs are recorded when calculating T. Finally, the calculated compliance score C, the pre-set threshold τ, and the difference report containing missing keys, redundant keys, and type-mismatched keys are packaged into a JSON object, which is the output compliance report.In this embodiment, since the code fully complies with the contract, the report can be as follows: {"score": 1.0, "threshold": 0.95, "diff": {"missing_keys": [], "extra_keys": [], "mismatched_types": []}}.

[0062] To further illustrate the verification process, a non-ideal scenario with missing keys is listed here. If the code generated by the large language model misses the shippingAddress field in its returned object, then the key set Keys_actual of the actual schema constructed through the above process will become {"orderId", "finalAmount", "discountApplied", "itemsDetail"}. In this case, when compared with the key set of the expected schema, the size of the intersection is 4 and the size of the union is 5, so the structural similarity J will be calculated as 4 / 5=0.8. If the types of the remaining 4 fields are all matched, the type matching degree T will still be 4 / 4=1.0. The final compliance score C will be 0.6*0.8+0.4*1.0=0.88. This score is lower than the preset threshold 0.95, indicating that the verification has failed. At the same time, the missing_keys list in the difference report will be obtained by set subtraction operation ["shippingAddress"]. The final generated output compliance report will accurately reflect this result, and its content is {"score": 0.88, "threshold": 0.95, "diff": {"missing_keys": ["shippingAddress"], "extra_keys": [], "mismatched_types": []}}, thus providing a clear and quantitative failure reason for subsequent decision-making.

[0063] After completing the independent static analysis of the generated code in the three dimensions of syntax, input and output, a series of scattered and original verification reports are obtained. These reports themselves cannot directly drive the subsequent business process decision-making, and a final arbitration mechanism is needed to comprehensively judge them. Therefore, the step of executing verification arbitration is to collect all the results of the previous analysis and make a final, binary pass or fail conclusion according to a set of clear and unified rules. The complex, multi-dimensional verification information is converted into a simple and clear decision signal, providing the final basis for automatically accepting or rejecting the AI-generated code.

[0064] In particular, scenario one: verification pass, in this scenario, the success result of the previous example is taken as input. Specifically, the input parse error is empty, the input input violation report is an empty list [], and the input output compliance report is a JSON object with content {"score": 1.0, "threshold": 0.95, "diff": {...}}. When the adjudication process starts, it first initializes an empty list to collect error information, denoted as errorMessages. Subsequently, the adjudication logic performs a series of checks in order. The first check is the parse error: since the input parse error is empty, this check passes, and the errorMessages list remains empty. The second check is the input violation: the adjudication logic checks the input violation report and finds that it is an empty list, indicating that no illegal data access has been found, so this check also passes, and the errorMessages list remains empty. The third check is the output compliance: the adjudication logic extracts the compliance score 1.0 and the preset threshold 0.95 from the output compliance report. It compares the two and finds that the score 1.0 is not lower than the threshold 0.95, so this check also passes, and the errorMessages list continues to remain empty. After completing all checks, it enters the final decision stage. The adjudication logic judges whether the errorMessages list is empty. In this scenario, the list is empty, so the final decision is verification pass. As a result of this decision, the original code string generated by the large language model is output as the verification pass code.

[0065] Scenario Two: Verification Failure. In this scenario, the non-ideal case mentioned in the previous embodiment, where there is an output contract violation, is taken as input. Specifically, the input has an empty parse error, an empty input violation report, but an output compliance report of {"score": 0.88, "threshold": 0.95, "diff": {"missing_keys": ["shippingAddress"], "extra_keys": [], "mismatched_types": []}}. The adjudication process starts with an empty errorMessages list as before. The first two checks (parse error and input violation) have the same results as in Scenario One, and the errorMessages list remains empty. However, when the third check, the output compliance check, is performed, the adjudication logic finds that the score of 0.88 is below the threshold of 0.95. This condition triggers the error recording operation. The adjudication logic further parses the diff object in the report and finds that the missing_keys list contains one element, "shippingAddress". It formats this structured discrepancy information into a human-readable error message, such as "Output contract mismatch: the returned object is missing the required field'shippingAddress'.", and adds this message to the errorMessages list. After all checks are completed, the final decision phase is entered. At this point, the adjudication logic examines the errorMessages list and finds that it is no longer empty. Therefore, the final decision is verification failure. As a result of this decision, the errorMessages list is packaged into a structured verification error information object for output. This object can be directly consumed by the frontend user interface to clearly show the user the specific reasons for the code generation failure, guiding the user to correct the intent description or the process design.

[0066] In step 6, in response to the verification result being verification passed, the generated code is associated with the target node ID. That is, after generating the code and passing a series of rigorous static analysis and verification, the code snippet has been proven to be syntactically correct and strictly comply with the data contract. However, at this time it is still a temporary product independent of the actual running environment of the low-code platform. Without subsequent operations, this successful code generation will be meaningless. Therefore, the present application associates the generated code with the target node ID in response to the verification passing, to formally and persistently integrate the verified and high-quality code into the definition of the business process, and broadcast its data output capability to the entire process, thereby completing the closed loop from requirement to functional implementation, and ensuring the data consistency of the entire business process at design time and runtime.

[0067] In one implementation, step 6 can be implemented as follows: first, perform the operation of persistently storing the validated code and associating it with the target node ID. In the background data store of the low-code platform, each node of a business process graph, such as node_B, corresponds to a record or a document. The record contains various attributes of the node, one of which is used to store the execution logic of the node. The handler receives the validated code string, then accesses the data store, locates the node record with ID node_B, and updates the value of the field used to store the execution logic, such as the logicScript field, to be this new code string. After this operation is completed, the AI-generated code has officially become the implementation of the total price calculation node's functionality, and when the business process is executed, this piece of code will be invoked.

[0068] Next, perform the operation of updating the target node's output schema. In order to maintain data consistency across the entire platform and provide accurate context for the development of other nodes, node_B's output data schema needs to be registered or updated in the node schema repository. The handler will determine node_B's final output schema based on the built and validated output contract constructed in step 3. The output contract JSON Schema object will be extracted and written or updated in the node schema repository with node_B as the key. For example, the following JSON Schema will be stored in the repository associated with node_B: {"type":"object","properties":{"orderId":{"type":"string"},"finalAmount":{"type":"number"},"shippingAddress":{"type":"string"},"discountApplied":{"type":"number"},"itemsDetail":{"type":"array"}}}. This ensures that node_B's data output has a clear, static definition that can be queried and used by other parts of the platform.

[0069] Finally, a notification operation of performing downstream node context update is executed. After the output mode of node_B is successfully updated, in order to ensure the continuity of data flow which can also be embodied in design, an internal event notification mechanism is triggered. This update operation will automatically publish a node mode change event, and the event content contains the ID of the updated node, that is, node_B. The module responsible for listening to such events in the platform will capture the event, and according to the topology structure of the business process diagram, identify all downstream nodes that take node_B as the upstream input, that is, node_C and node_E in this embodiment. Subsequently, the module will push a notification to the front-end visual editor, or update a shared state cache to indicate that the upstream data source of node_C and node_E has changed. In this way, when the user next selects the delivery notification generation node, that is, node_C in the editor and tries to configure its input data mapping, the platform will be able to show the user a complete and accurate list of available input fields based on the latest output mode of node_B in the node mode repository, thereby greatly improving the development experience and the accuracy of data configuration.

[0070] In summary, the AI-assisted low-code platform building method based on the embodiments of the present application is illustrated, which introduces a mechanism of first contract and then generation to solve the context missing problem in AI code generation. Before requesting the large language model to generate code, first, the business process diagram is topologically analyzed to accurately identify the upstream data source and downstream data destination of the target node. Based on this dependency relationship, a structured node data contract specification object is automatically constructed, which clearly defines the input data mode that the target node must follow and the output data mode that should be generated. Subsequently, this contract object is provided to the large language model as a strong constraint context to guide it to generate code that meets the data flow requirements, and the compliance is ensured through the final contract verification. This method changes the AI generation process from blind guessing to contract compliance, solves the problem of mismatching of node data contracts caused by lack of global perception, and guarantees the connectivity and reliability of the entire business process. Figure One

[0071] Figure 6 A block diagram of the AI-assisted low-code platform building system according to the embodiments of the present application is provided. As shown in FIG. 1, the system includes a business process diagram 101, a node mode repository 102, a contract specification object 103, a large language model 104, a contract verification module 105, and a platform module 106. Figure 6 ​As shown, the AI-assisted low-code platform building system 100 according to the embodiment of the present application comprises: a user information acquisition module 110 configured to acquire a business process diagram input by a user and a target node ID specified by the user; a business process diagram analysis module 120 configured to perform business process diagram analysis and dependency relationship extraction on the business process diagram and the target node ID to obtain an upstream node list and a downstream node list; a canonical object generation module 130 configured to generate a node data contract canonical object based on the upstream node list, the downstream node list, and a node mode library; a code generation module 140 configured to input the node data contract canonical object into a large language model to obtain generated code; a verification module 150 configured to perform code static analysis and contract verification on the generated code and the node data contract canonical object to obtain a verification result; and an association module 160 configured to associate the generated code with the target node ID in response to the verification result being passed.

[0072] Here, those skilled in the art can understand that the specific operations of each step in the above AI-assisted low-code platform building system have been described in detail above with reference to the description of the AI-assisted low-code platform building method of Figures 1 to 5 the above, and therefore, the repeated description thereof will be omitted.

Claims

1. An AI-assisted low-code platform building method, characterized in that, The method comprises the following steps: obtaining a business process diagram input by a user and a target node ID specified by the user; performing business process diagram analysis and dependency relationship extraction on the business process diagram and the target node ID to obtain an upstream node list and a downstream node list; generating a node data contract specification object based on the upstream node list, the downstream node list and a node schema library, wherein the node schema library is a repository for centrally managing input and output data schemas of all configured nodes in a low-code platform, and the node data contract specification object is a structured object that clearly defines an input data schema that must be followed by the target node and an output data schema that should be generated by the target node; inputting the node data contract specification object into a large language model to obtain generated code; performing code static analysis and contract verification on the generated code and the node data contract specification object to obtain a verification result, wherein the contract verification comprises converting the generated code into an abstract syntax tree, and performing input data access path legality checking and output data structure conformity evaluation on the abstract syntax tree based on the node data contract specification object; in response to the verification result being a verification pass, associating the generated code with the target node ID.

2. The AI assistance based low code platform building method according to claim 1, characterized in that, The method of performing business process diagram analysis and dependency relationship extraction on the business process diagram and the target node ID to obtain an upstream node list and a downstream node list comprises the following steps: traversing all directed edges in the business process diagram to filter out all edges ending with the target node ID to obtain the upstream node list; traversing all directed edges in the business process diagram to filter out all edges starting with the target node ID to obtain the downstream node list. 3.The AI assistance based low code platform building method of claim 1, wherein, The method of generating a node data contract specification object based on the upstream node list, the downstream node list and the node schema library comprises the following steps: based on the node schema library, performing upstream input contract aggregation on the upstream node list to obtain an aggregated input contract, specifically comprising querying the node schema library with each upstream node ID in the upstream node list as a key to obtain an upstream node output schema set, and aggregating the set to form an aggregated input contract defining a data structure that the target node is allowed to read; based on the node schema library, performing downstream output contract inference and construction on the downstream node list and a user intent description to obtain a constructed output contract, specifically comprising querying the node schema library with each downstream node ID in the downstream node list as a key to obtain an input schema required by a downstream node, and inferring a suggested output schema based on the user intent description, and merging to form a constructed output contract defining a data structure that the target node must output; performing object assembly on the aggregated input contract, the constructed output contract and the user intent description to generate a node data contract specification object containing input constraints, output constraints and business intent information.

4. The AI assistance based low code platform building method of claim 3, wherein, The method of performing upstream input contract aggregation on the upstream node list based on the node schema library to obtain an aggregated input contract comprises the following steps: querying the node schema library with each upstream node ID in the upstream node list as a key to obtain a pre-defined output data schema of each upstream node, and forming an upstream node output schema set; Index and integrate all data patterns in the upstream node output pattern set according to the upstream node ID to generate a unified JSON format object as the aggregated input contract, which clearly shows the data field name, data type and hierarchical structure received by the target node from each upstream node. 5.The AI assistance based low code platform building method according to claim 3, characterized in that, Based on the node schema library, the downstream output contract inference and construction are performed on the downstream node list and the user intent description to obtain the constructed output contract, including: Query the node schema library with each downstream node ID in the downstream node list as the key to obtain the pre-defined input pattern of each downstream node, and combine all the input patterns to obtain the required pattern; In response to the required pattern being empty or the field being incomplete, implicit requirement inference is performed based on the user intent description and the downstream node list to obtain a suggested pattern, the implicit requirement inference including extracting candidate fields from the user intent description, and evaluating the relevance of the candidate fields to the user intent and the necessity for the downstream node type to filter out high-score candidate fields and their inferred types to constitute the suggested pattern; The required pattern and the suggested pattern are combined to remove duplicate fields and unify field definitions to obtain the constructed output contract.

6. The AI assistance based low code platform building method of claim 5, wherein, In response to a required pattern being empty or a field being incomplete, an implicit requirement inference is performed based on the user intent description and the downstream node list to obtain a suggested pattern, including: In response to a required pattern being empty or a field being incomplete, an implicit requirement inference is performed based on the user intent description and the downstream node list to obtain a suggested pattern using the following formula: ;in, As key, The type is The output fields, and For configurable weights, For user intent description, It is a collection of all node types in the downstream node list. For evaluation With user intent description correlation function For evaluation For the set of downstream node types The necessary function, For a reasonable value, when When it exceeds the preset threshold, and its inference types Include the recommended model.

7. The AI assistance based low code platform building method according to claim 1, wherein, Inputting the node data contract specification object into a large language model to obtain generated code, including: Serializing the node data contract specification object to obtain a serialized node data contract specification object; Embedding the serialized node data contract specification object into a user prompt word template to obtain a final prompt word template; Inputting the final prompt word template into a large language model to obtain generated code. 8.The AI assistance based low-code platform building method of claim 1, wherein, Performing code static analysis and contract verification on the generated code and the node data contract specification object to obtain a verification result, including: Using a code parser to convert the generated code into an abstract syntax tree; Based on the aggregated input contract in the node data contract specification object, performing input contract compliance verification on the abstract syntax tree to obtain an input violation report, specifically including: generating a set of legal access paths according to the aggregated input contract; performing a depth-first traversal on the abstract syntax tree to identify all nodes representing data read operations and reconstructing the complete path string of each data access; comparing the reconstructed complete path string with the set of legal access paths, if the complete path string does not exist in the set of legal access paths, creating a violation record object and adding it to the input violation report; Based on the constructed output contract in the node data contract specification object, performing output contract compliance evaluation on the abstract syntax tree to obtain an output compliance report, specifically including: locating the return statement node in the abstract syntax tree, parsing the object expression node in the return statement node to construct an actual pattern; extracting the expected pattern from the constructed output contract; calculating the structural similarity and type matching degree between the actual pattern and the expected pattern, and calculating the weighted average of the structural similarity and type matching degree to obtain a compliance score; comparing the compliance score with a preset threshold, and generating a difference item report to obtain the output compliance report.

9. An AI-assisted low-code platform building system, characterized in that, including: A user information acquisition module is configured to acquire a business process diagram input by a user and a target node ID specified by the user. A business process diagram analysis module is configured to perform business process diagram analysis and dependency relationship extraction on the business process diagram and the target node ID to obtain an upstream node list and a downstream node list. A schema object generation module is configured to generate a node data contract schema object based on the upstream node list, the downstream node list, and a node schema library, wherein the node schema library is a resource library for centrally managing input and output data schemas of all configured nodes in a low-code platform, and the node data contract schema object is a structured object that clearly defines an input data schema that a target node must follow and an output data schema that should be generated. A code generation module is configured to input the node data contract schema object into a large language model to obtain generated code. A verification module is configured to perform code static analysis and contract verification on the generated code and the node data contract schema object to obtain a verification result, wherein the contract verification includes converting the generated code into an abstract syntax tree and performing input data access path legality checking and output data structure conformity evaluation on the abstract syntax tree based on the node data contract schema object. An association module is configured to associate the generated code with the target node ID in response to the verification result being a verification pass.

Images