Design document code generation method and computer program product

Abstract

The application relates to a design draft code generation method and a computer program product. The method comprises the following steps: in response to a code generation request for a target design draft, obtaining a design draft link of the target design draft, obtaining an original node tree file and screenshot data from the design draft link; identifying a picture node from a first node contained in the original node tree file, and replacing node content of the picture node contained in the original node tree file with a picture link corresponding to the picture node to obtain a first cleaned node tree file; obtaining an occluded node from a second node contained in the first cleaned node tree file, and deleting node content of the occluded node from the first cleaned node tree file to obtain a second cleaned node tree file; and constructing a model context protocol by using the second cleaned node tree file and the screenshot data to generate design draft code of the target design draft. The method can effectively improve the simplicity of the generated code.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for generating design draft code and a computer program product. Background Technology

[0002] With the development of computer technology, a technique has emerged to convert Figma designs into code. This technique can extract the attributes of nodes in the design, such as the basic attributes of the nodes, such as fill color, border, size, and text. Then, the node attributes can be converted into code snippets using a preset template to generate the design code.

[0003] However, existing design draft code generation methods suffer from serious code redundancy and insufficient ability to process complex graphics. The generated code may contain a large number of redundant nodes, and using code for all complex graphics would also lead to high code complexity. Therefore, existing design draft code generation methods do not produce concise code. Summary of the Invention

[0004] Therefore, it is necessary to provide a design draft code generation method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the simplicity of generated code in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for generating code from design drafts, including:

[0006] In response to a code generation request for a target design draft, obtain the design draft link of the target design draft, and obtain the original node tree file and screenshot data of the target design draft from the design draft link;

[0007] Image nodes are identified from the first nodes contained in the original node tree file, and the node content of the image nodes contained in the original node tree file is replaced with the image links corresponding to the image nodes to obtain the first cleaned node tree file.

[0008] Obscured nodes are obtained from the second nodes contained in the first cleaned node tree file, and the node content of the obscured nodes is deleted from the first cleaned node tree file to obtain the second cleaned node tree file.

[0009] The second cleaned node tree file and the screenshot data are used to construct a model context protocol, and the design draft code of the target design draft is generated according to the model context protocol.

[0010] In one embodiment, identifying image nodes from the first nodes contained in the original node tree file includes: obtaining each graphic node to be converted into an image from the first node, and obtaining a first graphic node and a second graphic node corresponding to the first graphic node from each graphic node; wherein the first graphic node is any lowest-level graphic node, and the second graphic node is a sibling node of the first graphic node; obtaining the distance between the first graphic node and the second graphic node, and if the distance is less than or equal to a preset distance threshold, setting the common parent node of the first graphic node and the second graphic node as a new graphic node, and deleting the first graphic node and the second graphic node; returning to the process of obtaining the first graphic node and the second graphic node corresponding to the first graphic node from each graphic node until the first graphic node is the highest-level graphic node; and using each graphic node as the image node.

[0011] In one embodiment, constructing each image node based on the graphic nodes contained in each set of graphic nodes includes: constructing initial image nodes corresponding to each set of graphic nodes based on the graphic nodes contained in each set of graphic nodes; obtaining a parent container corresponding to each initial image node; constructing a first image node corresponding to the parent container based on each node contained in the parent container if the parent container satisfies a preset condition; using the initial image node as a second image node if the parent container does not satisfy the preset condition; and using each first image node and each second image node as the image node.

[0012] In one embodiment, obtaining the graphic nodes to be converted into images from the first node includes: obtaining the node type of each first node contained in the original node tree file; if the node type is a Boolean operation node type, treating the first node as a graphic node; if the node type is a vector node type, obtaining the shape corresponding to the first node; if the shape represents the first node as a shape other than a rounded rectangle and a regular rectangle, treating the first node as a graphic node.

[0013] In one embodiment, obtaining the occluded node from the second nodes contained in the first cleaned node tree file includes: obtaining the design draft area of ​​the target design draft from the first cleaned node tree file, dividing the design draft area into multiple pixels, and a list of pixels covered by each second node; obtaining the occlusion priority of any two second nodes, and obtaining the occluded node according to the occlusion priority and the list of pixels covered by each second node.

[0014] In one embodiment, obtaining the occluded node based on the occlusion priority and the pixel list covered by each of the second nodes includes: obtaining the pixel list covered by the current second node, and other second nodes besides the current second node; the current second node is any one of the second nodes; for any of the other second nodes, if the other second node is an ancestor node of the current second node and the ancestor node has content clipping enabled, the intersection of the pixel list covered by the current second node and the pixel list covered by the other second nodes is used as the updated pixel list covered by the current second node; if the occlusion priority of the other second node is higher than that of the current second node, and the other second node is a solid color fill node, the pixels contained in the pixel list covered by the current second node are subtracted from the pixels contained in the pixel list covered by the current second node to obtain the updated pixel list covered by the current second node; if the updated pixel list covered by the current second node is an empty set, the current second node is set as an occluded node.

[0015] In one embodiment, obtaining the occlusion priority of any two second nodes includes: when the current second node is an ancestor node of another second node, the occlusion priority of the current second node is higher than that of the other second node; the current second node is one of any two second nodes, and the other second node is the other of any two second nodes excluding the current second node; when the current second node is a sibling node of the other second node, and the rendering order of the current second node is after that of the other second node, the occlusion priority of the current second node is higher than that of the other second node; when the current second node is not a sibling node of the other second node, the common ancestor node of the current second node and the other second node is obtained, and the occlusion priority of the current second node and the other second node is obtained using the common ancestor node.

[0016] In one embodiment, the list of pixels covered by each of the second nodes is obtained through the following steps: for any pixel, the center coordinates of the pixel and the regional position of the pixel in the design draft area are obtained; the second node associated with the pixel is obtained through a process of matching the regional positions; wherein the center coordinates of the pixel are located within the coverage area of ​​the second node associated with the pixel; and the pixel is added to the list of pixels covered by the second node associated with the pixel.

[0017] In one embodiment, the step of constructing a model context protocol using the second cleaned node tree file and the screenshot data includes: converting the second cleaned node tree file into a generic DSL file; and constructing the model context protocol using the generic DSL file and the screenshot data.

[0018] In one embodiment, constructing the model context protocol using the generic DSL file and the screenshot data includes: converting the generic DSL file into a data format that matches the target platform when the code generation request carries platform information of the target platform for applying the design draft code; and constructing the model context protocol using the DSL file after data format conversion and the screenshot data.

[0019] Secondly, this application also provides a design draft code generation device, comprising:

[0020] The design draft acquisition module is used to respond to a code generation request for a target design draft, obtain the design draft link of the target design draft, and obtain the original node tree file and screenshot data of the target design draft from the design draft link;

[0021] The first cleaning module is used to identify image nodes from the first nodes contained in the original node tree file, and replace the node content of the image nodes contained in the original node tree file with the image links corresponding to the image nodes to obtain the first cleaned node tree file.

[0022] The second cleaning module is used to obtain the occluded node from the second node contained in the first cleaning node tree file, and delete the node content of the occluded node from the first cleaning node tree file to obtain the second cleaning node tree file.

[0023] The code generation module is used to construct a model context protocol using the second cleaned node tree file and the screenshot data, and generate the design draft code of the target design draft according to the model context protocol.

[0024] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any embodiment of the first aspect.

[0025] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any embodiment of the first aspect.

[0026] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any embodiment of the first aspect.

[0027] The aforementioned design draft code generation method, apparatus, computer device, computer-readable storage medium, and computer program product, in response to a code generation request for a target design draft, obtain a design draft link for the target design draft, and retrieve the original node tree file and screenshot data of the target design draft from the design draft link; identify image nodes from the first nodes contained in the original node tree file, and replace the node content of the image nodes contained in the original node tree file with the image links corresponding to the image nodes to obtain a first cleaned node tree file; obtain occluded nodes from the second nodes contained in the first cleaned node tree file, and delete the node content of the occluded nodes from the first cleaned node tree file to obtain a second cleaned node tree file; construct a model context protocol using the second cleaned node tree file and the screenshot data, and generate the design draft code for the target design draft according to the model context protocol. This application, upon receiving a code generation request for a target design draft, can extract the original node tree file and screenshot data based on the link of the design draft. Then, it can identify image nodes from the first node in the original node tree file, replacing the content of the image nodes with their corresponding image links. Next, it can obtain occluded nodes from the node tree file and delete their content. Finally, it uses the cleaned node tree file and screenshot data to construct a model context protocol to generate the design draft code. This method not only effectively reduces the number of redundant nodes but also allows for image-based code generation for complex graphics, thus significantly improving the conciseness of the generated code. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a flowchart illustrating a design draft code generation method in one embodiment;

[0030] Figure 2 This is a schematic diagram of the process for identifying image nodes in one embodiment;

[0031] Figure 3 This is a schematic diagram of the process for obtaining an occluded node in one embodiment;

[0032] Figure 4 This is a schematic diagram of the process for obtaining the occluded node in another embodiment;

[0033] Figure 5 This is a schematic diagram of the overall architecture of the intelligent cleaning and code generation method for design drafts in one embodiment.

[0034] Figure 6 This is a flowchart illustrating a pixel-sampling-based planar scanning algorithm in one embodiment;

[0035] Figure 7 This is a structural block diagram of a design draft code generation device in one embodiment;

[0036] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0038] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0039] In one embodiment, such as Figure 1 As shown, a method for generating code from design drafts is provided. This embodiment illustrates the method using a server as an example; however, it can also be applied to a terminal. In this embodiment, the method includes the following steps:

[0040] Step S101: In response to the code generation request for the target design draft, obtain the design draft link of the target design draft, and obtain the original node tree file and screenshot data of the target design draft from the design draft link.

[0041] The target design draft refers to the design draft that needs to generate code. The code generation request refers to the request initiated by the user to generate code for the target design draft. This request may carry a link to the target design draft, which is the address link where the target design draft is stored. The original node tree file refers to the node content data file stored in the address link of the target design draft. The original node tree file can be a JSON file. The screenshot data is a screenshot of the target design draft, which can be PNG image data.

[0042] Specifically, when a user needs to generate code for a target design draft, they can initiate a code generation request for the target design draft by entering the design draft link. The server can then respond to the request and obtain the original node tree file and screenshot data of the target design draft through the design draft link.

[0043] Step S102: Identify image nodes from the first node contained in the original node tree file, and replace the node content of the image nodes contained in the original node tree file with the image links corresponding to the image nodes to obtain the first cleaned node tree file.

[0044] The first node refers to the node contained in the original node tree file. In this embodiment, the original node tree file can store the node content data corresponding to multiple first nodes. The image node refers to the node that can be displayed in the form of an image. In this embodiment, some nodes do not need to be represented in the form of code, but can be represented in the form of an image. The image node is a node that can be represented by an image. The image link refers to the link corresponding to the image node, which can be obtained based on the node representation of the image node.

[0045] Specifically, after obtaining the original node tree file, the first image node can be identified in the first node contained in the original node tree file to obtain the image node. Then, the node content of the above image node recorded in the original node tree file can be replaced with the link corresponding to the image node, i.e., the image link. The first cleaned node tree file can be obtained in this way.

[0046] Step S103: Obscure nodes are obtained from the second nodes contained in the first cleaned node tree file, and the node content of the obscure nodes is deleted from the first cleaned node tree file to obtain the second cleaned node tree file.

[0047] An occluded node refers to a node that is completely obscured and therefore invisible. A second node refers to a node contained in the first cleaned node tree file. Similarly, the first cleaned node tree file can store the node content data corresponding to multiple second nodes. In this embodiment, after obtaining the first cleaned node tree file, the server can also identify the completely obscured nodes from the second nodes. Then, the node content of the obscured nodes can be deleted from the first cleaned node tree file to obtain the second cleaned node tree file.

[0048] Step S104: Construct a model context protocol using the second cleaned node tree file and screenshot data, and generate the design draft code for the target design draft based on the model context protocol.

[0049] After obtaining the second cleaned node tree file, the Model Context Protocol (MCP) can be constructed by combining the second cleaned node tree file and screenshot data. The MCP can then be used to invoke an AI assistant to generate the design code for the target design draft.

[0050] In the above-described design draft code generation method, in response to a code generation request for the target design draft, the design draft link of the target design draft is obtained, and the original node tree file and screenshot data of the target design draft are obtained from the design draft link. From the first node contained in the original node tree file, image nodes are identified, and the node content of the image nodes contained in the original node tree file is replaced with the image links corresponding to the image nodes to obtain a first cleaned node tree file. From the second node contained in the first cleaned node tree file, the occluded nodes are obtained, and the node content of the occluded nodes is deleted from the first cleaned node tree file to obtain a second cleaned node tree file. The second cleaned node tree file and the screenshot data are used to construct a model context protocol, and the design draft code of the target design draft is generated according to the model context protocol. This application, upon receiving a code generation request for a target design draft, can extract the original node tree file and screenshot data based on the link of the design draft. Then, it can identify image nodes from the first node in the original node tree file, replacing the content of the image nodes with their corresponding image links. Next, it can obtain occluded nodes from the node tree file and delete their content. Finally, it uses the cleaned node tree file and screenshot data to construct a model context protocol to generate the design draft code. This method not only effectively reduces the number of redundant nodes but also allows for image-based code generation for complex graphics, thus significantly improving the conciseness of the generated code.

[0051] In one embodiment, such as Figure 2 As shown, step S102 may further include:

[0052] Step S201: Obtain each graphic node to be converted into an image from the first node, and obtain the first graphic node and the second graphic node corresponding to the first graphic node from each graphic node; wherein, the first graphic node is any lowest level graphic node, and the second graphic node is the sibling node of the first graphic node.

[0053] A graph node refers to all nodes in the first node that need to be converted into images for representation. The first graph node is the lowest level graph node, while the second graph node is the sibling node of the first graph node, meaning that the first graph node and the second graph node have the same parent node.

[0054] In this embodiment, the server can first identify each graphic node that needs to be converted into an image, and then select the lowest-level graphic node as the first graphic node. Then, it can determine whether there is a graphic node among the sibling nodes of the first graphic node. If there is, the sibling node is used as the second graphic node.

[0055] Step S202: Obtain the distance between the first graphic node and the second graphic node. If the distance is less than or equal to a preset distance threshold, set the common parent node of the first graphic node and the second graphic node as a new graphic node, and delete the first graphic node and the second graphic node.

[0056] The preset distance threshold refers to a pre-set distance threshold, which can be set to 15px. If the distance is less than or equal to the preset distance threshold, it means that the first graphic node and the second graphic node are connected to each other, and the first graphic node and the second graphic node can be merged and exported.

[0057] Specifically, the server can first calculate the distance between the first graphic node and the second graphic node. If the distance between the first graphic node and the second graphic node is less than or equal to a preset distance threshold, then the server can set the common parent node of the first graphic node and the second graphic node as the new graphic node, and delete the first graphic node and the second graphic node to complete the merging of graphic nodes.

[0058] For example, if node A has child nodes B and C, and both nodes B and C are graphic nodes, and the distance between nodes B and C is less than or equal to a preset distance threshold, then node A can be set as a new graphic node. When exporting, node A can be exported as a whole without exporting the images of nodes B and C separately.

[0059] Step S203: Return to step S201 and continue until the first graph node is the highest level graph node;

[0060] Step S204: Treat each graphic node as an image node.

[0061] After merging the lowest-level graphic nodes, the server can retrieve the lowest-level graphic nodes again and merge them again until the first graphic node becomes the highest-level graphic node. At this point, each graphic node can be used as an image node.

[0062] In this embodiment, each graphic node that needs to be converted into an image can be identified first. Then, based on the distance between two graphic nodes with the same parent node, it can be determined whether the images of the two graphic nodes need to be merged and exported. The graphic node merging is then performed through bottom-up recursive processing to obtain the final image node. This method can effectively reduce the number of nodes converted into images, further saving storage space and loading time.

[0063] Further, step S201 may further include: obtaining the node type of each first node contained in the original node tree file; if the node type is a Boolean operation node type, treating the first node as a graphic node; if the node type is a vector node type, obtaining the shape corresponding to the first node; if the shape representing the first node is a shape other than a rounded rectangle and a regular rectangle, treating the first node as a graphic node.

[0064] In this embodiment, graphic nodes can be identified based on node type. Specifically, it's first determined whether each first node is a Boolean operation node. If so, the first node is treated as a graphic node. If the identified first node is a vector node, its shape needs further determination. For example, this can be done by parsing the SVG path. If the identified shape is any shape other than a rounded rectangle or a regular rectangle, the first node is treated as a graphic node. If the identified shape is either a rounded rectangle or a regular rectangle, it is not set as a graphic node. Furthermore, nodes other than Boolean operation nodes and vector nodes are also not set as graphic nodes.

[0065] In this embodiment, only Boolean operation nodes and vector nodes with complex shapes, i.e. vector nodes other than rounded rectangles and ordinary rectangles, can be set as graphic nodes, while other types of nodes are not set as graphic nodes. In this way, only complex graphic nodes can be exported as images, thus effectively reducing the complexity of the code.

[0066] In one embodiment, such as Figure 3 As shown, step S103 may further include:

[0067] Step S301: Obtain the design draft area of ​​the target design draft from the first cleaning node tree file, and divide the design draft area into multiple pixels, as well as the list of pixels covered by each second node.

[0068] The design draft area can refer to the visible area of ​​the root node in the first clean node tree file. In this embodiment, the server can first obtain the design draft area of ​​the target design draft and divide the design draft area into multiple pixel grids, such as 20x20 pixels per pixel, thereby dividing it into multiple pixels. Then, based on the location of each second node, the list of pixels covered by each second node can be obtained.

[0069] Step S302: Obtain the occlusion priority of any two second nodes, and obtain the occluded node based on the occlusion priority and the list of pixels covered by each second node.

[0070] Occlusion priority can be used to characterize the occlusion relationship between two second nodes, and to characterize which of two overlapping second nodes will occlude the other. After obtaining the list of pixels covered by each second node, the server can also obtain the occlusion priority of any two second nodes, and thus filter out the occluded nodes based on the occlusion priority and the list of pixels covered by each second node.

[0071] In this embodiment, the design draft area can be divided into multiple pixels to obtain a list of pixels covered by each second node. Then, the list of pixels covered by the second node and the occlusion priority of the second node can be combined to filter out unoccluded nodes. This method can improve the accuracy of filtering occluded nodes.

[0072] Furthermore, such as Figure 4 As shown, step S302 may further include:

[0073] Step S401: Obtain the list of pixels covered by the current second node, and the other second nodes besides the current second node; the current second node is any one of the second nodes.

[0074] Step S402: For any other second node, if the other second node is an ancestor node of the current second node and the ancestor node has content clipping enabled, take the intersection of the pixel list covered by the current second node and the pixel list covered by the other second node as the updated pixel list covered by the current second node.

[0075] The current second node can refer to any one of the second nodes, while other second nodes are all other second nodes besides the current second node. If an other second node is an ancestor node of the current second node and that ancestor node has content clipping enabled, then the server can use the intersection of the pixel list covered by the current second node and the pixel lists covered by other second nodes as the updated pixel list covered by the current second node.

[0076] For example, if node A is the current second node, and node B is an ancestor node of node A, and node A covers pixels 1, 2, and 3, and node B has content clipping enabled and covers pixels 1, 2, and 4, then the updated list of pixels covered by the current second node can include pixels 1 and 2.

[0077] Step S403: If the occlusion priority of other second nodes is higher than that of the current second node, and the other second nodes are solid color filled nodes, subtract the pixels contained in the pixel list covered by the other second nodes from the pixels contained in the pixel list covered by the current second node to obtain the updated pixel list covered by the current second node.

[0078] If the occlusion priority of other second nodes is higher than that of the current second node, and the other second nodes are solid color filled nodes, then the other second nodes will also cause occlusion of the current second node. Therefore, the updated pixel list covered by the current second node can be obtained by subtracting the pixels covered by the pixel list of other second nodes from the pixels covered by the current second node.

[0079] For example, the pixel list covered by the second node A obtained in step S402 includes pixel 1 and pixel 2. The occlusion priority of other second nodes C is higher than that of second node A, and they are filled with solid colors. If the pixel list covered by second node C is node A, then the updated pixel list covered by the current second node is node B. However, if the pixel list covered by second node C is node A, node B, and node E, then after deducting the pixels contained in the pixel list covered by second node C, the updated pixel list covered by the current second node is an empty set.

[0080] Step S404: If the updated list of pixels covered by the current second node is empty, set the current second node as the occluded node.

[0081] Repeat steps S402 and S403 until all other second nodes have been traversed. If the updated list of pixels covered by the current second node is empty, it indicates that the current second node has been completely occluded. Therefore, the current second node can be set as an occluded node.

[0082] In this embodiment, the pixel list covered by the current second node can be updated based on the occlusion priority of other second nodes and whether other second nodes are ancestor nodes. If the pixel list covered by the current second node is an empty set, it is regarded as an occluded node. This method can further improve the accuracy of occluded node identification.

[0083] Additionally, step S302 may further include: when the current second node is an ancestor node of another second node, the occlusion priority of the current second node is higher than that of the other second node; when the current second node is one of any two second nodes, and the other second node is the other of any two second nodes excluding the current second node; when the current second node is a sibling node of another second node, and the rendering order of the current second node is after that of the other second node, the occlusion priority of the current second node is higher than that of the other second node; when the node levels of the current second node and the other second node are different, the common ancestor node of the current second node and the other second node is obtained, and the occlusion priority of the current second node and the other second node is obtained using the common ancestor node.

[0084] The current second node and another second node are two second nodes used to determine occlusion priority. In this embodiment, the occlusion priority of the two second nodes can be obtained in the following way:

[0085] If a current second node is an ancestor node of another second node, then the occlusion priority of the current second node can be set to be higher than that of the other second node.

[0086] If a current second node is a sibling node of another second node, and the rendering order of the current second node is after that of the other second node, then the occlusion priority of the current second node can be set to be higher than that of the other second node.

[0087] If a current second node is neither an ancestor / descendant nor a sibling node to another second node, the server can obtain the common ancestor node of the two second nodes. This indicates that the two second nodes are nodes of different branches. Then, the server can obtain the common ancestor node of the current second node and the other second node, and use the common ancestor node to obtain the occlusion priority of the current second node and the other second node. For example, the common ancestor node can be combined with the previous two methods to determine the occlusion priority of the two branches, thereby obtaining the occlusion priority of the current second node and the other second node.

[0088] In this embodiment, the occlusion priority of ancestor nodes can be set to be higher than that of descendant nodes, while for sibling nodes, the occlusion priority of nodes rendered later can be set to be higher than that of nodes rendered earlier. This method can improve the accuracy of occlusion priority settings.

[0089] In one embodiment, the list of pixels covered by each second node is obtained through the following steps: for any pixel, obtain the center coordinates of the pixel and the regional position of the pixel in the design area; obtain the second node associated with the pixel through a process of matching regional positions; wherein the center coordinates of the pixel are within the coverage area of ​​the second node associated with the pixel; add the pixel to the list of pixels covered by the second node associated with the pixel.

[0090] To improve the computational efficiency of the pixel list covered by the second node, this embodiment can use multiple processes to calculate pixel attribution in parallel. For example, the design draft area can be divided into four sub-regions, and each sub-region can have its pixel attribution calculated by a different process. Therefore, the process used for pixel attribution calculation can be determined based on the pixel's location within the design draft. For example, if the pixel is located in sub-region 1, then the process for sub-region 1 will be used to calculate the pixel attribution. Specifically, the server can first obtain the center coordinates of the pixel and its location within the region. Then, based on the process matching the region location, it can combine the pixel's center coordinates to identify the second node covering the pixel, i.e., the pixel-associated second node. This can be a second node whose center coordinates are within the coverage area of ​​the second node, which is then identified as the pixel-associated second node, and the pixel is added to the pixel list covered by the pixel-associated second node.

[0091] In this embodiment, the affiliation of each pixel can be identified based on the center position of the pixel and the coverage area of ​​the second node, thereby forming a list of pixels covered by each second node. This process can also be completed by different processes in the region where the pixel is located, which can improve the efficiency of obtaining the list of pixels covered by the second node.

[0092] In one embodiment, step S104 may further include: converting the second cleaned node tree file into a generic DSL file; and constructing a model context protocol using the generic DSL file and screenshot data.

[0093] A generic DSL file can refer to a generic domain-specific language file. After obtaining the second cleaned node tree file, it can be converted into a generic DSL file to complete multi-platform adaptation. Then, the generic DSL file and screenshot data can be used to construct a model context protocol. For example, the generic DSL file, screenshot data, and prompt words can be combined to construct a model context protocol.

[0094] In this embodiment, the second cleaned node tree file can be converted into a general DSL file to achieve multi-platform adaptation. Then, the general DSL file and screenshot data can be used to construct a model context protocol. In this way, the multi-platform adaptation of the design draft code can be achieved, improving the versatility of the design draft code.

[0095] Furthermore, constructing a model context protocol using a generic DSL file and screenshot data can further include: converting the generic DSL file into a data format that matches the target platform when the code generation request carries platform information of the target platform for the application design draft code; and constructing a model context protocol using the converted DSL file and screenshot data.

[0096] The target platform refers to the platform that requires the application of the design draft code. In this embodiment, the user can also initiate a code generation request for the target platform, thereby carrying the platform information of the target platform in the code generation request. After that, after converting the second cleaned node tree file into a general DSL file, the general DSL file can also be converted into a data format that matches the target platform. In this way, the model context protocol can be constructed using the DSL file after data format conversion and the screenshot data. A more accurate model context protocol can be obtained in this way.

[0097] In this embodiment, if the user specifies a target platform that requires the application of the design draft code, the DSL file can be converted into a data format that matches the target platform to construct the model context protocol. This method can improve the accuracy of the model context protocol construction.

[0098] In one embodiment, a Figma design draft intelligent cleaning and code generation method based on the MCP protocol is also provided, which can solve the problems of high node redundancy, difficulty in handling complex graphics, and difficulty in multi-platform adaptation of traditional D2C tools. The core includes: employing a multi-stage node cleaning strategy; using a planar scanline algorithm to achieve global occlusion detection and automatically deleting completely occluded redundant nodes; using a latent image node intelligent recognition algorithm based on connectivity analysis and shape classification to automatically convert complex vector graphics into image resources; constructing a general DSL as an intermediate layer to support one-time cleaning and multi-platform mapping (iOS / H5 / Mini Program, etc.); and seamlessly integrating with AI models through the MCP protocol to achieve end-to-end automated conversion from design drafts to high-quality code.

[0099] This method is applicable to the following typical scenarios:

[0100] Mobile application development: After designers complete the UI design in Figma, developers can directly generate iOS / Android code from Figma using AI assistants (such as Cursor and CodeBuddy);

[0101] Web front-end development: Product managers share Figma prototype links, and front-end engineers can generate HTML5 responsive pages with one click;

[0102] Cross-platform development: Generate code for multiple platforms such as WeChat Mini Program, React Native, and Flutter from the same Figma design.

[0103] The specific functions are shown in Table 1 below:

[0104] Table 1. Functional Diagram of Intelligent Cleaning and Code Generation Methods for Design Drafts

[0105]

[0106] Operation method

[0107] Use it in Codebuddy or Cursor, for example:

[0108] User: "Please convert this Figma link to iOS code: link XXX"

[0109] AI: [Automatically calls the get_code_from_figma tool], returns cleaned JSON + screenshot + prompt information, [AI generates complete iOS ViewController code based on the returned information], "Code generated, containing 3 components: LoginButton, UserAvatar, TabBar"

[0110] This embodiment can adopt a modular layered architecture design, including a user layer, MCP service layer, Figma interface layer, node cleaning layer, DSL conversion layer, and output layer. The overall architecture flow is as follows: Figure 5 As shown. This method may include the following core algorithms:

[0111] I. Global Occlusion Detection:

[0112] Problem Definition: On a two-dimensional plane, given n rectangular nodes and their Z-axis levels, determine which nodes are completely occluded.

[0113] Algorithm Design: A pixel-sampling-based planar scanning algorithm is adopted, which can achieve the following: Figure 6 As shown, it includes the following steps:

[0114] Step 1: Pixel grid division.

[0115] Objective: To divide the design draft area into small grids for accurate detection of node occlusion relationships.

[0116] # Divide the visible area of ​​the root node into a pixel grid (20x20 pixels per pixel).

[0117] xmin, ymin = floor(root.x), floor(root.y)

[0118] xmax, ymax = floor(root.x + root.width), floor(root.y + root.height)

[0119] pixel_size = (20, 20)

[0120] total_pixels = ((xmax - xmin) / 20) * ((ymax - ymin) / 20)

[0121] Step 2: Multi-process parallel pixel assignment calculation.

[0122] Objective: To divide the canvas area into blocks for parallel processing and quickly calculate which grids each node covers.

[0123] Core idea:

[0124] The canvas is divided into 4 areas, and 4 processes are used to process them in parallel;

[0125] Each process independently calculates the pixel attribution relationships within its assigned area;

[0126] The final merged result yields the complete set of pixels covered by each node.

[0127] Performance improvement: Using multi-processing can increase processing speed by 4 times, suitable for large design drafts (number of nodes > 500).

[0128] # Divide the region into 4 parts and process them in parallel using 4 processes.

[0129] regions = [

[0130] (ymin, ymin + h / 4),

[0131] (ymin + h / 4, ymin + h / 2),

[0132] (ymin + h / 2, ymin + 3h / 4),

[0133] (ymin + 3h / 4, ymax) ]

[0135] def process_region_worker(region):

[0136] result = {} # {node_id: set of pixel_ids}

[0137] for pixel in region:

[0138] pixel_center = (pixel.x + 10, pixel.y + 10)

[0139] for node in all_nodes:

[0140] if is_point_in_node(pixel_center, node):

[0141] result[node.id].add(pixel.id)

[0142] return result

[0143] Step 3: Node priority determination.

[0144] Objective: To determine which of two overlapping nodes will occlude the other (similar to layer order in Photoshop).

[0145] Priority rules:

[0146] Ancestor node > Descendant node (parent container has higher priority than child element);

[0147] Among sibling nodes, those rendered later (with higher order) have higher priority;

[0148] For nodes at different levels, find their common ancestor layer by layer and then compare them.

[0149] This method simulates Figma's Z-axis rendering order, ensuring that occlusion detection matches the actual visual effect.

[0150] def is_higher_priority(nodeA, nodeB):

[0151] Ancestor nodes have higher priority than descendant nodes.

[0152] if is_ancestor(nodeA, nodeB):

[0153] return True

[0154] # Comparison of sibling nodes: Rendered later (larger order) has higher priority.

[0155] if nodeA.parent == nodeB.parent:

[0156] return nodeA.order > nodeB.order

[0157] # Otherwise, compare upwards layer by layer.

[0158] while nodeA.floor != nodeB.floor:

[0159] nodeA = nodeA.parent

[0160] nodeB = nodeB.parent

[0161] return is_higher_priority(nodeA, nodeB)

[0162] Step 4: Remove occluded pixels.

[0163] Objective: Calculate the actual visible pixels of each node and delete nodes that are completely occluded.

[0164] for nodeA in all_nodes:

[0165] visible_pixels = nodeA.pixels.copy()

[0166] for nodeB in all_nodes:

[0167] if nodeA == nodeB:

[0168] continue

[0169] # The clipsContent of an ancestor node will prune descendant nodes.

[0170] if is_ancestor(nodeB, nodeA) and nodeB.clipsContent:

[0171] visible_pixels &= nodeB.pixels

[0172] # Nodes with higher priority and solid color fills will obscure the current node.

[0173] elif is_higher_priority(nodeB, nodeA) and has_pure_fill(nodeB):

[0174] visible_pixels -= nodeB.pixels

[0175] # Delete the node if no pixels are visible.

[0176] if len(visible_pixels) == 0:

[0177] mark_for_deletion(nodeA)

[0178] Time complexity analysis:

[0179] Number of pixels: O(W×H / 400);

[0180] Traversing all nodes per pixel: O(n);

[0181] Overall: O((W×H / 400)×n), but the actual time consumption is reduced by multi-process parallelism;

[0182] Compared to the naive O(n²) node comparison algorithm, it speeds up the process by more than 10 times in large-scale design drafts.

[0183] II. Potential Image Node Identification:

[0184] Problem definition: Determine which vector nodes should be exported as images instead of using code.

[0185] Algorithm design: Bottom-up recursive strategy + connectivity analysis.

[0186] Step 1: Single node judgment.

[0187] Objective: To determine whether a single node is difficult to implement using code and needs to be exported as an image.

[0188] Judgment criteria:

[0189] Boolean operation nodes (merge, subtract, intersection, etc.) can be exported as images.

[0190] Vector nodes, further categorized:

[0191] Rectangles / rounded rectangles, implemented using code (CSS border-radius / iOS cornerRadius).

[0192] Export complex shapes (stars, polygons, Bézier curves) as images.

[0193] Note: This condition is the dividing line between code and images, directly affecting the maintainability of the final code.

[0194] def is_hard_to_code(node):

[0195] # 1. Boolean operation nodes are directly marked

[0196] if node.type == "BOOLEAN_OPERATION":

[0197] return True

[0198] # 2. Vector nodes require further evaluation.

[0199] if node.type == "VECTOR":

[0200] path = node.fillGeometry[0].path

[0201] shape_type = classify_shape(path)

[0202] # Rounded rectangles and regular rectangles can be implemented using code.

[0203] if shape_type in ["rectangle", "rounded_rectangle"]:

[0204] return False

[0205] # Export other complex shapes as images

[0206] return True

[0207] return False

[0208] Step 2: Shape classification (classify_shape).

[0209] Objective: To identify whether a vector graphic is a simple or complex shape by parsing the SVG path.

[0210] Using SVG path parsing technology:

[0211] def classify_shape(svg_path):

[0212] path = parse_path(svg_path)

[0213] segments = list(path)

[0214] # Must be a closed continuous path

[0215] if not (path.isclosed() and path.iscontinuous()):

[0216] return "unknown"

[0217] lines = [s for s in segments if isinstance(s, Line)]

[0218] curves = [s for s in segments if isinstance(s, (CubicBezier,QuadraticBezier))]

[0219] # Determine if line segments form an axis-aligned rectangle

[0220] is_rect_like = (

[0221] has_horizontal_and_vertical_lines(lines) and

[0222] no_diagonal_lines(lines) and

[0223] has_2_to_4_unique_x_coords(lines) and

[0224] has_2_to_4_unique_y_coords(lines) )

[0226] # Rectangle without rounded corners

[0227] if is_rect_like and len(curves) == 0:

[0228] return "rectangle"

[0229] # Rectangle with rounded corners (1-4 rounded corners)

[0230] if is_rect_like and 1 <= len(curves) <= 4:

[0231] if any(curve_connected_with_line(c) for c in curves):

[0232] return "rounded_rectangle"

[0233] return "unknown" # Complex shapes

[0234] Step 3: Connectivity determination.

[0235] Objective: To determine whether multiple scattered nodes should be merged and exported as a single image.

[0236] Algorithm: Use Union-Find to determine whether the nodes form a connected graph.

[0237] Core idea:

[0238] Iterate through all pairs of nodes and calculate the shortest distance between them;

[0239] Nodes that are less than 15px apart are merged into the same set;

[0240] Finally, check if there is only one connected component (all nodes share the same root node).

[0241] Application scenario: For example, multiple small graphics in an icon that are close to each other (<15px) will be recognized as a single export.

[0242] def is_nodes_connected(nodes, threshold=15):

[0243] # Initialize disjoint-set data structure

[0244] parent = {i: i for i in range(len(nodes))}

[0245] def find(x):

[0246] if parent[x] != x:

[0247] parent[x] = find(parent[x])

[0248] return parent[x]

[0249] def union(x, y):

[0250] parent[find(x)] = find(y)

[0251] # Merge nodes whose distance is less than the threshold.

[0252] for i in range(len(nodes)):

[0253] for j in range(i+1, len(nodes)):

[0254] if node_distance(nodes[i], nodes[j]) <= threshold:

[0255] union(i, j)

[0256] # Check if there is only one connected component

[0257] return len(set(find(i) for i in range(len(nodes)))) == 1

[0258] Step 4: Determine the combination of nodes.

[0259] Objective: To recursively process from bottom to top and merge multiple complex child nodes into a single image.

[0260] def identify_potential_image_node(node):

[0261] # Recursively process child nodes

[0262] for child in node.children:

[0263] identify_potential_image_node(child)

[0264] # Special nodes (difficult to implement + vector nodes)

[0265] special_children = [c for c in node.children

[0266] if is_hard_to_code(c) or c.type == "VECTOR"]

[0267] # Icon Node Optimization

[0268] if "icon" in node.name.lower():

[0269] if any(is_hard_to_code(c) for c in node.children):

[0270] mark_as_image_node(node)

[0271] return

[0272] # Determine whether to merge based on threshold

[0273] ratio = len(special_children) / len(node.children)

[0274] if ratio >= threshold and is_nodes_connected(special_children):

[0275] mark_as_image_node(node)

[0276] export_as_png(node, scale=2.0)

[0277] III. General DSL Conversion:

[0278] Objective: To define a platform-independent intermediate representation to achieve "one-time cleaning, multi-platform generation".

[0279] # General DSL Example

[0280] {

[0281] "type": "view", # view / label / image

[0282] "frame": [x, y, width, height],

[0283] "backgroundColor": {"r": 255, "g": 255, "b": 255, "a": 1.0},

[0284] "layer": {

[0285] "cornerRadius": 8,

[0286] "borderWidth": 1,

[0287] "borderColor": {"r": 0, "g": 0, "b": 0, "a": 0.1}

[0288] },

[0289] "linearGradient": {

[0290] "colors": [{"r": 255, "g": 0, "b": 0, "a": 1}, ...],

[0291] "startPoint": {"x": 0, "y": 0},

[0292] "endPoint": {"x": 1, "y": 1}

[0293] },

[0294] "subviews": [...]

[0295] }

[0296] Platform mapping strategy:

[0297] Objective: To convert general-purpose DSLs into platform-specific data formats, making large models easier to understand platform characteristics.

[0298] # iOS Mapping

[0299] def to_ios_properties(dsl_node):

[0300] ios_node = {}

[0301] ios_node["type"] = {

[0302] "view": "UIView",

[0303] "label": "UILabel",

[0304] image: UIImageView

[0305] }[dsl_node["type"]]

[0306] # Color Mapping

[0307] color = dsl_node["backgroundColor"]

[0308] ios_node["backgroundColor"] = f"[UIColor colorWithRed:{color.r} " \

[0309] f"green:{color.g} blue:{color.b} " \

[0310] f"alpha:{color.a}]"

[0311] # Gradient mapping to CAGradientLayer

[0312] if "linearGradient" in dsl_node:

[0313] ios_node["CAGradientLayer"] = convert_gradient(dsl_node["linearGradient"])

[0314] return ios_node

[0315] Through the above embodiments, nodes can be cleaned, effectively solving the problem of code redundancy. They can also automatically identify potential image nodes, solving complex image processing problems. Furthermore, by constructing a general DSL middleware layer, the problem of multi-platform adaptation can be solved. Finally, the MCP protocol can be integrated to solve the problem of low integration in AI collaboration.

[0316] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0317] Based on the same inventive concept, this application also provides a design draft code generation apparatus for implementing the design draft code generation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more design draft code generation apparatus embodiments provided below can be found in the limitations of the design draft code generation method described above, and will not be repeated here.

[0318] In one embodiment, such as Figure 7 As shown, a design draft code generation device is provided, including: a design draft acquisition module 701, a first cleaning module 702, a second cleaning module 703, and a code generation module 704, wherein:

[0319] The design draft acquisition module 701 is used to respond to the code generation request for the target design draft, obtain the design draft link of the target design draft, and obtain the original node tree file and screenshot data of the target design draft from the design draft link;

[0320] The first cleaning module 702 is used to identify image nodes from the first nodes contained in the original node tree file, and replace the node content of the image nodes contained in the original node tree file with the image links corresponding to the image nodes to obtain the first cleaned node tree file.

[0321] The second cleaning module 703 is used to obtain the obscured node from the second node contained in the first cleaning node tree file, and delete the node content of the obscured node from the first cleaning node tree file to obtain the second cleaning node tree file.

[0322] The code generation module 704 is used to construct a model context protocol using the second cleaned node tree file and screenshot data, and generate the design draft code of the target design draft based on the model context protocol.

[0323] Each module in the aforementioned design draft code generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0324] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores design code data. The I / O interfaces allow the processor to exchange information with external devices. The communication interface allows communication with external terminals via a network connection. When executed by the processor, the computer program implements a design code generation method.

[0325] Those skilled in the art will understand that Figure 8The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0326] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0327] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0328] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0329] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0330] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0331] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0332] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating code from design drafts, characterized in that, The method includes: In response to a code generation request for a target design draft, obtain the design draft link of the target design draft, and obtain the original node tree file and screenshot data of the target design draft from the design draft link; Image nodes are identified from the first nodes contained in the original node tree file, and the node content of the image nodes contained in the original node tree file is replaced with the image links corresponding to the image nodes to obtain the first cleaned node tree file. Obscured nodes are obtained from the second nodes contained in the first cleaned node tree file, and the node content of the obscured nodes is deleted from the first cleaned node tree file to obtain the second cleaned node tree file. The second cleaned node tree file and the screenshot data are used to construct a model context protocol, and the design draft code of the target design draft is generated according to the model context protocol.

2. The method according to claim 1, characterized in that, The step of identifying image nodes from the first nodes contained in the original node tree file includes: Obtain each graphic node to be converted into an image from the first node, and obtain the first graphic node and the second graphic node corresponding to the first graphic node from each graphic node; wherein, the first graphic node is any lowest level graphic node, and the second graphic node is the sibling node of the first graphic node. Obtain the distance between the first graphic node and the second graphic node. If the distance is less than or equal to a preset distance threshold, set the common parent node of the first graphic node and the second graphic node as a new graphic node, and delete the first graphic node and the second graphic node. Return to the process of obtaining the first graphic node and the second graphic node corresponding to the first graphic node from each of the graphic nodes, until the first graphic node is the highest level graphic node; Each of the aforementioned graphic nodes is used as the image node.

3. The method according to claim 2, characterized in that, The step of obtaining the graphic nodes to be converted into an image from the first node includes: Obtain the node type of each first node contained in the original node tree file; When the node type is a Boolean operation node type, the first node is treated as a graphical node; If the node type is a vector node, obtain the shape corresponding to the first node; if the shape represents the first node as a shape other than a rounded rectangle and a regular rectangle, treat the first node as a graphic node.

4. The method according to claim 1, characterized in that, The step of obtaining the occluded node from the second node contained in the first cleaning node tree file includes: Obtain the design draft area of ​​the target design draft from the first cleaning node tree file, and divide the design draft area into multiple pixels, as well as the list of pixels covered by each of the second nodes; Obtain the occlusion priority of any two second nodes, and obtain the occluded node based on the occlusion priority and the list of pixels covered by each second node.

5. The method according to claim 4, characterized in that, The step of obtaining the occluded node based on the occlusion priority and the list of pixels covered by each of the second nodes includes: Obtain the list of pixels covered by the current second node, and the other second nodes in the second node group besides the current second node; the current second node is any one of the second nodes. For any of the other second nodes, if the other second node is an ancestor node of the current second node and the ancestor node has content clipping enabled, the intersection of the pixel list covered by the current second node and the pixel list covered by the other second nodes is taken as the updated pixel list covered by the current second node. If the occlusion priority of the other second nodes is higher than that of the current second node, and the other second nodes are solid color fill nodes, the pixels contained in the pixel list covered by the current second node are subtracted from the pixels contained in the pixel list covered by the other second nodes to obtain the updated pixel list covered by the current second node. If the updated list of pixels covered by the current second node is empty, then the current second node is set as an occluded node.

6. The method according to claim 4, characterized in that, The step of obtaining the occlusion priority of any two second nodes includes: When the current second node is an ancestor node of another second node, the occlusion priority of the current second node is higher than that of the other second node; the current second node is one of any two second nodes, and the other second node is the other of any two second nodes excluding the current second node; When the current second node is a sibling node of the other second node, and the rendering order of the current second node is after that of the other second node, the occlusion priority of the current second node is higher than that of the other second node. If the current second node is not a sibling node of the other second node, obtain the common ancestor node of the current second node and the other second node, and use the common ancestor node to obtain the occlusion priority of the current second node and the other second node.

7. The method according to claim 4, characterized in that, The list of pixels covered by each of the second nodes is obtained through the following steps: For any given pixel, obtain the center coordinates of the pixel and the regional position of the pixel in the design draft area; The second node associated with the pixel is obtained through a process that matches the location of the region; wherein the center coordinates of the pixel are located within the coverage area of ​​the second node associated with the pixel; Add the pixel to the pixel list covered by the second node associated with the pixel.

8. The method according to any one of claims 1 to 7, characterized in that, The step of constructing a model context protocol using the second cleaned node tree file and the screenshot data includes: Convert the second cleaned node tree file into a generic DSL file; The model context protocol is constructed using the general DSL file and the screenshot data.

9. The method according to claim 8, characterized in that, The step of constructing the model context protocol using the general DSL file and the screenshot data includes: If the code generation request carries platform information of the target platform for which the design code is applied, the generic DSL file is converted into a data format that matches the target platform; The model context protocol is constructed using the DSL file after data format conversion and the screenshot data.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images