腾讯云 CNB AI 代码评审：PR 自动评审的配置与实战

摘要：

代码评审靠人工，既耗时又容易漏掉潜在问题。腾讯云 CNB 提供 AI 代码评审能力，可在 PR 提交时自动检查代码隐患。本文介绍两种触发方式——插件自动触发与 NPC 按需触发，并给出 .cnb.yml 配置示例，帮助团队快速落地自动评审。

一、为什么要在 PR 阶段引入 AI 评审

代码评审（Code Review）是保障代码质量的关键环节，但现实里它常常流于形式：评审者时间有限，大段逻辑改动来不及细看；新人不熟悉规范，评审意见不到位；合并压力之下，很多问题被"先合再说"放过。

AI 代码评审的价值，在于把一部分重复性、基础性的检查工作前置到 PR 阶段自动完成。它可以在代码提交合并前，自动扫描变更内容，识别潜在的问题点，并把评审意见以评论的形式提交到 PR。人工评审者因此可以把精力集中在架构设计、业务逻辑等更需要经验的层面。

腾讯云云原生构建（Cloud Native Build，简称 CNB）把 AI 代码评审内置到流水线中，支持在 PR 事件触发时自动执行，也支持在 PR 评论中按需触发。两种方式都基于平台提供的 cnbcool/code-review 插件，该插件基于 CodeBuddy CLI，支持多种编程语言，会自动过滤非代码文件，评审结果以评论形式提交到 PR。

二、两种触发方式怎么选

CNB 的 AI 代码评审提供两种触发方式，适用场景不同：

如果你的目标是"每个 PR 都自动过一遍评审"，用 AI 评审插件更直接；如果你只想在特定 PR 上临时发起评审、或希望灵活控制评审时机，用 NPC 事件更合适。两种方式底层都通过 CNB_TOKEN 调用平台 API，评审结果都以评论形式回写到 PR。

三、前置准备：企业版启用 AI 代码评审插件

AI 代码评审插件属于 CNB 企业版的增强能力。企业版用户需要在管理后台完成 CodeBuddy 企业信息配置，并启用"AI 代码评审插件"后，仓库中的相关流水线才能正常调用评审能力。

企业版的其他相关信息：

• 授权定价为 1024 元/授权用户/年，100 用户起售，部署在客户腾讯云 VPC 中；
• 支持 1 个月免费试用，试用期间不扣除费用；
• 软件授权到期后，企业版进入只读状态并停止售后支持。

对于使用社区版的团队，NPC 相关的 AI 能力受 AI Credits 免费额度（500 credits/月）约束，额度用尽后 NPC 等 AI 能力将不可用。

四、方式一：AI 评审插件，PR 自动触发

最直接的做法，是在仓库根目录的 .cnb.yml 中配置 pull_request 事件，挂上 cnbcool/code-review 插件。这样每次有 PR 提交时，流水线自动执行代码评审，无需人工干预。

配置示例如下：

main:
  pull_request:
    - stages:
        - name: 代码评审
          image: cnbcool/code-review:latest
          settings:
            comment: true
            max_comments: 10
            fail_on_critical: false

这段配置的含义：

• main: 表示对 main 分支生效，分支名可按 glob 模式匹配其他分支；
• pull_request: 表示 PR 事件触发，当有合并请求创建或更新时自动运行；
• image: cnbcool/code-review:latest 指定使用官方代码评审插件镜像；
• settings.comment: true 表示把评审结果以评论形式提交到 PR；
• settings.max_comments: 10 限制单次评审最多提交 10 条评论，避免评论刷屏；
• settings.fail_on_critical: false 表示即使发现严重问题也不阻断流水线，仅做提示。

如果需要让评审发现严重问题时阻断合并，可以把 fail_on_critical 改为 true，让流水线在存在严重问题时失败，从而卡住合并。更多参数可参考 cnbcool/code-review 插件详情。

配置好之后，只要往 main 分支提交 PR，评审就会自动跑起来，结果以评论形式出现在 PR 页面。团队无需任何额外操作，评审就成了 PR 流程的固定一环。

五、方式二：NPC 事件，评论按需触发

如果不想每个 PR 都自动评审，可以在 PR 评论中通过提及 NPC 按需触发。CNB 提供系统内置 NPC CodeBuddy，也支持自定义 NPC 角色。

在 PR 评论中直接提及系统 NPC：

@CodeBuddy 代码评审

这条评论发出后，会触发 pull_request.comment@npc 事件，执行 AI 评审并把结果回复到评论区。

如果想用自己的评审角色（比如团队定制的"评审专家"），可以先在 NPC 所属仓库定义好角色，然后在 PR 评论中提及：

@cnb/feedback(评审专家) 代码评审

其中 @ 后跟 NPC 所属仓库路径（如 cnb/feedback），括号里填角色名（如 评审专家）。

对应的 .cnb.yml 配置挂在 $ 下，事件键换成 pull_request.comment@npc，其余 stages 与插件方式保持一致：

$:
  pull_request.comment@npc:
    - stages:
        - name: AI 评审
          image: cnbcool/code-review:latest
          settings:
            comment: true
            max_comments: 10
            fail_on_critical: false

NPC 事件触发时，CNB_TOKEN 的权限仅限于当前仓库，评审结果同样以评论形式回写。这种方式的好处是灵活——评审权交给评论者，想评哪个 PR、什么时候评，由人说了算。

六、NPC 触发的几个限制

使用 NPC 事件触发评审时，有几个平台限制需要留意，避免"提了却没反应"：

• 当 Issue 或 PR 的评论数超过 100 条时，对应的 issue.comment / pull_request.comment 及 @npc 事件都不再触发流水线；
• 一次最多支持触发 10 个 NPC 事件；
• 以下格式中的 @ 提及不会被识别为触发指令：引用（blockquote）、代码块（code）、折叠块（details）、有序列表、无序列表、表格，以及部分 HTML 标签。也就是说，要把 @ 写在正文里，写在代码块或表格里是不触发的；
• 重新打开 PR、编辑描述或评论，都不会重新触发 NPC 事件。

把这些限制记清楚，能有效减少"为什么 @ 了 NPC 却没执行"的困惑。

七、实战建议：把评审融入分支保护流程

落地 AI 代码评审时，建议结合 CNB 的分支保护能力一起使用。对重要分支设置保护规则，要求合并前必须通过 CI 检查、完成代码审查，再配合 AI 评审插件自动把关，形成"AI 先筛一遍、人工再确认"的双重保障。

对于评审过程中需要 NPC 进一步修改代码的场景，可以开启 NPC 的工作模式。在评论区勾选"替我上班"（需仓库开发者及以上权限）后，NPC 拥有更高权限，可自主编写代码、推送代码、创建分支、提交 PR，协助解决 Issue。若希望在评审阶段就让 NPC 具备改代码的能力，这一点会很有用。

八、结语

AI 代码评审把基础性的代码检查工作前置到 PR 阶段自动完成，让人工评审者能聚焦更重要的架构与逻辑问题。腾讯云 CNB 提供了插件自动触发和 NPC 按需触发两种方式，团队可以根据自身评审习惯灵活选择。

两种方式配置都不复杂——插件方式只需在 .cnb.yml 里挂一个 pull_request 事件，NPC 方式则多一步角色定义。企业版用户记得先在管理后台配置 CodeBuddy 企业信息并启用 AI 代码评审插件。

想给自己的仓库加上自动评审这道"质量门禁"，可以到 腾讯云 CNB 上照着本文的配置示例，在 .cnb.yml 里加上 cnbcool/code-review 插件，让每一个 PR 都先过一遍 AI 评审。