面向初学者的 GitHub Copilot 应用:如何让 Copilot 了解你的代码库

GitHub Blog 2026-10-13T05:42:45.651452

和 AI 一起工作时,上下文很关键。每个代码库都有自己的「家规」:组件怎么组织、要跑哪些脚本、不同框架和文件类型各有哪些约定。Copilot 能帮你在整个项目里做修改,但它了解这些规矩时效果最好。这些知识大部分可以直接放在仓库里,让 Copilot 自动读取,省得你每次开始新任务都要把同一套规范、脚本和工作流再讲一遍。

在「GitHub Copilot 新手指南」系列的本篇里,我们来看四种定制 Copilot 与项目协作方式的手段:

下面我们逐一看看它们各自怎么用,以及如何配合起来。

从自定义指令开始

假设你让 Copilot 给某个应用加一个自定义页面尺寸。改代码只是任务的一部分,新代码还得符合团队已经在用的那套模式。仓库级的自定义指令就是给 Copilot 打底用的。

在仓库里加一个 .github/copilot-instructions.md 文件,用来定义适用于整个仓库的指导,比如你偏好的架构、命名规范,或者对测试和验证的要求。

你还可以在 .github/instructions 里创建针对特定路径的指令文件。这类文件通过一个 applyTo 字段告诉 Copilot 这条指导什么时候适用。当 Copilot 处理的文件正好匹配时,它会同时参考仓库级指令和更具体的这条指导。这样,通用规则可以放在一个地方统一维护,又不必把所有文件类型硬塞进同一套模子里。

把可重复的流程打包成 Agent 技能

自定义指令适合那些会影响很多任务的规范。但有些指导只在 Copilot 执行某个特定流程时才有意义,比如跑质量检查、准备发布,或者排查失败的工作流。这时候就该用 Agent 技能了。

技能(skill)就是一个文件夹,里面装着说明文档,还可以放脚本和其他资源。Copilot 在需要时会自动加载这些内容。项目级技能放在 .github/skills 下,每个技能占一个子文件夹。比如 .github/skills/quality-checks 这个文件夹里可以放一个 SKILL.md,说明:

SKILL.md 里的描述能帮 Copilot 判断什么场景下该用这个技能。改完界面后,Copilot 就能加载 quality-checks 技能,按项目既定的流程跑测试和检查,而不是自己瞎猜该执行哪条命令。

需要更专业的工作,就用自定义代理

有些任务比单一流程复杂得多。比如做无障碍检查,Copilot 可能要翻好几个文件,看组件、模板、样式和交互。这种情况就可以用自定义代理(custom agent)——相当于给 Copilot 定制一个专门角色。

仓库级的代理配置放在 .github/agents 里,可以定义代理的用途、指令、工具和相关的项目上下文。如果某类工作反复出现,而且需要专门的视角或角色,尤其是任务跨多个文件、要调用多种工具或信息源时,就适合用自定义代理。

用 MCP 服务器把 Copilot 接到外部工具

指令、技能和代理都是帮 Copilot 理解「在这个项目里该怎么干活」。MCP 服务器则是把它的触角伸到仓库之外——连接外部工具、数据源和服务。

MCP(Model Context Protocol)是一套让 AI 助手连接外部能力的协议。文档服务器能让 Copilot 查到框架的使用指南;Playwright 这类服务器则能让它在浏览器里打开你的应用并与之交互。你可以在 Copilot 应用里浏览现成的 MCP 服务器,也可以自己加一个。

配好 Playwright 之后,可以这样问:

Use the Playwright MCP server to test the functionality manually.

Copilot 就会用 Playwright 打开浏览器里的应用,像你平时那样去操作它。

这样,Copilot 不仅能验证代码能否通过自动化检查,还能确认更新后的界面表现是否符合预期。

选择合适的自定义类型

这些自定义功能解决的是不同问题,但组合起来用效果更好:

带走这几点

想让 Copilot 获得有用的项目上下文,先从四个问题入手:

不知道从哪开始?社区已经通过 Awesome Copilot 分享了现成的指令、技能、智能体等资源。找一个能解决你已经在重复的工作流的,看看里面有什么,再根据你仓库的工具和规范做调整。

查看原文