一个仓库本来就有自己的规矩——目录怎么分、命名怎么统一、跑测试到底用哪条命令。问题在于这些规矩通常只存在人脑里，没有写在机器读得到的地方。GitHub 这篇面向初学者的 Copilot 教程把它们搬进仓库，分成四个可以提交到代码库的层次，再加 MCP 服务器解决「够不够得着」的问题。

关键事实

项目 内容
回答的问题 怎么让 GitHub Copilot 了解我项目的约定？
简答 把约定写进仓库，而不是写进提示词。仓库级规则放 .github/copilot-instructions.md；只对某类文件生效的规则放 .github/instructions，用 applyTo 指定范围；反复要做的流程做成技能，放 .github/skills，各自带一个 SKILL.md；跨文件的大活定义成自定义智能体，放 .github/agents。MCP 服务器再把 Copilot 够得着的范围往外扩…
阅读时长 ~2 分钟
最后更新 2026-10-13

四层结构，各管什么

  • 自定义指令：仓库级文件 .github/copilot-instructions.md。一段话写清架构、用哪个包管理器、怎么跑起来、怎么跑测试。这是应该最先加的一层，因为它影响几乎每一个任务。
  • 按文件生效的指令：.github/instructions/ 目录，配 applyTo 字段（例如 **/*.tsx）。这样约定只跟着它该管的目录走，前端规则不会漏进构建脚本。
  • 智能体技能（skills）：.github/skills/<名称>/SKILL.md。技能是一段被调用时才加载的流程，可以自带说明和资源。适合「你反复要做的那串步骤」，而不是「你反复要说的一句话」。
  • 自定义智能体（custom agents）：.github/agents/。用来承载比单个流程更大的活：它为什么存在、适用哪些指令、能用哪些工具。要同时检查组件、模板、样式和交互的可访问性审查，就是这一类工作。
  • MCP 服务器：解决「够不够得着」。文档服务器是最简单的例子；Playwright 更有意思——它能让 Copilot 在浏览器里打开正在运行的应用，亲自验证改动后界面是不是真的像描述的那样表现。

文章作者是 GitHub 的 Christopher Harrison，发布于 2026-10-12（https://github.blog/ai-and-ml/github-copilot/github-copilot-app-for-beginners-how-to-teach-copilot-about-your-codebase/）。真正值得学的是它的落点：这些内容一条都不写在提示词里，而是写进仓库。

就算不用 Copilot，也值得抄的那部分

四层是细节，底下的习惯才是能搬走的东西。别的智能体用的是各自的指令文件，但动作完全一样——把项目的规矩写进项目里，写一次，之后每个任务都继承它。

这个习惯在桌面智能体上收益最大，因为它面对的是你本机真实的文件，而不是浏览器标签页里的副本。规矩写在仓库里，决定了它是「照你的约定办事」，还是「每次自己猜」。落地就两个做法：一次只描述一条约定；下一个任务就去看它有没有真的被应用。没被应用，通常说明这条约定太含糊或埋得太深，该收紧，而不是继续往清单里加。

第一遍可以照做的清单

  1. 先挑你解释最频繁的那条约定：测试命令、命名规则、绝对不能动的目录。
  2. 写进 .github/copilot-instructions.md（或你所用的智能体对应的指令文件）。
  3. 跑一个日常任务，看它有没有被应用。
  4. 只有当一条规矩确实是一串流程时，才升级成技能；只有当工作跨很多文件时，才定义自定义智能体。
  5. 去 GitHub 的 Awesome Copilot 合集看现成例子，但要改成适合自己项目的版本，别直接粘。

想在 Windows 上用同一套思路——让智能体动手前先读你项目的规矩，每条命令执行前都要你确认——这正是 MOOGH 提供的桌面智能体工作方式。可以在 https://agent.aimoogh.com/download 获取。 ?????

相关阅读：