使用 /review 审查 Pull Request

最简单的场景——推送前审查自己的改动

在本地仓库中，切换到你想审查的分支，然后在聊天面板中输入：

/review

智能体会对合并基准运行 git diff，并通过 git log 查看已提交的内容。它会撰写一份涵盖以下内容的审查意见：改动做了什么、改动是否符合其声明的意图（来自提交信息）、bug / 竞态条件 / 安全问题、缺失的测试、与周边代码的风格不一致之处。

传入 PR 的 URL 或编号

对于 GitHub 上的 PR：

/review https://github.com/myorg/myrepo/pull/1234
# 或者，在仓库目录中：
/review #1234

智能体会使用 gh（如果已安装）或通过 GitHub API 获取信息。它会读取 PR 描述、关联的 issue（如有）、diff 以及近期评论。如果你连接了 GitHub MCP 服务器，智能体会优先使用它——结果相同，但走的是结构化工具调用。

三个层级，只有前两个需要你的重点关注

典型的审查会将发现分为大致三个层级：

• 层级一：疑似 bug。"第 47 行，user 在这里可能为 null，但没有做检查。"仔细阅读这些内容。大部分是真实问题，少数是过度谨慎。
• 层级二：缺失的部分。"这个函数逻辑不简单，却没有测试。""错误路径提前返回，没有释放锁。"这些是价值最高的发现——正是人类逐行阅读时容易忽视的东西。
• 层级三：风格问题。"命名约定与文件其他部分不一致。"有参考价值，但优先级低；只有在该不一致确实会让读者困惑时才需要处理。

时间充裕时，三个层级都处理。时间有限时，处理层级一和层级二，然后发布。

对话，而不是独白

第一次审查是智能体的整体概览。要深入某个具体发现，直接问就好：

• "告诉我 null 检查应该放在哪里，并提出修复方案。"
• "写一个能捕获你在 UserService 中标记的 bug 的测试。"
• "你为什么认为错误路径没有释放锁？把相关代码给我看看。"

智能体此时已经加载了审查上下文，后续对话的成本很低。这就是把"智能体发现了 7 个问题"变成"智能体帮我修好了 5 个，另外 2 个我们一起讨论了"的关键所在。

审查他人的 PR 时

如果你在审查团队成员的 PR 并希望分享智能体的发现，可以说："把这些作为 PR 评论发布到 GitHub。"安装了 GitHub MCP 或 gh 后，智能体会在相关行创建行内评论，在审查正文中汇总高层级发现，并将审查状态设为"评论"（既不批准，也不要求修改），供你检查确认。

点击"提交审查"之前，一定要亲自看一遍——这将会署上你的名字。

智能体的盲区

• 架构决策。智能体无法告诉你这个 PR 是否让系统走在正确的方向上。它能描述改动了什么，但无法判断改动是否明智。这由你来决定。
• 规模化性能。"这个查询看起来没问题"并不等于通过了负载测试。智能体读的是代码，不是生产环境的 trace。对于性能敏感的改动，请运行基准测试。
• 安全关键代码。请专门使用 /security-review——这是一个专注于威胁面的不同技能。/review 是通用代码审查。
• trivial 改动。一行拼写错误修复不需要 AI 审查。额外开销大于收益。