Method and system for automatic generation of UI interface based on natural language description

Abstract

The application provides a natural language description-based UI interface automatic generation method and system, which comprises the following steps: receiving a natural language requirement description text, guiding the fuzzy description in the requirement description text for completion, and outputting a standardized requirement text; performing semantic analysis on the standardized requirement text, locating the functional association nodes of UI components and data fields in the text, correcting the analysis deviation through a domain knowledge graph, and obtaining key information including component parameters, field check rules, and component priority; calling a design specification library including scene-specific visual standards and dynamic layout algorithms, and a component library including parameterized configuration functions; performing component matching and parameter adjustment based on the key information, the design specification library, and the component library, obtaining a target component, and generating front-end code or a low-code blueprint of the target component; and performing rendering to obtain a UI interface. In the application, the problems of low requirement transmission efficiency, high development threshold, and difficult multi-end adaptation are overcome.

Description

Technical Field

[0001] This invention relates to the technical field of text data processing, and in particular to a method and system for automatically generating UI interfaces based on natural language description. Background Technology

[0002] With the rapid development of the software industry, the user interface (UI), as the core carrier of human-computer interaction, directly impacts product iteration speed through its development efficiency and standardization. Currently, in UI development, product managers or business personnel typically output UI requirements in natural language (such as documentation or verbal descriptions). However, front-end engineers must translate these natural language requirements into technical code logic. This process is prone to discrepancies between the developed results and expectations due to misunderstandings of the requirements, necessitating multiple rounds of communication and confirmation, significantly extending the development cycle. This cost of aligning requirements across different roles increases further, especially when the requirements include complex interactive logic (such as component linkages and data filtering rules).

[0003] UI development requires front-end engineers to master programming languages ​​such as HTML, CSS, and JS / TS, as well as the application skills of component libraries (such as Element UI and Ant Design) and design specifications (such as Material Design and enterprise-defined specifications), creating a technical barrier for product / business personnel without a technical background. At the same time, many common UI scenarios (such as query pages and data display tables in backend management systems) involve repetitive development work, requiring engineers to repeatedly write similar code. This not only wastes human resources but also easily leads to inconsistent interface styles and compatibility issues due to differences in manual coding.

[0004] Under the current development model, UI adaptation across multiple platforms (PC, mobile, and tablet) requires engineers to adjust the layout, style, and interaction logic separately for different devices. Without the support of a unified dynamic layout algorithm and scenario-specific design specifications, problems such as interface misalignment and functional abnormalities (such as overflowing table columns on mobile devices and delayed component response on PCs) are likely to occur.

[0005] While low-code platforms exist to reduce the difficulty of UI development, users still need to manually drag and drop components and configure parameters through a visual interface, and cannot automatically generate UI based on natural language requirements. Some AI-assisted tools can only generate code for single components (such as buttons and input boxes), and cannot identify the component relationships and data field validation rules in the requirements, making it difficult to meet the requirements for automatic generation of complete UI interfaces.

[0006] In summary, the current UI development process suffers from problems such as inefficient requirement communication, high development threshold, repetitive work, and difficulty in multi-platform adaptation. Summary of the Invention

[0007] The main objective of this invention is to provide a method and system for automatically generating UI interfaces based on natural language description, aiming to overcome the problems of inefficient requirement transmission, high development threshold, and difficulty in multi-platform adaptation in the current UI interface development process.

[0008] To achieve the above objectives, the present invention provides a method for automatically generating UI interfaces based on natural language description, comprising the following steps:

[0009] It receives natural language requirement description text, performs guided completion of ambiguous descriptions in the requirement description text, and outputs standardized requirement text including UI components, data fields, and interaction logic.

[0010] Semantic parsing is performed on the standardized requirement text to locate the functional association nodes between UI components and data fields within the text. Parsing deviations are corrected using a domain knowledge graph to obtain key information including component parameters, field validation rules, and component priorities.

[0011] Access the design specification library, which includes scene-specific visual standards and dynamic layout algorithms, as well as the component library, which includes parameterized configuration functionality;

[0012] Based on the key information and the design specification library and component library, component matching and parameter adjustment are performed to obtain the target component, and the front-end code or low-code blueprint of the target component is generated.

[0013] The front-end code or low-code blueprint is rendered to obtain the UI interface.

[0014] Furthermore, it receives natural language requirement description text, performs guided completion on ambiguous descriptions in the requirement description text, and outputs standardized requirement text including UI components, data fields, and interaction logic, including:

[0015] It receives natural language requirement description text input by the user, extracts keywords from the requirement description text, and compares them with a preset fuzzy description feature library to identify fuzzy description fragments in the requirement description text about UI component types, data field relationships, and interaction logic triggering conditions.

[0016] For the ambiguous description fragment, generate guided completion prompts for the corresponding scenario;

[0017] Receive user feedback on guided completion prompts, integrate the feedback with the natural language requirement description text, and organize it in a structured manner to output standardized requirement text including UI components, data fields, and interaction logic.

[0018] Furthermore, semantic parsing is performed on the standardized requirement text to locate the functional association nodes between UI components and data fields within the text. Parsing deviations are corrected using a domain knowledge graph to obtain key information including component parameters, field validation rules, and component priorities, including:

[0019] The standardized requirement text is segmented into UI component description segment, data field description segment, and interaction logic description segment. Each segment of text is encoded into a vector to construct a semantic feature space.

[0020] In the semantic feature space, a bidirectional attention mechanism is used to perform cross-attention calculation on the UI component description segment and the data field description segment. By superimposing the bidirectional attention weights, the functional association nodes of UI components and data fields in the standardized requirement text are located, and the association strength is marked.

[0021] The functionally associated nodes are compared with the mapping relationships in the pre-built UI domain knowledge graph to correct parsing deviations and obtain corrected parsing results; the UI domain knowledge graph includes multiple sets of mapping relationships between component parameters, field validation rules, and component priorities;

[0022] The corrected parsing results are extracted in a structured manner to obtain key information including component parameters, field validation rules, and component priority.

[0023] Furthermore, based on the aforementioned key information and the design specification library and component library, component matching and parameter adjustment are performed to obtain the target component, and the front-end code or low-code blueprint of the target component is generated, including:

[0024] Based on the component type, component priority, and usage scenario parsed from the key information, candidate components with logical matching are selected from the component library;

[0025] Based on scene-specific visual standards and dynamic layout algorithms in the design specification library, the component parameters of candidate components are adjusted to obtain the target component.

[0026] The code template corresponding to the target component in the component library is called, the adjusted component parameters are embedded in the code template, and the front-end code or low-code blueprint of the target component is generated. For the front-end code template, the parameter placeholders in the code template are automatically replaced and performance optimization tags are embedded. For the low-code blueprint template, the component parameters are mapped to the visual configuration items of the low-code platform.

[0027] Furthermore, when adjusting the component parameters of candidate components, the component style parameters are automatically assigned values ​​according to the visual standards of different scenarios; the component layout parameters are calculated using a dynamic layout algorithm to determine the adaptation value; and the component function parameters are determined by combining the amount of field data in the key information to determine the optimal value.

[0028] Further, the front-end code or low-code blueprint is rendered to obtain a UI interface, including:

[0029] For the aforementioned front-end code, a resource bundling tool is used to package the HTML, CSS, JS / TS files, and related dependencies into a directly loadable resource package; the embedded performance optimization tags are parsed, and the resource loading priority is determined; the corresponding rendering environment is loaded according to the usage scenario of the UI interface, and the resource package is rendered according to the resource loading priority to generate a preview interface;

[0030] For low-code blueprints, the low-code platform's parsing engine converts the visual configuration items in the low-code blueprints into rendering instructions that the platform can recognize, establishing a mapping relationship between the visual configuration items and the rendering results; based on the mapping relationship, the rendering instructions are converted into visual interface elements to obtain a preview interface.

[0031] Verify the completeness of node loading in the preview interface, and verify the adaptation effect through a device compatibility testing framework;

[0032] After all verifications pass, a natural language interaction adjustment entry is generated to receive user input in natural language, parse the adjustment instructions, convert them into corresponding interface style and layout modification instructions, update the rendering results in real time, and finally obtain a functional UI interface that can be directly operated.

[0033] Further, the resource package is rendered according to the resource loading priority to generate a preview interface, including:

[0034] The PC client calls the browser kernel rendering module to render the DOM nodes and styles in the resource package according to the resource loading priority, and generates a preview interface.

[0035] The mobile device uses an adaptation engine to convert the format of the resource package, calls the native application rendering interface, renders the converted resource package according to the resource loading priority, and generates a preview interface.

[0036] Furthermore, after adjusting the component parameters of the candidate components to obtain the target component, the process also includes:

[0037] Extract user historical operation data and terminal device parameters from key information, and determine the performance of the terminal device based on the terminal device parameters;

[0038] The gradient boosting algorithm is used to analyze the matching degree between the performance of the terminal device and the resource consumption of the target component, and the resource consumption of the target component is adjusted according to the matching degree.

[0039] Adjust the layout priority of target components based on users' historical operation data.

[0040] This invention also provides a UI interface automatic generation system based on natural language description, comprising:

[0041] The receiving unit is used to receive natural language requirement description text, perform guided completion of ambiguous descriptions in the requirement description text, and output standardized requirement text including UI components, data fields, and interaction logic.

[0042] The parsing unit is used to perform semantic parsing on the standardized requirement text, locate the functional association nodes between UI components and data fields in the text, correct parsing deviations through domain knowledge graphs, and obtain key information including component parameters, field validation rules, and component priorities.

[0043] The retrieval unit is used to retrieve a design specification library that includes scene-specific visual standards and dynamic layout algorithms, as well as a component library that includes parameterized configuration functions;

[0044] The generation unit is used to perform component matching and parameter adjustment based on the key information and the design specification library and component library to obtain the target component and generate the front-end code or low-code blueprint of the target component.

[0045] The rendering unit is used to render the front-end code or low-code blueprint to obtain the UI interface.

[0046] The present invention provides a method and system for automatically generating UI interfaces based on natural language description, comprising: receiving natural language requirement description text; performing guided completion on ambiguous descriptions in the requirement description text; and outputting standardized requirement text including UI components, data fields, and interaction logic; performing semantic analysis on the standardized requirement text; locating functional association nodes between UI components and data fields within the text; correcting analysis deviations through a domain knowledge graph; obtaining key information including component parameters, field validation rules, and component priorities; retrieving a design specification library including scene-specific visual standards and dynamic layout algorithms, as well as a component library including parameterized configuration functions; performing component matching and parameter adjustment based on the key information, the design specification library, and the component library to obtain target components, and generating front-end code or low-code blueprints for the target components; and rendering the front-end code or low-code blueprints to obtain the UI interface. In this invention, guided completion is performed on ambiguous descriptions in the requirement description text to locate functional association nodes between UI components and data fields within the text. Domain knowledge graphs are used to correct parsing deviations, yielding key information including component parameters, field validation rules, and component priorities, facilitating the acquisition of complete user requirements. After obtaining the target component, the front-end code or low-code blueprint of the target component is directly generated and rendered to obtain the UI interface, lowering the development threshold and improving development efficiency. This overcomes the problems of inefficient requirement transmission, high development threshold, and difficulty in multi-platform adaptation in current UI interface development processes. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the steps of an automatic UI interface generation method based on natural language description in one embodiment of the present invention;

[0048] Figure 2 This is a structural block diagram of a system for automatically generating UI interfaces based on natural language description in one embodiment of the present invention;

[0049] Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0050] The implementation, functional features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0052] It is particularly important to note that all technical steps, algorithm applications, and parameter settings in the technical solution of this application have clear technical objectives and application value. They do not utilize complex steps and algorithmic formulas to achieve simple functions. To provide detailed explanations of each step and avoid ambiguity, some conventional algorithms are used for illustration. However, this does not mean that the algorithms and technical features listed herein are the only way to implement the technical solution of this application, nor is it intended to limit the scope of protection of this application. This application is not a combination or stacking of the listed algorithms and technical features; its essence is to exemplify the implementation methods of this application to fully explain it. It does not pursue formal complexity by adding meaningless technical steps, nor does it involve the accumulation of technologies divorced from practical needs; it conforms to the conventional logic of technical improvement and design.

[0053] Reference Figure 1 One embodiment of the present invention provides a method for automatically generating a UI interface based on natural language description, comprising the following steps:

[0054] Step S1: Receive natural language requirement description text, perform guided completion on ambiguous descriptions in the requirement description text, and output standardized requirement text including UI components, data fields, and interaction logic;

[0055] Step S2: Semantic parsing is performed on the standardized requirement text to locate the functional association nodes between UI components and data fields within the text. Parsing deviations are corrected through a domain knowledge graph to obtain key information including component parameters, field validation rules, and component priorities.

[0056] Step S3: Retrieve the design specification library, which includes scene-specific visual standards and dynamic layout algorithms, as well as the component library, which includes parameterized configuration functions;

[0057] Step S4: Based on the key information and the design specification library and component library, perform component matching and parameter adjustment to obtain the target component, and generate the front-end code or low-code blueprint of the target component;

[0058] Step S5: Render the front-end code or low-code blueprint to obtain the UI interface.

[0059] In this embodiment, the core objective of step S1 is to transform unstructured and ambiguous natural language requirements into structured, unambiguous, standardized requirement text, providing accurate input for subsequent semantic analysis. Specifically, the system first receives natural language requirement description text input by product managers or business personnel. This text may contain free descriptions of UI interface functions, component forms, data display formats, and interaction methods (e.g., "Generate a page that can query user information, including relevant search and data display functions"). Due to the inherent defects of natural language, such as ambiguity and missing information (e.g., not specifying "the input type of the search component," "the specific fields of the data display," or "interaction triggering conditions"), a fuzzy description identification mechanism is activated. Through a pre-built UI requirement corpus and semantic feature comparison algorithm, fuzzy description fragments or missing information regarding UI component types, data field ranges, and interaction logic details in the text are located. For the identified problems, guided completion prompts are automatically generated (e.g., "Please clarify the query fields corresponding to the search component (e.g., user name / ID)" or "Do we need to add filtering conditions for the data display?"). The system also receives supplementary feedback from users, integrates and organizes the original requirement text with the supplementary information, and finally outputs a structured, standardized requirement text. The standardized requirements document must clearly include three core elements: the specific type of the required UI component (such as a search box, a data table, or a filter), the definition of the data fields involved (such as user name, creation date, or order number), and the interaction logic between components (such as triggering table data filtering after entering information in the search box, or updating data in real time after the filter conditions change). This ensures that the requirements information is complete and unambiguous, providing a unified basis for subsequent steps.

[0060] Step S2 is the core step in converting natural language into technical information. Through precise semantic parsing and bias correction, key technical information required for UI generation is extracted from the standardized requirement text. Taking the standardized requirement text output from step S1 as input, the semantic parsing engine is activated to perform in-depth analysis of the text. Through operations such as grammatical structure decomposition and semantic feature extraction, the core expressions related to UI components and data fields in the text are identified. At the same time, a functional association positioning algorithm is used to discover the logical association nodes between UI components and data fields (such as the query association between "user name search box" and "user information table", and the filtering association between "creation date filter" and "table data time range"), clarifying the correspondence and linkage logic between components and data. Considering that semantic parsing may lead to parsing deviations due to differences in text expression habits and domain terminology (such as misjudging a "query box" as a non-standard component or omitting data field validation requirements), a pre-built UI domain knowledge graph is invoked. This knowledge graph contains knowledge in areas such as component type and standard name mapping, data field and validation rule association, and component interaction logic templates. By comparing the preliminary parsing results with the standard information in the knowledge graph, parsing deviations are corrected (such as correcting the "query box" to the standard component "search box" and supplementing the rule that "the mobile phone number field must meet 11-digit validation"). Finally, after parsing and correction, the system outputs structured data containing three main categories of key information: UI component parameters (such as input format restrictions for the search box and the number of pagination rows in the table), data field validation rules (such as field type, value range, and format validation logic), and component priorities (such as query components having higher priority than statistical components and core data display components having higher priority than auxiliary function components), providing technical support for component matching and code generation.

[0061] Step S3 serves to provide standardized resource support for UI component matching, parameter adjustment, and code generation, ensuring that the generated UI interface conforms to visual specifications, layout adaptation requirements, and is reusable. Based on the key information extracted in step S2 (especially component type and usage scenario information), the system automatically retrieves two pre-stored core resource libraries: First, a design specification library, which includes UI visual standards for different scenarios (such as font size, color theme, and component spacing for PC backend management systems, and adapted fonts and touch hotspot sizes for mobile apps), dynamic layout algorithms (such as responsive grid layout rules and adaptive component arrangement logic for different screen sizes), and cross-environment compatibility requirements (such as browser compatibility version range and mobile system adaptation standards), providing constraints for the visual consistency and layout rationality of the UI interface. Second, a component library, which stores a large number of reusable front-end UI components with parameterized configuration capabilities (such as search boxes, data tables, filters, buttons, etc.). Each component is associated with a corresponding standard code template (HTML / CSS / JS / TS) and parameter configuration interface, supporting flexible adaptation of component functionality and form by adjusting parameters (such as the number of table columns, button styles, and filter options), eliminating the need to develop component code from scratch and improving development efficiency and component reusability. By accessing two major resource repositories, a connection between "technical requirements and standardized resources" is established, laying the foundation for accurate matching and standardized generation of components in subsequent steps.

[0062] Step S4 is the core step in transforming key information and standardized resources into technical implementation. Through intelligent matching and precise adjustment, it generates front-end code or low-code blueprints that meet the requirements. The specific process is as follows: Based on the key information extracted in step S2, combined with the design specification library and component library retrieved in step S3, the intelligent component matching engine is activated. Following the logic of "component type matching → scenario adaptability filtering → priority fit sorting," the engine filters candidate components from the component library that best match the requirements (e.g., for "data query requirements of the backend management system," matching data table components with pagination functionality and support for multi-field filtering). Subsequently, based on the scenario-specific visual standards and dynamic layout algorithms in the design specification library, the parameters of the candidate components are automatically adjusted, including style parameters (such as component color, rounded corners, and font size to ensure compliance with visual specifications), functional parameters (such as the number of table pagination rows and search box suggestion function to ensure fulfillment of required functions), and layout parameters (such as the component's position and proportion on the page to ensure compliance with dynamic layout requirements). After parameter adjustment, the parameter information of the target component is embedded into the corresponding code template, automatically generating executable front-end code (HTML / CSS / JS / TS). This involves either a combination of components or a low-code blueprint (visual configuration file). During code generation, the component library's coding standards are followed to ensure correct syntax and direct execution. The low-code blueprint must be compatible with mainstream low-code platforms and support visual editing and secondary adjustments. This step significantly reduces repetitive coding workload through standardized component reuse and parameterized configuration, while ensuring that the generated technical deliverables meet design specifications and functional requirements.

[0063] Step S5 is the final implementation stage of the technical solution, transforming abstract code or blueprints into a directly operable visual UI interface through rendering. Receiving the front-end code or low-code blueprint generated in step S4, the system starts the rendering engine to execute the rendering process: For front-end code, the rendering engine first loads the associated dependent resources (such as style files and script files), then renders page nodes and loads component functions sequentially according to the DOM structure definition and logical instructions in the code, generating a visual interface; for low-code blueprints, the rendering engine parses the visual configuration items and component relationships in the blueprint, transforming them into corresponding page elements and interaction logic to achieve a visual presentation of the interface. During the rendering process, the system simultaneously verifies the integrity of the interface (e.g., whether all components are loaded and whether functions are triggered normally) and its adaptability (e.g., whether it conforms to the visual and layout requirements in the design specification library), ensuring that the interface has no missing components, no style errors, and no functional abnormalities. After rendering is complete, the system outputs a directly operable functional UI interface, through which users can perform interactive operations (e.g., inputting query conditions, filtering data, and viewing results), realizing the UI functions corresponding to natural language requirements.

[0064] In one embodiment, a natural language requirement description text is received, and guided completion is performed on ambiguous descriptions in the requirement description text to output a standardized requirement text including UI components, data fields, and interaction logic, including:

[0065] It receives natural language requirement description text input by the user, extracts keywords from the requirement description text, and compares them with a preset fuzzy description feature library to identify fuzzy description fragments in the requirement description text about UI component types, data field relationships, and interaction logic triggering conditions.

[0066] For the ambiguous description fragment, generate guided completion prompts for the corresponding scenario;

[0067] Receive user feedback on guided completion prompts, integrate the feedback with the natural language requirement description text, and organize it in a structured manner to output standardized requirement text including UI components, data fields, and interaction logic.

[0068] In this embodiment, taking the product manager's input requirement of "create an order query page with search, table, and time filtering, and be able to export data" as an example, the first step is to identify ambiguities in the requirement. The main purpose is to find vague descriptions that may cause problems in subsequent development. Specifically, NLP tools are used to break down the requirement, extracting key information from "create an order query page with search, table, and time filtering, and be able to export data." This includes "search, table, and time filtering" related to components, "export data" related to operations, and "order query page" related to the scenario, while automatically removing useless phrases like "create" and "must have." Next, the extracted key information is compared with a pre-stored "UI requirement fuzzy feature library." This feature library records common ambiguities in UI requirements, such as only mentioning "search" without specifying whether it's a single-line search box or a multi-condition search bar, only mentioning "table" without specifying what specific content to display, and only mentioning "time filtering" without explaining how to trigger the filtering. By comparing the requirements, we can quickly identify three unclear points: the "search" component doesn't specify its type, the "table" component doesn't specify which fields to display, and the "time filter" component doesn't specify how to trigger it. This step will clarify these three ambiguities, setting the direction for supplementing the information later.

[0069] After identifying the unclear points, it's time to guide users to fill in the missing information. Based on the three points of ambiguity found and the scenario of the order query page, provide precise prompts to help users efficiently complete the information. For example, regarding "What type of search is used?", the prompt will say, "There are two common types of searches on the order query page: one is a single-line search box, suitable for searching a single order number; the other is a multi-condition search bar, which allows you to enter both the order number and customer name to search. Which one do you choose?" Regarding "Which fields should be displayed in the table?", the prompt will say, "The order table must have at least two fields: order number, order time, and order amount; optional fields include customer name and logistics status. Choose whichever you want to display, and also confirm whether the table should be linked to the customer information table." Regarding "How is time filtering triggered?", the prompt will say, "There are two ways to trigger time filtering: one is to select a time point and then click the filter button, and the other is to select a time point and trigger it automatically; there are also two ways to update the data after filtering: one is for the table to change in real time, and the other is to pop up a result count prompt. Choose the corresponding method." Users will make choices based on their actual business needs, such as selecting a multi-condition search bar, making order number + order time + order amount mandatory fields, customer name optional field linked to the customer information table, and triggering a filter button to update the table in real time. These choices will be noted down, forming clear requirements details, which will prepare for later standardization.

[0070] Finally, the requirements are formalized into a standardized text. The initial natural language requirements are combined with clear details provided by the user, and then organized according to a fixed structure that machines can understand and developers can directly use, forming a standardized text. This text contains three parts: The first part is a list of UI components, clarifying the type and function of each component. For example, the multi-condition search bar supports searching by order number and customer name together; the order table displays the order number (as the primary identifier, linked to the customer information table), order time, order amount, and customer name (optional); the time filter is triggered by clicking the filter button and the table updates in real time after filtering; and the export button exports the currently displayed order data in the table. The second part is a list of data fields, clarifying the rules for each field. The third part is a list of interaction logic, clarifying the linkage between components. For example, clicking the filter button in the time filter refreshes the data in the order table, and clicking the export button only exports the currently filtered order data in the table. This standardized requirements text is then directly passed to the next step of semantic parsing to ensure that subsequent processes accurately connect with the original requirements and avoid information discrepancies.

[0071] In one embodiment, semantic parsing is performed on the standardized requirement text to locate functional association nodes between UI components and data fields within the text. Parsing deviations are corrected using a domain knowledge graph to obtain key information including component parameters, field validation rules, and component priorities, including:

[0072] The standardized requirement text is segmented into UI component description segment, data field description segment, and interaction logic description segment. Each segment of text is encoded into a vector to construct a semantic feature space.

[0073] In the semantic feature space, a bidirectional attention mechanism is used to perform cross-attention calculation on the UI component description segment and the data field description segment. By superimposing the bidirectional attention weights, the functional association nodes of UI components and data fields in the standardized requirement text are located, and the association strength is marked.

[0074] The functionally associated nodes are compared with the mapping relationships in the pre-built UI domain knowledge graph to correct parsing deviations and obtain corrected parsing results; the UI domain knowledge graph includes multiple sets of mapping relationships between component parameters, field validation rules, and component priorities;

[0075] The corrected parsing results are extracted in a structured manner to obtain key information including component parameters, field validation rules, and component priority.

[0076] In this embodiment, the standardized requirement text is first divided into three segments based on information type: UI component description, data field description, and interaction logic description. The UI component description includes the type and function of each component (e.g., "The multi-condition search bar supports combined queries of order number and customer name," "The order table displays fields such as order number and order time"). The data field description includes the rule definitions for each field (e.g., "The order number is a unique string," "The order time is in YYYY-MM-DD format"). The interaction logic description includes the linkage relationships between components (e.g., "The order table data refreshes after clicking the filter button in the time filter"). After the segmentation, a pre-trained text encoder (e.g., a domain-adaptive model based on BERT) is invoked to convert the three segments into high-dimensional semantic vectors. The encoder combines UI domain-specific word vectors to capture the implicit technical semantics in the text, ultimately generating semantic vectors corresponding to the three segments. These three sets of vectors are then integrated to construct a unified semantic feature space containing semantic information about components, fields, and interaction logic, providing a vector computation foundation for subsequent component and field association and localization.

[0077] Next, a bidirectional attention mechanism is used to locate functional association nodes. To accurately uncover the intrinsic relationships between UI components and data fields, a bidirectional attention mechanism is embedded in the semantic feature space, performing cross-attention calculations on the semantic vectors of UI component description segments and data field description segments. Specifically, the forward attention layer uses the UI component description segment vector as the query end and the data field description segment vector as the key value end, calculating the association weight between each component (such as a multi-condition search bar or an order form) and each data field (such as order number, customer name, and order time). The higher the weight value, the stronger the component's dependence on that field. The reverse attention layer uses the data field description segment vector as the query end and the UI component description segment vector as the key value end, calculating the association weight between each data field and each component. By superimposing the forward and reverse attention weights, component-field pairs with a total weight greater than or equal to a threshold can be selected. These pairings are defined as functional association nodes between UI components and data fields, and the association strength (i.e., the total weight) of each node is simultaneously marked, providing clear association objects for subsequent deviation correction.

[0078] Next, parsing bias correction is performed based on the UI domain knowledge graph. Since segmented encoding and attention calculation may have semantic discrepancies, a pre-built UI domain knowledge graph is called for bias correction. This knowledge graph uses a "component-field-rule-priority" core architecture and stores multiple sets of standardized mapping relationships: including "component type-associated field range" mapping and "component-field association strength threshold" mapping, while also containing standardized knowledge such as component parameters, field validation rules, and component priorities. The functional association nodes located in the previous step are compared with the component-field association range and strength threshold mapping in the knowledge graph: if the association strength of the order table-logistics status is found to be higher than the optional field threshold, it is determined to be a parsing bias, the association strength is automatically corrected, and the "optional association" attribute is marked; if the "multi-condition search bar" is found not to be associated with the "customer name field," the association node of "multi-condition search bar-customer name" is added, and the association strength is set to the preset value. Through this process, the system completes the correction of parsing bias and obtains a corrected parsing result that conforms to domain standards.

[0079] Finally, the corrected parsing results are extracted into a structured format. To facilitate subsequent steps, the corrected parsing results need to be converted into structured data. Specifically, information extraction is performed along three dimensions: "component parameters," "field validation rules," and "component priority." In terms of component parameters, standard parameters for each component are matched from the knowledge graph, and related fields are added based on associated nodes. In terms of field validation rules, validation logic for each field is extracted and associated with the corresponding component. In terms of component priority, based on the "scene-component priority" mapping in the knowledge graph, display-type components have higher priority than operation-type components, determining the priority order of each component. After extraction, this information is organized in JSON format to form structured key information containing component parameters, field validation rules, and component priority. This information is then directly transmitted to the resource library retrieval stage, providing accurate technical support for subsequent component matching and parameter adjustments.

[0080] In one embodiment, based on the key information and the design specification library and component library, component matching and parameter adjustment are performed to obtain the target component, and the front-end code or low-code blueprint of the target component is generated, including:

[0081] Based on the component type, component priority, and usage scenario parsed from the key information, candidate components with logical matching are selected from the component library;

[0082] Based on scene-specific visual standards and dynamic layout algorithms in the design specification library, the component parameters of candidate components are adjusted to obtain the target component.

[0083] The code template corresponding to the target component in the component library is called, the adjusted component parameters are embedded in the code template, and the front-end code or low-code blueprint of the target component is generated. For the front-end code template, the parameter placeholders in the code template are automatically replaced and performance optimization tags are embedded. For the low-code blueprint template, the component parameters are mapped to the visual configuration items of the low-code platform.

[0084] In this embodiment, the first step is candidate component screening based on key information. To ensure that the selected components highly match the requirements, the system extracts three core screening dimensions from the key information: component type, component priority, and usage scenario. These serve as triple filtering conditions for component library retrieval. Component type is the basic screening criterion. First, based on the component type specified in the key information, similar components are initially screened from the component library. Next, a second screening is performed based on component priority. According to the rule in the key information that "query-type components have higher priority than display-type components," templates with more complete functions corresponding to higher-priority components are retained first. Finally, precise filtering is performed based on usage scenario, eliminating component templates that are incompatible with the scenario. Through this triple screening logic, 3-5 logically matching candidate components are selected from the component library, providing alternatives for subsequent parameter adjustments.

[0085] Next, the parameters of candidate components are adjusted based on the design specification library. To ensure that components meet visual consistency, layout rationality, and functional adaptability, the scene-specific visual standards and dynamic layout algorithms in the design specification library are invoked to standardize and adjust the parameters of candidate components. The adjustment process revolves around three dimensions: "style parameters," "layout parameters," and "functional parameters." Regarding style parameter adjustment, the visual attributes of components are unified according to the visual standards of the "Backend Management System - Order Query Page" in the design specification library to ensure that the component style is consistent with the overall interface style. Regarding layout parameter adjustment, the optimal layout parameters of components on the page are calculated using dynamic layout algorithms (such as responsive grid layout algorithms) in the design specification library (e.g., the multi-condition search bar occupies 100% of a 1920px wide screen with 24px margins on each side; the order table is below the multi-condition search bar with a 16px gap from the search bar, also occupying 100% of the screen; the time filter is embedded to the right of the multi-condition search bar with a width of 220px), ensuring that components are not misaligned or overflowing on the target screen size. Regarding functional parameter adjustment, the functional attributes of candidate components are configured based on the component parameter requirements in the key information. After the parameters are adjusted, a preview of the adjusted component is generated. If the preview meets the design specifications and requirements, the component is selected as the target component. If there are deviations (such as styles that do not conform to visual standards or abnormal spacing in the layout), the parameters in the design specification library are called again for fine-tuning until the requirements are met.

[0086] Finally, front-end code or low-code blueprints are generated based on component templates. The code template (front-end code template or low-code blueprint template) corresponding to the target component in the component library is called, and the adjusted component parameters are embedded into the template to generate a directly usable technical output. For front-end code templates (including HTML, CSS, and JS / TS files), parameter placeholders in the template are parsed and automatically replaced, while performance optimization tags are embedded to generate syntactically correct and performance-optimized executable front-end code. For low-code blueprint templates (including visual component configuration items and property mapping rules), the adjusted component parameters are mapped to visual configuration items of the low-code platform, and a mapping table between parameters and configuration items is generated to ensure that configuration items are updated synchronously when parameters are modified in the low-code platform. After the code or blueprint is generated, it is checked using syntax validation tools (such as ESLint to validate the front-end code and the low-code platform's built-in validator to validate the blueprint) to ensure there are no syntax errors or configuration conflicts, and finally, the front-end code or low-code blueprint of the target component is output.

[0087] In one embodiment, when adjusting the component parameters of candidate components, the component style parameters are automatically assigned values ​​according to the scene-specific visual standards; the component layout parameters are calculated using a dynamic layout algorithm to determine the adaptation value; and the component function parameters are determined by combining the amount of field data in the key information to determine the optimal value.

[0088] In one embodiment, the front-end code or low-code blueprint is rendered to obtain a UI interface, including:

[0089] For the aforementioned front-end code, a resource bundling tool is used to package the HTML, CSS, JS / TS files, and related dependencies into a directly loadable resource package; the embedded performance optimization tags are parsed, and the resource loading priority is determined; the corresponding rendering environment is loaded according to the usage scenario of the UI interface, and the resource package is rendered according to the resource loading priority to generate a preview interface;

[0090] For low-code blueprints, the low-code platform's parsing engine converts the visual configuration items in the low-code blueprints into rendering instructions that the platform can recognize, establishing a mapping relationship between the visual configuration items and the rendering results; based on the mapping relationship, the rendering instructions are converted into visual interface elements to obtain a preview interface.

[0091] Verify the completeness of node loading in the preview interface, and verify the adaptation effect through a device compatibility testing framework;

[0092] After all verifications pass, a natural language interaction adjustment entry is generated to receive user input in natural language, parse the adjustment instructions, convert them into corresponding interface style and layout modification instructions, update the rendering results in real time, and finally obtain a functional UI interface that can be directly operated.

[0093] In this embodiment, the first step is the rendering of the front-end code. To transform the scattered front-end code into a visual interface, three core steps are required: resource packaging, performance optimization analysis, and scenario-based rendering. In the resource packaging stage, a resource packaging tool (such as Webpack or Vite) is used to integrate and package the HTML files (defining the interface structure), CSS files (defining interface styles), JS / TS files (defining interaction logic), and related dependencies (such as component library style files and third-party tool scripts) contained in the front-end code. The tool automatically handles dependencies between files (such as font resources imported in CSS files and component modules called in JS files), compresses redundant code (such as removing duplicate styles in CSS and unused variables in JS), and finally generates a static resource package that can be directly loaded, ensuring efficient resource loading. In the performance optimization analysis stage, performance optimization markers embedded in the resource package are scanned, and resource loading priorities are determined based on the marker type: core component resources are set to the highest priority to ensure that core functions are rendered first during initial page load; non-core component resources are set to low priority and delayed until the core resources are loaded to avoid initial loading blockage. In the scenario-based rendering stage, the corresponding rendering environment is loaded first according to the usage scenario of the UI interface. On PC, the browser's kernel rendering module is invoked; on mobile, the native application rendering interface is invoked. Then, according to the determined resource loading priority, resources in the resource package are loaded and rendered sequentially: first, the HTML and CSS resources of core components are loaded to build the basic interface structure and styles; then, the JS resources of core components are loaded to implement core interactive logic such as querying and filtering; finally, lower-priority resources are loaded to add detailed interface effects. Once all resources are loaded and rendered, a preview interface is generated, providing a preliminary view of the UI's functionality and form.

[0094] Next is the rendering process for low-code blueprints. Since low-code blueprints exist as visual configuration items, they need to be parsed and transformed for rendering. This is mainly accomplished through three steps: parsing engine processing, mapping relationship establishment, and UI element generation. In the parsing engine processing stage, the low-code platform's dedicated parsing engine is invoked to perform semantic parsing on the visual configuration items in the low-code blueprint. The engine converts each configuration item into standardized rendering instructions that the platform can recognize, according to the low-code platform's configuration rules. In the mapping relationship establishment stage, the association between each visual configuration item and its corresponding rendering instructions and rendering results is recorded, forming a two-way mapping table of "configuration item - rendering instruction - rendering result". For example, the "maximum length of input box" configuration item corresponds to the "set maxlength attribute" instruction, the rendering result of which is "the input box only allows 50 characters". If the configuration item needs to be modified later, the corresponding rendering instruction and result can be quickly located through the mapping table to ensure that the modification takes effect synchronously. In the interface element generation stage, based on the above mapping relationship, all rendering instructions are transformed into visual interface elements according to the interface structure logic: first, basic container elements (such as the main page div, partition container) are generated, then functional component elements (such as the input box of the multi-condition search bar, the header and row data of the order table, the selection box of the time filter) are generated, and finally interactive control elements (such as filter button, export button) are generated. Each element automatically inherits the style and functional attributes corresponding to the configuration items, and finally forms a preview interface consistent with the rendering result of the front-end code.

[0095] Next is the multi-dimensional verification of the preview interface. To ensure that the interface functions normally and meets the adaptation standards, verification is required from two dimensions: node integrity and device compatibility. In the node integrity verification stage, DOM structure inspection tools (such as Chrome DevTools' DOM Inspector, the automated testing tool Playwright) are called to scan the DOM tree nodes of the preview interface: check whether the core component nodes (such as the input box node of the multi-condition search bar, the tbody node of the order table, and the button node of the filter button) are all loaded (no missing, no duplicate), whether the style nodes associated with the components (such as the style rules corresponding to the CSS class) are working properly (no missing styles, no style conflicts), and whether the interaction logic nodes (such as the click events and input events bound by JS) are successfully mounted (no unbound events, no duplicate event bindings); if a node is found to be missing (such as the table tbody node not being loaded) or the function is abnormal (such as the filter button click event not being bound), the root cause of the problem is located (such as the failure to load the resource package, or the rendering instruction error), and the process is rolled back to the corresponding rendering stage for reprocessing. In the device compatibility verification phase, a device compatibility testing framework is invoked to simulate different devices and environments under the target usage scenario: the PC scenario simulates the latest three versions of different browsers, and the mobile scenario simulates devices of different brands and screen sizes (such as 6.1 inches and 7.9 inches); the adaptation effect of the preview interface in each environment is verified. Check for misalignment of interface elements (such as buttons exceeding container boundaries, table columns overflowing), style abnormalities (such as inconsistent font sizes, color display deviations), and functional failures (such as unresponsive filtering operations on mobile devices); if adaptation issues exist (such as incomplete table borders in Firefox), the compatibility configuration in the design specification library is invoked (such as supplementing Firefox-specific CSS prefixes), re-rendering and verification are performed again until the adaptation effect in all environments meets the requirements.

[0096] To meet users' personalized adjustment needs, an interactive adjustment mechanism is activated after verification, enabling flexible modifications through a natural language entry point. First, a natural language interactive adjustment entry point is generated in a fixed area of ​​the preview interface (such as the top toolbar). This entry point provides a text input box and operation buttons, supporting user input of natural language adjustment commands. Next, after receiving the user's input adjustment command, the semantic parsing module is invoked to perform deep analysis of the command: first identifying the adjustment object, then extracting the adjustment dimensions, and finally determining the adjustment parameters. Subsequently, the parsing results are converted into corresponding interface style and layout modification commands. For example, "increase row height by 5px" is transformed into the style instruction "modify the line-height property of the order table's tr element, adding 5px to the original value," and "hide the export button" is transformed into the layout instruction "add display:none style to the button element of the export button." Finally, the modification instructions are executed and the rendering results are updated in real time, allowing users to intuitively view the adjusted interface effect. If the user is satisfied with the effect, clicking the confirmation button will lock the interface state, generating the final, directly operable functional UI interface. This interface includes complete query, filtering, and export functions, supporting users to perform actual business operations (such as entering order numbers to query data, selecting time ranges to filter orders, and clicking the export button to download table data), while maintaining consistency with design specifications and adaptability to multiple devices.

[0097] In one embodiment, rendering the resource package according to the resource loading priority and generating a preview interface includes:

[0098] The PC client calls the browser kernel rendering module to render the DOM nodes and styles in the resource package according to the resource loading priority, and generates a preview interface.

[0099] The mobile device uses an adaptation engine to convert the format of the resource package, calls the native application rendering interface, renders the converted resource package according to the resource loading priority, and generates a preview interface.

[0100] In one embodiment, after adjusting the component parameters of the candidate components to obtain the target component, the method further includes:

[0101] Extract user historical operation data and terminal device parameters from key information, and determine the performance of the terminal device based on the terminal device parameters;

[0102] The gradient boosting algorithm is used to analyze the matching degree between the performance of the terminal device and the resource consumption of the target component, and the resource consumption of the target component is adjusted according to the matching degree.

[0103] Adjust the layout priority of target components based on users' historical operation data.

[0104] In this embodiment, firstly, two types of core data are extracted from the extended data module of key information: one is user historical operation data, which includes records of user behavior when using similar UI interfaces in the past and interactive feedback data during the operation process; the other is terminal device parameters, obtained through the front-end device detection interface or device information reported when the user logs in, covering three types of indicators: hardware parameters, system parameters, and display parameters. Subsequently, a performance evaluation model is established based on the terminal device parameters to classify and determine device performance. From a hardware perspective, based on processor clock speed, memory capacity, and graphics card performance level, devices are divided into high-performance devices, medium-performance devices, and low-performance devices. From a system and display perspective, if the device's operating system version is too old or the browser kernel does not support modern rendering technology, the hardware performance level is lowered by one level; if the screen resolution and refresh rate are low, a low display performance attribute needs to be marked simultaneously. Finally, the system outputs the terminal device's performance level label and corresponding performance threshold as the core basis for adjusting resource consumption.

[0105] Next, the resource consumption dimensions of the target component are defined, mainly including two categories of indicators: rendering resource consumption and runtime resource consumption. Benchmark resource consumption data of the target component under standard conditions is collected using performance monitoring tools. A gradient boosting algorithm is used to construct a performance-resource matching model to analyze the matching degree between the terminal device's performance and the target component's resource consumption. The algorithm uses the terminal device's performance level label and performance threshold as input features, and the benchmark resource consumption data of the target component as the evaluation object, calculating the deviation value between each resource consumption dimension and the device performance threshold. Through multiple rounds of iterative training, a mapping relationship between the deviation value and the resource consumption adjustment coefficient is established. Based on the adjustment coefficient, the resource consumption of the target component is optimized in a targeted manner, covering both rendering and runtime resource dimensions. After optimization, performance retesting tools are used to verify whether the resource consumption meets the device performance threshold. If deviations still exist, the adjustment coefficients are iterated again until all resource consumption dimensions meet the device's carrying capacity, ensuring that the component runs smoothly on the target terminal.

[0106] Then, structured analysis is performed on user historical operation data to extract two key behavioral features: operation frequency and operation efficiency. Operation frequency is determined by statistically analyzing the number and frequency of user operations on each functional element of the target component, forming an operation frequency ranking. Operation efficiency is determined by analyzing the average time users spend completing core operations, identifying efficiency bottlenecks caused by unreasonable layout. Based on these features, the layout priority of the target component is optimized hierarchically: elements with high-frequency operations in the operation frequency ranking are moved to the visual focus area of ​​the interface, while increasing the touch hotspot of these elements; layout relationships are adjusted to address operation efficiency bottlenecks, shortening operation paths and reducing accidental touches; low-frequency elements are folded and hidden to reduce interface redundancy; if user historical operation data shows significant personalized preferences, a customized layout is created for each user to further align with their operating habits. After optimization, a personalized layout configuration file is generated and bound to the target component, ensuring that the component achieves both performance adaptation and ease of operation across different users and terminals, ultimately outputting a final component that balances smoothness and user experience.

[0107] In one embodiment, after obtaining the UI interface, the process includes:

[0108] Collect multi-source data and related environmental information input to the UI interface to form a multi-dimensional dataset to be de-identified;

[0109] The multi-dimensional dataset to be desensitized is input into the enhanced lightweight sensitive data identification model, which outputs the sensitive data type, sensitivity level, and confidence score. The model is based on the SqueezeNet framework. In addition to the dynamic channel pruning module, the feature extraction layer adds a business attribute-sensitive feature association learning sub-module, which binds business scenarios and sensitive features through attention weights. In addition to the convolutional layer and the sigmoid spatial attention mechanism, the model parameters are fine-tuned using cross-scenario sensitive data samples before the output layer.

[0110] Preset basic thresholds for each sensitivity level, and adjust the basic thresholds for each sensitivity level in real time based on the user's login permission level and the data transmission network type.

[0111] If the model output confidence level reaches the corrected threshold, differentiated desensitization is performed on sensitive data of different sensitivity levels.

[0112] Call the domain rules engine to verify whether the anonymized data still meets the core business functions of the UI interface.

[0113] In this embodiment, a multi-source data acquisition module is first constructed to collect various types of data input by users to the UI interface in real time, including text input data (such as character sequences and semantic descriptions manually entered by users), structured form data (such as the definition types of form fields, data format specifications, and association attributes with business modules), and attachment-related data (such as the content characteristics, metadata tags, and data source identifiers of uploaded files). Simultaneously, related environmental information is collected, covering the business scenario identifiers of the current UI interface (such as "Customer Information Management," "Financial Data Statistics," and "Project Contract Approval"), the user's permission level when logging into the UI interface (such as system administrator, department head, ordinary operator, and external visitor), and the network type through which data is transmitted between the UI interface and the backend system (such as corporate intranet, public internet, and wireless Wi-Fi network). Subsequently, the collected multi-source data and related environmental information undergo data cleaning (removing redundant data and correcting format errors) and association mapping (establishing the correspondence between data and business scenarios, user permissions, and transmission networks). This results in a multi-dimensional dataset to be desensitized, containing both the characteristics of the data itself and the environmental association characteristics, ensuring that subsequent model recognition can accurately identify sensitive data by combining scenario and permission dimensions.

[0114] An enhanced lightweight sensitive data recognition model based on the SqueezeNet framework is adopted. This model makes two key optimizations to the traditional architecture: In the feature extraction layer, in addition to retaining the original dynamic channel pruning module (which reduces the model's computational load by adaptively pruning redundant feature channels to meet the performance requirements of real-time UI interaction), a new business attribute-sensitive feature association learning submodule is added. This submodule binds the weights of business scenario attributes and sensitive features through an attention mechanism. For example, in the "financial data statistics" business scenario, it automatically increases the attention weights of financial sensitive features such as "bank card number," "account balance," and "invoice number," ensuring that the model can accurately capture sensitive data features in combination with the business scenario. Before the output layer, in addition to retaining the convolutional layer (such as 3×3 convolution) and the sigmoid spatial attention mechanism used to strengthen the weights of sensitive feature regions, a cross-scenario sensitive data sample fine-tuning mechanism is introduced. A pre-stored library of sensitive data samples from different business scenarios is used. During model execution, samples from similar cross-scenario scenarios (e.g., sensitive data samples from the "customer contract" scenario are used to call sensitive data samples from the "customer consultation" scenario) are automatically invoked. By fine-tuning model parameters with a small number of samples, the identification bias caused by insufficient sensitive data samples in special or emerging business scenarios is resolved, improving the identification accuracy in small-sample scenarios. After the model runs, it outputs the types of sensitive data (such as personal identification information, financial account information, confidential business data, and private contact information) contained in the multi-dimensional data to be de-identified, their corresponding sensitivity levels (divided into high, medium, and low levels according to the risk of data leakage), and the confidence level of the identification results (reflecting the model's credibility of the identification results), providing a basis for subsequent threshold determination.

[0115] Next, by adjusting thresholds in real time in conjunction with environmental factors, a balance is struck between data security and identification accuracy, avoiding misjudgments or omissions caused by fixed thresholds. First, a base threshold is preset for each sensitivity level, based on historical sensitive data identification accuracy and business security requirements. Then, the base thresholds are adjusted in real time based on the user's login UI permission level and data transmission network type: For high-privilege users accessing the UI via the corporate intranet (high network security), to reduce the misjudgment rate of normal data due to strict thresholds, the base threshold for high-sensitivity levels is lowered by 10%-15%, and the threshold for medium-sensitivity levels is lowered by 5%-10%. For low-privilege users transmitting data via the public internet, to improve data security and avoid missing sensitive data, the base threshold for medium-sensitivity levels is increased by 15%-20%, and the threshold for low-sensitivity levels is increased by 10%-15%. If the user's permission level and network type combination is "low permission + public network," all sensitivity level thresholds are increased by the maximum amount; if it is "high permission + intranet," the thresholds are decreased by the maximum amount. By dynamically adjusting the threshold, a revised threshold is formed that is adapted to the current usage environment, ensuring that the threshold setting meets both security requirements and can adapt to the usage needs in different scenarios.

[0116] Then, targeted de-identification strategies are adopted for data with different sensitivity levels, ensuring both security and data usability. The confidence score of sensitive data identification output by the model is compared with the corrected threshold for the corresponding sensitivity level. If the confidence score reaches the corrected threshold, the data is determined to be sensitive data requiring de-identification, and differentiated de-identification operations are performed according to its sensitivity level: For high-sensitivity data, a full encryption + permission binding de-identification strategy is adopted. The data is encrypted using an asymmetric encryption algorithm, and only authorized users (such as designated administrators) can view the original data through the decryption key. The UI only displays the encrypted ciphertext or de-identification label; for medium-sensitivity data, a partial character mask + format preservation de-identification strategy is adopted; for low-sensitivity data (such as ordinary business numbers, customer numbers), a data obfuscation + key information preservation de-identification strategy is adopted. For example, the first 3 digits and the last 2 digits of the business number are retained, and the non-critical middle part is obfuscated, which avoids the leakage of sensitive information without affecting the basic identification and use of the data. If the data confidence level does not reach the corrected threshold, it is determined to be non-sensitive data, and no desensitization processing is required. It can be directly displayed on the UI interface for normal user use.

[0117] Finally, a pre-built domain rule engine is invoked, which stores the core functional rules of each business module in the UI interface. The rule engine then substitutes the anonymized data into the corresponding business function rules for simulation verification. If the verification result shows that the anonymized data meets all core business function rules, the anonymization is deemed successful, and the anonymized data is updated to the UI interface for user use. If the verification finds that the anonymized data cannot support a certain core business function (e.g., excessive anonymization causes order numbers to be unmatched), the process returns to the differentiated anonymization step, adjusting the anonymization strategy for the corresponding data (e.g., reducing the number of fuzzy digits in the order number), re-executing the anonymization operation, and performing verification again, until the anonymized data meets both security requirements and ensures the normal operation of the core business functions of the UI interface.

[0118] In another embodiment, after obtaining the UI interface, the process includes:

[0119] Collect multi-source data and user behavior data input to the UI interface to form a multi-dimensional dataset to be de-identified;

[0120] A dual-engine model is built, including a first engine and a second engine. The first engine is a multimodal sensitive data recognition engine, which adopts the Transformer lightweight architecture. It identifies the sensitive data types and initial sensitivity levels of multi-dimensional datasets to be desensitized through cross-modal attention fusion of text modality, behavioral modality and scene modality.

[0121] The second engine is a user behavior intent prediction engine, which analyzes multi-dimensional datasets to be de-identified based on the LSTM time series model and outputs data usage intent and intent confidence.

[0122] A basic desensitization strategy is preset, and the strategy parameters are optimized in real time based on the historical desensitization effect through reinforcement learning algorithm. Based on the optimized desensitization strategy, differentiated desensitization is carried out by combining the sensitive data type, initial sensitivity level, data usage intent and intent confidence.

[0123] In this embodiment, a multi-source data and behavioral data collaborative acquisition module is first established. On the one hand, it collects multi-source data input by users to the UI interface in real time, including text input data, structured form data, and attachment-related data. On the other hand, it simultaneously collects user behavioral data on the UI interface, covering user operation trajectory data (such as interface click location, dwell time, operation frequency, operation order, and operation interval), historical interaction records (such as past data input habits on similar interfaces, usage scenarios and operation purposes of anonymized data, and historical traces of data modification or export), and input rhythm characteristics (such as typing speed, pause intervals, error correction frequency, and other dynamic characteristics reflecting user operation habits). Simultaneously, the business scenario identifier of the current UI interface is associated, and the collected multi-source data, user behavioral data, and scenario identifiers are cleaned and structurally integrated to ultimately form a multi-dimensional dataset to be anonymized, containing static data features, dynamic user behavioral features, and scenario-related features.

[0124] Next, a dual-engine model architecture was built. The first engine is a multimodal sensitive data identification engine, employing a lightweight Transformer architecture (compressing the model parameter scale to 1 / 4 of the traditional Transformer through parameter pruning and layer fusion techniques, adapting to the performance requirements of real-time UI interaction). The core advantage of this engine lies in achieving cross-modal attention fusion of text, behavioral, and scenario modalities: the text modality focuses on the semantic features of the data itself; the behavioral modality combines user behavior data to determine data sensitivity tendencies; and the scenario modality adjusts the priority of sensitive features based on business scenario identifiers. Through the cross-modal attention mechanism, the engine weightedly fuses the features of the three modalities, automatically filtering out interference from non-sensitive features, accurately identifying sensitive data types in the multi-dimensional dataset to be de-identified, and classifying initial sensitivity levels based on the impact scope, recovery difficulty, and compliance requirements after data leakage. It outputs a list of sensitive data types, corresponding initial sensitivity levels, and identification confidence scores, providing a basis for the differentiated formulation of subsequent de-identification strategies at the sensitive information level.

[0125] The second engine is a user behavior intent prediction engine, built on an LSTM time-series model (utilizing LSTM's ability to capture long-term dependencies in time-series data to accurately analyze intent associations within user behavior sequences). It takes user behavior data (such as operation trajectories, historical interaction records, and input rhythm features) and time-series information (such as the time sequence of operations and the duration of behavior) from a multi-dimensional dataset to be anonymized as input. During model execution, the user behavior data is first transformed into a time-series feature vector. Through the forget gate, input gate, and output gate of the LSTM network, key behavioral features are gradually filtered to suppress irrelevant behavioral interference. Subsequently, combined with a historical behavior intent label library, the softmax function outputs the user's data usage intent and corresponding intent confidence. This second engine's processing clarifies the user's actual purpose for using the data, providing a basis for subsequent intent-based differentiated anonymization and avoiding over-protection or under-protection caused by relying solely on data sensitivity levels for anonymization.

[0126] Next, a basic de-identification strategy library is pre-set, and basic strategies are formulated for different sensitive data types and initial sensitivity levels. Simultaneously, a reinforcement learning algorithm is introduced to optimize the basic de-identification strategies in real time: Key indicators for the reward function are user feedback satisfaction (e.g., user evaluation of the usability of the de-identified data), security risk detection results (e.g., whether the de-identified data poses a risk of leakage), and business function adaptability (e.g., whether the de-identified data affects core UI functions). When the user feedback satisfaction of a certain strategy falls below a threshold (e.g., <70%) or the security risk detection result is abnormal, the algorithm automatically adjusts the parameters of that strategy. Through continuous iterative training, the de-identification strategies are constantly adapted to changes in actual usage scenarios, forming an optimized dynamic de-identification strategy library.

[0127] When performing data anonymization, the approach no longer relies solely on the sensitive data type and initial sensitivity level. Instead, it combines the user's intent and confidence level (output from the second engine) to match the optimal anonymization strategy from the optimized strategy library: If the data is a highly sensitive bank card number, and the user's intent is to view the data with a confidence level ≥ 0.8, a strategy of displaying the first 6 digits + the last 4 digits, with the middle 8 digits masked, is adopted to ensure that the user can identify the bank card's issuing bank and last four digits, while protecting core information; if the user's intent is to export the data with a confidence level ≥ 0.8, a strategy of full encryption + export permission verification is adopted. The user must enter a secondary verification code and pass the permission review before obtaining the encrypted exported data; if the data is identified as non-sensitive, it is directly output to the UI interface for normal user use without any anonymization processing.

[0128] In the above embodiments, this application incorporates some existing algorithms and technical features for explanation and description to make the specification more detailed, clear, and complete, thus complying with the provisions of the Patent Law. However, this is not achieved by using a series of complex steps and algorithmic formulas, nor by complicating the technical solution, nor by combining or stacking conventional or simple features. The existing algorithms and technical features listed are for the purpose of disclosing the specific implementation methods of each step of this application (not to limit this application) and to avoid situations where this application cannot be implemented.

[0129] Reference Figure 2 In another embodiment of the present invention, a UI interface automatic generation system based on natural language description is also provided, comprising:

[0130] The receiving unit is used to receive natural language requirement description text, perform guided completion of ambiguous descriptions in the requirement description text, and output standardized requirement text including UI components, data fields, and interaction logic.

[0131] The parsing unit is used to perform semantic parsing on the standardized requirement text, locate the functional association nodes between UI components and data fields in the text, correct parsing deviations through domain knowledge graphs, and obtain key information including component parameters, field validation rules, and component priorities.

[0132] The retrieval unit is used to retrieve a design specification library that includes scene-specific visual standards and dynamic layout algorithms, as well as a component library that includes parameterized configuration functions;

[0133] The generation unit is used to perform component matching and parameter adjustment based on the key information and the design specification library and component library to obtain the target component and generate the front-end code or low-code blueprint of the target component.

[0134] The rendering unit is used to render the front-end code or low-code blueprint to obtain the UI interface.

[0135] In this embodiment, the specific implementation of each unit in the above system embodiment is described in the above method embodiment, and will not be repeated here.

[0136] Reference Figure 3 This invention also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 3As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0137] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0138] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0139] In summary, the method and system for automatically generating UI interfaces based on natural language description provided in this embodiment of the invention includes: receiving natural language requirement description text; performing guided completion on ambiguous descriptions in the requirement description text; and outputting standardized requirement text including UI components, data fields, and interaction logic; performing semantic parsing on the standardized requirement text; locating functional association nodes between UI components and data fields within the text; correcting parsing deviations through a domain knowledge graph; obtaining key information including component parameters, field validation rules, and component priorities; retrieving a design specification library including scene-specific visual standards and dynamic layout algorithms, as well as a component library including parameterized configuration functions; performing component matching and parameter adjustment based on the key information, the design specification library, and the component library to obtain target components, and generating front-end code or low-code blueprints for the target components; and rendering the front-end code or low-code blueprints to obtain the UI interface. In this invention, guided completion is performed on ambiguous descriptions in the requirement description text to locate functional association nodes between UI components and data fields within the text. Domain knowledge graphs are used to correct parsing deviations, yielding key information including component parameters, field validation rules, and component priorities, facilitating the acquisition of complete user requirements. After obtaining the target component, the front-end code or low-code blueprint of the target component is directly generated and rendered to obtain the UI interface, lowering the development threshold and improving development efficiency. This overcomes the problems of inefficient requirement transmission, high development threshold, and difficulty in multi-platform adaptation in current UI interface development processes.

[0140] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0141] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0142] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for automatically generating UI interfaces based on natural language description, characterized in that, Includes the following steps: It receives natural language requirement description text, performs guided completion of ambiguous descriptions in the requirement description text, and outputs standardized requirement text including UI components, data fields, and interaction logic; Semantic parsing is performed on the standardized requirement text to locate the functional association nodes between UI components and data fields within the text. Parsing deviations are corrected using a domain knowledge graph to obtain key information including component parameters, field validation rules, and component priorities. Access the design specification library, which includes scene-specific visual standards and dynamic layout algorithms, as well as the component library, which includes parameterized configuration functionality; Based on the aforementioned key information and the design specification library and component library, component matching and parameter adjustment are performed to obtain the target component, and the front-end code or low-code blueprint of the target component is generated. This includes: filtering logically matching candidate components from the component library based on the component type, component priority, and usage scenario parsed from the key information; adjusting the component parameters of the candidate components based on the scene-specific visual standards and dynamic layout algorithms in the design specification library to obtain the target component; calling the code template corresponding to the target component in the component library, embedding the adjusted component parameters into the code template, and generating the front-end code or low-code blueprint of the target component; wherein, for the front-end code template, parameter placeholders in the code template are automatically replaced, and performance optimization markers are embedded; for the low-code blueprint template, the component parameters are mapped to visual configuration items of the low-code platform. The front-end code or low-code blueprint is rendered to obtain the UI interface; The system collects multi-source data and related environmental information input to the UI interface to form a multi-dimensional dataset to be anonymized. This dataset is then input into an enhanced lightweight sensitive data identification model, which outputs the sensitive data type, sensitivity level, and confidence score. The model is based on the SqueezeNet framework. In addition to the dynamic channel pruning module, the feature extraction layer includes a new sub-module for learning the association between business attributes and sensitive features, binding business scenarios and sensitive features through attention weights. Before the output layer, in addition to convolutional layers and a sigmoid spatial attention mechanism, model parameters are fine-tuned using cross-scenario sensitive data samples. Preset base thresholds for each sensitivity level and adjust these thresholds in real-time based on user login permission levels and data transmission network types. If the model output confidence score reaches the adjusted threshold, differentiated anonymization is performed for sensitive data of different sensitivity levels. Finally, a domain rule engine is invoked to verify whether the anonymized data still meets the core business functions of the UI interface.

2. The method for automatically generating UI interfaces based on natural language description according to claim 1, characterized in that, It receives natural language requirement description text, performs guided completion on ambiguous descriptions in the requirement description text, and outputs standardized requirement text including UI components, data fields, and interaction logic, including: It receives natural language requirement description text input by the user, extracts keywords from the requirement description text, and compares them with a preset fuzzy description feature library to identify fuzzy description fragments in the requirement description text about UI component types, data field relationships, and interaction logic triggering conditions. For the ambiguous description fragment, generate guided completion prompts for the corresponding scenario; Receive user feedback on guided completion prompts, integrate the feedback with the natural language requirement description text, and organize it in a structured manner to output standardized requirement text including UI components, data fields, and interaction logic.

3. The method for automatically generating UI interfaces based on natural language description according to claim 1, characterized in that, Semantic parsing is performed on the standardized requirement text to locate the functional association nodes between UI components and data fields within the text. Domain knowledge graphs are used to correct parsing biases, yielding key information including component parameters, field validation rules, and component priorities, including: The standardized requirement text is segmented into UI component description segment, data field description segment, and interaction logic description segment. Each segment of text is encoded into a vector to construct a semantic feature space. In the semantic feature space, a bidirectional attention mechanism is used to perform cross-attention calculation on the UI component description segment and the data field description segment. By superimposing the bidirectional attention weights, the functional association nodes of UI components and data fields in the standardized requirement text are located, and the association strength is marked. The functionally associated nodes are compared with the mapping relationships in the pre-built UI domain knowledge graph to correct parsing deviations and obtain corrected parsing results; the UI domain knowledge graph includes multiple sets of mapping relationships between component parameters, field validation rules, and component priorities; The corrected parsing results are extracted in a structured manner to obtain key information including component parameters, field validation rules, and component priority.

4. The method for automatically generating UI interfaces based on natural language description according to claim 1, characterized in that, When adjusting the parameters of candidate components, the component style parameters are automatically assigned values ​​according to the visual standards of different scenarios; the component layout parameters are calculated using a dynamic layout algorithm to determine the adaptation value; and the component function parameters are determined by combining the amount of data in the fields of key information to determine the optimal value.

5. The method for automatically generating UI interfaces based on natural language description according to claim 1, characterized in that, The front-end code or low-code blueprint is rendered to obtain the UI interface, including: For the aforementioned front-end code, a resource bundling tool is used to package the HTML, CSS, JS / TS files, and related dependencies into a directly loadable resource package; the embedded performance optimization tags are parsed, and the resource loading priority is determined; the corresponding rendering environment is loaded according to the usage scenario of the UI interface, and the resource package is rendered according to the resource loading priority to generate a preview interface; For low-code blueprints, the low-code platform's parsing engine converts the visual configuration items in the low-code blueprints into rendering instructions that the platform can recognize, establishing a mapping relationship between the visual configuration items and the rendering results; based on the mapping relationship, the rendering instructions are converted into visual interface elements to obtain a preview interface. Verify the completeness of node loading in the preview interface, and verify the adaptation effect through a device compatibility testing framework; After all verifications pass, a natural language interaction adjustment entry is generated to receive user input in natural language, parse the adjustment instructions, convert them into corresponding interface style and layout modification instructions, update the rendering results in real time, and finally obtain a functional UI interface that can be directly operated.

6. The method for automatically generating UI interfaces based on natural language description according to claim 5, characterized in that, Render the resource package according to the resource loading priority and generate a preview interface, including: The PC client calls the browser kernel rendering module to render the DOM nodes and styles in the resource package according to the resource loading priority, and generates a preview interface. The mobile device uses an adaptation engine to convert the format of the resource package, calls the native application rendering interface, renders the converted resource package according to the resource loading priority, and generates a preview interface.

7. The method for automatically generating UI interfaces based on natural language description according to claim 1, characterized in that, After adjusting the component parameters of the candidate components to obtain the target component, the process also includes: Extract user historical operation data and terminal device parameters from key information, and determine the performance of the terminal device based on the terminal device parameters; The gradient boosting algorithm is used to analyze the matching degree between the performance of the terminal device and the resource consumption of the target component, and the resource consumption of the target component is adjusted according to the matching degree. Adjust the layout priority of target components based on users' historical operation data.

8. A UI interface automatic generation system based on natural language description, characterized in that, include: The receiving unit is used to receive natural language requirement description text, perform guided completion of ambiguous descriptions in the requirement description text, and output standardized requirement text including UI components, data fields, and interaction logic. The parsing unit is used to perform semantic parsing on the standardized requirement text, locate the functional association nodes between UI components and data fields in the text, correct parsing deviations through domain knowledge graphs, and obtain key information including component parameters, field validation rules, and component priorities. The retrieval unit is used to retrieve a design specification library that includes scene-specific visual standards and dynamic layout algorithms, as well as a component library that includes parameterized configuration functions; The generation unit is used to perform component matching and parameter adjustment based on the key information, design specification library, and component library to obtain the target component and generate the front-end code or low-code blueprint of the target component. This includes: filtering logically matching candidate components from the component library based on the component type, component priority, and usage scenario parsed from the key information; adjusting the component parameters of the candidate components based on the scene-specific visual standards and dynamic layout algorithms in the design specification library to obtain the target component; calling the code template corresponding to the target component in the component library, embedding the adjusted component parameters into the code template, and generating the front-end code or low-code blueprint of the target component; wherein, for the front-end code template, parameter placeholders in the code template are automatically replaced, and performance optimization markers are embedded; for the low-code blueprint template, the component parameters are mapped to visual configuration items of the low-code platform. A rendering unit is used to render the front-end code or low-code blueprint to obtain a UI interface; The system collects multi-source data and related environmental information input to the UI interface to form a multi-dimensional dataset to be anonymized. This dataset is then input into an enhanced lightweight sensitive data identification model, which outputs the sensitive data type, sensitivity level, and confidence score. The model is based on the SqueezeNet framework. In addition to the dynamic channel pruning module, the feature extraction layer includes a new sub-module for learning the association between business attributes and sensitive features, binding business scenarios and sensitive features through attention weights. Before the output layer, in addition to convolutional layers and a sigmoid spatial attention mechanism, model parameters are fine-tuned using cross-scenario sensitive data samples. Preset base thresholds for each sensitivity level and adjust these thresholds in real-time based on user login permission levels and data transmission network types. If the model output confidence score reaches the adjusted threshold, differentiated anonymization is performed for sensitive data of different sensitivity levels. Finally, a domain rule engine is invoked to verify whether the anonymized data still meets the core business functions of the UI interface.

Images