AI-assisted code generation method and system applied to low-code platform

Abstract

The application provides an AI-assisted code generation method and system applied to a low-code platform, relates to the technical field of low-code platforms, and first acquires component requirement scenario information and analyzes to obtain a scene feature set, generates a dynamic evolution rule set in combination with platform real-time metadata; then calls an AI code generation module, inputs the scene feature set and the rule set, and generates initial component code; next, the initial code is deployed to a test environment, running data is collected and analyzed, iteration optimization instructions are generated to adjust the code and the rule set, and target component code is obtained; finally, the target code is embedded into a platform specified function module to complete code generation. The method can adapt to diversified scene requirements, combines with the real-time state of the platform, has self-optimization capability, and can improve the development efficiency and code quality of the low-code platform.

Description

Technical Field

[0001] This invention relates to the field of low-code platform technology, and more specifically, to an AI-assisted code generation method and system applied to low-code platforms. Background Technology

[0002] In the current era of rapid development of low-code platforms, code generation is a crucial step in improving development efficiency and lowering the development threshold. Traditional low-code platform code generation methods have several shortcomings. Firstly, code generation relies heavily on pre-defined fixed templates, which often fail to fully cover the diverse and complex needs of various component requirements. Different users have diverse needs for component application scenarios. For example, in e-commerce platform product display components, some users want to highlight product images, while others focus more on displaying product prices and promotional information. Fixed templates cannot flexibly adapt to these differentiated scenario requirements. Secondly, existing methods lack effective consideration of the real-time state of the low-code platform when generating code. Low-code platforms are constantly updating and evolving; their metadata changes with version upgrades and feature expansions. However, traditional methods fail to incorporate this real-time metadata into the code generation process, leading to compatibility issues or inability to fully utilize the platform's latest features on newer versions. Furthermore, traditional methods lack effective testing and optimization mechanisms after code generation. The generated code may have functional defects, unreasonable resource consumption, and cannot be adjusted and optimized in a timely manner based on actual operating conditions, thus affecting code quality and reliability. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide an AI-assisted code generation method applied to a low-code platform, the method comprising:

[0004] Obtain the component requirement scenario information of the low-code platform, and parse the scenario feature set based on the component requirement scenario information to obtain the scenario feature set. The component requirement scenario information includes scenario description information, operation sequence information and adaptation benchmark information. The scenario description information comes from the user's text description of the component application scenario. The operation sequence information comes from the user's component operation record in the visual interface. The adaptation benchmark information comes from the version adaptation manual of the low-code platform.

[0005] By combining the real-time metadata of the low-code platform, the scene feature set is matched and dynamically adjusted according to rules to generate a dynamic evolution rule set, which includes attribute mapping rules, logic compilation rules and adaptation calibration rules.

[0006] The AI ​​code generation module is invoked, taking the scene feature set and the dynamic evolution rule set as input. The scene features are converted into code structure units by the scene syntax conversion unit of the AI ​​code generation module, and then the code structure units are logically completed and grammatically adapted by the rule execution unit to generate the initial component code.

[0007] The initial component code is deployed to the test environment of the low-code platform. Functional operation data, resource consumption data, and version compatibility data of the initial component code in the test environment are collected. Based on the matching analysis results of the functional operation data, resource consumption data, version compatibility data, and the scene feature set, iterative optimization instructions are generated. The initial component code and the dynamic evolution rule set are adjusted through the iterative optimization instructions to obtain the optimized target component code.

[0008] The target component code is embedded into a designated functional module of the low-code platform. The determination of the designated functional module is based on the functional scene positioning features in the scene feature set, thereby completing the AI-assisted code generation.

[0009] Furthermore, embodiments of the present invention also provide an AI-assisted code generation system applied to a low-code platform, comprising:

[0010] A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described AI-assisted code generation method for a low-code platform by executing the machine-executable instructions.

[0011] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, a processor of a computer device reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the computer device to execute the above-described AI-assisted code generation method applied to a low-code platform.

[0012] Based on the above, by acquiring and parsing scenario-based information about component requirements from the low-code platform to obtain a set of scenario features, we can capture the diverse needs of users for components in different scenarios. Then, by combining the real-time metadata of the low-code platform, we can perform rule matching and dynamic adjustment on the set of scenario features to generate a dynamic evolution rule set. This ensures that the generated rules keep up with the platform's real-time changes, guaranteeing close adaptation between code generation and platform status, and effectively avoiding code compatibility issues caused by platform updates. By calling the AI ​​code generation module, which uses scenario syntax conversion and rule execution units to convert scenario features into code structure units and perform logic completion and syntax adaptation, we can efficiently and accurately generate initial component code, improving the efficiency and quality of code generation. Deploying the initial component code to the test environment and collecting relevant data, we can generate iterative optimization instructions based on the matching analysis between the data and the set of scenario features. This adjusts the initial component code and the dynamic evolution rule set, achieving self-optimization and iterative upgrades of the code, continuously improving the code's functional completeness, resource utilization efficiency, and version compatibility. Finally, the optimized target component code was embedded into the specified functional module of the low-code platform, completing the entire process from requirement acquisition to code generation and optimization, which significantly improved the development efficiency and code quality of the low-code platform. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the execution flow of the AI-assisted code generation method applied to a low-code platform provided in an embodiment of the present invention.

[0014] Figure 2 This is a schematic diagram of exemplary hardware and software components of an AI-assisted code generation system applied to a low-code platform, provided in an embodiment of the present invention. Detailed Implementation

[0015] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating an AI-assisted code generation method for low-code platforms according to an embodiment of the present invention. The following is a detailed description of this AI-assisted code generation method for low-code platforms.

[0016] Step S110: Obtain the component requirement scenario information of the low-code platform, and parse the scenario feature set based on the component requirement scenario information to obtain the scenario feature set. The component requirement scenario information includes scenario description information, operation sequence information and adaptation benchmark information. The scenario description information comes from the user's text description of the component application scenario. The operation sequence information comes from the user's component operation record in the visual interface. The adaptation benchmark information comes from the low-code platform's version adaptation manual.

[0017] Step S111: Receive the component application scenario text description submitted by the user through the scenario input interface of the low-code platform, perform semantic unit splitting on the component application scenario text description, and split the text description into multiple scenario description statements according to Chinese semantic logic. Each scenario description statement corresponds to a functional requirement of the component in a specific scenario.

[0018] After receiving the user-submitted text description of the component application scenario, the low-code platform's scenario input interface backend receives the text data and passes it to the semantic processing module. The semantic processing module first preprocesses the text, including removing redundant spaces and special characters and standardizing line break formatting. The preprocessed text then enters the word segmentation stage, using a dictionary-based forward maximum matching word segmentation algorithm. The dictionary includes general Chinese vocabulary and specialized terminology from the low-code platform's component development field. During word segmentation, starting from the beginning of the text, the longest possible word is selected as a segmentation result, continuing until the end of the text, resulting in a segmented word sequence.

[0019] Next, semantic unit decomposition is performed. Based on Chinese semantic logic, the word segmentation result sequence is input into the syntactic analyzer. The syntactic analyzer uses dependency parsing to analyze the dependency relationships between words and identify basic grammatical units such as subject-predicate structures and verb-object structures. Simultaneously, a punctuation mark recognizer locates and marks periods, commas, and semicolons in the text, comparing the marking results with the grammatical unit boundaries obtained from the syntactic analysis. Periods are used as the primary decomposition boundary; when a period is encountered, the text preceding it is divided into an independent semantic unit. Commasms and semicolons serve as auxiliary decomposition boundaries; when the grammatical units before or after a comma or semicolon belong to different functional requirement descriptions, they are divided into different semantic units. Each semantic unit corresponds to a scenario description statement candidate, and each candidate statement theoretically corresponds to a functional requirement of the component in a specific scenario.

[0020] Step S112: Identify punctuation marks in the text description of the application scenario of the component. The punctuation marks include period, comma and semicolon. The period is used as the main split boundary of the scenario description statement, and the comma and semicolon are used as auxiliary split boundaries.

[0021] In the application scenario of this component, the text description is converted into a character stream and input into a punctuation mark recognizer. The punctuation mark recognizer internally maintains a set of punctuation marks, including periods, commas, and semicolons. The recognizer scans the character stream character by character, comparing the current character with elements in the punctuation mark set. If a match is found, the recognizer records the type of the punctuation mark and its position index in the text.

[0022] After scanning, a list of punctuation marks is obtained, where each element contains the punctuation mark type and position index. Different splitting priorities are assigned based on the punctuation mark type, with the period having the highest priority and serving as the primary splitting boundary for scene description statements. The list of punctuation marks is traversed; when a period is encountered, the text from the end of the previous split to the current period position is identified as the boundary of a scene description statement. Commas and semicolons have lower priority than periods and serve as auxiliary splitting boundaries, used only within text segments between periods. For text segments between two periods, the comma and semicolon positions are traversed again. Based on the semantic logic within the text segment, it is determined whether the comma or semicolon separates different functional requirement descriptions. If so, the comma or semicolon is used as a splitting point to further split the text segment into multiple candidate scene description statements.

[0023] Step S113: When a period is detected, the text content before and after it is divided into independent scenario description statement candidates. When a comma is detected and the functional requirements described by the text before and after it belong to different scenario dimensions, the text before and after the comma is divided into independent scenario description statement candidates. When a semicolon is detected and the functional steps described by the text before and after it have a sequential order, the text before and after the semicolon is divided into independent scenario description statement candidates.

[0024] During the punctuation mark position list processing, when a period is detected, the main splitting logic is triggered. In this embodiment, the position index of the period is recorded, and the text content from the start position or after the previous period position to before the current period position is extracted as an independent candidate for scene description statement. After extraction, the start position is updated to the next character position after the current period position, and subsequent punctuation marks are processed.

[0025] For comma processing, upon detection, the text segments before and after the comma are first retrieved, and then input into the scene dimension classifier. The scene dimension classifier is a pre-trained text classification model capable of classifying text segments into one of three scenarios: data processing, interface display, or interactive response. If the classification result indicates that the text segments before and after the comma belong to different scene dimensions, it is determined that the comma separates different functional requirement descriptions, and the text content before and after the comma is divided into two independent scene description statement candidates.

[0026] When a semicolon is detected, the text segments before and after the semicolon are retrieved. Semantic role annotation is performed on these two text segments to identify action verbs and time adverbs. By comparing the execution order of the action verbs and the sequence of the time adverbs, it is determined whether there is a sequential order in the functional steps described in the text before and after the semicolon. If a sequential order exists, the text content before and after the semicolon is divided into independent scene description statement candidates to ensure that each candidate statement corresponds to a complete functional step.

[0027] Step S114: Perform semantic integrity judgment on the segmented scenario description statement candidates, check whether each candidate statement contains a complete subject-verb-object structure. If the candidate statement lacks a subject, add a component as the default subject. If it lacks a predicate, add an implementation as the default predicate. If it lacks an object, add the corresponding functional object based on the context.

[0028] After the candidate scenario description statements are generated, the semantic completeness judgment process begins. Each candidate statement is input into the parser, which uses a probabilistic context-free grammar to perform syntactic structure analysis and generate a syntax tree. By traversing the nodes of the syntax tree, the subject, predicate, and object components in the statement are identified. If there is no subject node in the syntax tree, the candidate statement is determined to be missing a subject, and a "component" is selected from the preset subject candidate pool as the default subject and added to the beginning of the statement. If there is no predicate node in the syntax tree, the predicate is determined to be missing, and "implementation" is selected as the default predicate and inserted into the appropriate position of the statement to ensure grammatical fluency. If there is a predicate node in the syntax tree but no object node, or the object node is incomplete, the context information of the candidate statement is combined to extract the functional object that matches the predicate verb from the relevant scenario description statement candidates or the original text narrative, and supplement it to the object position to form a complete subject-verb-object structure.

[0029] Step S115: Check whether each candidate statement contains scenario limitation information. If the candidate statement lacks scenario limitation information, mark the general scenario and record the marking result.

[0030] Candidate statements that have passed the semantic integrity check are passed to the scenario limitation information checking module. This module first loads a scenario limitation word dictionary, which contains scenario limitation words such as application page names, user group identifiers, and operation condition phrases. A string matching algorithm is used to search for the presence of scenario limitation words from the dictionary in the candidate statements. If a scenario limitation word is found, its type and content are recorded as scenario limitation information. If no scenario limitation word is found, the candidate statement is determined to lack scenario limitation information, and a "general scenario" tag is added to it. The tagging results are stored in the candidate statement's metadata as key-value pairs, with the key being "scenario_limit" and the value being either the found scenario limitation information or the "general scenario" tag.

[0031] Step S116: Identify the candidate statements that are semantically complete and have scene-limiting tags as the final scene description statements, count the number of scene description statements, and assign a sequence number to each scene description statement according to the order of appearance in the text narrative.

[0032] After semantic integrity assessment and scene limitation information check, candidate scene description statements are filtered. The filtering criteria are: the statement has a complete subject-verb-object structure and carries scene limitation information markers or "general scene" markers. Candidate statements meeting these criteria are determined as the final scene description statements. In this embodiment, the original text is traversed, and the order in which these final scene description statements appear in the original text is recorded. Each statement is assigned a unique sequence number from beginning to end, starting from 1 and incrementing. The correspondence between sequence numbers and scene description statements is stored in an ordered list, where each element contains a sequence number and the corresponding scene description statement content.

[0033] Step S117: Establish a correspondence table between scene description statements and sequential numbers. In the subsequent feature extraction process, the corresponding scene description statement can be quickly located by sequential number, so that the scene features and the requirement descriptions are in one-to-one correspondence.

[0034] The mapping table is established using a relational database table structure, named "scene_description_mapping," and contains two fields: "sequence_number" and "description_text." The "sequence_number" field stores the sequence number, is an integer, and serves as the primary key; the "description_text" field stores the text content of the scene description statement, is a string. Data from the ordered list obtained in step S116 is inserted into this table one by one to complete the construction of the mapping table. In the subsequent feature extraction process, when a scene description statement is needed, the corresponding "description_text" content can be quickly retrieved from the table by querying the value of the "sequence_number" field, ensuring that scene feature extraction accurately correlates with the original requirement description statement.

[0035] Step S118: Extract scene keywords from each scene description statement, remove duplicates from the extracted scene keywords, and then classify them according to scene dimensions to form a scene keyword classification list. Use the scene keyword classification list as part of the scene description information. The scene keywords include scene object words, function action words, and environment limiting words. The scene dimensions include data processing scenarios, interface display scenarios, and interactive response scenarios.

[0036] Each scene description statement is input into a keyword extractor, which uses a combination of the TF-IDF and TextRank algorithms for keyword extraction. First, the statement is segmented and stop words are removed. The TF-IDF value and TextRank score for each word are calculated, and the two metrics are weighted and combined to obtain a comprehensive score for each word. A score threshold is set, and words with scores higher than the threshold are extracted as scene keywords. The extracted scene keywords are initially categorized into scene object words, function action words, and environment limiting words. Scene object words describe components or data entities; function action words describe component functions or operations; and environment limiting words describe the application environment or conditions.

[0037] After extraction, keywords from all scene description statements are aggregated into a temporary set, and duplicate keywords are removed using the set's deduplication feature. Then, the deduplicated keywords are input into a scene-dimensional classification model. This model, trained using a support vector machine algorithm, categorizes keywords into data processing, interface display, or interactive response scenarios based on their semantic features. After classification, a keyword classification list is created according to scene dimensions. Each scene dimension in the list contains corresponding scene object words, functional action words, and environment-specific words, forming a scene keyword classification list that serves as a core component of the scene description information.

[0038] Step S119: Collect the operation records performed by the user in the component visual editing interface of the low-code platform, mark the operation type and extract the operation parameters for each operation record, and form a detailed list of operation records. The operation records include component addition records, parameter configuration records, logical association records and preview test records.

[0039] The front-end framework of the component visual editing interface integrates an operation log collection module. This module listens for operation events of all components on the interface through an event delegation mechanism. When a user performs a component addition operation, the "addComponent" event is triggered. The event handler records the operation type as "component addition record" and extracts the operation parameters, including the type of the added component, the component ID, and the coordinates of the addition location. When a user performs a parameter configuration operation, the "configParam" event is triggered, recording the operation type as "parameter configuration record" and extracting parameters including the target component ID, the configured attribute name, and the new value of the attribute. When a user performs a logic association operation, the "linkLogic" event is triggered, marked as "logic association record," and the parameters include the source component ID, the target component ID, the associated event type, and the trigger condition expression. When a user performs a preview test operation, the "previewTest" event is triggered, with the operation type being "preview test record," and the parameters including the preview timestamp and test environment configuration information.

[0040] Each operation record, once generated, is encapsulated into a JSON data object containing fields such as operation type, operation time, and operation parameters. This object is then sent to the backend operation record processing interface via an AJAX request. The interface validates the data object to ensure the integrity and validity of the parameters. Upon successful validation, the operation record is stored in a detailed operation record list. This list is implemented using a linked list data structure for efficient insertion and traversal operations.

[0041] Step S1110: Perform correlation analysis on the operation type and operation parameters in the detailed list of operation records, extract key operation nodes in the operation sequence, integrate the operation parameters corresponding to the key operation nodes with the order of operation occurrence to form operation sequence information. The key operation nodes include component selection nodes, parameter confirmation nodes, logic saving nodes, and preview trigger nodes.

[0042] The detailed list of operation records is input into the operation sequence analyzer. The analyzer first sorts the records by operation time to obtain an operation sequence arranged in chronological order. Then, based on the correlation between operation type and operation parameters, pattern mining is performed on the operation sequence. Component selection nodes correspond to operations in the component addition record where the component type is determined. When the operation type is "component addition record" and the component type field is not empty, it is marked as a component selection node. Parameter confirmation nodes correspond to operations in the parameter configuration record where the user clicks the confirmation button. This is determined by detecting if the "confirm" parameter value in the parameter configuration record is true. Logic save nodes correspond to operations in the logic association record where the user saves logical relationships. When the operation type is "logic association record" and the "saveStatus" parameter is "saved", it is marked. Preview trigger nodes correspond to operations in the preview test record that trigger the preview. When the operation type is "preview test record", it is marked as a preview trigger node.

[0043] After extracting these key operation nodes, the operation parameters and position index of each node in the operation sequence are recorded. The position index reflects the sequential relationship of the operations. The operation parameters and position indexes of the key operation nodes are integrated into an ordered data structure. This data structure contains node type, parameter list, and sequence number, forming operation sequence information that fully describes the key operation flow of the user's component construction.

[0044] Step S1111: Call the version information interface of the low-code platform to obtain the current low-code platform version identifier and the corresponding version adaptation manual. Extract the adaptation requirements related to component development from the version adaptation manual. Divide the adaptation requirements according to the adaptation type to form adaptation benchmark information. The adaptation requirements include code syntax specifications, interface call format, resource reference path, and module dependency scope. The adaptation types include syntax adaptation, interface adaptation, resource adaptation, and dependency adaptation.

[0045] The low-code platform's backend deploys a version information interface, designed with a RESTful architecture, with the URL " / api / version / current". Calling this interface via an HTTP GET request returns the current platform version identifier, such as "V2.3.5", and the download URL for the version's adaptation manual. Based on the download URL, the version adaptation manual file is downloaded via an HTTP GET request. The manual file is in PDF format, and its text content is extracted using a PDF parser.

[0046] Using keyword retrieval, we searched for chapters related to component development within the extracted text content. Chapter titles typically contain keywords such as "component development" and "adaptation requirements." From these chapters, we extracted adaptation requirements including code syntax standards, API call formats, resource reference paths, and module dependency scopes. The extracted adaptation requirements were then categorized into adaptation types: syntax adaptation, API adaptation, resource adaptation, and dependency adaptation. Each adaptation type contained specific requirements clauses, forming adaptation baseline information.

[0047] Step S1112: Integrate the scenario description information, the operation sequence information, and the adaptation benchmark information to form component requirement scenario information.

[0048] Scene description information, operation sequence information, and adaptation benchmark information are stored in different data structures, and the integration process is implemented through an integrator module. The integrator first creates a root object for component requirement scenario information, which contains three properties: "sceneDescription", "operationSequence", and "adaptationBenchmark". The scene keyword category list from the scene description information is assigned to the "sceneDescription" property; the ordered data structure of key operation nodes from the operation sequence information is assigned to the "operationSequence" property; and the adaptation type category data from the adaptation benchmark information is assigned to the "adaptationBenchmark" property. After integration, the root object is JSON serialized to obtain a JSON string of component requirement scenario information, which is stored in the requirement information database for subsequent use in parsing of scene feature sets.

[0049] Step S1113: Extract features from the scenario description information in the component requirement scenario information, and convert each scenario keyword in the scenario keyword classification list into a standardized scenario feature item. Each standardized scenario feature item includes a feature identifier, a feature type, and a feature value range.

[0050] Each scenario keyword in the scenario keyword classification list is processed individually and converted into standardized scenario feature items. First, a unique feature identifier is generated for each keyword, named in the format "Scenario Dimension_Keyword Type_Keyword". For example, the feature identifier for the function action word "calculate" in the data processing scenario is "data_processing_function_calculate". The feature type is determined based on the keyword type: scenario object words correspond to the "object" type, function action words correspond to the "action" type, and environment limiting words correspond to the "condition" type. The feature value range is determined based on the keyword's context in the scenario description statement. If the keyword describes an enumerable object or operation, the value range is an enumerated list of values; if it describes a numerical value or range, the value range is a numerical interval. The feature identifier, feature type, and feature value range are integrated into a structured data object to form standardized scenario feature items.

[0051] Step S1114: Extract features from the operation sequence information in the component requirement scenario information, and convert the operation parameters and operation order relationship corresponding to the key operation nodes into standardized operation feature items. Each standardized operation feature item includes operation identifier, parameter name, parameter value, and operation order number.

[0052] Each key operation node in the operation sequence information is processed into a standardized operation feature item. The operation identifier is generated based on the node type: "select_component" for component selection nodes, "confirm_param" for parameter confirmation nodes, "save_logic" for logic saving nodes, and "trigger_preview" for preview trigger nodes. Parameter names and values ​​are extracted from the parameter list of the key operation node; each parameter item in the parameter list corresponds to a parameter name and a parameter value. The operation sequence number is the index of the key operation node's position in the operation sequence. The operation identifier, parameter name, parameter value, and operation sequence number are combined into a standardized operation feature item, with each parameter item corresponding to one standardized operation feature item, ensuring that every detail of the operation sequence can be accurately described.

[0053] Step S1115: Extract features from the adaptation baseline information in the component requirement scenario information, and convert the adaptation requirements of different adaptation types into standardized adaptation feature items. Each standardized adaptation feature item includes an adaptation type identifier, requirement content, and compliance basis.

[0054] The adaptation requirements clauses under each adaptation type in the adaptation baseline information are converted into standardized adaptation feature items. The adaptation type identifier is determined based on the adaptation type: syntax adaptation corresponds to "syntax_adaptation", interface adaptation to "interface_adaptation", resource adaptation to "resource_adaptation", and dependency adaptation to "dependency_adaptation". The requirement content is the specific textual description of the adaptation requirement clause. The compliance basis is extracted from the version adaptation manual, recording the chapter number and page number of the adaptation requirement clause in the manual. The adaptation type identifier, requirement content, and compliance basis are integrated into standardized adaptation feature items, with each adaptation requirement clause corresponding to one standardized adaptation feature item.

[0055] Step S1116: Integrate the standardized scene feature items, the standardized operation feature items, and the standardized adaptation feature items to form a scene feature set.

[0056] Standardized scene features, standardized operation features, and standardized adaptation features are input into the feature set integrator. The integrator creates an empty scene feature set object containing three array attributes: "sceneFeatures," "operationFeatures," and "adaptationFeatures." All standardized scene features are added to the "sceneFeatures" array, all standardized operation features to the "operationFeatures" array, and all standardized adaptation features to the "adaptationFeatures" array. Then, the feature items in the three arrays are deduplicated and sorted. Deduplication is achieved by comparing feature identifiers, and sorting is performed according to the chronological order of feature item generation. After processing, the scene feature set object is constructed and stored in the feature database as input data for the AI ​​code generation module.

[0057] Step S120: Combine the real-time metadata of the low-code platform to perform rule matching and dynamic adjustment on the scene feature set to generate a dynamic evolution rule set, which includes attribute mapping rules, logic compilation rules and adaptation calibration rules.

[0058] Step S121: Call the metadata management system of the low-code platform to obtain the real-time metadata of the low-code platform. The real-time metadata includes component attribute metadata, interaction logic metadata and platform adaptation metadata. The component attribute metadata defines the configurable attribute names, data types and default values ​​of the component. The interaction logic metadata defines the interaction events, triggering conditions and execution logic templates supported by the component. The platform adaptation metadata defines the code syntax, interface list and resource format supported by different versions of the platform.

[0059] The low-code platform's metadata management system is deployed on a backend server, providing metadata query services based on the gRPC protocol. A gRPC request is constructed, specifying the metadata type as "realtime," and sent to the metadata management system's server. Upon receiving the request, the server reads the latest component attribute metadata, interaction logic metadata, and platform adaptation metadata from the metadata cache. Component attribute metadata is stored in a structured table format, with each row corresponding to a component attribute, including fields such as attribute name, data type, and default value. Interaction logic metadata is described using a state machine model, including state transition diagrams for interaction events and execution logic template code snippets. Platform adaptation metadata is organized by version, with each version containing code syntax specification documents, interface definition files, and resource format constraint lists. The server packages the above metadata into Protobuf format data and returns it to the caller via a gRPC response, completing the acquisition of real-time metadata.

[0060] Step S122: Collect real-time status data of the low-code platform. The real-time status data includes the current platform's CPU utilization, memory usage, disk I / O rate, number of module loads, module loading time, and interface call success rate. The current platform's CPU utilization, memory usage, disk I / O rate, number of module loads, module loading time, and interface call success rate are used for subsequent rule adjustments.

[0061] The low-code platform's server-side deployment includes a performance monitoring agent. This agent periodically collects server CPU utilization, memory usage, and disk I / O rate data via system call interfaces, with a collection cycle of 5 seconds. Simultaneously, log collectors are installed on the platform's application and database servers to collect module load logs and API call logs. Module load logs include information such as module name, load timestamp, and load duration. By statistically analyzing the number of module loads and the average load duration per unit time, the module load count and load duration data are obtained. API call logs include information such as API name, call time, and response status code. By calculating the ratio of successful response status codes to the total number of calls, the API call success rate is obtained.

[0062] The collected data on CPU utilization, memory usage, disk I / O rate, module loading count, module loading time, and interface call success rate are organized in time series and stored in a time series database to form real-time status data. This data will serve as the basis for dynamic rule adjustment to determine the current operating status of the platform, thereby optimizing the rule priority and triggering conditions of the dynamically evolving rule set.

[0063] Step S123: Match the standardized scene feature items in the scene feature set with the component attribute metadata, identify the attribute metadata entries corresponding to each standardized scene feature item, record the attribute definition rules and data conversion requirements of the successfully matched attribute metadata entries, and form an attribute matching result list.

[0064] Standardized scene feature items and component attribute metadata are input into the attribute matching module. The attribute matching module employs a semantic similarity-based matching algorithm. First, it converts the feature identifiers of the standardized scene feature items and the attribute names of the component attribute metadata into word vectors. Then, by calculating the cosine similarity between the word vectors, it identifies the attribute metadata entry with the highest similarity as the matching target. If the similarity is greater than a preset matching threshold, the match is considered successful.

[0065] Upon successful matching, attribute definition rules and data transformation requirements are extracted from the component attribute metadata entries. Attribute definition rules include attribute naming conventions, data type constraints, and value range limitations; data transformation requirements include conversion formulas and format conversion methods from scene feature values ​​to attribute values. The feature identifier of the standardized scene feature item, the attribute name of the matched attribute metadata entry, the attribute definition rules, and the data transformation requirements are integrated into a single matching result object and added to the attribute matching result list. Standardized scene feature items that fail to match are also recorded in the list and marked as "unmatched".

[0066] Step S124: Based on the attribute matching result list, generate initial attribute mapping rules. The initial attribute mapping rules include the method of converting feature identifiers in standardized scene feature items into code attribute names, the method of converting feature types into code data types, and the method of converting feature value ranges into code parameter constraints. Each initial attribute mapping rule corresponds to a matching combination of standardized scene feature items and attribute metadata entries.

[0067] Successful matches in the attribute matching results list are used to generate initial attribute mapping rules. For each matching combination, the rule generator determines how to convert feature identifiers into code attribute names based on the attribute definition rules of the attribute metadata entries, typically using underscore naming or camelCase; it determines how to convert feature types into code data types based on data type definitions, such as converting the "text" type of scene features into the "string" type in code; and it determines how to convert feature value ranges into code parameter constraints based on value range restrictions, such as generating if-else conditional statements or regular expression validation.

[0068] Each initial property mapping rule is represented as a JSON object containing fields such as "featureId", "propertyName", "typeConversion", and "rangeConstraint", which correspond to the feature identifier, code property name, type conversion method, and parameter constraint method, respectively. These JSON objects are combined into an array to form the initial property mapping rule set.

[0069] Step S125: Match the standardized operation feature items in the scene feature set with the interaction logic metadata, identify the interaction logic metadata entries corresponding to each standardized operation feature item, record the logical template structure and parameter passing rules of the successfully matched interaction logic metadata entries, and form a logical matching result list.

[0070] Standardized operation features and interaction logic metadata are input into the logic matching module. The logic matching module employs a process pattern matching algorithm to compare the operation identifiers and order of the standardized operation features with the interaction events and state transition sequences in the interaction logic metadata. By constructing a directed graph of the operation sequences and a state machine model of the interaction logic, the isomorphism between the two models is calculated. Interaction logic metadata entries with an isomorphism higher than a threshold are identified as matching objects.

[0071] Upon successful matching, the logical template structure and parameter passing rules of the interaction logic metadata entries are extracted. The logical template structure defines the code's control flow and function call relationships; the parameter passing rules specify the passing path and format conversion method of operation parameters within the logical template. The operation identifier of the standardized operation feature item, the event name of the matched interaction logic metadata entry, the logical template structure, and the parameter passing rules are recorded in the logical matching result list. Entries that fail to match are also recorded and marked.

[0072] Step S126: Based on the logical matching result list, generate initial logical compilation rules. The initial logical compilation rules include the method of converting operation identifiers in standardized operation feature items into code event names, the method of converting parameter names into code parameter names, and the method of converting operation sequence numbers into code execution order. Each initial logical compilation rule corresponds to a matching combination of standardized operation feature items and interactive logical metadata entries.

[0073] Successful matches in the logical matching result list are used to generate initial logical compilation rules. For each matching combination, the naming rules for converting operation identifiers into code event names are determined based on the event names of the interactive logical metadata entries; the mapping relationship between parameter names and code parameter names is determined based on the parameter passing rules; and the control structure for the code execution order is determined based on the operation sequence number, such as using sequential statements, conditional statements, or loop statements to organize the code execution flow.

[0074] The initial logic compilation rules are also represented as JSON objects, containing fields such as "operationId", "eventName", "paramMapping", and "executionOrder". These rule objects are combined into an array to form the initial logic compilation rule set.

[0075] Step S127: Match the standardized adaptation feature items in the scene feature set with the platform adaptation metadata, identify the platform adaptation metadata entry corresponding to each standardized adaptation feature item, record the syntax adjustment rules and format calibration requirements of the successfully matched platform adaptation metadata entries, and form an adaptation matching result list.

[0076] Standardized adaptation features and platform adaptation metadata are input into the adaptation matching module. Based on the adaptation type identifier of the standardized adaptation features, the module locates the corresponding version section in the platform adaptation metadata, performs keyword searches within that section, and finds platform adaptation metadata entries relevant to the required content. Through text similarity calculation, the most relevant entries are determined as the matching targets.

[0077] Upon successful matching, the syntax adjustment rules and format calibration requirements of the platform adaptation metadata entries are recorded. Syntax adjustment rules include code statement structure adjustments and keyword replacements; format calibration requirements include indentation format, line break rules, and comment specifications. The adaptation type identifier of the standardized adaptation feature, the version number of the matched platform adaptation metadata entries, the syntax adjustment rules, and the format calibration requirements are recorded in the adaptation matching result list.

[0078] Step S128: Based on the adaptation matching result list, generate initial adaptation calibration rules. The initial adaptation calibration rules include the method of converting the adaptation type identifier in the standardized adaptation feature item into the code adaptation identifier, the method of converting the requirement content into the code adaptation logic, and the method of converting the compliance basis into the code compliance check logic. Each initial adaptation calibration rule corresponds to a matching combination of a standardized adaptation feature item and a platform adaptation metadata item.

[0079] Successfully matched entries in the adaptation matching results list are used to generate initial adaptation calibration rules. For each matching combination, based on the version information of the platform adaptation metadata entry, the method for converting the adaptation type identifier into the code adaptation identifier is determined; based on the syntax adjustment rules and format calibration requirements, the method for converting the required content into code adaptation logic is determined, such as generating conditional compilation directives or adaptation layer code; based on the compliance basis, the implementation method of compliance check logic is determined, such as generating unit test cases or static code check rules.

[0080] The initial adaptation calibration rules are represented as JSON objects, containing fields such as "adaptationId", "codeAdaptId", "logicConversion", and "complianceCheck". These are combined into an array to form the initial adaptation calibration rule set.

[0081] Step S129: Integrate the initial attribute mapping rules, the initial logic compilation rules, and the initial adaptation calibration rules to form an initial rule set.

[0082] The initial property mapping rule set, initial logic compilation rule set, and initial adaptation calibration rule set are input into the rule integration module. The integration module creates an initial rule set object containing three properties: "propertyMappingRules," "logicCompilationRules," and "adaptationCalibrationRules," each referencing one of the three initial rule sets. A consistency check is performed on the rules in the rule sets to ensure there are no conflicting rule definitions. After the check passes, the initial rule set object is serialized into JSON format and stored in the rule database as the base version for dynamically evolving rule sets.

[0083] Step S1210: Based on the various indicators in the real-time status data, determine whether each indicator exceeds or falls below its respective preset threshold, and adjust the rule priority of the initial rule set accordingly. Specifically, when the CPU utilization rate exceeds its preset threshold or the memory usage exceeds its preset threshold, increase the priority of resource optimization-related rules; when the number of module loadings exceeds its preset number or the module loading time exceeds its preset time, increase the priority of module dependency adaptation-related rules; when the interface call success rate is lower than its preset threshold, increase the priority of interface call adaptation-related rules.

[0084] Each metric in the real-time status data is compared one by one with preset thresholds. These preset thresholds are stored in the system configuration file and can be adjusted through the platform's configuration interface. For CPU utilization, its current value is compared to the preset threshold; if it exceeds the threshold, all resource optimization-related rules are retrieved from the initial rule set, and the "priority" field value of these rules is increased by a preset step size. Memory usage is handled similarly to CPU utilization. For module load counts and module load times, if they exceed preset thresholds, the priority of rules related to module dependency adaptation is increased. For API call success rate, if it is below the preset threshold, the priority of rules related to API call adaptation is increased.

[0085] Priority adjustments employ an incremental strategy, recording the adjustment time and magnitude after each adjustment to prevent frequent fluctuations in rule priority. The adjusted rule set forms a temporary rule set, stored in memory for subsequent dynamic triggering condition additions.

[0086] Step S1211: Add dynamic triggering conditions to the rules after priority adjustment, and integrate the rules after priority adjustment and the dynamic triggering conditions to form a dynamic evolution rule set.

[0087] Each rule in the adjusted priority rule set is given a dynamic trigger condition. The trigger condition generator sets different trigger conditions for different types of rules based on the changing characteristics of real-time state data. Trigger conditions are represented as logical expressions, including elements such as indicator name, comparison operator, threshold, and time window. The trigger conditions are added to the "triggerCondition" field of the rule object, and then the adjusted priority rules are integrated with the trigger conditions to form a dynamically evolving rule set. This dynamically evolving rule set is stored in a distributed cache to ensure fast access by the AI ​​code generation module.

[0088] Step S130: Call the AI ​​code generation module, take the scene feature set and the dynamic evolution rule set as input, convert the scene features into code structure units through the scene syntax conversion unit of the AI ​​code generation module, and then perform logical completion and syntax adaptation on the code structure units through the rule execution unit to generate the initial component code.

[0089] Step S131: Input the scene feature set and the dynamic evolution rule set into the input processing unit of the AI ​​code generation module, and perform format conversion on the standardized scene feature items, standardized operation feature items and standardized adaptation feature items in the scene feature set, converting them into feature data format that can be recognized by the scene syntax conversion unit. The feature data format includes feature identifier field, feature type field and feature value range field.

[0090] After receiving the scene feature set and dynamic evolution rule set, the input processing unit of the AI ​​code generation module first performs format conversion on the scene feature set. For standardized scene feature items, it extracts their feature identifier, feature type, and feature value range fields, and converts them into the Protobuf format required by the scene syntax conversion unit. The Protobuf format defines a strict data structure, including the order of fields, data types, and length constraints. For example, the feature identifier field is a string type with a maximum length of 100 bytes; the feature type field is an enumeration type containing three enumeration values: "object", "action", and "condition"; and the feature value range field is a nested message type, containing the value type and the specific value data.

[0091] The format conversion process for standardized operation features and standardized adaptation features is similar. Fields such as operation identifier, parameter name, parameter value, operation sequence number, adaptation type identifier, requirement content, and compliance basis are extracted and converted into the corresponding Protobuf message structure. After format conversion, the input processing unit sends the converted data to the scene syntax conversion unit via the internal bus.

[0092] Step S132: Perform rule parsing on the attribute mapping rules, logic compilation rules, and adaptation calibration rules of the dynamic evolution rule set, extract the trigger condition field, execution logic field, and output format requirement field of each rule, and convert them into a rule data format that can be recognized by the rule execution unit.

[0093] The rule parsing of the dynamic evolution rule set is performed by a rule parser. The rule parser employs recursive descent analysis to parse the JSON structure of attribute mapping rules, logical compilation rules, and adaptation calibration rules. For each rule, the "triggerCondition" field is extracted as the trigger condition field, which is a logical expression string; the "executionLogic" field is extracted as the execution logic field, which is a code generation template or transformation function; and the "outputFormat" field is extracted as the output format requirement field, which contains format information such as code indentation and line break type.

[0094] After parsing, the above fields are converted into a rule data format recognizable by the rule execution unit. This rule data format uses a custom binary format and includes metadata such as rule type identifier, trigger condition length, and execution logic offset, as well as specific data regarding trigger conditions, execution logic, and output format requirements. The converted rule data is stored in the rule execution unit's local cache, improving rule execution efficiency.

[0095] Step S133: Input the transformed feature data into the scene syntax conversion unit. The scene syntax conversion unit calls the pre-trained feature syntax mapping model to perform mapping processing on the standardized scene feature items. The content in the feature identifier field is mapped to the code attribute name that conforms to the naming convention of the low-code platform. The content in the feature type field is mapped to the corresponding code data type declaration statement. The content in the feature value range field is mapped to the code parameter constraint statement containing condition judgment, and the attribute code fragment is generated.

[0096] Step S1331: The scene syntax conversion unit loads the pre-trained feature syntax mapping model. The feature syntax mapping model is trained using historical component code data and corresponding scene feature data from the low-code platform. The feature syntax mapping model includes a feature identifier mapping layer, a feature type mapping layer, and a feature value range mapping layer.

[0097] When the scene syntax conversion unit starts, it loads a pre-trained feature syntax mapping model from the model storage path. This model is trained based on historical component development projects accumulated on the low-code platform. The training data includes scene feature descriptions from historical projects and the final generated code files. The model architecture adopts a layered design, with the feature identifier mapping layer, feature type mapping layer, and feature value range mapping layer connected sequentially. Information is transferred between each layer through a fully connected network. The feature identifier mapping layer is responsible for converting the identifier information of scene features into attribute names in the code, the feature type mapping layer handles the mapping relationship of data types, and the feature value range mapping layer focuses on converting value constraints into conditional judgment logic in the code.

[0098] Step S1332: Input the feature identifier field content of the standardized scene feature item into the feature identifier mapping layer. The feature identifier mapping layer performs character replacement processing on the input content, replaces special characters that do not conform to the naming conventions of the low-code platform with underscores, converts Chinese words into corresponding English words, adjusts the case of characters according to the format of lowercase first letter and uppercase first letter of subsequent words, and generates code attribute name candidates that conform to the platform naming conventions.

[0099] After the standardized scene feature items are input into the feature identifier mapping layer, they first pass through a character filtering module. This module has a built-in naming character set allowed by the low-code platform, which detects special characters in the input content and replaces characters outside the allowed range with underscores. Next, it enters the vocabulary conversion module, which maintains a domain-specific vocabulary lookup table to convert Chinese words into their corresponding English technical terms. Finally, the format adjustment module adjusts the capitalization of the converted words according to the platform's naming format (lowercase first letter, uppercase first letter of subsequent words) to form candidate code attribute names.

[0100] Step S1333: Perform duplicate checks on the candidate code attribute names, query the list of reserved keywords for the low-code platform, and add a numeric suffix to the end if the candidate code attribute name belongs to a reserved keyword, until a code attribute name that does not belong to a reserved keyword is generated.

[0101] After candidate code attribute names are generated, a conflict detection phase begins. In this embodiment, the reserved keyword list of the low-code platform is first queried, and the candidate names are compared with the keywords in the list. If a candidate name does not appear in the reserved keyword list, it is directly determined as the final code attribute name. If a conflict exists, this embodiment automatically adds a numeric suffix to the end of the candidate name and performs a reserved keyword check again until the generated name no longer conflicts with the reserved keywords.

[0102] Step S1334: Input the content of the feature type field of the standardized scene feature item into the feature type mapping layer. The feature type mapping layer converts the content in the feature type field into the corresponding code data type declaration statement according to the preset correspondence between feature type and code data type. For example, it converts the text type into the string type declaration statement and the numeric type into the integer type or floating-point type declaration statement.

[0103] The feature type content of standardized scene feature items is fed into the feature type mapping layer, which has a built-in mapping rule library between feature types and code data types. The rule library defines basic mapping relationships such as "text" to "string", "count" to "integer", and "measurement" to "floating-point number". Based on the input feature type content, the mapping layer searches the rule library to find the matching code data type, and then generates the corresponding data type declaration statement according to the code syntax specification.

[0104] Step S1335: If the content in the feature type field is ambiguous, refer to the functional requirements in the scenario description information to determine the corresponding code data type. For example, if the feature type field is a count, refer to the functional requirements to determine the declaration statement to convert it to an integer type.

[0105] When the description of a feature type field is not specific enough to directly match the standard types in the rule base, the feature type mapping layer triggers a context analysis mechanism. This mechanism extracts the functional requirements related to the current feature from the scenario description information and analyzes the data processing requirements. For example, if the feature type field is labeled "quantity," but the scenario description mentions "accumulated statistics and support for addition and subtraction," then based on the functional requirements, it is determined that it should be converted to an integer type declaration statement; if the scenario description mentions "two decimal places of precision," then it is determined that it should be converted to a floating-point number type declaration statement.

[0106] Step S1336: Input the content of the feature value range field of the standardized scene feature item into the feature value range mapping layer. The feature value range mapping layer performs logical parsing on the value range content, extracts the upper and lower limits, enumeration values ​​or format requirements of the value range, and generates code parameter constraint statements containing condition judgments.

[0107] After receiving the value range of standardized scene feature items, the feature value range mapping layer starts the logic parser. The parser first identifies the type of the value range: if it is a numerical range, it extracts the upper and lower boundary values ​​of the range; if it is an enumeration type, it extracts all possible enumeration options; if it is a format constraint type, it extracts the format description rules. Based on the parsing results, the mapping layer calls the corresponding code generation template to generate parameter constraint statements containing conditional judgment structures, ensuring that the validity of the input parameter values ​​is checked at runtime.

[0108] Step S1337: If the value range is a numerical range, generate a conditional statement that is greater than or equal to the lower limit and less than or equal to the upper limit; if the value range is an enumerated value, generate a conditional statement that is equal to any item in the enumerated value list; if the value range is a format requirement, generate a conditional statement that includes regular expression matching.

[0109] When the value range is explicitly defined as a numerical range, the feature value range mapping layer generates conditional statements connecting the upper and lower limits with logical operators to ensure that the parameter value is within the specified range. If the value range is an enumerated set of values, it generates conditional statements connecting each enumerated option with logical operators to verify whether the parameter value is a valid option in the set. If the value range is a format requirement, such as a date format or email format, it generates conditional statements containing corresponding regular expressions to verify the correctness of the parameter format through pattern matching.

[0110] Step S1338: Integrate the generated code attribute names, code data type declaration statements, and code parameter constraint statements, and generate attribute code snippets according to the data type declaration code attribute names.

[0111] After the code attribute name, data type declaration statement, and parameter constraint statement are generated, the code fragment integration stage begins. In this embodiment, according to the code syntax structure requirements, the data type declaration statement is placed before the code attribute name to form a complete attribute definition statement. Then, the parameter constraint statement is added after the attribute definition as a supplementary explanation of the attribute definition. The three together constitute the basic structure of the attribute code fragment.

[0112] Step S1339: Perform a syntax check on the generated attribute code snippet to ensure that the code snippet conforms to the syntax specification of the current low-code platform version. If there is a syntax error, return to the corresponding mapping layer to readjust the mapping rules until a syntactically correct attribute code snippet is generated.

[0113] After the attribute code snippet is generated, it is verified through the syntax checking interface provided by the low-code platform. The interface performs a comprehensive check on keyword usage, symbol matching, and statement structure in the code snippet according to the syntax specifications supported by the current platform version. If a syntax error is detected, this embodiment records the error location and reason, and feeds the error information back to the corresponding mapping layer. The relevant mapping layer adjusts the mapping rules based on the error feedback, regenerates the code snippet, and performs syntax checks again until the generated attribute code snippet fully conforms to the platform's syntax specifications.

[0114] Step S134: Map the standardized operation feature items, map the content in the operation identifier field to code event declaration statements that conform to the low-code platform event naming convention, map the content in the parameter name field to the corresponding code parameter declaration statements, and map the content in the operation sequence number field to code execution sequence control statements containing sequence control keywords, thereby generating logical code fragments.

[0115] The scene syntax transformation unit processes the standardized operation feature data in the feature buffer. Another set of decoders in the feature syntax mapping model is dedicated to processing operation features, mapping operation identifiers to code event declaration statements, such as mapping the "click_button" operation identifier to the "onButtonClick()" event function declaration; mapping parameter names to function parameter declaration statements, such as mapping the "goods_id" parameter name to "intgoodsId"; and mapping operation sequence numbers to code execution order control statements, such as using keywords like "if", "else", and "for" to organize the execution order of code blocks.

[0116] The generated logic code snippets contain event handling functions, parameter passing logic, and flow control statements, and are stored in the "logic area" of the code snippet buffer.

[0117] Step S135: Map the standardized adaptation feature items, map the content in the adaptation type identifier field to the code adaptation identifier declaration statement that conforms to the low-code platform adaptation identifier specification, map the content in the requirement content field to the code adaptation logic statement containing adaptation logic, map the content in the compliance basis field to the code compliance check statement containing check conditions, and generate the adaptation code snippet.

[0118] The mapping of standardized adaptation features is handled by the adaptation layer decoder of the feature syntax mapping model. Adaptation type identifiers are mapped to code adaptation identifier declaration statements, such as mapping "syntax_adaptation" to "#ifdefSYNTAX_ADAPT_V2"; requirement content is mapped to adaptation logic statements, such as generating conditional compilation code blocks based on version adaptation requirements; compliance criteria are mapped to code compliance check statements, such as generating assertion statements or log output statements to check whether the code meets adaptation requirements.

[0119] The generated adapted code snippets contain version adaptation logic, compliance check code, and error handling statements, and are stored in the "adaptation area" of the code snippet buffer.

[0120] Step S136: Integrate the attribute code fragment, the logic code fragment, and the adaptation code fragment to form an initial code structure unit. The integration process follows the code syntax structure requirements of the low-code platform, placing the attribute code fragment in the header area of ​​the code file, the logic code fragment in the middle area of ​​the code file, and the adaptation code fragment in the tail area of ​​the code file.

[0121] The code snippet aggregator reads attribute code snippets, logic code snippets, and adapter code snippets from the "attribute area," "logic area," and "adaptation area" of the code snippet buffer, respectively. Following the code syntax structure specifications of low-code platforms, the header area of ​​the code file is used to declare attributes and variables, the middle area is used to define functions and logic control, and the tail area is used for version adaptation and compliance checks. The aggregator concatenates the three code snippets in this order, adding necessary code separators and comment lines during the concatenation process, such as adding a " / / logic code begins" comment line between the attribute code snippet and the logic code snippet.

[0122] After integration, an initial code structure unit is formed. This unit is a complete abstract representation of a code file, containing the syntactic structure and semantic information of the code, and is stored in the code structure buffer.

[0123] Step S137: Input the initial code structure unit and the converted rule data into the rule execution unit. The rule execution unit first calls the attribute mapping rule to perform syntax verification on the attribute code fragments in the initial code structure unit, corrects characters in the attribute names that do not conform to the platform naming conventions, adjusts the syntax format of the data type declaration statement to conform to the current platform version requirements, supplements the missing condition judgment keywords in the parameter constraint statement, and generates the verified attribute code fragments.

[0124] The initial code structure unit and the transformed rule data are input to the rule execution unit via an internal data bus. The rule execution unit first loads all attribute mapping rules from the rule data and sorts them according to rule priority. Then, it iterates through the attribute code snippets in the initial code structure unit and applies the attribute mapping rules to each attribute code line.

[0125] The syntax validator checks whether attribute names conform to the platform's naming conventions, such as whether they contain special characters or begin with a number. If non-compliant characters are found, they are corrected according to the conversion methods in the rules, such as replacing spaces with underscores. The syntax format of data type declaration statements is adjusted according to the platform version requirements, such as replacing the old version's "var" declaration with the new version's "let" or "const" declaration. Missing conditional keywords in parameter constraint statements, such as "if," "else," and "return," are added according to the logic templates in the rules. After processing, a validated attribute code snippet is generated, replacing the attribute code snippet in the initial code structure unit.

[0126] Step S138: Call the logical compilation rules to complete the logical code fragments in the initial code structure unit, supplement the missing execution function call statements after the event is triggered, adjust the logical structure of the execution order control statement to conform to the order requirements in the operation sequence information, add logical jump statements to handle abnormal execution scenarios, and generate the completed logical code fragments.

[0127] The rule execution unit loads the logic compilation rules and processes the logic code fragments. The logic completer analyzes the association between event declaration statements and function calls. If no corresponding function call statement is found after an event is triggered, the function call code is completed according to the execution logic template in the rules. The logical structure adjustment of the execution order control statements is achieved by comparing the order in the code with the operation order number in the operation sequence information. If they are inconsistent, the order of the code blocks is adjusted or the condition judgment conditions are modified. Logical jump statements for exception handling scenarios are added, such as try-catch statements or if-else error handling branches, generated according to the exception handling template in the rules. After processing, the completed logic code fragment is generated, and the initial code structure unit is updated.

[0128] Step S139: Invoke the adaptation calibration rules to perform syntax adaptation on the adaptation code snippets in the initial code structure unit, adjust the interface call format in the adaptation logic statement to conform to the interface specification of the current platform version, correct the conditional judgment expression in the compliance check statement to meet the adaptation requirements, supplement the platform version identifier in the resource reference path, and generate the adapted code snippets.

[0129] The adaptation calibration rules are loaded into the rule execution unit, and the adaptation processor performs syntax adaptation processing on the adaptation code snippets. Interface call format adjustments are made based on the interface list in the platform's adaptation metadata, such as changing old version URL paths to new version RESTful paths, and adding or removing request header parameters. Conditional expressions in compliance check statements are corrected, such as adjusting version number comparison logic or resource size limits. Platform version identifiers are added to resource reference paths, such as adding the " / v2 / " version prefix to image paths. After processing, the adapted code snippets are generated and replace the adapted code snippets in the initial code structure unit.

[0130] Step S1310: Integrate the verified attribute code snippet, the completed logic code snippet, and the adapted code snippet, and concatenate them according to the code execution logic order. Add code comment information, which includes code function description content and rule application record content, to form the initial component code.

[0131] The code integrator in the rule execution unit concatenates the validated attribute code snippets, the completed logic code snippets, and the adapted code snippets according to the code execution logic order. The concatenation order is: attribute code snippets first, logic code snippets in the middle, and adapted code snippets last. During the concatenation process, code comments are added. The code function description comments are located at the beginning of each code block, explaining the function of the code block; the rule application record comments are located at the application section of each rule, recording the applied rule ID and rule name.

[0132] After concatenation, the code is formatted, adjusting indentation, line breaks, and spaces to conform to the coding style requirements of low-code platforms. The formatted code forms the initial component code and is stored as a string in the code output buffer.

[0133] Step S140: Deploy the initial component code to the test environment of the low-code platform, collect the functional operation data, resource consumption data and version compatibility data of the initial component code in the test environment, generate iterative optimization instructions based on the matching analysis results of the functional operation data, the resource consumption data, the version compatibility data and the scene feature set, and adjust the initial component code and the dynamic evolution rule set through the iterative optimization instructions to obtain the optimized target component code.

[0134] Step S141: Deploy the initial component code to the test environment of the low-code platform. Simulate the actual application scenario of the component in the test environment. Trigger various functions of the component through test scripts. The test scripts include component initialization scripts, function triggering scripts, and abnormal scenario simulation scripts. Collect function operation data of the component during function execution. The function operation data includes function execution result content, function response time data, and function execution error record content. The function execution result content, function response time data, and function execution error record content are used to analyze the degree of matching between the component function and the scenario requirements.

[0135] The initial deployment of component code is achieved through the platform's automated deployment tool. This tool reads the component code's configuration file, determines the target server and deployment path for the test environment, and transfers the code files to the specified directory on the target server via the SSH protocol. Then, it executes the deployment script, installs the component's dependencies, configures the runtime environment variables, and starts the component service.

[0136] The test environment is equipped with a test script engine, which loads component initialization scripts, function triggering scripts, and abnormal scenario simulation scripts. The component initialization script is used to set test data, such as simulating product data and user membership data; the function triggering script simulates user clicks, inputs, and other operations to trigger the component's display, interaction, and data processing functions; the abnormal scenario simulation script simulates abnormal situations such as network timeouts, data format errors, and insufficient permissions.

[0137] During script execution, the function execution data collector intercepts component API calls and front-end events to record function execution results, such as whether product information is displayed correctly and whether the "add to cart" operation is successful; it also records function response time data, such as the time interval from clicking the button to the pop-up appearing; and it records function execution error logs, such as JavaScript error stack information and API call error codes. All of the above data is written to the function execution data table in the test database in real time.

[0138] Step S142: Collect resource consumption data of the component during operation using a resource monitoring tool in the test environment. The resource monitoring tool records data according to a preset collection cycle. The resource consumption data includes CPU utilization data, memory usage data, and disk I / O rate data in each collection cycle. The CPU utilization data, memory usage data, and disk I / O rate data in each collection cycle are used to analyze the component's resource usage on the platform.

[0139] The test environment server has a resource monitoring agent installed. The agent is configured to collect resource consumption data of component processes at a preset collection period (e.g., 1 second). CPU utilization data is calculated by reading the operating system's / proc / stat file, memory usage data is calculated by reading the / proc / meminfo file and the component process's smaps file, and disk I / O rate data is collected using the iostat tool.

[0140] The collected resource consumption data, bearing a timestamp and component instance ID, is sent to the resource monitoring server and stored in a time-series database. The time-series database organizes data according to a time series, supporting queries and aggregation calculations by time range, facilitating subsequent analysis of component resource usage at different operational stages.

[0141] Step S143: Obtain multiple platform installation packages of different versions from the low-code platform's version repository, build corresponding test sub-environments in the test environment, deploy the initial component code to each test sub-environment, trigger the component function through the same test script, and collect version compatibility data of the component in different version test sub-environments. The version compatibility data includes the number of successful version adaptations and version-related error records. The number of successful version adaptations and version-related error records are used to analyze the version adaptation capability of the component.

[0142] The low-code platform's repository is a Git repository that stores the source code for all historical versions of the platform's installation packages. The repository is cloned to the local machine using Git commands, and then different version tags are checked out, such as "v2.1.0", "v2.2.0", "v2.3.0", etc. For each version, a separate test sub-environment is built in the testing environment using DockerCompose. Each test sub-environment contains all the platform's service components, such as the front-end server, back-end API server, and database server. Network isolation ensures that the sub-environments do not interfere with each other.

[0143] The initial component code is deployed to each test sub-environment, following the same deployment process as the main test environment. After deployment, the same test scripts are run in each sub-environment to record whether the component can start normally and whether the functionality executes correctly. The version adaptation success count is recorded as the number of times all test cases for the component execute successfully in that version's sub-environment. Version-related error logs record platform version-related error information, such as API incompatibility errors and dependency library version conflicts. This data is stored in a version compatibility database and indexed by version number and component ID.

[0144] Step S144: Perform matching analysis between the function operation data and the standardized scene feature items in the scene feature set, compare the function execution result content with the function requirement description content in the scene feature items, count the number of tests in which the function execution result content and the requirement description content are consistent, calculate the proportion of the consistent number of tests to the total number of tests, and use this proportion as the function matching degree.

[0145] For example, step S1441: Extract the function execution result content of all test times from the function operation data, and assign a unique result identifier to the function execution result content of each test time.

[0146] The function execution data analysis module traverses the dataset storing function execution data. For each record's function execution result, this embodiment generates a unique result identifier. This identifier is generated by combining and encoding the function execution timestamp, test case number, and execution instance number, ensuring that each function execution result can be uniquely identified and referenced.

[0147] Step S1442: Extract all standardized scene feature items from the scene feature set, filter out standardized scene feature items that contain functional requirement descriptions, and assign a unique feature identifier to each standardized scene feature item that contains functional requirement descriptions.

[0148] The scene feature set parsing module traverses the scene feature set and identifies standardized scene feature items that contain functional requirement descriptions. For each qualified feature item, this embodiment assigns a unique feature identifier, which is generated based on the feature item's index position in the scene feature set and the feature type encoding. This identifier is used to subsequently establish the correspondence between the function execution result and the requirement description.

[0149] Step S1443: Establish a correspondence table between result identifiers and feature identifiers. Based on the function triggering logic in the test script, determine the standardized scenario feature item to which the function requirement belongs for each test count, and record the association between result identifiers and feature identifiers in the correspondence table.

[0150] The system analyzes the correspondence between each test step and the functional requirement description in the scenario feature set based on the functional triggering logic defined in the test script. For each test iteration, it determines the standardized scenario feature item corresponding to the triggered functional requirement, and then associates the result identifier of that test iteration with the corresponding feature identifier in the result identifier and feature identifier correspondence table, forming a many-to-many mapping relationship.

[0151] Step S1444: Perform text parsing on the function execution result content corresponding to each result identifier, extract the core function implementation description, and remove irrelevant log information and format characters.

[0152] The text parser processes the content of the function execution result. First, it uses regular expression matching to remove log header information such as timestamps and process IDs, and then filters out HTML tags, special characters, and other formatting characters. Next, it uses a keyword extraction algorithm to identify and extract key phrases and sentences that describe the core content of the function implementation, forming a structured core function implementation description text.

[0153] Step S1445: Perform text parsing on the functional requirement description content in the standardized scene feature item corresponding to each feature identifier, extract the core functional requirement description, compare the semantic similarity between the core functional implementation description and the core functional requirement description, and if the similarity score is higher than the preset score, determine that the functional execution result content of this test number is consistent with the requirement description content.

[0154] The text parser also processes the functional requirement descriptions in the standardized scene feature items, extracting the core functional requirement descriptions. Then, a semantic similarity calculation model compares the core functional implementation description with the core functional requirement description. This model is built on a pre-trained language model and can analyze the degree of matching between two texts at the semantic level. When the calculated similarity score exceeds the system's preset threshold, it is determined that the functional execution result for that number of tests meets the requirement description.

[0155] Step S1446: Count the number of tests that are determined to be consistent and record the specific value of the number of consistent tests; and, count the specific value of the total number of tests, which is the sum of the number of times all functions are triggered in the test script; calculate the quotient of the specific value of the number of consistent tests divided by the specific value of the total number of tests, and use the quotient as the function matching degree.

[0156] The system iterates through the results of all tests, accumulating the number of tests deemed consistent. Simultaneously, it sums the number of times all functions defined in the test scripts are triggered, calculating the total number of tests. The functional matching degree is obtained by dividing the number of consistent tests by the total number of tests; this metric reflects the degree to which the component's functional implementation conforms to the requirements description.

[0157] Step S145: Compare the functional response time data with the response requirement description in the scenario feature items, count the number of tests in which the functional response time data matches the requirement description, calculate the proportion of the number of matching times to the total number of tests, and use this proportion as the response matching degree.

[0158] Extract function response time data from the function operation data, and extract response requirement descriptions, such as "response time less than 500 milliseconds," from the scenario feature set. Compare the response time data of each test case with the threshold in the requirement description, and count the number of tests where the response time is less than the threshold. Divide the number of matches by the total number of tests to obtain the response matching score. For example, if there are 100 total tests and 75 matches, the response matching score is 0.75.

[0159] Step S146: Count the number of errors related to the scenario requirements in the error log of the statistical function execution, calculate the proportion of the number of errors to the total number of tests, and use this proportion as the error rate.

[0160] Error logs are categorized, with errors related to scenario requirements including unimplemented functions, data display errors, and interaction logic errors. The number of these errors is counted and divided by the total number of tests to obtain the error rate. For example, if there are 5 errors and 100 total tests, the error rate is 0.05.

[0161] Step S147: Match the resource consumption data with the resource demand features in the scene feature set. The resource demand features are extracted from the scene description information. Compare the CPU utilization data, memory usage data, and disk I / O rate data in each collection cycle with the resource limitation description content in the resource demand features. Count the number of collection cycles in which each resource consumption data matches the limitation description content. Calculate the proportion of the number of matching data to the total number of collection cycles. Use this proportion as the resource matching degree.

[0162] Resource requirement characteristics are extracted from environmental constraints in the scenario description information, such as "CPU utilization not exceeding 20%" and "memory usage not exceeding 100MB". Resource consumption data is queried from the time-series database, and compared with the resource constraint descriptions one by one according to the collection period. The number of collection periods in which CPU utilization, memory usage, and disk I / O speed all meet the constraints is counted, and divided by the total number of collection periods to obtain the resource matching degree. For example, if the total number of collection periods is 1000 and the number of matching periods is 800, the resource matching degree is 0.8.

[0163] Step S148: Perform matching analysis between the version compatibility data and the standardized adaptation feature items in the scene feature set, compare the number of successful version adaptations with the adaptation requirements in the adaptation feature items, count the number of versions whose successful version adaptations meet the requirements, calculate the proportion of the number of versions that meet the requirements to the total number of tested versions, and use this proportion as the version matching degree.

[0164] Retrieve the number of successful version adaptations and the adaptation requirements from the adaptation feature database, such as "compatible version no lower than v2.2.0". Count the number of versions with a successful version adaptation count greater than or equal to the adaptation requirement count, and divide this number by the total number of tested versions to obtain the version matching score. For example, if there are 5 tested versions and 4 are compatible, the version matching score is 0.8.

[0165] Step S149: Count the number of errors related to the adaptation requirements in the version-related error records, calculate the proportion of the number of errors to the total number of test versions, and use this proportion as the version error rate.

[0166] The version-related error logs include errors related to compatibility requirements, such as syntax incompatibility errors, API call failures, and resource reference errors. The error rate is calculated by counting the number of these errors and dividing by the total number of tested versions. For example, if there is 1 error and 5 total tested versions, the version error rate is 0.2%.

[0167] Step S1410: Integrate the function matching degree, response matching degree, error rate, resource matching degree, version matching degree, and version error rate to form a matching analysis result. Generate iterative optimization instructions based on the matching analysis result. When the function matching degree is lower than a preset ratio, generate a function completion instruction. The function completion instruction includes the specific code snippet of the function logic to be supplemented and the scene feature identifiers on which the function implementation is based. When the response matching degree is lower than a preset ratio, generate a response optimization instruction. The response optimization instruction includes the specific location of the code logic to be optimized and the resource requirement feature identifiers on which the optimization reference is based. When the error rate is higher than a preset ratio, generate an error repair instruction. The error repair instructions include the specific location of the error to be repaired and reference cases for the error repair method; when the resource matching degree is lower than a preset ratio, a resource optimization instruction is generated, which includes the specific code snippet of resource consumption to be optimized and the implementation steps of the resource optimization method; when the version matching degree is lower than a preset ratio, a version adaptation optimization instruction is generated, which includes the specific location of the adaptation code to be adjusted and the platform adaptation metadata entries on which the adaptation adjustment is based; when the version error rate is higher than a preset ratio, a version error repair instruction is generated, which includes the specific location of the version-related errors to be repaired and the version adaptation manual chapters on which the error repair is based.

[0168] The matching analysis result integration module integrates functional matching degree, response matching degree, error rate, resource matching degree, version matching degree, and version error rate into a single analysis result object. Each indicator includes its current value and a preset threshold. The analysis result object is compared with the preset optimization strategy. When an indicator fails to meet the threshold requirement, a corresponding iterative optimization instruction is triggered.

[0169] The generation of function completion instructions involves identifying scenario feature items with function matching scores below a threshold, retrieving corresponding function logic code templates from the rule base, filling in the scenario feature item identifiers, and generating the code snippets to be supplemented. Response optimization instructions use performance analysis tools to locate code logic with excessively long response times and associate resource requirement feature identifiers as optimization references. Error repair instructions determine the specific location of errors based on stack information in error logs and search for similar error repair methods in the error repair case library. Resource optimization instructions use resource analysis tools to locate code snippets with high resource consumption and provide resource optimization methods and steps such as algorithm optimization and caching. Version adaptation optimization instructions locate problem locations in adaptation code based on version compatibility data and reference platform adaptation metadata entries as adjustment criteria. Version error repair instructions search for the corresponding repair sections in the version adaptation manual based on version-related error logs and generate repair instructions.

[0170] Step S1411: Input the iterative optimization instructions into the code adjustment unit of the AI ​​code generation module. Based on the function completion instructions, supplement the missing functional logic in the initial component code, inserting specific code snippets of the functional logic to be supplemented at the corresponding code locations. Based on the response optimization instructions, adjust the response control logic in the code, modifying the statement structure of the specific locations of the code logic to be optimized. Based on the error repair instructions, modify the error locations in the code, adjusting the code content according to the reference cases of error repair methods. Based on the resource optimization instructions, optimize the resource consumption in the code, replacing the specific code snippets of resource consumption to be optimized with code snippets of lower resource consumption. Based on the version adaptation optimization instructions, adjust the adaptation logic in the code, modifying the content of the specific locations of the adaptation code according to the platform adaptation metadata entries used for adaptation adjustment. Based on the version error repair instructions, repair the version-related error locations in the code, adjust the code content according to the requirements of the corresponding chapters in the version adaptation manual, and generate the adjusted code snippets.

[0171] The code adjustment unit of the AI ​​code generation module receives iterative optimization instructions and parses the code adjustment information within them. Code snippets from function completion instructions are inserted into specified positions in the initial component code via a code insertion interface; the insertion position is determined based on the mapping relationship between scene feature identifiers and the code. Code logic locations in response optimization instructions are located using the code syntax tree, modifying statement structures such as changing synchronous calls to asynchronous calls or adding caching logic. Error locations in error correction instructions are located using line and column numbers, and code content is modified according to reference examples, such as correcting spelling errors in variable names or adjusting conditional expressions. Code snippet replacement in resource optimization instructions uses code matching algorithms to find high-resource-consuming code and replaces it with optimized code, such as changing loop iterations to vector operations. Version adaptation optimization instructions and version error correction instructions involve similar code adjustments, modifying code according to platform adaptation metadata entries and version adaptation manual chapter requirements, respectively. The adjusted code snippets are stored in a temporary code buffer.

[0172] Step S1412: Simultaneously, the iterative optimization instructions are input into the rule adjustment unit. Based on the function completion instructions, the logical compilation rules in the dynamic evolution rule set are adjusted, and execution steps related to logical completion are added to the execution logic field. Based on the response optimization instructions, the attribute mapping rules in the dynamic evolution rule set are adjusted, and response optimization-related parameter constraints are added to the parameter constraint field. Based on the error repair instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and error checking-related judgment conditions are added to the compliance basis field. Based on the resource optimization instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and resource optimization-related restrictions are added to the adaptation requirements field. Based on the version adaptation optimization instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and version adaptation-related operation steps are updated in the execution logic field. Based on the version error repair instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and version error checking-related judgment conditions are added to the compliance basis field.

[0173] The rule adjustment unit parses iterative optimization instructions and adjusts the dynamically evolving rule set. Function completion instructions trigger updates to the logic compilation rules, adding logic completion steps, such as adding function calls or conditional branches, to the "executionLogic" field. Response optimization instructions update the "paramConstraint" field of the attribute mapping rules, adding parameter constraints such as "maxResponseTime:500". Error correction instructions update the "compliance basis" field of the adaptation calibration rules, adding error checking conditions, such as a check for "errorCode:404". Resource optimization instructions update the "adaptationRequirements" field of the adaptation calibration rules, adding resource limits, such as "maxMemoryUsage:100MB". Version adaptation optimization instructions and version error correction instructions update the "executionLogic" and "compliance basis" fields of the adaptation calibration rules respectively, ensuring that the rules can guide the generation of code adapted to the new version.

[0174] Step S1413: Redeploy the adjusted code snippet to the test environment for verification. Repeat the process of collecting running data, performing matching analysis, generating optimization instructions, and adjusting code and rules until the functional matching degree, response matching degree, resource matching degree, and version matching degree in the matching analysis results all reach the preset ratio, and the error rate and version error rate are all lower than the preset ratio, and the optimized target component code is obtained.

[0175] The adjusted code snippet is redeployed to the test environment via the deployment interface, and steps S141 to S1412 are repeated. After each iteration, the matching degree and error rate metrics are recalculated and compared with preset thresholds. If all metrics meet the requirements, the iteration stops, and the current code snippet is identified as the target component code; otherwise, iterative optimization instructions are generated to adjust the code and rules until the requirements are met. The target component code is stored in the code repository and marked as "optimization complete".

[0176] Step S150: Embed the target component code into a specified functional module of the low-code platform. The specified functional module is determined based on the functional scene positioning features in the scene feature set to complete the AI-assisted code generation.

[0177] Step S151: Extract functional scene location features from the scene feature set. The functional scene location features include the module category to which the function belongs, the relationship between the function and other modules, and the function's entry point location information.

[0178] The metadata of the scene feature set includes a functional scene location feature field, the content of which is extracted through JSON parsing. This includes the module category to which the function belongs, such as "product display module," the function's relationship with other modules, such as "dependent on user authentication module," and the function's entry point location information, such as "content area of ​​search results page." This information is stored in the location feature object for subsequent module matching.

[0179] Step S152: Call the module management interface of the low-code platform to obtain a list of all functional modules of the low-code platform. The list of functional modules includes the module name, module category, module interface information, and module location information of each functional module.

[0180] The low-code platform's module management service provides a REST API interface, allowing users to retrieve a list of functional modules by sending a GET request to " / api / modules". The interface returns JSON-formatted data containing detailed information for each functional module. Module names include "Product Search Module", module categories include "Product Display", module interface information includes the interface URL and call parameters, and module location information includes "Page Path: / search / result".

[0181] Step S153: Match the module category of the function in the functional scene location feature with the module category in the functional module list, and filter out the functional modules with the same module category as candidate functional modules.

[0182] The module category with the functional scenario positioning feature is matched with the module category field in the functional module list. For example, the "product display module" category is compared with the module categories in the list to filter out modules with the same category and form a candidate functional module list.

[0183] Step S154: Based on the relationship between the function in the functional scenario positioning features and other modules, analyze the degree of association between the candidate functional modules and other modules, and retain the candidate functional modules whose associations meet the requirements.

[0184] The relationships between candidate functional modules are analyzed, and dependency edges and call edges between candidate modules and other modules are found from the platform's module dependency graph. If the functional scenario positioning feature requires a dependency on the "user authentication module," then it is checked whether the candidate module has a dependency on this module, and candidate modules with dependencies are retained.

[0185] Step S155: Based on the function call entry location information in the function scenario location features, compare the module location information of the candidate function modules, and determine the function module that matches the call entry location information as the designated function module.

[0186] The entry point location information for function calls, such as the "content area of ​​the search results page," is matched with the module location information of candidate function modules. The module location information includes the page path and region identifier. By comparing the page path and region identifier, the candidate module with the best matching location information is found and identified as the specified function module.

[0187] Step S156: Obtain the code embedding interface information of the specified functional module. The code embedding interface information includes the interface address, interface call parameters, and interface return value format.

[0188] By calling the " / api / modules / {moduleId} / embed" endpoint of the module management interface and passing in the ID of the specified functional module, the code embedding interface information can be obtained. The interface address is such as " / embed / modules / goods-list", the interface call parameters include "componentCode", "position", etc., and the interface return value is in JSON format, containing fields such as "success" and "message".

[0189] Step S157: Encapsulate the target component code according to the requirements of the interface call parameters, add the parameter information required for the interface call, and generate the encapsulated component code.

[0190] The target component code is converted into a string and encapsulated into the "componentCode" parameter according to the requirements of the API call parameters. Simultaneously, a "position" parameter is added to specify the embedding location, such as "content_area". The encapsulated component code is a JSON object containing all API call parameters.

[0191] Step S158: Using the module integration tool of the low-code platform, send the encapsulated component code to the code embedding interface address of the specified functional module and pass the corresponding interface call parameters.

[0192] The module integration tool is a command-line tool that configures the interface address and calling parameters, executes an HTTP POST request, and sends the encapsulated component code as the request body to the code embedding interface. The tool supports setting timeouts and retry mechanisms to ensure successful request delivery.

[0193] Step S159: Receive the execution result returned by the code embedding interface. If the execution result is successful, it means that the target component code has been successfully embedded into the specified functional module. If the execution result is unsuccessful, adjust the encapsulated component code according to the returned error information and resend it to the code embedding interface until the execution result is successful.

[0194] The execution result returned by the code embedding interface is received via an HTTP response. A 200 response status code indicates success, while other status codes indicate failure. In case of failure, the "message" field in the response body contains error information, such as "incorrect code format" or "insufficient permissions." The encapsulated component code is adjusted based on the error information, such as correcting syntax errors or requesting permissions, and then the request is resent until the execution result is successful.

[0195] Step S1510: Call the function verification interface of the low-code platform to perform function verification on the specified function module after embedding the target component code, trigger the core function of the specified function module, and check whether the target component code participates in the function execution normally.

[0196] The functional verification interface is " / api / modules / {moduleId} / validate". Calling this interface triggers automated testing of the specified functional module. The testing process simulates user operations to check whether the target component is displayed correctly and whether the interactive functions are normal. The verification result includes a pass or fail status, as well as detailed verification logs.

[0197] Step S1511: If the function verification passes, record the embedding success information, which includes the embedding time, the specified function module name, and the target component code identifier; if the function verification fails, adjust the target component code according to the verification error information, and re-encapsulate and embed the code until the function verification passes, and generate an AI-assisted code generation full-process report. The AI-assisted code generation full-process report includes a component requirement scenario information summary, a list of key rules in the dynamic evolution rule set, an initial component code optimization record, and the target component code embedding result, thus completing the AI-assisted code generation.

[0198] After successful functional verification, embedding success information is recorded in the system log and database, including the embedding timestamp, module name, and Git commit hash of the component code. If verification fails, the target component code is adjusted based on the error log, and steps S157 to S1510 are repeated. Finally, a full-process report on AI-assisted code generation is generated, summarizing key information from the entire process and outputting it in HTML format for developers to review. Once the report is generated, the AI-assisted code generation process is officially complete.

[0199] Based on the same inventive concept, please refer to Figure 2 This paper shows a schematic block diagram of an AI-assisted code generation system 100 for executing the above-described AI-assisted code generation method for low-code platforms, provided in an embodiment of this application. The AI-assisted code generation system 100 for low-code platforms may include a communication unit 110, a machine-readable storage medium 120, and a processor 130.

[0200] In this embodiment, both the machine-readable storage medium 120 and the processor 130 are located in the AI-assisted code generation system 100 applied to a low-code platform and are separately configured. Alternatively, the machine-readable storage medium 120 can also be integrated into the processor 130 and can communicate and interact with external systems through the communication unit 110. The machine-readable storage medium 120 is used to store machine-executable instructions for executing the scheme of this application, and the processor 130 is used to execute the machine-executable instructions stored in the machine-readable storage medium 120 to implement the AI-assisted code generation method applied to a low-code platform provided in the aforementioned method embodiments.

[0201] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. An AI-assisted code generation method applied to a low-code platform, characterized in that, The method includes: Obtain the component requirement scenario information of the low-code platform, and parse the scenario feature set based on the component requirement scenario information to obtain the scenario feature set. The component requirement scenario information includes scenario description information, operation sequence information and adaptation benchmark information. The scenario description information comes from the user's text description of the component application scenario. The operation sequence information comes from the user's component operation record in the visual interface. The adaptation benchmark information comes from the version adaptation manual of the low-code platform. By combining the real-time metadata of the low-code platform, the scene feature set is matched and dynamically adjusted according to rules to generate a dynamic evolution rule set, which includes attribute mapping rules, logic compilation rules and adaptation calibration rules. The AI ​​code generation module is invoked, taking the scene feature set and the dynamic evolution rule set as input. The scene features are converted into code structure units by the scene syntax conversion unit of the AI ​​code generation module, and then the code structure units are logically completed and grammatically adapted by the rule execution unit to generate the initial component code. The initial component code is deployed to the test environment of the low-code platform. Functional operation data, resource consumption data, and version compatibility data of the initial component code in the test environment are collected. Based on the matching analysis results of the functional operation data, resource consumption data, and version compatibility data with the scene feature set, iterative optimization instructions are generated. The initial component code and the dynamic evolution rule set are adjusted through the iterative optimization instructions to obtain the optimized target component code. The target component code is embedded into a specified functional module of the low-code platform. The specified functional module is determined based on the functional scene positioning features in the scene feature set to complete the AI-assisted code generation. The process of combining real-time metadata from a low-code platform to perform rule matching and dynamic adjustment on the scene feature set, generating a dynamically evolving rule set, includes: The low-code platform's metadata management system is invoked to obtain the low-code platform's real-time metadata. The real-time metadata includes component attribute metadata, interaction logic metadata, and platform adaptation metadata. The component attribute metadata defines the configurable attribute names, data types, and default values ​​of the component. The interaction logic metadata defines the interactive events, triggering conditions, and execution logic templates supported by the component. The platform adaptation metadata defines the code syntax, interface list, and resource formats supported by different versions of the platform. Collect real-time status data of the low-code platform. The real-time status data includes the current platform's CPU utilization, memory usage, disk I / O rate, number of module loads, module loading time, and interface call success rate. The current platform's CPU utilization, memory usage, disk I / O rate, number of module loads, module loading time, and interface call success rate are used for subsequent rule adjustments. The standardized scene feature items in the scene feature set are matched with the component attribute metadata, the attribute metadata entries corresponding to each standardized scene feature item are identified, the attribute definition rules and data transformation requirements of the successfully matched attribute metadata entries are recorded, and an attribute matching result list is formed. Based on the attribute matching result list, an initial attribute mapping rule is generated. The initial attribute mapping rule includes the method of converting feature identifiers in standardized scene feature items into code attribute names, the method of converting feature types into code data types, and the method of converting feature value ranges into code parameter constraints. Each initial attribute mapping rule corresponds to a matching combination of a standardized scene feature item and an attribute metadata entry. The standardized operation feature items in the scene feature set are matched with the interaction logic metadata, the interaction logic metadata entries corresponding to each standardized operation feature item are identified, the logical template structure and parameter passing rules of the successfully matched interaction logic metadata entries are recorded, and a logical matching result list is formed. Based on the logical matching result list, an initial logical compilation rule is generated. The initial logical compilation rule includes the method of converting the operation identifier in the standardized operation feature item into the code event name, the method of converting the parameter name into the code parameter name, and the method of converting the operation sequence number into the code execution order. Each initial logical compilation rule corresponds to a matching combination of a standardized operation feature item and an interactive logical metadata item. The standardized adaptation feature items in the scene feature set are matched with the platform adaptation metadata, the platform adaptation metadata entries corresponding to each standardized adaptation feature item are identified, the syntax adjustment rules and format calibration requirements of the successfully matched platform adaptation metadata entries are recorded, and an adaptation matching result list is formed. Based on the adaptation matching result list, an initial adaptation calibration rule is generated. The initial adaptation calibration rule includes the method of converting the adaptation type identifier in the standardized adaptation feature item into the code adaptation identifier, the method of converting the requirement content into the code adaptation logic, and the method of converting the compliance basis into the code compliance check logic. Each initial adaptation calibration rule corresponds to a matching combination of a standardized adaptation feature item and a platform adaptation metadata item. The initial attribute mapping rules, the initial logic compilation rules, and the initial adaptation calibration rules are integrated to form an initial rule set; Based on the various indicators in the real-time status data, it is determined whether each indicator exceeds or falls below its respective preset threshold, thereby adjusting the rule priority of the initial rule set. Specifically, when the CPU utilization rate exceeds its preset threshold or the memory usage exceeds its preset threshold, the priority of resource optimization-related rules is increased; when the number of module loads exceeds its preset number or the module loading time exceeds its preset time, the priority of module dependency adaptation-related rules is increased; when the interface call success rate is lower than its preset threshold, the priority of interface call adaptation-related rules is increased. Add dynamic triggering conditions to the rules after priority adjustment, and integrate the rules after priority adjustment with the dynamic triggering conditions to form a dynamic evolution rule set.

2. The AI-assisted code generation method for low-code platforms according to claim 1, characterized in that, The step of obtaining the component requirement scenario information of the low-code platform, and parsing the scenario feature set based on the component requirement scenario information to obtain the scenario feature set, includes: The system receives a text description of a component application scenario submitted by a user through the scenario input interface of a low-code platform. The text description of the component application scenario is then split into semantic units. According to Chinese semantic logic, the text description is split into multiple scenario description statements, and each scenario description statement corresponds to a functional requirement of the component in a specific scenario. Extract scene keywords from each scene description statement, remove duplicates from the extracted scene keywords, and then classify them according to scene dimensions to form a scene keyword classification list. The scene keyword classification list is used as the component of scene description information. The scene keywords include scene object words, function action words, and environment limiting words. The scene dimensions include data processing scenarios, interface display scenarios, and interactive response scenarios. Collect user operation records in the component visual editing interface of the low-code platform, mark the operation type and extract the operation parameters for each operation record to form a detailed list of operation records. The operation records include component addition records, parameter configuration records, logical association records and preview test records. The operation types and operation parameters in the detailed list of operation records are correlated and analyzed. Key operation nodes in the operation sequence are extracted. The operation parameters corresponding to the key operation nodes are integrated with the order of operation to form operation sequence information. The key operation nodes include component selection nodes, parameter confirmation nodes, logic saving nodes and preview trigger nodes. Call the low-code platform's version information interface to obtain the current low-code platform's version identifier and corresponding version adaptation manual. Extract the component development-related adaptation requirements from the version adaptation manual, and divide the adaptation requirements according to the adaptation type to form adaptation baseline information. The adaptation requirements include code syntax specifications, interface call format, resource reference path, and module dependency scope. The adaptation types include syntax adaptation, interface adaptation, resource adaptation, and dependency adaptation. Integrate the scenario description information, the operation sequence information, and the adaptation benchmark information to form component requirement scenario-based information; Feature extraction is performed on the scenario description information in the component requirement scenario information, and each scenario keyword in the scenario keyword classification list is converted into a standardized scenario feature item. Each standardized scenario feature item includes a feature identifier, a feature type, and a feature value range. Feature extraction is performed on the operation sequence information in the component requirement scenario information, and the operation parameters and operation sequence relationship of key operation nodes are converted into standardized operation feature items. Each standardized operation feature item includes operation identifier, parameter name, parameter value and operation sequence number. Feature extraction is performed on the adaptation benchmark information in the component requirement scenario information, and the adaptation requirements of different adaptation types are converted into standardized adaptation feature items. Each standardized adaptation feature item includes an adaptation type identifier, requirement content, and compliance basis. The standardized scene features, the standardized operation features, and the standardized adaptation features are integrated to form a scene feature set.

3. The AI-assisted code generation method for low-code platforms according to claim 2, characterized in that, The semantic unit decomposition of the component application scenario text description, according to Chinese semantic logic, divides the text description into multiple scenario description statements, including: Identify punctuation marks in the text description of the application scenario of the component, including period, comma and semicolon, with period as the main split boundary of the scenario description statement, and comma and semicolon as auxiliary split boundaries; When a period is detected, the text before and after it is divided into independent scenario description statement candidates. When a comma is detected and the functional requirements described by the text before and after it belong to different scenario dimensions, the text before and after the comma is divided into independent scenario description statement candidates. When a semicolon is detected and the functional steps described by the text before and after it have a sequential order, the text before and after the semicolon is divided into independent scenario description statement candidates. The semantic integrity of the scene description statement candidates obtained from the segmentation is judged. Each candidate statement is checked to see if it contains a complete subject-verb-object structure. If the candidate statement is missing a subject, a component is added as the default subject. If the predicate is missing, the implementation is added as the default predicate. If the object is missing, the corresponding functional object is added based on the context. Check whether each candidate statement contains scenario limiting information. If a candidate statement lacks scenario limiting information, mark it as a general scenario and record the marking result. Candidate statements that are semantically complete and have scene-limiting tags are identified as the final scene description statements. The number of scene description statements is counted, and each scene description statement is assigned a sequence number according to its order of appearance in the text. Establish a correspondence table between scene description statements and sequential numbers. In the subsequent feature extraction process, the corresponding scene description statement can be quickly located by sequential number, so that scene features and requirement descriptions are in one-to-one correspondence.

4. The AI-assisted code generation method for low-code platforms according to claim 1, characterized in that, The AI ​​code generation module takes the scene feature set and the dynamic evolution rule set as input, converts the scene features into code structure units through the scene syntax conversion unit of the AI ​​code generation module, and then performs logical completion and syntax adaptation on the code structure units through the rule execution unit to generate initial component code, including: The scene feature set and the dynamic evolution rule set are input into the input processing unit of the AI ​​code generation module. The standardized scene feature items, standardized operation feature items and standardized adaptation feature items in the scene feature set are converted into a feature data format that can be recognized by the scene syntax conversion unit. The feature data format includes a feature identifier field, a feature type field and a feature value range field. The attribute mapping rules, logic compilation rules, and adaptation calibration rules of the dynamic evolution rule set are parsed to extract the trigger condition field, execution logic field, and output format requirement field of each rule, and then converted into a rule data format that can be recognized by the rule execution unit. The transformed feature data is input into the scene syntax conversion unit. The scene syntax conversion unit calls the pre-trained feature syntax mapping model to perform mapping processing on the standardized scene feature items. The content in the feature identifier field is mapped to the code attribute name that conforms to the naming convention of the low code platform. The content in the feature type field is mapped to the corresponding code data type declaration statement. The content in the feature value range field is mapped to the code parameter constraint statement containing condition judgment, and the attribute code fragment is generated. The standardized operation feature items are mapped, the contents of the operation identifier field are mapped to code event declaration statements that conform to the low-code platform event naming convention, the contents of the parameter name field are mapped to the corresponding code parameter declaration statements, and the contents of the operation sequence number field are mapped to code execution sequence control statements containing sequence control keywords, generating logical code fragments; The standardized adaptation feature items are mapped, the content in the adaptation type identifier field is mapped to the code adaptation identifier declaration statement that conforms to the low-code platform adaptation identifier specification, the content in the requirement content field is mapped to the code adaptation logic statement containing the adaptation logic, and the content in the compliance basis field is mapped to the code compliance check statement containing the check conditions, and the adaptation code snippet is generated. The attribute code snippet, the logic code snippet, and the adaptation code snippet are integrated to form an initial code structure unit. The integration process follows the code syntax structure requirements of the low-code platform, placing the attribute code snippet in the head area of ​​the code file, the logic code snippet in the middle area of ​​the code file, and the adaptation code snippet in the tail area of ​​the code file. The initial code structure unit and the transformed rule data are input into the rule execution unit. The rule execution unit first calls the attribute mapping rule to perform syntax verification on the attribute code fragments in the initial code structure unit, corrects characters in the attribute names that do not conform to the platform naming conventions, adjusts the syntax format of the data type declaration statement to conform to the current platform version requirements, supplements the missing condition judgment keywords in the parameter constraint statement, and generates the verified attribute code fragments. The logic compilation rules are invoked to complete the logic code fragments in the initial code structure unit, supplement the missing execution function call statements after the event is triggered, adjust the logical structure of the execution order control statement to conform to the order requirements in the operation sequence information, add logical jump statements to handle abnormal execution scenarios, and generate the completed logic code fragments. Invoke the adaptation calibration rules to perform syntax adaptation on the adaptation code snippets in the initial code structure unit, adjust the interface call format in the adaptation logic statement to conform to the interface specification of the current platform version, correct the conditional judgment expression in the compliance check statement to meet the adaptation requirements, supplement the platform version identifier in the resource reference path, and generate the adapted code snippets. The validated attribute code snippet, the completed logic code snippet, and the adapted code snippet are integrated and concatenated according to the code execution logic order. Code comment information is added, which includes code function descriptions and rule application records, to form the initial component code.

5. The AI-assisted code generation method for low-code platforms according to claim 1, characterized in that, The process involves deploying the initial component code to a low-code platform's test environment, collecting functional operation data, resource consumption data, and version compatibility data of the initial component code in the test environment, and generating iterative optimization instructions based on the matching analysis results of the functional operation data, resource consumption data, and version compatibility data with the scene feature set. These instructions are then used to adjust the initial component code and the dynamic evolution rule set to obtain the optimized target component code. This process includes: The initial component code is deployed to the test environment of a low-code platform. In the test environment, the actual application scenarios of the component are simulated. Various functions of the component are triggered by test scripts. The test scripts include component initialization scripts, function triggering scripts, and abnormal scenario simulation scripts. Functional operation data of the component during function execution is collected. The functional operation data includes function execution result content, function response time data, and function execution error record content. The function execution result content, function response time data, and function execution error record content are used to analyze the degree of matching between the component's functions and scenario requirements. Resource consumption data of components during operation is collected by a resource monitoring tool in the test environment. The resource monitoring tool records data according to a preset collection period. The resource consumption data includes CPU utilization data, memory usage data and disk I / O rate data in each collection period. The CPU utilization data, memory usage data and disk I / O rate data in each collection period are used to analyze the resource consumption of the component during operation. Obtain multiple different versions of platform installation packages from the low-code platform's version repository, build corresponding version test sub-environments in the test environment, deploy the initial component code to each test sub-environment, trigger the component function through the same test script, and collect version compatibility data of the component in different version test sub-environments. The version compatibility data includes the number of successful version adaptations and version-related error records. The number of successful version adaptations and version-related error records are used to analyze the version adaptation capability of the component. The function operation data is matched and analyzed with the standardized scene feature items in the scene feature set. The content of the function execution result is compared with the content of the function requirement description in the scene feature item. The number of tests in which the content of the function execution result is consistent with the content of the requirement description is counted. The proportion of the number of consistent tests to the total number of tests is calculated, and this proportion is used as the function matching degree. Compare the function response time data with the response requirement description in the scenario feature items, count the number of tests in which the function response time data matches the requirement description, calculate the proportion of the number of tests in which the data matches the total number of tests, and use this proportion as the response matching degree. The system records the number of errors related to the scenario requirements in the error logs, calculates the proportion of these errors to the total number of tests, and uses this proportion as the error rate. The resource consumption data is matched and analyzed with the resource demand features in the scene feature set. The resource demand features are extracted from the scene description information. The CPU utilization data, memory usage data and disk I / O rate data in each collection cycle are compared with the resource limit description content in the resource demand features. The number of collection cycles in which each resource consumption data matches the limit description content is counted. The proportion of the number of matching data to the total number of collection cycles is calculated, and this proportion is used as the resource matching degree. The version compatibility data is matched and analyzed with the standardized adaptation features in the scene feature set. The number of successful version adaptations is compared with the adaptation requirements in the adaptation features. The number of versions that meet the requirements is counted, and the proportion of the number of versions that meet the requirements is calculated. This proportion is used as the version matching degree. The number of errors related to the adaptation requirements in the error logs of the version is counted, and the proportion of the number of errors to the total number of test versions is calculated. This proportion is used as the version error rate. The matching degree of the function, the matching degree of the response, the error rate, the matching degree of the resource, the matching degree of the version, and the error rate of the version are integrated to form a matching analysis result. An iterative optimization instruction is generated based on the matching analysis result. When the matching degree of the function is lower than a preset ratio, a function completion instruction is generated. The function completion instruction contains the specific code snippet of the function logic to be supplemented and the scene feature item identifier on which the function implementation is based. When the response matching degree is lower than a preset ratio, a response optimization instruction is generated. The response optimization instruction includes the specific location of the code logic to be optimized and the resource requirement feature identifiers for optimization reference. When the error rate is higher than a preset ratio, an error repair instruction is generated. The error repair instruction includes the specific location of the error to be repaired and a reference case for the error repair method. When the resource matching degree is lower than a preset ratio, a resource optimization instruction is generated. The resource optimization instruction includes the specific code segment with resource consumption to be optimized and the implementation steps of the resource optimization method. When the version matching degree is lower than a preset ratio, a version adaptation optimization instruction is generated. The version adaptation optimization instruction includes the specific location of the adaptation code to be adjusted and the platform adaptation metadata entries for adaptation adjustment. When the version error rate is higher than a preset ratio, a version error repair instruction is generated. The version error repair instruction includes the specific location of the version-related errors to be repaired and the version adaptation manual chapters for error repair. The iterative optimization instructions are input into the code adjustment unit of the AI ​​code generation module. Based on the function completion instructions, missing functional logic parts in the initial component code are supplemented, and specific code snippets of the functional logic to be supplemented are inserted at the corresponding code locations. Based on the response optimization instructions, the response control logic in the code is adjusted, modifying the statement structure at the specific locations of the code logic to be optimized. Based on the error repair instructions, the error locations in the code are modified, and the code content is adjusted according to the reference cases of error repair methods. Based on the resource optimization instructions, the resource consumption part of the code is optimized, replacing the specific code snippets of resource consumption to be optimized with code snippets of lower resource consumption. Based on the version adaptation optimization instructions, the adaptation logic in the code is adjusted, and the content at the specific locations of the adaptation code is modified according to the platform adaptation metadata entries on which the adaptation adjustment is based. Based on the version error repair instructions, the version-related error locations in the code are repaired, and the code content is adjusted according to the requirements of the corresponding chapter in the version adaptation manual, generating the adjusted code snippets. Simultaneously, the iterative optimization instructions are input into the rule adjustment unit. Based on the function completion instructions, the logical compilation rules in the dynamic evolution rule set are adjusted, and execution steps related to logical completion are added to the execution logic field. Based on the response optimization instructions, the attribute mapping rules in the dynamic evolution rule set are adjusted, and response optimization-related parameter constraints are added to the parameter constraint field. Based on the error repair instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and error checking-related judgment conditions are added to the compliance basis field. Based on the resource optimization instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and resource optimization-related restrictions are added to the adaptation requirements field. Based on the version adaptation optimization instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and version adaptation-related operation steps are updated in the execution logic field. Based on the version error repair instructions, the adaptation calibration rules in the dynamic evolution rule set are adjusted, and version error checking-related judgment conditions are added to the compliance basis field. The adjusted code snippet is redeployed to the test environment for verification. The process of collecting runtime data, performing matching analysis, generating optimization instructions, and adjusting code and rules is repeated until the functional matching degree, response matching degree, resource matching degree, and version matching degree in the matching analysis results all reach the preset ratio, and the error rate and version error rate are all lower than the preset ratio, thus obtaining the optimized target component code.

6. The AI-assisted code generation method for low-code platforms according to claim 4, characterized in that, The scene syntax conversion unit calls a pre-trained feature syntax mapping model to map standardized scene feature items. It maps the content in the feature identifier field to code attribute names conforming to low-code platform naming conventions, maps the content in the feature type field to corresponding code data type declaration statements, and maps the content in the feature value range field to code parameter constraint statements containing conditional judgments, generating attribute code snippets, including: The scene syntax conversion unit loads a pre-trained feature syntax mapping model. The feature syntax mapping model is trained using historical component code data and corresponding scene feature data from the low-code platform. The feature syntax mapping model includes a feature identifier mapping layer, a feature type mapping layer, and a feature value range mapping layer. The content of the feature identifier field of the standardized scene feature item is input into the feature identifier mapping layer. The feature identifier mapping layer performs character replacement processing on the input content, replacing special characters that do not conform to the naming conventions of the low-code platform with underscores, converting Chinese words into corresponding English words, adjusting the case of characters according to the format of lowercase first letter and uppercase first letter of subsequent words, and generating code attribute name candidates that conform to the platform naming conventions. Perform duplicate checks on candidate code attribute names, query the list of reserved keywords for the low-code platform, and add a numeric suffix to the end if a candidate code attribute name is a reserved keyword, until a code attribute name that is not a reserved keyword is generated. The content of the feature type field of the standardized scene feature item is input into the feature type mapping layer. The feature type mapping layer converts the content in the feature type field into the corresponding code data type declaration statement according to the preset correspondence between the feature type and the code data type. Specifically, the text type is converted into the string type declaration statement, and the numeric type is converted into the integer type or floating-point type declaration statement. If the content in the feature type field is ambiguous, refer to the functional requirements in the scenario description information to determine the corresponding code data type; The content of the feature value range field of the standardized scene feature item is input into the feature value range mapping layer. The feature value range mapping layer performs logical parsing on the value range content, extracts the upper and lower limits, enumeration values ​​or format requirements of the value range, and generates code parameter constraint statements containing condition judgments. If the value range is a numerical range, a conditional statement containing the condition that is greater than or equal to the lower limit and less than or equal to the upper limit will be generated. If the value range is an enumerated value, a conditional statement containing the condition that is equal to any item in the enumerated value list will be generated. If the value range is a format requirement, a conditional statement containing regular expression matching will be generated. Integrate the generated code attribute names, code data type declaration statements, and code parameter constraint statements, and generate attribute code snippets according to the data type declaration code attribute names; The generated attribute code snippets are syntax-checked to ensure they conform to the syntax specifications of the current low-code platform version. If syntax errors are found, the process returns to the corresponding mapping layer to readjust the mapping rules until a syntactically correct attribute code snippet is generated.

7. The AI-assisted code generation method for low-code platforms according to claim 1, characterized in that, The step of embedding the target component code into a designated functional module of a low-code platform, wherein the determination of the designated functional module is based on the functional scene positioning features in the scene feature set, and completing the AI-assisted code generation, includes: Extract functional scene location features from the scene feature set. The functional scene location features include the module category to which the function belongs, the relationship between the function and other modules, and the function's call entry point location information. Call the module management interface of the low-code platform to obtain a list of all functional modules of the low-code platform. The list of functional modules includes the module name, module category, module interface information and module location information of each functional module. The module category of the function in the functional scenario location feature is matched with the module category in the functional module list, and functional modules with the same module category are selected as candidate functional modules. Based on the functional scene positioning features and the relationship between the functions and other modules, analyze the degree of relationship between the candidate functional modules and other modules, and retain the candidate functional modules whose relationship meets the requirements. Based on the function call entry point location information in the function scenario location features, compare the module location information of the candidate function modules, and determine the function module that matches the call entry point location information as the designated function module. Obtain the code embedding interface information of a specified functional module, wherein the code embedding interface information includes the interface address, interface call parameters and interface return value format; The target component code is encapsulated according to the requirements of the interface call parameters, the parameter information required for the interface call is added, and the encapsulated component code is generated. The module integration tool of the low-code platform sends the encapsulated component code to the code embedding interface address of the specified functional module and passes the corresponding interface call parameters. Receive the execution result returned by the code embedding interface. If the execution result is successful, it means that the target component code has been successfully embedded into the specified functional module. If the execution result is unsuccessful, adjust the encapsulated component code according to the returned error information and resend it to the code embedding interface until the execution result is successful. Call the function verification interface of the low-code platform to perform function verification on the specified function module after embedding the target component code, trigger the core function of the specified function module, and check whether the target component code participates in the function execution normally. If the function verification is successful, the embedding success information is recorded. The embedding success information includes the embedding time, the name of the specified function module and the target component code identifier. If the functional verification fails, the target component code is adjusted according to the verification error information, and the format encapsulation and embedding operations are re-performed until the functional verification passes. An AI-assisted code generation full-process report is generated, which includes a summary of component requirement scenario information, a list of key rules in the dynamic evolution rule set, initial component code optimization records, and target component code embedding results, thus completing the AI-assisted code generation.

8. An AI-assisted code generation system for low-code platforms, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the AI-assisted code generation method for a low-code platform as described in any one of claims 1 to 7 by executing the machine-executable instructions.

9. A computer program product, characterized in that, The computer program product includes machine-executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the machine-executable instructions from the computer-readable storage medium and executes the machine-executable instructions, causing the computer device to perform the AI-assisted code generation method for a low-code platform as described in any one of claims 1 to 7.

Images