摘要
- Claude Academy课程介绍了两种自动审查Pull Request的方式：托管式服务Code Review，以及需要自行配置的GitHub Action
- Code Review目前作为Team和Enterprise方案的研究预览版提供，只会留下行内评论，不会批准、拦截或自动修复代码
- 若要执行审查之外的工作，需要在仓库中直接接入anthropics/claude-code-action@v1，通过触发短语和Claude参数调整具体行为
每次PR自动审查代码的两种方法
Anthropic运营的Claude Academy在总共九讲的Claude Code课程中，第七讲介绍了如何让Claude自动为每个Pull Request附加审查。Pull Request是开发者在合并代码变更之前，先交给同事审核的流程。接入方式有两种：一种是开启Anthropic自己运营的托管服务Code Review，另一种是由开发团队自行配置Claude Code GitHub Action。
只需开启即可使用的托管服务
Code Review是一项通过Claude GitHub应用审查Pull Request、并把结果以行内评论形式留在对应代码行上的服务。组织管理员需要先在Claude Code管理员设置中开启该功能并安装Claude GitHub应用，再选择要监控哪些仓库、以及何时触发审查。触发时机可以是Pull Request被打开时、每次推送时，或有人在评论里输入"@claude review"时。审查工作由运行在Anthropic基础设施上的多个审查代理来完成：它们会把变更与整个代码库进行比对分析，按严重程度打上标签并以行内评论呈现，同时在检查运行结果中附上一份汇总表。这套机制会过滤重复内容并排出优先级，目的是让开发者不必翻遍一堆琐碎意见，只看真正需要处理的那几条。目前该服务在Team和Enterprise方案中以研究预览版形式提供。
既不批准也不自动修复
这里值得留意的，是Code Review不做什么。这项服务绝不会做出批准或拦截Pull Request的决定，判断始终留给人来完成。它也不会自动修复发现的问题，服务止步于发布评论意见。要真正把这些意见落实到代码里，开发者需要在自己的终端里执行"/code-review"命令重新检查diff，并加上"--fix"参数把修改应用到工作树中。自动审查到这一步为止，后续的确认和执行都需要人来完成。
超出审查范围的工作，交给GitHub Action
如果要做的不只是审查，比如根据评论指令修改代码、定期生成报告，或响应特定的GitHub事件，就需要自行接入Claude Code GitHub Action。配置从在Claude Code中执行"/install-github-app"命令开始，使用这条命令需要具备仓库管理员权限。执行命令后，只要跟着提示完成GitHub应用安装以及在仓库中注册Anthropic API密钥这两步，配置就算完成。
这个Action的名称是"anthropics/claude-code-action@v1"，需要填入的值包括：必填的Anthropic API密钥；默认值为"secrets.GITHUB_TOKEN"的GitHub令牌；决定Action在评论中对哪句话作出反应的触发短语（默认是"@claude"）；承载具体执行指令的prompt；以及原样传递给Claude Code的CLI参数字符串，也就是Claude参数。使用Bedrock或Vertex的组织，也可以把provider改成对应的选项。
可以直接套用的工作流示例
把这些配置写进".github/workflows/claude.yml"后，就会得到一个在Pull Request和Issue评论中持续监听"@claude"的工作流。比如有人在Pull Request里写下"@claude implement the spec in the linked Linear issue"，Action就会接手这条指令，让Claude提交代码并在评论中说明自己做了什么。同样的思路也能用来搭建每日报告工作流：设置一个在每天UTC上午9点触发的cron任务，让Claude整理结果并发布出来；再加上"workflow_dispatch"触发器，就能在Actions标签页里手动执行。
具体行为可以通过Claude参数这一行来调整。视频中给出的示例是：把"max-turns"设为5，给代理的执行轮数设一个上限；把"permission-mode"设为"don't ask"，让流程在无需人工确认的情况下自动运行；如果是只读的报告类任务，"allow-tools"就只开放这项任务所需的最小范围。
两种方式对比
| 项目 | Code Review（托管式） | GitHub Action（自行配置） |
|---|---|---|
| 配置主体 | 组织管理员在设置中开启 | 仓库管理员自行安装 |
| 执行范围 | 仅限PR审查 | 审查之外的全部工作（实现代码、生成报告、响应事件） |
| 批准/拦截权限 | 无 | 取决于工作流设计 |
| 自动修复 | 无，需在本地执行/code-review --fix | 根据prompt设定，甚至可以直接提交代码 |
| 使用条件 | Team/Enterprise方案研究预览版 | 需要仓库管理员权限和API密钥 |
编辑视角
这次课程展示的，是Anthropic把代码审查自动化拆分成两层的做法。上层是开箱即用的托管服务，降低了入门门槛；下层则是可以直接调整Claude参数和工作流事件的开放式Action，给出了更大的自由度。这种两层结构，在此前介绍过的/design技能和插件市场里也曾反复出现。Claude Code似乎正在形成一种固定套路：每推出新功能，都会同时给出新手一键上手的路径，以及熟手深度调优的路径。
上一代的代码审查机器人大多基于规则，只能停留在抓取风格违规或lint错误的水平。这次的Code Review往前走了一步，会把变更放到整个代码库的背景下分析，并按严重程度排序，但值得注意的是，它同时主动收回了批准/拦截和自动修复的权限。能力增强了，权限反而收紧，这与其说是刻意加装的安全阀，更像是对一项尚未积累足够信任的功能，采取的一种务实设计。
对国内的开发团队来说，把这两条路径分开使用会更合理。刚开始接入时，可以先在Team或Enterprise方案里开启托管式Code Review，用几周时间观察行内评论到底有多大帮助；等真正需要的是审查之外的自动化——比如靠Issue评论直接推进实现，或是定期生成报告——再转向GitHub Action，这个顺序会更自然。接入Action时，从一开始就养成用max-turns防止无限循环、用allow-tools只开放任务所需最小范围的习惯，会比事后再收紧权限范围省心得多。
未来几周内，这项托管服务有可能摘掉研究预览版的标签，扩大适用的方案范围，甚至加入自动修复选项。不过，把Pull Request批准权限真正交给AI的决定，会来得晚得多，也会审慎得多。
评论