A code generation method, apparatus and computer program product

Abstract

Embodiments of the present application disclose a code generation method and device and a computer program product. The method comprises: obtaining a requirement description of a coding task input by a user; analyzing the requirement description to obtain code scenario information, the code scenario information comprising at least one of code function, development scenario and technical stack; querying at least one knowledge base to determine at least one first specification content in the at least one knowledge base that matches the code scenario information as a candidate specification content; determining a reference specification content from the candidate specification content; and inputting the requirement description and the reference specification content into a large model to obtain code generated by the large model. The present application can improve the adaptability of code to relevant specifications.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a code generation method, apparatus, and computer program product. Background Technology

[0002] With the rapid development of artificial intelligence technology, programming techniques are gradually shifting from manual code writing to intelligent code generation, leading to the emergence of technologies that utilize large models to generate code. Large models possess powerful contextual understanding capabilities, enabling them to efficiently generate common logical code. However, currently, code generated based on large models exhibits poor adaptability to relevant specifications. Summary of the Invention

[0003] In view of this, this application provides a code generation method, apparatus and computer program product that can improve the code's compatibility with relevant specifications while automatically generating code.

[0004] This application provides the following solution: According to the first aspect, a code generation method is provided, the method comprising: Requirements description for the coding task that obtains user input; The requirement description is parsed to obtain code scenario information, which includes at least one of code function, development scenario, and technology stack. Query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content; Determine the reference specification content from the candidate specification content; Input the requirements description and the reference specification into the large model, and obtain the code generated by the large model.

[0005] According to a second aspect, a code generation apparatus is provided, the apparatus comprising: The user-side interaction unit is configured to obtain the requirement description of the coding task from user input; The requirement parsing unit is configured to parse the requirement description to obtain code scenario information, which includes at least one of code function, development scenario, and technology stack. The specification management unit is configured to query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content. The standard adjudication unit is configured to determine reference standard content from the candidate standard content; The code generation unit is configured to input the requirement description and the reference specification content into the large model and obtain the code generated by the large model.

[0006] According to a third aspect, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in any of the first aspects above.

[0007] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application parses the requirements description of the coding task to obtain code scenario information, queries matching candidate specification content based on the code scenario information, and determines the reference specification content from the candidate specification content. This ensures that the large model is constrained by the reference specification during the code generation process based on the requirements description. This method of introducing the corresponding specification content into the code generation of the large model through code scenario information effectively improves the code's adaptability to relevant specifications.

[0008] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

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

[0010] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0011] Figure 2 A flowchart illustrating the code generation method provided in this application embodiment.

[0012] Figure 3 A detailed flowchart of a code generation method provided in an embodiment of this application.

[0013] Figure 4 This is a flowchart illustrating the updating process of a knowledge base, as provided in an embodiment of this application.

[0014] Figure 5 A timing interaction diagram for the code generation method provided in the embodiments of this application.

[0015] Figure 6 A schematic diagram of the functional framework provided for embodiments of this application.

[0016] Figure 7 A schematic block diagram of a code generation apparatus provided in an embodiment of this application.

[0017] Figure 8A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

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

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

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

[0022] Currently, some AI programming assistants can automate code writing, but the output often suffers from problems such as "understanding syntax but not service specifications" and "conforming to general standards but not team specifications." This is especially true in complex cross-platform projects where different functional modules need to follow strict interface specifications, and existing methods cannot adapt to these specifications.

[0023] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: a user terminal, a code generation device located on the server side, at least one knowledge base, and an LLM (Large Language Model).

[0024] Users who need to write code can send a description of their programming task requirements to the server via their user terminal. The server-side code generation device can automatically generate code using the method provided in this embodiment and return the generated code to the user terminal. The code generation process involves querying at least one knowledge base and calling an LLM (Local Library Management System).

[0025] LLM, also known as large language model, refers to a deep learning model trained on a large amount of text data that can generate natural language text or understand the meaning of language text. Its characteristics include large scale and a huge number of parameters, and it is usually based on deep learning architectures such as the Transformer architecture. The main difference between LLM and ordinary pre-trained language models lies in the scale of parameters. When the parameter scale exceeds a certain level, the model achieves significant performance improvements and exhibits capabilities that are difficult for smaller models to achieve, such as in-context learning capabilities. It can learn complex patterns in language and perform a wide range of tasks, including text summarization, translation, sentiment analysis, multi-turn dialogue, code generation, and more.

[0026] User terminals can include, but are not limited to, smart mobile terminals, smart home devices, wearable devices, and PCs (Personal Computers). Smart mobile devices can include devices such as mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), and connected cars. Smart home devices can include smart TVs, smart refrigerators, and so on. Wearable devices can include devices such as smartwatches, smart glasses, virtual reality devices, augmented reality devices, and mixed reality devices (i.e., devices that support both virtual and augmented reality).

[0027] The code generation device can be configured as a standalone server, within a server cluster, or on a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service system, designed to address the management difficulties and weak service scalability inherent in traditional physical hosts and Virtual Private Servers (VPS) services. Besides... Figure 1 In addition to the architecture shown, the code generation device can also be set up on a computer terminal with strong computing power.

[0028] It should be understood that Figure 1 The number of user terminals, code generation devices, knowledge bases, and large language models shown is merely illustrative. Depending on implementation needs, any number of user terminals, code generation devices, knowledge bases, and large language models can be included.

[0029] Figure 2 This is a flowchart of a code generation method provided in an embodiment of this application. This method can be generated by... Figure 1 The code generation device in the system shown is executed. For example... Figure 2 As shown, the method may include the following steps: Step 201: Obtain the user-inputted description of the coding task requirements.

[0030] Step 203: Analyze the requirement description to obtain code scenario information, which includes at least one of the following: code function, development scenario, and technology stack.

[0031] Step 205: Query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content.

[0032] Step 207: Determine the reference specification content from the candidate specification content.

[0033] Step 209: Input the requirements description and reference specifications into the large model and obtain the code generated by the large model.

[0034] As can be seen from the above process, this application obtains code scenario information by parsing the requirement description of the coding task, queries matching candidate specification content based on the code scenario information, and determines the reference specification content from the candidate specification content. This ensures that the large model is constrained by the reference specification during the code generation process based on the requirement description. This method of introducing the corresponding specification content into the code generation of the large model through code scenario information effectively improves the code's adaptability to relevant specifications.

[0035] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first," "second," etc., used in this disclosure do not have limitations in terms of size, order, or quantity, but are only used to distinguish them by name. For example, "first specification content" and "second specification content" are used to distinguish different specification contents by name. Similarly, "first component," "second component," etc., are used to distinguish different components by name.

[0036] First, we will describe step 203, namely "parse the requirement description and obtain code scenario information", in detail with reference to the embodiment.

[0037] Typically, when a user starts a programming task, they can input a description of the task's requirements. In this embodiment, a user interface can be displayed to the user, which may include a first component for inputting the requirement description. The user can input the requirement description in the form of natural language instructions through the first component, or they can input the requirement description in the form of a command line. Taking natural language instructions as an example, code scenario information can be parsed from the requirement description through natural language processing. For example, key technical fields can be parsed from the requirement description through natural language processing, and code scenario information can be determined based on preset mapping rules.

[0038] The code scenario information can include at least one of the following: code function, development scenario, and technology stack. The code function mainly describes the core operations, service logic, inputs and outputs of the generated code, and can also be the functional module it belongs to (e.g., UI components). The development scenario mainly refers to the technical field (e.g., web development, embedded development), development environment (e.g., front-end, back-end, or root directory path), and technical scale (e.g., personal tools, enterprise systems). The technology stack refers to a collection of protocols (e.g., HTTP, MQTT), tools, frameworks (e.g., React, Android), and programming languages ​​(e.g., Python, Java, JS) used in software development, system construction, and other technical practices to achieve specific functions.

[0039] Specifically, it can be like Figure 3 As shown, after the user inputs a requirement description, the code generation device parses the requirements, locates the development scenario, and identifies the technology stack. Specifically, the technology stack type can be determined by performing feature analysis on the project files associated with the requirement description. This feature analysis can include analyzing features such as the project file format, file content, and file relationships.

[0040] As can be seen, in this application, users only need to input the requirement description of the coding task into the user interface to parse the requirement description and automatically realize the mapping of requirements to scenarios, thereby providing a foundation for subsequent querying and acquisition of specification content.

[0041] The following describes in detail step 205, namely, "querying at least one knowledge base and determining at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content", with reference to the embodiments.

[0042] This application's embodiments may involve various knowledge bases, primarily including local knowledge bases and MCP (ModelContext Protocol) server-side knowledge bases. For example, Figure 3As shown, the knowledge base is queried. The local knowledge base includes the local default knowledge base and the project knowledge base. It can also include a knowledge base pulled from a remote device, called a remote knowledge base. Knowledge base queries can be implemented using an LLM model. For example, code scenario information can be provided to the LLM, which then queries the local knowledge base and the MCP server-side knowledge base for the corresponding specifications.

[0043] The local default knowledge base primarily stores project-level or global-level specifications. The engineering knowledge base primarily stores engineering-level specifications. Knowledge bases pulled from remote devices can be user-configured personalized knowledge bases, storing various user-defined specifications.

[0044] In this embodiment, users can add any valid Git repository address via a user interface or command line. As one possible implementation, the user interface can also include a second component for configuring the repository address and a third component for maintaining the repository status. Users can input the repository address (e.g., a Git repository address) through the second component and set the repository address's status information (e.g., enabled or disabled) through the third component. It can be seen that users can flexibly configure enabled repository addresses visually, making the process more intuitive and convenient.

[0045] Taking a Git repository address as an example, a Git repository address is a string used to uniquely identify the location of a remote Git repository. Through this address, Git tools can locate the knowledge base hosted on a remote device. Git is a distributed version control system whose core function is to track and manage the historical changes of files (such as shared public resource files within a project), facilitating collaborative development, reverting to older versions, and resolving code conflicts. When the code generation service starts, it scans for Git repository addresses pre-configured by the user and marked as enabled. Using the Git repository address, it retrieves the corresponding knowledge base from the remote device and downloads it locally (i.e., to the local cache directory). In subsequent embodiments, the knowledge base retrieved from the remote device and downloaded locally is referred to as the remote knowledge base.

[0046] In this way, users can customize specifications by specifying the storage location of service specifications, project specifications, team specifications, etc., that the code must follow during programming as a repository address. These can be added and enabled through the user interface. When the code generation service starts, it scans the user-added repository address, retrieves the corresponding knowledge base from the remote device, and downloads it locally. The user-customized specifications are then used as constraints in the generated code. This approach is flexible, allowing users to configure specifications according to their needs, achieving "plug and play" functionality.

[0047] The knowledge base obtained and downloaded from a remote device to the local machine, i.e., the remote knowledge base, can be indexed using index files, such as a structured indexing strategy. Taking a structured indexing strategy as an example, structured descriptive information can be used in the root file to index the specification content. This structured descriptive information can include file path indexes, code scenario information, and specification descriptions (such as how the specification corresponds to the model usage). For example: ~ / Documents / AAA / Docs / android / android-network-rules.md #Android Network Usage Guidelines ~ / Documents / AAA / Docs / android / android-log-rules.md #Android logging usage guidelines ~ / Documents / AAA / Docs / android / android-imageloader-rules.md #Android Image Loading Usage Guidelines The three structured descriptive information above are examples listed above. The content before ".md" reflects the file path index. For example, "~ / Documents / AAA / Docs / android / android-network-rules" reflects the path index of a network usage specification. "Android" reflects the code scenario information, and "network usage specification" reflects the model usage method corresponding to the specification.

[0048] This approach can directly and efficiently locate the specification content that matches the code scenario information through the index of the directory layer, thereby reducing the token consumption generated by LLM when querying the knowledge base (because without the index of the directory layer, it is necessary to search through the specification content of the entire knowledge base, resulting in a large number of redundant tokens, while with the index of the directory layer, it is only necessary to search within the index of the directory layer to achieve a match), and greatly improving the accuracy of specification queries.

[0049] In addition to querying the local knowledge base, at least one of the aforementioned knowledge bases also includes an MCP server-side knowledge base. An MCP server is a standardized tool used to connect an LLM (Local Library Management System) with external tools, data sources, or services. Essentially, an MCP server is a program running locally or in the cloud, communicating with AI clients via standard input / output or streaming protocols. MCP servers have functions such as directly querying the knowledge base and reading local files or cloud storage.

[0050] The code generation device can send a query request carrying code scenario information to the MCP server, retrieve at least one second specification content that matches the code scenario information from the MCP-side knowledge base; convert the at least one second specification content into a unified format; and use the converted at least one second specification content as candidate specification content. This method can recall richer specifications, providing standardized constraints for subsequent LLM code generation, and unifying coding style and specifications.

[0051] like Figure 3 As shown, the MCP server-side knowledge base may include at least one of a document knowledge base, a RAG (Retrieval-Augmented Generation) knowledge base, and an interface knowledge base. The document knowledge base is typically located in the cloud and is primarily used to store interface (API) specification content, referred to as the first interface specification content in this embodiment. The first interface specification content matching the code scenario information can be queried from the document knowledge base. For such a large volume of knowledge as interface specifications, to reduce storage resource consumption and improve query efficiency, the first interface specification content can be stored in the document knowledge base as a summary. To distinguish different technology stacks, the summary includes the interface name and interface description. In other words, storing the specification content in the form of knowledge blocks increases information density and effectively reduces noise in the determined reference specification content, thereby improving the accuracy of code generation.

[0052] The RAG knowledge base primarily comprises structured multimodal knowledge units. Its design goal is to provide accurate contextual support for large models, addressing issues such as information lag during generation, missing domain knowledge, and technology stack mismatch. Data types can cover all modalities. In this embodiment, RAG specifications matching code scenario information can be queried within the RAG knowledge base. One feasible approach is to store RAG specifications in the form of a knowledge graph within the RAG knowledge base, upgrading the specifications from fragmented to a reasonable, interconnected network. Compared to traditional specifications stored as data blocks, this enables more precise queries and aids subsequent LLM logical reasoning, effectively improving the accuracy of generated LLM code.

[0053] The API knowledge base primarily includes API usage instructions. This involves searching the knowledge base for second-level API specifications that match the code scenario information. These second-level API specifications include usage instructions. These usage instructions are typically in unstructured document format and can include specific API definitions, parameter descriptions, usage examples, and preferred practices. This effectively improves the completeness of RAG recall, thereby significantly enhancing the accuracy of subsequent LLM-generated code.

[0054] As can be seen, the methods provided in this application include structured index-type specifications and unstructured tool-type specifications, which can effectively cover more coding scenarios.

[0055] Furthermore, when querying at least one knowledge base, the queries can be performed in parallel or sequentially. When querying sequentially, the knowledge bases can be queried according to a preset priority. The priority of each type of knowledge base can be: local default knowledge base > project knowledge base > remote knowledge base > remote knowledge base > MCP server-side knowledge base.

[0056] The following describes step 207, namely "determining reference specification content from candidate specification content", in detail with reference to the embodiments.

[0057] It should be noted that a coding task can typically be broken down into multiple query tasks. For example, a programming task might be broken down into: interface specification query, parameter validation specification query, security specification query, error handling specification query, code style specification query, code framework specification query, etc. Each query task executes the query described in step 205. If a query task yields only one candidate specification, that candidate specification can be directly used as the reference specification. If a candidate query task yields multiple candidate specification contents, there may be conflicting candidate specification contents among these multiple candidate specification contents. Therefore, if... Figure 3 As shown, conflict detection can be performed on multiple candidate specification contents. If multiple candidate specification contents conflict with each other, a weight score is determined for each of the following: timeliness, frequency of use, priority of the knowledge base type to which the candidate specification contents belong, and semantic similarity with the requirement description. Based on the weight score, one candidate specification content is selected from the multiple candidate specification contents that conflict with each other as the reference specification content.

[0058] Common types of conflicts between candidate specification contents can include situations where the constraints of two candidate specifications cannot be simultaneously followed for the same constraint object. For example, two candidate specifications might have completely different naming conventions for the same function name. Another type of conflict could involve two specifications whose constraint objects have dependencies but are mutually exclusive. For instance, one specification might require token verification before API calls, while another might prohibit token verification. Conflict detection can be based on predefined rules, utilize large models for logical reasoning, or combine both methods.

[0059] When determining the weight scores of multiple conflicting candidate specification contents, a scoring method based on multidimensional dynamic weights is used. For example, the following formula can be used to determine the scores of candidate specification contents. Priority_Score : Priority_Score = Freshness_Weight + Semantic_Weight + Usage_Weight + Layer_Weight; in, ; Semantic_Weight = cosine_similarity ( rule_desc, user_intent ); Days_since_updage The version update time of the candidate specification content. cosine_similarity(rule_ desc, user_intent) To calculate the semantic similarity between candidate specification content and user-input requirement description, usage_ count The maximum number of times the candidate specification content is invoked (reflecting usage frequency). _usage This represents the maximum number of times a candidate specification is invoked among the aforementioned candidate specification contents. For example, suppose there are three candidate specification contents, A, B, and C, which are invoked 0, 99, and 9999 times respectively. Then, the maximum number of times each candidate specification content A, B, and C is invoked is... usage_count The values ​​are 0, 99, and 9999 respectively, and the maximum value is... _usage It is 9999. Layer_Weight is The priority value of the knowledge base type to which the candidate specification content belongs is determined, for example, the priority value of the local default knowledge base, the priority value of the engineering knowledge base, the priority value of the remote knowledge base, and the priority value of the MCP server-side knowledge base decreases in that order. , , and The weighting coefficients are adjustable and can be optimized based on user feedback on the generated code.

[0060] After determining the weight scores of multiple conflicting candidate specification contents, the candidate specification content with the highest weight score can be selected as the reference specification content for the query task.

[0061] This multi-dimensional dynamic scoring method, based on timeliness, frequency of use, knowledge base type, and semantic similarity to the requirement description, can accurately adjudicate conflicting specifications, effectively improving the accuracy of reference specification content and thus enhancing the accuracy of code generated by the LLM model.

[0062] Furthermore, in this embodiment, the determined reference specification content can be displayed to the user through a user interface, and real-time feedback can be obtained from the user. For example, if the user finds an error in the determined reference specification content, they can report the erroneous specification content. Accordingly, the code generation device can delete the erroneous specification content from the reference specification content based on the user feedback, so that it will not be used as a reference and constraint for the large model in the next step. This feedback can also be used for updating the knowledge base, for example, deleting specification content whose reported error count meets the requirements from the knowledge base.

[0063] The following describes step 209, namely "inputting the requirement description and reference specification content into the large model and obtaining the code generated by the large model," in detail with reference to the embodiments.

[0064] In this step, the reference specification content can be converted into a preset format (such as JSON Schema, Markdown, etc.) and used as a Prompt Context to generate a Prompt along with the requirement description. The Prompt is then input into the LLM, which generates the code.

[0065] The code generated by LLM can be displayed to the user on the user interface. For example... Figure 3 As shown, users can provide feedback on the code, such as acceptance or rejection, satisfaction rating, etc. The code generation device can acquire user feedback on the code; in response to feedback including negative feedback (e.g., the user chooses to reject the generated code, or the satisfaction rating is very low, or the user points out errors in the specification), the reference specification content is marked as an error based on the negative feedback; the algorithm parameters used to determine the reference specification content (e.g., the score for determining candidate specification content) are adjusted based on the error-marked reference specification content. Priority_Score The optimization is performed using the weighting coefficients used, the priority of knowledge base types, etc., or at least one knowledge base version strategy (the version management of knowledge bases will be detailed in subsequent embodiments).

[0066] As can be seen, this application can realize a closed-loop mechanism for continuous improvement based on user feedback, and continuously optimize the algorithm parameters and / or knowledge base version management strategy used to determine the reference specification content, so that the obtained reference specification content can be continuously accurate, and the code content generated by LLM can better meet the user's programming needs.

[0067] In this embodiment of the application, the knowledge base can be updated and version managed to keep pace with code changes. Figure 4 A flowchart illustrating the updating process of a knowledge base is provided for an embodiment of this application, such as... Figure 4 As shown, the following steps may be included: Step 401: Use Git Hooks set in the code repository to monitor updates to the code repository.

[0068] Git Hooks are "hook scripts" embedded in Git workflows that run automatically before or after specific operations. When a developer pushes code to a code repository, the Git Hook set in the code repository will be automatically triggered, capturing key information such as the pushed branch, commit history, and changes.

[0069] Step 403: In response to the detection of code updates in the code repository, the changed code content is detected to extract new specification content. The detection includes at least one of interface update detection, component modification detection, and configuration change detection.

[0070] This step first uses at least one of interface update detection, component modification detection, and configuration change detection to accurately locate the code change and determine the actual modified code segment. The modified code segment is then structurally parsed to extract core code elements. Based on these extracted elements, implicit specification content is identified through pattern matching, analysis, and comparison with historical specifications. This includes extracting at least one specification element from conceptual terminology, code structure, scenario practice content, and summarized domain knowledge. The extracted specification content is then transformed according to the corresponding knowledge carrier, and the transformed specification content becomes the new specification content. For example, for a remote knowledge base, the extracted specification content can be transformed into an index file; for a document knowledge base, it can be transformed into a summary; for a RAG knowledge base, it can be transformed into nodes in a knowledge graph; and so on. It can be seen that in this embodiment, the five categories of specification content can be stored using at least three knowledge carriers, greatly ensuring support for various specifications and facilitating subsequent LLM calls.

[0071] Step 405: Update at least one knowledge base with the new specification content, and perform version management on the specification content in the updated knowledge base.

[0072] In this embodiment, version management can be implemented for the specification content in the knowledge base to address the needs of knowledge iteration, scenario differences, and compliance traceability. For example, specification modifications may contain errors, and maintaining multiple versions allows for direct identification of historical states. Furthermore, the same specification may need to meet different scenario requirements; different development environments may have different specifications, and specifications for different users may differ, and so on.

[0073] The same specification can be stored hierarchically in the knowledge base directory using the format of "specification name-version number". For example, in a technical specification, the content of the specification "database connection configuration" can be divided into "development environment version v1.0" and "production environment version v2.0, etc."

[0074] Additionally, expiration dates can be set for some specifications in the knowledge base. The specifications in the knowledge base can be checked regularly, and those that have exceeded their expiration dates can be deleted or corrected to ensure the accuracy of the specifications in the knowledge base.

[0075] The essence of the above process is to detect interface changes, component modifications, configuration changes, etc. from the changed code content, and to extract implicit coding conventions, design rules, interface standards, such as naming styles, comment formats, and design pattern preferences, in order to dynamically update the specification library and assist LLM in generating code that is more in line with the actual project.

[0076] Because the specifications in the knowledge base are version-specific, more detailed differentiation can be made based on version when querying the knowledge base. For example, development scenarios identified from requirement descriptions can include code context information. Figure 1 In step 205, when querying at least one knowledge base, at least one first specification content that matches the code scenario information in at least one knowledge base can be identified first. If the matched first specification content has only one version, the first specification content corresponding to that version can be directly used as the candidate specification content. If the matched first specification content contains multiple versions, the first specification content corresponding to one version can be further identified as the candidate specification content based on the code context information.

[0077] For example, a user's coding task is to "add a form validation tool to an existing front-end project for use on the login page." Analysis reveals the code context: the current project uses an ES6 module system, and the existing login module uses ES6 import syntax. When querying the export specification, it's determined that there are two versions: v1.0 for ES6 modules and v2.0 for CommonJS. Based on the code context, export specification v1.0 is chosen as the candidate specification.

[0078] In this way, it is possible to support the dynamic updating of specification content with the code, ensuring the flexibility of knowledge iteration, while avoiding the chaos and loss of historical information caused by the modification of specification content, thereby ensuring the stability and security of specification content.

[0079] Figure 5 A timing interaction diagram for the code generation method provided in the embodiments of this application, such as Figure 5 As shown, the timing sequence may include: Step 501: The code generation service obtains the user's input description of the coding task requirements, such as "Write an Android network request function".

[0080] Step 502: The code generation service parses the requirement description, including calling the technology stack identifier to identify the technology stack.

[0081] Step 503: The technology identifier analyzes the characteristics of the project files and detects the project configuration files, and obtains that the technology stack type is Android project.

[0082] Step 504: The technology identifier returns technology stack information to the code generation device.

[0083] Step 505: The code generation service sends a specification query request to the specification manager, which carries the technology stack information.

[0084] Step 506: The specification manager performs parallel queries on multiple knowledge bases, which may include the following four query processes: Query 1: The specification manager queries the local default knowledge base for global-level specifications, retrieves Android-related specifications from it, and returns local Android-related global-level specifications from the local default knowledge base.

[0085] Query 2: The specification manager queries the local default knowledge base for engineering-level specifications, retrieves Android-related specifications from it, and returns the local Android-related engineering-level specifications from the local default knowledge base.

[0086] Query 3: The specification manager queries the Git service for specifications in the remote knowledge base, retrieves Android-related specifications, and the Git service returns the Android-related remote specifications.

[0087] Query 4: The Rule Manager sends a query request to the MCP server, containing technology stack information. The MCP server searches the RAG knowledge base, queries the document knowledge base for matching interface specifications, and queries the interface knowledge base for API usage instructions. After processing, it returns the RAG enhancement specifications and interface information.

[0088] Step 507: The specification manager can also perform knowledge freshness checks, which means it can check the knowledge base version status with the knowledge production engine.

[0089] Step 508: The knowledge production engine analyzes the code change history, triggers enhanced knowledge updates, and returns the latest knowledge status to the specification manager.

[0090] Step 509: The specification manager starts the priority adjudication engine to perform conflict detection and priority adjudication (i.e., weight scoring) of the acquired specifications (i.e., multiple candidate specifications).

[0091] Step 510: The priority adjudication engine performs conflict detection and weight scoring on multiple candidate specifications and selects the reference specification content.

[0092] Step 511: The priority adjudication engine returns the reference specification content to the specification manager.

[0093] Step 512: The specification manager sends the reference specification content to the MCP server for multimodal knowledge fusion.

[0094] Step 513: Inject the structured knowledge of the reference specification content obtained after MCP server fusion, along with the requirement description, into the LLM.

[0095] Step 514: LLM generates code based on structured knowledge derived from the requirements description and reference specifications.

[0096] Step 515: The LLM returns the generated code to the code generation service, which in turn returns it to the user.

[0097] Step 516: The user provides feedback on the code, and the feedback is sent to the feedback collector.

[0098] Step 517: The feedback collector records user feedback and sends it to the priority decision engine.

[0099] Step 518: The priority decision engine optimizes algorithm parameters based on user feedback.

[0100] Step 519: The feedback collector updates the specification using statistics and version control, and synchronizes it with the specification manager.

[0101] Step 520: The specification manager triggers the Git service to optimize the specification version policy.

[0102] Based on the above embodiments, the entire implementation framework for code generation can be divided into several functional layers, such as... Figure 6 As shown in the diagram, the user-inputted requirement description is parsed by the scene recognition layer to obtain code scene information. Identification of the technology stack is a crucial component of this process; therefore, the scene recognition layer may include… Figure 5The technology stack identifier involved in the timeline shown. Based on the identified code scenario information, various types of specifications are obtained from the local knowledge base and the MCP server-side knowledge base. For example, the local knowledge base includes a local default knowledge base, an engineering knowledge base, and a remote knowledge base, while the MCP-side knowledge base includes a document knowledge base, a RAG knowledge base, and an interface knowledge base. The specification content obtained from each knowledge base is used as candidate specification content, as detailed in the previous embodiments. Then, the priority adjudication layer performs conflict detection and priority adjudication (i.e., determines the weight score of each candidate specification content) on the candidate specification content, and finally determines the reference specification. The knowledge fusion and structuring layer fuses and structures the reference specification, and then inputs it into the LLM to generate code. After the user provides feedback on the code, the feedback optimization and continuous learning layer collects the feedback and provides it to the priority adjudication layer and the knowledge production and preservation layer. The priority adjudication layer can optimize the algorithm parameters based on user feedback. The knowledge production and preservation layer can optimize the version strategy based on user feedback.

[0103] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0104] According to another embodiment, a code generation apparatus is provided. Figure 5 This is a schematic block diagram of a code generation apparatus provided in an embodiment of this application. Figure 5 As shown, the device 700 may include: a user-side interaction unit 701, a requirement analysis unit 702, a specification management unit 703, a specification adjudication unit 704, and a code generation unit 705, and may also include: a version service unit 706. The main functions of each component are as follows: User-side interaction unit 701 is configured to obtain the requirement description of the coding task input by the user.

[0105] The requirement parsing unit 702 is configured to parse the requirement description to obtain code scenario information, which includes at least one of the following: code function, development scenario, and technology stack.

[0106] The specification management unit 703 is configured to query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content.

[0107] The standard adjudication unit 704 is configured to determine the reference standard content from the candidate standard content.

[0108] Code generation unit 705 is configured to input the requirements description and reference specification content into the large model and obtain the code generated by the large model.

[0109] As one possible approach, at least one knowledge base includes a local knowledge base, which comprises a knowledge base that has been pre-acquired from a remote device and downloaded to the local machine based on a user-specified repository address.

[0110] Version service unit 706 is configured to scan for repository addresses that are pre-configured by the user and marked as enabled, and use the repository address to obtain the corresponding knowledge base from the remote device and download it to the local machine.

[0111] As one possible implementation method, the user-side interaction unit 701 can be specifically configured to: display a user interface, the user interface including a first component for inputting a requirement description, a second component for configuring a repository address, and a third component for maintaining the repository address, and obtain the requirement description of the coding task input by the user through the first component.

[0112] The user-side interaction unit 701 can also be configured to obtain the warehouse address input by the user through the second component and the status information set by the user for the warehouse address through the third component, including the enabled or disabled status.

[0113] As another possible implementation, at least one of the above knowledge bases includes an MCP server-side knowledge base; the specification management unit 703 can be specifically configured to: send a query request carrying code scenario information to the MCP server, obtain at least one second specification content that matches the code scenario information obtained by the MCP server from the MCP-side knowledge base; convert at least one second specification content into a unified format; and use the converted at least one second specification content as candidate specification content.

[0114] When the specification management unit 703 retrieves at least one second specification content that matches the code scenario information from the MCP-side knowledge base, it may specifically execute at least one of the following: Search the document knowledge base for the first interface specification content that matches the code scenario information. The first interface specification content is stored in the document knowledge base in the form of a summary, which includes the interface name and interface description. The retrieval enhancement generates RAG specifications by querying the RAG knowledge base and matching the code scenario information. The RAG specifications are stored in the RAG knowledge base in the form of a knowledge graph. Search the API knowledge base for the second API specification content that matches the code scenario information. The second API specification content includes API usage instructions.

[0115] Furthermore, version service unit 706 can also be configured to: monitor code repository updates using GitHooks set in the code repository; and in response to detecting code updates in the code repository, detect the changed code content to extract new specification content, including at least one of interface update detection, component modification detection, and configuration change detection.

[0116] The specification management unit 703 can also be configured to update at least one knowledge base with new specification content and to perform version management on the specification content in the updated at least one knowledge base.

[0117] As one possible approach, the development scenario includes code context information; the specification management unit 703 can be specifically configured to: query at least one knowledge base, determine at least one first specification content in the at least one knowledge base that matches the code scenario information; if the first specification content contains multiple versions, determine the first specification content corresponding to one version as a candidate specification content based on the code context information.

[0118] As one possible implementation, at least one candidate specification content can be multiple candidate specification contents; the specification adjudication unit 704 can be specifically configured to: perform conflict detection on multiple candidate specification contents; if there are multiple conflicting candidate specification contents, determine the weight score of each of the multiple conflicting candidate specification contents based on at least one of the following: timeliness, frequency of use, priority of the knowledge base type to which the candidate specification contents belong, and semantic similarity with the requirement description; based on the weight score, determine one candidate specification content as the reference specification content from the multiple conflicting candidate specification contents.

[0119] Furthermore, the user-side interaction unit 701 can also be configured to: display the code generated by the large model; and obtain user feedback on the code. In response to feedback including negative feedback, the reference specification content is marked as incorrect based on the negative feedback; the incorrectly marked reference specification content is fed back to the specification adjudication unit 704 and the version service unit 706, so that the specification adjudication unit 704 and the version service unit 706 can respectively optimize the algorithm parameters or at least one knowledge base versioning strategy used to determine the reference specification content based on the incorrectly marked reference specification content.

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

[0121] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0122] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0123] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0124] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0125] in, Figure 8An exemplary architecture of an electronic device is shown, which may include a processor 810, a video display adapter 811, a disk drive 812, an input / output interface 813, a network interface 814, and a memory 820. The processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, and memory 820 can communicate with each other via a communication bus 830.

[0126] The processor 810 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0127] The memory 820 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 820 can store the operating system 821 for controlling the operation of the electronic device 800, and the basic input / output system (BIOS) 822 for controlling the low-level operations of the electronic device 800. Additionally, it can store a web browser 823, a data storage management system 824, and a code generation device 500, etc. The aforementioned code generation device 500 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when the technical solution provided in this application is implemented through software or firmware, the relevant program code is stored in the memory 820 and executed by the processor 810.

[0128] The input / output interface 813 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0129] Network interface 814 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0130] Bus 830 includes a pathway for transmitting information between various components of the device, such as processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, and memory 820.

[0131] It should be noted that although the above-described device only shows the processor 810, video display adapter 811, disk drive 812, input / output interface 813, network interface 814, memory 820, bus 830, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0132] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0133] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A code generation method, characterized in that, The method includes: Requirements description for the coding task that obtains user input; The requirement description is parsed to obtain code scenario information, which includes at least one of code function, development scenario, and technology stack; Query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content; Determine the reference specification content from the candidate specification content; Input the requirement description and the reference specification into the large model, and obtain the code generated by the large model.

2. The method according to claim 1, characterized in that, The at least one knowledge base includes a local knowledge base, which includes a knowledge base that is pre-acquired from a remote device and downloaded to the local machine according to a repository address specified by the user. Before querying at least one knowledge base, the method further includes: Scan the repository addresses that are pre-configured by the user and marked as enabled, use the repository addresses to obtain the corresponding knowledge base from the remote device and download it to the local machine.

3. The method according to claim 2, characterized in that, The process of obtaining the user-inputted coding task requirement description includes: displaying a user interface, the user interface including a first component for inputting the requirement description, a second component for configuring the repository address, and a third component for maintaining the repository address; and obtaining the user-inputted coding task requirement description through the first component. The method further includes: obtaining the warehouse address input by the user through the second component and obtaining the status information of the warehouse address set by the user through the third component, the status information including enabled status or disabled status.

4. The method according to claim 1, characterized in that, The at least one knowledge base includes the Model Context Specification (MCP) server-side knowledge base; The step of querying at least one knowledge base and determining at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content includes: Send a query request carrying the code scenario information to the MCP server, and obtain at least one second specification content that matches the code scenario information obtained by the MCP server from the MCP side knowledge base; Transform the at least one second specification content into a unified format; The transformed at least one second specification content is used as the candidate specification content.

5. The method according to claim 4, characterized in that, The at least one second specification content that matches the code scenario information obtained from the MCP-side knowledge base includes at least one of the following: The document knowledge base is used to query the first interface specification content that matches the code scenario information. The first interface specification content is stored in the document knowledge base in the form of a summary, which includes the interface name and interface description. The search enhancement generation RAG specification that matches the code scenario information is queried in the search enhancement generation RAG knowledge base. The RAG specification is stored in the RAG knowledge base in the form of a knowledge graph. The second interface specification content, which matches the code scenario information, is queried in the interface knowledge base. The second interface specification content includes the interface usage instructions.

6. The method according to claim 1, characterized in that, The method further includes: Use hook scripts set in the code repository to monitor updates to the code repository; In response to the detection of code updates in the code repository, the changed code content is detected to extract new specification content. The detection includes at least one of interface update detection, component modification detection, and configuration change detection. The at least one knowledge base is updated using the new specification content, and version management is performed on the specification content in the updated at least one knowledge base.

7. The method according to claim 6, characterized in that, The development scenario includes code context information; The step of querying at least one knowledge base and determining at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content includes: Query the at least one knowledge base to determine at least one first specification content in the at least one knowledge base that matches the code scenario information; If the first specification content contains multiple versions, then the first specification content corresponding to one of the versions is determined as the candidate specification content based on the code context information.

8. The method according to any one of claims 1 to 7, characterized in that, The at least one candidate specification content may be multiple candidate specification contents; the step of determining the reference specification content from the candidate specification contents includes: Conflict detection is performed on the multiple candidate specification contents; If there are multiple conflicting candidate specification contents, the weight scores of the multiple conflicting candidate specification contents shall be determined based on at least one of the following: timeliness, frequency of use, priority of the knowledge base type to which they belong, and semantic similarity with the requirement description. Based on the weighted score, one candidate specification is selected from the multiple conflicting candidate specification contents as the reference specification content.

9. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain user feedback on the code; If the feedback includes negative feedback, then the reference specification content is marked as an error based on the negative feedback; Based on the error-marked reference specification content, the algorithm parameters used to determine the reference specification content or the version strategy of the at least one knowledge base are optimized.

10. A code generation device, characterized in that, The device includes: The user-side interaction unit is configured to obtain the requirement description of the coding task from user input; The requirement parsing unit is configured to parse the requirement description to obtain code scenario information, which includes at least one of code function, development scenario, and technology stack. The specification management unit is configured to query at least one knowledge base and determine at least one first specification content in the at least one knowledge base that matches the code scenario information as candidate specification content. The standard adjudication unit is configured to determine reference standard content from the candidate standard content; The code generation unit is configured to input the requirement description and the reference specification content into the large model and obtain the code generated by the large model.

11. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 9.

Images