Claude Code Review 现已正式发布 —— 其 REVIEW.md 规则仅在合并后生效，其余由分支保护决定（2026）

正式发布公告描述了三项变化。审查速度比预览期间更快。发现的问题写得更简短，直接指出问题、触发原因以及修复方法。现在管理员可以为每个代码库选择审查级别：“管理员可以为每个代码库选择 Quick、Standard（默认）或 Deep，这样常规代码库可以快速通过，而最关键的代码库则可以进行深度审查。”

产品的形态保持不变：多个智能体（agent）读取每次更改，一个验证步骤过滤它们的发现，结果以行内注释的形式呈现，并伴随一个名为 Claude Code Review 的检查运行（check run）。在其他任何事情之前，有两个属性至关重要：

• 它不会合并或阻止。 文档指出：“审查永远不会批准或阻止拉取请求，因此合并的决定权仍在您的团队手中。”
• 它只读取，不运行。 审查“通过读取 diff 和周围的代码来工作，而无需构建或运行您的代码。”在审查过程中，“对您代码库的访问是只读的，且审查不会推送提交。”

因此，审查器的判断完全取决于它所读取的内容，包括您的指令文件。

Code Review 从您代码库中的两种文件中获取指导。

CLAUDE.md 是 Claude Code 已经使用的项目指令文件。Anthropic 将其描述为“Claude Code 在执行每项任务（包括审查）时都会读取的项目指令。Code Review 将它们作为项目上下文读取，并标记违反这些指令的更改。”审查并不会读取代码库中的每一个 CLAUDE.md。“审查会读取您代码库根目录下的 CLAUDE.md，以及每个被更改文件的父目录中的 CLAUDE.md 文件。当拉取请求更改了该路径下的文件时，就会读取子目录的 CLAUDE.md。”

REVIEW.md 是专门针对 Code Review 的。它是“仅用于审查的指令。用它来指明您的团队希望标记什么、严重程度如何以及跳过什么。”您可以将其放在代码库根目录中，并在子目录中添加更多文件，以针对这些路径下的更改添加检查。它的内容会到达审查的每个阶段：“寻找问题的智能体和验证问题的智能体都会收到其内容，作为您代码库的审查指令，同时还有 Code Review 的默认审查指南。编写最终审查的步骤在确定严重程度和编写摘要之前会参考它。”

Anthropic 推荐的划分很简单：“将 REVIEW.md 留给改变审查行为的指令，而将通用的项目上下文留在 CLAUDE.md 中。”默认情况下，Code Review 专注于正确性，这意味着会破坏生产环境的 bug，而不是格式或测试覆盖率。REVIEW.md 是您为代码库移动这条界线的方式：重新定义什么算作“重要”（Important）、限制琐碎问题（nits）的数量、列出要跳过的路径、添加您团队关心的检查，或者要求将文件和行作为某些类型发现的证据。

在关于 Claude Code 团队如何进行代码审查的博文中，Anthropic 写道：“CLAUDE.md 告诉 Claude 项目是什么：技术栈、规范、目标和非目标。每次审查都会加载它，因此在大型代码库中，我们保持其简短，并从那里指向其他文档。”以及“由代码所有者编写的 REVIEW.md 告诉审查器在他们那部分代码中什么最重要。我们会单独检查审查器是否真正遵守了它。”

Anthropic 并不假设该文件一定会被遵守。以下规则解释了为什么您编写的规则可能没有生效。

文档非常明确：“Code Review 从拉取请求的基准分支或默认分支读取 REVIEW.md，绝不从拉取请求自身的更改中读取。要更改审查行为，请先合并 REVIEW.md 的更改。”

在实践中，这会影响到一种很自然的开发流程。开发者注意到审查器标记了生成的文件，于是在触发这些注释的同一个拉取请求中向 REVIEW.md 添加了一条跳过规则，然后推送。下一次审查运行时，针对的是基准分支或默认分支上的 REVIEW.md 副本，而该副本尚未包含新规则。注释会一直出现，直到更改被合并。

同样，首次引入 REVIEW.md 的拉取请求在进行审查时，也是在没有该文件的情况下进行的。

文档陈述了这条规则，但没有给出原因。其效果是，拉取请求自身对 REVIEW.md 的编辑不能降低其发现问题的严重程度，也不能排除它所更改的文件。该决定权仍留在控制合并到审查所读取分支的人手中。

实际的影响是：将 REVIEW.md 的更改视为独立的小型拉取请求，在它们旨在影响的工作之前进行合并。

合并 REVIEW.md 并不是结束。Code Review 会检查它所读取的分支是否受到保护，而结果会改变它所读取的内容以及它所遵守的规则。

Anthropic 的建议是“将 REVIEW.md 保留在默认分支上并保护该分支”。当审查读取受保护默认分支上的副本时，它会遵守根文件中的三种指令：

• 降低发现问题的严重程度
• 排除路径、文件或问题类别
• 限制琐碎注释（nit comments）的数量

这正是文档最初建议编写的五种指令中的三种。一个声明忽略 lockfile 并将琐碎问题限制在少数几个的 REVIEW.md，需要依赖分支保护才能生效。

文档列出了四种情况：

有两行值得注意。在第三行中，子目录的 REVIEW.md 文件根本不会被读取，因此针对每个目录的检查将失效。在第四行中，不会读取任何 REVIEW.md。文档指出，这种情况“包括未受保护的默认分支，且基准分支仅具有经典规则”。

什么算作保护也是具体的。对于默认分支，Code Review 接受“经典分支保护规则或规则集”。对于任何其他分支，它“仅接受规则集”。而且并非每个规则集都符合条件：“当规则集限制更新或要求拉取请求至少获得一个批准时，该规则集才有效。如果它要求拉取请求，它还必须在有新推送时撤销该批准，或者要求批准必须在最后一次推送之后进行。”

检查运行会告诉您何时发生这种情况。一条消息写道：“此审查应用了来自其默认分支的代码库审查指令（REVIEW.md），该分支未针对直接推送进行保护。”这意味着仅读取了根文件。另一条消息说，指令“未应用于此审查：无法确认分支保护”，这意味着没有应用任何指令。

Code Review 有一个在您自己的会话中运行的兄弟工具。文档直接指出了这一区别：“Code Review 服务和本地的 /code-review 命令是两个独立的工具，它们读取不同的文件。”

该服务同时读取 CLAUDE.md 和 REVIEW.md。而本地命令则遵循您的 CLAUDE.md，“包括在非交互式的 -p 运行中。它不会读取 REVIEW.md。”

这对您编写规则的方式产生了影响。仅存在于 REVIEW.md 中的检查将出现在拉取请求审查中，而不会在开发者在开启拉取请求之前运行 /code-review 时出现。Anthropic 的建议是：“将您希望在两处都应用的指南放入 CLAUDE.md 中，并将 REVIEW.md 留给专门针对拉取请求审查的规则。”

在推送前进行本地审查的开发者将会看到两个审查器根据重叠但不同的指令进行工作。

假设新的 REVIEW.md 一经推送就会生效。 它只有在合并到 Code Review 读取的分支后才会生效，并且只有在该分支受保护时才会完全生效。我们关于智能体为何忽略您的指令文件的指南涵盖了编码会话中类似的问题。

假设回复可以教会审查器。 回复某个发现只是与该拉取请求的下一次审查进行对话，而不是一条持久的规则。“仅靠回复并不能消除发现的问题。”下一次审查“会读取对其先前发现的回复，并可以解决该讨论串或发布一条跟进回复。”对于不断重复出现的发现，文档的建议是“请求维护者向 REVIEW.md 添加一条规则。”

假设 CLAUDE.md 仅用于编码会话。 Code Review 会将其作为项目上下文读取并标记违规行为。Anthropic 团队指出，其自身的审查器“还会标记违反其中规范的代码，以及使其中某行内容过时的更改。”一旦审查器读取了 CLAUDE.md，保持其内容最新对于审查来说就至关重要，而不仅仅是对于会话。我们关于冲突的 CLAUDE.md 层级的指南涵盖了如何发现并修复这些问题。

步骤 1：保护默认分支并确认读取了哪个副本

对照上表检查您的分支保护设置。为默认分支提供经典规则或规则集。如果拉取请求的目标是其他长期存在的分支，则这些分支需要一个规则集，以便它们自己的 REVIEW.md 副本能够生效。

然后开启一个小型测试拉取请求并阅读检查运行。如果它显示指令来自未受保护的分支，或者未被应用，请先修复该问题。

步骤 2：在 CLAUDE.md 和 REVIEW.md 之间拆分规则

梳理您想要执行的规则并进行分类：

• 关于项目本身的规则放入 CLAUDE.md：规范、架构边界、更改不应偏向的非目标。这些规则适用于编码会话、本地审查和拉取请求审查。
• 关于审查的规则放入 REVIEW.md：在此代码库中什么算作“重要”（Important）、发布多少个琐碎问题（nits）、跳过哪些路径、始终运行哪些检查。
• 针对代码某一区域的规则放入子目录的 CLAUDE.md 或 REVIEW.md 中。子目录的 REVIEW.md 文件依赖于分支保护。

单独合并 REVIEW.md 的更改。如果您是第一次编写 CLAUDE.md 规则，我们关于让 Claude 坚持您的编码风格的指南涵盖了如何表述规范以便它们被遵守。

步骤 3：将重复出现的发现转化为已合并的规则，并保留原因

Anthropic 自身的过程就是这里的典范。该团队写道：“当自动审查器不断标记相同的内容时，我们会从源头上解决它。”他们推荐的推广方式是将 AI 审查器添加到一个代码库中，“调整 REVIEW.md 几周，然后扩大范围。”当审查遗漏了某些内容时，“我们会询问模型面前缺少了什么，并将修复方案放入 CLAUDE.md、技能或新的检查中。”

这些修复中的每一个都是一个决定：为什么排除某个路径、为什么某类发现在这里是“重要”（Important）而在其他地方是“琐碎”（Nit）、哪次事件导致了某项检查。规则写在文件中。原因也值得保留，因为下一个编辑 REVIEW.md 的人需要它来了解该规则是否仍然适用。我们关于 Claude Code 遗忘您的纠正的指南涵盖了编码会话的相同模式：最重要的纠正属于整个团队都能阅读的文件。

REVIEW.md 保存了规则。而其背后的历史，例如事件、争论以及您拒绝的替代方案，则存在于发生该讨论的任何地方：拉取请求讨论串、聊天记录、个人的记忆中。MemoryLake 是一个记忆层，用于将此类决策记录保存在您维护的一个列表中，供您在编写稍后将由审查器读取的代码时，连接的 Claude Code 和其他助手使用。

您可以用自己的语言亲自编写这些条目。不会从您代码库的 CLAUDE.md 或 REVIEW.md 文件、您的拉取请求、Code Review 的发现或任何供应商的存储中读取、写入或删除任何内容。Code Review 服务仅读取您代码库中的内容，因此它应用的规则仍属于这些文件。在将项目细节存储在代码库之外之前，请检查您组织的政策。

步骤 1：创建 API 密钥

登录并从控制面板生成一个密钥。该密钥属于您的 MemoryLake 工作区，与您的 Anthropic 和 GitHub 账户是分开的。

步骤 2：上传您的第一批记忆

从您审查规则背后的原因开始：为什么跳过某个路径、为什么某个发现类别在此代码库中是“重要”（Important）、哪次事件导致了某项检查。每个条目记录一个决策，注明日期，并指向它所解释的规则。

步骤 3：连接您的 AI 和智能体

连接 Claude Code 和您使用的任何其他助手。这样，在编写代码时，在拉取请求到达审查器之前，您规则背后的推理就已经可用了。

第一个变化是检查运行中的意外更少。一旦确认了分支保护，您编写的排除规则和琐碎问题上限就会生效。第二个变化是一致性：应该在所有地方应用的规则都放在 CLAUDE.md 中，因此本地的 /code-review 和拉取请求审查会有相同的预期。第三个变化是能够有目的地改进设置，将重复出现的发现转化为写明原因的规则。我们对编码智能体实际读取内容的探讨涵盖了为什么这种书面上下文在不同工具中都很重要。

单独合并 REVIEW.md 的更改。 拉取请求是使用基准分支的副本进行审查的。

保护默认分支。 严重程度更改、排除规则和琐碎问题上限都依赖于它。

阅读检查运行消息。 它们会说明何时仅读取了根文件，或者没有读取任何文件。

将共享规则放入 CLAUDE.md。 本地命令不会读取 REVIEW.md。

保持两个文件简短。 Anthropic 自身对审查文件的评价是：“好的文件都很短。”

Code Review 的正式发布使对每个拉取请求进行 AI 审查成为 Team 和 Enterprise 组织的一个默认选项。但它根据什么进行审查仍由团队决定：REVIEW.md 从基准或默认分支读取，绝不从拉取请求自身的更改中读取；分支保护决定了子目录文件是否生效，以及严重程度更改、排除规则和琐碎问题上限是否被遵守；当无法确认保护时，不会读取任何 REVIEW.md。保护分支，将项目规则与审查规则分开，并将重复出现的发现转化为记录了原因的已合并规则。