Claude Code 学习站
v2.1.201

PR 审查工作流

从拉一个 PR 或本地 diff 开始,跑 /code-review 找 bug、跑 /security-review 查漏洞、按 findings 逐条修,最后总结改动建 PR——全程不离开终端。

为什么要在终端里审 PR

合并前发现的 bug 比合并后便宜得多。Claude Code 把审查这件事拉进了你的终端:不用切到网页、不用装 GitHub App,就能在本地对一段 diff 跑正确性审查、安全审查,甚至直接让它逐条修。

一个完整的 PR 审查流程通常是这样:

  1. 拉一个 PR 或审本地改动 —— 拿到要看的 diff。
  2. 跑 /code-review —— 找正确性缺陷 + 清理建议。
  3. 逐条修 —— 让 Claude 按 findings 改,或自己挑着改。
  4. 跑 /security-review —— 安全维度单独复查一遍。
  5. 收尾 —— 总结改动、建 PR、完善描述。

下面按这个顺序走一遍。

拉一个 PR 或审本地 diff

最常见的是审你自己还没提交的本地改动 —— 什么都不用拉,/code-review 默认就覆盖当前分支相对上游的提交 + 工作区未提交的改动:

> /code-review

如果要审的是别人的 PR,先用 git/gh 把它的分支拉到本地,再在该分支上跑审查:

gh pr checkout 1234   # 切到这个 PR 的分支
claude                # 启动会话,再 /code-review

关于 --from-pr:这个 flag 是用来恢复 Claude 自己创建某个 PR 时的那次会话的 —— Claude 用 gh pr create 建 PR 时会把会话自动关联到该 PR,之后 claude --from-pr 1234(或把 PR URL 粘进 /resume 选择器)就能回到它。它不是用来 checkout 任意第三方 PR 的。

提示:也可以不进会话,在 shell 里直接喂 diff 给 headless 模式:git diff main | claude -p "审一下这段 diff 有没有正确性问题"。适合脚本化。

跑 /code-review 找正确性缺陷与清理建议

/code-review 是会话内的 Slash 命令,在本地对 diff 跑审查,不需要 GitHub App。它报告两类东西:正确性缺陷,以及代码复用 / 简化 / 效率方面的清理建议。

基本用法 + effort 等级

> /code-review
> /code-review high

effort 越高覆盖越广:

  • low / medium —— 数量更少、置信度更高的发现
  • high 到 max —— 覆盖更广,可能包含不确定性更高的发现

不传 effort 时用当前会话的配置(可用 /effort 单独调)。典型输出是一份按严重度排序的 findings 列表,每条带文件 + 行号 + 一句话描述 + 失败场景。

指定审查目标

不带参数审本地 diff;也可以显式指定看什么:

> /code-review path/to/service.ts     # 单个文件
> /code-review 1234                    # PR 编号
> /code-review my-feature              # 分支名
> /code-review main...my-feature       # ref 范围(等价于该 PR 的 diff)

main...my-feature 审的是把 my-feature 合进 main 时 PR 包含的提交,与分支上游配置无关 —— 这是最贴近"PR diff"的写法。

让 Claude 按 findings 逐条修

审查给出 findings 后,有两种修法。

自己挑着修

直接用自然语言指挥,挑你认可的条目:

> 上面第 1、3 条我同意,按你的建议改掉;
> 第 2 条是误报,那个分支永远走不到,跳过

审查找 bug、人来定夺、再让 Claude 落地 —— 这是最稳的节奏,尤其是 high/max 等级可能混进不确定的发现时。

让它审完直接改

如果信得过,可以让审查跑完后自动把修复写进工作区:

> /code-review --fix
> /code-review high --fix

--fix 会在审查结束后把建议的改动直接应用到工作树。改完务必自己 git diff 过一遍再提交。

历史变更:--fix 之前的等价物是 /simplify。从 v2.1.154 起 /simplify 变成独立的"仅清理"命令(应用清理类修复,但不查 bug)。旧脚本若靠 /simplify 查 bug 并修复,要改成 /code-review --fix。

/security-review 复查安全漏洞

正确性过关不代表安全过关。/security-review 是一个内置 Skill,对当前分支的待处理改动做以安全为核心的审查,只上报高置信度、有真实利用路径的漏洞。

> /security-review

它会输出结构化报告,每条带:文件 + 行号、严重等级(HIGH / MEDIUM / LOW)、漏洞类别、利用场景、修复建议。覆盖的类别包括 SQL/命令注入、认证绕过、IDOR、硬编码凭据、反序列化 RCE、XSS、敏感数据泄露等。

可以追加自然语言收窄重点:

> /security-review 重点看新加的 API 认证逻辑,忽略前端校验

注意它只看 diff,不扫全量历史代码;且明确不查 DoS / 速率限制 / 已知 CVE / 磁盘上的 secrets —— 这些交给专项工具。

为什么单独跑:/code-review 管正确性和可维护性,/security-review 管数据流追踪和利用路径验证,两者关注点不重叠。重要改动两个都跑一遍。

收尾 总结改动并建 PR

bug 修完、安全过了,就可以收尾建 PR。可以一句话让 Claude 全包,也可以分步走、每步把关。

一步到位

> 给我的改动建一个 PR

Claude 会用 gh pr create 建 PR,会话随之自动关联到它。

分步走(更可控)

> 总结一下我对认证模块做的改动
> 建一个 PR
> 在 PR 描述里补充更多关于这次安全加固的背景

提交前让 Claude 自己点一遍风险也是个好习惯:

> 提交前先指出这次改动里潜在的风险或需要 reviewer 留意的点

变体 CI 里 headless 自动留 inline comment

把审查搬进 CI,新 PR 自动被审、findings 直接以 inline comment 写回 PR。

正确性审查:--comment

在会话里(或脚本里对某个 PR)跑审查并把发现发为 PR inline comments,无需装 GitHub App:

> /code-review 1234 --comment

把发现以 inline comments 形式发布到对应 PR。

安全审查:官方 GitHub Action

安全审查有现成的 GitHub Action,PR 打开时自动触发并留评论。在 .github/workflows/security.yml 里:

name: Security Review
 
permissions:
  pull-requests: write   # 留 PR 评论需要
  contents: read
 
on:
  pull_request:
 
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2
 
      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

comment-pr 默认 true,会在漏洞所在行直接留 inline 评论。其他可选输入:exclude-directories(排除目录)、claudecode-timeout(超时分钟数,默认 20)、upload-results(上传 artifact,默认 true)。

安全提醒:官方 README 明确该 Action 未针对 prompt injection 加固。对外部贡献者的 PR,建议配置为仅在维护者审阅后才运行,避免恶意 diff 操控审查输出。

回到 示例列表 →