让 Copilot 读懂你的代码库：四层上下文配置法

GitHub 官方博客给出一套把项目规则写进仓库的做法：用自定义指令、Agent Skills、自定义 Agent 和 MCP 服务器四层配置，让 Copilot 自动继承团队的架构约定、测试脚本和外部工具，不必每次任务都重复解释。

为什么要把规则写进仓库

• 每个代码库都有自己的“家规”：组件怎么组织、跑哪些脚本、不同框架和文件类型适用什么约定。
• Copilot 能跨项目改代码，但只有知道这些规则才做得好；把知识放进仓库，它就能自动读取，不用每次新任务重新交代。
• 文章给出四种定制方式：自定义指令、Agent Skills、自定义 Agent、MCP 服务器，分别解决不同层次的问题。

第一层：自定义指令打底

• 在仓库里加 .github/copilot-instructions.md，写全仓库通用的约定，比如偏好的架构、命名规范、测试与验证要求。
• 需要按文件类型区分时，在 .github/instructions 下建路径专属指令文件，用 applyTo 字段声明适用范围。
• Copilot 处理匹配文件时，会同时读取仓库级指令和更具体的路径指令，宽泛规则和细分规则可以分开维护。
• 举例：让它给应用加一个自定义页面尺寸，改代码只是一半，新代码还得符合团队既有模式，这一步靠指令兜住。

第二层：把重复流程打包成 Skill

• 有些指导只在特定流程里有用，比如跑质量检查、准备发布、排查失败的 workflow，这类适合做成 Agent Skill。
• 一个 Skill 就是一个文件夹，里面放指令，也可以放脚本和其他资源，Copilot 在相关时加载。项目级 Skill 放在 .github/skills，每个 Skill 一个子文件夹。
• 以 .github/skills/quality-checks 为例，里面的 SKILL.md 说明：什么时候用这个 Skill、哪些脚本跑测试和 lint、每个脚本检查什么、常见失败怎么排查。
• SKILL.md 里的描述帮助 Copilot 判断何时启用；改完界面后它能加载这个 Skill，按项目既定流程测试和 lint，而不是猜该跑什么命令。

第三层：用自定义 Agent 处理大任务

• 有些任务比单个流程大，比如无障碍审查，要跨多个文件看组件、模板、样式和交互。
• 自定义 Agent 就是为这类工作造一个专用版 Copilot，仓库级 Agent 配置放在 .github/agents，可定义它的用途、指令、可用工具和相关项目上下文。
• 判断标准：某类工作反复出现、需要专门视角、可能跨多个文件并调用多种工具或上下文来源时，就值得建一个 Agent。

第四层：用 MCP 服务器接外部能力

• 前三层让 Copilot 懂项目内部规则，MCP 服务器则扩展它能访问和操作的外部工具、数据源与服务。
• 文档类服务器可以给它框架指南；Playwright 这类服务器能让它在浏览器里打开并操作你的应用。
• 可以在 Copilot 应用里浏览现成的 MCP 服务器，也可以自己加。配好 Playwright 后，直接让它用 Playwright MCP 服务器手动测功能，它会像人一样打开应用交互。
• 这样验证的不只是自动化检查是否通过，还包括改完的界面行为是否符合预期。

怎么选、从哪开始

• 四个问题帮你定位：哪条项目约定我总在重复解释？哪个多步流程我总在重复做？哪类复杂任务值得配一个专属 Agent？Copilot 还需要什么外部工具或数据源？
• 社区在 Awesome Copilot 里分享了现成的指令、Skill 和 Agent，可以挑一个对应你已有重复流程的，看清内容后按自己仓库的工具和标准改。
• 起步别贪多：挑一条你总在解释的约定，写进 .github/copilot-instructions.md，看它在下一个任务里怎么用。