A method and system for constructing a large model-based code review assistant

Abstract

The application discloses a kind of construction methods and systems of code review assistant based on large model, the construction method includes: developer is submitted to internal network Git hosting service Push;Internal pipeline triggers review task, obtains the file list and increase and delete content involved in this push;According to warehouse, branch or configuration file mapping to the project group, load the review rule text, applicable language list and Skills file corresponding to the project group;Large model review engine is deployed on the inference service or approved internal network model gateway of internal network, and adopts not to pass notification and author mailbox analysis algorithm;Carry out multi-round review until pass;Excel statistics and monthly summary are carried out.A set of code review assistant technical scheme is constructed from Git change acquisition, according to team rules and large model skill review, not to pass according to analysis rule email, multiple rounds until pass, whole process metadata statistics and periodic summary, improve standard landing rate and process traceability.

Description

Technical Field

[0001] This invention relates to the field of manual code review, and in particular to a method and system for constructing a code review assistant based on a large model. Background Technology

[0002] Program development typically takes place on the intranet, with code hosted on an intranet Git service. Manual code reviews after submission suffer from inconsistent timelines, varying standards, and disconnects from project team guidelines. Large language models, capable of understanding natural language rules and multi-language source code, can be integrated with automated pipelines to conduct rule-based reviews of intranet-visible changes after submission. Furthermore, the intranet is isolated from the internet; model capabilities or rule updates must be verified in the external System Testing Environment (SIT) before being synchronized to the intranet, creating a deployment constraint of "external verification – intranet implementation."

[0003] Existing technical solutions: 1. Manual review: Relies on the reviewer's experience, is asynchronous with Git commits, and is difficult to match with each commit one by one and track in multiple rounds.

[0004] 2. Rule checks based on static analysis tools: effective for syntax and some defect patterns, but difficult to cover items that require semantic understanding, such as "project team natural language specifications" and "cross-document intent".

[0005] 3. Public network SaaS code review or AI review: Relies on external network APIs and code going outside the domain, data security and authenticity are uncontrollable.

[0006] Disadvantages of existing technology: 1. In an intranet environment, it is difficult to securely and consistently utilize the capabilities of large models to complete and submit reviews.

[0007] 2. Different teams use different programming languages ​​and standards, making it impossible to adapt to a single universal rule and lacking a loadable "rule + language" skill mechanism.

[0008] 3. The feedback channels after a review fails are not automatically linked to the Git author information, and manually searching for the author is not conducive to a closed loop.

[0009] 4. Lack of unified status management and auditable statistics for the multiple rounds of "failure-revision-re-evaluation".

[0010] 5. The lack of summary analysis by calendar month or fixed time point is not conducive to R&D quality management. Summary of the Invention

[0011] In view of the above problems, the present invention is proposed to provide a method and system for constructing a code review assistant based on a large model to overcome or at least partially solve the above problems.

[0012] According to one aspect of the present invention, a method for constructing a code review assistant based on a large model is provided, the method comprising: Developers push commits to the internal Git hosting service; The internal network pipeline triggers a review task to obtain a list of files involved in this push and the content that has been added, deleted, or modified. Map the repository, branch, or configuration file to the project group it belongs to, and load the review rule text, applicable language list, and Skills file corresponding to the project group. The large model review engine is deployed on an inference service within the intranet or on an approved intranet model gateway, and uses an algorithm that does not resolve data via notification and author email. Multiple rounds of review are conducted until approval is granted; Perform Excel statistics and monthly summaries.

[0013] Optionally, the developer's push submission to the internal Git hosting service specifically includes: the merge results of the same product line on the external network first enter SIT, and after verification, they are synchronized in a controlled manner to the same source or mirror repository on the internal network.

[0014] Optionally, the intranet pipeline triggering a review task to obtain the list of files involved in this push and the content of additions, deletions, and modifications specifically includes: The internal Git service provides read-only credentials for the API or Runner; Change extraction is performed on the intranet to ensure the code does not leave the domain; External SIT is only used for verifying merge and assistant versions / rule packages; Once approved, the image submission or artifact will be synchronized to the intranet via the whitelist synchronization channel. On the intranet side, the same diff extraction logic as the intranet repository will still be triggered by the Push event or image update event.

[0015] Optionally, the step of mapping to the project group based on the repository, branch, or configuration file, and loading the review rule text, applicable language list, and Skills file corresponding to the project group specifically includes: Maintain a mapping table in the repository root directory or organization-level configuration: repository / branch / tag → team identifier → rule version number; Skills are stored in files and include: applicable languages, naming and style constraints, security red lines, performance considerations, and output JSON Schema; Loading steps: Parse configuration → Verify Skills syntax and version → Intersect with the language type of the current change → Merge into the final Prompt attachment.

[0016] Multilingual repositories can be split into multiple subtasks based on file extensions and called in parallel, then merged for judgment.

[0017] Optionally, the large model review engine is deployed on an inference service within the intranet or on an approved intranet model gateway, and employs an algorithm that does not rely on notifications or author email address parsing. Specifically, this includes: The large model review engine assembles "change diff + rule + skill" into a hint on the inference service deployed on the intranet or on the approved intranet model gateway, and calls the model to generate structured results; According to the rule definition, a Boolean conclusion is obtained; If the request fails: The author email parsing unit reads the submitted Author information; the email sending unit sends the review summary or link to the parsed address.

[0018] Optionally, the process of conducting multiple rounds of review until approval specifically includes: After the developer makes the changes, they push the task again, associating it with the previous state, and performing secondary and subsequent reviews until it passes or the policy limit is reached.

[0019] Optionally, the developer modifies and pushes the task again, associating it with the previous state, and performing secondary and subsequent reviews until it passes or the policy limit is reached. This specifically includes: Maintain the state machine using the business review form or merge request identifier and the target branch as the dimensions: Pending review → Not approved → Repaired and awaiting re-review → … → Approved; If each push lands on the same review form, the review round counter increments by one; the form is closed when the review is passed. Send an email when the conclusion is "not passed" or "blocking item changed".

[0020] Optionally, the Excel statistics and monthly summary specifically include: After each review, add a metadata record to Excel, without forcing the writing of the complete review text to meet storage and compliance requirements; The scheduler reads the monthly cumulative table at a fixed time each month, generates a summary view showing the maximum / minimum number of failures and the maximum / minimum number of repair rounds for each author, and outputs a new table or a new sheet of the same table.

[0021] Optionally, the step of appending a metadata record to Excel after each review, without mandating writing the complete review text to meet storage and compliance requirements, specifically includes: Example of fields written for each review: review time, repository, branch, commit SHA, author's original string, parsed email, team, language, pass / fail, round number, number of blocking items, and whether the notification was successful; Monthly Task: After a scheduled task is triggered, filter the records for the current month; Aggregated by parsed email or employee ID primary key: Number of rejections; Number of approvals; Distribution of repair rounds; Output ranking: most / fewest failures, most / fewest repair rounds.

[0022] This invention also provides a system for building a code review assistant based on a large model, which applies the above-described method for building a code review assistant based on a large model. The system includes: Developers push commits to the internal Git hosting service; The internal and external network and change acquisition module: the internal network pipeline triggers a review task and obtains the list of files involved in this push and the content of additions, deletions and modifications. The rules and skills loading module is used to map to the project group based on the repository, branch, or configuration file, and load the review rule text, applicable language list, and Skills file corresponding to the project group. The result determination module is used on the inference service deployed on the intranet or on the approved intranet model gateway of the large model review engine, and adopts an algorithm that does not use notifications or author emails for parsing. The iterative review scheduling module is used to conduct multiple rounds of review until approval is achieved; The statistics persistence module is used for Excel statistics and monthly summaries.

[0023] This invention provides a method and system for constructing a code review assistant based on a large model. The construction method includes: developers pushing commits to an internal Git hosting service; the internal pipeline triggers a review task, obtaining a list of files involved in the push and their added, deleted, and modified content; mapping repositories, branches, or configuration files to their respective project groups, loading the review rule text, applicable language list, and Skills file corresponding to the project group; the large model review engine is deployed on an inference service or an approved internal model gateway, employing a failure notification and author email parsing algorithm; multiple rounds of review are conducted until approval; and Excel statistics and monthly summaries are performed. This invention constructs a code review assistant technical solution that obtains Git changes, reviews according to team rules and large model skills, sends emails according to parsing rules for failures, conducts multiple rounds until approval, and performs full-process metadata statistics and periodic summaries, improving the implementation rate of standards and process traceability.

[0024] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

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

[0026] Figure 1 This invention provides an architecture diagram of a code review assistant building system based on a large model, as shown in the embodiments of the present invention. Figure 2 A single review data flow sequence diagram provided for embodiments of the present invention (trigger → diff → loading → inference → judgment → email / write table); Figure 3 A flowchart of author email parsing provided for embodiments of the present invention (branch: email / username / failure fallback). Figure 4 This is a multi-round review state transition diagram provided for embodiments of the present invention. Detailed Implementation

[0027] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0028] The terms "comprising" and "having," and any variations thereof, in the specification, embodiments, claims, and drawings of this invention are intended to cover non-exclusive inclusion, such as including a series of steps or units.

[0029] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0030] like Figure 1 As shown, a method for building a code review assistant based on a large model includes: (I) Overview of the overall process 1. Developers push submissions to the internal Git hosting service; merge results for the same product line on the external network first enter the SIT, and after verification, they are synchronized in a controlled manner (such as offline packages, one-way imports) to the same source or mirror repository on the internal network.

[0031] 2. The internal pipeline (Webhook or timed polling) triggers the review task. The Git change extraction unit obtains the list of files involved in this push and the added, deleted and modified content through gitdiff / git show / compare parent commits, etc. (preprocessing can be done by path filtering, size truncation, binary exclusion and other strategies).

[0032] 3. The rules and skills loading unit maps to the project group according to the repository, branch or configuration file, and loads the review rule text, applicable language list and Skills file corresponding to the group (Skills is a structured description for large models to follow, which may include check items, output format, positive and negative examples, etc.).

[0033] 4. The large model review engine assembles "change diff + rule + skill" into a prompt on the inference service deployed on the intranet or on the approved intranet model gateway, and calls the model to generate structured results (e.g., whether it passes, a list of violations, severity level, description of the file / line number, etc.).

[0034] 5. The result determination unit obtains a Boolean pass conclusion based on the rule definition (e.g., if any blocking item exists, it will not pass).

[0035] 6. If the submission fails: The author email parsing unit reads the submitted Author information; the email sending unit sends the review summary or link (which may not include the full text according to the intranet policy) to the parsed address.

[0036] 7. After the developer makes modifications, they push the task again. The iterative review scheduling unit associates the task with the previous state (such as the same Merge Request / same commit series or business-side review number) and performs secondary and subsequent reviews until it passes or reaches the policy limit (the limit can be written into the implementation example as a configurable item).

[0037] 8. After each review, the statistical persistence unit appends a metadata record to the Excel file (or equivalent spreadsheet file) (see field design below). Writing the complete review text is not mandatory to meet storage and compliance requirements. 9) The scheduled reporting unit uses a scheduler (such as cron or an intranet task platform) to read the monthly cumulative table at 09:00 on the last Thursday of each month (or the "last full week" rule defined in the calendar is hardcoded in the configuration and parsed by the program), generating a summary view: maximum / minimum number of rejections for each author, maximum / minimum number of repair rounds (number of reviews - 1 or number of times from the first rejection to approval), etc., and can output a new table or a new sheet of the same table.

[0038] The time sequence diagram of the data flow for a single review is as follows: Figure 2 As shown.

[0039] (II) Internal and External Networks and Change Acquisition 1. The intranet Git service provides read-only credentials for API or Runner; changes are extracted and executed on the intranet to ensure that the code does not leave the domain.

[0040] 2. External SIT is only used to verify merge and assistant version / rule package; after passing, the image submission or artifact is synchronized to the internal network through the whitelist synchronization channel. On the internal network side, the same diff extraction logic as the internal network repository is triggered by Push event or image update event.

[0041] 3. Technical points: Use commit SHA (or before / after SHA) as the key to cache the evaluated results and avoid repeated full scans.

[0042] (III) Project Team Rules, Languages ​​and Skills 1. Maintain a mapping table in the repository root directory or organization-level configuration: repository / branch / tag → team identifier → rule version number.

[0043] 2. Skills are stored in the form of files (such as Markdown / XML), and the content includes: applicable languages, naming and style constraints, safety red lines, performance considerations, output JSON Schema, etc.

[0044] 3. Loading steps: Parse configuration → Verify Skills syntax and version → Intersect with the language type of the current change → Merge into the final Prompt attachment.

[0045] 4. Multilingual repositories can be split into multiple subtasks based on file extensions and called in parallel, and then merged for judgment.

[0046] (iv) Not using notifications and author email parsing algorithms Input: Git author field string A, email fixed suffix S=@xx.com.

[0047] Branch 1: If A contains a standard email address (e.g., contains @ and conforms to common email patterns), then take the @ prefix substring P. Filter P for characters: retain letters, numbers, and allowed symbols (consistent with your company's account rules; examples include _, -, and .). Then, according to business rules, if "only letters are used for account matching," extract a continuous sequence of Latin letters from P as the primary account key (or map it to LDAP). Finally, concatenate the substrings to local@xx.com. If the prefix can be directly mapped to an email address from the mapping table, prioritize looking up the table. The author's email address parsing flowchart is as follows: Figure 3 As shown.

[0048] Branch 2: If A is a plain username (without @), then extract the letter characters from left to right (or according to the configured Unicode letter class) to form L; if L is not empty, then the email address is L + S; if it is empty (the username is a plain number or symbol), then fall back to other metadata or account mapping table in the commit log, otherwise mark it as undeliverable and write it to the statistics table "Notification of failure reason".

[0049] Output: List of recipient addresses (can be copied to project team email addresses).

[0050] The email body includes: repository, branch, commit SHA, failure summary, and link to internal review.

[0051] (v) Multiple rounds of review until approval 1. Maintain a state machine based on the business review form or merge request identifier and the target branch: Pending review → Failed → Fixed and awaiting re-review → … → Passed. The multi-round review state transition diagram is as follows: Figure 4 As shown.

[0052] 2. If each push lands on the same review form, the review round counter increments by one; the form is closed when it passes.

[0053] 3. Optional: Send an email only when the conclusion is "not passed" or "blocking item changed" to reduce harassment.

[0054] (vi) Excel statistics and monthly summary Examples of fields written for each review (excluding large model articles): review time, repository, branch, commit SHA, author's original string, parsed email, team, language, pass / fail, round number, number of blocking items, whether the notification was successful, etc.

[0055] Monthly task: After the scheduled task is triggered, filter the records for the current month.

[0056] Aggregated by parsed email or employee ID primary key: Number of rejections (or the number of times "participated in review and judged as rejection"); Number of approvals; Distribution of repair rounds (e.g., max(rounds)-1 from the first rejection to the final approval).

[0057] Output ranking: Most / least passing, most / least number of repair rounds ("least" is defined as a threshold, only authors with ≥N participation times are counted to avoid insufficient data for new employees).

[0058] Beneficial effects: Under the premise of intranet deployment, we will build a code review assistant technical solution that improves the implementation rate of standards and the traceability of the process by obtaining Git changes, reviewing according to team rules and large model skills, sending emails according to parsing rules if the review fails, going through multiple rounds until the review is passed, and collecting and periodically summarizing metadata throughout the process.

[0059] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for constructing a code review assistant based on a large model, characterized in that, The construction method includes: Developers push commits to the internal Git hosting service; The internal network pipeline triggers a review task to obtain a list of files involved in this push and the content that has been added, deleted, or modified. Map the repository, branch, or configuration file to the project group it belongs to, and load the review rule text, applicable language list, and Skills file corresponding to the project group. The large model review engine is deployed on an inference service within the intranet or on an approved intranet model gateway, and uses an algorithm that does not resolve data via notification and author email. Multiple rounds of review are conducted until approval is granted; Perform Excel statistics and monthly summaries.

2. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The developer's push submission to the internal Git hosting service specifically includes: the merge results of the same product line on the external network first enter the SIT, and after verification, they are synchronized in a controlled manner to the same source or mirror repository on the internal network.

3. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The internal network pipeline triggers a review task, which obtains the list of files involved in this push and the specific additions, deletions, and modifications, including: The internal Git service provides read-only credentials for the API or Runner; Change extraction is performed on the intranet to ensure the code does not leave the domain; External SIT is only used for verifying merge and assistant versions / rule packages; Once approved, the image submission or artifact will be synchronized to the intranet via the whitelist synchronization channel. On the intranet side, the same diff extraction logic as the intranet repository will still be triggered by the Push event or image update event.

4. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The step of mapping repositories, branches, or configuration files to their respective project groups and loading the review rule text, applicable language list, and Skills file corresponding to those project groups specifically includes: Maintain a mapping table in the repository root directory or organization-level configuration: repository / branch / tag → team identifier → rule version number; Skills are stored in files and include: applicable languages, naming and style constraints, security red lines, performance considerations, and output JSON Schema; Loading steps: Parse configuration → Verify Skills syntax and version → Intersect with the language type of the current change → Merge into the final Prompt attachment; Multilingual repositories can be split into multiple subtasks based on file extensions and called in parallel, then merged for judgment.

5. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The large model review engine is deployed on an inference service within the intranet or on an approved intranet model gateway, and employs an algorithm that does not rely on notifications or author email address parsing. Specifically, this includes: The large model review engine assembles "change diff + rule + skill" into a hint on the inference service deployed on the intranet or on the approved intranet model gateway, and calls the model to generate structured results; According to the rule definition, a Boolean conclusion is obtained; If the request fails: The author email parsing unit reads the submitted Author information; the email sending unit sends the review summary or link to the parsed address.

6. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The process of conducting multiple rounds of review until approval specifically includes: After the developer makes the changes, they push the task again, associating it with the previous state, and performing secondary and subsequent reviews until it passes or the policy limit is reached.

7. The method for constructing a code review assistant based on a large model according to claim 6, characterized in that, The developer's modification and subsequent push, linking the task to the previous state, and executing secondary and subsequent reviews until approval or the policy limit is reached, specifically includes: Maintain the state machine using the business review form or merge request identifier and the target branch as the dimensions: Pending review → Not approved → Repaired and awaiting re-review → … → Approved; If each push lands on the same review form, the review round counter increments by one; the form is closed when the review is passed. Send an email when the conclusion is "not passed" or "blocking item changed".

8. The method for constructing a code review assistant based on a large model according to claim 1, characterized in that, The specific steps for performing Excel statistics and monthly summaries include: After each review, add a metadata record to Excel, without forcing the writing of the complete review text to meet storage and compliance requirements; The scheduler reads the monthly cumulative table at a fixed time each month, generates a summary view showing the maximum / minimum number of failures and the maximum / minimum number of repair rounds for each author, and outputs a new table or a new sheet of the same table.

9. The method for constructing a code review assistant based on a large model according to claim 8, characterized in that, At the end of each review, a metadata record is appended to Excel. Writing the complete review text is not mandatory to meet storage and compliance requirements. Specifically, this includes: Example of fields written for each review: review time, repository, branch, commit SHA, author's original string, parsed email, team, language, pass / fail, round number, number of blocking items, and whether the notification was successful; Monthly Task: After a scheduled task is triggered, filter the records for the current month; Aggregated by parsed email or employee ID primary key: Number of rejections; Number of approvals; Distribution of repair rounds; Output ranking: most / fewest failures, most / fewest repair rounds.

10. A system for constructing a code review assistant based on a large model, comprising the method for constructing a code review assistant based on a large model as described in any one of claims 1-9, characterized in that, The construction system includes: Developers push commits to the internal Git hosting service; The internal and external network and change acquisition module: the internal network pipeline triggers a review task and obtains the list of files involved in this push and the content of additions, deletions and modifications. The rules and skills loading module is used to map to the project group based on the repository, branch, or configuration file, and load the review rule text, applicable language list, and Skills file corresponding to the project group. The result determination module is used on the inference service deployed on the intranet or on the approved intranet model gateway of the large model review engine, and adopts an algorithm that does not use notifications or author emails for parsing. The iterative review scheduling module is used to conduct multiple rounds of review until approval is achieved; The statistics persistence module is used for Excel statistics and monthly summaries.

Images