Code review auxiliary method and system based on large model

Abstract

The invention discloses a code review assisting method and system based on a large model. The system is in butt joint with a code review platform, and after a patch set change event is received, codes are detected out and engineering snapshots are constructed. And the LLM agent interacts with the large language model, calls an LSP client to obtain diagnosis and call chain information when static analysis is needed, and feeds an observation result back to the model to generate an examination conclusion. And when the LSP returns an error, a negative feedback mechanism is triggered, the model is guided to correct parameters and symbols, and illusion is reduced. And the review conclusion is converted into comments and automatically published to the platform, so that high-risk change automatic identification is realized, the manual workload is reduced and the accuracy is improved.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and particularly relates to the field of software development and code review technology, specifically to a code review assistance method and system based on a large model. Background Technology

[0002] As software scales and becomes increasingly complex, issues such as code defects, resource leaks, concurrency conflicts, and null pointer dereferences pose a growing threat to system stability and security. To identify problems as early as possible before software integration and release, the industry has widely adopted code review processes, where experienced developers manually review newly submitted code to improve code quality.

[0003] In existing technologies, code review primarily relies on manual reading of code diffs and related documentation, combined with the reviewer's experience to identify potential issues. This approach has the following drawbacks: First, manual review is time-consuming and labor-intensive, and in large projects or scenarios with frequent submissions, omissions or insufficient review are likely to occur. Second, the quality of review is highly dependent on the individual reviewer's ability and state of mind; different reviewers can provide opinions with significant differences in accuracy and comprehensiveness, making it difficult to guarantee the consistency and stability of review results.

[0004] To reduce the workload of manual labor, existing technologies have introduced static analysis tools, continuous integration platforms, and code hosting and review platforms. Some systems can automatically trigger compilation checks or rule-based scans after code submission, and provide feedback on the problems found to the developers. However, these tools are usually based on fixed rules or have limited syntax and type checking capabilities, and have limited ability to identify risks in complex business logic and across function call chains, making it difficult to detect deep-seated logical defects and high-risk changes in a timely manner.

[0005] In recent years, large-scale pre-trained language models have demonstrated certain capabilities in code understanding and generation. Some solutions attempt to directly input newly submitted code or discrepancies into general language models to generate review comments or modification suggestions. However, these solutions generally suffer from the following problems: First, the models often make inferences based solely on surface-level code text, lacking a systematic utilization of semantic information such as the overall project structure, type information, diagnostic results, and call relationships. This makes them prone to "imagined" problems or ignoring actual high-risk defects, with false positive rates typically exceeding 40%. Second, many solutions have low integration with existing code review platforms, usually requiring developers to manually trigger them or use tools separately outside the development environment, failing to naturally integrate into the existing code review process. Third, existing solutions typically do not deeply integrate with the diagnostic information and call hierarchy information provided by the Language Server Protocol (LSP), failing to effectively utilize the precise results of static analysis tools before and after large model inference, thus remaining insufficient in terms of the accuracy, interpretability, and stability of the review.

[0006] Therefore, existing technologies lack a code review assistance method and system that can be automatically triggered within the workflow of a code review platform, utilize language service protocols to obtain semantic information such as diagnostics and call chains, and deeply integrate with the intelligent analysis capabilities of large models, so as to improve defect detection rate and risk assessment accuracy while reducing the burden of manual review. Summary of the Invention

[0007] The technical problem to be solved by this invention is: Existing code review technologies mainly rely on manual reading of code differences and fixed rules of static analysis tools, making it difficult to identify high-risk code changes across functions and modules in a timely and accurate manner. Existing solutions that directly submit code diffs to large language models for review lack systematic utilization of engineering-level semantic information (such as diagnostic results and call chain information), which can easily lead to "illusion" conclusions with a false positive rate of over 40%. Furthermore, they have low integration with the workflow of code review platforms such as Gerrit, and cannot automatically trigger and generate structured review comments when patch sets are created, resulting in low review efficiency and poor result stability.

[0008] To address the aforementioned technical problems, this invention provides a code review assistance method and system based on a large model. This method automatically triggers review tasks within the workflow of a code review platform. It constrains the analysis process of the large language model by incorporating semantic information provided by the language service protocol, reduces illusions by constraining model inference through the objectivity of LSP diagnostic results, self-corrects model errors through a negative feedback mechanism, and assesses the scope of change impact through call chain information, thereby improving defect detection capabilities and the reliability of review conclusions. The technical solution adopted by this invention to solve its technical problems is as follows: A code review assistance method and system based on a large model, the system including an event receiving module, a review coordination module, an LLM agent module, a code intelligence tool module, and a result publishing module that interface with a code review platform; The event receiving module is used to receive patch set creation events and parse out the project identifier, change identifier, and patch set identifier; the review coordination module is used to check out the corresponding version from the code repository, build a project code snapshot that can be parsed by the language server locally, and generate a review model object containing the project code snapshot and difference information. The LLM proxy module calls the large language model to obtain model output containing thought content. Based on the model output, it generates call instructions to the code intelligence tool when needed. The code intelligence tool module calls the language server that follows the language service protocol to obtain diagnostic results and / or call chain information. After writing the obtained observation results into the session context, it calls the large language model again to generate code review conclusions. When the language server returns an exception message such as "definition not found", the LLM agent module triggers a negative feedback mechanism: it identifies the error type (symbol does not exist, file is inaccessible, parameter format is incorrect or service is abnormal), generates a corresponding correction prompt word based on the error type, and guides the large language model to self-correct the previous tool call parameters, symbol names or analysis paths. The code intelligence tool module encapsulates the diagnostic interface and call hierarchy interface of LSP, and converts the diagnostic and call chain results returned by the language server into structured observation results and returns them to the LLM agent module; The results publishing module then converts the code review conclusions into comment data compatible with the code review platform and publishes them to the corresponding patch set page; In addition, the present invention also provides a computer device and a computer-readable storage medium in which a computer program running or stored is used to execute the above-described code review assistance method based on a large model.

[0009] The present invention has achieved significant technical effects through the following technical means: Technical effect 1: By using an objectivity constraint model to infer LSP diagnostic results, the false positive rate is significantly reduced. Traditional LLM schemes, when directly analyzing code text, are prone to "fabricating" non-existent defects due to a lack of understanding of the actual code semantics (e.g., claiming a function has a memory leak when the actual code does not). This invention obtains true diagnostic results (such as compiler warnings, type errors, and null pointer risks) through LSP diagnostic tools, and uses this objective semantic information as constraints for model inference.

[0010] Specific results: In the comparative experiment, for 1,000 code changes containing actual defects, the false positive rate of the traditional pure LLM scheme was 42% (the proportion of problems claimed by the model but not actually existing), while the false positive rate was reduced to 13% after adopting the LSP constraint scheme of this invention, a decrease of 69%.

[0011] Technical effect 2: By using call chain information, the model can understand the scope of the change's impact, thus improving defect recall. Modifying a function may seem simple and without obvious problems, but if that function is called by core modules or frequently accessed paths, the risk of change could be high. Traditional LLM solutions struggle to understand such cross-function impact relationships. This invention uses an LSP call chain tool to obtain information on "who called the function," enabling the model to assess the risk range of changes in scenarios such as module initialization and core data processing paths.

[0012] Specific results: In the test set, 35 high-risk changes were difficult to identify based on the functions themselves alone. However, call chain analysis revealed that these changes were called by initialization functions or error handling paths, thus correctly identifying them as high-risk. After adopting call chain analysis, the defect recall rate increased from 68% to 89%.

[0013] Technical effect 3: The model self-corrects through a negative feedback mechanism, further improving accuracy. When analyzing complex code, LLMs may reference non-existent symbol names (e.g., mistakenly writing "alloc_buff" instead of "alloc_buffer"). Traditional solutions would directly report an error or stop. This invention uses a negative feedback mechanism: when an LSP returns a "definition not found" error, the system identifies the error type and generates correction prompts (e.g., "Check symbol name spelling" or "Confirm the actual name using a symbol lookup tool"), guiding the LLM to self-correct in the next round of dialogue.

[0014] Specific results: In the experiment, 18% of the LLM output contained symbolic reference errors. Through the negative feedback mechanism, 77% of these errors were successfully self-corrected, and the accuracy of the final review conclusions increased from 82% to 94%.

[0015] Technical benefit 4: Seamless integration with existing workflows through automatic result publishing. This invention automates the entire process from patch set creation to review result publication through Gerrit's event subscription and comment publishing interface, eliminating the need for manual intervention. Review conclusions are provided as inline comments precisely linked to specific lines of code, or as summary comments offering an overall assessment. Gerrit automatically notifies developers to view the review comments.

[0016] Efficiency improvements: The average review time for each patch set has been reduced from 45 minutes for manual review to 3 minutes for automated review, improving review efficiency by 15 times; it also supports parallel review of multiple projects, with throughput more than 10 times that of manual review. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] Figure 1 This is a schematic diagram of the overall structure of a code review assistance system based on a large model provided in an embodiment of the present invention.

[0019] Figure 2 This is a flowchart illustrating a code review assistance method based on a large model provided in an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of the execution flow of the negative feedback mechanism provided in an embodiment of the present invention. Detailed Implementation

[0021] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0022] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0023] To make the technical solution of the present invention clearer, the present invention will be further described below with reference to specific embodiments. Those skilled in the art should understand that various modifications or equivalent substitutions can be made to the following embodiments without departing from the concept of the present invention, and all such modifications or equivalent substitutions fall within the protection scope of the present invention.

[0024] In embodiments of this invention, the system is integrated into a code version control and review system (such as Gerrit) to automate and intelligently review code changes submitted by developers. The core idea of ​​this invention is to utilize precise and structured code semantic context, such as diagnostic information and call hierarchy information provided by the Language Server Protocol (LSP), to constrain and guide the analysis process of the Large Language Model (LLM), thereby significantly improving the accuracy of the review, reducing model illusion, and enhancing the efficiency and quality of code review.

[0025] I. System Overall Architecture like Figure 1 As shown, in a preferred embodiment, the present invention provides a code review assistance system based on a large model. This system can be deployed on a standalone server or a continuous integration (CI) server connected to a Gerrit server. The system mainly includes the following functional modules: 1. Event receiving module The event receiving module interfaces with code review systems (such as Gerrit) to receive patch set creation events published by the system (e.g., Gerrit's "patchset-created" event). The event receiving module parses information from the event, including the associated project, change number, patch set number, commit hash, and the triggering user's identity, and encapsulates this information into an internal review task request.

[0026] In one embodiment, the event receiving module can subscribe to Gerrit's event stream through a message queue (such as Kafka, RabbitMQ) or gRPC stream, and trigger the review process in real time when a patchset-created event is detected.

[0027] 2. Review and Coordination Module (Main Control Module) The review coordination module (also known as the main module) is used to create review tasks based on review task requests generated by the event receiving module and coordinate subsequent review processes. The review coordination module can perform the following operations: (1) Pull the code differences (diff) of the corresponding patch set and the complete contents of related files from Gerrit or the underlying version control system (such as Git); (2) Determine whether a new review model instance (e.g., a review context object corresponding to a certain project / branch / patchset) needs to be created based on the project configuration. (3) Call the review engine module to start the automatic review of the current patch set.

[0028] In practice, the review coordination module can obtain reference information of the current patch set through the SSH or REST interface provided by Gerrit, and allocate an independent working directory for each review task locally for subsequent code checkout and LSP analysis.

[0029] 3. Review Engine Module The review engine module is used to organize code snapshot synchronization, LLM proxy calls, and result summarization in specific review tasks. The review engine module provides interfaces such as New, CreateModel, and Review, among which: (1) The New interface is used to create a new review session for the current patch set, generate a unique session identifier and initialize the context state; (2) The CreateModel interface is used to construct a review model object based on project configuration information, code repository address, branch information and patch set information. The object includes at least: code baseline version identifier, target version identifier after change, list of difference files and related metadata; (3) The Review interface is used to drive the LLM agent module to execute the automatic code review process after code synchronization is completed.

[0030] In practice, the review engine module can check out the code version corresponding to a patch set (e.g., a specific patchset in Gerrit) to the local working directory, forming a code snapshot for review. This snapshot is then used by the LSP language server for subsequent diagnostics and call chain analysis. The review engine module can also generate suitable project configurations for the LSP server, such as compilation options and include paths, ensuring that the LSP analysis environment is as consistent as possible with the actual build environment.

[0031] 4. LLM Agent Module The LLM proxy module interacts with the large language model interface and employs a cyclical mechanism of "think – call tool – observe – rethink" (similar to ReAct's intelligent proxy mode). It progressively infers and generates review conclusions based on code differences, diagnostic information, and call chain information. The LLM proxy module includes: (1) Session Management Submodule The context used to maintain this review includes the current diff, acquired diagnostic information, call chain information, and historical dialogue content. The session management submodule is responsible for organizing the input content for each round of model calls and updating the context state based on the model output.

[0032] (2) Prompt to build submodules Used to construct hints sent to a large language model. When generating initial hints, the hint construction submodule includes code change context (e.g., commit messages, diff snippets, list of changed files) and explicit review task instructions. These instructions require a security, correctness, and maintainability review of the code changes, identification of potential defects and assessment of risk levels, and provision of modification suggestions.

[0033] (3) Model Calling Submodule Used to send prompts to the LLM interface and receive model output. The Model Invocation submodule can send text or structured prompts generated by the prompt building submodule to the LLM service and receive model output containing "Thought" and "Action / Answer" fields.

[0034] (4) Decision Submodule The decision submodule is used to analyze the thought processes and action instructions output by the model, determine whether to invoke a tool in the code intelligence tool module (such as diagnostic tools, call chain tools, symbol lookup tools), and determine the input required for the next round of model invocation. When the model output contains tool invocation instructions that do not conform to the interface specification, the decision submodule can also trigger an error feedback process, prompting the model to readjust the tool invocation format or analysis path.

[0035] The tool invocation decision-making process of the decision-making submodule includes the following steps: Step 1: Model Output Analysis Use regular expressions or a JSON parser to extract the command call. Example parsing format: •TOOL_CALL:{'name':'getDiagnostics','args':{'filePath':'memory.c'}} •Or JSON format: {"action": "tool_call", "tool": "getDiagnostics", "parameters": {"filePath": "memory.c"}} Step 2: Parameter Verification Check if the tool name is in the list of registered tools; Verify that the parameter type meets the tool interface requirements (e.g., filePath should be a string); Verify that the required parameters are complete.

[0036] Step 3: Security Check Check if the file path is within the scope of the code snapshot directory (to prevent path traversal attacks); Check whether the parameters contain malicious input (such as command injection or sensitive information leakage).

[0037] Step 4: Call Execution and Timeout Control Initiate a call request to the code intelligence tool module; Set a timeout period (e.g., 30 seconds), and return an error type and observe the results after the timeout.

[0038] Step 5: Result Processing Success: Encapsulate the results into structured observations and update the session context; Failure: Triggers a negative feedback mechanism based on the error type.

[0039] Through the cooperation of the above sub-modules, the LLM agent module concretizes the originally abstract "model thinking process" into a series of tool call decisions and context update steps, making the reasoning process of the large language model controllable and traceable.

[0040] 5. Code Intelligence Tools Module The code intelligence tool module encapsulates calls to the Language Services Protocol (LSP) server, providing structured semantic information to the LLM agent. In one embodiment, the module includes at least: (1) Diagnostic tool interface This is used to implement the `getDiagnostics(filePath)` operation. Internally, it sends a diagnostic request for the specified file to the LSP server via the LSP's `textDocument / diagnostic` request. The diagnostic tool interface can filter and categorize the returned results, such as grouping them by severity, error type, or code location, providing a more aggregated diagnostic view for higher layers.

[0041] (2) Call the chain tool interface This tool is used to implement the `getCallHierarchy(filePath, symbolName)` operation. Internally, it retrieves call relationship information for a specified function or method from the LSP server via `textDocument / prepareCallHierarchy` and `callHierarchy / incomingCalls` or `outgoingCalls` requests. The call chain utility interface can return the call chain results in a tree structure or list format, indicating the file, function name, and call location of each caller.

[0042] (3) Symbol lookup and reference tool interface In other embodiments, the code intelligence tool module can also provide symbol definition query interfaces, reference lookup interfaces, etc., to obtain the definition and reference locations of symbols such as functions, variables, and classes. When the LLM references a symbol in its response, it can use these interfaces to verify or supplement the context.

[0043] The code intelligence tool module shields the upper layer from the specific JSON-RPC details of the LSP protocol, and provides simplified observation results to the LLM agent module through a unified function call interface. For example, it returns diagnostic level, error type, location of occurrence, and list of called functions in the form of structured data.

[0044] When the LSP server returns "definition not found" or an exception, the code intelligence tool module will also encapsulate the error message as an observation and feed it back to the LLM agent module to trigger the subsequent self-correction process.

[0045] 6. LSP Server Module (Language Server) The LSP server can be implemented using existing language servers, such as clangd for C / C++, gopls for Go, pylsp for Python, and tsserver for TypeScript. This server runs based on code snapshots synchronized by the review and coordination module and provides functions including diagnostics (textDocument / diagnostic), call hierarchy analysis, and symbol information (textDocument / documentSymbol) according to the language service protocol.

[0046] In practice, the LSP server can run in single-process or multi-process mode to parse JSON-RPC requests from the code intelligence tool module. By performing syntax analysis, semantic analysis, and partial data flow analysis on the code snapshot, it generates corresponding diagnostic and call chain results and then returns the results in the standard LSP response format.

[0047] 7. Model Interface Module (LLM API Module) The model interface module is used to communicate with large language model services deployed externally or internally, and can be invoked via HTTP / HTTPS, gRPC, etc. For example, the model interface module receives prompts from the LLM proxy module, constructs request messages according to the model service's interface protocol, and receives the text results generated by the model. The model output can include "Thought" and "Answer" fields in a predefined format, and the model interface module can pass the raw response to the decision submodule for parsing and processing.

[0048] In one embodiment, the large language model can adopt models that support function calling capabilities, such as Qwen, GPT-4, and Claude.

[0049] 8. Results Publishing Module The results publishing module is used to convert the review results output by the review engine module into a comment format that can be recognized by the target code review system, and publish the comments to the corresponding patch set page via Gerrit's REST API or SSH interface.

[0050] The results publishing module can precisely link comments to the corresponding lines of code based on the location of issues in the review results (such as file paths and line numbers), or generate summary comments in the overall comments section of the patch set. After successful publishing, Gerrit will send a notification to the user who submitted the code, reminding them to view the AI ​​review comments, according to its own mechanism.

[0051] 9. Cache Management Module In a preferred embodiment, the system further includes a cache management module, used for: (1) Cache key generation: {project identifier + branch identifier + file path + file content hash value} is used as the cache key to ensure that the same version of the same file corresponds to a unique cache entry; (2) Cache reuse judgment: When reviewing a new patch set, calculate the similarity between the changed file and the cached file (e.g., by comparing content hashes). If the similarity exceeds a preset threshold (e.g., 80%), then reuse the cached result. (3) Cache expiration strategy: When the code version undergoes major changes (such as branch switching, dependency updates) or the LSP service is restarted, the relevant cache is cleared; cache entries are set to expire (such as 24 hours), and expire automatically after the timeout.

[0052] Through caching mechanisms, the system can reduce repeated calls to the LSP server and LLM service, thereby improving review efficiency.

[0053] II. Specific Work Process In one specific embodiment, based on the above system, when developers submit new patch sets via Gerrit, the present invention also provides a code review assistance method based on a large model, such as... Figure 2 As shown, its specific workflow is described below.

[0054] S101. Event Triggering and Task Creation Developers execute the `git push` command locally to push code commits to the Gerrit server. Gerrit generates a `patchset-created` event upon receiving the new patch set. The event receiving module subscribes to or listens for this event source, and upon receiving the event, parses information such as the project name, change number, and patch set number, and then sends a review task request to the review coordination module.

[0055] After receiving a task request, the review coordination module calls the New interface of the review engine module to create a new review session, and checks out the corresponding code version based on the Gerrit repository and patch set information through the CreateModel interface. Specifically, the review engine module can: (1) Obtain the Git reference corresponding to the current patch set from Gerrit via SSH or HTTP protocol; (2) Perform a checkout in the local working directory to create a complete snapshot of the project code, including the changed files; (3) Extract the diff information and list of changed files for this patch set, for example, find that the file memory.c has been modified; (4) Save the above code snapshot path, change file list, etc. into the review model object.

[0056] Subsequently, the review coordination module calls the Review interface of the review engine module to start the automatic code review process.

[0057] Initial Analysis of S102 and LLM Agents The review engine module calls the LLM agent module to pass context information related to the current patch set, including: commit message, code diff, list of changed files, and summary information on project language and compilation configuration.

[0058] The prompt building submodule generates initial prompts to be sent to the large language model. The prompts include: review task instructions (explicitly requiring a security, correctness and maintainability review of code changes, identifying potential defects, assessing risk levels and providing modification suggestions), and diff snippets and key code contexts related to the patch set.

[0059] The model invocation submodule sends the above prompts to the LLM service and receives the model output. The model's initial output includes analysis results containing thought-provoking content and possible tool invocation instructions.

[0060] When the model generates a tool call instruction in the output that conforms to the agreed format, the decision submodule will call the corresponding code intelligence tool interface according to the instruction.

[0061] S103, LSP-based diagnostic examination In this embodiment, the LLM agent module first decides to perform a diagnostic check on the memory.c file. The decision submodule parses the tool call instructions in the model output and determines that getDiagnostics("src / memory.c") needs to be called.

[0062] After receiving the call request, the code intelligence tool module constructs a textDocument / diagnostic request according to the LSP protocol, sending the identifier of memory.c (such as URI and version number) to the LSP server. The LSP server analyzes memory.c in the root directory of the current code snapshot, checking its syntax, types, control flow, etc., and returns a set of diagnostic results.

[0063] The diagnostic results can include several records, each containing: the diagnostic level (e.g., Error, Warning, Hint), the diagnostic message (e.g., "Null pointer dereference possible", "Potential memoryleak"), the corresponding code location (file path, start and end line numbers), and related code snippets.

[0064] In this embodiment, the diagnostic information returned by the LSP server includes a warning about a certain section of code in memory.c, indicating a potential risk of null pointer dereference. The code intelligence tool module adapts and transforms the data returned by the LSP, organizing it into a structured observation result containing the diagnostic level, diagnostic message, and code location.

[0065] The observation is returned to the LLM agent module and added to the current review context by the session management submodule.

[0066] The LLM proxy module takes this observation, along with the previous diff information, as new context information and calls the large language model again through the model interface module. The model may then determine from the new output to further analyze the function call chain to assess the scope of the problem.

[0067] S104. Risk Propagation Analysis and Negative Feedback Mechanism Based on Call Chain Based on the model's output, the decision submodule decides to call the call chain tool interface to obtain the call relationship of the alloc_buffer function. The decision submodule sends a getCallHierarchy("src / memory.c", "alloc_buffer") request to the code intelligence tool module.

[0068] The code intelligence tool module first queries the LSP server via textDocument / prepareCallHierarchy to find the definition location and call hierarchy root node information of the symbol alloc_buffer in memory.c; then it queries via callHierarchy / incomingCalls to find out which functions called alloc_buffer.

[0069] Scenario A: The LSP server returns the call chain result normally. The LSP server performs static analysis within the scope of the code snapshot and returns a list of parent functions that called the function, for example: [ { "name": "init_module", "file": "src / module.c", "range": {"startLine": 45, "endLine": 45} }, { "name": "process_data", "file": "src / core.c", "range": {"startLine": 230, "endLine": 230} }, { "name": "handle_request", "file": "src / api.c", "range": {"startLine": 89, "endLine": 89} } ] The code intelligence tool module encapsulates the call chain list into observation results: [Observation] The function alloc_buffer is called by the following function: 1. init_module (src / module.c:45) - Module initialization function 2. process_data (src / core.c:230) - Core data processing functions 3. handle_request (src / api.c:89) - Request handling function The LLM proxy module uses the call chain information, along with the previous diff and diagnostic information, as context to call the large language model again.

[0070] The model can provide a comprehensive review conclusion in the Answer field: Answer: In memory.c, the modification of the alloc_buffer function introduces a potential risk of null pointer dereference (line 125).

[0071] Risk Analysis: This function is called by the module initialization function `init_module`, the core data processing function `process_data`, and the request handling function `handle_request`. Since `alloc_buffer` is called during the initialization phase and in the core data processing path, if `ptr` is empty, it will cause system initialization failure or data processing anomalies, with a significant impact.

[0072] Problem location: - File: src / memory.c - Line number: 125 - Code: return *ptr; / / ptr may be null Risk level: High Suggested revisions: 1. In the `alloc_buffer` function, NULL is returned instead of dereferencing `ptr` when allocation fails; 2. Add return value checks at all call points (init_module, process_data, handle_request) to handle allocation failures.

[0073] Scenario B: The LSP server returns a "definition not found" error, triggering a negative feedback mechanism. Suppose the model misnamed the function as "alloc_buff" (a spelling error) during the previous tool call, and the LSP server returned: { "error": { "code": -32803, "message": "Symbol 'alloc_buff' not found in document" } } The code intelligence tool module captures the error response and encapsulates it as an observation of the error type: [Error Observation] Symbol Not Found: The definition of symbol 'alloc_buff' was not found in the code snapshot. Error type: Symbol Not Found The execution process of the negative feedback mechanism is as follows: Figure 3 As shown, it includes the following steps: Step S401: Error Type Identification After receiving the error observation, the LLM agent module identifies the error type based on the error code and error message: • Type A: Symbol not found (LSP returns "Symbol not found" or "Definition not found") • Type B: File inaccessible (LSP returns "File not found" or "Cannot open file") • Type C: Parameter format error (LSP returns "Invalid parameters" or "Type mismatch") • Type D: Service timeout or exception (LSP returns "Request timeout" or "Internal error") In this example, it was identified as type A: symbol does not exist error.

[0074] Step S402: Generate correction prompt words Generate corresponding guidance information based on the error type and insert it into the next round of prompts: Previous tool call returned an error: - Use the tool: getCallHierarchy - Call parameters: filePath='src / memory.c', symbolName='alloc_buff' - Error message: Symbol 'alloc_buff' not found in code snapshot Please perform one of the following corrections: 1. Check if the symbol name is spelled correctly (should it be "alloc_buffer"?). 2. Check if the wrong file has been selected; 3. Use a symbol lookup tool to confirm the actual name of the function; 4. Adjust the analysis approach and continue reviewing other changes without relying on this symbol.

[0075] Please re-analyze based on the above error message. Step S403: Recall the model The LLM agent module merges the corrected prompt with the historical context (original diff, diagnostic information, previous thought process) and then calls the large language model again.

[0076] The model self-corrects in the new output: Thought: I found an error; the symbol name was misspelled. According to the error message, the correct function name should be "alloc_buffer" instead of "alloc_buff". I need to re-invoke the tool.

[0077] Action: TOOL_CALL:getCallHierarchy(filePath='src / memory.c',symbolName='alloc_buffer') The decision submodule parses the corrected tool call instructions, finds that the parameters have been corrected, and calls the code intelligent tool module again.

[0078] Step S404: Continue with the normal procedure. The code intelligence tool module calls the LSP server using the corrected parameters and successfully obtains the call chain result. The subsequent process is the same as in "Case A".

[0079] Through this closed loop of "instrumental error → observation results → model self-correction", the present invention can constrain the illusions or erroneous inferences that the model may produce, thereby improving the reliability of the final review conclusion.

[0080] S105. Summary and Publication of Review Results The LLM proxy module returns the above review conclusions and the corresponding evidence chain (e.g., the location of diagnostic entries, the names of relevant functions in the call chain) to the review engine module. The review engine module can organize these results into one or more comment items according to the configuration, each comment item containing: (1) Problem type (such as null pointer risk, resource leak risk, concurrency race condition risk, etc.); (2) Problem location (e.g., line 125 in memory.c); (3) Problem description (comprehensive model output, explaining the risk background and scope of impact); (4) Suggested modifications (such as adding null pointer checks, adjusting error handling paths, etc.).

[0081] Before generating a review conclusion, the system verifies the existence of the symbols referenced in the conclusion through a symbol query interface. For non-existent symbols, the system lowers the confidence level of the review conclusion or triggers a re-analysis to avoid erroneous conclusions based on false symbols.

[0082] After receiving the comment data from the review engine module, the results publishing module uses Gerrit's REST API to publish the comments to the review page of the corresponding patch set. Publishing methods can include: • In-line comments: Displayed in the diff view for specific lines of code, highlighting problematic lines and providing review comments; • Summary comments: Displayed on the patch set overview page, providing an overall assessment and priority ranking.

[0083] Once a comment is successfully published, Gerrit will send a notification (such as an email or in-site message) to the user who submitted the code, reminding them to check the AI ​​review comments.

[0084] III. Detailed Implementation Examples of Negative Feedback Mechanism like Figure 3 As shown, the present invention provides a method for implementing a negative feedback mechanism to guide the model to self-correct when an LLM tool call error occurs.

[0085] Step S401: Error Type Identification When the code intelligence tool module receives an error response from the LSP server, it first identifies the error type, including errors such as symbol not found, file inaccessible, parameter format errors, or service exceptions.

[0086] Step S402: Generate correction prompt words Based on the error type, corresponding boot information is generated. For example, for a symbol not found error, the boot model checks the spelling of the symbol name, verifies the file path selection, or confirms the actual name using a symbol lookup tool; for a file inaccessible error, the boot model confirms whether the file path is correct; for a parameter format error, the boot model uses the correct parameter type.

[0087] Step S403: Recall the model By merging correction prompts with historical context and preserving the complete dialogue history, the model can understand previous errors and correction suggestions, and guide the model to self-correct in new outputs.

[0088] Step S404: Model Self-Correction Step S405: Verify the correction results The decision submodule parses and verifies the revised tool call instructions: • Does the symbol name exist in the code snapshot? (This can be quickly verified using the symbol query interface). • Does the parameter format conform to the tool interface requirements? • Are there any potential security risks (such as path traversal)?

[0089] After successful verification, the code intelligence tool module is invoked again to execute the tool call.

[0090] Through a negative feedback mechanism, this invention achieves the self-correcting capability of LLM. In the experiment, 18% of the LLM output contained symbolic reference errors. Through the negative feedback mechanism, 77% of these errors were successfully self-corrected, and the accuracy of the final review conclusions increased from 82% to 94%.

[0091] IV. Other Implementation Methods and Extensions This invention is not limited to the embodiment described above using Gerrit as an example. In other embodiments: (1) Extension of code review system The code review system can be any platform that supports change submission and review, such as code review systems based on GitLab, GitHub, or Phabricator. The event receiving module only needs to be adapted to the Webhook or event flow interface provided by the corresponding system to automatically trigger the review process of this invention when a new change is created.

[0092] (2) Multilingual support of the language server The language server can be selected for different programming languages: •C / C++: clangd •Go: gopls • Python: pylsp, pyright •TypeScript / JavaScript: tsserver, vtsls • Rust: rust-analyzer • Java: jdt-language-server As long as the language server conforms to the LSP standard, the code intelligence tool module can obtain diagnostic and call chain information through unified interfaces such as textDocument / diagnostic and callHierarchy.

[0093] (3) Selection of large language model Large language models can provide services for self-built or third-party provided models: • A Thousand Questions on General Knowledge (Qwen Series) •GPT-4 / GPT-3.5 •Claude series •PaLM series Depending on the project's security requirements, deployment can be chosen to be on a local data center or invoked via cloud services. The model interface module can be adapted according to the API specifications of specific services, including mechanisms such as authentication, rate limiting, and timeout retries.

[0094] (4) Incremental analysis and optimization To further reduce model illusion, this invention can perform structured validation of the model output in the LLM proxy module: • Symbol Existence Verification: When the model references a function name or variable name in its response, the LLM proxy module can call the symbol query interface through the code intelligence tool module to check whether the symbol actually exists in the current code snapshot; if it does not exist, the confidence of the review conclusion is reduced, or the model's self-correction mechanism is triggered by observing the negative feedback results.

[0095] • Code location verification: Verify whether the line number referenced by the model is within the range of line numbers in the modified file.

[0096] • Logical consistency check: Check whether the model's review conclusions are consistent with the LSP diagnosis results (e.g., the LSP did not report a memory leak, but the model claims to have a memory leak, triggering a re-analysis).

[0097] (5) Performance optimization strategy In terms of performance optimization, an incremental analysis strategy can be adopted for large-scale projects: • Change file filtering: Diagnoses and call chain analysis are performed only on the files or functions involved in the diff, rather than the entire project; • Intermediate result caching: Cache intermediate results with the cache key using {project ID + branch + file path + file content hash}. Reuse cached results when the file content has not changed. • Batch requests: Send diagnostic requests for multiple files in batches to reduce the number of LSP calls; • Parallel processing: Multiple tool calls (such as diagnosing multiple files simultaneously) are executed in parallel to improve analysis efficiency; Through the above optimizations, the system can reduce analysis time by more than 60% and improve the overall throughput of the system while ensuring the accuracy of the review.

[0098] V. Examples of Computer Equipment In one embodiment, the present invention also provides a computer device for executing the above-described code review assistance system and method based on a large language model and language service protocol. The computer device may be a physical server, a virtual machine, or a cloud computing node, including but not limited to: The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor.

[0099] The processor can be one or more of a general-purpose processor (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), and a field-programmable gate array (FPGA). The processor executes the logic of the various functional modules described in this invention, including an event receiving module, a review coordination module, a review engine module, an LLM agent module, a code intelligence tool module, and a result publishing module, to implement the code review assistance functions described in the above embodiments.

[0100] The memory may include volatile and / or non-volatile storage media, such as random access memory (RAM), read-only memory (ROM), hard disk, solid-state drive, flash memory, etc. The memory is used to store the operating system, code repository image, prompt word templates for large language models, project configuration files, Gerrit code snapshots, diagnostic data returned by LSP, call chain data, inspection context information, and computer programs used to implement the methods of this invention.

[0101] The computer device may also include a communication interface for data communication with external systems. The communication interface can be a wired network interface, a wireless network interface, etc., used to enable data transmission with the Gerrit server, CI server, LSP server, and external LLM API services. For example, the communication interface can be used to receive patchset-created events and code repository data from Gerrit, and to send model call requests to external LLM services and receive the returned results.

[0102] When the processor executes the computer program in the memory, it causes the computer device to execute the code review method based on the large language model and language service protocol as described in the foregoing embodiments, including: listening to the patch set creation event of the code review system, detecting the corresponding code snapshot, calling the LSP server to obtain diagnostic information and call chain information, organizing the large language model to perform analysis via the LLM proxy module, and publishing the generated review results to the code review system.

[0103] In another embodiment, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the code review method based on a large language model and language service protocol described in any of the above embodiments. By implementing the software method on a specific computer device and storage medium, the present invention ensures that it has a clear technical carrier and executability, thus meeting the requirements of patent law for full disclosure of technical solutions.

[0104] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0105] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A code review assistance system based on a large model, used for interfacing with a code review platform, characterized in that, include: The event receiving module is used to receive change events from the code review platform that indicate the addition of a new patch set in the existing code, and to parse the project identifier, change identifier, and patch set identifier from the change event; The review coordination module is used to, upon receiving a review task request transferred by the event receiving module, check out the code version corresponding to the patch set identifier from the code repository, build a project code snapshot corresponding to the code version locally, the project code snapshot is used for semantic analysis by the language server, generate a review model object containing the project code snapshot and difference information, the difference information includes at least a list of changed files and corresponding code differences, and start the corresponding review session. The LLM proxy module is configured to construct a prompt message for the large language model based on the difference information in the review model object and the project code snapshot, call the large language model to obtain model output containing the thought content, generate a call instruction to code intelligence tools and call at least one code intelligence tool when it is determined that static analysis is required based on the thought content, and call the large language model again based on the observation results returned by the code intelligence tool after obtaining the observation results to generate a code review conclusion for the patch set. When the thought content indicates that static analysis is not required, the large language model is configured to generate the code review conclusion without calling the code intelligence tool. The LLM proxy module is also configured to trigger a negative feedback mechanism when receiving an error type observation result returned by the code intelligence tool, guiding the large language model to correct the previous tool call parameters, symbol names, or analysis paths in a new prompt message. The code intelligence tool module is used as a Language Service Protocol (LSP) client to interact with the language server. According to the call request of the LLM proxy module, it obtains the diagnostic results and / or function call relationship information of the target source file from the language server, and returns the processed structured observation results to the LLM proxy module. The results publishing module is used to generate comment data compatible with the code review platform based on the code review conclusions output by the LLM proxy module, and publish the comment data to the code review page corresponding to the patch set identifier.

2. The code review assistance system based on a large model according to claim 1, characterized in that, The LLM agent module includes: The session management submodule is used to maintain the context information of the current review session. The context information includes at least the difference information, the diagnostic results, the function call relationship information, and the historical model output. The prompt construction submodule is used to inject the context information along with the review task instruction when constructing the prompt information to be sent to the large language model. The review task instruction explicitly requires a security, correctness and maintainability review of the code changes, identification of potential defects and assessment of risk levels, and provision of modification suggestions. The model invocation submodule is used to send the prompt information to the large language model service and receive the model output; The decision submodule is used to parse the thinking content and tool call instructions in the model output, determine the target tool and its call parameters, send a call request to the code intelligence tool module, and update the context information and the next round of prompt information after receiving the observation results.

3. The code review assistance system based on a large model according to claim 1, characterized in that, The code intelligence tool module includes: The diagnostic tool interface is used to construct a diagnostic request based on a diagnostic call request, send a request containing file path identification information to the language server, receive a set of diagnostic results returned by the language server, and convert the set of diagnostic results into a structured observation result containing diagnostic level, diagnostic message, and code location. The call chain tool interface is used to construct a call chain query request based on the call chain query request, obtain the root node information of the call hierarchy corresponding to the symbol and the list of callers from the language server, and convert them into structured observation results containing the name of the called function, the file where it is located, and the call location.

4. The code review assistance system based on a large model according to claim 3, characterized in that, The code intelligence tool module further includes a symbol query interface, which, upon receiving a symbol verification request from the LLM proxy module, sends a symbol definition query and / or reference query request to the language server to determine whether the function name or variable name referenced by the large language model in the output exists in the project code snapshot, and returns the verification result as an observation result to the LLM proxy module.

5. The code review assistance system based on a large model according to claim 4, characterized in that, When the code intelligence tool module receives "definition not found" or exception information returned by the language server, it encapsulates the exception information into an observation of the error type and returns it to the LLM agent module. The LLM agent module triggers a self-correction mechanism based on the observations of the error type, specifically including the following steps: Identify error type: Determine the error type based on the error message; Generate correction prompts: Generate corresponding guidance information based on the error type, and the guidance information prompts the large language model to perform correction operations; Recall the model: After merging the corrected prompts with the historical context, the large language model is called again, so that the large language model corrects the tool call parameters, symbol names or analysis paths in the new model output; Before outputting the code review conclusion, the LLM proxy module verifies the existence of the symbols referenced in the output through the symbol query interface to reduce erroneous review conclusions based on non-existent symbols.

6. The code review assistance system based on a large model according to claim 1, characterized in that: The event receiving module is configured to subscribe to patch set change events from the code review platform; The review coordination module is configured to trigger diagnostic requests and call hierarchy requests only for the changed files contained in the difference information, and to cache the obtained diagnostic results and call relationship information. The cache generates a cache key based on the project identifier, file path and file content. When reviewing adjacent versions with the same code version or file content similarity exceeding a preset threshold, some cache results are reused, thereby reducing the number of calls to the language server and the large language model. The result publishing module is configured to publish the comment data as inline comments or summary comments for the patch set through the interface provided by the code review platform, and associate the comment data with the corresponding file path and line number.

7. A code review assistance method based on a large model, characterized in that, Includes the following steps: S101. Event Triggering and Task Creation: Receive a change event from the code review platform indicating that a new patch set has been added to the existing code, and parse the project identifier, change identifier, and patch set identifier from the change event; Based on the patch set identifier, the corresponding code version is checked out from the code repository, and a project code snapshot corresponding to the code version is built locally. The project code snapshot includes project source files and their dependencies that can be used by the language server for semantic analysis. A review model object containing the project code snapshot and difference information is generated. The difference information includes at least a list of changed files and the corresponding code differences. Create a review session corresponding to the review model object.

8. S102, Initial Analysis of LLM Agent: The initial prompt information is constructed based on the review model object and sent to the large language model. The initial prompt information includes at least: The review task instructions, the difference information, and the code context associated with the patch set are reviewed. The review task instructions explicitly require a security, correctness, and maintainability review of the code changes, identification of potential defects and assessment of risk levels, and provision of modification recommendations. The large language model is invoked to obtain the first model output, which includes the thought content regarding the difference information and the tool invocation instruction for whether to invoke a certain code intelligence tool. 9.S103. LSP-based diagnostic examinations: If the first model output indicates that a diagnostic check is required, the identifier of the target source file is determined according to the tool invocation instruction, an LSP textDocument / diagnostic request is constructed and sent to the language server; Receive a set of diagnostic results returned by the language server, the set of diagnostic results including diagnostic level, diagnostic message and code location; The diagnostic results set is converted into structured first observations and added to the context of the review session; Based on the first observation and the difference information, a prompt message is reconstructed and the large language model is invoked to obtain the output of the second model. 10.S104. Risk propagation analysis and negative feedback mechanism based on call chain: When the second model output indicates that call chain analysis is required, the target source file and target function symbol are determined according to the tool call instructions. An LSP textDocument / prepareCallHierarchy request and a callHierarchy / incomingCalls request are constructed and sent to the language server to obtain the list of upper-level functions that call the target function symbol. If the language server returns a normal call chain result, the list of upper-level functions is converted into a second observation result containing the name of the called function, the file it is located in, and the location of the call; If the language server returns "definition not found" or an error message, identify the error type and generate a corresponding correction prompt word, and encapsulate the error message into an observation of the error type; The second observation or the observation of the error type is added to the context of the review session, and a prompt message is reconstructed to call the large language model. The large language model then assesses the impact range and risk level of the target defect in the new model output, or self-corrects the previous tool call parameters, symbol names, or analysis paths through a negative feedback mechanism. The negative feedback mechanism specifically includes: for symbol non-existence errors, guiding the model to check the spelling of the symbol name, verify the file path selection, or confirm the actual name through a symbol lookup tool; for file inaccessibility errors, guiding the model to reselect the correct changed file; and for analysis path errors, guiding the model to adjust its analysis approach. 11.S105. Summary and Publication of Review Results: Based on the first and second observations, a code review conclusion for the patch set is generated according to the output of the large language model. The code review conclusion includes at least one or more of the following: problem type, problem location, problem description, and modification suggestions. Before generating the code review conclusion, the function name or variable name referenced in the conclusion is verified to exist in the project code snapshot through the symbol query interface. For symbols that do not exist, the confidence of the review conclusion is reduced or a re-analysis is triggered. The code review conclusions are converted into comment data compatible with the code review platform, and the comment data is published to the corresponding code review page.

12. A computer device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, causes the computer device to perform steps S101 to S105 of the code review assistance method based on a large model as described in claim 7.

13. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing steps S101 to S105 of the code review assistance method based on a large model as described in claim 7.

Images