Code ai review method, system, device and storage medium of central warehouse architecture

Abstract

This invention provides a code AI review method, system, device, and storage medium with a central repository architecture. The method includes: constructing a centralized code review service repository to provide unified services for multiple business projects; receiving code change trigger signals and loading the review configuration for the corresponding business project; splitting multi-dimensional review tasks into multiple independent execution units and executing them in parallel, with each unit running in an independent context; creating a multi-level versioned storage directory based on code version identifiers and storing review results by dimension; submitting the review results to the central repository to generate an audit trail and pushing the review report to the code hosting platform. This invention, through unified management of the central repository and a multi-agent parallel architecture, achieves efficient access for multiple projects, significantly improved review efficiency, versioned traceability of review results, and a significant reduction in review costs.

Description

Technical Field

[0001] This invention relates to the field of code review, and more specifically, to a code AI review method, system, device, and storage medium for a central repository architecture. Background Technology

[0002] In the software development lifecycle, code review is a crucial step in ensuring code quality, identifying potential defects, and guaranteeing code standardization and security. With the increasing scale and iteration speed of software development, traditional manual code review methods have gradually revealed their inherent limitations and cannot meet the demands of modern DevOps practices for efficient, accurate, and traceable code reviews. Specifically, existing technologies suffer from the following significant technical shortcomings: Inefficient review processes and high coordination costs: Multi-dimensional code reviews typically involve multiple aspects such as code quality, performance, security, and standards, requiring reviewers with different expertise. This not only leads to a lengthy review process but also incurs high costs for cross-role and cross-team coordination and communication, severely slowing down the software delivery pipeline.

[0003] AI review faces challenges related to context accumulation and cost: Currently, using AI models for code review is an important technological direction. However, a single AI review task often requires analyzing the entire code change context, which is time-consuming. Furthermore, as the analysis deepens, the accumulation of contextual information can cause large language models to develop "illusions," leading to a decrease in the quality and stability of the output results. In addition, the high-performance models used to achieve accurate analysis have high token costs, especially when performing large-scale code searches, resulting in high costs for a single review and limiting the large-scale application of AI review technology.

[0004] Review results are scattered and cannot be traced: Existing review results are usually scattered in temporary logs of various continuous integration environments, lacking a centralized and persistent storage mechanism. This makes it impossible to effectively trace the review history. When it is necessary to review the code quality of a certain historical version or analyze the cause of an issue, it is impossible to obtain the accurate review results at that time, leading to difficulties in problem localization.

[0005] High barriers to entry for multiple projects and difficulty in reusing infrastructure: For organizations with multiple business projects, each project requires building an independent review environment, including configuring CI / CD processes, adapting AI models, and defining review rules. This repetitive configuration work is not only voluminous but also makes it difficult to ensure consistency in review standards. The lack of a unified infrastructure reuse mechanism makes it extremely difficult to promote AI code review in a multi-project environment.

[0006] In summary, existing technologies cannot effectively solve the problems of deeply integrating AI code review with version management in development scenarios with multiple projects, multiple dimensions, and high-frequency iterations, such as achieving strong correlation between review results and code versions, permanent traceability of review history, and unified reuse of review infrastructure.

[0007] In view of this, the present invention provides a code AI review method, system, device and storage medium for a central repository architecture. Summary of the Invention

[0008] To address the problems in existing technologies, the present invention aims to provide a code AI review method, system, device, and storage medium with a central repository architecture. It overcomes the difficulties of existing technologies and enables efficient access to multiple projects, significantly improved review efficiency, version-based traceability of review results, and significant reduction in review costs through unified management of the central repository and a multi-Agent parallel architecture.

[0009] Embodiments of the present invention provide a code AI review method for a central repository architecture, comprising the following steps: S110. Build a centralized code review service repository and adopt a centralized multi-project service architecture to provide unified code review services for multiple business projects; S120. Establish an independent working directory for each business project in the central warehouse to store the review configuration corresponding to the business project and configure the loading priority. S130. Receive a code change trigger signal from any business project, parse the project information contained in the code change trigger signal, and load the corresponding review configuration from the working directory of the business project. S140. Based on the loaded review configuration, the multi-dimensional code review task is split into multiple independent execution units, each corresponding to a review dimension. S150: Trigger each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context and generates review results. S160. Based on the code version identifier in the project information, create a multi-level versioned storage directory in the central repository, and store the review results generated by each execution unit in the storage directory according to the dimension. S170. Submit the versioned storage review results to the central repository to generate an audit trail containing complete context information; S180. The review report generated based on the review results will be automatically pushed to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located.

[0010] Preferably, in step S120, the working directory includes: a workflow directory, used to store the review configurations for each business project, wherein the review configurations include at least project-specific review rules, model selection strategies, and task splitting definitions; The configuration loading priority is configured such that project-specific configurations have a higher priority than the system default configurations.

[0011] Preferably, in step S140, the multi-dimensional code review includes at least two of the following: code quality review, submission information review, merge request review, performance analysis, specification check, and security audit.

[0012] Preferably, in step S150, each execution unit executes the corresponding AI code review task in an independent context environment, including: creating an independent sub-agent for each execution unit; each sub-agent has a context environment independent of other sub-agents and does not inherit the context information in the execution process of other sub-agents; limiting the search scope of each sub-agent, allowing it to search only for files or code snippets related to the current review dimension.

[0013] Preferably, step S150 further includes a hierarchical model selection strategy: according to the complexity of the review dimension corresponding to the execution unit, different performance AI models are assigned to different execution units; wherein, according to the preset judgment rules based on the complexity of the review dimension, the review dimension judged as a complex analysis task uses a high-performance AI model, and the review dimension judged as a regular review task uses an economical AI model.

[0014] Preferably, in step S160, the multi-level versioned storage directory structure includes four levels: The project directory is used to store all review history for the corresponding business projects; The branch directory, located below the project directory, is used to store review results by code branch; the merge request or iteration version directory, located below the branch directory, is used to store review results by merge request or iteration version identifier. The code version directory, located below the merge request or iteration version directory, is used to store the review results by code version identifier; The code version directory contains at least the following: a log subdirectory for storing execution logs of each execution unit according to the review dimension; a report subdirectory for storing comprehensive review reports; a code change file for recording code changes that trigger reviews; and a project metadata file for storing metadata information of the business project.

[0015] Preferably, in step S170, generating an audit trail containing complete context information includes: After each review task is completed, a code hosting commit operation is automatically performed in the central repository. The commit information generated by the code hosting commit operation includes at least the project name, branch, merge request or iteration version identifier, code version identifier, and the currently executed review dimension from the project information. The code hosting version control mechanism enables the review history to be immutable and permanently traceable, and supports review history queries by at least one dimension: project, branch, merge request or iteration version, and code version identifier.

[0016] Embodiments of the present invention also provide a code AI review system for a central repository architecture, used to implement the above-described code AI review method for a central repository architecture, wherein the code AI review system for a central repository architecture includes: The central repository module builds a centralized code review service repository, adopting a centralized multi-project service architecture to provide unified code review services for multiple business projects; The configuration management module establishes an independent working directory for each business project in the central repository to store the review configuration corresponding to the business project and configure the loading priority. The task splitting module receives a code change trigger signal from any business project, parses the project information contained in the code change trigger signal, and loads the corresponding review configuration from the working directory of the business project. The parallel execution module, based on the loaded review configuration, breaks down the multi-dimensional code review task into multiple independent execution units, each corresponding to a review dimension; The context isolation module triggers each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context environment and generates review results. The versioned storage module creates a multi-level versioned storage directory in the central repository based on the code version identifier in the project information, and stores the review results generated by each execution unit into the storage directory according to the dimension. The audit trail module submits the versioned review results to the central repository, generating an audit trail containing complete contextual information. The results push module will automatically push the review report generated based on the review results to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located.

[0017] Embodiments of the present invention also provide a code AI review device with a central repository architecture, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the code AI review method for the central repository architecture by executing the executable instructions.

[0018] Embodiments of the present invention also provide a computer-readable storage medium for storing a program that, when executed, implements the steps of the code AI review method of the above-described central repository architecture.

[0019] The purpose of this invention is to provide a code AI review method, system, device and storage medium with a central repository architecture. It can achieve efficient access of multiple projects, a significant improvement in review efficiency, version traceability of review results and a significant reduction in review costs through unified management of the central repository and a multi-Agent parallel architecture. Attached Figure Description

[0020] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0021] Figure 1 This is a flowchart of the code AI review method for the central repository architecture of the present invention.

[0022] Figure 2 This is a system architecture diagram of the code AI review system of the central repository architecture of the present invention.

[0023] Figure 3 This is a schematic diagram of the code AI review device of the central warehouse architecture of the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0025] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0026] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0027] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0028] Furthermore, the terms "first" and "second" are used for illustrative purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the representation of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0029] For the purpose of clearly describing this application, devices that are not relevant to the description are omitted, and the same or similar components throughout the specification are given the same reference numerals.

[0030] Throughout this specification, when it is said that a device is "connected" to another device, this includes not only "direct connection" but also "indirect connection" by placing other components in between. Furthermore, when it is said that a device "comprises" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather implies that other constituent elements may be included.

[0031] When we say that a device is "above" another device, this can mean that it is directly above the other device, or it can mean that other devices are present in between. Conversely, when we say that a device is "directly" "above" another device, there are no other devices present in between.

[0032] Although the terms first, second, etc., are used in some instances herein to refer to various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, first interface and second interface, etc., are used. Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to also include the plural forms unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition will only occur if the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0033] The technical terms used herein are for reference only to specific embodiments and are not intended to limit the scope of this application. The singular form used herein includes the plural form unless the statement explicitly indicates otherwise. The word "comprising" as used in the specification means to specify a particular characteristic, region, integer, step, operation, element, and / or component, and does not exclude the presence or addition of other characteristics, regions, integers, steps, operations, elements, and / or components.

[0034] Although not explicitly defined, all terms, including technical and scientific terms used herein, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. Terms defined in commonly used dictionaries shall be further interpreted as having a meaning consistent with the relevant technical literature and the content of this present application, and shall not be over-interpreted as having an ideal or overly formulaic meaning unless otherwise defined.

[0035] Figure 1 This is a flowchart of the code AI review method for the central repository architecture of this invention. Figure 1 As shown, the code AI review method for the central repository architecture of the present invention includes the following steps: S110. Build a centralized code review service repository and adopt a centralized multi-project service architecture to provide unified code review services for multiple business projects; S120. Establish an independent working directory for each business project in the central repository to store the review configuration corresponding to the business project and configure the loading priority. S130. Receive a code change trigger signal from any business project, parse the project information contained in the code change trigger signal, and load the corresponding review configuration from the working directory of the business project. S140. Based on the loaded review configuration, the multi-dimensional code review task is split into multiple independent execution units, each corresponding to a review dimension. S150: Trigger each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context and generates review results. S160. Based on the code version identifier in the project information, create a multi-level versioned storage directory in the central repository, and store the review results generated by each execution unit in the storage directory according to the dimensions. S170. Submit the versioned storage review results to the central repository to generate an audit trail containing complete context information; S180. The review report generated based on the review results will be automatically pushed to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located.

[0036] In this embodiment, the code change trigger signal is sent from the code hosting platform associated with the business project to the central repository via a Webhook mechanism. The trigger signal is encapsulated in JSON format and includes at least the project identifier, trigger branch name, merge request or iteration version number, code commit hash value, and trigger timestamp. Upon receiving the signal, the central repository first performs signature verification to ensure the legitimacy and integrity of the request source. After successful verification, the aforementioned project information is parsed. When triggering each execution unit in parallel, an asynchronous task distribution mechanism based on a message queue is adopted. Each execution unit is encapsulated as an independent task message and pushed to a work queue, where it is consumed concurrently by multiple pre-deployed executor nodes, achieving distributed parallel execution of tasks. The review results generated by each execution unit are temporarily stored in a local temporary storage area in a structured format (JSON, YAML, or Markdown). After all associated execution units have completed, a unified versioned storage operation is performed. This invention, through Webhook and signature verification mechanisms, ensures the real-time performance and security of the trigger signal, avoiding the risk of attacks on the review system by illegal requests. By adopting an asynchronous task distribution and distributed executor architecture based on message queues, the originally serially executed review tasks are transformed into parallel execution. The total review time is changed from the sum of the times of each dimension to the time of the longest-running dimension, significantly improving review efficiency, especially demonstrating good horizontal scalability in high-concurrency scenarios. The structured result temporary storage and unified storage mechanism ensures the atomic submission of multi-dimensional review results, avoiding the problem of incomplete historical records caused by missing results of some dimensions, and providing a complete data foundation for subsequent audit traceability.

[0037] In a preferred embodiment, in step S120, the working directory includes: a workflow directory, used to store the review configurations for each business project. The review configurations include at least project-specific review rules, model selection strategies, and task splitting definitions. The configuration loading priority is configured such that project-specific configurations have higher priority than the system default configurations. In this embodiment, the workflow directory is located in the root directory of the central repository, and its internal structure is organized according to the path rule workflow / {projectName} / .claude / , where {projectName} is the unique identifier of the business project. The review configurations for each business project include at least: a config.json file, used to define project-specific review rules (such as the upper limit of lines of code, cyclomatic complexity threshold, naming convention regular expressions), model selection strategies (specifying the AI ​​model type and version for different review dimensions), and task splitting definitions (clarifying which review dimensions need to be executed in the current project); a claude.md file, used to provide behavioral guidance and contextual background descriptions during AI review, such as project architecture description, core business logic, common problem patterns, etc.; and a .mcp.json file, used to define the connection configuration of the Model Context Protocol, including model server endpoints, authentication credentials, timeout, etc. The specific implementation of configuration loading priority is as follows: When the central repository CI / CD pipeline starts, it first attempts to read workflow / {projectName} / .claude / config.json; if the file does not exist or reading fails, it automatically copies the default configuration file from the pre-set template / .claude / directory in the central repository to the project working directory and uses the default configuration to execute review tasks; if the default template is also unavailable, it falls back to the hard-coded system-level default parameters. This invention achieves physical isolation and unified management of configurations for various business projects through the standardized directory structure of workflow / {projectName} / .claude / , avoiding configuration file chaos and conflicts. The layered configuration design of config.json, claude.md, and .mcp.json decouples review rules, AI behavior guidance, and model connection, facilitating fine-tuning for different project characteristics and supporting version tracking of configurations. The configuration priority mechanism (project-specific configuration > template configuration > system default configuration) ensures that new projects can be quickly integrated with zero configuration, while mature projects can be deeply customized for review standards, achieving a balance between lowering the access threshold and ensuring review flexibility. The automatic template copying function further simplifies the project initialization process, allowing configuration preparation to be completed without manual intervention.

[0038] In a preferred embodiment, step S140 involves multi-dimensional code review, which includes at least two of the following: code quality review, commit message review, merge request review, performance analysis, specification check, and security audit. In this embodiment, multi-dimensional code review is managed through a review dimension configuration table. Each row in the configuration table corresponds to a review dimension, and its fields include: a unique dimension identifier (e.g., code-review, security-auditor), dimension name, corresponding executor type, dependent AI model identifier, input file range filtering rules, output result format specification, a flag indicating whether it is enforced, and a timeout setting. During the task splitting phase, the central repository CI / CD pipeline parses the project's config.json file, reads the enabled_dimensions array defined therein, and encapsulates each dimension listed in the array into an independent execution unit. For dimensions not explicitly declared in the configuration file, a default strategy is adopted: security audit and code quality review are enabled by default; performance analysis and specification check are enabled by default but can be disabled by project configuration overriding; commit message review and merge request review are dynamically determined to be enabled based on the trigger signal type (commit triggered or MR triggered). Each execution unit, when encapsulated, carries all parameters from the configuration table for that dimension, including model selection strategies, file filtering rules, timeout thresholds, etc., ensuring complete autonomy during execution. This invention, through the review dimension configuration table and the `enabled_dimensions` declaration mechanism, enables on-demand activation and flexible combination of review dimensions. Different projects can autonomously select the review dimensions to execute based on their own maturity, risk level, resource budget, and other factors, avoiding resource waste from fixed dimensions. The default enabled hierarchical strategy (mandatory for security and quality, optional for performance and specifications, dynamic for submission and merging) ensures both core quality baselines and provides project teams with flexible adjustment space. Each execution unit carries complete configuration parameters, achieving complete autonomy for the execution unit, reducing coupling between execution units, and ensuring that configuration changes in a single dimension do not affect the execution logic of other dimensions, thus improving system maintainability and scalability.

[0039] In a preferred embodiment, in step S150, each execution unit executes the corresponding AI code review task in an independent context environment, including: creating an independent sub-agent for each execution unit; each sub-agent having a context environment independent of other sub-agents and not inheriting context information from the execution process of other sub-agents; limiting the search scope of each sub-agent, allowing it to search only for files or code snippets related to the current review dimension. In this embodiment, creating an independent sub-agent for each execution unit is specifically implemented as follows: the central repository CI / CD pipeline dynamically instantiates a lightweight containerized execution environment (such as a Docker container) for each review dimension, and each container runs an independent sub-agent process. When the sub-agent starts, it initializes a completely new dialogue context window, which does not load any historical session records or inherit cached data or intermediate analysis results accumulated during the execution process of other sub-agents. Regarding file search scope restrictions, each sub-agent receives a set of file path filtering rules upon startup. This set of rules is predefined based on the characteristics of the current review dimension. For example, the code quality review sub-agent is only allowed to access code files in the source code directory (e.g., / src / main / java), the security audit sub-agent is additionally allowed to access dependency configuration files (e.g., pom.xml, package.json) and security-related configuration files, and the performance analysis sub-agent is allowed to access database query statement files and critical business logic code. When the sub-agent performs a search operation, the underlying file access interface filters the search results in real time according to this set of filtering rules, ensuring that the sub-agent cannot read or analyze file content unrelated to its review dimension. This invention achieves physical isolation of the execution environment by creating independent containerized sub-agents for each review dimension, fundamentally avoiding resource competition and context pollution between different dimensions. The independent context window mechanism effectively solves the "illusion" problem caused by context accumulation when large language models process long texts. The review results for each dimension are derived only based on the current code changes and its own set of rules, resulting in stable and predictable output quality. The refined file search scope limitation reduces the amount of data that sub-agents need to process, improving review speed; it also mitigates the security risks of sub-agents misreading sensitive files or performing unauthorized operations from the source. The containerized implementation also provides excellent resource isolation and elastic scalability, allowing the number of sub-agent instances to be dynamically adjusted according to the review task load.

[0040] In a preferred embodiment, step S150 further includes a hierarchical model selection strategy: AI models with different performance levels are assigned to different execution units based on the complexity of the review dimension corresponding to the execution unit; wherein, a pre-defined judgment rule is used based on the complexity of the review dimension, review dimensions judged as complex analysis tasks use high-performance AI models, and review dimensions judged as regular review tasks use economical AI models. In this embodiment, the hierarchical model selection strategy is implemented through a model routing table, which defines the default model and alternative models corresponding to each review dimension. The specific process of model selection is as follows: During the task splitting stage, each execution unit queries the model routing table based on its dimension identifier to obtain the recommended AI model type; subsequently, the system calls the model cost estimation service to predict the number of tokens required for execution of that dimension based on the current code change scale (such as the number of changed files or lines of code), and dynamically decides the final model instance to be used in conjunction with the real-time model service load status. The criteria for determining complex analysis tasks include: the review dimension being security audit or performance analysis; code changes involving core business modules; the number of changed files exceeding a preset threshold (e.g., 10 files); or the number of lines of code exceeding a preset threshold (e.g., 500 lines). Meeting any one of these conditions qualifies a task as complex analysis, and a high-performance model (e.g., Claude-3-Opus, GPT-4-Turbo) is assigned. Regular review tasks, such as code style checks, submission information reviews, and simple format validations, are assigned economical AI models (e.g., Claude-3-Sonnet, GPT-3.5-Turbo). The system also supports a model degradation strategy: when the high-performance model service is unavailable or times out, it automatically degrades to an economical AI model to ensure uninterrupted review tasks; the degradation event is also recorded for subsequent operational analysis. This invention achieves an optimal balance between review quality and computational cost through collaborative decision-making between the model routing table and the cost estimation service. High-performance models are used for complex tasks to ensure accurate identification of high-risk issues such as security vulnerabilities and performance bottlenecks, avoiding false negatives due to insufficient model capabilities. Economical AI models are used for routine tasks to significantly reduce token consumption costs. A dynamic decision-making mechanism adjusts model selection based on the actual scale of code changes, avoiding a "one-size-fits-all" approach that wastes resources. A model degradation strategy ensures high availability of the system under abnormal conditions; a failure of a single model service will not block the entire review process, demonstrating the system's robust design. According to actual test data, this layered strategy can reduce the token cost of a single multi-dimensional review by 60% to 80%, while maintaining a detection rate of no less than 95% for high-risk dimensions.

[0041] In a preferred embodiment, in step S160, the multi-level versioned storage directory structure includes four levels: The project directory is used to store all review history for the corresponding business projects; The branch directory, located below the project directory, is used to store review results by code branch; the merge request or iteration version directory, located below the branch directory, is used to store review results by merge request or iteration version identifier. The code version directory, located below the merge request or iteration version directory, is used to store review results by code version identifier; The code version directory should contain at least the following: a log subdirectory for storing execution logs of each execution unit according to the review dimension; a report subdirectory for storing comprehensive review reports; code change files for recording code changes that trigger reviews; and project metadata files for storing metadata information of business projects.

[0042] The construction process of the four-level hierarchical storage directory in this embodiment is as follows: First, a project directory is created or located in the root directory of the central repository, with the directory name being the projectName parsed from the trigger signal; second, a branch directory is created or located in the project directory, with the directory name being the branch name in the trigger signal. For branch names containing path separators (such as release / 2024-05), the separators are automatically replaced with hyphens to ensure the validity of the directory structure; third, a merge request or iteration version directory is created or located in the branch directory, with the directory name preferentially using the merge_request_id from the trigger signal, and if this field is empty, the iteration_version field is used; finally, a version directory is created in the merge request or iteration version directory, with the directory name being the commit_hash value of the trigger signal. To ensure the uniqueness and readability of the directory name, the complete 40-bit SHA-1 hash value is used. In the code version directory, the system automatically creates two subdirectories, cc-logs / and review / , and creates subdirectories named after the dimension names under cc-logs / according to the dimension identifiers of each execution unit. The `diff.md` file is generated by executing the `diff` command in the code hosting system, comparing the differences between the current commit and its parent commit, and redirecting the output to this file. The `projectInfo.json` file is generated by extracting metadata such as project name, description, programming language, dependency list, and maintainer information from the project's configuration files (e.g., `package.json`, `pom.xml`), formatting it as JSON, and storing it. This invention's four-level hierarchical directory structure (project-branch-MR / iteration-code version) achieves precise mapping and permanent binding between review results and code versions. Each review result corresponds to a unique and immutable code snapshot, solving the pain point of traditional review results being difficult to associate with specific code versions. Automatic conversion of path separators in branch names ensures compatibility of the directory structure under any naming rules. Using a complete 40-digit commit hash value as the version directory name guarantees the global uniqueness of the directory name and allows developers to quickly locate the corresponding code version based on the hash value. The separation design of `cc-logs / ` and `review / ` stores the original execution logs and comprehensive review reports separately, providing detailed data support for problem investigation and a simple entry point for daily reference. The storage of projectInfo.json allows subsequent historical tracing and data analysis to directly obtain project metadata without the need for additional queries to external systems, thus improving query efficiency.

[0043] In a preferred embodiment, step S170 generates an audit trail containing complete contextual information, including: automatically performing a code hosting commit operation in the central repository after each review task is completed; the commit information generated by the code hosting commit operation includes at least the project name, branch, merge request or iteration version identifier, code version identifier, and the currently executed review dimension from the project information; the code hosting version control mechanism enables the immutability and permanent traceability of the review history, and supports querying the review history by at least one dimension among project, branch, merge request or iteration version, and code version identifier.

[0044] The purpose of this invention is to provide a code AI review method, system, device, and storage medium with a central repository architecture. By constructing a "1+N" central repository architecture, it achieves the unification and reuse of review infrastructure, reducing the access threshold for multiple projects. Through a multi-agent parallel architecture and context isolation mechanism, it significantly improves review efficiency and avoids AI illusions. Through multi-level versioned storage and code hosting audit trails, it achieves permanent traceability of review results. Through a layered model selection strategy, it effectively controls review costs, thereby solving the problems of low review efficiency, high cost, difficulty in traceability of results, and difficulty in accessing multiple projects in the prior art.

[0045] The following is an example of code review for the payment module of a large e-commerce platform. The specific steps are as follows: Application Scenario: The backend team of a large e-commerce platform is responsible for developing the core payment module. This module has a massive amount of code and extremely high requirements for performance, security, and code quality. The team integrated the AI ​​code review system of this invention into a code hosting platform. This scenario involves a Review Request (MR) involving changes to payment security logic, MR number M12345.

[0046] Implementation steps: Triggering and Resolution: Developers complete feature development and create MR M12345, targeting the release / 2024-05 branch. This MR contains one code commit with a commit hash of 9f8e7d6c5b4a3... The code repository CI pipeline automatically triggers this, sending a trigger signal to the central repository. This signal includes information such as the project name "payment-module," the branch "release / 2024-05," the MR number "M12345," and the commit hash "9f8e7d6c...". Upon receiving the signal, the central repository's CI / CD pipeline parses the aforementioned project information.

[0047] Configuration Loading: The central repository CI / CD pipeline loads the specific configuration from workflow / payment-module / .claude / config.json based on the project name "payment-module". This configuration file defines the four dimensions to be performed in this review: security-auditor, code-review, performance-analyzer, and rules-review. The configuration file also specifies that for the security-auditor dimension, due to its high risk, the high-performance model claude-3-opus is mandatory; for the other dimensions, the economical AI model claude-3-sonnet is used.

[0048] Parallel execution and context isolation: The central repository CI / CD pipeline creates four parallel jobs, each corresponding to one of the four review dimensions mentioned above. Each job calls gm-codepolish-cli, passing in the corresponding dimension parameter.

[0049] The security-auditor job: Its sub-agent is created, with context isolation. It is authorized to search all .java files and pom.xml dependency files under / src / main / java / com / payment / . It analyzes the changed code, focusing on the implementation of encryption algorithms, user input validation, SQL injection risks, etc. It finds that the new code uses an insecure MD5 hash function and marks it as "high risk" in the report.

[0050] The code-review job: Its sub-agents were created, and the context was isolated. It was limited to analyzing code style, naming conventions, cyclomatic complexity, etc., within the scope of the changed files. It pointed out that a method in the newly added TransactionProcessor class had a cyclomatic complexity of 12, exceeding the project's configured threshold of 10, and recommended refactoring.

[0051] The performance-analyzer job analyzes the potential performance impact of code changes, such as database query efficiency and lock granularity. It did not identify any significant performance bottlenecks.

[0052] The rules-review job's sub-agent checks whether the commit message format conforms to the project specifications (e.g., feat:...) and checks for unused imports, etc. It finds commit messages that do not conform to the specifications and lack a "scope of impact" description.

[0053] Versioned storage: After all four jobs are completed, the results are aggregated. The system constructs a storage path `payment-module / release-2024-05 / M12345 / 9f8e7d6c... / ` based on the project information. Subsequently, logs and reports from various dimensions are stored in their respective subdirectories: security audit logs are stored in `cc-logs / security-auditor / `, code quality reports are stored in `review / codeReview.json`, performance analysis reports are stored in `review / performanceResult.json`, and rule check reports are stored in `review / ruleResult.md`, and saved as `diff.md`.

[0054] Generate audit trail and push results: The system performs multi-dimensional review and summarizes reports from various dimensions, generating a comprehensive comment containing key points such as "high-risk security risks", "high code complexity" and "non-standard submitted information", which is then pushed to the discussion forum of MR M12345 via API.

[0055] Results: Developers saw instant feedback from the AI ​​in the MapReduce, immediately corrected the MD5 algorithm based on security audit recommendations, refactored highly complex methods based on code quality suggestions, and revised their commit messages. The entire review process (e.g., "involving 15 files, approximately 800 lines of code") was completed within 3 minutes, while a traditional manual review of changes of this scale would take at least half a day. More importantly, all review records were permanently stored in a central repository, providing a reliable basis for future security audits and code quality reviews.

[0056] Compared with the prior art, the present invention has the following significant advantages: (1) Unified management, reducing the threshold for multiple projects to access This invention constructs a "1+N" central repository architecture to centrally manage review infrastructure, configuration, and results. Each business project no longer needs to repeatedly build its environment; simply placing the configuration file in the central repository's workflow directory grants access to unified AI review capabilities. New project integration time is reduced from days to minutes, while ensuring consistency in review standards across the company and achieving efficient reuse of review infrastructure.

[0057] (2) Efficiency revolution: Parallel architecture greatly improves review speed

[0058] This invention breaks down the traditional serial multi-dimensional review task into multiple independent execution units and utilizes multiple agents to execute them in parallel. Each agent runs in an independent context environment without interfering with others. The total review time is significantly reduced from over 40 minutes in traditional AI review to 4-12 minutes, improving efficiency by over 70% and completely changing the bottleneck status of code review in the CI / CD process.

[0059] (3) Eradicate hallucinations and ensure the accuracy of results by isolating context.

[0060] This invention avoids the "illusion" problem of large language models caused by context accumulation in a single long session by creating an independent context environment for each sub-agent of the review dimension. The review results of each dimension are derived entirely based on the current code changes and their own rules, resulting in stable output quality, high accuracy, and enhanced credibility of AI review results.

[0061] (4) Version-based tracing to build an unalterable audit trail

[0062] This invention leverages the version control features of a central repository to create a four-level hierarchical storage directory: "Project-Branch-MR-Code Version". Each review result is committed as a new managed code version, with the commit message containing the complete review context. This permanently binds review history to code versions, making it tamper-proof and supporting historical backtracking and issue analysis across multiple dimensions such as time, project, branch, and version.

[0063] (5) Costs are controllable, and the hierarchical model strategy achieves a balance between quality and economy.

[0064] This invention introduces a hierarchical model selection strategy, dynamically assigning AI models with different performance levels based on the complexity of the review task. High-performance models are used for complex tasks to ensure analysis quality, while cost-effective AI models are used for routine tasks to reduce costs. Practice has shown that this strategy can reduce token costs by 6-10 times, making large-scale, routine AI code review economically feasible.

[0065] (6) Strong robustness, exception handling and fault tolerance mechanisms ensure system stability

[0066] This invention incorporates robust retry, degradation, and timeout mechanisms within the central warehouse CI / CD pipeline. When a review task in a certain dimension fails, the system logs the failure, but this does not affect the parallel execution of other dimensions or the delivery of final results. The overall success rate of batch review tasks is effectively guaranteed, and the system exhibits high robustness.

[0067] Figure 2 This is a system architecture diagram of the code AI review system based on the central repository architecture of this invention. (For example...) Figure 2As shown, the code AI review system 5 of the central repository architecture of the present invention includes: Central Repository Module 51: Constructs a centralized code review service repository, adopting a centralized multi-project service architecture to provide unified code review services for multiple business projects; The configuration management module 52 establishes an independent working directory for each business project in the central repository to store the review configuration corresponding to the business project and configure the loading priority. The task splitting module 53 receives a code change trigger signal from any business project, parses the project information contained in the code change trigger signal, and loads the corresponding review configuration from the working directory of the business project. The parallel execution module 54, based on the loaded review configuration, splits the multi-dimensional code review task into multiple independent execution units, each corresponding to a review dimension; The context isolation module 55 triggers each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context environment and generates review results. Versioned storage module 56 creates a multi-level versioned storage directory in the central repository based on the code version identifier in the project information, and stores the review results generated by each execution unit into the storage directory according to the dimensions. The audit trail module 57 submits the versioned audit results to the central repository, generating an audit trail containing complete context information; The results push module 58 will automatically push the review report generated based on the review results to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located.

[0068] In summary, the code AI review system based on the central repository architecture of this invention can achieve efficient access to multiple projects, significantly improve review efficiency, enable version-based traceability of review results, and significantly reduce review costs through unified management of the central repository and a multi-Agent parallel architecture.

[0069] This invention also provides a code AI review device for a central repository architecture, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of a code AI review method for a central repository architecture by executing the executable instructions.

[0070] As shown above, the code AI review device of the central repository architecture of this embodiment can achieve efficient access of multiple projects, a significant improvement in review efficiency, version traceability of review results, and a significant reduction in review costs through unified management of the central repository and a multi-Agent parallel architecture.

[0071] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0072] Figure 3 This is a structural diagram of the code AI review device within the central repository architecture of this invention. See below for reference. Figure 3 To describe an electronic device 600 according to this embodiment of the present invention. Figure 3 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0073] like Figure 3 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0074] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0075] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0076] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0077] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0078] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0079] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of a code AI review method based on a central repository architecture. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the foregoing method section of this specification according to various exemplary embodiments of the invention.

[0080] As shown above, the code AI review system of the central repository architecture of this embodiment can achieve efficient access of multiple projects, a significant improvement in review efficiency, version traceability of review results, and a significant reduction in review costs through unified management of the central repository and a multi-Agent parallel architecture.

[0081] Figure 4 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 4 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0082] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0083] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0084] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0085] In summary, the purpose of this invention is to provide a code AI review method, system, device, and storage medium with a central repository architecture. Through unified management of the central repository and a multi-Agent parallel architecture, it can achieve efficient access of multiple projects, a significant improvement in review efficiency, version traceability of review results, and a significant reduction in review costs.

[0086] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A code AI review method of a central warehouse architecture, characterized by, Includes the following steps: S110. Build a centralized code review service repository and adopt a centralized multi-project service architecture to provide unified code review services for multiple business projects; S120. Establish an independent working directory for each business project in the central warehouse to store the review configuration corresponding to the business project and configure the loading priority. S130. Receive a code change trigger signal from any business project, parse the project information contained in the code change trigger signal, and load the corresponding review configuration from the working directory of the business project. S140. Based on the loaded review configuration, the multi-dimensional code review task is split into multiple independent execution units, each corresponding to a review dimension. S150: Trigger each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context and generates review results. S160. Based on the code version identifier in the project information, create a multi-level versioned storage directory in the central repository, and store the review results generated by each execution unit in the storage directory according to the dimension. S170. Submit the versioned storage review results to the central repository to generate an audit trail containing complete context information; S180. The review report generated based on the review results will be automatically pushed to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located.

2. The code AI review method of the central repository architecture of claim 1, wherein, In step S120, the working directory includes a workflow directory, which is used to store the review configuration of each business project. The review configuration includes at least project-specific review rules, model selection strategies, and task splitting definitions. The configuration loading priority is configured such that project-specific configurations have a higher priority than the system default configurations.

3. The code AI review method of the central repository architecture of claim 1, wherein, In step S140, the multi-dimensional code review includes at least two of the following: code quality review, commit information review, merge request review, performance analysis, specification check, and security audit.

4. The code AI review method of the central repository architecture of claim 1, wherein, In step S150, each execution unit executes the corresponding AI code review task in an independent context environment, including: creating an independent sub-agent for each execution unit; each sub-agent has a context environment independent of other sub-agents and does not inherit the context information in the execution process of other sub-agents; and restricting the search scope of each sub-agent, allowing it to search only for files or code snippets related to the current review dimension.

5. The code AI review method of the central repository architecture of claim 1, wherein, Step S150 further includes a hierarchical model selection strategy: according to the complexity of the review dimension corresponding to the execution unit, different performance AI models are assigned to different execution units; wherein, according to the preset judgment rules based on the complexity of the review dimension, the review dimension judged as a complex analysis task uses a high-performance AI model, and the review dimension judged as a regular review task uses an economical AI model.

6. The code AI review method of the central repository architecture of claim 1, wherein, In step S160, the multi-level versioned storage directory structure includes four levels: The project directory is used to store all review history for the corresponding business projects; The branch directory, located below the project directory, is used to store review results by code branch; A merge request or iteration version directory, located below the branch directory, is used to store review results by merge request or iteration version identifier; The code version directory, located below the merge request or iteration version directory, is used to store the review results by code version identifier; The code version directory shall contain at least the following: a log subdirectory, used to store the execution logs of each execution unit according to the review dimensions; a report subdirectory, used to store the comprehensive review report; and a code change file, used to record the code changes that triggered the review. The project metadata file is used to store the metadata information of the business project.

7. The code AI review method of the central repository architecture of claim 1, wherein, In step S170, generating an audit trail containing complete context information includes: After each review task is completed, a code hosting commit operation is automatically performed in the central repository. The commit information generated by the code hosting commit operation includes at least the project name, branch, merge request or iteration version identifier, code version identifier, and the currently executed review dimension from the project information. The code hosting version control mechanism enables the review history to be immutable and permanently traceable, and supports review history queries by at least one dimension: project, branch, merge request or iteration version, and code version identifier.

8. A code AI review system of a central repository architecture for implementing the method of any one of claims 1 to 7, characterized in that, include: The central repository module builds a centralized code review service repository, adopting a centralized multi-project service architecture to provide unified code review services for multiple business projects; The configuration management module establishes an independent working directory for each business project in the central repository to store the review configuration corresponding to the business project and configure the loading priority. The task splitting module receives a code change trigger signal from any business project, parses the project information contained in the code change trigger signal, and loads the corresponding review configuration from the working directory of the business project. The parallel execution module, based on the loaded review configuration, breaks down the multi-dimensional code review task into multiple independent execution units, each corresponding to a review dimension; The context isolation module triggers each execution unit in parallel. Each execution unit executes the corresponding AI code review task in an independent context environment and generates review results. The versioned storage module creates a multi-level versioned storage directory in the central repository based on the code version identifier in the project information, and stores the review results generated by each execution unit into the storage directory according to the dimension. The audit trail module submits the versioned review results to the central repository, generating an audit trail containing complete contextual information. The results push module will automatically push the review report generated based on the review results to the discussion thread or comments of the code hosting platform where the business project that triggered the code change is located. 9.A code AI review device of a central warehouse architecture, characterized by, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the code AI review method for the central repository architecture according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the code AI review method for the central repository architecture as described in any one of claims 1 to 7.

Images