A knowledge base visualization method, device, storage medium and electronic equipment

Abstract

The application provides a knowledge base visualization method and device, a storage medium and an electronic equipment, and is applied to the technical field of data processing. The application obtains a function area division result and a corresponding interface entry function through directory structure analysis and route registration entry identification. On this basis, project global index data, area index data and interface flow data are generated in sequence, and a structured knowledge base is constructed and a visualized page is generated. Since the above data generation process is based on automatic analysis of code structure and call chain analysis, manual sorting is not required, and a complete three-layer structured knowledge system can be obtained without deploying an additional vector database, realizing a full-automatic closed loop from source code to a structured knowledge base to a visualized page, and reducing the threshold for different roles such as research and development, testing and product to understand engineering code.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a knowledge base visualization method, apparatus, storage medium, and electronic device. Background Technology

[0002] Understanding and accumulating knowledge about backend code is a crucial aspect of software development. As business complexity continues to increase, the ability to quickly extract business logic from massive amounts of source code, define module boundaries, and understand interface execution flows has become a significant factor hindering improvements in development efficiency.

[0003] Currently, API documentation auto-generation tools can only extract surface-level metadata such as interface input and output parameters, and cannot penetrate the call stack to extract business execution logic; static code analysis tools can only generate call topology diagrams at the syntax level, and lack the ability to recognize business semantics; manually maintained knowledge bases and wiki systems rely on manual sorting, which is inefficient and cannot be automatically updated with code changes; static site generation tools only perform format conversion and cannot automatically identify the business hierarchy structure of the project; large model code explanation solutions have no fixed format constraints, poor consistency, and no visualization rendering capabilities. None of the above solutions can achieve a fully automated closed loop from source code to structured knowledge base and generate interactive visual pages.

[0004] Therefore, how to achieve automated knowledge extraction and hierarchical visualization of backend engineering code has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention provides a knowledge base visualization method, apparatus, storage medium, and electronic device to overcome or at least partially solve the above problems. The technical solution is as follows:

[0006] A knowledge base visualization method, comprising:

[0007] Obtain the source code of the backend project;

[0008] The source code is parsed for directory structure and route registration entry is identified to obtain the functional area division results and the interface entry functions corresponding to each functional area;

[0009] Using the functional area division results, generate global index data for the project;

[0010] Using the project's global index data and the interface entry function, generate regional index data;

[0011] Using the call chain corresponding to the interface entry function, generate interface flow data;

[0012] A structured knowledge base is constructed using the project's global index data, the regional index data, and the interface process data.

[0013] The structured knowledge base is rendered according to its hierarchical structure to generate a visual page corresponding to the backend project.

[0014] A knowledge base visualization device includes: a code acquisition unit, a parsing and recognition unit, a first index generation unit, a second index generation unit, an interface process generation unit, a knowledge base construction unit, and a visualization rendering unit;

[0015] The code acquisition unit is used to acquire the source code of the backend project;

[0016] The parsing and identification unit is used to parse the directory structure and identify the route registration entry point of the source code to obtain the functional area division results and the interface entry function corresponding to each functional area;

[0017] The first index generation unit is used to generate global index data for the project using the functional area division results;

[0018] The second index generation unit is used to generate regional index data using the project global index data and the interface entry function;

[0019] The interface process generation unit is used to generate interface process data using the call chain corresponding to the interface entry function;

[0020] The knowledge base construction unit is used to construct a structured knowledge base using the project global index data, the regional index data, and the interface process data.

[0021] The visualization rendering unit is used to render according to the hierarchical structure of the structured knowledge base and generate a visualization page corresponding to the backend project.

[0022] A computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the knowledge base visualization method.

[0023] An electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the knowledge base visualization method.

[0024] By employing the above technical solutions, this invention provides a knowledge base visualization method, device, storage medium, and electronic device. Through directory structure parsing and route registration entry point identification, it obtains functional area division results and corresponding interface entry functions. Based on this, it sequentially generates project global index data, regional index data, and interface process data, thereby constructing a structured knowledge base and rendering a visualization page. Since the above data generation process is based on automatic parsing of the code structure and call chain analysis, it eliminates the need for manual analysis and the deployment of additional vector databases to obtain a complete three-layer structured knowledge system. This achieves a fully automated closed loop from source code to structured knowledge base to visualization page, lowering the barrier to understanding engineering code for different roles such as R&D, testing, and product.

[0025] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0026] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0027] Figure 1 A flowchart illustrating one implementation of the knowledge base visualization method provided in this invention is shown.

[0028] Figure 2 The diagram illustrates a specific implementation of step S140 in the knowledge base visualization method provided in this embodiment of the invention.

[0029] Figure 3 A schematic diagram of the knowledge base visualization device provided in an embodiment of the present invention is shown. Detailed Implementation

[0030] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0031] like Figure 1 The diagram shows a flowchart of one implementation of the knowledge base visualization method provided in this invention. The method may include:

[0032] S100: Obtain the source code of the backend project.

[0033] The backend project refers to the complete code project that implements the backend business logic, which may include directory structure, source code files, dependency configuration files, and route registration files.

[0034] Source code refers to the program code files written by developers in the backend project, which may include route registration files, controller files, business logic files, data access files, and data model files.

[0035] Specifically, in this embodiment of the invention, the root directory path of the backend project can be read through the file system interface, and all subdirectories and source code files under that path can be recursively traversed. The source code includes at least the route registration file, dependency configuration files, controller files in the controller directory, business logic files in the business logic directory, and data access files in the data access directory. During the recursive traversal, the absolute path, filename, file size, and last modification time of each file are recorded, and the file content is read into memory in text format. Simultaneously, the hierarchical relationships of all directory names, filenames, and package names obtained from the recursive traversal are organized into a tree structure to generate the complete directory tree structure of the backend project.

[0036] As an example, taking a ticketing system using a certain MVC framework as an example, the root directory path of the project is read through the file system interface, and all subdirectories and source code files under the path are recursively traversed to obtain all directories and files, including route registration files, dependency configuration files, controller directories, business logic directories, and data access directories. The directory names, file names, and package names are then organized into a directory tree structure.

[0037] S110. Perform directory structure parsing and route registration entry identification on the source code to obtain the functional area division results and the interface entry functions corresponding to each functional area.

[0038] The functional area division result refers to the identification result of the boundaries of each functional area in the backend project, including the area identifier and core responsibility description of each functional area. A functional area is a set of codes in the project that is responsible for specific business functions (such as ticketing management, gate management, event management, etc.).

[0039] The interface entry function refers to the controller method bound in the route registration statement. It is the first entry point for external requests to enter the backend project and includes the function name, the controller it belongs to, and the function's internal implementation logic.

[0040] Specifically, in this embodiment of the invention, the complete directory tree structure and the content of the dependency configuration file can be constructed as the first prompt word, which is input into the large language model. The large language model identifies the technology stack type and MVC layered structure based on directory naming characteristics, package structure characteristics, and dependency information, and outputs the package path and responsibility description corresponding to each layer, as well as technology stack information including the framework name and major dependencies. Then, the entire source code content of the route registration file and its code comments are read to construct the second prompt word, which is input into the large language model. The large language model performs route parsing, extracting the URL path, HTTP method, bound controller type, and entry function name corresponding to each route registration statement, and generating an interface route table containing the above fields. At the same time, based on the semantic information of the interface's URL path, controller affiliation, and comment description, the large language model clusters functionally related interfaces into the same functional area, assigns a region number and region name to each functional area, and summarizes its core capability description, forming a domain list containing the region number, region name, list of interfaces within the region, and description of the region's core capabilities. The interface route table, domain list, and technology stack information together constitute the project structure metadata.

[0041] As examples, embodiments of the present invention can construct a complete directory tree structure and the content of dependency configuration files as the first prompt word input to the large language model. Based on the dependency configuration file containing a framework dependency project and the package naming characteristics of the controller layer, business logic layer, data access layer, and model layer in the directory structure, the large language model determines that the project is a backend project based on the MVC framework and outputs the package paths and responsibility descriptions corresponding to each layer, while also outputting technology stack information (framework type, programming language, and database type). Then, it reads the entire source code of the route registration file, constructs the framework route registration statement (such as Router(" / path",&Controller{},"method:FuncName")) and its comments as the second prompt word input to the large language model, and parses out the URL path, HTTP method, controller type, and entry function name, generating a record in the interface routing table. Based on the URL path structure of the interface, controller affiliation, and semantic information of the comment descriptions (such as "ticket issuance," "ticket verification," and "ticket status"), the large language model clusters functionally related interfaces into the same functional area (such as "ticket management"), assigns area numbers and names, and summarizes core capability descriptions to form a domain list.

[0042] S120. Using the functional area division results, generate global index data for the project.

[0043] Among them, the project global index data refers to the structured data that records the system location of the entire project, the list of all functional areas, and the description of the core capabilities of each area, which is used to provide global navigation and fast routing location.

[0044] Specifically, in this embodiment of the invention, the domain list, interface routing table, and technology stack information in the engineering structure metadata can be constructed as third prompt words. These third prompt words include the structural template of the target output document and an output example conforming to the template format. The third prompt words are input into a large language model, which generates a system positioning description, a list of functional areas, a fast routing prompt word table, and a knowledge base retrieval rule description. All generated content is written to the project's global index file in the root directory, forming the project's global index data.

[0045] As examples, embodiments of the present invention can construct a third prompt word input large language model from a domain list, interface routing table, and technology stack information (framework type, programming language, and database type). The large language model generates a system location description (such as "a ticketing system under an e-commerce platform, supporting multi-channel ticket issuance, verification, and event management"), generates a region list containing region number, region name, and core capabilities, and a quick routing prompt word table from user intent keywords to the region to be searched. The above content is written into the project's global index file in the root directory.

[0046] S130. Generate regional index data using the project's global index data and interface entry functions.

[0047] Among them, regional index data refers to structured data that records the domain location, core entity relationships, branch indexes and quick navigation mapping of a single functional area, which is used to locate specific module cards or interface documents within that area.

[0048] Specifically, in this embodiment of the invention, the region identifier of each functional area can be obtained from the project's global index data. The source code directory of each functional area is traversed, and the interface paths and request methods contained in each functional area are scanned according to the corresponding interface entry functions. For each functional area, the contents of all controller source code files and the interface entries related to that area in the interface routing table are constructed as a fourth prompt word. The fourth prompt word includes a structural template and corresponding output examples of four parts: domain location, branch index, core entity relationship diagram, and quick navigation table. The fourth prompt word is input into a large language model, which generates a domain location description, branch index, core entity relationship diagram, and quick navigation table, and writes them to the domain overview file under the functional area's directory, forming the regional index data for that functional area. The above process is repeated for each functional area until the regional index data for all functional areas is generated.

[0049] As examples, embodiments of the present invention can obtain the region identifier of a certain functional area from the project's global index data, traverse the controller source code files corresponding to that region, construct the fourth prompt word from all controller source code files and interface entries related to that region in the interface routing table, input the fourth prompt word into the large language model, generate a region location description (such as "the core domain of a certain business, covering the entire lifecycle from issuance to cancellation"), generate a branch index directory tree, a core entity relationship diagram, and a quick navigation table, and write them into the domain overview file under the region directory.

[0050] S140. Generate interface process data using the call chain corresponding to the interface entry function.

[0051] The call chain refers to a directed graph structure that starts from the interface entry function and obtains the source code file path, function name, call level and call location of each called function by traversing the function call relationship.

[0052] Among them, interface process data refers to structured data extracted from the call chain according to the actual execution order of the code, which contains an ordered sequence of business steps and a business type label for each step.

[0053] Specifically, in this embodiment of the invention, for each interface entry function, starting from the corresponding controller entry function, a breadth-first search strategy is used to traverse the function call relationship downwards, with a preset upper limit for the search depth. The source code file path, function name, call level, and call location of each called function are recorded during the search process, forming a directed call graph rooted at the controller entry function. The contents of all source code files contained in the directed call graph are constructed as a fifth prompt word. This fifth prompt word includes a structural template and corresponding output examples for four parts: interface location, ordered business execution flow, exception handling summary table, and comparison table of similar interfaces. The fifth prompt word is input into a large language model, which extracts business execution nodes along the call graph according to the actual execution order of the code, starting from the controller entry function. Each node is assigned an incremental step number and labeled with a business type, generating an ordered business step sequence. Deep calls exceeding three levels are summarized and described using the call format in the parent function. The ordered business step sequence is written into the interface details file, forming the interface flow data corresponding to that interface. The above process is repeated for each interface entry function until the interface flow data for all interfaces is generated.

[0054] As examples, embodiments of the present invention can start with an interface entry function and use a breadth-first search strategy to traverse the function call relationships downwards, with a preset upper limit for the search depth, to obtain a directed call graph containing the entry function itself (level 0), the functions it directly calls (level 1), and the functions directly called by each function in level 1 (level 2). The contents of all source code files in the call graph are constructed as the fifth prompt word and input into a large language model. The large language model extracts business execution nodes along the call graph according to the actual execution order of the code, assigns an incremental step number to each node and labels it with a business type (such as "request parameter verification", "business parameter verification", "risk control verification"), and then writes the generated ordered business step sequence into the interface details file.

[0055] S150. Utilize project-wide index data, regional index data, and interface process data to construct a structured knowledge base.

[0056] The structured knowledge base refers to a machine-readable Markdown format knowledge system organized according to a preset hierarchical specification, consisting of project global index data, regional index data, and interface process data. It includes three levels: the project global index layer, the regional index layer, and the interface process layer.

[0057] Specifically, in this embodiment of the invention, the global index data of the project can be stored in the root directory according to the preset three-layer knowledge base directory structure, the regional index data of each functional area can be stored in the domain overview file under the functional area directory, and the interface process data can be stored in the interface directory under the functional area directory, thus forming a three-layer structured knowledge base consisting of the global index layer, the regional index layer and the interface process layer.

[0058] The project global index layer contains project global index data in Markdown format, including system location descriptions, functional area lists, quick route hints, and knowledge base retrieval rules. The regional index layer contains regional index data in Markdown format, including domain location descriptions, branch index directory trees, core entity relationship diagrams, and quick navigation tables. The regional index layer also includes module index files and module card files. Module index files are in Markdown format and contain module lists and quick location hint tables; module card files are in Markdown format and contain module location, core data, core business processes, frequently asked questions (Q&A), and comparison tables of similar modules. The regional index layer also includes interface index files in Markdown format, containing interface lists and interface documentation specifications. The interface process layer contains interface process data in Markdown format, including interface location, ordered business execution processes, exception handling summary tables, and comparison tables of similar interfaces. The interface process layer also includes visual flowchart files in Mermaid format, containing a checkpoint quick reference table and data storage views. The project's global index data, regional index data, module index files, module card files, interface index files, interface process data, and visual flowchart files are organized according to a preset directory structure. The preset directory structure is as follows: the project's global index file is stored in the root directory; the regional index files for each functional area are stored in their respective functional area directories; the module index files and module card files for each functional area are stored in the module subdirectories within their respective functional area directories; and the interface index files, interface process files, and visual flowchart files for each functional area are stored in the interface subdirectories within their respective functional area directories. This embodiment of the invention uses a preset directory structure to uniformly organize and store the files at each level of the three-tiered knowledge base, ensuring a one-to-one correspondence between the knowledge base's directory structure and the hierarchical navigation structure of the visual page, thus guaranteeing the maintainability and scalability of the knowledge base.

[0059] As examples, embodiments of the present invention can store the project global index file in the root directory of the knowledge base, store the domain overview file in the directories of each functional area, and store the interface details file in the interface directory of each functional area, forming a complete knowledge base with a three-layer structure of project global index layer, regional index layer and interface process layer.

[0060] S160. Render the structured knowledge base according to its hierarchical structure to generate a visual page corresponding to the backend project.

[0061] The visual page refers to a single-file HTML page rendered based on the hierarchical structure of a structured knowledge base. It has built-in hierarchical navigation, cross-level hyperlinks, and step-by-step collapsible panels, and supports offline opening in a browser.

[0062] Specifically, embodiments of the present invention can read a structured knowledge base, map the project's global index data to a top-level navigation bar component, map the index data of each region to second-level navigation node components, map the process data of each interface to a third-level details panel component, and map the ordered business step sequence in the interface process data to a collapsible step panel component. Combining these components generates a single-file HTML page, which includes a hierarchical tree navigation, cross-level hyperlinks, and a collapsible step panel.

[0063] As examples, embodiments of the present invention can read a three-layer structured knowledge base, map the region list in the project's global index file to clickable region labels in the top-level navigation bar, map the branch index in the domain overview file of a certain functional area to a second-level sidebar navigation node, and map each step in the interface details file to a collapsible step panel. Each step panel is collapsed by default and can be expanded after being clicked to display the detailed processing logic of that step, generating a single-file HTML page.

[0064] Optionally, in this embodiment of the invention, when rendering and generating a visual page based on the hierarchical structure of the structured knowledge base, the mapping rules further include: mapping the visual flowchart files corresponding to each interface to visual flowchart components rendered by embedded Mermaid.js; and mapping the module card files of each functional area to business concept card components. For example: reading the Mermaid flowchart data in " / domain1-ticket management / interface / API-ticket-send-flowchart.md", and rendering a flowchart display panel in the visual page using Mermaid.js; reading the module card data in " / domain1-ticket management / module / module-ticket distribution.md", and rendering a business concept card component containing module positioning, core data, core business processes, and frequently asked questions (Q&A). This embodiment of the invention, by mapping the visual flowchart files to flowchart components rendered by embedded Mermaid.js and mapping the module card files to business concept card components, achieves a complete mapping from the data at each level of the structured knowledge base to the visual page components, enabling the visual page to fully present the three-layer architecture of the knowledge base, and solving the problem that existing solutions cannot automatically extract links to form a visual closed loop.

[0065] This invention provides a knowledge base visualization method that obtains functional area division results and corresponding interface entry functions through directory structure parsing and route registration entry point identification. Based on this, it sequentially generates project global index data, regional index data, and interface process data, thereby constructing a structured knowledge base and rendering a visualization page. Since the above data generation process is based on automatic parsing of the code structure and call chain analysis, it eliminates the need for manual analysis and the deployment of additional vector databases to obtain a complete three-layer structured knowledge system. This achieves a fully automated closed loop from source code to structured knowledge base to visualization page, lowering the barrier to understanding engineering code for different roles such as R&D, testing, and product.

[0066] Optional, based on Figure 1 The method shown is as follows: Figure 2 The diagram shows a specific implementation of step S140 in the knowledge base visualization method provided in this embodiment of the invention. Step S140 may specifically include:

[0067] S200. Determine the scope of the call chain corresponding to each interface in the interface entry function.

[0068] The call chain range refers to the directed graph structure that starts from the interface entry function and traverses all function calls covered by the function call relationship. It includes the source code file path, function name, call level, and call location information of each called function.

[0069] Specifically, in this embodiment of the invention, for each interface entry function in the list of interface entry functions, starting from the corresponding controller entry function, a breadth-first search strategy is used to traverse the function call relationship layer by layer downwards, with the upper limit of the search depth set to a preset value. The source code file path, function name, call level, and call location of each called function are recorded during the search process, forming a directed call graph rooted at the controller entry function.

[0070] As examples, embodiments of the present invention can, when determining the scope of the call chain, start from the controller entry function SendTicketController.Post() of the ticket issuance interface, and use a breadth-first search strategy to traverse the function call relationship downwards, with the upper limit of the search depth set to 2 levels, to obtain a directed call graph containing Post() itself (level 0), the BaseVerifySimpleSelfForm and sendTicketValidate functions directly called by it (level 1), and the ActiveCheck and FrequecyCheck functions (level 2). The source code file path, function name, call level, and called position of each function are recorded as the scope of the call chain for that interface.

[0071] S210. Traverse the code execution path along the call chain to extract the target business execution node.

[0072] The code execution path refers to the specific call sequence in the call chain, starting from the interface entry function and extending along the directed call relationship to the called functions at each level.

[0073] Here, the target business execution node refers to an atomic operation unit with business semantics extracted from the code execution path within the call chain. Each node corresponds to a code block that completes a specific business function. Business semantics include at least one of request parameter validation, business parameter validation, risk control validation, data query, data writing, and resource allocation.

[0074] Specifically, embodiments of the present invention can start from the root node of the directed call graph and traverse the function call relationships at each level sequentially along the directed edges. During the traversal, the semantic features of each called function are identified. These semantic features include at least one of parameter validation statements, conditional judgment statements, data query statements, data writing statements, and exception return statements. Based on these semantic features, a code block that completes a single business function is taken as a target business execution node, and all target business execution nodes are extracted from the function calls at each level.

[0075] As examples, in this embodiment of the invention, when extracting target business execution nodes by traversing the call chain, starting from Post(), the function calls at each layer of the directed call graph are traversed sequentially. If the BaseVerifySimpleSelfForm function contains a request form format validation statement, it is extracted as a target business execution node; if the sendTicketValidate function contains an activity validity validation statement, it is extracted as another target business execution node, and so on, until the entire call chain is traversed to obtain all target business execution nodes of the interface.

[0076] S220. Sort the target business execution nodes according to the actual execution order of the code, and mark the business type of each target business execution node to generate a business sequence.

[0077] The actual execution order of the code refers to the actual timing of the code execution from the interface entry function downwards during runtime, that is, the order in which the called functions are executed according to their calling relationship, which is different from the writing order or alphabetical order of the code in the source file.

[0078] Among them, business type refers to the category label marked according to the code semantic features of the target business execution node. The category label is used to distinguish the functional role undertaken by the node in the business execution process.

[0079] Among them, the business sequence refers to the sequence formed by arranging multiple target business execution nodes in the order of actual code execution. Each target business execution node in the sequence has a step number and a business type label.

[0080] Specifically, in this embodiment of the invention, all extracted target business execution nodes are sorted according to the depth-first execution path starting from the root node, based on the actual runtime execution order from the interface entry function downwards. During the sorting process, each target business execution node is assigned an incremental step number, and the code semantic features of each target business execution node are identified, with corresponding business type labels marked based on the code semantic features. All target business execution nodes with step numbers and business type labels are arranged into a sequence according to the actual runtime execution order to generate a business sequence.

[0081] As examples, embodiments of the present invention can, when sorting and labeling business types according to the actual execution order, first call BaseVerifySimpleSelfForm to validate request parameters when executing the Post() function, then call sendTicketValidate to validate business parameters, and finally call the coupon code allocation function to perform data writing operations. The nodes are arranged in this execution order, with step number Step1 assigned to the request parameter validation node and labeled as "request parameter validation"; step number Step2 assigned to the business parameter validation node and labeled as "business parameter validation"; and step number Step3 assigned to the data writing operation node and labeled as "data writing", thus generating the business sequence of the interface.

[0082] S230. Generate interface process data corresponding to each interface based on the business sequence.

[0083] Specifically, in this embodiment of the invention, for each interface, the interface location information and business sequence are merged and organized according to a preset interface document structure template, which at least includes an interface location section and a business sequence section. The organized data is then written into the corresponding interface details file to generate the interface flow data for that interface. The above process is repeated for each interface entry function until the interface flow data for all interfaces is generated.

[0084] As examples, when generating interface process data according to the business sequence, embodiments of the present invention may merge the interface location information (functional description: "internal system issues tickets to users", belonging to the file controllers / ticket_controller.go, and the entry function is Post) with the business sequence, organize it according to the interface document structure template (including two parts: interface location and step by step ordered business execution process), and write it into the API-ticket-send.md file to generate the interface process data corresponding to the interface.

[0085] This invention, through determining the call chain range corresponding to each interface in the interface entry function and traversing the code execution path along the call chain to extract target business execution nodes, then sorts the nodes according to the actual execution order of the code and labels them with business types to generate a business sequence. This allows the generation of interface process data using the business sequence, achieving penetrating extraction of business execution logic within the call stack and ordered organization according to the actual execution order. This solves the problems of existing solutions being unable to penetrate the call stack to extract business logic and lacking business semantic recognition capabilities.

[0086] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S220 may include:

[0087] Assign incremental step numbers to each target business execution node according to the actual execution order of the code, identify the semantic features of the code of each target business execution node, label the corresponding business type based on the semantic features of the code, and generate a business sequence.

[0088] Here, code semantic features refer to the syntactic patterns and program structure features in the source code used to characterize the functional intent and operational nature of the code. These can include at least one of the following: parameter validation statements, conditional statements, data query statements, data write statements, and exception return statements. Parameter validation statements include at least one of the following: non-empty checks, type checks, and value range checks; conditional statements include at least one of the following: status checks, permission checks, and business rule checks; data query statements include at least one of the following: database queries, cache queries, and remote service calls; data write statements include at least one of the following: database inserts, database updates, cache writes, and message sending; and exception return statements include at least one of the following: error code returns and exception throwing.

[0089] The business type tag refers to a category identifier marked based on the code semantic characteristics of the target business execution node, used to characterize the functional role that target business execution node plays in the business execution process. Business type tags include at least one of the following: request parameter validation, business parameter validation, risk control validation, data query, data writing, resource allocation, and exception handling. Each target business execution node corresponds to one business type tag, and the business type tag is recorded in the business sequence in association with the target business execution node.

[0090] Specifically, in this embodiment of the invention, starting from the root node of the directed call graph (i.e., the controller entry function), each extracted target business execution node is assigned a step number starting from 1, according to the actual execution order of each called function after entering the interface entry function at runtime. During the step number assignment process, for each target business execution node, the program statements in the corresponding code block are scanned to extract its code semantic features. These features include at least one of parameter validation statements, conditional judgment statements, data query statements, data write statements, and exception return statements. Based on the code semantic features, each target business execution node is labeled with a corresponding business type tag. These tags include at least one of request parameter validation, business parameter validation, risk control validation, data query, data write, resource allocation, and exception handling. All target business execution nodes that have undergone step number assignment and business type tagging are organized into a sequence structure according to the step number order, forming the business sequence of the interface.

[0091] As examples, this embodiment of the invention can take the ticket distribution interface as an example. When the controller entry function Post() is executed, it first calls the BaseVerifySimpleSelfForm function to perform request parameter validation, then calls the sendTicketValidate function to perform business parameter validation, and finally calls the ticket code allocation function to perform data writing operation. According to this execution order, the step number of the corresponding BaseVerifySimpleSelfForm node is assigned as 1, and its code contains non-empty checks and type checks. Based on the semantic features of this code, the business type label is marked as "request parameter validation"; the step number of the corresponding sendTicketValidate node is assigned as 2, and its code contains activity status judgment and validity period judgment statements. Based on the semantic features of this code, the business type label is marked as "business parameter validation"; the step number of the corresponding ticket code allocation function is assigned as 3, and its code contains database insertion statements. Based on the semantic features of this code, the business type label is marked as "data writing". The BaseVerifySimpleSelfForm node, which is assigned step number 1 and labeled "Request Parameter Validation", the sendTicketValidate node, which is assigned step number 2 and labeled "Business Parameter Validation", and the coupon code allocation node, which is assigned step number 3 and labeled "Data Writing", are organized into a sequence according to the order of step numbers 1, 2, and 3 to generate the business sequence of this interface.

[0092] This invention addresses the problems of existing solutions that cannot penetrate the call stack to extract business logic and lack business semantic recognition capabilities by assigning incremental step numbers to each target business execution node according to the actual execution order of the code and labeling business type tags based on code semantic features.

[0093] Optionally, in the above Figure 2 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, after step S230, the method may further include:

[0094] Generate visual flowchart data corresponding to each interface.

[0095] The visual flowchart data refers to flowchart files in Mermaid flowchart format that convert the business sequences in the interface process data into flowchart files according to preset rules. The preset rules include: validation steps are converted into diamond-shaped decision nodes; data operation steps are converted into rectangular operation nodes; substeps within the same step number are grouped using subgraphs; exception paths that fail validation are connected to error code nodes with dashed lines; and successful paths that cross steps are connected with solid arrows.

[0096] Specifically, in this embodiment of the invention, for each interface, the business sequence in the interface process data corresponding to that interface is obtained, and the business sequence is converted into a Mermaid flowchart format according to preset rules. The step number and business type label of each target business execution node in the business sequence are extracted. Nodes with business type labels of "request parameter verification," "business parameter verification," and "risk control verification" are converted into diamond-shaped judgment nodes, and the verification conditions corresponding to the step are written into the diamond-shaped judgment nodes. Nodes with business type labels of "data query," "data write," and "resource allocation" are converted into rectangular operation nodes, and the data operation description corresponding to the step is written into the rectangular operation nodes. Substeps within the same step number are grouped using subgraphs. Abnormal paths that fail verification are connected to the corresponding error code nodes with dashed lines. Successful paths across steps are connected with solid arrows. The generated Mermaid flowchart, along with the accompanying verification checkpoint quick reference table and data storage view, are written into the visualization flowchart file corresponding to that interface.

[0097] As examples, taking the "Ticket Issuance" interface as an example, the business sequence of this interface includes Step 1 "Request Parameter Validation", Step 2 "Business Parameter Validation" and Step 3 "Data Writing". The validation conditions of Step 1 "ActId not empty, SkuId not empty, Uuid not empty" are converted into diamond-shaped judgment nodes. The validation condition of Step 2 "within the activity validity period" is converted into a diamond-shaped judgment node. Step 3 "Write to ticket_info table" is converted into a rectangular operation node. The sub-steps within the same Step are grouped with subgraph. The validation failure path is connected to the error code node with a dashed line. The success path is connected with a solid arrow. A Mermaid format flowchart is generated and written to " / domain1-ticket management / interface / API-ticket-send-flowchart.md".

[0098] This invention converts each node in a business sequence into a Mermaid flowchart format according to preset rules, so that verification nodes, data operation nodes, sub-step groups, and abnormal paths are all presented in a visual graphic. This achieves a dual expression of the business execution process in terms of both structure and graphics, and solves the problems of fragmented extraction and display and poor information readability in existing solutions.

[0099] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, after step S150, the method may further include:

[0100] Build the first-level index link from the project's global index data to the index data of each region.

[0101] The first-level index link refers to the reference path from the project's global index data to the index data of each region, used to locate the corresponding regional index data from the project's global index data during retrieval. The first-level index link must at least include the storage path of the target regional index data and the regional identifier.

[0102] Specifically, in this embodiment of the invention, each functional area in the functional area division result can be traversed in the project's global index data to obtain the area identifier and storage path of the area index data for each functional area. The area identifier of each functional area is associated with the corresponding area index data storage path to form a reference relationship between the project's global index data and the index data of each area.

[0103] As an example, taking the "Ticketing Management" function area as an example, the area identifier of this area is obtained from the project's global index data as "Domain 1" and the storage path of the area index data is " / Domain 1-Ticketing Management / _Overview.md". "Domain 1" is associated with this storage path to form a first-level index link, so that when searching, clicking "Domain 1-Ticketing Management" will jump to the corresponding "_Overview.md file".

[0104] Construct a second-level index link from the index data of each region to the corresponding interface process data.

[0105] The second-level index link refers to the reference path from the index data of each region to the corresponding interface process data. It is used to locate the specific interface process data within that region during retrieval. The second-level index link must at least include the storage path of the target interface process data and the interface identifier.

[0106] Specifically, in each regional index data embodiment, each interface in the interface routing table within that region can be traversed to obtain the interface identifier of each interface and the storage path of the corresponding interface process data. The interface identifier of each interface is then associated with its corresponding interface process data storage path, forming a reference relationship between each regional index data and its corresponding interface process data.

[0107] As an example, taking the "Ticket Issuance" interface as an example, the interface identifier of this interface is obtained from the index data of the "Ticket Management" area as "API-ticket-send", and the storage path of the interface process data is " / domain1-Ticket Management / Interface / API-ticket-send.md". "API-ticket-send" is associated with this storage path to form a second-level index link, so that when searching, clicking on "Ticket Issuance Interface" in the "Ticket Management" area will jump to the corresponding "API-ticket-send.md file".

[0108] The mapping relationship of the first-level index links is recorded in the project's global index data, and the mapping relationship of the second-level index links is recorded in the index data of each region.

[0109] Specifically, in this embodiment of the invention, a mapping field can be added under each functional area entry in the project's global index data. The mapping field contains the correspondence between the area identifier and the corresponding area index data storage path. A mapping field can also be added under each interface entry in each area index data. The mapping field contains the correspondence between the interface identifier and the corresponding interface process data storage path.

[0110] As examples, embodiments of the present invention can record the first-level index link mapping relationship in the project's global index data by writing the correspondence between "domain 1" and " / domain 1-ticket management / _overview.md" into the mapping field under the corresponding area entry in the project's global index data, so that the corresponding area index data can be located from the project's global index data during retrieval. When recording the second-level index link mapping relationship in each area index data, the correspondence between "API-ticket-send" and " / domain 1-ticket management / interface / API-ticket-send.md" is written into the mapping field under the corresponding interface entry in the "ticket management" area index data, so that the corresponding interface process data can be located from the area index data during retrieval.

[0111] This invention establishes a two-level index link from project global index data to regional index data and from regional index data to interface process data after constructing a structured knowledge base, and records the mapping relationship. This enables retrieval to locate the target interface process data hierarchically from the project global index data, thereby realizing a hierarchical navigation and hierarchical retrieval knowledge base access mechanism. This solves the problem of existing solutions lacking business hierarchy division, extraction and display gaps.

[0112] Optionally, based on one or more of the above-described embodiments, in another optional embodiment provided by the present invention, the method may further include:

[0113] Obtain the target business knowledge query request.

[0114] Among them, the target business knowledge query request refers to the query instruction issued by the user or system to obtain specific business knowledge of the backend project. The query instruction includes at least one of the target area identifier and the target interface identifier, which is used to trigger a step-by-step location retrieval based on the first-level index link and the second-level index link.

[0115] Specifically, embodiments of the present invention can receive query commands input by users through a human-computer interaction interface, wherein the query commands contain business questions described in natural language; or receive structured query messages sent by external systems through an application programming interface.

[0116] As an example, embodiments of the present invention can take an e-commerce ticketing system as an example, and receive a user's input "I want to know which checks were performed by the ticket issuance interface" through an interactive interface to obtain a target business knowledge query request.

[0117] Extract the target region identifier and target interface identifier from the target business knowledge query request.

[0118] The target area identifier refers to the unique identifier information that specifies the target functional area, which is used to locate the corresponding area index data in the project's global index data through the first-level index link.

[0119] The target interface identifier refers to the unique identifier information that specifies the target interface, which is used to locate the corresponding interface process data in the regional index data through the second-level index link.

[0120] Specifically, embodiments of the present invention can parse target business knowledge query requests. When the query request is a natural language description, the target region identifier and target interface identifier are extracted from the natural language description through keyword matching. When the query request is a structured query message, the target region identifier and target interface identifier are read from the specified fields of the structured query message.

[0121] As examples, embodiments of the present invention can parse the target business knowledge query request "I want to know which checks the ticket distribution interface performed", and extract the target area identifier as "ticket management" and the target interface identifier as "ticket distribution" through keyword matching.

[0122] Based on the target region identifier and the target interface identifier, the corresponding region index data is located sequentially through the first-level index link, and then the corresponding interface process data is located through the second-level index link.

[0123] Specifically, in this embodiment of the invention, the mapping fields can be traversed in the project's global index data to find a region identifier that matches the target region identifier. When a match is successful, the region index data storage path corresponding to the region identifier is read, and the region index data under the storage path is loaded. In the loaded region index data, the mapping fields are traversed to find an interface identifier that matches the target interface identifier. When a match is successful, the interface process data storage path corresponding to the interface identifier is read, and the interface process data under the storage path is loaded.

[0124] As examples, embodiments of the present invention can search for a region identifier matching "ticketing management" in the mapping field of the project's global index data, read the storage path of the region index data, and then load the index data of the "ticketing management" region; search for an interface identifier matching "ticket distribution" in the mapping field of the region index data, read the storage path of the interface process data, and then load the process data of the "ticket distribution" interface.

[0125] Extract business knowledge that matches the target query request from the located interface process data.

[0126] Among them, business knowledge refers to the business information fragments extracted from the interface process data that match the target query request, including at least one of the following: the sequence of business execution steps of the interface, the step number corresponding to each target business execution node, and the business type label.

[0127] Specifically, embodiments of the present invention can parse the loaded interface process data, extract interface location information and business sequence from the interface process data, the business sequence includes each target business execution node arranged in the actual execution order of the code and its corresponding step number and business type label; and return the interface location information and business sequence as business knowledge matching the target query request.

[0128] As examples, embodiments of the present invention can parse and extract interface location information (functional description: "internal system issues tickets to users", file: controllers / ticket_controller.go, entry function: Post) and business sequence (including Step 1 marked as "request parameter verification" and Step 2 marked as "business parameter verification") from the process data of the "ticket issuance" interface, and use it as business knowledge that matches "I want to know which verifications the ticket issuance interface performed".

[0129] This invention, through establishing two levels of index links and recording mapping relationships in a structured knowledge base, sequentially locates the corresponding interface process data and extracts business knowledge based on the target region identifier and target interface identifier via the first-level index link and the second-level index link. This achieves accurate layer-by-layer retrieval based on hierarchical indexes, solving the problem that existing solutions rely on vector databases or full-text search and cannot perform efficient and accurate positioning according to business levels.

[0130] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S130 may specifically include:

[0131] Obtain the region identifier of each functional area from the project's global index data.

[0132] The region identifier refers to the identification information used to uniquely identify a functional region, including at least one of the following: region number, region name, and description of the region's core capabilities. The region identifier is used to distinguish different functional regions in the project's global index data.

[0133] Specifically, in this embodiment of the invention, the project's global index data can be read, the list of functional areas can be parsed from the project's global index data, and the area number and area name corresponding to each functional area can be extracted to form a set of area identifiers for each functional area. Each element in the area identifier set contains the correspondence between the area number and the area name.

[0134] As an example, taking an e-commerce ticketing system as an example, the functional area list is parsed from _index.md, and area identifiers such as "Domain 1 - Ticketing Management" and "Domain 2 - Event Management" are extracted. Among them, the area number corresponding to "Domain 1 - Ticketing Management" is "Domain 1" and the area name is "Ticketing Management".

[0135] Traverse the source code directory of each functional area, and scan the interface paths and request methods contained in each functional area according to the corresponding interface entry function.

[0136] The source code directory refers to the folder path in the backend project used to store source code files, including at least one of the controller directory, business logic directory, and data access directory for that functional area.

[0137] The interface path refers to the URL address used to locate the interface, which is used to identify the access address of the interface in the route registration statement corresponding to the interface entry function.

[0138] The request method refers to the HTTP request method of the interface, including at least one of POST, GET, PUT and DELETE.

[0139] Specifically, in this embodiment of the invention, for the interface entry function corresponding to each functional area, the controller directory path corresponding to that functional area is located using the area identifier of each functional area as an index. All source code files in the controller directory are traversed, and the corresponding route registration statement is matched from the source code file based on the interface entry function name. The URL path and HTTP request method are extracted from the route registration statement. The URL paths and HTTP request methods of all interfaces within that functional area are summarized to form an interface path-request method mapping table for that functional area.

[0140] As an example, taking "Domain 1 - Ticketing Management" as an example, the controllers / ticket / directory is located according to the interface entry function corresponding to this functional area. The ticket_controller.go file in this directory is traversed. The route registration statement is matched from the source code according to the interface entry function SendTicket. The URL path is extracted as / manager / ticket / send and the HTTP request method is POST. After all interfaces in this functional area are traversed, an interface path-request method mapping table is formed.

[0141] Extract interface metadata from the source code corresponding to each interface.

[0142] Interface metadata refers to attribute information extracted from the source code corresponding to the interface, used to describe the technical characteristics of the interface, and includes at least one of the following: interface positioning description, interface parameter description, and interface return data format description. The interface positioning description describes the functional purpose of the interface; the interface parameter description describes the structure of the input parameters and the meaning of each field; and the interface return data format description describes the structure of the output data and the meaning of each field.

[0143] Specifically, in this embodiment of the invention, for each interface entry function, the corresponding controller source code file can be located. Code comments for the interface entry function are extracted from the controller source code file, and an interface function description is extracted from the code comments. Parameter names, parameter types, and parameter constraints are extracted from the request parameter structure of the interface entry function to form an interface parameter description. Return field names, return field types, and return field meanings are extracted from the return value structure of the interface entry function to form an interface return data format description. The interface function description, interface parameter description, and interface return data format description are associated to generate the interface metadata for that interface.

[0144] As examples, taking the ticket distribution interface as an example, we locate the code comment "Complete process of the internal system distributing a single ticket to the user" in the SendTicket function of the controllers / ticket_controller.go file, and extract the interface function description from the comment; we extract the field names, types, and whether they are required from the actId, skuId, and uuid request parameter structure of the SendTicket function to form the interface parameter description; we extract the error code field and its meaning from the function's return value structure to form the interface return data format description, and associate the above information to generate the interface metadata for this interface.

[0145] Based on the area identifier, interface path, request method, and interface metadata of each functional area, generate the area index data corresponding to each functional area.

[0146] Specifically, in this embodiment of the invention, the region identifier of each functional area can be used as the grouping key to summarize the interface paths, request methods, and interface metadata of all interfaces within that functional area. According to a preset regional index data format, the region identifier, the interface path-request method mapping table of all interfaces within the region, and the corresponding interface metadata are organized into structured data and written into the regional index file under the directory of that functional area, generating the regional index data corresponding to that functional area.

[0147] As examples, the area identifier of "Domain 1-Ticketing Management", the interface path-request method mapping table of the ticket issuance interface and ticket verification interface in this area, and the interface metadata corresponding to each interface are organized according to the area index data format (such as including domain location, branch index, core entity relationship diagram and quick navigation table) and written into " / Domain 1-Ticketing Management / _Overview.md" to generate the area index data of the "Ticketing Management" functional area.

[0148] This invention achieves a structured refinement from the global project layer to the regional interface layer by obtaining the regional identifier from the project's global index data, traversing the source code directories of each functional region to scan the interface paths and request methods, extracting interface metadata from the interface source code, and then organizing the regional index data by region. This solves the problems of existing solutions lacking business hierarchy division and a unified business abstraction system.

[0149] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, the region index data is a domain overview document ("_overview.md"), which includes four parts: domain location, branch index, core entity relationship diagram and quick navigation table.

[0150] Specifically, after obtaining the region identifiers of each functional area from the project's global index data, for each functional area, a fourth prompt word is constructed from the contents of all controller source code files and the interface entries related to that area in the interface routing table. The fourth prompt word includes a structural template comprising four parts: domain location, branch index, core entity relationship diagram, and quick navigation table, along with an output example conforming to the template format. The fourth prompt word is input into the large language model, which generates a complete domain overview document in one go. Specifically, the domain location description is a business location description generated based on the controller type naming, entry function naming, function comments, and request parameter processing logic of the functional area; the branch index is the directory tree structure of module card files and interface files within the functional area; the core entity relationship diagram identifies core business entities and their relationships from the request parameter structure and return value structure of the controller entry function; and the quick navigation table is a navigation mapping table for "requirements → where to find". The generated domain overview document is written to the "_overview.md" file in the directory of the functional area, forming the regional index data for that functional area.

[0151] As examples, taking the "Ticket Management" functional area as an example, all controller source code files under the controllers / ticket / directory and interface entries related to "Ticket Management" in the interface routing table are constructed as the fourth prompt word input large language model. The large language model generates a domain positioning description of "the core domain of ticket business, covering the entire lifecycle from issuance to redemption", generates a branch index directory tree, generates a core entity relationship diagram "Activity → Ticket Type SKU → Ticket Batch → Redemption Log", generates a quick navigation table "Want to understand the complete process of a certain interface → Interface / → Corresponding API File" and "Want to understand a certain business concept → Module / → Corresponding Module Card", and writes the above content into the / domain1-Ticket Management / _Overview.md file.

[0152] This invention constructs a fourth prompt word input large language model by using all controller source code files and intra-domain interface routing tables for each functional area. It generates a domain overview document containing domain location, branch index, core entity relationship diagram and quick navigation table at once, realizing the structured organization and quick navigation location of functional area-level knowledge. This solves the problems of existing solutions lacking business hierarchy division and being unable to perform structured knowledge management at the regional level.

[0153] Optionally, based on one or more of the above-described embodiments, in another optional embodiment provided by the present invention, before step S140, the method may further include:

[0154] Generate module card data and module index data for each functional area.

[0155] The module cards are knowledge cards organized according to business concepts. Each module card contains five fields: module positioning, core data, core business processes, frequently asked questions (Q&A), and a comparison table with similar modules. The module positioning describes the functional problems solved and the role played by the module in the system; the core data describes the key table structures and key field descriptions involved in the module; the core business processes describe the core operation steps of the module; the frequently asked questions (Q&A) record typical questions and answers for the module in a question-and-answer format; and the comparison table with similar modules records the comparison relationship between this module and other modules in the same domain.

[0156] Specifically, in this embodiment of the invention, for each functional area, the contents of all controller source code files in that functional area can be constructed as a sixth prompt word. The sixth prompt word includes a structural template for a module index file and module card files, as well as an output example conforming to the template format. The module card template includes five fields: module location, core data, core business processes, frequently asked questions (Q&A), and a comparison table of similar modules. The sixth prompt word is input into a large language model, which identifies the module boundaries within the functional area according to the business concept dimension. A module card is generated for each identified business module, and all module cards are summarized to generate a module list and a quick reference table. The generated module index file is written to the module " / _index.md" in the directory of that functional area, and each module card file is written to the module " / module-*.md" in the directory of that functional area.

[0157] As examples, taking the "Ticket Management" functional area as an example, all controller source code files under the controllers / ticket / directory are constructed as the sixth prompt word input large language model. The large language model identifies business modules such as "Ticket Issuance", "Ticket Verification", "Ticket Status", and "Ticket Inquiry" according to the business concept dimension. For the "Ticket Issuance" module, a module card is generated, which includes the module positioning as "the complete ability to issue tickets to users or external systems", the core data includes fields such as "ActId Activity ID, SkuId Ticket Type SKU ID, Uuid Target User UUID", and the core business process includes steps such as "parameter verification → business verification → ticket code allocation → data writing → return result". A module index file containing a module list and a quick location prompt table is generated. The module index file is written to / domain1-Ticket Management / module / _index.md, and the "Ticket Issuance" module card is written to / domain1-Ticket Management / module / module-Ticket Issuance.md.

[0158] This invention identifies module boundaries based on business concepts and generates module cards that include module positioning, core data, core business processes, frequently asked questions (Q&A), and comparison tables of similar modules. This achieves the separation and independent organization of business and technical perspectives, enabling non-technical personnel such as product managers and testers to understand engineering functions based on business concepts. It solves the problems of existing solutions lacking a standardized business abstraction system and different roles being unable to obtain knowledge of different granularities as needed.

[0159] Optionally, based on one or more of the above-described embodiments, in another optional embodiment provided by this invention, step S120 may specifically include:

[0160] Identify the boundaries of each functional area in the functional area division results based on the directory structure of the source code.

[0161] The directory structure refers to the directory hierarchy of the backend project source code, including at least one of the following: directory names, file names, and package names at each level.

[0162] The boundaries of functional areas refer to the basis for dividing each functional area in the functional area division result, including at least one of the following: URL path prefix, controller affiliation, and annotation description semantic information.

[0163] Specifically, in this embodiment of the invention, the directory tree structure of the backend project can be read. For each functional area in the functional area division result, the URL path prefix and controller affiliation information are extracted from the interface entry function corresponding to the functional area. Interfaces with the same URL path prefix or the same controller affiliation are grouped into the same functional area. The controller directory path corresponding to each functional area is marked in the directory tree structure, and the directory division boundary between each functional area is used as the boundary of each functional area.

[0164] As an example, taking an e-commerce ticketing system as an example, based on the fact that the URL paths of the interface entry functions (SendTicket, VerifyTicket, QueryTicket) corresponding to the functional area "Ticket Management" all have / manager / ticket / as a prefix and the controllers all belong to the ticket package, the / manager / ticket / path prefix and the ticket controller affiliation are used as the boundary of the "Ticket Management" functional area, and the controllers / ticket / directory is marked in the directory tree as the controller directory corresponding to this functional area.

[0165] Extract the entry file path and package reference relationship of each functional area.

[0166] The entry file path refers to the storage path of the entry file corresponding to each functional area in the source code directory. The entry file is a file containing route registration statements or interface entry function definitions.

[0167] Package reference relationships refer to the dependencies between other code packages imported through import statements in the source code files of functional areas, which are used to determine the calling dependencies between functional areas.

[0168] Specifically, in this embodiment of the invention, for each functional area, the storage path of the source code file where the corresponding interface entry function is located is determined as the entry file path; all import statements in the entry file are read, the paths of the referenced packages are extracted from each import statement, and a package reference relationship list for the functional area is formed.

[0169] As an example, taking the "Ticketing Management" functional area as an example, the entry file path is determined to be controllers / ticket_controller.go based on the source code file controllers / ticket_controller.go where the interface entry function SendTicket is located; the import statements in the file are read, and the referenced package paths server / ticket_server and dao / ticket_dao are extracted from import "server / ticket_server" and import "dao / ticket_dao", forming a package reference relationship list for this functional area.

[0170] Based on the boundaries of functional areas, entry file paths, and package reference relationships, determine the responsibility description information for each functional area.

[0171] The job description information refers to a general description of the core functions of a functional area, including at least one of the business scope, core capabilities, and system boundaries of the functional area.

[0172] Specifically, in this embodiment of the invention, for each functional area, functional theme keywords are extracted based on the annotation descriptions and function names of the interface entry functions contained in the boundary of the functional area; the level to which the functional area belongs in the layered architecture is determined based on the entry file path of the functional area; other functional areas or external components that the functional area depends on are determined based on the package reference relationship of the functional area; and the functional theme keywords, the level to which they belong, and the dependency relationship are combined into a natural language description as the responsibility description information of the functional area.

[0173] As examples, taking the "Ticketing Management" functional area as an example, based on the interface entry function comments describing "ticket issuance," "ticket verification," and "ticket status" contained in its boundaries, the functional theme keyword is extracted as "ticket management." Based on the entry file path being located in the controllers / layer, the layer to which it belongs is determined to be the controller layer. Based on the package reference relationship containing server / ticket_server, the dependent business logic layer is determined. Combining the above information into the responsibility description information, "The controller layer functional area responsible for the entire lifecycle management of tickets, dependent on the ticketing business logic layer."

[0174] Write the area identifiers and corresponding responsibility descriptions of each functional area into the preset project global index template to generate project global index data.

[0175] The preset project global index template refers to a predefined format template used to generate project global index data, which includes at least one of the following: system location field, functional area list field, quick route prompt word field, and knowledge base retrieval rule field. The functional area list field contains placeholders for area identifiers and responsibility description information.

[0176] Specifically, in this embodiment of the invention, a preset global index template for a project can be obtained. The preset global index template includes a system location field, a functional area list field, a quick route prompt field, and a knowledge base retrieval rule field. Technology stack information is written into the system location field. For each functional area, the area identifier and corresponding responsibility description information of that functional area are written into the corresponding entry of the functional area list field according to the template format. Quick route prompts are generated based on the responsibility description information of each functional area and written into the quick route prompt field. Preset retrieval rules are written into the knowledge base retrieval rule field. All the filled content is output as the global index data for the project.

[0177] As examples, taking an e-commerce ticketing system as an example, the following steps are taken: A preset global index template is obtained, the technology stack information "Go / Beego / MySQL / Redis" is written into the system location field, the area identifier "Domain 1" of the "Ticketing Management" functional area and the responsibility description information "Controller layer functional area responsible for the entire lifecycle management of tickets" are written into the functional area list field, a quick routing suggestion "How to execute ticket issuance → Domain 1 - Ticketing Management" is generated based on the responsibility description information and written into the quick routing suggestion field, preset search rules are written into the knowledge base search rule field, and the complete "_index.md" is output as the project's global index data.

[0178] This invention identifies functional area boundaries based on the directory structure, extracts entry file paths and package reference relationships to determine the responsibility description information of each functional area, and then writes it into a preset template to generate global project index data. This enables the generated global project index data to reflect the macro-architecture information and responsibility division of each functional area of ​​the project, solving the problem that existing solutions lack business hierarchy division and cannot quickly establish a global understanding of the project.

[0179] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0180] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0181] Corresponding to the above method embodiments, this invention also provides a knowledge base visualization device, the structure of which is as follows: Figure 3 As shown, it may include: code acquisition unit 10, parsing and recognition unit 20, first index generation unit 30, second index generation unit 40, interface process generation unit 50, knowledge base construction unit 60 and visualization rendering unit 70.

[0182] Code acquisition unit 10 is used to acquire the source code of the backend project.

[0183] The parsing and identification unit 20 is used to parse the directory structure of the source code and identify the route registration entry point to obtain the functional area division results and the interface entry function corresponding to each functional area.

[0184] The first index generation unit 30 is used to generate global index data for the project using the functional area division results.

[0185] The second index generation unit 40 is used to generate regional index data using the project's global index data and interface entry functions.

[0186] The interface flow generation unit 50 is used to generate interface flow data using the call chain corresponding to the interface entry function.

[0187] Knowledge base construction unit 60 is used to build a structured knowledge base using project global index data, regional index data, and interface process data.

[0188] The visualization rendering unit 70 is used to render according to the hierarchical structure of the structured knowledge base and generate a visualization page corresponding to the backend project.

[0189] Optionally, the interface process generation unit 50 may include: a call chain range determination subunit, a target business execution node extraction subunit, a business sequence generation subunit, and an interface process data generation subunit.

[0190] The call chain scope determination subunit is used to determine the call chain scope corresponding to each interface in the interface entry function.

[0191] The target business execution node extraction sub-unit is used to traverse the code execution path along the call chain and extract the target business execution node.

[0192] The business sequence generation subunit is used to sort the target business execution nodes according to the actual execution order of the code, and mark the business type of each target business execution node to generate a business sequence.

[0193] The interface process data generation subunit is used to generate interface process data corresponding to each interface based on the business sequence.

[0194] Optionally, the business sequence generation subunit can be used to assign incremental step numbers to each target business execution node according to the actual execution order of the code, identify the code semantic features of each target business execution node, label the corresponding business type based on the code semantic features, and generate a business sequence.

[0195] Optionally, the knowledge base visualization device may also include: a first link building unit, a second link building unit, and a mapping relationship recording unit.

[0196] The first link building unit is used to build the first-level index link from the project's global index data to the index data of each region.

[0197] The second link building unit is used to build a second-level index link from the index data of each region to the corresponding interface process data.

[0198] The mapping relationship recording unit is used to record the mapping relationship of the first-level index links in the project's global index data, and to record the mapping relationship of the second-level index links in the index data of each region.

[0199] Optionally, the knowledge base visualization device may also include: a query request acquisition unit, an identifier extraction unit, a data location unit, and a knowledge extraction unit.

[0200] The query request acquisition unit is used to obtain the target business knowledge query request.

[0201] The identifier extraction unit is used to extract the target region identifier and the target interface identifier from the target business knowledge query request.

[0202] The data location unit is used to locate the corresponding area index data sequentially through the first-level index link based on the target area identifier and the target interface identifier, and then locate the corresponding interface process data through the second-level index link.

[0203] The knowledge extraction unit is used to extract business knowledge that matches the target query request from the located interface process data.

[0204] Optionally, the second index generation unit 40 can be used to obtain the region identifier of each functional area from the project's global index data; traverse the source code directory of each functional area, scan the interface paths and request methods contained in each functional area according to the interface entry function corresponding to each functional area; extract interface metadata from the source code corresponding to each interface; and generate the region index data corresponding to each functional area according to the region identifier, interface path, request method and interface metadata of each functional area.

[0205] Optionally, the first index generation unit 30 can be used to identify the boundaries of each functional area in the functional area division result based on the directory structure of the source code; extract the entry file path and package reference relationship of each functional area; determine the responsibility description information of each functional area based on the boundaries, entry file path and package reference relationship of the functional area; write the area identifier and corresponding responsibility description information of each functional area into the preset project global index template to generate project global index data.

[0206] This invention provides a knowledge base visualization device that obtains functional area division results and corresponding interface entry functions through directory structure parsing and route registration entry point identification. Based on this, it sequentially generates project global index data, regional index data, and interface process data, thereby constructing a structured knowledge base and rendering a visualization page. Since the above data generation process is based on automatic parsing of the code structure and call chain analysis, it eliminates the need for manual analysis and the deployment of additional vector databases to obtain a complete three-layer structured knowledge system. This achieves a fully automated closed loop from source code to structured knowledge base to visualization page, lowering the barrier to understanding engineering code for different roles such as R&D, testing, and product.

[0207] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0208] The knowledge base visualization device includes a processor and a memory. The code acquisition unit 10, parsing and recognition unit 20, first index generation unit 30, second index generation unit 40, interface process generation unit 50, knowledge base construction unit 60 and visualization rendering unit 70 are all stored in the memory as program units. The processor executes the above program units stored in the memory to realize the corresponding functions.

[0209] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, a fully automated closed loop can be achieved, from source code to a structured knowledge base and then to a visual page.

[0210] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements the knowledge base visualization method.

[0211] This invention provides a processor for running a program, wherein the program executes the knowledge base visualization method during runtime.

[0212] This invention provides an electronic device, which includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the aforementioned knowledge base visualization method. The electronic device in this document can be a server, PC, PAD, mobile phone, etc.

[0213] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program that initializes a knowledge base visualization method step.

[0214] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0215] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0216] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0217] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0218] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. A knowledge base visualization method, characterized in that, include: Obtain the source code of the backend project; The source code is parsed for directory structure and route registration entry is identified to obtain the functional area division results and the interface entry functions corresponding to each functional area; Using the functional area division results, generate global index data for the project; Using the project's global index data and the interface entry function, generate regional index data; Using the call chain corresponding to the interface entry function, generate interface flow data; A structured knowledge base is constructed using the project's global index data, the regional index data, and the interface process data. The structured knowledge base is rendered according to its hierarchical structure to generate a visual page corresponding to the backend project.

2. The method according to claim 1, characterized in that, The step of generating interface flow data using the call chain corresponding to the interface entry function includes: Determine the scope of the call chain corresponding to each interface in the interface entry function; Traverse the code execution path along the call chain range to extract the target business execution node; The target business execution nodes are sorted according to the actual execution order of the code, and the business type of each target business execution node is labeled to generate a business sequence; Generate interface process data corresponding to each interface based on the business sequence.

3. The method according to claim 2, characterized in that, The step of sorting the target business execution nodes according to the actual execution order of the code, and labeling the business type of each target business execution node to generate a business sequence includes: Assign incremental step numbers to each target business execution node according to the actual execution order of the code, identify the code semantic features of each target business execution node, label the corresponding business type based on the code semantic features, and generate a business sequence.

4. The method according to claim 1, characterized in that, After constructing a structured knowledge base using the project's global index data, the regional index data, and the interface process data, the method further includes: Construct a first-level index link from the project's global index data to the index data of each of the aforementioned regions; Construct a second-level index link from the index data of each region to the corresponding interface process data; The mapping relationship of the first-level index links is recorded in the global index data of the project, and the mapping relationship of the second-level index links is recorded in the index data of each region.

5. The method according to claim 4, characterized in that, The method further includes: Obtain the target business knowledge query request; Extract the target region identifier and the target interface identifier from the target business knowledge query request; Based on the target region identifier and the target interface identifier, the corresponding region index data is located sequentially through the first-level index link, and then the corresponding interface process data is located through the second-level index link; Extract business knowledge that matches the target query request from the located interface process data.

6. The method according to claim 1, characterized in that, The process of generating regional index data using the project's global index data and the interface entry function includes: Obtain the region identifier of each functional area from the project's global index data; Traverse the source code directory of each functional area, and scan the interface paths and request methods contained in each functional area according to the interface entry function corresponding to each functional area; Extract interface metadata from the source code corresponding to each interface; Based on the region identifier, interface path, request method, and interface metadata of each functional region, generate region index data corresponding to each functional region.

7. The method according to claim 1, characterized in that, The step of generating global index data for the project using the functional area division results includes: Identify the boundaries of each functional area in the functional area division result based on the directory structure of the source code; Extract the entry file paths and package reference relationships for each functional area; Based on the boundaries of the functional areas, the entry file paths, and the package reference relationships, determine the responsibility description information of each functional area; Write the area identifiers and corresponding responsibility descriptions of each functional area into the preset project global index template to generate project global index data.

8. A knowledge base visualization device, characterized in that, include: The system comprises a code acquisition unit, a parsing and recognition unit, a first index generation unit, a second index generation unit, an interface process generation unit, a knowledge base construction unit, and a visualization rendering unit. The code acquisition unit is used to acquire the source code of the backend project; The parsing and identification unit is used to parse the directory structure and identify the route registration entry point of the source code to obtain the functional area division results and the interface entry function corresponding to each functional area; The first index generation unit is used to generate global index data for the project using the functional area division results; The second index generation unit is used to generate regional index data using the project global index data and the interface entry function; The interface process generation unit is used to generate interface process data using the call chain corresponding to the interface entry function; The knowledge base construction unit is used to construct a structured knowledge base using the project global index data, the regional index data, and the interface process data. The visualization rendering unit is used to render according to the hierarchical structure of the structured knowledge base and generate a visualization page corresponding to the backend project.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the knowledge base visualization method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the knowledge base visualization method as described in any one of claims 1 to 7.

Images