代码审查如果还停留在人工逐行比对的阶段，效率确实难以跟上现代开发节奏。Trae 提供了一套一站式的智能审查路径，核心理念是将 Git 上下文、AI 推理与 IDE 操作深度整合。你无需编写复杂的提示词，也无需逐行翻阅代码，从触发审查到获得修复建议，整个流程都非常流畅自然。

先来看整体效果：开启「代码审查智能体」后，配置好 Git 上下文，然后按暂存区、提交或分支差异选择审查范围，结果会以双栏方式呈现——左侧是变更摘要，右侧是问题定位。更妙的是，你可以直接用自然语言指令调用参考文档，进行精准校验。

启用智能体审查功能

这是所有后续操作的基础开关——如果不开启，审查模型根本不会工作。操作很简单：启动 TRAE IDE，点击左下角齿轮图标进入「设置」，切换到「Beta」选项页，找到「代码审查智能体」开关，直接打开即可。【该操作仅需一次，开启后即永久生效，无需每次重启重配】

系统会自动加载轻量级审查模型与本地工具链，大约 3–5 秒就能完成，不需要联网下载额外组件。

配置 Git 上下文确保分析准确

Trae 的审查不是简单的纯文本扫描——它必须知道“改了什么”以及“和谁比”，否则无法判断新增逻辑是否破坏了原有流程。这一点非常关键。

第一步：确认项目根目录下存在 .git 文件夹，且当前分支已经至少 commit 过一次（空仓库不支持审查）。

第二步：在 TRAE 主界面右上角点击「源代码管理」图标（分支符号）。如果弹出「未检测到 Git 仓库」提示，手动输入项目的绝对路径，例如 /Users/you/project/myapp。

第三步：点击「刷新上下文」按钮，等待右下角状态栏显示「Git context loaded: main ← feature/login」才算就绪。如果显示「invalid ref」，说明分支名含非法字符或远程追踪失效，需要先执行 git checkout main && git pull。

选择范围并触发 AI 审查

审查粒度直接决定结果精度——暂存区最细，分支差异最全，选错了可能会导致漏检关键问题。

方法一：审查未提交的变更（推荐日常开发）
进入「源代码管理」视图，将鼠标悬停在待审文件名右侧，点击「+」号将其加入暂存区，然后点击顶部操作栏的「总结并审查」按钮。

方法二：审查某次提交（适合 Code Review 后复盘）
在「源代码管理」中点击左侧「提交历史」，右键目标 commit，选择「审查此提交」。系统会自动提取 diff 并加载上下文。

方法三：审查分支差异（适合 PR 前自检）
点击右上角分支名称，在弹出菜单中选择「比较分支」，输入目标分支如 origin/dev，然后点击「开始审查」。【必须确保两个分支都已经 fetch，否则对比结果为空】

解读双栏式审查结果

结果页面分为左右两栏——左侧是业务视角的摘要，右侧是代码级的问题定位，两者不可互相替代。

左侧「变更总结」区域会生成自然语言摘要，例如：“新增用户登录态校验中间件，移除旧版 token 解析逻辑，调整 /api/v2/auth 路径响应结构”。这对快速确认改动是否符合设计意图很有帮助，避免误删核心逻辑。

右侧「问题列表」中每个条目对应一个具体的代码位置，点击后直接跳转到 diff 视图的高亮行。问题类型按严重性分级：Critical（必须修复）、Warning（建议修复）、Info（优化提示）。举个例子，某行标为 Critical 的 SQL 拼接，会同时显示原始语句、风险点（未参数化）以及修复示例（改为 cursor.execute("SELECT * FROM user WHERE id = %s", [user_id])）。

如果某个问题右侧出现了「修复」按钮，点击后会自动唤起对话面板，预填入问题描述、相关代码块及上下文函数签名——你只需要在此基础上补充业务约束，比如“此处必须兼容老版本客户端，不能修改返回字段名”，AI 会据此重新生成适配建议。

用自然语言指令激活参考资料

即使已经配置了全局参考源，Trae 也不会默认读取全部文档——必须明确告诉它“参照哪份材料、检查哪类问题”，否则仍然按通用规则运行。

第一步：在对话面板中输入指令，例如：“请结合 .ref/api-spec.yaml 中 /v1/orders/{id} 接口定义，检查当前修改是否违反响应字段命名规范。”

第二步：Trae 会立即定位 spec 文件中对应的路径，比对代码返回结构，指出字段名大小写、嵌套层级、必选字段缺失等问题。

第三步：如果发现规范冲突，它会直接引用 PDF 第 12 页“响应体字段命名”条款原文，并标注条款编号，而不是笼统地说“不符合规范”。【PDF 必须含可复制文本层，扫描版无法提取内容】