A requirement code generation method, device, equipment, medium and program product

Abstract

This invention discloses a method, apparatus, device, medium, and program product for generating requirement code, applied in the field of software development technology. It includes: determining the stage to be executed based on the stage state of the target software requirement, and obtaining the stage input data corresponding to the stage to be executed; processing the stage input data to obtain the output data corresponding to the stage to be executed; updating the stage state based on the output data when the output data meets the currently set stage switching conditions; determining the next stage to be executed based on the updated stage state, until all development stages are completed, obtaining the target requirement code corresponding to the target software requirement. This invention divides the code into multiple stages to be executed, updating the stage state and executing the next stage only when the output data meets the currently set stage switching conditions. This makes the execution of the subsequent stage dependent on the output result of the previous stage meeting the conditions, ensuring that the output of all stages meets the requirements, thus improving the efficiency and quality of code generation.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method, apparatus, device, medium, and program product for generating requirement code. Background Technology

[0002] In the software development process, the process from software requirements being defined to code delivery typically relies on manual processing by developers. Developers need to search and organize information related to the target requirements from various channels and historical communication records, and then rely on their experience to understand the requirements, implement the code, and deliver the final result. This results in relatively low code development efficiency.

[0003] It is evident that improving the efficiency of software development is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a method, apparatus, device, medium and program product for generating requirement code, which solves the technical problem of low code development efficiency in the prior art.

[0005] To address the aforementioned technical problems, this invention provides a method for generating requirement codes, comprising: The stage to be executed is determined by the stage status of the target software requirement, and the stage input data corresponding to the stage to be executed is obtained; the stage to be executed is the current development stage among multiple development stages corresponding to the target software requirement. According to the data processing method corresponding to the stage to be executed, the input data of the stage is processed to obtain the output data corresponding to the stage to be executed; When the output data meets the currently set stage switching conditions, the stage state is updated based on the output data; Based on the updated stage status, determine the next stage to be executed, and based on the output data, determine the stage input data corresponding to the next stage to be executed. Then, return to execute the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, and obtain the target requirement code corresponding to the target software requirement.

[0006] Optionally, the stage to be executed is determined based on the stage status of the target software requirements, and the stage input data corresponding to the stage to be executed is obtained, including: The stage state of the target software requirement is obtained based on the stage state persistence file; Based on the stage status, the stage to be executed is determined to be any one of the following: information collection stage, requirement definition stage, functional specification stage, implementation planning stage, task decomposition stage, and development execution stage. The information collection stage is the stage of determining the data required for code generation; the requirement definition stage is the stage of determining the required functions; the function specification stage is the stage of determining the function specifications; the implementation planning stage is the stage of determining the implementation files; the task decomposition stage is the stage of determining the task list; and the development execution stage is the stage of generating code based on the task list file.

[0007] Optionally, the input data of the stage to be executed is processed according to the data processing method corresponding to the stage to be executed, to obtain the output data corresponding to the stage to be executed, including: During the information collection phase, the main intelligent agent calls the sub-intelligent agent to collect the data required for code generation corresponding to the target software requirements; In the requirements definition phase, the data required for code generation is used as the input data for the phase. Multiple user stories are extracted using the main intelligent agent, along with the functions and priorities corresponding to each user story, and the functional points corresponding to the functions to construct a requirements definition file; wherein, the user story is a functional unit described from the user's perspective. In the functional specification phase, the requirement definition file is used as the input data for the phase, and the main intelligent agent is used to generate a functional specification file including acceptance scenarios, functional requirements and acceptance criteria. In the implementation planning phase, the functional specification document is used as the input data for the phase to generate an implementation planning document; wherein, the implementation planning document is a structured document that determines the implementation method of the target software requirements at the code level; In the task decomposition phase, the implementation planning file is used as the input data for the phase to generate multiple executable tasks, and a task list file is generated based on the multiple executable tasks. During the development and execution phase, the task list file is used as the input data for the phase to generate the target requirement code corresponding to the target software requirements.

[0008] Optionally, in the implementation planning phase, the functional specification document is used as input data to generate an implementation planning document, including: The main intelligent agent generates an implementation planning document, including data model fields, interfaces, and architecture design, based on the functional specification document and code knowledge base. The list of modified files in the architecture design has been marked with the corresponding user stories.

[0009] Optionally, in the task decomposition stage, the implementation planning file is used as the input data for this stage to generate multiple executable tasks, and a task list file is generated based on the multiple executable tasks, including: The main intelligent agent is used to break down the file modifications in the implementation plan file into executable tasks. The main intelligent agent is used to label the corresponding task stages, dependencies, and complexity of the executable tasks to obtain the task list file.

[0010] Optionally, when the output data meets the currently set stage switching conditions, the stage state is updated based on the output data, including: Based on the output data, semantic analysis is performed using a large language model to determine whether the output data meets the output requirements of the current execution stage. When the output requirements corresponding to the stage to be executed are met, it is determined that the current stage switching conditions are met, and the stage status is updated based on the output data.

[0011] Optionally, semantic analysis is performed using a large language model based on the output data to determine whether the output data meets the output requirements of the current execution stage, including: Based on the output data, semantic analysis is performed using the large language model to determine the field integrity results and semantic quality results. Based on the field integrity results and the semantic quality results, the large language model is used to determine whether the output data meets the output requirements of the current execution stage.

[0012] Optionally, in the information collection phase, the main agent invokes sub-agents to collect the data required for code generation corresponding to the target software requirements, including: The main agent invokes tools and sub-agents; Based on the aforementioned tools and the aforementioned sub-agent, the data required for code generation is obtained from the project management platform, design draft tools, code repository, and historical iteration records; The data required for code generation includes at least a requirement description and historical code.

[0013] This invention also provides a requirement code generation apparatus, comprising: The stage input data determination module is used to determine the stage to be executed based on the stage status of the target software requirement, and to obtain the stage input data corresponding to the stage to be executed; the stage to be executed is the current development stage to be executed among multiple development stages corresponding to the target software requirement; The output data determination module is used to process the input data of the stage according to the data processing method corresponding to the stage to be executed, so as to obtain the output data corresponding to the stage to be executed. The stage status update module is used to update the stage status based on the output data when the output data meets the currently set stage switching conditions; The target requirement code determination module is used to determine the next stage to be executed based on the updated stage status, and to determine the stage input data corresponding to the next stage to be executed based on the output data, and to return to the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, and to obtain the target requirement code corresponding to the target software requirement.

[0014] The present invention also provides a requirement code generation device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the above-described requirement code generation method.

[0015] The present invention also provides a medium on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described requirement code generation method.

[0016] The present invention also provides a computer program product, including a computer program / instructions, wherein the computer program / instructions, when executed by a processor, implement the steps of the above-described requirement code generation method.

[0017] As can be seen, this invention determines the stage to be executed by the stage status of the target software requirement and obtains the stage input data corresponding to the stage to be executed. The stage to be executed is the current development stage among multiple development stages corresponding to the target software requirement. The stage input data is processed according to the data processing method corresponding to the stage to be executed to obtain the output data corresponding to the stage to be executed. When the output data meets the currently set stage switching conditions, the stage status is updated based on the output data. The next stage to be executed is determined based on the updated stage status, and the stage input data corresponding to the next stage to be executed is determined based on the output data. The process returns to the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all development stages are completed, and the target requirement code corresponding to the target software requirement is obtained.

[0018] The beneficial effects of this invention are as follows: Compared with the current method of manually writing code, this invention determines the stage to be executed based on the stage status, so that the code generation process no longer depends on a single continuous dialogue or manual memorization of the current progress. Instead, it can clearly identify the processing stage that should be executed at the current time based on the stage status. By dividing the requirement to code generation process into multiple stages to be executed, the stage status is updated and the next stage to be executed is executed only when the output data meets the current set stage switching conditions. This makes the execution of the next stage depend on the output results of the previous stage that meet the conditions, avoiding directly entering the subsequent code generation process when the output of the previous stage is incomplete or does not meet the requirements. Therefore, it can improve the efficiency and quality of code generation.

[0019] In addition, the present invention also provides a demand code generation apparatus, device, medium and program product, which also have the above-mentioned beneficial effects. Attached Figure Description

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

[0021] Figure 1 A flowchart illustrating a requirement code generation method provided in an embodiment of the present invention; Figure 2 A system architecture diagram for requirement code generation provided in an embodiment of the present invention; Figure 3 A flowchart illustrating a requirement code generation method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a requirement code generation device provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a requirement code generation device provided in an embodiment of the present invention. Detailed Implementation

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

[0023] Some terms that appear in the description of the embodiments of this application are subject to the following interpretation: LLM: Large Language Model, refers to a large-scale pre-trained model with the ability to understand and generate natural language.

[0024] Agent: An autonomous execution unit based on LLM, capable of calling tools, reading and writing files, and invoking external services.

[0025] Phase Gate: A quality checkpoint before phase switching, ensuring that the previous output meets the conditions before allowing the process to proceed.

[0026] User Story: A user story is a deliverable functional unit described from the user's perspective.

[0027] meta.yaml: A persistent file that records the current stage and context of the requirements.

[0028] TAPD: Project Management Platform, used to store requirements, defects, and tasks.

[0029] MCP: Model Context Protocol, a standardized protocol for LLM to call external tools.

[0030] FR: Functional Requirement, a specific description of a testable function.

[0031] SC: Success Criteria, quantifiable acceptance criteria.

[0032] Please refer to Figure 1 , Figure 1 A flowchart illustrating a requirement code generation method provided in an embodiment of the present invention. The method may include: S101, determine the stage to be executed by the stage status of the target software requirement, and obtain the stage input data corresponding to the stage to be executed; the stage to be executed is the current development stage to be executed among the multiple development stages corresponding to the target software requirement.

[0033] Each step in this embodiment can be executed by a designated electronic device, which can be a server, a portable terminal, or other form. This electronic device contains memory modules, the specific number of which is not limited. The stage state in this embodiment is data representing the current execution progress of the code generation process corresponding to the target software requirement. The stage state can include at least one of the following: currently pending stage, completed stage, output data path, data path required for code generation, stage check results, sub-agent execution status, and exception records. This embodiment does not limit the specific storage method of the stage state. For example, the stage state can be stored in a stage state persistence file; or the stage state can be stored in a local database, a remote database, or a cache database. The stage state persistence file in this embodiment is a file capable of saving the stage state between different sessions. The stage state persistence file can be a YAML (Data Serialization Format) file, such as meta.yaml (stage state metadata file); or the stage state persistence file can be a JSON (Lightweight Data Interchange Format) file, an XML (Extensible Markup Language) file, or a local SQLite (Lightweight Relational Database) database file. This embodiment saves the current stage to be executed and the output data path through a stage state persistence file. This allows the system to read the last interrupted position when the requirement code generation process is restarted, preventing the need to re-execute completed stages due to session closure or context loss. The stage input data in this embodiment is the data required for each stage to obtain its output data. For example, the stage input data for the information gathering stage is the historical iteration record; the stage input data for the requirement definition stage is the output of the information gathering stage.

[0034] It should be further explained that, based on any of the above embodiments, determining the stage to be executed by the stage status of the target software requirements and obtaining the corresponding stage input data can include: determining the current stage to be executed as any one of the following based on the stage status determination file: information collection stage, requirement definition stage, functional specification stage, implementation planning stage, task decomposition stage, and development execution stage; wherein, the information collection stage is the stage for determining the data required for code generation, the requirement definition stage is the stage for determining the required functions, the functional specification stage is the stage for determining the functional specifications, the implementation planning stage is the stage for determining the implementation files, the task decomposition stage is the stage for determining the task list, and the development execution stage is the stage for generating code based on the task list file. The stage status persistence file in this embodiment can record the current stage and context information. This embodiment does not limit the specific fields in the stage status persistence file. For example, the stage state persistence file can record the requirement identifier, the current stage to be executed, the completed stage, the data path required for code generation, the path of the requirement definition file, the path of the functional specification file, the path of the implementation planning file, the path of the task list file, and the stage check status; or the stage state persistence file can further record the execution status of the sub-agent, the degradation processing record, and the last update time. The stages in this embodiment can include the information collection stage, the requirement definition stage, the functional specification stage, the implementation planning stage, the task decomposition stage, and the development execution stage. This embodiment provides a specific process for determining the stage state based on the stage state persistence file, which improves the accuracy of stage state determination. This embodiment persists the stage state through meta.yaml (persistent state file), and any session can be accurately restored to the breakpoint.

[0035] S102, process the input data of the stage according to the data processing method corresponding to the stage to be executed, and obtain the output data corresponding to the stage to be executed; The data processing method in this embodiment refers to the method of processing stage inputs and outputs to generate output data.

[0036] It should be further noted that, based on any of the above embodiments, processing the input data of the stage according to the data processing method corresponding to the stage to be executed, to obtain the output data corresponding to the stage to be executed, may include: S1021, In the information collection phase, the main intelligent agent calls the sub-intelligent agent to collect the data required for code generation corresponding to the target software requirements; The data required for code generation in this embodiment is a dataset used to generate the target requirement code. This data may include at least one of the following: requirement description, requirement comments, design draft data, interface screenshots, historical code, and historical iteration records. This embodiment does not limit the carrier of the data required for code generation. For example, the data may be recorded in a context file; or it may be distributed across multiple structured files, with the storage paths of these structured files recorded by the stage status. It should be noted that the context file and the stage status persistence file corresponding to the data required for code generation serve different purposes. The context file records substantive data such as requirement content, design content, historical code analysis results, and stage outputs; the stage status persistence file records which stage is currently being executed, which files need to be read in subsequent stages, which stages have been completed, and abnormal states. This embodiment can store content data and stage status separately, enabling the large language model to read the complete context and generate output data, while allowing the requirement code generation system to recover the process based on the stage status. The large language model in this embodiment is a pre-trained model with natural language understanding and generation capabilities. This embodiment does not limit the specific type of the large language model. For example, a large language model can be a general-purpose language model deployed in the cloud; or it can be a code generation model deployed locally or within an enterprise. This embodiment can utilize the large language model to generate output data based on the input content corresponding to the current execution stage, thereby reducing the workload of manually understanding requirements, writing specifications, and breaking down tasks.

[0037] In this embodiment, the main agent is used to read the stage status, determine the current stage to be executed, invoke tools or sub-agents, and promote stage switching. The sub-agents in this embodiment are used to perform specific information collection, code analysis, or code writing tasks. This embodiment does not limit the collaboration mode between the main agent and sub-agents. For example, the main agent can dynamically delegate specific tasks to sub-agents. Data required for code generation can be obtained from the project management platform, design tools, code repositories, and historical iteration records (which can serve as stage input data). The project management platform can be used to store requirements, defects, and tasks; the design tools can be used to provide interface nodes and screenshots; the code repository can be used to provide historical code and code call relationships; and historical iteration records can be used to provide implementation methods for similar requirements. This embodiment does not limit the method of obtaining multi-source information. For example, external services can be called through the model context protocol tool; or multi-source information can be obtained through interface calls, event pushes, or local file imports. In this embodiment, when the data required for code generation includes design link links, the user interface extraction sub-agent can be used to extract interface node data and screenshots from the design. When the target software requirement is iterative, a codebase analysis sub-agent can be used to analyze historical code paths, identify historical code files, associated modules, and code call relationships. When a sub-agent fails, the reason for failure and the degradation result can be recorded, and the collected data can be retained to continue execution of subsequent stages. This embodiment prevents the failure of a single sub-agent from disrupting the entire process by recording degradation results.

[0038] S1022, In the requirements definition phase, the data required for code generation is used as the input data for the phase. Multiple user stories are extracted using the main intelligent agent, along with the functions and priorities corresponding to each user story, and the functional points corresponding to the functions to construct a requirements definition file; wherein, the user story is a functional unit described from the user's perspective. In this embodiment, the requirements definition phase is the phase for determining the required functions. User stories in this embodiment are independently deliverable functional units described from the user's perspective. This embodiment does not limit the method of extracting user stories. For example, a large language model can be used to extract user stories from requirement descriptions, comments, and design drafts; or a preset prompt template can be used to guide the large language model to extract user stories based on requirement titles, requirement descriptions, and historical iteration records. In this embodiment, the requirements definition file can record the mapping relationship between user stories, functions, priorities, and functional points. This embodiment does not limit the format of the requirements definition file. For example, the requirements definition file can be a YAML format feature.yaml (requirements definition file); or the requirements definition file can be in JSON (Object Notation) format or a database table record. By labeling user stories with functions and priorities, the acceptance content and implementation scope of each function can be determined in the subsequent functional specification phase, thereby reducing rework caused by unclear requirement scope. It should be noted that confirmation with developers is possible during the requirements definition phase. This embodiment does not limit the confirmation method. For example, a user story priority list can be output for developer confirmation; or module division and functional point classification results can be output for developer confirmation. This implementation confirms user stories, features, and priorities, ensuring the requirements definition file better aligns with the actual development scope of the target software requirements, thus preventing subsequent functional specifications from deviating from the requirements. Specifically, during the requirements definition phase, the controlling agent extracts User Stories from tapd-context.md and conducts two rounds of interactive confirmation with the developers: the first round confirms the priority order of User Stories, and the second round confirms the module division and feature classification of each Story. After confirmation, feature.yaml is generated, establishing a three-tiered structured mapping of User Stories, modules, and features.

[0039] S1023, In the functional specification phase, the requirement definition file is used as the input data for the phase, and the main intelligent agent is used to generate a functional specification file including acceptance scenarios, functional requirements and acceptance criteria. In this embodiment, the functional specification phase is the phase of defining functional specifications. Functional requirements in this embodiment are testable, specific functional descriptions; acceptance criteria are acceptance indicators used to verify whether functional requirements are implemented; and acceptance scenarios (Given-When-Then) can be used to describe scenarios where a certain behavior is triggered under given conditions and the expected result is obtained. In this embodiment, the main agent can read the requirement definition file and project specification file, match relevant modules in the knowledge base, and generate a functional specification file including acceptance scenarios, functional requirements, and acceptance criteria. This embodiment does not limit the source of the knowledge base. For example, the knowledge base can be existing specification documents and historical design documents within the project; or the knowledge base can be module descriptions, interface descriptions, and component descriptions extracted from the code repository. This embodiment uses the association index between functional requirements and user stories, and between acceptance criteria and functional requirements, to enable tracing back from user stories to functional requirements and acceptance criteria when requirements change, thereby reducing the cost of locating the scope of change impact. Specifically, in the functional specification phase (spec-design), the master agent reads feature.yaml and the project specification file, automatically matches relevant modules in the knowledge base, and generates spec-design.md (functional specification design file) containing acceptance scenarios (Given-When-Then), functional requirements (FRs), and acceptance criteria (SCs). Each FR is explicitly associated with the US, and each SC is explicitly associated with the FR, forming the first layer of the requirement traceability chain.

[0040] S1024, During the implementation planning phase, the functional specification document is used as input data to generate the implementation planning document; the implementation planning document is a structured document that determines the implementation method of the target software requirements at the code level; In this embodiment, the implementation planning phase is the phase of determining the implementation file. The implementation planning file in this embodiment may include data model fields, interfaces, architecture design, and a list of modified files. This embodiment does not limit the format of the implementation planning file. For example, the implementation planning file can be a Markdown-formatted impl-plan.md; or it can be in YAML format, JSON format, or a database record. In this embodiment, during the implementation planning phase, the main agent can generate an implementation planning file including data model fields, interfaces, and architecture design based on the functional specification file and the code knowledge base. The list of modified files in the architecture design is annotated with corresponding user stories. This embodiment does not limit the construction method of the code knowledge base. For example, the code knowledge base can be generated by scanning the root directory of the source code in the code repository; or it can be generated by parsing historical code paths, interface documents, component directories, and dependencies. This embodiment establishes a correlation between target software requirements and code file changes by annotating the corresponding user stories in the list of modified files, thereby enabling the location of affected code files when requirements change.

[0041] S1025, In the task decomposition stage, the implementation planning document is used as the stage input data to generate multiple executable tasks, and a task list file is generated based on the multiple executable tasks; In this embodiment, the task decomposition phase is the phase of determining the task list. The executable tasks in this embodiment are code generation tasks that can be independently executed by the development execution phase. This embodiment does not limit the granularity of executable tasks. For example, executable tasks can be split according to file modifications; or executable tasks can be split according to categories such as data models, interfaces, front-end pages, test cases, and configuration files. This embodiment can utilize a master agent to split file modifications in the implementation plan into executable tasks, and use the master agent to label the corresponding task stages, dependencies, and complexity of the executable tasks to obtain a task list file. This embodiment does not limit the way complexity is represented. For example, complexity can be high, medium, and low; or complexity can be a value obtained based on the number of modified files, the number of interfaces, and the number of dependent tasks. This embodiment, by labeling dependencies for executable tasks, enables the development execution phase to generate code according to the dependency order, preventing incomplete code generation results caused by premature execution of subsequent tasks before dependent tasks are completed.

[0042] S1026, During the development and execution phase, the task list file is used as phase input data to generate target requirement code corresponding to the target software requirements.

[0043] In this embodiment, the development execution phase is the code generation phase based on the task list file. This embodiment does not limit the code generation method. For example, a code execution sub-agent can be used to generate or modify code files item by item according to the task list; or a single agent can be used to execute each task in the task list sequentially. During the development execution phase, tasks to be executed can be read from the task list file in the order of task phases, taking task descriptions, associated functional requirements, associated acceptance criteria, target file paths, and dependent task results as input, and outputting code file changes. After code generation is complete, quality verification can be performed based on the code execution results. This embodiment does not limit the quality verification method. For example, static analysis, unit testing, compilation checks, or code style checks can be used to verify the code execution results; or a large language model can be used to perform semantic checks on the code execution results based on associated functional requirements and acceptance criteria. This embodiment marks tasks as completed only after quality verification, allowing tasks in the task list to proceed sequentially, thereby reducing the risk that the generated code will not meet requirements. Specifically, during the development execution phase, the master agent retrieves tasks from the todo-list.md (task list file) in phase order and dynamically delegates them to the impl-execute (code writing task) sub-agent to execute the code writing. After the sub-agent completes its work, it returns the result to the master agent for quality verification. If the verification is successful, the task is marked as completed and the next task is initiated, forming a loop until all tasks are completed.

[0044] It should be further explained that, based on any of the above embodiments, in the implementation planning phase, generating the implementation planning document by using the functional specification document as phase input data can include: using the main agent to generate an implementation planning document including data model fields, interfaces, and architecture design based on the functional specification document and the code knowledge base; wherein, the list of modified files in the architecture design has been marked with the corresponding user stories. Specifically, in the implementation planning phase (impl-plan), the main agent locates existing code based on spec-design.md (functional specification document) and combines it with source_root (source code root directory) in the code knowledge base, performs specification compliance checks, and generates impl-plan.md (implementation planning document), which includes data model field definitions, interface contracts, and architecture design (list of added / modified files). Each file change is marked with its corresponding US (user story), establishing the second layer of the requirement traceability chain. This embodiment provides a specific process for determining the implementation planning document, improving the accuracy of the implementation planning document.

[0045] It should be further explained that, based on any of the above embodiments, in the task decomposition stage, the implementation planning document is used as the stage input data to generate multiple executable tasks, and a task list file is generated based on these multiple executable tasks. This can include: using a master agent to decompose the file modifications in the implementation planning document into executable tasks; using the master agent to label the corresponding task stages, dependencies, and complexities of the executable tasks to obtain the task list file. Specifically, in this embodiment, the master agent can be used to decompose the file modifications in impl-plan.md into independently executable atomic tasks, generating todo-list.md (task list file), with each task labeled with its Phase, dependencies, and estimated complexity. This embodiment provides a specific process for determining the task list file, improving the accuracy of task list file determination.

[0046] It should be further explained that, based on any of the above embodiments, during the information collection phase, the collection of data required for code generation corresponding to the target software requirements by the main agent calling the sub-agent may include: using the main agent to call tools and sub-agents; and obtaining the data required for code generation from the project management platform, design tool, code repository, and historical iteration records based on the tools and sub-agents. The data required for code generation includes at least the requirement description and historical code. The tools in this embodiment can be model context protocol tools, REST interface calling tools, webhook receiving tools, local file reading tools, or command-line tools. The project management platform in this embodiment can be a platform for storing requirements, defects, and tasks; the design tool can be a platform for providing user interface design drafts; the code repository can be a version management system for storing project source code; and the historical iteration records can be historical requirements, historical commit records, or a historical task list. During the information collection process, requirement titles, requirement descriptions, requirement comments, and embedded images can be obtained from the project management platform; interface nodes, interface screenshots, and layout information can be obtained from the design tool; historical code paths, source code root directories, associated modules, and call relationships can be obtained from the code repository; and the processing methods for similar requirements can be obtained from the historical iteration records. This embodiment does not limit the specific source of the data required for code generation. For example, it can be obtained from the four types of data sources mentioned above; or it can be obtained from instant communication records, local requirement documents, or test case documents. Specifically, the main control agent uses the TAPD MCP tool to pull requirement details, comments, and embedded images, parses Figma (design draft tool) links, and delegates the figma-ui-extractor (user interface extraction sub-agent) sub-agent to extract UI (main interface) node data and screenshots. If it is an iterative requirement, it delegates the codebase-researcher (analyzing historical code paths) sub-agent to analyze historical code paths. All information is uniformly written to tapd-context.md (context file, i.e., data required for code generation) and meta.yaml, forming a unified information base for subsequent stages. When a sub-agent fails, it automatically degrades the record without interrupting the main process.

[0047] S103, when the output data meets the current set stage switching conditions, update the stage status based on the output data.

[0048] The output data in this embodiment is the data obtained after the current execution phase has been completed. The output data can be the data required for code generation obtained in the information collection phase, the requirement definition file obtained in the requirement definition phase, the function specification file obtained in the function specification phase, the implementation planning file obtained in the implementation planning phase, the task list file obtained in the task decomposition phase, or the target requirement code obtained in the development and execution phase. This embodiment does not limit the file format of the output data. The current stage switching condition in this embodiment is used to determine whether it is allowed to move from the current execution phase to the next execution phase. The current stage switching condition may include at least one of the following: whether the output data exists, whether the required fields are complete, whether the output data meets the semantic quality requirements of the current phase, whether the number of clarification markers is less than a preset number, and whether the output data contains the associated index required for the next phase. This embodiment does not limit the method of checking the stage switching condition. For example, a rule engine can be used for field integrity checks; or a large language model can be used for semantic quality analysis. When the output data meets the current stage switching condition, the path of the output data can be written into the stage status, the current execution phase can be marked as completed, and the next execution phase can be written into the stage status. This embodiment updates the stage status through output data, allowing subsequent stages to read the output data that passed the checks from the previous stage based on the stage status. This prevents incomplete output from the previous stage from directly entering the next stage, which could lead to errors in the subsequent code generation. When the output data does not meet the currently set stage switching conditions, the current stage to be executed in the stage status remains unchanged, and the failed checks are recorded. Failed checks may include at least one of the following: missing fields, insufficient semantic quality, unclarified requirements, missing related indexes, and code generation results failing verification. By recording failed checks, this embodiment allows for the regeneration or correction of output data for those failed checks upon subsequent re-triggers, thereby reducing unnecessary repetitive processing.

[0049] It should be further explained that, based on any of the above embodiments, the process of updating the stage status based on the output data when the output data meets the current stage switching conditions may include: performing semantic analysis on the output data using a large language model to determine whether the output data meets the output requirements of the current stage to be executed; when the output requirements corresponding to the stage to be executed are met, it is determined that the current stage switching conditions are met, and the stage status is updated based on the output data. This embodiment does not limit the method of semantic analysis. For example, a large language model can be used to determine whether the output data covers the stage requirements based on the output template of the current stage to be executed; or a large language model can be used to determine whether there are logical gaps in the output data based on project specifications, requirement descriptions, and related indexes. Through semantic analysis, the stage switching conditions not only check whether the fields exist, but also check whether the output content meets the semantic quality requirements of the current stage, thereby improving the reliability of the output data.

[0050] It should be further explained that, based on any of the above embodiments, the above-mentioned semantic analysis of output data using a large language model to determine whether the output data meets the output requirements of the current execution stage can include: performing semantic analysis of output data using a large language model to determine field completeness results and semantic quality results; and using a large language model to determine whether the output data meets the output requirements of the current execution stage based on the field completeness results and semantic quality results. In this embodiment, the field completeness results can be used to indicate whether the required fields in the output data are complete. This embodiment does not limit the required fields. For example, required fields in a requirements definition document may include user stories, functions, priorities, and functional points; required fields in a functional specification document may include acceptance scenarios, functional requirements, and acceptance criteria; required fields in an implementation planning document may include data model fields, interfaces, and architecture design; and required fields in a task list document may include task stages, dependencies, and complexity. In this embodiment, the semantic quality results can be used to indicate whether the output data meets the quality requirements of the current execution stage. This embodiment does not limit the way the semantic quality results are expressed. For example, the semantic quality results may include pass or fail; or the semantic quality results may include quality scores, the number of clarification markers, defects, and correction suggestions. This embodiment uses both field integrity and semantic quality results to determine whether the output data meets the output requirements, preventing the omission of logical errors based solely on field existence. Specifically, if the field integrity result indicates that all required fields are present, and the semantic quality result indicates that the output data meets the quality requirements of the current execution stage, then the output data is deemed to meet the requirements of that stage. Conversely, if the field integrity result indicates missing fields, or the semantic quality result indicates that the output data contains unclarified content, missing related indexes, or semantic conflicts, then the output data is deemed not to meet the requirements of the current execution stage. This embodiment, by comprehensively considering both field integrity and semantic quality, makes the stage switching process more stable, thereby improving the quality of the generated code for the target requirements.

[0051] S104: Determine the next stage to be executed based on the updated stage status, and determine the stage input data corresponding to the next stage to be executed based on the output data. Then return to execute the steps of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all development stages are completed, and obtain the target requirement code corresponding to the target software requirement.

[0052] In this embodiment, the target requirement code is the code corresponding to the target software requirement, which is the software requirement that needs to be converted into code for implementation. The target software requirement can be a new requirement, an iterative requirement, a defect fixing requirement, or a refactoring requirement. This embodiment does not limit the source of the target software requirement. For example, the target software requirement can come from a requirement sheet in a project management platform; or it can come from a locally imported requirement document. This embodiment determines the next stage to be executed based on the updated stage status and uses the output data of the current stage as the input data for the subsequent stages. In this way, the data required for code generation obtained in the information collection stage can be used in the requirement definition stage; the requirement definition file obtained in the requirement definition stage can be used in the functional specification stage; the functional specification file obtained in the functional specification stage can be used in the implementation planning stage; the implementation planning file obtained in the implementation planning stage can be used in the task decomposition stage; and the task list file obtained in the task decomposition stage can be used in the development execution stage. In this embodiment, the target requirement code is a code file that can be directly run to implement the target software requirement.

[0053] An embodiment of the present invention provides a requirement code generation method, which may include: S101, determining the stage to be executed based on the stage status of the target software requirement, and obtaining the stage input data corresponding to the stage to be executed; the stage to be executed is the current development stage to be executed among multiple development stages corresponding to the target software requirement; S102, processing the stage input data according to the data processing method corresponding to the stage to be executed, and obtaining the output data corresponding to the stage to be executed; S103, when the output data meets the currently set stage switching conditions, updating the stage status based on the output data; S104, determining the next stage to be executed based on the updated stage status, and determining the stage input data corresponding to the next stage to be executed based on the output data, and returning to execute the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all development stages are completed, and obtaining the target requirement code corresponding to the target software requirement. Compared to current methods that rely on manual coding, this invention determines the current execution stage based on the stage status. This eliminates the need for a single, continuous dialogue or manual memorization of the current progress in the code generation process. Instead, it clarifies the processing stage that should be executed based on the stage status. By dividing the requirement-to-code generation process into multiple execution stages, the stage status is updated and the next execution stage is executed only when the output data meets the currently set stage switching conditions. This ensures that the execution of the subsequent stage depends on the output results of the previous stage, avoiding direct entry into the subsequent code generation process when the output of the previous stage is incomplete or does not meet the requirements. Therefore, it can improve the efficiency and quality of code generation.

[0054] Currently, the industry offers the following main technical solutions in the field of AI-assisted software development: Option 1: Single-round AI code generation tool. Developers input natural language descriptions, and AI directly generates code snippets or functions. Each interaction is independent, with no cross-session state memory and no workflow orchestration.

[0055] Option 2: One-time conversational requirements analysis. Developers paste their requirements document into the LLM and receive technical solution suggestions in a single conversation. The state is lost after the conversation ends, making it impossible to continue development into subsequent phases.

[0056] This invention can be integrated into the developer's AI programming assistant as a command-line plugin. The developer can trigger the workflow of each stage through natural language commands and complete the entire process from requirements to code without switching tools. Typical use cases are as follows: (1) Start a new requirement: The developer enters / vibecx:create-requirement (create requirement command), and the system guides him to provide information such as TAPD (project management platform) requirement link, Figma (external service) design draft link, and historical reference code path, and automatically completes information aggregation without manual sorting. (2) Cross-session resume: The developer reopens the editor the next day and enters / vibecx:continue-requirement (continue to create requirement command), and the system automatically reads the stage that was interrupted last time, restores the complete context, and continues from the breakpoint without having to describe the requirement background again. (3) Stage progressive advancement: After each stage is completed, the system outputs structured outputs (such as feature.yaml, spec-design.md, impl-plan.md). After the developer confirms that there are no errors, he can issue a continue command to enter the next stage. The outputs are automatically linked. (4) Code delivery: During the task decomposition phase, a todo-list is generated. During the development and execution phase, sub-Agents are dispatched to write code according to each task. After completion, compliant commit information is automatically generated through / vibecx:fast-commit. The whole process forms a complete closed loop from requirements to commit.

[0057] For a clearer understanding of this invention, please refer to the following details. Figure 2 , Figure 2 A system architecture diagram for requirement code generation provided in this embodiment of the invention may specifically include: The system consists of four core components: a master agent, a pool of dedicated sub-agents, a stage state persistence layer, and a multi-source information adaptation layer. The master agent reads the meta.yaml file (persistent state file) to determine the current stage, executes the stage skill (the specific skills and tasks required for the current stage), performs access control checks upon completion, and switches to the next stage via phase transition if successful. The dedicated sub-agent pool includes dedicated sub-agents such as figma-ui-extractor (extracts Figma design nodes and screenshots), codebase-researcher (analyzes historical code paths), and impl-execute (executes code writing tasks), which are dynamically delegated by the master agent as needed. Stage State Persistence Layer: This layer includes structured files such as meta.yaml (state persistence file), feature.yaml (requirement definition file), spec-design.md (functional specification design file), impl-plan.md (implementation planning file), todo-list.md (task list file), and tapd-context.md (context file), recording all contexts and deliverables throughout the requirement's lifecycle. At the end of each stage, a gate check is performed to verify the existence of deliverable files, the completeness of required fields, and whether quality indicators meet standards (e.g., the number of NEEDS CLARIFICATION markers (the current content is ambiguous, missing, or unclear, requiring the author to supplement information before proceeding) should not exceed three). If the check fails, stage switching is blocked, and developers are guided to fix the issues before re-triggering the stage. Multi-Source Information Adaptation Layer: This layer connects to external services such as TAPD (requirement management), Figma API (UI design), and Git (code repository) via the MCP protocol.

[0058] For easier understanding, please refer to Figure 3 , Figure 3 The flowchart illustrating a requirement code generation method provided in this embodiment of the invention specifically includes: an information collection stage, a requirement definition stage, a functional specification stage, a task decomposition stage, and a development execution stage. Specifically, it may include the following steps: During the information collection phase, the system receives requirement creation instructions from developers and parses these instructions to obtain requirement source information. This requirement source information includes at least one of the following: a requirement link from the project management platform, a design draft link, or a path to historical reference code.

[0059] In this embodiment, the master agent uses sub-agents to create a persistent state file corresponding to the current requirement based on the requirement source information. The requirement source information is then processed as stage input data according to the corresponding data processing method to obtain the data required for code generation. The persistent state file records the data needed for the current requirement. The master agent performs stage access control checks on the persistent state file. These checks include verifying the existence of the context file, the completeness of required fields, and whether the number of clarification tags meets preset conditions. When the stage access control check of the persistent state file passes, the master agent updates the current stage in the persistent state file to the requirement definition stage. When the stage access control check of the information collection stage fails, the master agent blocks stage switching and outputs information that needs to be supplemented or repaired.

[0060] During the requirements definition phase, the master agent extracts user stories from the data needed for code generation and interacts with developers to confirm the information. This yields multiple user stories, their priorities, functional module divisions, and functional point classifications for each module. Based on the confirmed user stories, their priorities, and the corresponding functional modules and functional point classifications, the master agent generates a requirements definition file. This file records the three-tiered structured mapping between user stories, modules, and functional points. The master agent performs phase access checks on the deliverables of the requirements definition phase. When the requirements definition file exists and the mapping between user stories, modules, and functional points is complete, the master agent updates the current phase in the state persistence file to the functional specification phase.

[0061] During the functional specification phase, the master agent reads the requirements definition file and project specification file, matches relevant modules in the knowledge base based on the module information in the requirements definition file, and generates functional design specifications based on the matching results. These specifications include acceptance scenarios, functional requirements, and acceptance criteria. Acceptance scenarios use a Given-When-Then format, establishing explicit associations between functional requirements and user stories, and between acceptance criteria and functional requirements. The master agent performs phase access checks on the deliverables of the functional specification phase. When the functional requirements, acceptance criteria, and relationships in the functional specification design file meet preset quality conditions, the master agent updates the current phase in the state persistence file to the implementation planning phase.

[0062] During the implementation planning phase, the master agent reads the functional specification design document and locates existing code in the source code root directory of the code knowledge base. Based on the existing code, the master agent performs compliance checks and generates an implementation plan document. This implementation plan document includes data model field definitions, interface contracts, architecture design, and a list of file changes. Each file change in the file change list is labeled with its associated user story to establish a traceability relationship from requirements to file changes. The master agent performs phase access checks on the deliverables of the implementation planning phase. When the data model field definitions, interface contracts, architecture design, and file change list in the implementation plan document meet preset integrity conditions, the master agent updates the current phase in the state persistence file to the task decomposition phase.

[0063] During the task decomposition phase, the master agent reads the implementation planning file and breaks down the file modifications in the implementation planning file into independently executable atomic tasks. A task list file is generated based on these atomic tasks. Each atomic task in the task list file is labeled with its corresponding stage, dependencies, and estimated complexity. The dependencies are used to determine the execution order of atomic tasks in the development execution phase. The master agent performs phase access checks on the outputs of the task decomposition phase. When the task list file exists and each atomic task contains its corresponding stage, dependencies, and estimated complexity, the master agent updates the current stage in the state persistence file to the development execution phase.

[0064] During the development and execution phase, the master agent reads the tasks to be executed according to the phase order in the task manifest file and dispatches code writing tasks to the implementation execution agents. The implementation execution agents execute the code writing according to the tasks to be executed and return the code writing results to the master agent. The master agent performs quality verification on the code writing results returned by the implementation execution agents. When the quality verification passes, the master agent marks the corresponding task as completed and reads the next task to be executed from the task manifest file. When the quality verification fails, the master agent records the failure reason according to the quality verification result and re-dispatches the corresponding task or blocks the current task from progressing; the failure reason is written to the state persistence file for use in subsequent sessions to restore the current task state. The master agent cyclically executes task reading, task dispatching, result reception, and quality verification until all tasks in the task manifest file are marked as completed. When all tasks are completed, the master agent forms a full-link traceability relationship from requirements to code submission based on the correlation between user stories, functional requirements, acceptance criteria, implementation plans, file changes, and code submissions.

[0065] In this embodiment, when a developer interrupts the process at any stage and re-enters the command to continue creating the requirement, the master agent reads the persistent state file to determine the interrupted stage, completed deliverables, and incomplete tasks of the current requirement, and then continues the subsequent process from the interrupted stage. Once the development execution stage is complete, the master agent responds to the rapid code submission command, generates compliant submission information based on completed tasks and file changes, and associates the code submission with the corresponding user story, functional requirements, and acceptance criteria.

[0066] It should be noted that this solution uses a YAML file (meta.yaml) as the persistent storage medium for stage states. Alternatively, a local SQLite database, JSON file, or a remote database (such as Redis) can be used to store stage states and context information. Any method that enables cross-session state reading and recovery falls within the scope of this invention. This solution uses the MCP (Model Context Protocol) tool to call external services (TAPD, Figma, Git). It can also use direct REST API calls, Webhook event-driven pushes, or local file imports to aggregate multi-source information. The core innovation lies in the aggregation behavior itself, not the specific access protocol. This solution adopts a hierarchical collaborative model where the master agent dynamically delegates sub-agents. Other possible models include: a multi-agent peer-to-peer negotiation model (where agents communicate via message queues), a directed acyclic graph (DAG) scheduler to uniformly orchestrate all agents, or a single-agent sequential execution model (no delegation, with the master agent assuming responsibilities for each stage sequentially). This solution employs rule checks based on file existence and field integrity. Alternatively, decisions can be made on whether to proceed based on the semantic quality score of the output by an LLM, or by replacing automatic access control with a manual review process, or by using the unit test pass rate as the access control indicator.

[0067] The beneficial effects of this invention are as follows: 1. Significantly reduces the cost of understanding requirements: Automatic aggregation of multi-source information eliminates the repetitive work of developers manually moving information between tools such as TAPD, Figma, and Git, reducing information collection time from hours to minutes.

[0068] 2. Eliminate the problem of context breakage in long LLM processes: By persisting the stage state in meta.yaml, developers can accurately recover after interruption at any point in time, which solves the core pain point of existing LLM dialogues being prone to context loss and requiring repeated re-description of the background in long-cycle development tasks.

[0069] 3. Improve the reliability of AI-generated outputs: The stage access control mechanism ensures that the output of each stage can only proceed after it meets the quality conditions, avoiding the AI ​​from forcibly generating low-quality outputs when the preceding information is incomplete, thereby reducing rework in subsequent stages.

[0070] 4. Establish a complete traceability chain from requirements to code: US→FR→SC→impl-plan→file change→commit, which is a full-link association that enables the accurate location of the affected code scope when requirements change, reducing the risk of changes introducing bugs.

[0071] 5. Improve the controllability of multi-agent systems: The main control agent and dedicated sub-agents have separate responsibilities. Each sub-agent has a focused context and clear input and output. Compared with a single agent undertaking all tasks, the execution results are more stable and the degradation strategy in case of failure is clearer.

[0072] 6. Accelerate knowledge accumulation and reuse: The structured documents such as spec-design.md and impl-plan.md generated by the workflow naturally become part of the project knowledge base. New members can quickly understand the design decisions and implementation basis of historical requirements through these documents.

[0073] The following describes a requirement code generation device provided by an embodiment of the present invention. The requirement code generation device described below can be referred to in correspondence with the requirement code generation method described above.

[0074] Please refer to the details. Figure 4 , Figure 4 A schematic diagram of a requirement code generation device provided in an embodiment of the present invention may include: The stage input data determination module 100 is used to determine the stage to be executed based on the stage status of the target software requirement, and to obtain the stage input data corresponding to the stage to be executed; the stage to be executed is the current development stage to be executed among multiple development stages corresponding to the target software requirement. The output data determination module 200 is used to process the input data of the stage according to the data processing method corresponding to the stage to be executed, so as to obtain the output data corresponding to the stage to be executed. The stage status update module 300 is used to update the stage status based on the output data when the output data meets the currently set stage switching conditions; The target requirement code determination module 400 is used to determine the next stage to be executed based on the updated stage status, and to determine the stage input data corresponding to the next stage to be executed based on the output data, and to return to the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, and to obtain the target requirement code corresponding to the target software requirement.

[0075] Furthermore, based on the above embodiments, the stage input data determination module 100 may include: A stage state determination unit is used to obtain the stage state of the target software requirement based on a stage state persistence file. The phase determination unit is used to determine, based on the phase status, the phase to be executed as any one of the following: information collection phase, requirement definition phase, functional specification phase, implementation planning phase, task decomposition phase, and development execution phase; The information collection stage is the stage of determining the data required for code generation; the requirement definition stage is the stage of determining the required functions; the function specification stage is the stage of determining the function specifications; the implementation planning stage is the stage of determining the implementation files; the task decomposition stage is the stage of determining the task list; and the development execution stage is the stage of generating code based on the task list file.

[0076] Furthermore, based on any of the above embodiments, the output data determination module 200 may include: The first output data determination unit is used to, during the information collection phase, collect the data required for code generation corresponding to the target software requirements based on the main intelligent agent calling the sub-intelligent agent to collect the data. The second output data determination unit is used in the requirement definition stage to take the data required for code generation as the input data of the stage, and use the main intelligent agent to extract multiple user stories, as well as the functions and priorities corresponding to each user story, and the functional points corresponding to the functions to construct a requirement definition file; wherein, the user story is a functional unit described from the user's perspective. The third output data determination unit is used to take the requirement definition file as the input data of the stage in the functional specification stage, and use the main intelligent agent to generate a functional specification file including acceptance scenarios, functional requirements and acceptance criteria. The fourth output data determination unit is used to generate an implementation planning document by taking the functional specification document as the input data of the implementation planning stage; wherein, the implementation planning document is a structured document that determines the implementation method of the target software requirements at the code level; The fifth output data determination unit is used to take the implementation planning file as the input data of the stage in the task decomposition stage, generate multiple executable tasks, and generate a task list file based on the multiple executable tasks. The sixth output data determination unit is used to take the task list file as the input data of the development execution phase and generate the target requirement code corresponding to the target software requirement.

[0077] Furthermore, based on any of the above embodiments, the fourth output data determining unit may include: The implementation planning document determination subunit is used to generate the implementation planning document, which includes data model fields, interfaces, and architecture design, based on the functional specification document and code knowledge base by the main intelligent agent; wherein, the list of modified documents in the architecture design has been marked with the corresponding user stories.

[0078] Furthermore, based on any of the above embodiments, the fifth output data determining unit may include: An executable task determination unit is used to use the main intelligent agent to break down the file changes in the implementation planning file into executable tasks; The task list file determination unit is used to use the main intelligent agent to label the corresponding task stage, dependency relationship and complexity of the executable task to obtain the task list file.

[0079] Furthermore, based on any of the above embodiments, the stage state update module 300 may include: The semantic analysis unit is used to perform semantic analysis based on the output data using a large language model to determine whether the output data meets the output requirements of the current execution stage. The status update unit is used to determine that the current stage switching condition is met when the output requirements corresponding to the stage to be executed are met, and to update the stage status based on the output data.

[0080] Furthermore, based on any of the above embodiments, the semantic analysis unit may include: The semantic analysis subunit is used to perform semantic analysis based on the output data using the large language model to determine the field integrity result and the semantic quality result. The judgment subunit is used to determine, based on the field integrity result and the semantic quality result, whether the output data meets the output requirements of the current execution stage using the large language model.

[0081] Furthermore, based on any of the above embodiments, the first output data determining unit may include: Calling sub-units is used to invoke tools and sub-units using the main agent; The code generation data determination subunit is used to obtain the code generation data from the project management platform, design tool, code repository and historical iteration records based on the tool and the sub-agent; The data required for code generation includes at least a requirement description and historical code.

[0082] It should be noted that the order of the modules and units in the aforementioned requirement code generation device can be changed without affecting the logic.

[0083] An embodiment of the present invention provides a requirement code generation device, which may include: a stage input data determination module 100, used to determine the stage to be executed based on the stage status of the target software requirement, and obtain the stage input data corresponding to the stage to be executed; the stage to be executed is the current development stage among multiple development stages corresponding to the target software requirement; an output data determination module 200, used to process the stage input data according to the data processing method corresponding to the stage to be executed, to obtain the output data corresponding to the stage to be executed; a stage status update module 300, used to update the stage status based on the output data when the output data meets the currently set stage switching conditions; and a target requirement code determination module 400, used to determine the next stage to be executed based on the updated stage status, and determine the stage input data corresponding to the next stage to be executed based on the output data, and return to execute the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, to obtain the target requirement code corresponding to the target software requirement. As can be seen, compared with the current method of manually writing code, this invention determines the stage to be executed based on the stage status, so that the code generation process no longer depends on a single continuous dialogue or manual memorization of the current progress. Instead, it can clearly identify the processing stage that should be executed at the current time based on the stage status. By dividing the requirement to code generation process into multiple stages to be executed, the stage status is updated and the next stage to be executed is executed only when the output data meets the current set stage switching conditions. This makes the execution of the next stage depend on the output results of the previous stage that meet the conditions, avoiding directly entering the subsequent code generation process when the output of the previous stage is incomplete or does not meet the requirements. Therefore, it can improve the efficiency and quality of code generation.

[0084] The following describes a requirement code generation device provided by an embodiment of the present invention. The requirement code generation device described below and the requirement code generation method described above can be referred to in correspondence.

[0085] Please refer to Figure 5 , Figure 5 A schematic diagram of a demand code generation device provided in an embodiment of the present invention may include: Memory 10 is used to store computer programs; Processor 20 is used to execute computer programs to implement the above-described requirement code generation method.

[0086] The memory 10, processor 20, and communication interface 30 all communicate with each other through the communication bus 40.

[0087] In this embodiment of the invention, the memory 10 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment of the invention, the memory 10 may store programs for implementing the following functions: The stage to be executed is determined by the stage status of the target software requirement, and the stage input data corresponding to the stage to be executed is obtained; the stage to be executed is the current development stage among the multiple development stages corresponding to the target software requirement. According to the data processing method corresponding to the stage to be executed, process the input data of the stage to obtain the output data corresponding to the current stage to be executed; When the output data meets the current stage switching conditions, update the stage status based on the output data; Based on the updated stage status, determine the next stage to be executed, and based on the output data, determine the stage input data corresponding to the next stage to be executed. Then, return to execute the steps of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all development stages are completed, and obtain the target requirement code corresponding to the target software requirements.

[0088] In one possible implementation, the memory 10 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0089] Furthermore, memory 10 may include read-only memory and random access memory, providing instructions and data to the processor. A portion of the memory may also include NVRAM. The memory stores operating systems and operating instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and handling hardware-based tasks.

[0090] Processor 20 can be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic device. Processor 20 can be a microprocessor or any conventional processor. Processor 20 can call programs stored in memory 10.

[0091] The communication interface 30 can be an interface for the communication module, used to connect with other devices or systems.

[0092] Of course, it should be noted that, Figure 5 The structure shown does not constitute a limitation on the requirement code generation device in the embodiments of the present invention. In practical applications, the requirement code generation device may include devices such as... Figure 5 More or fewer components as shown, or combinations of certain components.

[0093] The computer-readable storage medium provided in the embodiments of the present invention is described below. The computer-readable storage medium described below and the requirement code generation method described above can be referred to in correspondence.

[0094] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described requirement code generation method.

[0095] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0097] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0098] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0099] The above provides a detailed description of the requirement code generation method, apparatus, device, medium, and program product provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for generating requirement code, characterized in that, include: The stage to be executed is determined by the stage status of the target software requirements, and the stage input data corresponding to the stage to be executed is obtained. The pending stage is the current pending development stage among the multiple development stages corresponding to the target software requirement; According to the data processing method corresponding to the stage to be executed, the input data of the stage is processed to obtain the output data corresponding to the stage to be executed; When the output data meets the currently set stage switching conditions, the stage state is updated based on the output data; Based on the updated stage status, determine the next stage to be executed, and based on the output data, determine the stage input data corresponding to the next stage to be executed. Then, return to execute the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, and obtain the target requirement code corresponding to the target software requirement.

2. The requirement code generation method according to claim 1, characterized in that, The stage to be executed is determined by the stage status of the target software requirements, and the stage input data corresponding to the stage to be executed is obtained, including: The stage state of the target software requirement is obtained based on the stage state persistence file; Based on the stage status, the stage to be executed is determined to be any one of the following: information collection stage, requirement definition stage, functional specification stage, implementation planning stage, task decomposition stage, and development execution stage. The information collection stage is the stage of determining the data required for code generation; the requirement definition stage is the stage of determining the required functions; the function specification stage is the stage of determining the function specifications; the implementation planning stage is the stage of determining the implementation files; the task decomposition stage is the stage of determining the task list; and the development execution stage is the stage of generating code based on the task list file.

3. The requirement code generation method according to claim 2, characterized in that, According to the data processing method corresponding to the stage to be executed, the input data of the stage is processed to obtain the output data corresponding to the stage to be executed, including: During the information collection phase, the main intelligent agent calls the sub-intelligent agent to collect the data required for code generation corresponding to the target software requirements; In the requirements definition phase, the data required for code generation is used as the input data for the phase. Multiple user stories are extracted using the main intelligent agent, along with the functions and priorities corresponding to each user story, and the functional points corresponding to the functions to construct a requirements definition file; wherein, the user story is a functional unit described from the user's perspective. In the functional specification phase, the requirement definition file is used as the input data for the phase, and the main intelligent agent is used to generate a functional specification file including acceptance scenarios, functional requirements and acceptance criteria. In the implementation planning phase, the functional specification document is used as the input data for the phase to generate an implementation planning document; wherein, the implementation planning document is a structured document that determines the implementation method of the target software requirements at the code level; In the task decomposition phase, the implementation planning file is used as the input data for the phase to generate multiple executable tasks, and a task list file is generated based on the multiple executable tasks. During the development and execution phase, the task list file is used as the input data for the phase to generate the target requirement code corresponding to the target software requirements.

4. The requirement code generation method according to claim 3, characterized in that, In the implementation planning phase, the functional specification document is used as input data to generate an implementation planning document, including: The main intelligent agent generates an implementation planning document, including data model fields, interfaces, and architecture design, based on the functional specification document and code knowledge base. The list of modified files in the architecture design has been marked with the corresponding user stories.

5. The requirement code generation method according to claim 3, characterized in that, In the task decomposition phase, the implementation planning file is used as the input data for this phase to generate multiple executable tasks, and a task list file is generated based on these multiple executable tasks, including: The main intelligent agent is used to break down the file modifications in the implementation plan file into executable tasks. The main intelligent agent is used to label the corresponding task stages, dependencies, and complexity of the executable tasks to obtain the task list file.

6. The requirement code generation method according to any one of claims 1 to 5, characterized in that, When the output data meets the currently set stage switching conditions, the stage state is updated based on the output data, including: Based on the output data, semantic analysis is performed using a large language model to determine whether the output data meets the output requirements of the current execution stage. When the output requirements corresponding to the stage to be executed are met, it is determined that the current stage switching conditions are met, and the stage status is updated based on the output data.

7. The requirement code generation method according to claim 6, characterized in that, Based on the output data, semantic analysis is performed using a large language model to determine whether the output data meets the output requirements of the current execution stage, including: Based on the output data, semantic analysis is performed using the large language model to determine the field integrity results and semantic quality results. Based on the field integrity results and the semantic quality results, the large language model is used to determine whether the output data meets the output requirements of the current execution stage.

8. The requirement code generation method according to claim 1, characterized in that, In the information collection phase, the main agent invokes sub-agents to collect the data required for code generation corresponding to the target software requirements, including: The main agent invokes tools and sub-agents; Based on the aforementioned tools and the aforementioned sub-agent, the data required for code generation is obtained from the project management platform, design draft tools, code repository, and historical iteration records; The data required for code generation includes at least a requirement description and historical code.

9. A requirement code generation device, characterized in that, include: The stage input data determination module is used to determine the stage to be executed based on the stage status of the target software requirements, and to obtain the stage input data corresponding to the stage to be executed. The pending stage is the current pending development stage among the multiple development stages corresponding to the target software requirement; The output data determination module is used to process the input data of the stage according to the data processing method corresponding to the stage to be executed, so as to obtain the output data corresponding to the stage to be executed. The stage status update module is used to update the stage status based on the output data when the output data meets the currently set stage switching conditions; The target requirement code determination module is used to determine the next stage to be executed based on the updated stage status, and to determine the stage input data corresponding to the next stage to be executed based on the output data, and to return to the step of processing the stage input data according to the data processing method corresponding to the stage to be executed, until all the development stages are completed, and to obtain the target requirement code corresponding to the target software requirement.

10. A requirement code generation device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the requirement code generation method as described in any one of claims 1 to 8.

11. A medium, characterized in that, The medium stores a computer program that, when executed by a processor, implements the steps of the requirement code generation method as described in any one of claims 1 to 8.

12. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the requirement code generation method as described in any one of claims 1 to 8.

Images