Skip to Content
用户指南功能特性代码审查

代码审查

使用 /review 审查代码变更的正确性、安全性、性能和代码质量。

快速开始

# 审查本地未提交的更改
/review
 
# 审查 pull request（通过编号或 URL）
/review 123
/review https://github.com/org/repo/pull/123
 
# 审查并在 PR 上发布行内评论
/review 123 --comment
 
# 审查特定文件
/review src/utils/auth.ts

如果没有未提交的更改，/review 会提示并停止——不会启动任何 agent。

工作原理

/review 命令运行一个多阶段流水线：

步骤 1：确定范围（本地 diff / PR worktree / 文件）
步骤 2：加载项目审查规则
步骤 3：10 个并行审查 agent                         [10 次 LLM 调用]
           |-- Agent 0：Issue 保真度与根因归属
           |-- Agent 1：正确性
           |-- Agent 2：安全性
           |-- Agent 3：代码质量
           |-- Agent 4：性能与效率
           |-- Agent 5：测试覆盖率
           |-- Agent 6：无导向审计（3 个角色：6a/6b/6c）
           '-- Agent 7：构建与测试（运行 shell 命令）
步骤 4：去重 --> 批量验证 --> 聚合                 [1 次 LLM 调用]
步骤 5：迭代反向审计（1-3 轮，查漏补缺）           [1-3 次 LLM 调用]
步骤 6：展示发现 + 结论
步骤 7：提交 PR 审查（如请求则添加行内评论）
步骤 8：保存报告 + 增量缓存
步骤 9：清理（移除 worktree + 临时文件）

审查 Agent

Agent关注点
Agent 0：Issue 保真度关联 issue 证据、根因归属，以及 PR 是否解决了报告的问题
Agent 1：正确性逻辑错误、边界情况、空值处理、竞态条件、类型安全
Agent 2：安全性注入、XSS、SSRF、认证绕过、敏感数据泄露
Agent 3：代码质量风格一致性、命名、重复代码、死代码
Agent 4：性能与效率N+1 查询、内存泄漏、不必要的重渲染、包体积
Agent 5：测试覆盖率diff 中未测试的代码路径、缺失的分支覆盖、薄弱的断言
Agent 6：无导向审计3 个并行角色（攻击者 / 凌晨 3 点 oncall / 维护者）—— 捕捉跨维度问题
Agent 7：构建与测试运行构建和测试命令，报告失败

所有 agent 并行运行（Agent 6 并发启动 3 个角色变体，同仓库 PR 审查共计 10 个并行任务；本地 diff 和文件路径审查跳过 Agent 0，运行 9 个）。Agent 0-6 的发现会在单次批量验证中进行验证（一个 agent 一次性审查所有发现，使验证成本固定，不随发现数量增加）。验证后，迭代反向审计运行 1-3 轮查漏补缺——每一轮接收前几轮的累计发现列表，因此后续轮次专注于尚未发现的问题。一旦某轮返回“未发现问题”或达到 3 轮（硬性上限），循环即停止。反向审计的发现跳过验证（agent 已具备完整上下文），并作为高置信度结果包含在内。

严重级别

严重级别含义是否作为 PR 评论发布？
Critical合并前必须修复（bug、安全问题、数据丢失、构建失败）是（仅限高置信度）
Suggestion建议改进是（仅限高置信度）
Nice to have可选优化否（仅终端显示）

低置信度的发现会显示在终端单独的“需要人工审查”部分，且永远不会作为 PR 评论发布。

Worktree 隔离

审查 PR 时，/review 会创建一个临时的 git worktree（.qwen/tmp/review-pr-<number>），而不是切换你当前的分支。这意味着：

  • 你的工作树、暂存更改和当前分支不会被修改
  • 依赖项安装在 worktree 中（如 npm ci），以确保构建/测试正常工作
  • 构建和测试命令在隔离环境中运行，不会污染本地构建缓存
  • 如果出现任何问题，你的环境不受影响——只需删除 worktree
  • 审查完成后，worktree 会自动清理
  • 如果审查被中断（Ctrl+C、崩溃），下次对同一 PR 执行 /review 时，会在重新开始前自动清理过期的 worktree
  • 审查报告和缓存保存在主项目目录中（而非 worktree）

跨仓库 PR 审查

你可以通过传递完整 URL 来审查其他仓库的 PR：

/review https://github.com/other-org/other-repo/pull/456

这将在轻量级模式下运行——无 worktree，无构建/测试。审查仅基于 diff 文本（通过 GitHub API 获取）。如果你具有写权限，仍可发布 PR 评论。

能力同仓库跨仓库
LLM 审查（Agent 0-6 + 验证 + 迭代反向审计）✅✅
Agent 7：构建与测试✅❌（无本地代码库）
跨文件影响分析✅❌
PR 行内评论✅✅（如果你具有写权限）
增量审查缓存✅❌

PR 行内评论

使用 --comment 将发现直接发布到 PR 上：

/review 123 --comment

或者，在运行 /review 123 后，输入 post comments 以发布发现，而无需重新运行审查。

发布的内容：

  • 高置信度的 Critical 和 Suggestion 发现，作为特定行的行内评论
  • 对于 Approve/Request changes 结论：包含结论的审查摘要
  • 对于 Comment 结论且所有行内评论已发布：无单独摘要（行内评论已足够）
  • 每条评论底部的模型归属说明（例如，— qwen3-coder via Qwen Code /review）

仅在终端显示的内容：

  • Nice to have 发现
  • 低置信度发现

自己提交的 PR： GitHub 不允许你对自己的 pull request 提交 APPROVE 或 REQUEST_CHANGES 审查——两者都会因 HTTP 422 失败。当 /review 检测到 PR 作者与当前认证用户匹配时，它会自动将 API 事件降级为 COMMENT，无论结论如何，从而确保提交成功。终端仍会显示真实的结论（“Approve” / “Request changes” / “Comment”）——只有 GitHub 端的审查事件被中和。实际发现仍会作为特定行的行内评论出现，因此实质性反馈保持不变。

重新审查带有先前 Qwen Code 评论的 PR： 当 /review 在已有先前 Qwen Code 审查评论的 PR 上运行时，它会在发布新评论前对它们进行分类。只有同行重叠（现有评论与新发现在相同的 (path, line) 上）才会提示你确认——这是你会在同一代码行上看到视觉重复的情况。来自较早提交的评论、已回复的评论（视为已解决）以及与新发现不重叠的评论会被静默跳过，并在终端输出一行日志让你知道过滤了什么。

APPROVE 前的 CI / 构建状态检查： 如果结论是 “Approve”，/review 会在提交前查询 PR 的 check-runs 和 commit statuses。如果有任何检查失败（或所有检查仍在 pending），API 事件会自动从 APPROVE 降级为 COMMENT，并在审查正文中说明原因。原因：LLM 审查是静态读取代码，无法看到运行时测试失败；在 CI 标红时批准会产生误导。行内发现仍会照常发布。如果你仍想批准（例如，已知的 CI 偶发失败），请在验证后手动提交 GitHub 批准。

后续操作

审查后，上下文感知的提示会以 ghost text 形式出现。按 Tab 键接受：

审查后的状态提示发生的情况
包含未修复发现的本地审查fix these issuesLLM 交互式修复每个发现
包含发现的 PR 审查post comments发布 PR 行内评论（不重新审查）
PR 审查，无发现post comments在 GitHub 上批准 PR（LGTM）
本地审查，全部通过commit提交你的更改

注意：fix these issues 仅适用于本地审查。对于 PR 审查，worktree 会在审查后清理，因此不支持审查后的交互式修复——请使用 --comment 或 post comments 来发布发现。

项目审查规则

你可以为每个项目自定义审查标准。/review 按以下顺序从这些文件中读取规则：

  1. .qwen/review-rules.md（Qwen Code 原生）
  2. .github/copilot-instructions.md（首选）或 copilot-instructions.md（回退——仅加载其中一个，不会同时加载）
  3. AGENTS.md — ## Code Review 部分
  4. QWEN.md — ## Code Review 部分

规则会作为附加标准注入到 LLM 审查 agent（0-6）中。对于 PR 审查，规则从基础分支读取，以防止恶意 PR 注入绕过规则。

Issue 保真度

对于 bugfix PR，Issue 保真度 agent 直接获取 issue 证据，而不是依赖 PR 描述文本。它使用 gh pr view <pr> --repo <owner/repo> --json closingIssuesReferences 获取 GitHub 的强关联 issue 元数据，然后使用 gh issue view <number> --repo <issue_owner>/<issue_repo> --json title,body,comments 获取原始报告和讨论——--json 形式包含 issue 正文（报告者的原始复现步骤），而仅使用 --comments 会遗漏这些，并且 issue 自身的仓库是从每个引用中读取的（一个 PR 可以关闭不同仓库中的 issue）。此 agent 仅针对 PR 目标运行；本地 diff 和文件路径审查会跳过它。

closingIssuesReferences 是一个发现提示，而非作者链接了正确 issue 的证明：如果它为空但 PR 引用了明显的目标 issue，agent 在判断相关性后仍会获取它。获取的 issue 文本被视为不受信任的数据（提取事实，忽略嵌入的指令）。对于相关的 issue，原始复现、观察到的 payload、预期行为和维护者评论被视为判断 PR 是否修复了正确问题的最高优先级证据。

如果 issue 证据显示上游服务或 provider 返回了超出客户端契约的畸形数据，则客户端解析器或清理器的更改不被视为有效的根因修复，除非维护者明确要求防御性变通方法。重放畸形上游输出的测试仅证明变通方法处理了该结构；它不能证明该变通方法在架构上是合适的。

示例 .qwen/review-rules.md：

# 审查规则
 
- 所有 API 端点必须验证身份认证
- 数据库查询必须使用参数化语句
- React 组件不得使用内联样式
- 错误信息不得暴露内部路径

增量审查

当审查之前已经审查过的 PR 时，/review 仅检查自上次审查以来的更改：

# 首次审查 —— 全量审查，创建缓存
/review 123
 
# PR 更新了新提交 —— 仅审查新增更改
/review 123

跨模型审查

如果你切换模型（通过 /model）并重新审查同一个 PR，/review 会检测到模型更改并执行全量审查，而不是跳过：

# 使用模型 A 进行审查
/review 123
 
# 切换模型
/model
 
# 再次审查 —— 使用模型 B 进行全量审查（不跳过）
/review 123
# → "上次审查使用了 qwen3-coder。正在使用 gpt-4o 进行全量审查以获取第二意见。"

缓存存储在 .qwen/review-cache/ 中，并同时跟踪 commit SHA 和 model ID。请确保将此目录加入 .gitignore（使用更宽泛的规则如 .qwen/* 也可以）。如果缓存的 commit 在 rebase 中被移除，系统将回退到全量审查。

审查报告

对于同仓库审查，结果会作为 Markdown 文件保存在项目的 .qwen/reviews/ 目录中（跨仓库轻量级审查会跳过报告持久化）：

.qwen/reviews/2026-04-06-143022-pr-123.md
.qwen/reviews/2026-04-06-150510-local.md

报告包含：时间戳、diff 统计、构建/测试结果、所有发现及其验证状态，以及最终结论。

跨文件影响分析

当代码更改修改了导出的函数、类或接口时，审查 agent 会自动搜索所有调用方并检查兼容性：

  • 参数数量/类型更改
  • 返回类型更改
  • 移除或重命名公共方法
  • 破坏性 API 更改

对于大型 diff（>10 个修改的符号），分析会优先处理签名发生更改的函数。

Token 效率

无论产生多少发现，审查流水线都会使用有上限的 LLM 调用次数：

阶段LLM 调用次数说明
审查 agent（步骤 3）10（或 9）并行运行；跨仓库模式下跳过 Agent 7
批量验证（步骤 4）1单个 agent 一次性验证所有发现
迭代反向审计（步骤 5）1-3循环直到“未发现问题”或达到 3 轮上限
总计12-14 (11-13)同仓库：12-14；跨仓库：11-13（无 Agent 7）

大多数 PR 会收敛到范围的下限（1 轮反向审计）；该上限可防止在极端情况下成本失控。

不会标记的内容

审查会刻意排除以下内容：

  • 未更改代码中预先存在的问题（仅关注 diff）
  • 格式化程序会自动规范的样式或格式，或符合代码库约定的命名——但 linter 或类型检查器会标记的实质性问题（如未使用的变量、不可达代码、类型错误）除外，这些仍在审查范围内
  • 没有实际问题的主观“建议考虑做 X”
  • 未修复 bug 或风险的微小重构
  • 缺失的文档，除非逻辑确实令人困惑
  • 现有 PR 评论中已讨论过的问题（避免重复人工反馈）

设计理念

沉默胜于噪音。 每条评论都应值得读者花时间阅读。

  • 如果不确定某个问题是否真的是问题 → 不要报告
  • 跨 N 个文件的相同模式 → 聚合为一个发现
  • PR 评论仅包含高置信度内容
  • 排除符合代码库约定的表面样式/格式问题
Last updated on
命令后续建议