--- title: 代码审查 description: "使用内置的 Reviewer 子智能体进行代码审查，支持多模型审查与一键修复" --- Verdent 内置了一个名为 **Reviewer** 的子智能体，它的唯一职责就是审查你的代码。在你写完代码后，只需标记 `@Reviewer`，它就会从多个角度扫描你的改动，并输出一份按严重程度排序的结构化问题清单。点击任意你想修复的项，它就会自动应用改动——无需手动写注释或查阅文档。 --- ## 如何触发代码审查 最直接的方式是在对话中输入 `@Reviewer`，就像在群聊中提到一位同事一样： ``` @Reviewer please review the authentication logic I just wrote ``` Reviewer 会自动读取当前上下文并开始审查。你也可以不带任何指令直接调用 `@Reviewer`——它会自行决定检查哪些内容。 除了手动触发，智能体还可以在工作流中自动调用 Reviewer 作为最后的 **VERIFY** 步骤。代码写完后你无需操心——系统会引入 Reviewer 来验证结果。 --- ## 审查输出长什么样 审查完成后，你会看到一份结构化的 **Findings（问题清单）**。每一项都包含： - **标题** — 一行描述该问题 - **详细说明** — 为什么这是个问题以及其潜在影响 - **文件路径 + 行号** — 点击可直接跳转到代码 - **置信度评分** — Reviewer 的确信程度（0–1） 问题被分为三个严重等级： | 优先级 | 含义 | 典型示例 | |----------|---------|----------| | **P0** | 严重，必须修复 | 逻辑错误、SQL 注入、权限提升 | | **P1** | 重要，应当修复 | 遗漏边界情况、潜在性能问题 | | **P2** | 建议 | 代码风格、可读性改进 | 顶部会有类似 `P0: 1 / P1: 3 / P2: 5` 的汇总，让你一眼看清严重程度分布。末尾的 `overall_explanation` 则对本次改动给出整体评价。 --- ## 一键修复 无需手动逐个修改问题。每个 Finding 都带有一个复选框： 1. 选择你想修复的问题（支持全选） 2. 点击 **Fix** 3. Reviewer 自动应用改动 4. 状态更新为 **Fix done** 在某些情况下，如果 Reviewer 判断改动风险较低，它可能会自动全选所有问题并触发修复，而无需确认。 --- ## 多模型协同审查 Reviewer 最强大的功能之一是**多模型代码审查**——多个 AI 模型并行审查同一段代码，就像让三位背景各异的工程师独立评估你的实现一样。 **如何启用** 进入 **Settings → Chat → Reviewer → 启用 "Multi-model review"**。 **模型选择模式** | 模式 | 说明 | |------|------| | **Default mode** | Verdent 根据任务复杂度自动选择最佳模型组合 | | **User mode** | 手动选择 1–3 个模型（Claude、GPT、Gemini 可混搭） | 你最多可以选择 **3 个模型**。第一个是主审查者；其余为副审查者。模型越多，覆盖面越广，但执行越慢。对于简单改动，单个模型通常就够了。 --- ## 审查规则（自定义审查策略） Reviewer 默认会捕捉许多常见问题，但每个团队都有自己的标准。**审查规则**让你可以直接定义自己的工程规范。 **在哪里配置** Settings → Chat → Reviewer → 审查规则编辑器（支持 Markdown 的 Monaco 编辑器）。 **你可以定义什么** - 所有 SQL 查询必须使用参数化语句，不得使用字符串拼接 - 异步操作必须包含恰当的 try/catch 错误处理 - 当 props 稳定时，React 组件应使用 `memo` - 所有公开 API 必须校验用户权限 这些规则会被自动注入到 Reviewer 的上下文中，并在每次审查时检查。更新约 500ms 后自动生效——无需手动保存。 --- ## 实时工作流 审查过程中，你可以实时观察 Reviewer 的 **Working Tree Stream**——显示它正在读取哪个文件、分析哪段逻辑。展开后可看到完整的任务树。如果你偏好更简洁的视图，可以将其折叠，不会影响结果。 --- ## 使用场景 ### 最终质量检查 在实现复杂逻辑后，运行 `@Reviewer` 来捕捉你可能因疲劳而遗漏的边界情况和细微 bug。 ### PR 前验证 在提交拉取请求前先运行一次审查。先修复所有 P0/P1 问题，以减少来回沟通，减轻队友的审查负担。 ### 安全审计 添加以安全为重点的审查规则（例如"所有输入必须经过 XSS 净化"），确保每次改动都会自动对照安全策略进行检查。 ### 强制执行团队标准 将 ESLint 规则、API 设计约定和命名规范编入审查规则，这样即使是新贡献者也能自动遵循团队准则。 ### 多视角架构决策 对于重大改动，启用多模型审查以获得独立评估并发现盲点。 ### 初学者的学习工具 把 Reviewer 的反馈当作学习材料——理解为什么 P0 问题重要，比阅读文档更快地掌握核心工程原则。 --- ## 注意事项 - **单模型 vs 多模型**：多模型覆盖面更广，但更慢且成本更高。对于简单或紧急任务，单模型通常已足够。 - **免费版限制**：在 User mode 下，免费用户只能从 Eco Mode 的模型池中选择；高级模型需要订阅。 - **模型弃用**：如果所选模型被下线，它将被禁用，必须替换。 - **审查规则是全局的**：它们适用于所有项目。如果某条规则仅针对特定项目，请添加备注或在使用后移除。 - **BYOK 状态**：如果使用你自己的 API 密钥，过期或余额不足会禁用对应模型，并导致审查失败，直到更新为止。 --- ## 另请参阅 了解内置子智能体 使用你自己的 API 密钥 在实现前先规划