Interface document automatic generation method and device, electronic equipment and storage medium

Abstract

The application relates to an interface document automatic generation method and device, electronic equipment and a storage medium. The method comprises the following steps: obtaining a structure library and an encapsulation function by analyzing project source code, and constructing a function mapping table according to parameters in each encapsulation function and structure fields; based on the analyzed project source code, locating processing functions and interface information corresponding to each interface path, and determining a response expression finally returned by the processing functions; if the response expression is an encapsulation function call, injecting a parameter type of an actual parameter in the response expression into a structure field of the corresponding encapsulation function according to the function mapping table, and combining the structure library to perform recursive analysis on each field after the parameter type is injected, so as to obtain a field type tree; calling a large language model to perform semantic description on the field type tree and context information of each field, so as to form an enhanced version of a data structure; and integrating the interface information and the enhanced version of the data structure, so as to generate an interface document. The application improves the accuracy of interface document generation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for automatically generating interface documentation. Background Technology

[0002] In modern software engineering, API (API) interface documentation serves as the core contractual carrier for front-end and back-end interaction and system integration, and is a crucial foundation for ensuring efficient R&D collaboration and standardized system governance. Complete API documentation typically covers core elements such as API paths and HTTP methods, request parameter definitions, response structure definitions, error codes and explanations, sample data, and constraints.

[0003] API documentation is crucial throughout the entire development lifecycle: During front-end and back-end collaboration, it avoids repeated communication due to inconsistencies in interface field definitions; during testing and quality assurance, it supports test case generation, mock service design, and interface return verification; during operation and governance, it provides a basis for interface gateway route registration, authentication policy verification, and compatibility auditing; and during engineering automation, it drives automatic SDK generation, mock tool construction, contract test execution, and API change impact analysis. Therefore, the completeness, accuracy, and consistency between API documentation and code implementation directly determine the efficiency of development collaboration and the level of system governance.

[0004] However, existing methods for automatically generating API documentation based on static analysis have certain shortcomings, which are reflected in the following two aspects: First, existing static analysis tools can only mechanically extract field names and basic data types from the source code, failing to truly reflect the business meaning of the fields, resulting in low practical value of the documentation. Second, business applications widely employ multi-layered encapsulation functions to encapsulate HTTP response output logic. Traditional static analysis tools cannot penetrate the call chain of these encapsulation functions, leading to problems such as missing fields, incorrect types, and chaotic nesting levels in the generated documentation, severely deviating from the actual implementation logic of the code. Therefore, the API documentation generated by existing solutions generally suffers from inaccuracies. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for automatically generating interface documentation to solve the problem of inaccurate interface documentation generation.

[0006] Firstly, this application provides a method for automatically generating interface documentation, the method comprising:

[0007] By parsing the project source code, the structure library and encapsulated functions in the project source code are obtained, and a function mapping table is constructed based on the parameters and structure fields in each of the encapsulated functions. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters.

[0008] Based on the parsed project source code, locate the processing functions and interface information corresponding to each interface path, and determine the response expression finally returned by the processing function;

[0009] If the response expression is a function call, then according to the function mapping table, the parameter types of the actual parameters in the response expression are injected into the structure fields of the corresponding encapsulated function, and the fields after the parameter types are injected are recursively parsed in conjunction with the structure library to obtain a field type tree;

[0010] The large language model is invoked to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure.

[0011] Integrate the interface information and the enhanced data structure to generate interface documentation.

[0012] Optionally, by parsing the project source code, the structure library and encapsulated functions in the project source code can be obtained, including:

[0013] Traverse the function bodies and structure information of each loaded package in the project source code;

[0014] Summarize the field names, data types, and nesting relationships of all structure information to generate a structure library;

[0015] If the function body satisfies the following conditions, the function corresponding to the function body is marked as a wrapper function: the parameter list of the function body contains a type or pointer type related to the request context; the function body contains a call statement for serializing response data, and the call object of the call statement is an instance parsed as a type related to the request context; the number of return values ​​of the function body is greater than a preset threshold, and the type of the first or only return value is a named structure or a named structure pointer type.

[0016] Optionally, based on the parsed project source code, the processing functions and interface information corresponding to each interface path are located, and the response expression finally returned by the processing function is determined to include:

[0017] Based on the framework's routing registration rules, the interface information and processing functions corresponding to each interface path are parsed from the parsed project source code. The interface information includes the interface route, request method, and request parameters.

[0018] Identify the response output class expression that was last executed by the processing function, wherein the response output class expression is a response output statement or a function call expression.

[0019] If the response output class expression is a response output statement, then the second parameter in the response output statement is extracted as the response expression to be parsed;

[0020] If the response output class expression is a function call expression, then the function call expression is used as the response expression to be parsed.

[0021] Optionally, if the response expression is a function call, then according to the function mapping table, the parameter types of the actual parameters in the response expression are injected into the structure fields of the corresponding encapsulated function, and the fields after the parameter types are injected are recursively parsed using the structure library to obtain a field type tree including:

[0022] If the response expression is a function call, the target function is matched from the function mapping table using the package name and function name of the response expression as indexes, and the structure template in the structure field of the target function is extracted.

[0023] Identify the actual parameters and parameter types in the response expression, and inject the parameter types into the field positions in the structure template that are mapped to the actual parameters;

[0024] Based on the field names, data types, and nesting relationships in the structure library, the fields after the injected parameter types are recursively decomposed until all nested types of the fields are decomposed into atomic types.

[0025] Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

[0026] Optionally, after determining the response expression ultimately returned by the processing function, the method further includes:

[0027] If the response expression is a structure instance, then the structure instance is recursively decomposed according to the field names, data types and nesting relationships in the structure library until all nested types of the structure instance are decomposed into atomic types;

[0028] Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

[0029] Optionally, if the response expression is a structure instance, then the structure instance is recursively decomposed based on the field names, data types, and nesting relationships in the structure library until all nested types of the structure instance are decomposed into atomic types, including:

[0030] If the response expression is a structure instance, then the structure library is queried using the structure type of the structure instance as an index to determine the target structure information corresponding to the structure instance;

[0031] Extract the top-level field of the structure instance based on the target structure information, wherein the top-level field is the field directly declared at the outermost layer of the structure instance;

[0032] If the data type of the top-level field is an atomic type, then the name of the top-level field and its corresponding atomic type are retained;

[0033] If the top-level field is a complex type, then continue to query the internal composition information of the complex type in the structure library, and decompose the sub-fields contained in the top-level field layer by layer;

[0034] Repeatedly perform data type determination and decomposition operations on the subfields of the top-level field until all top-level fields of the structure instance are converted to atomic types.

[0035] Optionally, a large language model is invoked to semantically describe the field type tree and the contextual information of each field in the project source code, forming an enhanced data structure including:

[0036] Convert the field type tree into a standardized data structure;

[0037] Extract the context information of each field from the project source code, wherein the context information includes: field name, format tag, function call chain context, the structure to which it belongs, and the package path to which it belongs;

[0038] The field type tree of the standardized data structure and the context information of each field are input into the large language model to generate a business semantic description of each field;

[0039] The business semantic description is embedded into the corresponding description field of the standardized data structure to form the enhanced data structure.

[0040] Secondly, this application provides an interface documentation automatic generation device, the device comprising:

[0041] The parsing module is used to obtain the structure library and encapsulated functions in the project source code by parsing the project source code, and to construct a function mapping table based on the parameters and structure fields in each of the encapsulated functions. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters.

[0042] The determination module is used to locate the processing function and interface information corresponding to each interface path based on the parsed project source code, and to determine the response expression finally returned by the processing function.

[0043] The injection module is used to inject the parameter types of the actual parameters in the response expression into the structure fields of the corresponding encapsulated function according to the function mapping table if the response expression is an encapsulated function call, and to recursively parse each field after injecting the parameter types in combination with the structure library to obtain a field type tree;

[0044] The processing module is used to call the large language model to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure;

[0045] The generation module is used to integrate the interface information and the enhanced data structure to generate interface documentation.

[0046] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus.

[0047] Fourthly, this application also provides a computer storage medium storing computer-executable instructions for executing the interface documentation automatic generation method described in any of the preceding claims of this application.

[0048] The technical solutions provided in this application have the following advantages compared with the prior art:

[0049] First, by analyzing the project source code, a structure library capable of recursively decomposing to atomic types is constructed. Additionally, encapsulated functions are identified, and a function mapping table is established between the parameters of these encapsulated functions and the fields of the returned structure. Then, the processing functions and interface information corresponding to each interface path are determined, and the final response expression in the processing function is extracted to ensure that all processing revolves around the actual response data of the interface. If the response expression is an encapsulated function call, the function mapping table can be used to directly locate the fuzzy field corresponding to the actual parameter, injecting the actual parameter type into this fuzzy field. This breaks the type masking problem caused by multiple layers of encapsulation, restoring the originally fuzzy arbitrary type to a clear business data type. Subsequently, the injected structure is recursively parsed using the structure library, decomposing the nested structure layer by layer until all fields are expanded to atomic types, forming a complete and accurate field type tree. Next, the context information of each field is collected and input into a large language model along with the field type tree. The large language model then derives and generates natural language descriptions that fit the actual use based on the business scenario, forming a semantically enhanced data structure. Finally, this enhanced data structure is integrated with the previously collected interface information to generate interface documentation. This application can clearly define business data types even in multi-layered encapsulation scenarios, and also ensures that the interface documentation has clear business semantics, thereby improving the accuracy of interface documentation generation. Attached Figure Description

[0050] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0053] Figure 1 A flowchart illustrating an automatic interface documentation generation method provided in this application embodiment;

[0054] Figure 2 This application provides an overall flowchart of an interface documentation automatic generation method.

[0055] Figure 3 A schematic diagram of an interface documentation automatic generation device provided in an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0059] The following will describe in detail an interface documentation automatic generation method provided in this application embodiment, taking a terminal application as an example, with specific implementation details. Figure 1 As shown, the specific steps are as follows:

[0060] Step 101: By parsing the project source code, obtain the structure library and encapsulated functions in the project source code, and construct a function mapping table based on the parameters and structure fields in each encapsulated function. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters.

[0061] Step 102: Based on the parsed project source code, locate the processing functions and interface information corresponding to each interface path, and determine the final response expression returned by the processing function;

[0062] Step 103: If the response expression is a function call, then according to the function mapping table, inject the parameter types of the actual parameters in the response expression into the structure fields of the corresponding encapsulated function, and recursively parse each field after injecting the parameter types using the structure library to obtain the field type tree;

[0063] Step 104: Call the large language model to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure;

[0064] Step 105: Integrate interface information and enhanced data structure to generate interface documentation.

[0065] In step 101, the terminal starts the project source code parsing process. First, it loads the complete project code files and compilation environment configuration information. Then, it filters out test packages and third-party dependency packages through static analysis technology, retaining only the effective code structure of the project itself.

[0066] During the process of traversing valid code, the terminal simultaneously completes two core tasks: First, it collects the attribute information of all structures, including the code package to which each structure belongs, field names, field data types, and nesting relationships between fields. Whether it is a single-level or multi-level nested structure, it is fully included. This information together constitutes the structure library. The structure library not only marks the original type of each field, such as basic type, structure type, and cross-package type, but also retains the internal structure of complex types, such as field details of nested structures and element types of arrays, providing complete type definition support and clear nesting link guidance for subsequent field decomposition.

[0067] On the other hand, the terminal filters out the encapsulation functions in the project source code used for unified processing of interface responses. These encapsulation functions all belong to specific code packages in the project source code, and the terminal synchronously records the package path and package name of each encapsulation function. Then, the terminal performs in-depth analysis on each encapsulation function to clarify the binding relationship between the parameters of the encapsulation function and the fields of the returned structure. Then, using the package name and the encapsulation function name as indexes, this binding relationship is organized into a function mapping table. Each entry in the function mapping table clearly records the association between the parameters of the corresponding encapsulation function and the structure fields. The structure fields are of fuzzy type, that is, the actual business data is hidden in the generic field type, for example, the generic field type is interface{}. Traditional tools can only identify that the business data is of arbitrary type and cannot penetrate the encapsulation to see the real data structure inside.

[0068] For example, the encapsulated function is SuccessResponse(data→Response.Payload), where SuccessResponse is the function name, data is the parameter, Response.Payload is the structure field corresponding to data, Response is the structure template, and Payload is the field in the structure template whose type is originally ambiguous.

[0069] In step 102, based on the parsed project source code, the terminal locates the corresponding processing function for each interface path, such as the Handler function, according to the framework's routing registration rules, for example, the framework's routing registration rule is router.GET(" / user", handler). The processing function, as the core business logic carrier of the interface, is responsible for receiving the interface request, executing business processing, and returning the response result. The processing function can be a standard format function or a business-defined function. The terminal analyzes the code logic within the processing function body and extracts the response expression. The response expression can be a directly parsable struct instance, such as User{ID:1,Name:"test"}, or it can be a wrapped function call, such as SuccessResponse(c,user).

[0070] While locating the processing function, the terminal will simultaneously collect interface information, which includes the interface path, request method, and request parameters. Request parameters include query parameters, path parameters, request header parameters, and request body parameters. This information together constitutes the basic interaction contract of the interface.

[0071] In step 103, the terminal first determines the type of the response expression. If the response expression is a direct structure instance, the terminal will call the constructed structure library and recursively parse the structure instance according to the field definition and nesting relationship of the structure, decomposing the nested substructures, arrays, mappings and other complex types layer by layer until all fields are decomposed into atomic types that cannot be further decomposed, such as strings, ints, and booleans.

[0072] If the response expression is a function call, such as `SuccessResponse(c, user)`, the terminal will use the package name and the name of the encapsulated function in the response expression as indexes to query the constructed function mapping table. This retrieves the mapping relationship between the parameters of the encapsulated function and the fields of the returned structure. In the static phase without runtime dependencies, the terminal injects the parameter type of the actual parameter `user` in the response expression (`*user`) into the corresponding field `Payload` of the returned structure, directly replacing the original ambiguous type such as generic or interface. Originally, the structure field `Payload` only displayed as an arbitrary type due to multiple layers of encapsulation; after injecting the actual parameter type, it is clearly identified as a `User` structure, successfully uncovering the hidden data structure. Subsequently, the terminal also calls the structure library to recursively parse the injected fields, ultimately integrating all field and type information to generate a field type tree containing a complete field hierarchy and clearly defined types. This completely solves the problem of structure loss caused by the inability of traditional tools to penetrate multiple layers of encapsulation.

[0073] When recursively parsing struct instances or injected fields, the terminal can quickly query the type attributes of any field through the struct library: if the field is an atomic type such as string, integer, or boolean, it is directly confirmed and retained; if the field is a struct type, its internal fields are further decomposed layer by layer according to the struct field attributes recorded in the struct library; if the field is a complex type such as array or mapping, it is also recursively parsed through the element type and key-value type recorded in the struct library until all levels of fields are decomposed into atomic types that cannot be further decomposed, ensuring that the parsing process has a clear basis and no type omissions.

[0074] Furthermore, if the response expression references a struct from an external dependency package, such as a struct in a third-party package or a submodule package of the project, the dependency management mechanism of the Go dependency management module will be used to automatically locate the path and metadata of the external package, load its complete struct information, and ensure that cross-package structs and internal project structs are recursively decomposed in a consistent manner. This avoids parsing breaks or type omissions caused by cross-package structs, and ensures that the final generated field type tree is complete and accurate.

[0075] In step 104, the terminal first converts the generated field type tree into a standardized data structure. This standardized data structure contains basic metadata such as field name, data type, whether it is required, and default value, which conforms to the industry's common interface description specifications, ensuring the universality and standardization of the data structure.

[0076] The terminal collects context information for each field from the project source code. The context information includes the field name, format tags, the structure to which it belongs, the path of the code package to which it belongs, and the function call chain context. The rich context information can fully restore the business application scenario of the field and provide sufficient basis for the accurate semantic inference of the large language model.

[0077] The terminal inputs a standardized data structure's field type tree along with collected contextual information into a large language model. The large language model performs in-depth analysis and semantic inference based on this input data, combining the field's application scenario, its associated business module, and calling logic to generate a semantic description tailored to the actual business. For example, for the field AliActiveStatus, the generated semantic description is whether the payment order is active on the set platform, with true indicating activation and false indicating inactivation. This generated business semantic description is precisely embedded into the corresponding field of the standardized data structure, forming an enhanced data structure.

[0078] This application adds business-level semantic information to the interface documentation by using contextual information, making the business meaning of each field clear and explicit in the documentation. This not only solves the problem that traditional documentation can only present the field format and cannot explain the business purpose, but also makes the generated interface documentation more accurate at the business level. Technical personnel can quickly understand the purpose of the fields without additional communication, thus improving the efficiency of R&D collaboration.

[0079] In step 105, the terminal fully integrates the generated enhanced data structure with the collected interface information. The interface information covers the interface path, request method, and various request parameters, while the enhanced data structure includes field type information and business semantic descriptions. The integration of these two elements forms a complete interface description. The terminal formats the integrated information according to the OpenAPI specification, generating a standardized and comprehensive interface document. This document includes both the basic interaction rules of the interface (e.g., the interface path is / user / info and the request method is POST) and detailed business semantic descriptions and type information for each field, achieving a dual completeness in both syntax structure and business meaning.

[0080] The terminal uses automated tools to synchronize the generated interface documentation to the team collaboration platform, ensuring that all collaborators can access the latest version of the documentation in a timely manner. When the project source code undergoes changes such as the addition of fields, type changes, or structural adjustments, the terminal can automatically re-execute steps 101 to 105 to quickly generate updated interface documentation and synchronize it to the collaboration platform. This forms a complete automated closed loop of source code changes, automatic document updates, and platform synchronization, ensuring a high degree of consistency between documentation and code implementation and reducing manual maintenance costs.

[0081] In this application, the project source code is first analyzed to construct a structure library that supports recursive decomposition to atomic types. Furthermore, encapsulated functions are identified, and a function mapping table is established between the parameters of these encapsulated functions and the fields of the returned structure. Then, the processing functions and interface information corresponding to each interface path are determined, and the final response expression in the processing function is extracted to ensure that all processing revolves around the actual response data of the interface. If the response expression is an encapsulated function call, the function mapping table can be used to directly locate the fuzzy type field corresponding to the actual parameter, injecting the actual parameter type into this fuzzy type field. This breaks the type masking problem caused by multi-layer encapsulation, restoring the originally fuzzy arbitrary type to a clear business data type. Subsequently, the injected structure is recursively parsed using the structure library, decomposing the nested structure layer by layer until all fields are expanded to atomic types, forming a complete and accurate field type tree. Next, the context information of each field is collected and input into a large language model along with the field type tree. The large language model then derives and generates natural language descriptions that fit the actual use based on the business scenario, forming a semantically enhanced data structure. Finally, this enhanced data structure is integrated with the previously collected interface information to generate interface documentation. This application can clearly define business data types even in multi-layered encapsulation scenarios, and also ensures that the interface documentation has clear business semantics, thereby improving the accuracy of the interface documentation.

[0082] As an optional implementation, by parsing the project source code, the structure library and encapsulated functions in the project source code are obtained, including:

[0083] Step S11: Traverse the function bodies and structure information of each loaded package in the project source code;

[0084] Step S12: Summarize the field names, data types, and nesting relationships of all structure information to generate a structure library;

[0085] Step S13: If the function body meets the following conditions, then the function corresponding to the function body is marked as a wrapper function: the parameter list of the function body contains a type or pointer type related to the request context; the function body contains a call statement for serializing the response data, and the call object of the call statement is an instance that is parsed as a type related to the request context; the number of return values ​​of the function body is greater than a preset number threshold, and the type of the first or only return value is a named structure or a named structure pointer type.

[0086] The terminal uses a preset loading tool to load the project source code. By enabling a loading mode that includes an Abstract Syntax Tree (AST), Types, and Syntax, it extracts these three core types of information from the source code. Simultaneously, it combines compilation environment configuration information and optional filtering rules to ensure the loaded project source code is complete and meets subsequent analysis requirements. Subsequently, the terminal filters the loaded packages according to preset rules and an ignore list in the optional configuration items, removing test packages and third-party dependencies, retaining only the code packages developed within the project itself. This ultimately forms an effective code structure focused on core business logic, preventing irrelevant code from interfering with the subsequent parsing process.

[0087] The terminal iterates through each loaded package in the valid code structure, comprehensively scanning all functions (including ordinary functions and methods) and structure information within each package. Simultaneously, it makes judgments based on the package path, skipping built-in functions and third-party library functions to ensure that the analysis object is only the code elements defined by the project itself. During the traversal, the terminal filters out encapsulated functions containing request context parameters and outputting response data from the function bodies according to preset conditions.

[0088] The encapsulated function must meet three core judgment rules.

[0089] 1. The parameter list of the function body contains types or pointer types related to the request context. For example, if the request context is gin.Context, the related types or pointer types are *gin.Context or context.Context. This determination can be achieved through type compatibility comparison methods or by comparing fully qualified names, and it supports plug-in configuration without hard-depending on the Gin framework.

[0090] 2. The function body contains call statements related to the serialization and output of response data such as ctx.JSON or ctx.JSONP, and the calling object of the call statements is an instance that is parsed as a request context related type. For example, by parsing the abstract syntax tree of the function body to find the SelectorExpr node, it is ensured that the type corresponding to SelectorExpr.X of the node can be parsed as *gin.Context or context.Context and other request context related types.

[0091] 3. The number of function return values ​​is greater than a preset threshold. For example, the number of function return values ​​is not less than 1, and the type of the first or only return value is a named structure or a pointer to a named structure, that is, the type is types.Named or *types.Pointer points to the type is types.Named.

[0092] For the selected encapsulated functions, the terminal establishes a mapping relationship between parameter names and fields in the returned structure. For example, it maps the function's `data` parameter to the `Payload` field of the returned `Response` structure: `data → Response.Payload`. Subsequently, the function signature, which includes information such as the function location, parameter-field mapping relationship, and returned structure template, is written into a global function mapping table and indexed using the package and function name as unique identifiers.

[0093] During the traversal of each loaded package within the valid code structure, the terminal synchronously collects all structure information. This includes structures defined within the project's internal code packages, as well as basic information related to cross-package structures required for subsequent parsing. The summarized structure information covers the field names, data types, and nesting relationships between fields for each structure. Whether it's a simple single-level structure or a multi-level nested structure containing substructures, arrays, and mappings, its hierarchical relationships and internal composition are recorded in detail.

[0094] As an optional embodiment, in step 102, based on the parsed project source code, the processing functions and interface information corresponding to each interface path are located, and the response expression finally returned by the processing function is determined, including:

[0095] Step S21: Based on the framework routing registration rules, parse the interface information and processing functions corresponding to each interface path from the parsed project source code. The interface information includes the interface route, request method, and request parameters.

[0096] Step S22: Identify the response output class expression executed last in the processing function, where the response output class expression is a response output statement or a function call expression.

[0097] Step S23: If the response output class expression is a response output statement, then extract the second parameter from the response output statement as the response expression to be parsed;

[0098] Step S24: If the response output class expression is a wrapper function call expression, then the wrapper function call expression is used as the response expression to be parsed.

[0099] In step S21, the terminal relies on the framework's route registration rules to perform in-depth analysis of the route configuration-related code in the effective code structure. During the analysis, the terminal accurately identifies key information in each route registration statement, including the interface route, request method, and the processing function bound to that interface route. At the same time, the terminal also collects request parameters, including various interaction parameters such as query parameters, path parameters, request header parameters, and request body parameters.

[0100] In step S22, after locating the processing function, the terminal will analyze the code logic within the function body to pinpoint the expression corresponding to the final response data returned by the interface to the front end. Since the processing function may contain multiple intermediate logic checks or temporary response outputs, the terminal will traverse the abstract syntax tree of the function body to trace the code execution flow and identify the last executed response output expression. This is because the last response output is the valid response returned by the interface in its normal or final state, ensuring that subsequent parsing yields the actual response data structure of the interface.

[0101] These response output expressions are mainly divided into two categories: one is a direct response output statement, such as c.JSON(http.StatusOK,...), and the other is a function call expression, such as SuccessResponse(c,user)). Both contain the business data that the interface will eventually return and are the objects for subsequent response structure parsing.

[0102] In step S23, if the identified response output expression is a direct response output statement, the terminal will further extract the key parameters from the statement as the response expression to be parsed. This type of response output statement is common in the Go language's Gin framework, such as User{ID:1,Name:"test"}. In its syntax, the first parameter is the HTTP response status code, used to inform the frontend of the status of the request processing result, not the actual business data; the second parameter is the actual business data that the interface wants to return to the frontend, which may be a struct literal, variable reference, or dictionary type, etc. The structure of this data is precisely what needs to be parsed later. Therefore, the terminal will extract the second parameter of the response output statement as the response expression to be parsed, ensuring that subsequent parsing focuses on the actual business data structure.

[0103] In step S24, if the identified response output expression is a wrapper function call expression, the terminal will directly use this wrapper function call expression as the response expression to be parsed. These wrapper functions are used in the project to uniformly process interface responses, such as SuccessResponse(c, user) or APIResponseOK(c, orderList). The first parameter is the request context c, and the second parameter is the actual parameter, such as user corresponding to user information and orderList corresponding to order list data. Business data needs to be associated with the final response structure through the non-mapping relationship between the function's parameters and the returned structure fields. For example, user corresponds to Response.Payload. If only the second parameter user or orderList is extracted, the association information of the response structure template Response corresponding to this business data will be lost, and it will be impossible to know which field of which structure the actual parameter should be injected into. Therefore, the entire wrapper function call expression must be retained to query the function mapping table by function name to find the corresponding structure template and parameter mapping rules.

[0104] This application addresses the issue of traditional tools easily overlooking request parameter types by locating interface information based on framework routing rules, ensuring the integrity of the interface interaction contract. Furthermore, it avoids interference from intermediate temporary responses by identifying the last executed response output expression in the processing function, guaranteeing the authenticity and validity of the response expression. Moreover, it employs differentiated processing methods for response output statements and encapsulated function call expressions, extracting the second parameter and using it directly as the response expression, respectively. This adapts to simple scenarios with direct structure returns and is compatible with widely used encapsulated function call scenarios in projects, overcoming the limitations of traditional tools in adapting to diverse response formats and ensuring a high degree of consistency between the response structure in the interface documentation and the code implementation from the source.

[0105] As an optional embodiment, in step 103, if the response expression is an encapsulated function call, the fields in the response expression are determined according to the function mapping table, and each field is recursively parsed using the structure library to obtain a field type tree including:

[0106] Step S31: If the response expression is a wrapper function call, then the target wrapper function is obtained from the function mapping table by using the package name and wrapper function name of the response expression as indexes, and the structure template in the structure field of the target wrapper function is extracted.

[0107] Step S32: Identify the actual parameters and parameter types in the response expression, and inject the parameter types into the field positions in the structure template that are mapped to the actual parameters;

[0108] Step S33: Based on the field names, data types, and nesting relationships in the structure library, recursively decompose the fields after injecting parameter types until all nested types of the fields are decomposed into atomic types;

[0109] Step S34: Based on the hierarchical dependency relationship between the subfields corresponding to each atomic type after decomposition, construct a field type tree containing all subfields.

[0110] In step S31, if the response expression is a function call, such as SuccessResponse(c, user), the terminal will use the package name and the name of the encapsulated function as a unique index, for example, using the package name + SuccessResponse as the unique index, to query the pre-built function mapping table. The function mapping table stores the complete signature information of all identified encapsulated functions, including the package path to which the function belongs, the mapping relationship between parameters and return structure fields, and the corresponding structure template. This structure template is the basic data structure returned by the encapsulated function, typically containing fixed fields and fuzzy type fields used to carry business data, such as a payload of type interface{}. After the terminal accurately matches the target encapsulated function through the index, it will directly extract its corresponding structure template, such as the Response structure, providing a framework for subsequent injection of actual parameter types.

[0111] In step S32, the terminal further parses the parameter list of the response expression to accurately identify the actual business parameters and their specific parameter types. For example, in the response expression SuccessResponse(c, user), the business parameter is the user parameter, and the parameter type is the *User structure. The terminal combines the mapping relationship between parameters and structure fields recorded in the function mapping table, such as the data parameter corresponding to the Payload field of the Response structure. The terminal injects the actual parameter type *User into the corresponding field position of the structure template, directly replacing the original ambiguous type interface{} of that field. This step breaks the type masking caused by multi-layer encapsulation, transforming the originally uncertain template field into a clearly defined business field.

[0112] In step S33, after injecting the actual parameter type, the terminal calls the structure library and recursively decomposes the fields after the parameter type is injected, based on the field names, data types, and nesting relationships of all structures recorded in the structure library. During the decomposition process, the fixed fields of the structure template itself are parsed first, such as the Code of Response being of type int and Message being of type string. For fields with injected specific types, such as the Payload field being injected with type *User, the definition of the User structure in the structure library is queried, and its internal fields are decomposed, such as the ID of User being of type int and Name being of type string. If the field is an array, mapping, or cross-package structure, the terminal will further expand the array element type, mapping key-value type, or load the complete definition of the cross-package structure through the Go dependency management module and decompose it synchronously. The entire process continues until all levels of fields are decomposed into atomic types that cannot be further decomposed, such as strings, integers, and booleans, ensuring that no nested structures or type information is omitted.

[0113] In step S34, after recursively decomposing all fields, the terminal will analyze the hierarchical dependencies between the subfields corresponding to each atomic type, that is, restore the hierarchy of each field in the response structure. For example, Response is the top-level structure, Payload is its next-level field, and User's ID and Name are subfields of Payload. Based on this hierarchical relationship, the terminal constructs a field type tree containing all subfields. This type tree clearly presents the complete structure of the interface response in a tree structure: the top level is the structure template encapsulating the function return, the next level contains fixed fields and fields of injected business types, the next level contains nested fields within business fields, and so on, up to all atomic type fields. The field type tree not only fully records the name and data type of each field, but also clarifies the hierarchical relationship between fields, providing structured data support for subsequent conversion into standardized data structures and semantic enhancement.

[0114] For example, the structure template for the encapsulated function SuccessResponse is Response, and the function mapping table records the Response.Payload field corresponding to the data parameter. The original type of Payload is interface{}.

[0115] The interface response expression is SuccessResponse(c, order), where the actual parameter order is of type *Order structure. The *Order structure contains OrderID (string), Amount (float64), and Address (*Address, where Address contains City (string) and Detail (string)).

[0116] 1. Query the function mapping table using package name + SuccessResponse as index, match the target encapsulated function, and extract the struct template Response; 2. Identify the actual parameter order as *Order, inject the Response.Payload field according to the mapping relationship, and replace the original interface{} type; 3. Recursively decompose the struct library: Response's Code (int) and Message (string) are directly atomic types; Payload (*Order) is decomposed into OrderID (string), Amount (float64), and Address (*Address); Address is further decomposed into City (string) and Detail (string), all of which are atomic types; 4. Construct a field type tree with the hierarchy Response→Code / Message / Payload→OrderID / Amount / Address→City / Detail, fully presenting the nested structure of the response and all field types.

[0117] This application employs a progressive logic of matching encapsulated functions, injecting actual types, recursively decomposing structures, and constructing a type tree from fields. It precisely associates the constructed function mapping table with the target encapsulated function through index matching and extracting structure templates, providing a clear basis for type restoration. Furthermore, by injecting actual parameter types into fuzzy fields of the template, it breaks the type masking problem caused by multi-layered encapsulation, solving the problem that traditional tools cannot see the true business structure behind fuzzy types. Simultaneously, relying on a structure library for recursive decomposition, combined with the Go dependency management module loading cross-package structure definitions, it ensures complete parsing of complex scenarios such as nested structures, arrays, and cross-package types, avoiding type omissions or parsing breaks. Finally, by constructing a complete type tree containing field hierarchy dependencies, it structures and systematizes fragmented type information, ensuring the accuracy, completeness, and hierarchical clarity of the response structure in subsequent interface documentation, solving the document structure errors or missing information problems caused by insufficient encapsulation penetration and weak complex type parsing capabilities in traditional tools.

[0118] As an optional implementation, after determining the response expression finally returned by the processing function, the method further includes: if the response expression is a structure instance, then recursively decompose the structure instance according to the field names, data types and nesting relationships in the structure library, until all nested types of the structure instance are decomposed into atomic types; based on the hierarchical dependency relationships between the subfields corresponding to each atomic type after decomposition, construct a field type tree containing all subfields.

[0119] If the response expression is a direct struct instance, such as User{ID:1,Name:"test"}, the terminal will use the type of the struct instance as an index to query the struct library. For example, using the User struct as an index, it will accurately obtain the complete information of the struct, including the names, data types, format tags, and nesting relationships between fields.

[0120] Based on the basic information provided by the struct library, the terminal initiates a recursive decomposition process: First, it parses the top-level fields of the struct instance. For fields that are atomic types, such as strings, integers, and booleans, their types are directly marked and preserved. For nested sub-struct fields, such as the Address field in User, it continues to query the definition of the Address struct in the struct library and decomposes its internal fields, such as City and Detail. For array (such as []Order) or mapping (such as map[string]Product) type fields, it further parses the element types of the array and the key-value types of the mapping. If the element type or key-value type is still a complex type, such as a struct or a cross-package type, it continues to recursively decompose until all levels of fields are restored to atomic types that cannot be further decomposed, thus completely avoiding the problem of nested structure omissions or parsing breaks.

[0121] After recursively decomposing all fields, the terminal systematically organizes the hierarchical dependencies between the subfields corresponding to each atomic type. This means restoring the hierarchical position of each subfield within the original struct instance. For example, User is the top-level struct, ID and Name are top-level fields, Address is a top-level nested field, and Address.City and Address.Detail are second-level subfields. Based on this hierarchy, the terminal constructs a field type tree containing all subfields. This type tree clearly presents the complete hierarchical architecture of the interface response in a tree structure. It not only records basic metadata such as the name, data type, and JSON tags of each subfield but also clarifies the parent-child hierarchical relationships between fields, ensuring that the subsequently generated interface documentation accurately reproduces the actual response structure of the struct instance.

[0122] This application provides a schematic diagram of the overall process for automatically generating interface documentation, such as... Figure 2As shown, it includes the following content.

[0123] Phase 1: Global preprocessing and encapsulation function modeling.

[0124] Technical objective: Extract struct information and encapsulated functions from the project code, and build a struct library and function mapping table.

[0125] Enter your content.

[0126] Project source code (Go module): Contains all .go files in the project;

[0127] Compilation environment configuration information: available for loading by the packages.Load tool;

[0128] Optional configuration options: maximum recursion depth, ignore package / directory list, large language model server endpoint, etc.

[0129] Specific steps.

[0130] 1. Loading Packages and Type Information: The project is loaded using the official Go language toolkit. The enabled loading modes include abstract syntax tree, type information (Types, used to identify the data type of variables / fields), and syntax structure (Syntax, used to verify code syntax standards). It also supports custom filtering rules through configuration options to automatically remove test packages and third-party dependency packages, retaining only the core business code packages developed by the project itself.

[0131] 2. Traverse functions and structures within the package: For each loaded business code package, traverse all functions (including ordinary functions and methods) and structure information within the package one by one; based on package path judgment, skip built-in functions and third-party library functions, and focus on custom code elements of the project.

[0132] 3. Encapsulation function determination: Perform the following determination on the traversed functions, and mark them as encapsulation functions if the conditions are met.

[0133] The function's parameter list includes request context-related types such as the Gin framework context pointer type and the general context type (supports plug-in extensions to adapt to other frameworks, does not force dependency on the Gin framework, and allows switching the adapted context type through configuration).

[0134] The function body contains call statements related to the serialization and output of response data such as ctx.JSON or ctx.JSONP, and the calling object of the call statements is an instance that is parsed into a request context-related type;

[0135] The function returns at least one value, and the first or only return value is of type named structure or named structure pointer.

[0136] 4. Construct function mapping tables and structure libraries.

[0137] For encapsulated functions, parse their return structure template and establish a mapping relationship from parameter names in the function body to fields in the return structure. For example, the data parameter is mapped to the Payload field of the Response structure. The function signature, which contains information such as the package to which the function belongs, the function name, the mapping relationship, and the return structure template, is uniquely identified by the package name + function name and stored in the global function mapping table.

[0138] 5. Summarize the information of all structures (including cross-package structures), including the field names, data types, format tags, and nesting relationships between fields for each structure (completely record single-level or multi-level nesting), and generate a structure library.

[0139] Output results: Structure library (containing complete information on all custom and cross-package structures), function mapping table (containing function mapping relationships and returned structure templates).

[0140] Phase Two: Interface Information Collection and Response Expression Extraction.

[0141] Technical objective: Associate API interface paths with corresponding processing functions (Handler functions), extract the final response expression of the interface, and extract interface information.

[0142] Specific steps.

[0143] 1. Route parsing and Handler location: Based on the Gin framework's route registration rules, scan the abstract syntax tree of the project's source code to identify route mapping relationships; extract the interface path (e.g., " / user / info"), request method (e.g., GET, POST) and request parameters of each route, and locate the processing function (e.g., GetUserInfo, CreateOrder) bound to that route.

[0144] 2. Response output expression identification: By delving into the function body and traversing the abstract syntax tree to trace the code execution flow, the response output expression executed last is identified. This type of expression is divided into two categories: one is a direct response output statement (such as c.JSON(http.StatusOK,...)), and the other is a function call expression (such as SuccessResponse(c,user)).

[0145] 3. Response Expression Extraction: If it is a direct response output statement, such as User{ID:1,Name:"test"}, extract the second parameter of the statement as the response expression to be parsed. The first parameter is the HTTP status code, which is only used to inform the request processing status and does not contain business data. If it is a function call expression, such as SuccessResponse(c,user), directly use the call expression as the response expression to be parsed.

[0146] Output results: Response expressions and interface information for each interface.

[0147] Phase 3: Recursive type parsing and structure expansion.

[0148] Technical goal: To penetrate multi-layered encapsulation and nested structures, restore the true data type of the interface response, and generate a complete field type tree.

[0149] Specific steps.

[0150] 1. Categorization and processing of response expressions:

[0151] If the response expression to be parsed is a direct struct instance, such as User{ID:1,Name:"test",Address:Address{City:"Beijing"}}, the struct library will be called directly to begin parsing.

[0152] 2. If it is a function call expression, use the package name and the name of the encapsulated function as indexes to query the function mapping table built in Phase 1, match the target encapsulated function and extract its return structure template, such as the Response structure, which contains fields such as Code, Message, and Payload.

[0153] 3. Actual Parameter Type Injection: In the case of encapsulated function call scenarios, parse the parameter list of the response expression, identify the actual business parameters and parameter types; based on the mapping relationship between parameters and structure fields recorded in the function mapping table, inject the specific parameter type of the actual parameter into the corresponding field position of the structure template, replacing the original fuzzy type of the field.

[0154] 4. Recursive decomposition and cross-package support: Based on the struct library, recursively decompose fields after injection or direct struct instances.

[0155] Top-level atomic type fields (strings, integers, booleans, etc.) are directly retained;

[0156] For complex types such as nested structures, arrays, and maps, the parsing is performed layer by layer (e.g., the array []Order is parsed to parse the element type Order, and the map [string]Product is parsed to parse the key-value type).

[0157] If a field is a cross-package struct type, the complete definition of the cross-package struct is loaded through the Go dependency management module, and recursively decomposed synchronously until all levels of fields are restored to atomic types that cannot be further decomposed.

[0158] 5. Field Type Tree Construction: Analyze the hierarchical dependencies between subfields of all atomic types. For example, Response is the top-level structure, Payload is its next-level field, and User's ID and Name are subfields of Payload. Construct a field type tree containing all subfields, clarifying field names, data types, nesting relationships, and other information.

[0159] Output: A complete field type tree (including type information and hierarchical relationships for all fields).

[0160] Phase 4: Enhanced data structure construction and semantic enhancement.

[0161] Technical goal: To convert the field type tree into a standardized data structure, generate business semantic descriptions through a large language model, and form an enhanced data structure.

[0162] Specific steps.

[0163] 1. Standardized Format Conversion: The field type tree generated in Phase 3 is converted into a standardized data structure (JSON Schema) that conforms to the industry-standard OpenAPI specifications. This format includes meta-information such as field name, data type, whether it is required, default value, format tags, and field constraints (such as string length and numerical range) to ensure the universality and standardization of the data structure.

[0164] 2. Field Context Extraction: Deeply extract the context information of each field from the project source code, including: field name (e.g., AliActiveStatus), format tag (JSONTag, e.g., ali_active_status), the name of the structure it belongs to (e.g., PaymentResponse), the path of the package it belongs to (e.g., github.com / example / service / order), the function call chain context (e.g., the response logic of the OrderService.GetPaymentStatus interface for this field), and auxiliary information such as code snippets and example assignments surrounding the field definition.

[0165] 3. Generate business semantic descriptions using a large language model: Input standardized data structures and extracted field context information into the large language model, and guide the model to focus on business scenarios for semantic inference through preset prompts; the large language model generates accurate and easy-to-understand natural language descriptions based on field names, business modules, call chain logic, and other information.

[0166] 4. Create an enhanced data structure: The business semantic description generated by the large language model is accurately embedded into the description fields of the corresponding fields in the standardized data structure, forming an enhanced data structure that combines grammatical standardization and business readability.

[0167] Output: Enhanced data structure.

[0168] Phase 5: Document output and platform synchronization.

[0169] Technical goal: Integrate all information to generate standard interface documentation and automatically synchronize it to the collaboration platform to ensure that the documentation and code are consistent in real time.

[0170] Specific steps.

[0171] 1. Interface Documentation Integration and Generation: The enhanced data structure obtained in Phase 4 is integrated with the interface information (interface path, request method, request parameters, etc.) collected in Phase 2 to generate a complete interface document that conforms to the OpenAPI specification. The document includes core content such as interface overview, request body definition, response structure, field description, sample data, and error code description, meeting the needs of front-end and back-end collaboration, testing and verification, etc.

[0172] 2. Automatic synchronization to the collaboration platform: By calling the collaboration platform's API through tools such as YApi-MCP (Model Context Protocol), the generated complete interface documentation is automatically pushed to the platform to complete the creation or updating of the documentation; after synchronization is completed, a team notification can be triggered to ensure that relevant personnel can obtain the latest documentation in a timely manner, and achieve real-time synchronization of documentation and code changes.

[0173] Output: Interface documentation conforming to the OpenAPI specification.

[0174] This application also provides an interface documentation automatic generation device, such as... Figure 3 As shown, the device includes:

[0175] The parsing module 301 is used to obtain the structure library and encapsulated functions in the project source code by parsing the project source code, and to construct a function mapping table based on the parameters and structure fields in each encapsulated function. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters.

[0176] The determination module 302 is used to locate the processing functions and interface information corresponding to each interface path based on the parsed project source code, and to determine the final response expression returned by the processing function.

[0177] The injection module 303 is used to inject the parameter types of the actual parameters in the response expression into the structure fields of the corresponding encapsulated function according to the function mapping table if the response expression is an encapsulated function call, and to recursively parse each field after injecting the parameter types in combination with the structure library to obtain the field type tree.

[0178] Processing module 304 is used to call the large language model to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure.

[0179] Module 305 is used to integrate interface information and enhanced data structures to generate interface documentation.

[0180] Optionally, the parsing module 301 is used for:

[0181] Traverse the function bodies and structure information of each loaded package in the project source code;

[0182] Summarize the field names, data types, and nesting relationships of all structure information to generate a structure library;

[0183] If the function body meets the following conditions, the function corresponding to the function body will be marked as a wrapper function: the parameter list of the function body contains a type or pointer type related to the request context; the function body contains a call statement for serializing the response data, and the call object of the call statement is an instance that is parsed as a type related to the request context; the number of return values ​​of the function body is greater than a preset number threshold, and the type of the first or only return value is a named structure or a named structure pointer type.

[0184] Optionally, the determining module 302 is used for:

[0185] Based on the framework's routing registration rules, the interface information and processing functions corresponding to each interface path are parsed from the parsed project source code. The interface information includes the interface route, request method, and request parameters.

[0186] Identify the response output class expression executed last in the processing function, where the response output class expression is either a response output statement or a function call expression.

[0187] If the response output class expression is a response output statement, then the second parameter of the response output statement is extracted as the response expression to be parsed;

[0188] If the response output class expression is a function call expression, then the function call expression will be used as the response expression to be parsed.

[0189] Optionally, the injection module 303 is used for:

[0190] If the response expression is a function call, the target function is matched from the function mapping table using the package name and function name of the response expression as indexes, and the structure template in the structure field of the target function is extracted.

[0191] Identify the actual parameters and parameter types in the response expression, and inject the parameter types into the field positions in the structure template that correspond to the actual parameters;

[0192] By combining the field names, data types, and nesting relationships in the structure library, the fields after the injected parameter types are recursively decomposed until all nested types of the fields are decomposed into atomic types.

[0193] Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

[0194] Optionally, the device is also used for:

[0195] If the response expression is a struct instance, then the struct instance is recursively decomposed based on the field names, data types, and nesting relationships in the struct library until all nested types of the struct instance are decomposed into atomic types.

[0196] Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

[0197] Optionally, the device is also used for:

[0198] If the response expression is a structure instance, then the structure library is queried using the structure type of the structure instance as the index to determine the target structure information corresponding to the structure instance;

[0199] Extract the top-level fields of the structure instance based on the target structure information. The top-level fields are the fields directly declared at the outermost level of the structure instance.

[0200] If the data type of the top-level field is an atomic type, then the name of the top-level field and its corresponding atomic type are retained;

[0201] If the top-level field is a complex type, continue querying the internal structure information of the complex type in the structure library, and disassemble the subfields contained in the top-level field layer by layer;

[0202] Repeatedly perform data type determination and decomposition operations on the subfields of the top-level field until all top-level fields of the structure instance are converted to atomic types.

[0203] Optionally, the processing module 304 is used for:

[0204] Convert the field type tree into a standardized data structure;

[0205] Extract the context information of each field from the project source code. The context information includes: field name, format tags, function call chain context, the structure to which it belongs, and the package path to which it belongs.

[0206] The standardized data structure field type tree and the context information of each field are input into the large language model to generate a business semantic description of each field;

[0207] The business semantic description is embedded into the corresponding description field of the standardized data structure to form an enhanced data structure.

[0208] like Figure 4 As shown, this application provides an electronic device including a processor 401, a communication interface 402, a memory 403, and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.

[0209] Memory 403 is used to store computer programs.

[0210] In one embodiment of this application, when the processor 401 executes the program stored in the memory 403, it implements the interface documentation automatic generation method provided in any of the foregoing method embodiments.

[0211] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the interface documentation automatic generation method provided in any of the foregoing method embodiments.

[0212] The 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.

[0213] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0214] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0215] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for automatically generating interface documentation, characterized in that, The method includes: By parsing the project source code, the structure library and encapsulated functions in the project source code are obtained, and a function mapping table is constructed based on the parameters and structure fields in each of the encapsulated functions. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters. Based on the parsed project source code, locate the processing functions and interface information corresponding to each interface path, and determine the response expression finally returned by the processing function; If the response expression is a function call, then according to the function mapping table, the parameter types of the actual parameters in the response expression are injected into the structure fields of the corresponding encapsulated function, and the fields after the parameter types are injected are recursively parsed in conjunction with the structure library to obtain a field type tree; The large language model is invoked to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure. Integrate the interface information and the enhanced data structure to generate interface documentation; This includes calling a large language model to semantically describe the field type tree and the contextual information of each field in the project source code, forming an enhanced data structure, including: Convert the field type tree into a standardized data structure; Extract the context information of each field from the project source code, wherein the context information includes: field name, format tag, function call chain context, the structure to which it belongs, and the package path to which it belongs; The field type tree of the standardized data structure and the context information of each field are input into the large language model to generate a business semantic description of each field; The business semantic description is embedded into the corresponding description field of the standardized data structure to form the enhanced data structure.

2. The method according to claim 1, characterized in that, By analyzing the project source code, the structure library and encapsulated functions in the project source code are obtained as follows: Traverse the function bodies and structure information of each loaded package in the project source code; Summarize the field names, data types, and nesting relationships of all structure information to generate a structure library; If the function body satisfies the following conditions, the function corresponding to the function body is marked as a wrapper function: the parameter list of the function body contains a type or pointer type related to the request context; the function body contains a call statement for serializing response data, and the call object of the call statement is an instance parsed as a type related to the request context; the number of return values ​​of the function body is greater than a preset threshold, and the type of the first or only return value is a named structure or a named structure pointer type.

3. The method according to claim 1, characterized in that, Based on the parsed project source code, the processing functions and interface information corresponding to each interface path are located, and the response expressions finally returned by the processing functions are determined to include: Based on the framework's routing registration rules, the interface information and processing functions corresponding to each interface path are parsed from the parsed project source code. The interface information includes the interface route, request method, and request parameters. Identify the response output class expression that was last executed by the processing function, wherein the response output class expression is a response output statement or a function call expression. If the response output class expression is a response output statement, then the second parameter in the response output statement is extracted as the response expression to be parsed; If the response output class expression is a function call expression, then the function call expression is used as the response expression to be parsed.

4. The method according to claim 1, characterized in that, If the response expression is a function call, then according to the function mapping table, the parameter types of the actual parameters in the response expression are injected into the structure fields of the corresponding encapsulated function. The structure library is then used to recursively parse each field after the parameter types are injected, resulting in a field type tree including: If the response expression is a function call, the target function is matched from the function mapping table using the package name and function name of the response expression as indexes, and the structure template in the structure field of the target function is extracted. Identify the actual parameters and parameter types in the response expression, and inject the parameter types into the field positions in the structure template that are mapped to the actual parameters; Based on the field names, data types, and nesting relationships in the structure library, the fields after the injected parameter types are recursively decomposed until all nested types of the fields are decomposed into atomic types. Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

5. The method according to claim 1, characterized in that, After determining the response expression ultimately returned by the processing function, the method further includes: If the response expression is a structure instance, then the structure instance is recursively decomposed according to the field names, data types and nesting relationships in the structure library until all nested types of the structure instance are decomposed into atomic types; Based on the hierarchical dependencies between the subfields corresponding to each atomic type after decomposition, a field type tree containing all subfields is constructed.

6. The method according to claim 5, characterized in that, If the response expression is a struct instance, then based on the field names, data types, and nesting relationships in the struct library, the struct instance is recursively decomposed until all nested types of the struct instance are decomposed into atomic types, including: If the response expression is a structure instance, then the structure library is queried using the structure type of the structure instance as an index to determine the target structure information corresponding to the structure instance; Extract the top-level field of the structure instance based on the target structure information, wherein the top-level field is the field directly declared at the outermost layer of the structure instance; If the data type of the top-level field is an atomic type, then the name of the top-level field and its corresponding atomic type are retained; If the top-level field is a complex type, then continue to query the internal composition information of the complex type in the structure library, and decompose the sub-fields contained in the top-level field layer by layer; Repeatedly perform data type determination and decomposition operations on the subfields of the top-level field until all top-level fields of the structure instance are converted to atomic types.

7. An interface documentation automatic generation device, characterized in that, The device includes: The parsing module is used to obtain the structure library and encapsulated functions in the project source code by parsing the project source code, and to construct a function mapping table based on the parameters and structure fields in each of the encapsulated functions. The structure library contains the attribute information of each structure, and the structure fields are fuzzy types of parameters. The determination module is used to locate the processing function and interface information corresponding to each interface path based on the parsed project source code, and to determine the response expression finally returned by the processing function. The injection module is used to inject the parameter types of the actual parameters in the response expression into the structure fields of the corresponding encapsulated function according to the function mapping table if the response expression is an encapsulated function call, and to recursively parse each field after injecting the parameter types in combination with the structure library to obtain a field type tree; The processing module is used to call the large language model to semantically describe the field type tree and the context information of each field in the project source code, forming an enhanced data structure; A generation module is used to integrate the interface information and the enhanced data structure to generate interface documentation. The processing module is used for: Convert the field type tree into a standardized data structure; Extract the context information of each field from the project source code, wherein the context information includes: field name, format tag, function call chain context, the structure to which it belongs, and the package path to which it belongs; The field type tree of the standardized data structure and the context information of each field are input into the large language model to generate a business semantic description of each field; The business semantic description is embedded into the corresponding description field of the standardized data structure to form the enhanced data structure.

8. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images