A hybrid model dual closed loop software development method, system, device and medium

Abstract

This application relates to the field of computer software engineering technology, and discloses a hybrid model dual-closed-loop software development method, system, device, and medium. The method performs structured analysis of development requirements, matches requirement features with requirement element templates, and controls directional clarification based on requirement coverage evaluation values. When coverage reaches a threshold, a directed task graph is constructed. For ready subtasks, cross-file contexts are determined from code semantic indexes and symbol relationship graphs, and code is generated or modified. Associated tests are performed to obtain verification evaluation values. If verification fails, the failure is attributed to a repair subtask and re-scheduled by injecting it back into the task graph. If verification passes, code changes, change descriptions, and test reports are output. This application aims to reduce redundant processing caused by incomplete requirements, code repository context mismatch, and disconnected repair processes.

Description

Technical Field

[0001] This application relates to the fields of computer software engineering and data processing technology, and in particular to a hybrid model dual-closed-loop software development method, system, device and medium. Background Technology

[0002] Language model-based programming assistance systems can receive natural language development requirements and generate code. However, in development tasks targeting existing code repositories, development requirements typically include functional goals, inputs and outputs, constraints, and acceptance criteria, and these elements may appear in a scattered, implicit, or incomplete manner. If the system directly proceeds to code generation before the requirements are complete, inconsistencies can easily arise in subsequent task decomposition, interface design, and testing conditions, leading to duplicate generation and repeated rework.

[0003] In typical software development processes, requirements understanding, task breakdown, code generation, and testing / repair are separated into distinct stages. These stages primarily exchange natural language text or code snippets, lacking a unified evaluation signal that can directly alter the subsequent processing status. Consequently, the system struggles to determine when to further clarify requirements, when to proceed with task planning, and accurately pinpoint the cause of test failures to their original task dependencies.

[0004] Furthermore, existing code repositories contain cross-file class, function, interface, and variable call relationships. Relying solely on local text similarity to retrieve code snippets may miss objects that have call dependencies on the current subtask but have low text similarity; extending the context solely based on call relationships may introduce code irrelevant to the subtask's semantics. Context mismatch can cause generated code to be inconsistent with existing interface contracts, data structures, or call chains.

[0005] Therefore, there is a need for a software development technology solution that can evaluate and control requirement clarification based on requirement coverage, verify and evaluate control delivery or repair, and connect task graphs, repository-level contexts, and failure attribution in the same data flow. Summary of the Invention

[0006] This application provides a hybrid model dual-closed-loop software development method, system, device, and medium to solve the problems of premature task execution when development requirements are incomplete, mismatch between repository-level context and subtask, and inability to inject task dependencies back into test failure results.

[0007] Firstly, embodiments of this application provide a hybrid model dual-closed-loop software development method. This method acquires development requirement information and target code repository identifiers; performs structured parsing of the development requirement information to obtain a set of requirement features; matches the set of requirement features with a preset requirement element template to obtain a requirement coverage evaluation value and a set of missing requirement elements; when the requirement coverage evaluation value is lower than a preset requirement coverage threshold, generates targeted clarification questions based on the set of missing requirement elements, updates the development requirement information using received supplementary responses, and repeats the evaluation until the requirement coverage evaluation value reaches the preset requirement coverage threshold.

[0008] Once the requirement coverage evaluation value reaches the preset requirement coverage threshold, a directed task graph is generated based on the current development requirement information. The system identifies ready subtasks whose predecessor subtasks have been completed from the directed task graph, determines the cross-file context corresponding to the ready subtasks from the code semantic index and symbol relationship graph corresponding to the target code repository, and generates or modifies code based on the cross-file context.

[0009] The system performs associated tests on the generated or modified code and obtains a verification evaluation value based on the test execution results. When the verification evaluation value is lower than the preset verification pass threshold or when the test execution fails, the system attributes the failed test to the cause, identifies the associated subtasks and code snippets, generates a repair subtask, inserts the repair subtask into the directed task graph and updates the dependencies to reschedule the code repair and retesting; when the verification evaluation value reaches the preset verification pass threshold, it outputs the code changes, change descriptions, and a test report.

[0010] Optionally, the requirement element template includes functional objective elements, input / output elements, constraint elements, and acceptance criterion elements. The system calculates the semantic similarity between requirement features and requirement elements respectively, uses the highest semantic similarity corresponding to each requirement element to form the coverage value of that requirement element, and performs weighted aggregation on the coverage values.

[0011] Optionally, the directed task graph uses subtasks as nodes and dependencies as directed edges. The system determines executable subtasks through topological sorting and a ready queue, and assigns subtasks to execution agents based on the matching relationship between roles and task types. Each execution agent exchanges subtask states and intermediate results through a shared task state area.

[0012] Optionally, the code semantic index uses files and symbols as the index granularity, and the symbol relationship graph records definition relationships, reference relationships, and call relationships. The system integrates semantic similarity and graph proximity into a relevance evaluation value to select cross-file contexts and ensure that the indexed version corresponds to the target code repository version.

[0013] Optionally, the verification evaluation value is determined by the number of passed test cases and the total number of test cases. The system categorizes failed tests according to error type, determines associated subtasks and code snippets by combining exception information, file location, and call relationships, and prioritizes repair subtasks over ordinary subtasks that have not yet been executed.

[0014] Secondly, embodiments of this application provide a hybrid model dual-closed-loop software development method system, including a requirements processing module, a task graph planning module, a repository-level code understanding module, a task scheduling and execution agent module, a testing and verification module, a failure attribution and repair module, and a delivery module.

[0015] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein a computer program is stored in the memory, and the processor executes the computer program to implement the aforementioned method. Fourthly, embodiments of this application provide a computer-readable storage medium, wherein the stored computer program, when executed by a processor, implements the aforementioned method.

[0016] By adopting the above technical solution, the requirement coverage evaluation value directly controls the requirement status from pending clarification to plannable, and the verification evaluation value directly controls the task node from verification to completion or pending repair. This makes the two evaluation values ​​status control signals for the software development process, rather than just result fields for display.

[0017] By adopting the above technical solution, failed tests are attributed to subtasks and code snippets. The attribution results are used to generate repair subtasks and update dependencies in the same directed task graph, enabling the verification results to change subsequent scheduling paths.

[0018] By adopting the above technical solution, semantic similarity and graph proximity of the symbol relationship graph jointly participate in cross-file context selection, preserving call dependency information while controlling the context size. Attached Figure Description

[0019] Figure 1 This is a diagram of the overall architecture of the software development system according to an embodiment of this application;

[0020] Figure 2 This is the main flowchart of the software development method according to an embodiment of this application;

[0021] Figure 3 This is a closed-loop diagram of demand coverage evaluation and targeted clarification in an embodiment of this application;

[0022] Figure 4 This is a task graph scheduling and multi-agent collaboration graph according to an embodiment of this application;

[0023] Figure 5 This is a flowchart of a warehouse-level hybrid retrieval process according to an embodiment of this application;

[0024] Figure 6 This is a back-annotation diagram of the verification failure attribution and repair task in an embodiment of this application;

[0025] Figure 7 This is a diagram showing the relationship between key data objects and memory reuse in embodiments of this application;

[0026] Figure 8 This is a structural diagram of an electronic device according to an embodiment of this application; Detailed Implementation

[0027] The embodiments of this application will be further described in detail below with reference to the accompanying drawings. The following embodiments are used to explain the technical solutions and are not intended to limit the scope of protection to the listed models, parameters, software frameworks, or deployment forms.

[0028] Regarding the application environment and key terms, embodiments of this application can run on servers, workstations, personal computers, or computing environments composed of multiple computing nodes. The system can receive development requirement information through a web-based workbench, integrated development environment plugins, command-line interfaces, or application programming interfaces. The development requirement information can be Chinese natural language text, or it can include text converted from speech, interface descriptions, design documents, acceptance rules, and target code repository identifiers.

[0029] The target code repository is the collection of code relevant to this development task. The repository identifier can be a local directory identifier, a repository address, or a project identifier. The repository version identifier is used to ensure that the code semantic index, symbol graph, search results, and code changes correspond to specific commit versions, preventing old indexes from being used for newer versions of the code.

[0030] Requirement elements are abstractions of information categories that should be clearly defined in development requirements. A requirement element template can at least include functional objectives, inputs and outputs, constraints, and acceptance criteria. Requirement features are structured extractions of functional points, data objects, interfaces, constraints, and acceptance criteria from development requirement information.

[0031] In a directed task graph, nodes represent subtasks that can be executed and verified independently, and directed edges represent dependencies between subtasks. Subtask states can include pending, ready, executing, verifying, completed, pending repair, and requiring manual intervention.

[0032] Symbols are functions, methods, classes, interfaces, variables, or other code entities in the target code repository that can be determined by syntax analysis. A symbol relationship graph can record definition, reference, and call relationships. A cross-file context is a combination of multiple code objects associated with the current subtask, along with their paths, symbols, versions, and relationship information.

[0033] System overall architecture, refer to Figure 1The software development system includes a requirement access and requirement understanding module 101, a task graph planning module 102, a task scheduling and execution agent module 103, a repository-level code understanding module 104, a skill invocation module 105, a testing and verification module 106, a failure attribution and repair module 107, a memory module 108, a delivery module 109, and a model adaptation layer 110.

[0034] The requirement access and requirement understanding module 101 receives development requirement information and target code repository identifiers, performs structured parsing of the development requirement information, and maintains current development requirement information, requirement feature set, requirement coverage evaluation value, missing requirement element set, and requirement status. The requirement status includes at least a pending clarification status and a plannable status.

[0035] The task graph planning module 102 generates a directed task graph only when the requirement status is plannable. The task scheduling and execution agent module 103 reads the directed task graph and schedules execution agents. The repository-level code understanding module 104 provides cross-file contexts corresponding to repository versions. The skill invocation module 105 provides invocation of tools such as code retrieval, compilation and building, program execution, static analysis, and version management.

[0036] The testing and verification module 106 executes associated tests and calculates verification evaluation values. If verification passes, the delivery module 109 outputs delivery data; if verification fails, the failure attribution and repair injection module 107 generates repair subtasks and injects them back into the task graph planning module 102. The memory module 108 stores requirements, tasks, code, and verification records. The model adaptation layer 110 encapsulates a unified calling interface for one or more language models.

[0037] The main workflow of software development methodology, refer to Figure 2 The software development method of this application includes steps 201 to 209. The two loops in the figure represent the requirement clarification closed loop and the verification and repair closed loop, respectively.

[0038] In step 201, the first development requirement information and the target code repository identifier are received, and the first development requirement information is parsed in a structured manner to obtain a set of requirement features. The requirement feature records the source fragment, feature type, and structured content.

[0039] In step 202, the set of demand features is matched with the demand element template, the demand coverage evaluation value is calculated, and a set of missing demand elements is formed.

[0040] In step 203, the demand coverage evaluation value is compared with a preset demand coverage threshold. If it is lower than the threshold, the demand status is set to pending clarification and the process proceeds to step 204; if it reaches the threshold, the demand status is set to plannable and the process proceeds to step 205.

[0041] In step 204, a targeted clarification question is generated for the missing requirement element, a supplementary response is received, the supplementary response is merged with the current development requirement information to form updated development requirement information, and the process returns to step 202 for re-analysis and evaluation.

[0042] In step 205, a directed task graph is generated based on the current development requirements information of the planarable state, and the cross-file context corresponding to the ready subtask is determined from the code semantic index and symbol relationship graph.

[0043] In step 206, the execution agent generates or modifies code in the target code repository based on the ready subtask description and cross-file context, invokes skills to complete compilation, building, running or static analysis, and executes tests associated with the subtask.

[0044] In step 207, a verification evaluation value is calculated based on the test execution results. When the verification evaluation value reaches the threshold, the task node status is updated to "complete" and the process proceeds to step 209; if the value is below the threshold or an error occurs during test execution, the task node status is updated to "pending repair" and the process proceeds to step 208.

[0045] In step 208, the failure test is attributed, the associated subtasks and code snippets are identified, the repair subtasks are generated, the repair subtasks are inserted into the original directed task graph and the dependencies are updated, and the process returns to step 205 to re-identify the ready subtasks.

[0046] In step 209, when the task nodes within the delivery scope are completed and the verification evaluation value reaches the threshold, the code changes, Chinese change descriptions, and test reports are summarized.

[0047] Demand coverage assessment and targeted clarification closed loop, refer to Figure 3 The development requirement information 301 is structured and parsed to obtain a requirement feature set 302. A preset requirement element template 303 is semantically matched and element weighted 304 with the requirement feature set 302 to obtain a requirement coverage evaluation value 305 and a set of missing requirement elements 306.

[0048] In one exemplary calculation method, let the set of demand features be... The demand element template is Demand factors The weight is , Indicate demand characteristics With demand factors The semantic similarity between them. The requirement coverage evaluation value can be calculated according to the following formula:

[0049]

[0050] In the formula, Here, n represents the demand coverage evaluation value; m represents the number of demand characteristics; and m represents the number of demand elements. For the first The weights of each demand element are assigned; the highest semantic similarity is used as the coverage value for the corresponding demand element.

[0051]

[0052] In the formula, For the set of missing demand elements, For the first The element matching threshold corresponding to each demand element. (For) The requirement elements generate targeted clarification questions 308, supplementary answers and updated requirements 309 return to the structured parsing process; when the coverage reaches the threshold, the requirement status is set to plannable 310.

[0053] In one exemplary parameter configuration, the preset requirement coverage threshold can be between 0.75 and 0.90, with a recommended initial value of 0.85. The actual value can be calibrated based on the clarification rounds and the accuracy of requirement understanding in the labeled requirement set.

[0054]

[0055] Task graph scheduling and multi-agent collaboration, refer to Figure 4 The task graph planning module decomposes the development requirements information of the planarable state into subtasks and generates a directed task graph 401. The task granularity is constrained by the fact that a single execution agent can complete the task independently and pass independent testing and verification.

[0056] The scheduling submodule 405 reads the pending subtasks 402 and checks the predecessor status 403. When all predecessor subtasks are completed, the subtask is written to the ready queue 404; if the predecessor has not yet been completed, it remains in the pending state. The scheduling submodule 405 assigns a planning agent 406, a coding agent 407, a testing agent 408, or a review agent 409 based on the matching relationship between roles and task types.

[0057] Each execution agent writes the subtask identifier, input version, execution status, intermediate results, and error information to the shared task status area 410. When multiple agents make overlapping modifications to the same code region, the conflict arbitration submodule 411 selects the result or generates a conflict record based on the subtask dependencies and the scope of modification. The completion or failure status write-back 412 is used to update the directed task graph 401.

[0058] Repository-level hybrid retrieval and cross-file context, see reference Figure 5 The target code repository (501) can include source code, project documentation, and historical commit history. The preprocessing excludes automatically generated code and third-party dependency directories, and performs splitting at the file level and symbol level (502).

[0059] Code semantic vector index 503 stores code object vectors, file paths, symbol names, repository version identifiers, and vector model version identifiers. Symbol relationship graph 504 establishes definition, reference, and call relationships by parsing the syntax structure.

[0060] For ready subtask query 505, the system calculates the semantic similarity 506 and graph proximity 507 of the candidate code objects, respectively. The graph proximity weight of a one-hop relationship is higher than that of a two-hop relationship, and it decreases as the number of hops increases.

[0061]

[0062] In the formula, Query vectors for ready subtasks. Let x be a vector of candidate code objects. This represents the semantic similarity mapped to [0,1]. Relevance fusion and ranking can be achieved using the following formula:

[0063]

[0064] In the formula, This is the relevance evaluation value. For graph proximity, For weighting, after sorting by relevance evaluation scores, select the top... Each candidate code object forms a cross-file context 509 and is used for code generation or modification 510.

[0065] In one exemplary parameter configuration, the vector dimension It can be between 384 and 1024. It can be between 0.6 and 0.8. The values ​​can range from 5 to 20; recommended initial values ​​are 768, 0.7, and 10.

[0066]

[0067] When the target code repository undergoes version changes, the system performs incremental index updates on the changed files and symbols. If the repository version carried in the online request is inconsistent with the index version, the index is updated first or a version inconsistency status is returned; the old version context is not used directly to generate code.

[0068] Code generation, skill invocation, and model adaptation: The coding agent receives ready subtask descriptions, cross-file contexts, acceptance criteria, and target code repository versions, generates new code files or modifies existing code files, and records the change location, change content, and affected objects as code change data.

[0069] The skill records in the skill library include the skill name, function description, input mode, output mode, and invocation entry point. The system selects the target skill based on the matching relationship between the task type and the skill function description, and writes the invocation parameters, return code, standard output, standard error, and result file location to the shared task status area.

[0070] The model adaptation layer can maintain the scoring relationship between task types and model capabilities. Requirements parsing, code generation, and failure attribution can be performed by the same model or routed to different models. When a model call fails or times out, the model adaptation layer switches to another model according to the alternative order, while maintaining the same structured input-output pattern.

[0071] Verification evaluation, failure attribution, and remediation task backlog, refer to Figure 6 Code changes and associated tests (601) form the test input. Test execution results (602) include at least the test case identifier, pass / fail status, exception information, file location, call stack, and runtime log. The test verification module calculates the verification evaluation value (603).

[0072]

[0073] In the formula, To verify the evaluation value, The number of test cases passed. This represents the total number of test cases within the scope of this verification.

[0074] When the verification evaluation value reaches the preset verification pass threshold 604, proceed to delivery 612. If it is below the threshold or the test execution fails, the failed test case classification and attribution 605 combines the exception information, file location, call relationship and code change data to determine the associated subtasks and code snippets 606, generate the repair subtasks 607, and insert the task graph and update the dependencies 608.

[0075] If the maximum number of iterations has not been reached, reschedule, repair, and retest 610; if the maximum number of iterations has been reached 609, output the current result and prompt for manual intervention 611.

[0076] In one exemplary parameter configuration, the preset verification pass threshold can be between 0.85 and 1.0, and the key module can be set to 1.0; the preset maximum number of iterations can be between 3 and 10, with a recommended initial value of 5.

[0077]

[0078] For memory data objects and cross-task reuse, refer to Figure 7The requirement record 701 should include at least the development requirement information, requirement characteristics, requirement coverage evaluation value, and clarification responses; the task record 702 should include at least the directed task graph snapshot, node status, and dependencies; the code context record 703 should include at least the file path, symbol name, repository version, and cross-file context; and the verification record 704 should include at least the test results, verification evaluation value, and failure attribution.

[0079] During task execution, the above records are written to the session-level short-term memory 705; after the task ends or is confirmed, the requirements summary, task graph snapshot, key code changes, verification results, and human feedback are written to the project-level long-term memory 706. Similar historical task retrieval 707 provides the results to subsequent requirements understanding and task planning 708.

[0080] The memory record carries the project identifier, task identifier, and repository version identifier. When reusing historical solutions in subsequent tasks, the system first checks whether the repository version and dependencies are still valid.

[0081] Throughout this embodiment, the following example of adding data export functionality to an existing business code repository illustrates the entire processing chain. This example is used to illustrate data flow and state transitions and is not limited to specific business types, programming languages, or software frameworks.

[0082] The system receives the initial development requirement information, "Add export functionality to the order list," along with the target code repository identifier. The requirement understanding module identifies the functional objective but fails to identify the output format, access permissions, and acceptance criteria. The requirement coverage evaluation value is below the threshold, and the requirement status is set to "Pending Clarification."

[0083] The system requires confirmation of the output file format, the roles authorized to perform the export, and the acceptance criteria for successful export. After the supplementary response was merged with the original requirement and re-parsed, the current requirement explicitly states that the output must be a spreadsheet file, only accounts with export permissions can execute it, and the exported file should contain all order fields under the current filtering conditions. The requirement coverage evaluation value has reached the threshold, and the requirement status has changed to "plannable."

[0084] The task graph planning module breaks down requirements into sub-tasks such as export interface implementation, permission verification, data query adaptation, file generation, and correlation testing. The repository-level code understanding module retrieves the order list interface and historical export implementations from the code semantic index, and extends it from the symbol relationship graph to the order service, permission verification function, and file response tool, forming a cross-file context.

[0085] In the initial test, exporting test cases passed normally, but accounts without export permissions could still call the interface. The failure attribution module located the permission verification subtask and its code snippet based on the failed test, call stack, and code changes, generated a repair subtask, and inserted the repair subtask after the permission verification subtask and before the retest subtask.

[0086] During the retest, authorized accounts successfully exported files, while unauthorized accounts received rejection results. The file fields and filtering range met the acceptance criteria. The verification evaluation value reached the threshold, and the delivery module output code changes, Chinese change instructions, and a test report. The requirements, task diagram, and verification results were also written to the project-level long-term memory.

[0087] This implementation demonstrates the control of two evaluation signals over the same development process: the requirement coverage evaluation value controls whether a task graph is generated, and the verification evaluation value controls whether a task is delivered or re-injected to fix it; the repository-level cross-file context provides code relationships corresponding to the project version for code generation and failure attribution.

[0088] Alternative implementation methods allow requirement information to be input directly as text, or after being converted from speech to text. Contextual documentation, interface specifications, and acceptance rules can also be attached. Structured parsing of requirement features can be achieved using a language model, a rule engine, or a combination of both.

[0089] The number of agent roles can be increased or decreased, and multi-agent collaboration can employ shared state areas, message queues, or blackboard mechanisms. Code semantic indexing can use code vectors of different dimensions, and symbol relationship graphs can be stored using relational databases, graph databases, or in-memory graph structures.

[0090] In addition to test pass rate, validation evaluation values ​​can also be determined by combining static check results, build status, or key test weights. Failure attribution can be achieved through rules, program analysis, language models, or a combination thereof, but the attribution results are all used to generate the remediation subtasks of the back-injection task graph.

[0091] The system can be deployed on an enterprise intranet, private cloud, or authorized cloud environment. Code change outputs can be patch files, merge requests, code repository commits, changes within the integrated development environment, or web-based workbench results. These alternative methods do not alter the dual closed-loop relationship of requirement coverage control, task planning, and verification / evaluation control / repair / injection.

[0092] Electronic devices and storage media, see reference Figure 8 The electronic device includes a processor 801, a memory 802, a network interface 803, persistent memory 804, an input / display interface 805, and a system bus 806. The processor 801, memory 802, network interface 803, persistent memory 804, and input / display interface 805 exchange data via the system bus 806.

[0093] The memory 802 stores the currently executing computer program and the state of shared tasks, while the persistent memory 804 stores the target code repository, code semantic index, symbol relationship graph, skill library, and memory. The network interface 803 is used to access the version control system, model services, or distributed execution nodes. The input / display interface 805 is used to receive development requirement information and display task status, clarify issues, and deliverables.

[0094] When processor 801 executes the computer program in memory 802, it performs the aforementioned requirements coverage evaluation, directional clarification, directed task graph generation, repository-level context retrieval, code generation or modification, test verification, failure attribution, remediation task back-injection, and delivery processing.

[0095] Computer-readable storage media may be read-only memory, random access memory, solid-state memory, magnetic disk, optical disk, or other tangible media capable of storing computer programs. When the computer program is executed by a processor, it implements the methods of the embodiments of this application.

Claims

1. A hybrid model dual-closed-loop software development method, characterized in that, include: Obtain the first development requirement information and the target code repository identifier, perform structured parsing on the first development requirement information to obtain a set of requirement features; The set of demand features is matched with a preset demand element template to obtain a demand coverage evaluation value and a set of missing demand elements. When the demand coverage evaluation value is lower than a preset demand coverage threshold, a targeted clarification question is generated based on the set of missing demand elements. Supplementary responses to the targeted clarification questions are received. The supplementary responses are merged with the development demand information corresponding to this round of matching to form updated development demand information. The updated development demand information is used as the current development demand information, and the current development demand information is re-structured, parsed, and matched until the demand coverage evaluation value reaches the preset demand coverage threshold. A directed task graph is generated based on the current development requirement information where the requirement coverage evaluation value reaches the preset requirement coverage threshold. The directed task graph uses subtasks as nodes and the dependencies between subtasks as directed edges. The ready subtasks that have completed the predecessor subtasks are determined from the directed task graph. Based on the ready subtasks, cross-file contexts are determined from the code semantic index and symbol relationship graph corresponding to the target code repository. Based on the cross-file contexts, code is generated or modified in the target code repository. Execute tests associated with the ready subtasks for the generated or modified code, and obtain a verification evaluation value based on the test execution results; When the verification evaluation value is lower than the preset verification pass threshold or the test execution fails, the failed test is attributed, the sub-tasks and code snippets associated with the failed test are determined, a repair sub-task is generated based on the attribution result, the repair sub-task is inserted into the directed task graph and the dependency relationship is updated, so as to re-determine the ready sub-task and execute code repair and retesting. When the verification evaluation value reaches the preset verification pass threshold, the code change, change description, and test report are output.

2. The hybrid model dual-closed-loop software development method according to claim 1, characterized in that, The preset requirement element template includes functional target elements, input and output elements, constraint elements, and acceptance criterion elements; the matching of the requirement feature set with the preset requirement element template includes: calculating the semantic similarity between each requirement feature and each requirement element, taking the highest semantic similarity corresponding to each requirement element as the coverage value of that requirement element, weighting and aggregating the coverage values ​​of each requirement element to obtain the requirement coverage evaluation value, and determining the requirement elements with coverage values ​​lower than the corresponding element matching threshold as the missing requirement element set.

3. The hybrid model dual-loop software development method according to claim 1, characterized in that, The generation of the directed task graph includes: decomposing the current development requirement information into multiple subtasks that can be executed and verified independently based on a preset task granularity threshold, and establishing the dependency relationship between the multiple subtasks; the determination of ready subtasks includes: performing topological sorting on the directed task graph, writing subtasks whose predecessor subtasks are all in the completed state into the ready queue, and assigning the ready subtasks to the corresponding execution agents based on the matching relationship between roles and task types, with each execution agent writing and reading the subtask status and intermediate results through a shared task status area.

4. The hybrid model dual-closed-loop software development method according to claim 1, characterized in that, The code semantic index includes a semantic vector index built based on files and symbols in the target code repository, and the symbol relationship graph includes definition relationships, reference relationships, and call relationships between symbols; The determination of the cross-file context includes: calculating the semantic similarity and graph proximity of candidate code objects for the ready subtask, fusing the semantic similarity and graph proximity into a relevance evaluation value, sorting the candidate code objects according to the relevance evaluation value, and selecting a preset number of candidate code objects at the top of the sort as the cross-file context, wherein the code semantic index, the symbol relationship graph, and the target code repository have corresponding repository version identifiers.

5. The hybrid model dual-closed-loop software development method according to claim 1, characterized in that, The verification evaluation value is the ratio of the number of passed test cases to the total number of test cases. The attribution of failed tests includes: classifying failed tests according to error type; determining associated subtasks and code snippets based on the exception information, file location, and call relationship corresponding to the failed tests; and prioritizing the scheduling of the repair subtasks over ordinary subtasks that have not yet been executed. When the cumulative number of repair rounds reaches the preset maximum iteration round and the verification evaluation value is still lower than the preset verification pass threshold, the current result and manual intervention prompt are output.

6. The hybrid model dual-loop software development method according to claim 1, characterized in that, Also includes: The development requirement information, requirement coverage evaluation value, directed clarification record, directed task graph snapshot, code change, verification evaluation value, failure attribution result and manual feedback are written into the memory bank, which includes a session-level short-term memory area and a project-level long-term memory area. When processing subsequent development requirements, similar historical tasks are retrieved from the project-level long-term memory, and the retrieved requirement summaries, task graph snapshots, and verification results are used as context for subsequent requirement understanding or task planning.

7. The hybrid model dual-closed-loop software development method according to claim 3, characterized in that, It also includes: maintaining a skill library, wherein the skill records in the skill library include skill name, function description, input mode, output mode and call entry point; selecting a target skill based on the matching relationship between the task type of the currently ready subtask and the function description, calling the target skill according to the input mode, and writing the call parameters and return results into the shared task status area, wherein the target skill includes code retrieval, compilation and construction, program execution, static analysis or version management skills.

8. A hybrid model dual-closed-loop software development system, characterized in that, include: The requirement processing module is used to acquire development requirement information, perform structured parsing on the development requirement information, match the obtained requirement feature set with a preset requirement element template to obtain a requirement coverage evaluation value and a set of missing requirement elements, and generate targeted clarification questions based on the set of missing requirement elements and update the development requirement information using supplementary answers when the requirement coverage evaluation value is lower than a preset requirement coverage threshold; the task graph planning module is used to generate a directed task graph when the requirement coverage evaluation value reaches the preset requirement coverage threshold; the task scheduling and execution proxy module is used to determine the completed subtasks of the predecessor subtasks as ready subtasks based on the directed task graph. A repository-level code understanding module is used to determine the cross-file context corresponding to the ready subtask from the code semantic index and symbol relationship graph corresponding to the target code repository; The task scheduling and execution agent module is also used to generate or modify code based on the cross-file context; The test verification module is used to execute tests associated with the ready subtasks and obtain verification evaluation values; the failure attribution and repair injection module is used to determine the associated subtasks and code snippets when the verification evaluation value is lower than the preset verification pass threshold or when the test execution fails, generate repair subtasks, insert the repair subtasks into the directed task graph and update the dependencies. The delivery module is used to output code changes, change descriptions, and test reports when the verification evaluation value reaches the preset verification pass threshold.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the hybrid model dual-loop software development method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the hybrid model dual-loop software development method according to any one of claims 1 to 7.

Images