Method and system for automatically generating technical document driven SDK (Software Development Kit) based on large model

Abstract

The invention discloses a method and a system for automatically generating a technical document driven SDK (Software Development Kit) based on a large model, and belongs to the technical field of software development and artificial intelligence. The method comprises the following steps: intelligently cutting a technical document to generate a plurality of logically independent sub-document fragments; combining the sub-document fragments with a preset generation instruction template, and inputting the combined sub-document fragments and the preset generation instruction template into a large language model; receiving a structured code snippet which is returned by the large language model and corresponds to a project structure defined in the instruction template; integrating the code snippets to generate an initial SDK; and verifying the initial SDK and performing iterative optimization according to a result until a final SDK is generated. By combining the large language model and the standardized instruction template, full-automatic and intelligent generation from the technical document to the high-quality SDK is realized, a low-efficiency development mode depending on manpower is thoroughly changed, and development efficiency, code quality and normalization are remarkably improved.

Description

Technical Field

[0001] This invention relates to the fields of software development and artificial intelligence technology, and in particular to a method and system for automatically generating technical documentation-driven SDKs based on large models. Background Technology

[0002] In the field of software development, SDKs (Software Development Kits) are the core bridge connecting third-party services (such as various cloud services, payment interfaces, push notifications, etc.) and developer applications. Their core value lies in encapsulating complex low-level communication, encryption, exception handling, and other logic, providing developers with simple, easy-to-use, and directly callable programming interfaces, thereby significantly reducing development difficulty and improving integration efficiency.

[0003] Currently, the mainstream technical solutions for generating SDKs in the industry heavily rely on manual development. The typical process is as follows: developers first need to carefully study the technical documentation (taking the API documentation as an example, this requires understanding a large amount of information such as API addresses, request parameters, response formats, signature rules, and exception codes); then, they design the SDK's project structure based on the target programming language (such as Java or Python) (usually including configuration classes, constant classes, model classes, utility classes, and service classes); finally, they manually write code to implement all functions such as parameter validation, request sending, response parsing, and exception handling.

[0004] The existing SDK generation process relies heavily on developers' ability to "understand and transform" technical documentation, and this process lacks a standardized, automated, and intelligent technical means to support it. Summary of the Invention

[0005] In view of the above-mentioned shortcomings in the fields of software development and artificial intelligence technology, the present invention provides a method and system for automatically generating SDKs based on technical documents driven by large models, which can automatically and intelligently transform technical documents into high-quality SDKs.

[0006] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0007] A method for automatically generating technical documentation-driven SDKs based on large models includes the following steps:

[0008] Intelligent segmentation of technical documents to generate multiple logically independent sub-document fragments;

[0009] The sub-document fragment is combined with a preset generation instruction template and then input into the large language model;

[0010] Receive the structured code snippet returned by the large language model, which corresponds to the project structure defined in the generated instruction template;

[0011] The structured code snippets are integrated to generate the initial SDK;

[0012] The initial SDK is verified, and iterative optimization is performed based on the verification results until the final SDK is generated.

[0013] According to one aspect of the present invention, the intelligent segmentation of the technical document is performed based on a preset semantic structure rule; the semantic structure rule is used to identify the core modules, appendix content and logical relationships between modules in the technical document, and to segment it according to page number control requirements.

[0014] According to one aspect of the present invention, the semantic structure rule includes: dividing the technical document into a basic interface module, a business interface module, a callback interface module, and an appendix module.

[0015] According to one aspect of the present invention, the semantic structure further includes subdividing modules whose content exceeds a preset threshold based on the relevance of their interface functions.

[0016] According to one aspect of the invention, the generated instruction template specifies the development specifications, project structure, and core functional components that must be implemented for the target programming language.

[0017] According to one aspect of the present invention, the project structure includes a configuration class, a data model class, a service client class, a utility class, an exception class, and a constant class.

[0018] According to one aspect of the present invention, the core functional components include at least one of parameter verification, signature generation, response parsing, exception handling, retry mechanism, and logging function.

[0019] According to one aspect of the invention, the integration of structured code snippets is performed based on a preset project structure template and the component type identifier of each code snippet.

[0020] According to one aspect of the present invention, the verification includes syntax verification and logic verification; the iterative optimization refers to, when the verification fails, regenerating the combined instructions for the failed part and calling the large language model again to generate code.

[0021] A technical documentation-driven SDK automatic generation system based on a large model includes:

[0022] Segmentation module: Intelligently segments technical documents to generate multiple logically independent sub-document fragments;

[0023] Input module: Combines the sub-document fragment with a preset generation instruction template and inputs it into the large language model;

[0024] Receiving module: Receives the structured code fragments returned by the large language model that correspond to the project structure defined in the generation instruction template;

[0025] Generation module: Integrates the structured code snippets to generate the initial SDK;

[0026] Iteration module: Verifies the initial SDK and iteratively optimizes it based on the verification results until the final SDK is generated.

[0027] The advantages of this invention are as follows: Through the above technical solution, it is possible to achieve fully automatic, end-to-end generation from technical documents to high-quality SDKs, which fundamentally solves the pain points inherent in manual development mode such as low efficiency, high error rate, and difficult maintenance, achieving an exponential improvement in development efficiency and a qualitative leap in code quality, and possessing powerful adaptive iteration capabilities. Attached Figure Description

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

[0029] Figure 1 This is an overall flowchart of the method and system for automatically generating technical documentation-driven SDKs based on a large model, as described in this invention.

[0030] Figure 2 This is a flowchart illustrating the method and system for automatically generating technical documentation-driven SDKs based on a large model, as described in this invention.

[0031] Figure 3 This is an application flowchart of the method and system for automatically generating technical documentation-driven SDKs based on a large model, as described in this invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Example 1

[0034] like Figure 2As shown, this invention provides a method for automatically generating SDKs based on technical documents driven by a large model. Leveraging the large model's understanding of technical documents and its code generation capabilities, it employs a workflow of "document segmentation - segmented delivery - structured output - code integration" to achieve automated and universal SDK generation without requiring manual writing of core code. The specific steps of this method are as follows:

[0035] Intelligent segmentation of technical documents to generate multiple logically independent sub-document fragments;

[0036] Step S101: Technical document preprocessing (document segmentation)

[0037] I. Document Module Splitting and Sub-Document Page Number Control Rules

[0038] 1. First, identify the core modules and appendices:

[0039] After reading through the documentation, prioritize separating the three core modules (if they exist): "1. Basic Interface Module", "2. Business Interface Module", and "3. Callback Interface Module". If there is no "Callback Interface", it should be clearly marked as "No Callback Interface Module".

[0040] Synchronously identify the appendix content and categorize it according to the appendix theme as "Appendix A: Message Encryption Rules", "Appendix B: General Signature Rules", and "Appendix C: Enumeration Value Definition" (if the original document appendix does not have a clear title, manually divide it according to the three themes of "Message Encryption", "Signature", and "Enumeration") to ensure that the appendix content is not scattered in the core module.

[0041] 2. Sub-document division of modules and appendices:

[0042] Core module splitting: If a single module (such as a business interface module) has too much content, split it into sub-modules (such as "business interface - order related sub-module") according to "interface function relevance", ensuring that each sub-module sub-document has 15-20 pages; if the module content is too little (such as only 2-3 basic interfaces), it can be merged, but the number of pages after merging should not exceed 20 pages.

[0043] Appendix splitting: If the total content of the appendix exceeds 20 pages, it shall be split into independent sub-documents according to the "Appendix Topic" (such as "Appendix Sub-document - Message Encryption and Signature Rules" and "Appendix Sub-document - Enumeration Value Definition"); if the appendix content is too short (such as only 5 pages), the appendix and "Common Content" can be merged into one sub-document, and the merged document must meet the page number requirement.

[0044] II. Key information to be extracted from a single interface (see attached appendix)

[0045] Within each independent interface unit, the following four types of core information must be extracted completely, arranged in a fixed order, and marked as "This information for this interface is not mentioned in the original document" when information is missing. Furthermore, when appendix content is involved, the appendix sub-document must be accurately referenced:

[0046] 1. API address: The complete URL (including protocol, domain name, and path, such as "https: / / api.xxx.com / v1 / user / token") needs to be extracted. If there is a distinction between environments (development / testing / production), the environment type should be listed separately.

[0047] 2. Request parameters:

[0048] Organized by "parameter name, parameter type (e.g., String / Int / Object), whether required (required / optional), parameter description, and example value"; nested parameters are displayed using a hierarchical list (first-level parameter → second-level parameter).

[0049] If the parameters involve enumeration values ​​(such as "payType: 1=WeChat, 2=Alipay"), it is necessary to mark "Enumeration value reference [Appendix Sub-document - Appendix C: Enumeration value definition - XX enumeration (such as payment method enumeration)]", and the enumeration details should not be written repeatedly.

[0050] 3. Response format: All responses should be uniformly categorized under "Common Response Format Description". The interface unit should be marked with "Response format reference [Common Content - Common Response Format Description]". If the response field involves enumeration values, it is necessary to add "Response field XX enumeration value reference [Appendix Sub-document - Appendix C: Enumeration Value Definition - XX Enumeration]".

[0051] 4. Signature and Encryption Rules:

[0052] If the interface requires signing, mark it with "Signing rules refer to [Appendix Sub-document - Appendix B: General Signing Rules]"; if message encryption is required (such as request body encryption, response decryption), mark it with "Message encryption / decryption process refer to [Appendix Sub-document - Appendix A: Message Encryption Rules]".

[0053] If an interface has special signature / encryption requirements (which conflict with or supplement the rules in the appendix), it must be marked separately as "Interface-specific signature / encryption supplementary rule: XXX", and the differences from the rules in the appendix must be explained.

[0054] III. Common Contents, Appendix Contents, and Complex Data Model Processing

[0055] 1. Common content is uniformly categorized:

[0056] After all core modules are split, a new "Common Content" section will be added (which can be a separate sub-document or combined with the appendix), which includes "Common Response Format Description" (general response structure, meaning of status codes, etc.), shown with example JSON. The interface sub-documents should only reference it and not repeat it.

[0057] 2. Standardization of Appendix Content:

[0058] Appendix A: Message Encryption Rules: The complete encryption logic (such as encryption algorithm AES-256, key generation method, encrypted field range, and decryption steps) must be extracted and described step by step with examples (such as "Example request body before encryption: XXX, after encryption: XXX") to ensure that it can be implemented.

[0059] Appendix B: General Signature Rules: Extracts the signature generation steps (parameter sorting, concatenation of the string to be signed, encryption algorithm, signature field verification logic), supplements examples (such as "Example parameter concatenation: XXX, SHA256 encrypted signature: XXX"), and replaces the original "Explanation of General Signature Rules" (to avoid duplication).

[0060] Appendix C: Enumeration Value Definitions: Organized by "Enumeration Topic" (e.g., "Payment Method Enumeration," "Order Status Enumeration," "API Return Code Enumeration"), each enumeration includes "Enumeration Value, Enumeration Meaning, and Applicable Scenarios," presented in a table (example below) to ensure clear identification when referencing various APIs.

[0061] |Enumeration Topic|Enumeration Value|Enumeration Meaning|Applicable Scenarios|

[0062] |Payment Method Enumeration|1|WeChat Pay|Order Creation Interface payType Parameter|

[0063] |Payment Method Enumeration|2|Alipay Payment|Order Creation Interface payType Parameter|

[0064] 3. Organizing complex data models:

[0065] For reusable nested models (such as "User Information Model" and "Order Details Model"), a new "General Data Model" chapter will be added (which can be merged into the common content sub-document). Each model will be organized according to "Model Name, Model Fields (Field Name, Type, Description), and Example JSON". If a model field involves enumeration values, it will be marked "Field XX Enumeration Reference [Appendix Sub-document - Appendix C: Enumeration Value Definition - XX Enumeration]".

[0066] IV. Output Format Requirements

[0067] 1. All sub-documents should be formatted using Markdown with clear hierarchy: Core module sub-documents should begin with "Document Title: XXX Module (Sub-document number, e.g., 1 / 2)", and appendix sub-documents should begin with "Document Title: Appendix Sub-document - XXX Topic (e.g., Message Encryption and Signature Rules)". Sub-documents should end with "Document Page Count: XX pages" (estimated based on A4 paper, size 5 font, single line spacing), ensuring 15-20 pages.

[0068] 2. Key information (interface address, required parameters, appendix reference path) should be bolded and highlighted; the appendix reference format should be uniformly "[Appendix Sub-document - Appendix X: XX Rule - XX Section (if any)]" (e.g., "[Appendix Sub-document - Appendix B: General Signature Rules - Signature Step 3]") to avoid ambiguity.

[0069] 3. If there are inconsistencies in the original document (such as conflicts between the interface signature rules and the appendix) or missing information (such as the appendix not explaining how to obtain the encryption key), it should be marked with "

Note

[0070] After confirming the above rules (including the processing method of the appendix content and the control of the number of pages in the sub-documents), the splitting operation can be performed on the original text of the interface document to be split based on the determined rules.

[0071] Step S102: Parameterized feeding of sub-document fragments

[0072] The segmented sub-document fragments, combined with the "SDK generation instruction template," are fed segment by segment into the large model. The "SDK generation instruction template" contains standardized generation requirements to ensure the large model output conforms to development specifications. The template format is as follows:

[0073] 1. Configuration Management Module Implementation

[0074] The configuration management module in this embodiment employs an automatic binding and verification mechanism for configuration attributes, achieving centralized management and automatic verification of configuration parameters through annotations. This module includes core configuration items such as application identifier, security key, base address, connection timeout, and read timeout, and also incorporates a retry policy configuration submodule. The retry policy supports configuration of maximum retry count limits and backoff intervals, and verifies the legality and integrity of configuration parameters through annotation verification, thus solving the technical problems of traditional scattered configurations and difficult verification.

[0075] 2. Request-Response Model Design

[0076] The request-response model in this embodiment employs generic design and an automated verification mechanism, including core fields such as application identifier, timestamp, random number, digital signature, and business data payload. The signature content is generated through tree-structured sorting and key-value pair concatenation, combined with the MD5 digest algorithm to implement digital signature functionality, effectively preventing signature verification failures caused by inconsistent parameter order. The model incorporates parameter validation rules to ensure the integrity and legitimacy of the request data.

[0077] 3. Unified Response Packaging Design

[0078] This embodiment employs generic design and a standardized status code mechanism for response encapsulation, including fields such as success status, status code, message description, business data, and timestamp. It provides a static factory method to support the rapid construction of success and error responses, standardizes the interface return data structure through a unified response format, and achieves standardized transmission of error information and unified handling of exceptional situations.

[0079] 4. Custom exception handling system

[0080] This embodiment establishes a hierarchical exception handling system, comprising three levels: basic SDK exceptions, business logic exceptions, and system-level exceptions. Each exception type encapsulates specific error codes, error messages, and original exception information, supporting the complete propagation of the exception chain. A difference in handling between exceptions of different levels is achieved through an exception classification mechanism, providing comprehensive error message recording and propagation capabilities.

[0081] 5. Implementation of the signature utility class

[0082] This embodiment's signature utility class supports multiple encryption algorithms, including MD5, SHA-256, and HMAC-SHA256, and generates the string to be signed using parameter sorting and specific concatenation rules. Through a unified signature generation and verification interface, it ensures the integrity and tamper-proof capability of the requested data. The utility class has a built-in algorithm selection mechanism to support signature requirements at different security levels.

[0083] 6. HTTP Client Core Implementation

[0084] The HTTP client in this embodiment is built on RestTemplate and integrates core functions such as connection pool management, timeout control, retry mechanism, and signature verification. The client automatically handles the serialization of request parameters and the deserialization of response data, and supports configurable retry strategies and exception handling processes. The template method pattern is used to standardize the execution of the request process, ensuring the reliability and consistency of API calls.

[0085] 7. Constant Definition Management

[0086] This embodiment uses a combination of enumeration classes and constant interfaces to define system constants, including HTTP header information, error code sets, and configuration key names. Centralized constant management eliminates magic values ​​and ensures unified maintenance of configuration information, improving code readability and maintainability.

[0087] 8. Unit test coverage

[0088] This embodiment provides a complete unit test suite, employing the JUnit5 testing framework and the Mockito simulation tool, covering normal business processes, abnormal boundary conditions, and performance testing scenarios. Test cases include multiple dimensions such as client initialization testing, API call testing, exception handling testing, and signature verification testing, ensuring the correctness and stability of the SDK functionality.

[0089] Receive the structured code snippet returned by the large language model, which corresponds to the project structure defined in the generated instruction template;

[0090] Step S103: Output structured code snippets from the large model

[0091] After receiving "instructions + sub-document fragments," the large model, based on its understanding of technical documents and code generation capabilities, outputs structured SDK code fragments. The structured output must meet the following requirements:

[0092] The code snippet contains clear "component type identifiers" (such as configuration classes, request model classes, and signature utility classes) to facilitate subsequent integration;

[0093] The code snippets follow the syntax rules of the target programming language, have no syntax errors, and include key logic comments (such as implementation comments for the signature algorithm and comments on the business meaning of exception codes).

[0094] Maintain "interface compatibility" between code snippets. For example, the method definitions of utility classes must match the calling logic of service classes, and the field definitions of model classes must be consistent with the interface parameter requirements.

[0095] For example, for the "order interface sub-document", the large model can output three structured code snippets: "order request model class (BookRequest.java)", "order response model class (BookResponse.java)" and "order service method (XxxServiceImpl#bookTicket)". The service method already contains the logic of calling the HTTP utility class to send the request and parse the response.

[0096] The structured code snippets are integrated to generate the initial SDK;

[0097] Step S104: Sandbox-based SDK verification

[0098] Syntax verification: Prepare the compilation environment in a sandbox, and perform a syntax check on the integrated SDK using the compiler / interpreter of the target programming language to ensure that there are no syntax errors (e.g., Java is compiled using javac).

[0099] Logical verification: Based on the test cases in the interface documentation (such as interface call examples), automatically generate test code for the SDK (test case code can be generated through large models), and execute tests to verify the core logic of the SDK (such as calling the order interface service class to check whether the request can be correctly assembled and the response parsed).

[0100] The initial SDK is verified, and iterative optimization is performed based on the verification results until the final SDK is generated.

[0101] Step S105: Human Enhancement

[0102] Human-enhanced instruction engineering: If problems are found during the verification process (such as the large model misunderstanding the signature rules in the document, resulting in a signature error), the large model can be re-fed with "supplementary instructions + corrected sub-document fragments" to generate corrected code fragments, replace the original erroneous fragments, and achieve iterative optimization of the SDK.

[0103] The advantages of this invention are as follows: Through an automated workflow based on a large model, it achieves efficient generation of technical documentation-driven SDKs, with a core advantage of significantly improving development efficiency and code quality. This method employs a process of "document segmentation - segmented delivery - structured output - code integration," which can automatically process large or complex technical documents (such as multi-module interface documents). Through intelligent segmentation and parameterized delivery, it ensures that the large model accurately understands the document content and generates SDK code snippets that conform to the target programming language specifications. This process eliminates the need for manual writing of core code, lowering the development threshold and avoiding human error. It also supports generalized generation, applicable to various technical documentation scenarios, achieving standardization and scalability of SDK generation.

[0104] Example 2

[0105] Example Background

[0106] like Figure 3 As shown, this embodiment demonstrates the specific process of a partner (such as a travel agency or ticket agent) using the train ticket SDK for offline ticketing. The SDK encapsulates the underlying details such as signature generation, HTTP requests, and retry mechanisms, allowing partners to quickly integrate by focusing only on business parameters. The embodiment uses the agentBook (offline ticketing) interface as an example to demonstrate the complete code implementation from SDK initialization to request and response.

[0107] Code implementation steps

[0108] Step S201: Intelligent Segmentation and Modular Processing of Complex Technical Documents

[0109] For train ticketing technical documents that include core business interfaces and appendices, intelligent segmentation is performed according to a dual dimension of "functional modules + appendices":

[0110] 1. Core module identification and segmentation:

[0111] Identify basic interface modules (such as configuration management and constant definitions), business interface modules (such as offline ticketing, refunds, and changes), and utility modules (such as signature tools and encryption tools) in the document.

[0112] Following the principle of functional aggregation, the "Offline Ticketing Related Interfaces" are treated as an independent sub-document, containing the AgentBookRequest model, ticketing business logic, and related constant definitions.

[0113] The "Configuration Management Module" is a separate sub-document containing configuration classes such as SdkConfig and HttpConfig.

[0114] 2. Special handling of appendix content:

[0115] Identify the signature rules (Appendix B), enumeration definitions (such as the ErrorCode enumeration), encryption rules, and other content in the document appendix.

[0116] The signature rules appendix has been separated into a separate sub-document, "Appendix Sub-Document - General Signature Rules," which details the logic regarding parameter sorting, signature verification, and other aspects.

[0117] The enumeration definitions have been consolidated into an appendix sub-document - Enumeration Value Definitions, which includes error code enumerations, order type enumerations, priority enumerations, etc.

[0118] 3. Establishing cross-references:

[0119] In the business interface sub-document, mark "Signature rules refer to Appendix Sub-document - General Signature Rules"

[0120] In the configuration class sub-document, note "The error code definition is referenced in the Appendix Sub-document - Enumeration Value Definition - ErrorCode Enumeration".

[0121] Ensure that each sub-document has between 15 and 20 pages.

[0122] Step S202: Modular instruction template design and parameterized feeding

[0123] Design differentiated generation instruction templates for different types of sub-documents:

[0124] Instructions for generating business interface sub-documents:

[0125] Instructions: Based on the following offline train ticketing interface documentation, generate Java SDK code (JDK17) that meets the following requirements:

[0126] 1. The code conforms to Java development standards and uses Lombok annotations to simplify the code.

[0127] 2. Includes a complete request model class (based on validation annotations), business service class, and related constant definitions.

[0128] 3. Handle logic overriding parameter validation, business exception handling, and log recording.

[0129] 4. Refer to the signature rules and enumeration definitions in the appendix to ensure code integrity.

[0130] Technical document excerpt: [Offline ticketing interface document content]

[0131] Instructions for generating appendix sub-documents:

[0132] Instructions: Generate JavaSDK utility class code based on the following signature rules outlined in the appendix document, which must meet the following requirements:

[0133] 1. Implement a complete signature generation algorithm, supporting parameter sorting.

[0134] 2. The utility class includes detailed business comments and example descriptions.

[0135] 3. Maintain interface compatibility with the main business logic code.

[0136] 4. Error handling covers all abnormal scenarios.

[0137] Technical document excerpt: [Content of the appendix sub-document of general signature rules]

[0138] Step S203: Co-code generation and structured output of large models

[0139] After receiving modularization instructions, the large model generates structured code snippets:

[0140] 1. Business module code generation:

[0141] Generate AgentBookRequest.java, which includes validation annotations such as @NotBlank and @NotNull.

[0142] Generate xxTicketClient.java, which includes business methods such as agentBook().

[0143] Generate ApiConstant.java and define request type constants.

[0144] 2. Appendix content code generation:

[0145] Generate SignUtil.java to implement the signature generation algorithm.

[0146] Generate the ErrorCode.java enumeration class and define error code constants.

[0147] Generate HeaderKey.java and define HTTP header constants.

[0148] 3. Interface compatibility guarantee:

[0149] Correctly reference utility class methods in the business code, such as SignUtil.generateSign().

[0150] Constant definitions should be consistent with business logic, such as ApiConstant.REQUEST_TYPE_AGENT_BOOK

[0151] The exception handling mechanism is unified, using the same error code enumeration.

[0152] Step S204: Intelligent integration and dependency management of multi-module code

[0153] The generated code snippets are intelligently integrated:

[0154] 1. Dependency Analysis:

[0155] Identify the reference relationships between business code and utility classes and constant classes.

[0156] Analyze inheritance and composition relationships between classes

[0157] Ensure the package structure is reasonable, such as com.xx.sdk.client, com.xx.sdk.util, etc.

[0158] 2. Code conflict detection and resolution:

[0159] Detect duplicate class definitions generated by different modules

[0160] Resolve constant definition conflicts and ensure uniqueness

[0161] Merge identical utility methods to eliminate duplicate code.

[0162] 3. Initial SDK packaging:

[0163] Organize code according to the Maven standard directory structure.

[0164] Generate the pom.xml file and define project dependencies.

[0165] Packaged into a complete SDK project

[0166] Step S205: Sandbox-based multi-dimensional verification and iterative optimization

[0167] Perform comprehensive verification on the integrated SDK:

[0168] 1. Compilation and verification:

[0169] Execute the mvncompile command in a Java sandbox environment

[0170] Verify the syntax correctness of all code snippets.

[0171] Check the integrity of dependencies.

[0172] 2. Functional verification:

[0173] Automatically generate unit test cases to verify the correctness of the signature algorithm.

[0174] Simulate business scenarios and test the complete process of the offline ticketing interface.

[0175] Verify the accuracy of the parameter validation logic.

[0176] 3. Specific verification of appendix content:

[0177] Specifically verify the consistency between the signature rules and the document appendix.

[0178] Check the matching degree between the enumeration values ​​and the document definition.

[0179] Confirm the correctness of the encryption and decryption process.

[0180] Advantages of this invention: This embodiment demonstrates the powerful ability of the method to process complex technical documents, and is particularly suitable for enterprise-level interface documents containing a large amount of appendix content, providing a complete technical solution for the automated generation of SDKs.

[0181] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for automatically generating technical documentation-driven SDKs based on large models, characterized in that, Includes the following steps: Intelligent segmentation of technical documents to generate multiple logically independent sub-document fragments; The sub-document fragment is combined with a preset generation instruction template and then input into the large language model; Receive the structured code snippet returned by the large language model, which corresponds to the project structure defined in the generated instruction template; The structured code snippets are integrated to generate the initial SDK; The initial SDK is verified, and iterative optimization is performed based on the verification results until the final SDK is generated.

2. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 1, characterized in that, The intelligent segmentation of technical documents is based on a preset semantic structure rule; the semantic structure rule is used to identify the core modules, appendix content and logical relationships between modules in the technical document, and to segment the document according to page number control requirements.

3. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 2, characterized in that, The semantic structure rules include: dividing the technical document into a basic interface module, a business interface module, a callback interface module, and an appendix module.

4. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 3, characterized in that, The semantic structure also includes a secondary division of modules whose content exceeds a preset threshold based on the relevance of their interface functions.

5. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 1, characterized in that, The generated instruction template specifies the development specifications, project structure, and core functional components that must be implemented in the target programming language.

6. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 5, characterized in that, The project structure includes configuration classes, data model classes, service client classes, utility classes, exception classes, and constant classes.

7. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 5, characterized in that, The core functional components include at least one of parameter verification, signature generation, response parsing, exception handling, retry mechanism, and logging.

8. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 1, characterized in that, The integration of structured code snippets is based on a preset project structure template and the component type identifier of each code snippet.

9. The method for automatically generating technical documentation-driven SDKs based on large models according to claim 1, characterized in that, The verification includes syntax verification and logic verification; the iterative optimization refers to regenerating the combined instructions for the failed part and calling the large language model to generate code again when the verification fails.

10. A technical documentation-driven SDK automatic generation system based on a large model, characterized in that, The method for automatically generating technical documentation-driven SDKs based on any one of claims 1 to 9 includes: Segmentation module: Intelligently segments technical documents to generate multiple logically independent sub-document fragments; Input module: Combines the sub-document fragment with a preset generation instruction template and inputs it into the large language model; Receiving module: Receives the structured code fragments returned by the large language model that correspond to the project structure defined in the generation instruction template; Generation module: Integrates the structured code snippets to generate the initial SDK; Iteration module: Verifies the initial SDK and iteratively optimizes it based on the verification results until the final SDK is generated.

Images