Code generation method and device, equipment and storage medium

Abstract

This disclosure relates to a code generation method, apparatus, electronic device, and storage medium, relating to the field of artificial intelligence. The method includes: performing semantic analysis on a requirements document using a large language model to obtain multiple functional modules and the relationships between them, and generating a dependency graph based on these dependencies; generating a task queue containing multiple development tasks based on the dependency graph, with each task carrying its corresponding execution order; determining the type of each development task and generating corresponding code or components; and assembling the code or components corresponding to the multiple development tasks according to their respective execution orders to obtain program code corresponding to the requirements document. This method can achieve a higher degree of matching between the obtained program code and the requirements document.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and more specifically, to a code generation method, apparatus, device, and storage medium. Background Technology

[0002] With breakthroughs in artificial intelligence technology, particularly large language models, in software engineering, automated code generation technology is evolving from assisting with code completion and fragment generation to generating complete functional modules based on natural language requirements. This automatic "requirement-to-code" conversion technology is considered a key path to improve software development efficiency, reduce labor costs, and address the challenges of rapid iteration.

[0003] The inventors discovered through research that existing methods still have significant shortcomings in achieving automatic conversion from "requirements to code." Traditional methods typically rely on manual parsing or rule-based automated tools to process requirements, resulting in coarse functional module divisions and high coupling. Consequently, the generated program code struggles to meet the accuracy, integrability, and maintainability requirements of complex software systems. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a code generation method, apparatus, device, storage medium, and program product that can improve the accuracy of the obtained code.

[0005] To achieve the above objectives, in a first aspect, this disclosure provides a code generation method, the method comprising: Obtain the requirements document; The requirement document is semantically analyzed using a large language model to obtain multiple functional modules and their dependencies, and a dependency graph is generated based on these dependencies. Based on the dependency graph, a task queue including multiple development tasks is generated, and the task queue carries the execution order corresponding to each of the multiple development tasks; Determine the type of the development task, and generate the corresponding code or component based on the type of the development task; Based on the execution order of the multiple development tasks, the code or components corresponding to the multiple development tasks are assembled to obtain the program code corresponding to the requirements document.

[0006] Secondly, this disclosure provides a code generation apparatus, the apparatus comprising: The document retrieval module is used to retrieve the requirements documents; The document processing module is used to perform semantic analysis on the requirement document using a large language model, obtain multiple functional modules and the dependencies between them, and generate a dependency graph based on the multiple functional modules and the dependencies between them. The task generation module is used to generate a task queue including multiple development tasks based on the dependency graph, wherein the task queue carries the execution order corresponding to each of the multiple development tasks; A code generation module is used to determine the type of the development task and generate code or components corresponding to the development task based on the type of the development task. The code assembly module assembles the code or components corresponding to the multiple development tasks based on their respective execution order to obtain the program code corresponding to the requirements document.

[0007] Thirdly, this disclosure provides an electronic device, including: A memory on which computer programs are stored; A processor is used to execute the computer program in the memory to implement the code generation method described above.

[0008] Fourthly, this disclosure provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described code generation method.

[0009] Fifthly, this disclosure provides a computer program product, including a computer program, characterized in that the computer program implements the above-described code generation method when executed by a processor.

[0010] The above technical solution first utilizes a large language model to perform deep semantic analysis on the requirements document, identifying multiple functional modules and their interrelationships, and constructing a dependency graph reflecting their inherent constraints. Then, based on this graph and functional modules, a parallel development task queue with a defined execution order is generated. By identifying the technology type of each development task, the system calls the most suitable generation technology (such as generative AI or low-code platforms) to efficiently generate the corresponding code or components. Finally, according to the execution order in the task queue, these separately generated codes and components are automatically assembled and integrated, ultimately resulting in program code that highly matches the requirements document, meaning the obtained program code more accurately reflects the requirements in the requirements document.

[0011] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0012] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating a code generation method according to an exemplary embodiment of the present disclosure.

[0013] Figure 2 yes Figure 1 A flowchart of step S130.

[0014] Figure 3 This is a flowchart illustrating a code generation method according to an exemplary embodiment of the present disclosure.

[0015] Figure 4 This is another flowchart illustrating a code generation method according to an exemplary embodiment of the present disclosure.

[0016] Figure 5 This is another flowchart illustrating a code generation method according to an exemplary embodiment of the present disclosure.

[0017] Figure 6 This is a schematic diagram of a dependency graph shown according to an exemplary embodiment of the present disclosure.

[0018] Figure 7 This is a block diagram of a code generation apparatus according to an exemplary embodiment of the present disclosure.

[0019] Figure 8 This is a schematic diagram of the structure of an electronic device for executing a code generation method, according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0020] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0021] Figure 1 This is a flowchart illustrating a code generation method according to an exemplary embodiment of this disclosure. The method can be executed by an electronic device, which can be a terminal device or a server; that is, the method can be executed by the terminal device or the server alone, or by the terminal device and the server working together.

[0022] Taking the server as the execution entity as an example, the specific implementation process of this method is as follows: Step S110: Obtain the requirements document.

[0023] In this context, a requirements document refers to any formal or informal document written in natural language or semi-structured form that describes the goals, functions, behaviors, constraints, and rules of the software system to be developed.

[0024] A requirements document can be a document or set of data that describes one or more of the following: functional requirements, non-functional requirements, business rules, user use cases, data requirements, and constraints of the software system to be developed. Functional requirements describe the specific functions or services that the system must provide; non-functional requirements describe the quality attributes or constraints of the system's operation; business rules define or constrain the logic or strategies of business operations; user use cases describe functional requirements from the user's perspective; data requirements refer to the data entities, attributes, and relationships that the system needs to process; and constraints refer to limitations in terms of technology stack, compatibility, security, compliance, etc.

[0025] Requirements documents can be obtained in several ways: by receiving requirements documents uploaded by users, by automatically pulling requirements documents from other requirements management or project management tools through application programming interfaces, or by having product managers or business analysts directly input or paste requirements documents into an interface provided by an electronic device.

[0026] Step S120: Perform semantic analysis on the requirement document using a large language model to obtain multiple functional modules and their dependencies, and generate a dependency graph based on the multiple functional modules and their dependencies.

[0027] The dependency graph can be a weighted directed graph, where nodes are functional modules and edges are dependencies.

[0028] The core operation of semantic analysis of the requirements document using a large language model is to extract requirement elements, namely, to identify core elements in the text such as business processes, functional descriptions, business rules, use case descriptions, interface prototypes, and data requirements through natural language processing technology. Subsequently, the system aggregates closely related requirement elements based on semantic similarity to generate preliminary definitions of functional modules. Next, the system analyzes the logical, data, and temporal relationships between these functional modules, constructing and outputting a clear dependency graph based on the dependencies between them. The dependency graph is a directed graph with functional modules as nodes, various dependencies as edges, and attribute labels.

[0029] Specifically, the aforementioned large language model can be a model specifically trained and optimized for software engineering, particularly for requirements analysis and system design tasks, based on a general large language model. First, publicly available or anonymized requirement documents from different industries (such as finance, e-commerce, and enterprise services) are used. Dependency graphs of the functional modules corresponding to these requirement documents are obtained through manual annotation, thus completing sample construction. Then, the large language model is trained based on these constructed samples. During training, the large language model performs structured intermediate processing on the sample requirement text, including semantic analysis, module partitioning, and dependency analysis. Based on the intermediate processing results, a predicted dependency graph is generated. The model loss is calculated based on the annotated dependency graph and the predicted dependency graph, and then fine-tuned based on the model loss to obtain the trained large language model.

[0030] In the intermediate processing stage, the large language model first automatically identifies the functional components, data entities, and operational objects described in the text; then it analyzes the logical relationships and potential data flows between these identified entities; finally, it identifies the constraints and validation rules defining the business process from the requirement description. This intermediate stage yields data with detailed semantic association tags, which not only includes the original requirement items but also clarifies the relationships and rules between entities, providing a direct basis for subsequent modular grouping. This enables the generation of a predictive dependency graph based on the intermediate processing results.

[0031] To improve the accuracy of the obtained predictive dependency graph, one possible implementation involves performing text cleaning and logical structure recognition before semantic analysis of the requirements document. This standardization process standardizes the document, and the standardized data serves as input to the large language model. In this implementation, the preprocessing of the input requirements document includes automatically recognizing formats such as PDF, Word, and Markdown and extracting content without loss, as well as identifying the document's chapter structure and heading levels. Subsequently, the extracted text undergoes automated cleaning (removing irrelevant characters and correcting formatting errors).

[0032] Step S130: Based on the dependency graph, generate a task queue including multiple development tasks, wherein the task queue carries the execution order corresponding to each of the multiple development tasks.

[0033] Among them, the smallest technical execution unit that independently completes the development task is an independent execution unit (such as an AI agent, a developer, or an automation tool).

[0034] In one possible implementation, step S130 can be: constructing the dependency graph, functional module description, and decomposition principles (such as atomicity, explicit dependencies, and parallel optimization) into structured prompts and inputting them into the generative language model. The generative language model, by understanding the structured prompts, ultimately outputs a task queue that is directly parsable by the machine and contains structured information such as task descriptions, dependencies, and execution order.

[0035] This implementation method eliminates the need for complex environment modeling and reinforcement learning training, directly leveraging the planning and reasoning capabilities of generative languages.

[0036] Step S140: Determine the type of the development task, and generate the code or component corresponding to the development task based on the type of the development task.

[0037] The type of development task can be obtained by parsing the technical tags and descriptions of each development task in the task queue. The technical tags can be "front-end interface," "back-end API," "data model," etc. The descriptions refer to structured text or data sets that fully define the specific content, requirements, constraints, and context of a development task. After obtaining the type of development task, generative AI, intelligent agent workflow engines, and low-code platforms can be intelligently scheduled and integrated for targeted generation based on the task type: specifically, for back-end logic, data model, and interface tasks, generative large language models are mainly called, combined with the task context to generate program code; for example, for front-end interface tasks, the open APIs of the low-code platform are called to convert the design description into visual components; and for configuration, deployment, and testing tasks, the intelligent agent workflow engine automatically generates scripts and test cases. Throughout the process, the intelligent agent workflow engine is responsible for connecting and coordinating each generation step, performing code style checks, dependency resolution, and basic verification to ensure that the generated program code and components conform to standards and can be directly integrated, ultimately achieving efficient and high-quality multi-technology integrated output.

[0038] That is, step S140 above includes: parsing the task description and technical requirements of the development task, determining its task type based on a preset type matching rule, wherein the task type includes at least one of front-end interface task, back-end logic task, data model task, or interface task; if the task type is a back-end logic task, data model task, or interface task, calling a generative language model, and generating corresponding program code based on the detailed description, input / output specifications, and context information of the development task; if the task type is a front-end interface task, calling the open application programming interface of the low-code platform, and converting the description of the front-end interface task into a component of the low-code platform.

[0039] Step S150: Assemble the code or components corresponding to the multiple development tasks according to their respective execution order to obtain the program code corresponding to the requirements document.

[0040] In one possible implementation, the code or components corresponding to each development task can be retrieved and assembled based on the execution order and priority of each development task. The assembly process adopts an incremental integration mode. Each time a new component is added, the associated tests with the integrated components (such as interface call tests and data format verification) are automatically triggered. Assembly conflicts (such as inconsistent dependency versions and naming conflicts) are dynamically handled by the intelligent agent workflow engine. The components are gradually accumulated to form a complete set of components, and finally integrated into standardized program code through a unified configuration tool.

[0041] In another possible implementation, the backend business logic code and data model are first transformed into visual components supported by a low-code platform. Using the platform's drag-and-drop orchestration function, the core business logic and front-end interface framework are built according to the required workflow. Then, customized code snippets generated from the large language model (such as complex algorithm implementations and special interface adaptation code) are embedded into the corresponding component nodes through the platform's open interfaces. Data mapping rules and interaction logic between components are configured, and the platform's built-in integration and verification tools are used to complete component linkage testing. Finally, the complete program code integrating the visual components and customized code is exported.

[0042] In another possible implementation, the calling order of each of the multiple development tasks is obtained according to the task priority library and the execution order of each of the multiple development tasks; the code or components corresponding to the multiple development tasks are assembled based on the calling order of each of the multiple development tasks to obtain the program code corresponding to the requirements document.

[0043] By employing the method described in this application, firstly, a large language model is used to perform deep semantic analysis on the requirements document, identifying multiple functional modules and their interrelationships, and constructing a dependency graph reflecting their inherent constraints. Then, based on this graph and the functional modules, a parallel development task queue with a defined execution order is generated. By identifying the technology type of each development task, the system calls the most suitable generation technology (such as generative AI or low-code platforms) to efficiently generate the corresponding code or components. Finally, according to the execution order in the task queue, these separately generated codes and components are automatically assembled and integrated, ultimately yielding program code that highly matches the original requirements document, meaning the obtained program code more accurately reflects the requirements specification.

[0044] In one possible implementation, please refer to Figure 2 The above step S130 includes: Step S132: Divide the multiple functional modules included in the dependency graph according to the business domain to obtain functional modules under multiple business domains.

[0045] In one possible implementation, step S132 can be implemented using a community discovery algorithm (such as the Louvain algorithm) or a spectral clustering algorithm. By iteratively optimizing the modularity index, the modularity index is optimized to ensure that the internal connections of the divided communities (i.e., business domains) are tight and the external connections are sparse. The algorithm automatically determines the number and boundaries of business domains, ultimately obtaining the set of functional modules contained in each business domain.

[0046] Step S134: Generate multiple development tasks based on the functional modules under each business domain.

[0047] In one possible implementation, development tasks corresponding to the functional modules can be obtained from predefined task templates corresponding to pre-set functional modules (such as CRUD operations, user authentication, data reports, etc.).

[0048] Step S136: Based on the dependency relationships between functional modules in the dependency graph, determine the dependency relationships between each development task.

[0049] In one possible implementation, development tasks inherit the dependencies of their corresponding functional modules. Specifically, if functional module A depends on functional module B, then all development tasks corresponding to module A depend on all development tasks corresponding to module B. Furthermore, data dependencies are refined based on the input-output relationships between tasks (e.g., the output of task A is the input of task B), and technical dependencies are supplemented by technical constraints (e.g., compilation order), ultimately forming a task-level dependency network.

[0050] In another possible implementation, the data flow dependencies between development tasks can be determined based on the data information corresponding to the interfaces of the development tasks: if the output interface of task A matches the input interface of task B in terms of data type and semantics, then a dependency from A to B is established. Simultaneously, the resources required for task execution (such as database tables and external services) are analyzed; if task B needs to access resources created or initialized by task A, then a dependency from A to B is established. Finally, the dependencies of all development tasks are integrated.

[0051] Step S138: Determine the execution order of each development task according to the dependency relationship between each development task to obtain a task queue.

[0052] In one possible implementation, a directed acyclic graph (DAG) can be constructed based on the development tasks and their dependencies. A topological sorting algorithm (such as Kahn's algorithm) is then used to generate a linear execution order of the development tasks based on the DAG, ensuring that each task executes after all its predecessor tasks. This yields the execution order of the development tasks.

[0053] In another possible implementation, a priority score can be obtained for each development task. The priority score is calculated based on factors such as the importance of the business domain to which the task belongs, the depth of the task in the dependency graph (dependency chain length), and whether it is on the critical path. Then, under the premise of satisfying the dependencies, a priority scheduling algorithm (such as prioritizing tasks with higher priority) is used to determine the execution order of each development task.

[0054] By employing the steps S132-S136 described above, the dependency graph is divided to obtain functional modules under multiple business domains. Subsequently, a series of standard and executable development tasks are generated based on the functional modules under the business domains, improving the efficiency and consistency of task generation. This effectively solves the problems of coarse splitting, unclear dependencies, and difficulty in parallelization in traditional methods, providing a core guarantee for subsequent efficient code generation and integration.

[0055] In one possible implementation, functional points contained in each functional module under the same business domain can be extracted from the requirements document. Based on the data flow and semantic relationships between functional points, a clustering algorithm (such as hierarchical clustering) is used to form highly cohesive sub-functional modules. Then, for each sub-functional module, according to its technical characteristics (such as front-end, back-end, and data) and preset AI context window constraints, it is decomposed into multiple atomic development tasks (i.e., development tasks), ensuring that each task has appropriate granularity and single responsibility. Specifically, step S132 above includes: Step S132a: Generate multiple candidate business domain partitioning schemes, wherein each candidate business domain partitioning scheme defines a grouping method for dividing the multiple functional modules into multiple business domains.

[0056] The above-mentioned methods for generating multiple candidate business domain partitioning schemes can be either to randomly generate multiple candidate business domain partitioning schemes, or to cluster by adjusting the number of clusters to generate multiple candidate business domain partitioning schemes.

[0057] Step S132b: For each of the candidate business domain partitioning schemes, obtain the coupling degree evaluation value based on the number and type of cross-business domain dependency edges in the dependency graph; obtain the business integrity evaluation value based on the semantic similarity between functional modules in each business domain.

[0058] Among them, semantic similarity is positively correlated with business integrity assessment value. Different types of dependency edges can be assigned different coefficients, and the complexity assessment value can be calculated based on the coefficient corresponding to the number of each type of dependency edge.

[0059] Step S132c: Based on the service integrity assessment value and coupling degree assessment value corresponding to each of the candidate service domain partitioning schemes, determine the target service domain partitioning scheme from the multiple candidate service domain partitioning schemes.

[0060] In this implementation, step S132c may specifically involve obtaining a comprehensive evaluation value based on the business integrity evaluation value and coupling degree evaluation value corresponding to each candidate business domain partitioning scheme; and determining the candidate business domain partitioning scheme with the highest comprehensive evaluation value as the target business domain partitioning scheme.

[0061] By employing the above implementation method, multiple candidate partitioning schemes are generated (randomly generated or adjusted based on the number of clusters). For each candidate scheme, its business integrity evaluation value (based on the semantic similarity of functional modules within the domain, reflecting "high cohesion") and coupling evaluation value (based on the number and type of cross-domain dependency edges, reflecting "low coupling") are quantitatively calculated. By selecting the scheme with the highest comprehensive evaluation value, the system automatically achieves multi-objective optimization that maximizes intra-domain cohesion while minimizing inter-domain coupling. The final target business domain partitioning scheme ensures that the modules within each business domain are highly related in business semantics and closely collaborate.

[0062] In one possible implementation, for each business domain, step S134 includes: Step S134a: Extract multiple functional points from the requirements document that correspond to the functional modules under the business domain.

[0063] Specifically, the requirement document fragments corresponding to the functional modules under the current business domain can be located. Then, natural language processing technology is used to automatically parse the requirement document fragments, and a dependency parser is used to identify the core verb phrases in the sentences and their associated objects. These are then matched and filtered in combination with a predefined business action dictionary to extract the "action-object" pairs describing the specific operation units, forming a structured list of functional points.

[0064] Step S134b: Based on the multiple functional points, generate multiple candidate sub-functional module partitioning schemes, wherein each candidate sub-functional module partitioning scheme defines a grouping method for dividing the multiple functional points into multiple sub-functional modules.

[0065] Specifically, clustering algorithms can be used, with different clustering termination conditions preset (such as different inter-cluster distance thresholds or specifying different target cluster numbers K) to generate multiple candidate partitioning schemes with different granularities.

[0066] The aforementioned sub-functional module refers to a functional unit formed within a defined business domain by clustering closely related functional points. This unit has a single responsibility, clear boundaries, and can be independently designed and generated.

[0067] Among them, the sub-functional module is composed of multiple functional points within the business domain. Its granularity is between "functional module" and "development task". For example, in the "order management" business domain, functional points such as "order creation", "order payment" and "order delivery" can be aggregated into "order processing sub-functional module".

[0068] Step S134c: For each candidate sub-functional module partitioning scheme, obtain the cohesion of the sub-functional module based on the semantic similarity and dependency strength between each functional point in the sub-functional module; obtain the coupling degree of the sub-functional module based on the number of shared entities and dependency relationships between each sub-functional module and other sub-functional modules.

[0069] Among them, the cohesion of the sub-functional module is positively correlated with the semantic similarity and dependency strength between the functional points in the sub-functional module, and the number of shared entities and dependency relationships between each sub-functional module and other sub-functional modules is positively correlated with the coupling degree of the sub-functional module.

[0070] Step S134d: Determine the target sub-functional module partitioning scheme from the plurality of candidate sub-functional module partitioning schemes based on the cohesion and coupling of each sub-functional module.

[0071] Specifically, the evaluation score of the candidate sub-functional module partitioning scheme can be obtained based on the cohesion and coupling of each sub-functional module in the candidate sub-functional module partitioning scheme, and the candidate sub-functional module partitioning scheme with the highest evaluation score can be determined as the target sub-functional module partitioning scheme. The evaluation score of the candidate sub-functional module partitioning scheme is positively correlated with cohesion and negatively correlated with coupling.

[0072] Step S134e: Generate development tasks corresponding to each sub-functional module under the target sub-functional module division scheme.

[0073] By employing the steps S134a-S124e described above, multiple candidate clustering schemes are evaluated and selected based on quantitative indicators (semantic similarity, dependency strength, number of shared entities, etc.) to obtain the optimal sub-functional module partitioning scheme that can automatically generate maximum cohesion and minimum coupling.

[0074] In one possible implementation, step S134e includes: Step S134e1: Generate multiple candidate task partitioning schemes under the target sub-functional module partitioning scheme. The candidate task partitioning schemes define the partitioning method of dividing each sub-functional module in the multiple business domains into multiple development tasks.

[0075] Specifically, a fine-tuned generative language model can be used to perform splitting based on pre-defined splitting prompts (such as {Separation: High, Granularity: Medium, Decoupling Strategy: Contract-First}), thus obtaining a candidate solution. By traversing a pre-defined, reasonable parameter combination space, a set of diverse candidate task partitioning schemes can be automatically generated.

[0076] Step S134e2: For each of the candidate task partitioning schemes, obtain the task complexity score and feasibility score of each development task based on the feature information of each development task in each of the sub-functional modules.

[0077] Specifically, the characteristic information of a development task can include one or more of the following: task description, task type, dependencies, input / output specifications, and priority. The complexity of a development task can be calculated based on its technical depth, scope, and the number of dependent tasks. A feasibility score can be obtained based on the estimated number of tokens required and the token budget threshold. Technical depth refers to the level of technical difficulty in implementing the task, and scope refers to the number of functionalities involved in the development task. The estimated number of tokens required refers to the number of context tokens estimated to be consumed by the code generation model to generate the code for the task, based on the task description and type. The token budget threshold is the upper limit of available tokens for a single task, calculated based on the context window size of the selected AI model and the system's reserved space.

[0078] Step S134e3: Obtain the parallel execution degree score of the candidate task partitioning scheme based on the dependency relationship of multiple development tasks in the candidate task partitioning scheme.

[0079] Specifically, the number of prerequisite tasks for each development task can be obtained based on the dependencies between multiple development tasks, and the parallel execution score of the candidate task partitioning scheme can be obtained based on the number of prerequisite tasks for each development task. For example, the percentage of tasks with fewer than a specified number of prerequisite tasks out of the total number of tasks can be obtained, and the parallel execution score can be determined based on this percentage. A higher percentage corresponds to a higher parallel execution score.

[0080] Step S134e4: Based on the parallel execution score of each candidate task partitioning scheme and the task complexity score and feasibility score of each development task therein, determine the target task partitioning scheme from the multiple candidate task partitioning schemes.

[0081] Specifically, the total score for each candidate task partitioning scheme can be calculated based on the feasibility score (positive indicator) and task complexity score (negative indicator) of each task in the candidate task partitioning scheme, as well as the parallel execution score of the candidate task partitioning scheme. Then, the scheme with the highest total score is selected as the final target task partitioning scheme.

[0082] By employing the above method, after generating multiple candidate task partitioning schemes, each candidate scheme is quantitatively evaluated from three key dimensions: task complexity, technical feasibility, and parallel execution potential. The task complexity score integrates technical depth, scope breadth, and the number of dependent tasks, accurately reflecting the implementation difficulty; the feasibility score ensures that each task is within the capabilities of generative AI by comparing the expected number of tokens required with the token budget threshold; and the parallel execution score assesses the degree to which the scheme supports concurrent development based on task dependencies (such as the number of prerequisite tasks). This multi-dimensional evaluation makes the scheme comparison more objective and comprehensive. A total score is calculated based on parallel execution, feasibility, and complexity, and the scheme with the highest total score is selected as the final target task partitioning scheme. This multi-objective optimization decision-making process can maximize development parallelism and control task complexity while ensuring technical feasibility, thereby achieving an optimal balance between efficiency, reliability, and implementation cost.

[0083] For example, such as Figure 3 As shown in the embodiments of this application, a code generation method is provided. The overall design of this method follows an automated logic of "parsing-driven, intelligent decomposition, parallel generation, and closed-loop verification," aiming to build an efficient and accurate requirement-to-code conversion system. Its core lies in transforming abstract and complex natural language requirements into concrete, executable software code through a structured parsing model and a distributed parallel architecture, thereby achieving a deep understanding and efficient implementation of the requirement specification. The overall execution flow of the method includes six core stages: requirement preprocessing, AI intelligent parsing, task decomposition and planning, parallel task execution, multi-technology fusion generation, and integration testing and deployment. These stages, through close collaboration, constitute a complete automated closed-loop system from requirement input to product output.

[0084] I. Requirements Preprocessing: The received raw requirements document serves as input. The processing begins with automated parsing and content extraction of the raw requirements document, followed by text cleaning and logical structure recognition to standardize the document. This stage outputs a structured requirements dataset. This data will serve as input for the next stage, "AI Intelligent Parsing and Dependency Analysis," for in-depth semantic processing.

[0085] Specifically, requirement preprocessing can be performed by a preprocessing module. This module, located at the front end of the entire requirement parsing and generation system, serves as the entry point and starting point for the system's data flow, undertaking the crucial tasks of receiving, parsing, and standardizing the original requirement documents. As the system's data preprocessing center, this module utilizes a collaborative working mode combining "AI automatic extraction" and "human expert verification" to transform unstructured natural language requirements into high-quality structured data, providing accurate and unified input for subsequent intelligent parsing and decomposition. The module adopts a hybrid human-machine architecture, ensuring processing efficiency while guaranteeing the accuracy of core business logic through human intervention, fundamentally ensuring the quality of the final generated results.

[0086] Its workflow is a linear, sequential process, going through four stages: "document input → AI automatic extraction → human expert intervention → standardized output," aiming to transform raw, unstructured input into standardized, structured data output. For example... Figure 4 As shown, its complete process covers the following four stages in sequence: (1) Document input stage The process begins with the system receiving various initial requirement documents. These documents serve as the raw input for the process, and their diverse content and format are the starting point for this stage of processing. Upon receiving the raw requirement documents, the system initiates the data receiving process, receiving the raw requirement documents through a file upload interface or system integration.

[0087] (2) AI automatic extraction stage This phase takes the verified original document set as input and performs core parsing and initial structure tasks using automated technology. The process begins with preprocessing the input documents, including automatically recognizing formats such as PDF, Word, and Markdown and extracting content without loss, as well as identifying the document's chapter structure and heading levels. The extracted text is then automatically cleaned (removing irrelevant characters and correcting formatting errors). Finally, a natural language processing model is used for preliminary structuring: identifying functional entities and business objects, analyzing logical relationships, and marking metadata such as priorities, thereby generating a structured data draft with preliminary hierarchy, tags, and relationship annotations. This draft serves as the output of this phase, providing a directly operable foundation for subsequent manual review.

[0088] (3) Stage of human expert intervention This phase uses AI-generated structured data drafts as input, and the process revolves around manual verification and correction. Product managers or business experts use the system's visual review interface to review each item of the AI-extracted results, performing operations such as adding, deleting, and modifying data to calibrate the business logic and supplement key business background information. After iterative review to ensure that the extracted results accurately reflect the business intent, experts finalize the version. The output of this phase is a meticulously proofread and corrected structured data document that has undergone in-depth verification and correction by business authorities.

[0089] (4) Standardization and Output Stage This stage uses meticulously crafted structured data as input to complete the final standardized encapsulation of the data. The process performs integrity checks and logical consistency checks on the input based on a predefined data pattern to ensure it conforms to the system's internal standards. Subsequently, the validated data is serialized into standard machine-readable formats such as JSON, and metadata such as version identifiers is appended, then packaged to generate the final standard data package. This standardized requirement data serves as the module's final output, and its format and quality fully meet the input requirements of the next stage, the "AI Intelligent Parsing and Dependency Analysis Module," marking the end of a complete transformation cycle from raw requirements to well-structured data.

[0090] Second, AI-powered intelligent analysis uses structured requirement data output from the requirement preprocessing stage as input. Its core operation is extracting requirement elements, specifically identifying core elements in the text such as business processes, functional descriptions, business rules, use case descriptions, interface prototypes, and data requirements through natural language processing technology. Subsequently, the system aggregates closely related requirement elements based on semantic similarity, generating preliminary definitions of functional modules. Next, the system analyzes the logical, data, and temporal relationships between these functional modules, constructing and outputting a clear dependency graph based on the dependencies between them. The dependency graph is a directed graph with functional modules as nodes, various dependencies as edges, and attribute labels. It is a key intermediate product for transforming natural language requirements into a computable and analyzable engineering blueprint, directly serving subsequent intelligent task decomposition and parallel planning. This graph is a crucial input for decision-making in the "intelligent task decomposition and planning" stage.

[0091] Develop multivariate information extraction technology based on natural language processing to accurately identify functional requirements, performance indicators, and business rules; construct a network of relationships between requirement elements to form a structured requirement knowledge graph; and solve the problem of automatic detection and handling of requirement ambiguity and inconsistency in complex business scenarios.

[0092] Specifically, the AI ​​intelligent parsing process can be executed by the AI ​​intelligent parsing and dependency analysis module. This module is located at the core of the entire requirement processing flow and serves as the system's "intelligent decision-making center." It undertakes the critical tasks of extracting deep semantics from structured requirement data, identifying functional modules, and analyzing their dependencies. As the system's intelligent analysis engine, this module transforms preprocessed structured requirements into an executable system architecture design through the comprehensive application of advanced AI technologies such as natural language processing, machine learning, and graph algorithms. The module adopts a multi-layered analysis architecture, ensuring analysis depth while optimizing processing efficiency through algorithm optimization, providing accurate module partitioning and dependency graphs for subsequent parallel generation.

[0093] like Figure 5 The diagram illustrates the complete workflow of the AI ​​intelligent analysis and dependency analysis module for AI intelligent analysis. The specific steps are explained below: (1) Semantic analysis stage This phase takes the standardized requirements document from the previous phase as input. The core of the process is to perform multi-layered, deep semantic analysis on this structured data. The system first automatically identifies the functional components, data entities, and operational objects described in the text; then it analyzes the logical relationships and potential data flows between these identified entities—this step is accomplished by analyzing sentence structure, action goals, and context; finally, the system identifies the constraints and validation rules defining the business process from the requirements description. The output of this phase is data with detailed semantic association tags. It not only contains the original requirements items but also clarifies the relationships and rules between entities, providing a direct basis for subsequent modular grouping.

[0094] (2) Module division stage This stage uses data with detailed semantic association labels from the previous stage as input, aiming to cluster discrete requirement items into cohesive functional modules based on semantic and functional characteristics. The process first converts the textual information in the requirement descriptions into a series of numerical vectors. Specifically, using embedding techniques from natural language processing, the textual expression of each requirement item is mapped to a multi-dimensional numerical sequence (e.g., the requirement "user login" might be represented as multi-dimensional coordinates like [0.12, -0.45, 0.78, ...]) to allow the computer to perform precise mathematical calculations and comparisons. Based on this, a computable semantic feature space is constructed by aggregating the vectors of all requirement items. Each point in this space represents a requirement item, and the distance between points reflects their semantic and functional similarity. Subsequently, a clustering algorithm is applied within the feature space to automatically identify similarity based on the distance between vectors and initially delineate module boundaries. For example, requirement items with very close vector distances, such as "user login" and "password verification," are automatically grouped into the same candidate module. Finally, the system will optimize and adjust the initial boundaries by evaluating metrics such as module cohesion and coupling, ensuring the logical and technical rationality of the partitioning results. The output of this stage is a set of candidate functional modules and a detailed list of their included requirements, clarifying the initial components of the system.

[0095] (3) Dependency Analysis Phase This phase takes a set of candidate functional modules as input, and its core task is to construct a complete system dependency relationship. The process first delves into various types of dependencies between modules, including call dependencies, data flow dependencies, and time sequence dependencies. Specifically, by analyzing the interface definitions, data entities, and operation flows in the module descriptions, it identifies which modules need to call services from other modules, which modules' output data is the input of another module, and which operations can only be executed after other operations are completed. Based on these discovered relationships, the system constructs a dependency graph, creating a visual architectural relationship network with modules as nodes and dependencies as edges, and labeling each edge with dependency type and strength. Then, by performing topological sorting and path calculation on the graph, the critical path is identified—the sequence of tasks that determines the shortest total project duration and cannot be delayed. The final output of this phase is a dependency graph with critical path markers, which accurately depicts the internal constraints and interactions of system components, providing a core decision-making basis for intelligent task decomposition.

[0096] (4) Results integration stage This phase uses a dependency graph as input to generate a standardized, structured design document that can directly guide subsequent development. The process first systematically integrates and converts the node and edge information in the graph, automatically generating a structured architecture design document. This document clearly lists the complete definitions, interface descriptions, and inter-module dependencies of all functional modules. Based on this, the system automatically assigns a development priority to each module. This process is achieved by analyzing the module's position in the dependency graph (higher priority for modules on the critical path), the number of other modules it directly or indirectly depends on (higher dependency complexity requires priority), and combining this with the business value weights defined in the initial requirements. The output of this phase is a structured architecture design specification. As the final result of this module, it provides clear, quantifiable, and priority-guided architectural input for the next stage, "Intelligent Task Decomposition and Planning," completing the transition from requirements analysis to high-level design.

[0097] The third step, task decomposition planning, takes the dependency graph as input, and its core objective is to transform the functional modules in the graph into parallel executable development tasks. To achieve this goal, the system strictly adopts a "three-layer, four-principle" decomposition method: first, decomposition by business domain to define macro-level boundaries; second, decomposition by functional module within each business domain to identify functional components; and finally, decomposition by development task, refining each component into specific implementation-oriented, single-responsibility development tasks, such as components and pages for generating front-end interfaces, APIs and services for implementing back-end business logic, designing data models and storage structures, and configuring automated workflows or integration scripts. This process marks each task with estimated complexity, clear pre- and post-dependencies, and assigns execution priorities based on critical path analysis results. The output of this step is a structured task queue containing detailed definitions of all tasks. This queue clarifies the content, technology type, and dependencies of each subtask and serves as the direct input for scheduling in the "parallel task execution and dependency management" step.

[0098] like Figure 6 As shown, an exemplary diagram of a dependency graph is presented. Nodes (functional modules) in this dependency graph refer to logically cohesive independent functional units identified from the requirements. Directed edges (dependencies) refer to the constraints and connections between modules, with the arrow direction indicating the direction of dependency (e.g., A depends on B, meaning B must be completed before or in collaboration with A).

[0099] The following example, using the development requirements of a conference room management system, demonstrates the application of the "three-layer, four-principle" model. The business domain layer divides the system into two independent domains: conference room management and reservation management. The functional module layer implements highly cohesive functional grouping within each business domain. The development task layer breaks down the functional modules into independently executable specific development tasks. Dependencies accurately reflect the logical constraints and development sequence between the various components of the system.

[0100] Specifically, task decomposition and planning can be executed by the intelligent task decomposition and planning module. This module is located at a critical decision-making stage in the entire requirements processing flow, serving as a bridge between system architecture design and concrete execution. It bears the important responsibility of decomposing functional modules into executable development tasks. As the system's "task planning hub," this module transforms the complex system architecture into a highly efficient parallel development task flow through multi-dimensional decomposition strategies and intelligent planning algorithms. The module adopts a strategic task decomposition architecture, ensuring task quality while optimizing execution efficiency through intelligent scheduling, providing a clear task blueprint and resource allocation scheme for subsequent parallel code generation.

[0101] The task breakdown process can be completed in the following stages: (1) Task decomposition phase This phase takes the dependency graph from the previous stage as input. Its core task is to systematically decompose the functional modules defined in the dependency graph into independently executable development tasks based on the "three-layer, four-principle" model. The process strictly follows the "three-layer" structure: the decomposition must proceed progressively from "business domain → functional module → development task," while adhering to the four principles of "low coupling, high cohesion, parallelizability, and verifiability" to ensure that each decomposed unit can be executed independently and ultimately seamlessly integrated.

[0102] The first step is to perform a layer-one "splitting by business domain," which achieves intelligent partitioning by executing a business domain partitioning algorithm. This algorithm takes the set of functional modules and the dependencies between modules in the dependency graph as input, quantitatively evaluates the business integrity of each candidate business domain (based on the tightness of the business logic association between modules within the domain), calculates the coupling degree between different business domains (based on the number and type of cross-domain dependency edges), and introduces a scale balance constraint. Finally, it outputs a business domain partitioning scheme that maximizes business cohesion, minimizes inter-domain coupling, and has an appropriate size for each domain.

[0103] The first layer involves splitting the system by "business domain" to solve the problem of "parallelism in major directions." The entire system is first broken down into independent "business domains" based on core business scenarios. Each business domain corresponds to a "business unit." Units interact with each other through predefined interfaces (from a pre-processed "interface list"), without direct coupling.

[0104] Based on the "business process description" and "user stories" in the requirements specification, ensure that each business domain covers a complete "user value loop" (such as the "product domain" covering the complete user needs of "finding products → viewing details → checking inventory").

[0105] Parallelism: Each business domain can be treated as an independent "large task package" and assigned to different "business intelligence agents" (such as "product domain intelligence agent" and "order domain intelligence agent") to carry out subsequent module decomposition and generation work in parallel.

[0106] For example, for each candidate business domain partitioning scheme, the total business integrity of all business domains is maximized, while the total interface complexity (coupling) between different business domains is minimized.

[0107] Business domain optimization target = Sum of business integrity scores across all business domains - Interface complexity penalty coefficient × Sum of interface complexity between all different business domain pairs - Scale imbalance penalty coefficient × Scale imbalance of the business domain partitioning scheme maxΣ_{b∈B}Integrity(b)-λ_c×Σ_{b≠b'}Coupling(b,b')-λ_s×Imbalance(B) maxΣ_{b∈B}V(b)-λ_b×Σ_{b≠b'}InterfaceComplexity(b,b') The parameters are explained below: Integrity(b): Business integrity score of business domain b, used to comprehensively evaluate the business correlation and coverage of functional modules within the domain, with a value range of [0,+∞). b: A specific business domain; B: Represents a candidate business domain partitioning scheme, which includes the set of all business domains; λ_c: Interface complexity (coupling) penalty coefficient, used to adjust the tolerance for inter-domain coupling, with a typical value range of [0.1, 1.0]. Coupling(b,b'): The interface complexity (i.e., coupling degree) between business domains b and b', calculated based on the weighted average of the number and type of cross-domain dependency edges in the dependency graph; λ_s: Penalty coefficient for scale imbalance, used to adjust the intensity of the requirement for scale balance in the business domain, with a typical value range of [0.05, 0.5]. Imbalance(B): The scale imbalance of business domain partitioning scheme B, calculated based on the difference between the number of functional modules contained in each business domain and its average value.

[0108] The calculation process is as follows: Calculation of the business integrity assessment value Integrity(b): ① For a specific business domain b in a candidate partitioning scheme, first analyze the functional description text of all functional modules in the domain.

[0109] ② By calculating the degree of aggregation of these modules in the semantic feature space (e.g., average semantic similarity) and combining it with the degree of association of these modules in the business process described in the requirements, a basic score representing business cohesion is obtained.

[0110] ③ The basic score is weighted according to the coverage and completeness of business objectives within the domain, and the business integrity assessment value Integrity(b) of business domain b is finally obtained.

[0111] Then, the coupling degree Coupling(b,b') evaluation value is calculated: ① For any two different business domains b and b' in the same candidate business domain partitioning scheme, check all dependency edges in the dependency graph that connect these two domains.

[0112] ② For these cross-domain dependency edges, quantify them and assign corresponding weights according to their type (such as call dependency, data dependency) and complexity (such as data format constraints, call frequency).

[0113] ③ Sum the weights of all dependent edges pointing from business domain b to business domain b' to obtain the coupling degree between the two domains, Coupling(b,b').

[0114] ④ Traverse all pairs of distinct business domains (b, b') in the candidate scheme, repeat steps ① to ③, and calculate the coupling degree of each pair of business domains.

[0115] ⑤ Sum the coupling degrees Coupling(b,b') between all business domain pairs to obtain the total coupling degree Σ_{b≠b'}Coupling(b,b') under the candidate business domain partitioning scheme.

[0116] Calculate the scale imbalance (Imbalance(B)): ① For a candidate partitioning scheme B, count the number of functional modules contained in each business domain b.

[0117] ② Calculate the average number of these modules, and then calculate the absolute deviation of the number of modules in each business domain from this average.

[0118] ③ Based on these absolute deviations (e.g., calculate their standard deviation or mean absolute deviation), quantify the dispersion of business domain size in the entire partitioning scheme. This value is called the size imbalance impalance (B).

[0119] The comprehensive evaluation value (objective function value) and scheme selection are as follows: ① For the current candidate partitioning scheme B, substitute its total business integrity score total_integrity=Σ_{b∈B}Integrity(b), total coupling degree total_coupling=Σ_{b≠b'}Coupling(b,b'), and scale imbalance degree Imbalance(B) into the objective function formula: objective_value=total_integrity-λ_c×total_coupling-λ_s×Imbalance(B) to calculate the comprehensive evaluation value (objective function value) objective_value of the scheme.

[0120] ② Enumerate or search all possible business domain partitioning schemes through heuristic algorithms, and repeat all the above calculation processes for each candidate scheme to obtain its corresponding objective_value.

[0121] ③ Compare the objective_values ​​of all candidate solutions and select the solution that maximizes the objective_value as the final and optimal business domain partitioning result.

[0122] Next, within each defined business domain, the second layer of "splitting by functional module" is executed. This step is achieved by calling the "functional module splitting algorithm." This algorithm takes the set of functional points and their relationship network (including semantic associations and dependencies between functional points) within the current business domain as input, and optimizes the calculation with the goal of maximizing module cohesion and minimizing inter-module coupling. Finally, it outputs an optimal functional module partitioning scheme, thereby refining the business domain into a series of functional modules with single responsibilities and clear boundaries.

[0123] Among them, it is broken down into "functional modules" to solve the problem of "parallel tasks within the domain".

[0124] Each business domain is further broken down into "functional modules". A module is the "smallest functional unit that can be generated independently" (such as the combination of "page + logic + data model" in a low-code platform). It needs to meet the requirements of "high cohesion" (strong correlation of functions within the module) and "low coupling" (interaction between modules is only through interfaces).

[0125] Splitting steps: Extract "core functional points": From the structured requirements list, filter all functional requirements under the current business domain (such as the functional points of the "product domain": product addition, product editing, product category management, product search, and inventory query).

[0126] Clustering by "functional logical correlation": Strongly related functional points are merged into one module (e.g., "product addition + product editing + product deletion" are merged into "product management module" because all three operate on the "product data model" and share permission verification logic).

[0127] Define the three key elements of a module: Define clear boundaries for each module to avoid conflicts during subsequent generation. Data model: Database tables / entities that the module depends on (e.g., the "Product Management Module" depends on the "Product Table" and "Product Category Table").

[0128] Input / output: The requests received by the module (such as "product ID") and the results returned (such as "product details") need to be preprocessed into an "interface list".

[0129] Acceptance criteria: The module must meet the functional verification conditions (such as "after a product is added, the inventory table must be updated synchronously").

[0130] Parallelism: Different modules under the same business domain can be executed in parallel (e.g., the "product management module" and the "inventory management module" can be processed simultaneously by two different "function generation agents"), as long as the interface specifications between modules are agreed upon in advance.

[0131] For example, when determining the target sub-functional module partitioning scheme from the multiple candidate sub-functional module partitioning schemes based on the cohesion and coupling of each sub-functional module, the candidate sub-functional module partitioning scheme with the highest module optimization can be selected as the target sub-functional module partitioning scheme. The functional module partitioning scheme score = the sum of the cohesion of all functional modules - the penalty coefficient × the sum of the coupling between all different pairs of functional modules, i.e., maxΣ_{f∈F}Cohesion(f)-λ_f×Σ_{f≠g}Coupling(f,g).

[0132] The parameters are explained below: Cohesion(f): Cohesion of sub-functional module f, calculated based on semantic similarity and data dependency strength between functional points within the module; f, g: Sub-functional modules respectively; F: A candidate sub-functional module partitioning scheme, i.e., the set of all sub-functional modules; λ_f: Coupling penalty coefficient, used to adjust the tolerance for coupling between modules, with a typical value range of [0.1, 1.0]; Coupling(f, g): Coupling degree between functional modules f and g, calculated based on shared data entities and call dependencies between modules.

[0133] Calculation process: Cohesion is calculated as follows: ① Initialize the total cohesion to 0; ② Traverse each functional module f in the candidate partitioning scheme F; ③ For the current functional module f, calculate its cohesion Cohesion(f): First, calculate the average semantic similarity of the description texts of all functional points in the module, then calculate the sum of the strength of the data dependencies between functional points in the module, and finally sum the two values ​​by weight to obtain Cohesion(f). ④ Add this cohesion value to total_cohesion; ⑤ After processing all functional modules in set F, the final total_cohesion is the sum of the cohesion of the partitioning scheme.

[0134] The coupling degree is calculated as follows: ① Initialize the total coupling degree to 0; ② Traverse all distinct functional module pairs (f, g) in the candidate partitioning scheme F, where f ≠ g; ③ For the current functional module pair (f,g), calculate its coupling degree Coupling(f,g): First, count the number of shared data entities between module f and module g, then count the number of mutual call dependencies between the two modules, and finally sum the two values ​​by weight to obtain Coupling(f,g); ④ Add this coupling value to total_coupling; ⑤ After processing all functional module pairs, the final total_coupling is the sum of the coupling degree of this partitioning scheme.

[0135] The scoring calculation and scheme selection for the functional module division scheme are as follows: ① Calculate the scoring of the functional module division scheme: objective_value = total_cohesion - λ_f × total_coupling; ② Repeat all the above calculation steps to calculate the corresponding objective_value for each candidate functional module partitioning scheme; ③ Compare the objective_values ​​of all candidate schemes and select the functional module partitioning scheme that maximizes the objective_value as the final result.

[0136] Subsequently, a third layer of "splitting by development task" is executed for each functional module. This step is achieved by calling the "development task splitting algorithm." This algorithm takes the definition of the functional module (including its functional description, internal functional points, and technical requirements) and global resource constraint configuration (the core being the AI ​​model's context window size) as input. Its core is to evaluate task difficulty through a three-dimensional complexity model (technical depth, scope breadth, and number of dependent tasks) to control granularity, and to introduce an AI context window adaptation mechanism. Feasibility checks are performed through calculation and estimation to ensure that each task is within the AI's processing capabilities. Finally, the algorithm decouples the functional modules and filters them into a set of atomic, feasibility-verified development tasks (such as developing the front-end interface, implementing the back-end API, designing data models, etc.), and defines clear input and output specifications for each task.

[0137] The purpose of breaking down the process into "development tasks" is to address the issue of "parallel steps within modules." That is, each functional module needs to be broken down into "development tasks that can be performed by a single tool / role," covering the entire chain of "AI analysis → model design → code generation → testing and verification," ensuring that the granularity of the tasks matches the capabilities of the tools (e.g., if AI cannot generate "data model + page + logic" in one go, it needs to be broken down into independent tasks).

[0138] Key principle: The "dependencies" between tasks must be clearly marked (e.g., the "interface generation task" depends on the "data model design task" and must be executed after the data model is determined; the "interface adaptation task" depends on the "business logic generation task"). Non-dependent tasks can be performed in parallel (e.g., the "data model design task" and the "module requirement analysis task" can be started simultaneously, as long as the input information is complete).

[0139] The task granularity must match the "AI context window": If the AI ​​tool's context is limited to 2000 tokens, then the "module requirement parsing task" must focus on a single module to avoid parsing multiple modules at the same time, which would cause context overflow.

[0140] Specifically, after generating multiple candidate task partitioning schemes under the target sub-functional module partitioning scheme, for each candidate task partitioning scheme, its task complexity score = technical depth × scope breadth × number of dependent tasks Complexity(t)=TechnicalDepth(t)×ScopeBreadth(t)×DependencyCount(t) Task feasibility score = Indicator function (Available Token budget ≥ Expected number of Tokens generated) Feasibility(t)=I(TokenBudget(t)≥EstimatedTokens(t)) Parameter description: Complexity(t): The overall complexity of development task t; TechnicalDepth(t): The technical depth of development task t, which is evaluated based on factors such as the difficulty of the required technology stack, and the value range is [1,5]. ScopeBreadth(t): The breadth of the development task t, representing the number of functional components or business points required for its implementation; DependencyCount(t): The number of dependent tasks of development task t, that is, the number of other tasks that must be completed before it can begin; Feasibility(t): A feasibility indicator function for development task t. The value is 1 when the task is feasible, and 0 otherwise. TokenBudget(t): The available token budget allocated to development task t, which is the size of the AI ​​model context window minus the number of tokens used by system prompts and output buffers; EstimatedTokens(t): The number of tokens expected to be consumed in executing and generating the output of development task t.

[0141] Calculation process: The task complexity is calculated as follows: For each development task t, obtain TechnicalDepth(t), ScopeBreadth(t), and DependencyCount(t). Calculate Complexity(t)=TechnicalDepth(t)×ScopeBreadth(t)×DependencyCount(t) The feasibility of the task is checked as follows: For each development task t, compute TokenBudget(t). TokenBudget(t)=ContextWindow-[PromptTokens+OutputBuffer] Obtain EstimatedTokens(t) (estimated based on historical data or model); If TokenBudget(t) ≥ EstimatedTokens(t), then set Feasibility(t) = 1; otherwise, set Feasibility(t) = 0.

[0142] The task selection process is as follows: traverse all development tasks t, retain only those development tasks that satisfy Feasibility(t)=1 as feasible tasks, define clear input and output specifications for each feasible task, and then obtain the parallel execution degree score of the candidate task partitioning scheme based on the dependency relationship of multiple development tasks in the candidate task partitioning scheme. In this process, the initial parallelizable task ratio and critical path impact can be calculated to evaluate the overall parallelism, and resource allocation can be optimized through load balancing index.

[0143] For example, the parallel execution score = the initial proportion of parallelizable tasks + the sum of the critical path time ratios of all tasks.

[0144] ParallelScore(T)=|{t∈T|Predecessors(t)= }| / |T|+Σ_{t∈T}[1-CriticalPathRatio(t)] Load balance = 1 - Standard deviation of workload / Mean of workload LoadBalance=1-σ(Workload(a_i)) / μ(Workload(a_i)) Parameter description: ParallelScore(T): Parallelism score of candidate task partitioning scheme T, with a value range of [0,2]. Predecessors(t): The set of preceding tasks for task t; CriticalPathRatio(t): The percentage of time task t spends on the critical path, i.e., the proportion of the estimated duration of the task to the total project duration. LoadBalance: Load balancing degree, with a value range of [0,1]. Workload(a_i): The estimated workload of agent a_i, which is usually calculated based on the complexity, priority and resource requirements of all tasks assigned to the agent. σ: Standard deviation function, used to calculate the dispersion of a set of values; μ: Mean function, used to calculate the average of a set of values.

[0145] Calculation process: Parallelism score calculation: ① Initialize the count of parallelizable tasks: independent_count = 0.

[0146] ② Iterate through each task t in the task set T.

[0147] ③ Check if the set of preceding tasks for task t, Predecessors(t), is empty (i.e., Predecessors(t) = ...). If empty, it indicates that the task can be executed at the start of the project without any dependencies waiting, and the value of independent_count is incremented by 1.

[0148] ④ Calculate the initial parallelizable task ratio: parallel_ratio = independent_count / |T|, where |T| is the total number of tasks in the candidate task partitioning scheme T.

[0149] ⑤ Initialize the critical path complement and critical_sum = 0.

[0150] ⑥ Iterate through each task t in the candidate task partitioning scheme T again.

[0151] ⑦ For the current task t, calculate its complement [1-CriticalPathRatio(t)] based on its critical path time ratio (CriticalPathRatio(t)). This value reflects the degree to which the task is not in the critical path's urgent part; the larger the value, the more flexible its scheduling and the higher its parallel potential.

[0152] ⑧ Add the complement value calculated in step ⑦ to critical_sum.

[0153] ⑨ Calculate the parallel execution score of the final candidate task partitioning scheme: ParallelScore(T) = parallel_ratio + critical_sum. This score comprehensively reflects the concurrency potential of each task in the candidate task partitioning scheme during the startup phase and the overall execution process.

[0154] Load balancing calculation: ① Initialize an empty workload list workload_list=[] to store the estimated workload values ​​of each agent.

[0155] ② Iterate through all execution agents a_i that are to be assigned tasks.

[0156] ③ For the current agent a_i, calculate its estimated workload Workload(a_i). The specific method is: for all tasks t that are (initially or in simulation) assigned to the agent, sum up the complexity (t) of these tasks (or other defined workload metric), i.e., Workload(a_i)=Σ_{t∈Tasks(a_i)}Complexity(t).

[0157] ④ Add the calculated Workload(a_i) to the workload list.

[0158] ⑤ Based on all workload values ​​in workload_list, calculate the standard deviation σ(workload_list) and mean μ(workload_list) of these values.

[0159] ⑥ Calculate the load balance using the formula LoadBalance=1-σ(workload_list) / μ(workload_list). This metric quantifies the uniformity of workload distribution among agents; the closer the value is to 1, the more balanced the load.

[0160] Throughout the decomposition process, the principle of "moderate scale" was adhered to. After each layer of decomposition, the system would assess the estimated complexity, implementation points, and dependencies of the resulting components, and dynamically adjust their granularity to ensure that they were neither too large to handle nor too fragmented to increase management and coordination costs.

[0161] The final output of this stage is a structured queue of tasks to be executed. It clearly lists each atomic task and its business domain, functional module, technology type, estimated workload, resource feasibility status, and preliminary dependencies. This queue will serve as the direct basis for in-depth optimization and scheduling in the next stage, "Dependency and Priority Management."

[0162] Finally, the system implements dynamic priority allocation, using the parallelism score and load balancing pre-analysis results as key inputs. These are then comprehensively evaluated along with the critical path, task business value, technical risks, and actual resource requirements to assign a precise and executable priority to each task. This systematically applies the "priority sorting" principle, aiming to achieve globally optimal allocation of system resources. The output of this stage is an optimized task queue with clearly defined priorities and strengthened dependencies, based on quantitative evaluation of concurrency and resource balance. It defines a scientific execution order and serves as authoritative input for efficient scheduling in the next stage.

[0163] It is worth mentioning that the essence of requirement decomposition is to "break down large problems into smaller problems, so that each small problem can be solved independently by a single tool / role, and then reassembled into a complete system through a collaborative mechanism".

[0164] Dimensional breakdown: from "business" to "function" and then to "technology", progressing step by step to ensure that the "business value" and "technical boundaries" of each breakdown unit are clear.

[0165] Parallelism prerequisite: By preprocessing and sharing an asset library, each parallel task has "independent input information" and "clear output criteria", avoiding dependency conflicts.

[0166] Quality Assurance: Through "three-level verification" and "toolchain automation", quality is controlled synchronously during parallel execution, avoiding a large number of compatibility issues during later integration.

[0167] This systematic task planning process ensures the manageability and efficiency of complex system development. Through scientific multi-dimensional decomposition, intelligent dependency management, and precise task definition, this module lays a solid foundation for subsequent parallel code generation, significantly improving the efficiency and quality of the entire software development process.

[0168] IV. Parallel Task Execution refers to receiving a structured task queue from the previous stage as input. Based on the dependencies and priorities between tasks, the system dynamically allocates multiple subtasks to multiple execution agents through a scheduling system. The scheduling system identifies all "executable tasks" in the task queue whose prerequisites have been satisfied in real time, and matches and assigns them to agents in the agent resource pool that meet the task generation technology requirements and are currently available, thereby initiating concurrent task execution. After each agent begins execution, a core coordination service continuously monitors the execution progress and status of all tasks. Its main purpose is to coordinate the execution status of each subtask, ensuring they proceed according to predetermined dependencies and logical order. For example, it ensures that subsequent tasks are triggered only after the completion of prerequisite tasks and manages data transfer between tasks. Simultaneously, each agent can obtain necessary information from a unified context service during execution, ensuring collaborative work and data consistency in a parallel environment. The output of this stage is a collection of task outputs completed by all agents and a log recording the execution status and collaborative events of each task. These outputs will serve as input for the next stage, "Multi-Technology Fusion Generation."

[0169] The intelligent task decomposition and planning algorithm aims to solve the core problems of traditional requirement processing methods, such as coarse-grained task decomposition, improper handling of dependencies, and low parallel efficiency. Through a systematic decomposition strategy and an intelligent planning mechanism, this algorithm transforms complex software requirements into a set of development tasks with clear structure, well-defined dependencies, and efficient parallel execution, providing a scientific and reliable task planning foundation for AI-driven automated code generation.

[0170] V. Multi-technology integration generation: The input to this process is the set of task outputs from the previous stage and the original task definition. Upon receiving a specific task, each executing agent comprehensively analyzes the task type, technology stack requirements, and contextual information. This drives the agent to collaboratively generate code using three technologies: generative AI, agent workflow, and low-code platform. Specifically, the agent first uses the generative AI model to generate business logic code, data access layer code, or basic algorithm implementations based on the task description. For tasks involving user interfaces or visualization processes, the agent then calls the open API of the low-code platform to convert the design logic into platform-specific visualization components or models. Simultaneously, the agent workflow engine runs throughout the process, connecting the automated steps from code generation and dependency resolution to basic verification, ensuring the orderly and controllable generation process. Through the collaboration of these technologies, the system can selectively generate code for different parts such as the front-end interface, back-end logic, and data models, achieving optimal technology selection and maximizing generation efficiency. After the generation process is complete, the system performs preliminary organization and standardization checks on the generated results, including unifying code style, validating basic syntax, ensuring the project structure conforms to the agreement, and generating the final integration project directory required for integration. This directory serves as the output of this stage and is the direct input for the next stage, "Integration, Testing, and Deployment," to complete the building and verification process.

[0171] If a generative AI model is invoked to generate business logic code, the model first performs a deep understanding of the task requirements and code planning, analyzing business logic, technical constraints, and performance requirements to determine the optimal implementation scheme and technical route. Subsequently, based on this planning, the model automatically generates core business logic code snippets that conform to coding standards and are highly readable. For tasks involving data persistence, the system specifically generates efficient SQL query statements, data model definitions, and secure data access layer code. Simultaneously, for tasks that need to provide or call services externally, the model automatically generates clear application programming interface (API) definition code based on interface specifications, and generates corresponding unit test cases to provide a basic guarantee for functional correctness. The output of this stage is a set of high-quality source code and configuration scripts specific to the task, providing raw materials for subsequent integration and assembly.

[0172] Upon obtaining the invocation order of each development task, an automated task execution workflow can be initiated. The intelligent agent, following a pre-defined pipeline, sequentially triggers code style checks, dependency resolution, static analysis, and other stages, ensuring seamless integration of various technical actions. The workflow intelligently calls the open APIs of the low-code platform based on the task type, passing suitable logic (especially user interface and business process logic) to the platform for processing, achieving an organic combination of traditional coding and visual development. Simultaneously, an independent quality assurance workflow is embedded, automatically performing code security scanning, potential defect detection, and basic performance analysis to ensure the intrinsic quality of the generated code. Before producing the final deployment package, the workflow also automatically generates corresponding containerization configurations, cloud service orchestration scripts, or continuous integration / continuous deployment (CI / CD) pipeline definitions based on the target runtime environment (e.g., testing, production). The output of this stage is a quality-verified, standardized project package containing a complete deployment description.

[0173] If components are generated using code technology, suitable general logic or UI code can be automatically converted into reusable low-code visual components using tools or APIs provided by the platform, and then stored in the component library. Subsequently, developers or systems can use the graphical designer provided by the low-code platform to quickly assemble these components into complete user interfaces and visual business processes through drag-and-drop, significantly reducing the technical barrier to front-end development. For back-end service integration, the platform can automatically configure connection points with external systems or internal microservices, API gateway routes, and data source bindings, reducing a significant amount of manual coding and configuration work. Finally, leveraging the low-code platform's built-in automated optimization and tuning capabilities (such as resource compression, lazy loading configuration, and performance baseline checks), the overall performance of the integrated application is improved. The output of this stage is a complete application directory that can be directly deployed and integrates code and low-code assets. This directory, as the final output of this module, will be transferred to the next stage, the "Integration, Testing, and Deployment Module," for system-level verification and release.

[0174] The AI ​​code generation phase is responsible for the original creation of the core logic; the intelligent agent workflow phase is responsible for the automated coordination and built-in quality of the production process; and the low-code integration phase is responsible for the productization and user experience optimization of the results. These three phases work together to ultimately output an integrated project directory, which contains all the runnable code, configurations, low-code components, and deployment instructions, providing a complete deliverable for final integration testing and deployment.

[0175] VI. Integration Test Deployment: The input for this step is the integration project directory. The automated build system (a pipeline comprised of a continuous integration toolchain, DevOps) is triggered first, responsible for executing a series of operations such as code compilation, dependency installation, and resource packaging, integrating the scattered build artifacts into a unified, deployable application artifact. Subsequently, the test engine (a system that automatically generates and executes test cases based on the original requirements specifications) starts, sequentially running interface integration tests to comprehensively verify the functional correctness and business process continuity of the integrated system. After successful verification, the system deploys the application artifact to the target runtime environment. This step outputs a runnable application system, a detailed test report, and deployment results. Issues found in the test report can be traced back to specific build tasks or requirement elements, providing a clear basis for targeted optimization of the entire process.

[0176] Please see Figure 7 This application also provides a code generation apparatus 200, comprising: Document acquisition module 210 is used to acquire requirement documents; The document processing module 220 is used to perform semantic analysis on the requirement document using a large language model to obtain multiple functional modules and the dependencies between them, and to generate a dependency graph based on the multiple functional modules and the dependencies between them. The task generation module 230 is used to generate a task queue including multiple development tasks based on the dependency graph, wherein the task queue carries the execution order corresponding to each of the multiple development tasks. The code generation module 240 is used to determine the type of the development task and generate code or components corresponding to the development task based on the type of the development task; The code assembly module 250 assembles the code or components corresponding to the multiple development tasks based on the execution order of each of the multiple development tasks, to obtain the program code corresponding to the requirements document.

[0177] In one possible implementation, the task generation module 230 includes: The domain partitioning submodule is used to divide the multiple functional modules included in the dependency graph according to the business domain, so as to obtain functional modules under multiple business domains; The task generation submodule is used to generate multiple development tasks based on the functional modules under each of the business domains. The dependency determination submodule is used to determine the dependencies between development tasks based on the dependencies between functional modules in the dependency graph. The execution order determination submodule is used to determine the execution order of each development task based on the dependencies between them, so as to obtain a task queue.

[0178] In one possible implementation, the domain partitioning submodule includes: The domain partitioning scheme generation unit is used to generate multiple candidate business domain partitioning schemes, wherein each candidate business domain partitioning scheme defines a grouping method for dividing the multiple functional modules into multiple business domains; The evaluation value generation unit is used to obtain a coupling degree evaluation value based on the number and type of cross-business domain dependency edges in the dependency graph for each candidate business domain partitioning scheme; and to obtain a business integrity evaluation value based on the semantic similarity between functional modules in each business domain. The domain partitioning scheme selection unit is used to determine the target business domain partitioning scheme from the multiple candidate business domain partitioning schemes based on the business integrity evaluation value and coupling degree evaluation value corresponding to each candidate business domain partitioning scheme.

[0179] In one possible implementation, the domain partitioning scheme selection unit is further configured to obtain a comprehensive evaluation value based on the business integrity evaluation value and coupling degree evaluation value corresponding to each candidate business domain partitioning scheme; and determine the candidate business domain partitioning scheme with the highest comprehensive evaluation value as the target business domain partitioning scheme.

[0180] In one possible implementation, the task generation submodule includes: The function point extraction unit is used to extract multiple function points from the requirement document that correspond to the function modules under the business domain. The module partitioning scheme generation unit is used to generate multiple candidate sub-functional module partitioning schemes based on the multiple functional points, wherein each candidate sub-functional module partitioning scheme defines a grouping method for dividing the multiple functional points into multiple sub-functional modules. The parameter determination unit is used to determine the cohesion of each sub-functional module based on the semantic similarity and dependency strength between functional points in each sub-functional module for each candidate sub-functional module partitioning scheme; and to determine the coupling degree of each sub-functional module based on the number of shared entities and dependencies between each sub-functional module and other sub-functional modules. The module partitioning scheme selection unit is used to determine the target sub-functional module partitioning scheme from the multiple candidate sub-functional module partitioning schemes based on the cohesion and coupling of each sub-functional module. The task generation unit is used to generate development tasks corresponding to each sub-functional module under the target sub-functional module division scheme.

[0181] In one possible implementation, the task generation unit is further configured to generate multiple candidate task partitioning schemes under the target sub-functional module partitioning scheme, wherein the candidate task partitioning schemes define a partitioning method for dividing each sub-functional module in the multiple business domains into multiple development tasks; for each candidate task partitioning scheme, a task complexity score and a feasibility score for each development task are obtained based on the feature information of each development task in each sub-functional module; a parallel execution score for the candidate task partitioning scheme is obtained based on the dependency relationship of multiple development tasks in the candidate task partitioning scheme; and a target task partitioning scheme is determined from the multiple candidate task partitioning schemes based on the parallel execution score of each candidate task partitioning scheme and the task complexity score and feasibility score of each development task therein.

[0182] In one possible implementation, the code assembly module 250 is further configured to obtain the calling order of each of the multiple development tasks according to the task priority library and the execution order of each of the multiple development tasks; and to assemble the code or components corresponding to the multiple development tasks based on the calling order of each of the multiple development tasks to obtain the program code corresponding to the requirements document.

[0183] In one possible implementation, the code generation module 240 is further configured to parse the task description and technical requirements of the development task, determine its task type based on a preset type matching rule, wherein the task type includes at least one of: front-end interface task, back-end logic task, data model task, or interface task; if the task type is a back-end logic task, data model task, or interface task, a generative language model is invoked to generate corresponding program code based on the detailed description, input / output specifications, and context information of the development task; if the task type is a front-end interface task, the open application programming interface of the low-code platform is invoked to convert the description of the front-end interface task into a component of the low-code platform.

[0184] Regarding the code generation apparatus in the above embodiments, the specific methods by which each module performs its operations have been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0185] Based on the same inventive concept, this disclosure provides an electronic device, including: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the above-described method of living.

[0186] Figure 8 This is a block diagram illustrating an electronic device 100 according to an exemplary embodiment. Figure 8As shown, the electronic device 100 may include a processor 101 and a memory 102. The electronic device 100 may also include one or more of a multimedia component 103, an input / output (I / O) interface 104, and a communication component 105. Specifically, the electronic device may be a server or terminal, or other device with data processing capabilities, and may be able to run code generation methods.

[0187] The processor 101 controls the overall operation of the electronic device 100 to complete all or part of the steps in the above-described solution method. The memory 102 stores various types of data to support the operation of the electronic device 100. This data may include, for example, instructions for any application or method operating on the electronic device 100, and application-related data. The memory 102 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 103 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used for outputting and / or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory 102 or transmitted via communication component 105. The audio component also includes at least one speaker for outputting audio signals. I / O interface 104 provides an interface between processor 101 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. Communication component 105 is used for wired or wireless communication between the electronic device 100 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IoT, eMTC, or other 5G, or a combination thereof, is not limited here. Therefore, the corresponding communication component 105 may include: a Wi-Fi module, a Bluetooth module, an NFC module, etc.

[0188] In an exemplary embodiment, the electronic device 100 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the code generation method described above.

[0189] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the code generation method described above. For example, the computer-readable storage medium may be the memory 102 including the program instructions described above, which may be executed by the processor 101 of the electronic device 100 to complete the code generation method described above.

[0190] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the code generation method described above when executed by the programmable device.

[0191] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0192] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0193] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A code generation method, characterized in that, The method includes: Obtain the requirements document; The requirement document is semantically analyzed using a large language model to obtain multiple functional modules and their dependencies, and a dependency graph is generated based on these dependencies. Based on the dependency graph, a task queue including multiple development tasks is generated, and the task queue carries the execution order corresponding to each of the multiple development tasks; Determine the type of the development task, and generate the corresponding code or component based on the type of the development task; Based on the execution order of the multiple development tasks, the code or components corresponding to the multiple development tasks are assembled to obtain the program code corresponding to the requirements document.

2. The method of claim 1, wherein, The process of generating a task queue comprising multiple development tasks based on the dependency graph includes: The multiple functional modules included in the dependency graph are divided according to business domains to obtain functional modules under multiple business domains; Based on the functional modules under each of the aforementioned business domains, multiple development tasks are generated; Based on the dependency relationships between functional modules in the dependency graph, the dependency relationships between each development task are determined; Based on the dependencies between the development tasks, the execution order of each development task is determined to obtain a task queue.

3. The method of claim 2, wherein, The step of dividing the multiple functional modules included in the dependency graph according to business domains to obtain functional modules under multiple business domains includes: Multiple candidate business domain partitioning schemes are generated, wherein each candidate business domain partitioning scheme defines a grouping method for dividing the multiple functional modules into multiple business domains; For each of the candidate business domain partitioning schemes, a coupling degree evaluation value is obtained based on the number and type of cross-business domain dependency edges in the dependency graph; a business integrity evaluation value is obtained based on the semantic similarity between functional modules in each business domain. Based on the business integrity assessment value and coupling degree assessment value corresponding to each of the candidate business domain partitioning schemes, the target business domain partitioning scheme is determined from the plurality of candidate business domain partitioning schemes.

4. The method of claim 3, wherein, The step of determining the target business domain partitioning scheme from the multiple candidate business domain partitioning schemes based on the business integrity assessment value and coupling degree assessment value corresponding to each candidate business domain partitioning scheme includes: A comprehensive evaluation value is obtained based on the business integrity evaluation value and coupling degree evaluation value corresponding to each of the candidate business domain partitioning schemes; The candidate business domain partitioning scheme with the highest comprehensive evaluation value is determined as the target business domain partitioning scheme.

5. The method of claim 2, wherein, The process of generating multiple development tasks based on the functional modules under each business domain includes: For each business domain, perform the following steps: Extract multiple functional points corresponding to the functional modules under the business domain from the requirements document; Based on the multiple functional points, multiple candidate sub-functional module partitioning schemes are generated, wherein each candidate sub-functional module partitioning scheme defines a grouping method for dividing the multiple functional points into multiple sub-functional modules; For each candidate sub-functional module partitioning scheme, the cohesion of the sub-functional module is obtained based on the semantic similarity and dependency strength between each functional point in the sub-functional module; the coupling degree of the sub-functional module is obtained based on the number of shared entities and dependency relationships between the sub-functional module and other sub-functional modules. The target sub-functional module partitioning scheme is determined from the plurality of candidate sub-functional module partitioning schemes based on the cohesion and coupling of each of the sub-functional modules. Generate the development tasks corresponding to each sub-functional module under the target sub-functional module division scheme.

6. The method of claim 5, wherein, The development tasks corresponding to each sub-functional module under the target sub-functional module division scheme include: Generate multiple candidate task partitioning schemes under the target sub-functional module partitioning scheme, wherein the candidate task partitioning schemes define the partitioning method of dividing each sub-functional module in the multiple business domains into multiple development tasks; For each of the candidate task partitioning schemes, the task complexity score and feasibility score of each development task are obtained based on the feature information of each development task in each of the sub-functional modules. The parallel execution score of the candidate task partitioning scheme is obtained based on the dependencies between multiple development tasks in the candidate task partitioning scheme. Based on the parallel execution score of each candidate task partitioning scheme and the task complexity score and feasibility score of each development task therein, the target task partitioning scheme is determined from the multiple candidate task partitioning schemes.

7. The method of claim 1, wherein, The assembly of code or components corresponding to the multiple development tasks based on their respective execution order to obtain program code corresponding to the requirements document includes: Based on the task priority library and the execution order of each of the multiple development tasks, the calling order of each of the multiple development tasks is obtained; Based on the calling order of the multiple development tasks, the code or components corresponding to the multiple development tasks are assembled to obtain the program code corresponding to the requirements document.

8. The method of claim 1, wherein, The step of determining the type of the development task and generating the corresponding code or component based on the type of the development task includes: The task description and technical requirements of the development task are analyzed, and its task type is determined based on the preset type matching rules. The task type includes at least one of the following: front-end interface task, back-end logic task, data model task, or interface task. If the task type is a backend logic task, data model task, or interface task, a generative language model is invoked to generate corresponding program code based on the detailed description of the development task, input and output specifications, and context information. If the task type is a front-end interface task, call the open application programming interface of the low-code platform to convert the description of the front-end interface task into a component of the low-code platform.

9. A code generation apparatus characterized by comprising: The device includes: The document retrieval module is used to retrieve the requirements documents; The document processing module is used to perform semantic analysis on the requirement document using a large language model, obtain multiple functional modules and the dependencies between them, and generate a dependency graph based on the multiple functional modules and the dependencies between them. The task generation module is used to generate a task queue including multiple development tasks based on the dependency graph, wherein the task queue carries the execution order corresponding to each of the multiple development tasks; A code generation module is used to determine the type of the development task and generate code or components corresponding to the development task based on the type of the development task. The code assembly module assembles the code or components corresponding to the multiple development tasks based on their respective execution order to obtain the program code corresponding to the requirements document.

10. An electronic device, comprising: include: A memory on which computer programs are stored; A processor for executing the computer program in the memory to implement the method of any one of claims 1-8.

11. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-8.

12. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-8.

Images