Qwen Code 代码审查教程：自动检查 GitHub PR、识别漏洞降低代码风险

AI 编程工具生成代码的速度越来越快，但对于真实的软件项目来说，代码写出来只是开发流程的一部分。

一个功能可能可以正常运行，却存在权限校验遗漏、异常处理不完整、数据库查询效率低等问题。尤其在多人协作项目中，AI 修改的代码还可能影响其他模块，甚至引入原本不存在的安全漏洞。

因此，开发团队真正需要解决的问题，已经不只是如何让 AI 写代码，而是如何让 AI 参与代码审查、质量控制和风险识别。

Qwen Code 在这一方向提供了值得关注的能力。它不仅可以读取和修改项目文件，还提供 /review 代码审查命令、专用 Subagents 和 Hooks 机制。开发者可以将这些功能组合起来，让 AI 参与本地代码检查、GitHub Pull Request 审查以及问题修复。

本文从实际工程流程出发，拆解 Qwen Code 如何承担代码审查任务，以及怎样将它融入现有开发团队的质量控制体系。

一、为什么 AI 编程项目更需要代码审查？

传统软件开发中，代码审查通常发生在开发者提交 Pull Request 之后。

开发人员完成代码修改，将分支推送到 GitHub，再由其他成员检查代码差异、运行测试，并决定是否合并。

这种方式比较成熟，但随着 AI 编程工具进入开发流程，代码审查面临新的问题。

1.1 AI 生成代码的速度快，但不代表代码质量稳定

例如，开发者让 AI 为用户系统增加一个登录接口。

模型可能很快生成以下内容：
用户身份验证逻辑；
Token 生成与校验；
数据库查询；
登录失败处理；
接口返回结构。

从表面看，功能已经完整。

但实际审查时，还需要考虑其他问题：
是否存在密码明文存储？
是否正确验证用户权限？
是否存在 SQL 注入风险？
是否对登录请求进行必要的频率限制？
是否会泄露用户敏感信息？
Token 是否具有合理的有效期？
异常情况下是否会暴露内部堆栈信息？

这些问题不一定会在普通功能测试中暴露。

AI 可以生成代码，但开发者仍然需要验证代码是否满足安全要求和项目规范。

1.2 多文件修改增加了审查难度

AI 编程工具经常需要同时修改多个文件。

例如，增加一个用户权限功能，可能涉及：
前端页面；
后端接口；
身份验证中间件；
数据库模型；
权限配置；
单元测试。

如果只检查最终页面能否正常打开，很容易遗漏跨文件依赖问题。

一个接口可能已经修改，但调用它的前端组件仍然使用旧参数；数据库字段已经调整，但其他查询逻辑没有同步更新。

这类问题需要从整个代码差异出发进行检查。

Qwen Code 的 /review 正是面向这类任务提供的代码审查入口。

二、Qwen Code 的 /review 能做什么？

Qwen Code 官方提供了 /review 命令，用于检查代码修改。

它不仅可以审查本地尚未提交的修改，也支持指定 GitHub Pull Request、单独检查文件，以及在一定条件下应用修复。

常见使用方式如下：

# 审查当前未提交的代码修改
/review

# 审查指定 Pull Request
/review 123

# 使用 PR URL 进行审查
/review https://github.com/org/repo/pull/123

# 审查指定文件
/review src/utils/auth.ts

# 审查并尝试修复发现的问题
/review --fix

对于需要在 PR 中留下审查意见的场景，还可以使用：

/review 123 --comment

如果之前的审查因为任务中断而没有完成，可以使用：

/review 123 --resume

这些命令覆盖了从本地修改检查到远程代码审查的不同场景。

需要注意，--comment 涉及向 GitHub PR 发布评论，需要确认对应的仓库权限和操作授权。AI 给出的审查结论也不应直接代替人工合并决策。

三、如何使用 Qwen Code 检查真实项目中的安全问题？

对于开发团队来说，最有价值的不是让 AI 泛泛地评价代码，而是让它围绕具体风险进行检查。

建议将审查任务拆分为四个方向。

3.1 身份验证与权限控制

身份验证与权限控制是 Web 应用中比较容易出现问题的部分。

例如，一个后台系统可能有管理员、普通员工和访客三种角色。

如果只在前端隐藏按钮，却没有在后端接口进行权限验证，攻击者仍然可能直接请求对应接口。

可以让 Qwen Code 检查：

> 检查当前项目的身份验证和权限控制逻辑。
> 重点分析：
>
> 1. 是否存在只在前端进行权限判断的情况；
> 2. 后端接口是否正确验证用户身份；
> 3. 不同角色是否存在越权访问；
> 4. Token 是否正确校验有效期和签名；
> 5. 是否存在敏感信息泄露。
> 请结合实际代码位置给出问题，区分已确认的问题和需要进一步验证的风险。
> 不要直接修改文件。

这里特别建议加入最后一句：不要直接修改文件。

第一轮先审查，再决定是否修复，可以避免 AI 在检查过程中同时改变原有代码。

3.2 SQL 注入与数据库查询

数据库安全也是代码审查的重要部分。

例如，以下代码直接将用户输入拼接到 SQL 语句中：

query = "SELECT * FROM users WHERE name = '" + username + "'"

这种写法可能导致 SQL 注入。

更合理的做法是使用参数化查询：

cursor.execute(
    "SELECT * FROM users WHERE name = ?",
    (username,)
)

可以要求 Qwen Code 检查：
SQL 是否使用参数化查询；
用户输入是否经过必要校验；
ORM 查询是否存在不安全的原始 SQL；
数据库权限是否遵循最小权限原则；
敏感字段是否在日志中被意外输出。

对于大型项目，不建议只检查一个数据库文件。应该结合接口调用路径、数据模型和查询逻辑进行审查。

3.3 API 密钥和敏感信息泄露

AI 编程工具经常需要读取配置文件、环境变量和项目代码。

因此，还应该检查：
是否存在硬编码 API Key；
是否把数据库密码写入代码；
是否将内部服务地址暴露在公开配置中；
是否在异常日志中输出认证信息；
是否把敏感配置提交到 Git 仓库。

可以使用以下审查指令：

> 检查当前项目是否存在敏感信息泄露风险。
> 重点检查：API Key、数据库密码、访问令牌、私钥、内部服务凭证和敏感环境变量。
> 只报告有代码依据的问题，提供文件路径和对应代码位置。
> 不要在报告中完整输出密钥内容。
> 不要修改任何文件。

这里需要注意，代码审查工具本身可能读取敏感文件。

如果项目包含真实生产密钥，应该提前配置访问范围和文件排除规则，不要把不必要的凭证交给模型处理。

3.4 异常处理与资源管理

有些问题并不直接属于安全漏洞，但会影响生产环境稳定性。

例如：
HTTP 请求没有超时设置；
数据库连接没有正确释放；
异步任务异常后没有恢复机制；
文件上传没有限制大小；
重试逻辑可能产生重复写入；
并发情况下出现数据竞争。

这些问题可以通过专门的审查任务发现。

对于涉及支付、订单、用户数据和任务队列的系统，尤其需要关注幂等性、事务边界和异常恢复。

四、Qwen Code 多 Agent 审查：为什么不应该只让一个模型检查全部代码？

一个复杂项目涉及多个技术领域。

如果让同一个 Agent 同时负责安全审计、性能优化、架构分析和测试检查，容易出现任务范围过大、检查重点不明确的问题。

Qwen Code 官方支持 Subagents，可以通过 /agents 查看和管理专用子代理。

同时也支持创建自定义 Subagent，可配置项包含 Agent 唯一标识、适用任务、可用工具、专属系统提示词。

例如，可以为一个项目设计三个不同的审查角色。

4.1 安全审查 Agent

负责检查身份验证、权限、输入校验和敏感信息处理。

> 你是一名应用安全审查人员。
> 检查代码中的：
>
> 1. 身份验证缺陷；
> 2. 越权访问；
> 3. SQL 注入；
> 4. 敏感信息泄露；
> 5. 不安全的文件操作。
> 只报告有代码依据的问题。每个问题需要说明风险、影响范围和修复建议。

4.2 性能审查 Agent

重点分析：
重复数据库查询；
不必要的循环；
大量内存复制；
缺少缓存的高频请求；
不合理的并发处理；
可能造成阻塞的同步操作。

> 你是一名后端性能审查人员。
> 分析本次代码修改可能造成的性能问题。
> 重点关注数据库查询次数、循环复杂度、内存占用、并发处理和缓存策略。
> 区分确定的问题与潜在优化建议。
> 不要为了优化而改变现有业务逻辑。

4.3 测试审查 Agent

重点检查：
是否覆盖主要业务路径；
是否存在边界条件遗漏；
是否缺少异常场景测试；
是否存在测试用例与真实业务不一致；
修改是否破坏原有功能。

> 你是一名软件测试审查人员。
> 检查本次代码修改对应的测试覆盖情况。
> 重点关注：正常输入、异常输入、边界条件、权限错误、并发情况和回归风险。
> 指出缺失的测试场景，并建议优先补充哪些测试。

这样做的意义在于让不同审查角色拥有明确职责，而不是让多个 Agent 重复阅读相同代码并输出相似结论。

但需要注意，多 Agent 审查会增加模型调用次数和 Token 消耗。对于简单修改，没有必要启动多个子代理。

五、Hooks：如何让代码审查从手动操作变成自动检查？

如果团队每次都需要手动输入 /review，仍然存在一定的操作成本。

Qwen Code 的 Hooks 提供了另一种方式：在应用生命周期的指定位置自动执行脚本或程序。

表格

Hooks 可以用于监控工具调用、执行安全策略和注入额外上下文。

例如，开发团队可以设置一个规则：AI 修改认证模块之后，自动提醒执行相关测试。

也可以在工具执行前检查即将运行的命令，避免不必要的危险操作。

5.1 一个简单的自动审查思路

假设团队希望在 AI 修改关键文件后，自动触发检查。

可以设计如下流程：
Qwen Code 修改代码
↓
PostToolUse 事件触发
↓
判断修改文件类型
↓
是否涉及关键模块？
├─是 → 运行安全检查 → 输出检查结果 → 必要时要求人工复核
└─否 → 继续任务

例如，涉及以下目录时可以提高审查级别：
src/auth/
src/payment/
src/database/
src/permissions/

这样可以将安全审查与实际代码修改关联起来。

需要特别说明，Hooks 本身不是完整的安全扫描引擎。它负责在指定事件触发脚本或决策逻辑，真正的扫描工作仍需要由脚本、测试工具或其他审查流程完成。

Prompt Hooks 可以将事件信息交给配置的模型进行判断。因此，如果开启了文件调试日志，相关请求内容也可能被记录，需要特别注意敏感信息保护。

六、GitHub PR 审查：如何把 Qwen Code 放进团队协作流程？

对于多人开发项目，最适合引入 AI 审查的节点之一就是 Pull Request。

传统流程通常是：
开发者提交代码
↓
创建 Pull Request
↓
CI 自动运行测试
↓
人工 Code Review
↓
修改问题
↓
合并代码

可以增加 AI 审查环节：
开发者提交代码
↓
创建 Pull Request
↓
CI 自动运行测试
↓
Qwen Code 审查代码差异
↓
检查安全和逻辑风险
↓
输出审查意见
↓
开发者确认并修复
↓
人工批准合并

Qwen Code 官方支持针对 GitHub PR 执行审查，也提供 --comment 和 --fix 等操作。

不过，建议团队不要一开始就允许 AI 自动修改并合并代码。

更稳妥的方式是先让 AI 只提供审查意见，观察一段时间的误报率和漏报情况，再逐步开放修复权限。

6.1 如何避免 AI 审查产生大量无效意见？

代码审查最怕的不是发现问题少，而是输出大量没有实际价值的建议。

例如，AI 可能建议重构一段本来没有问题的代码，或者把风格偏好误认为程序缺陷。

建议将审查结果分为四个级别：

表格

这套等级是团队可以自行制定的审查规则，不是 Qwen Code 官方固定的漏洞评级体系。

同时，建议每条问题都必须提供：
文件路径；
对应代码位置；
触发条件；
实际影响；
修复建议；
是否经过测试验证。

只有这样，审查结果才方便开发者复现和处理。

七、AI 修复代码之后，如何避免越修越错？

AI 审查发现问题后，开发者可能希望直接让模型修复。

Qwen Code 的 /review --fix 可以用于审查并尝试应用发现的问题。

但在生产项目中，修复并不意味着问题已经解决。

/review --fix 可以帮助开发者减少手动修改代码的工作，但自动修复也可能引入新的问题。例如，模型为了消除一个报错，可能修改了原有业务逻辑，导致其他模块受到影响。

因此，建议将自动修复放在独立的验证流程中。

7.1 先检查，再修复

可以按照以下顺序执行：

# 第一步：检查当前代码
/review --effort medium

# 第二步：尝试修复审查发现的问题
/review --fix

# 第三步：重新审查
/review --effort high

这里需要区分三个动作：
第一次审查：识别潜在问题；
自动修复：尝试修改相关代码；
第二次审查：检查修改是否引入新的问题。

不要把自动修复后的代码直接视为可合并版本。

7.2 修复之后必须重新运行测试

假设一个项目出现了 SQL 查询漏洞，AI 建议将字符串拼接改成参数化查询。

修改完成后，还需要检查：
原有查询功能是否正常；
特殊字符输入是否能够正确处理；
数据库返回结构是否发生变化；
单元测试是否全部通过；
是否影响其他依赖该接口的模块。

可以在终端运行：

npm run lint
npm run test
npm run build

上述命令是 Node.js 项目的常见验证示例，实际项目应使用自己的测试脚本。

对于 Python 项目，可以采用：

pytest

对于大型项目，还应该增加集成测试和回归测试。

核心原则：AI 可以提出修复方案，但最终是否通过，必须由实际测试结果决定。

7.3 自动修复不要直接作用于主分支

对于多人协作项目，建议先建立独立 Git 分支：

git checkout -b ai-review-fix

# 检查修改
git diff

# 运行测试
npm run test

# 确认后提交
git add .
git commit -m "fix: resolve review findings"

这样可以避免 AI 修改过程中影响主分支。

如果修复结果不符合预期，也可以直接丢弃临时分支，保留原始代码。

八、如何把 Qwen Code 代码审查接入 GitHub PR 工作流？

如果团队每天都有大量 PR，仅依赖开发者手动执行 /review，仍然会产生一定的工作量。

更合理的方式是将代码审查放进现有 CI/CD 流程。

一个常见的开发流程如下：
开发者提交代码
↓
创建 GitHub Pull Request
↓
触发自动化检查
↓
执行代码审查
↓
检查安全问题与逻辑错误
↓
运行测试和构建
↓
整理审查报告
↓
开发者确认问题
↓
修改并重新提交
↓
人工审核后合并

这里需要注意，Qwen Code 的本地 /review 命令和 GitHub Actions 自动化并不是同一回事。

如果希望在 PR 创建时自动触发审查，需要额外配置 GitHub Actions、运行环境、身份认证和 Qwen Code 执行步骤。

不能仅仅在 GitHub 仓库中添加一个配置文件，就认为自动审查已经完成。

8.1 GitHub Actions 应该检查哪些内容？

建议至少包含四类检查。

表格

对于 AI 代码审查，还应该要求报告包含：
问题所在文件；
具体代码行；
问题产生的原因；
可能造成的影响；
推荐修复方式；
是否已经通过测试验证。

这样开发者才能判断审查结果是否值得处理。

8.2 不要让 AI 自动批准所有 PR

这是企业部署 AI 审查时需要特别注意的问题。

AI 可能漏掉复杂的业务逻辑，也可能将正常代码误判为缺陷。

因此，不建议直接赋予审查 Agent 自动合并 PR 的权限。

更合理的权限划分是：
AI：发现问题、提供建议、生成审查报告；
CI：执行测试、检查构建状态；
开发者：确认业务逻辑和风险；
仓库规则：控制最终合并权限。

尤其是涉及支付、权限管理、用户数据和生产数据库的代码，应该保留人工审核。

在落地这套自动化审查方案时，开发者可通过 考拉 api 统一调用 Gemini、DeepSeek、Codex 等主流大模型，在不同审查子代理之间灵活切换模型能力，降低多模型接入与密钥管理成本。

九、Qwen Code 代码审查有哪些局限？不能忽略哪些问题？

Qwen Code 的 /review 能够帮助开发者理解代码差异，但它并不能替代完整的软件安全审计。

实际使用时，需要关注以下几个边界。

9.1 模型可能产生误报

例如，模型看到某个函数没有进行参数校验，就可能认为存在安全风险。

但如果参数已经在上游完成校验，这个判断可能并不准确。

因此，审查报告应该结合调用链和项目上下文进行判断，而不是看到问题就立即修改。

9.2 模型可能漏掉跨模块问题

某个文件本身可能没有明显错误，但与其他模块结合后会产生问题。

例如：
数据库字段修改影响旧版本接口；
新增缓存逻辑导致数据不一致；
修改权限中间件影响其他路由；
异步任务没有正确处理异常。

对于这类问题，需要结合项目结构、调用关系和实际测试进行检查。

9.3 安全审查不能只依赖 LLM

对于 SQL 注入、依赖漏洞、密钥泄露和权限配置等问题，建议结合成熟的安全工具。

例如：
Semgrep：静态代码安全分析；
Gitleaks：敏感信息扫描；
Trivy：容器、依赖和配置安全检查；
Dependabot：依赖更新与漏洞提醒。

这些工具可以与 Qwen Code 形成互补。

LLM 更擅长理解上下文和分析业务逻辑，专用安全工具则适合执行规则明确的检测。

9.4 审查结果还需要控制成本

如果每次代码提交都启动高强度审查，可能增加模型调用量和等待时间。

建议采用分级机制：

表格

这样可以避免所有变更都采用相同的审查强度。

十、Qwen Code 适合什么样的开发团队？

从代码审查的使用方式来看，它比较适合以下几类团队。

中小型开发团队：开发人员数量有限，代码审查资源不足。可以利用 Qwen Code 对日常 PR 进行初步检查，帮助开发者提前发现常见问题。

高频迭代的产品团队：如果项目每天都有大量代码修改，可以将 Low 和 Medium 用于日常检查，把 High 留给重要模块和高风险 PR。

多人协作的大型项目：大型项目的代码依赖关系比较复杂。可以让模型围绕代码差异、模块调用和测试结果提供辅助分析，但最终仍需要熟悉项目架构的开发人员确认。

对安全要求较高的业务系统：例如企业管理平台、用户权限系统和数据处理服务。可以将 Qwen Code 与静态代码分析、依赖漏洞扫描和人工安全审计结合使用。

十一、总结：Qwen Code 的价值不只是生成代码，而是帮助建立质量控制流程

AI 编程工具提高了代码生产效率，但开发团队不能因此减少对代码质量的关注。

尤其是当 AI 开始一次性修改多个文件、调用终端工具和处理复杂项目时，代码审查的重要性会进一步增加。

Qwen Code 的 /review 提供了一个比较实用的入口：
Low 适合快速检查；
Medium 适合日常代码审查；
High 适合重要变更的深度检查；
/review --fix 可以尝试修复发现的问题；
GitHub PR 审查可以融入团队代码协作流程。

但需要明确，AI 审查不是代码正确性的最终证明。

真正可靠的质量控制体系，应该将模型分析、静态检查、自动化测试、权限管理和人工审核结合起来。

对于开发团队而言，最值得尝试的不是让 AI 代替所有 Code Reviewer，而是让它承担重复性较高的初步检查工作，把人工精力留给复杂业务逻辑和关键风险判断。

当代码生成越来越容易，如何证明一段代码可以安全地进入生产环境，反而会成为 AI 开发流程中更重要的一环。