GitHub Copilot 入门：如何教 Copilot 了解代码库

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

Copilot 可以帮助你在整个项目中进行更改，但当它也了解这些规则时，效果最好。这些知识大多可以存放在仓库中，这样 Copilot 就能自动获取，而不必在你每次开始新任务时反复解释同样的标准、脚本和工作流。

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

让我们看看每一种如何运作，以及它们如何协同工作。

从自定义指令开始

假设你让 Copilot 为应用程序添加自定义页面大小。做出更改只是工作的一部分。新代码还应遵循你的团队已经采用的模式。

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

你也可以在 .github/instructions 中创建针对特定路径的指令文件。这些文件使用 applyTo 字段来告诉 Copilot 该指导在何时相关。

当 Copilot 处理匹配的文件时，它可以同时使用仓库范围的指令和更具体的指导。这样你就可以把宽泛的规则集中在一处，而不必将每种文件类型都套进同一个模子。

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

这正是 agent skills 的用武之地。skill 是一个文件夹，其中包含指令，以及可选的脚本和其他资源，Copilot 可以在它们相关时加载。项目级 skill 可以存放在 .github/skills 中，每个 skill 位于各自的子文件夹内。

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

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

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

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

当某类反复出现的工作能从专门的角色或视角中受益时，请使用自定义代理，尤其是当任务可能跨越多个文件，并借助多种工具或上下文来源时。

指令、技能和智能体帮助 Copilot 了解如何在你的项目中工作。MCP 服务器扩展了它在仓库之外可以访问和完成的事情。

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

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

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

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

为 Copilot 提供有用的项目上下文，可以从四个问题开始：

不确定从哪里开始？社区已经分享了现成的指令、技能、智能体等，均通过 Awesome Copilot 提供。找一个能应对你已经在重复的工作流的内容，查看其中包含的内容，并根据你仓库的工具和标准进行调整。

从小处开始：选择一条你反复解释的约定，将其添加到 .github/copilot-instructions.md，然后看看 Copilot 如何将其应用到你的下一个任务中。