Application description document generation method and related device, electronic equipment and storage medium

Abstract

The invention discloses an application description document generation method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a domain knowledge base for supporting application building; wherein the domain knowledge base comprises a plurality of metadata structure descriptions; analyzing code data of the target application based on the metadata structure description to obtain an information graph of the target application, and obtaining role description of the target object; wherein the target object is an object to be provided by a to-be-generated description document of the target application; based on the domain knowledge base, the information atlas and the role description, constructing a first large model instruction; and obtaining an output text of the first large model in response to the first large model instruction as a target description document provided for the target object. According to the scheme, automatic generation of the application description document can be realized, and pertinence and accuracy of description document generation are improved.

Description

Technical Field

[0001] This application relates to the field of application development technology, and in particular to an application documentation generation method and related apparatus, electronic devices and storage media. Background Technology

[0002] With the advancement of information technology, application development models continue to evolve, and the functions and structures of the applications being built are becoming increasingly complex. As a result, documentation for understanding these applications has received increasing attention.

[0003] In existing technologies, professional developers typically manually write documentation for the target application's system architecture, module design, interface specifications, and operation guides. However, this approach not only demands high levels of expertise from the writers but is also inefficient. Furthermore, as application complexity increases, manual documentation struggles to meet the demands of rapid application iteration and the diversification of documentation scenarios. Therefore, how to automate the generation of application documentation and improve its relevance and accuracy has become a pressing issue. Summary of the Invention

[0004] The main technical problem addressed by this application is to provide an application specification document generation method and related apparatus, electronic device and storage medium, which can realize the automated generation of application specification documents and improve the relevance and accuracy of the generated documents.

[0005] To address the aforementioned technical problems, the first aspect of this application provides a method for generating application documentation, comprising: acquiring a domain knowledge base used to support application construction; wherein the domain knowledge base contains several metadata structure descriptions; parsing the code data of the target application based on the metadata structure descriptions to obtain an information graph of the target application, and acquiring a role description of a target object; wherein the target object is the object to be provided by the documentation to be generated for the target application; constructing a first major model instruction based on the domain knowledge base, the information graph, and the role description; wherein the first major model instruction is used to instruct the first major model to generate a documentation for the target object to understand the target application based on the domain knowledge base; and acquiring the output text of the first major model in response to the first major model instruction, as the target documentation provided to the target object.

[0006] To address the aforementioned technical problems, a second aspect of this application provides an application documentation generation apparatus, comprising: an acquisition module, a parsing module, a construction module, and an output module. The acquisition module acquires a domain knowledge base used to support application development; wherein the domain knowledge base contains several metadata structure descriptions. The parsing module parses the code data of the target application based on the metadata structure descriptions to obtain an information graph of the target application, and acquires a role description of the target object; wherein the target object is the object to be provided in the documentation to be generated for the target application. The construction module constructs a first major model instruction based on the domain knowledge base, the information graph, and the role description; wherein the first major model instruction instructs the first major model to generate a documentation for the target object to understand the target application based on the domain knowledge base. The output module acquires the output text of the first major model in response to the first major model instruction, as the target documentation provided to the target object.

[0007] To address the aforementioned technical problems, a third aspect of this application provides an electronic device including a memory and a processor coupled to each other. The memory stores at least program instructions, and the processor executes the program instructions to implement the application documentation generation method described in the first aspect.

[0008] To address the aforementioned technical problems, a fourth aspect of this application provides a computer-readable storage medium storing program instructions executable by a processor, the program instructions being used to implement the application documentation generation method of the first aspect described above.

[0009] The above solution involves acquiring a domain knowledge base to support application development. This knowledge base contains several metadata structure descriptions. Based on these metadata structure descriptions, the code data of the target application is parsed to obtain an information graph of the target application, as well as role descriptions of target objects. Target objects are the objects to be provided in the documentation to be generated for the target application. Based on the domain knowledge base, information graph, and role descriptions, a first major model instruction is constructed. This first major model instruction instructs the first major model to generate documentation for the target objects to understand the target application based on the domain knowledge base. The output text of the first major model in response to the first major model instruction is obtained and serves as the target documentation provided to the target objects. On one hand, the domain knowledge base, as support for analyzing the target application, provides foundational knowledge for application parsing and information graph construction, and enables automated generation of the target documentation through a large language model. On the other hand, using the information graph of the target application as reference data for generating the target documentation provides more logically clear data related to the target application during the documentation generation process, thereby improving the accuracy of the documentation generation. Furthermore, by combining the role descriptions of the target objects, the generated first major model instruction becomes more targeted, ensuring that the output target documentation meets the understanding needs of different roles. Therefore, it can automate the generation of application documentation and improve the relevance and accuracy of the generated documentation. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating an embodiment of the method for generating application documentation in this application; Figure 2 This is a schematic diagram of an embodiment of the construction of the first major model instruction in the application specification document generation method of this application; Figure 3 This is a schematic diagram of another embodiment of the method for generating application documentation in this application; Figure 4 This is a schematic diagram of the framework of an embodiment of the application specification document generation device of this application; Figure 5 This is a schematic diagram of the framework of an embodiment of the electronic device of this application; Figure 6 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0011] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0012] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0013] In this paper, the terms "system" and "network" are often used interchangeably. The term "and / or" describes the relationship between related objects, 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 slash " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this paper means two or more.

[0014] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0015] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the method for generating application documentation according to this application. Specifically, it may include the following steps: Step S11: Obtain the domain knowledge base used to support application development.

[0016] In this embodiment of the disclosure, the domain knowledge base includes several metadata structure descriptions. Specifically, the metadata structure descriptions represent the data structures and logical relationships involved in the application development process. These metadata structure descriptions include the associated business logic, interface specifications, and data flow interaction methods in the application building process.

[0017] In one implementation scenario, a domain knowledge base is applied to a low-code application building platform. The target application is built upon this platform. Specifically, low-code application building platforms typically have a visual development environment, allowing developers to quickly build applications by dragging and dropping components and configuring parameters. Specifically, the editor enables visual operations and configuration pages for the application's content, allowing users to drag and drop components, configure components, configure application pages, preview the application, publish the application, and cancel the publication of the application. During this process, the domain knowledge base automatically captures the metadata involved in these operations and transforms it into a parsable, structured description.

[0018] In a specific implementation scenario, the domain knowledge base includes a library of known application templates, a DSL (Domain-Specific Language) use case library, documentation, and metadata structure descriptions known to the low-code application building platform. The metadata structure descriptions include component metadata structure descriptions and application metadata structure descriptions. Components are the basic elements that constitute the UI interface, and can be categorized into four main types based on functional complexity: basic components, layout components, form components, and advanced components. Basic components include input boxes, text boxes, buttons, and dialog boxes. Components possess attributes (configurable parameters, such as component name and title), styles (appearance attributes such as component size, margins, alignment, text, and background), interactive events (component behavior and actions, such as clicks, double-clicks, and loading), data binding (dynamically associating components with data sources, such as displaying database query results in a table), and responsive behavior (automatically updating based on object operations or data changes, such as real-time search filter lists). For ordinary objects, the application in the low-code application building platform has the general meaning of an application program. For platform developers, the application specifically refers to the entity after the developed application is released, i.e., the application's definition data, generally called a SCHEMA. A Domain-Specific Language (DSL) is used to describe the JSON-formatted data structure of a component or application. The application schema mentioned above can also be described as the application DSL data body, which is a hierarchically structured DSL assembled from several component DSLs. An example DSL for a text component is as follows: { "id": "text_1", / / Unique identifier for the text component "name": "text", "description": "This is a text component DSL", "type": "Text", "attribute": { / / Text component attribute configuration "value": "Text content" }, "style": { / / Style configuration for the text component width: 60px "height": "32px" "background-color": "#1c79f4" }, "eventOptions": [{ / / Event configuration for the text component] "name": "When clicked" "type": "click" "actions": [{ / / Reactive behavior for button click events] "name": "Set Text" "type": "setCubeComponentText" "options": [{ "id": "text_1" "value": { "value": "New text content" } }] }] }] } In a specific implementation scenario, after acquiring the domain knowledge base, it needs to be preprocessed to ensure that the metadata structure description can adapt to the subsequent information graph construction requirements. Specifically, the preprocessing process includes operations such as standardizing the format of the metadata structure description, cleaning up redundant data, and annotating key fields.

[0019] Step S12: Parse the code data of the target application based on the metadata structure description to obtain the information graph of the target application and the role description of the target object.

[0020] In this embodiment of the disclosure, the target object is the object to be provided by the documentation to be generated for the target application. The role description of the target object is used to clarify the characteristics and needs of the target audience for the documentation. Specifically, the role description may include information such as the object's scope of responsibilities, technical background, usage scenarios, and functional expectations for the target application.

[0021] In an implementation scenario, the target objects include developers, administrators, and end users. For developers, the documentation may need to focus on code logic, interface contracts, and error handling mechanisms; for administrators, it needs to highlight security policies, access control, and deployment topology; and for end users, it needs to focus on operation steps, descriptions of interface elements, and common problems.

[0022] In a specific implementation scenario, the role description of the target object can be generated based on the target object's role requirements for the application documentation. For example, the requirements for the developer role documentation include: in-depth technical focus, mandatory technical elements, prohibited content, and document output format requirements. In-depth technical focus includes analyzing how the event handling chain conforms to the platform's standard pattern, explaining how the API connector implementation follows the knowledge base specification, and showing a comparison between data mapping rules and the platform's recommended pattern. Mandatory technical elements include interface contracts (describing the API request / response structure standard based on the knowledge base), error handling mechanisms (referring to the platform's default error handling process), component lifecycle (explaining the consistency of value binding implementation with the platform specification), and extension point analysis (providing custom extension suggestions that conform to the platform specification). Prohibited content includes interface operation steps, explanations of business terms, non-technical descriptions, internal implementation details not disclosed by the platform, and non-platform standard implementation methods. Output format requirements include first-level headings (main document title), second-level headings (main chapters), third-level headings (sub-chapter), syntax highlighting for code blocks (e.g., JSON, JavaScript), clear alignment of tables using pipe symbols, ordered / unordered lists, emphasis and bolding for key terms, URL format for links, and sequence diagrams using sequence diagram syntax or clear descriptions.

[0023] In one implementation scenario, the code data of the target application is parsed based on the metadata structure description to obtain an information graph of the target application. Specifically, the information graph is represented in a directed graph format, where nodes represent various entities in the target application, such as components, interfaces, and data flows, and edges represent the relationships between these entities, such as call relationships, dependency relationships, or data transfer paths. The construction process of the information graph includes static analysis and dynamic behavior capture of the code data. Static analysis mainly parses the code structure and comment information to extract key entities and their attributes, with relevant reference data coming from the domain knowledge base. Dynamic behavior capture records the actual interaction logic of the target application or DSL use cases in the domain knowledge base through runtime data, thereby supplementing information that may have been missed by static analysis. The final generated information graph provides a clear and comprehensive logical framework for the generation of target documentation.

[0024] In a specific implementation scenario, the nodes of the infographic can be further subdivided into different categories, such as functional module nodes, data processing nodes, and external interface nodes. Each type of node comes with detailed metadata descriptions to support content extraction and organization during subsequent document generation. Furthermore, the infographic supports multi-level display; objects can choose to view the global logical view or a detailed view of a specific module, helping to meet the differentiated needs of different roles for explanatory documentation.

[0025] In one implementation scenario, the metadata structure description of the target application is retrieved from the domain knowledge base. Based on this target metadata structure description and the target application's code data, a second-level model instruction is constructed. This second-level model instruction instructs the second-level model to analyze the target data of the target application at the target level based on the target metadata structure description, thereby constructing a logically structured data graph. The target level represents the data organization hierarchy of the target application. The output text of the second-level model in response to the second-level model instruction is obtained, serving as the information graph of the target application. This approach, by constructing the information graph through the second-level model, provides more accurate data support for the target documentation.

[0026] It should be noted that the first and second major models in this application may be the same model or different models, and both the first and second major models belong to the category of large language models. Specifically, large language models are deep learning models used to process natural language tasks.

[0027] In a specific implementation scenario, the target hierarchy includes component, process, and data levels. Specifically, the component level focuses on the basic units that make up the application, such as UI elements like buttons and text boxes, and their attribute configurations. The process level focuses on the application's internal business logic and operational steps, describing the complete path of interaction between objects and the system, such as page navigation logic, conditional branches, loop structures, and service call chains. The data level involves the data structures, data flows, and their mapping relationships processed during application operation, such as data source definitions, state variables, data mapping rules, and API interface contracts. This approach, by dividing the target hierarchy, can more accurately extract the core information of the target application and transform it into an information graph suitable for generating documentation.

[0028] In a specific implementation scenario, based on the target application's code data, the analysis yields the first sub-data at the component level, the second sub-data at the process level, and the third sub-data at the data level. Based on the target metadata structure description, the first sub-data, and the first graph construction rules, a first sub-instruction is generated. Similarly, based on the target metadata structure description, the second sub-data, and the second graph construction rules, a second sub-instruction is generated. Finally, based on the first, second, and third sub-instructions, a second major model instruction is obtained through fusion. This approach, by fusing and analyzing data from different levels, can more comprehensively reflect the structure and logical relationships of the target application. Specifically, the first sub-instruction is mainly used to parse relevant information at the component level, such as component attributes, styles, and interaction events. The second sub-instruction focuses on the process level, extracting object operation paths, business logic flow, and service call relationships. The third sub-instruction targets the data level, analyzing core elements such as data flow transmission paths, state variable change patterns, and data mapping rules. These sub-instructions combine the target metadata structure description and corresponding graph construction rules during the generation process to ensure the accuracy and consistency of information extraction.

[0029] In a specific implementation scenario, the first sub-data includes the visualization components contained in the target application and the interaction and association data between the visualization components. The first graph construction rules include: identifying each visualization component as a node of the first graph, using the interaction and association data between the visualization components as the edges of the first graph, and recording the component attributes and states of the visualization components in the first graph.

[0030] In a specific implementation scenario, the second sub-data includes the logical flow and control flow of the target application. The rules for constructing the second graph include: extracting process nodes from the logical flow as nodes of the second graph, marking conditional branches and loop structures in the second graph based on the control flow, and recording API calls and service dependencies of the target application in the second graph.

[0031] In a specific implementation scenario, the third sub-data includes the data entities and data streams of the target application. The third graph construction rules include: identifying data entities and their state variables as nodes of the third graph, constructing the paths of the data streams as edges of the third graph, and recording the data mapping rules of the data entities in the third graph.

[0032] In one implementation scenario, key metadata is extracted from the target application's code data. This key metadata is then used to search the domain knowledge base, yielding a metadata structure description that matches the key metadata. This description serves as the target metadata structure description. This approach, through the extraction and matching of key metadata, can accurately locate the metadata structure description related to the target application in the domain knowledge base, thus providing a reliable foundation for generating the target documentation.

[0033] In a specific implementation scenario, assuming the target application is built on a low-code application platform, the metadata structure descriptions of all components are used as the knowledge base retrieval corpus. Combined with the application DSL or component DSL, and based on retrieval enhancement techniques, the second major model is used to analyze the DSL structural features of the target application, constructing an information graph about the target application at the target level. Existing graph instances from the domain knowledge base can also be added to the second major model instructions. For example, the second major model instructions are as follows: ### Task As a low-code application architecture analysis expert, please use the retrieved DSL metadata structure description knowledge... (Knowledge) and the target application DSL are used to construct a three-layer directed graph information graph (component layer, process layer, data layer) and present it intuitively. Output in directed graph format.

[0034] ### Tagging Specification - [K]: Standard definition in the domain knowledge base - [I]: Instantiation configuration in the target application DSL - [D]: Analytical derivation of relationships / structures ### Infographic Format Requirements Represented using a directed graph, it contains the following elements: 1. **Nodes**: Entities (components, processes, data entities) 2. **Edges**: Relationships (triggering, calling, passing data, dependencies, etc.) 3. **Hierarchical organization**: - Component layer: UI components and their interactions - Process layer: logical flow and control flow - Data layer: Data entities and data flows ### Directed Graph Representation Rules - Node format: "Node ID" [label="Node Name", type="Node Type", properties= {...}] - Edge format: "Source node" -> "Target node" [label="Relationship type", properties={...}] - Hierarchical format: Use subgraph to represent logical layers. - Comment format: [K] Component definition from knowledge base ### Processing Guidelines 1. **Component Layer** - Identify all UI components as nodes - Mark interactive events as edges (e.g., "click → trigger") - Record component properties and state 2. **Process Layer** - Extract the complete event handling chain as a process node - Mark conditional branches and loop structures - Record API calls and service dependencies 3. **Data Layer** - Identify state variables and data entities - Construct the data flow path (e.g., "form input → order entity") - Record data mapping rules ### Key Rules - Prioritize following the standard definitions in the knowledge base - Undefined elements are marked as [EXTENDED] and this can be reasonably inferred. - All derivations ([D]) must have clear logical basis. - Keep relationship descriptions accurate and intuitive ### Example Output / / Component layer "searchInput" [label="search input box", type="Input", properties= {placeholder:"Please enter your search keywords"}] "searchBtn" [label="Search Button", type="Button", properties={text:"Search"] [Scan] "resultTable" [label="Result Table", type="Table", properties={columns:[" ID","Name"]}] "searchInput" -> "searchBtn" [label="Input → Trigger", type="USER_INPUT"] "searchBtn" -> "searchHandler" [label="Click → Trigger Process", type="EVENT_ TRIGGER"] / / Process layer "searchHandler" [label="search processing flow", type="Process"] "searchHandler" -> "executeQuery" [label="Call → Query Service", type=" SERVICE_CALL"] "executeQuery" -> "updateTable" [label="Return → Update Table Data", type=" DATA_UPDATE"] / / Data layer "searchKeyword" [label="searchKeyword", type="StateVariable", properties ={type:"string"}] "searchResults" [label="search results", type="StateVariable", properties= {type:"array"}] "searchInput" -> "searchKeyword" [label="Value→Bound to", type="DATA_ BINDING "searchKeyword" -> "executeQuery" [label="as parameter → passed to", type=" DATA_FLOW"] "executeQuery" -> "searchResults" [label="Response → Mapped to", type="DATA_ MAPPING "searchResults" -> "resultTable" [label="Data Source → Bind to", type=" DATA_BINDING"] ### Current Request {Knowledge} DSL structure data: {DSL} Please output the directed graph representation of the information graph according to the above format.

[0035] In one implementation scenario, when the target application's DSL is very large, it can be extracted page by page to generate information sub-graphs, which are then combined to form a complete application information graph. Specifically, if the target application contains several target pages, the code data of the target application is used to break down the code data into page-level code data for each target page. This page-level code data is then parsed based on the metadata structure description to obtain the corresponding information sub-graph for each target page. Finally, these information sub-graphs are merged to obtain the overall information graph of the target application. For example, the final information graph structure of a search query page consisting of input boxes, buttons, and table components is shown below: { "componentLayer": [ "lcp-input_CsHpDfkH: Input box component, two-way bound to the state variable 'query condition'", "lcp-button_Ma8IV3ZE: Search button, clicking triggers an API call", "lcp-table_cLXUrvdE: Result table, displaying query result data" ], "flowLayer": [ "searchHandler: Click event handler that calls the API connector", "apiConnector_4ifG-HJzKI: Connector id=1954833651549196289, methodCode=e C8J8R1grbhGGEqcWNHqtw59bKjqTbfr", "successHandler: API successfully processed, triggering data binding" ], "dataLayer": [ "searchKeyword (string): Stores the search keywords entered into the object", "searchResults (array): Stores the query results returned by the API", API request parameter mapping: keyword→q API response mapping: body.results → searchResults ] } The above solution, by extracting DSLs in pages and generating information sub-graphs, can effectively address the structured analysis needs of complex applications. Each page-level code data is parsed to form an independent information sub-graph. These sub-graphs not only contain detailed descriptions of the component layer, process layer, and data layer, but also record the interaction logic and data flow relationships within each page, which can reduce the difficulty of generating information graphs for the target application.

[0036] In a specific implementation scenario, to further enhance the practical value of the infographic, a dynamic update mechanism can be introduced. When the code data of the target application changes, the code differences are detected and the corresponding infographic is updated synchronously, thus maintaining consistency between the documentation and the application. For example, when a new page is added or an API call logic is modified, the relevant sub-graphies are regenerated, while the sub-graphies of other unchanged pages are retained to update the overall infographic of the target application.

[0037] Step S13: Based on the domain knowledge base, information graph, and role description, construct the first major model instruction.

[0038] In this embodiment of the disclosure, the first major model instruction is used to instruct the first major model to generate a description document based on the domain knowledge base, which is provided to the target object to understand the target application.

[0039] In one implementation scenario, based on the different requirements of different target objects for the content of application documentation, corresponding role descriptions are obtained. By combining the domain knowledge base, information graph, and role descriptions, prompt words under different roles can be obtained.

[0040] Please see Figure 2 , Figure 2 This is a schematic diagram of an embodiment of the construction of the first major model instruction in the application documentation generation method of this application. For example... Figure 2 As shown, when the target object's roles include developers, administrators, and terminal objects, the first major model instructions from the perspectives of the three roles can be generated based on the domain knowledge base, information graph, and role descriptions, respectively. These instructions are used to instruct the first major model to generate the target specification document.

[0041] In a specific implementation scenario, the target language type can also be incorporated as part of the construction of the primary model instruction. This ensures that the generated documentation conforms to the grammatical rules and expression habits of the target language. Specifically, the primary model instruction is constructed based on the domain knowledge base, information graph, role descriptions, and target language type. The target language type includes, but is not limited to, multiple language options such as Chinese, English, and French, each with its own specific grammatical structure and terminology. Based on this, prompts for different roles are obtained. For example, prompts from the developer's perspective are shown below: ### Character Commands You are a senior low-code platform development expert, and your task is to generate technical documentation based on application infographics. The target audience is the developers responsible for application maintenance and expansion.

[0042] ### Language Parameters - language: {lang} (support: zh-CN, en-US, ja-JP, fr-FR, de-DE, es-ES) - content_style: technical (technical document style) - output_format: markdown ### Key References for the Knowledge Base {knowledge_refs} ### Key Components of Infographics {relevant_sections} ### Document Requirements 1. **In-depth Technology Focus**: - Analyze how the event handling chain conforms to the platform's standard pattern. - Explain how the API connector implementation conforms to the knowledge base specification. - Show a comparison between data mapping rules and platform recommendation patterns. 2. **Required technical elements:** - Interface Contract: A standard for describing API request / response structure based on a knowledge base. - Error handling mechanism: Refer to the platform's default error handling process - Component lifecycle: Explaining the consistency between value binding implementation and platform specifications. - Extension point analysis: Provides custom extension suggestions that conform to platform specifications. 3. **Prohibited Contents:** - Interface operation steps - Explanation of Business Terminology - Non-technical description - Undisclosed internal implementation details of the platform - Non-platform standard implementation methods 4. **Markdown output format requirements:** - Level 1 Heading: # Heading (Document Main Heading) - Second-level heading: ## Heading (Main Chapter) - Third-level heading: ### Heading (Sub-section) - Code blocks: Use syntax highlighting (e.g., json, javascript) - Tables: Use pipe formatting for clear alignment. - Lists: Using ordered / unordered lists - Emphasis: **Bold** indicates key terms. - Link: [Description](URL) format - Sequence diagram: Use Markdown sequence diagram syntax or a clear description - Language: Select the corresponding language based on the {lang} parameter. ### Document Output Requirements Generate chapters in the following Markdown format: 1. # Architecture Overview (including sequence diagram description) 2. ## API Connector Details 3. ## Data Binding Implementation Principles 4. ## Extended Suggestions For example, the prompt from the administrator's perspective is as follows: ### Character Commands You are a low-code platform system administrator whose task is to generate deployment and management instructions based on application information graphs. South. The target audience is administrators responsible for application operation and configuration.

[0043] ### Language Parameters - language: {lang} (support: zh-CN, en-US, ja-JP, fr-FR, de-DE, es-ES) - content_style: operational (operation guide style) - output_format: markdown ### Key References for the Knowledge Base {knowledge_refs} ### Key Components of Infographics {relevant_sections} ### Document Requirements 1. **System Management Focus**: - Identify security critical points and compare them against knowledge base security standards - Analyze the consistency between the deployment topology and the platform's recommended architecture. - Assess whether the access control implementation complies with platform specifications. 2. **Required Management Elements**: - Security strategy: Refer to best practices for authentication mechanisms in the knowledge base. - Deployment checklist: Based on platform standard environment configuration - Monitoring metrics: Use the monitoring items recommended by the platform. - Backup strategy: Follow the platform data management guidelines - Upgrade path: Refer to the platform compatibility matrix 3. **Prohibited Contents:** - Code implementation details - Development and debugging techniques - Object Manipulation Guide 4. **Markdown output format requirements:** - First-level heading: # Heading - Second-level heading: ## Heading - Third-level heading: ### Heading - Tables: Used for configuration items, environment variables, etc. - Task list: - [ ] Used to check the checklist - Note block: > **Note** Use the syntax > **Note** - Warning block: > **Warning** Use the syntax ">**Warning** - Code block: Used for command-line examples - Step-by-step guide: 1. First step 2. Second step - Language: Select the corresponding language based on the {lang} parameter. ### Document Output Requirements Generate chapters in the following Markdown format: 1. # Security Configuration Guide 2. # Deployment Checklist 3. # Monitoring and Maintenance Recommendations 4. # Troubleshooting Manual For example, the terminal object's perspective prompt is as follows: ### Character Commands You are an object training expert, tasked with generating an object operation guide based on an application infographic. Target audience: They are business personnel who use the application.

[0044] ### Language Parameters - language: {lang} (support: zh-CN, en-US, ja-JP, fr-FR, de-DE, es-ES) - content_style: user_friendly (object-friendly style) - output_format: markdown ### Key References for the Knowledge Base {knowledge_refs} ### Key Components of Infographics {relevant_sections} ### Document Requirements 1. **Object Experience Focus**: - Transform technical components into visible object elements that conform to the platform's UI specifications. - Refer to the platform's standard process description for object interaction - Feedback processed based on error copywriting guidelines in the knowledge base 2. **Required object elements:** - Operation steps: Follow the platform's standard operation guide format. - Interface element descriptions: using platform standard terminology - Frequently Asked Questions: Refer to the platform's standard FAQ library - Expected result description: Conforms to the platform's UI feedback guidelines - Quick Operation Tips: Platform-Based Shortcut Key Guide 3. **Prohibited Contents:** - Code snippet - API endpoints - Any technology ID or parameter - Non-platform standard UI description - Content that conflicts with the platform's style guidelines 4. **Markdown output format requirements:** - First-level heading: # Heading - Second-level heading: ## Heading - Third-level heading: ### Heading - Icon: √ Used for visual cues - Important Note: > **Tip:** Use quote blocks + icons - Warning: > **Note:** Use quote blocks + icons. - Step-by-step guide: 1. First step 2. Second step - Screen description: Use **bold** to indicate UI elements. - Frequently Asked Questions: Usage > - **Question** Format - Language: Select the corresponding language based on the {lang} parameter, maintaining a friendly tone. ### Document Output Requirements Generate chapters in the following Markdown format: 1. # Quick Start Guide 2. # Detailed Operating Procedures 3. # Frequently Asked Questions 4. # Best Practice Tips Step S14: Obtain the output text of the first large model responding to the first large model instruction, and use it as the target description document provided to the target object.

[0045] In one implementation scenario, to ensure that the generated target documentation accurately meets the needs of different roles, the first major model performs in-depth analysis and content generation based on the input instructions. This process relies not only on the richness of the domain knowledge base but also on the accuracy of the information graph and the clarity of the role descriptions. For example, from a developer's perspective, the generated technical documentation will focus on code implementation details, API call logic, and extension point analysis; while from an administrator's perspective, it will emphasize the presentation of security policies, deployment configurations, and monitoring metrics.

[0046] In one implementation scenario, the output text is optimized based on the target language. For example, when Chinese is selected as the target language, the system automatically adjusts the terminology and sentence structure to suit the reading habits of Chinese readers; while when English is selected, it follows the international standards of technical documents to ensure the accuracy of technical terminology and grammatical structure.

[0047] In one implementation scenario, the primary model is based on an open-source large model. After training with training corpora, the fine-tuned large model is used as the primary model. Specifically, the training corpora include: multilingual technical document alignment corpora (such as English-Chinese API documentation), manually written documentation for low-code platforms, and description sample sets from different perspectives. The primary model generation process can employ a constrained decoding strategy to force the model to adhere to specific rules or restrictions during text generation, ensuring that the output meets preset conditions, such as grammatical correctness, factual accuracy, keyword inclusion, and structured formatting, thus ensuring terminological consistency and factual accuracy.

[0048] In a specific implementation scenario, after obtaining the output text of the first model's response to its instructions, the text content of the output text is parsed to adjust it. Specifically, the document structure of the output text is highlighted, and the output text with the highlighted document structure is converted into the target format as the target application's documentation. For example, after parsing the text content, the original structure and style are preserved, and heading levels, list indentation, and code block highlighting are processed. Simultaneously, the rendering of mathematical formulas, tables, and references is supported. Then, a conversion engine converts the output text content into professional formats such as PDF, Word, and HTML to obtain the target application document. This approach ensures that the generated documentation not only meets the needs of the specific role in terms of content but also conforms to the expectations of the target audience in terms of format and language expression.

[0049] In a specific implementation scenario, after obtaining the target specification document provided to the target object, the validated target specification document is stored in the domain knowledge base.

[0050] Please see Figure 3 , Figure 3 This is a schematic diagram of another embodiment of the application documentation generation method of this application. For example... Figure 3 As shown, after obtaining the DSL of the target application, the DSL of the target application is parsed by the DSL parser. It is then vectorized by combining the domain knowledge base consisting of the application template library, DSL use cases, existing documentation, component metadata structure description, and application metadata structure description. The parsing results of the DSL parser are analyzed based on the knowledge in the vectorized knowledge base to generate an information graph of the target application. The first major model instruction is constructed by using the information graph, the domain knowledge base, and the role description. The first major model outputs text based on the first major model instruction. The output text that passes the verification is stored in the domain knowledge base. Finally, the output text is converted by the conversion engine to obtain the target documentation of the target application.

[0051] The above solution involves acquiring a domain knowledge base to support application development. This knowledge base contains several metadata structure descriptions. Based on these metadata structure descriptions, the code data of the target application is parsed to obtain an information graph of the target application, as well as role descriptions of target objects. Target objects are the objects to be provided in the documentation to be generated for the target application. Based on the domain knowledge base, information graph, and role descriptions, a first major model instruction is constructed. This first major model instruction instructs the first major model to generate documentation for the target objects to understand the target application based on the domain knowledge base. The output text of the first major model in response to the first major model instruction is obtained and serves as the target documentation provided to the target objects. On one hand, the domain knowledge base, as support for analyzing the target application, provides foundational knowledge for application parsing and information graph construction, and enables automated generation of the target documentation through a large language model. On the other hand, using the information graph of the target application as reference data for generating the target documentation provides more logically clear data related to the target application during the documentation generation process, thereby improving the accuracy of the generated documentation. Furthermore, by combining the role descriptions of the target objects, the generated first major model instruction becomes more targeted, ensuring that the output target documentation meets the understanding needs of different roles. Therefore, it can automate the generation of application documentation and improve the relevance and accuracy of the generated documentation.

[0052] Please see Figure 4 , Figure 4 This is a schematic diagram of the framework of an embodiment of the application documentation generation device of this application. Figure 4 As shown, the application documentation generation device 40 includes an acquisition module 41, a parsing module 42, a construction module 43, and an output module 44. The acquisition module 41 is used to acquire a domain knowledge base to support application construction; wherein, the domain knowledge base contains several metadata structure descriptions. The parsing module 42 is used to parse the code data of the target application based on the metadata structure descriptions to obtain the information graph of the target application, and to acquire the role description of the target object; wherein, the target object is the object to be provided by the documentation to be generated for the target application. The construction module 43 is used to construct a first major model instruction based on the domain knowledge base, the information graph, and the role description; wherein, the first major model instruction is used to instruct the first major model to generate a documentation for the target object to understand the target application based on the domain knowledge base. The output module 44 is used to acquire the output text of the first major model in response to the first major model instruction, as the target documentation provided to the target object.

[0053] Therefore, the application documentation generation device 40 acquires a domain knowledge base to support application construction. This domain knowledge base contains several metadata structure descriptions. Based on these metadata structure descriptions, the device parses the target application's code data to obtain an information graph of the target application, and acquires role descriptions of target objects. Target objects are the objects to be provided in the documentation to be generated for the target application. Based on the domain knowledge base, information graph, and role descriptions, a first major model instruction is constructed. This first major model instruction instructs the first major model to generate documentation for the target object to understand the target application based on the domain knowledge base. The device acquires the output text of the first major model responding to the first major model instruction, which serves as the target documentation provided to the target object. On one hand, the domain knowledge base, as support for analyzing the target application, provides fundamental knowledge for the analysis and information graph construction of the target application, and enables automated generation of the target documentation through a large language model. On the other hand, using the information graph of the target application as reference data for generating the target documentation provides more logically clear data related to the target application during the documentation generation process, thereby improving the accuracy of the generated documentation. Furthermore, by combining the role descriptions of the target objects, the generated first major model instruction becomes more targeted, ensuring that the output target documentation meets the understanding needs of different roles. Therefore, it can automate the generation of application documentation and improve the relevance and accuracy of the generated documentation.

[0054] In some disclosed embodiments, the construction module 43 further includes a retrieval module (not shown) for retrieving metadata structure descriptions of the target application from the domain knowledge base, as the target metadata structure description; the construction module 43 also includes a second instruction construction module (not shown) for constructing a second major model instruction based on the target metadata structure description and the code data of the target application; wherein, the second major model instruction is used to instruct the second major model to analyze the target data of the target application at the target level based on the target metadata structure description, so as to construct a data graph with a logical structure, and the target level represents the data organization level of the target application; the construction module 43 also includes a second output module (not shown) for obtaining the output text of the second major model in response to the second major model instruction, as the information graph of the target application.

[0055] In some disclosed embodiments, the target hierarchy includes a component hierarchy, a process hierarchy, and a data hierarchy. The second instruction construction module (not shown) also includes a hierarchy data analysis module (not shown), used to analyze the code data of the target application to obtain the first sub-data of the corresponding component hierarchy, the second sub-data of the corresponding process hierarchy, and the third sub-data of the corresponding data hierarchy. The second instruction construction module (not shown) also includes a sub-instruction construction module (not shown), used to generate a first sub-instruction based on the target metadata structure description, the first sub-data, and the first graph construction rules; generate a second sub-instruction based on the target metadata structure description, the second sub-data, and the second graph construction rules; and generate a third sub-instruction based on the target metadata structure description, the third sub-data, and the third graph construction rules. The second instruction construction module (not shown) also includes an instruction fusion module (not shown), used to fuse the first, second, and third sub-instructions to obtain a second major model instruction.

[0056] In some disclosed embodiments, the first sub-data includes the visualization components contained in the target application and the interaction association data between the visualization components. The first graph construction rules include: identifying each visualization component as a node of the first graph, using the interaction association data between the visualization components as edges of the first graph, and recording the component attributes and states of the visualization components in the first graph. The second sub-data includes the logical flow and control flow of the target application. The second graph construction rules include: extracting the process nodes in the logical flow as nodes of the second graph, marking the conditional branches and loop structures in the second graph based on the control flow, and recording the API calls and service dependencies of the target application in the second graph. The third sub-data includes the data entities and data flows of the target application. The third graph construction rules include: identifying the data entities and the state variables of the data entities as nodes of the third graph, constructing the paths of the data flows as edges of the third graph, and recording the data mapping rules of the data entities in the third graph.

[0057] In some disclosed embodiments, the retrieval module (not shown) further includes a metadata extraction module (not shown) for extracting key metadata based on the code data of the target application; the retrieval module (not shown) further includes a knowledge base retrieval module (not shown) for retrieving the domain knowledge base based on the key metadata to obtain a metadata structure description that matches the key metadata, which serves as the target metadata structure description.

[0058] In some disclosed embodiments, when the target application contains several target pages, the parsing module 42 further includes a page splitting module (not shown), used to split the code data of the target application to obtain the page-level code data corresponding to each target page; the parsing module 42 further includes a sub-graph generation module (not shown), used to parse the page-level code data based on the metadata structure description to obtain the information sub-graph of the corresponding target page; the parsing module 42 further includes a sub-graph fusion module (not shown), used to fuse the information sub-graph to obtain the information graph of the target application.

[0059] In some disclosed embodiments, in the application documentation generation apparatus 40, after obtaining the output text of the first major model responding to the first major model instruction, the document structure of the output text is highlighted, and the output text after highlighting the document structure is converted into a target format as the target documentation for the target application; and / or, the domain knowledge base is applied to the low-code application building platform, and the target application is built on the low-code application building platform; and / or, the roles of the target object include developers, administrators, and terminal objects; and / or, the first major model instruction is constructed based on the domain knowledge base, information graph, role description, and target language type; and / or, after obtaining the target documentation provided to the target object, the verified target documentation is stored in the domain knowledge base.

[0060] Please see Figure 5 , Figure 5 This is a schematic diagram of a framework of an embodiment of the electronic device of this application. The electronic device 50 includes at least a memory 51 and a processor 52 coupled to each other. The memory 51 stores at least program instructions, and the processor 52 is used to execute the program instructions to implement the steps in any of the above-described application documentation generation method embodiments. For details, please refer to the foregoing disclosed embodiments, which will not be repeated here. It should be noted that the specific type of the electronic device 50 is not limited here.

[0061] Specifically, processor 52 controls itself and memory 51 to implement the steps in any of the above-described application documentation generation method embodiments. Processor 52 may also be referred to as a CPU (Central Processing Unit). Processor 52 may be an integrated circuit chip with signal processing capabilities. Processor 52 may also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 52 may be implemented using integrated circuit chips.

[0062] In the above scheme, electronic device 50 acquires a domain knowledge base to support application construction. This domain knowledge base contains several metadata structure descriptions. Based on these metadata structure descriptions, the code data of the target application is parsed to obtain an information graph of the target application, as well as role descriptions of target objects. The target objects are the objects to be provided in the documentation to be generated for the target application. Based on the domain knowledge base, information graph, and role descriptions, a first major model instruction is constructed. This first major model instruction instructs the first major model to generate documentation for the target object to understand the target application based on the domain knowledge base. The output text of the first major model in response to the first major model instruction is acquired and used as the target documentation for the target object. On one hand, the domain knowledge base, as support for analyzing the target application, provides foundational knowledge for the parsing of the target application and the construction of the information graph, and enables automated generation of the target documentation through a large language model. On the other hand, using the information graph of the target application as reference data for generating the target documentation provides more logically clear data related to the target application during the document generation process, thereby improving the accuracy of the generated documentation. Furthermore, by combining the role descriptions of the target objects, the generated first major model instruction becomes more targeted, ensuring that the output target documentation meets the understanding needs of different roles. Therefore, it can automate the generation of application documentation and improve the relevance and accuracy of the generated documentation.

[0063] Please see Figure 6 , Figure 6This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. The computer-readable storage medium 60 stores program instructions 61 that can be executed by a processor. The program instructions 61 are used to implement the steps in any of the above-described embodiments of the application documentation generation method.

[0064] In the above scheme, the computer-readable storage medium 60 acquires a domain knowledge base to support application construction. The domain knowledge base contains several metadata structure descriptions. Based on these metadata structure descriptions, the code data of the target application is parsed to obtain an information graph of the target application, and role descriptions of target objects are acquired. Target objects are the objects to be provided in the documentation to be generated for the target application. Based on the domain knowledge base, information graph, and role descriptions, a first major model instruction is constructed. This first major model instruction instructs the first major model to generate documentation for the target object to understand the target application based on the domain knowledge base. The output text of the first major model in response to the first major model instruction is acquired and used as the target documentation for the target object. On one hand, the domain knowledge base, as support for analyzing the target application, provides basic knowledge for the parsing of the target application and the construction of the information graph, and enables the automated generation of the target documentation through a large language model. On the other hand, using the information graph of the target application as reference data for generating the target documentation provides more logically clear data related to the target application during the document generation process, thereby improving the accuracy of the generated documentation. Furthermore, by combining the role descriptions of the target objects, the generated first major model instruction becomes more targeted, ensuring that the output target documentation meets the understanding needs of different roles. Therefore, it can automate the generation of application documentation and improve the relevance and accuracy of the generated documentation.

[0065] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0066] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0067] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0068] 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 units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0069] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0070] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for generating application documentation, characterized in that, include: Obtain a domain knowledge base to support application development; wherein the domain knowledge base contains several metadata structure descriptions; Based on the metadata structure description, the code data of the target application is parsed to obtain the information graph of the target application and the role description of the target object; wherein, the target object is the object to be provided in the documentation to be generated by the target application; Based on the domain knowledge base, the information graph, and the role description, a first major model instruction is constructed; wherein, the first major model instruction is used to instruct the first major model to generate a description document based on the domain knowledge base for the target object to understand the target application; Obtain the output text of the first large model in response to the first large model instruction, and use it as a target description document provided to the target object.

2. The method according to claim 1, characterized in that, The step of parsing the code data of the target application based on the metadata structure description to obtain the information graph of the target application includes: Retrieve the metadata structure description of the target application from the domain knowledge base, and use it as the target metadata structure description; Based on the target metadata structure description and the code data of the target application, a second major model instruction is constructed; wherein, the second major model instruction is used to instruct the second major model to analyze the target data of the target application at the target level based on the target metadata structure description, so as to construct a data graph with a logical structure, wherein the target level represents the data organization level of the target application; The output text of the second large model in response to the second large model instruction is obtained and used as the information graph of the target application.

3. The method according to claim 2, characterized in that, The target hierarchy includes a component hierarchy, a process hierarchy, and a data hierarchy. The second major model instruction, constructed based on the target metadata structure description and the target application's code data, includes: Based on the code data of the target application, the first sub-data corresponding to the component level, the second sub-data corresponding to the process level, and the third sub-data corresponding to the data level are obtained through analysis. Based on the target metadata structure description, the first sub-data, and the first graph construction rules, a first sub-instruction is generated; based on the target metadata structure description, the second sub-data, and the second graph construction rules, a second sub-instruction is generated; and based on the target metadata structure description, the third sub-data, and the third graph construction rules, a third sub-instruction is generated. The second major model instruction is obtained by fusing the first sub-instruction, the second sub-instruction, and the third sub-instruction.

4. The method according to claim 3, characterized in that, The first sub-data includes the visualization components contained in the target application and the interaction association data between the visualization components. The first graph construction rules include: identifying each of the visualization components as nodes of the first graph, using the interaction association data between the visualization components as edges of the first graph, and recording the component attributes and states of the visualization components in the first graph. The second sub-data includes the logical flow and control flow of the target application. The second graph construction rules include: extracting the process nodes in the logical flow as nodes of the second graph, marking the conditional branches and loop structures in the second graph based on the control flow, and recording the API calls and service dependencies of the target application in the second graph. The third sub-data includes the data entities and data streams of the target application. The third graph construction rules include: identifying the data entities and their state variables as nodes of the third graph, constructing the paths of the data streams as edges of the third graph, and recording the data mapping rules of the data entities in the third graph.

5. The method according to claim 2, characterized in that, The retrieval of the metadata structure description of the target application in the domain knowledge base, as the target metadata structure description, includes: Key metadata is extracted based on the code data of the target application. The domain knowledge base is retrieved based on the key metadata to obtain the metadata structure description that matches the key metadata, which is then used as the target metadata structure description.

6. The method according to claim 1, characterized in that, When the target application contains several target pages, the step of parsing the code data of the target application based on the metadata structure description to obtain the information graph of the target application includes: Based on the code data of the target application, page-level code data corresponding to each target page is obtained; Based on the metadata structure description, the page-level code data is parsed to obtain the information sub-graph corresponding to the target page; Based on the information sub-graph, the information graph of the target application is obtained by fusion.

7. The method according to claim 1, characterized in that, After obtaining the output text of the first large model in response to the first large model instruction, the document structure of the output text is highlighted, and the output text after highlighting the document structure is converted into the target format as the target description document of the target application; And / or, the domain knowledge base is applied to the low-code application building platform, and the target application is built on the low-code application building platform; And / or, the roles of the target object include developer, administrator, and terminal object; And / or, based on the domain knowledge base, the information graph, the role description, and the target language type, a first major model instruction is constructed; And / or, after obtaining the target specification document provided to the target object, the verified target specification document is stored in the domain knowledge base.

8. An application specification document generation device, characterized in that, include: The acquisition module is used to acquire a domain knowledge base to support application development; wherein, the domain knowledge base contains several metadata structure descriptions; The parsing module is used to parse the code data of the target application based on the metadata structure description to obtain the information graph of the target application and to obtain the role description of the target object; wherein, the target object is the object to be provided in the documentation to be generated by the target application; A construction module is used to construct a first major model instruction based on the domain knowledge base, the information graph, and the role description; wherein, the first major model instruction is used to instruct the first major model to generate a description document based on the domain knowledge base for the target object to understand the target application; The output module is used to obtain the output text of the first large model in response to the first large model instruction, and to provide it as a target description document to the target object.

9. An electronic device, characterized in that, It includes at least a memory and a processor, wherein the memory stores at least program instructions, and the processor is used to execute the program instructions to implement the application documentation generation method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The system stores program instructions that can be executed by a processor, the program instructions being used to implement the application documentation generation method according to any one of claims 1 to 8.

Images