Page processing method and apparatus

Abstract

The embodiment of the specification provides a page processing method and device, wherein the method comprises: identifying an interactive element in a target page design draft, and acquiring an interaction logic corresponding to the interactive element according to a project process knowledge base, wherein the project process knowledge base stores a mapping relationship between a project element and an interaction behavior; generating an interaction script corresponding to the target page design draft based on the interaction logic, and generating a page prototype file based on the interaction script and the target page design draft, wherein the page prototype file is used to generate an interactive preview page corresponding to the target page design draft. The automatic generation from a static design draft to a runnable prototype is realized, the interactive prototype that can be previewed and operated is obtained without writing code, and the technical threshold of prototype production is significantly reduced.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a page processing method and apparatus. Background Technology

[0002] In the current UI design field, designers typically use professional design tools to produce static visual drafts to showcase page layouts, component styles, and visual details. However, in scenarios such as product requirement reviews, user testing, or development delivery, static design drafts often fail to intuitively demonstrate the page's interaction flow and navigation logic, thus requiring their transformation into clickable and interactive high-fidelity prototypes. Currently, converting static design drafts into interactive prototypes mainly relies on manual operation: designers need to manually define clickable areas on the page, configure hotspot links and navigation targets one by one, and maintain the interaction relationships between multiple pages. This method is not only time-consuming and labor-intensive but also requires a high degree of standardization in the design drafts. Therefore, how to lower the barrier to converting static design drafts into interactive prototypes and reduce manual intervention is a pressing issue that needs to be addressed. Summary of the Invention

[0003] In view of the above, embodiments of this specification provide a page processing method. One or more embodiments of this specification also relate to a page processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a page processing method is provided, including: Identify interactive elements in the target page design draft and obtain the interaction logic corresponding to the interactive elements according to the project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors; Based on the interaction logic, an interaction script corresponding to the target page design draft is generated, and a page prototype file is generated based on the interaction script and the target page design draft. The page prototype file is used to generate an interactive preview page corresponding to the target page design draft.

[0005] According to a second aspect of the embodiments of this specification, a page processing apparatus is provided, comprising: The identification module is configured to identify interactive elements in the target page design draft and obtain the interaction logic corresponding to the interactive elements according to the project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors. The generation module is configured to generate an interaction script corresponding to the target page design draft based on the interaction logic, and to generate a page prototype file based on the interaction script and the target page design draft, wherein the page prototype file is used to generate an interactive preview page corresponding to the target page design draft.

[0006] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the page processing method described above.

[0007] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the page processing method described above.

[0008] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the page processing method described above.

[0009] One embodiment of this specification implements a method to automatically complete interactive behaviors for interactive elements on a page by identifying interactive elements in the target page design draft and obtaining corresponding interactive logic based on a project flow knowledge base that stores the mapping relationship between project elements and interactive behaviors. This eliminates the need for manual configuration of clickable areas and jump targets, improving the efficiency of interaction definition and making the generated interactive logic more consistent with the actual project flow, thus enhancing the accuracy and intelligence of interaction configuration. By generating interactive scripts based on the interactive logic and integrating the interactive scripts with the target page design draft to generate a page prototype file for interactive preview, the system achieves automated generation from static design drafts to runnable prototypes. This allows for obtaining interactive prototypes that can be previewed and operated in a browser without writing code, significantly lowering the technical threshold for prototype creation, shortening the design review and user testing cycle, and improving the communication efficiency between design and development teams. Attached Figure Description

[0010] Figure 1 A schematic diagram of a scenario illustrating a page processing method according to an embodiment of this specification is shown; Figure 2 A flowchart of a page processing method according to an embodiment of this specification is shown; Figure 3 A flowchart illustrating the processing procedure of a page processing method provided in one embodiment of this specification is shown. Figure 4 This specification shows a schematic diagram of the structure of a page processing apparatus according to one embodiment; Figure 5 A structural block diagram of a computing device provided according to one embodiment of this specification is shown. Detailed Implementation

[0011] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0012] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0013] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0014] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0015] The technical solutions provided in this application can employ deep learning models with relatively large parameter scales. However, this large model is merely an example; this application does not limit the number of model parameters supported by the deep learning model used, aiming to meet actual needs. The deep learning models involved in this application can be artificial intelligence-based language models (LM) or multimodal models (MM).

[0016] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0017] Static design drafts: Static design drafts refer to source files generated by professional design tools that contain structured information such as layers, components, and styles, rather than ordinary bitmap images such as JPG / PNG. Their key feature is that they retain editable layer structures and component definitions.

[0018] With the rapid development of internet products, user interface design has become increasingly important in the product development process. Designers typically use professional design tools to produce static design drafts, showcasing the visual layout, component styles, and details of a page. However, in scenarios such as product requirements review, user testing, or development delivery, static design drafts often fail to intuitively demonstrate the page's interaction flow and navigation logic, and cannot realistically simulate the user's actual operating experience. Therefore, converting static design drafts into clickable, interactive, high-fidelity prototypes has become a common requirement in the product development process.

[0019] Currently, converting static design drafts into interactive prototypes mainly relies on the following methods: First, it relies on manual configuration by designers. Existing prototyping tools support defining page navigation relationships through manual connections, but this method requires designers to identify clickable areas on each page, configure hotspot links and target pages one by one, and manually maintain the interaction relationships between multiple pages. When the design draft contains a large number of pages or complex interactions, the workload of manual configuration increases significantly, and it is easy to cause errors in the interaction logic due to human oversight.

[0020] Secondly, there is a reliance on standardized design drafts. Existing automation tools have high requirements for the quality of input design drafts, demanding clear layer naming, standardized component structures, and complete state definitions. However, in practice, many existing design drafts suffer from problems such as inconsistent layer naming (e.g., "rectangle 3" "group copy"), multiple similar blocks not being uniformly classified as components, and missing key state pages (e.g., empty state, loading state). These non-standard design drafts cannot be directly processed by automation, requiring designers to invest additional time in manual repairs, further reducing prototyping efficiency.

[0021] Third, existing tools lack an understanding of project logic. Current prototyping tools only support basic page connection interactions and cannot automatically infer reasonable navigation behavior based on the project semantics of components. For example, when an "order card" exists on a page, the tool cannot understand that it should redirect to the "order details page"; when a component has multiple states (such as "pending shipment" and "shipped"), the tool cannot automatically configure conditional interaction logic based on the state (such as the "refund" button being grayed out and unclickable in the "shipped" state). This lack of understanding of project context leads to deviations between the generated interactive prototypes and the actual project flow.

[0022] Fourth, historical project assets are difficult to reuse. As products iterate, design teams accumulate a large number of historical design drafts, but these existing drafts cannot be directly converted into interactive prototypes due to a lack of interactive information. When new projects need to reference or reuse historical designs, designers still need to configure the interaction logic from scratch, failing to effectively utilize existing design assets and resulting in repetitive work.

[0023] Therefore, how to lower the threshold for converting static design drafts into interactive prototypes, reduce manual intervention, and at the same time be compatible with non-standard design drafts and incorporate project context understanding to achieve effective reuse of design assets has become an urgent problem to be solved in the field of UI design automation.

[0024] To address the aforementioned technical problems, this specification provides a page processing method. This specification also relates to a page processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0025] See Figure 1 , Figure 1 This diagram illustrates a scenario of a page processing method according to an embodiment of this specification. The scenario includes a client 20 and a server 10, with the client 20 and server 10 connected via a network. The client 20 is a terminal device used by a designer, running professional design tools to initiate page processing requests to the server 10 and provide original page design drafts. The server 10 is a backend device providing page processing services, used to execute the page processing method provided in this embodiment.

[0026] Specifically, the designer sends the original page design draft to the server 10 via client 20. After receiving the original page design draft, server 10 first identifies structural problem objects in the original page design draft and updates the original page design draft based on these structural problem objects to obtain the target page design draft. Subsequently, server 10 identifies interactive elements in the target page design draft and obtains the corresponding interaction logic based on a project process knowledge base, which stores the mapping relationship between project elements and interactive behaviors. Finally, server 10 generates an interaction script corresponding to the target page design draft based on the interaction logic, and generates a page prototype file based on the interaction script and the target page design draft, returning the page prototype file to client 20. The designer can preview or download the page prototype file via client 20, which is used to generate an interactive preview page corresponding to the target page design draft. It should be noted that... Figure 1 The scenario shown is merely an application example provided by the embodiments of this specification and does not constitute a limitation on the scope of protection of the embodiments of this specification.

[0027] See Figure 2 , Figure 2 A flowchart of a page processing method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0028] Step 202: Identify the interactive elements in the target page design draft, and obtain the interaction logic corresponding to the interactive elements according to the project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors.

[0029] The target page design draft refers to the page design draft that conforms to the preset structured specifications obtained after the aforementioned steps, and serves as the input for this step.

[0030] Interactive elements refer to visual units in the target page design that have interactive functions and can be triggered by users, including but not limited to content cards such as order cards and product cards, operation buttons such as "View Details" and "Submit", and function icons such as filter and search. The system identifies these elements by analyzing their naming, content, and visual style.

[0031] A project workflow knowledge base is a pre-built knowledge base that stores the mapping relationships between project elements and interactive behaviors. It is used to provide interactive logic for interactive elements that conforms to the project context. This knowledge base can be jointly maintained by project personnel, designers, and developers, and can be iteratively optimized based on user feedback.

[0032] Project elements refer to predefined element types with specific project semantics in the project process knowledge base, such as "order cards," "submit buttons," and "filter icons." Project elements form the left-hand side of the mapping relationships in the knowledge base.

[0033] Interactive behaviors refer to predefined response actions in the project workflow knowledge base that correspond to project elements, including page navigation, function triggering, and conditional response logic. Interactive behaviors form the right-hand side of the mapping relationships in the knowledge base.

[0034] The mapping relationship between project elements and interactive behaviors refers to the core relational data stored in the project process knowledge base, used to establish the correspondence between interactive elements and interactive behaviors. The mapping relationship includes the association between element categories and page navigation targets, the association between element categories and function triggering behaviors, and the association between element states and conditional response logic.

[0035] Interaction logic refers to the complete behavioral definition determined for the interactive elements identified in this step, including page navigation targets, function trigger types, and state-based judgment rules. The interaction logic is obtained by the system based on mapping relationships in the knowledge base and will serve as the basis for generating interaction scripts in subsequent steps.

[0036] In practical applications, when converting static design drafts into interactive prototypes, existing prototyping tools require designers to manually identify clickable areas on the page and configure click events and jump targets one by one. When there are many pages or complex interactions, the configuration workload is enormous and prone to errors. Existing tools only support basic page connection interactions and cannot automatically infer reasonable jump behaviors based on the project semantics of components. For example, when there is an "order card" on the page, the tool cannot understand that it should jump to the "order details page," resulting in a deviation between the generated interactive prototype and the actual project flow. Similar elements in different projects or pages often require similar interactive behaviors, but existing tools lack standardized definitions and reuse mechanisms for interaction logic, leading to repetitive work. This step solves the above problems by automatically identifying interactive elements in the target page design draft and obtaining the corresponding interaction logic based on a project flow knowledge base that stores the mapping relationship between project elements and interactive behaviors, thus achieving intelligent completion of interaction logic.

[0037] In a specific embodiment of this specification, referring to the example above, the target page design draft obtained by the system includes a repaired order list page. This page contains the following elements: a component object named "OrderCard," representing an order card; a button object named "PrimaryButton," representing a "View Details" button; and a funnel-shaped icon at the top of the page, representing the filter function entry. The system identifies interactive elements in the target page design draft and obtains the corresponding interaction logic. The system analyzes the target page design draft according to preset interaction recognition dimensions: Semantic recognition dimension: The system detects that the name "OrderCard" contains the keyword "Card," and the name "PrimaryButton" contains the keyword "Button," listing them as candidate interactive elements. Content recognition dimension: The system detects that "OrderCard" contains content information such as order number and price, conforming to content item characteristics. Morphological recognition dimension: The system detects that the visual style of the top funnel icon conforms to the characteristics of a function icon (simple geometric shape, usually located in the top bar). Based on the above analysis, the system identifies the "OrderCard" component object, the "PrimaryButton" button object, and the funnel icon as interactive elements.

[0038] The system extracts the element features of each interactive element and performs semantic matching with the project elements stored in the project workflow knowledge base. The features of "OrderCard" successfully match the "Order Card" project element in the knowledge base, and the interactive behavior mapped to "Order Card" in the knowledge base is "Jump to the order details page". "PrimaryButton", located inside the order card, successfully matches the "View Button within Card" project element in the knowledge base, and the interactive behavior mapped to "View Button within Card" in the knowledge base is also "Jump to the order details page" (consistent with the card's own jump target). The features of the funnel icon successfully match the "Filter Icon" project element in the knowledge base, and the interactive behavior mapped to "Trigger the filter panel to expand" in the knowledge base. Based on the matching results, the system obtains the corresponding interactive behavior for each interactive element and determines the corresponding interactive logic: the interactive logic for "OrderCard" is: Jump to the order details page; the interactive logic for "PrimaryButton" is: Jump to the order details page; the interactive logic for the funnel icon is: Trigger the filter panel to expand.

[0039] At this point, the system has completed the identification of interactive elements in the target page design draft and obtained the corresponding interaction logic for each interactive element.

[0040] Based on this, by automatically identifying interactive elements in the target page design draft and obtaining the corresponding interaction logic based on the project process knowledge base that stores the mapping relationship between project elements and interactive behaviors, the automation and intelligence of interaction configuration are realized: on the one hand, there is no need to manually identify clickable areas and configure jump targets one by one, which significantly reduces the workload of interaction configuration; on the other hand, based on the project semantic matching of the knowledge base, the obtained interaction logic can fit the real project process, avoiding interaction deviations caused by lack of contextual understanding.

[0041] Furthermore, before identifying interactive elements in the target page design draft, the method further includes: determining structural problem objects in the original page design draft, and updating the original page design draft based on the structural problem objects to obtain the target page design draft.

[0042] The original page design draft refers to a static design source file generated by professional design tools, containing structured information such as layers, components, and styles, rather than a regular bitmap image. Its key feature is that it retains an editable layer structure and component definitions, providing the operational basis for the structured inspection and repair in this step.

[0043] Structural problem objects refer to constituent units in the original page design draft that do not conform to the preset structural rules, including at least one of layer-level objects, block-level objects, and page-level objects. Specifically, layer-level objects refer to single layers with non-standard naming, such as "Rectangle 3"; block-level objects refer to multiple visually or functionally similar visual blocks that are not aggregated into components, such as multiple independent order cards; and page-level objects refer to missing key status pages or target pages, such as empty status pages or order detail pages. The target page design draft refers to the page design draft that conforms to the preset structural rules after fixing and updating the structural problem objects in the original page design draft, and serves as input for subsequent processing steps.

[0044] In practical applications, existing automation tools have high requirements for the quality of input design drafts, demanding clear layer naming, standardized component structures, and complete state definitions. However, many existing design drafts or AI-generated drafts suffer from issues such as chaotic layer naming, unaggregated components, and missing state pages, making them unsuitable for direct automation and requiring manual correction, thus increasing processing costs. For non-standard design drafts, designers need to manually rename layers, create component variations, and fill in missing pages. These operations are time-consuming and labor-intensive, and prone to incomplete repairs due to human error, affecting the accuracy of subsequent processing. With product iteration, design teams accumulate a large number of historical design drafts, but these existing drafts cannot be directly converted into interactive prototypes due to their non-standard structures, resulting in a waste of design assets. This step solves the above problems by performing structured detection and repair on the original page design drafts, automatically identifying and processing structurally problematic objects, enabling non-standard design drafts to enter the subsequent automated processing flow.

[0045] In a specific embodiment of this specification, assume that a designer imports an order list page design draft migrated from another tool. This design draft has a problem with inconsistent layer naming; for example, the layer name for the order card is "Rectangle 2378", the layer name for the product image is "Mask Group 5", and the layer name for the button is "Button 2". The system first scans the original page design draft according to preset structured detection rules to identify structurally problematic objects, specifically layer-level objects. The system detects that the layer names "Rectangle 2378", "Mask Group 5", and "Button 2" do not conform to the preset naming conventions and identifies these layers as layer-level objects with structural problems. Based on the identified structurally problematic objects, the system updates the original page design draft. For layer-level objects, according to preset identifier mapping rules, the system renames "Rectangle 2378" to "OrderCard", "Mask Group 5" to "ProductImage", and "Button 2" to "PrimaryButton". After the above update operation, the system obtains the updated target page design draft, which conforms to the layer naming conventions.

[0046] Based on this, by performing structured detection and repair on the original page design drafts, the system automatically identifies and processes objects with structural problems, eliminating the need for designers to manually rename layers, aggregate components, and fill in missing pages, thus significantly improving the efficiency of design draft preprocessing.

[0047] Furthermore, determining the structural problem objects in the original page design draft includes: performing a structure check on the original page design draft according to the preset structured rules, and determining the structural problem objects in the original page design draft that do not conform to the preset structured rules; the structural problem objects include at least one of layer-level objects, block-level objects, and page-level objects.

[0048] Among them, the preset structured rules refer to a pre-defined set of standards used to measure whether a page design draft is up to standard, including layer naming conventions, componentization conventions, and page integrity conventions. For example, layer names should include the project semantics, such as "OrderCard" instead of "Rectangle 3," similar blocks should be aggregated into components, and critical state pages should exist completely. Structured inspection refers to the process by which the system comprehensively scans and analyzes the page design draft according to the preset structured rules, in order to discover various structural problems in the design draft and provide a basis for subsequent repairs.

[0049] Structural problem objects refer to constituent units identified through structured analysis that do not conform to preset structured rules. The system classifies them hierarchically into layer-level objects, block-level objects, and page-level objects. Layer-level objects refer to the most basic constituent units in the page design draft, i.e., a single layer. When a layer's naming does not conform to preset specifications, such as using the default name "Rectangle 3" or "Group Copy," the layer is identified as a layer-level object in the structural problem object category. Block-level objects refer to visual blocks with independent semantics composed of multiple layers, such as an order card or a product list item. When multiple visually or functionally similar blocks are not aggregated into reusable components, these blocks are identified as block-level objects in the structural problem object category. Page-level objects refer to complete page canvases. When a design draft lacks key pages related to existing components or project logic, such as empty status pages, loading status pages, or detail pages, the missing pages are identified as page-level objects in the structural problem object category.

[0050] In practical applications, simple overall inspection is insufficient to accurately pinpoint specific problems in design drafts. By subdividing structural problem objects into three levels—layer level, block level, and page level—it is possible to achieve fine-grained problem localization in design drafts, providing an accurate basis for subsequent targeted repairs. Different types of problems, such as naming issues, componentization issues, and missing page issues, require different repair strategies. Classifying structural problem objects facilitates the system's use of differentiated processing methods, improving the targeting and efficiency of repairs. Categorizing and statistically analyzing structural problem objects according to their levels makes the quality status of design drafts clearer and more quantifiable, allowing users to understand the standardization level of the design drafts and the progress of repairs.

[0051] In a specific embodiment of this specification, referring to the example above, when the system performs structured detection on the order list page design draft, it scans one by one according to preset structured rules, identifies and categorizes structural problem objects that do not conform to the rules. The system scans all layers in the design draft and detects layers whose names do not conform to preset specifications: the main layer of the order card is named "Rectangle 2378," which should be a name containing project semantics; the product image layer is named "Mask Group 5," which should be a "ProductImage" class name; and the button layer is named "Button 2," which should be "PrimaryButton" or a similar name. The system identifies these layers as structural problem objects at the layer level. The system analyzes the visual blocks in the design draft and finds five structurally similar order card blocks in the list area. These blocks are highly consistent in layout and the types of layers they contain (images, text, buttons), but they are all independent graphic combinations and have not been created as reusable components. The system identifies these similar blocks as structural problem objects at the block level. Based on preset project rules, such as the order list page should include an empty status page, the system checks whether a corresponding page canvas exists in the current design draft. Upon inspection, the design draft only contained a list page with order data, lacking an empty status page to display when the order data was empty. The system identified the missing empty status page as a structural issue object at the page level. At this point, the system completed the structured inspection of the original page design draft, clarifying all structural issue objects that did not conform to the preset structured rules and their respective levels, providing accurate input for subsequent update operations.

[0052] Based on this, by dividing structural problem objects into three levels—layer level, block level, and page level—the system can accurately identify different types and granularities of structural problems in the design draft, avoiding omissions or misjudgments caused by coarse-grained detection. Categorizing structural problem objects at different levels facilitates the system's subsequent adoption of appropriate repair strategies for different types of problems, improving the targeting and effectiveness of repair operations. By hierarchically organizing structural problem objects, the system can visually present the standardization status of the design draft in terms of layer naming, componentization degree, and page integrity, making it easier for designers to understand the quality shortcomings of the design draft.

[0053] Furthermore, updating the original page design draft based on the structural problem object to obtain the target page design draft includes: determining the object type of the structural problem object, wherein the object type includes at least one of layer-level object type, block-level object type, and page-level object type; updating the structural problem object according to the object type to obtain the target page design draft.

[0054] In this context, "object type" refers to the hierarchical category to which the structural issue object belongs. This is determined by the system during the structured detection phase based on the object's granular hierarchy within the page design draft. This includes layer-level, block-level, and page-level object types. Layer-level object types identify structural issue objects as single layers, primarily indicating layer naming that does not conform to preset standards. Block-level object types identify structural issue objects as visual blocks composed of multiple layers, primarily indicating multiple similar blocks not being aggregated into components. Page-level object types identify structural issue objects as complete page canvases, primarily indicating missing key pages related to existing components or project logic.

[0055] In practical applications, layer-level objects, block-level objects, and page-level objects exist at different granular levels in page design drafts, and their corresponding structural problems vary in nature (naming issues, componentization issues, page missing issues), requiring different repair strategies. Applying a uniform update method to all structural problem objects may lead to poor repair results or even introduce new problems. This step, by identifying the object type of the structural problem objects, provides a type basis for subsequent differentiated update operations, making the repair process more targeted.

[0056] In a specific embodiment of this specification, referring to the example above, after completing the structured detection, the system has determined that the structural problem objects in the original page design draft include layer-level objects: "Rectangle 2378", "Mask Group 5", "Button 2"; block-level objects: multiple unaggregated order card blocks; and page-level objects: missing empty state pages. The system further determines the object type of each structural problem object: for layers such as "Rectangle 2378", its object type is determined to be a layer-level object type; for multiple unaggregated order card blocks, its object type is determined to be a block-level object type; and for the missing empty state page, its object type is determined to be a page-level object type. Subsequently, the system performs corresponding update operations on the structural problem objects according to different object types: For layer-level object types, the system renames "Rectangle 2378" to "OrderCard", "Mask Group 5" to "ProductImage", and "Button 2" to "PrimaryButton"; for block-level object types, the system aggregates multiple independent order card blocks into a component object named "OrderCard"; for page-level object types, the system generates an empty page based on a preset page template library and adds it to the design draft. After the above type-based update operations, the system obtains the target page design draft.

[0057] Based on this, by determining the object type of the structural problem, the classification and identification of structural problems at different levels were achieved, providing an accurate type basis for subsequent differentiated update operations. This ensures that the repair strategy is precisely matched with the problem type, avoids the repair deviation caused by a uniform processing method, and improves the pertinence and effectiveness of the design draft update.

[0058] Furthermore, updating the structural problem object according to the object type includes: when the object type includes the layer-level object type, obtaining the current identification information of the layer-level objects in the structural problem object, determining the target identification information corresponding to the current identification information according to the identification mapping rule, and updating the current identification information to the target identification information; when the object type includes the block-level object type, aggregating the block-level objects in the structural problem object to generate a component object including at least one display state; when the object type includes the page-level object type, determining the page information of the page-level objects in the structural problem object, generating a page object to be supplemented based on the page information, and adding the page object to be supplemented to the original page design draft.

[0059] The current identifier information refers to the current name identifier of the layer-level object, which is usually a default name automatically generated by the design tool or a user-defined non-standard name. The identifier mapping rules refer to a set of preset rules used to convert non-standard layer names into standardized names. Rules can be defined based on layer content characteristics, such as mapping "Order Number" to "OrderCard," layer type characteristics such as mapping image layers to "ProductImage," or location characteristics. The target identifier information refers to the standardized name determined according to the identifier mapping rules and conforming to the preset naming conventions, used to replace the current identifier information of the layer-level object.

[0060] Aggregation refers to the process of merging multiple independent block-level objects into a unified component object, including operations such as identifying similar blocks, extracting common structures, and creating component definitions. A component object is a reusable unit generated by aggregating multiple related layers, with a unified definition and configurable variant properties. Display state refers to the visual presentation of a component object in different project scenarios, such as the "normal" or "unavailable" state of a button, or the "pending shipment" or "shipped" state of an order card.

[0061] Page information refers to the characteristic information used to describe the page object to be supplemented, including page type, page purpose, related components, etc., which can be determined by preset project templates or context analysis. The page object to be supplemented refers to the new page canvas generated by the system based on the page information, used to complete the missing pages in the design draft.

[0062] In practical applications, layer-level objects, block-level objects, and page-level objects differ significantly in nature, requiring differentiated repair strategies. Applying a uniform repair method to all types will result in poor repair outcomes. This step designs adaptive update operations for each of the three object types, ensuring that the repair strategy precisely matches the problem type.

[0063] In a specific embodiment of this specification, referring to the above example, after determining the object type of the structural problem object, the system performs corresponding update operations based on different object types: The system retrieves the current identifier information of layer-level objects. Based on the identifier mapping rules, it analyzes the following: "Rectangle 2378" contains text information such as order number, product name, and price, matching the characteristics of an order card; therefore, the system determines its target identifier information as "OrderCard". "Mask Group 5" is an image layer; the system determines its target identifier information as "ProductImage". "Button 2" is a rounded rectangle containing the text "View Details"; therefore, the system determines its target identifier information as "PrimaryButton". The system then updates the current identifier information of these three layers to their corresponding target identifier information.

[0064] The system retrieves multiple unaggregated order card blocks, identifies their common characteristics in layer structure and element types, and aggregates these independent blocks into a component object named "OrderCard". Simultaneously, based on pre-defined project knowledge (orders typically have multiple states), the system configures multiple display states for this component object, including "pending shipment," "shipped," and "refund pending."

[0065] The system identifies the missing page as an empty page. Based on a preset empty page template, it generates a page object containing prompt text and operation buttons to be added to the original page design as a new page canvas. After these update operations, all structural issues in the original page design are addressed, resulting in the target page design.

[0066] Based on this, differentiated update operations were designed for layer-level, block-level, and page-level object types, enabling precise repair of objects with structural problems: For layer-level objects, standardized naming was achieved through identifier mapping, resolving the naming chaos issue; for block-level objects, multi-state component objects were generated through aggregation, resolving the componentization missing issue; and for page-level objects, pages to be supplemented were generated through templates, resolving the missing critical pages issue. These three types of update operations work together to effectively standardize the original page design draft at multiple granular levels, providing a high-quality input foundation for subsequent processing steps.

[0067] Furthermore, identifying interactive elements in the target page design draft includes: identifying the target page design draft according to the interaction identification dimension to determine the interactive elements in the target page design draft, wherein the interaction identification dimension includes at least one of semantic identification dimension, content identification dimension, and form identification dimension.

[0068] Interaction recognition dimension refers to the set of judgment dimensions used to determine whether the page components have interactive functions. The system determines the interactive elements in the target page design draft through a comprehensive evaluation of one or more dimensions.

[0069] Semantic recognition dimension refers to the dimension of interactivity determination based on the naming information of constituent units. The system determines whether a unit has interactive functionality by analyzing whether the name of a layer or component contains preset interactive semantic identifiers (such as keywords like Card, Button, Item, etc.).

[0070] Content recognition dimension refers to the dimension for determining interactivity based on the content information contained in the constituent units. The system analyzes whether the unit contains preset interactive trigger features (such as price, title, status fields, etc.) to determine whether the unit has the potential for clickable interaction as a content item.

[0071] The morphological recognition dimension refers to the dimension of interactivity determination based on the visual presentation information of the constituent units. The system determines whether a unit has interactive functionality as an operation entry point by analyzing whether its visual style conforms to preset interactive style characteristics (such as rounded rectangle background with text, icon shape, etc.).

[0072] In practical applications, relying solely on a single dimension for identification can lead to misjudgments or omissions. For example, some buttons may have irregular names but distinct visual styles, making them difficult to identify using only a semantic dimension; some content cards may lack keywords in their names but contain typical interactive content features. Different design drafts have varying naming habits and visual styles, making it difficult for single-dimensional identification rules to cover diverse real-world situations, resulting in decreased identification accuracy and consequently affecting the accuracy of subsequent interaction logic acquisition. By introducing multi-dimensional identification, the method can adapt to page design drafts with different design styles and naming habits, improving its universality and robustness.

[0073] In a specific embodiment of this specification, referring to the above example, the target page design obtained by the system contains the following constituent units: a component object named "OrderCard"; the component contains a button object named "PrimaryButton"; there is a funnel-shaped icon object at the top of the page named "Icon_184"; and a text layer named "Text_23" with the content "10 orders in total".

[0074] The system identifies these constituent units based on the interaction recognition dimension. The system detects the naming information of each constituent unit: the name "OrderCard" contains the preset interaction semantic identifier "Card", and it is determined that it has interaction potential; the name "PrimaryButton" contains the preset interaction semantic identifier "Button", and it is determined that it has interaction potential; the name "Icon_184" does not contain the preset interaction semantic identifier, and the semantic recognition dimension cannot be determined; the name "Text_23" does not contain the preset interaction semantic identifier, and the semantic recognition dimension cannot be determined.

[0075] The system analyzes the content information of each component: "OrderCard" contains content information such as order number, product name, and price, which meets the interactive trigger characteristics of content items; "Text_23" contains "a total of 10 orders", which is only statistical information and does not have interactive trigger characteristics.

[0076] The system analyzes the visual presentation information of each component: the funnel icon "Icon_184" has a simple geometric shape and is located at the top of the page, which conforms to the interactive style characteristics of a function icon; "OrderCard" is in the shape of a card, which conforms to the visual characteristics of a content card; "PrimaryButton" has a rounded rectangle background with text, which conforms to the interactive style characteristics of a button.

[0077] Based on the combined recognition results across the three dimensions, the system identifies interactive elements as constituent units that simultaneously satisfy multiple dimensional features or have a prominent feature in one dimension: "OrderCard": semantic dimension (including "Card") + content dimension (including price, etc.) + form dimension (card form), identified as an interactive element; "PrimaryButton": semantic dimension (including "Button") + form dimension (button style), identified as an interactive element; "Icon_184": form dimension (function icon style), identified as an interactive element; "Text_23": does not satisfy any of the three dimensions, therefore not considered an interactive element.

[0078] Based on this, a multi-dimensional interactive element identification mechanism was constructed by introducing at least one interaction recognition dimension from semantic recognition, content recognition, and morphological recognition: the semantic dimension identifies explicitly marked interactive elements based on naming information; the content dimension uncovers the interactive potential of hidden content items; and the morphological dimension captures the interactive features presented by visual styles. This multi-dimensional comprehensive evaluation avoids the identification bias caused by a single standard, improves the accuracy and coverage of interactive element identification, and makes the identification results more adaptable to page design drafts with different design styles and naming habits.

[0079] Furthermore, obtaining the interaction logic corresponding to the interactive element based on the project process knowledge base includes: extracting the element features of the interactive element, and using the element features to perform semantic matching with project elements in the project process knowledge base to determine the target project element; and determining the interaction logic corresponding to the interactive element based on the target interactive behavior mapped by the target project element.

[0080] Element features refer to the key attribute information of interactive elements, used to match them with item elements in the knowledge base. Element features may include element name information, type information, content information, and contextual information.

[0081] Semantic matching refers to comparing the semantic similarity of interactive element features with project elements in the project process knowledge base, rather than a simple string matching. Semantic matching can handle different expressions of the same project concept, improving the flexibility and accuracy of matching.

[0082] Project elements refer to predefined standard element types with specific project semantics in the project process knowledge base, such as "order cards," "submit buttons," and "filter icons." Each project element is associated with one or more interactive behaviors in the knowledge base. Target project elements refer to the project elements in the knowledge base with the highest similarity to interactive elements, determined through semantic matching, and serve as the basis for subsequent matching to obtain interactive behaviors. Target interactive behaviors refer to the interactive behaviors in the knowledge base that map to the target project elements, including page navigation goals, function triggering behaviors, or conditional response logic, which will be identified as the interactive logic corresponding to the interactive elements.

[0083] In practical applications, element naming in design drafts may vary due to designers' personal habits (e.g., "order card" might be named "OrderCard," "order_item," "card_order," etc.). If only exact string matching is used, many interactive elements will fail to find corresponding project elements in the knowledge base, impacting the success rate of acquiring interaction logic. The same project concept may have multiple expressions, requiring a matching mechanism that understands semantic similarity, rather than rigid exact matching, to improve the method's adaptability and robustness. Semantic matching enables automatic mapping from interactive elements to knowledge base project elements, allowing for the acquisition of corresponding interactive behaviors for various elements without manual intervention, further enhancing the automation level of interaction configuration.

[0084] In a specific embodiment of this specification, the system identifies interactive elements in the target page design draft, including an "OrderCard" component object, a "PrimaryButton" button object, and a funnel icon object. The system then performs this step to obtain the corresponding interaction logic for these interactive elements.

[0085] The system extracts the feature information of each interactive element: The "OrderCard" component object: The element name is "OrderCard", the type is card, and it contains text information such as order number and price. It is located on the order list page. The "PrimaryButton" button object: The element name is "PrimaryButton", the type is button, and it contains the text "View Details". It is located inside the "OrderCard" component. The funnel icon object: The element name is "Icon_184", the type is icon, and the visual style is funnel shape. It is located in the top bar of the page.

[0086] The system will perform semantic matching between the extracted element features and the project elements stored in the project process knowledge base: The characteristics of “OrderCard” are highly similar to the “Order Card” item element in the knowledge base in semantics. Both are card-type elements that represent order information. Therefore, “Order Card” is identified as the target item element. The characteristics of "PrimaryButton" are: located within a card, with the text "View Details". A semantic match was successfully found with the "View Button within Card" item element in the knowledge base, confirming "View Button within Card" as the target item element. Characteristics of the funnel icon object: funnel shape, top bar position. A semantic match was successful with the "Filter Icon" item element in the knowledge base; therefore, "Filter Icon" is identified as the target item element.

[0087] Based on the matched target item elements, the system retrieves the corresponding target interaction behavior from the knowledge base: The target interactive behavior mapped to the "Order Card" is "jump to the order details page", and the system identifies this behavior as the "OrderCard" interactive logic; The target interaction behavior mapped to the "view button in card" is also "jump to order details page", and the system identifies this behavior as the interaction logic of "PrimaryButton"; The target interactive behavior mapped to the “filter icon” is “trigger the filter panel to expand”, and the system identifies this behavior as the interactive logic of the funnel icon object; At this point, the system has obtained the corresponding interaction logic for each interactive element through semantic matching.

[0088] Based on this, by extracting the element features of interactive elements and semantically matching them with project elements in the project process knowledge base, intelligent mapping from design draft elements to standard elements in the knowledge base is achieved, avoiding matching failures caused by naming differences and improving the success rate and flexibility of interactive logic acquisition. At the same time, by determining the target project element and acquiring the corresponding target interactive behavior through semantic matching, the process of acquiring interactive logic is fully automated, and interactive behaviors that conform to the project context can be assigned to various interactive elements without manual intervention.

[0089] Furthermore, determining the interaction logic corresponding to the interactive element based on the target interaction behavior mapped by the target item element includes: when the target item element is a multi-state item element, determining the interaction behavior corresponding to the target item element in multiple display states respectively; and determining the interaction logic corresponding to the interactive element based on the interaction behavior corresponding to the multiple display states respectively.

[0090] Among them, multi-state project elements refer to project element types defined in the project process knowledge base that have multiple different display states. For example, the "order card" project element can have multiple states such as "pending shipment," "shipped," and "refund in progress," and the corresponding interactive behaviors may be different in different states.

[0091] Presentation state refers to the specific presentation form of a multi-state project element in different project scenarios, usually corresponding to different state variations of a component object. Each presentation state can be associated with independent interactive behavior definitions.

[0092] The interactive behaviors corresponding to multiple display states refer to the interactive behaviors defined separately for each display state of a multi-state item element. For example, clicking the order card in the "Pending Shipment" state will redirect to the shipping page; clicking the order card in the "Shipped" state will redirect to the logistics details page; and clicking the order card in the "Refund in Progress" state will redirect to the refund progress page.

[0093] In practical applications, many components on a page have multiple display states, such as different states of an order card or different states of a button. The interactive behaviors that should be executed in different states often differ. If only a single interactive behavior is configured for the target item element, it cannot meet the differentiated interaction needs in multi-state scenarios, resulting in generated interaction logic that does not match the actual project flow. This step achieves fine-grained adaptation between interaction logic and component states by determining the corresponding interactive behavior for each display state of a multi-state item element.

[0094] In a specific embodiment of this specification, referring to the example above, the system determines the target item element corresponding to the interactive element "OrderCard" as "Order Card" through semantic matching. The "Order Card" item element stored in the project process knowledge base is defined as a multi-state item element, which has the following display states and their corresponding interactive behaviors: Display state - corresponding interactive behavior, pending shipment state - jump to the order shipment page, shipped state - jump to the logistics details page, refund in progress state - jump to the refund progress page, transaction completed state - jump to the order evaluation page.

[0095] The system determines the interactive behaviors corresponding to the multi-state item element "Order Card" in the above-mentioned display states: for "Pending Shipment", the corresponding interactive behavior is "Jump to Order Shipment Page"; for "Shipped", the corresponding interactive behavior is "Jump to Logistics Details Page"; for "Refund in Progress", the corresponding interactive behavior is "Jump to Refund Progress Page"; and for "Transaction Completed", the corresponding interactive behavior is "Jump to Order Evaluation Page".

[0096] Based on the interactive behaviors corresponding to these multiple display states, the system determines the interaction logic for the interactive elements of "OrderCard" as a complete mapping set containing the correspondence between the aforementioned states and behaviors. This interaction logic will be used in subsequent steps to generate interaction scripts, enabling "OrderCard" to execute differentiated response behaviors when triggered in different states.

[0097] Based on this, by determining the corresponding interactive behaviors for each display state of a multi-state project element, the interactive logic obtained by the interactive element can be matched with its multi-state attributes, thus achieving fine-grained adaptation between interactive behaviors and component states. This avoids logical deviations in multi-state scenarios due to single behavior configurations and improves the fit between interactive logic and real project processes.

[0098] Step 204: Generate an interaction script corresponding to the target page design draft based on the interaction logic, and generate a page prototype file based on the interaction script and the target page design draft, wherein the page prototype file is used to generate an interactive preview page corresponding to the target page design draft.

[0099] Interactive scripts refer to a set of instructions that can be executed by a computer, generated based on interactive elements and their corresponding interactive logic. These instructions are used to implement the response behavior when interactive elements are triggered, including page navigation, function triggering, and state switching. Interactive scripts are usually written in scripting languages ​​such as JavaScript, but this step focuses on their generation process rather than their specific code form.

[0100] A page prototype file refers to a collection of files generated by associating the visual information of the target page design with the interaction script. It typically includes multiple page files, style files, and resource files, and can be opened in a browser to present an interactive preview interface.

[0101] An interactive preview page refers to an interactive interface that is presented after opening the page prototype file in a browser. It can realistically respond to user operations. Users can click on elements on the page to experience preset jumps and functions, simulating the usage process of a real product.

[0102] In practical applications, converting static design drafts into interactive prototypes typically requires manually writing HTML, CSS, and JavaScript code to integrate the visual presentation of the design with interactive behavior, which is quite challenging for designers without programming skills. The visual information and interactive behaviors of the design draft exist separately in the design tools and code, making automatic association difficult and resulting in high costs for manual consistency maintenance and iteration. The generated prototype files lack a standardized format, making them unsustainable on different devices and browsers, and inconvenient for team members to view and test at any time. By automatically generating interactive scripts and integrating them with the design drafts into standardized page prototype files, these problems are solved. This achieves fully automated generation from static design to a runnable prototype, providing an interactive preview page without manual coding.

[0103] In a specific embodiment of this specification, referring to the above example, the system has obtained the corresponding interaction logic for the interactive elements in the target page design: "OrderCard" card object: clicking it will redirect to the order details page; "PrimaryButton" button object: clicking it will redirect to the order details page (consistent with the card's redirection target); funnel icon object: clicking it will trigger the expansion of the filter panel.

[0104] The system generates a set of instructions describing the triggered response behaviors based on each interactive element and its interaction logic. This instruction set includes the following core logic: registering click listeners for all "OrderCard" card elements, redirecting the page to the order details page when a card is clicked; registering click listeners for all "PrimaryButton" button elements, also redirecting to the order details page when a button is clicked, and preventing event bubbling to avoid simultaneously triggering card redirects; and registering click listeners for the funnel icon element, controlling the display or hiding state of the filter panel (i.e., toggling visibility) when the icon is clicked. The system encapsulates these instruction sets into a complete interactive script file, such as `interaction.js`, which is independent of the visual content and contains only the behavioral logic.

[0105] The system first exports each page canvas from the target page design draft as an independent HTML page file. Each file contains the visual structure and style references for the corresponding page. For example: order-list.html: visual content for the order list page (including order cards, buttons, filter icons, etc.); order-detail.html: visual content for the order details page; empty-state.html: visual content for the empty state page. Then, the system associates the generated interactive scripts with these HTML page files. Specifically, it adds a reference to the interactive script to each HTML file, allowing the script to be automatically loaded and executed after the page loads. The system also collects and organizes the style files and resource files referenced in the pages. Finally, all files, including HTML files, script files, style files, and resource files, are packaged into a single compressed file as the page prototype file output. After obtaining this page prototype file package, the designer decompresses it and opens the order-list.html file in a browser. The resulting interactive preview page is visually identical to the design draft and features realistic interactive behavior. Clicking any order card or the "View Details" button will automatically redirect your browser to the order-detail.html page; clicking the filter icon will expand or collapse the filter panel. The entire process requires no coding and provides an interactive experience indistinguishable from that of a real product.

[0106] Based on this, by automatically generating interaction scripts based on interaction logic and integrating these scripts with the target page design drafts into a page prototype file, a fully automated transformation from static design to a runnable prototype is achieved. The automatic generation of interaction scripts eliminates the coding barrier, the automatic association between visuals and behavior avoids consistency issues associated with manual maintenance, and the standardized page prototype file format ensures convenient cross-platform previewing. The resulting prototype file for interactive preview pages allows designers to obtain an interactive experience consistent with the actual product's usage flow without programming, significantly improving the efficiency and usability of prototype creation.

[0107] Furthermore, generating the interaction script corresponding to the target page design based on the interaction logic includes: generating an element trigger instruction set according to the interactive element and the interaction logic, wherein the element trigger instruction set is used to describe the response behavior when the interactive element is triggered; and encapsulating the element trigger instruction set to obtain the interaction script corresponding to the target page design.

[0108] The element trigger instruction set refers to a set of logical descriptions generated based on interactive elements and their corresponding interaction logic, describing the response behavior that should be executed when the element is triggered by the user. The element trigger instruction set records the correspondence of "when an element is triggered, execute a certain behavior" in a structured form and is the core content carrier of the interactive script.

[0109] Responsive behavior refers to the specific actions performed after an interactive element is triggered, including page navigation (such as navigating to a specified page), function triggering (such as expanding a panel or submitting a form), and state switching (such as changing the display state of a component). Responsive behavior is defined by interaction logic and described through element trigger instruction sets. Encapsulation refers to the process of integrating and organizing the generated element trigger instruction sets according to preset formats and specifications to form a complete interactive script file that can be recognized and executed by a computer. The encapsulated interactive script can be associated with the target page design.

[0110] In practical applications, the acquired interaction logic is an abstract rule definition (such as "the order card should redirect to the order details page"), which needs to be transformed into a concrete description that the computer can understand and execute in order to achieve interactive effects on the actual page. This step transforms the abstract interaction logic into a structured behavioral description by generating element trigger instruction sets, solving the problem of conversion from logical definition to executable description. When there are multiple interactive elements in the target page design, each element has its own interaction logic, which needs to be uniformly organized and integrated to form a complete interactive behavior description system. This step encapsulates multiple element trigger instruction sets into interactive scripts, achieving centralized management and unified invocation of multi-element interactive behaviors.

[0111] In a specific embodiment of this specification, referring to the above example, the system has obtained the corresponding interaction logic for the interactive elements in the target page design: "OrderCard" card object: clicking it will redirect to the order details page; "PrimaryButton" button object: clicking it will redirect to the order details page (consistent with the card's redirection target); funnel icon object: clicking it will trigger the expansion of the filter panel.

[0112] The system generates corresponding element trigger commands based on each interactive element and its corresponding interaction logic. For the "OrderCard" card object, the generated command is: when the element named "OrderCard" is clicked, execute the page navigation behavior, redirecting to the "Order Details Page". For the "PrimaryButton" button object, the generated command is: when the element named "PrimaryButton" is clicked, execute the page navigation behavior, redirecting to the "Order Details Page", with an added "Prevent Event Bubbling" behavior control to avoid simultaneously triggering navigation of the parent card. For the funnel icon object, the generated command is: when the element named "Icon_184" is clicked, execute the function trigger behavior, triggering the expansion or collapse of the "Filter Panel" to toggle its visibility. The system organizes these commands in a unified format, forming an element trigger command set. This command set records the identification information, trigger conditions, response behavior type, and behavior parameters such as navigation target and target panel for each interactive element in a structured manner.

[0113] The system encapsulates the generated element trigger instruction sets according to preset script specifications: adding necessary execution frameworks such as initialization listening after page loading and a unified error handling mechanism, and optimizing the organization of instructions according to the structure of the target page design, such as grouping element instructions within the same page. After encapsulation, the system obtains a complete interactive script file containing the trigger response logic for all interactive elements in the target page design. This script can be associated with the visual file of the target page design in subsequent steps, so that the script automatically loads and takes effect when the user opens the preview page. For example, when the user clicks the order card in the actual preview page, the corresponding instruction in the script is triggered, and the page jumps to the order details page; when the filter icon is clicked, the filter panel is expanded.

[0114] Based on this, by generating element trigger instruction sets according to interactive elements and their interaction logic, and encapsulating the instruction sets into interactive scripts, the transformation from abstract interaction logic to executable behavior descriptions is realized: the element trigger instruction sets clearly record the response behavior of each interactive element in a structured manner, bridging the gap between logical definition and executable description; the encapsulated interactive scripts unify the instructions of multiple elements, forming a complete behavior description system, which facilitates subsequent association and integration with visual pages, laying the foundation for the final generation of interactive preview pages.

[0115] Furthermore, the step of generating a page prototype file based on the interaction script and the target page design draft includes: generating a visual page file based on the target page design draft; and associating the interaction script with the visual page file to obtain the page prototype file.

[0116] Visual page files, in this context, refer to files generated from the visual information in the target page design draft to present the page's appearance. They are typically in HTML format and include the page's structure and layout, text content, image resources, and style definitions. Visual page files retain the original visual presentation of the design draft but do not contain interactive logic.

[0117] Linking refers to the process of establishing a connection between interactive scripts and visual page files, enabling the interactive scripts to be loaded and executed simultaneously when the visual page files are loaded, thereby integrating the page's visuals and interactive behavior. Linking methods include adding references to the interactive scripts in the visual page files and embedding script content into the page files.

[0118] A page prototype file refers to a collection of executable files generated by associating visual page files with interactive scripts. It typically contains multiple page files, script files, style files, and resource files, and can be opened in a browser to present a design prototype with complete interactive functions.

[0119] In practical applications, the target page design draft itself only contains visual presentation information; the interaction scripts exist independently of the design draft. The two need to be linked to form a complete interactive prototype. Without an effective linking mechanism, the visual page will be unable to execute interactive behaviors, and the interaction scripts will not be able to apply to the correct page elements. When the target page design draft contains multiple page artboards, a corresponding visual page file needs to be generated for each page, ensuring that each page file can be correctly linked to the interaction script to achieve a consistent interactive experience across pages. The generated page prototype file needs to contain complete visual resources such as images, styles, and behavioral resources such as interaction scripts, ensuring that these resources can be correctly loaded and executed in the browser to form a usable, interactive preview page.

[0120] In a specific embodiment of this specification, referring to the example above, the system obtains the target page design draft, which includes an order list page, an order details page, and an empty state page. It then obtains the interaction logic for the interactive elements and further defines and generates interaction scripts. The system exports each page canvas in the target page design draft as an independent visual page file: the order list page canvas is exported as an `order-list.html` file, which contains the complete visual presentation of the order list page: the position, style, and content of elements such as order card components, button components, and filter icons are consistent with the design draft; the order details page canvas is exported as an `order-detail.html` file, which contains the visual information of the order details page; and the empty state page canvas is exported as an `empty-state.html` file, which contains the visual information of the empty state page. During the export process, the system simultaneously extracts the style definitions used in the design draft, such as colors, fonts, and spacing, and generates corresponding style files such as `styles.css`. It also exports the image resources in the design draft as independent image files such as `product-image.png`. All visual page files include references to style files and image resources during generation, ensuring that the original visual appearance of the design is correctly rendered when opened in a browser.

[0121] The system associates the previously generated interaction scripts with each visual page file: a reference to the interaction script is added to the appropriate location in the `order-list.html` file. This ensures that when a user opens the order list page in their browser, the interaction script is automatically loaded and executed after the page loads, registering event listeners for interactive elements on the page. Similarly, references to the same interaction script are added to the `order-detail.html` and `empty-state.html` files. Although these pages may not contain elements that require interaction, consistently referencing the script maintains consistency in the file structure and reserves space for possible future interactive expansions. For differentiated interaction logic that needs to be executed on specific pages, such as the order details page potentially requiring a back button interaction, the system can generate corresponding instruction sets for different pages when generating the interaction script, or implement differentiated behavior through page recognition logic within the script.

[0122] The system organizes and packages all generated files: visual page files: order-list.html, order-detail.html, empty-state.html; interaction script file: interaction.js; style file: styles.css; image resource files: several .png and .jpg files. The system packages these files into a single complete file collection, which serves as the final page prototype file output. After obtaining this prototype file, the designer decompresses it and opens order-list.html in a browser to see an interactive preview page that matches the design draft visually and has complete interactive functions: clicking the order card redirects to the order details page, clicking the filter icon expands the filter panel, and all interactive behaviors execute as expected.

[0123] Based on this, by generating visual page files from the target page design draft and associating the interaction scripts with these visual page files, a complete integration of visual and interactive information from the design draft was achieved: the visual page files accurately reproduce the original appearance of the design draft, and the associated interaction scripts endow the page with realistic interactive functions; the combination of the two forms a complete interactive prototype. Simultaneously, by establishing associations for each visual page file in multi-page scenarios, consistency of cross-page interactive experience was ensured; and by fully packaging all visual and behavioral resources, the prototype file was guaranteed to be correctly loaded and executed in different environments, ultimately resulting in an interactive preview page that can be directly used for review and testing.

[0124] Furthermore, the method also includes: obtaining user behavior adjustment information for interactive elements in the page prototype file; and updating the mapping relationship in the project process knowledge base based on the behavior adjustment information.

[0125] Among them, behavior adjustment information refers to the operation information that users manually modify the preset interactive behaviors of interactive elements during the preview or use of page prototype files. Behavior adjustment information may include changes to the navigation target, such as changing page A to page B, changes to the interaction type, such as changing page navigation to pop-up triggering, and adjustments to conditional logic, etc.

[0126] Updating refers to the process of modifying, optimizing, or supplementing the mapping relationship between project elements and interactive behaviors stored in the project process knowledge base based on user behavior adjustment information. The updated knowledge base can support the user's adjusted interactive behaviors in subsequent processing.

[0127] In practical applications, project workflow knowledge bases are often static after construction, unable to self-optimize and evolve based on user feedback during actual use. As projects develop and user needs change, static knowledge bases may gradually become out of touch with real requirements. Different projects, teams, and even designers may have different preferences and needs regarding the interactive behavior of the same type of elements. Static knowledge bases struggle to adapt to these personalized differences, resulting in interactive logic that may not meet user expectations. Updating the knowledge base typically requires project personnel, designers, and developers to collaborate again, manually sorting and modifying mapping relationships—a tedious and inefficient process. This step, by obtaining user behavior adjustment information for interactive elements in the page prototype file and updating the mapping relationships in the knowledge base accordingly, enables the knowledge base to dynamically evolve and continuously adapt to user needs and project changes.

[0128] In a specific embodiment of this specification, referring to the example above, the designer obtained an interactive preview page of the order list page through the page prototype file generated by the system. During the review meeting, the product manager pointed out that while the "View Details" button in the order card currently redirects to the order details page when clicked, a more reasonable flow for the project would be redirecting to the order tracking page. The designer directly adjusted the interactive behavior of the "View Details" button in the preview page: using the debugging tools or editing interface provided on the page, the button's redirection target was changed from the "order details page" to the "order tracking page." The system captured this adjustment operation and generated corresponding behavior adjustment information, including: the adjusted interactive element: the "View Details" button in the order card; the interaction behavior before adjustment: redirecting to the order details page; the interaction behavior after adjustment: redirecting to the order tracking page; and contextual information such as the adjustment time and user identifier.

[0129] After obtaining the behavior adjustment information, the system updates the mapping relationships in the project process knowledge base. Specifically: the system locates project elements in the knowledge base that match the "View Details" button, such as the "View Button within Card"; checks whether the current mapped interaction behavior of this project element is "Jump to Order Details Page"; and based on the user's behavior adjustment information, updates the mapped interaction behavior of this project element to "Jump to Order Logistics Tracking Page," or adds a weight adjustment to the mapping relationship, such as recording the adjustment as a preference option. After the update, the mapping relationships in the project process knowledge base are optimized. When the system subsequently processes new page designs containing similar "View Details" buttons, it will prioritize the user-adjusted "Jump to Order Logistics Tracking Page" as the default interaction logic, making the generated interaction behavior more in line with the actual needs of the project.

[0130] Based on this, by acquiring user behavior adjustment information for interactive elements in the page prototype file and updating the mapping relationship in the project process knowledge base according to the adjustment information, the knowledge base has the ability to continuously learn and evolve from user feedback: on the one hand, the user's personalized adjustments can be absorbed by the knowledge base, making the subsequently generated interaction logic more in line with the actual project needs; on the other hand, the dynamically updated knowledge base reduces manual maintenance costs, avoids the problem of static knowledge bases becoming disconnected from project development, and realizes the self-optimization and iteration of the knowledge base.

[0131] Furthermore, the method also includes: storing the page prototype file in a prototype pattern library, wherein the prototype files in the prototype pattern library are used for reuse when page processing is performed on the page design draft to be processed.

[0132] The prototype pattern library refers to a reusable library used to store page prototype files that have been confirmed or verified by users; it is an organization-level collection of reusable assets. The prototype files stored in the prototype pattern library contain complete visual presentations and interaction logic, which can be used as reference templates or processing guidelines when subsequently processing new page design drafts.

[0133] Reuse refers to the process of calling stored successful prototype files from the prototype pattern library when processing new page design drafts, referencing or adopting their interaction logic, structural specifications, or processing methods to improve the efficiency and quality of processing new design drafts. Reuse can be full reuse (directly using the entire prototype) or incremental reuse (referencing some features).

[0134] The page design draft to be processed refers to the new original page design draft that has not yet been processed by this method. It needs to undergo a series of processing operations such as structure detection, interactive element identification, interaction logic acquisition and prototype file generation.

[0135] In practical applications, each new design draft involves starting from scratch with structural repair, interaction identification, and logic acquisition. Existing successful cases and processing experience cannot be effectively saved and reused, resulting in a waste of knowledge assets. When multiple page design drafts contain similar functional modules or interaction patterns, the same processing and configuration work needs to be repeated, lacking an effective reuse mechanism, leading to inefficiency. Different designers may use different interaction logics and specifications when handling similar pages, lacking a unified reference, making it difficult to guarantee the consistency and quality of team outputs. This step solves the above problems by storing the generated page prototype files in a prototype pattern library and providing a reuse basis for subsequent processing, thus realizing the preservation and reuse of design assets.

[0136] In a specific embodiment of this specification, referring to the example above, the designer obtained a prototype file for the order list page using this method. This prototype file underwent review and verification, and its interaction logic (clicking an order card to jump to the details page, expanding the filter panel with the filter icon, etc.) was confirmed by the team as a successful case meeting project requirements. The system stores this page prototype file in the prototype pattern library. During storage, the system can simultaneously record the prototype file's metadata, including: prototype type: order list page; core interactive elements: order card, view details button, filter icon; corresponding interaction logic: clicking a card to jump to the details page, clicking a button to jump to the details page, expanding the panel with the filter icon; applicable scenario: e-commerce backend order management module. This prototype file becomes a successful case in the pattern library, which can be referenced and reused by other team members when processing similar pages in the future.

[0137] Another designer on the team needed to work on a new design for a refund order list page. This page was similar in structure and function to the order list page: both included list cards, action buttons, and filtering functionality. When working on this new design, the processing tool provided by this method was activated, and a successful reuse case was selected from the prototype pattern library. The system retrieved the previously stored order list page prototype file from the pattern library, extracting reusable information: Regarding structural specifications: referencing the layer naming conventions and componentization methods of the order list page, similar blocks in the new design were automatically named and aggregated; Regarding interaction logic: referencing the mapping relationship between clicking on order cards and jumping to the details page, the interaction logic for clicking on refund order cards and jumping to the refund details page was automatically configured for the new design; referring to the interaction behavior of filter icons, the interaction logic for expanding the filter panel was configured for the filter icons in the new design. The designer only needed to make minor adjustments to the intermediate results generated by the system based on reuse, such as changing the jump target from "order details page" to "refund details page," to quickly obtain a page prototype file that met the requirements, without having to configure everything from scratch. As the team processed an increasing number of page design drafts, more and more successful cases were stored in the prototype pattern library. The library gradually covered typical page types across various project scenarios, including order management, product management, and marketing campaigns, forming an organizational-level reusable asset repository. When new members join the team or handle new types of pages, they can draw upon the pattern library for reference, significantly improving the team's overall processing efficiency and quality consistency.

[0138] Based on this, by storing the generated page prototype files in a prototype pattern library and providing a basis for reuse in subsequent processing, the effective preservation and reuse of design assets is achieved: on the one hand, the experience and standards of successful cases are preserved, avoiding duplication of work and knowledge loss; on the other hand, the reuse mechanism provides a reference template and basis for processing new design drafts, improving processing efficiency and ensuring the consistency and quality of team outputs. As the pattern library continues to grow, its value as an organizational-level knowledge asset also continues to increase.

[0139] This specification provides a page processing method, comprising: identifying interactive elements in a target page design draft, and obtaining the interaction logic corresponding to the interactive elements according to a project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors; generating an interaction script corresponding to the target page design draft based on the interaction logic, and generating a page prototype file based on the interaction script and the target page design draft, wherein the page prototype file is used to generate an interactive preview page corresponding to the target page design draft. This method achieves automatic identification and repair of structural problems in the original page design draft, such as non-standard layer naming, unaggregated components, and missing key pages, by identifying and updating structural problem objects in the original page design draft. This allows non-standard design drafts that do not conform to preset specifications to enter subsequent automated processing flows, thereby reducing reliance on the standardization of the input design draft, reducing manual correction costs, and improving the applicability and robustness of the method. By identifying interactive elements in the target page design draft and retrieving corresponding interaction logic from a project workflow knowledge base that stores the mapping relationship between project elements and interactive behaviors, the system can automatically complete interactive behaviors for interactive elements on the page that conform to the project context. This eliminates the need for manual configuration of clickable areas and jump targets, improving the efficiency of interaction definition and making the generated interaction logic more aligned with the actual project workflow, thus enhancing the accuracy and intelligence of interaction configuration. Furthermore, by generating interaction scripts based on the interaction logic and integrating these scripts with the target page design draft to create a page prototype file for interactive preview, the system automates the generation from static design drafts to a runnable prototype. This allows for the creation of interactive prototypes that can be previewed and operated in a browser without writing code, significantly lowering the technical barrier to prototype creation, shortening the design review and user testing cycle, and improving communication efficiency between the design and development teams.

[0140] The following is in conjunction with the appendix Figure 3 Taking the application of the page processing method provided in this specification in page design as an example, the page processing method will be further explained. Among other things, Figure 3 The present specification shows a flowchart of a page processing method according to an embodiment, which specifically includes the following steps.

[0141] Step 302: Perform a structure check on the original page design draft according to the preset structure rules to identify structural problem objects in the original page design draft that do not conform to the preset structure rules.

[0142] In one embodiment, designer Xiao Wang needs to design a profile page for an app, including a user avatar, nickname, number of followers, and an edit profile button. He imported a basic design draft from the template library, but there are some structural issues. The system scanned the original design draft and found the following structurally problematic objects: Layer-level objects: The avatar layer is named "Ellipse 5", and the edit button layer is named "Rectangle 12"; Block-level objects: The follower count area (containing three text blocks: "Following", "Fans", and "Likes") has a similar structure but is not aggregated; Page-level objects: The "Edit Profile" page (the target page after clicking the edit button) is missing.

[0143] Step 304: Determine the object type of the structural problem object, wherein the object type includes at least one of layer-level object type, block-level object type, and page-level object type; update the structural problem object according to the object type to obtain the target page design draft.

[0144] Specifically, when the object type includes layer-level objects, the current identifier information of the layer-level objects in the structural problem object is obtained, the target identifier information corresponding to the current identifier information is determined according to the identifier mapping rules, and the current identifier information is updated to the target identifier information; when the object type includes block-level objects, the block-level objects in the structural problem object are aggregated to generate component objects including at least one display state; when the object type includes page-level objects, the page information of the page-level objects in the structural problem object is determined, the page objects to be supplemented are generated based on the page information, and the page objects to be supplemented are added to the original page design draft.

[0145] In one embodiment, the system updates according to object type: Layer level: rename "ellipse 5" to "AvatarImage" and "rectangle 12" to "EditButton"; Block level: aggregate the three text blocks into a "StatsBar" component; Page level: generate an "EditProfile" page based on the template and add it to the design draft to obtain the target page design draft.

[0146] Step 306: Identify the target page design draft based on the interaction recognition dimension to determine the interactive elements in the target page design draft. The interaction recognition dimension includes at least one of the semantic recognition dimension, content recognition dimension, and form recognition dimension.

[0147] In one embodiment, the system identifies interactive elements based on interaction recognition dimensions: avatar (morphological dimension: circular image); edit button (semantic dimension: name contains "Button"; morphological dimension: rounded rectangle); and follower count area (content dimension: contains numbers).

[0148] Step 308: Extract the element features of interactive elements and use the element features to perform semantic matching with project elements in the project process knowledge base to determine the target project element.

[0149] In one embodiment, the system extracts element features and matches them with the project process knowledge base: avatar - matches "user avatar"; edit button - matches "data edit button"; follower count area - matches "data statistics column".

[0150] Step 310: When the target item element is a multi-state item element, determine the interactive behavior corresponding to the target item element in each of the multiple display states; determine the interactive logic corresponding to the interactive element based on the interactive behavior corresponding to each of the multiple display states.

[0151] In one embodiment, the mapping relationships in the knowledge base are as follows: User avatar: clicking it will enlarge the avatar to view it; Profile edit button: clicking it will take you to the profile edit page; Data statistics bar: clicking it will take you to the corresponding list page (following list, follower list, etc.).

[0152] Step 312: Generate an element trigger instruction set based on the interactive element and the interaction logic, wherein the element trigger instruction set is used to describe the response behavior when the interactive element is triggered; encapsulate the element trigger instruction set to obtain the interaction script corresponding to the target page design draft.

[0153] In one embodiment, the system generates an element trigger instruction set: clicking the avatar - zooms in for a preview; clicking the edit button - jumps to the EditProfile page; clicking the follower count area - jumps to different pages based on the specific text clicked. This is then encapsulated to obtain the interaction script.

[0154] Step 314: Generate a visual page file based on the target page design draft, associate the interaction script with the visual page file, and obtain the page prototype file.

[0155] Specifically, obtain user behavior adjustment information for interactive elements in the page prototype file; update the mapping relationship in the project process knowledge base based on the behavior adjustment information.

[0156] Specifically, the page prototype file is stored in a prototype pattern library, where the prototype files in the prototype pattern library are reused when processing the page design draft.

[0157] In one embodiment, the system exports the design draft as HTML page files (profile.html, edit-profile.html), associates the interactive scripts, and packages them to generate a page prototype file. During subsequent user previews, the jump target of the edit button is adjusted to "Edit Profile Page 2.0," and the system updates the knowledge base. This prototype file is stored in the pattern library and can be reused when processing similar profile pages later.

[0158] Corresponding to the above method embodiments, this specification also provides embodiments of a page processing apparatus. Figure 4 A schematic diagram of the structure of a page processing apparatus according to one embodiment of this specification is shown. Figure 4 As shown, the device includes: The identification module 402 is configured to identify interactive elements in the target page design draft and obtain the interaction logic corresponding to the interactive elements according to the project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors. The generation module 404 is configured to generate an interaction script corresponding to the target page design draft based on the interaction logic, and to generate a page prototype file based on the interaction script and the target page design draft, wherein the page prototype file is used to generate an interactive preview page corresponding to the target page design draft.

[0159] Optionally, the device further includes an update module configured to identify structural problem objects in the original page design draft; update the original page design draft based on the structural problem objects to obtain the target page design draft.

[0160] Optionally, the update module is further configured to perform structure detection on the original page design draft according to the preset structured rules, and determine the structural problem objects in the original page design draft that do not conform to the preset structured rules; the structural problem objects include at least one of layer-level objects, block-level objects and page-level objects.

[0161] Optionally, the update module is further configured to determine the object type of the structural problem object, wherein the object type includes at least one of layer-level object type, block-level object type, and page-level object type; and update the structural problem object according to the object type to obtain the target page design draft.

[0162] Optionally, the update module is further configured to: when the object type includes the layer-level object type, obtain the current identification information of the layer-level objects in the structural problem object, determine the target identification information corresponding to the current identification information according to the identification mapping rule, and update the current identification information to the target identification information; when the object type includes the block-level object type, aggregate the block-level objects in the structural problem object to generate a component object including at least one display state; when the object type includes the page-level object type, determine the page information of the page-level objects in the structural problem object, generate a page object to be supplemented based on the page information, and add the page object to be supplemented to the original page design draft.

[0163] Optionally, the recognition module 402 is further configured to recognize the target page design draft according to the interaction recognition dimension and determine the interactive elements in the target page design draft, wherein the interaction recognition dimension includes at least one of semantic recognition dimension, content recognition dimension and form recognition dimension.

[0164] Optionally, the identification module 402 is further configured to extract element features of the interactive element, and use the element features to perform semantic matching with project elements in the project process knowledge base to determine the target project element; and determine the interaction logic corresponding to the interactive element based on the target interaction behavior mapped by the target project element.

[0165] Optionally, the identification module 402 is further configured to, when the target item element is a multi-state item element, determine the interactive behavior corresponding to the target item element in multiple display states respectively; and determine the interactive logic corresponding to the interactive element based on the interactive behavior corresponding to the multiple display states respectively.

[0166] Optionally, the generation module 404 is further configured to generate an element trigger instruction set based on the interactive element and the interaction logic, wherein the element trigger instruction set is used to describe the response behavior when the interactive element is triggered; and to encapsulate the element trigger instruction set to obtain the interaction script corresponding to the target page design draft.

[0167] Optionally, the generation module 404 is further configured to generate a visual page file based on the target page design draft; and associate the interaction script with the visual page file to obtain a page prototype file.

[0168] Optionally, the device further includes an adjustment module configured to acquire user behavior adjustment information for interactive elements in the page prototype file; and update the mapping relationship in the project process knowledge base based on the behavior adjustment information.

[0169] Optionally, the device further includes a storage module configured to store the page prototype file in a prototype pattern library, wherein the prototype files in the prototype pattern library are used for reuse when page processing is performed on the page design draft to be processed.

[0170] The above is an illustrative scheme of a page processing apparatus according to this embodiment. It should be noted that the technical solution of this page processing apparatus and the technical solution of the page processing method described above belong to the same concept. For details not described in detail in the technical solution of the page processing apparatus, please refer to the description of the technical solution of the page processing method described above.

[0171] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0172] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0173] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0174] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0175] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the page processing method described above.

[0176] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the page processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the page processing method described above.

[0177] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the page processing method described above.

[0178] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the page processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the page processing method described above.

[0179] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the page processing method described above.

[0180] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the page processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the page processing method described above.

[0181] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0182] The computer program / instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0183] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0184] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0185] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A page processing method, comprising: Identify interactive elements in the target page design draft, and obtain the interaction logic corresponding to the interactive elements according to the project process knowledge base, wherein the project process knowledge base stores the mapping relationship between project elements and interactive behaviors; Based on the interaction logic, an interaction script corresponding to the target page design draft is generated, and a page prototype file is generated based on the interaction script and the target page design draft. The page prototype file is used to generate an interactive preview page corresponding to the target page design draft.

2. The method according to claim 1, wherein before identifying interactive elements in the target page design draft, the method further comprises: Identify structural issues in the original page design draft; The original page design draft is updated based on the structural problem object to obtain the target page design draft.

3. The method according to claim 2, wherein determining the structural problem objects in the original page design draft includes: The original page design draft is subjected to structure detection according to preset structure rules to identify structural problem objects in the original page design draft that do not conform to the preset structure rules; The structural problem objects include at least one of layer-level objects, block-level objects, and page-level objects.

4. The method according to claim 2, wherein updating the original page design draft based on the structural problem object to obtain the target page design draft includes: Determine the object type of the structural problem object, wherein the object type includes at least one of layer-level object type, block-level object type, and page-level object type; The structural problem object is updated according to the object type to obtain the target page design draft.

5. The method according to claim 4, wherein updating the structural problem object according to the object type includes: When the object type includes the layer-level object type, obtain the current identification information of the layer-level object in the structural problem object, determine the target identification information corresponding to the current identification information according to the identification mapping rule, and update the current identification information to the target identification information; When the object type includes the block-level object type, the block-level objects in the structural problem object are aggregated to generate a component object that includes at least one display state; If the object type includes the page-level object type, determine the page information of the page-level objects in the structural problem object, generate a page object to be supplemented based on the page information, and add the page object to be supplemented to the original page design draft.

6. The method according to claim 1, wherein identifying interactive elements in the target page design draft includes: The target page design draft is identified based on the interaction recognition dimension to determine the interactive elements in the target page design draft. The interaction recognition dimension includes at least one of the semantic recognition dimension, content recognition dimension, and form recognition dimension.

7. The method according to claim 6, wherein obtaining the interaction logic corresponding to the interactive element based on the project process knowledge base includes: Extract the element features of the interactive element, and use the element features to perform semantic matching with the project elements in the project process knowledge base to determine the target project element; The interaction logic corresponding to the interactive element is determined based on the target interaction behavior mapped from the target project element.

8. The method according to claim 7, wherein determining the interaction logic corresponding to the interactive element based on the target interaction behavior mapped from the target project element includes: When the target item element is a multi-state item element, determine the interactive behaviors of the target item element in each of the multiple display states; The interaction logic corresponding to the interactive element is determined based on the interaction behavior corresponding to the multiple display states.

9. The method according to claim 1, wherein generating the interaction script corresponding to the target page design draft based on the interaction logic comprises: Based on the interactive element and the interaction logic, an element trigger instruction set is generated, wherein the element trigger instruction set is used to describe the response behavior when the interactive element is triggered; The element trigger instruction set is encapsulated to obtain the interaction script corresponding to the target page design draft.

10. The method according to claim 1, wherein generating a page prototype file based on the interaction script and the target page design draft comprises: Generate visual page files based on the target page design draft; The interactive script is associated with the visual page file to obtain the page prototype file.

11. The method according to claim 1, further comprising: Obtain user behavior adjustment information for interactive elements in the page prototype file; The mapping relationships in the project process knowledge base are updated based on the behavior adjustment information.

12. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 11.

13. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

14. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

Images