A page item generation method and device based on a user design draft

Abstract

This application provides a method, apparatus, electronic device, and storage medium for generating page projects based on user design drafts. The method includes: acquiring the user's design draft; extracting variable resources from the design draft to obtain a metadata set; performing semantic recognition on the design nodes in the metadata set using a semantic analysis model to obtain tag information for the design nodes; aggregating the design nodes into components based on the tag information and the corresponding structural information to obtain a component candidate set; generating a page metadata structure based on the component tree selected by the user in the component candidate set; and generating code corresponding to the page project based on the metadata set and the page metadata structure. Implementing this application achieves integrated page project generation, improves the connection between each step, and forms a controllable, adjustable, and traceable integrated project generation solution. It offers higher flexibility and integration, better assisting users in developing their design drafts.

Description

Technical Field

[0001] This application relates to the field of front-end technology, and more specifically, to a method, apparatus, electronic device, and storage medium for generating page projects based on user-designed drafts. Background Technology

[0002] Existing technologies have many drawbacks in generating product projects from design drafts. The separation between design, front-end, and back-end is significant, making it difficult to form an automated and integrated generation method. Specifically, these drawbacks are as follows: Static code export tools based on design drafts only focus on the geometric and style information of layers, lacking abstraction of component semantics and business meaning; design tokens and design system management tools only focus on the style tokens themselves, lacking strong association with component code, page structure, and business logic; there is no direct connection between the scaffolding and the design drafts; the code is decoupled from the design drafts, and designers need to recreate the UI within the platform; the switching methods for styles such as colors and fonts are difficult, there is no unified management of resources such as icons, illustrations, and layout differences, and there is no ability to automatically synchronize with the design drafts.

[0003] As the above demonstrates, current technologies remain at the static export level in many aspects, including design drafts and code tools, failing to establish an integrated link between design drafts, code, components, pages, and the project. This results in a lack of unified version control and dependencies for variables and resources, making accurate tracking difficult when updates occur. There is a severe disconnect between components, page abstractions, and design drafts; similar UI modules are implemented multiple times on different pages; component reusability is low; the correspondence between components and code-level components is unstable; maintenance costs are high; and changes to design drafts cannot be accurately mapped to the metadata layer. Furthermore, when design drafts are adjusted, safe incremental merging based on modified code is not possible.

[0004] In summary, existing technologies lack a channel for deep integration of the design version, the generated code version, and the manually modified version. Summary of the Invention

[0005] The purpose of this application is to provide a method, device, electronic device, and storage medium for generating page projects based on user design drafts. Starting from the design drafts, it integrates the development of code, components, pages, and projects into a unified whole, improves the connection between each link, and forms a controllable, adjustable, and traceable integrated page project generation solution based on metadata. It is more flexible and integrated, and can better help users develop design drafts and apply products.

[0006] In a first aspect, embodiments of this application provide a method for generating page items based on user-designed drafts, the method comprising: Obtain the user's design drafts; Variable resources are extracted from the design draft to obtain a metadata set; The design nodes of the metadata set are semantically identified based on a pre-built semantic analysis model to obtain the label information of the design nodes; Based on the tag information and the structural information corresponding to the design node, the design node is aggregated into components to obtain a candidate set of components. Generate page metadata structure based on the component tree selected by the user from the component candidate set; Based on the metadata set and the page metadata structure, generate the code corresponding to the page item.

[0007] In the above implementation process, metadata is formed by extracting variable resources from the design draft. Based on the metadata, semantic analysis and component aggregation are carried out, and finally a visual page project is formed. Starting from the design draft, the development of code, components, pages and projects are integrated and perfected. The relationship between each link is improved, forming a controllable, adjustable and traceable integrated page project generation solution based on metadata. It is more flexible and more integrated, and can better help users develop design drafts and apply products.

[0008] Furthermore, the step of extracting variable resources from the design draft to obtain a metadata set includes: Obtain the target page corresponding to the design draft selected by the user; The parsing process is triggered based on the design document identifier of the target page, and the node tree of the design document identifier is traversed to obtain the structural information of the node tree; Extract the design marks from the design draft; The vector resources referenced in the design draft are scanned to obtain the resource metadata entries for each vector resource; The metadata set consists of three different types of metadata: the structural information of the node tree, the design tags, and the resource metadata entries.

[0009] In the above implementation process, by parsing the design draft, extracting design tags, and scanning vector resources, the three types of metadata are integrated to achieve fast, effective, and comprehensive information extraction from the design draft. This provides data support for the accurate display and refined modification of the design draft, and also helps with the subsequent integrated process.

[0010] Furthermore, the step of performing semantic recognition on the design nodes of the metadata set according to the pre-built semantic analysis model to obtain the label information of the design nodes further includes: Define the pre-defined data types based on the pre-built metadata model to obtain the reference relationships between different fields of the metadata set; The resource mapping table is obtained by mapping different fields of the metadata set according to the reference relationship; Update the tag information in the resource mapping table.

[0011] In the above implementation process, by mapping different fields in the metadata set through a resource mapping table, the relationship between each field and other metadata can be quickly and accurately located, providing a basis for subsequent code generation and updates.

[0012] Further, the step of aggregating components of the design node based on the tag information and the structural information corresponding to the design node to obtain a candidate set of components includes: Based on the tag information, at least one component in the design node whose morphological similarity, semantic similarity, and frequency of occurrence reach a preset threshold is identified as a general candidate component; Based on the structural information, the components containing multiple basic controls in the design node are identified as candidate components for the business template; The component candidate set is composed of the general candidate component and the business template candidate component.

[0013] In the above implementation process, similar components are selected by tag information to determine general candidate components, and then aggregated with relatively stable business template candidate components to form a component candidate set, which makes it easier for users to select the required components, improves the reusability of components, and reduces the maintenance cost of components.

[0014] Further, the step of generating the page metadata structure based on the component tree selected by the user in the component candidate set includes: Based on the component information in the component tree, a basic page metadata structure is generated; Add component annotations to component instances in the basic page metadata structure to obtain the page metadata structure.

[0015] In the above implementation process, component annotations are added to the basic page metadata structure generated by the component tree to form the page metadata structure, providing data support for page rendering. The addition of component annotations can provide logical node types, making the real-time displayed page more complete.

[0016] Further, the step of generating the code corresponding to the page item based on the metadata set and the page metadata structure includes: The design tags and component metadata of the metadata set are populated into a preset technology stack template; Generate component code based on the populated technology stack template; Based on the page metadata structure, the component code is combined into a route component file corresponding to the page item; Configure the theme resources to load the route component file, and generate the code corresponding to the page project.

[0017] In the above implementation process, by filling the design tags and component metadata into the technology stack template to generate component code, and then loading theme resources to generate the page project code, hard-coded color values ​​or font sizes can be avoided in the component code, thus fundamentally enabling subsequent theme switching and incremental updates.

[0018] Further, the step of configuring theme resource loading for the route component file and generating the code corresponding to the page project includes: Read the topic association configuration field from the resource mapping table to generate a resource path mapping table; The resource path mapping table is added as a configuration file to the routing component file to generate the code corresponding to the page project.

[0019] In the above implementation process, by adding theme association configuration to the code, components can flexibly switch style branches under different themes, realize the integration of the theme and the page project, and avoid the cumbersome process of theme switching in the page project.

[0020] Furthermore, the step of configuring theme resource loading for the routing component file further includes: The resource path mapping table is loaded according to the pre-set resource loader to obtain the corresponding resource path; A list of topic resources is generated based on the resource paths and their corresponding priorities; Generate the version hash for each theme resource in the theme resource list; Update the version hash corresponding to each topic resource in the resource mapping table.

[0021] In the above implementation process, when the design draft is updated and resources are changed, the resource mapping table and version hash can be updated in a timely manner to ensure that the page is generated based on the latest resources rather than using the cache.

[0022] Furthermore, the step of generating the code corresponding to the page item based on the metadata set and the page metadata structure further includes: When the page project is generated, or when the page project undergoes incremental updates, bidirectional visual collaboration is performed on the design draft and the page project.

[0023] In the above implementation process, the changes of design drafts, components, code and page projects are displayed to users in real time through two-way visual collaboration. This allows for an intuitive and convenient display of updated areas and differentiated content, providing convenience for users to make changes.

[0024] Furthermore, the step of performing bidirectional visual collaboration between the design draft and the page project includes: Get the incrementally updated design draft, the incrementally updated metadata collection, and the incrementally updated page project code; Visualize the visual differences between the design draft and the incrementally updated design draft; Visualize the differences between the code of the page item and the code of the page item after the incremental update; The semantic differences between the metadata set and the incrementally updated metadata set are identified according to the pre-defined semantic difference generation rules to obtain semantic differences, and the semantic differences are visualized.

[0025] In the above implementation process, the differences between the design draft, metadata, and page project code are visualized, realizing the integrated management of the differences and enabling bidirectional traceability between design and code.

[0026] Secondly, embodiments of this application also provide a page project generation device based on user design drafts, the device comprising: The acquisition module is used to acquire the user's design drafts; The extraction module is used to extract variable resources from the design draft to obtain a metadata set. The semantic recognition module is used to perform semantic recognition on the design nodes of the metadata set according to the pre-built semantic analysis model, and obtain the label information of the design nodes; The component aggregation module is used to aggregate components of the design node according to the tag information and the structural information corresponding to the design node, so as to obtain a component candidate set. The first generation module is used to generate the page metadata structure based on the component tree selected by the user in the component candidate set; The second generation module is used to generate the code corresponding to the page item based on the metadata set and the page metadata structure.

[0027] In the above implementation process, metadata is formed by extracting variable resources from the design draft. Based on the metadata, semantic analysis and component aggregation are carried out, and finally a visual page project is formed. Starting from the design draft, the development of code, components, pages and projects are integrated and perfected. The relationship between each link is improved, forming a controllable, adjustable and traceable integrated page project generation solution based on metadata. It is more flexible and more integrated, and can better help users develop design drafts and apply products.

[0028] Thirdly, an electronic device provided in this application includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any of the first aspects.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in any of the first aspects.

[0030] Other features and advantages of this disclosure will be set forth in the following description, or some features and advantages may be inferred from the description or determined without doubt, or may be learned by practicing the techniques described above.

[0031] It can be implemented in accordance with the contents of the specification. The preferred embodiments of this application are described in detail below with reference to the accompanying drawings. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the range. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 A flowchart illustrating a method for generating page items based on user design drafts is provided for embodiments of this application. Figure 2 A schematic diagram of the structural composition of a page project generation device based on user design drafts is provided for embodiments of this application; Figure 3 This is a schematic diagram of the structural composition of the electronic device provided in the embodiments of this application. Detailed Implementation

[0034] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0035] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0036] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings and examples. The following examples are used to illustrate this application, but are not intended to limit the scope of this application.

[0037] Existing technologies struggle to automate the generation of product projects from design drafts, lack the ability to automatically synchronize with design drafts, have unstable correspondences between components and code-level components, high maintenance costs, and cannot adapt to diverse user design needs.

[0038] This application enables integrated page project development, perfecting the connection between code, components, pages, and every stage of project development. It forms a controllable, adjustable, and traceable integrated page project generation solution based on metadata, offering greater flexibility and integration, and better assisting users in developing design drafts and applying products.

[0039] Example 1 Figure 1 This is a flowchart illustrating a method for generating page items based on user design drafts, as provided in an embodiment of this application. Figure 1 As shown, the method includes: S1, Obtain the user's design draft; S2, extract variable resources from the design draft to obtain a metadata set; S3, based on the pre-built semantic analysis model, perform semantic recognition on the design nodes of the metadata set to obtain the label information of the design nodes; S4. Based on the label information and the structural information corresponding to the design node, perform component aggregation on the design node to obtain a candidate set of components; S5 generates the page metadata structure based on the component tree selected by the user in the component candidate set; S6 generates the code corresponding to the page item based on the metadata set and page metadata structure.

[0040] In the above implementation process, metadata is formed by extracting variable resources from the design draft. Based on the metadata, semantic analysis and component aggregation are carried out, and finally a visual page project is formed. Starting from the design draft, the development of code, components, pages and projects are integrated and perfected. The relationship between each link is improved, forming a controllable, adjustable and traceable integrated page project generation solution based on metadata. It is more flexible and more integrated, and can better help users develop design drafts and apply products.

[0041] Furthermore, S2 includes: Retrieve the target page corresponding to the design draft selected by the user; The parsing process is triggered based on the design document identifier of the target page, and the node tree of the design document identifier is traversed to obtain the structural information of the node tree; Extract design marks from the design draft; Scan the vector resources referenced in the design draft to obtain the resource metadata entries for each vector resource; The metadata set is composed of three different types of metadata: the structural information of the node tree, design tags, and resource metadata entries.

[0042] In the above implementation process, by parsing the design draft, extracting design tags, and scanning vector resources, the three types of metadata are integrated to achieve fast, effective, and comprehensive information extraction from the design draft. This provides data support for the accurate display and refined modification of the design draft, and also helps with the subsequent integrated process.

[0043] During the parsing process, this application traverses all node trees of the design draft. The nodes of the design draft include canvas (Frame), component (Component), instance (Instance), group (Group), layer (Layer) and their associated style information. The design draft is composed of multiple nodes. During the parsing process, it is necessary to traverse all nodes that make up the design draft (and the node tree formed by multiple nodes) to read the structural information of canvas, component, instance, group, layer and other elements in the design draft.

[0044] The structural information of the node tree parsed above is used to describe the structure and attributes of the design elements, rather than the visual content of the elements themselves, and belongs to structural metadata.

[0045] Design tokens include: token type (such as color, font, spacing, shadow, radius, etc.); token name or semantic tag (such as primary / background / success / error, etc.); and token value (such as hexadecimal color value, font size, line height, px value, etc.). Design tags are stored in a metadata center in a unified intermediate format (such as JSON), forming tokens.json or an equivalent data structure. This is used to describe the reuse rules and semantics of design styles, rather than individual style values ​​themselves, and belongs to rule metadata.

[0046] Design markup can be subsequently mapped to specific technology stacks such as CSS Custom Properties (also known as CSS variables), SCSS variables (Syntactically Awesome Style Sheets CSS), JavaScript constants, and Tailwind configuration extensions.

[0047] Vector resources are Scalable Vector Graphics (SVG), also known as vector bitmaps or vector graphics.

[0048] Resource metadata entries include: resource identifier (resource_id), resource source node ID, original resolution, format; export specifications at different scaling ratios; resource semantics (such as "Logo", "Illustration", "Icon / Close").

[0049] Resource metadata entries describe the attributes and usage relationships of resource files, rather than the content of the resource files themselves, and belong to resource metadata.

[0050] This application utilizes design tools or their backend to download the corresponding resource files, performs operations such as compression, format conversion, and naming standardization (unified prefix, size suffix, etc.), and stores the above three types of metadata in a static resource directory structure. Simultaneously, a resource mapping table (such as resources.json) is generated, recording the correspondence between design node IDs, resource file paths, and semantic tags for use in subsequent code generation and runtime.

[0051] Furthermore, S3 includes: The semantic analysis model in this application is based on a semantic analysis module formed by a rule engine and a trainable AI model (such as a layer classification model and a component recognition model), and uses the following features to identify design nodes: Layer naming patterns and prefixes (such as "btn / ", "input / ", "card / ", etc.); Layer hierarchy (whether it includes typical button structures such as icon + text + background rectangle); Combinations of style features (color, rounded corners, shadows, interactive state variations, etc.); The frequency of component reuse and its location distribution (similar structures appearing in multiple places are more likely to be reusable components).

[0052] The semantic analysis model automatically assigns semantic tags to nodes, such as Button, Input, Card, Modal, NavBar, FormItem, Table, etc.

[0053] Furthermore, S3 also includes: Define the pre-defined data types based on the pre-built metadata model to obtain the reference relationships between different fields of the metadata set; Based on the reference relationships, mappings are established for different fields of the metadata collection to obtain the resource mapping table; Update the tag information in the resource mapping table.

[0054] In the above implementation process, by mapping different fields in the metadata set through a resource mapping table, the relationship between each field and other metadata can be quickly and accurately located, providing a basis for subsequent code generation and updates.

[0055] This application standardizes metadata specifications, defining them using either JSON Schema or TypeScript data types. It standardizes the field composition and inter-field references in core metadata files such as tokens.json, resources.json, components.json, and pages.json. Specifically, the mapping relationships between different metadata fields are as follows: (1) The tokens.json structure definition includes: Top-level fields include metadata version, theme identifier, and token array. Each Token object contains: id (globally unique identifier, such as "color.primary.500"), type ("color" / "typography" / "spacing" / "radius" / "shadow", etc.), name (semantic name), value (primitive value, such as "#1890ff"), aliases (an array of aliases used to reference other Tokens), value mappings under different themes (themeVariants, such as { "default": "#1890ff","dark": "#1677ff"}), source node ID, design draft version, and other traceability information (metadata); Tokens are linked together by the aliases field to form a mapping (Token dependency graph). For example, "color.button.background" can reference "color.primary.500".

[0056] (2) The resources.json structure definition includes: The top-level field includes the resource array (version sresource); Each resource object contains: id (e.g., "logo.main"), type ("image" / "icon" / "illustration" / "font", etc.), design draft node ID (sourceNodeId), local or CDN path (filePath), variants of different sizes / formats (e.g., { "1x": "logo@1x.png", "2x":"logo@2x.png","svg":"logo.svg"}), theme map (e.g., {"default":"logo-brand-a.svg","brand-b": "logo-brand-b.svg"}), semantic tag array (e.g., ["logo", "header"]), size, format, compression information, etc. (metadata); resources.json establishes a mapping between sourceNodeId and design draft nodes, and supports theme-based resource switching through themeMapping.

[0057] (3) The structure definition of components.json: The top-level field includes an array of components (version components); Each component object contains: id (e.g., "button.primary"), component name (name), type ("atomic" / "composite" / "template"), design draft node ID (sourceNodeId), array of property definitions (props, each property contains name, type, required, defaultValue, description), array of referenced TokenIDs (tokenDependencies, e.g., ["color.primary.500", "spacing.md"]), array of referenced resource IDs (resourceDependencies, e.g., ["icon.close"]), array of child component IDs (childComponents), style variant configurations for different themes (themeVariants), component path, export configuration, etc. (metadata). components.json establishes reference relationships with tokens.json and resources.json through tokenDependencies and resourceDependencies, forming a complete mapping (dependency graph).

[0058] (4) The structure definition of pages.json includes: The top-level field includes an array of pages (version pages); Each page object contains: id (e.g., "page.login"), route path, page name, component tree structure (componentTree, which uses a recursive structure and includes componentId, props, children, layoutInfo, etc.), page-level token dependencies (tokenDependencies), page-level resource dependencies (resourceDependencies), and page metadata. For example, the reference relationship between various fields is as follows: pages.json references the component definition in components.json through the componentId in the component tree structure, forming a complete reference chain of pages, components, and tokens / resources.

[0059] All metadata files establish cross-file references through a unified ID namespace (such as "color.primary.500", "button.primary", "page.login"). Before generating code, this application performs dependency verification to ensure that all referenced tokens, resources, and components exist, and detects circular dependencies. When a design change causes a token or resource to be deleted, this application can quickly locate all affected components and pages through the dependency graph, providing accurate impact range analysis for incremental updates.

[0060] Furthermore, S4 includes: Based on the tag information, components in the design nodes that reach at least a preset threshold in terms of morphological similarity, semantic similarity, and frequency of occurrence are identified as general candidate components. Based on the structural information, components containing multiple basic controls in the design node are identified as candidate components for the business template; The general candidate components and the business template candidate components are combined into a component candidate set.

[0061] In the above implementation process, similar components are selected by tag information to determine general candidate components, and then aggregated with relatively stable business template candidate components to form a component candidate set, which makes it easier for users to select the required components, improves the reusability of components, and reduces the maintenance cost of components.

[0062] This application identifies regions with similar morphology, similar semantics, and high frequency of occurrence as general candidate components. These features are achieved by calculating the morphological similarity, semantic similarity, and frequency of occurrence of the components.

[0063] Candidate components for business templates include, for example, statistics cards, search + table pages, and wizard step pages.

[0064] The selection rules for general candidate components are as follows: Morphological similarity: Similarity is calculated using structural features (number of child nodes, hierarchy depth, aspect ratio, inner margin ratio, arrangement direction, etc.), and examples of structural features of a button with icon + text + rounded rectangle are provided.

[0065] Semantic similarity: obtained by clustering based on semantic tags and layer names (such as btn-primary, button_submit).

[0066] Frequency of occurrence: Set the number of times it appears (e.g., ≥3 times), and give an example of a component with user avatar + name + drop-down arrow.

[0067] Selection rules for candidate components of business templates: The composite structure is stable, with at least two basic control combinations, and the substructures remain consistent across multiple designs; the semantic patterns are inductive, providing specific substructure descriptions for statistical cards, search + table pages, and wizard step pages; the reuse scenarios are clear, with a stable structure that appears repeatedly across multiple pages or scenarios.

[0068] For example, the selection of general candidate components can be achieved by clustering 15 main button areas with a shape similarity > 0.9 into one main button component candidate.

[0069] The selection of candidate components for the business template can be done in the following way: if all 5 pages contain a search box + filter + table + pagination, then the proposed candidate component for the business template is the search + table page.

[0070] Furthermore, S5 includes: Generate a basic page metadata structure based on the component information in the component tree; Add component annotations to component instances in the basic page metadata structure to obtain the page metadata structure.

[0071] In the above implementation process, component annotations are added to the basic page metadata structure generated by the component tree to form the page metadata structure, providing data support for page rendering. The addition of component annotations can provide logical node types, making the real-time displayed page more complete.

[0072] In the visual workspace, users can drag and drop components or business templates onto the page canvas.

[0073] Generate the basic page metadata structure based on the component tree, including: Page routing path, page name, and module; component tree structure within the page (parent-child relationship, layout information); binding relationship between each component instance and component definition, and attribute configuration.

[0074] Add component comments to the component instance. Component comments include interaction comments and data binding placeholders, for example: Click the login button → validate the form → call the login interface → redirect to / home upon successful login; The table data comes from / api / list, and the pagination parameters page / pageSize come from the component's internal state.

[0075] Component annotations are converted into logical placeholder metadata to form an event handling flow graph (such as event_flows.json), and the types of logical nodes that need to be generated by subsequent code or added by developers are marked, thus obtaining the page metadata structure (such as pages.json).

[0076] Furthermore, S6 includes: Populate the design tags and component metadata of the metadata set into the preset technology stack template; Generate component code based on the populated technology stack template; Based on the page metadata structure, the component code is combined into the corresponding route component file for the page project; Configure the theme resources to load into the route component files, and generate the corresponding code for the page project.

[0077] In the above implementation process, by filling the design tags and component metadata into the technology stack template to generate component code, and then loading theme resources to generate the page project code, hard-coded color values ​​or font sizes can be avoided in the component code, thus fundamentally enabling subsequent theme switching and incremental updates.

[0078] The code generation engine can pre-configure various technology stack templates, such as React + TypeScript + Vite + Ant Design, Vue3 + TypeScript + Vite + Element Plus, Next.js + Tailwind, etc.

[0079] Each technology stack template includes: project scaffolding structure (directory structure, packaging configuration, Lint / Format configuration, etc.); general layout components and routing configuration templates; and rules for mapping to Design Token.

[0080] Before generating the page project, this application allows users to select a technology stack template and some configurable parameters (such as whether to use a state management solution like Zustand / Pinia).

[0081] The definitions and theme dimension information in the design tokens (tokens.json) of the metadata collection are added to the technology stack template to ensure that all style references are accessed through tokens during the code generation process, avoiding hard-coded color values ​​or font sizes in component code and fundamentally supporting subsequent theme switching.

[0082] Component metadata (components.json) generates component code based on the following strategies: The corresponding UI library's secondary encapsulation mode maps semantic components (such as main buttons and warning prompts) to specific UI components (such as Antd Button / Alert), and encapsulates a unified Props interface and Token mapping logic in the outer layer; Independent pure component mode, which generates basic components that do not depend on a specific UI library and are implemented using native HTML / JSX + CSS variables; The design draft node ID from which the component originated; List of Tokens and Resources Used; The component has switchable style branches under different themes.

[0083] Introducing the above strategies into component code generation can provide a basis for subsequent design change mapping and automatic diffing.

[0084] Based on the page metadata structure, generate a corresponding route component file for each page and update the route configuration table.

[0085] As can be seen from the technical content of S5, the page metadata structure uses the generated basic components and business template components. Based on logical placeholder functions (logical placeholder metadata) such as handleSubmit and handleSearch, event flow metadata (i.e., event processing flow graph) is generated. The above technical means reserve standardized extension points for data source requests, state management, and access control.

[0086] Optionally, in this application, when the event stream metadata contains a parsable natural language description, an external Large Language Model (LLM) service can be invoked. This service, combined with a pre-defined scenario-based Prompt template (also known as a prompt word template, a reusable structured text framework pre-designed for AI dialogue or generation tasks), automatically generates form validation logic, asynchronous API call code, and common error handling and feedback logic. The generated logic code is inserted into the corresponding event stream metadata, and the automatically generated areas are explicitly marked with comments for developers to review and modify.

[0087] Further steps include configuring theme resource loading in the route component files and generating the corresponding code for the page project, including: Read the topic association configuration field from the resource mapping table to generate a resource path mapping table; Add the resource path mapping table as a configuration file to the route component file to generate the corresponding code for the page project.

[0088] In the above implementation process, by adding theme association configuration to the code, components can flexibly switch style branches under different themes, realize the integration of the theme and the page project, and avoid the cumbersome process of theme switching in the page project.

[0089] Furthermore, the steps for configuring theme resource loading in the route component files also include: The resource path mapping table is loaded according to the pre-set resource loader to obtain the corresponding resource path; Generate a list of topic resources based on the resource paths and their corresponding priorities; Generate the version hash for each theme resource in the theme resource list; Update the version hash corresponding to each theme resource in the resource mapping table.

[0090] In the above implementation process, when the design draft is updated and resources are changed, the resource mapping table and version hash can be updated in a timely manner to ensure that the page is generated based on the latest resources rather than using the cache.

[0091] This application injects theme-aware resource loading logic into the generated component code during the code generation phase. The runtime resource loading mechanism is as follows: (1) Generation of resource path mapping table: The code generation engine reads the themeMapping field from resources.json and generates a resource path mapping table for each theme, in the format of {"logo.main":{"default": " / assets / themes / default / logo.svg","dark":" / assets / themes / dark / logo.svg", "brand-a": " / assets / themes / brand-a / logo.svg"}}; This mapping table is output to the project as a TypeScript constant or a JSON configuration file for dynamic lookup at runtime.

[0092] (2) Runtime theme switching and resource loading: The `getResource(resourceId:string)` method is provided through the `ResourceLoader` utility class; When a component needs to load resources, it calls ResourceLoader.getResource("logo.main"). The loader looks up the corresponding path from the resource path mapping table based on the current theme and returns the correct Uniform Resource Locator (URL). For image resources, this application generates code that uses tags or Image components, with the src attribute dynamically obtained through ResourceLoader. For SVG icons, React / Vue components can be generated, which internally load the corresponding SVG files according to the theme through dynamic import (a JavaScript feature) or require.context (a special API provided by Webpack, not a native JavaScript feature).

[0093] (3) Resource preloading and lazy loading strategies: When generating code, a theme resource list (resource-manifest.json) is generated for each theme, listing the paths and priorities of all resources under the theme resource list; When the application starts or the theme is switched, ResourceLoader preloads critical resources (such as logo and main icon) according to priority, while non-critical resources (such as illustrations and background images) are loaded using a lazy loading strategy and are loaded when the component is rendered for the first time. For Content Delivery Network (CDN) deployment scenarios, the code generated by this application supports configuring the CDN base path and automatically appending the CDN prefix to the resource URL to achieve distributed loading of resources.

[0094] (4) Resource caching and version management: When generating resource files, add a version hash (e.g., logo.svg?v=abc123) to each resource and record the version information in the resource mapping table; The runtime ResourceLoader supports a resource caching mechanism, ensuring that resources with the same resource ID and theme are loaded only once in the same session, reducing network requests. When design updates result in resource changes, update the resource mapping table and version hash to ensure that the browser can obtain the latest resources instead of using the cache.

[0095] Furthermore, the step of generating the code corresponding to the page item based on the metadata set and the page metadata structure also includes: When a page project is generated, or when an incremental update of a page project occurs, two-way visual collaboration is performed on the design draft and the page project.

[0096] In the above implementation process, the changes of design drafts, components, code and page projects are displayed to users in real time through two-way visual collaboration. This allows for an intuitive and convenient display of updated areas and differentiated content, providing convenience for users to make changes.

[0097] Each time a project is generated or incrementally updated, this application will package the current metadata such as tokens.json, resources.json, components.json, pages.json, and event_flows.json, and store them in association with the corresponding Git commit ID and design draft version number.

[0098] When design drafts or code change, the system can quickly locate the state of the last successful collaboration as a baseline for comparison.

[0099] The baseline for comparison includes: Adding, deleting, or modifying tokens (e.g., color A → B, font size changed from 14 to 16); Resource-level changes (adding images, replacing icon files, adjusting export specifications); Adjustments to component structure or parameters (adding a Prop to a component, deleting child elements, switching style variants); Page layout changes (component position changes, component additions / deletions).

[0100] This application can visualize the above changes and highlight the affected components / pages in the visualization interface.

[0101] Furthermore, the steps for two-way visual collaboration between design drafts and page projects include: Get the incrementally updated design draft, the incrementally updated metadata collection, and the incrementally updated page project code; Visualize the differences between the original design and the incrementally updated design. Visualize the differences between the page project code and the incrementally updated page project code; Based on the pre-defined semantic difference generation rules, semantic differences are identified between the metadata set and the incrementally updated metadata set to obtain semantic differences, which are then visualized.

[0102] In the above implementation process, the differences between the design draft, metadata, and page project code are visualized, realizing the integrated management of the differences and enabling bidirectional traceability between design and code.

[0103] Bidirectional Visual Collaboration refers to a real-time, two-way interaction between the design view and the code view in a design-code integrated collaborative scenario. When the content on one end changes, the other end can automatically synchronize, map, refresh, and present the corresponding changes, achieving WYSIWYG, bidirectional traceability, and interactive changes between design and code, thereby reducing information gaps and communication costs between design and development.

[0104] In the collaboration interface, the left side displays screenshots showing the visual differences between the design draft and the incrementally updated design draft, the right side displays the code of the page project and the git diff view of the incrementally updated page project code, and the middle displays the metadata collection and the semantic-level change summary of the incrementally updated metadata collection.

[0105] Users can choose the following actions for each change: One-click application: Automatically modifies relevant token files, component styles, and page layout code according to predefined rules, while retaining manual modifications made by developers at the logic layer; Semi-automatic merging: Provides code patch suggestions, which developers can confirm one by one in the integrated development environment (IDE) or web interface; Change rejection: Record the reasons for rejecting this design change at the technical implementation level to facilitate design / product review.

[0106] Semantic diffing is a meaning-based, structured comparison of design or code content, rather than a simple pixel or line-of-text comparison. By parsing design metadata (components, layers, attributes, structures) or code abstract syntax trees (ASTs), it identifies semantic-level changes such as additions, deletions, modifications, renamings, and moves, and automatically generates human-understandable change summaries, allowing users to intuitively understand what has been changed and what its impact is, rather than just seeing underlying details.

[0107] This application can identify semantic differences between a metadata set and an incrementally updated metadata set. The rules for generating semantic differences are as follows: (1) Derivation of the change from node change in design draft to token value change: Compare the tokens.json files in the old and new intermediate representations to identify changes in the value field of the Token object; For color-related tokens, the system detects changes in hexadecimal values, as well as format conversions such as RGB / RGBA / HSL (three color formats) and changes in transparency, generating semantic events such as "color.primary.500: #1890ff→#1677ff". For font-type tokens, detect changes in properties such as fontSize, lineHeight, fontWeight, and fontFamily, and generate semantic events such as "typography.body.size: 14px→16px"; The source of changes can be traced through the design node ID. If multiple design nodes use the same token, all components affected by the token change are marked.

[0108] (2) Derivation of the new derivation from the change of the design draft node to the component Prop: Compare the old and new components.json files to detect changes in the component's props array (additions, deletions, and modifications to property definitions). When a new prop is detected in a component (such as a "loading" property being added to a button component), the system analyzes whether the instance of the component in the design draft has a corresponding visual state (such as an icon or text indicating a loading state) and generates a semantic event such as "button.primary: added prop 'loading' (boolean, default: false)". By analyzing changes in the internal structure of components (such as adding child elements or style variations), the system automatically infers the possible props and suggests them to developers in the semantic diff.

[0109] (3) Semantic recognition of resource changes: Compare the old and new resources.json files to detect changes in fields such as filePath, variants, and themeMapping. When a change in the resource file path is detected, the file content hash is used to determine whether it is a replacement (different content) or a renaming (same content), and a semantic event such as "resource.logo.main: file replacement (logo-old.svg→logo-new.svg)" or "resource.icon.close: path renaming" is generated. For themed resources, detect the addition or deletion of theme variants in the themeMapping field and generate semantic events such as "resource.logo.main: added theme variant 'brand-b'".

[0110] (4) Semantic recognition of component structure changes: By comparing the component tree structure (childComponents array and component internal layout information), the addition, deletion, and modification of components can be identified; When a new child component is detected, the semantics and position of the child component are analyzed to generate a semantic event such as "card.statistics: new child component 'stat-item' (position: top area)"; By analyzing the usage of components on different pages, the scope of impact of structural changes can be determined and annotated in the semantic diff.

[0111] (5) Semantic recognition of page layout changes: Compare the component tree structure in the old and new pages.json files to detect the addition, deletion, position changes, and attribute configuration changes of component instances; By using layout algorithms (such as Flexbox / Grid layout parsing) to identify changes in component positions, semantic events such as "page.dashboard: 'stat-card-1' component position moves from (0,0) to (1,0)" are generated. When the property configuration of a component instance changes, the props field is compared to generate a semantic event such as "page.login: 'submit-button' component props.loading changes from false to true".

[0112] (6) Aggregation and prioritization of semantic events: Aggregate multiple underlying changes (such as color changes, size changes, and text changes) generated at the same design node into a single high-level semantic event (such as "overall button style update"). Semantic events are assigned priorities based on their impact scope (affecting Tokens → affecting components → affecting pages) and change type (style changes vs. structural changes vs. logical changes), and then displayed in the collaboration interface in order of priority. It supports user-defined semantic event rules, allowing teams to extend semantic recognition capabilities according to business scenarios.

[0113] Once the old and new versions are merged, this application will automatically generate a Git commit and record the corresponding design version number and change summary in the commit message, enabling two-way traceability between design and code.

[0114] Prior to the above code submission, for code that has been significantly refactored by developers, this application constructs a three-way merging scenario through the intermediate representation of the design layer (design baseline vs. latest design), the intermediate representation of the generation layer (the code structure generated last time), and the current code in the actual repository.

[0115] The merging algorithm, while preserving the developer's logical modifications and refactoring, automatically patches only style- and structure-related areas as much as possible, and prompts the developer to handle conflicting parts that cannot be safely merged manually.

[0116] The specific logic of the above three-party merging algorithm is as follows: (1) Code region classification and marking: (2) Identification of style / structure area vs. business logic area: When a merge conflict is detected, it can be resolved in the following ways: Text conflict: When three parties have different content at the same location on the same line of code (detected by line-level diff algorithm), the conflict retention strategy is to prioritize the application of design changes, but check whether the changes affect the code marked as the business logic area. If they do, the developer version is retained and a prompt is given. Structural conflict: A design change requires the removal of a component or attribute, but it is still used in the current business logic. The conflict retention strategy is to retain the current code structure, highlight the conflict point in the collaboration interface, and require the developer to make a manual decision. Semantic conflict: When design changes and developer refactoring result in semantic inconsistencies (e.g., a design change changes a button to a link, but the code logic still treats it as a button), the conflict retention strategy is not to automatically merge the changes. Instead, conflict details and impact analysis are displayed in the collaboration interface, allowing developers to choose a solution (accept the design change and modify the logic / reject the design change / manually adjust).

[0117] After the merge is complete, perform the following verifications: syntax check, reference integrity check, type check, and logical integrity check. If the verification fails, display the error details in the collaboration interface and prompt the developer to fix the conflict and try again.

[0118] This application achieves traceability of code submissions through the above methods, automatically generating detailed change summaries in Git commit messages, including design version numbers, a list of affected components / pages, and merging strategy descriptions, which facilitates team collaboration and issue tracing.

[0119] This application can export a front-end project compressed package that can be run immediately at any time during the generation process. It includes: complete source code, packaging and deployment configuration, and dependency declaration files, ensuring that the page project can directly install dependencies and start running in a local or CI environment.

[0120] Example 2 To execute the method corresponding to Embodiment 1 above and achieve the corresponding functional and technical effects, a page project generation device based on user design drafts is provided below, such as... Figure 2 As shown, the device includes: Module 1 is used to obtain the user's design drafts; Extraction module 2 is used to extract variable resources from the design draft to obtain a metadata set; Semantic recognition module 3 is used to perform semantic recognition on the design nodes of the metadata set according to the pre-built semantic analysis model to obtain the label information of the design nodes; Component aggregation module 4 is used to aggregate design nodes into components based on tag information and structural information corresponding to design nodes, and obtain a candidate set of components. The first generation module 5 is used to generate the page metadata structure based on the component tree selected by the user in the component candidate set; The second generation module 6 is used to generate the code corresponding to the page items based on the metadata set and the page metadata structure.

[0121] In the above implementation process, metadata is formed by extracting variable resources from the design draft. Based on the metadata, semantic analysis and component aggregation are carried out, and finally a visual page project is formed. Starting from the design draft, the development of code, components, pages and projects are integrated and perfected. The relationship between each link is improved, forming a controllable, adjustable and traceable integrated page project generation solution based on metadata. It is more flexible and more integrated, and can better help users develop design drafts and apply products.

[0122] Furthermore, extraction module 2 is also used for: Retrieve the target page corresponding to the design draft selected by the user; The parsing process is triggered based on the design document identifier of the target page, and the node tree of the design document identifier is traversed to obtain the structural information of the node tree; Extract design marks from the design draft; Scan the vector resources referenced in the design draft to obtain the resource metadata entries for each vector resource; The metadata set is composed of three different types of metadata: the structural information of the node tree, design tags, and resource metadata entries.

[0123] In the above implementation process, by parsing the design draft, extracting design tags, and scanning vector resources, the three types of metadata are integrated to achieve fast, effective, and comprehensive information extraction from the design draft. This provides data support for the accurate display and refined modification of the design draft, and also helps with the subsequent integrated process.

[0124] Furthermore, the semantic recognition module 3 is also used for: Define the pre-defined data types based on the pre-built metadata model to obtain the reference relationships between different fields of the metadata set; Based on the reference relationships, mappings are established for different fields of the metadata collection to obtain the resource mapping table; Update the tag information in the resource mapping table.

[0125] In the above implementation process, by mapping different fields in the metadata set through a resource mapping table, the relationship between each field and other metadata can be quickly and accurately located, providing a basis for subsequent code generation and updates.

[0126] Furthermore, component aggregation module 4 is also used for: Based on the tag information, components in the design nodes that reach at least a preset threshold in terms of morphological similarity, semantic similarity, and frequency of occurrence are identified as general candidate components. Based on the structural information, components containing multiple basic controls in the design node are identified as candidate components for the business template; The general candidate components and the business template candidate components are combined into a component candidate set.

[0127] In the above implementation process, similar components are selected by tag information to determine general candidate components, and then aggregated with relatively stable business template candidate components to form a component candidate set, which makes it easier for users to select the required components, improves the reusability of components, and reduces the maintenance cost of components.

[0128] Furthermore, the first generation module 5 is also used for: Generate a basic page metadata structure based on the component information in the component tree; Add component annotations to component instances in the basic page metadata structure to obtain the page metadata structure.

[0129] In the above implementation process, component annotations are added to the basic page metadata structure generated by the component tree to form the page metadata structure, providing data support for page rendering. The addition of component annotations can provide logical node types, making the real-time displayed page more complete.

[0130] Furthermore, the second generation module 6 is also used for: Populate the design tags and component metadata of the metadata set into the preset technology stack template; Generate component code based on the populated technology stack template; Based on the page metadata structure, the component code is combined into the corresponding route component file for the page project; Configure the theme resources to load into the route component files, and generate the corresponding code for the page project.

[0131] In the above implementation process, by filling the design tags and component metadata into the technology stack template to generate component code, and then loading theme resources to generate the page project code, hard-coded color values ​​or font sizes can be avoided in the component code, thus fundamentally enabling subsequent theme switching and incremental updates.

[0132] Furthermore, the second generation module 6 is also used for: Read the topic association configuration field from the resource mapping table to generate a resource path mapping table; Add the resource path mapping table as a configuration file to the route component file to generate the corresponding code for the page project.

[0133] In the above implementation process, by adding theme association configuration to the code, components can flexibly switch style branches under different themes, realize the integration of the theme and the page project, and avoid the cumbersome process of theme switching in the page project.

[0134] Furthermore, the second generation module 6 is also used for: The resource path mapping table is loaded according to the pre-set resource loader to obtain the corresponding resource path; Generate a list of topic resources based on the resource paths and their corresponding priorities; Generate the version hash for each theme resource in the theme resource list; Update the version hash corresponding to each theme resource in the resource mapping table.

[0135] In the above implementation process, when the design draft is updated and resources are changed, the resource mapping table and version hash can be updated in a timely manner to ensure that the page is generated based on the latest resources rather than using the cache.

[0136] Furthermore, the device also includes a two-way visual collaboration module for: When a page project is generated, or when an incremental update of a page project occurs, two-way visual collaboration is performed on the design draft and the page project.

[0137] In the above implementation process, the changes of design drafts, components, code and page projects are displayed to users in real time through two-way visual collaboration. This allows for an intuitive and convenient display of updated areas and differentiated content, providing convenience for users to make changes.

[0138] Furthermore, the two-way visual collaboration module is also used for: Get the incrementally updated design draft, the incrementally updated metadata collection, and the incrementally updated page project code; Visualize the differences between the original design and the incrementally updated design. Visualize the differences between the page project code and the incrementally updated page project code; Based on the pre-defined semantic difference generation rules, semantic differences are identified between the metadata set and the incrementally updated metadata set to obtain semantic differences, which are then visualized.

[0139] In the above implementation process, the differences between the design draft, metadata, and page project code are visualized, realizing the integrated management of the differences and enabling bidirectional traceability between design and code.

[0140] The page project generation apparatus based on the user design draft described above can implement the method of Embodiment 1. The options in Embodiment 1 described above are also applicable to the embodiments of this application, and will not be described in detail here.

[0141] The remaining contents of this application embodiment can be referred to the contents of the above embodiment one, and will not be repeated in this application embodiment.

[0142] Example 3 This application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to execute the page item generation method based on the user design draft of Embodiment 1.

[0143] Alternatively, the aforementioned electronic device may be a server.

[0144] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating the structural composition of an electronic device provided in an embodiment of this application. The electronic device may include a processor 31, a communication interface 32, a memory 33, and at least one communication bus 34. The communication bus 34 is used to enable direct communication between these components.

[0145] Optionally, the electronic device may also include a storage controller and an input / output unit. The memory 33, storage controller, processor 31, peripheral interface, and input / output unit are electrically connected to each other directly or indirectly to realize data transmission or interaction.

[0146] Input / output units are used to enable users to create tasks and set optional start periods or preset execution times for those tasks, facilitating user-server interaction. Input / output units can be, but are not limited to, a mouse and keyboard.

[0147] Understandable. Figure 3 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 3 The more or fewer components shown, or having the same Figure 3 Different configurations are shown. Additionally, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the page item generation method based on user design drafts as described in Embodiment 1.

[0148] This application also provides a computer program product that, when run on a computer, causes the computer to perform the method described in the method embodiment.

[0149] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0150] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

Claims

1. A method for generating page projects based on user-designed drafts, characterized in that, The method includes: Obtain the user's design drafts; Variable resources are extracted from the design draft to obtain a metadata set; The design nodes of the metadata set are semantically identified based on a pre-built semantic analysis model to obtain the label information of the design nodes; Based on the tag information and the structural information corresponding to the design node, the design node is aggregated into components to obtain a candidate set of components. Generate page metadata structure based on the component tree selected by the user from the component candidate set; Based on the metadata set and the page metadata structure, generate the code corresponding to the page item.

2. The method for generating page items based on user design drafts according to claim 1, characterized in that, The step of extracting variable resources from the design draft to obtain a metadata set includes: Obtain the target page corresponding to the design draft selected by the user; The parsing process is triggered based on the design document identifier of the target page, and the node tree of the design document identifier is traversed to obtain the structural information of the node tree; Extract the design marks from the design draft; The vector resources referenced in the design draft are scanned to obtain the resource metadata entries for each vector resource; The metadata set consists of three different types of metadata: the structural information of the node tree, the design tags, and the resource metadata entries.

3. The method for generating page items based on user design drafts according to claim 1, characterized in that, The step of performing semantic recognition on the design nodes of the metadata set according to the pre-built semantic analysis model to obtain the label information of the design nodes further includes: Define the pre-defined data types based on the pre-built metadata model to obtain the reference relationships between different fields of the metadata set; The resource mapping table is obtained by mapping different fields of the metadata set according to the reference relationship; Update the tag information in the resource mapping table.

4. The method for generating page items based on user design drafts according to claim 1, characterized in that, The step of aggregating components of the design node based on the tag information and the structural information corresponding to the design node to obtain a candidate set of components includes: Based on the tag information, at least one component in the design node whose morphological similarity, semantic similarity, and frequency of occurrence reach a preset threshold is identified as a general candidate component; Based on the structural information, the components containing multiple basic controls in the design node are identified as candidate components for the business template; The general candidate components and the business template candidate components are combined to form the component candidate set.

5. The method for generating page items based on user design drafts according to claim 1, characterized in that, The step of generating the page metadata structure based on the component tree selected by the user in the component candidate set includes: Based on the component information in the component tree, a basic page metadata structure is generated; Add component annotations to component instances in the basic page metadata structure to obtain the page metadata structure.

6. The method for generating page items based on user design drafts according to claim 3, characterized in that, The step of generating the code corresponding to the page item based on the metadata set and the page metadata structure includes: The design tags and component metadata of the metadata set are populated into a preset technology stack template; Generate component code based on the populated technology stack template; Based on the page metadata structure, the component code is combined into a route component file corresponding to the page item; Configure the theme resources to load the route component file, and generate the code corresponding to the page project.

7. The method for generating page items based on user design drafts according to claim 6, characterized in that, The steps of configuring theme resources for the routing component file and generating the code corresponding to the page project include: Read the topic association configuration field from the resource mapping table to generate a resource path mapping table; The resource path mapping table is added as a configuration file to the routing component file to generate the code corresponding to the page project.

8. The method for generating page items based on user design drafts according to claim 7, characterized in that, The step of configuring theme resource loading for the routing component file further includes: The resource path mapping table is loaded according to the pre-set resource loader to obtain the corresponding resource path; A list of topic resources is generated based on the resource paths and their corresponding priorities; Generate the version hash for each theme resource in the theme resource list; Update the version hash corresponding to each topic resource in the resource mapping table.

9. The method for generating page items based on user design drafts according to claim 1, characterized in that, The step of generating the code corresponding to the page item based on the metadata set and the page metadata structure further includes: When the page project is generated, or when the page project undergoes incremental updates, bidirectional visual collaboration is performed on the design draft and the page project.

10. The method for generating page items based on user design drafts according to claim 9, characterized in that, The steps for bidirectional visual collaboration between the design draft and the page project include: Get the incrementally updated design draft, the incrementally updated metadata collection, and the incrementally updated page project code; Visualize the visual differences between the design draft and the incrementally updated design draft; Visualize the differences between the code of the page item and the code of the page item after the incremental update; The semantic differences between the metadata set and the incrementally updated metadata set are identified according to the pre-defined semantic difference generation rules to obtain semantic differences, and the semantic differences are visualized.

11. A page project generation device based on user-designed drafts, characterized in that, The device includes: The acquisition module is used to acquire the user's design drafts; The extraction module is used to extract variable resources from the design draft to obtain a metadata set. The semantic recognition module is used to perform semantic recognition on the design nodes of the metadata set according to the pre-built semantic analysis model, and obtain the label information of the design nodes; The component aggregation module is used to aggregate components of the design node according to the tag information and the structural information corresponding to the design node, so as to obtain a component candidate set. The first generation module is used to generate the page metadata structure based on the component tree selected by the user in the component candidate set; The second generation module is used to generate the code corresponding to the page item based on the metadata set and the page metadata structure.

12. A storage medium, characterized in that, The storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in claims 1-10.

Images