GitHub Copilot自定义指令完全实战指南

已更新：是的——我不得不更换横幅。它快让我疯了 🤣 我最终会让 Leonardo 用这个角色训练出来的。与此同时，ChatGPT 表现不错（忽略 v5 升级带来的性格变化和重新训练的情况）。

🦄 说实话，我原本打算下周才写这篇，但我这周写的那篇文章……消失了。而且重做已经做过的工作？零乐趣。就像重新加热薯条——在技术上可以吃，但你知道它不会像原来一样好。所以我们现在就是这样，跳过薯条，继续前进！

另外，你可能想给这篇备好零食！它比平常深入一些。是的——我确实把自己的方法评分比微软和 GitHub 的高。当然了。😛

别再把 Copilot 扔进深水区而不给救生圈！写仓库指令，测试它们，调整它们，构建它们，重复。不管你用微软的、Coding Agent 的，还是我的 Instructionalist，目标都是一样的：让 Copilot 在你的范围内工作。

这篇文章是一部分个人发言（我真的需要测试者 🙋‍♀️）和一部分我最受欢迎文章的续篇《我所学到的关于 GitHub Copilot 指令的一切（到目前为止）》。

如果你从未读过它，或者错过了最近的一些更新（是的——我总是尽量回顾之前的内容，每当 GitHub 或 VS Code 改变什么时都会说明），那就先去查看基础知识，然后再深入这里。如果你已经了解最新情况了？太好了——跳进来，我会给你盛大的导览！🏎️

原始文章仍然代表了我处理自定义指令方式的约 95%。我仍然使用了几乎所有内容。但有些东西改变了——新的入门方式，从让 Copilot 在企业代码库中"牵绳溜达"中吸取的教训，以及更清晰地关注让它写你想要的东西，而不是它认为你可能想要的东西。

🦄 另外，是的，无耻的自卖自夸：我启动了一个 awesome-github-copilot 仓库。它仍在 WIP 中，但里面已经有了一些宝石。如果你愿意做个小白鼠 🐹，请联系我！

为什么 Repo Instructions 很重要 ⚠️👇

让我们设置一下场景。你有一个庞大的遗留怪兽应用坐在角落里。没人想碰它。现在一位全新的资深开发者走了进来。你会说：

"嘿，去重构一些东西。祝你好运！"

当然不会！但这正是每次你没有任何指导或关于你期望什么的方向就把 Copilot 冷冰冰地扔进去时发生的事情。它会产生一些东西——而且它会自信地产生——完全基于你仓库最坏的模式。你会得到更多代码，更快……但根本不会更好！

💡 专业提示：不要理解错了——我不是说把 AI 当作资深开发者对待。那是如何引发生产火灾的。🔥 我说的是，它完全能够像对待一个开发者一样被指导。混乱和协作之间的区别在于你如何措辞这个要求！

计划一个前期的 15 分钟 ⌚️

那么，与其把你的黄金资深开发者在第一天就送到战壕里，你不如花 15 分钟和他们在一起呢？解释为什么代码的一半像逃生室拼图一样缠绕在一起，哪些系统在你碰错文件时会炸毛，以及为什么那个 java.io 序列化在三次 Java 升级后仍然存在。

这正是你应该对待 Copilot 的方式。

你会看到和任何能够阅读文档并在重要时做出正确决定的训练有素的开发者一样的回报。

🦄 注意：这永远不会是一个"设置后不管"的系统。经过一轮扎实的测试后，它不需要像新生儿那样需要持续照顾，但它仍然会随着你的应用而增长和变化。应用更改 = 指令更改。总是！

Repo Instructions 来救援 🚢🛟

Repo instructions 是你在 Copilot 开始挥舞锤子之前给它一个导览的机会。它们在 Copilot 运行的任何地方工作——IDE、GitHub.com，甚至移动端（根据文档）。把它们放在 main，突然间每个提示 Copilot 的人都在同样的规则、风格和"不要碰"列表下工作。

如果你在考虑简单地列出最佳编码实践只是为了展示 Copilot 逗号该放在哪里？你用错了。开始把这些文件看作任何资深开发者的事实上的入职培训，并用那个级别的信息来处理它们，让自动格式化程序处理逗号和新行。

💡 专业提示：Copilot 会自然地领会，但一句简短的话说"遵循 eslint.config.js 中的规则"通常就足以让它开始自动检查 lint 命令。

从小处开始，不要让文件变得太臃肿。如果你有一组相似的指令，你总可以把它们分离成一个自定义指令文件，与主版本分开。然后在前置元数据中使用 applyTo 来定义它们应该应用到哪些文件。

例如，你有具体的数据库指令，概述约束或即将计划的功能，你想开始"前瞻性思考"？把它们放在 .github/instructions/database.instructions.md 而不是默认文件中，并添加 applyTo。每当 Copilot 引用这些 DAO 类之一时，这些指令会自动附加。

---
applyTo: src/main/java/dao/**/*
---

# My Custom Database Instructions

三种最佳入门方式

1. Microsoft 在 VS Code 中的"Generate Instructions"（⭐️⭐️⭐️）

当这个功能刚推出时，说实话——我讨厌它。我是说，它很糟糕。"去读仓库中每个文件的第一行，复制/粘贴到一个文档中，叫它指令"那么糟。就像你的同事给你发一个谷歌搜索链接而不是实际答案。

但我必须公平——现在好多了。它实际上读取你的仓库，找到重要的东西，映射出项目结构，甚至指出工作流和自动化。仍然不完美，但你可以把它交给一个新开发者，他们不会立即尖叫着跑开。

💡 专业提示：让你的格式化程序 + linter 处理风格规则，这样你就不会浪费指令空间告诉 Copilot 逗号该放在哪里。绝对没有人需要在他们的指令文件中看到 14 个 JavaScript 的例子。

点击聊天窗口顶部的齿轮图标 ⚙️。

点击 Generate Instructions

然后，像任何负责任的仓库所有者一样，在提交前删除冗余内容。

按 Ctrl+Shift+P / Cmd+Shift+P。

搜索 Chat: Generate Workspace Instructions File。

2. Coding Agent（⭐️⭐️⭐️½ — 逐渐接近 4）

这个有点不同——它运行在 Claude Sonnet 4 上，不，你不能改变那个。好处是什么？Claude 对架构和实施策略有很好的理解，所以有点像问你团队中"大局"的人来出第一稿。坏处是什么？如果你不够具体，它会开始猜测……你可能会得到一份完整的贡献者指南，而你真的只是想要仓库设置说明。

Coding Agent 也是 PR 安全的——它总是创建一个单独的分支。你可以告诉它"尽管去吧"，走开，它在没有拉取请求的情况下不会碰你的主分支。额外奖励——你可以用一个迷你系列提示它，只要它适合单个提示，它就会为一个单一的高级请求处理你的整个列表。

💡 专业提示：这里的具体内容是关键。想象一下你在进行知识转移。你需要传达基础知识的所有重要亮点是什么？如果你不确定，省略什么比错误或提及一个"也许"要好，那会强制 Copilot 代替你猜测。

在 GitHub.com/Copilot：

去 GitHub.com/Copilot。

点击左手边栏中的 Agents。

选择你的仓库 + 基础分支（Copilot 仍然会从那里创建自己的分支）。

提示它："Generate custom repository instructions for this repo"+ 任何重要的细节。

3. 我的"Instructionalist"聊天模式（⭐️⭐️⭐️⭐️，承认有偏见）

好吧，是的，我有偏见。但这个东西存在是因为我厌倦了解释——第四或第五次——为什么每个仓库都应该有好的 Copilot 指令。

这是一个问答，其中你（也就是真正了解仓库的人）填写 Copilot 无法猜测的东西：你的 SLA、没人碰的奇怪依赖关系、"如果 X 在凌晨 3:15 发生，重启 Y 否则整个系统都会掉下来"那种知识。

它从"我们想要的地方"写，而不是"我们所在的地方"，并构建了其他方法跳过的东西——反模式、测试目标、部署说明，甚至温和的推动，比如当存在多个解决方案时"承认不确定性"。

📢 模型说明：这个也运行在 GPT-4.1 上！

我的仓库在 github.com/anchildress1/awesome-github-copilot

找到 Instructionalist 聊天模式（或任何其他你能找到的聊天模式）并复制原始内容 ⚠️ 小心！不要误拿文档。你要找的是以 .chatmode.md 结尾的文件

找到 Instructionalist 聊天模式（或任何其他你能找到的聊天模式）并复制原始内容

⚠️ 小心！不要误拿文档。你要找的是以 .chatmode.md 结尾的文件

在 VS Code 中创建新的聊天模式并用粘贴的 Instructionalist 替换默认值

在 VS Code 中创建新的聊天模式并用粘贴的 Instructionalist 替换默认值

从下拉菜单中选择自定义模式

从下拉菜单中选择自定义模式

提示 Copilot 开始 🦄 试试"Help me create repo instructions"这样的东西，给它时间扫描你的设置。然后尽你所能回答——Copilot 会过滤掉它不需要的东西。🎤 这是尝试 Speech 插件的完美时机，但先检查延迟设置，这样它就不会在你准备好之前发送。

提示 Copilot 开始

🦄 试试"Help me create repo instructions"这样的东西，给它时间扫描你的设置。然后尽你所能回答——Copilot 会过滤掉它不需要的东西。

🎤 这是尝试 Speech 插件的完美时机，但先检查延迟设置，这样它就不会在你准备好之前发送。

VS Code 中的 Microsoft 🪼

Microsoft 的指令非常注重结构。你在顶部得到"欢迎来到这个仓库"的简介（我在我的版本中省略了这个，因为为什么要呢？），以及"项目结构"和"关键概念"这样的部分。我惊讶地发现它甚至指出了状态徽章系统。它整洁且实用。它有效。

🦄 它还添加了一个简短的"如何打开自定义指令"说明——除非你之前有意地进去并关闭了它，否则你不需要这个。

通过 GitHub 的 Coding Agent 🧩

Coding Agent 的版本围绕顺序做了交换，重新命名了几个标题（虽然，我不认为"结构"和"原则"是可以互换的——所以如果你使用这个方法，考虑重新命名那个！）它在简介中跳过了状态徽章部分，但稍后用自己的"状态系统"部分回归。你也得到了内容准则、写作风格说明，以及用于内部文档的真实 markdown 链接参考（这是最佳实践）。

但它也试图偷偷塞进一整个"贡献指南"部分……说实话，这应该在 CONTRIBUTING.md 中，而不是在 Copilot 指令中。

🦄 这不是 Coding Agent 第一次试图添加 GitHub 在 PR 期间提供的每个可能的文档。它似乎被连接到这样一个事实，即如果你有一个公开仓库，那么所有这些东西都需要存在。我会更深入地研究这个，然后回报。

Instructionalist 自定义聊天模式 📢

我的版本忽略了所有"欢迎"和"结构"的样板，而是直接跳到"目的"和"价值"。它定义了聊天模式、提示和指令的方式，使 Copilot 的角色更具吸引力和互动性。Copilot 明确指出这些不仅仅是通用的 AI 提示——它们为开发过程的所有阶段策划。

这些不明确地指出状态徽章系统，但在上下文中被引用。而且你会得到你在其他两个中看不到的额外内容："成熟度级别"（所以 Copilot 知道项目是否被积极维护或只是在测试模式中驻扎）、"对其他系统的依赖"，以及，是的，偶尔还有一些知识。😇 加上明确的反模式和测试/部署计划。

🦄 我必须说出这是唯一需要用户预先参与的版本。所以自然地，它需要更长时间才能启动。如果你问我？完全值得权衡。

当你把它们并排堆放时，你可以立即看到哲学差异：

Microsoft：通过描述地图（结构、文件、概念）来定向 Copilot。

Coding Agent：通过描述游戏规则（准则、原则、风格）来定向 Copilot。

我的 Instructionalist：通过描述玩家的角色（目的、价值、模式、反模式）来定向 Copilot。

真相是什么？如果你完全忽视我显然认为我的是最好的这一事实（因为当然我是），理想的文件实际上是一个混合体。从 Microsoft 获取一点结构，从 Coding Agent 获取一点准则清晰度，从 Instructionalist 获取一点角色和背景。

每个生成的文件都很长，所以不要害怕删除任何没有显然增加价值的东西。在 /future-review 文件夹中保存额外内容。在主文件中保留要点，为了你的 PR 理智——每次改变时都要更新它们！

⚠️ 严肃地说，各位！旧指令和没有指令一样危险！

你还尝试过什么？

你有没有试过手工写指令或用 Copilot 生成你自己的指令？不管你选择 Microsoft、Coding Agent、我的 Instructionalist、这三个的某个奇怪混合体，还是完全不同的东西——我想知道什么有效（什么炸裂了）。

在评论中放下你的结果、截图或恐怖故事。额外加分如果你把你的评分比我的高。😛

……但只有在我给了它一个恰当的导览、告诉了它咖啡机在哪里，并警告它关于积极感染 LLC 的僵尸诅咒之后。

在制作这篇文章期间，没有 Copilot 被无人监管。

Ashley Childress