真正可以传输的内容
结合两家厂商的官方文档，我们来逐层分析。
根目录文件：原样传输。 GitHub 的指令文档列出了仓库中任何位置的 AGENTS.md 文件（目录树中最近的文件优先），并将仓库根目录下的 CLAUDE.md 或 GEMINI.md 命名为替代方案。因此，根目录下的 CLAUDE.md 无需修改即可被 Copilot 的智能体读取。如果你的项目知识集中在那里——构建命令、规范、架构说明——那么你已经迁移了大部分核心内容。
特定路径规则：通过清晰的映射进行传输。 这是整个迁移过程中匹配度最高的一对。Claude Code 的 .claude/rules/ 目录保存了可以携带 paths: 前言（frontmatter）字段的 markdown 文件，因此只有当 Claude 处理匹配的文件时才会加载该规则。Copilot 的等效项是 .github/instructions/NAME.instructions.md，其前言使用 glob 语法接收 applyTo 字段。相同的概念，相同的 glob 词汇，不同的文件名约定。在一个系统中作用域为 src/api/**/*.ts 的规则，在另一个系统中也是作用域为 src/api/**/*.ts 的规则。
仓库级指令：第二个冗余的归宿。 Copilot 还支持 .github/copilot-instructions.md，它适用于仓库上下文中的所有请求。如果你的根目录 CLAUDE.md 正在被读取，你就不需要它，而且同时保留两者会导致内容偏差问题——两个文件，只有一个被更新。选择其中一个作为唯一事实来源。
嵌套的 `CLAUDE.md` 文件：无法传输。 这是最容易让人掉入陷阱的部分。Claude Code 的文档描述了从工作目录向上遍历目录树，沿途加载每个目录中的 CLAUDE.md 和 CLAUDE.local.md，并将所有发现的文件拼接成上下文；子目录中的文件也会被发现，并在 Claude 读取那里的文件时按需加载。而 Copilot 仅接受仓库根目录中的 CLAUDE.md——这是有文档记录的作用域。你的 packages/billing/CLAUDE.md 对它来说是不可见的。Copilot 原生表达单目录指令的方法是嵌套的 AGENTS.md，文档称当它在目录树中最近时具有最高优先级。在 monorepo（单体大仓库）中，这一个差异就可能导致你的大部分指令在无形中失效。
`@` 导入：无对应接收端。 Claude Code 的 CLAUDE.md 可以使用 @path/to/import 语法递归引入其他文件，文档记录的最大深度为四次跳转。GitHub 的指令文档没有描述任何导入机制。如果你的根文件是一个导入了五个真实文档的瘦索引，Copilot 将只读取该索引，而不会读取任何文档。
`CLAUDE.local.md`：无对应接收端。 Claude Code 支持项目根目录下的 CLAUDE.local.md，用于保存不纳入版本控制的个人偏好。Copilot 的个人偏好层是个人指令（personal instructions），它们存在于你的 GitHub 账户中，而不是仓库中。这是一个真实的层——GitHub 声明的优先级是：“个人指令优先级最高。其次是仓库指令，组织指令优先级最低。”——但它不是你本地检出代码中的文件，因此内容需要通过重新输入来迁移，而不是通过复制。
自动记忆：无对应接收端，而且它本身就无法移植。 Claude Code 的自动记忆默认开启，将每个项目的笔记存储在 ~/.claude/projects/<project>/memory/ 下，在每个会话中加载 MEMORY.md 的前 200 行或 25KB，并且明确是机器本地的——文档指出这些文件“不会在机器或云环境之间共享”。GitHub 的指令文档没有关于在会话之间持久化记忆或上下文的说明；指令文件是有文档记录的持久化机制。因此，这一层无法传输，原因不在于 Copilot 的设计——而是因为这一层从一开始就不是一个共享的产物。如果你已经遇到了这个瓶颈，这与为什么 Claude Code 会在不同机器间遗忘中描述的是同一个问题。
在开始步骤之前，请注意一个设定：两个系统都将指令描述为上下文，而不是强制执行的规则。Claude Code 的文档指出，指令是“上下文，而非强制配置”，并且内容是在系统提示词之后作为用户消息发送的，“不保证严格遵守”。GitHub 的优先级声明最后提到：“但是，所有相关的指令集都会提供给 Copilot。”两家厂商都没有承诺绝对服从。请围绕哪些内容会被读取来规划迁移，而不是围绕你希望它们遵守哪些内容。
手动迁移
步骤 1：映射有对应接收端的层
自上而下进行，并克制将所有内容合并为一个巨大文件的冲动。
保留根目录下的 CLAUDE.md。它能正常工作。如果你想对不知道 Copilot 会读取它的团队成员明确说明这一点，可以在文件顶部添加一行注释，说明两个智能体都会读取此文件。不要将其复制到 .github/copilot-instructions.md 中——否则你将需要维护两份副本，其中一份必然会过时。
将每个带有 paths: 字段的 .claude/rules/*.md 文件转换为 .github/instructions/<name>.instructions.md，并在 applyTo 下使用相同的 glob 模式。保持文件名易于识别，以便在 diff 中一眼看出对应关系。没有 paths: 字段的规则是无条件规则——Claude Code 在启动时会以与 .claude/CLAUDE.md 相同的优先级加载它们——因此这些规则属于你的根文件或 AGENTS.md，而不属于特定路径目录。
将嵌套的 CLAUDE.md 文件提升为相同目录下的嵌套 AGENTS.md 文件。这是一个重命名加上一个决策：如果你希望两个智能体都读取相同的嵌套内容，请注意 Claude Code 的文档直接指出了这种不对称性——“Claude Code 读取 CLAUDE.md，而不读取 AGENTS.md”——其推荐的模式是使用 CLAUDE.md 通过 @AGENTS.md 导入 AGENTS.md，或者使用软链接（symlink）。因此，在每个子目录中，你可以保留一个真实文件（AGENTS.md）和一个导入它的单行 CLAUDE.md。两个智能体都会读取相同的文本；而且只有一个地方需要编辑。
在继续之前，先扁平化你的导入。每个通过 @ 导入的文件都需要变成导入它的文件中的内联内容、相关目录中嵌套的 AGENTS.md，或者特定路径的指令文件。Claude Code 自己的文档指出，拆分为导入“有助于组织，但不会减少上下文，因为导入的文件在启动时就会加载”——因此，在 Claude 端的上下文方面，扁平化不会给你带来任何损失，而且这是让内容能够到达 Copilot 的唯一方法。
步骤 2：决定如何处理没有对应接收端的层
分为三堆，每一堆都需要一个实际的决策，而不是默认处理。
`CLAUDE.local.md`。 阅读并对其进行分类。这些文件中的大多数都混合了真正的个人偏好（你的沙盒 URL、你偏好的测试数据）和几个月前就应该提交的项目事实。将第二种类型提交到根文件中——无论是否使用 Copilot，你都会为此感到高兴——并将第一种类型重新输入到 Copilot 的个人指令中，请记住这些指令适用于你工作的每个仓库，而不仅仅是这一个。任何你不想放在这两个地方的内容，直接删除。一个只有一台机器上的一个工具能读取的文件不是知识库。
自动记忆。 打开记忆目录并阅读 MEMORY.md 以及主题文件。这是整个迁移过程中价值最高的一小时，因为它是 Claude 发现的关于你项目的书面记录，而你以前从未费心写下来过：构建怪癖、调试见解、测试不稳定的原因。这些内容都不会自动同步到 Copilot。将持久的事实提升到你的根文件或特定路径的指令文件中。将其余内容——关于某个模型习惯的笔记、一次性调试轨迹——留在原处。它们没有错，只是它们不属于共享知识。
你可能在往回迁移时需要的 Copilot 专属机制。 Copilot 端存在两个 Claude Code 没有的等效机制，现在了解它们可以防止以后出现意外。特定路径的指令文件支持一个可选的 excludeAgent 字段，该字段可以阻止 "code-review" 或 "cloud-agent" 使用它——因此，你刻意不让其参与代码审查的规则在另一端将无法避免。此外，组织指令是一个真实的层，可能由其他人控制；GitHub 将其排在优先级最后，但仍会提供。如果你迁移回来，或者同时运行两者，请向管理员询问该层中有什么内容。它会塑造你从未配置过的输出。
更好的方法：一个记忆层，适用于任何智能体
做一次上述操作是合理的。但每当有新的智能体出现时都做一次才是真正的问题，而且这种计算方式正在变得越来越糟糕：每个工具都发明了自己的文件名、自己的前言、自己的优先级顺序以及自己的私有记忆库，因此 N 个工具意味着 N 份相同项目知识的副本以 N 种不同的速度产生偏差。
MemoryLake 的存在就是为了打破这种模式：将项目的知识保存在一个记忆层中，让每个智能体都从中读取，而不是从它们自己的本地副本中读取。指令文件留在它们该在的地方——用于每个会话中必须存在于上下文中的规则——而积累的、不断增长的知识体则存在于两个智能体都能访问的地方。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭证，供你连接的每个工具使用，这就是重点：该凭证的生命周期比你当前选择的智能体更长。
步骤 2：上传你的第一批记忆
从你刚刚在迁移过程中挖掘出来的材料开始——来自自动记忆的持久事实、隐藏在 CLAUDE.local.md 中的项目真相、决策日志，以及那些如果没有解释就会显得武断的规范背后的原因。保持条目简短且具体。衡量一个好条目的标准是，新团队成员或新智能体是否可以在不提出后续问题的情况下根据其采取行动。
步骤 3：连接你的 AI 和智能体
连接你的工具。MemoryLake 可以通过 MCP 和 API 访问，因此原生支持 MCP 的智能体——包括 Claude Code、Codex、OpenClaw 等——通过指向 MCP 服务器进行连接，而其他任何工具则通过 API 读取相同的记忆。指令文件继续履行其狭窄的职责；共享知识不再针对每个工具进行重复。
两个限制。MemoryLake 不是一个强制执行层——如果一条规则必须在不考虑模型决定的情况下保持有效，那么它应该属于钩子（hook）或 CI 检查，正如两家厂商的文档在将指令称为上下文而非配置时所暗示的那样。而且它不会为你读取现有的文件：上述迁移清单仍然是你需要做一次的工作。
这在实践中带来了什么改变
第二个智能体的成本低于第一个。 在 Claude Code 之外添加 Copilot，昂贵的部分不是配置，而是重新推导第一个工具设置中已经隐含的知识。在共享层中做一次，第三个智能体就只是一个连接，而不是一个项目。
Monorepos 不再是特例。 嵌套文件的不对称性是指令在无形中失效的最常见原因。当特定区域的知识是可检索的，而不是依赖于每个工具在哪个目录中发现哪个文件时，树状结构就不再是兼容性问题了。
指令文件变得更短，这使它们工作得更好。 Claude Code 的文档建议将每个文件的目标控制在 200 行以内，并指出较长的文件“会消耗更多上下文并降低遵守度”。Copilot 的指南也指向同一个方向。将参考知识移出始终加载的文件，并移入可检索的内容中，这不仅仅是为了整洁——它还能显著提高剩余规则被遵循的可靠性。
审查能捕获偏差，而不是隐藏它。 只有一个事实来源时，过时的条目就是一个 diff。而当每个工具有五个副本时，过时的条目就会变成一个谜团：为什么一个智能体相信一些另一个智能体不相信的事情。
同时运行 CLAUDE.md 和 Copilot 的最佳实践
每个目录一个真实文件，外加一个指针。 保留 AGENTS.md 作为内容，并使用单行 CLAUDE.md 导入它。两个智能体都会读取相同的文本，并且只有一个地方需要编辑。
切勿复制根文件。 根目录 CLAUDE.md 和包含几乎相同文本的 .github/copilot-instructions.md 必然会导致未来的不一致。选择其中一个。
在两个系统中保持 glob 模式一致。 当 paths: 和 applyTo 以相同的语法描述相同的文件集时，你可以将它们作为成对项进行审查。当它们产生偏差时，你会遇到特定区域的规则在一个工具中适用而在另一个工具中不适用的情况，这比没有这些规则还要糟糕。
在每次结构更改后验证加载了什么。 Claude Code 在会话中公开了已加载记忆文件的列表；在移动文件后检查它。在 Copilot 端，在假设嵌套的 AGENTS.md 已被采用之前，先确认它确实已被读取。未被读取的文件看起来就像模型忽略了指令——这一区别在为什么 GitHub Copilot 会遗忘代码库上下文中有所提及。
询问组织层。 如果你的仓库位于配置了指令的组织下，无论你是否阅读过，该文本都会提供给 Copilot。去阅读它。
将必须遵守的规则放在强制执行中，而不是指令中。 两家厂商都明确表示，指令文件是塑造行为而不是保证行为。任何必须在每次提交前发生的事情都属于钩子或 CI。
结论
这次迁移的头条新闻异常令人愉快：Copilot 会读取根目录下的 CLAUDE.md，因此你已经维护的文件可以继续工作。工作量在于它周围的四个层——需要提升为 AGENTS.md 的嵌套文件、需要扁平化的导入、需要分类的本地文件，以及保存着从未共享过的知识的自动记忆目录。
做一次这样的盘点，并将其输出放在两个智能体都能读取的地方。否则，你将不得不为下一个工具再做一次，而且起点会稍微糟糕一些，因为到那时两份副本已经产生了偏差。如果你也在朝另一个方向迁移，将 GitHub Copilot 迁移到 Claude Code 涵盖了反向旅程，而将 CLAUDE.md 迁移到 Cursor 则处理了第三个常见目的地。