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

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

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

在本期 GitHub Copilot 初学者应用系列中，我们将介绍四种定制 Copilot 与你的项目协作方式的方法：

让我们看看每一种是如何工作的，以及它们如何协同配合。

从自定义指令开始

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

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

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

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

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

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

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

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

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

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

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

指令、技能和代理帮助 Copilot 理解如何在你的项目中工作。MCP 服务器扩展了它可访问和可执行的范围，使其超越代码仓库。

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

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

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

这些自定义解决不同的问题，但当你将它们组合使用时，它们会变得更有用：

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

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

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