Method, device and medium for large-scale code change analysis based on multi-batch processing
By dividing code change data into multiple analysis batches and combining large language models and source code verification, the context window limitation problem in large-scale code change analysis is solved, and automated intelligent analysis of semantic integrity and cross-file correlation is achieved, generating efficient and reliable global code change analysis reports.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SWIFTPASS TECH CO LTD
- Filing Date
- 2026-02-11
- Publication Date
- 2026-06-02
Smart Images

Figure CN122132272A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method, device and medium for large-scale code change analysis based on multi-batch processing. Background Technology
[0002] In software development, using version control systems (such as Git) to manage code changes is a common practice. Tools like Git Diff can reveal the specific changes introduced by code commits. Furthermore, as large language models demonstrate powerful capabilities in code understanding and analysis, utilizing them for automated and intelligent review of code changes has become an important technological direction. Existing technical solutions mainly have two typical implementation paths.
[0003] The first type is the full-scale review approach, which takes all code changes involved in a single commit as input and submits it to an AI model for one-time analysis. While this method preserves the complete change context, its processing capacity is entirely limited by the inherent context window length of the AI model. When the scale of code changes is large and involves numerous files, the input content is very likely to exceed the model's single-time processing limit, leading to analysis task failure or a significant decrease in output quality, making it unsuitable for analyzing large-scale code changes.
[0004] Furthermore, to circumvent the limitations of context windows, a second type of fragmented review scheme has emerged. This type of scheme breaks down the entire change set into smaller units for processing, such as analyzing each modified file independently, or mechanically splitting long difference texts into multiple segments with a fixed number of lines for separate analysis. However, this splitting method disrupts the inherent logical connections between code changes, making it impossible for AI models to understand the collaborative modification logic across files or code blocks when analyzing isolated fragments, easily overlooking errors caused by the lack of connections. Furthermore, mechanical segmentation may destroy the integrity of individual function or class definitions, leading to distorted analysis. Furthermore, the analysis results produced by this invention are multiple isolated conclusions, lacking effective overall summarization and structured integration, resulting in fragmented reports and significantly increasing the difficulty of manual integration and global understanding. Summary of the Invention
[0005] This invention provides a method, device, and medium for large-scale code change analysis based on multi-batch processing. The technical problem it aims to solve is: how to provide an effective solution that can overcome the limitations of the context window of artificial intelligence models while maintaining semantic integrity and cross-file correlation in the automated intelligent analysis of large-scale code changes.
[0006] In a first aspect, embodiments of the present invention provide a method for large-scale code change analysis based on multi-batch processing, comprising: Obtain the code change data to be analyzed; The code change data is divided into multiple analysis batches, and corresponding batch metadata is generated for each analysis batch. During the division, it is ensured that all changes to a single code file are completely allocated to the same analysis batch, and the amount of data contained in each analysis batch does not exceed a preset processing capacity threshold. For each analysis batch, based on the code change data and batch metadata of the analysis batch, a pre-trained large language model is invoked for analysis, and the preliminary analysis results output by the large language model are verified based on the source code to generate the verified analysis results of the analysis batch. Integrate the post-verification analysis results from all analysis batches, perform cross-batch data deduplication, correlation analysis, and structured summarization, and generate a global code change analysis report.
[0007] Optionally, dividing the code change data into multiple analysis batches includes: Read the file change content from the code change data sequentially; When assigning changes to the file content of the current analysis batch, perform the first and second checks; The first determination includes: determining whether the number of files already included in the current analysis batch has reached a first preset threshold; if so, creating a new analysis batch as the current analysis batch, and allocating the file changes to be assigned to the new current analysis batch; The second judgment includes: when the first judgment does not trigger the generation of a new batch, judging whether the total number of words corresponding to all the changed content in the current analysis batch exceeds the second preset threshold after adding the file change content to be assigned; if it exceeds the threshold, a new analysis batch is created as the current analysis batch, and the file change content to be assigned is assigned to the new current analysis batch. The first preset threshold and the second preset threshold together define the processing capacity threshold.
[0008] Optionally, dividing the code change data into multiple analysis batches further includes: Before assigning file changes, identify the relationships between multiple file changes to be assigned. When performing the first and second judgments, if the judgment result allows multiple related file changes to be assigned to the same analysis batch, then the multiple related file changes will be assigned to the same analysis batch.
[0009] Optionally, generating corresponding batch metadata for each analysis batch includes: Record the path identifier of each file contained in the analysis batch; Count the total number of terms in all the changed content in the analyzed batch; Based on the file path or predefined module mapping relationship, determine and record the functional module identifier to which the analysis batch belongs.
[0010] Optionally, for each analysis batch, based on the code change data and batch metadata of the analysis batch, a pre-trained large language model is invoked for analysis, and the preliminary analysis results output by the large language model are validated based on the source code to generate the validated analysis results of the analysis batch, including: Based on the preset structured output template, construct a prompt message containing code change data for the current analysis batch; The prompt information is input into the large language model, the output returned by the large language model is received and parsed, and a preliminary analysis result conforming to the format of the structured output template is obtained. The preliminary analysis result contains at least one identified potential code problem. For each potential code problem in the preliminary analysis results, the source code repository is accessed and the corresponding actual source code content is read according to the code location information indicated by the potential code problem; The actual source code content is compared with the description of the potential code problem to verify whether the potential code problem actually exists, and the verification result is obtained. Based on the verification results, the post-verification analysis results for the current analysis batch are generated.
[0011] Optionally, the process of integrating the validation analysis results of all analysis batches, performing cross-batch data deduplication, correlation analysis, and structured summarization, and generating a global code change analysis report includes: The results of the post-validation analysis of all analysis batches are compiled; Identify and merge duplicate issue items for the same code location or the same code entity from post-validation analysis results from different analysis batches; Analyze the logical relationships between different question items, and classify or establish association markers for question items that have relationships; All question items are prioritized according to the preset sorting rules; Based on the sorted and correlated results, a global code change analysis report is generated, which includes a structured summary and a detailed list of issues.
[0012] Optionally, the global code change analysis report includes: The first report section lists the actual modified code content based on the code change data, using code files or code modules as the dimension. The second report section, based on all post-verification analysis results, lists the code issues identified after deduplication and correlation analysis, along with their potential impact analysis.
[0013] Optionally, the process of generating the second report section includes: Based on all sorted and associated issue items, a global statistical summary is generated by counting the total number of issue items, the number of issue items distributed by issue type, and the number of issue items distributed by preset severity level. All sorted and associated question items are categorized according to the functional modules corresponding to the question items, generating a detailed question list by functional module. Question items under each functional module are arranged in order of priority. The second report section is generated by integrating the global statistical summary with the detailed issue list based on functional modules.
[0014] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.
[0015] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.
[0016] This invention provides a method, device, and medium for large-scale code change analysis based on multi-batch processing. The method includes: acquiring code change data to be analyzed; dividing the code change data into multiple analysis batches and generating corresponding batch metadata for each batch, wherein the division ensures that all changes to a single code file are completely allocated to the same analysis batch, and the data volume of each analysis batch does not exceed a preset processing capacity threshold; for each analysis batch, based on the code change data and batch metadata, calling a pre-trained large language model for analysis, and performing source code-based verification on the preliminary analysis results output by the large language model to generate a verified analysis result for the analysis batch; integrating the verified analysis results of all analysis batches, performing cross-batch data deduplication, correlation analysis, and structured summarization to generate a global code change analysis report. This invention, by dividing large-scale code change data into multiple controllable-scale analysis batches based on complete files, ensures that the data volume of each batch does not exceed a processing capacity threshold, thereby technically achieving the ability to handle changes of any scale. Furthermore, based on this, each batch undergoes independent in-depth analysis and source code-based verification, ensuring the contextual relevance of the analysis process and the credibility of the results. Moreover, by deduplicating, correlating, and structurally summarizing the analysis results across all batches, a global analysis report is generated that combines a complete macro perspective with reliable detailed findings. This overcomes the shortcomings of isolated and scattered analysis conclusions, significantly improving the practicality, accuracy, and efficiency of automated code review. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a large-scale code change analysis method based on multi-batch processing, provided for an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation
[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0020] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0021] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0022] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0023] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."
[0024] Please see Figure 1 This invention provides a method for large-scale code change analysis based on multi-batch processing. The invention includes the following steps: S1, obtain the code change data to be analyzed.
[0025] In practice, the code change data to be analyzed is obtained. This invention executes a difference comparison command for two specific commits (e.g., the current commit and its parent commit) by calling the command-line interface or library functions of a version control system (e.g., Git). Further, this difference comparison command generates a standardized difference output text, which the system reads into memory or stores in a temporary file as raw input data. This difference text contains at least the paths of all modified files, and the specific lines of code added and deleted in each file.
[0026] S2, the code change data is divided into multiple analysis batches, and corresponding batch metadata is generated for each analysis batch. During the division, it is ensured that all changes to a single code file are completely allocated to the same analysis batch, and the amount of data contained in each analysis batch does not exceed a preset processing capacity threshold.
[0027] In practice, the code change data is divided into multiple analysis batches, and corresponding batch metadata is generated for each batch. Specifically, the system first parses the acquired code change data text. The parsing logic involves identifying the start markers and boundaries that represent each independent file change unit. The system scans the text line by line, and when a line that matches the preset file change start marker format is detected, it is determined as the beginning of a new file change block. The system will continue to read and collect subsequent text lines starting from this starting line until it encounters the next line that matches the file change start marker format or reaches the end of the text stream. Through this process, the system segments and identifies the complete original difference text into a series of continuous, independent file change blocks. Each block contains all the additions, deletions, or modifications made to a specific code file, thus ensuring that subsequent processing can be based on the complete changes of a single file as the basic unit.
[0028] Furthermore, the segmentation process is implemented by sequentially traversing all identified file change blocks. This process maintains a temporary storage structure for the current analysis batch. Before attempting to add a file change block to the current analysis batch, the total data volume of the batch after addition is estimated. This estimation is achieved by merging the existing content of the current batch with the content of the file change block to be added and calculating the total number of tokens. Further, if the calculated total number of tokens does not exceed a preset processing capacity threshold, the file change block is added to the current batch; if it exceeds, the current batch is marked as complete, a new empty batch is created as the current batch, and the file change block is then added to it. Furthermore, when creating each analysis batch, a corresponding batch metadata file is generated. This file records basic information such as the batch's identification information and the list of file paths it contains in a structured data format.
[0029] In some preferred embodiments, dividing the code change data into multiple analysis batches includes: sequentially reading the file change content in the code change data; when allocating file change content to the current analysis batch, performing a first judgment and a second judgment; the first judgment includes: judging whether the number of files already included in the current analysis batch has reached a first preset threshold; if it has, then creating a new analysis batch as the current analysis batch, and allocating the file change content to be allocated to the new current analysis batch; the second judgment includes: if the first judgment does not trigger the generation of a new batch, judging whether the total number of tokens corresponding to all changes in the current analysis batch after adding the file change content to be allocated exceeds a second preset threshold; if it exceeds, then creating a new analysis batch as the current analysis batch, and allocating the file change content to be allocated to the new current analysis batch; wherein, the first preset threshold and the second preset threshold together define the processing capacity threshold.
[0030] In practice, the file change content in the code change data is read sequentially. The system reads the original Git diff text line by line, uses a state machine to identify the beginning and end of the change content block for each file, and caches each complete block as an independent data object, forming a queue according to the order in which they appear in the diff file.
[0031] Furthermore, when assigning file changes to the current analysis batch, the first and second checks are performed. The system maintains two state variables for the analysis batch currently being built: the count of the number of included files and the estimated total number of tokens in the included content.
[0032] Further, the first determination includes: determining whether the number of files already included in the current analysis batch has reached a first preset threshold. Before adding a new file change content object to the current batch each time, the system checks the current file count. Further, if the count has reached the first preset threshold (e.g., set to 15), the system triggers a batch completion operation. Specifically, the data and metadata of the current batch are persistently saved, then a new empty batch is initialized, the new file count is reset to 0, and the estimated total number of terms is reset to 0. Afterwards, the file change content objects to be assigned are added to this newly created batch.
[0033] Further, the second judgment includes: when the first judgment does not trigger the generation of a new batch, determining whether the total number of lexical units corresponding to all changes in the current analysis batch exceeds a second preset threshold after adding the file change content to be assigned. Specifically, the system uses a lexer to lexically convert the text of the file change content object to be added and counts its lexical units. This value is added to the estimated total number of lexical units already in the current batch to obtain the estimated new total. The system determines whether this estimated total exceeds the second preset threshold (e.g., set to 75% of the maximum number of lexical units allowed in a single call of the large language model). If it exceeds, the batch completion operation is triggered: the current batch is saved, a new batch is created and switched to, and then the file change content object to be assigned is added to the new batch. Further, if it does not exceed, the object is added to the current batch, and the file count and estimated total number of lexical units in the current batch are updated.
[0034] It should be noted that in this embodiment, the first preset threshold and the second preset threshold together define the processing capacity threshold, constraining the batch size from two dimensions: the number of files and the text volume.
[0035] This embodiment introduces a dual-judgment mechanism based on both the number of files and the total number of lexical units, applying more refined and dynamic capacity control to the batch division process. The first judgment ensures that a single analysis batch does not contain too many files, helping to prevent the analysis focus from becoming too scattered due to excessive files. This allows the large language model to more effectively process code changes within a limited scope, improving the depth and relevance of the analysis. Furthermore, provided the number of files does not exceed the limit, the second judgment, based on the more direct metric of the total number of lexical units, prevents the input size from exceeding the model's processing capacity limit. This dual constraint mechanism works together to achieve precise control over the size of each analysis batch. It fully utilizes the processing power of the large language model while strictly ensuring that the amount of input data in each batch never exceeds its context window limit, thus fundamentally eliminating analysis failures or quality degradation caused by exceeding input limits.
[0036] In some preferred embodiments, dividing the code change data into multiple analysis batches further includes: identifying the relationship between multiple file change contents to be allocated before allocating the file change contents; when performing the first judgment and the second judgment, if the judgment result allows multiple file change contents with relationships to be allocated to the same analysis batch, then the multiple file change contents with relationships are allocated to the same analysis batch.
[0037] In practice, before allocating file change content, the system identifies the relationships between multiple file change contents to be allocated. The system can perform a preprocessing analysis after parsing the difference text and before batch processing. For example, the system analyzes the code entities involved in all file change contents (such as modified class names and function names), or determines the call or dependency relationships between files based on the code dependency graph in the project (e.g., generated by static analysis tools). It can also perform clustering analysis based on the path similarity of files in the project directory structure (e.g., belonging to the same module or subdirectory). For example, if two or more files modify classes or functions with the same name, or if these files are in the same strongly connected subgraph according to a predefined code dependency graph, the system assigns these file change content objects the same "association group" identifier. Furthermore, another approach is to consider files in the same subdirectory as having module cohesion relationships based on their position in the project directory structure.
[0038] Furthermore, when executing the first and second judgments, if the judgment result allows multiple related file change contents to be assigned to the same analysis batch, then the multiple related file change contents will be assigned to the same analysis batch. Further, when processing a file change content object A with an "associated group" identifier, the system checks whether other objects within that associated group have not yet been assigned. If there is an unassigned object B in the same group, the system will attempt a "forward-looking" judgment: estimating whether adding object A and object B to the current batch simultaneously still satisfies the first and second preset threshold constraints. If satisfied, object A and object B will be added to the current analysis batch in this loop, and the batch status will be updated accordingly. This ensures that, within the limits of capacity, logically closely related changes are retained in the same analysis context as much as possible.
[0039] This embodiment proactively shapes the semantic context within each batch by identifying the relationships between file changes before allocation and, under the condition of meeting capacity constraints, prioritizing the allocation of multiple related changes to the same analysis batch. This operation changes the mechanical nature of simple sequential allocation, giving the partitioning process a certain degree of semantic awareness and significantly enhancing the contextual relevance and cohesion of code changes within each analysis batch. When a large language model processes such a more coherent set of changes, it can more easily understand collaborative modification logic across files, such as the correspondence between interface definition changes and related implementation updates, or modifications to the same business logic scattered across different files. This greatly reduces the risk of misjudgment or missed detection of correlation errors caused by context fragmentation in the large language model, thereby improving the accuracy and completeness of batch-level analysis.
[0040] In some preferred embodiments, generating corresponding batch metadata for each analysis batch includes: recording the path identifier of each file contained in the analysis batch; counting the total number of terms in all changed content in the analysis batch; and determining and recording the functional module identifier to which the analysis batch belongs based on the file path or a predefined module mapping relationship.
[0041] In practice, the path identifier of each file included in the analysis batch is recorded. During batch processing, whenever a file change object is successfully added to an analysis batch, the system adds the source file path parsed from that object (i.e., the file path in the Git diff header) to a list array specifically maintained for that batch. This list of file paths is fully recorded when the batch is complete.
[0042] Furthermore, the total number of tokens for all changes in the analyzed batch is counted. During the batching process, the system accumulates the token count each time file changes are added to the batch. At the end of the batch, the accumulated total token count is the total number of tokens for all changes in that batch, and this value is directly recorded.
[0043] Furthermore, based on file paths or predefined module mapping relationships, the functional module identifier to which the analysis batch belongs is determined and recorded. The system is configured with a mapping rule, which can be based on path prefix matching (e.g., paths containing / src / auth / belong to the "authentication module") or a lookup table. After a batch is completed, the system iterates through the list of file paths for that batch, determining a module identifier for each file according to the mapping rule. Then, the system determines the primary functional module identifier to which the entire batch belongs by voting or selecting the most frequently occurring module identifier, and records it.
[0044] Furthermore, the three core fields—file path list, total number of tokens, and functional module identifier—are serialized into JSON objects and saved as batch metadata files for this batch. The filename can be associated with the batch ID.
[0045] This invention specifically defines the core data items that batch metadata should include, including a file path list, a total number of tokens, and functional module identifiers. A detailed file path list provides precise traceability for the entire processing flow, ensuring that any analytical conclusion can be accurately linked back to its source file, facilitating subsequent location and verification. Furthermore, counting and recording the total number of tokens provides a quantitative indicator for monitoring and optimizing the processing process; for example, it can be used to verify whether capacity thresholds are strictly adhered to, or to analyze the computational load of different batches. Furthermore, identifying and recording functional module identifiers adds a higher level of semantic organization to the analysis of code changes.
[0046] S3. For each analysis batch, based on the code change data and batch metadata of the analysis batch, call the pre-trained large language model for analysis, and perform source code-based verification on the preliminary analysis results output by the large language model to generate the verified analysis results of the analysis batch.
[0047] In practice, for each analysis batch, based on the code change data and batch metadata, a pre-trained large language model is invoked for analysis. The preliminary analysis results output by the large language model are then validated based on the source code, generating the validated analysis results for that batch. For each generated analysis batch, the system reads the code change data text it contains. The system predefines a structured prompt template, which includes system instructions (such as "Please analyze the following code changes to identify potential problems"), placeholders for the code change data, and explicit instructions requiring the large language model to output in a specified JSON format. The system fills the placeholders in the template with the code change data for the current batch, forming a complete prompt message.
[0048] Furthermore, the system sends the prompt information to a large language model service (such as OpenAI GPT-4, Anthropic Claude, etc.) via an application programming interface (API) and receives the text response returned by the model. The system parses this response, extracts data conforming to a predetermined JSON pattern, and uses this as a preliminary analysis result. This result may contain multiple question entries, each with fields such as type, description, file, and line number.
[0049] Furthermore, the system iterates through each issue entry, and based on the file path and line number information in the entry, precisely reads the actual code content of that line and its surrounding context from the corresponding version in the source code repository using version control commands (such as `git show`) or direct file access. The system then logically compares the read actual code with the issue description, for example, determining whether the indicated missing error handling actually exists, to verify the authenticity of the issue. Finally, the system generates a new structured document, the post-verification analysis results, which contains only the verified issue entries, or marks the entries that failed verification.
[0050] In some preferred embodiments, for each analysis batch, based on the code change data and batch metadata of the analysis batch, a pre-trained large language model is invoked for analysis, and the preliminary analysis results output by the large language model are verified based on source code to generate the verified analysis results of the analysis batch. This includes: constructing a prompt message containing the code change data of the current analysis batch according to a preset structured output template; inputting the prompt message into the large language model, receiving and parsing the output returned by the large language model to obtain a preliminary analysis result conforming to the format of the structured output template, wherein the preliminary analysis result contains at least one identified potential code problem; for each potential code problem in the preliminary analysis result, accessing the source code repository and reading the corresponding actual source code content according to the code location information indicated by the potential code problem; comparing the actual source code content with the description of the potential code problem to verify whether the potential code problem actually exists, and obtaining a verification result; and generating the verified analysis results of the current analysis batch based on the verification results.
[0051] In practice, based on a pre-defined structured output template, a prompt message containing code change data for the current analysis batch is constructed. The system provides a pre-defined template string, for example: "As a code review assistant, please analyze the following Git diffs to identify potential errors, code smells, or potential improvement points. Please strictly adhere to the following JSON format for output, outputting only JSON: {"issues": [{"type": "", "description": "", "file": "", "line": ,"severity": ""}]}. Difference content: {{DIFF}}". The system reads the code change data text for the current analysis batch and replaces the "{{DIFF}}" placeholder in the template, thus constructing the final prompt message string.
[0052] Further, the system inputs the prompt information into the large language model, receives and parses the output returned by the large language model, and obtains preliminary analysis results conforming to the structured output template format. The system calls the large language model's API via an HTTP request, sending a request containing the aforementioned prompt information. Upon receiving the API response, the system extracts the JSON portion from the response text. The system uses a JSON parsing library to parse the text into an in-memory data structure (such as a dictionary or list). If parsing is successful, this data structure represents the preliminary analysis result, with the "issues" list containing multiple issue dictionaries.
[0053] Furthermore, for each potential code issue in the preliminary analysis results, the system accesses the source code repository and reads the corresponding actual source code content based on the code location information indicated by the potential code issue. The system iterates through each issue dictionary in the preliminary analysis results. Further, for each issue, the `file` and `line` fields are extracted. The system constructs a read command based on the local path of the current code repository and the specified commit version. For example, the command `git show` is used. <commit-hash> : <file-path>This allows you to retrieve the complete content of a file in a specific version and then locate the line near the specified line number.
[0054] Furthermore, the actual source code content is compared with the description of the potential code problem to verify whether the potential code problem actually exists. The system logically compares the actual code lines read with the descriptions in the problem dictionary. For example, if the description is "variable not initialized," it checks whether the variable was assigned a value before its first use in that line or nearby lines. This comparison process can be based on simple pattern matching or combined with lightweight static analysis rules. The verification result is a Boolean value, indicating whether the problem exists or not.
[0055] Furthermore, based on the verification results, the system generates the post-verification analysis results for the current analysis batch. The system creates a new list, adding only the dictionary of issues with a verification result of "existence". Unverified issues can be discarded or marked as "unverified" and added to another list. Finally, the system encapsulates the filtered and marked list, along with batch IDs and other information, into a new JSON object and saves it as the post-verification analysis results for the current analysis batch.
[0056] This invention constrains the output format of large language models through preset structured output templates, guiding the originally free and unstructured natural language responses towards machine-readable, clearly defined structured data. This solves the problem that raw AI output is difficult to process programmatically, laying the foundation for subsequent automatic aggregation. Furthermore, it introduces an active verification step based on source code. For each potential problem pointed out by the model, the system retrieves the actual code content from the source code repository based on the location information in the problem description for comparison and verification. This step constructs a "AI hypothesis-fact check" verification closed loop, greatly improving the credibility and practicality of the final analysis results. It effectively filters out common illusion problems in large language models—false alarms that seem reasonable in description but do not actually exist in the code—thus significantly reducing the false alarm rate. Furthermore, for genuine problems, the credibility of the report is also enhanced after comparison with the source code.
[0057] S4 integrates the post-verification analysis results of all analysis batches, performs cross-batch data deduplication, correlation analysis, and structured summarization, and generates a global code change analysis report.
[0058] In practice, the system integrates the post-verification analysis results from all analysis batches, performs cross-batch data deduplication, correlation analysis, and structured summarization, and generates a global code change analysis report. The system reads the post-verification analysis results produced by all analysis batches. The system first performs deduplication: it compares the core characteristics of all issue entries (such as file path, line number, and issue type), merges entries with the same or highly similar characteristics into one item, and records whether it was discovered by multiple batches.
[0059] Furthermore, the system performs association analysis: analyzing the semantic or logical relationships between problem items, such as calling relationship diagrams or co-occurring keywords through code, grouping problem items that belong to the same root cause of modification or have an influence chain relationship, and establishing association identifiers.
[0060] Furthermore, the system sorts all unique issue entries according to preset rules (such as issue severity level and the criticality of the modules involved). Finally, following a report template, the system organizes the deduplicated, correlated, and sorted issue list, along with generated global statistics (such as total number of issues and distribution of each type), into a complete and readable global code change analysis report document, and outputs it.
[0061] In some preferred embodiments, the process of integrating the post-verification analysis results of all analysis batches, performing cross-batch data deduplication, correlation analysis, and structured summarization to generate a global code change analysis report includes: collecting the post-verification analysis results of all analysis batches; identifying and merging duplicate issue items from different analysis batches that target the same code location or the same code entity; analyzing the logical relationships between different issue items, classifying or establishing association markers for issue items with relationships; prioritizing all issue items according to preset sorting rules; and generating a global code change analysis report containing a structured summary and a detailed list of issues based on the sorting and association results.
[0062] In practice, the system aggregates the post-verification analysis results from all analysis batches. It scans the directory storing the post-verification analysis results, reads all files conforming to the naming rules, loads the problem list data from each file into memory, and merges them into a large temporary list of problem entries.
[0063] Furthermore, the system identifies and merges duplicate issue entries targeting the same code location or entity from post-verification analysis results from different analysis batches. The system iterates through each issue entry A in the temporary list. For A, the system searches the list for other issue entries B such that A and B have the same file path, the same or similar line number (e.g., within the same function), and their issue type and description semantic similarity exceed a threshold. When such a B is found, the system merges A and B into a new issue entry C. C may retain the description of A and record in its metadata that the issue was discovered simultaneously by batches X and Y, thus removing duplicates.
[0064] Furthermore, the logical relationships between different problem items are analyzed, and related problem items are categorized or associated with each other. The system then analyzes the deduplicated problem list. For example, by analyzing the function names, class names, or variable names mentioned in the problem entries, a co-occurrence graph is constructed. Alternatively, based on predefined problem category rules (such as all problems related to "null pointer"), problem items with strong connectivity or conforming to the same rule in the graph are assigned the same "association group ID," or reference IDs pointing to other related problems are added to their metadata.
[0065] Furthermore, according to preset sorting rules, all issue items are prioritized. The system calculates a priority score for each issue item. The score calculation rules are configurable, for example: "high risk" issues receive 3 points, "medium risk" issues receive 2 points, and "low risk" issues receive 1 point; issues involving core modules receive an additional 2 points. Further, the system sorts all issue items in descending order based on these scores.
[0066] Furthermore, based on the sorted and grouped results, a global code change analysis report containing a structured summary and a detailed issue list is generated. The system creates a report document. First, a structured summary is generated based on the sorted issue list, including the total number of issues, the number of issues at each severity level, and the issue distribution across modules. Then, the sorted and grouped issue list is presented in detail, displaying the description, location, severity, and associated group information for each issue. The summary and detailed list together constitute the main body of the report and are output as HTML, Markdown, or PDF files.
[0067] This invention systematically processes scattered post-verification analysis results through a series of operations including aggregation, deduplication, correlation, and sorting. Aggregation ensures the integrity of the analysis scope, omitting information from any batch. Deduplication solves the report redundancy problem caused by the same issue being repeatedly identified in different batches, resulting in a concise and clear final report. Correlation analysis aims to uncover potential logical connections between different issue items, such as linking causes and effects, or multiple related issues triggered by the same modification. This restores and strengthens cross-file logical connections that may have been fragmented during the batching phase. Furthermore, the sorting operation prioritizes all issues according to preset rules (such as severity), guiding users to focus on key issues.
[0068] In some preferred embodiments, the global code change analysis report includes: a first report section, which lists the actual modified code content based on the code change data, with code files or code modules as the dimension; and a second report section, which lists the code problems and potential impact analyses confirmed after deduplication and correlation analysis, based on all verified analysis results.
[0069] In practice, the generation process of the first report section is as follows: The system directly processes the initial raw Git difference data. It parses the difference data and lists all modified files by file path. For each file, it calculates and displays the number of lines of code added and deleted. Furthermore, it extracts the changed code blocks (hunks) for each file and displays them with syntax highlighting, forming a pure "code change list." This part is completely objective and originates from the version control system's output.
[0070] Furthermore, the generation process for the second report section is as follows: The system takes the aforementioned final issue list (i.e., the list after deduplication, association, and sorting) as input. All issue entries in this list are then formatted and presented according to their order and grouping structure in the final list. For example, a global statistical summary can be displayed first, followed by a list of each issue in priority order, including its type, description, file location, severity, and associated group information. This part is based on subjective review opinions and inferences generated after AI analysis and automated verification.
[0071] Furthermore, in the final global code change analysis report, the first and second report sections are clearly distinguished and arranged as two independent chapters or sections. For example, the report could begin with "Part One: Overview of Code Changes," followed by "Part Two: Issues and Recommendations Found During the Review." This structure ensures the separation of factual statements from analytical opinions.
[0072] In this embodiment of the invention, the first report section directly originates from the discrepancy data generated by the version control system. It objectively and unambiguously lists all the specific changes that actually occurred, forming the factual basis for the analysis. The second report section, based on all the review conclusions derived after the aforementioned multi-step processing (analysis, verification, and summarization), lists the confirmed code issues and their potential impacts. This structured report design achieves a clear separation and parallel presentation of objective facts and subjective analysis. Furthermore, users can quickly and accurately grasp from the first report section which code was modified in this submission, serving as the benchmark for all subsequent discussions. Furthermore, users can obtain intelligent review opinions from the second report section after in-depth AI analysis and automated verification.
[0073] In some preferred embodiments, the generation process of the second report portion includes: generating a global statistical summary based on all sorted and associated issue items, counting the total number of issue items, the number of issues distributed by issue type, and the number of issues distributed by preset severity level; classifying all sorted and associated issue items according to the functional modules corresponding to the issue items, generating a detailed issue list by functional module, wherein issue items under each functional module are arranged in priority order; and integrating the global statistical summary with the detailed issue list by functional module to generate the second report portion.
[0074] In practice, based on all sorted and associated issue items, a global statistical summary is generated by counting the total number of issue items, the number of issues distributed by issue type, and the number of issues distributed by preset severity levels. The system iterates through the final issue list. The total number of issues is obtained by counting the length of the list. Based on the "type" field in each issue item, the number of occurrences of each issue type (e.g., "security vulnerability", "performance bottleneck", "code smell") is counted. Based on the "severity" field in each issue item, the number of occurrences of each severity level (e.g., "high", "medium", "low") is counted. These statistical results are then used to generate a text or data object in the form of a table or chart summary, serving as the global statistical summary.
[0075] Furthermore, all sorted and associated issue items are categorized according to their corresponding functional modules, generating a detailed issue list by functional module. The system determines the functional module to which each issue item belongs. This can be achieved by querying the module identifier corresponding to the file path where the issue item is located. This identifier may already exist in the batch metadata or be calculated in real time according to the same path mapping rules. Then, the system groups the issue items into different sets using the functional module identifier as the key. Within each functional module set, the issue items still maintain a global priority order. Further, the system generates a sub-section for each module according to a certain order of modules (such as alphabetical order of module names or descending order of the number of issues in the module), and lists all issue items belonging to that module and their detailed information in order within the sub-section.
[0076] Furthermore, the global statistical summary is integrated with the detailed issue list organized by functional module to generate the global code change analysis report. When writing the final report, the system first uses the global statistical summary as the opening section of the second part of the report. Following the summary, detailed issue lists for each functional module are presented sequentially. Each module section can have its own subheading (e.g., "Module: User Authentication") and may include a brief statistical summary of the issues within that module. Thus, the second part of the report forms a clear structure from a global overview to detailed content organized by module. This structure, together with the first part of the report, constitutes the complete global code change analysis report.
[0077] In this embodiment of the invention, a global-level statistical analysis of the quantity and type of all confirmed issues is performed to generate a high-level statistical summary. This provides users with a quick overview of the overall quality and risk distribution of the change. Furthermore, based on the correspondence between issue items and functional modules, all issue items are categorized and grouped into their respective modules, maintaining priority within each module. This generates a detailed issue list based on functional modules, enabling the final second report to possess multi-level expressive capabilities, from macro-level statistics to micro-level lists, and from a global overview to a module-focused approach. The global statistical summary meets the needs of senior managers or architects to quickly grasp the overall situation. The detailed list organized by functional modules greatly facilitates targeted processing by specific development teams or module leaders, allowing them to directly locate the issue set relevant to their assigned module without repeatedly filtering through the full report.
[0078] Please see Figure 2 , Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.
[0079] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.
[0080] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to perform a large-scale code change analysis method based on multi-batch processing.
[0081] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.
[0082] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a large-scale code change analysis method based on multi-batch processing.
[0083] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.
[0084] The processor 502 is used to run a computer program 5032 stored in the memory to implement the steps of a large-scale code change analysis method based on multi-batch processing provided in any of the above method embodiments.
[0085] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.
[0086] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.
[0087] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform the steps of a large-scale code change analysis method based on multi-batch processing provided in any of the above method embodiments.
[0088] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.
[0089] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0090] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other specific division methods in practice. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
[0091] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0094] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.
[0095] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims. < / commit-hash>
Claims
1. A method for large-scale code change analysis based on multi-batch processing, characterized in that, include: Obtain the code change data to be analyzed; The code change data is divided into multiple analysis batches, and corresponding batch metadata is generated for each analysis batch. During the division, it is ensured that all changes to a single code file are completely allocated to the same analysis batch, and the amount of data contained in each analysis batch does not exceed a preset processing capacity threshold. For each analysis batch, based on the code change data and batch metadata of the analysis batch, a pre-trained large language model is invoked for analysis, and the preliminary analysis results output by the large language model are verified based on the source code to generate the verified analysis results of the analysis batch. Integrate the post-verification analysis results from all analysis batches, perform cross-batch data deduplication, correlation analysis, and structured summarization, and generate a global code change analysis report.
2. The method for large-scale code change analysis based on multi-batch processing according to claim 1, characterized in that, The step of dividing the code change data into multiple analysis batches includes: Read the file change content from the code change data sequentially; When assigning changes to the file content of the current analysis batch, perform the first and second checks; The first determination includes: determining whether the number of files already included in the current analysis batch has reached a first preset threshold; if so, creating a new analysis batch as the current analysis batch, and allocating the file changes to be assigned to the new current analysis batch; The second judgment includes: when the first judgment does not trigger the generation of a new batch, judging whether the total number of words corresponding to all the changed content in the current analysis batch exceeds the second preset threshold after adding the file change content to be assigned; if it exceeds the threshold, a new analysis batch is created as the current analysis batch, and the file change content to be assigned is assigned to the new current analysis batch. The first preset threshold and the second preset threshold together define the processing capacity threshold.
3. The method for large-scale code change analysis based on multi-batch processing according to claim 2, characterized in that, The step of dividing the code change data into multiple analysis batches also includes: Before assigning file changes, identify the relationships between multiple file changes to be assigned. When performing the first and second judgments, if the judgment result allows multiple related file changes to be assigned to the same analysis batch, then the multiple related file changes will be assigned to the same analysis batch.
4. The method for large-scale code change analysis based on multi-batch processing according to claim 1, characterized in that, The process of generating corresponding batch metadata for each analysis batch includes: Record the path identifier of each file contained in the analysis batch; Count the total number of terms in all the changed content in the analyzed batch; Based on the file path or predefined module mapping relationship, determine and record the functional module identifier to which the analysis batch belongs.
5. The method for large-scale code change analysis based on multi-batch processing according to claim 1, characterized in that, For each analysis batch, based on the code change data and batch metadata of the analysis batch, a pre-trained large language model is invoked for analysis, and the preliminary analysis results output by the large language model are verified based on the source code to generate the verified analysis results of the analysis batch, including: Based on the preset structured output template, construct a prompt message containing code change data for the current analysis batch; The prompt information is input into the large language model, the output returned by the large language model is received and parsed, and a preliminary analysis result conforming to the format of the structured output template is obtained. The preliminary analysis result contains at least one identified potential code problem. For each potential code problem in the preliminary analysis results, the source code repository is accessed and the corresponding actual source code content is read according to the code location information indicated by the potential code problem; The actual source code content is compared with the description of the potential code problem to verify whether the potential code problem actually exists, and the verification result is obtained. Based on the verification results, the post-verification analysis results for the current analysis batch are generated.
6. The method for large-scale code change analysis based on multi-batch processing according to claim 1, characterized in that, The integrated analysis results from all analysis batches are then used to perform cross-batch data deduplication, correlation analysis, and structured summarization to generate a global code change analysis report, including: The results of the post-validation analysis of all analysis batches are compiled; Identify and merge duplicate issue items for the same code location or the same code entity from post-validation analysis results from different analysis batches; Analyze the logical relationships between different question items, and classify or establish association markers for question items that have relationships; All question items are prioritized according to the preset sorting rules; Based on the sorted and correlated results, a global code change analysis report is generated, which includes a structured summary and a detailed list of issues.
7. The method for large-scale code change analysis based on multi-batch processing according to claim 6, characterized in that, The global code change analysis report includes: The first report section lists the actual modified code content based on the code change data, using code files or code modules as the dimension. The second report section, based on all post-verification analysis results, lists the code issues identified after deduplication and correlation analysis, along with their potential impact analysis.
8. The method for large-scale code change analysis based on multi-batch processing according to claim 7, characterized in that, The generation process of the second report section includes: Based on all sorted and associated issue items, a global statistical summary is generated by counting the total number of issue items, the number of issue items distributed by issue type, and the number of issue items distributed by preset severity level. All sorted and associated question items are categorized according to the functional modules corresponding to the question items, generating a detailed question list by functional module. Question items under each functional module are arranged in order of priority. The second report section is generated by integrating the global statistical summary with the detailed issue list based on functional modules.
9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-8.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.