A hybrid intelligent code review system and method based on model agent layer packaging

CN122816599APending Publication Date: 2026-09-25FAW CAR CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202610888120.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-18
Publication Date
2026-09-25

AI Technical Summary

Technical Problem

[0010]问题一:多模型差异导致集成复杂度高

Benefits of technology

[0057]效果一:模型切换零代码变更;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122816599A_ABST
    Figure CN122816599A_ABST
Patent Text Reader

Abstract

The application relates to a hybrid intelligent code review system and method based on a model agent layer package. The application realizes the non-perception switching of a Jenkins pipeline to an underlying model by uniformly packaging the differences of multiple models through a model agent layer; a Prompt templating management mechanism of enterprise code specifications is constructed to realize the versioning sedimentation and dynamic loading of specifications; a hybrid model intelligent scheduling strategy is designed to dynamically select a local or online model based on code characteristics, and the cost and quality are balanced; a multi-level Fallback mechanism is designed to avoid the CI pipeline blockage caused by single-point faults and guarantee the continuity of the research and development process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology and relates to a hybrid intelligent code review system and method based on model proxy layer encapsulation. Background Technology

[0002] As software engineering scales up, code review has become a crucial step in ensuring code quality. Traditional code review relies primarily on manual processes, which suffers from low efficiency, inconsistent standards, and a scarcity of expert resources. In recent years, automated code review technologies based on Large Language Models (LLMs) have developed rapidly, mainly forming the following technical approaches:

[0003] (1) Single online model scheme

[0004] Cloud services, such as Alibaba Cloud DashScope, directly call the cloud-based large model API for code review. This solution has strong model capabilities, but it also has problems such as the risk of code leakage, high network latency (average 500-2000ms), and uncontrollable call costs (billed by token).

[0005] (2) Single local model scheme

[0006] This approach utilizes an open-source inference framework to deploy large open-source models locally. While offering high data security, the model's capabilities are limited by local computing power (typically only able to run 7B-14B parameter models), resulting in poor performance for tasks such as complex architecture design and cross-file semantic understanding.

[0007] (3) Simple parallel hybrid scheme

[0008] Some companies have attempted to simultaneously call local and online models, taking the union or using simple voting. However, this approach lacks an intelligent scheduling mechanism, leading to resource waste (all models are called at once), no arbitration strategy for conflicting results, and an inability to select the optimal model based on code characteristics.

[0009] The existing technology has the following specific problems:

[0010] Question 1: Differences between multiple models lead to high ensemble complexity.

[0011] The API formats, input / output specifications, and response structures of different large models vary significantly.

[0012] Online API formats vary across different vendors, including authentication methods, request fields, and response levels.

[0013] Local model service: Even with a compatible format, differences still exist in field nesting levels and error code definitions;

[0014] If an enterprise CI / CD pipeline (such as Jenkins Pipeline) directly interfaces with multiple models, the model differences need to be hard-coded in each step, resulting in:

[0015] Switching models requires modifying the Jenkinsfile, which introduces operational risks.

[0016] The same specification (such as Java code style) needs to be configured repeatedly in multiple places using the Prompt;

[0017] When adding a new model, the entire pipeline needs to be modified.

[0018] Question 2: Enterprise coding standards are difficult to solidify and solidify.

[0019] The core value of code review lies in enforcing enterprise-specific coding standards (such as Java security standards and automotive system performance standards). In existing technologies:

[0020] The Prompt project is scattered across various calling points, making version management difficult;

[0021] Standard updates (such as adding SQL injection check rules) require modifications to each section individually;

[0022] Historical review data cannot be used to optimize model output.

[0023] Question 3: Lack of a cost-quality-delay trade-off mechanism

[0024] In a real production environment, different code changes require different model capabilities:

[0025] Simple formatting issues (such as indentation and naming conventions): can be recognized by the local 7B model;

[0026] Complex architectural flaws (such as circular dependencies and concurrency security issues): Requires an online model with hundreds of billions of parameters;

[0027] Existing parallel call schemes result in:

[0028] Simple problems excessively consume online model API fees;

[0029] Complex problems may be missed due to insufficient capabilities of the local model;

[0030] Without a dynamic fallback mechanism, a single point of failure can cause the review process to be interrupted.

[0031] Patent document CN119883358A discloses a code review method and related equipment based on a large language model. The core of this patent lies in large-scale code modification processing and integral compression. This invention focuses on proxy layer encapsulation + multi-model scheduling, rather than code compression.

[0032] Patent document CN119512556A discloses a code review and optimization method driven by a large language model. The core of this patent lies in AST semantic analysis and optimization suggestion generation. This invention focuses on model layer difference encapsulation, not AST analysis.

[0033] Patent document CN120162239A discloses an intelligent code review method and system based on a large language model, with an end-to-end algorithm scheme, no agent layer encapsulation, no multi-model scheduling, and no Prompt template management.

[0034] Patent document CN121560720A discloses a code style review method, device and electronic device based on a combination of large language model and static code inspection tool. The scheduling objects are different (static tool vs. multiple LLM), the architecture is different (MCP vs. custom agent), and the decision dimensions are different (rule type vs. code feature). Summary of the Invention

[0035] To address the shortcomings of the existing technology, this invention provides a hybrid intelligent code review system and method based on model proxy layer encapsulation; by uniformly encapsulating the differences between multiple models through the model proxy layer, the Jenkins pipeline can achieve seamless switching of the underlying model; a Prompt template management mechanism for enterprise code standards is constructed to achieve versioned accumulation and dynamic loading of standards; and a hybrid model intelligent scheduling strategy is designed to dynamically select local / online models based on code characteristics, balancing cost and quality.

[0036] To solve the above-mentioned technical problems, the present invention is implemented using the following technical solution:

[0037] A hybrid intelligent code review system based on a model proxy layer encapsulation is proposed. A model proxy layer is set up between the CI / CD pipeline scheduling layer and the model service layer. The model proxy layer has a unified interface encapsulation. The model proxy layer dynamically loads Prompt templates from independent directories to achieve version management of enterprise standards and code decoupling. When there are differences in the output formats of different models, the model proxy layer responds with standardized parsing.

[0038] Furthermore, the unified interface encapsulation of the model proxy layer means that the model proxy layer encapsulates model differences in an independent Flask service and exposes a unified interface to the outside world. All proxy services implement RESTful interfaces, and the unified interface protocol shields the underlying model differences.

[0039] Furthermore, the standardized parsing of model proxy layer responses refers to the model proxy layer uniformly parsing the responses into a standard issue list structure.

[0040] Furthermore, the standardized list of issues is converted into Gerrit-readable Markdown format and formatted for Jenkins-style output.

[0041] A hybrid intelligent code review method based on model proxy layer encapsulation is proposed. By encapsulating the standardized interface of the model proxy layer, the differences of the underlying model are shielded. The code specification is decomposed into system role definition sys_prompt and user input template user_tpl, which are stored in separate directories. Based on the intelligent routing algorithm of code features, a single optimal model is dynamically selected.

[0042] Furthermore, the intelligent routing algorithm based on code features dynamically selects a single optimal model, specifically including: extracting multi-dimensional features of the code; establishing a model capability profile; using a multi-factor decision algorithm to dynamically select the optimal model; and designing a multi-level fallback mechanism.

[0043] Furthermore, the code's multidimensional features include file type, language type, code complexity, number of lines of change, and security keywords;

[0044] The establishment of model capability profiles refers to the establishment of a knowledge base for the capability boundaries of each model;

[0045] The multi-factor decision algorithm is the design of a multi-factor decision function;

[0046] The aforementioned multi-level fallback mechanism is designed to provide three levels of fault tolerance:

[0047] Level 1: The model is initially deemed normal; then the review results are returned.

[0048] Level 2: If the preferred model times out, the system will automatically switch to a backup local model.

[0049] Level 3: All models fail, then return "Review service error, please review manually" and mark CI as Unstable.

[0050] Furthermore, the code specification is optimized based on historical review data, specifically including:

[0051] (1) Standardized version management: Prompt templates are incorporated into Git version control to standardize the update process; the proxy service automatically pulls the latest templates through Git Webhook;

[0052] (2) Review data accumulation: Record the complete context of each review in the model proxy layer;

[0053] (3) Model fine-tuning feedback: Extract samples of "valid issues confirmed by humans but not detected by AI" from the database, and continuously optimize the local model based on historical review data using parameter efficient fine-tuning technology. Parameter efficient fine-tuning includes, but is not limited to, low-rank adaptation, adapter fine-tuning, and prompt fine-tuning.

[0054] Furthermore, the Prompt template is incorporated into Git version control to standardize the update process, specifically including: modifying the template in the prompts / directory; submitting an MR to trigger CI verification; and after verification, updating the review status of the merge request or generating review feedback information.

[0055] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the above-described review method.

[0056] Compared with the prior art, the beneficial effects of the present invention are:

[0057] Effect 1: Zero code changes when switching models;

[0058] Through standardized interface encapsulation at the proxy layer, Jenkins Pipeline only needs to call the unified / review / markdown endpoint, without needing to know whether the underlying model is a local primary model, a local secondary model, or an online cloud service model. When switching models, only the proxy service needs to be restarted; Jenkins configuration remains unchanged, reducing operational risks by over 90%.

[0059] Effect 2: Enterprise standards are solidified and reused;

[0060] The code style guide is broken down into `sys_prompt` (system role definition) and `user_tpl` (user input template), stored in separate directories. When the style guide is updated, only the template file needs to be replaced, and all proxy services automatically load the new version. This achieves "configure once, reuse everywhere," improving style guide maintenance efficiency by more than 5 times.

[0061] Effect 3: Review costs reduced by 40%-60%;

[0062] By pre-analyzing code features (file type, code complexity, number of lines of change), intelligent routing is used to either the local model (cost ≈ 0, latency < 2s) or the online model (high cost, latency 3-5s). Real-world testing shows that approximately 65% ​​of simple formatting issues can be accurately identified by the local model, while only 35% of complex issues require calling the online model, resulting in a 55% reduction in overall API call costs.

[0063] Result 4: Review availability reached 99.9%;

[0064] The system employs a multi-level fallback mechanism: online model timeout → automatic degradation to local model → local model failure → return to default pass and issue an alert. This avoids single points of failure that could block the CI pipeline and ensures the continuity of the development process. Attached Figure Description

[0065] The invention will now be further described with reference to the accompanying drawings:

[0066] Figure 1 This is a diagram illustrating the overall architecture of a hybrid intelligent code review system based on a model proxy layer, as described in this invention.

[0067] Figure 2 This is a sequence diagram of the Jenkins Pipeline.

[0068] Figure 3 This is a flowchart of the internal processing of the model proxy layer;

[0069] Figure 4 A diagram illustrating how the proxy layer dynamically loads the Prompt template from an independent directory;

[0070] Figure 5 Example of template file content Figure 1 ;

[0071] Figure 6 Example of template file content Figure 2 ;

[0072] Figure 7 A diagram illustrating the standardized issue list structure for unified parsing by the proxy layer;

[0073] Figure 8 A diagram illustrating the process of converting a standardized list of issues into a Gerrit-readable Markdown format;

[0074] Figure 9 This is a diagram illustrating the process before calling the Jenkins Pipeline.

[0075] Figure 10 This is a diagram illustrating the process after a Jenkins Pipeline call.

[0076] Figure 11 This is a diagram illustrating the extraction of multidimensional features from change files in Jenkins Step-2.

[0077] Figure 12 A schematic diagram for designing a multi-factor decision function;

[0078] Figure 13 A complete context diagram for recording each review at the proxy layer;

[0079] Figure 14This is a schematic diagram of the submission specification verification for Example 1;

[0080] Figure 15 This is a schematic diagram of the modified document detection in Example 1;

[0081] Figure 16 This is a schematic diagram illustrating the AI ​​review process in Example 1.

[0082] Figure 17 This is a schematic diagram illustrating the write-back of the review results from Example 1 to Gerrit.

[0083] Figure 18 This is a diagram illustrating how maintenance personnel modify environment variables in the Jenkins configuration, as shown in Example 2.

[0084] Figure 19 This is a schematic diagram illustrating the modification of java_review.sys.prompt in Example 3. Detailed Implementation

[0085] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be described in more detail below with reference to the accompanying drawings. In the drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described embodiments are some, but not all, embodiments of this invention. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this invention, and should not be construed as limiting the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention. The embodiments of this invention will be described in detail below with reference to the accompanying drawings.

[0086] The present invention will now be described in detail with reference to the accompanying drawings:

[0087] I. Overall Architecture of a Hybrid Intelligent Code Review System Based on Model Proxy Layer

[0088] This invention proposes a three-tiered hybrid intelligent code review system, such as... Figure 1 , Figure 2 As shown;

[0089] The three-tier architecture consists of: CI / CD pipeline scheduling layer (Jenkins), model proxy layer, and model service layer; the CI / CD pipeline scheduling layer (Jenkins) is the continuous integration and continuous delivery pipeline layer (Jenkins).

[0090] II. Key Technical Solution 1: Standardized Encapsulation of the Model Proxy Layer;

[0091] 1. Technical Problems and Solutions

[0092] In existing technologies, Jenkins Pipeline directly calls large model APIs, causing model differences to intrude into business logic. This invention introduces a Model Proxy Layer, such as... Figure 3 As shown, the model differences are encapsulated in a separate Flask service, exposing a unified interface to the outside world.

[0093] 2. Specific Implementation Plan

[0094] (1) Unified interface definition

[0095] All proxy services implement the following RESTful interfaces, as shown in Table 1:

[0096] Table 1

[0097] / review / markdown POST {"filename": str, "code": str, "job_name": str, "mr_id": str} {"message": str}

[0098] Description of request body fields:

[0099] filename: The filename to be reviewed (used to determine the language type and review rules);

[0100] code: The text containing the code;

[0101] job_name: Jenkins task name (used for log tracking);

[0102] mr_id: Gerrit Change number (used to associate review records);

[0103] The message field in the response body is a Markdown-formatted string containing the review conclusion (pass / list of issues), which can be directly written back to Gerrit.

[0104] (2) Prompt template management

[0105] The proxy layer dynamically loads the Prompt template from an independent directory, achieving decoupling between specifications and code, such as... Figure 4 As shown;

[0106] Example of template file content: ava_review.sys.prompt, such as... Figure 5 As shown;

[0107] java_review.user.tpl, such as Figure 6 As shown;

[0108] (3) Analytical standardization of multi-model response

[0109] Different models have different output formats, and the proxy layer uniformly parses them into a standard `issues` list structure, such as... Figure 7 As shown;

[0110] (4) Jenkins-style output formatting

[0111] Convert the standardized list of issues into a Gerrit-readable Markdown format, such as... Figure 8 As shown;

[0112] 3. Mechanism of beneficial effects

[0113] Through the above encapsulation, Jenkins Pipeline calls can be made from... Figure 9 The diagram is simplified to Figure 10 As shown;

[0114] When you need to switch models, simply:

[0115] Deploy a new proxy service (new port);

[0116] Modify the Jenkins environment variable PROXY_URL=http: / / <proxy service IP>:<new port>;

[0117] No need to modify the Pipeline script logic.

[0118] III. Key Technical Solution Two: Hybrid Model Intelligent Scheduling Strategy;

[0119] 1. Technical Problems and Solutions

[0120] Existing parallel calling schemes (calling multiple models simultaneously) result in resource waste. This invention proposes an intelligent routing algorithm based on code features to dynamically select a single optimal model.

[0121] 2. Specific Implementation Plan

[0122] (1) Code feature extraction

[0123] In Jenkins Step-2, extract multidimensional features of the changed files, such as... Figure 11 As shown;

[0124] (2) Model capability portrait

[0125] Establish a knowledge base for the capability boundaries of each model, as shown in Table 2.

[0126] Table 2

[0127] First local model (Level 7B) Syntax rules, naming checks, simple null pointers Cross-file architecture, complex design patterns 0 <2s Second local model (Level 9B) Code generation, commenting standards, and Chinese language scenarios Long English texts, complex algorithms 0 <3s Cloud service model (hundreds of billions) Architecture design, security vulnerabilities, performance optimization Basic syntax (too costly) high 3-5s

[0128] (3) Intelligent routing decision algorithm

[0129] Design multi-factor decision functions, such as Figure 12 As shown; the design of the multi-factor decision function is an existing technology.

[0130] (4) Fallback mechanism

[0131] Design with three levels of fault tolerance:

[0132] Level 1: Preferred model is normal → Return review results;

[0133] Level 2: Preferred model timeout (>5s) → Automatically switch to backup local model;

[0134] Level 3: All models fail → Return "Review service error, please review manually" and mark CI as Unstable (non-blocking merge).

[0135] 3. Mechanism of beneficial effects

[0136] Taking a real-world scenario as an example, as shown in Table 3:

[0137] Table 3

[0138] Add a Java Bean with only field getter / setter methods. Low complexity, no security keywords First local model 100% (Unadjusted cloud service model) Modify SQL concatenation logic Contains "SELECT" / "WHERE" keywords Forced routing to cloud service model 0% (but to avoid missed detections) Refactor the Service layer interface Spanning multiple files, high complexity Second local model initial screening + cloud service review 50% (not full cloud service)

[0139] IV. Key Technical Solution Three: Enterprise Standardization and Continuous Optimization

[0140] 1. Technical Problems and Solutions

[0141] Code standards need to be updated as business evolves (e.g., new technical standards are added due to expanding project issues), and existing technologies struggle to track the effectiveness of standard implementation. This invention designs a closed-loop optimization mechanism encompassing standards, data, and models.

[0142] 2. Specific Implementation Plan

[0143] (1) Standardize version management

[0144] Prompt templates are incorporated into Git version control to standardize the update process:

[0145] The quality team modified the template in the prompts / directory, where "prompts / " is the folder name currently used in the implementation.

[0146] Submitting a MapReduce (MR) triggers CI verification (verifying the detection rate using a test suite of historical issue codes).

[0147] Once verification is successful, a tag is added (e.g., java-review-v2.3), and the review status of the merge request is updated or review feedback information is generated.

[0148] The proxy service automatically pulls the latest templates via Git Webhook.

[0149] (2) Reviewing the data accumulation

[0150] Record the complete context of each review at the proxy layer, such as Figure 13 As shown.

[0151] 3. Mechanism of the beneficial effects

[0152] This forms a closed loop of "standard definition → automatic review → manual confirmation → model optimization":

[0153] The updated specifications will take full effect within 24 hours (no service restart required).

[0154] As data accumulates, the detection rate of the local model increases from 75% initially to 92%; reducing reliance on external cloud service models leads to lower long-term costs.

[0155] Example 1: Java code style review scenario

[0156] Scenario Description: A developer submits a Gerrit Change, modifying UserService.java and adding SQL query logic. Step-1: Submit for specification validation, such as... Figure 14 As shown;

[0157] Step-2: Change document detection, such as... Figure 15 As shown;

[0158] Step-3 AI review execution, such as Figure 16 As shown;

[0159] The review results are written back to Gerrit, such as Figure 17 As shown.

[0160] Example 2: Model Hot Switching Scenario

[0161] Scenario: Due to cloud service provider maintenance / partner switching, it is necessary to temporarily switch to the local second model.

[0162] Operating steps:

[0163] Operations personnel modify environment variables in the Jenkins configuration, such as... Figure 18 As shown;

[0164] All subsequent AI review requests will be automatically routed to the second local model without requiring modifications to the Pipeline script;

[0165] After maintenance, modify the environment variables to switch back to the third-party proxy service;

[0166] Beneficial effects: The switchover process involves zero code changes, can be completed within 5 minutes, and is seamless in the development process.

[0167] Example 3: Standard Update Scenario

[0168] Scenario: The quality team has added a "Thread Safety Specification for In-Vehicle Systems" and requires a review of Handler usage.

[0169] Operating steps:

[0170] Modify java_review.sys.prompt to add a fourth point to the review priorities, such as... Figure 19 As shown;

[0171] Submit Git tag java-review-v2.4;

[0172] The proxy service automatically detects tag updates via Webhook and reloads the Prompt accordingly.

[0173] Ten minutes later, the new specification was automatically applied to the newly submitted Change.

[0174] This invention features a standardized encapsulation architecture for the model proxy layer, introducing an independent proxy layer between the CI / CD pipeline and heterogeneous large models; a unified interface protocol ( / review / markdown) shields the differences in the underlying models (local GGUF / online API); and the Prompt template is decoupled from the executable code, enabling versioned management of enterprise standards.

[0175] This invention presents a hybrid model intelligent scheduling method based on code features, which extracts multi-dimensional code features (language type, complexity, security keywords); establishes a model capability profile (accuracy / cost / latency); dynamically selects the optimal model using a multi-factor decision algorithm; and ensures service availability through a fallback mechanism.

[0176] This invention employs a closed-loop optimization mechanism of standardization, data, and model, with review data being persistently stored (time-series database); manual confirmation results being fed back to the model for fine-tuning; and the capabilities of the local model continuously evolving as data accumulates.

[0177] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a hybrid intelligent code review method based on model proxy layer encapsulation. This hybrid intelligent code review method includes: encapsulating code through a standardized interface of the model proxy layer to shield underlying model differences; decomposing code specifications into system role definitions (sys_prompt) and user input templates (user_tpl), storing them in separate directories; and using an intelligent routing algorithm based on code features to dynamically select a single optimal model.

[0178] The computer-readable storage medium provided by the present invention has computer-executable instructions that are not limited to the method operations described above, but can also execute related operations in the hybrid intelligent code review method based on model proxy layer encapsulation provided in any embodiment of the present invention.

[0179] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0180] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line DSL) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk, SSD), etc.

[0181] 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 modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be included within the scope of protection of the present invention. Furthermore, all content not described in detail in this specification is prior art known to those skilled in the art.

Claims

1. A hybrid intelligent code review system based on a model proxy layer encapsulation, characterized in that: A model proxy layer is set up between the CI / CD pipeline scheduling layer and the model service layer; the model proxy layer has a unified interface encapsulation; the model proxy layer dynamically loads Prompt templates from an independent directory to achieve enterprise-standard version management and code decoupling; the model proxy layer responds with standardized parsing when there are differences in the output formats of different models.

2. The hybrid intelligent code review system based on model proxy layer encapsulation according to claim 1, characterized in that: The unified interface encapsulation of the model proxy layer refers to the model proxy layer encapsulating model differences in an independent Flask service and exposing a unified interface to the outside world. All proxy services implement RESTful interfaces, and the unified interface protocol shields the underlying model differences.

3. The hybrid intelligent code review system based on model proxy layer encapsulation according to claim 1, characterized in that: The standardized parsing of model proxy layer responses refers to the unified parsing of model proxy layer responses into a standard issue list structure.

4. The hybrid intelligent code review system based on model proxy layer encapsulation according to claim 3, characterized in that: Convert the standardized list of issues into a Gerrit-readable Markdown format and output it in a Jenkins-style format.

5. The review method of a hybrid intelligent code review system based on model proxy layer encapsulation according to any one of claims 1 to 4, characterized in that: By standardizing the interface encapsulation of the model proxy layer, the differences in the underlying models are shielded, and the code specifications are decomposed into system role definitions sys_prompt and user input templates user_tpl, which are stored in separate directories; an intelligent routing algorithm based on code features dynamically selects a single optimal model.

6. The examination method according to claim 5, characterized in that, The intelligent routing algorithm based on code features dynamically selects a single optimal model. Specifically, it includes: extracting multi-dimensional features of the code; establishing a model capability profile; using a multi-factor decision algorithm to dynamically select the optimal model; and designing a multi-level fallback mechanism.

7. The examination method according to claim 6, characterized in that: The code features include file type, language type, code complexity, number of lines changed, and security keywords; The establishment of model capability profiles refers to the establishment of a knowledge base for the capability boundaries of each model; The multi-factor decision algorithm is the design of a multi-factor decision function; The aforementioned multi-level fallback mechanism is designed to provide three levels of fault tolerance: Level 1: The model is initially deemed normal; then the review results are returned. Level 2: If the preferred model times out, the system will automatically switch to a backup local model. Level 3: All models fail, then return "Review service error, please review manually" and mark CI as Unstable.

8. The examination method according to claim 5, characterized in that, The code style guidelines are optimized based on historical review data, specifically including: (1) Standardized version management: The Prompt template is incorporated into Git version control to standardize the update process; the proxy service automatically pulls the latest template through GitWebhook; (2) Review data accumulation: Record the complete context of each review in the model proxy layer; (3) Model fine-tuning feedback: Extract samples of "valid issues confirmed by humans but not detected by AI" from the database, and continuously optimize the local model based on historical review data using parameter efficient fine-tuning technology. Parameter efficient fine-tuning includes, but is not limited to, low-rank adaptation, adapter fine-tuning, and prompt fine-tuning.

9. The examination method according to claim 8, characterized in that, The Prompt template is incorporated into Git version control to standardize the update process, which specifically includes: modifying the template in the prompts / directory; submitting a MapReduce (MR) to trigger CI verification; and updating the review status of the merge request or generating review feedback information after verification.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by the processor, it implements the review method as described in any one of claims 5-9.

Citation Information

Patent Citations

  • Code review and optimization method driven by large language model

    CN119512556A

  • Code review method based on large language model and related equipment

    CN119883358A

  • Intelligent code review method and system based on large language model

    CN120162239A

  • Code specification review method and device based on combination of large language model and static code check tool and electronic equipment

    CN121560720A