A large model-based software product pipeline production method

Abstract

The application discloses a large model-based software product pipeline production method, which comprises the following steps: acquiring a requirement description, a specification file, a code index and a dependent task product list, generating a design document, a unified technical scheme and a development task by using a large language model; extracting context requirement items from the task description, constructing a task-level context dependency graph, and forming a context list; performing coverage, version consistency and dependency closure verification on the context list, and generating a task context package after the verification; submitting the development task and the task context package to a command line intelligent agent, generating code modification by a code generation model, and performing compilation and testing; when the compilation or testing fails, distinguishing between context deficiency and code writing error according to error evidence, and respectively updating the task context package or repairing the code for re-execution. The application can improve the matching degree of development context and task requirements, and reduce invalid code modification.

Description

Technical Field

[0001] This application relates to the field of software development technology based on large models, specifically a software product pipeline production method based on large models. Background Technology

[0002] As the application of large language models in software engineering deepens, model-based requirements analysis, design document generation, development task decomposition, code writing, test case generation, and defect repair are gradually being applied to the software development process. Existing code agents can read code repositories, modify code in the execution environment, and run compilation, testing, and other verification commands. Software development is evolving from single-point code assistance to continuous task execution.

[0003] However, software product development involves various types of data, including requirement specifications, architecture design, interface definitions, data entities, business rules, engineering specifications, code versions, and pre- and post-task artifacts, and these data are continuously updated with project iterations. Existing solutions typically provide development context to the code generation model through natural language prompts, fixed file sets, or temporary search results. They lack mechanisms for identifying necessary data for specific development tasks, linking data sources, and verifying data integrity. This can easily lead to problems such as inconsistencies between design documents and the current code version, missing dependency artifacts, and missing interface definitions or test constraints.

[0004] Furthermore, when compilation or testing fails, existing processes typically involve directly regenerating or revising the code. This makes it difficult to accurately distinguish whether the failure is due to insufficient development context or code implementation errors, easily leading to repeated execution of invalid modifications and increasing the costs of manual troubleshooting, version rollback, and task recovery. Therefore, effectively organizing and validating the context required for development tasks and taking appropriate action based on execution errors remains a technical problem that needs to be solved in the large-scale software product pipeline production process. Summary of the Invention

[0005] The purpose of this application is to provide a software product pipeline production method based on a large model to solve the problems mentioned in the background art.

[0006] According to one aspect of this application, a software product pipeline production method based on a large model is provided, comprising the following steps: Obtain the product list of requirements description, specification documents, code index and dependent tasks; generate design documents from the large language model and compile the detailed designs in them into a unified technical solution; and generate development tasks containing task descriptions and dependent task relationships based on the unified technical solution. Extract contextual requirement items from the task description, and construct a task-level contextual dependency graph based on the correspondence between the contextual requirement items and the design document, specification file, code index, and artifact list. A context list is formed based on the task-level context dependency graph. The context list is verified for context coverage, version consistency and dependency closure. After the verification is passed, a task context package is generated. The development task and the task context package are submitted to the command-line agent. The command-line agent calls the code generation model to generate code, modify it, and execute compilation and testing. If compilation or testing fails, the error evidence and the context list determine whether the context is insufficient or the code is written incorrectly. If the context is insufficient, the task context package is supplemented or updated and the development task is re-executed. If the code is written incorrectly, the task context package is kept unchanged, the code is repaired, and compilation and testing are performed again.

[0007] Preferably, the development task further includes task type, functional module identifier, execution level, priority, and execution command; after the development task is generated, the completeness of each field, the matching relationship between the functional module identifier and the functional module list, the legality of the execution level, and the existence of tasks referenced by the dependent task relationship are verified, and the task granularity, unified technical solution coverage, and dependency direction are verified by the large language model. After all verifications are passed, the context requirement item is extracted.

[0008] Preferably, extracting contextual requirements from the task description includes: parsing the task objectives, technical objects, inputs and outputs, exception handling, and acceptance criteria in the task description; forming interface contract requirements based on the interface path or method name; forming data entity requirements based on the data table name or entity name; forming business rule requirements based on exception handling or permission conditions; forming test assertion requirements based on compilation conditions, test cases, or return results; and forming code location requirements based on the functional module identifier.

[0009] Preferably, the task-level context dependency graph includes task nodes, requirement nodes corresponding to each context requirement item, and data nodes corresponding to candidate data; the task nodes are associated with each requirement node, and each requirement node is associated with a data node that provides corresponding information; the candidate data is retrieved from design documents, specification documents, code indexes, and the product list of dependent tasks.

[0010] Preferably, each record in the context list includes a semantic key, file path, source category, design type, requirement identifier, functional module identifier, document version, content summary value, covered context requirement items, dependent task identifier, and validity status; the semantic key is associated with the file path, and the content summary value is generated based on the normalized file content.

[0011] Preferably, the context coverage verification includes: for each context requirement item, determining a coverage marker based on whether there are associated data nodes in the task-level context dependency graph, whether the corresponding file is readable, whether the content summary value is consistent, and whether the data status is valid; determining the weight of each context requirement item based on the proportion of tasks that failed due to the lack of corresponding category data in the same type of historical tasks, and obtaining the context coverage based on the weight and the coverage marker; when the interface contract requirement item, data entity requirement item, and test assertion requirement item are all covered, and the context coverage reaches the 5th percentile of the successful task coverage of the same task type and execution level, the context coverage verification is deemed to have passed; when there are fewer than 30 successful tasks of the same task type and execution level, the context coverage verification is deemed to have passed after all context requirement items are covered.

[0012] Preferably, the version consistency verification includes: using interface path, method name, data entity name, or business rule identifier as technical object identifier, standardizing the structured definition of each technical object to form an object signature; determining the unified technical solution that is bound to the current requirement, has an approved status, and has the largest version number as the baseline version; using the technical object identifier as a matching condition, comparing the object signatures in the baseline version, architecture design, code index, and the product list of dependent tasks, and determining design version conflicts, dependent task products not being integrated, or the current code status being inconsistent with the baseline version based on object signature differences and version relationships.

[0013] Preferably, the dependency closure check includes: reading the status and artifact list of the dependency tasks corresponding to the dependency task relationships one by one, checking whether the dependency tasks are completed, whether the files referenced by the current development task exist, whether the corresponding code commits can be traced by the current task branch, and whether the version identifier of the database migration file is duplicated; if any check fails, the current development task is kept in the pending execution state.

[0014] Preferably, the task context package includes the context list, a read-only copy of the data pointed to by the context list, the structured data of the development task, and a summary of the verification result; after generating the task context package, the summary value of the context list is calculated, and the task context package identifier, the summary value, and the current execution round are written to the checkpoint; when the task resumes, the summary value is compared, and a new execution round is created if the comparison result is inconsistent.

[0015] In another aspect, this application also provides a software product pipeline production system based on a large model, comprising: The development task generation module is used to obtain the product list of requirements description, specification documents, code index and dependent tasks. The large language model generates design documents and compiles the detailed design in them into a unified technical solution. Based on the unified technical solution, development tasks containing task descriptions and dependent task relationships are generated. The context dependency graph construction module is used to extract context requirement items from the task description and construct a task-level context dependency graph based on the correspondence between the context requirement items and design documents, specification files, code indexes and product lists. The task context package generation module is used to form a context list based on the task-level context dependency graph, verify the context coverage, version consistency and dependency closure of the context list, and generate a task context package after the verification is passed. The code execution and error handling module is used to submit the development task and the task context package to the command-line agent. The command-line agent calls the code generation model to generate code, modify it, and execute compilation and testing. If compilation or testing fails, it determines that the context is insufficient or the code is written incorrectly based on the error evidence and the context list. If the context is insufficient, it supplements or updates the task context package and re-executes the development task. If the code is written incorrectly, it keeps the task context package unchanged, repairs the code, and recompiles and tests.

[0016] This application uses development tasks as the basic processing unit, establishing a clear correspondence between requirement descriptions, design documents, specification files, code indexes, and dependent task artifacts. A verifiable context list is formed through a task-level context dependency graph. Data coverage, version consistency, and dependency closure checks are performed before code execution, ensuring the code generation model receives input data that matches the current task and has traceable origins. This reduces execution errors caused by missing data, version conflicts, or the failure to integrate previous artifacts. Combining the task context package with checkpoint records allows for identification of execution cycles when tasks resume or data changes, preventing the continued modification of code using invalid contexts. In case of compilation or testing failures, this invention distinguishes between insufficient context and code errors based on error evidence, object signatures, and the context list. It then employs either updating the task context package or fixing the code while keeping the task context package unchanged, reducing invalid retries and redundant modifications, and improving the consistency and stability of task execution, error location, and code delivery in the software product pipeline. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of a software product pipeline production method based on a large model, provided as an embodiment of this application.

[0019] Figure 2 This is a schematic diagram of a software product pipeline production system based on a large model, provided as an embodiment of this application.

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

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] This embodiment is applicable to software product pipelines that take business requirements as input and sequentially complete software design, development task generation, code modification, compilation and testing, and error handling. The implementation environment includes a model invocation server, a design document database, a task database, a code repository, command-line agent execution nodes, and continuous integration services. The model invocation server runs a large language model and a code generation model. The design document database stores documents and version information for each design stage. The task database stores development tasks, task status, dependent task relationships, task context package identifiers, and checkpoints. The code repository establishes task branches according to development tasks. The command-line agent reads task context packages, modifies code, and executes compilation and testing within an isolated project directory, without directly rewriting approved design documents.

[0023] In one example, the model call server is configured with at least two graphics processors with 80GB of dedicated memory each, and the command-line agent execution node is configured with an 8-core processor and 32GB of memory. Each task is assigned an independent working directory. The design document database, task database, and code repository can be deployed on the same intranet or separately; each node is associated with data through requirement identifiers, development task identifiers, and task context package identifiers.

[0024] The following detailed description, in conjunction with specific embodiments, illustrates the implementation process of the software product pipeline production method based on a large model described in this application. It should be noted that these embodiments are merely for explaining this application and are not intended to limit the scope of protection of this application. Any conventional adjustments or substitutions made by those skilled in the art to the steps without departing from the concept of this application should be included within the scope of protection of this application.

[0025] like Figure 1 As shown in the figure, this application discloses a schematic diagram of a software product pipeline production method based on a large model, including the following method steps: Step S1: Obtain the requirements description, specification documents, code index and the list of dependent tasks. Generate a design document from the large language model and compile the detailed design into a unified technical solution. Generate development tasks containing task descriptions and dependent task relationships based on the unified technical solution. Step S2: Extract contextual requirement items from the task description, and construct a task-level contextual dependency graph based on the correspondence between the contextual requirement items and the design document, specification file, code index, and artifact list. Step S3: Form a context list based on the task-level context dependency graph, verify the context coverage, version consistency and dependency closure of the context list, and generate a task context package after the verification is passed; Step S4: Submit the development task and the task context package to the command-line agent. The command-line agent calls the code generation model to generate code modifications and executes compilation and testing. If compilation or testing fails, it is determined that the context is insufficient or the code is written incorrectly based on the error evidence and the context list. If the context is insufficient, the task context package is supplemented or updated and the development task is re-executed. If the code is written incorrectly, the task context package is kept unchanged, the code is repaired, and compilation and testing are performed again.

[0026] According to an embodiment of this disclosure, in step S1, the large language model receives a requirement description, a preliminary design document, a list of functional modules, a specification document, and structured output constraints, and outputs a design document or development task. The model input is text encoded in Unicode Conversion Format 8, which is converted into a two-dimensional integer tensor by a tokenizer. The dimension is the batch size multiplied by the length of the input sequence. For example, the batch size is 1, and the upper limit of the input sequence length is 32768 tokens.

[0027] Specifically, the large language model employs a Transformer network containing only decoders. The input embedding dimension is 4096, and 32 decoder modules are sequentially connected. Each decoder module includes a root mean square normalization layer, a 32-head causal self-attention layer, a first residual connection, a second root mean square normalization layer, a gated linear unit feedforward layer, and a second residual connection. Each attention head has a dimension of 128, and the feedforward layer has an intermediate dimension of 11008. The last decoder module connects the root mean square normalization layer and the vocabulary projection layer, outputting the vocabulary probability at each labeled position. The model generates text in an autoregressive manner. When generating design documents, the output is a Unicode-converted Format 8 encoded text document; when generating development tasks, the output is structured data, including at least the task name, task type, task description, functional module identifier, execution level, dependent task relationships, priority, and execution command.

[0028] According to embodiments of this disclosure, the code generation model receives a development task and a task context package. The command-line agent first reads the context list in the task context package, then reads the corresponding file content according to each semantic key, and organizes the development task, file content, current code differences, and verification commands into Unicode-8 encoded text. After word segmentation, it forms a two-dimensional integer tensor with the dimension being the batch size multiplied by the length of the input sequence.

[0029] The code generation model employs a transformer network containing only decoders, with an input embedding dimension of 3072 and 24 decoder modules connected in series. Each decoder module includes a 24-head causal self-attention layer, a root mean square normalization layer, a gated linear unit feedforward layer, and residual connections. Each attention head has a dimension of 128, and the feedforward layer has an intermediate dimension of 8192. The model output consists of code modification and verification commands. Code modifications are represented by file paths, modification locations, and modification content, which the command-line agent uses to write to the task branch. Thus, the output of the large language model development task becomes part of the input to the code generation model, and the file content in the task context package provides the design, specifications, and code materials required for the task.

[0030] Optionally, both models can utilize existing pre-trained parameters and undergo supervised fine-tuning using historical software project data from the company. For example, Qwen2.5-72B can be used as the base for the large language model, and DeepSeek-Coder-V2-Lite as the base for the code generation model, both undergoing supervised fine-tuning using historical software project data from the company. The training samples for the large language model consist of requirement descriptions, preliminary design documents, functional module lists, specification documents, and manually confirmed design documents or development tasks. Each sample is grouped according to the design stage, with each group containing no fewer than 1000 records, for a total sample size of no fewer than 5000 records. The training samples for the code generation model consist of development tasks, task context packages, unmodified code, and reviewed and approved code modifications, for a total sample size of no fewer than 10000 records. The training data is divided into training, validation, and test sets in an 8:1:1 ratio, with the test set being set later than the training set during the division.

[0031] The training samples for the large language model consist of requirement descriptions, preliminary design documents, functional module lists, specification documents, and manually approved design documents or development tasks; the training samples for the code generation model consist of development tasks, task context packages, unmodified code, and reviewed and approved code modifications. During training, the target text is shifted one position to the right as the prediction target, and a causal language model loss is used.

[0032] in, Indicates the average batch loss. Indicates the number of samples. Indicates the first Number of target labels per sample Indicates the first The input label sequence of each sample, Represents the first of the target sequence One tag, These parameters represent the conditional probabilities output by the model; all are count or probability values. For example, a sample contains three target labels, and the model gives conditional probabilities of 0.8, 0.5, and 0.25 for the correct label, respectively. The loss for this sample is the average of the negative logarithms of these three conditional probabilities, which is approximately 0.998. Training uses an Adaptive Moment Estimator Optimizer (AdamW) with weight decay. The initial learning rate is, for example, 1 / 100,000. The learning rate increases linearly for the first 5% of training steps, and then decays cosine-wise to 10% of the initial learning rate. The number of training epochs is 2 to 5, and the batch size is 8 to 32. Training stops when the validation set loss does not decrease for two consecutive epochs, and the model parameters with the lowest validation set loss are retained.

[0033] In this embodiment, after receiving the requirement description, the platform assigns a requirement identifier to this software production. The requirement description includes at least the functions to be developed, inputs and outputs, external interfaces, and acceptance criteria. The large language model reads the requirement description and specification document to generate a requirement specification. The platform then uses the validated previous design document as input to generate a logical model, physical model, architecture design, overall design, terminal design, and development specifications. Each design document stores a requirement identifier, design type, document version, content, approval status, and content digest value. The content digest value is a fixed-length digest obtained by performing a secure hash algorithm 256 (SHA-256) on the normalized file content. Normalization includes standardizing newline characters, removing trailing spaces, and fixing the order of structured fields. For example, when the normalized file content is 1280 bytes long, the secure hash algorithm 256 outputs a content digest value consisting of 64 hexadecimal characters. After the file content changes, the platform recalculates and updates the content digest value.

[0034] According to embodiments of this disclosure, each design stage employs a generation, verification, and revision process. Non-empty verification checks the text length, field verification checks required fields, keyword verification checks necessary design objects, and semantic verification uses a large language model to read the design document and verification rules, outputting pass markers and problem descriptions. If verification fails, the platform re-inputs the problem description, the original document, and output format constraints into the large language model to obtain a revised document; the revised document, after passing verification, is saved as a new version. For example, if the architecture design requirements include module division, interface boundaries, and data storage methods, and the generated document lacks interface boundaries, the field verification output will be missing field paths. The revision input only requires supplementing the interface boundaries; the platform does not delete the module divisions and data storage content that have already passed verification in the original document.

[0035] After the backend, frontend, testing, and algorithm roles generate their detailed designs, the large language model reads these four detailed designs and their referenced architecture designs, merges duplicate objects, and handles conflicts according to technical object identifiers. A technical object identifier consists of a functional module identifier, object type, and object name, used to uniquely identify an interface, data entity, page, configuration item, or test object. For objects with the same name and consistent definition, a unified technical solution is retained. For objects with the same name but different fields, parameters, or return types, the large language model lists the conflicting objects and their sources in the output. The platform selects a consistent definition based on the approved architecture design; if no consistent definition can be selected, the compilation is paused and manual confirmation is required. The completed unified technical solution includes interface contracts, data entities, business rules, page rules, and acceptance criteria. Subsequent development tasks only read the unified technical solution and do not directly read the four independent detailed designs.

[0036] The large language model generates development tasks based on requirement descriptions, unified technical solutions, requirement-related functional points, and a list of functional modules. Each record in the functional module list includes a functional module identifier, module name, and code directory. Development tasks include task name, task type, task description, functional module identifier, execution level, dependent task relationships, priority, and execution command. The task description uses fixed fields to record the task objective, technical objects, inputs and outputs, exception handling, and acceptance criteria. The task type can be frontend, backend, or script; the execution level can be infrastructure layer, interface layer, implementation layer, integration layer, or inspection layer; and the dependent task relationships record the identifiers of development tasks that must be completed before the current development task can be executed.

[0037] According to embodiments of this disclosure, after generating development tasks, the platform first performs structural verification. Structural verification checks whether each field exists, whether the functional module identifier belongs to the functional module list, whether the execution level belongs to the limited enumeration, and whether the development task identifier exists in the dependency task relationship. The platform then establishes a directed graph based on the dependency task relationship and performs topological sorting. If all development tasks can enter the sorting result, the dependency direction is acyclic; if there are still development tasks not entering the sorting result, the development tasks not entering the sorting result constitute a circular dependency. For example, if task A depends on task B, task B depends on task C, and task C does not depend on other tasks, the topological sorting outputs task C, task B, and task A in that order. If task C also depends on task A, none of the three tasks can be output as the first task without a preceding dependency. The platform writes task A, task B, task C, and their dependency edges into the revision input, and the large language model regenerates the dependency task relationship.

[0038] After the structural validation passes, the large language model reads the unified technical solution and all development tasks, checking whether each technical object is assigned to at least one development task, whether each development task corresponds to an independent acceptance unit, and whether the dependency relationships conform to the order of interface before implementation and infrastructure before business code. If all validations pass, the platform saves the development tasks; if a validation fails, the platform writes the missing objects or granularity issues into the revision input, revising only the relevant development tasks.

[0039] For example, when a large language model generates a design document, the input is a Prompt organized in the following JSON structure: { "system_prompt": "You are a software architect. Please generate a design document that conforms to the specifications based on the requirements description..." "Requirements Description": "Natural language text describing the functions to be developed, inputs / outputs, external interfaces, and acceptance criteria". "Preliminary Design Documents":[{"Design Type":"Requirement Specification | Logical Model | Physical Model |...","Version":"v1.0","Content":"Text or structured content"}], "List of Functional Modules":[{"Functional Module Identifier":"MOD_ORDER","Module Name":"Order Module","Code Directory":" / src / order"}], "Specification Document":[{"Specification Name":"Interface Design Specification","Content":"..."}], "Structured output constraints":{"Output format":"markdown|json","Required sections":["Module division","Interface boundaries","Data storage method"]} } The output is a Unicode-encoded text document. The document structure includes seven design types: requirements specification, logical model, physical model, architecture design, overall design, terminal design, and development specifications. Each design type is organized by chapter. When generating a development task, the input, in addition to the above, includes a unified technical solution and related functional points. The output is structured data following the following JSON Schema: { "type":"array", "items":{ "taskName":{"type":"string","maxLength":100}, "taskType":{"enum":["frontend","backend","script"]}, "taskDescription":{"type":"string","required":["taskGoal","technicalObjects","inputsOutputs","exceptionHandling","acceptanceCriteria"]}, "functionModuleId":{"type":"string","pattern":"^MOD_[A-Z_]+$"}, "executionLevel":{"enum":["Infrastructure Layer","Interface Layer","Implementation Layer","Integration Layer","Check Layer"]}, "dependencies":{"type":"array","items":{"type":"string"}}, "priority":{"type":"integer","minimum":1,"maximum":10}, "executionCommand":{"type":"string"} } } In some embodiments, for step S2, a contextual requirement item refers to the smallest unit of data that must be obtained to complete the current development task. The platform reads the validated task description and extracts contextual requirement items from the task objectives, technical objects, inputs and outputs, exception handling, and acceptance criteria. Each contextual requirement item records a requirement item identifier, requirement item type, technical object identifier, source category, necessity level, and acceptance reference; the requirement item type includes interface contracts, data entities, business rules, interface rules, engineering specifications, code locations, dependent task artifacts, and test assertions.

[0040] The extraction process employs structured field parsing and rule matching, without separately invoking the extraction model. When an interface path, request method, or method name appears in the task objective or technical object, the platform generates an interface contract requirement item; when a data table name, entity name, request object, or return object appears in the input or output, a data entity requirement item is generated; exception handling or permission conditions form business rule requirement items; compilation conditions, test cases, and return results in the acceptance criteria form test assertion requirement items; and the code directory corresponding to the functional module identifier forms code location requirement items. When the current development task has dependency relationships, the platform also generates dependency task artifact requirement items and writes the identifier of the dependent development task into the source category.

[0041] For example, the task description states that a new POST / orders interface will be added to the order module, with the input being CreateOrderRequest and the output being OrderView. When inventory is insufficient, it will return the OUT_OF_STOCK error code, and will pass two tests: createOrder_success and createOrder_outOfStock. The platform extracts the order interface contract, the CreateOrderRequest data entity, the OrderView data entity, the insufficient inventory business rule, the order module code location, and two test assertions. Each extracted result retains its original field positions, allowing for subsequent retrieval of the task description from the context requirements.

[0042] A task-level context dependency graph is a directed graph consisting of task nodes, requirement nodes, and data nodes. Task nodes represent the current development task, requirement nodes correspond one-to-one with context requirement items, and data nodes represent candidate data from design documents, specification files, code files, or the product list of dependent tasks. The platform establishes edges from task nodes to all requirement nodes, and then retrieves candidate data based on technical object identifiers, source categories, and functional module identifiers, establishing edges from requirement nodes to data nodes.

[0043] The design document database pre-builds an index of design objects. The interface object index records the request method, interface path, parameter name, parameter type, and return type; the data entity object index records the entity name, field name, field type, whether nullables are allowed, and primary key identifier; the business rule object index records the rule identifier, triggering condition, and processing action. The code index is obtained by scanning the code repository and records the class name, function name, file path, functional module identifier, and most recent commit identifier. After the dependency tasks are completed, the command-line agent generates an artifact list, which records interface files, database migration files, configuration files, code commit identifiers, and test results.

[0044] Taking the order interface task as an example, the task node connects to six types of requirement nodes. The order interface contract requirement node matches the interface definition in the unified technical solution through the interface path; the two data entity requirement nodes match the data entities in the unified technical solution through the entity name; the business rule requirement node connects to the inventory rules in the unified technical solution and the error code rules in the backend specification; the code location requirement node connects to the order module directory; and the test assertion requirement node connects to the acceptance conditions in the unified technical solution. If there is no CreateOrderRequest definition in the unified technical solution, and the corresponding requirement node does not have a preferred data node, the platform retains a vacancy in the task-level context dependency graph and writes the context requirement item into the missing source record.

[0045] In some embodiments, for step S3, the context list refers to the data directory and source records submitted to the command-line agent along with the development task. The platform traverses the task-level context dependency graph, exports the data associated with each requirement node as read-only files, and generates a list record for each file. The list record includes semantic keys, file paths, source categories, design types, requirement identifiers, functional module identifiers, document versions, content summary values, covered context requirement items, dependent task identifiers, and validity status. Development specifications use KEY_DEV_STANDARD, front-end page specifications use KEY_UI_PAGE_SPEC, architecture design uses KEY_SYSTEM_DESIGN, and unified technical solutions use KEY_TECH_SOLUTION; code files use KEY_CODE_FILE with a sequence number, and dependent task artifacts use KEY_DEPENDENCY_ARTIFACT with a sequence number.

[0046] Context coverage verification checks each context requirement item one by one. If a context requirement item has a preferred data node, the file can be read, the file summary value matches the list record, and the data status is approved or completed, the coverage flag is set to 1; otherwise, it is set to 0. The weight of each context requirement item is determined based on the proportion of historical tasks of the same category that failed due to the lack of corresponding data. The failure rate for missing class context requirements is:

[0047] in, Indicates the first Failure rate due to missing class context requirements This indicates the number of historical tasks of the same category that failed due to a lack of corresponding data. This represents the total number of historical tasks of the same category; all three are dimensionless. The context requirement item belongs to the first When classifying, its weight is:

[0048] in, Indicates the first The weight of each context requirement item, This represents the missing failure rate for the corresponding category. Context coverage is:

[0049] in, Indicates context coverage. Indicates the number of contextual requirements. Indicates the first The weight of each context requirement item, Indicates the first Override tags for each context requirement item.

[0050] In one example, the total number of historical tasks for the interface contract class is 38. The number of tasks that failed due to missing interface contract data is 6, resulting in a failure rate of 7 divided by 40, or 0.175, corresponding to a weight of 0.2575. A development task has 5 context requirements with weights of 0.9, 0.8, 0.7, 0.4, and 0.3, and coverage markers of 1, 1, 1, 0, and 1, respectively. The context coverage is 2.7 divided by 3.1, resulting in approximately 0.871. The platform requires that the coverage markers for interface contract requirements, data entity requirements, and test assertion requirements all be 1. When there are at least 30 successful tasks of the same task type and execution level, the 5th percentile of the context coverage of these successful tasks is taken as the passing threshold, and this threshold is limited to between 0.85 and 0.98. For example, if the second value of the context coverage of 40 successful tasks, sorted in ascending order, is 0.90, then the passing threshold is 0.90, and the aforementioned 0.871 fails the context coverage check. When there are fewer than 30 successful tasks, the context coverage check is only passed after all context requirement items have a coverage flag of 1. Historical task data is updated once a development task is completed, and the platform adds the corresponding total number of tasks and the number of failed tasks according to the final attribution result of the task.

[0051] According to embodiments of this disclosure, version consistency verification uses object signatures as the comparison object. An object signature refers to the text formed by arranging the structured definition of a technical object in a fixed order. Interface object signatures include the request method, interface path, parameter names and types sorted by parameter name, and return type; data entity object signatures include the entity name, field names sorted by field name, field types, whether nullables are allowed, and primary key identifier; business rule object signatures include rule identifier, triggering conditions, and processing actions. The platform calculates the object signatures and their content digest values ​​in the artifact lists of the unified technical solution, architecture design, code index, and dependent tasks, respectively.

[0052] The baseline version refers to the unified technical solution version that is bound to the current requirement identifier, has an approved status, and the highest version number. The platform matches the object signatures from each source according to the technical object identifier, and then determines the differences based on the version relationship. If the unified technical solution and the architecture design object signatures are different, and the architecture design version is later than the architecture design version referenced by the unified technical solution, a design version conflict is recorded. If the object signature in the code index is different from the baseline version, and the differing object exists in a dependency task submission that has not yet been integrated into the current task branch, it is recorded that the dependency task artifact has not been integrated. If the differing object does not belong to the object to be created in the current development task, and there is no corresponding dependency task submission, it is recorded that the current code state is inconsistent with the baseline version.

[0053] For example, the base version specifies that the `OrderService.create` method receives a `CreateOrderRequest` and returns an `OrderView`, while the code index records that the current method returns an `OrderEntity`. If the artifact list of a dependent task contains a commit identifier that modifies the return type to `OrderView`, but the current task branch cannot trace this commit, the version consistency check outputs that the dependent task artifact is not included; if there is no corresponding commit, the output code's current state is inconsistent with the base version. If the current development task itself is responsible for creating the `OrderService.create` method, the absence of this method in the code index does not constitute a version conflict.

[0054] The dependency closure check reads the task status and artifact list corresponding to each dependency task relationship one by one. The dependency task status must be "completed," the file referenced by the current development task must exist, the corresponding code commit must be traceable from the commit graph of the current task branch, and the version identifier of the database migration file must not be duplicated with an existing migration file in the current branch. For example, if the current development task depends on task A and task B, and task A is completed and its commit has been merged, while task B is completed but its commit has not been merged, then the dependency closure check fails, and the current development task remains in a pending state. The platform first merges the task B commit and then re-checks the files and commit relationships.

[0055] After context coverage verification, version consistency verification, and dependency closure verification all pass, the platform generates a task context package. The task context package consists of a context list, a read-only copy of the data pointed to by the context list, structured data of the development task, and a summary of the verification results. The platform calculates the content digest value of the context list and writes the task context package identifier, content digest value, and the current execution round to the checkpoint. When the task resumes, the content digest value of the context list is recalculated. If the result is consistent, the original execution round continues; if the result is inconsistent, the original execution instance is aborted, a new execution round is created, and a new task context package is generated. Code modifications generated in the original execution round but not yet committed are saved as candidate modifications.

[0056] When validation fails, the platform updates the data according to the failure record. Specifically, if the database already has a valid design document record but the exported file is missing, the file is re-exported; if the code index is missing, the platform scans the code directory corresponding to the current functional module identifier; if a dependency task submission is not integrated, the corresponding submission is merged into the current task branch; if the unified technical solution lacks interface contracts, data entities, or test assertions, the large language model receives the missing context requirements, the current development task, relevant architectural design fragments, and the original unified technical solution, and outputs the supplemented unified technical solution. The platform performs object signature and semantic validation on the supplemented content, saves the new version, and re-executes the aforementioned steps. The maximum number of supplementation attempts is the 95th percentile of the successful supplementation rounds of similar historical tasks; if historical samples are insufficient, three attempts are used. If the maximum number of attempts is reached and the system still fails, the platform pauses the current development task and saves the failure record.

[0057] In some embodiments, for step S4, after receiving the development task and task context package, the command-line agent first verifies whether the task context package identifier matches the checkpoint record, and then reads the context list. The command-line agent loads the development specifications, architecture design, unified technical solution, code files, and dependent task artifacts according to semantic keys, and inputs the development task, file content, current code differences, and verification commands into the code generation model. The code generation model generates code modification and verification commands, and the command-line agent writes the code modifications to the current task branch and executes the compilation, unit test, and task acceptance commands sequentially. Each execution records the command, exit code, standard output, standard error, file path, line number, and occurrence time.

[0058] When compilation or testing fails, the platform generates error evidence from the output of the compiler, testing framework, or continuous integration service. Error evidence refers to a structured record describing the location and content of a failure, including error category, error code, file path, line number, symbol name, expected type, actual type, and failed test identifier. The platform determines the cause of the error in a fixed order, terminating the subsequent determinations in the current round once the previous determination is valid.

[0059] According to some embodiments, the first judgment checks whether the technical object involved in the error belongs to the product of a dependent task and checks whether the current task branch is missing a corresponding code commit; if the condition is met, it is determined that the dependent task product is missing due to insufficient context. If the first judgment is not met, the second judgment compares the signature of the current code object with the object signature in the base version; if the two are inconsistent and the base version is later than the current code object version, it is determined that the version is inconsistent due to insufficient context. If the second judgment is still not met, the third judgment checks whether the context requirement item involved in the error lacks valid information, or whether the content digest value of the valid information is inconsistent with the content digest value in the context list; if either of these conditions exists, it is determined that the information is missing due to insufficient context. If all three judgments are not met, it is determined that there is a code writing error.

[0060] Taking the example of a parameter mismatch when calling the `create` method from `OrderController`, the error evidence records the file path, the `create` symbol, the expected three parameters, and the actual two parameters. If the dependent task artifact list shows a three-parameter interface commit, but the current task branch does not have this commit, the first condition is met, and the platform treats it as a missing dependent task artifact. If the commit already exists, and both the base version and the current interface have three parameters, but `OrderController` still passes two parameters, the first three conditions are not met, and the platform determines it to be a code writing error. Similarly, if the test report indicates a missing `OUT_OF_STOCK` error code, even though the task context package already contains the insufficient inventory business rule and the content digest value is consistent, the platform also determines it to be a code writing error.

[0061] When the context is deemed insufficient, the platform stops the current execution round, saves a snapshot of the code modifications and error evidence, and returns to the aforementioned verification step S3 based on the type of insufficiency. If dependent task artifacts are missing, the corresponding commit is merged; if versions are inconsistent, the corresponding data for the baseline version is updated; if data is missing, the data is re-exported or a unified technical solution is supplemented. After updating, the task context package is regenerated, and a new execution round is created. Code modifications not committed in the previous execution round are not directly written to the new baseline; the code generation model reads the new task context package, error evidence, and candidate modifications before regenerating the code modifications.

[0062] When a code error is identified, the platform keeps the task context unchanged and inputs the error evidence, the failed command, and the differences in the current code into the code generation model. The code generation model generates revised code modifications, the command-line agent applies the modifications, and re-executes the original failed command; after the original failed command passes, the task acceptance command is executed. The platform calculates an error fingerprint based on the error category, error code, normalized file path, and symbol name. The error fingerprint refers to the content digest value used to identify whether two errors belong to the same failure event. If the same error fingerprint appears in two consecutive rounds, the platform re-verifies the content digest value and object signature of the task context; if the content digest value changes, it switches to context insufficiency processing; if the content digest value does not change, the large language model reads the error evidence and the current development task to generate a repair task description, and the code generation model continues to modify the code based on the repair task description. The judgment values ​​for the two consecutive rounds are derived from the distribution of occasional and persistent failures in historical tasks; two rounds are used when historical samples are insufficient.

[0063] After the code passes compilation, unit testing, and task acceptance commands, the command-line agent submits the code and generates a list of artifacts for this development task. The artifact list is written to the interface file, database migration file, configuration file, code submission identifier, and test results, and the task status is updated to "completed." Upon receiving the completion event, the scheduler re-examines subsequent development tasks that reference the current development task; these subsequent tasks enter the execution queue after passing dependency closure checks. Development tasks with the same functional module identifier are executed serially, while development tasks with different functional module identifiers and closed dependencies are executed in parallel. The execution hierarchy is ordered as infrastructure layer, interface layer, implementation layer, integration layer, and inspection layer.

[0064] The above process establishes contextual requirement items, task-level context dependency graphs, context lists, and task context packages on a task-by-task basis. Before execution by the command-line agent, it checks context coverage, version consistency, and dependency closure. After compilation or testing failures, the platform handles error evidence according to dependent task artifacts, baseline versions, and data coverage relationships. When context is insufficient, the task context package is updated; when code errors occur, the task context package is maintained and the code is modified. This ensures that design document versions, task dependencies, input data, code modifications, and verification results continuously correspond within the same development task record, reducing redundant code revisions caused by outdated or missing data.

[0065] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0066] Please see Figure 2 , Figure 2 This application provides a software product pipeline production system based on a large model. The system embodiments are similar to... Figure 1 Corresponding to the illustrated method embodiments, this system can be specifically applied to various electronic devices. The system specifically includes: The development task generation module 201 is used to obtain the product list of requirements description, specification documents, code index and dependent tasks, generate design documents from the large language model and compile the detailed design in it into a unified technical solution, and generate development tasks containing task descriptions and dependent task relationships based on the unified technical solution. The context dependency graph construction module 202 is used to extract context requirement items from the task description and construct a task-level context dependency graph based on the correspondence between the context requirement items and the design document, specification file, code index and product list. The task context package generation module 203 is used to form a context list based on the task-level context dependency graph, verify the context coverage, version consistency and dependency closure of the context list, and generate a task context package after the verification is passed. The code execution and error handling module 204 is used to submit the development task and the task context package to the command line agent. The command line agent calls the code generation model to generate code, modify it, and execute compilation and testing. If compilation or testing fails, it determines that the context is insufficient or the code is written incorrectly based on the error evidence and the context list. If the context is insufficient, the task context package is supplemented or updated and the development task is re-executed. If the code is written incorrectly, the task context package is kept unchanged, the code is repaired, and compilation and testing are performed again.

[0067] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0068] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0069] Figure 3 The diagram illustrates the structure of an electronic device suitable for implementing the methods and / or technical solutions in the embodiments of this application. The electronic device includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage section 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input section 306, an output section 307, a communication section 309, and an input / output (I / O) interface 305 are also connected to the bus 304.

[0070] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 301, it performs the functions defined in the methods of this application.

[0071] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0072] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of electronic devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0073] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A software product pipeline production method based on a large model, characterized in that, Includes the following steps: Obtain the product list of requirements description, specification documents, code index and dependent tasks; generate design documents from the large language model and compile the detailed designs in them into a unified technical solution; and generate development tasks containing task descriptions and dependent task relationships based on the unified technical solution. Extract contextual requirement items from the task description, and construct a task-level contextual dependency graph based on the correspondence between the contextual requirement items and the design document, specification file, code index, and artifact list. A context list is formed based on the task-level context dependency graph. The context list is verified for context coverage, version consistency and dependency closure. After the verification is passed, a task context package is generated. The development task and the task context package are submitted to the command-line agent, which then calls the code generation model to generate modified code and executes compilation and testing. When compilation or testing fails, the error evidence and the aforementioned context list determine whether the context is insufficient or the code is written incorrectly. If the task context is deemed insufficient, supplement or update the task context package and re-execute the development task; if the task context is deemed to be incorrect, keep the task context package unchanged, fix the code, and recompile and test.

2. The method according to claim 1, characterized in that, The development task also includes task type, functional module identifier, execution level, priority, and execution command. After the development task is generated, the completeness of each field, the matching relationship between the functional module identifier and the functional module list, the legality of the execution level, and the existence of tasks referenced by the dependent task relationship are verified. The large language model verifies the task granularity, the coverage of the unified technical solution, and the dependency direction. After all verifications are passed, the context requirement item is extracted.

3. The method according to claim 2, characterized in that, Extracting contextual requirements from the task description includes: parsing the task objectives, technical objects, inputs and outputs, exception handling, and acceptance criteria in the task description; forming interface contract requirements based on the interface path or method name; forming data entity requirements based on the data table name or entity name; forming business rule requirements based on exception handling or permission conditions; forming test assertion requirements based on compilation conditions, test cases, or return results; and forming code location requirements based on the functional module identifier.

4. The method according to claim 3, characterized in that, The task-level context dependency graph includes task nodes, requirement nodes corresponding to each context requirement item, and data nodes corresponding to candidate data. The task nodes are associated with each requirement node, and each requirement node is associated with a data node that provides corresponding information. The candidate data is retrieved from design documents, specification documents, code indexes, and the product list of dependent tasks.

5. The method according to claim 4, characterized in that, Each record in the context list includes a semantic key, file path, source category, design type, requirement identifier, functional module identifier, document version, content summary value, covered context requirement items, dependent task identifier, and validity status; the semantic key is associated with the file path, and the content summary value is generated based on the normalized file content.

6. The method according to claim 5, characterized in that, The context coverage verification includes: for each context requirement item, determining a coverage marker based on whether there are associated data nodes in the task-level context dependency graph, whether the corresponding file is readable, whether the content summary value is consistent, and whether the data status is valid; determining the weight of each context requirement item based on the proportion of tasks that failed due to the lack of corresponding category data in the same type of historical tasks, and obtaining the context coverage based on the weight and coverage marker; when the interface contract requirement item, data entity requirement item, and test assertion requirement item are all covered, and the context coverage reaches the 5th percentile of the successful task coverage of the same task type and execution level, the context coverage verification is deemed to have passed; when there are fewer than 30 successful tasks of the same task type and execution level, the context coverage verification is deemed to have passed after all context requirement items are covered.

7. The method according to claim 6, characterized in that, The version consistency verification includes: using interface path, method name, data entity name, or business rule identifier as the technical object identifier, standardizing the structured definition of each technical object to form an object signature; determining the unified technical solution that is bound to the current requirement, has an approved status, and has the largest version number as the baseline version; using the technical object identifier as the matching condition, comparing the object signatures in the baseline version, architecture design, code index, and the product list of dependent tasks, and determining design version conflicts, missing dependent task products, or inconsistent code current status with the baseline version based on object signature differences and version relationships.

8. The method according to claim 7, characterized in that, The dependency closure check includes: reading the status and artifact list of the dependency tasks corresponding to the dependency task relationships one by one, checking whether the dependency tasks are completed, whether the files referenced by the current development task exist, whether the corresponding code commits can be traced by the current task branch, and whether the version identifier of the database migration file is duplicated; if any check fails, the current development task is kept in the pending execution state.

9. The method according to claim 8, characterized in that, The task context package includes the context list, a read-only copy of the data pointed to by the context list, the structured data of the development task, and a summary of the verification result. After the task context package is generated, the summary value of the context list is calculated, and the task context package identifier, the summary value, and the current execution round are written to the checkpoint. When the task resumes, the summary values ​​are compared. If the comparison results are inconsistent, a new execution round is created.

10. A software product pipeline production system based on a large model, characterized in that, include: The development task generation module is used to obtain the product list of requirements description, specification documents, code index and dependent tasks. The large language model generates design documents and compiles the detailed design in them into a unified technical solution. Based on the unified technical solution, development tasks containing task descriptions and dependent task relationships are generated. The context dependency graph construction module is used to extract context requirement items from the task description and construct a task-level context dependency graph based on the correspondence between the context requirement items and design documents, specification files, code indexes and product lists. The task context package generation module is used to form a context list based on the task-level context dependency graph, verify the context coverage, version consistency and dependency closure of the context list, and generate a task context package after the verification is passed. The code execution and error handling module is used to submit the development task and the task context package to the command line agent, which calls the code generation model to generate code modifications and executes compilation and testing; When compilation or testing fails, the error evidence and the aforementioned context list determine whether the context is insufficient or the code is written incorrectly. If the context is deemed insufficient, supplement or update the task context package and re-execute the development task. When a code error is detected, keep the task context unchanged, fix the code, and recompile and test.

Images