跳转到主要内容
随着代码智能体越来越普及，瓶颈已从编写代码转移到了审阅代码。 Devin Review 是 Devin 网页应用中的全功能代码审查平台，可以将庞大而复杂的 GitHub PR 转化为结构直观的差异视图（diff）和精准的解释说明。
Devin Review 免费提供，可用于常规 GitHub 仓库上的 PR （不支持 GitHub Enterprise）。公开 PR 不需要 Devin 账号。私有 PR 可以通过 Devin 账号或通过 CLI 查看。

​
功能

智能 diff 组织

按逻辑对变更分组，将相关编辑组织在一起，而不是按字母顺序排列。

复制与移动检测

检测代码是否被复制或移动，并清晰展示变更，而不是显示完整删除和插入。

缺陷检测器

检查缺陷并按置信度等级标注。严重缺陷需要立刻处理。

GitHub 兼容性

在 Devin Review 中直接发表评论、批准 PR、请求更改，并与 GitHub 实时同步。

代码库感知聊天

就该 PR 提问，并基于其余代码库的相关上下文获取解答。你也可以在 diff 视图中的任何评论、缺陷或标记处直接向 Devin 提问。

​
入门

  • Devin webapp — 前往 app.devin.ai/review，查看按类别组织的未处理拉取请求（PR）（指派给你、你创建的、请求你评审的）。当 Devin 创建 PR 时，你会在聊天中看到橙色的 “Review” 按钮。
  • URL 快捷方式 — 对于任何 GitHub PR 链接，将 URL 中的 github.com 替换为 devinreview.com。对于私有 PR，请先登录 Devin 或使用 CLI。
  • CLI — 在本地克隆的仓库中运行 npx devin-review {pr-url}。详情见下文的 CLI。

​
自动审查

Devin 可以自动审查 PR，而无需你手动触发。你可以在 Settings > Review 中配置自动审查，或者通过任意 PR 审查页面上的设置图标进行配置。

​
自动审查何时运行？

自动审查会在以下情况下触发：
  • 打开非草稿 PR 时
  • 向 PR 推送新的提交时
  • 将草稿 PR 标记为“准备审查”时
  • 将已加入自动审查的用户添加为审查人（Reviewer）或负责人（Assignee）时
草稿 PR 在被标记为“准备审查”之前会被跳过。

​
自助注册（所有用户）

任何已连接 GitHub 账号的用户都可以为自己开启自动审查——不需要管理员权限。
  1. 前往 Settings > Review
  2. 点击 “Add myself (@yourusername)” 为自己注册
注册后，Devin 会在任意仓库中自动审查你创建的 PR（拉取请求）、你被添加为审查者的 PR，或指派给你的任何 PR。 你也可以直接在 PR 审查页面中自助注册：点击设置图标并切换 “Me (@username)“。

​
管理员配置

管理员在 Settings > Review 中有更多选项：
  • Repositories — 将代码仓库添加到自动审查列表，以自动审查该仓库中的所有 PR。使用下拉菜单从已连接的代码仓库中搜索并选择。
  • Users — 查看并管理整个组织中所有已加入的用户。可以将任意 GitHub 用户名添加到自动审查列表。
  • Insert link in PR description — 启用时（默认），Devin 会在 PR 描述中添加指向此次审查的链接。
Enterprise 账户： 设置会应用于 Enterprise 中所有组织。只有主组织中具有企业管理员 权限的用户可以管理这些设置。非主组织中的用户只能自行开通自动审查。
自动审查不适用于未连接到你组织的公共代码仓库。

​
Bug Catcher

Bug Catcher 会自动分析你的 PR（pull request 合并请求），查找潜在问题，并在 Analysis 侧边栏中展示结果。结果分为两类：Bugs 和 Flags。

​
Bugs

Bug 是指应在代码中修复的可处理错误。它们表示 Bug Catcher 高度确信为实际存在的问题。 Bug 会以两种严重程度显示：
  • 严重 — 置信度高， 需要立即处理的问题
  • 一般 — 严重程度较低，但仍应进行审查的问题
当你看到 bug 时，应对其进行排查并在代码中修复。

​
标记

标记是供参考的代码注释，可能需要也可能不需要采取行动。它们分为两类：
  • Investigate（需排查） — 需要进一步排查的标记。你应当自行审查被标记的代码，并确认是否存在实际的 bug 或问题。
  • Informational（仅供参考） — Bug Catcher 要么已确认其是正确的，要么是在解释某段逻辑的工作方式。 这些标记帮助你理解代码变更，而无需你采取任何行动。

​
解决发现项

当你修复了问题或确认它们无需处理时，就可以将 bug 和标记设为已解决。已解决的项会在侧边栏中以灰显方式显示，并在各自所属部分的列表底部排列。

​
评审操作

​
开始 Review

在创建新的行内评论或回复现有讨论线程时，你可以勾选 Start a review 复选框，将评论汇总到一个待提交的 Review 中，而不是逐条单独发布。这与 GitHub 的 Review 工作流相同，让你可以在提交前先收集好全部反馈。一旦某次 Review 已经开始，后续的评论会自动加入其中，该复选框也会被隐藏。

​
解决评论

你可以将评审线程标记为已解决，以表明它们已经被处理。当某个由机器人提交的评审中的所有线程都被解决后，Devin 会在 GitHub 上自动将该评审折叠，以保持 PR 对话简洁。如果某个线程之后被重新标记为未解决，则该评审会自动恢复为展开状态。 在 diff 视图中，你可以使用尖角图标开关展开或折叠单个评论线程，以便聚焦于尚未解决的反馈。

​
代码所有者指示器

当某位代码所有者被指定为审阅者时，Devin Review 会在审阅者侧边栏中其姓名旁显示一个盾牌图标，并带有“已作为代码所有者被请求”的工具提示。这样可以轻松识别待审核的审阅者中哪些对已更改的文件拥有代码所有权。

​
自动修复

Devin Review 可以针对它在你的 PR 中检测到的缺陷自动提出修复建议并应用修复。启用自动修复后，Devin 会在报告缺陷的同时直接给出相应的代码修改建议。

​
如何启用

有三种方式可以启用 Auto-Fix：
  1. 通过 PR 审查设置弹出层 — 在任意 Devin Review 页面，点击设置图标（三个点），然后打开 Enable Autofix 开关。此开关仅会出现在由 Devin 提交的 PR 上。
  2. 通过嵌入式 PR 审查设置 — 在 Devin 会话中嵌入的 Devin Review 视图里，打开设置弹出层，然后打开 Enable Autofix 开关。
  3. 通过全局自定义设置 — 前往 Settings > Customization > Pull request settings > Autofix settings - bot comments，然后执行以下任一操作：
    • 将模式设置为 Respond to specific bots only，并将 devin-ai-integration[bot] 添加到允许列表，或
    • 将模式设置为 Respond to all bot comments。
当 Devin Review 发现缺陷且已启用 Auto-Fix 时，它会生成修复建议，你可以直接在 diff 视图中审查并应用这些修复。

​
权限与限制

  • 只有组织管理员可以更改此设置。
  • 如果 bot 评论模式设置为 Respond to all bot comments，Auto-Fix 开关会显示为已启用，但你无法在 PR 审查设置中更改它。请使用 Customization 设置来修改 bot 评论模式。
  • Devin Review 的 No Issues Found 汇总评论始终会被忽略。只有包含实际问题的评论才会触发 Auto-Fix。
如果当前在你的代码库中，Devin Review 的反馈被设置为忽略，你会在会话时间线上看到启用它的提示。

​
CLI

Devin Review CLI 允许你直接在终端中运行代码审查。对于私有代码库，或当你希望使用更简化的本地工作流时，它尤其有用。

​
安装和使用

在本地克隆的仓库中运行 CLI，无需身份验证： 
cd path/to/repo
npx devin-review https://github.com/owner/repo/pull/123
你必须在正在审核的代码仓库内运行此命令。 工作原理：
  1. 基于 Git 的 diff 提取 — CLI 使用你本地的 Git 访问权限获取 PR 分支并计算 diff。这意味着你需要在本机上对该代码仓库具有读取权限。
  2. 隔离的 worktree 检出 — CLI 会在一个缓存目录中创建一个 git worktree 来检出 PR 分支。这样可以保持你的工作目录不受影响 —— 无需暂存（stash）、无需切换分支。审核完成后，该 worktree 会自动清理。
  3. 将 diff 发送到 Devin 服务器 — 计算出的 diff 和文件内容会被发送到 Devin 的服务器进行分析。

​
隐私与访问控制

CLI 使用 localhost 本地服务器 为你的评审会话进行身份验证：
  • 默认仅限本地访问 — 当你运行 devin-review 时，它会在你的机器上启动一个 localhost 服务器，用于提供安全令牌。只有你本地机器上的进程可以访问该令牌，这意味着在未登录的情况下，只有你可以查看评审页面。
  • 转移到你的 Devin 账户 — 如果你登录了一个对该 GitHub 组织有访问权限的 Devin 账户，评审会话会被转移到你的账户下。这样你就可以从其他设备访问评审，并与团队成员共享。
当你运行 CLI 时，devin-review 可以在你的本地机器上执行命令，以收集更多用于查找 bug 的上下文信息。这比仅基于 diff 的评审能进行更深入的分析。 Bug Catcher 只能执行一组受限的、作用范围限定在 worktree 目录内的 只读 操作：
  • 文件读取 — 读取代码仓库中的文件内容
  • 搜索 — 使用 grep 搜索模式、使用 glob 匹配文件名
  • Bash 命令 — 仅限只读命令，如 ls、cat、pwd、file、head、tail、wc、find、tree、stat 和 du

​
提交与评论归属

  • Bug 发现、标记和自动注释始终以 Devin bot 的身份出现。
  • 当用户通过 Devin Review 编写评论或评审时，这些内容会显示为该用户的 GitHub 身份。
  • 当用户让聊天代理进行代码修改时，由此产生的提交会以 Devin bot 的身份创建。
  • GitHub Suggested Changes 遵循 GitHub 的标准行为：任何评审者（包括 Devin）都可以在评审评论中留下建议修改。当用户点击“Apply suggestion”时，提交的作者为该用户，与 GitHub 中的行为一致。
  • Devin 绝不会在用户未明确发起操作的情况下，代表用户创建提交或评论。

​
AGENTS.md / 指令文件

Devin Review 会遵循代码仓库中的指令文件。如果这些文件中的任意一个存在，它们都会在分析你的 PR 时作为上下文使用：
  • REVIEW.md
  • AGENTS.md
  • CLAUDE.md
  • CONTRIBUTING.md
  • .cursorrules
  • .windsurfrules
  • .cursor/rules
  • *.rules
  • *.mdc
这些文件可以包含编码规范、项目约定或其他指南，从而帮助提供更有针对性的反馈。

​
自定义 Review 规则

你可以在 Settings > Review 页面的 Review Rules 部分配置额外的文件，作为评审上下文供 Devin 使用。这样可以在上述默认规则之外，添加自定义的文件 glob 模式。 要添加自定义规则：
  1. 前往 Settings > Review
  2. 在 Review Rules 下输入一个文件 glob 模式（例如 docs/**/*.md）
  3. 点击 Add
自定义规则会与默认的 **/REVIEW.md 规则一起显示在列表中。你可以点击其旁边的垃圾桶图标来移除任意自定义规则。 当你的项目中与评审相关的文档位于非标准位置时（例如架构决策记录、风格指南，或存放在自定义路径中的团队特定约定），这会非常有用。

​
REVIEW.md

REVIEW.md 是专门为 Devin Review 准备的说明文档。将它放在代码仓库中的任意位置，即可自定义 Devin 在你的项目中审查 PR（拉取请求）的方式。Devin 会在任意目录层级（**/REVIEW.md）自动查找 REVIEW.md 文件，因此如有需要，你可以将审查规范限定到特定子目录。 使用 REVIEW.md 来定义与代码审查相关的专项规范，例如：
  • 代码库中需要额外严格审查的区域
  • 需要留意的常见陷阱或反模式
  • 审查者应当强制执行的项目特定约定
  • 在审查期间可以安全忽略的文件或目录
  • 你项目特有的安全或性能方面的注意事项
示例 REVIEW.md： 
# Review Guidelines

## Critical Areas
- All changes to `src/auth/` must be reviewed for security implications.
- Database migration files should be checked for backward compatibility.

## Conventions
- API endpoints must include input validation and proper error handling.
- All public functions require TypeScript return types — do not use `any`.
- React components should use functional components with hooks, not class components.

## Ignore
- Auto-generated files in `src/generated/` do not need review.
- Lock files (package-lock.json, yarn.lock) can be skipped unless dependencies changed.

## Performance
- Flag any database queries inside loops.
- Watch for N+1 query patterns in API resolvers.