这个 PR 改了 30 个文件，同事希望今天就完成审查，你想在逐行阅读之前先过一遍。Verboo Code 为此内置了两个命令：/review 读取 GitHub 拉取请求并给出整体审查；/security-review 只检查当前分支的改动，寻找高置信度的安全漏洞。
Verboo Code 的 /review 做什么？
它让智能体借助 GitHub CLI 扮演代码审查者：用 gh pr list 列出打开的 PR，用 gh pr view 打开选中的 PR，用 gh pr diff 读取差异，然后分节写出审查意见。全部在你的机器上本地运行，使用你在会话中选择的模型。
审查覆盖命令提示词中规定的五个方面：代码正确性、项目约定、性能影响、测试覆盖和安全。输出包括 PR 概览、质量分析、具体建议和风险。
如何用 /review 一步步审查拉取请求？
/review 依赖已安装并登录的 gh，因为 PR 是由它获取的。每台机器做一次：
# 检查 gh 是否已登录
gh auth status
# 如果没有
gh auth login然后在仓库目录的会话中输入：
# 不带编号：智能体运行 gh pr list，列出打开的 PR
/review
# 带编号：直接审查 PR 42
/review 42
命令名后面输入的内容会作为 PR 编号放进提示词。如果你输入的是文字而不是编号，智能体收到的就是这段文字，所以最好只写编号，把额外的关注点放在下一条消息里，例如“现在只看 migrations”。
/review 和 /security-review 有什么区别？
/review 对 GitHub 上的一个 PR 做全面审查。/security-review 审查你当前所在的分支，不需要打开 PR，只寻找真正可能被利用的漏洞。
/review | /security-review | |
|---|---|---|
| 审查对象 | 一个 GitHub 拉取请求 | 当前分支的改动 |
| 差异来源 | gh pr diff <编号> | git diff origin/HEAD... |
需要 gh | 需要，且已登录 | 不需要，只用 git |
| 需要已打开的 PR | 需要 | 不需要 |
| 关注点 | 正确性、约定、性能、测试、安全 | 只看该分支新引入的漏洞 |
| 降噪过滤 | 没有明确过滤 | 丢弃置信度低于 8 的结果（1 到 10 分） |
| 可用工具 | 会话中的工具，按你的权限设置 | 预先放行：git diff、git status、git log、git show、git remote show、Read、Glob、Grep、LS 和 Task |
如何在打开 PR 之前做一次安全审查？
在包含你改动的分支上输入 /security-review。调用模型之前，CLI 会先运行四条 git 命令，并把输出粘贴进提示词：
git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff origin/HEAD...拿到差异后，智能体先启动一个子任务寻找漏洞，再为每个发现并行启动一个子任务，专门过滤误报。最后只保留置信度 8 分以上的结果。每一项都包含文件和行号、严重程度（High、Medium 或 Low）、类别（如 sql_injection 或 xss）、利用场景和修复建议。
提示词还特意排除了噪音很大的类别：拒绝服务、速率限制、存储在磁盘上的密钥、过时的依赖库、仅用于测试的文件，以及内存安全语言中的内存问题。如果你需要审查其中某一类，请在对话中单独提出，不要用这个命令。
陷阱：没有 origin/HEAD，/security-review 就没有比较基准。四条命令都以 origin/HEAD 为基准。用 git init 创建、之后才关联远程的仓库经常缺少这个引用，git 会返回 fatal: ambiguous argument 'origin/HEAD...'。创建指向远程默认分支的引用：
# 识别远程默认分支并写入 origin/HEAD
git remote set-head origin --auto
# 检查
git rev-parse --abbrev-ref origin/HEAD第二行应返回类似 origin/main 的结果。然后重新运行 /security-review。
如何把 PR 评论带进会话？
使用 /pr-comments。它用 gh pr view --json number,headRepository 找到当前分支的 PR，通过 GitHub API 获取普通评论和代码审查评论，并按讨论串分组显示，附上每条评论的文件、行号和差异片段。
完整闭环是：用 /pr-comments 查看审查者的要求，让智能体去修改，再用 /diff 在提交前确认改了什么。
可以只依赖智能体的审查吗？
不建议作为唯一的审查。/review 是第一遍：指出明显问题、总结 PR、找出差异中显眼的地方。它读取的是 gh 返回的差异，所以差异之外的上下文（例如另一个模块里的业务规则）只有在智能体决定打开那个文件时才会被考虑。重要的时候直接要求：“打开 src/billing/，检查这次改动会不会破坏折扣计算”。
想让智能体每次审查都检查同样的规则（测试命名、错误处理模式、禁止修改的目录），把规则写进 用 /memory 管理的 AGENTS.md。这些规则会进入每个会话的上下文，包括审查会话。
好的审查需要智能体打开差异周围的文件，而不只是看差异本身。Verboo Code 的套餐提供无限 token，所以让它在下结论前读完整个模块，和只读改动的几行花费一样。
