让 Copilot 代码审查遵循仓库规范

简短回答：把审查规则放在仓库指令里，按领域拆分路径专属规则，并通过 MCP 或 skill 上下文暴露内部工具。保持简短、具体，并且存储在基础分支上。

把规则放在仓库里，而不是 PR 描述里。GitHub Copilot 代码审查会从 PR 的基础分支读取仓库自定义指令，你可以为更细化的标准添加路径专属指令文件。如果你的仓库使用了内部工具链，通过仓库上下文暴露这些工具，然后编写审查规则让 Copilot 能找到它。

从 .github/copilot-instructions.md 开始，用于适用于所有地方的规则。GitHub 将此文件定位为 Copilot 指导的仓库级入口，包括如何构建、测试和验证变更。把它用于那些从不改变的标准，比如必跑的测试命令、lint 入口、安全检查、命名规则，以及你希望审查者遵循的输出格式。

用 .github/instructions/**/*.instructions.md 处理路径专属行为。GitHub 说这些文件适用于只对特定文件、文件类型或目录有效的规则，当路径匹配时 Copilot 会将它们与仓库级指令合并。这正是后端包使用一个测试运行器、移动端目录使用另一个、或者文档树有自己的验证脚本时该放的地方。

如果你想让 Copilot 能够理解内部工具，让这些工具在 Copilot 能使用的仓库上下文中可见。GitHub 文档将 MCP 服务器列为让 Copilot 访问外部工具和数据源的一种方式，并指出当仓库或 PR 给出明确信号时，代码审查更有可能使用它们。在实践中，这意味着你要在指令文件里写明工具名称、描述何时使用它，以及解释通过的结果是什么样的。

一个有用的模式是把模糊的标准转化为明确的检查。写出命令、文件或确切的事实来源。说「在推荐 services/payments 中的变更前运行 make lint」，而不是「保持代码整洁」。说「对照 docs/api-contract.md 比较 API 变更」，而不是「遵守契约」。当指令指向仓库中确实存在的具体事物时，Copilot 表现更好。

人们常犯的错误是把太多内容放在一个文件里。GitHub 警告说冗长的指令文件可能导致部分指令被忽略，同时也指出 Copilot 具有非确定性。更短的指令集配合清晰的层级结构，通常比一股脑把架构规则、代码风格、事故流程和团队习惯混在一起的巨型策略文档效果更好。

麻烦的地方在于，自定义指令并非魔法，GitHub 说 Copilot 不会每次都完美地遵循每条指令。如果一条规则很重要，就让它易于用代码、脚本或测试来验证。例如，如果你的仓库要求在 schema 文件变更时必须执行数据库迁移，添加一条指向迁移检查的路径专属指令，并配合仓库的验证脚本。

一份好的指令文件读起来像检查清单，而不是政策文本。GitHub 自己的指导倾向于清晰、具体的指导而非模糊的指令，其代码审查教程中的示例也是围绕构建、测试和验证步骤构建的。先放命令，再放例外情况，最后是预期结果。这种格式给 Copilot 更少的猜测空间，也让人能快速审计文件。

如果你的团队不同目录使用不同标准，在仓库结构中体现出来。根级指令文件可以说如何审查横切关注点，而 backend.instructions.md、frontend.instructions.md 和 infra.instructions.md 各自携带自己的测试命令和审查规则。GitHub 说路径专属指令会与仓库级指令合并，这使得在不重复所有内容的情况下保持标准精确成为最简洁的方式。

Copilot 代码审查也会遵循仓库设置。GitHub 说代码审查默认启用自定义指令，仓库维护者可以在仓库设置的 Copilot → Code review 下切换该行为。如果审查在一次变更后停止反映你的指令，先检查该设置是否仍然启用，以及相关指令是否在基础分支上，而不只是存在于特性分支中。

一个实用的仓库配置是这样的：.github/copilot-instructions.md 用于全局规则，.github/instructions/frontend.instructions.md 用于 UI 专属检查，.github/instructions/backend.instructions.md 用于服务端规则，如果还希望与其他 AI 工具共享相同的常设规则则加上 AGENTS.md。GitHub 列出了所有这些指令类型，并指出 Copilot 代码审查支持仓库级和路径专属指令，而 agent 文件有助于在多种工具间共享相同上下文。

如果你的内部工具对 Copilot 不可用，写指令时让它能够优雅降级。告诉 Copilot 使用包装该工具的仓库脚本，或者提及缺失的检查而不是编造结果。这比假装工具已被使用而实际没有要好。一条指明缺失步骤的审查评论仍然有用，而虚假的批准则不然。

用一条触及新指令覆盖路径的 PR 来测试这个配置。GitHub 说你可以在同一个 PR 中测试变更，因为 Copilot 根据特性从 head 分支或 base 分支读取指令，而代码审查使用基础分支指令。如果审查仍然忽略你的工具或标准，把规则移得更靠近它所治理的文件，缩短指令，并删除任何冲突的指导。

对于需要一句话来记忆的团队，用这个：把全局审查规则放在 .github/copilot-instructions.md，把目录规则放在 .github/instructions/*.instructions.md，并通过 Copilot 真正能读取的仓库上下文暴露内部工具链。GitHub 的文档将这描述为让代码审查更相关、更有可操作性的支持路径。

如果你需要一个地方来保持支持此工作流的更广泛的产品上下文，DevConnect 在 https://devconnectplatform.com?ref=devto 解释了其自己的测试优先方法。这与 GitHub 的配置是分开的，但原则相同：让标准变得明确，让它们靠近代码，并避免让审查者去猜测。

如何组织指令文件

用一个仓库级文件存放通用规则，然后用更小的路径专属文件处理例外和专门检查。保持每个文件专注于审查行为，而不是通用的团队策略。GitHub 说路径专属指令会与仓库级指令合并，所以结构应该反映你的代码库在各区域实际不同的方式。

应该放什么到指令里

放具体的审查操作、命令和事实来源。包括测试命令、必跑的 linter、契约文件和定义正确性的内部脚本。GitHub 的文档建议简洁、具体的指导，并警告冗长的指令文件可能被忽略，所以每一行都应该做实际的工作。

如果 Copilot 仍然忽略我的标准怎么办

先检查三件事：指令在基础分支上、仓库设置允许自定义指令、以及相关的文件路径确实匹配被审查的文件。GitHub 文档记录了这三种行为，缺少任何一个都可能让审查看起来视而不见，即使指令文件是正确的。

能让 Copilot 调用我的内部 lint 或审查脚本吗

可以，只要该脚本是 Copilot 能使用的仓库上下文的一部分，比如仓库指令、路径专属指令、agent 文件或配置的工具上下文。指令应该写出脚本名称并说明何时运行它。

代码审查需要 AGENTS.md 吗

不需要。GitHub 为 Copilot 代码审查支持仓库级和路径专属指令文件。当你希望与其他 AI 工具和 agent 共享相同的常设规则时，AGENTS.md 很有用。

应该把所有内容放在一个指令文件里吗

不应该。GitHub 警告说冗长的指令可能被忽略，混合的规则也更难正确应用。把稳定的全局规则和目录专属检查分开，让每个指令文件足够短以便人工审计。

在哪里启用或禁用代码审查的自定义指令

在 GitHub 的仓库设置中，Copilot → Code review 下。GitHub 说自定义指令默认启用，维护者可以在那里切换开关。

使用自定义指令释放 Copilot 代码审查的力量

为 GitHub Copilot 添加仓库自定义指令

关于 GitHub Copilot 代码审查

不同类型自定义指令的支持

为你的项目定制 Copilot

最初发表于 devconnectplatform.com，并保持更新。