实际可以迁移的内容
Copilot 的自定义界面有三个层级，GitHub 为它们定义了精确的优先级顺序：首先是个人指令，然后是仓库指令，最后是组织指令——并且“所有相关的指令集都会提供给 Copilot”。
在仓库层级内部，有三个子类型，按优先级排序如下：
.github/instructions/**/*.instructions.md中的特定路径指令.github/copilot-instructions.md中的仓库级指令- 智能体指令，“在名为
AGENTS.md、CLAUDE.md或GEMINI.md的文件中指定”
另外，Copilot 还有一个记忆系统。Copilot Memory“目前处于公开预览阶段，可能会发生变化”，它存储两类内容：“仓库级事实”（如“编码规范、架构决策、构建命令和项目特定规则”）以及“用户级偏好”（被描述为“关于用户希望如何与 Copilot 交互的暗示或明确声明的个人偏好”）。
现在来进行盘点。
原样迁移。 AGENTS.md。两款工具都会读取它，无需转换。这是唯一一个白给的胜利，而且非常实在。
重写后迁移。 .github/copilot-instructions.md 和您的特定路径 .instructions.md 文件。内容是可移植的 markdown；改变的是激活机制，下文会详细介绍。
无法迁移。 有三样东西，各自原因不同。
个人指令，因为范围限制：“个人自定义指令仅在 GitHub 中的 GitHub Copilot Chat 中受支持。”它们本来就无法到达您的编辑器，因此没有什么可迁移的——但它们可能包含值得记录下来的偏好。
组织自定义指令，因为它们是组织级别的 GitHub 设置，“目前仅在 GitHub.com 上的 Copilot Chat、GitHub.com 上的 Copilot code review 以及 GitHub.com 上的 Copilot cloud agent 中受支持。”如果您的组织依赖它们，请注意，在一个团队中停用 Copilot 并不会为其他任何人移除这些指令。
Copilot Memory，因为它的存储位置以及绑定得非常紧密。仓库级事实“对在该仓库中拥有 Copilot Memory 访问权限的任何用户可用，但这些事实只能在对同一仓库的操作中使用。”用户级偏好“仅在同一用户后续的交互中可用。”目前没有记录在册的导出到其他厂商工具的路径。您可以查看它们，仓库所有者可以审查和删除仓库级事实——但手动将它们读取出来就是唯一的迁移方式。
有一个细节可以让这听起来不那么痛苦：Copilot Memory 的范围比大多数人想象的要窄。根据 GitHub 的说法，“Copilot Memory 目前由 Copilot cloud agent、Copilot code review 和 Copilot CLI 使用。”如果您的团队使用 Copilot 主要是进行编辑器内补全和聊天，那么里面的内容可能远比您担心的要少。在安排时间预算之前先检查一下——让人们纳闷为什么 Copilot forgets codebase context 的那种界面混淆，在这里同样适用。
本指南不会重新解释 Copilot 自身的层级是如何工作的；如果您首先需要了解这些，setting up Copilot memory in VS Code 完整介绍了源端的情况。接下来的内容假设您已经决定离开并希望获得映射关系。
手动迁移
步骤 1：理清每个规则实际来自哪个 Copilot 层级，然后进行盘点
在 Devin 这边编写任何内容之前先做这件事，因为优先级顺序会告诉您实际生效的行为是什么。
Copilot 的完整顺序（最高优先级在前）是：个人指令、特定路径指令、仓库级指令、智能体指令（如 AGENTS.md），然后是组织自定义指令。如果某个规范同时存在于 copilot-instructions.md 和 AGENTS.md 中，前者会胜出。如果把两者都迁移到 Devin 的始终开启（always-on）层，就会让原本失效的那个重新复活。
收集以下四样东西：
- 完整的
.github/copilot-instructions.md。 - 每个
.github/instructions/**/*.instructions.md及其路径模式。这些模式才是最有价值的部分。 - 如果存在
AGENTS.md、CLAUDE.md或GEMINI.md，也一并收集。 - 手动读取的 Copilot Memory 内容。仓库级事实是值得花精力整理的；用户级偏好是因人而异的，直接重新声明会更容易。GitHub 指出“无论使用何种 Copilot 方案，用户都可以查看和删除自己的用户级偏好”，因此每个人都可以自己处理。
在读取仓库级事实时，请注意一个关于它们如何保持准确性的有用细节：它们是“与指向支持它们的代码的引用一起存储的”，当 Copilot 使用其中一个事实时，它会“根据当前分支检查这些引用，以确认信息是否仍然准确。只有经过验证的事实才会被使用。”Devin 中没有任何功能会为您做这件事。您迁移的事实，现在需要您自己来维护其准确性。
步骤 2：为每个规则选择一种激活模式，因为 Devin 要求您必须这样做
这是真正的核心工作，也是偷懒的迁移会导致上下文窗口臃肿的地方。
Devin Desktop 的规则保存在 .devin/rules 中（首选，且它“优先级高于 .windsurf/”），并在“您当前的工作区目录”、“工作区的任何子目录”以及“直到 git 根目录的父目录”中进行查找。每个工作区规则都通过 trigger 字段在 frontmatter 中声明一种激活模式：
| 模式 | trigger: | 如何到达 Cascade | 上下文成本 |
|---|---|---|---|
| 始终开启 | always_on | 完整规则内容在每条消息的系统提示词中 | 每条消息 |
| 模型决策 | model_decision | “系统提示词中仅显示描述” | 始终包含描述；按需加载完整内容 |
| Glob | glob | 当读取或编辑匹配 globs 的文件时应用 | 仅在触及匹配的文件时 |
| 手动 | manual | 不在系统提示词中；通过输入 @rule-name 激活 | 仅在被 @ 提及时 |
从 Copilot 的映射几乎是机械式的。特定路径的 .instructions.md 文件变成 glob 规则——直接把模式复制过去。仓库级的 copilot-instructions.md 内容进行拆分：必须始终应用的部分变成 always_on，而视情况而定的部分变成 model_decision。个人偏好则放入全局规则文件中。
需要规划的两个限制：“工作区规则文件限制为每个 12,000 字符。全局规则文件限制为 6,000 字符。”另外请注意该全局文件的存放位置——~/.codeium/windsurf/memories/global_rules.md，位于 memories 目录下，这就是为什么很多人以为自己根本没有全局规则的原因。
然后是 frontmatter 特例：“全局规则文件（global_rules.md）和根目录级别的 AGENTS.md 文件不使用 frontmatter——它们始终处于开启状态。”这就是引言中提到的陷阱。您的 AGENTS.md 曾是 Copilot 中优先级最低的仓库指令；但在 Devin 中，它是无条件开启的。
最后，有一个警告会改变您应该尝试迁移的内容。Devin Desktop 的 memories 文档一开头就写道：“Memories 仅适用于旧版 Cascade 智能体。”以及：“Devin Local 智能体（新标签页的默认智能体）不会持久化 memories。”如果您的计划是将 Copilot Memory 移入 Devin memories，默认智能体将无法携带它。厂商自己的建议指向了别处：“对于您希望 Cascade 可靠重用的知识，请将其写为 Rule（规则）或添加到您仓库中的 AGENTS.md 中，而不是依赖自动生成的 Memories。规则是版本控制的、可与团队共享的，并且能让您对激活进行显式控制。”
接受这个建议。迁移后的 Copilot Memory 事实的目标位置应该是 Rule，而不是 memory。
更好的方法：将事实保留在不适用激活模式的地方
步骤 1 和 2 可以建立一个正确的 Devin 设置。但它们也给您带来了 6,000 字符的全局预算、每个文件 12,000 字符的工作区预算，并且需要为您了解的关于项目的每一件事决定激活模式。
激活模式对于规则（关于如何表现的指令）来说是一个很好的设计。但它们不适合事实。“我们使用 bun，而不是 npm”需要一个触发器。而“由于工单 4471 中记录的上游异常，支付服务会重试三次”不需要触发器；它需要的是在相关时能够被找到，永远如此，而不需要在每条消息上消耗系统提示词。
这正是记忆层所填补的空白，也是让下一次迁移变得廉价的原因。MemoryLake 只需三个步骤即可设置完成。
步骤 1：创建 API 密钥
登录并在您的控制面板中生成一个 API 密钥。该凭据属于您的团队，而不属于 Copilot 或 Devin，因此无论前面是哪个智能体，该存储库都是可读的——包括自身不持久化 memories 的 Devin Local 智能体。
步骤 2：上传您的第一批记忆
这就是读取出来的 Copilot Memory 的去处。仓库级事实：架构决策、构建命令、项目特定规则以及背后的原因。然后是每个人恢复的用户级偏好，以及以前只能到达 GitHub.com 上的 Copilot Chat 的个人指令。
将您真正的行为规则留在 .devin/rules/ 中并设置合适的触发器，并将始终为真的规则保留在 AGENTS.md 中。这种拆分才是关键：规则保持足够小以留在字符限制内，而事实不再竞争该预算。
步骤 3：连接您的 AI 和智能体
将 Devin Desktop 指向该存储库。因为存储库是外部的，它不在乎当前标签页运行的是 Cascade 还是 Devin Local 智能体——这是对 Devin 的 memories 页面顶部警告的实际解决方案。
这在实践中带来了什么改变
第一个改变是，字符限制不再是您知识库的设计约束。对于智能体应该如何表现，6,000 字符是一个合理的预算；但对于它应该知道什么，这显然是不合理的。
第二个改变是，您不再需要为事实支付激活模式的“税”。model_decision 会在每条消息的系统提示词中放入描述，并在看起来相关时获取主体内容——这对于规则来说是合理的，但对于您必须单独描述的两百个领域事实来说，则是极大的浪费。
第三个改变是，Cascade 与 Devin Local 的分裂变成了别人的问题。厂商会重组智能体；但您提交的文件和您拥有的存储库都能幸存下来。已经这样做的团队在经历 Windsurf to Devin Desktop 更名时，完全没有动过他们的知识库。
从 Copilot 迁移到 Devin 的最佳实践
- 在复制任何内容之前，先阅读优先级顺序。 如果某个规范存在于两个 Copilot 层级中，只有优先级较高的那个才会生效。
- 先检查 Copilot Memory 实际保存了什么。 它服务于 Copilot cloud agent、Copilot code review 和 Copilot CLI——并非所有界面。需要迁移的内容可能比您预期的要少。
- 原样复制路径模式。 Copilot 的特定路径指令可以干净地映射到 Devin 的
glob触发器。 - 刻意分配激活模式。 如果把所有内容都默认设为
always_on，上下文窗口在第一条提示词之前就会被塞满。 - 在 memories 目录下寻找
global_rules.md。 它位于~/.codeium/windsurf/memories/global_rules.md，并且始终开启，没有 frontmatter。 - 首选
.devin/rules而非.windsurf/rules。 它是首选位置且优先级更高，而工作区根目录下的旧版单文件.windsurfrules仍会被读取——因此如果它已过时，请将其删除。 - 不要将事实迁移到自动生成的 memories 中。 Devin 自己的文档建议对于任何您希望可靠重用的内容使用 Rules 或
AGENTS.md，而且默认智能体根本不会持久化 memories。 - 一周后审计保留下来的内容。 一个迁移了但无人验证的规则集，往往是一个被悄悄忽略了一半的规则集。Auditing what your AI remembers 是一个很好的习惯，可以帮您开启一个干净的设置。
结论
AGENTS.md 让这次迁移看起来微不足道，而且确实是其中最棒的部分。其余部分则是两种不同哲学之间的转换工作：Copilot 对指令源进行排序并将它们全部交给模型，而 Devin 则要求每个规则声明何时需要被加载。
对照着优先级顺序，刻意地进行一次这样的转换。然后将事实——决策、领域知识、原因——放在一个不需要您为每一个都挑选触发器的地方。