如何确定在每个界面上读取哪个 Copilot 指令文件（2026 指南）

GitHub 完整发布了该列表，并介绍道："以下列表显示了完整的优先级顺序，列表中位置较高的指令优先于位置较低的指令。" 按此顺序，这些条目依次为：个人指令；然后是仓库自定义指令，其自身顺序为"任何适用的 .github/instructions/**/*.instructions.md 文件中的特定路径指令"，然后是".github/copilot-instructions.md 文件中的仓库级指令"，接着是"智能体指令（例如在 AGENTS.md 文件中）"；最后是组织自定义指令。

这个列表中的三件事让人感到意外。

个人优于一切。 软件中的大多数指令系统都将组织放在最顶层，个人放在最底层。Copilot 则相反，而且这是刻意为之：组织要求始终用某种语言回答的指令只是默认设置，而不是强制命令，个人可以覆盖它。GitHub 明确指出，组织指令"适用于组织的所有成员，无论他们的 Copilot 订阅是否来自该组织" —— 它们适用范围很广，但仍然排在最后。

智能体文件排在仓库文件之下。 AGENTS.md、CLAUDE.md 和 GEMINI.md 被列在 .github/instructions/**/*.instructions.md 和 .github/copilot-instructions.md 之下。那些迁移到与供应商无关的智能体文件、却保留了旧仓库文件的团队，在无意中降低了新文件的优先级。迁移方向本身是一项具有自身权衡的实际操作，我们在将 CLAUDE.md 移入 AGENTS.md以及针对此特定目标的将 CLAUDE.md 移入 Copilot中详细探讨过。

没有任何内容会被丢弃。 这句话改变了你阅读整个列表的方式："然而，所有相关的指令集都会提供给 Copilot。" 这里的优先级并不是过滤掉失败者的筛选器。每个适用的指令集都会提交给模型，而顺序描述了在发生冲突时哪一个会胜出。因此，你忘记删除的冲突规则仍然存在于提示词中，仍然在消耗注意力，仍然偶尔会在你意想不到的措辞上胜出。GitHub 的建议紧随其后："只要有可能，请尽量避免提供相互冲突的指令集。"

在这一切的底层是覆盖范围问题。关于智能体指令，GitHub 写道，它们"类似于仓库级的自定义指令，但目前并非所有 Copilot 功能都支持，" 并且它们"在名为 AGENTS.md、CLAUDE.md 或 GEMINI.md 的文件中指定。" 对于组织指令，支持说明则更为狭窄："组织自定义指令目前仅支持 GitHub.com 上的 Copilot Chat、GitHub.com 上的 Copilot 代码审查以及 GitHub.com 上的 Copilot 云智能体。"

将这两条说明结合起来看，实际情况就清晰了。哪个文件主导回复取决于你处于哪个 Copilot 界面，同一个仓库在编辑器中、在 GitHub.com 的聊天中以及在拉取请求（pull request）审查中的表现可能会有所不同 —— 而任何地方都不会有消息告诉你加载了哪些规则。这就是我们在为什么智能体悄悄跳过你的指令文件中描述的常见失效模式。

在上一级再次添加规则。 当规则被忽略时，人们的本能反应是提升其级别：如果仓库文件不起作用，就把它放到组织设置中。鉴于已公布的顺序，这实际上是将规则在优先级列表中下调，而不是上调。如果个人指令与之冲突，提升级别只会让冲突变得更严重。

将所有内容合并到一个文件中。 这很合理，而且确实消除了冲突。但它也丢弃了特定路径范围指令做得很好的一点：.github/instructions/**/*.instructions.md 仅在匹配的地方适用，这正是你防止前端规范混入后端回答的方法。将所有内容折叠到单个仓库级文件中会使每个规则都变成全局规则。

在不检查哪个界面读取哪个文件的情况下删除旧文件。 只有在你确切知道答案的情况下，这才是安全的。因为文档指出并非所有 Copilot 功能都支持智能体指令，所以为了使用 AGENTS.md 而删除 .github/copilot-instructions.md 可能会导致某些界面完全没有任何指令 —— 而且它不会对此发出声明。

在错误的地方进行测试。 人们在编辑器中验证仓库指令，并得出它在所有地方都适用的结论，或者在 GitHub.com 的聊天中进行测试，并得出相反的结论。鉴于每个界面的支持说明不同，一次测试只能证明一个界面。

假设拉取请求读取的是合并后的状态。 事实并非如此。GitHub 明确指出："在审查拉取请求时，Copilot 从源分支（包含你更改的分支）而不是目标分支读取仓库自定义指令、智能体指令和智能体技能。" 好处在同一条说明中指出 —— "因此你可以在同一个拉取请求中测试对它们的更改" ——而坏处则是硬币的另一面：一个偏离了 main 分支的分支会根据其自身较旧的规则来进行自我审查。

将指令文件视为记忆层。 它们是被重新读取的配置，而不是累积的记录。设置持久化端是一项独立的操作，在在 VS Code 中设置 Copilot 记忆中有所介绍。

目标不是挑选出唯一正确的文件。而是能够在五秒钟内回答出是哪个文件主导了给定的回复。

步骤 1：写下顺序，然后检查你实际拥有的文件

首先列出仓库中存在的内容：特定路径范围的指令目录、仓库级文件、智能体文件或其某种组合。然后将你的个人指令放在它们旁边，因为在已公布的顺序中，个人指令的优先级高于这三者。

此时常见的发现是一个没人记得添加过的文件。因为所有适用的指令集都会提供给 Copilot，而不是被过滤掉，所以一个被遗弃的文件并不是不起作用的 —— 它仍然存在于提示词中。在调整你正在维护的内容之前，先删除你不再维护的内容。

步骤 2：按规则决定范围，而不是按文件

GitHub 官方的指南就是关于范围的：自定义指令"在作为简短、独立的陈述时最有效，" 并且在选择是在个人、仓库还是组织级别添加指令时，你应该"考虑你希望指令适用的范围。"

这是正确的决策轴。语言偏好是个人层面的。框架规范是仓库级的。仅适用于一个目录的规则属于特定路径范围的文件，而这正是你通过合并所放弃的唯一功能。每个成员默认应该获得且可以覆盖的策略是组织级的 —— 并且值得在明知其排在最后且仅在三个 GitHub.com 界面上受支持的情况下编写。

步骤 3：按界面验证，并在你正在审查的分支上验证

在团队实际使用的每个界面中运行相同的提示词，并记录规则在何处生效。这是一个只需十分钟的操作，却能代替反复出现的争论。

对于拉取请求，请记住源分支规则。如果你更改了指令文件并希望审查能够反映这一更改，请在被审查的分支中进行更改。如果一个长期存在的分支产生的审查忽略了大家上个月都同意的规则，请检查该规则是否已合并到该分支中。跨仓库的冲突层本身就是一个维护问题，我们在调和冲突的 Claude.md 层中探讨过这个问题。

指令文件回答的是"你应该如何表现。" 它们并不适合存放"我们决定了什么以及为什么，" 而这正是人们一直试图存储在其中的东西。MemoryLake 是一个你专门用来写入这些决定的存储库，它与任何单一工具的配置分开，并且可以从你连接的每个助手进行读取。你自己用自己的话编写这些条目。没有任何内容会从 GitHub 的系统或任何其他供应商的存储中读取、写入或删除 —— 你的仓库文件和 Copilot 设置完全保持在它们自己的控制之下。

步骤 1：创建 API 密钥

从仪表板生成一个密钥。正是它让 Copilot、终端智能体和聊天助手能够访问同一组事实，而不需要它们各自拥有自己的文件。

步骤 2：上传你的第一批记忆

从规则背后的决定开始：为什么存在该规范、它取代了什么、排除了哪种方法以及依据是什么。指令文件承载规则；它们很少承载原因，而原因正是阻止规则被下一个人推翻的关键。

步骤 3：连接你的 AI 和智能体

将你的工具指向该层，以便在会话开始时加载这些事实，而不是从规则文件中推断。然后用唯一能证明一切的方法进行测试：向另一个助手询问其中一个决定。如果它能回答，说明你的推理不再受限于单一供应商的文件格式。

第一个改变是关于优先级的争论结束了。顺序已经公布，个人优于组织，并且无论如何所有指令集都会被提供。一旦团队一起阅读了该列表，大部分争论就会转化为一次简短的清理工作。

第二个改变是覆盖范围成了人们真正关心的问题。"哪个文件胜出" 远没有 "这里究竟读取了哪个文件" 重要，而每个界面的支持说明正是令人意外的地方。

第三个改变是被遗弃的文件不再是无害的。因为每个适用的指令集都会提交给模型，所以旧文件是一个活跃的参与者。将删除视为维护而不是家务杂事，会立即改变人们的行为。

第四个改变是拉取请求审查变得可预测。从源分支读取指令是一个明智的设计 —— 它允许你在同一个拉取请求中测试规则更改 —— 而且只有在不为人知时，它才是一个陷阱。

每个范围只保留一个文件，其余的删除。 特定路径范围用于目录规则，仓库级用于项目规则，智能体文件用于其他工具需要的地方，个人文件用于你自己。

编写简短、独立的陈述。 这是 GitHub 官方的指南，在合并多个指令集时这一点尤为重要。

预期个人指令会胜出。 如果团队规则一直失效，在重写仓库文件之前，先检查是否有人在个人设置中与其冲突。

分别验证每个界面。 文档指出并非所有 Copilot 功能都支持智能体指令，而组织指令仅在三个 GitHub.com 界面上受支持。

在被审查的分支上更改指令文件。 拉取请求审查是从源分支而不是目标分支读取它们的。

将推理过程保存在其他地方。 一个同时承载自身历史记录的规则文件将不再简短，而简短正是使其发挥作用的关键。

GitHub 公布了 Copilot 指令的完整优先级顺序，其结构值得了解：个人指令排在第一位，然后是特定路径范围的仓库指令，接着是仓库级文件，然后是像 AGENTS.md 这样的智能体文件，最后是组织指令。所有适用的指令集仍然会提供给 Copilot，因此优先级决定的是冲突时的胜负，而不是移除失败者。

相比顺序，导致更多人浪费下午时间的是覆盖范围。智能体指令"目前并非所有 Copilot 功能都支持，" 组织指令在文档中仅支持三个 GitHub.com 界面，而拉取请求审查是从源分支读取这些文件的。一条规则可能写得完美无缺、放置得当，但却根本没有在你测试的地方加载。

这一切都不是缺陷，GitHub 公开记录了所有这些内容。实际的做法是保留更少的文件、深思熟虑地决定每条规则的范围、在团队使用的每个界面上进行验证，并将规则背后的推理保存在配置文件本不该承载的其他地方。