在拉取请求的整个生命周期中使用 GitHub Copilot 代码评审

Introduction

Copilot 代码评审作为拉取请求工作流的一部分使用时，效果最佳。本教程介绍如何在手动评审和自动评审之间进行选择，提前请求草稿拉取请求，以及如何在合并之前触发重新评审。

你还将了解应在何时使用自定义、技能、MCP 服务器和运行器选项，以便根据你的需求定制 Copilot 的审查。

选择评审模型，并为草稿和主动拉取请求设置早期反馈。

Copilot 代码评审可以在你自行触发时手动运行，也可以在拉取请求生命周期的一个或多个阶段自动运行。人工审核让你可以精确控制 Copilot 代码评审何时介入。自动评审可确保一致的覆盖面，你可以选择它们是在打开、草稿还是每次新推送时触发。

审阅模型	最适用于	为什么
人工审核请求	高上下文更改或选择性使用	只有在你想听听其他视角时，才能调用 Copilot。
对未关闭的拉取请求进行自动评审	需要广泛、一致的覆盖范围的团队	每个拉取请求都会获得基线反馈，而无需依赖个人习惯。
对草稿拉取请求的自动评审	希望获得更早反馈周期的团队	作者可以在人工评审开始之前修复问题。
对新推送进行自动评审	快速迭代且经过多次修订的拉取请求
Copilot 会随着拉取请求的演变重新评估重大更新。

借助 Copilot 代码评审审查草稿拉取请求，可让你在请求团队进行评审之前，及早并可靠地检查代码。

有用的草稿工作流是：

这种方法有助于团队将更多人工评审时间投入到设计取舍和产品影响上，而不是花在那些原本可以更早发现的明显问题上。

通过确定何时发起重新评审，以及在哪些情况下自定义、外部上下文和运行器能够发挥价值，来提升评审质量。

进行重大更改后，请求重新审查，以检查在解决早期反馈时是否引入了新风险。

在以下情况下申请重新审核：

对于频繁更新活动拉取请求的团队，启用对新推送的自动评审可以减少手动重新评审请求，同时保持反馈最新状态。

当每种文件类型支持工作流中的评审决策点时，自定义功能最有用：

使用 .github/copilot-instructions.md 表示适用于大多数拉取请求的整个存储库范围内的评审要求。
当代码库的不同部分采用不同标准时，请使用 .github/instructions/**/*.instructions.md 提供针对代理和路径的特定指导。
使用 AGENTS.md 来提供有助于提高相关性的存储库上下文，例如预设模式、体系结构边界或评审优先级。

让这些文件聚焦于评审者在拉取请求评审期间需要据此作出决定的内容。避免将它们变成完整的工程手册。

当团队需要依赖于组织特定上下文的评审时，代理技能和 MCP 服务器最有价值。

如果需要可重用评审例程，请使用代理技能，例如：

当评审需要参考拉取请求本身之外的上下文时，请使用 MCP 服务器，例如：

在许多情况下，标准的 GitHub 托管运行器对于 Copilot 代码评审来说已经足够，并且无需进行任何设置；默认情况下，系统已为你完成配置。

在您需要以下情况时，请考虑使用自托管或更大的运行器：

需要使用运行器，因为 Copilot 代码评审会使用 GitHub Actions 执行代理式操作，例如更深入地收集上下文信息和调用工具。如果 GitHub托管运行器不可用，且未正确配置任何受支持的自托管选项，评审将退回到功能更受限的模式。

有关规划和设置详细信息，请参阅为 GitHub Copilot 代码评审配置运行器。

团队方案	建议的工作流
频繁提交拉取请求的小团队	为所有拉取请求启用自动评审，评审草稿以尽早获得反馈，并在变更较大时在合并前进行手动重新评审。
具有混合堆栈的大型单存储库	启用自动评审并评审新的推送，为每个主要领域添加路径专属说明，并针对重复出现的评审模式使用技能。
安全敏感或受监管的代码库	在合并前使用草稿拉取请求评审并要求重新评审，将整个存储库范围内的安全要求保留在 `.github/copilot-instructions.md` 中，并使用 MCP 服务器处理存储在 GitHub 外部的事件或合规上下文。
具有内部平台依赖项的团队	从自动评审开始，只有在为了提供有用的评审反馈而确实需要访问内部系统时，才添加自托管运行器和 MCP 上下文。