用 CodeRabbit 为 PR 配置自动审查：从安装到 .coderabbit.yaml 调校

CodeRabbit 是一个在 Pull Request 上自动留言审查的 AI 平台。它解决的是这样一个具体问题：PR 开出去两三天没人看，最后资深工程师下班前扫一眼就按了 Approve。当团队开始用 AI 编辑器写代码，PR 数量变多，这个缺口只会更大。CodeRabbit 会在 PR 创建后自动给出摘要、逐文件说明和行内建议，很多建议可以一键套用。它适合 PR 量大、资深工程师时间不够的小团队，也适合想给开源项目加一道自动过滤的个人开发者。需要说明的是，默认配置下的审查意见往往偏多偏碎，真正好用的前提是调过 .coderabbit.yaml。如果你还想先了解站内对这个工具的收录情况，可以看 CodeRabbit 这一条目。

它支持的代码托管平台包括 GitHub（含 Enterprise Server）、GitLab（含自架）、Azure DevOps、Bitbucket Cloud 与 Bitbucket Data Center；也能在 VS Code、Cursor 等编辑器以及命令行里审查尚未提交的代码。除了 PR 审查，它还有 Triage 用于排 PR 优先级、Change Stack 用于理解大型 diff、Security 用于持续扫描漏洞，以及在 Slack、Discord 里工作的 Agent。本文只讲最核心的一条链路：装好、跑通第一次审查、用指令控制它、把团队规范写进配置文件、在本机先审一轮。

准备工作

开始之前，先确认下面几件事，能省掉后面很多来回。

• 一个代码托管平台账号：GitHub、GitLab、Azure DevOps 或 Bitbucket 均可，CodeRabbit 用这个账号注册登录。
• 一个可被审查的仓库：建议先挑一个中小型、PR 频率高的项目试水，不要一上来就把整个组织全开。全开的后果是每个仓库都开始产生审查留言，而你还没摸清默认配置的脾气。
• 仓库根目录的写权限：后面要放 .coderabbit.yaml，没有这个权限就只能用网页界面配置，而网页配置的优先级低于配置文件。
• 团队内部的约定：审查留言用哪种语言、哪些路径需要重点看、哪些目录不该被审查。这三件事最好在动手配置前就讨论清楚，写进配置文件后不要每个人各自去网页上改。

付费方案都提供 14 天免费试用，且不需要信用卡。公开仓库通过 GitHub 或 GitLab 安装则永久免费。价格、方案档位与试用政策可能调整，请以官网当前信息为准。

操作步骤

第一步：用代码托管平台账号登录

到 CodeRabbit 官网，用 GitHub、GitLab、Azure DevOps 或 Bitbucket 账号注册登录。登录过程本质上是授权 CodeRabbit 读取你账号下的仓库列表，这一步不会立刻开始审查任何代码，选择仓库在下一步。

第二步：选择要审查的仓库

登录后进入 repository 设置，勾选希望 CodeRabbit 审查的仓库。这里的关键是克制：先只勾一个项目，跑完一轮再决定要不要扩大范围。如果一开始就勾了整个组织，后面调整配置时很难判断某条留言是来自哪个仓库的哪套设置。

第三步：开一个 PR 看第一轮结果

按平常的流程开一个 PR，CodeRabbit 会自动开始审查，通常几分钟内就会留下摘要、逐文件说明和行内建议。看完这一轮，你基本能判断默认配置对你们团队来说是太啰嗦还是刚好。多数团队的第一反应是「太吵」，这很正常，第四步和第五步就是用来解决它的。

第四步：用 PR 留言指令控制审查

在 PR 里留言并 tag @coderabbitai，可以触发各种动作。常用的几条：

• @coderabbitai review：只审查新增的变更，适合在推送了新提交之后补一轮。
• @coderabbitai full review：从头整个重审一遍，适合配置改过之后验证效果。
• @coderabbitai pause 与 @coderabbitai resume：暂停与恢复自动审查。
• @coderabbitai generate unit tests：生成单元测试。
• @coderabbitai autofix：自动修掉还没处理的审查意见。
• @coderabbitai rate limit：查询还剩多少审查额度。

另外，在 PR 描述里放 @coderabbitai ignore，这个 PR 就不会被自动审查。纯改配置文件、改版本号的 PR 很适合这样处理，能省下不少噪音和额度。

第五步：把配置写进 .coderabbit.yaml

在仓库根目录放一个 .coderabbit.yaml，它的优先级高于网页界面的设置。这意味着团队可以把规范固化在代码仓库里，跟着分支走，也能被 code review 本身审查。

不知道从哪写起，可以在任意 PR 里留言 @coderabbitai generate configuration，它会开一个 PR，把当前生效的配置导出成文件。以这个文件为起点改，比从空白开始写要稳。

一个可以直接用的起手式：

language: "zh-TW"
reviews:
  profile: "chill"
  path_filters:
    - "!dist/**"
  path_instructions:
    - path: "src/api/**"
      instructions: "檢查所有輸入是否有驗證，錯誤訊息不得洩漏內部資訊"

逐项说明：

• language：控制审查留言与对话使用的语言。官方配置文档列出的语言代码包含 zh-TW，设成它之后留言会改用繁体中文。也可以按团队习惯选其他语言代码。
• reviews.profile：审查的严格程度，可选 quiet、chill、assertive，默认是 chill。assertive 的意见更多，容易被认为吹毛求疵；觉得太吵就调成 quiet。
• path_filters：用 ! 前缀排除不需要审查的路径，例如构建产物目录。把 dist/** 这类目录排除掉，能显著减少无意义的留言。
• path_instructions：按路径给出针对性的审查要求。上面例子的意思是：src/api/** 下的改动要检查所有输入是否做了验证，错误信息不得泄露内部信息。

第六步：在本机先审一轮

CLI 让你在推送之前就看到审查意见，避免把明显问题推到 PR 上再被指出来。安装方式：macOS 可以用 Homebrew 执行 brew install coderabbit，也可以使用官方安装脚本；Windows 有对应的 PowerShell 版本。

安装完成后先登录：

cr auth login

然后在项目目录下直接执行 cr，就会审查当前的变更。几个常用参数：

# 只看还没提交的部分
cr --uncommitted

# 指定比对的分支
cr --base develop

把这一步放进日常习惯里，效果比在 PR 上反复来回要快得多。

一个完整示例

下面把上面的步骤串成一个最小可跑通的流程，假设团队有一个后端仓库，主要代码在 src/api/，构建产物在 dist/，主干分支是 main，日常开发基于 develop。

1. 接入仓库。用 GitHub 账号登录 CodeRabbit，在 repository 设置里只勾选这一个仓库。

2. 导出初始配置。随便开一个 PR，在里面留言：

@coderabbitai generate configuration

CodeRabbit 会开一个新 PR，把当前配置写成 .coderabbit.yaml。合并它，你就有了一个可编辑的基线文件。

3. 改成团队要的样子。把根目录的 .coderabbit.yaml 替换成下面这份，然后提交：

language: "zh-TW"
reviews:
  profile: "chill"
  path_filters:
    - "!dist/**"
    - "!**/*.lock"
  path_instructions:
    - path: "src/api/**"
      instructions: "檢查所有輸入是否有驗證，錯誤訊息不得洩漏內部資訊"
    - path: "src/payments/**"
      instructions: "特別檢查金額的四捨五入與幣別處理，任何浮點運算都要確認精度"

这里新增了一条针对支付模块的路径指示，并额外排除了锁文件。路径指示是整套配置里最影响审查质量的部分，值得花时间写细。

4. 验证效果。在刚才那个 PR 里留言：

@coderabbitai full review

让它按新配置从头重审一遍，对比之前的留言数量与内容。如果还是太吵，把 profile 从 chill 改成 quiet 再试。

5. 本机预审。在本地装好 CLI 并登录后，在功能分支上执行：

cr auth login
cr --base develop

先处理掉本机能发现的问题，再推送并开 PR。这样 PR 上的审查留言会集中在真正需要讨论的地方。

6. 处理不认同的建议。遇到不适用于团队惯例的意见，不要直接忽略，而是在那条留言下回复理由，例如说明「这里不用改，我们的惯例是这样」。CodeRabbit 会把这些记进 Learnings，下次不再提。Learnings 的范围可以设成单个仓库或整个组织，按团队规模选。

注意事项

费用与计费口径

方案按开发者计价，年缴比月缴便宜。只对会开 PR 的开发者收费，不写代码的成员不计入。公开仓库通过 GitHub 或 GitLab 安装则永久免费。具体档位、单价与折扣请以官网当前信息为准，本文不保证数字长期有效。

审查次数限制

方案不限 PR 总数，但每位开发者每小时的审查次数有上限，不同档位上限不同。超过之后可以开启用量计费，按审查的文件数计价，管理员可以设置每月上限。如果打算开启用量计费，务必先把每月上限设好，否则账单可能超出预期。具体次数与单价以官网当前信息为准。随时可以用 @coderabbitai rate limit 查询剩余额度。

功能分档

生成单元测试、解决合并冲突这类收尾性质的功能，从较高的档位才开始提供；每个 PR 的安全审查与持续安全监控需要更高的档位。选方案前先确认你们真正需要哪些功能，不要为用不上的能力付费。

语言混排的实际体验

把 language 设成中文之后，留言是中文，但代码里的变量名、commit 信息仍然是英文，两种语言夹在一起看久了会累。建议团队内部先定好审查留言用中文还是英文，一旦决定就写进配置文件，不要每个人各自在网页上调整，否则同一个仓库的留言语言会不一致。

代码数据的流向

代码会被送到 CodeRabbit 进行分析。对源码外流敏感的组织，需要确认是否有自架选项，并在签约前完成厂商安全审查。这一条应该在技术评估阶段就提出，而不是等接入之后才补。

配置优先级与常见坑

.coderabbit.yaml 的优先级高于网页界面设置，所以出现「网页上改了但没生效」的情况，先检查仓库里是不是有这个文件。反过来，如果团队习惯在网页上调整，就要接受配置不随仓库走、换仓库要重设一遍的代价。另外，单一路径的指示有字数上限，写得太长会被截断，把最关键的几条写在前面。

把它当第一道过滤网

AI 审查的价值在于把资深工程师从重复性的检查里解放出来，让他们把时间花在真正需要判断的地方。最终按 Approve 的仍然应该是人。装了两周就关掉的团队，多数是因为没碰过配置文件、一直用默认值；把 profile 调低、把团队重点写进 path_instructions、用 Learnings 记住惯例，它的表现会完全不同。