Code repository automatic generation method, electronic device, and program product
By constructing a repository planning graph (RPG) and a test-driven development process, the problems of static solidification of code generation rules and lagging quality assurance were solved, achieving structural consistency and automated quality assurance in code generation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- INDUSTRIAL AND COMMERCIAL BANK OF CHINA
- Filing Date
- 2026-02-10
- Publication Date
- 2026-06-30
AI Technical Summary
In existing technologies, code generation rules are static and fixed, making it difficult to adapt to dynamic changes in requirements. They also lack explicit hierarchical planning and dependency modeling mechanisms, resulting in loose code structure and lagging quality assurance.
By constructing a repository planning graph (RPG), using a vector database for semantic retrieval and functional path planning, and combining an exploration-utilization strategy and a test-driven development process, a code repository is generated.
It achieves structural consistency, automation, and quality assurance in code generation, improving the credibility and maintainability of the generated code.
Smart Images
Figure CN122308801A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software design and development, and in particular to a method for automatically generating code repositories, electronic devices, and program products. Background Technology
[0002] In modern software engineering practice, code repository generation and maintenance are core components of the development process. As enterprise software systems in fields such as finance, healthcare, and industrial automation become increasingly complex, developers frequently face the challenge of rapidly constructing well-structured and fully functional code repositories based on natural language requirements documents. This process places higher demands on the dynamic, modular, and scalable nature of code generation.
[0003] Currently, mainstream automated code generation technologies mainly revolve around structured templates. Specifically, template-based code generation methods are implemented through predefined code template libraries. The system first uses natural language processing technology to parse the user's requirements document to extract key functional modules, parameters, and logic; then, it uses a similarity matching algorithm to search for suitable code templates in the template library, and generates specific code snippets through parameter replacement and logic concatenation; during this process, a dependency resolver analyzes the call relationships between templates, generates a dependency graph, optimizes the code structure, and finally outputs a complete code file with basic comments.
[0004] However, the above-mentioned technical solutions have the drawback of being static and rigid, making it difficult to adapt to dynamic changes in demand. Summary of the Invention
[0005] This application provides an automated code repository generation method, electronic device, and program product to solve the technical problem that static code generation rules are difficult to adapt to dynamic changes in requirements.
[0006] In a first aspect, embodiments of this application provide an automated method for generating code repositories, the method comprising:
[0007] Obtain functional specification information;
[0008] The corresponding functional subtree is generated based on the functional specification information, where the nodes in the functional subtree represent functional units;
[0009] Based on the principle of cohesion, the nodes in the functional subtree are clustered into multiple functional modules, and a modular functional diagram is generated.
[0010] Map the functional modules in the modular function diagram to the file structure to generate an enhanced file structure diagram;
[0011] Based on the file structure enhancement graph, the data flow between functional modules and the file order dependency within the functional modules are modeled to generate a warehouse planning graph. The nodes of the warehouse planning graph are mapped to the file structure, and the edges of the warehouse planning graph are represented by the execution dependency relationship based on the data flow and file order dependency. The execution dependency relationship is used to determine the topological order between nodes.
[0012] Based on the topological order determined by execution dependencies, code files are generated using a test-driven development process to form a code repository.
[0013] In this embodiment, by constructing and utilizing a unified constraint representation—the warehouse planning graph—the process from requirements analysis to code implementation is driven, achieving synergistic optimization in code structure standardization, automated generation process, and inherent reliability of results. Specifically: First, based on the explicit dependencies of the planning graph, the code organization is constrained to strictly follow the high-level functional design, ensuring structural consistency; second, end-to-end automated generation is achieved by replacing manual decision-making with vectorized retrieval and strategy optimization algorithm serialization; finally, the test-driven development process is embedded into the topological execution sequence of the planning graph, constructing a pre-emptive quality verification and correction loop, thereby improving the credibility of the generated code.
[0014] In one possible implementation, the corresponding functional subtree is generated based on the functional specification information, including:
[0015] Using a vector database, retrieve a set of candidate functional paths that match the semantic similarity of the functional specification information;
[0016] Based on the hierarchical relationship of the functional path candidate set, construct the functional subtree.
[0017] This implementation overcomes code generation biases caused by the ambiguity of natural language requirements by introducing a vector database and semantic similarity retrieval. Specifically, unstructured functional specification information is transformed into vectors and similarity matching is performed. This allows for the selection of the most semantically relevant functional path candidates from a large-scale functional knowledge base, thus avoiding the one-sided or erroneous functional understanding caused by traditional methods that rely on manual parsing or keyword matching. Based on this, functional subtrees are constructed according to the hierarchical relationships of the candidate set, ensuring that the generated functional plan has logical consistency and completeness in structure. This improves the accuracy from requirements to functional planning and provides a clear, semantically explicit, and reliable input for subsequent modular refactoring and dependency modeling.
[0018] In one possible implementation, a functional subtree is constructed, including:
[0019] Based on the exploration-exploitation strategy, target functional paths are identified from the functional path candidate set and integrated to generate functional subtrees.
[0020] In this implementation, by combining the above-mentioned exploration and utilization strategies, the problems of randomness, bias, and incomplete coverage of function enumeration that may be caused by simply relying on model generation or a single strategy selection are solved. A focused yet comprehensive functional planning foundation is systematically generated, providing high-quality and reliable input for downstream modular design.
[0021] In one possible implementation, the explore-exploitation strategy includes an exploit phase and an exploration phase:
[0022] The utilization phase includes selecting the top-k functional paths with the highest semantic similarity from the functional path candidate set;
[0023] The exploration phase includes expanding the set of functional paths from the functional path candidate set to include other functional paths not included in the functional paths selected during the utilization phase.
[0024] In this implementation, through the division of labor and collaboration in the two stages mentioned above, the system can effectively explore potential related functions while deeply mining the core functions, thereby balancing the processing of the functional path candidate set and providing an algorithmic foundation for generating high-quality functional subtrees that are both focused on key points and comprehensive.
[0025] In one possible implementation, the explore-exploitation strategy is driven by a reinforcement learning framework, and the method also includes:
[0026] Receive evaluation information for the generated code file;
[0027] Transform evaluation information into reward signals for the reinforcement learning framework;
[0028] The policy parameters of the reinforcement learning framework are updated based on the reward signal.
[0029] In this implementation, the aforementioned mechanism enables the exploration-exploitation strategy to evolve from static, predefined rules to a dynamic, online-learning intelligent agent. The system can autonomously adjust its planning tendencies based on actual generated results and changes in user needs, thereby continuously improving the accuracy, adaptability, and ultimately, user satisfaction of its functional planning over long-term operation.
[0030] In one possible implementation, a test-driven development process is used to generate code files, including:
[0031] Generate test cases for the execution dependencies defined by data flows in the warehouse planning diagram;
[0032] Before generating and executing the code files corresponding to each functional module in the dependency relationship, execute the test cases generated for the functional modules;
[0033] If the test case fails to execute, adjust the code generation strategy or repository planning map, and regenerate the code files based on the adjustment results.
[0034] In this implementation, the strict closed loop formed by the three steps described above—"generating tests -> test-driven implementation -> intelligent revision in case of failure"—transforms quality verification from traditional post-event checks into core constraints embedded in the generation process. This not only ensures that each generated code module passes specialized tests for its interface, but also gives the entire system the robustness to self-diagnose and self-correct when encountering problems, thereby improving the reliability and correctness of the generated code.
[0035] In one possible implementation, test cases are generated, including:
[0036] From the data flow in the warehouse planning diagram, the input and output types used for data transfer between functional modules can be analyzed;
[0037] Based on the parsed input and output types, test data and assertions are constructed to generate test cases.
[0038] In this implementation, the automated process of parsing contracts, generating data, and assertions achieves a high degree of synchronization between test cases and system design. The generated test cases directly verify whether the code meets the interface specifications defined in the planning phase, thus ensuring the correctness of interactions between modules at the implementation level and forming an indispensable quality checkpoint in the high-quality code generation process.
[0039] In one possible implementation, if test case execution fails, the code generation strategy or repository planning map is adjusted, including:
[0040] The failure results of test cases are analyzed through a majority voting mechanism to distinguish the categories of failure reasons;
[0041] Adjust the code generation strategy or repository planning map based on the identified failure reasons.
[0042] In this implementation, the closed-loop mechanism of majority voting diagnosis and classification-oriented adjustment improves the intelligence and efficiency of the post-test failure handling process, avoids invalid code rewriting due to environmental issues, and ensures accurate repair of real code defects, thereby enhancing the reliability of the entire code generation system.
[0043] In a second aspect, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;
[0044] The memory stores the instructions that the computer executes;
[0045] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.
[0046] Thirdly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects. Attached Figure Description
[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0048] Figure 1 A flowchart illustrating a template-based code generation method provided in an embodiment of this application;
[0049] Figure 2 A flowchart illustrating a model-driven code generation method provided in this application embodiment;
[0050] Figure 3 A flowchart illustrating a deep learning-based code generation method provided in an embodiment of this application;
[0051] Figure 4 A flowchart illustrating an automated code repository generation method provided in this application embodiment;
[0052] Figure 5 This is a schematic diagram of the architecture of an automated code repository generation system provided in an embodiment of this application.
[0053] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0054] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0055] It should be noted that the automated code repository generation method, electronic device and program product provided in this application can be used in the field of software design and development, or in any field other than software design and development. This application does not limit the application field of the automated code repository generation method, electronic device and program product.
[0056] This application can be applied to specific scenarios, such as enterprise software development that requires high-frequency iterative development and complex dependency management. In such scenarios, business logic, compliance requirements, and data processing flows are often dynamically changing, and development teams need to quickly transform requirements in natural language form into a well-structured, modular, and long-term maintainable code repository.
[0057] For example, in the fintech sector, banking institutions need to dynamically adjust or restructure the rule modules and data processing links in their risk control systems based on constantly updated regulatory policies; in the healthcare sector, hospitals or research platforms need to promptly restructure their software processes for data collection, analysis, and sharing in response to changes in patient data privacy regulations. These scenarios not only require the code to accurately implement the current functionality, but also emphasize that the code repository itself has a well-organized structure, clear dependencies, and scalability to support continuous business expansion and technological iteration.
[0058] For the above application scenarios, one possible implementation is to achieve automatic code generation, for example, through a template-based code generation method. This method is an automated solution for generating structured code using a predefined template library. The following will combine... Figure 1 This implementation method will be introduced. Figure 1 This is a flowchart illustrating a template-based code generation method provided in an embodiment of this application. Figure 1 As shown, this solution is typically implemented through the collaborative efforts of the following modules:
[0059] S101. Analyze requirements through the requirements analysis module.
[0060] This module receives requirement documents in natural language form and uses natural language processing technology to parse them in order to extract key structured information such as functional modules, parameter types, and core business logic.
[0061] S102. Maintain the template library through the template library management module.
[0062] This module is responsible for storing and managing a code template library containing multiple programming languages and covering different functional scenarios, and for version management and classification of the templates, such as API interface templates and database operation templates.
[0063] S103. Perform template matching through the template matching engine.
[0064] Based on the structured information extracted by S101, the engine uses a similarity matching algorithm to search and compare in the template library managed by S102, thereby finding code templates that match the current requirements.
[0065] S104. Generate specific code using a code generator.
[0066] The generator injects the parameters into the placeholders of the template based on the template matched by S103 and the parameters extracted by S101, and generates specific code snippets according to the preset logical structure within the template.
[0067] S105. Analyze and optimize the structure using a dependency resolver.
[0068] The parser analyzes the code snippets generated by S104, parses the call relationships between different templates to construct a dependency graph, and optimizes the code structure based on this graph.
[0069] S106. Output is completed through the code output module.
[0070] This module integrates the code processed by the aforementioned process into a standardized source file, and usually provides automatically generated code comments and basic documentation, ultimately outputting a complete code file.
[0071] Another possible implementation is a model-driven code generation approach. This method centers on a domain model and uses a model-driven architecture to automate the generation of code from abstract design to concrete code. The following will combine... Figure 2 This implementation method will be introduced. Figure 2 This is a flowchart illustrating a model-driven code generation method provided in an embodiment of this application. Figure 2 As shown, this solution is typically implemented through the collaborative efforts of the following modules:
[0072] S201. Perform domain modeling using requirements building tools.
[0073] This tool provides a graphical interface that allows developers to visually define and configure entities, attributes, business rules, and interaction processes.
[0074] S202. A standardized model is formed through the domain model building module.
[0075] Based on the definition of S201, this module constructs a platform-independent model (PIM). This model focuses on describing the core business logic and data structure, without including any details of specific implementation technologies. It is typically described using standard modeling languages such as Unified Modeling Language (UML) or Systems Modeling Language (SysML), and supports model version management and consistency verification.
[0076] S203, Perform model transformation through the model transformation engine.
[0077] The engine uses a model transformation language to convert the PIM built by S202 into a platform-specific model (PSM) that is bound to a specific programming language or technology framework through rule mapping and detail injection.
[0078] S204. Generate target code using a code generator.
[0079] Based on the PSM output by S203, the generator automatically maps the elements in the PSM that already contain technical details to the code framework of the target programming language, including the generation of classes, interfaces, methods and their declarations.
[0080] S205. Analyze and optimize the structure using a dependency resolver.
[0081] The parser analyzes the dependencies within and between the domain model constructed by S202, and optimizes module partitioning and call paths when generating code to enhance the modularity and maintainability of the code.
[0082] S206. Ensure generation quality through the code verification module.
[0083] This module uses techniques such as static code analysis to verify the syntax correctness and basic logic consistency of the code generated by S204, so as to ensure the initial quality of the output code.
[0084] In another possible implementation, a deep learning-based code generation method could be employed. This method utilizes deep learning models to learn programming patterns from a large-scale code corpus, directly generating code in an end-to-end manner. The following will combine... Figure 3 This implementation method will be introduced. Figure 3 This is a flowchart illustrating a deep learning-based code generation method provided in an embodiment of this application. Figure 3 As shown, this solution is typically implemented through the collaborative efforts of the following modules:
[0085] S301, manage and provide training data through a code corpus.
[0086] The code corpus is responsible for collecting, cleaning, and managing large-scale code datasets covering multiple programming languages, open-source projects, and common patterns, providing a diverse and representative data foundation for model training.
[0087] S302. The original code is structured through the data preprocessing module.
[0088] This module performs operations such as word segmentation, syntax tree parsing, and control flow graph extraction on the code provided by S301, removes noise such as comments and blank lines, and converts it into an input format acceptable to the model, such as token sequences or abstract syntax tree representations.
[0089] S303. Construct a vectorized representation of code through the code representation learning module.
[0090] This module uses techniques such as word embedding or sub-word segmentation to map the code fragments processed by S302 into high-dimensional vectors, and combines syntactic structure and semantic information to construct multimodal representations to capture the contextual dependencies and deep logic of the code.
[0091] S304. Learn code generation patterns through deep learning models.
[0092] This model is typically based on advanced architectures such as Transformer, and uses a self-attention mechanism to learn global dependencies in the code. It can support code generation or context-aware code completion based on conditions such as natural language descriptions.
[0093] S305. Code generation is performed via the code generator.
[0094] The generator receives user input (such as a requirement description or part of the code), calls the model trained by S304, generates target code snippets that conform to the syntax rules, and supports multi-language output and dynamic adjustment of the generation strategy.
[0095] S306. Analyze the structure of the generated code through the dependency reasoning module.
[0096] This module parses the code generated by S305, analyzes its function call chains, class inheritance relationships, etc., constructs a dynamic dependency graph to detect potential conflicts, and provides a basis for code optimization.
[0097] S307. Improve the quality of generated code through a code optimizer.
[0098] This optimizer combines static analysis tools with syntax tree refactoring technology to optimize the performance, improve readability, and unify the style of the code after S306 analysis, and generates corresponding optimization logs for traceability.
[0099] However, the above implementation method has the following technical problems:
[0100] First, both template-based and model-driven generation methods suffer from static planning and adaptability issues. Template-based methods rely heavily on predefined static template libraries, resulting in rigid generation logic that struggles to flexibly respond to the ambiguity and dynamic changes common in natural language requirements, leading to fragmented code structures. While model-driven methods offer an improved level of abstraction, their domain model construction and transformation rules are highly dependent on manual definition, making the model transformation process prone to logical conflicts and similarly difficult to adapt to evolving needs during continuous iteration.
[0101] Secondly, existing solutions generally lack explicit, traceable hierarchical planning and dependency modeling mechanisms. Whether it's the calling relationships between templates or the mappings between model elements, dependency resolution largely relies on predefined rules, failing to establish an explicit, bidirectional mapping from high-level functional intent to the underlying code organization structure. This makes it difficult to clearly define and trace data flows and interface contracts between modules. As the code scales, the problems of high module coupling and loose structure become prominent, increasing maintenance costs and limiting system scalability.
[0102] Furthermore, deep learning-based methods suffer from shortcomings in terms of structural consistency and controllability of generated code. These methods rely on statistical patterns learned from large-scale corpora, making them susceptible to training data bias, leading to semantic inconsistencies and stylistic inconsistencies in the generated code. More importantly, their end-to-end generation process lacks explicit planning and constraints on the overall structure of the code repository, resulting in a loosely structured codebase lacking clear module boundaries and dependencies. Moreover, performance and quality significantly degrade when generating large-scale code.
[0103] Furthermore, existing technical solutions have failed to deeply integrate with a systematic quality assurance mechanism. The verification of the correctness, reliability, and performance of the generated code heavily relies on manual testing and review, lacking an automated test-driven development mechanism embedded in the generation process. This results in lagging and costly quality assurance of the generated code, making it difficult to meet enterprises' high standards for code reliability, security, and maintainability.
[0104] The automated code repository generation method provided in this application aims to solve the aforementioned technical problems of existing technologies. By constructing an explicit hierarchical diagram representation of a repository planning graph (RPG), it unifies the proposal-level functional planning (i.e., what to do) and implementation-level structural organization (i.e., how to implement it with code) of the code repository. This planning graph is generated and continuously optimized by intelligent algorithms, thereby supporting end-to-end automated construction and quality assurance from requirements to code.
[0105] Specifically, the natural language requirements are first transformed into semantically meaningful functional tree node representations, and then semantic retrieval and functional path planning are performed using a vector database. By introducing an explore-utilize balancing strategy, the system can intelligently select and optimize functional subtrees, ensuring complete functional coverage while also considering implementation diversity. This process provides optimized, fine-grained functional node inputs for RPG construction.
[0106] Building upon this foundation, a modular refactoring algorithm is used to refactor functional boundaries according to the principle of cohesion, forming a modular functional organization. Subsequently, by mapping functional nodes to specific repository file structures and explicitly modeling data flow between modules and file sequence dependencies within modules, the system dynamically generates a complete RPG. In the RPG, nodes represent progressively refined functional capabilities and are also mapped to specific repository organizational structures; edges capture execution dependencies across granularities. The topological order of the graph provides consistency constraints for functional decomposition and code organization, ensuring the inherent unity between planning and implementation.
[0107] Ultimately, this RPG guides the subsequent code generation process. The system generates executable code based on the graph's topological order using a test-driven development process. During generation, if tests fail, a closed-loop revision mechanism for the RPG or generation strategy is triggered, ensuring the correctness, maintainability, and scalability of the code from the outset. This addresses issues such as inconsistent planning, complex dependency management, and lagging quality assurance in existing technologies.
[0108] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0109] First, combine Figure 4 This application describes an automated code repository generation method provided in its embodiments. Figure 4 A flowchart illustrating an automated code repository generation method provided in this application embodiment is shown below. Figure 4 As shown, the method includes:
[0110] S401. Obtain functional specification information.
[0111] Functional specification information is input describing the expected behavior of a software system, and its forms include, but are not limited to, natural language documents, structured requirements specifications, or application programming interface (API) definitions. The system can obtain this information, for example, through file reading, network reception, or a human-computer interaction interface.
[0112] S402. Generate the corresponding functional subtree based on the functional specification information.
[0113] This step aims to transform unstructured requirements into structured functional plans. A specific implementation method may include the following steps:
[0114] Semantic retrieval: Natural language processing techniques are used to transform functional specification information into query vectors. A pre-built vector database stores functional units and their semantic embedding vectors from large-scale code knowledge bases (such as open-source projects). The system retrieves the multiple functional units and their call paths most relevant to the query vector from this database by calculating cosine similarity, forming an initial candidate set of functional paths.
[0115] Strategy optimization: Apply the exploration-utilization strategy to optimize and integrate the above candidate set. For example, first use the most relevant Top-k candidates for in-depth expansion (utilization phase), and then expand other candidates randomly or based on diversity indicators to explore potential functions (exploration phase).
[0116] Subtree Construction: The optimized functional paths are integrated and constructed into a functional subtree based on the inclusion, calling, or dependency relationships between the paths. This functional subtree uses nodes to represent specific functional units and edges to represent the hierarchical or logical relationships between nodes, thus systematically expressing the possible set of functions to achieve the requirements.
[0117] S403. Based on the principle of cohesion, the nodes in the functional subtree are clustered into multiple functional modules, and a modular functional diagram is generated.
[0118] This step aims to modularize the functional subtrees. The system analyzes the strength of associations between nodes in the subtrees, which can be measured by data flow dependencies, call frequency, or semantic similarity. Based on this, a graph clustering algorithm (such as the Louvain algorithm) is used to aggregate closely related nodes into the same module to ensure high cohesion of the modules. After the clustering operation is completed, a modular functional graph is generated, where nodes represent the aggregated functional modules, and edges represent the main dependencies between modules.
[0119] S404. Map the functional modules in the modular function diagram to the file structure to generate an enhanced file structure diagram.
[0120] The purpose of this step is to determine the physical organization of the functional modules. The system assigns a unique path in the project's source code directory to each functional module in the modular functional diagram and creates corresponding source code files for the core functional units within the module. For example, the "User Authentication" module might be mapped to the src / auth / directory, and files such as controller.py and service.py might be created in that directory. Based on this process, an enhanced file structure diagram can be generated, which associates the functional modules with specific file system locations based on their logical structure.
[0121] S405. Based on the file structure enhancement graph, model the data flow between functional modules and the file sequence dependency within the functional modules to generate a warehouse planning graph.
[0122] This step is crucial for generating the RPG, and it may include the following steps:
[0123] Dataflow modeling involves analyzing the data that needs to be exchanged between functional modules, defining names, data types, and directions (input / output) to form a clear interface contract. For example, the "data preprocessing module" outputs training data of type numpy.ndarray to the "model training module."
[0124] File order modeling: Determine the compilation or execution order dependencies between multiple source files within the same module.
[0125] Graph Structure Generation: Based on the above information, a directed graph, i.e., RPG, is generated. The nodes of this graph associate functional modules with their corresponding files; the edges represent two types of dependencies: inter-module execution dependencies based on data flow, and intra-module execution dependencies based on file order. These dependencies collectively define the execution topology order of each part of the system.
[0126] S406. Based on the topological order determined by execution dependencies, generate code files using the test-driven development process to form a code repository.
[0127] The system generates code files for each node (functional module) sequentially according to the topological order determined by the edge dependencies in the RPG. The generation process for each functional module follows the test-driven development workflow:
[0128] Test generation: Based on the interface contract (data flow) defined for this functional module in S405, automatically generate unit test cases to verify its inputs and outputs.
[0129] Code implementation: Generate source code (e.g., functions, classes) that can pass the above tests.
[0130] Verification and Revision: Execute tests. If a test fails, analyze the cause and revise the code generation strategy or backtrack to the revision RPG, then regenerate the code files until the test passes.
[0131] Finally, all generated and tested code files are organized according to the file structure defined in S404 to form a complete, buildable, and executable code repository.
[0132] The automated code repository generation method provided in this application, by constructing and utilizing a unified constraint representation—a repository planning graph—drives the process from requirements analysis to code implementation, achieving synergistic optimization in code structure standardization, automation of the generation process, and inherent reliability of the results. Specifically: First, based on the explicit dependencies of the planning graph, the code organization is constrained to strictly follow the high-level functional design, ensuring structural consistency; second, end-to-end automated generation is achieved by replacing manual decision-making with vectorized retrieval and strategy optimization algorithm serialization; finally, the test-driven development process is embedded into the topological execution sequence of the planning graph, constructing a pre-emptive quality verification and correction loop, thereby improving the credibility of the generated code.
[0133] Optionally, embodiments of this application specifically describe how to generate a functional subtree based on functional specification information. A concrete implementation can be achieved through, for example, the following steps:
[0134] First, functional path retrieval is performed. The system receives functional specification information input by the user (e.g., a natural language description of "implementing a data clustering function"). Internally, the system maintains a vector database that stores semantic embedding vectors of functional units extracted from a large-scale code knowledge base, along with the complete functional path associated with each vector as metadata.
[0135] The system uses natural language processing (NLP) technology to encode user requests into query vectors and performs semantic similarity matching by calculating cosine similarity. It then retrieves the functional paths with the highest semantic similarity to the query vectors from this vector database, forming a candidate set of functional paths. This process uses semantic matching instead of keyword matching, resolving the ambiguity problem in natural language processing.
[0136] Subsequently, the functional subtree is constructed. Based on the functional path candidate set obtained above, the system constructs the final functional subtree according to the hierarchical relationship contained therein. This hierarchical relationship is reflected in the structure of the functional path; for example, a path might be "data preprocessing -> feature scaling -> K-Means clustering".
[0137] The system analyzes all candidate paths, identifies common parent nodes, sibling nodes, and inheritance relationships, and integrates and merges these paths into a unified tree structure. Nodes in this functional subtree represent specific functional units, and edges represent parent-child or calling relationships between nodes. In this way, the system transforms a discrete, potentially repetitive set of path candidates into a clearly structured, non-redundant hierarchical functional planning representation.
[0138] By introducing a vector database and semantic similarity retrieval, the code generation bias caused by the ambiguity of natural language requirements is overcome. Specifically, unstructured functional specification information is transformed into vectors and similarity matching is performed. This allows for the selection of the most semantically relevant functional path candidates from a large-scale functional knowledge base, thus avoiding the one-sided or erroneous functional understanding caused by traditional methods that rely on manual parsing or keyword matching. Based on this, functional subtrees are constructed according to the hierarchical relationship of the candidate set, ensuring that the generated functional plan has logical consistency and completeness in structure. This improves the accuracy from requirements to functional planning and provides a reliable input with a clear structure and explicit semantics for subsequent modular refactoring and dependency modeling.
[0139] Optionally, the embodiments of this application specifically describe how to construct a functional subtree based on an exploration-utilization strategy. The implementation process revolves around the core goal of balancing functional coverage and diversity, and optimizes and integrates the functional path candidate set obtained from the above embodiments.
[0140] Specifically, the exploration-exploitation strategy comprises the following two synergistic phases:
[0141] Utilization Phase: The system first selects the top-k (e.g., k=3) functional paths from the candidate functional path set that have the highest semantic alignment with the user's needs. Subsequently, these highly relevant paths are expanded in depth, for example, by digging deeper into more specific sub-functions along the existing hierarchical structure of the functional path, to ensure full coverage and in-depth satisfaction of the core requirements.
[0142] Exploration Phase: To avoid the generated functional subtree being limited to known high-similarity paths and missing potentially important functions, the system will select other paths from the candidate set that are currently underutilized or located in unvisited areas of the functional tree for expansion. For example, even if the user's requirements are not explicitly mentioned, the system may proactively expand related module paths such as "exception handling," "logging," or "performance monitoring" to capture the diversity and completeness of functions and enhance the ability of the generated code to handle edge cases and exceptions.
[0143] After completing the path expansion in the two stages described above, the system calls the integration module to filter, deduplicat, and logically integrate the expanded set of paths that may contain redundancy or conflicts. Ultimately, these discrete paths are structured into a unified, hierarchical functional subtree. This subtree not only closely revolves around the user's core intent but also possesses good functional breadth and structural balance.
[0144] By combining the above exploration and utilization strategies, the problems of randomness, bias, and incomplete coverage in function enumeration that may be caused by simply relying on model generation or a single strategy selection are solved. A systematic function planning foundation that is both focused and comprehensive is generated, providing high-quality and reliable input for downstream modular design.
[0145] Optionally, embodiments of this application further specify the aforementioned exploration-exploitation strategy, clarifying that it includes an exploration phase and an exploitation phase executed sequentially.
[0146] Specifically, during the utilization phase, the system performs a precise focusing operation, which involves directly analyzing the candidate set of functional paths obtained from semantic retrieval and selecting the top-k functional paths with the highest semantic similarity (for example, k can be 3, as described earlier). These paths represent the core solutions most directly related to the user's intent, and the goal of this phase is to ensure the full adoption of these high-value paths.
[0147] Following this, in the exploration phase, the system performs a breadth expansion operation. The corresponding input remains the same set of functional path candidates, but the processing objective shifts to expanding other functional paths not included in the Top-k paths selected in the utilization phase. This phase increases the diversity of functional planning by introducing potentially relevant auxiliary or safeguard functions (e.g., modules not explicitly requested by the user).
[0148] Through the division of labor and collaboration in the two stages described above, the system can effectively explore potential related functions while deeply mining the core functions, thereby balancing the processing of the functional path candidate set and providing an algorithmic foundation for generating high-quality functional subtrees that are both focused on key points and comprehensive.
[0149] Optionally, embodiments of this application aim to enable the system's functional path selection strategy to possess the ability to continuously learn and self-optimize. Specifically, the exploration-exploitation strategy is driven and managed by a reinforcement learning framework. This framework formalizes the path planning process as a multi-step decision-making task. In this task, the state faced by the system at each step is the currently constructed functional subtree structure, the executable action corresponds to selecting and expanding a functional path from the candidate set, and the feedback obtained after executing the action is quantified as a reward signal. The specific operation and optimization process is as follows:
[0150] Reward Signal Acquisition: After generating and delivering code files, the system actively receives or passively acquires external evaluation information. This information can be direct user feedback (e.g., "functionality satisfied," "needs to add parallel computing support") or the results of automated tests (e.g., performance score, pass rate). The system converts this evaluation information into a quantified reward value as an evaluation of the previous round of decision-making (i.e., the path selection strategy used to generate the current code).
[0151] Policy parameter update: The reinforcement learning framework receives the reward signal and dynamically adjusts the internal policy model parameters according to the update rules of the corresponding algorithm (e.g., the proximal policy optimization algorithm). The essence of this adjustment process is: if the reward is positive (indicating a positive outcome), the framework will fine-tune the parameters to make future path selection decisions more inclined to be similar to the current one; if the reward is negative, it will prompt the framework to explore different path directions in the future.
[0152] Dynamic strategy adjustment: Updated strategy parameters will immediately affect the behavior during the next execution of functional planning. For example, when the system receives feedback that "parallel computing needs to be supported" (positive reward), the exploration weight of parallel computing-related paths in the exploration strategy will be increased. This will enable the system to more proactively and accurately expand corresponding module paths, such as thread pool management, when encountering similar needs in the future, without the need for manual reconfiguration or reconstruction of the functional tree.
[0153] Through the above mechanism, the exploration-exploitation strategy has evolved from static, predefined rules to a dynamic, online-learning intelligent agent. The system can autonomously adjust its planning tendencies based on changes in actual generated results and user needs, thereby continuously improving the accuracy, adaptability, and ultimate user satisfaction of functional planning over long-term operation.
[0154] Optionally, this application embodiment specifically illustrates how to deeply integrate the test-driven development (TDD) process into RPG-based code generation to build a quality assurance closed loop with self-verification capabilities. This process follows the RPG topology, and the specific steps are as follows:
[0155] Step 1: Automated generation of test cases
[0156] The system traverses the RPG, deriving and generating corresponding test cases for each execution dependency defined by data flow edges in the graph. Specifically, the system parses the types and constraints of the source module outputs and target module inputs associated with the data flow edges (e.g., a data cleaning module outputs a DataFrame data structure to a feature extraction module), and constructs test code to verify the interface contract accordingly. These test cases aim to verify the correctness of data transfer between modules and the expected behavior of module functions.
[0157] Step 2: Test-Driven Generation Based on Topological Order
[0158] The system processes functional modules one by one according to the topological order determined by the execution dependencies in the RPG. For the current module, the system executes a standardized test-driven development sub-process:
[0159] Test-first approach and goal setting: Before generating any implementation code for this module, the system first executes all test cases generated for that module. Since the implementation logic is currently missing, these test cases are expected to fail. This step clearly defines the functional contract and acceptance criteria that the module must meet, providing precise goals for subsequent coding.
[0160] Generation and Verification: Subsequently, the system generates source code files (e.g., functions or classes) that enable all the aforementioned test cases to pass. After code generation, the system immediately re-executes the same set of test cases for verification. This step aims to generate a functional implementation that conforms to the predetermined contract and perform immediate self-checking.
[0161] Step 3: Failure Diagnosis and Closed-Loop Revision
[0162] If any test case fails during the immediate verification phase, the system enters a revision loop. The system analyzes the failure results and performs adjustments accordingly. The adjustments target the following two categories:
[0163] One approach involves adjusting the code generation strategy. If the diagnosis indicates that the implementation logic of the current module is flawed (e.g., algorithm error, interface implementation deviation), the system corrects the corresponding code generation logic (e.g., adjusts the API call method, corrects the calculation steps), and then re-executes the implementation coding and real-time verification only for that module.
[0164] Another type involves adjusting the RPG. If the diagnostics indicate that the failure stems from an upstream module's output not conforming to the contract, or from defects in the RPG's dependencies or interface definitions, the system will backtrack and update the corresponding data flow definitions or module partitions in the RPG. Subsequently, the system will restart the entire TDD process based on the updated RPG, starting with the earliest affected module.
[0165] The strict closed loop formed by the above three steps—"generating tests -> test-driven implementation -> intelligent revision in case of failure"—transforms quality verification from traditional post-event checks into core constraints embedded in the generation process. This not only ensures that each generated code module passes specialized tests for its interface, but also gives the entire system the robustness to self-diagnose and self-correct when encountering problems, thereby improving the reliability and correctness of the generated code.
[0166] Optionally, this application embodiment specifically describes how to automatically derive test cases from an RPG, the core of which lies in utilizing the clearly defined interface contract information already modeled in the graph. The specific implementation includes the following two steps:
[0167] Step 1: Interface Type Resolution
[0168] The system iterates through the data flow edges in the RPG. For each data flow edge connecting two functional modules, the system parses the type information used for data transfer between the modules. This type information may include, for example:
[0169] Output type: The data structure definition provided by the source module. For example, the output type of a data loading module might be defined as List[Dict[str, float]] (a list of dictionaries where the keys are strings and the values are floating-point numbers).
[0170] Input type: The definition of the data structure that the target module expects to receive. For example, the input type of a statistical analysis module might be defined as pd.DataFrame (a Pandas DataFrame object).
[0171] Through this step, the system obtains the strongly typed contract of module interaction from the planning level.
[0172] Step 2: Test Data and Assertion Construction
[0173] Based on the input / output types obtained from the first step, the system performs the following operations to generate executable test code:
[0174] Test data generation: The system constructs test input data that conforms to the constraints of the input type. For example, for the input type pd.DataFrame, the system may generate an empty DataFrame containing specific column names and data types, or a small DataFrame filled with compliant sample data.
[0175] Assertion logic construction: The system generates verification assertions based on the output type and the expected function of the module. For example, for a sorting module, the assertion might verify whether its output list is sorted in ascending order by a specified key; for a module that calculates the average, the assertion would verify whether its output floating-point number is within the expected error range.
[0176] Finally, the system combines the generated test data and assertion logic into complete unit test cases for specific functional modules (e.g., a Python unittest.TestCase or a pytest test function).
[0177] Through the automated process of parsing contracts, generating data, and assertions described above, a high degree of synchronization between test cases and system design is achieved. The generated test cases directly verify whether the code meets the interface specifications defined in the planning phase, thereby ensuring the correctness of interactions between modules at the implementation level and forming an indispensable quality checkpoint in the high-quality code generation process.
[0178] Optionally, embodiments of this application aim to address the problem of accurate diagnosis and targeted remediation after test failures in the test-driven development process. By introducing a majority voting mechanism, the root causes of failures are automatically analyzed, thereby making the most effective adjustment decisions. The specific implementation includes the following two stages:
[0179] Phase 1: Diagnosing the reasons for failure (majority vote analysis)
[0180] When a test case fails, the system does not immediately perform a blind retry or a simple rollback. Instead, it initiates a diagnostic process. The system repeatedly executes the failed test case multiple times in isolated and controlled environment configurations. For example, it executes the test case under different runtime dependency versions, temporary resource conditions, or with slightly modified input data.
[0181] Subsequently, a majority voting mechanism analyzes the results of all these parallel executions. If the test fails in the vast majority of cases and the failure pattern is consistent (e.g., the same assertion error), the system determines with high confidence that the failure is due to a substantial error in the code implementation logic (e.g., algorithmic defect, interface implementation mismatch).
[0182] If a test fails only in a few specific environments (e.g., only with a specific dependency version) but passes in other environments, the system determines that the failure is more likely due to temporary runtime environment issues (e.g., dependency conflicts, insufficient resources, transient network failures) rather than defects in the code itself.
[0183] Through this mechanism, the system can distinguish test failure results into different failure reason categories, mainly implementation errors and environmental problems.
[0184] Phase Two: Targeted Adjustment Based on Diagnostic Results
[0185] Based on the failure cause categories identified in the first phase, the system executes different adjustment strategies.
[0186] In response to adjustments to error categories, the system determines that the root cause lies in the currently generated code or the plan itself. Therefore, it triggers revisions to the code generation strategy (e.g., correcting logic within functions, changing API calling methods) or modifications to related data flows and interface definitions in the RPG. Then, based on the revised strategy or plan, the code is regenerated and tests are executed.
[0187] Adjustments for environmental issue categories: If the system determines that the problem stems from external uncertainty, it may choose to automatically retry, log warnings and continue the process, or attempt to adaptively fine-tune the environment configuration without modifying the core code generation strategy or RPG.
[0188] The closed-loop mechanism of majority voting diagnosis and categorized targeted adjustment improves the intelligence and efficiency of the post-test failure handling process, avoids invalid code rewriting due to environmental issues, and ensures accurate repair of real code defects, thereby enhancing the reliability of the entire code generation system.
[0189] After describing the foregoing specific embodiments, in order to more completely and systematically demonstrate an integrated implementation of the technical solution of this application, the following is combined with... Figure 5 This implementation method will be explained in its entirety. Figure 5 This is a schematic diagram of the architecture of an automated code repository generation system provided in an embodiment of this application. Figure 5 The system demonstrates a modular architecture and data flow, with modules working together to achieve an end-to-end automated process from requirement input to high-quality code repository output.
[0190] like Figure 5 As shown, the system mainly includes the following core modules and their collaborative processes:
[0191] S501, Function Tree Retrieval Module. This module serves as the system's input and planning starting point, responsible for receiving and processing user requests. Internally, it maintains a vector database built upon a large-scale structured functional knowledge base. This module encodes user requests into semantic vectors and performs precise retrieval by calculating the similarity between these vectors and the embedded functional nodes in the database, combined with structural context information, outputting a set of semantically relevant functional path candidate sets. This design aims to systematically screen out reasonable directions from a massive number of functional options, providing high-quality alternative inputs for subsequent decision-making.
[0192] S502, Exploration-Utilization Subtree Selector. This module receives a set of functional path candidates from S501. Its core task is to apply intelligent strategies to optimize and integrate these candidates, generating a structured functional subtree. As described in the previous embodiments, this module employs an exploration-utilization strategy to achieve a balance between deeply utilizing the most relevant paths and broadly exploring potential functions, ultimately integrating and outputting a comprehensive and balanced functional subtree, laying the foundation for downstream architecture design.
[0193] S503, Modular Refactoring Engine. This module receives functional subtrees and, based on the principles of high cohesion and low coupling in software engineering, automatically clusters and refactors the nodes of the functional subtrees. The goal is to transform the functional list into a modular functional architecture diagram, clearly defining the division of functional modules and the dependencies between them, thereby improving the modularity quality during the design phase.
[0194] S504, File Structure Encoder. This module is responsible for mapping logical functional modules to the physical source code organization structure. It achieves this through two-level encoding: at the folder level, it assigns a dedicated directory path to each functional subgraph or module, achieving semantic isolation; at the file level, it maps specific functional units to executable source code files (e.g., .py, .java files). This process generates a file enhancement graph that attaches specific file system anchors to the logical functional modules, thereby reducing cross-file coupling in future code.
[0195] S505, Data Flow Modeler. This module is a crucial step in generating the RPG. Based on the file enhancement graph, it performs refined dependency modeling, specifically including: data flow encoding, defining typed interfaces for data transfer between modules; interface abstraction and unification to improve consistency; and file sequence planning. The final output is a complete RPG, which accurately describes the organizational structure, execution dependencies, and data contracts of all elements in the system.
[0196] S506, Graph-guided code generation module. This module is the core execution engine of the system, taking the complete RPG as input. Based on the topological order determined by the execution dependencies in the graph, it sequentially drives the code generation and verification process of each functional module.
[0197] S507, Test-Driven Development Module. Deeply integrated as a core submodule of S506, this module is responsible for implementing a rigorous built-in quality mechanism. Following the test-driven development paradigm, it automatically generates test cases for each module based on interface contracts in RPG, ensuring that tests are executed before code generation to clarify objectives and that results are verified after code generation. This module integrates diagnostic functions, enabling analysis and handling of test failures, forming a closed loop of "generation-testing-diagnosis-revision," thereby improving the quality and reliability of the output code.
[0198] S508, Code Repository Output Module. This module is responsible for the assembly and delivery of the final deliverables. Based on the file organization structure and module mapping relationships contained in the RPG, it physically organizes all verified code files and integrates a complete test suite automatically generated by the system, ultimately outputting a well-structured, directly buildable, and sufficiently test-covered executable code repository.
[0199] In conclusion, Figure 5 The system shown seamlessly integrates requirement analysis, intelligent planning, architecture design, dependency modeling, and quality-driven coding through the collaboration of the aforementioned modules, forming a complete and autonomous automated code repository generation solution. The specific technical details of each module have been described in the previous embodiments and will not be repeated here.
[0200] In another embodiment, step S402 (generating the corresponding functional subtree based on the functional specification information) can be implemented using a dynamic programming scheme based on reinforcement learning.
[0201] In this embodiment, the system uses a policy gradient-based reinforcement learning algorithm to directly generate functional subtrees, thus providing an alternative to the aforementioned explore-exploitation policy. The system models this generation process as a sequential decision-making task, specifically including the following elements:
[0202] Status: Represents the currently constructed partial subtree structure and unmet user needs.
[0203] Action: Defined as selecting a candidate functional node or path from the preset functional knowledge base and adding it to the current subtree.
[0204] Reward: Provided through a designed reward function. This function calculates the immediate reward value for a single step by quantitatively evaluating the coverage of user needs by the current subtree and the non-repetitiveness (i.e., diversity) of the introduced functional nodes.
[0205] Optimization objective: The training objective of reinforcement learning algorithms is to learn an optimal decision policy to maximize the expected cumulative reward from the initial state (corresponding to empty demand) to the terminal state (generating a complete functional subtree).
[0206] By training the subsequent processes of code generation and verification as an interactive environment, this reinforcement learning algorithm can autonomously optimize its decision-making strategy. Based on the trained strategy, the system can directly infer and output a high-quality functional subtree that achieves a balance between functional coverage and diversity, according to the input requirements.
[0207] The electronic device provided in this application embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0208] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.
[0209] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.
[0210] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0211] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0212] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0213] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.
[0214] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.
[0215] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.
[0216] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0217] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0218] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.
[0219] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0220] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A method for automatically generating code repositories, characterized in that, The method includes: Obtain functional specification information; Based on the functional specification information, a corresponding functional subtree is generated, wherein the nodes in the functional subtree represent functional units; Based on the principle of cohesion, the nodes in the functional subtree are clustered into multiple functional modules, and a modular functional diagram is generated. The functional modules in the modular functional diagram are mapped to the file structure to generate an enhanced file structure diagram. Based on the file structure enhancement graph, data flows between functional modules and file order dependencies within functional modules are modeled to generate a warehouse planning graph; wherein, the nodes of the warehouse planning graph map the functional modules to the file structure, and the edges of the warehouse planning graph represent execution dependencies based on data flows and file order dependencies, and the execution dependencies are used to determine the topological order between the nodes; Based on the topological order determined by the execution dependencies, code files are generated using a test-driven development process to form the code repository.
2. The method according to claim 1, characterized in that, The generation of the corresponding functional subtree based on the functional specification information includes: Using a vector database, retrieve a set of candidate functional paths that match the semantic similarity of the functional specification information; Based on the hierarchical relationship of the candidate functional paths, the functional subtree is constructed.
3. The method according to claim 2, characterized in that, The construction of the functional subtree includes: Based on the exploration-exploitation strategy, target functional paths are determined from the candidate set of functional paths and integrated to generate the functional subtree.
4. The method according to claim 3, characterized in that, The exploration-exploitation strategy includes an exploitation phase and an exploration phase: The utilization phase includes selecting the top-k functional paths with the highest semantic similarity from the functional path candidate set; The exploration phase includes expanding the set of functional path candidates to include other functional paths not included in the functional paths selected in the utilization phase.
5. The method according to claim 4, characterized in that, The exploration-exploitation strategy is driven by a reinforcement learning framework, and the method further includes: Receive evaluation information for the generated code file; The evaluation information is then converted into a reward signal by the reinforcement learning framework; Based on the reward signal, the policy parameters of the reinforcement learning framework are updated.
6. The method according to claim 1, characterized in that, The generation of code files using the test-driven development process includes: Test cases are generated based on the execution dependencies defined by the data flow in the warehouse planning diagram. Before generating the code file corresponding to each functional module in the execution dependency relationship, execute the test cases generated for the functional module; If the test case fails to execute, the code generation strategy or the repository planning diagram is adjusted, and the code files are regenerated based on the adjustment results.
7. The method according to claim 6, characterized in that, The generation of test cases includes: From the data flow in the warehouse planning diagram, the input and output types used for data transmission between functional modules are analyzed; Based on the parsed input and output types, test data and assertions are constructed to generate the test cases.
8. The method according to claim 6 or 7, characterized in that, If the test case fails to execute, the code generation strategy or the repository planning diagram will be adjusted, including: The failure results of the test cases are analyzed through a majority voting mechanism to distinguish the categories of failure reasons; Adjust the code generation strategy or the repository planning map based on the identified failure reason categories.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.
10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.