Front-end technical design document generation method and device

Abstract

The present disclosure provides a front-end technology design document generation method and device, relates to the technical field of computers, and particularly to the field of artificial intelligence. The specific implementation scheme is: obtaining a product requirement document of a target development project; determining each to-be-developed page in the target development project and page requirement information of each to-be-developed page based on the product requirement document, the page requirement information being used to represent the development requirement of the to-be-developed page; obtaining page description information of each to-be-developed page, the page description information being used to represent visual elements of the to-be-developed page; determining a design scheme of the target development project based on the page requirement information and the page description information; and generating a front-end technology design document based on the design scheme. In this way, the efficiency and quality of the front-end technology design document can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to the field of information flow. Background Technology

[0002] Current methods for generating front-end technology design documents typically rely on manual writing by front-end developers. However, this approach requires manually integrating information from multiple sources, leading to low efficiency. Furthermore, the quality of the generated front-end technology design documents depends heavily on the individual experience of the front-end developers. Therefore, ensuring both the efficiency and quality of front-end technology design document generation has become a pressing issue. Summary of the Invention

[0003] This disclosure provides a method and apparatus for generating front-end technology design documents, so as to improve the efficiency and quality of front-end technology design document generation.

[0004] According to one aspect of this disclosure, a method for generating a front-end technology design document is provided, comprising: obtaining a product requirements document for a target development project; determining, based on the product requirements document, each page to be developed in the target development project and page requirement information for each page to be developed, wherein the page requirement information is used to characterize the development requirements of the page to be developed; obtaining page description information for each page to be developed, wherein the page description information is used to characterize the visual elements of the page to be developed; determining a design scheme for the target development project based on the page requirement information and the page description information; and generating a front-end technology design document based on the design scheme.

[0005] According to another aspect of this disclosure, a front-end technology design document generation apparatus is provided, comprising: a first acquisition unit configured to acquire a product requirement document for a target development project; a first determination unit configured to determine, based on the product requirement document, each page to be developed in the target development project and page requirement information for each page to be developed, wherein the page requirement information is used to characterize the development requirements of the page to be developed; a second acquisition unit configured to acquire page description information for each page to be developed, wherein the page description information is used to characterize the visual elements of the page to be developed; a second determination unit configured to determine a design scheme for the target development project based on the page requirement information and the page description information; and a generation unit configured to generate a front-end technology design document based on the design scheme.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods of embodiments of this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods of embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods of embodiments of this disclosure.

[0009] This disclosure automates the acquisition and parsing of product requirements documents for a target development project, transforming them into structured page requirements organized by page dimension. This ensures that the design scheme of the subsequently generated target development project better matches the requirements of the product requirements document. Furthermore, by acquiring page description information, it automatically performs deep integration and correlation analysis of the development requirements and visual elements of each page to be developed in the target development project, further improving the quality of the generated design scheme and ensuring the quality of the front-end technical design document automatically generated from the target development project's design scheme. Simultaneously, since the entire process from the product requirements document to the generation of the front-end technical design document is automated, it solves the problem of low efficiency in manually writing front-end technical design documents, significantly shortening the generation cycle and improving the efficiency of front-end technical design document generation.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.

[0012] Figure 1 A schematic diagram of the architecture of the front-end technology design document generation system provided in the embodiments of this disclosure.

[0013] Figure 2 A flowchart illustrating the front-end technology design document generation method provided in this embodiment of the disclosure.

[0014] Figure 3 A schematic block diagram of a front-end technology design document generation device provided in an embodiment of this disclosure.

[0015] Figure 4 A schematic block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure. The singular forms “a,” “the,” and “the” as used in the embodiments of this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0018] It should be understood that the term "and / or" used in this document is merely a description of the relationship between related items, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this document generally indicates that the preceding and following related items have an "or" relationship.

[0019] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0020] In the field of software development, the common practice for generating front-end technical design documents for front-end developers is for them to manually sift through information from multiple sources and then write the documents themselves. However, the inventors discovered through analysis that the mapping and coverage between these multiple sources of information relies entirely on the individual experience of the front-end developers. When the front-end page design of a project is complex, this approach not only suffers from low efficiency in sifting through multiple sources but may also lead to omissions in the generated front-end design technical documents. Consequently, it fails to guarantee both the efficiency and quality of the generated front-end design technical documents.

[0021] To address the aforementioned problems, this disclosure provides a novel approach. In one embodiment of this disclosure, a front-end technology design document generation system is provided. Figure 1 This is a schematic diagram of the architecture of the front-end technology design document generation system provided in this embodiment of the disclosure. Please refer to... Figure 1 The front-end technology design document generation system 100 may include a data source 101 and a front-end technology design document generation device 102.

[0022] Data source 101 aggregates data from multiple sources, including product requirement documents, design draft links, API documents, and code repositories. This multi-source data can be stored in different formats on data source 101 without prior unified conversion.

[0023] The front-end technology design document generation device 102 is used to generate a front-end technology design document based on multi-source data stored in the data source, using the method provided in the embodiments of this disclosure.

[0024] Front-end developers can use the generated front-end technology design documents to design the front-end for the target development project.

[0025] It should be understood that Figure 1 The number of data sources 101 and front-end technology design document generation devices 102 shown is merely illustrative. Depending on implementation needs, there can be any number of data sources 101 and front-end technology design document generation devices 102.

[0026] In another embodiment of this disclosure, a method for generating front-end technology design documents is provided. Figure 2 This is a flowchart illustrating a front-end technology design document generation method provided in an embodiment of the present disclosure. This method can be executed by a front-end technology design document generation device, which can be located on a server or on a computer terminal with strong computing power. Figure 2 As shown, the method may include the following steps: Step 201: Obtain the product requirements document for the target development project.

[0027] Step 202: Based on the product requirements document, determine each page to be developed in the target development project and the page requirements information of each page to be developed. The page requirements information is used to characterize the development requirements of the page to be developed.

[0028] Step 203: Obtain the page description information for each page to be developed. The page description information is used to represent the visual elements of the page to be developed.

[0029] Step 204: Based on the page requirement information and page description information, determine the design scheme for the target development project.

[0030] Step 205: Generate front-end technology design documents based on the design scheme.

[0031] As can be seen from the above process, this disclosure automatically acquires and parses the product requirements document of the target development project, transforming it into structured page requirement information organized by page dimension. This ensures that the requirements of the subsequently generated design scheme of the target development project better match the requirements of the product requirements document. Furthermore, by acquiring page description information, the development requirements and visual elements of each page to be developed in the target development project can be automatically and deeply integrated and analyzed, further improving the quality of the generated design scheme of the target development project and further ensuring the quality of the front-end technical design document automatically generated using the design scheme of the target development project. Simultaneously, since the entire process from the product requirements document of the target development project to the generation of the front-end technical design document is automated, it solves the problem of low efficiency in manually writing front-end technical design documents, significantly shortens the generation cycle of front-end technical design documents, and improves the generation efficiency of front-end technical design documents.

[0032] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments.

[0033] First, a detailed description of step 201 above, namely "obtaining the product requirements document for the target development project", will be provided.

[0034] The Product Requirements Document (PRD) for the target development project describes the functions, interaction logic, business rules, and other content that the target development project should implement. The sources of the Product Requirements Document can be diverse, and may include, for example: For online documentation sources, front-end developers can provide knowledge base links, and the content can be safely retrieved from product requirement documents using content retrieval commands.

[0035] For local file sources, product requirement documents in formats such as Markdown (.md), Word (.docx), or PDF can be read directly from a specified local file path.

[0036] Direct text source: The text content of the product requirements document is provided directly through the interactive interface.

[0037] A unified document parser can be used to process product requirement documents from diverse sources, transforming heterogeneous raw inputs into a unified, structured intermediate representation (e.g., standardized Markdown format or JSON structure), so that subsequent processing steps can understand and manipulate product requirement documents in a unified manner.

[0038] The following is a detailed description of step 202 above, namely, "Based on the product requirements document, determine each page to be developed in the target development project and the page requirements information of each page to be developed. The page requirements information is used to characterize the development requirements of the page to be developed."

[0039] After obtaining and parsing the product requirements document, the document can be parsed. This parsing process can include page identification, information extraction and classification, thereby obtaining the page requirements information for each page to be developed.

[0040] Page recognition, in particular, involves analyzing the product requirements document to identify all the independent user interface (UI) pages that need to be developed. For example, the product requirements document for a cloud storage application might include a "file list page," a "sharing management page," and a "recycle bin preview page."

[0041] Information extraction and classification: For each identified page to be developed, further extract its associated, specific page requirement information to determine the development requirements of the corresponding page. Page requirement information may include, but is not limited to: The feature list refers to the core functions that the page to be developed needs to implement, such as "displaying a list of files", "supporting multiple file selection", and "batch sharing button".

[0042] Interaction logic, or user operation flow, represents the jump logic between various functional points, such as "click on the file to enter the details page" or "long press the file to bring up the operation menu".

[0043] Data requirements, which are the data states that the page to be developed needs to display or process, such as "file name, size, and modification date need to be displayed".

[0044] Business constraints, non-functional requirements, such as "list loading must be completed within 1 second" and "deletion operations require secondary user confirmation".

[0045] By transforming loosely structured product requirement documents into highly structured page requirement information organized by page dimension, a direct basis can be provided for the subsequent development of accurate design solutions.

[0046] The following describes step 203, namely "obtaining page description information for each page to be developed, the page description information being used to characterize the visual elements of the page to be developed," in detail with reference to an embodiment.

[0047] For pages to be developed that involve UI implementation, the page description information refers to a formatted description of the visual presentation and interaction details of the page to be developed, in order to identify the visual elements in the corresponding page. Optionally, for pages to be developed that do not involve UI implementation, the page description information can be empty or only contain a data flow description of the page's functionality.

[0048] In one embodiment of this disclosure, obtaining page description information for each page to be developed includes: obtaining design description data for each page to be developed; generating pseudocode descriptions based on the design description data; and extracting summaries from the pseudocode descriptions to obtain page description information.

[0049] Original design description data related to each page to be developed can be obtained from multi-source heterogeneous input data. This design description data can contain complete information on the page's visual presentation and interaction logic. Therefore, the design description data is large in volume and quite complex.

[0050] To transform complex design description data into a format more easily understood and processed by large language models, the analytical capabilities of these models can be leveraged to perform deep parsing. This transforms the design description data into concise pseudocode descriptions, such as tree-structured pseudocode, that approximate the logic of programming languages. By using pseudocode, the layout and style features of key page elements are preserved, while a large amount of redundant or unimportant field information is filtered out, thus compressing the data volume of the design description data.

[0051] To further reduce the data volume of the design description data, making it manageable within the context window of the large language model, a secondary refinement can be performed on the pseudocode description to generate a lightweight structured summary, resulting in highly structured page description information with a minimal data volume. The large language model can then be invoked again to refine the pseudocode description, identifying and extracting the core information most valuable for design decision-making, such as: the main functional layout of the page, key UI elements (buttons, lists, input boxes), interactive states requiring special handling (loading, empty data, errors), and key points that may differ from the PRD description.

[0052] The content of the page description information may include, but is not limited to: page overview information, that is, a simple summary of the page's functions; key elements, that is, all UI components on the page that have business functions (such as file list, upload button, search input box); special states, that is, abnormal states that need to be handled in the interaction (such as empty list data, loading failure); and information on differences from the PRD.

[0053] The above method first generates pseudocode descriptions of the large volume of design description data for the pages to be developed, preserving key elements and style details. This achieves the first compression and structural optimization of the original design description data. Then, through summary extraction, the most core key page information (such as key elements, special states, and differences from the PRD) is extracted from the pseudocode description, achieving a second, extremely lightweight compression. This two-stage compression mechanism significantly reduces the amount of page description data obtained while retaining the core visual and interactive information of the original design description data. This solves the technical problems of exceeding the context limits of large language models and low efficiency and inconsistent standards in manual operations caused by processing large volumes of unstructured design description data. It provides a high-quality, standardized data foundation for subsequent design scheme analysis, thereby generating design schemes with greater engineering value.

[0054] In one embodiment of this disclosure, the design description data includes domain-specific language (DSL) data. Obtaining the design description data for each page to be developed includes: obtaining the DSL data of the pages to be developed from an online collaborative design platform based on a Model Context Protocol (MCP) tool.

[0055] For design drafts included in the target development project (such as design files from online collaborative design platforms like Figma and Pixso), design description data for each page to be developed can be obtained through corresponding interfaces or tools. This design description data is usually in a structured but large-volume form, such as Domain-Specific Language (DSL) data or JSON data from the online collaborative design platform. It contains all the details of each element's hierarchy, geometric attributes (width, height, position), and style attributes (color, font, spacing, rounded corners). Therefore, a standardized protocol for large-scale model interaction, namely the Model Context Protocol (MCP), can be used to automatically and with high fidelity obtain the DSL data of the pages to be developed from the online collaborative design platform.

[0056] DSL is a highly structured descriptive language generated by an online collaborative design platform for each design element within it. DSL data is typically stored in JSON (such as JavaScript object notation) format, fully recording the detailed attributes of each design element on the page. These attributes may include, but are not limited to: hierarchical relationships (i.e., the tree structure of page elements and their child elements); geometric attributes (i.e., the width, height, and coordinate position of page elements); visual styles (i.e., the fill color, stroke (thickness, color, and style), corner radius, opacity, and shadow of page elements); text attributes (i.e., the font size, weight, line height, letter spacing, text color, and font family of page elements); and layout attributes (i.e., the layout direction of page elements (such as horizontal or vertical), alignment, spacing, and padding).

[0057] During design draft parsing, the system can identify the online collaborative design platform corresponding to the page to be developed. For different online collaborative design platforms, its dedicated MCP tool can be invoked. For example, for the Figma platform, the command `mcp__figma__get_figma_data` can be called; for the Pixso platform, the command `mcp__remote-pixso__get_node_dsl` can be called. These MCP tools can pre-establish secure and efficient connection channels with the corresponding online collaborative design platforms.

[0058] The MCP tool communicates with the server of the corresponding online collaborative design platform by receiving the unique identifier of the page element (e.g., fileKey and nodeId in the design draft link) to accurately extract the original DSL data corresponding to the page element. This method solves the problem of inefficient data acquisition caused by manually viewing design drafts, taking screenshots, or downloading design source files.

[0059] To ensure the robustness of the process of retrieving DSL data for the pages to be developed from an online collaborative design platform using the MCP tool, a pre-check can be performed before executing the MCP tool call. That is, before formally initiating the MCP tool call request to the corresponding online collaborative design platform, it's possible to first check whether the MCP tool corresponding to that platform is available. For example, it's possible to check whether the MCP tools for Figma or Pixso are correctly installed, configured, and running successfully.

[0060] Because this detection process is performed independently for different online collaborative design platforms, if Figma's MCP tool becomes unavailable, only data interaction with the Figma platform will cease, without affecting data interaction with the Pixso platform, and vice versa. This ensures that even when some MCP tools malfunction, DSL data from other online collaborative design platforms can still be processed, maximizing the continuity of the entire front-end design technical document generation process.

[0061] The implementation method provided in this embodiment transforms the acquisition of design description data for the pages to be developed from manual operation to protocol-driven automated acquisition. By calling the underlying interface of the online collaborative design platform, the complete DSL data (including hierarchical relationships, style attributes, interaction states, etc.) of each page to be developed can be acquired atomically and with high fidelity, ensuring the original consistency of the data structure in subsequent processing and solving the problems of information distortion and omission caused by manual screenshots and manual input. Furthermore, through the MCP protocol, it can be connected to any online collaborative design platform that supports MCP, significantly reducing the complexity of system integration. In addition, through the availability detection mechanism of the pre-set MCP tool, the availability of the MCP tool is determined before calling the MCP tool, solving the problem of the entire design draft parsing process being interrupted due to the failure of a single tool, significantly improving the stability and engineering usability of the entire front-end design technical document generation process.

[0062] In one alternative implementation, in addition to the MCP protocol, the native REST API provided by online collaborative design platforms such as Figma or Pixso can be invoked to obtain design description data.

[0063] In one embodiment of this disclosure, a summary extraction is performed on the pseudocode description to obtain page description information, including: extracting description information of specified fields from the pseudocode description as page description information.

[0064] A predefined set of fields can be used, encompassing the core fields necessary to describe the technical features of the front-end page. These fields can be determined through abstraction and summarization of front-end engineering design practices, aiming to convey the most complete design intent with the minimum amount of data. For example, these fields may include, but are not limited to: The page summary field is the field that summarizes the main functions and layout type of the page (such as list page, detail page, pop-up).

[0065] Key element fields, which are the fields corresponding to all UI components with business functions on the page, such as the fields corresponding to the search box, file list, upload button, confirmation pop-up, etc., can be derived from the identification of business component nodes in the pseudocode description; special states, which are the fields that mark the abnormal UI states that need to be processed for each data area on the page, such as the fields corresponding to the loading state, empty data state, and error state, can be inferred by analyzing the container hierarchy and general state patterns in the pseudocode description.

[0066] Fields corresponding to discrepancies with the PRD, that is, fields corresponding to inconsistencies between the visual representation in the pseudocode description and the textual description in the product requirements document. For example, the field content could be "According to the PRD, the list should support multiple selections, but no checkbox node was found in the pseudocode description".

[0067] The large language model can be invoked to analyze the pseudocode description, enabling it to identify and populate the content of the specified fields from the pseudocode description. The large language model can scan the pseudocode description line by line, identifying content that matches each specified field. For example, when searching for the field "key element," it can identify all lines of pseudocode with specific structures (such as List, Button, Input). When searching for the field "special state," it can identify patterns such as visible===false, loading, or their missing states, and make inferences and additions based on engineering experience (such as "any area with data requests should consider an empty data state").

[0068] After obtaining the description information of the specified fields, the description information of all specified fields can be filled into a unified, structured summary template, so that the generated page description information is clear in format, concise in content, and each field carries a specific type of decision information.

[0069] The implementation method provided in this embodiment utilizes pre-defined standardized fields to ensure that the page description information of each page to be developed is presented in a unified field structure. This allows for direct parsing and aggregation of the core information of each page to be developed without the need for additional alignment of the page description information. This structured summarization mechanism transforms the aggregation process of page description information across multiple pages from unstructured text aggregation to structured data fusion. It enables the rapid location of key elements, special states, and differences from the PRD for each page using standardized field names and meanings as indexes. This allows for more accurate cross-page analysis and comparison in subsequent design scheme generation, significantly improving the efficiency and accuracy of design scheme generation in complex multi-page scenarios, and further enhancing the efficiency and accuracy of front-end design technical document generation.

[0070] In one embodiment of this disclosure, obtaining page description information for each page to be developed includes: independently obtaining page description information for each page to be developed through multiple sub-intelligent agents; determining the design scheme of the target development project based on page requirement information and page description information includes: obtaining page description information provided by each sub-intelligent agent through the main intelligent agent, and determining the design scheme of the target development project based on page requirement information and page description information.

[0071] When processing the design description data of all pages to be developed, an agent architecture involving a master agent and sub-agents is used. That is, multiple independent sub-agents can be set up, each assigned to process a single page to be developed and independently generating the corresponding page description information. The master agent is responsible for overall scheduling and result aggregation.

[0072] After parsing the PRD, a node mapping table can be generated. This node mapping table maps each page to be developed to an independent processing node and records information such as the identifier of each page to be developed, the source platform (such as Figma or Pixso), the functional description text of the page, the unique identifier of the design file, the unique identifier of a specific node (page, artboard, group, layer) in the design file, the access link, and the name of the expected output file.

[0073] The main agent can traverse the node mapping table and assign a brand new, independent sub-agent instance to each processing node in the node mapping table. Each sub-agent can then acquire and process the design description data for each processing node.

[0074] Each sub-agent has a completely independent processing context and runtime space. That is, each sub-agent loads a complete instance of the large language model or its own independent session, and has its own independent context window, which will not be polluted or occupied by information from other pages. Furthermore, each sub-agent receives only one instruction, which is to retrieve the corresponding page description information for its assigned processing node.

[0075] Specifically, each sub-agent executes independently within its own context window: Data Acquisition: Utilize the appropriate MCP tool to retrieve the raw DSL data for the corresponding processing node from the online collaborative design platform. The acquired raw DSL data can then be completely written to a local file for archiving.

[0076] Data transformation: After filtering out hidden page elements (e.g., page elements with visible===false and their child page elements), the DSL data is converted into a pseudocode description. The pseudocode description can be written to a local file.

[0077] Summary Extraction: Extract a summary from the pseudocode description, resulting in a page description information with a much smaller output data volume than the original data.

[0078] Throughout the process, there is no information exchange between each sub-agent and other sub-agents, and the data is processed in complete local isolation.

[0079] Once all sub-agents have completed their processing and returned their respective page description information, the master agent receives and aggregates the page description information returned by all sub-agents to facilitate the subsequent generation of design solutions. Furthermore, the master agent can update the node mapping table and generate an optimized PRD based on the page description information returned by all sub-agents. This involves replacing the original design draft links (if any) in the PRD with pseudocode descriptions and adding a design draft analysis summary section at the end of the PRD.

[0080] By assigning an independent sub-agent to each page to be developed, each sub-agent has its own independent processing context, enabling them to complete the entire process from MCP data acquisition to pseudocode generation and summary extraction without interference. Each sub-agent only returns a lightweight structured summary to the main agent, significantly improving multi-page processing efficiency. Furthermore, this decoupled architecture combining the main agent and sub-agents allows for linear scaling of the number of pages to be processed without being constrained by the upper limit of the context window. The isolation mechanism between sub-agents reduces mutual interference between data from different pages, ensuring the processing quality and consistency of each page and guaranteeing the reliability and robustness of the obtained page description information.

[0081] The following describes step 204, namely "determining the design scheme of the target development project based on page requirement information and page description information," in detail with reference to an embodiment.

[0082] A design scheme refers to a systematic and structured technical planning scheme for front-end engineering practices. It is a specific technical implementation strategy generated by comprehensively analyzing page requirements and page description information to guide subsequent code writing.

[0083] In order to formulate a design scheme that is highly compatible with the implemented solutions of the target development project, in one embodiment of this disclosure, the design scheme of the target development project is determined based on page requirement information and page description information, including: in response to the existence of developed code corresponding to the target development project, determining the development status information of the target development project based on the developed code; and determining the design scheme based on page requirement information, page description information, and development status information.

[0084] It can determine whether an accessible codebase exists for the target development project. For example, it can attempt to access the target project's local or remote code repository (such as a Git repository). If the target project is a newly started project with no existing code or an inaccessible codebase, it generates a tagging information to mark the target project as a completely new project with no existing implementation, and will be prioritized for a completely new design in subsequent design phases. If the codebase is remote, it can request the paths to existing components from the front-end developers.

[0085] If it is determined that the target development project contains accessible, already developed code, the code repository can be scanned. The scanning scope can typically be limited to the functional modules and pages covered in the product requirements document to improve scanning efficiency and generate structured development status information for the target development project. This development status information may include, but is not limited to, the following analytical results: Page routing status: Record the existing page routing paths, naming rules, route guard configurations (e.g., interception operations during page navigation), and page layout reuse status in the target development project.

[0086] Component status: Identify the encapsulated and reusable UI and business components in the code repository, and record their properties (Props, such as input parameters or configuration items), usage methods, and locations.

[0087] Current state of data: Determine the state management architecture already adopted by the target development project (e.g., using libraries such as Redux, Pinia, and Zustand), and clarify the defined global state store (Store), page-level state, server-side state cache, etc.

[0088] After scanning the code repository, the scan results can be organized into a structured list of current status evidence. For example, each record can include fields such as: capability points (e.g., search box component), evidence path (e.g., src / components / SearchBox), current implementation (e.g., based on Ant Design encapsulation), gaps / conflicts (e.g., lack of debouncing function), thereby obtaining information on the current development status.

[0089] After obtaining the current development status information, it can be jointly analyzed with the page requirement information and page description information. This analysis process can compare the target state of the target development project (determined by the page requirement information and page description information) with the current state (defined by the current development status information), thereby formulating a design scheme that meets new requirements while maximizing the reuse of existing code and reducing conflicts.

[0090] For example, regarding page routing, we can analyze the page routes that need to be added or modified. If the page requirement information requires the addition of a file details page, and the development status information shows that a general content details page route template already exists in the target development project, then the design solution will suggest reusing the template, only modifying the route parameters and business logic, rather than creating it from scratch.

[0091] For component design, it can identify which UI structures are needed in the page description information. If the development status information indicates that the target development project already has common avatar components, pagination components, and search boxes, the design solution will suggest directly referencing these components and only defining business components specific to the new page (such as the search results list).

[0092] Regarding data status, the data flow of new features can be planned. If there is already a global user preference settings store in the current development status information, and the new feature also needs to read user preferences, the design will incorporate the status of the new feature into the existing store, rather than creating a new global store, thereby maintaining the consistency of the state management architecture.

[0093] The design scheme determined through comparison and integration not only includes a completely new design to meet new requirements, but also identifies the parts of the developed code that can be directly reused or modified for reuse, thus forming a highly engineered and executable design scheme.

[0094] Optionally, in addition to the dimensions mentioned above, the following may also be included: The UI state dimension refers to whether each data display area describes its UI behavior and interaction logic in abnormal states such as loading, empty data, and loading failure, and whether the form describes states such as initial, submission, successful submission, and failed submission.

[0095] Performance-wise, strategies include: tiered list data volume (normal rendering for lists with fewer than 100 items, pagination for lists with 100-1000 items, and virtual scrolling for lists with more than 1000 items), lazy loading of images, route-level code splitting (e.g., using defineAsyncComponent in Vue3, and React.lazy in React), and search debouncing (e.g., setting a timeout of 300 milliseconds).

[0096] Security analysis dimensions include XSS protection (such as escaping user input), sensitive data handling (such as not storing passwords locally, displaying them in encrypted form, etc.), and file upload verification (both front-end and back-end verify the type and size of the file).

[0097] Engineering configuration dimensions include code file organization conventions, internationalization (i18n) schemes, theming (Theme / CSS variables), and testing strategies.

[0098] By employing the above methods, if the target development project already has existing code, its current development status information can be automatically scanned and extracted. This allows the design solution to identify reusable page routes, components, and state management within the existing codebase, thus enabling incremental design based on current development status information and reducing engineering redundancy caused by repeated development. Because it incorporates current development status information, the generated design solution is highly compatible with the existing code implementation of the target development project in terms of routing planning, component reuse, and state management. This solves the technical problem of the generated design solution being disconnected from the existing code in the target development project, leading to difficulties in implementation or conflicts, and significantly improves the feasibility of implementation and development efficiency.

[0099] To make the generated design scheme more refined, structured, and highly engineering-executable, one embodiment of this disclosure introduces multi-dimensional development status information. Specifically, the development status information includes at least one of the following: current status information of page routing, current status information of components, and current status information of resources. The design scheme includes at least one of the following: a page routing planning scheme determined based on the current status information of page routing, page requirement information, and page description information; a component design scheme determined based on the current status information of components, page requirement information, and page description information; and a resource status management scheme determined based on the current status information of resources, page requirement information, and page description information.

[0100] The current development status information can be broken down into multiple dimensions, and for each dimension, combined with page requirement information and page description information, a specific design solution for that dimension can be generated.

[0101] Development status information may include at least one or more of the following specific technical dimensions: Page routing status information: This information records all existing page routing configurations in the target development project. This may include: the number and path of page routes, i.e., the total number of existing page routes and their corresponding URL paths; page route naming conventions, i.e., the naming rules used for page routes in the target development project (e.g., using kebab-case or PascalCase); dynamic page route parameters, i.e., whether existing page routes use dynamic parameters (e.g., / user / :id) and their definition methods; page route guard configuration, i.e., page routes configured with permission guards (e.g., login permission verification, role verification, etc.) and their corresponding guard logic; layout reuse status: whether the current page reuses shared layout components.

[0102] Component Status Information: This information analyzes the components already encapsulated in the target development project, which may include: UI component library, i.e., the general UI component library introduced in the target development project (such as Ant Design, Element Plus) and its basic components already used (such as buttons, input boxes, tables); business components, i.e., self-encapsulated components for specific business scenarios (such as search boxes, file list items, user cards); component Props definition, i.e., recording the types and uses of input parameters of reusable components; component usage location, i.e., in which pages or modules the component is referenced.

[0103] Resource status information: This information analyzes the current state management architecture of the target development project, which may include: state management library, i.e., the state management scheme used by the target development project (such as Redux, Pinia, Zustand, Context API); global store, i.e., the defined global state repository and the shared data it manages (such as user information, theme settings, language preferences); page-level or module-level state, i.e., the definition used to manage the private state inside a specific page or module; server-side state cache, i.e., the caching strategy and library used to manage data from the server (such as React Query, SWR).

[0104] Having determined the above structured, multi-dimensional development status information, we can then conduct a precise comparative analysis of the target status and the current status for each dimension: By analyzing the current state of page routing information, we can examine pages in new requirements (e.g., the recycle bin preview page) and compare them with the existing page routing information. If a common page routing template already exists in the developed code, the design solution will suggest reusing that template, modifying only the dynamic routing parameters and permission guards. If it's a completely new page type, the design solution will suggest adding a new route and defining its path, parameters, and guard logic according to the target development project's specifications. This results in a page routing plan determined based on the current state of page routing information, page requirement information, and page description information. This approach solves the problem of creating page routing configurations from scratch for each new page, ensuring the consistency and maintainability of the page routing structure.

[0105] By analyzing the current status information of components, the UI structure in the page description can be identified to pinpoint required UI elements (such as a user list containing avatars and text). Then, the current status information of the components is retrieved to determine if reusable business components or basic UI components exist. If so, the design solution suggests directly referencing these components; otherwise, it suggests adding new business components and defining their Props interfaces. This results in a component design solution determined based on the current status information, page requirements, and page description. This approach maximizes code reuse, reduces redundant development work, and ensures consistency in page style.

[0106] By analyzing the current status information of resources, we can determine whether new requirements (e.g., batch sharing) necessitate storing the user-selected file list or sharing settings. We can query the current status information of resources to assess whether the existing global Store (e.g., user information Store) or specific business Store is suitable for expansion to accommodate these new states. If suitable, the design solution will suggest expanding the state and actions within the existing Store. If not, the design solution will suggest creating new page-level states or independent sub-Stores, thus obtaining a resource state management solution based on the current status information of resources, page requirement information, and page description information. This approach ensures a clear and orderly state management architecture, resolving issues of data flow chaos and state redundancy.

[0107] By leveraging the development status information across the three dimensions provided in this embodiment and generating corresponding solutions, the relationship between the existing routing structure and the routes to be added can be accurately identified at the page routing dimension. At the component dimension, the mapping points between the existing component library and the components to be developed can be accurately located. At the state management dimension, the boundaries between globally shared state and page-level private state can be clearly defined. This transforms the decision-making process for project reuse or addition from experience-driven to data-driven. The generated design solutions are specific and directly executable solutions for page routing, components, and state management, thereby maximizing the value of the existing code in the target development project. This significantly reduces the workload of developing new features and ensures that the newly generated page routing planning, component design, and state management solutions are highly compatible with the structure and specifications of the existing code library of the target development project. This resolves the conflict between the design solution and the existing architecture and improves the accuracy and effectiveness of the generated design solutions.

[0108] To ensure the API integration portion of the design scheme remains feasible and prevents process interruptions or incorrect scheme generation due to missing information, in one embodiment of this disclosure, a design scheme for the target development project is determined based on page requirement information and page description information. This includes: in response to the existence of an interface document for the target development project, a design scheme is determined based on the page requirement information, page description information, and interface document, wherein the design scheme includes the interface scheme provided by the interface document; in response to the absence of an interface document for the target development project, a design scheme is determined based on the page requirement information and page description information, wherein the design scheme includes an interface suggestion scheme generated based on the interface requirement information in the page requirement information.

[0109] Based on the usability of the target development project's interface documentation, differentiated design solutions are generated. This includes the following two scenarios: In the first scenario, when the interface documentation for the target development project exists, the interface documentation is parsed and used as a reliable structured data source. It is then deeply integrated with the page requirement information and page description information to determine the design scheme based on these three types of information, so that the generated design scheme includes the interface scheme provided by the interface documentation.

[0110] The API solution includes complete and precise technical details provided in the API documentation. This may include: API definitions, i.e., the request methods (e.g., GET, POST) and URL paths for each API; data structures, i.e., the complete TypeScript type definitions for request parameters (RequestBody / Query Params) and response data (Response Body); status code mapping, i.e., the business meaning and front-end processing logic corresponding to different request status codes (e.g., 200, 400, 500); and invocation strategies, such as retry mechanisms, timeout settings, and race condition handling (e.g., using AbortController to cancel duplicate requests).

[0111] In this scenario, since the interface information is fixed, accurate interface solutions can be generated without the need for secondary confirmation or speculation, which greatly improves the accuracy of the design solution and ensures the accuracy of front-end technical design documents and development efficiency.

[0112] In the second scenario, when the target development project lacks API documentation (e.g., not provided by front-end developers, not mentioned in the PRD, or other situations where there is no valid API documentation), a deeper analysis of the page requirements can be conducted to extract API requirements related to backend data interaction. This API requirement information may include, but is not limited to: the data to be displayed on the page (e.g., file list, user information), the data to be submitted by the user (e.g., forms, deletion requests), and the relationships between data. Based on the page requirements and page description information, the determined design scheme includes API suggestion schemes generated based on the API requirements information.

[0113] Interface proposals can serve as a starting point for discussion and progress. For example, they can include: an interface list, which is a list of potentially needed interfaces derived from the PRD's feature point analysis (e.g., retrieving file lists, deleting files); suggested data structures, which define the expected request parameters and candidate TypeScript types for response data for each proposed interface, inferred from the UI component's Props definition and page state; and a status description, clearly indicating in the PRD that the interface proposal is pending confirmation with the backend, allowing frontend and backend developers to finalize it during the review process.

[0114] In this scenario, even in the absence of interface documentation, valuable design solutions can be generated, providing a clear review basis for the joint debugging of the front-end and back-end. This solves the problem of development process stagnation caused by front-end developers waiting for interface documentation, thereby ensuring the continuity of the entire target development project's development process.

[0115] Through these two scenarios, when the API documentation exists, its structured data is integrated into the design scheme to ensure the high accuracy of the API integration solution. When the API documentation is missing, an API suggestion scheme is automatically generated based on the API requirements in the page requirements information. This differentiated processing mechanism ensures that complete API integration content can be provided for the design scheme regardless of the existence of the API documentation. This solves the technical problem of interrupting the design scheme generation process or generating impractical design schemes due to missing API documentation, ensuring the robustness and continuity of the development process, improving the engineering adaptability and feasibility of the generated design scheme, and enhancing the development collaboration efficiency of the front-end and back-end developers of the target project, thereby guaranteeing the development efficiency of the target project.

[0116] In order to detect whether certain standard design elements necessary for front-end engineering practices are missing in the design scheme, in one embodiment of this disclosure, after determining the design scheme of the target development project, in response to the lack of sub-design schemes for preset functional points in the design scheme, supplementary information for the missing preset functional points can be generated and provided to the user, or, preset sub-design schemes for preset functional points can be added to the design scheme.

[0117] A pre-defined list of preset functionalities can be created, which can be derived from common practices and best practices in the field of front-end engineering. This list of preset functionalities may include: UI state handling refers to whether each data display area describes its UI behavior and interaction logic in abnormal states such as loading, empty data, and loading failure, and whether the form describes states such as initial, submission, successful submission, and failed submission.

[0118] Form validation rules, that is, whether basic required field validation, format validation (such as email address, mobile phone number) and length limit are defined for all input fields.

[0119] Destructive operation protection, that is, for irreversible operations such as "delete" and "clear", whether a secondary confirmation pop-up mechanism is designed, and whether the confirmation button uses a dangerous color (such as red).

[0120] Anti-duplicate submission, that is, for form submission, saving and other operations, whether there are mechanisms designed to prevent users from clicking repeatedly, such as disabling buttons or loading states.

[0121] For page access events, key function clicks, and operation success or failure events, have tracking points or data monitoring mechanisms been set up?

[0122] Are list pagination, virtual scrolling, lazy loading of images, code splitting, and search debouncing configured reasonably according to the data volume?

[0123] Is user input display secure against XSS vulnerabilities? Are sensitive fields handled correctly? Is file upload double-checked?

[0124] After generating the design scheme, the design scheme can be compared with the list of preset functional points item by item. This process can be implemented by a large language model. For example, the large language model will perform semantic-level understanding of the design scheme and determine item by item whether each chapter in the design scheme (such as component design, state management, API integration, etc.) has provided corresponding strategies for each preset functional point in the list of preset functional points.

[0125] For example, in the component design section of the design scheme, have the UI states of the list component that retrieves data from the API been described for loading and when the data is empty? In the interaction design section, has a secondary confirmation pop-up logic been designed for the "Delete" button after clicking? In the state management section, has a "submitting" (isSubmitting) state been defined for the form submission button to prevent duplicate submissions?

[0126] If, during the comparison process, it is found that the design scheme lacks a strategy for a specific preset function, one of the following two methods can be selected based on the nature of that preset function: The first approach involves generating supplementary questions and notifying front-end developers. That is, for missing items that cannot be automatically determined through general rules and require decision-making based on business scenarios or specific user preferences, structured supplementary questions can be generated. These questions clearly indicate the missing design elements, their context (such as a file list component), and pose one or more specific, answerable questions (e.g., "Does the member list need virtual scrolling when it exceeds 200 people?"). This supplementary information can then be presented to front-end developers via an interactive interface. After receiving responses from front-end developers, their answers can be transformed into specific sub-design solutions and incorporated into the original design.

[0127] The second method is to automatically supplement preset sub-design schemes. That is, for missing items that are highly universal and applicable to almost all scenarios, corresponding preset sub-design schemes can be automatically supplemented. For example: When it is found that no abnormal state is defined in a certain data acquisition area, the system can automatically supplement the preset sub-design scheme of the three-stage standard abnormal state of "loading - empty data - loading failed", and include a retry mechanism and general text.

[0128] When it is found that a form submit button does not have anti-duplicate protection, a preset sub-design scheme can be automatically added: "When submitting, the button is grayed out and a loading animation is displayed; after a submission failure, the button is restored and can be resubmitted."

[0129] When it is found that a "Delete" button does not have a secondary confirmation mechanism, a preset sub-design scheme can be automatically added: "Clicking it will pop up a confirmation pop-up window with the title 'Confirm Delete' and buttons for 'Cancel' and 'Confirm Delete' (using a danger color)".

[0130] The pre-defined sub-design schemes can be standardized technical templates, which can be seamlessly embedded into the original design schemes.

[0131] Through the above approach, a preset standard design element list is used to automatically detect the generated design scheme, so as to identify missing function points in the design scheme. For content that can be automatically supplemented according to general rules, supplementation can be performed directly; for content requiring user judgment, structured supplementary inquiry information can be generated and presented to the user with the minimum number of questions. This mechanism combining automatic supplementation and user clarification solves the technical problems of incomplete front-end technical design documents and high rework rate in the research and development stage caused by the omission of standard design elements (such as abnormal state handling, duplicate submission prevention, etc.) in the automatically generated design scheme, significantly improves the completeness and standardization degree of front-end technical design documents, reduces the communication and rework costs in the research and development stage, and improves the generation efficiency of front-end technical design documents.

[0132] The above step 205, namely "generating a front-end technical design document based on the design scheme", is described in detail below with reference to the embodiments.

[0133] To ensure the professionalism, consistency and completeness of the front-end technical design document, so that it can be directly used by front-end engineers for coding, in an embodiment of the present disclosure, generating the front-end technical design document based on the design scheme includes: extracting requirement overview information based on the product requirement document; assembling the requirement overview information and the design scheme into a preset document template to obtain the front-end technical design document.

[0134] After obtaining the design scheme, targeted summary extraction can be performed on the product requirement document first, for example, a large language model is called to perform semantic analysis on the preprocessed structured product requirement document, so as to extract the requirement overview information of the target development project. The requirement overview information may include: Project background, that is, the reason for this development or revision, and the business or user pain points to be solved.

[0135] Business objectives, that is, the business indicators or user experience improvement targets expected to be achieved through this development.

[0136] Non-functional constraints, such as performance indicators (page loading time consumption), compatibility requirements (supported browser versions), security requirements, etc.

[0137] Key points of the scheme, that is, summary information of the current design scheme, such as "reconstruct the file list module", "add a new sharing function", etc.

[0138] The requirement overview information can provide a context basis for all details of the subsequent design scheme.

[0139] The document template may be a predefined standard template oriented to front-end engineering practice, and the document template may define the chapter structure, content specifications and organization mode that the front-end technical design document should have.

[0140] By filling in the requirements overview and design solutions according to the document template, a professional front-end technology design document that conforms to industry standards, has a clear and complete structure, and is easy to read can be obtained. This filling process can be a structured data mapping process, for example: The "Summary" section in the document template will be filled with a summary of the requirements.

[0141] The "Page and Route Design" section in the document template will be filled with the content about the page routing plan from the design scheme.

[0142] The "Component Design" section in the document template will be filled with the content of the component decomposition and design scheme from the design plan.

[0143] The "State Management" section in the document template will be filled with the content of the state management layering scheme from the design plan.

[0144] The "API Integration" section in the document template should be filled with information about the interface scheme or suggested interface scheme from the design proposal.

[0145] By utilizing pre-set, industry-standard professional document templates, the various dimensions of the design scheme are structurally assembled according to a standard format. This template-based output mechanism ensures that the resulting front-end technology design documents achieve a standardized structure. Front-end developers can directly use these documents as coding guidelines or as contextual input for programming tools without secondary formatting. This solves the technical problem of inconsistent formatting, incomplete content, and difficulty in direct use by front-end developers in generating front-end technology design documents due to a lack of standardized organization and presentation structures. It ensures the professionalism and consistency of front-end technology design, reduces the reading and understanding costs of front-end technology design, improves the completeness of front-end technology design, and enhances the development efficiency of front-end developers for the target project.

[0146] In one alternative implementation, the front-end technical design document can also be obtained based on progressive content generation using a large language model. For example, by constructing complex prompts containing writing instructions for each chapter, such as "component design" and "state management," the large language model can autonomously and sequentially generate the content of each chapter in the front-end technical design document.

[0147] To ensure that the final output front-end technical design document is highly consistent with the original input product requirement document, in one embodiment of this disclosure, after generating the front-end technical design document based on the design scheme, a large language model can be used to compare the front-end technical design document with the product requirement document to determine missing and deviating functional points. Missing functional points are functional points included in the product requirement document but not in the front-end technical design document, and deviating functional points are functional points whose descriptions are inconsistent between the front-end technical design document and the product requirement document.

[0148] Front-end technical design documents and product requirement documents can be used as input, and a large language model can be used for requirement validation. After reading the front-end technical design documents and product requirement documents, the large language model performs the following comparison process: Function point extraction and anchoring, also known as large language modeling, first involves identifying and listing all explicitly defined or implicit function points from the product requirements document. These function points can be specific operations (such as "support batch file download"), business rules (such as "non-VIP users can select a maximum of 10 files at a time"), or interface requirements (such as "the list page must display file size and upload time"), etc.

[0149] Correspondence search, also known as large language model, traverses each chapter of the front-end technical design document (such as page routing, component design, API integration, interaction state, etc.), searching one by one whether each functional point in the product requirements document has a corresponding design embodiment in the front-end technical design document. This search process can be implemented based on semantic understanding, or optionally, based on keyword matching.

[0150] The classification labeling, or classification by the large language model after comparison, categorizes the coverage of each functional point: Covered, indicating that the functional point has a clear design description in the front-end technical design document; Omitted, indicating that the functional point is clearly present in the product requirements document, but the corresponding design description cannot be found in any chapter of the front-end technical design document; Deviated from the functional point, indicating that the functional point is described in both the front-end technical design document and the product requirements document, but the descriptions are inconsistent. For example, the product requirements document specifies that "a secondary confirmation pop-up window should pop up after clicking the delete button," while the front-end technical design document describes it as "the deletion operation is performed directly after clicking the delete button."

[0151] After the comparison is complete, a structured verification summary can be output. This summary can be attached as a quality report to a section of the front-end technical design document or output separately. The content of the verification summary may include: Missing Feature List: Clearly list all features that exist in the product requirements document but are missing from the front-end technical design document.

[0152] Deviation from Feature List: Clearly list the features whose descriptions in the front-end technical design document are inconsistent with those in the product requirements document.

[0153] Coverage statistics: Quantitative indicators of verification results, such as "requirement coverage is 27 / 30, or 90%", which intuitively shows the completeness of the front-end technical design document.

[0154] By employing the above method, a large language model is invoked to perform a full comparison between the generated front-end technical design document and the original PRD. The functional coverage of the front-end technical design document is verified point by point. Simultaneously, by outputting detailed verification summaries, a quantitative metric for the quality of the front-end technical design document is provided to the user. This solves the technical problem that the lack of a quality verification mechanism often leads to automatically generated front-end technical design documents omitting functional points from product requirement documents or exhibiting descriptive deviations, resulting in uncontrollable quality and high rework rates in R&D. It achieves an automated and highly accurate verification process, significantly improving the efficiency and reliability of the verification stage, enhancing the quality of the front-end technical design document, reducing communication and rework costs during the R&D phase, and improving the efficiency of the front-end technical design document.

[0155] Experiments have shown that relying on front-end developers to manually write front-end technical design documents takes approximately 8 to 16 hours, while the automated generation process for front-end technical design documents provided in this disclosure takes approximately 2 hours, improving the generation efficiency by about 4 to 8 times. In addition, the requirement coverage rate of front-end technical design documents obtained by relying on front-end developers to write documents is 70%-75%, while the requirement coverage rate of front-end technical design documents generated by the automated generation process provided in this disclosure is over 90%, improving the requirement coverage rate of front-end technical design documents by about 15%-20%.

[0156] The foregoing has described specific embodiments of this disclosure. 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 also possible or may be advantageous.

[0157] In another embodiment of this disclosure, a front-end technology design document generation device is provided. Figure 3 This is a schematic block diagram of a front-end technology design document generation device provided in an embodiment of this disclosure. This device can be located on a server or on a computer terminal with strong computing power. Figure 3 As shown, the front-end technology design document generation device 300 includes a first acquisition unit 301, a first determination unit 302, a second acquisition unit 303, a second determination unit 304, and a generation unit 305. The main functions of each component are as follows: The first acquisition unit 301 is configured to acquire the product requirements document of the target development project.

[0158] The first determining unit 302 is configured to determine each page to be developed in the target development project and the page requirement information of each page to be developed based on the product requirement document. The page requirement information is used to characterize the development requirements of the page to be developed.

[0159] The second acquisition unit 303 is configured to acquire page description information of each page to be developed, the page description information being used to characterize the visual elements of the page to be developed.

[0160] The second determining unit 304 is configured to determine the design scheme of the target development project based on page requirement information and page description information.

[0161] Generation unit 305 is configured to generate front-end technology design documents based on the design scheme.

[0162] As one possible implementation method, when the second determining unit 304 determines the design scheme of the target development project based on the page requirement information and the page description information, it can be specifically configured as follows: in response to the fact that there is already developed code corresponding to the target development project, the development status information of the target development project is determined based on the already developed code; and the design scheme is determined based on the page requirement information, the page description information and the development status information.

[0163] Furthermore, the development status information includes at least one of the following: current status information of page routing, current status information of components, and current status information of resources. The design scheme includes at least one of the following: a page routing planning scheme determined based on the current status information of page routing, page requirement information, and page description information; a component design scheme determined based on the current status information of components, page requirement information, and page description information; and a resource status management scheme determined based on the current status information of resources, page requirement information, and page description information.

[0164] As one possible implementation method, when the second determining unit 304 determines the design scheme of the target development project based on the page requirement information and the page description information, it can be specifically configured as follows: in response to the existence of an interface document for the target development project, a design scheme is determined based on the page requirement information, the page description information, and the interface document, and the design scheme includes the interface scheme provided by the interface document; in response to the absence of an interface document for the target development project, a design scheme is determined based on the page requirement information and the page description information, and the design scheme includes the interface suggestion scheme generated based on the interface requirement information in the page requirement information.

[0165] As one possible implementation method, when the second acquisition unit 303 acquires the page description information of each page to be developed, it can be specifically configured to: acquire the design description data of each page to be developed; generate pseudocode description based on the design description data; and extract a summary from the pseudocode description to obtain the page description information.

[0166] As one possible approach, the design description data includes domain-specific language (DSL) data. When the second acquisition unit 303 acquires the design description data for each page to be developed, it can be specifically configured to acquire the DSL data of the page to be developed from the online collaborative design platform based on the Model Context Protocol (MCP) tool.

[0167] As one possible implementation method, when the second acquisition unit 303 extracts a summary from the pseudocode description to obtain page description information, it can be specifically configured to: extract description information of specified fields from the pseudocode description as page description information.

[0168] As one possible implementation method, when the second acquisition unit 303 acquires the page description information of each page to be developed, it can be specifically configured to: acquire the page description information of each page to be developed independently through multiple sub-intelligent agents; and determine the design scheme of the target development project based on the page requirement information and the page description information, including: acquiring the page description information provided by each sub-intelligent agent through the main intelligent agent, and determining the design scheme of the target development project based on the page requirement information and the page description information.

[0169] Furthermore, the second determining unit 304 can also be specifically configured to: after determining the design scheme of the target development project, in response to the lack of sub-design schemes for preset functional points in the design scheme, generate supplementary information for the missing preset functional points and provide the supplementary information to the user, or supplement the design scheme with preset sub-design schemes for preset functional points.

[0170] As one possible approach, when generating a front-end technology design document based on a design scheme, the generation unit 305 can be specifically configured to: extract requirement overview information from the product requirement document; assemble the requirement overview information and the design scheme into a preset document template to obtain the front-end technology design document.

[0171] Furthermore, the generation unit 305 can also be specifically configured to: after generating the front-end technical design document based on the design scheme, use a large language model to compare the front-end technical design document with the product requirements document to determine the missing functional points and the deviated functional points. The missing functional points are the functional points included in the product requirements document but not included in the front-end technical design document, and the deviated functional points are the functional points whose descriptions are inconsistent between the front-end technical design document and the product requirements document.

[0172] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0173] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of various types of information, such as user personal information, involved in the technical solutions disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0174] According to embodiments of this disclosure, this disclosure also provides an electronic device, a non-transitory computer-readable storage medium storing computer instructions, and a computer program product.

[0175] Figure 4This is a schematic block diagram of an electronic device provided for embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0176] like Figure 4 As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the electronic device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0177] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of displays, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0178] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as the front-end technology design document generation method. For example, in some embodiments, the front-end technology design document generation method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the front-end technology design document generation method described above can be performed. Alternatively, in other embodiments, the computing unit 401 can be configured to perform the front-end technology design document generation method by any other suitable means (e.g., by means of firmware).

[0179] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0180] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0181] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0182] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0183] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0184] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0185] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0186] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for generating front-end technology design documentation, comprising: Obtain the product requirements document for the target development project; Based on the product requirements document, each page to be developed in the target development project and the page requirements information of each page to be developed are determined. The page requirements information is used to characterize the development requirements of the page to be developed. Obtain page description information for each of the pages to be developed, wherein the page description information is used to characterize the visual elements of the pages to be developed; Based on the page requirement information and the page description information, the design scheme of the target development project is determined; A front-end technology design document is generated based on the design scheme.

2. The method according to claim 1, wherein, The step of determining the design scheme of the target development project based on the page requirement information and the page description information includes: In response to the fact that there is already developed code corresponding to the target development project, the development status information of the target development project is determined based on the developed code; Based on the page requirement information, the page description information, and the development status information, the design scheme is determined.

3. The method according to claim 2, wherein, The development status information includes at least one of the following: page routing status information, component status information, and resource status information; the design scheme includes at least one of the following: Based on the current status information of the page routing, the page requirement information, and the page description information, a page routing planning scheme is determined. The design scheme of the component is determined based on the current status information of the component, the page requirement information, and the page description information; A resource status management scheme is determined based on the current status information of the resources, the page requirement information, and the page description information.

4. The method according to claim 2 or 3, wherein, The step of determining the design scheme of the target development project based on the page requirement information and the page description information includes: In response to the existence of the interface document for the target development project, the design scheme is determined based on the page requirement information, the page description information, and the interface document, wherein the design scheme includes the interface scheme provided by the interface document; In response to the absence of an interface document for the target development project, the design scheme is determined based on the page requirement information and the page description information. The design scheme includes an interface suggestion scheme generated based on the interface requirement information in the page requirement information.

5. The method according to any one of claims 1-4, wherein, The step of obtaining the page description information for each of the pages to be developed includes: Obtain the design description data for each of the pages to be developed; Generate pseudocode description based on the design description data; The pseudocode description is digested to obtain the page description information.

6. The method according to claim 5, wherein, The design description data includes domain-specific language (DSL) data, and obtaining the design description data for each of the pages to be developed includes: The Model Context Protocol (MCP) tool obtains the DSL data of the page to be developed from an online collaborative design platform.

7. The method according to claim 5 or 6, wherein, The pseudocode description is digested to obtain the page description information, including: The description information of the specified fields is extracted from the pseudocode description and used as the page description information.

8. The method according to any one of claims 1-7, wherein, The step of obtaining the page description information for each of the pages to be developed includes: The page description information of each page to be developed is obtained independently by multiple sub-intelligent agents; The step of determining the design scheme of the target development project based on the page requirement information and the page description information includes: The main agent obtains the page description information provided by each of the sub-agents, and determines the design scheme of the target development project based on the page requirement information and the page description information.

9. The method according to any one of claims 1-8, wherein after determining the design scheme of the target development project, the method further comprises: In response to the lack of a sub-design scheme for a preset function point in the design scheme, supplementary information for the missing preset function point is generated and provided to the user, or a preset sub-design scheme for the preset function point is added to the design scheme.

10. The method according to any one of claims 1-9, wherein, The generation of front-end technology design documents based on the design scheme includes: Extract the requirements overview information from the aforementioned product requirements document; The requirements overview information and the design scheme are assembled into a preset document template to obtain the front-end technology design document.

11. The method according to any one of claims 1-10, after generating the front-end technology design document based on the design scheme, the method further includes: Using a large language model, the front-end technical design document and the product requirements document are compared to identify missing and deviated functional points. The missing functional points are those included in the product requirements document but not in the front-end technical design document, and the deviated functional points are those whose descriptions are inconsistent between the front-end technical design document and the product requirements document.

12. A front-end technology design document generation device, comprising: The first acquisition unit is configured to acquire the product requirements document of the target development project; The first determining unit is configured to determine, based on the product requirements document, each page to be developed in the target development project and the page requirement information of each page to be developed, wherein the page requirement information is used to characterize the development requirements of the page to be developed. The second acquisition unit is configured to acquire page description information of each of the pages to be developed, wherein the page description information is used to characterize the visual elements of the pages to be developed; The second determining unit is configured to determine the design scheme of the target development project based on the page requirement information and the page description information; The generation unit is configured to generate a front-end technology design document based on the design scheme.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-11.

Images