Software development data synthesis method, device, medium and program product based on code repository evolution process

Abstract

The application provides a software development data synthesis method and device based on code repository evolution process, a medium and a program product. The method comprises the following steps: obtaining development process data with code merging requests in a code repository, and structuring development records; determining the evolution relationship between the code merging requests based on the structured development records, and constructing a code repository evolution chain; mapping the structured development records in the code repository evolution chain to staged tasks; and executing corresponding stage task inputs on the repository versions of the staged tasks to generate candidate execution tracks; evaluating the generated patches in the candidate execution tracks based on real patches, and filtering the candidate execution tracks based on stage evaluation scores, and converting the candidate execution tracks meeting the filtering conditions to a target data format to generate software development data. The application improves the reproducibility, verifiability and quality controllability of the software development data, and makes the software development data closer to the real software development scene.

Description

Technical Field

[0001] This application relates to the field of computer software engineering technology, and in particular to a method, device, medium and program product for synthesizing software development data based on the code repository evolution process. Background Technology

[0002] In scenarios such as software engineering model training, software development agent construction, and code repair evaluation, it is often necessary to construct software development data that can characterize the evolution process of real code repositories. Since the software development process in real code repositories is typically continuous and phased, this type of software development data does not only include code snippets or single-round question-and-answer samples, but also needs to record the evolutionary relationships between multiple code merge requests, as well as the repository version, scope of changed files, phase task inputs, patch results, and evaluation results corresponding to each development phase.

[0003] Current methods for constructing software development data typically rely on manually written instructions, static question-and-answer pairs, single-round code completion samples, teacher model distillation results, or repository data mining based on individual issue records, code commits, or merge requests. While these methods can obtain local code snippets, issue descriptions, modified files, or patch results, they usually treat isolated development events and lack effective identification of the continuous evolutionary relationships between multiple merge requests. This results in software development data that fails to reflect the contextual continuity between development events such as feature implementation, defect fixing, test supplementation, and refactoring optimization in a real code repository, and is prone to problems where development goals, code versions, modification scope, and patch results are disconnected.

[0004] Therefore, software development data generated in the current way often fails to maintain the contextual continuity between consecutive development phases, and it is also difficult to ensure that there is a consistent correspondence between development goals, code versions, modification scope, and patch results in the data. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method, device, medium, and program product for synthesizing software development data based on the code repository evolution process. This is at least used to solve the problem that existing software development data construction methods are unable to effectively reflect the continuous evolutionary relationship between multiple development events in a real code repository, so as to maintain the consistency between development goals, code versions, modification scope, and patch results.

[0006] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0007] In a first aspect, some embodiments of this application provide a method for synthesizing software development data based on the code repository evolution process, including:

[0008] Obtain development process data with code merge requests from the code repository, and convert the development process data into structured development records;

[0009] The evolutionary relationship between code merge requests is determined based on multiple structured development records, and a link is constructed on multiple structured development records according to the evolutionary relationship to obtain the code repository evolution chain;

[0010] Multiple structured development records in the code repository evolution chain are mapped to corresponding staged tasks, wherein each staged task includes the repository version of the corresponding development stage, the stage task input, and the actual patch; and the corresponding stage task input is executed on the repository version of each staged task to generate candidate execution trajectories.

[0011] Based on the real patches corresponding to each staged task, the generated patches in the candidate execution trajectory are evaluated to obtain the stage evaluation score.

[0012] The candidate execution trajectories are filtered based on the stage evaluation scores, and the candidate execution trajectories that meet the preset filtering conditions are converted into target data format to generate software development data.

[0013] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0014] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the software development data synthesis method based on the code repository evolution process as described above.

[0015] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the software development data synthesis method based on the code repository evolution process as described above.

[0016] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the software development data synthesis method based on the code repository evolution process as described above.

[0017] Compared with existing technologies, the solution provided in this application converts development process data with code merge requests in the code repository into structured development records, and determines the evolutionary relationship between code merge requests and constructs a code repository evolution chain based on multiple structured development records. This ensures that the generated software development data no longer relies on manually assumed task chains or isolated single code change samples, but retains the contextual continuity, iterative repair, and target continuity relationships between multiple development stages in the real code repository. Furthermore, by mapping the structured development records in the code repository evolution chain to staged tasks, and executing the stage task input on the repository version corresponding to each staged task, the stage tasks can be guaranteed. The input is matched with the corresponding code state to generate candidate execution trajectories with real version context. At the same time, by using the real patches corresponding to each stage task as the evaluation basis, the generated patches in the candidate execution trajectories are evaluated. After the candidate execution trajectories are selected based on the stage evaluation scores, they are converted into the target data format. This can form a closed-loop processing process from real repository evolution relationship identification, stage task execution, real patch evaluation to software development data generation. This improves the reproducibility, verifiability and quality control of software development data, making the final generated software development data closer to the real software development scenario, and making it suitable for application scenarios such as software engineering model training, software development agent construction and code repair evaluation. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a software development data synthesis method based on the code repository evolution process provided in an embodiment of this application;

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

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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] Some embodiments of this application relate to a software development data synthesis method based on the code repository evolution process. This method can be applied to scenarios such as constructing training data for software engineering models, evaluating software development agents, generating code repair task samples, and analyzing the code repository evolution process. Specifically, this method can be executed by a software development data synthesis system deployed on a server, cloud computing platform, or enterprise internal R&D data processing platform. The software development data synthesis system can interact with code hosting platforms, offline repository data sources, repository mirror systems, task execution agents, and model training or evaluation systems. The code hosting platform can provide development process data such as code merge requests, commit records, change files, comments, review information, related issue records, and patch content. The task execution agent can execute stage task inputs and generate candidate execution trajectories in the workspace corresponding to a specified repository version. The model training or evaluation system can receive filtered and format-converted software development data for subsequent model training, fine-tuning, evaluation, or process analysis.

[0023] In real-world software development scenarios, the development process is typically phased and continuous. Subsequent code merge requests may build upon the code state established by previous merge requests, continuing to refine functionality, fix defects, supplement tests, adjust compatibility, or optimize refactoring. If only a single merge request or a single code modification is considered, it's difficult to preserve the contextual continuity between different development phases, and it's also difficult to ensure a consistent correspondence between development goals, repository versions, change file scopes, and patch results in the subsequently generated software development data. Therefore, this application identifies the evolutionary relationships between multiple merge requests and constructs a code repository evolution chain. This allows subsequent phased task mapping, corresponding repository version execution, and real patch evaluation to be built upon the continuous development process of a real code repository, thereby generating software development data that characterizes the real software development process. (Refer to...) Figure 1 As shown, the method may include the following steps:

[0024] Step S1: Obtain development process data with code merge requests from the code repository and convert the development process data into structured development records.

[0025] In one specific embodiment, development process data of a code repository can be obtained from a code hosting platform interface, an offline repository data source, or a repository mirror system. The code hosting platform can include GitHub, GitLab, Gitee, or an internal enterprise code hosting platform; the offline repository data source can include event logs, interface return files, patch files, database tables, or object storage files exported by the code hosting platform; and the repository mirror system can include mirror data formed after periodic or incremental synchronization of the target code repository. Therefore, it is not limited to directly pulling data from an online code hosting platform in real time; subsequent processing can also be performed based on offline archived data, historical backup data, or mirror repository data.

[0026] After acquiring development process data, field mapping and standardization can be performed on the data from different sources. Specifically, since development process data is stored on different code hosting platforms or offline data sources, the field names and organization formats for code repositories, code merge requests, commit records, comments, reviews, related issues, change files, and patch content may differ. Data from different sources can be uniformly mapped into structured development records based on preset field mapping rules.

[0027] In one implementation, each structured development record corresponds to a code merge request. A structured development record may include a code repository identifier, code repository name, code merge request identifier, code merge request number, request status, creation time, merge time, closing time, development description information, repository version information, changed file scope information, associated description information, and patch information.

[0028] The code repository identifier uniquely identifies the code repository to which the structured development record belongs, facilitating the identification of code merge request pairs within the same code repository and preventing erroneous identification of merge requests from different code repositories as having an evolutionary relationship. The code repository name represents the name of the code repository to which the merge request belongs, facilitating result display, data traceability, and cross-repository data management. The code merge request identifier and code merge request number uniquely identify the corresponding code merge request. The request status indicates whether the code merge request is in an open, merged, closed, or other processing state. The creation time, merge time, and closing time determine the chronological order of the code merge requests and provide a time basis for subsequent calculation of creation time differences, screening of candidate evolutionary relationships, and construction of the code repository evolution chain.

[0029] The development description information is used to characterize the development goals, issue descriptions, feature themes, fix intentions, or review feedback corresponding to the code merge request. It can be formed by one or more of the following: title, body, comment information, review information, tag information, or milestone information. The repository version information is used to characterize the code version status before and after the code merge request is executed. It can include one or more of the base commit version, target commit version, and commit list, and is used to restore the repository version of the corresponding development stage later. The changed file scope information is used to characterize the file paths, file names, directory ranges, or module identifiers involved in the code merge request, and is used to generate stage task inputs that match the patch scope later. The association description information is used to characterize the association between the code merge request and other code merge requests, issue records, or development events. It can be formed by one or more of the following: timeline events, associated issue records, cross-reference information, comment references, or review references. The patch information is used to characterize the code difference content corresponding to the code merge request. It can include patch text or difference content, and is used to determine the actual patch for the corresponding development stage later.

[0030] For example, in the data returned by the code hosting platform interface, the code repository identifier can correspond to `repository_id`, the code repository name can correspond to `repository_name`, the code merge request identifier can correspond to `pr_id`, the code merge request number can correspond to `pr_number`, the request status can correspond to `state`, and the creation time, merge time, and close time can correspond to `created_at`, `merged_at`, and `closed_at`, respectively; the title and body can correspond to `title` and `body`, respectively; comments, reviews, and timeline events can correspond to `comments`, `reviews`, and `timeline_events`, respectively; the base commit version, target commit version, and commit list can correspond to `base_commit_sha`, `head_commit_sha`, and `commit_list`, respectively; the changed file scope information can correspond to `changed_files`; the linked issue records, milestones, labels, and cross-reference information can correspond to `linked_issues`, `milestones`, `labels`, and `cross_references`, respectively; and the patch information can correspond to `patch_text` or `diff_content`. Through the above field mapping, development process data from different sources and in different formats can be converted into a unified structured development record.

[0031] Step S1 transforms the development process data, previously scattered across code hosting platform interfaces, offline repository data sources, or repository mirror systems, into structured development records with clearly defined field meanings and a consistent structure. Subsequent steps can then identify the evolutionary relationships between code merge requests based on these structured development records, construct a code repository evolution chain, and further generate phased tasks, candidate execution trajectories, and software development data. This provides a unified and traceable data foundation for the entire data synthesis process.

[0032] Step S2: Determine the evolutionary relationship between code merge requests based on multiple structured development records, and construct a link for multiple structured development records according to the evolutionary relationship to obtain the code repository evolution chain.

[0033] Evolutionary relationships are used to characterize the continuous development association between two code merge requests in terms of development goals, commit versions, change files, content references, or timeline events. For example, a later code merge request may be a defect fix, test addition, regression adjustment, further modification, or refactoring optimization of the functionality implemented by the previous code merge request. Since evolutionary relationships essentially require judgment between two code merge requests, multiple code merge request pairs to be identified can be formed within the same code repository first, and then candidate relationship identification and scoring screening processes can be performed on each code merge request pair.

[0034] In a preferred embodiment, step S2, which involves determining the evolutionary relationship between code merge requests based on multiple structured development records, specifically includes:

[0035] Step S201: Based on multiple structured development records, identify multiple code merge request pairs to be identified, wherein each code merge request pair contains two code merge requests belonging to the same code repository.

[0036] Specifically, based on the code repository identifiers corresponding to multiple structured development records, the repositories of these records can be grouped together to obtain a set of structured development records belonging to the same code repository. Subsequently, from this set, any two structured development records can be selected to correspond to code merge requests, or two code merge requests that meet the initial time sequence condition, forming a pair of code merge requests to be identified. Each code merge request pair includes two code merge requests belonging to the same code repository. The earlier merge request, the one that was merged earlier, or the one that was referenced, can be considered the predecessor code merge request, while the later merge request, the one that was created later, or the one that referenced the other, can be considered the successor code merge request. By using code merge request pairs as the identification object, the complex continuous development process between multiple code merge requests can be decomposed into multiple computable binary relationships, providing a relational foundation for subsequently forming candidate relationship records and constructing a code repository evolution chain.

[0037] Step S202: Determine the creation time difference between the two code merge requests in each code merge request pair, and generate candidate relationship records when the creation time difference meets the preset time window and at least one relationship source strategy is triggered; wherein, the candidate relationship record includes the triggered relationship source strategy and the corresponding relationship evidence information, and the relationship source strategy includes at least one of the following: timeline association strategy, submission connection strategy, target association strategy, file overlap strategy and content reference strategy.

[0038] Specifically, the creation time difference between the two code merge requests in each code merge request pair can be determined, and it can be judged whether this creation time difference meets a preset time window. The preset time window can be set according to the development rhythm of the code repository, the version iteration cycle, or empirical rules. For example, it can be set to not exceed a preset maximum time window, such as 180 days, to filter code merge request pairs with excessively large time spans and weak correlation. When the creation time difference meets the preset time window, it is further determined, based on the structured development records corresponding to the two code merge requests, whether the code merge request pair triggers at least one relationship source strategy. Relationship source strategies can include at least one of the following: timeline association strategy, commit connection strategy, target association strategy, file overlap strategy, and content referencing strategy.

[0039] The timeline association strategy can be determined based on timeline events in the structured development log. For example, if the timeline events of a subsequent code merge request reference a predecessor code merge request, close the same issue record, include dependency descriptions, backlink descriptions, or continued fix descriptions, it can be determined that the code merge request triggers the timeline association strategy. The commit continuation strategy can be determined based on repository version information or commit lists in the structured development log. For example, if there is an inheritance, rollback, continued modification, or patch continuation relationship between the base commit version, commit description, or commit list of a subsequent code merge request and the target commit version or commit information of the predecessor code merge request, it can be determined that the code merge request triggers the commit continuation strategy. The target association strategy can be determined based on title / topic, associated issue records, milestones, or tag combinations. For example, if two code merge requests share the same issue record, the same milestone, the same or similar tag combinations, or if the title / topic points to the same feature or fix target, it can be determined that the code merge request triggers the target association strategy. The file overlap strategy can be determined based on changed file scope information. For example, if two code merge requests have a path overlap exceeding a preset threshold between their changed file sets, or if they involve the same file, the same directory range, or the same module identifier, it can be determined that the code merge request triggers a file overlap policy. Content referencing policies can be determined based on the title, body, comments, or review information. For example, if one code merge request explicitly mentions another code merge request number, issue log number, fix object, error message, or functional module in its title, body, comments, or review information, it can be determined that the code merge request triggers a content referencing policy.

[0040] The aforementioned relationship source strategies can be triggered individually or simultaneously. When at least one relationship source strategy is triggered, candidate relationship records can be generated. These candidate relationship records can include the triggered relationship source strategy and corresponding relationship evidence information. The relationship evidence information can be used to record evidence fragments, evidence summaries, or evidence source fields that triggered the relationship source strategy, thus providing a basis for subsequent quantitative scoring and review. For example, a first code merge request is used to implement the token verification function of an authentication module, and a second code merge request mentions in a comment or body that it will continue to fix the null pointer exception in the token verification function, and both involve the same file path in the authentication module. In this case, the second code merge request may simultaneously trigger the content reference strategy and the file overlap strategy; if the second code merge request also shares the same issue record or tag with the first code merge request, it may also trigger the target association strategy. Corresponding candidate relationship records can be generated accordingly, and the triggered relationship source strategies and corresponding relationship evidence information can be recorded in the candidate relationship records.

[0041] Step S203: Quantitatively score the relationship source strategies and relationship evidence information recorded in the candidate relationship records, and select the target relationship records from the candidate relationship records based on the scoring results to determine the evolutionary relationship between code merge requests.

[0042] Specifically, a relationship credibility score can be calculated for each candidate relationship record based on one or more of the triggered timeline association strategy, submission connection strategy, target association strategy, file overlap strategy, and content reference strategy, as well as the corresponding evidence fragment, trigger location, or evidence summary. Subsequently, the candidate relationship records can be filtered based on this score, and those that meet the preset filtering criteria are identified as target relationship records. Target relationship records are used to characterize the evolutionary relationship between two code merge requests, confirmed by scoring or review, and serve as the data foundation for subsequent link construction of multiple structured development records.

[0043] In a preferred embodiment, step S203 specifically includes:

[0044] Step S2031: Based on the relationship source strategy and relationship evidence information recorded in the candidate relationship records, calculate at least one score corresponding to the candidate relationship record, wherein the score includes at least one of the following: content reference score, target association score, submission connection score, file overlap score, and time proximity score.

[0045] The process reads the relationship source strategies and corresponding relationship evidence information recorded in the candidate relationship records, and calculates the corresponding score based on the triggered relationship source strategies. Candidate relationship records are generated in step S202 for code merge request pairs under the same code repository. They may include a unique identifier for the relationship record, the identifier of the predecessor code merge request, the identifier of the successor code merge request, the set of triggered relationship source strategies, evidence fragments, and the evidence triggering location. Based on the above information, one or more of the following can be calculated: content reference score, target association score, commit connection score, file overlap score, and time proximity score.

[0046] The content citation score characterizes the degree of explicit citation or semantic continuity between two code merge requests in terms of text content. It can be calculated based on relational evidence in the title, body, comments, or review information. For example, a higher content citation score can be determined when the subsequent code merge request explicitly mentions the predecessor's code merge request number, issue log number, target object, error message, or functional module. When the two code merge requests only have similar requirement statements, common error descriptions, or descriptions of the same functional module, the corresponding content citation score can be determined based on rule matching results, text similarity calculation results, or semantic similarity calculation results.

[0047] The target association score is used to characterize the consistency or continuity of two code merge requests in terms of development goals. It can be determined based on whether they share the same issue record, the same milestone, the same or similar tag combinations, the same title theme, or the same functional goal. For example, if both code merge requests are associated with the same issue record and their tags point to the same functional module or defect type, a higher target association score can be assigned; if there is only partial tag overlap or similar title themes, a relatively lower target association score can be assigned.

[0048] The commit continuity score is used to characterize the continuity between two code merge requests in terms of code version or commit content. It can be determined based on the base commit version, commit message, or commit list of the subsequent merge request, as well as the target commit version or commit message of the preceding merge request. A higher commit continuity score can be determined when the base commit version of the subsequent merge request has a version inheritance relationship with the target commit version of the preceding merge request, or when the commit message of the subsequent merge request contains content such as rollback, continued modification, patch continuation, or continued processing based on previous modifications.

[0049] The file overlap score characterizes the degree of overlap between the range of changed files involved in two code merge requests. The sets of changed files corresponding to the preceding and subsequent code merge requests can be extracted separately, and the file overlap score can be calculated based on the path intersection, path union, or module overlap of the two sets of changed files. In one implementation, the file overlap score can be determined based on the intersection-union ratio of the two sets of changed files; a higher file overlap score is given when the two code merge requests involve the same files, the same directories, or the same modules.

[0050] The time proximity score characterizes the temporal proximity of two code merge requests. It can be segmented based on the number of days between the merge time of the preceding request and the creation time of the subsequent request. Generally, a subsequent merge request created within a short period after the preceding request is completed is more likely to have a relationship of continued repair, regression adjustment, or supplementary testing with the preceding request, and therefore can obtain a higher time proximity score; the longer the time interval, the lower the time proximity score can be.

[0051] Step S2032: Normalize each score and perform weighted fusion based on the preset weights corresponding to each score to obtain the total quantitative score.

[0052] Since different scores may come from different calculation methods, such as rule matching results, statistical indicators, set intersection and union ratio, text similarity or time segmentation mapping results, the scores obtained in step S2031 can be normalized to convert each score into a uniform numerical range, such as between 0 and 1. Normalization can reduce the impact of different calculation scales on the fusion results.

[0053] After normalization, a weighted fusion can be performed based on the preset weights corresponding to each score to obtain the quantized total score of the candidate relationship records. This quantized total score is used to characterize the credibility of an evolutionary relationship between the code merge request pairs corresponding to the candidate relationship records. In one implementation, the quantized total score can be calculated according to the following formula:

[0054]

[0055] Where S represents the total quantitative score of the candidate relation record; This indicates the score for content citation; Indicates the target correlation score; This indicates the submission of the connection score; Indicates the file overlap score; The score represents the score for proximity in time; W1, W2, W3, W4 and W5 represent the corresponding weight parameters.

[0056] In one alternative implementation, the weight parameters can satisfy the following relationship:

[0057]

[0058] The values ​​of W1, W2, W3, W4, and W5 can all be between 0 and 1. Each weight parameter can be determined based on historical annotation samples, manual review results, statistical characteristics of different code repository types, or empirical rules, or it can be dynamically adjusted in subsequent processing. Generally, content citation scores and target association scores better reflect the semantic continuity and task consistency between two code merge requests, therefore their corresponding weights can be relatively high; commit connection scores are used to characterize the evolutionary continuity relationship at the code version and commit level, therefore their corresponding weights can be moderate; file overlap scores and time proximity scores serve more as auxiliary signals to supplement the credibility of judging candidate relationships, therefore their corresponding weights can be relatively low. Through the above weighted fusion method, multiple factors such as text citation, development goals, commit versions, file range, and time proximity can be integrated to obtain more stable candidate relationship evaluation results.

[0059] Step S2033: If the total quantitative score is greater than or equal to the first preset threshold, the candidate relationship record is determined as the target relationship record.

[0060] In this step, the total quantized score of the candidate relationship record can be compared with a first preset threshold. When the total quantized score is greater than or equal to the first preset threshold, it indicates that the code merge request corresponding to the candidate relationship record has high credibility in multiple dimensions such as content reference, target association, commit connection, file overlap, or time proximity, and there is a high probability that there is an evolutionary relationship between the two. At this time, the candidate relationship record can be identified as the target relationship record.

[0061] In one implementation, the first preset threshold can be set according to the actual application scenario, for example, it can be set to 0.75. When the total quantized score of the candidate relationship record is greater than or equal to 0.75, the candidate relationship record can be marked as received and used as the target relationship record. The target relationship record can retain information such as the unique identifier of the relationship record, the predecessor code merge request identifier, the successor code merge request identifier, the set of triggered relationship source strategies, the total quantized score, and the evidence summary from the candidate relationship record, so as to serve as the basis for connecting the relationship between two structured development records when constructing the code repository evolution chain.

[0062] For example, if in a code merge request pair, the body of the subsequent code merge request explicitly mentions the predecessor's code merge request number, both share the same issue record, and the changed file scope involves the same functional module, then this code merge request pair may simultaneously have high content citation scores, target association scores, and file overlap scores. After weighted fusion, if the total quantified score reaches a first preset threshold, the candidate relationship record can be automatically identified as the target relationship record, thereby reducing the cost of manual judgment.

[0063] Step S2034: If the total quantitative score is less than the first preset threshold but greater than or equal to the second preset threshold, the candidate relationship record is transferred to the review process, and the review results determine whether to use the candidate relationship record as the target relationship record.

[0064] In this step, when the total quantified score of a candidate relationship record is less than a first preset threshold but greater than or equal to a second preset threshold, it indicates that the candidate relationship record has some relationship evidence, but its credibility is not yet sufficient for direct automatic acceptance. At this time, the candidate relationship record can be transferred to the review process. In one implementation, the second preset threshold can be set according to the actual application scenario, for example, it can be set to 0.45; when the total quantified score is greater than or equal to 0.45 and less than 0.75, the candidate relationship record can be marked as pending review and written into the review queue.

[0065] The records in the review queue can include at least a unique identifier for the relationship record, an identifier for the predecessor code merge request, an identifier for the successor code merge request, a set of triggered relationship source strategies, a quantitative total score, a summary of evidence supporting the candidate relationship, and a review status. Specifically, the identifiers for the predecessor and successor code merge requests can be derived from code merge request identifiers or code merge request numbers in the structured development records; the set of triggered relationship source strategies and the summary of evidence can be generated based on the relationship source strategies, evidence fragments, and trigger locations recorded in step S202; the quantitative total score can be obtained by normalizing and weighting the scores in step S203; and the review status can be added during the review process to record statuses such as pending review, manual approval, or manual rejection.

[0066] During the review process, the system can display to reviewers or the review module the code merge request pair corresponding to the candidate relationship record, the triggered relationship source strategy, evidence summary, evidence trigger location, various scores, and the total quantitative score. Reviewers or the review module can use this information to determine whether there is indeed an evolutionary relationship between the two code merge requests, such as functional continuation, defect fixing, regression adjustment, test supplementation, continued modification, or refactoring optimization. When the review result is a confirmation, the candidate relationship record can be designated as the target relationship record, and the review result can be written back to the corresponding candidate relationship record or candidate relationship record table. When the review result is a manual rejection, the system can exclude the candidate relationship record and it will no longer be used as the basis for constructing the subsequent code repository evolution chain.

[0067] In one optional implementation, when the total quantized score of a candidate relationship record is less than a second preset threshold, the candidate relationship record can be marked as rejected and excluded. For example, when the total quantized score is less than 0.45, it indicates that the candidate relationship record lacks sufficient evidence of content references, target associations, submission connections, file overlaps, or temporal proximity, and can be directly excluded to reduce the interference of low-credibility relationships on subsequent link construction.

[0068] In the solution provided in this embodiment, steps S2031 to S2034 calculate scores from dimensions such as content citation, target association, submission connection, file overlap, and temporal proximity. A quantitative total score is obtained through normalization and weighted fusion, enabling comprehensive judgment of relationship evidence of different types and scales within a unified evaluation framework. This avoids misjudging the evolutionary relationship between code merge requests based solely on chronological order, file overlap, or single text similarity. Simultaneously, by setting a first and a second preset threshold, highly credible candidate relationships are automatically identified as target relationship records, moderately credible candidate relationships with evidentiary basis are transferred to the review process, and low-credibility candidate relationship records are excluded. Therefore, the final selected target relationship records have both quantitative scoring support and traceability of evidence fragments and review status, thereby improving the accuracy, reliability, and auditability of subsequent code repository evolution chain construction.

[0069] In a preferred embodiment, step S2, which involves constructing a link between multiple structured development records based on their evolutionary relationships to obtain a code repository evolution chain, specifically includes:

[0070] Step S204: Based on the code merge request pair identifier, aggregate multiple target relationship records pointing to the same code merge request pair to obtain merge relationship records.

[0071] In this step, a code merge request pair identifier can be generated based on the predecessor and successor code merge request identifiers in the target relationship records. Multiple target relationship records are then grouped according to this identifier. If multiple target relationship records point to the same predecessor and successor code merge request, it indicates that the code merge request pair may be supported by multiple relationship source strategies or multiple pieces of relationship evidence. These target relationship records can then be aggregated into a single merged relationship record. The merged relationship record can retain a complete list of triggering strategies, evidence summaries, evidence trigger locations, the total quantitative score of each target relationship record, and automatic filtering or review results for the code merge request pair. Through this processing, the system can uniformly express multi-source relationship evidence on the same code merge request pair, avoiding repeated connections of the same code merge request pair by multiple relationship records during subsequent link construction.

[0072] For example, for the same code merge request pair, if one target relationship record comes from the content referencing strategy and the other target relationship record comes from the file overlap strategy, and both point to the same predecessor code merge request and successor code merge request, then the two can be aggregated into the same merge relationship record, and the content referencing strategy and the file overlap strategy and the corresponding evidence digest can be retained in the merge relationship record.

[0073] Step S205: Determine the maximum value of the total quantitative score of each target relationship record as the fusion relationship score of the fusion relationship record, and determine the final relationship status of the fusion relationship record based on the automatic filtering results and review results of each target relationship record.

[0074] In this step, for multiple target relationship records contained in the same fusion relationship record, the total quantified score of each target relationship record can be extracted, and the maximum value among them can be determined as the fusion relationship score of the fusion relationship record. Using the maximum quantified total score as the fusion relationship score can retain the relationship judgment result with the highest credibility among multi-source evidence for this code merging request, avoiding a decrease in the overall relationship credibility due to the existence of weak evidence relationships. At the same time, the fusion relationship record can still retain the triggering strategies and evidence summaries corresponding to other target relationship records for subsequent review, tracing, or interpretation.

[0075] Furthermore, the final relationship status of the fused relationship record can be determined based on the automatic filtering and review results of each target relationship record. In one implementation, if any target relationship record is in the "accepted" state, the final relationship status of the corresponding fused relationship record can be determined as "accepted"; if there are no target relationship records in the "accepted" state, but there are target relationship records in the "manually confirmed" state, the final relationship status of the corresponding fused relationship record can be determined as "manually confirmed"; if only target relationship records in the "pending review" state exist, the final relationship status of the corresponding fused relationship record can be determined as "pending"; if all relevant target relationship records are manually rejected or do not meet the retention conditions, the final relationship status of the corresponding fused relationship record can be determined as "rejected". Through this status determination method, the automatic filtering results and review results can be unified into the same fused relationship record, forming a clear relationship status for subsequent chain construction.

[0076] Step S206: Determine the fusion relationship record whose final relationship state satisfies the preset construction chain conditions as the final relationship record, and form a final relationship record set consisting of multiple final relationship records.

[0077] In this step, the final relationship status of the fusion relationship record can be used to determine whether it meets the preset construction chain conditions. The preset construction chain conditions may include: the final relationship status of the fusion relationship record being either "received" or "manually confirmed." In other words, only fusion relationship records that have undergone automatic screening or manual review will be determined as final relationship records; fusion relationship records with a final relationship status of "pending" or "rejected" can be temporarily excluded from subsequent code repository evolution chain construction, or they can be retained in the pending review set, failed relationship set, or audit records.

[0078] Through the above processing, a final relationship record set can be formed, consisting of multiple final relationship records. Each final relationship record can be used to represent the confirmed evolutionary relationship between two code merge requests in the same code repository, and can include information such as the predecessor code merge request identifier, the successor code merge request identifier, the merge relationship score, the final relationship status, the trigger strategy list, and the evidence summary. This final relationship record set serves as the relationship foundation for subsequently connecting multiple structured development records and constructing the code repository evolution chain.

[0079] Step S207: Based on the final relationship record set, within the same code repository, connect multiple structured development records according to the time order, fusion relationship score and dependency connectivity of each final relationship record, and obtain the code repository evolution chain according to the preset chain length constraint.

[0080] In this step, a code repository evolution chain can be constructed within the scope of the code repository corresponding to the same code repository identifier, based on the set of final relationship records. Specifically, structured development records can be used as link nodes, and final relationship records can be used as relationship edges connecting two link nodes. The order of link nodes is determined according to the creation time, merge time, or closure time of the code merge request. For multiple optional connection relationships, the selection can be made by combining the fusion relationship score and dependency connectivity, so that there is a corresponding final relationship record between adjacent structured development records in the link.

[0081] The fusion relationship score measures the reliability of the connection between two structured development records, while dependency connectivity characterizes whether multiple structured development records can form a continuous and unbroken evolutionary path. For example, if there is a final relationship record between the first and second structured development records, and also between the second and third structured development records, the system can connect the three into a code repository evolution chain, provided the temporal order is satisfied. If multiple candidate connection paths exist, the connection path with a higher fusion relationship score, a reasonable temporal order, and stronger dependency connectivity can be prioritized to reduce the interference of weak correlations on link construction.

[0082] Furthermore, the constructed chains can be filtered according to preset chain length constraints. For example, the chain length of a code repository evolution chain can be set to 2 to 8. When the chain length is less than 2, it is difficult to reflect the continuous evolution process between multiple code merge requests; when the chain length is too long, it may increase weakly related connections, version drift, and execution costs, reducing the stability of subsequent staged task execution and evaluation. Therefore, limiting the chain length to 2 to 8 is beneficial for covering common continuous development patterns such as feature implementation, defect fixing, regression fixing, test supplementation, and iterative optimization, while maintaining the executability and verifiability of the chain construction results.

[0083] In the solution provided in this embodiment, through steps S201 to S207, candidate evolutionary relationships can be identified within the same code repository using code merge request pairs as identification units, based on creation time difference, relationship source strategy, and relationship evidence information. Credible target relationship records are obtained through quantitative scoring and verification screening. Furthermore, multi-source relationship records pointing to the same code merge request pair are fused, retaining multiple triggering strategies and evidence summaries. A final relationship record set is formed based on the fused relationship score and the final relationship status, avoiding interference from duplicate relationships, weak evidence relationships, or unconfirmed relationships in link construction. Therefore, when constructing the code repository evolution chain, multiple structured development records can be connected under the constraints of time sequence, relationship credibility, and dependency connectivity. This allows the obtained code repository evolution chain to more accurately represent the continuous development process in the real code repository, including function implementation, defect fixing, regression adjustment, test supplementation, and iterative optimization, providing a reliable link foundation for subsequent phased task generation, candidate execution trajectory construction, and real patch evaluation.

[0084] Step S3: Map multiple structured development records in the code repository evolution chain to corresponding staged tasks. Each staged task includes the repository version of the corresponding development stage, the stage task input, and the actual patch. Execute the corresponding stage task input on the repository version of each staged task to generate candidate execution trajectories.

[0085] In a preferred embodiment, step S3, which maps multiple structured development records in the code repository evolution chain to corresponding staged tasks, specifically includes:

[0086] Step S301: Based on the link order of each structured development record in the code repository evolution chain, determine the stage sequence information and stage dependency relationship corresponding to each structured development record.

[0087] In this step, the link sequence of multiple structured development records in the code repository evolution chain can be read, and each structured development record can be mapped to a development stage. The link sequence can be determined by the final relationship record between the predecessor code merge request and the successor code merge request, or it can be corrected by combining the creation time, merge time, or closure time of the code merge request. A stage identifier and a stage sequence number are generated for each development stage, where the stage identifier is used to uniquely identify the stage, and the stage sequence number is used to indicate the position of the stage in the code repository evolution chain.

[0088] Furthermore, the stage dependencies between development stages can be determined based on the final relationship records between adjacent structured development records in the code repository evolution chain. For example, if the code merge request corresponding to a later structured development record is a continuation of the fix, test supplement, regression adjustment, or refactoring optimization of the code merge request corresponding to a previous structured development record, then the later stage can be determined to depend on the previous stage. If the current stage does not have an explicit dependency specification, it can be set to depend on its previous stage by default, so that the subsequently generated staged tasks can maintain the context continuity relationship in the actual code repository development process.

[0089] Step S302: Based on the repository version information, changed file scope information and patch information in each structured development record, determine the repository version before execution, repository version after execution, changed file scope and actual patch for the corresponding staged task.

[0090] In this step, repository version information, changed file scope information, and patch information can be extracted from each structured development record and converted into version, scope, and patch fields in the phased task. Specifically, repository version information can include one or more of the base commit version, target commit version, and commit list. The base commit version can be identified as the repository version before the execution of this phase, used for subsequent phase task input in the code state corresponding to this version. The target commit version can be identified as the repository version after the execution of this phase, used to characterize the code state after the actual code merge request for this phase is completed. Changed file scope information can be used to determine the file paths, file names, directory ranges, or module identifiers involved in this phase. Patch information can be used to determine the actual patches for this phase, which can be extracted from the patch text or difference content in the source code merge request.

[0091] In this embodiment, the real patch is not merely an ancillary result of the phased task, but rather serves as an objective reference for patches generated in the subsequent evaluation candidate execution trajectory. Since patches directly reflect actual file modifications, code snippet edits, and core logic changes that occur during a specific development phase, real patches offer greater objectivity and verifiability compared to relying solely on textual responses, task description similarity, or model self-evaluation results. Therefore, when generating phased tasks, the repository version before execution, the repository version after execution, the scope of changed files, and the real patch are simultaneously bound. This ensures that subsequent task execution and patch evaluation are based on the actual code state and modification results of the development phase, thereby preventing a disconnect between the phased task and the actual code modification results.

[0092] Step S303: Based on the development description information and change file scope in each structured development record, generate stage task input that matches the patch scope of the corresponding development stage.

[0093] In this step, the development description information may include one or more of the following: title, body, comments, review information, associated issue records, tags, milestones, or timeline events, used to characterize the issues, features, fixes, review comments, or refactoring topics addressed in this phase; the change file scope is used to characterize the code objects involved in the development intent in the actual code repository, including file paths, file names, directory ranges, module identifiers, or code regions, to constrain the code scope pointed to by the phase task input.

[0094] While development descriptions reflect the intent behind code merge requests, they can be quite general. Without constraints on the scope of changed files, the generated stage task input may have an overly broad scope, unclear targeting, or even point to files from other stages. This makes it difficult to guarantee comparability with the actual patches generated during subsequent execution of the stage task input. Therefore, when generating stage task inputs, both development descriptions and the scope of changed files should be considered. This ensures that the stage task input reflects the problem, feature, or fix target of the current stage, while also referencing the actual file paths, filenames, module names, or stability scope identifiers involved in the current stage. This guarantees that the stage task input matches the patch scope of the corresponding development stage.

[0095] It's important to note that "matching the patch scope" doesn't require the stage task input to directly describe the specific modifications of the actual patch, nor does it require the subsequently generated patch to be completely identical to the actual patch line by line. Instead, it requires that the task objective and code scope pointed to by the stage task input remain consistent with the modified objects corresponding to the actual patch. Using this method, after executing the stage task input on the corresponding previous repository version, the generated patch in the candidate execution trajectory can be compared with the actual patch of that stage. This allows for assessment of whether the candidate execution trajectory truly reproduces the task results of that development stage based on factors such as file hit rate, edit coverage, core logic consistency, and patch structure similarity.

[0096] Furthermore, the validity of the generated stage task inputs can be validated. When a stage task input simultaneously reflects the development goals of the current stage and references the scope of changed files or stable module identifiers for the current stage, the stage task input can be deemed valid. Conversely, when a stage task input only references files from other stages, or is significantly inconsistent with the modification scope corresponding to the actual patch in that stage, the stage task input can be deemed invalid, triggering regeneration, manual correction, or abandonment of the stage task input. This validation prevents inconsistencies between stage task inputs and the actual patch scope, thus avoiding impacts on the accuracy of subsequent candidate execution trajectory generation and patch evaluation.

[0097] Step S304: Based on the phase sequence information, phase dependencies, repository version before execution, repository version after execution, scope of changed files, phase task input, and actual patches, generate phased tasks corresponding to each structured development record.

[0098] In this step, the stage sequence information, stage dependencies, repository version before execution, repository version after execution, scope of changed files, stage task inputs, and real patches obtained from steps S301 to S303 can be organized to generate staged tasks corresponding to each structured development record. Each staged task can be used to represent a development stage in the code repository evolution chain and serve as the basic task unit for subsequent task inputs on the corresponding repository version, generating candidate execution paths, and evaluating real patches.

[0099] In one implementation, a phased task may include a phase identifier, an evolution chain identifier, a phase sequence number, a phase name, a source code merge request number, a pre-execution repository version, a post-execution repository version, a scope of changed files, phase task inputs, phase dependencies, a patch set, and actual patches. Specifically, the phase identifier uniquely identifies the phase; the evolution chain identifier identifies the code repository evolution chain to which the phase belongs; the phase sequence number indicates the phase's order in the evolution chain; the phase name describes the phase's theme, such as feature implementation, defect fixing, regression fixing, test supplementation, or refactoring adjustments; the source code merge request number traces back to the corresponding code merge request; the pre-execution repository version is used to subsequently build the execution environment for this phase; the post-execution repository version characterizes the actual code state after the phase is completed; the scope of changed files limits the code objects involved in the phase task; the phase task input serves as input for subsequent phase tasks; the phase dependencies characterize the preceding phases or outputs that the current phase depends on; the patch set records the patch content related to this phase; and the actual patches serve as the benchmark for subsequent patch generation during evaluation.

[0100] In the solution provided in this embodiment, steps S301 to S304 convert multiple structured development records in the code repository evolution chain into a set of staged tasks. Each staged task has a clear stage sequence, dependencies, repository versions before and after execution, scope of changed files, stage task inputs, and actual patches. Therefore, when executing stage task inputs subsequently, the task can be reproduced on the actual repository version of the corresponding development stage, and the generated patch can be evaluated based on the actual patch.

[0101] In a preferred embodiment, step S3, which involves executing the corresponding stage task input on the repository version of each staged task to generate candidate execution trajectories, specifically includes:

[0102] Step S305: Based on the pre-execution repository version in each stage of the task, construct a repository workspace that matches the corresponding development stage.

[0103] In this step, the repository version before execution can correspond to the base commit version in the structured development log, representing the code state before the actual execution of this development phase. A repository workspace consistent with this repository version before execution can be built through methods such as version checkout, repository image restoration, container mounting, cache workspace copying, or offline archive restoration.

[0104] The reason for building the repository workspace based on the repository version before execution is that the input for a phase task needs to be executed in the code state before the actual occurrence of that development phase. If the input for a phase task is executed in the code state of an incorrect version, a subsequent version, or another phase, the generated patch may be based on modified code, code lacking relevant context, or code containing changes from other phases. This would cause the generated patch to deviate from the actual development context of that phase, making it difficult to effectively compare with the actual patch corresponding to that phase later. Therefore, this embodiment ensures a consistent correspondence between phase task inputs, code state, and actual patches by limiting the repository workspace to the repository version before execution.

[0105] In one implementation, after building the repository workspace, the workspace can be initialized, for example, by installing dependencies, restoring configuration files, loading test scripts, setting environment variables, verifying the existence of target files, or recording the current commit version, branch information, and dependency status. This initialization process can improve the stability and reproducibility of subsequent task execution.

[0106] Step S306: Execute the corresponding stage task input in the repository workspace, generate the corresponding development stage patch, and record the execution process information. The execution process information includes one or more of the following: stage input, interaction process information, tool call information, stage completion status, and running log.

[0107] In this step, the phase task inputs corresponding to the phased tasks can be executed in the repository workspace constructed in step S305. The phase task inputs can be the input queries generated in step S303 that match the patch scope of the current development phase, used to instruct the execution agent, code repair model, or software development agent to complete the code modification tasks of the corresponding development phase in the current repository workspace, such as feature implementation, defect repair, test supplementation, regression adjustment, or refactoring optimization tasks.

[0108] In one specific embodiment, during the task input process in the execution phase, the task execution agent can invoke tools such as file search, code reading, code editing, command execution, test execution, and build checks to locate the code to be modified, generate code modification content, and verify the modification results. After modifying the repository files, the task execution agent can generate a patch corresponding to the development phase based on the file content before and after the modification. The generated patch is used to characterize the code modification results generated by the task execution agent for the current development phase, and it can include one or more of the following: the file path of the modified file, code snippets before and after the modification, line-level differences, added content, deleted content, replaced content, or uniform difference format data. This generated patch serves as the result data in the candidate execution trajectory and is used for subsequent comparison and evaluation with the actual patch of the development phase. If the task execution agent fails to generate effective code modifications, or if the generated patch is missing due to execution failure, interruption, timeout, abnormal test environment, patch extraction failure, etc., the corresponding patch missing status, exception reason, accessed files, executed tool calls, running logs, and phase completion status can be recorded.

[0109] During execution, execution process information can be recorded synchronously. This information can include one or more of the following: stage input, interaction process information, tool call information, stage completion status, and runtime logs. Stage input records the actual task input executed in the current stage; interaction process information can include dialogue records, message sequences, inference explanations, or intermediate responses between the execution agent and the large language model; tool call information can include records of tool calls such as file search, code reading, code modification, test execution, build checks, and command execution; stage completion status indicates whether the stage task has been completed, failed, been interrupted, or needs to be retried; runtime logs can include command output, test results, error logs, exception information, build logs, or environment logs. By recording the above execution process information, not only can the final generated patch be obtained, but the operation path, tool behavior, and runtime feedback during the patch generation process can also be preserved.

[0110] For example, in a development phase that addresses a null pointer exception, the phase task input can be executed in the workspace corresponding to the previous repository version. For instance, the task could be set to "Fix the issue of a null pointer exception being triggered when the token is empty in the authentication module, while maintaining compatibility with existing interfaces." The task execution agent can read the token verification file in the authentication module, analyze the token verification logic, add null value checks or exception handling logic at appropriate locations, and run relevant test cases. A corresponding patch can be generated based on the code differences before and after this modification, while simultaneously recording the task execution agent's message sequence, file read records, code editing records, test execution results, phase completion status, and execution logs. This not only provides the code modification results for this phase but also preserves the execution process that generated these results, providing a complete basis for subsequent patch evaluation, failure analysis, and training sample construction.

[0111] Step S307: Generate candidate execution trajectories based on generated patches and execution process information.

[0112] In this step, the generated patch and execution process information obtained in step S306 can be structured and organized to generate candidate execution trajectories for the corresponding development stage. Candidate execution trajectories can be used to record the complete process and results of executing stage task inputs on a specified repository version. In one implementation, the candidate execution trajectory may include fields such as trajectory identifier, stage identifier, evolution chain identifier, repository version before execution, stage input, interaction process information, tool call information, generated patch, stage completion status, and runtime logs.

[0113] Among them, the generated patch is used to characterize the code modification results produced by the task execution agent in response to the current development stage, and is the main object for subsequent comparison and evaluation with the real patch; the stage input is used to restore the task context corresponding to the candidate execution trajectory; the interaction process information and tool call information are used to record the intermediate behaviors of the task execution agent in the process of code understanding, file retrieval, code modification, test execution, etc., which can be used for subsequent process supervision sample construction and audit traceability; the running log is used to record command output, test feedback, error information or environmental anomaly information, which can be used for subsequent failure cause analysis and execution strategy optimization.

[0114] Furthermore, candidate execution trajectories can be marked with status based on stage completion status. Stage completion status is used to characterize the execution result status of the task execution agent for the current stage task input, including one of the following: completed, failed, interrupted, or timed out. For example, if the task execution agent completes code modification and generates a patch, the candidate execution trajectory is marked as completed; if the task execution agent fails to locate the code to be modified, fails to generate a patch, or the test verification fails, the candidate execution trajectory is marked as failed; if the task execution process is prematurely terminated by the system or manually, it is marked as interrupted; if the execution time exceeds the preset time limit and is still not completed, it can be marked as timed out.

[0115] For candidate execution trajectories that have failed, been interrupted, or timed out, they can still be generated based on recorded stage inputs, interaction process information, tool call information, and runtime logs. These can then be used for failure cause analysis, execution strategy optimization, or high-value failure sample screening. For candidate execution trajectories that are completed and have generated valid patches, they can be sent to the subsequent real patch evaluation process to determine whether the generated patch is consistent with the real patch of the corresponding development stage in terms of modified files, edit locations, core logic, and patch structure. In the event of a missing patch, a difference summary can be generated as a fallback candidate and associated with the corresponding candidate execution trajectory. The difference summary can be used to record the reasons why the current stage task failed to generate a patch, the files or modules that were located or attempted to be accessed during execution, tool call results, error logs, test feedback, and deviations from the scope of the real patch. The difference summary can be saved as abnormal result data in the candidate execution trajectory for subsequent audit tracing, failure cause analysis, execution strategy optimization, manual review, or high-value failure sample screening.

[0116] In the solution provided in this embodiment, steps S305 to S307 construct a corresponding repository workspace based on the repository version before execution, and execute the stage task input within the context of this real version, thereby avoiding the generated patch deviating from the current development stage due to code version inconsistencies. Furthermore, while generating the patch, stage input, interaction process information, tool call information, stage completion status, and runtime logs are recorded and structured into candidate execution trajectories, ensuring that the candidate execution trajectories simultaneously contain code modification results and execution process records. This improves the reproducibility and verifiability of the candidate execution trajectories and provides a reliable basis for subsequent real patch evaluation, failure analysis, and software development data generation.

[0117] Step S4: Based on the real patches corresponding to each stage of the task, evaluate the generated patches in the candidate execution trajectory to obtain the stage evaluation score.

[0118] In this step, the generated patches in the candidate execution trajectory are compared with the actual patches recorded in the phased tasks to obtain the phase evaluation score corresponding to the candidate execution trajectory. The generated patches represent the code modification results produced by the task execution agent after the task input in the execution phase, while the actual patches represent the actual code modification results generated by the source code merging request in that development phase. By comparing the generated patches with the actual patches, the candidate execution trajectory can be objectively evaluated from the code modification perspective, rather than judging its validity solely based on task descriptions, text responses, or execution completion status.

[0119] In a preferred embodiment, step S4 specifically includes:

[0120] Step S401: Obtain the set of generated modified files corresponding to the generated patch and the set of real modified files corresponding to the real patch, and determine the file hit score based on the set of generated modified files and the set of real modified files.

[0121] In this step, generated patches in the candidate execution trajectory can be analyzed to extract a set of generated modified files, and real patches recorded in the phased tasks can be analyzed to extract a set of real modified files. The set of generated modified files represents the range of files actually modified by the task execution agent after the task input in the execution phase, while the set of real modified files represents the range of files actually modified by the source code merging request in the corresponding development phase. A file hit score can be determined based on the degree of overlap between the generated modified file set and the real modified file set to measure whether the generated patch hits the files or modules actually involved in the current development phase. Preferably, the file hit score can be calculated using the following formula:

[0122]

[0123] in, This indicates the file hit score; This indicates the set of modified files involved in generating the patch; This represents the actual set of modified files involved in a real patch.

[0124] The higher the overlap between the generated set of modified files and the actual set of modified files, the higher the file hit score; if the generated patch mainly modifies files unrelated to the actual patch, the lower the file hit score.

[0125] Step S402: Determine the editing coverage score based on the editing fragment matching results between the generated patch and the real patch.

[0126] In this step, key edit fragments can be extracted from the real patch, and it can be determined whether the generated patch covers these key edit fragments. Key edit fragments may include modified functions, modified code blocks, modified configuration items, modified test assertions, modified line intervals, or other fragments that can characterize the key edit locations in the real patch. The edit fragments in the generated patch can be matched with the key edit fragments in the real patch, and an edit coverage score can be determined based on the matching results to measure whether the generated patch covers the key modification locations in the real patch. Preferably, the edit coverage score can be calculated using the following formula:

[0127]

[0128] in, This indicates the edit coverage score; This indicates the number of segments in the generated patch that match the key edit segments of the actual patch; This indicates the total number of critical edit segments in the actual patch.

[0129] If the generated patch covers the main modified functions, key code blocks, or test assertions in the real patch, the edit coverage score is high; if the generated patch modifies the same file but does not cover the key edit locations in the real patch, the edit coverage score is low.

[0130] Step S403: Determine the logical consistency score based on the matching results of the core logic changes between the generated patch and the real patch.

[0131] In this step, core logic changes can be extracted from the real patch, and it can be determined whether there are any logic changes in the generated patch that are consistent with or match the core logic changes. Core logic changes can be obtained through one or more of the following methods: function name or method name level differences, conditional branch modifications, parameter or return value changes, exception handling logic, and test case assertion changes. For example, when adding null value checks, modifying exception handling branches, adjusting function return values, or supplementing test assertions in the real patch, all of the above can be considered core logic changes. Preferably, the logic consistency score can be calculated using the following formula:

[0132]

[0133] in, This represents the logical consistency score; This indicates the number of differences in the generated patch that are consistent with the core logic changes in the actual patch. This indicates the total number of core logic changes in the actual patch.

[0134] If the generated patch is not exactly the same as the real patch in terms of code form, but implements the same or similar core logic changes, it can obtain a higher logic consistency score; if the generated patch does not implement the key logic reflected in the real patch, the logic consistency score will be lower.

[0135] Step S404: Determine the structural similarity score based on the structural matching results between the generated patch and the real patch.

[0136] In this step, the similarity in organizational structure between the generated patch and the real patch can be compared to determine the structural similarity score. The structural differences can include the difference blocks in the patch, the order of modification blocks, line-level difference patterns, contextual line distribution, the distribution of modification locations within the same file, or the patch organization format. The difference blocks in the generated patch can be matched with the difference blocks in the real patch, and the structural similarity score can be determined based on the matching results. Preferably, the structural similarity score can be calculated using the following formula:

[0137]

[0138] in, Indicates the structural similarity score; This indicates the number of difference blocks in the generated patch that match the actual patch; This indicates the total number of difference blocks in the actual patch.

[0139] If the generated patch is similar to the real patch in terms of the location of the difference block, the organization of the modified block, or the row-level difference pattern, the structural similarity score will be high. In another implementation, the structural similarity score can also be calculated using edit distance, longest common subsequence similarity, or row-level difference pattern similarity.

[0140] Step S405: Based on the file hit score, edit coverage score, logical consistency score, and structural similarity score, obtain the stage evaluation score of the generated patch relative to the real patch.

[0141] In this step, the file hit rate score, edit coverage score, logical consistency score, and structural similarity score can be normalized and then weighted and fused based on the weight parameters corresponding to each score to obtain the stage evaluation score of the generated patch relative to the real patch. The stage evaluation score is used to characterize the degree to which the generated patch in the candidate execution trajectory reproduces the real patch in the current development stage, and its value range can be 0 to 1. Preferably, the stage evaluation score can be calculated according to the following formula:

[0142]

[0143] in, Indicates the stage evaluation score; This indicates the file hit score; This indicates the edit coverage score; This represents the logical consistency score; Indicates the structural similarity score; , , and These represent the corresponding weight parameters.

[0144] In one alternative implementation, the weight parameters can satisfy the following relationship:

[0145]

[0146] in, , , and The value can be between 0 and 1.

[0147] In the solution provided in this embodiment, through steps S401 to S405, the generated patch can be comprehensively evaluated from dimensions such as the scope of modified files, key edited segments, core logic changes, and patch difference structure, using a real patch as an objective reference, to obtain a stage evaluation score. This avoids evaluating candidate execution trajectories solely based on execution completion status or single file hit results, allowing the evaluation results to more accurately reflect the degree to which the generated patch reproduces the modifications made during the actual development phase, thereby improving the objectivity and verifiability of candidate execution trajectory selection.

[0148] Step S5: Filter candidate execution trajectories based on stage evaluation scores, and convert candidate execution trajectories that meet preset filtering conditions into target data format to generate software development data.

[0149] In this step, candidate execution trajectories corresponding to each staged task can be filtered based on the stage evaluation scores obtained in step S4. Specifically, the stage evaluation scores of candidate execution trajectories can be compared with preset filtering thresholds. When the stage evaluation score is greater than or equal to the preset filtering threshold, the candidate execution trajectory is determined to meet the preset filtering conditions and is used as the target execution trajectory. When the stage evaluation score is less than the preset filtering threshold, the candidate execution trajectory can be marked as failed, pending retry, or pending review. The preset filtering threshold can be set according to data quality requirements, task type, repository type, or manual annotation results. For example, it can be set to 0.8 to filter out candidate execution trajectories that have high consistency with the actual patch in terms of modified files, key edit segments, core logic changes, and patch structure.

[0150] In one implementation, the candidate execution trajectory can also be filtered based on its stage completion status. For example, a candidate execution trajectory with a stage completion status of "completed" and a stage evaluation score that meets a preset screening threshold can be identified as a target execution trajectory that passes the screening. For candidate execution trajectories with a stage completion status of "failed," "interrupted," or "timed out," they can be written into a failed trajectory set, a retry set, or a manual review set based on runtime logs, tool call information, and interaction process information. It should be noted that the stage completion status is used to characterize whether the task execution process is complete, while the stage evaluation score is used to characterize the degree of reproducibility of the generated patch relative to the real patch. Both can be used together to determine whether a candidate execution trajectory is suitable as a valid sample of software development data.

[0151] After identifying candidate execution paths that meet the preset screening criteria, the data of these candidate execution paths can be organized and standardized. Specifically, the stage inputs, interaction process information, tool call information, generated patches, stage completion status, runtime logs, and stage evaluation scores in the candidate execution paths can be structured and the corresponding metadata can be retained. Metadata may include one or more of the following: code repository identifier, code repository name, code repository evolution chain identifier, stage identifier, stage sequence number, source code merge request number, repository version before execution, repository version after execution, scope of changed files, actual patch identifier, path identifier, and stage evaluation score. By retaining the above metadata, the generated software development data can be traced back to the corresponding code repository, code merge request, code repository evolution chain, development stage, and evaluation results, thereby improving data traceability and auditability.

[0152] Furthermore, the filtered execution trajectories can be converted into target data formats. The target data format can be set according to subsequent application scenarios such as model training, model evaluation, or process analysis. For example, it can include one or more of the following: conversational training data format, instruction response data format, and structured table data format. Specifically, the conversational training data format organizes system prompts from the task execution agent, stage task inputs, interaction process information, tool call information, tool return information, and the final patch answer into a multi-turn message sequence; the instruction response data format uses stage task inputs as instruction content and generated patches, repair results, or execution results as response content; the structured table data format organizes stage identifiers, evolution chain identifiers, code repository identifiers, trajectory identifiers, stage task inputs, generated patches, real patches, stage evaluation scores, stage completion status, and running logs into structured fields. The above target data formats can be stored and exported using file encapsulation formats such as JSON, JSONL, or Parquet.

[0153] During the conversion process, the message content and process information in the execution trajectory can be standardized. Standardization can include unifying message role fields, cleaning irrelevant logs, structurally splitting tool call results, standardizing patch content into a unified difference format, replacing temporary path or environment variable identifiers, and supplementing stage labels, code repository labels, task type labels, and evaluation labels. For example, when generating conversational training data, system prompts from the task execution agent, stage task inputs, tool calls, tool returns, and final patch answers can be converted into message arrays, and the generated patch, real patch, stage evaluation score, stage identifier, code repository evolution chain identifier, code repository identifier, and trajectory identifier can be written into metadata fields. Through the above processing, the converted software development data can meet the input format requirements of subsequent training or evaluation systems while preserving the correspondence between stage tasks, execution processes, patch results, and evaluation results.

[0154] When generating software development data, it's possible to simultaneously retain stage task inputs, interaction process information, tool call information, generated patches, stage completion status, runtime logs, and real patches. In this way, real patches can serve as truth benchmarks for generated patches, used to evaluate the execution effectiveness of candidate execution trajectories; interaction process information and tool call information can be converted into conversational training samples, tool call samples, or process supervision samples; and stage completion status and runtime logs can be used for failure analysis, audit tracing, and sample quality management. Therefore, the generated software development data not only includes code modification results but also retains the task execution process and real evaluation evidence, thereby enhancing the data's utilization value in model training, model evaluation, and process analysis scenarios.

[0155] In a preferred embodiment, the pass status, fail status, retry status, or review status of each candidate execution trajectory can be determined based on the stage evaluation score, stage completion status, patch generation status, and manual review results, thereby forming a complete data synthesis product. The data synthesis product may include one or more of the following: code repository evolution chain file, staged task file, execution trajectory file, evaluation report file, message file converted from training format, and structured data files stored in encapsulation formats such as JSON, JSONL, or Parquet. The code repository evolution chain file records the relationship identification results and link construction results between code merge requests; the staged task file records the stage task generation results obtained by mapping the code repository evolution chain, including stage order, stage dependencies, repository version before execution, repository version after execution, scope of changed files, and stage task input; the execution trajectory file records the process records obtained by executing stage task inputs on the corresponding repository version, including stage input, interaction process information, tool call information, generated patch, stage completion status, and running log; the evaluation report file records the comparison results between the generated patch and the real patch, the evaluation scores of each sub-item, and the stage evaluation score; and the message file after training format conversion records the input and output message sequences, tool call fragments, generated patches, real patches, and metadata records extracted and standardized from the selected execution trajectories, which can be used to construct supervised training samples, process supervision samples, or evaluation input samples. The system can also export relationship files, failed relationship files, and manual review queue files based on the screening and review results. The relationship files are used to retain relationship records that have been received or manually confirmed. The failed relationship files are used to retain relationship records that have been rejected, records of stages that have failed the evaluation, or abnormal trajectory records of missing patches. The manual review queue files are used to retain relationships to be reviewed, stages to be reviewed, and corresponding evidence summaries, scoring results, and review statuses for subsequent manual review and quality tracking.

[0156] Through the above processing, candidate execution trajectories can be screened for quality based on stage evaluation scores. The screened trajectories are then converted into target data formats that meet the requirements of model training, evaluation, or process analysis, while retaining data products such as the code repository evolution chain, stage tasks, execution trajectories, patch evaluations, and review records. Therefore, the aforementioned steps can generate trainable, measurable, and auditable software development data in a closed loop from the original code repository development process data, improving the quality controllability, traceability, and subsequent utilization value of the generated software development data.

[0157] In summary, this embodiment provides a software development data synthesis method based on the code repository evolution process. By converting development process data with code merge requests in the code repository into structured development records, and determining the evolutionary relationships between code merge requests based on multiple structured development records, a code repository evolution chain is constructed. This ensures that the generated software development data no longer relies on manually assumed task chains or isolated single code change samples, but rather retains the contextual continuity, iterative repair relationships, and target continuity relationships between multiple development stages in the real code repository. Furthermore, by mapping the structured development records in the code repository evolution chain to staged tasks, and executing the stage task input on the repository version corresponding to each staged task, it is possible to... This ensures that the input of each stage task matches the corresponding code state, thereby generating candidate execution trajectories with a real version context. Simultaneously, by using real patches corresponding to each stage task as evaluation criteria, the generated patches in the candidate execution trajectories are evaluated. After filtering candidate execution trajectories based on stage evaluation scores, they are converted into target data format. This forms a closed-loop processing process from identifying real repository evolution relationships, executing stage tasks, evaluating real patches, to generating software development data. This improves the reproducibility, verifiability, and quality control of software development data, making the final generated software development data closer to real software development scenarios, and suitable for applications such as software engineering model training, software development agent construction, and code repair evaluation.

[0158] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0159] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0160] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a software development data synthesis method based on code repository evolution as provided in any one or more of the above embodiments. Figure 2An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0161] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 2 Taking the example of a connection between China and Israel via a bus.

[0162] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0163] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0164] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a software development data synthesis method based on code repository evolution provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more computer-readable instructions.

[0165] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0166] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0167] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0168] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0169] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0170] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0171] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0172] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of 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, may 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.

[0173] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used only to distinguish descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0174] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for synthesizing software development data based on the evolution process of a code repository, characterized in that, include: Obtain development process data with code merge requests from the code repository, and convert the development process data into structured development records; The evolutionary relationship between code merge requests is determined based on multiple structured development records, and a link is constructed on multiple structured development records according to the evolutionary relationship to obtain the code repository evolution chain; Multiple structured development records in the code repository evolution chain are mapped to corresponding staged tasks, wherein each staged task includes the repository version of the corresponding development stage, the stage task input, and the actual patch; and the corresponding stage task input is executed on the repository version of each staged task to generate candidate execution trajectories. Based on the real patches corresponding to each staged task, the generated patches in the candidate execution trajectory are evaluated to obtain the stage evaluation score. The candidate execution trajectories are filtered based on the stage evaluation scores, and the candidate execution trajectories that meet the preset filtering conditions are converted into target data format to generate software development data.

2. The software development data synthesis method based on code repository evolution process according to claim 1, characterized in that, The step of determining the evolutionary relationship between code merge requests based on multiple structured development records includes: Based on multiple structured development records, multiple code merge request pairs to be identified are determined, wherein each code merge request pair contains two code merge requests belonging to the same code repository; Determine the creation time difference between two code merge requests in each code merge request pair, and generate candidate relationship records when the creation time difference meets a preset time window and triggers at least one relationship source strategy; wherein, the candidate relationship record includes the triggered relationship source strategy and the corresponding relationship evidence information, and the relationship source strategy includes at least one of timeline association strategy, submission connection strategy, target association strategy, file overlap strategy and content reference strategy; The relationship source strategy and relationship evidence information recorded in the candidate relationship records are quantitatively scored, and the target relationship records are selected from the candidate relationship records based on the scoring results to determine the evolutionary relationship between the code merge requests.

3. The software development data synthesis method based on code repository evolution process according to claim 2, characterized in that, The step of quantifying and scoring the relationship source strategies and relationship evidence information recorded in the candidate relationship records, and filtering out the target relationship records from the candidate relationship records based on the scoring results, includes: Based on the relationship source strategy and relationship evidence information recorded in the candidate relationship records, at least one score corresponding to the candidate relationship records is calculated, wherein the score includes at least one of the following: content reference score, target association score, submission connection score, file overlap score, and time proximity score; The scores are normalized and then weighted and fused based on the preset weights corresponding to each score to obtain the total quantified score. If the total quantified score is greater than or equal to a first preset threshold, the candidate relationship record is determined as the target relationship record; If the total quantitative score is less than the first preset threshold but greater than or equal to the second preset threshold, the candidate relationship record is transferred to the review process, and the review result determines whether the candidate relationship record is used as the target relationship record.

4. The software development data synthesis method based on code repository evolution process according to claim 2 or 3, characterized in that, The step of constructing a link between multiple structured development records based on the evolutionary relationship to obtain a code repository evolution chain includes: Based on the code merge request pair identifier, multiple target relationship records pointing to the same code merge request pair are aggregated to obtain a merged relationship record; The maximum value among the total quantitative scores of each target relationship record is determined as the fusion relationship score of the fusion relationship record, and the final relationship status of the fusion relationship record is determined based on the automatic filtering results and review results of each target relationship record. The fusion relationship record whose final relationship state satisfies the preset construction chain condition is determined as the final relationship record, and a final relationship record set consisting of multiple final relationship records is formed; Based on the set of final relationship records, within the same code repository, multiple structured development records are connected according to the time order, fusion relationship score, and dependency connectivity of each final relationship record, and the code repository evolution chain is obtained according to the preset chain length constraint.

5. The software development data synthesis method based on code repository evolution process according to claim 1, characterized in that, include: The step of mapping multiple structured development records in the code repository evolution chain to corresponding staged tasks includes: Based on the link order of each structured development record in the code repository evolution chain, determine the stage order information and stage dependency relationship corresponding to each structured development record; Based on the repository version information, changed file scope information, and patch information in each of the structured development records, the repository version before execution, the repository version after execution, the changed file scope, and the actual patch are determined for the corresponding phased tasks. Based on the development description information in each of the structured development records and the scope of the change files, generate stage task inputs that match the patch scope of the corresponding development stage; Based on the stage sequence information, stage dependencies, the repository version before execution, the repository version after execution, the scope of changed files, the stage task input, and the actual patch, a staged task corresponding to each of the structured development records is generated.

6. The software development data synthesis method based on code repository evolution process according to claim 1 or 5, characterized in that, The step of executing the corresponding stage task input on the repository version of each staged task to generate candidate execution trajectories includes: Based on the pre-execution repository version in each of the phased tasks, construct a repository workspace that matches the corresponding development phase; The corresponding stage task input is executed in the repository workspace to generate the corresponding development stage patch and record the execution process information. The execution process information includes one or more of the following: stage input, interaction process information, tool call information, stage completion status, and running log. The candidate execution trajectory is generated based on the generated patch and the execution process information.

7. The software development data synthesis method based on code repository evolution process according to claim 1, characterized in that, The step of evaluating the generated patches in the candidate execution trajectory based on the real patches corresponding to each staged task to obtain a stage evaluation score includes: Obtain the set of generated modified files corresponding to the generated patch and the set of real modified files corresponding to the real patch, and determine the file hit score based on the set of generated modified files and the set of real modified files; Based on the matching results of the edited fragments between the generated patch and the real patch, the edit coverage score is determined; Based on the matching results of the core logic changes between the generated patch and the real patch, a logic consistency score is determined. Based on the structural matching results between the generated patch and the real patch, a structural similarity score is determined. Based on the file hit score, the edit coverage score, the logical consistency score, and the structural similarity score, the stage evaluation score of the generated patch relative to the real patch is obtained.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the software development data synthesis method based on the code repository evolution process as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the software development data synthesis method based on the code repository evolution process as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the software development data synthesis method based on the code repository evolution process as described in any one of claims 1-7.

Images