Code generation methods, apparatus, equipment, media and program products

Abstract

This application provides a code generation method, apparatus, device, medium, and program product, relating to the field of data processing technology, for improving the quality of code generation. The specific technical solution is as follows: Obtaining pseudocode input by a user; based on a cross-file dependency graph and the pseudocode, obtaining the relevant code corresponding to the target code entity matching the pseudocode; the cross-file dependency graph is used to represent the dependency relationships between different code entities in different code files; the cross-file dependency graph uses code entities as nodes and the call dependency relationships between code entities as directed edges; each code entity indicates a piece of code; the cross-file dependency graph and the relevant code are input into a language model, and the target code is output; wherein, the cross-file dependency graph is constructed based on at least two code files, with different code files corresponding to different functions and different code files employing different code implementation methods. This application is applied to code generation scenarios.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a code generation method, apparatus, device, medium, and program product. Background Technology

[0002] In recent years, the application of large language models has made breakthrough progress, especially in the field of code understanding and generation, where it has demonstrated powerful capabilities and has been widely used in all aspects of software development, significantly improving code writing efficiency and reducing software development costs.

[0003] Currently, existing code generation solutions mainly employ large language models combined with a Retrieval-augmented Generation (RAG) architecture. The basic principle is that during the inference phase of code generation, a retrieval system retrieves code fragments relevant to the current editing context from the code repository in real time. These retrieval results are then injected as supplementary context into the prompts of the large language model, assisting the model in generating code that meets project requirements.

[0004] However, existing code generation solutions lack a grasp of global information such as the overall architecture, module division, and call chain of the code development project when retrieving code snippets related to the current editing code context. They cannot understand the implicit relationships between code entities, resulting in poor accuracy of the retrieval results and consequently, low-quality code generated by existing code generation solutions. Summary of the Invention

[0005] This application provides a code generation method, apparatus, device, medium, and program product for improving the quality of code generation.

[0006] In a first aspect, embodiments of this application provide a code generation method, the method comprising:

[0007] Pseudocode for obtaining user input;

[0008] Based on the cross-file dependency graph and the pseudocode above, the relevant code corresponding to the target code entity that matches the pseudocode is obtained; the cross-file dependency graph above is used to represent the dependency relationship between different code entities in different code files; the cross-file dependency graph above uses code entities as nodes and the call dependency relationship between code entities as directed edges; each code entity indicates a piece of code;

[0009] Input the cross-file dependency graph and the aforementioned related code into the language model, and output the target code;

[0010] The aforementioned cross-file dependency graph is built based on at least two code files, with different code files corresponding to different functions and different code implementation methods.

[0011] The technical solution provided in this application brings at least the following beneficial effects: By constructing and introducing a cross-file dependency graph, relevant code is obtained based on the graph and pseudocode input by the user, and the cross-file dependency graph and relevant code are jointly input into the language model to output target code. Compared with related technologies, since the above-mentioned cross-file dependency graph uses code entities as nodes and the call dependency relationship between code entities as directed edges, and is constructed based on at least two code files corresponding to different functions and different code implementation methods, it breaks the boundary restrictions of physical files, accurately extracts and represents the real call dependency and implicit association between code entities across files and modules, enabling the language model to directly obtain and understand the global call chain and the overall architecture of the project when generating code, rather than relying solely on local text similarity retrieval, thereby significantly improving the accuracy of relevant code retrieval, ensuring that the target code generated by the model is deeply integrated with the existing design concept and architecture of the project, and significantly improving the quality of code generation.

[0012] One possible implementation of the above code generation method also includes:

[0013] Obtain at least two code files from the target code repository;

[0014] For each code file, change operations are performed on the import statement nodes extracted from that code file to obtain the destructive refactored code file;

[0015] Static diagnostic processing is performed on each code file and the corresponding destructed and reconstructed code file to obtain the first error offset value of each code file and the second error offset value of each destructed and reconstructed code file.

[0016] Based on the difference between the first and second error offset values ​​corresponding to each code file, the call dependencies between code entities in each code file are determined.

[0017] Based on the above call dependencies, an initial cross-file dependency graph is constructed;

[0018] The initial cross-file dependency graph was decycliced ​​to obtain the cross-file dependency graph.

[0019] Another possible implementation involves performing acyclic processing on the initial cross-file dependency graph to obtain the cross-file dependency graph, including:

[0020] Identify the strongly connected components in the initial cross-file dependency graph described above;

[0021] Each strongly connected component is folded into a corresponding first component node. The strongly connected components are formed by bidirectional imports, recursive calls, or indirect mutual references between the code entities.

[0022] The nodes mentioned above that are not included in any strongly connected components are directly used as the second component nodes;

[0023] Construct a strongly connected component agglomeration graph based on the first component node and the second component node mentioned above.

[0024] When the aforementioned strongly connected component agglomeration graph passes the topological sorting verification, it will be used as the aforementioned cross-file dependency graph.

[0025] Another possible implementation involves performing modification operations on the import statement nodes extracted from the code file, resulting in a broken, refactored code file, including:

[0026] Based on the preset change processing rules, change processing is performed on the import statement nodes extracted from the above code file to obtain the countermeasure reference code file;

[0027] The aforementioned preset change processing rules include:

[0028] When the import method of an import statement node is to import code entities from a module, determine the type of code entity imported by that import statement node;

[0029] If the type of the code entity imported by the import statement node is a class, delete the import statement node and add an empty definition of the class in the original position of the import statement node.

[0030] If the code entity imported by the import statement node is of type function or variable, delete the above import statement node;

[0031] When the import statement node is mapped to an import module, scan all attribute accesses of the code entities in the code file to the aforementioned import module, identify the code entity type corresponding to each attribute access, delete the aforementioned import statement node when the code entity type is a class, and add an empty definition of the aforementioned class to the original position of the import statement node. When the code entity type is a function or variable, delete the aforementioned import statement node.

[0032] Another possible implementation, the code generation method described above also includes:

[0033] The dependency subgraph for each code entity is obtained from the cross-file dependency graph above. The dependency subgraph for each code entity is dynamically segmented to obtain a set of code blocks.

[0034] The language model is trained based on the above set of code blocks to obtain the trained language model.

[0035] Another possible implementation involves obtaining a dependency subgraph for each code entity from the aforementioned cross-file dependency graph, dynamically segmenting the dependency subgraph, and obtaining a set of code blocks including:

[0036] If the number of characters in the code body of a code entity is less than or equal to the maximum load threshold, a breadth-first traversal is performed along the outgoing edges of the code entity in the cross-file dependency graph to obtain the dependency subgraph of the code entity.

[0037] Based on the graph step size of each dependent node in the above dependent node subgraph and the above code entity, the above dependent nodes are sorted, and the code bodies corresponding to each dependent node are concatenated based on the sorting results to obtain the concatenated code body.

[0038] If the total number of characters in the concatenated code body exceeds the maximum load threshold, the code body of each dependent node is replaced with a code entity signature to obtain the replaced dependency subgraph.

[0039] The dependent subgraph after the above replacement is dynamically segmented to obtain a set of code blocks.

[0040] Another possible implementation involves training the language model based on the aforementioned set of code blocks, resulting in a trained language model that includes:

[0041] Negative samples are obtained by injecting a predetermined proportion of random code fragments and error codes into the code blocks in the above code block set;

[0042] A fine-tuning instruction dataset is constructed based on positive samples and the aforementioned negative samples. The code blocks in the aforementioned code block set are positive samples, and each code block in the aforementioned code block set has predefined explicit boundary markers added.

[0043] The language model was trained using the fine-tuned dataset to obtain the trained language model.

[0044] Another possible way to achieve this is through the methods described above, which include:

[0045] When code files are modified, dependency re-analysis is performed on the affected set of code entities to obtain the updated dependencies;

[0046] The cross-file dependency graph is updated based on the updated dependency relationships described above.

[0047] Secondly, embodiments of this application provide a code generation apparatus, including:

[0048] The first acquisition module is used to acquire pseudocode input by the user;

[0049] The second acquisition module is used to acquire the relevant code corresponding to the target code entity that matches the pseudocode based on the cross-file dependency graph and the pseudocode mentioned above. The cross-file dependency graph is used to represent the dependency relationship between different code entities in different code files. The cross-file dependency graph uses code entities as nodes and the call dependency relationship between code entities as directed edges. Each code entity indicates a piece of code.

[0050] The output module is used to input the cross-file dependency graph and the related code mentioned above into the language model and output the target code.

[0051] The aforementioned cross-file dependency graph is built based on at least two code files, with different code files corresponding to different functions and different code implementation methods.

[0052] In one possible implementation, the code generation device further includes:

[0053] The third acquisition module is used to acquire at least two code files from the target code repository;

[0054] The change module is used to perform change operations on the import statement nodes extracted from each code file, resulting in a broken refactored code file;

[0055] The first processing module is used to perform static diagnostic processing on each code file and the corresponding destructed and reconstructed code file to obtain the first error offset value of each code file and the second error offset value of each destructed and reconstructed code file.

[0056] The determination module is used to determine the call dependencies between code entities in each code file based on the difference between the first error offset value and the second error offset value corresponding to each code file.

[0057] The building module is used to construct an initial cross-file dependency graph based on the above call dependencies;

[0058] The second processing module is used to perform acyclic processing on the initial cross-file dependency graph to obtain the cross-file dependency graph.

[0059] Another possible implementation, the second processing module described above is specifically used for:

[0060] Identify the strongly connected components in the initial cross-file dependency graph described above;

[0061] Each strongly connected component is folded into a corresponding first component node. The strongly connected components are formed by bidirectional imports, recursive calls, or indirect mutual references between the code entities.

[0062] The nodes mentioned above that are not included in any strongly connected components are directly used as the second component nodes;

[0063] Construct a strongly connected component agglomeration graph based on the first component node and the second component node mentioned above.

[0064] When the aforementioned strongly connected component agglomeration graph passes the topological sorting verification, it will be used as the aforementioned cross-file dependency graph.

[0065] Another possible implementation is that the aforementioned change module is specifically used for:

[0066] Based on the preset change processing rules, change processing is performed on the import statement nodes extracted from the above code file to obtain the countermeasure reference code file;

[0067] The aforementioned preset change processing rules include:

[0068] When the import method of an import statement node is to import code entities from a module, determine the type of code entity imported by that import statement node;

[0069] If the type of the code entity imported by the import statement node is a class, delete the import statement node and add an empty definition of the class in the original position of the import statement node.

[0070] If the code entity imported by the import statement node is of type function or variable, delete the above import statement node;

[0071] When the import statement node is mapped to an import module, scan all attribute accesses of the code entities in the code file to the aforementioned import module, identify the code entity type corresponding to each attribute access, delete the aforementioned import statement node when the code entity type is a class, and add an empty definition of the aforementioned class to the original position of the import statement node. When the code entity type is a function or variable, delete the aforementioned import statement node.

[0072] Another possible implementation of the above-mentioned code generation device includes:

[0073] The fourth acquisition module is used to obtain the dependency subgraph of each code entity from the above cross-file dependency graph, and to dynamically segment the dependency subgraph of each code entity to obtain a set of code blocks.

[0074] The training module is used to train the language model based on the above set of code blocks to obtain the trained language model.

[0075] Another possible implementation is that the fourth acquisition module mentioned above is specifically used for:

[0076] If the number of characters in the code body of a code entity is less than or equal to the maximum load threshold, a breadth-first traversal is performed along the outgoing edges of the code entity in the cross-file dependency graph to obtain the dependency subgraph of the code entity.

[0077] Based on the graph step size of each dependent node in the above dependent node subgraph and the above code entity, the above dependent nodes are sorted, and the code bodies corresponding to each dependent node are concatenated based on the sorting results to obtain the concatenated code body.

[0078] If the total number of characters in the concatenated code body exceeds the maximum load threshold, the code body of each dependent node is replaced with a code entity signature to obtain the replaced dependency subgraph.

[0079] The dependent subgraph after the above replacement is dynamically segmented to obtain a set of code blocks.

[0080] Another possible implementation is that the above training module is specifically used for:

[0081] Negative samples are obtained by injecting a predetermined proportion of random code fragments and error codes into the code blocks in the above code block set;

[0082] A fine-tuning instruction dataset is constructed based on positive samples and the aforementioned negative samples. The code blocks in the aforementioned code block set are positive samples, and each code block in the aforementioned code block set has predefined explicit boundary markers added.

[0083] The language model was trained using the fine-tuned dataset to obtain the trained language model.

[0084] Another possible implementation method for the above-mentioned code generation device includes:

[0085] The third processing module is used to perform dependency re-analysis on the affected code entity set when the code file is changed, so as to obtain the updated dependency.

[0086] The update module is used to update the cross-file dependency graph based on the updated dependencies.

[0087] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory stores a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the first aspect described above.

[0088] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0089] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0090] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0091] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0092] Figure 1 A schematic diagram of the network architecture for a code generation method application provided in this application embodiment;

[0093] Figure 2 A flowchart illustrating a code generation method provided in an embodiment of this application;

[0094] Figure 3 A flowchart illustrating another code generation method provided in an embodiment of this application;

[0095] Figure 4 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0096] Figure 5 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0097] Figure 6 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0098] Figure 7 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0099] Figure 8 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0100] Figure 9 A flowchart illustrating yet another code generation method provided in an embodiment of this application;

[0101] Figure 10 This is a schematic diagram of the structure of a code generation system provided in an embodiment of this application;

[0102] Figure 11 This application provides a schematic diagram of an offline training process.

[0103] Figure 12This is a schematic diagram of the structure of a code generation device provided in an embodiment of this application;

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

[0105] The code generation method, apparatus, device, medium, and program product provided in this application will now be described in detail with reference to the accompanying drawings.

[0106] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. 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.

[0107] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0108] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0109] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0110] The code generation method, apparatus, device, medium, and program product provided in this application embodiment can be applied in code generation scenarios.

[0111] Existing code generation solutions primarily employ large language models, combined with a Retrieval-augmented Generation (RAG) architecture. The basic principle is that during the inference phase of code generation, a retrieval system retrieves code fragments relevant to the current editing context from the code repository in real time. These retrieval results are then injected as supplementary context into the large language model's prompts, assisting the model in generating code that meets project requirements.

[0112] However, existing code generation solutions lack a grasp of global information such as the overall architecture, module division, and call chain of the code development project when retrieving code snippets related to the current editing code context. They cannot understand the implicit relationships between code entities, resulting in poor accuracy of the retrieval results and consequently, low-quality code generated by existing code generation solutions.

[0113] To address the aforementioned technical problems, embodiments of this application provide a code generation method, apparatus, device, medium, and program product. By constructing and introducing a cross-file dependency graph, relevant code is obtained based on this graph and user-input pseudocode. The cross-file dependency graph and relevant code are then input into a language model to output target code. Compared to related technologies, the aforementioned cross-file dependency graph, with code entities as nodes and the call dependencies between code entities as directed edges, and constructed based on at least two code files corresponding to different functions and code implementation methods, breaks the boundary limitations of physical files. It accurately extracts and characterizes the real call dependencies and implicit associations between code entities across files and modules. This allows the language model to directly obtain and understand the global call chain and the overall project architecture when generating code, rather than relying solely on local text similarity retrieval. This significantly improves the accuracy of relevant code retrieval, ensures that the target code generated by the model is deeply integrated with the existing design concepts and architecture of the project, and significantly improves the quality of code generation.

[0114] The code generation method, apparatus, device, medium, and program product provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0115] Figure 1 The network architecture of a code generation method application provided in an embodiment of this application is illustrated. For example... Figure 1 As shown, the network architecture includes a code generation device 101 and a terminal device 102. The code generation device 101 and the terminal device 102 are interconnected.

[0116] In some embodiments, the code generation apparatus 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster comprising multiple servers. It should be noted that the embodiments of this application do not limit the specific device form of the code generation apparatus 101. Figure 1 The code generation device 101 is used as an example of a single server.

[0117] In some embodiments, the terminal device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, with terminal device 102 as an example.

[0118] In some embodiments, the code generation device 101 responds to pseudocode sent by the terminal device 102 to execute pseudocode for obtaining user input; based on the cross-file dependency graph and the pseudocode, it obtains the relevant code corresponding to the target code entity that matches the pseudocode; the cross-file dependency graph is used to represent the dependency relationship between different code entities in different code files; the cross-file dependency graph uses code entities as nodes and the call dependency relationship between code entities as directed edges; each code entity indicates a piece of code; the cross-file dependency graph and the relevant code are input into a language model, and the target code is output; wherein, the cross-file dependency graph is constructed based on at least two code files, different code files correspond to different functions, and different code files adopt different code implementation methods. The terminal device 102 is used to send pseudocode to the code generation device 101 and receive the target code sent by the code generation device 101.

[0119] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0120] See Figure 2This is a flowchart illustrating a code generation method provided in an embodiment of this application. Figure 2 As shown, the code generation method provided in this application embodiment can be implemented by the above-mentioned code generation device, specifically including the following steps 201 to 203.

[0121] Step 201: The code generation device obtains the pseudocode input by the user.

[0122] In some embodiments, the code generation device acquires pseudocode input by the user, which is used to describe the business logic or functional intent of the code to be generated.

[0123] In some embodiments, pseudocode represents natural language or semi-structured text input by the user that describes the logic or intent of the code to be generated.

[0124] Step 202: The code generation device obtains the relevant code corresponding to the target code entity that matches the pseudocode based on the cross-file dependency graph and the pseudocode mentioned above. The cross-file dependency graph is used to represent the dependency relationship between different code entities in different code files. The cross-file dependency graph uses code entities as nodes and the call dependency relationship between code entities as directed edges. Each code entity indicates a piece of code.

[0125] In some embodiments, the code generation device performs a search and matching in the project-level code library based on the cross-file dependency graph and the aforementioned pseudocode to obtain the relevant code corresponding to the target code entity that matches the pseudocode; wherein, the aforementioned cross-file dependency graph is constructed based on code entities as nodes and the call dependency relationship between code entities as directed edges, and is constructed based on at least two code files that correspond to different functions and different code implementation methods.

[0126] In some embodiments, the cross-file dependency graph representation is a directed graph used to represent the dependencies between different code entities in different code files, and it is constructed based on at least two code files that correspond to different functions and adopt different code implementations.

[0127] In some embodiments, code entity representations indicate structural units of a piece of code, such as functions, classes, etc.

[0128] In some embodiments, call dependencies characterize the call or reference relationships between different code entities.

[0129] In some embodiments, the target code entity represents a node code entity that matches the pseudocode logic and exists in a cross-file dependency graph.

[0130] In some embodiments, the relevant code represents the actual code fragment corresponding to the target code entity obtained based on pseudocode and cross-file dependency graph retrieval.

[0131] Step 203: The code generation device inputs the cross-file dependency graph and the aforementioned related code into the language model and outputs the target code.

[0132] In some embodiments, the above cross-file dependency graph is constructed based on at least two code files, with different code files corresponding to different functions and different code implementation methods.

[0133] In some embodiments, the code generation device concatenates the cross-file dependency graph and the aforementioned related code according to a preset serialization format and inputs them into the language model, which then uses the language model to infer and output the target code in conjunction with global dependency information.

[0134] In some embodiments, the language model represents a large language model used to perform code generation tasks.

[0135] In some embodiments, the target code representation language model is based on the final code generated from cross-file dependency graphs and related code and conforms to the project architecture.

[0136] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, the code generation method provided in this application embodiment may further include the following steps 301 to 306.

[0137] Step 301: The code generation device obtains at least two code files from the target code repository.

[0138] In some embodiments, the code generation apparatus obtains at least two code files from the target code repository and uses an abstract syntax tree (AST) module to perform initial parsing and filtering of these code files, extracting all import statement nodes.

[0139] In some embodiments, a target code repository represents a project codebase containing multiple code files with different functions and different code implementations.

[0140] In some embodiments, a code file represents a physical file containing code entities and import statements.

[0141] Step 302: For each code file, the code generation device performs a change operation on the import statement nodes extracted from the code file to obtain the destructive refactored code file.

[0142] In some embodiments, the code generation device performs modification operations on the import statement nodes extracted from each code file, such as deleting the original import statement and adding an empty class definition in the same position, or directly deleting the corresponding import statement, to generate an "adversarial reference group" and obtain a destructive refactored code file.

[0143] In some embodiments, an import statement node represents a node containing code import information (such as from module import X or import module) recorded in the AST.

[0144] In some embodiments, a change operation represents an operation that deletes the original import statement and adds an empty class definition or directly deletes the missing import code of the corresponding import statement.

[0145] In some embodiments, the destructive refactored code file represents the adversarial reference group file generated after the change operation is performed.

[0146] Step 303: The code generation device performs static diagnostic processing on each code file and the corresponding destructive and reconstructed code file to obtain the first error offset value of each code file and the second error offset value of each destructive and reconstructed code file.

[0147] In some embodiments, the code generation device disables all warning levels of the static diagnostic tool, only enables NameError and AttributeError blocking, and performs static diagnostic processing on each code file and the corresponding destructive reconstructed code file to obtain the first error offset value of each code file and the second error offset value of each destructive reconstructed code file.

[0148] In some embodiments, static diagnostic processing characterizes disabling all warning levels and enabling only the static scanning process blocked by NameError and AttributeError.

[0149] In some embodiments, the first error offset value represents the error location offset obtained after performing static diagnostic processing on the original code file.

[0150] In some embodiments, the second error offset value represents the error location offset obtained after performing static diagnostic processing on the corrupted and reconstructed code file.

[0151] Step 304: The code generation device determines the calling dependency relationship between code entities in each code file based on the difference between the first error offset value and the second error offset value corresponding to each code file.

[0152] In some embodiments, the code generation device calculates the difference between a first error offset value and a second error offset value corresponding to each code file, and determines the call location, dependency type, associated file, and specific call variable based on the specific line and function context where the newly added error is captured according to the error difference, thereby determining the call dependency relationship between code entities in each code file.

[0153] In some embodiments, code entities represent specific function blocks or class definitions.

[0154] In some embodiments, call dependencies characterize specific dependencies between code entities, including call location, dependency type, associated file, specific call variables, etc.

[0155] Step 305: The code generation device constructs an initial cross-file dependency graph based on the above-mentioned call dependency relationships.

[0156] In some embodiments, the code generation device uses the above-mentioned call dependencies as original candidate dependency edges, unifies the nodes and edge directions, and constructs an initial cross-file dependency graph refined to the line level, with specific code entities as nodes and dependencies as directed edges.

[0157] In some embodiments, the initial cross-file dependency graph representation is a directed graph containing original candidate dependency edges and potentially loops.

[0158] Step 306: The code generation device performs acyclic processing on the initial cross-file dependency graph to obtain the cross-file dependency graph.

[0159] In some embodiments, the code generation device uses a depth-first traversal to identify strongly connected components in the initial cross-file dependency graph, folds components containing multiple nodes or containing self-loops into a single component node, retains only dependency edges between different component nodes to form an aggregated graph, and performs topological sorting verification to perform acyclic processing, thereby obtaining the cross-file dependency graph.

[0160] In some embodiments, acyclic processing characterizes the process of identifying strongly connected components, performing component folding, constructing an aggregated graph, and verifying topological sorting to eliminate loops.

[0161] In some embodiments, the cross-file dependency graph represents a directed acyclic graph that has undergone acyclic processing, is topologically sortable, and has code entities as nodes and dependencies as directed edges.

[0162] In this way, by using destructive refactoring and static diagnostic differential algorithms to accurately extract cross-file call candidate dependencies between code entities and performing acyclic processing, a compact cross-file dependency graph is constructed. This enables the large model to establish a project-level global view and dependency relationships, providing a data foundation for subsequently generating high-quality code consistent with the project architecture.

[0163] The code generation method provided in this application constructs and introduces a cross-file dependency graph, obtains relevant code based on this graph and pseudocode input by the user, and inputs the cross-file dependency graph and relevant code into a language model to output target code. Compared with related technologies, the cross-file dependency graph, with code entities as nodes and the call dependency relationships between code entities as directed edges, and constructed based on at least two code files corresponding to different functions and different code implementation methods, breaks the boundary limitations of physical files. It accurately extracts and represents the real call dependencies and implicit associations between code entities across files and modules, enabling the language model to directly obtain and understand the global call chain and the overall project architecture when generating code, rather than relying solely on local text similarity retrieval. This significantly improves the accuracy of relevant code retrieval, ensures that the target code generated by the model is deeply integrated with the existing design concepts and architecture of the project, and significantly improves the quality of code generation.

[0164] In some embodiments, combined with Figure 3 ,like Figure 4 As shown, step 306 above can be implemented through steps 306a to 306e.

[0165] Step 306a: The code generation device identifies the strongly connected components in the initial cross-file dependency graph.

[0166] In some embodiments, the code generation device scans the initial cross-file dependency graph using a depth-first search isograph traversal algorithm to identify loop structures, i.e., strongly connected components, that exist therein.

[0167] In some embodiments, the initial cross-file dependency graph represents an original directed graph that may contain directed loops, constructed based on call dependencies between code entities.

[0168] In some embodiments, a strongly connected component represents the largest subset of nodes in a directed graph that are reachable from any two nodes.

[0169] Step 306b: The code generation device folds each strongly connected component into a corresponding first component node. The strongly connected components are formed by bidirectional import, recursive call or indirect mutual reference between the code entities.

[0170] In some embodiments, the code generation device merges and collapses all nodes and their internal edges within each strongly connected component to form a corresponding first component node, thereby eliminating loops formed by bidirectional imports, recursive calls, or indirect references between the aforementioned code entities.

[0171] In some embodiments, the first component node represents a virtual node formed by the collapse and aggregation of strongly connected components, representing the set of all code entities within that component.

[0172] In some embodiments, code entities represent specific code structures such as function blocks or class definitions in a code file.

[0173] Step 306c: The code generation device directly uses the aforementioned nodes that are not included in any strongly connected components as second component nodes.

[0174] In some embodiments, the code generation apparatus directly extracts independent nodes that are not included in any strongly connected components, i.e., do not involve loops, as second component nodes.

[0175] In some embodiments, the second component node represents an independent original code entity node that does not form a loop in the initial cross-file dependency graph.

[0176] Step 306d: The code generation device constructs a strongly connected component agglomeration graph based on the first component node and the second component node.

[0177] In some embodiments, the code generation apparatus uses the first component node and the second component node as nodes of a new graph, and reconnects the first component node and the second component node according to the directed edges between nodes across components or between independent nodes in the original initial cross-file dependency graph, thereby constructing a strongly connected component agglomeration graph.

[0178] In some embodiments, a strongly connected component agglomerative graph represents a graph structure reconstructed from the folded first component nodes, second component nodes, and their directed edges.

[0179] Step 306e: When the strongly connected component agglomeration graph passes the topological sorting verification, the code generation device uses the strongly connected component agglomeration graph as the cross-file dependency graph.

[0180] In some embodiments, the code generation apparatus performs topological sorting on the strongly connected component agglomeration graph. If the graph can be successfully sorted in a complete topological order, it is determined to have passed the verification, and the strongly connected component agglomeration graph that has passed the verification is determined as the final cross-file dependency graph.

[0181] In some embodiments, topological sorting verification characterizes the process of linearly sorting the nodes of a directed graph to verify whether directed loops still exist in the graph.

[0182] In some embodiments, cross-file dependency graphs represent directed acyclic graphs that have undergone acyclic processing, passed topological sorting verification, and have a compact structure.

[0183] In this way, by identifying and folding strongly connected components into component nodes, and processing nodes that do not form loops separately to construct an agglomerative graph, and then ensuring acyclicity through topological sorting verification, the complex loop dependencies in the initial graph are effectively eliminated, ensuring the strict acyclicity of the cross-file dependency graph, and improving the accuracy and parsability of subsequent graph serialization input into the language model.

[0184] In some embodiments, combined with Figure 3 ,like Figure 5 As shown, step 302 above can be implemented through step 302a as follows.

[0185] Step 302a: The code generation device performs change processing on the import statement nodes extracted from the above code file based on preset change processing rules to obtain the countermeasure reference code file.

[0186] In some embodiments, the aforementioned preset change processing rules include: when the import method of the import statement node is to import code entities from a module, determining the type of the code entity imported by the import statement node; when the type of the code entity imported by the import statement node is a class, deleting the import statement node and adding an empty definition of the class to the original position of the import statement node; when the type of the code entity imported by the import statement node is a function or variable, deleting the import statement node; when the map method of the import statement node is to import a module, scanning all attribute accesses of the code entities in the code file to the imported module, identifying the code entity type corresponding to each attribute access, deleting the import statement node when the code entity type is a class, and adding an empty definition of the class to the original position of the import statement node; and deleting the import statement node when the code entity type is a function or variable.

[0187] In some embodiments, the preset change processing rule represents a differentiated processing strategy that deletes import statements or replaces them with empty definitions based on the different import methods of the import statement node and the type of the imported code entity.

[0188] In some embodiments, an import statement node represents a syntax tree node extracted from a code file for importing external modules or code entities.

[0189] In some embodiments, code entities represent classes, functions, or variables in a code file.

[0190] In some embodiments, the mind map approach represents the specific syntax of an import statement node that introduces an external dependency, including importing code entities from a module or directly importing a module.

[0191] In some embodiments, attribute access characterizes a call or reference operation made by a code entity in a code file to a member of an imported module.

[0192] In some embodiments, the code file generated after the original import dependency relationship is broken by performing change processing on the import statement node against the reference code file representation.

[0193] In some embodiments, the aforementioned adversarial reference code file is one of the aforementioned destructive reconstructed code files.

[0194] In this way, by performing differentiated deletion or empty definition replacement on import statement nodes of different types and import methods based on preset change processing rules, an adversarial reference code file with missing normal import dependencies is constructed, laying the foundation for accurately extracting implicit call dependencies between code entities through static diagnostic differential analysis.

[0195] In some embodiments, combined with Figure 2 ,like Figure 6 As shown, the code generation method provided in this application can also be implemented through the following steps 401 and 402.

[0196] Step 401: The code generation device obtains the dependency subgraph of each code entity from the above cross-file dependency graph, performs dynamic segmentation processing on the dependency subgraph of each code entity, and obtains a set of code blocks.

[0197] In some embodiments, the code generation device performs graph traversal from the aforementioned cross-file dependency graph, starting with the target code entity, to obtain the dependency subgraph of each code entity. Based on the context window length limit of the language model, the dependency subgraph of each code entity is dynamically segmented, and the dependency subgraph exceeding the length limit is divided into local subgraph segments that meet the input length requirements, thereby obtaining a set of code blocks.

[0198] In some embodiments, the cross-file dependency graph represents a directed acyclic graph constructed with code entities as nodes and the call dependencies between code entities as directed edges.

[0199] In some embodiments, a code entity represents a specific function block or class definition in a code file.

[0200] In some embodiments, the dependency subgraph represents a local graph structure centered on a specific code entity, including other code entities that its direct or indirect calls depend on, and their corresponding directed edges.

[0201] In some embodiments, dynamic segmentation processing represents the process of dynamically dividing a complete dependency subgraph into multiple code or graph fragments that meet the length requirements, based on the token length limit of the language model or the context window size.

[0202] In some embodiments, the code block set represents a set of multiple code fragments or graph fragments that meet the model input length requirements after dynamic segmentation of the dependency subgraph.

[0203] Step 402: The code generation device trains the language model based on the above code block set to obtain the trained language model.

[0204] In some embodiments, the code generation device serializes the code block set to construct instruction fine-tuning data, employs training tasks such as autoregressive or masked language modeling, and fine-tunes the parameters of the language model based on the code block set, enabling the model to learn global features across file-dependent contexts, thereby obtaining a trained language model.

[0205] In some embodiments, the language model represents the initial base large language model used to perform code generation tasks.

[0206] In some embodiments, the trained language model representation, after being trained on a set of code blocks containing cross-file dependency information, is a model with project-level global architecture understanding and cross-file code generation capabilities.

[0207] In this way, by dynamically segmenting the dependency subgraph in the cross-file dependency graph to obtain a set of code blocks that meet the length requirements, and using this set to train the language model, the limitation of the model context window length is overcome, and the model is able to learn the project-level global dependency context in depth, which significantly improves the accuracy and global consistency of the code generated by the model in complex project environments.

[0208] In some embodiments, combined with Figure 6 ,like Figure 7 As shown, step 401 above can be implemented through steps 401a to 401d.

[0209] Step 401a: When the number of characters in the code body of a code entity is less than or equal to the maximum load threshold, the code generation device performs a breadth-first traversal along the outgoing edge direction of the code entity in the cross-file dependency graph to obtain the dependency subgraph of the code entity.

[0210] In some embodiments, when the number of characters in the code body of a code entity is less than or equal to the maximum load threshold, the code generation device performs a breadth-first traversal along the outgoing edge direction of the code entity in the cross-file dependency graph, expanding and collecting relevant dependency nodes layer by layer to obtain the dependency subgraph of the code entity.

[0211] In some embodiments, the code body represents the specific code text content contained in the code entity.

[0212] In some embodiments, the maximum load threshold represents the maximum token or character length limit of the language model context window or input sequence.

[0213] In some embodiments, the outgoing edge direction represents the directed edge direction in a cross-file dependency graph from the current code entity to other code entities it calls.

[0214] In some embodiments, the dependency subgraph represents a local graph structure obtained through breadth-first traversal, starting from the current code entity and including its adjacent and multi-level dependency nodes.

[0215] Step 401b: The code generation device sorts the dependent nodes based on the graph step length of each dependent node in the dependent node subgraph and the code entity, and splices the code bodies corresponding to each dependent node based on the sorting results to obtain the spliced ​​code body.

[0216] In some embodiments, the code generation device sorts the dependent nodes in the dependent node subgraph according to the graph step length of each dependent node and the code entity in ascending order of graph step length, and splices the code bodies corresponding to each dependent node in sequence based on the sorting result to obtain the spliced ​​code body.

[0217] In some embodiments, the dependency node subgraph represents a local subgraph containing the current code entity and its dependent nodes obtained through traversal.

[0218] In some embodiments, the graph step size represents the shortest path hop count or level distance between a dependent node and the current code entity in the dependency subgraph.

[0219] In some embodiments, the concatenated code body represents the overall code text formed by sequentially concatenating the code bodies of each dependent node after sorting by graph step size.

[0220] Step 401c: If the total number of characters in the concatenated code body exceeds the maximum load threshold, the code generation device replaces the code body of each dependent node with a code entity signature to obtain a replaced dependent subgraph.

[0221] In some embodiments, if the total number of characters in the concatenated code body exceeds the maximum load threshold, the code generation device replaces the specific code body of each dependent node with a code entity signature to compress the context length and obtain a replaced dependency subgraph.

[0222] In some embodiments, the code entity signature represents the structured abstract description information of the code entity, such as its name, parameter list, and type annotations, but does not contain the specific function body implementation.

[0223] In some embodiments, the replaced dependency subgraph representation replaces the specific code body that exceeds the length limit with a local dependency graph structure that is compressed in length after the code entity is signed.

[0224] Step 401d: The code generation device performs dynamic segmentation processing on the above-mentioned replaced dependency subgraph to obtain a set of code blocks.

[0225] In some embodiments, the code generation device dynamically segments the replaced dependency subgraph according to the context load requirements of the language model, dividing it into multiple segments that meet the length limit, to obtain a set of code blocks.

[0226] In some embodiments, dynamic segmentation processing represents the operation of further segmenting the replaced dependent subgraph into local sequence fragments that can be directly processed by the model, based on the model's length constraints.

[0227] In some embodiments, the code block set represents a collection of multiple code fragments that meet the model input length requirements, obtained after dynamic segmentation of the replaced dependency subgraph.

[0228] In this way, by concatenating the code bodies of dependent nodes based on graph step size, and using code entity signatures for replacement and compression when the code is too long, and finally dynamically segmenting and obtaining a set of code blocks, the limitation of language model context length is effectively overcome. This maximizes the preservation of global dependency information of the project while improving the accuracy and efficiency of model training and inference.

[0229] In some embodiments, combined with Figure 6 ,like Figure 8 As shown, step 402 above can also be implemented through steps 402a to 402c.

[0230] Step 402a: The code generation device obtains negative samples by injecting a preset proportion of random code fragments and error codes into the code blocks in the above code block set.

[0231] In some embodiments, the code generation device injects random code fragments and erroneous code into the code blocks in the aforementioned code block set at a preset ratio to interfere with and disrupt the original valid code logic and cross-file dependency context, thereby obtaining negative samples.

[0232] In some embodiments, the preset ratio represents a fixed percentage of the injected noise code in the total length or volume of the code block.

[0233] In some embodiments, random code fragments represent code snippets randomly extracted from unrelated codebases that have no connection to the context of the current code block.

[0234] In some embodiments, an error code represents an invalid code segment containing a syntax error, a type error, or a logical flaw.

[0235] In some embodiments, negative samples represent code samples containing noise interference information and used to train the model's robustness to interference.

[0236] Step 402b: The code generation device constructs an instruction fine-tuning dataset based on the positive samples and the aforementioned negative samples. The code blocks in the aforementioned code block set are positive samples, and each code block in the aforementioned code block set has a predefined explicit boundary marker added.

[0237] In some embodiments, the code generation apparatus uses the original code blocks without injected noise in the above-mentioned code block set as positive samples, and adds predefined explicit boundary markers at the boundaries of each code block of the positive and negative samples, and constructs an instruction fine-tuning dataset based on the positive samples with explicit boundary markers and the above-mentioned negative samples.

[0238] In some embodiments, positive sample representations are pure, undamaged cross-file code blocks obtained directly from cross-file dependency graph segmentation.

[0239] In some embodiments, explicit boundary markers represent predefined special tokens or labels used to explicitly delineate the start and end positions of different code entities or code blocks in the input sequence.

[0240] In some embodiments, the instruction fine-tuning dataset represents a training data set consisting of positive and negative samples with explicit boundary labels, used for instruction fine-tuning of a large language model.

[0241] Step 402c: The code generation device trains the language model based on the fine-tuned dataset to obtain the trained language model.

[0242] In some embodiments, the code generation device trains the language model by fine-tuning parameters based on the instruction fine-tuning dataset, enabling the model to learn the ability to shield negative sample interference and extract effective dependency features of positive samples in a noisy context based on explicit boundary markers, thereby obtaining the trained language model.

[0243] In some embodiments, the language model represents the underlying large language model to be trained for performing code generation tasks.

[0244] In some embodiments, the trained language model representation, after being trained on an instruction fine-tuning dataset, is a model capable of accurately identifying valid cross-file dependency information and generating high-quality code in complex and noisy contexts.

[0245] In this way, by injecting noise to construct negative samples and combining them with positive samples with explicit boundary markers to generate instructions to fine-tune the dataset for training the language model, the model's ability to focus on effective information and resist interference in redundant or noisy contexts is effectively enhanced, and the robustness and accuracy of the model's generated code are significantly improved.

[0246] In some embodiments, combined with Figure 2 ,like Figure 9 As shown, the code generation method provided in this application embodiment may further include the following steps 501 to 502.

[0247] Step 501: When the code file is changed, the code generation device performs dependency re-analysis on the affected code entity set to obtain the updated dependency.

[0248] In some embodiments, when a code file is modified, the code generation device identifies a set of code entities affected by the modification, and re-executes dependency re-analysis processes such as destructive refactoring and static diagnosis on the code entities in the set to obtain updated dependencies.

[0249] In some embodiments, a change in a code file indicates that the file content in the code repository has undergone operations such as adding, modifying, or deleting code entities.

[0250] In some embodiments, the affected code entity set represents the set of code entities whose own or their calling dependencies have changed due to code file changes.

[0251] In some embodiments, dependency reanalysis represents the process of re-executing the extraction of import statement nodes, change operations, and static diagnostic differences for the affected code entities to obtain the latest call dependencies.

[0252] In some embodiments, the updated dependency represents the latest call dependencies between affected code entities obtained after local reanalysis.

[0253] Step 502: The code generation device updates the cross-file dependency graph based on the updated dependency relationship.

[0254] In some embodiments, the code generation device, based on the updated dependencies described above, performs corresponding addition, deletion, or modification operations on the nodes and directed edges in the original cross-file dependency graph, and re-executes the acyclic processing, thereby completing the update of the cross-file dependency graph.

[0255] In some embodiments, the cross-file dependency graph represents a directed acyclic graph constructed with code entities as nodes and the call dependencies between code entities as directed edges.

[0256] In this way, when code changes, by performing local dependency reanalysis on the affected code entity set and updating the cross-file dependency graph, the high cost of a full refactoring of the graph is avoided while ensuring that the graph is synchronized with the latest project architecture, and subsequent code generation can be based on real-time and accurate global dependency information.

[0257] The code generation method of this application is described below through specific embodiments. The code generation optimization method proposed in this application also includes an offline training stage and an online inference stage. The specific steps are as follows: Step 1: Construct a cross-file dependency graph (DCG). Specifically, taking the target code repository as input, the "Destructive Refactoring and Static Diagnostic Differentiation" algorithm (MID algorithm) is used to first accurately extract cross-file call candidate dependencies between code entities. Then, through loop detection, strongly connected component folding, and topology layering, an acyclic DCG graph with functions / classes as nodes and dependencies as directed edges is output. This graph is the common data foundation for subsequent steps, enabling the model to understand the global structure and dependencies of the project.

[0258] Step 2: Dynamic Dependency-Aware Code Segmentation Based on DCG. Specifically, using the DCG graph output from Step 1 and a preset Token threshold as input, for each core code entity, traverse its dependency subgraphs from near to far according to the dependency graph step size. Within the Token budget, prioritize including complete code bodies of near-layer dependencies. When the budget is tight, use function / class signatures for dimensionality reduction to preserve parameter contract information. When the budget is exhausted, stop expansion and output a set of code blocks with controlled length. This step reduces context length and alleviates the semantic truncation and dependency breakage problems in traditional solutions. Step 3: Cross-File Dependency Serialization and Pre-training. Specifically, using the code block set output from Step 2 as input, use an explicit boundary-marked serialization format to concatenate them into a one-dimensional sequence for pre-training the base model. This step enables the model to learn structured patterns of cross-file dependencies, establish a project-level global perspective, and improve the architectural consistency of code generation. Step 4: Dynamic Attention-Based Noise-Reducing Instruction Fine-Tuning. Specifically, using the code blocks output from Step 2 as positive samples, inject random code fragments and erroneous code with preset probabilities as negative samples to construct mixed instruction fine-tuning data. The model learns through training to autonomously filter effective information in a mixed context of positive and negative samples, enhancing the accuracy and robustness of code generation. Step 5: Online lightweight inference. Specifically, taking the user's code editing request and the current project DCG as input, the segmentation method from Step 2 is reused to recall relevant code. The recall results, along with the DCG graph, are injected into the model trained and optimized in Steps 3 and 4 to generate the target code. Step 6: Incremental update of the dependency graph. Specifically, during online inference, the codebase continuously changes. Code changes are detected through AST-level diffs, and reanalysis is selectively performed on the smallest affected area. The DCG graph is updated transactionally, ensuring that Step 5 always performs inference based on the latest dependency graph. Steps 1 to 4 constitute the offline training phase, while Steps 5 and 6 constitute the online inference phase.

[0259] Corresponding to the aforementioned code generation methods, this application provides a code generation optimization system, which includes an offline training subsystem and an online inference subsystem, which work together to improve code generation performance. The overall system architecture is as follows: Figure 10 As shown in the diagram, the code generation system consists of two subsystems: offline training and online generation. Offline training includes a data processing layer and a model training layer. In the data processing layer, codebase data is processed by A1 to generate pre-training data, and the pre-training data is processed by A2 to generate instruction fine-tuning data. In the model training layer, the base model is first pre-trained, and then the instruction fine-tuning data is combined to complete instruction fine-tuning. The online generation part includes a dependency graph (supporting initialization and incremental updates), RAG, codebase, and LLM. After the model is deployed, the trained model is connected to the online generation stage. When the user interacts with the LLM, RAG combines the update information of the codebase and dependency graph (A3, A4, and A5 indicate the data flow) to support the LLM in order to achieve code generation.

[0260] Figure 11 This application provides a schematic diagram of an offline training process, which is specifically as follows: Figure 10 The training process for the system modules in the offline training section is explained below. Figure 10 and Figure 11 The document describes an offline training subsystem containing a complete pipeline from data processing to model training. Through training with this subsystem, the base model learns patterns in the code dependency graph and the ability to resist interference by filtering attention in complex or erroneous contexts, thereby enabling the model to possess powerful code understanding and generation capabilities and reducing reliance on online retrieval systems. Specifically, it addresses... Figure 10 In the offline training subsystem, the A1 and A2 modules generate pre-training data and instruction fine-tuning data. This invention proposes a processing flow and corresponding method. After obtaining the pre-training data and instruction fine-tuning data using this invention, the model optimized with these data possesses the ability to understand code dependency graphs and resist interference from redundant or erroneous contexts. The flow is as follows: Figure 11 As shown, Figure 1 The A1 pre-training data can be used Figure 11 Obtained through steps S1, S2, and S3; Figure 1 The A2 instruction can be used to fine-tune data. Figure 11 The results are obtained through steps S1, S2, and S4. The following is a detailed explanation of each step, including:

[0261] S1: Constructing a cross-file dependency graph (DCG) is specifically for the model to understand cross-file logic. The prerequisite is that the system must accurately and completely extract the project-level call dependency network. This invention proposes a "destructive refactoring and static diagnosis comparison" algorithm (MID algorithm) to accurately strip dependencies and construct a cross-file dependency graph: (1) Initial parsing and filtering: Use the built-in AST module of Python to construct a preliminary abstract syntax tree and extract all Import and ImportFrom nodes. (2) Structured destruction and construction: For the extracted Import nodes, perform change operations (construct missing import code) to generate "adversarial reference groups" and process them according to the import form: a. For imports of the form from module import X: process them according to the actual type of X - if X is a class, delete the original import statement and add an empty definition of the class in the same position (e.g., class class name: pass), keep the class name but remove the actual implementation; if X is a function or variable, delete the corresponding import statement directly and do not add any definition; b. For imports of the form import module: first scan all attribute accesses of the module in the current file (e.g. module.ClassName, module.func_name), identify the actual type of each attribute, and then process them according to the classification logic of rule (a) - add the corresponding empty class definition for class attributes, and do not add a definition for function or variable attributes. Finally, delete the original module import statement. (3) Diagnostic differential localization: turn off all warning levels of Linter (static diagnostic) tool, and only enable NameError and AttributeError blocking. a. Perform static scanning on the original file and the file after destruction and reconstruction, and calculate the "Diff" of the error offset value. b. Based on the error difference, capture the specific line and function context where the newly added error is located, and determine the precise call relationship such as call location, dependency type, associated file, and specific call variable. (4) Graph mapping: Based on the precise relationship mentioned above in (3), construct a cross-file dependency graph (DCG) with fine detail down to the line level. The node granularity of the graph is the specific code entity (such as a specific function block or class definition), rather than the entire physical file, and the directed edges record the specific dependencies between the entities. This provides a data foundation for the subsequent local replacement strategy with precision down to the function signature. (5) Acyclic constraints and loop resolution: The dependency edges obtained in the above steps (2) and (3) are first used as the original candidate dependency edges Eraw, and are not directly written into the final DCG.Before candidate edges are added to the graph, the system performs a uniform acyclic process to ensure that the final output DCG is a topologically sortable directed acyclic graph. This includes: a. Unifying node and edge directions: For imports of the form "from module import X", the function or class that actually references X in the current file is designated as the source node, and the entity definition of X in the module is designated as the target node, generating candidate dependency edges in the "source node → target node" direction. For imports of the form "import module", the access to attributes such as module.ClassName and module.func_name is first resolved back to the corresponding class, function, or variable definition entity in the module, and then candidate dependency edges are generated in the same direction. Thus, both import forms are normalized to entity-level candidate edges. b. Identifying strongly connected components: After obtaining all candidate edges, a depth-first traversal is used to identify strongly connected components formed by bidirectional imports, recursive calls, or indirect mutual references. If a component contains only one node and has no self-loops, that node is retained directly. If a component contains multiple nodes or has self-loops, it is collapsed into a component node, with the member entity list and internal edges (member_edges) retained as metadata. c. Construct and validate the agglomerative graph: Only dependent edges are retained between different component nodes, forming a strongly connected component agglomerative graph. Since the agglomerative graph naturally does not have a path back from a component to itself, the final DCG does not contain loops. The system performs a topological sorting validation on the agglomerative graph. If sorting is not possible, it backtracks to the candidate edge set and re-executes strongly connected component folding, without writing unresolved loops into the final DCG. d. Traversal output rules: For collapsed component nodes, subsequent code expansion outputs the component's internal members in a deterministic order of file path, definition start line number, and entity name, avoiding repeated expansion through the visited set; components are strictly traversed from near to far according to the topological hierarchy. Therefore, even if the original codebase contains circular imports or recursive calls, the final DCG used for code segmentation, training data construction, and online inference remains acyclic.

[0262] The DCG graph constructed in this step is the data foundation of the entire method: Step 2 performs semantically complete code segmentation based on DCG; Steps 3 / 4 organize training data based on DCG to enable the model to learn project dependency patterns; Step 5 injects DCG into the context during the online phase, giving the model a global view of the project, thereby generating code consistent with the project architecture.

[0263] S2: Dynamic dependency-aware code segmentation based on DCG. Specifically, in order to solve the physical token upper limit limitation, the traditional approach is to forcibly cut long texts in one stroke, resulting in semantic breaks and loss of key dependencies. This invention uses the DCG map produced by S1 to propose a dynamic dependency-aware code segmentation method, which fundamentally solves the overflow and business breakage problems of long-tail inputs and ensures the semantic continuity of the context. The specific process of the method is as follows: (1) Set the threshold and locate the target node: Set the maximum load threshold Tmax of a single sequence (e.g., 8192). Take the target function or class of the current code generation task as the core node V0 (the code entity in the randomly sampled code library during the offline training stage, and the function or class that the user is currently editing during the online inference stage). (2) Breadth-first weight extraction: Calculate the token value T(V0) of the V0 code body, including: a. If T(V0)≤Tmax, then perform a breadth-first traversal along the outgoing edge direction of the node or component node where V0 is located in the acyclic DCG (i.e. the dependencies called or referenced by V0), and collect the set of dependent nodes {V1, V2, ... Vn}. During the traversal, maintain the set of visited nodes, and do not expand the visited nodes again; since the final DCG has been folded by strongly connected components and can be topologically sorted, the traversal will not return to the expanded path due to circular imports or recursive dependencies. Arrange the collected nodes in ascending order according to their graph depth from V0. b. In this ascending order, concatenate the dependent nodes Vi one by one into the context, and calculate the total number of tokens ∑T after each concatenation. (3) Syntax-safe exit boundary: When the accumulated dependent node Vk finds that the expected ∑Token>Tmax: a. Strip the complete code of Vk. b. Use only function / class signatures (with Docstring) for dimensionality reduction to avoid long text clutter and preserve the semantics of the parameter contract. c. If adding only function / class signatures still results in ∑Token>Tmax, exit the process and do not add that node or any subsequent nodes.

[0264] This step contributes to code generation by replacing traditional text similarity retrieval with deterministic dependencies in the DCG graph, including only code entities that have real call dependencies with the target code, thus excluding irrelevant code from the source and reducing context length. At the same time, it expands layer by layer from near to far according to the dependency graph step size, prioritizing the retention of complete code for near-layer dependencies within the token budget, and replacing it with function / class signature dimensionality reduction when the budget is exceeded, avoiding semantic truncation and dependency breakage, thereby significantly improving the effective information density within a limited context window and improving code generation efficiency.

[0265] S3: Cross-file dependency concatenation and serialization, specifically based on the complete closed-loop block produced by S2. To obtain pre-training corpus data, this invention adopts a serialization standard of "explicit boundary marking." When concatenating the contents of multiple files into a one-dimensional sequence for the model to read, explicit predefined reserved vocabulary is used for delimitation.

[0266] # Start boundary marker for project-level code sequences

[0267] <project_start>

[0268] # The file path identifier of the current code snippet

[0269] <file_path> src / core / main.py< / file_path>

[0270] # Begins at the cross-file dependency closure section, used to embed code from other files that the current file depends on.

[0271] <import_closure>

[0272] # The file path identifier of the cross-file code entity that is depended upon

[0273] <file_path> src / utils / helper.py< / file_path>

[0274] # Dependency function body or code entity signature extracted and embedded from cross-file dependency graph

[0275] [Resolving embedded dependency function bodies...]

[0276] # End of cross-file dependency closure section

[0277] < / import_closure>

[0278] # The core code logic body to be generated or analyzed in the current main file

[0279] [Core code body...]

[0280] # End boundary marker for project-level code sequences

[0281] <project_end>

[0282] This structure enables the attention mechanism to effectively distinguish the scope of the main code logic from that of external referenced code, thereby preventing the structured sequence of code logic from being confused.

[0283] S4: Dynamic attention-based noise-resistant cross-file instruction fine-tuning mechanism, specifically including: To improve the model's tolerance to retrieval noise, this method adopts a positive and negative sample mixed training strategy in the instruction fine-tuning stage: positive samples are constructed using the code blocks produced in S2 and their correct dependencies, and random code fragments or erroneous codes are injected as negative samples with a preset probability (e.g., 20%-30%), and then mixed for fine-tuning. Since the training objective is only associated with positive samples, the model learns the ability to filter effective information in noisy contexts through training.

[0284] For the online generation subsystem, namely the online RAG system, that is... Figure 10 In the A5 module, this application differs from traditional solutions that place all the pressure on the RAG system's heavy retrieval dependency mode. Figure 10 The architecture shown demonstrates that, through training, the large base model possesses the ability to recognize code dependency graphs and is robust to redundant or erroneous contexts. Building upon this, an online RAG system injects the dependency graph of the current project, enabling the large model to have a global view of the project and its dependencies; then... Figure 11 S2: Retrieval and recall are performed using dynamic dependency-aware code segmentation based on DCG, significantly reducing context length. In the online phase, it exhibits "lightweight integration characteristics" with extremely low resource consumption and high tolerance. The initialization of the online system dependency graph (DCG) is related to... Figure 11 While S1 remains the same, the codebase dynamically changes during user editing and large model generation, thus altering the dependency graph. To address this, this invention proposes an incremental dependency graph update method, corresponding to... Figure 10 The A4 module includes: 1. Change Detection: Precisely classifies code changes into 11 types (Import additions, deletions, modifications; entity additions, deletions, renamings; signature changes; function body changes; file additions, deletions, and renamings) through AST-level diffing. This step determines the accuracy and granularity of subsequent analysis. 2. Impact Domain Analysis: Calculates the minimum set of files / entities requiring reanalysis based on the change type. A key design decision is to distinguish between "outbound edge changes" and "inbound edge changes"—import changes only affect their own outbound edges, while entity deletions / renamings affect the inbound edges of all dependents. 3. Selective Reanalysis: Incremental MID: Performs destructive refactoring and diagnostic differencing only on a subset of changed imports, rather than a full scan of all imports in all files. Lightweight Body Scan: Replaces the full MID with AST name references for BODY_ONLY changes, resulting in extremely low overhead. 4. Graph Repair: Performs node / edge additions, deletions, and modifications in a transactional manner and corrects line number offsets. By using incremental updates, the dependency graph can be kept in sync with the latest code with minimal overhead, ensuring that the large model always maintains a correct understanding of the project as a whole and its dependencies.

[0285] In some embodiments, instead of the static analysis method of "destructive refactoring and static diagnostic differential (MID)" used in the above embodiments, a dynamic analysis method can be used. That is, unit tests or integration test cases are run in a sandbox environment, and instrumentation technology is used to trace the actual function call stack, object instantiation process, and module loading order during code execution.

[0286] In some embodiments, instead of using AST parsing and differential comparison, a dedicated graph neural network (GNN) or code-large model is trained, taking the text sequence of the code repository as input and directly outputting a dependency graph between entities.

[0287] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0288] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0289] This application embodiment can divide the code generation device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0290] In some embodiments, this application also provides a code generation apparatus. The code generation apparatus may include one or more functional modules for implementing the code generation method of the above method embodiments.

[0291] For example, Figure 12 This is a schematic diagram of a code generation device provided in an embodiment of this application. Figure 12As shown, the code generation device 900 includes:

[0292] The first acquisition module 901 is used to acquire pseudocode input by the user. The second acquisition module 902 is used to acquire the relevant code corresponding to the target code entity that matches the pseudocode based on the cross-file dependency graph and the pseudocode. The cross-file dependency graph is used to represent the dependency relationship between different code entities in different code files. The cross-file dependency graph uses code entities as nodes and the call dependency relationship between code entities as directed edges. Each code entity indicates a piece of code. The output module 903 is used to input the cross-file dependency graph and the relevant code into the language model and output the target code. The cross-file dependency graph is constructed based on at least two code files, with different code files corresponding to different functions and different code files using different code implementation methods.

[0293] The code generation device provided in this application constructs and introduces a cross-file dependency graph, obtains relevant code based on the graph and pseudocode input by the user, and inputs the cross-file dependency graph and relevant code into a language model to output target code. Compared with related technologies, the cross-file dependency graph, with code entities as nodes and the call dependency relationship between code entities as directed edges, and constructed based on at least two code files corresponding to different functions and different code implementation methods, breaks the boundary restrictions of physical files. It accurately extracts and represents the real call dependencies and implicit associations between code entities across files and modules, enabling the language model to directly obtain and understand the global call chain and the overall architecture of the project when generating code, rather than relying solely on local text similarity retrieval. This significantly improves the accuracy of relevant code retrieval, ensures that the target code generated by the model is deeply integrated with the existing design concept and architecture of the project, and significantly improves the quality of code generation.

[0294] In some embodiments, the code generation apparatus further includes:

[0295] The third acquisition module is used to acquire at least two code files from the target code repository.

[0296] The module performs a change operation on the import statement nodes extracted from each code file to obtain a destructive and reconstructed code file. The first processing module performs static diagnostic processing on each code file and its corresponding destructive and reconstructed code file to obtain a first error offset value for each code file and a second error offset value for each destructive and reconstructed code file. The determination module determines the call dependency relationship between code entities in each code file based on the difference between the first and second error offset values. The construction module constructs an initial cross-file dependency graph based on the above call dependency relationship. The second processing module performs acyclic processing on the initial cross-file dependency graph to obtain the cross-file dependency graph.

[0297] In other embodiments, the second processing module is specifically used to: identify strongly connected components in the initial cross-file dependency graph, fold each strongly connected component into a corresponding first component node, wherein the strongly connected components are formed by bidirectional imports, recursive calls, or indirect mutual references between the code entities, directly use the nodes not included in any strongly connected components as second component nodes, construct a strongly connected component agglomeration graph based on the first component nodes and the second component nodes, and use the strongly connected component agglomeration graph as the cross-file dependency graph when the strongly connected component agglomeration graph passes the topological sorting verification.

[0298] Another possible implementation is that the aforementioned change module is specifically used to: perform change processing on the import statement nodes extracted from the aforementioned code file based on preset change processing rules to obtain an adversarial reference code file. The preset change processing rules include: when the import method of the import statement node is to import code entities from a module, determining the type of the code entity imported by the import statement node; when the type of the code entity imported by the import statement node is a class, deleting the import statement node and adding an empty definition of the class to the original position of the import statement node; when the type of the code entity imported by the import statement node is a function or variable, deleting the import statement node; when the map method of the import statement node is to import a module, scanning all attribute accesses of the code entities in the code file to the aforementioned imported module, identifying the code entity type corresponding to each attribute access, deleting the import statement node when the code entity type is a class, and adding an empty definition of the class to the original position of the import statement node; and deleting the import statement node when the code entity type is a function or variable.

[0299] Another possible implementation, the code generation apparatus provided in this application embodiment further includes:

[0300] The fourth acquisition module is used to obtain the dependency subgraph of each code entity from the above cross-file dependency graph, and to dynamically segment the dependency subgraph of each code entity to obtain a set of code blocks.

[0301] The training module is used to train the language model based on the above set of code blocks to obtain the trained language model.

[0302] Another possible implementation is that the fourth acquisition module is specifically used to: when the number of characters in the code body of the code entity is less than or equal to the maximum load threshold, perform a breadth-first traversal along the outgoing edge direction of the code entity in the cross-file dependency graph to obtain the dependency subgraph of the code entity.

[0303] Based on the graph step size of each dependent node in the aforementioned dependent node subgraph and the aforementioned code entity, the aforementioned dependent nodes are sorted. Based on the sorting results, the code bodies corresponding to each dependent node are concatenated to obtain the concatenated code body. If the total number of characters in the concatenated code body exceeds the aforementioned maximum load threshold, the code body of each dependent node is replaced with the code entity signature to obtain the replaced dependent subgraph. The replaced dependent subgraph is then dynamically segmented to obtain a set of code blocks.

[0304] Another possible implementation is that the training module is specifically used to: obtain negative samples by injecting a preset proportion of random code fragments and erroneous codes into the code blocks in the code block set; construct an instruction fine-tuning dataset based on the positive samples and the negative samples; the code blocks in the code block set are positive samples; each code block in the code block set has a predefined explicit boundary marker added; and train the language model based on the fine-tuning dataset to obtain the trained language model.

[0305] Another possible implementation of the above-mentioned code generation device includes:

[0306] The third processing module is used to perform dependency re-analysis on the affected code entity set when the code file is changed, so as to obtain the updated dependency.

[0307] The update module is used to update the cross-file dependency graph based on the updated dependencies.

[0308] It should be noted that the code generation device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0309] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 13As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0310] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0311] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0312] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0313] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the code generation method provided in the embodiments of this application.

[0314] In another possible implementation, memory 91 can also be integrated with processor 92.

[0315] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0316] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0317] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above code generation method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0318] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0319] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the code generation method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, Smart MediaCard (SMC), Secure Digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0320] This application also provides a computer program product, which is stored in a storage medium and implements the code generation method provided in the above embodiments when the computer program product is executed by a computer.

[0321] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0322] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. 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 software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0323] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A code generation method, characterized in that, include: Pseudocode for obtaining user input; Based on the cross-file dependency graph and the pseudocode, obtain the relevant code corresponding to the target code entity that matches the pseudocode; The cross-file dependency graph is used to represent the dependency relationships between different code entities in different code files; the cross-file dependency graph uses code entities as nodes and the call dependency relationships between code entities as directed edges; each code entity indicates a piece of code; Input the cross-file dependency graph and the related code into the language model, and output the target code; The cross-file dependency graph is constructed based on at least two code files, with different code files corresponding to different functions and different code implementation methods.

2. The code generation method according to claim 1, characterized in that, The method further includes: Obtain at least two code files from the target code repository; For each code file, change operations are performed on the import statement nodes extracted from that code file to obtain the destructive refactored code file; Static diagnostic processing is performed on each code file and the corresponding destructed and reconstructed code file to obtain the first error offset value of each code file and the second error offset value of each destructed and reconstructed code file. Based on the difference between the first and second error offset values ​​corresponding to each code file, the call dependencies between code entities in each code file are determined. Construct an initial cross-file dependency graph based on the aforementioned call dependencies; The initial cross-file dependency graph is acyclic to obtain the cross-file dependency graph.

3. The code generation method according to claim 2, characterized in that, The process of acyclic processing the initial cross-file dependency graph to obtain the cross-file dependency graph includes: Identify strongly connected components in the initial cross-file dependency graph; Each strongly connected component is folded into a corresponding first component node, and the strongly connected components are formed by bidirectional imports, recursive calls or indirect mutual references between the code entities. The node that is not included in any strongly connected component is directly used as the second component node; Construct a strongly connected component aggregation graph based on the first component node and the second component node; When the strongly connected component agglomeration graph passes the topological sorting verification, the strongly connected component agglomeration graph is used as the cross-file dependency graph.

4. The code generation method according to claim 2, characterized in that, The step of performing modification operations on the import statement nodes extracted from the code file to obtain the destructive refactored code file includes: Based on preset change processing rules, change processing is performed on the import statement nodes extracted from the code file to obtain the counter-reference code file; The preset change processing rules include: When the import method of an import statement node is to import code entities from a module, determine the type of code entity imported by that import statement node; If the type of the code entity imported by the import statement node is a class, delete the import statement node and add an empty definition of the class in the original position of the import statement node; If the type of the code entity imported by the import statement node is a function or variable, delete the import statement node; When the import statement node is mapped to an import module, scan all attribute accesses of the code entity to the import module in the code file, identify the code entity type corresponding to each attribute access, delete the import statement node when the code entity type is a class, and add an empty definition of the class to the original position of the import statement node. When the code entity type is a function or variable, delete the import statement node.

5. The code generation method according to claim 1, characterized in that, The method further includes: The dependency subgraph of each code entity is obtained from the cross-file dependency graph, and the dependency subgraph of each code entity is dynamically segmented to obtain a set of code blocks; The language model is trained based on the set of code blocks to obtain the trained language model.

6. The code generation method according to claim 5, characterized in that, The step of obtaining a dependency subgraph for each code entity from the cross-file dependency graph, and dynamically segmenting the dependency subgraph to obtain a set of code blocks includes: If the number of characters in the code body of a code entity is less than or equal to the maximum load threshold, a breadth-first traversal is performed along the outgoing edges of the code entity in the cross-file dependency graph to obtain the dependency subgraph of the code entity. Based on the graph step size of each dependent node in the dependent node subgraph and the code entity, the dependent nodes are sorted, and the code bodies corresponding to each dependent node are concatenated based on the sorting results to obtain the concatenated code body. If the total number of characters in the concatenated code body exceeds the maximum load threshold, the code body of each dependent node is replaced with a code entity signature to obtain a replaced dependency subgraph. The replaced dependency subgraph is dynamically segmented to obtain a set of code blocks.

7. The code generation method according to claim 5, characterized in that, The process of training the language model based on the set of code blocks to obtain the trained language model includes: Negative samples are obtained by injecting a predetermined proportion of random code fragments and error codes into the code blocks in the code block set; An instruction fine-tuning dataset is constructed based on positive samples and the negative samples. The code blocks in the code block set are positive samples, and each code block in the code block set has a predefined explicit boundary marker added. The language model is trained based on the fine-tuned dataset to obtain the trained language model.

8. The code generation method according to any one of claims 1-7, characterized in that, The method further includes: When code files are modified, dependency re-analysis is performed on the affected set of code entities to obtain the updated dependencies; The cross-file dependency graph is updated based on the updated dependencies.

9. A code generation device, characterized in that, include: The first acquisition module is used to acquire pseudocode input by the user; The second acquisition module is used to acquire the relevant code corresponding to the target code entity that matches the pseudocode, based on the cross-file dependency graph and the pseudocode. The cross-file dependency graph is used to represent the dependency relationships between different code entities in different code files; the cross-file dependency graph uses code entities as nodes and the call dependency relationships between code entities as directed edges; each code entity indicates a piece of code; The output module is used to input the cross-file dependency graph and the related code into the language model and output the target code; The cross-file dependency graph is constructed based on at least two code files, with different code files corresponding to different functions and different code implementation methods.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the code generation method as described in any one of claims 1-8.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the code generation method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, the computer program product implements the code generation method as described in any one of claims 1-8.

Images