GitHub Copilot 入门：如何让 Copilot 了解你的代码库

使用 AI 时，上下文很重要。每个代码库都有自己的规则：组件如何组织、要运行哪些脚本，以及不同框架和文件类型适用哪些约定。

Copilot 可以帮助你在整个项目中进行修改，但如果它也了解这些规则，效果会更好。其中许多信息可以保存在代码仓库中，这样 Copilot 就能自动获取，无须你每次开始新任务时都重复说明相同的标准、脚本和工作流程。

在本期 GitHub Copilot 入门系列中，我们将介绍四种定制 Copilot 与项目协作方式的方法：

下面来看看每种方式的工作原理，以及它们如何协同工作。

从自定义指令开始

假设你让 Copilot 为应用添加一种自定义页面尺寸。完成修改只是工作的一部分。新代码还应该遵循团队现有的模式。

代码仓库自定义指令为 Copilot 提供了这类基础上下文。添加一个 .github/copilot-instructions.md 文件来定义适用于整个代码仓库的指导，例如你偏好的架构、命名约定，或对测试和验证的要求。

你还可以在 .github/instructions 中创建针对特定路径的指令文件。这些文件使用 applyTo 字段，告诉 Copilot 何时应采用其中的指导。

当 Copilot 处理匹配的文件时，可以同时使用适用于整个代码仓库的指令和更具体的指导。这样，你就能将通用规则集中放在一处，而不必要求所有文件类型都遵循同一种模式。

对于应影响多种任务的规范，自定义指令很有用。但有些指导只在 Copilot 执行特定流程时才有用，例如运行质量检查、准备发布或调试失败的工作流程。

这时就可以使用代理技能。技能是一个文件夹，其中包含指令，也可以包含脚本和其他资源，Copilot 可在相关时加载这些内容。项目级技能可以放在 .github/skills 中，每项技能分别存放在自己的子文件夹里。

例如，.github/skills/quality-checks 文件夹可以包含一个 SKILL.md 文件，说明：

SKILL.md 中的描述有助于 Copilot 判断何时适用该技能。更新界面后，Copilot 可以加载质量检查技能，并遵循项目既定的测试和代码检查流程，而不是猜测要运行哪些命令。

有些任务比单个流程复杂得多。例如，无障碍审查可能需要 Copilot 检查多个文件中的组件、模板、样式和交互。

自定义代理让你能够为这类工作创建专门版本的 Copilot。代码仓库级代理配置文件位于 .github/agents 中，可以定义代理的用途、指令、工具和相关项目上下文。

如果某类重复性工作适合由特定角色或视角来处理，就可以使用自定义代理；尤其是任务可能涉及多个文件，并需要利用多种工具或上下文来源时。

指令、技能和代理可以帮助 Copilot 了解如何在你的项目中工作。MCP 服务器则能扩展它在代码仓库之外可以访问和执行的内容。

MCP 服务器将 Copilot 连接到外部工具、数据源和服务。文档服务器可以让它访问框架指南，而 Playwright 这样的服务器则可以让它在浏览器中打开并操作你的应用。

你可以在 Copilot 应用中浏览可用的 MCP 服务器，也可以添加自定义服务器。配置好 Playwright 后，你可以这样提问：使用 Playwright MCP 服务器手动测试功能。

随后，Copilot 可以使用 Playwright 在浏览器中打开应用并与之交互，就像你亲自操作一样。这样，它不仅能验证代码是否通过自动化检查，还能确认更新后的界面是否按预期运行。

这些自定义项解决的问题各不相同，但组合使用会更有用：

为 Copilot 提供有用的项目背景信息，可以从四个问题开始：

不知道从何处着手？社区通过 Awesome Copilot 分享了现成的指令、技能、代理等内容。找一个适用于你已在重复执行的工作流程的内容，查看其中包含什么，再根据代码仓库使用的工具和规范进行调整。

从小处着手：选一条你总是在反复解释的规范，将它添加到 .github/copilot-instructions.md，然后看看 Copilot 如何将其应用到你的下一个任务中。