使用 AI 审查

本指南介绍如何让审查智能体审查一个 pull request，以及如何把结果发布到 GitHub。

开始一次 AI 审查

打开该 PR，进入它的概览标签页
打开操作行中的 ⋯ 溢出菜单，选择询问 AI

该菜单项只在 PR 处于打开状态时出现——它是一个合并前的操作。在评审标签页的空状态上（此时还没有任何审查），同一个按钮也会以询问 AI 的形式提供。

Control Center 会启动预置的 pr_review 流水线，并打开该 PR 的评审标签页，让你可以看着它运行。流水线会：

打开该 PR 自己的审查空间，其隔离工作树已把该 PR 检出到它的 head
按工作区的审阅级别并行派出审查者——默认三个（预置的 qa、architect 和 engineer 智能体，同时运行）。不做任何语言或领域检测
由主导（CEO）智能体把他们的发现项汇总成一份走查
收尾：把发现项归入共识分桶并计算判定。当关联进入 awaiting approval 时， 发布到 GitHub 会出现在评审标签页上

审查的深入程度由工作区的审阅级别决定——light（一个审查者）、balanced（三个，默认值）或 thorough（全部五个，增加安全和性能专家）——在 设置 → 工作区 → 通用中的工作区策略卡片上设置。更轻的级别提交的发现项数量完全一样，只是它一开始报告的更少。

所有审查者都发布到该 PR 唯一的审查空间中，这正是他们的发现项可以相互比较的原因。各组成部分如何配合，见 AI 审查。

pr_review 只附带手动触发器。要让它在每个已发布的 PR 上自动触发，请自行添加触发器—— 见派发审查智能体。你也可以直接从 GitHub 启动一次审查，无需任何流水线触发器：在 PR 上 @ 提及服务器的机器人，或添加 ai-review 标签——见从 GitHub PR 与 Control Center 对话。

如果弹出提示说此 pull request 上已经有一次审查正在运行，那就是确有一次仍在进行中；留在评审标签页，或打开流水线找到它。

阅读发现项

审查者把发现项记录为审查空间中的审查节点。每个节点包含：

字段	说明
类型	`bug`、`suggestion`、`recommendation`、`question` 或 `ticket`
优先级	P0（严重）→ P3（细枝末节）
类别	`security`、`stability`、`data_integrity`、`correctness`、`performance` 或 `maintainability`
文件与行号	发现项锚定在何处
原始代码	发现项所针对的代码
建议代码	提议的修复
置信度	审查者有多确信
状态	`open` → `consensus-ready` → `resolved` 或 `dismissed`

只有当一位_同行_审查者确认后，一个发现项才会到达 consensus-ready。智能体无法确认自己的发现项，因此单个审查者的意见永远不会自行升级。

评审标签页会显示发现项列表（可按类型和状态筛选，并有一个用于显示已驳回发现项的开关），旁边是汇总智能体发布的工件。确定性视图——队列、多轴仪表板、契约 diff 与视觉 diff——在服务器端计算，但应用中没有对应的界面；这一遍会产生什么，见审查计算。

检查分歧面板

当两位审查者把发现项锚定到同一个文件和行、但评价相差很大时——优先级相差两级或更多，或是一个称其为 bug 而另一个称其为 suggestion——发现项列表上方会出现一个分歧面板。先读这些：正是在这里，审查者的意见出现分歧，而你的判断最有价值。

阅读判定

当主导智能体收尾时，它会计算出一个判定：

判定	含义
Ship	未发现任何阻塞性问题
Hold	有应在合并前解决的问题
Block	有必须修复的严重问题

该判定带有一个总体置信度评分，以及按优先级统计的发现项数量。

随后审查轴会加入进来，而它们只会让判定更严重。受门禁约束且失败的轴会强制给出 Block；受门禁约束、无法完成（partial）或根本无法运行（unavailable）的轴至少会强制给出 Hold。证据缺失绝不会让门禁通过。

把审查发布到 GitHub

发布是一个单独的步骤，且刻意由用户把关。pr_review 流水线会把审查留在 Control Center 里；它不会发布到 GitHub。

在评审标签页上，等到发布到 GitHub 出现
按下发布到 GitHub

Control Center 只发送一条 GitHub 审查。已经解决或已驳回的发现项会被跳过。该按钮会包含所有仍然未解决的发现项，并且在 Ship 时提交 APPROVE。（MCP 工具 publish_review_to_github 的默认行为仍然是只提交经同行确认的发现项，并且除非你传入 approve_on_ship，否则不会批准。）锚定到文件和行号的发现项会变成行内评论；其余的一切都归入摘要正文，每一项都带有“— Control Center AI review”页脚，以便来源清楚明确。 Block 判定会以 REQUEST_CHANGES 提交；Hold 以 COMMENT 提交；Ship 则由该按钮以 APPROVE 提交。随后提示会显示已发布。审查会以服务器应用的标识发布。

如果 GitHub 因为某一行不属于 diff 而拒绝一个行内锚点，整条审查会重新发送，并把每一个发现项都归入正文，这样就不会有任何东西被悄悄丢弃。

其他内置流水线会直接发布到 GitHub：cross_review、pr_triage、ticket_to_pr 和 pre_merge_gate 都以一个评论步骤结尾。只有 pr_review 会把它的输出留给你来处理。

自己派发审查者

如果你想控制由哪些角色审查该 PR、以及每个角色看哪些文件，请在已有的审查空间中使用 dispatch_reviewers MCP 工具，或向流水线添加审查者节点。两条路径以及该工具的确切签名，见派发审查智能体。