跳到主要内容
gitee logo

Pull Request 审查队友

PR 审查队友是由 Gitee 推出，与 Pull Request 流程深度集成的主动式 AI 数字员工。

本功能适用于 个人 / 组织 / 企业 下的代码仓库。你可前往 AI Teammates 页面 申请开通使用。

功能概述​

在传统研发流程中，代码审查（Code Review）质量往往受限于人工精力与上下文理解成本。随着工程规模的扩大，海量 Diff 导致审查效率下降及潜在风险遗漏成为普遍痛点。

通过静态代码扫描与大模型（LLM）语义理解相结合，PR 审查队友能够自主分析 PR 变更点，发现潜在问题，并输出结构化的审查建议，帮助开发者快速聚焦关键风险与变更要点，实现从人工排查到AI 预审+人工决策的模式升级。

核心维度功能特性与价值说明
自动化风险预审
语义缺陷识别：超越基础的 Lint 检查，能够识别业务逻辑漏洞、异常处理缺失及长尾路径下的潜在风险。
降低漏检率：作为“第一道防线”对 Pull Request 进行全量预审，有效拦截低级错误，确保进入人工审查阶段的代码已具备基础一致性。
审查决策辅助
上下文关联摘要：自动解析变更意图，将复杂的代码 Diff 转化为可读性强的变更要点，降低 Reviewer 的认知成本。
精准风险聚焦：通过结构化分析自动标注关键逻辑变更点，指引 Reviewer 优先关注高危区域，显著缩短审查时长。
审查标准演进
规范能力沉淀：支持跨仓库配置统一的审查规则矩阵，通过持续迭代 AI 审查策略，将团队工程经验转化为可复用的代码治理资产。
质量一致性控制：消除因审查者经验差异导致的质量波动，确保不同项目中 Pull Request 的审查深度对齐。

最佳实践​

  • 与人工审查协同：将 AI 审查结果作为“预审”与“提示项”，由 Reviewer 做最终判断与合并决策。
  • 规则因地制宜：结合业务与技术栈逐步细化规则，持续沉淀审查规范。
  • 聚焦噪声治理：利用 glob 过滤与手册规范，减少自动生成文件与无关变更带来的噪声。
注意

作为人工代码审查的辅助工具，PR 审查队友的定位是辅助者，而非替代者。

由 AI 驱动的自主式代码审查能从多个维度对代码进行检查，挖掘代码中潜在的问题，但代码合入的最终决策仍由人进行最终决策把控。

使用指南​

将 AI 队友添加到仓库​

个人/组织/企业 添加 AI 队友流程类似，前往仓库成员管理页面操作即可，此处以企业为代表，介绍添加流程

  1. 打开「代码仓库 → 成员页面」，点击【+ 添加 AI 队友】。

  2. 在弹出界面选择已有 AI 队友，或新建队友并完成基础信息设置。

    a. 如当前空间下不存在 AI 队友，则先添加 AI 队友 invite_ai_teamate

    b. 选择 Pull Request 审查助手后点击添加（支持批量添加至仓库） create_ai_teamate

  3. 添加成功后，队友将显示在仓库成员列表中，并带有 AI队友 标签。 ai_teamates

备注：队友默认具备开发者权限，且不可更改。

配置队友审查规则​

默认评审规则（队友加入仓库后自动填充，可按需编辑）：

  1. 功能逻辑：代码是否按预期执行？
  2. 安全性：是否存在 SQL 注入、XSS、敏感信息泄露等风险？
  3. 性能：是否存在冗余查询、内存泄漏或明显性能瓶颈？
  4. 可维护性：命名、注释、结构是否清晰，是否便于迭代维护？

自定义规则：

  • 每个仓库最多配置 10 条规则。
  • 规则名称 ≤ 70 字，规则内容 ≤ 400 字。
  • 支持上传团队开发手册（支持上传规范手册 md、pdf、txt、html）。
  • 支持从其它仓库导入评审规则，实现相似项目之间的规则快速复用，减少重复配置。

分支匹配规则：

  • 支持配置分支匹配规则，可设置仅针对特定目标分支（如 main、release 等）自动发起审查。
  • 避免在合并到非主要分支时触发不必要的审查任务，优化审查资源使用。

pr_review_bot_config

Pull Request 审查流程​

  1. 触发时机：

草稿状态下不主动式触发

  • Pull Request 新建时自动触发。
  • 源分支有新的提交更新时。
  • Pull Request 重新打开时。
  • 在评论区手动触发：@PR审查队友 /review。
  1. 反馈方式：

Pull Request 审查队友将在触发审查的 Pull Request 下进行动态评论

  • 审查中：自动评论提示“正在审查...”。
  • 审查完成：输出完整 Review 意见与建议，含发现问题、影响说明与改进建议。

review_report

使用指令辅助审查​

在 Pull Request 或代码行评论输入框中，使用 @ 可快速唤起 PR 审查队友。唤起队友后，你可以查看或通过关键字搜索相关可用指令。

slash

指令功能与适用场景
全量代码审查指令
/review		对当前 Pull Request 进行完整代码审查，帮助发现潜在问题与改进建议。
适合在合并前进行全面检查。
影响分析指令
/impact		分析本次改动可能影响的模块与功能范围，帮助提前评估风险。
仅提供分析结果，不输出审查结论。
交互式问答指令
/ask		直接向队友提问，快速理解代码逻辑、设计意图或潜在风险。
适合阅读他人代码或自查时使用。
单元测试生成指令
/gen-unit-tests		围绕当前改动生成相应的单元测试，用于补充测试覆盖和验证场景。
生成后可按需检查并合并。
函数注释补全指令
/gen-doc-strings		针对当前改动中的相关函数，补充或调整注释内容，主要用于提升代码可读性与理解成本。
生成后可按需检查并合并。
系统只会展示你当前可用的指令，无法使用的指令不会出现，无需手动设置。
  • 对于参与 Pull Request 的所有成员，可以使用：/review、/ask、/impact
  • 对于参与代码修改的成员，还可以使用：/gen-unit-tests、/gen-doc-strings

工作区与任务管理​

每个 Pull Request 审查队友均有独立的工作区。在队友详情页中，可查看以下信息：

  • 队友配置全览：记录最近的 Pull Request 审查行为与处理状态，便于溯源与复盘。
  • 任务规划：展示 Pull Request 审查队友的规划任务列表及状态分布，新增了触发人、审查结果等详细字段，帮助用户更直观地了解队友的工作状态与审查进展。
ai_teamate_overview
tasks_overview

可用指令一览表​

/review 全量代码审查指令​

  • 自动触发审查：

    • 在开启自动审查后，系统将在 PR 新建、源分支更新（push）、PR 重新打开 时自动发起审查；同时支持在评论区通过指令手动触发：@PR审查队友 /review。
    • 审查启动时，系统会在评论区自动展示 「正在审查…」 的动态状态。
    • 审查完成后，输出完整的审查结论与改进建议，形成可追溯的审查反馈闭环。

  • 反馈学习机制：

    • 支持开发者通过 回复审查评论 或 @PR审查队友 + 文字说明 的方式，对误报或不准确的审查结论进行纠正。AI 队友将结合反馈持续优化后续审查表现，降低误报率并提升规则命中准确度。
    • 如需在澄清说明后立即重新触发审查，可在评论中使用 /review 指令并附带说明内容。例如：@PR审查队友 /review 不存在 SQL 注入，已采用 PreparedStatement 预编译。

  • 分支匹配审查：

    • 支持配置 分支匹配规则，仅在目标分支符合条件时自动发起审查（如 main、release 等）。
    • 通过限制自动审查的触发范围，避免在实验分支、个人分支或低价值场景中产生不必要的审查任务，降低噪声与资源消耗。

  • 规则化检查：

    • 围绕 功能逻辑、安全性、性能、可维护性 等维度进行结构化检查，并支持自定义审查规则，以适配不同技术栈与工程规范。

  • 审查治理与配置边界：

    • 审查者接入：支持将 AI 队友加入 PR Reviewer 列表：无阻断项时自动通过，存在阻断项时不通过（管理员可强制通过）。
    • 权限控制：仅仓库负责人及以上权限可添加或移除审查队友，并修改审查规则。
    • 配置粒度：审查规则以仓库为粒度独立配置，并支持通过 glob 规则包含或过滤指定文件。
    • 规则上限：单仓库最多可配置 10 条审查规则。

/impact 影响分析指令​

功能说明
用于在合并前快速识别本次 Pull Request 的影响范围与潜在风险，仅做影响分析，不产生审查结论或通过/不通过判断，适合在合并前进行自检与风险评估。

示例
指令执行后，系统将在评论区自动生成一份结构化的影响分析结果，包含以下内容：

  • 变更概览： 汇总本次 Pull Request 的主要改动情况，包括涉及的文件、代码行数变化以及文件类型分布，便于快速了解改动范围和规模。
  • 详细影响分析： 基于当前改动内容，对可能产生的影响进行评估，并按风险程度进行区分。
    • 高风险： 可能影响核心功能或关键流程，建议重点关注。
    • 中等风险： 可能存在行为变化，建议进行必要的验证。
    • 低风险： 对现有功能影响有限，整体风险可控。
    • 分析覆盖 功能、测试、安全、代码质量 四个方面，帮助减少遗漏。
  • 行动建议： 根据影响评估结果，给出下一步处理建议，并按优先级进行整理。
    • 合并前必须完成： 建议在合并前处理，以避免潜在风险。
    • 建议当前 Pull Request 完成： 可在当前 PR 中一并完成，以提升整体质量。
    • 可后续优化： 不影响当前合并，可在后续迭代中处理。
    • 系统会在合适的位置直接引导使用相关指令（如生成单元测试、补全函数注释），帮助开发者快速完成下一步操作。

impact_report

/ask 交互式问答指令​

  • 用于围绕当前 Pull Request 进行问题咨询和说明性问答，帮助你更快理解本次改动的背景、逻辑和影响范围。
  • 该指令仅用于解释与答疑，不会修改代码，也不会生成审查结论，适合在评审或合并前用于澄清细节。
  • 以辅助理解为目的，降低沟通成本，帮助评审者和提交者在同一上下文下更高效地交流。

ask_report

/gen-unit-tests 单元测试生成指令​

功能说明

  • 当执行该命令时，将围绕相关改动生成相应的单元测试，并以独立的补丁 Pull Request 提交，不影响当前分支。
  • 如多次生成，仅保留基于最新提交生成的结果供审核。
  • 此命令主要用于补充测试覆盖和验证场景，用户只需关注并审核最新生成的补丁结果即可。

示例

  • 第一次生成：
  PR1：b1 → master
  PR2：unit-tests-r40H → b1
  • 源分支 b1 有新提交后再次生成：
  PR1：b1 → master
  PR3：unit-tests-r41H → b1

系统自动关闭 PR2，仅保留基于最新提交生成的 PR3，用户只需审核最新结果。

gen_unit_tests_report

/gen-doc-strings 函数注释补全指令​

功能说明

  • 当执行该命令时，将根据本次改动补充或完善相关函数注释，并以独立的补丁 Pull Request 提交，不影响当前分支。
  • 如多次生成，仅保留基于最新提交生成的结果供审核。
  • 此命令用于提升代码可读性和理解成本，用户只需审核最新生成的结果即可。

示例

  • 第一次生成：
  PR1：b1 → master
  PR2：unit-tests-r40H → b1
  • 源分支 b1 有新提交后再次生成：
  PR1：b1 → master
  PR3：unit-tests-r41H → b1

系统自动关闭 PR2，仅保留基于最新提交生成的 PR3，用户只需审核最新结果。

gen_doc_strings_report

相关文档​

AI 队友介绍