实际迁移了什么
Copilot 记录了三种类型的仓库自定义指令，以及它们之上和之下的另外两个层。
仓库级别的三个层：
"仓库级自定义指令，适用于在仓库上下文中发出的所有请求。这些指令在仓库.github目录下的copilot-instructions.md文件中指定。"
"特定路径自定义指令，适用于在与指定路径匹配的文件上下文中发出的请求。这些指令在仓库中.github/instructions目录内或其下方的的一个或多个NAME.instructions.md文件中指定。"
"智能体指令，类似于仓库级自定义指令，但目前并非所有 Copilot 功能都支持。这些指令在名为AGENTS.md、CLAUDE.md或GEMINI.md的文件中指定。"
在它们之上是个人指令，您在 "GitHub.com 上的 Copilot Chat 页面弹窗中" 设置，并且 "Copilot 仅适用于您。" 在它们之下是组织自定义指令，"只能由拥有 Copilot Business 或 Copilot Enterprise 订阅的组织的组织所有者设置。"
优先级链按自上而下的顺序记录：个人指令，然后是特定路径指令，接着是仓库级指令，然后是智能体指令，最后是组织指令。该部分中有一项条款改变了迁移计划的制定方式：
"多种类型的自定义指令可以应用于发送给 Copilot 的请求。个人指令优先级最高。仓库指令次之，组织指令优先级最低。然而，所有相关的指令集都会提供给 Copilot。"
仔细阅读最后一句话。优先级解决的是冲突，它并不排除任何内容。所有相关的内容都会被输入。
Factory 的模型故意设计得更窄。其 AGENTS.md 文档描述了一个具有特定职责的文件：
"AGENTS.md 为 Droid 提供了它在每个会话中应携带的项目简报：如何安装、运行、测试、编辑、验证，并保持在仓库的边界内。"并且它对结构和作用域有明确的要求：
"在仓库根目录下添加 AGENTS.md。先从一个文件开始，然后仅在包、应用或服务需要不同规则的地方添加嵌套文件。""用它来提供在 Droid 编写代码之前应该加载的指导。保持简短、具体且易于验证。"
所以，实际迁移的是这些。您的仓库级文件几乎可以直接迁移。您的 AGENTS.md——如果您已经为 Copilot 的智能体指令准备了一个——可以原样迁移，并且现在它成为了主要界面，而不是优先级最低的界面。您的特定路径指令在内容上可以迁移，但机制会发生变化。而您的个人和组织指令则完全无法迁移，因为没有什么可以复制的：一个存在于针对您个人的网页弹窗中，另一个存在于针对您公司的组织设置中。
手动迁移步骤
步骤 1：收集两个非文件的层，并决定它们的去向
这是最容易被跳过的步骤，所以请先做这一步。
个人指令。 打开 GitHub.com 上的 Copilot Chat 页面，阅读该弹窗中的内容。在大多数团队中，它包含两类内容：真正的个人偏好（“每行解释一个概念”，“始终用葡萄牙语回答”——官方文档自己的例子）以及根本不应该是个人指令的规则，因为它们描述了项目是如何运作的，且每个团队成员都需要它们。
将它们拆分。个人偏好属于 Factory 的用户级设置，位于 macOS 和 Linux 上的 ~/.factory/settings.json，以及可选的 settings.local.json。隐藏在个人弹窗中的项目规则属于仓库的 AGENTS.md，这样团队的其他成员终于可以获取它们。这通常是整个迁移过程中最单一且最有价值的成果，而如果您只迁移文件，它是不可见的。
组织指令。 这些需要管理员来读取，尽管 Factory 的指令界面没有记录每个组织的等效层，但它们仍然值得捕获。请注意，Copilot 自己的文档限制了它们的作用范围——它们“目前仅支持 GitHub.com 上的 Copilot Chat、GitHub.com 上的 Copilot 代码审查以及 GitHub.com 上的 Copilot 云智能体。”因此，这些组织指令很有可能从未影响过您的 IDE 会话。在决定要保留多少内容之前，请先确认这一点。
任何真正适用于每个仓库的内容都应放入用户级或项目级的 .factory/ 配置以及仓库的 AGENTS.md 中。任何从未到达 IDE 的合规性模板文件都可以丢弃，并附上说明原因的注释。
步骤 2：解决 Copilot 允许您推迟的冲突，然后重建作用域
因为 Copilot 提供了所有相关的指令集，并且仅使用优先级来解决分歧，所以一个团队可能会在两个相互矛盾的层下运行一年而从未察觉。优先级较高的那个胜出，而较低的那个则闲置在那里。
Factory 的指导原则恰恰相反。其 AGENTS.md 文档要求规则“简短、具体且易于验证”，建议将确切的安装、开发、测试、类型检查、lint 和构建命令放在最前面，并明确划分了什么内容属于哪里：
"将人类新手引导、屏幕截图和贡献者背景保留在README.md中。将 Droid 特定的命令、护栏和完成标准放在AGENTS.md中。"
它还要求提供 Copilot 格式所没有的内容：一个验证部分，说明在 Droid 宣布工作完成之前所需的证明。文档将改变 Droid 工作方式的具体规则与“无法检查的模糊规则”进行了对比。如果您的 copilot-instructions.md 包含诸如“编写优秀的代码”之类的行，那么这就是它被删除而不是被移植的地方。
因此，编写一个根目录 AGENTS.md，首先是命令，然后是仓库地图、约定、测试规则、生成文件规则、安全边界和验证步骤。在两个旧层发生冲突的地方，选择一个。这个决定是真正的工作，也是 Copilot 的优先级链之前为您吸收的工作。如果您已经在 Copilot 文件旁保留了 CLAUDE.md，将 CLAUDE.md 转换为 Copilot 的指令格式涵盖了在这种合并中哪些内容倾向于保留，哪些不保留——在您决定新文件可以有多长之前，编码智能体实际上阅读什么值得一读。
然后处理特定路径的文件。Copilot 的 .github/instructions/NAME.instructions.md 文件针对文件模式，文档解释了它们存在的原因：“通过使用特定路径的指令，您可以避免在仓库级指令中充斥仅适用于某些类型文件或某些目录的信息。”
这个目的保留了下来；但机制改变了。Factory 按目录划分嵌套 AGENTS.md 文件的作用域——“仅在包、应用或服务需要不同规则的地方添加嵌套文件。”作用域限于目录的规则可以干净地移植：在该目录中放置一个 AGENTS.md。而在整个树中作用域限于文件类型的规则没有可供存放的目录，因此您有两个诚实的抉择。如果该文件类型集中在一个区域，请将其放在那里。如果它确实横跨整个仓库，请在规则本身的第一句话中说明作用域，并接受它现在是被陈述的，而不是被匹配的。
在仓库中还有一件事需要检查：如果您发现了一个 .droid.yaml，这是一个已弃用的界面。Factory 的设置文档说明应使用当前的 .factory/ 文件，并“使用 AGENTS.md 来存放仓库指令、约定和验证命令。”
更好的方法：将推理保留在任何工具格式都无法孤立的地方
上述两个步骤是一个翻译过程加上一系列决策。决策是代价最高昂的部分，而目前它们仅存在于在迁移过程中做出这些决策的人的脑海中。
这就是值得放在持久地方的层。当您解决个人指令与仓库指令之间的冲突时，您就对项目实际遵循的约定做出了决定。当您删除“编写优秀的代码”时，您判定它是无法验证的。六个月后，有人会发现保留下来的规则，并询问它为什么要这样写。
MemoryLake 将这些决策保留在两款产品之外，并通过 MCP 或 API 将它们提供给任何发出请求的智能体。Copilot 自身的记忆功能和 Factory 自身的配置保持原样，并继续按照其供应商记录的方式工作。
步骤 1：创建 API 密钥
生成密钥并在大约三十秒内发出您的第一次请求。在开始上述步骤 2 之前完成此操作，以便在您做出每个决策时都有地方可以存放它们。
步骤 2：上传您的第一批记忆
您解决的每个冲突都是值得保留的记忆：哪个规则胜出，哪个规则失败，以及原因。添加源于特定事件的规则，以及您刻意不使用的库或模式。文档和其他支持文件也放在同一个地方。
步骤 3：连接您的 AI 和智能体
通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和 Droid 访问权限。连接后，“为什么这是约定”将伴随着附加的原因得到解答，这正是让根目录 AGENTS.md 保持如 Factory 推荐的那般简短的关键。
这在实践中改变了什么
第一个变化是个人指令问题不再重复发生。一旦隐藏在某个人弹窗中的项目规则进入仓库，并且推理进入共享存储库，就不再有一个私有层在暗中凌驾于团队的规则之上。
第二个变化是关于 Spec Mode（规格模式），这是 Factory 生成其最有价值产物的地方，也是持久性差距所在的地方。Spec Mode 是只读规划，以请求批准结束——Droid 在其中“不应编辑文件、更改配置、提交代码、启动服务或写入外部系统”。它生成的计划是在恰当的时机写下的变更推理。但默认保存位置是 ~/.factory/specs，这是一个位于仓库之外的每个用户目录。这是一个合理的默认设置，并且可以通过 specSaveDir 进行配置。这也是为什么一个好的计划可能只存在于一台笔记本电脑上而别无他处的原因。要么将 specSaveDir 指向已提交的内容，要么养成将结论移入共享存储库的习惯。
第三个变化发生在下一次工具迁移时。指令文件会再次被重写——这是不可避免的，而且每个工具的格式都有些许不同。但其背后的决策不会，因为它们从未存在于任何人的指令格式中。
从 Copilot 迁移到 Factory Droid 的最佳实践
在动文件之前，先阅读个人指令弹窗。 它是优先级最高、可见度最低的层，其中的某些内容属于整个团队。
向管理员索要组织指令，然后检查它们是否曾被应用。 Copilot 的文档限制了它们对特定界面的支持。结转从未到达您 IDE 的规则是无用功。
删除任何无法验证的内容，而不是移植它。 Factory 的文档要求提供可检查的规则，并将其与模糊的规则进行对比。一个没人能验证的规则在 Copilot 中也起不到任何作用。
把命令放在最前面。 安装、运行、测试、类型检查、lint、构建。Factory 自身的步骤顺序推荐这样做，这是您的指令文件中在第一次会话中就能收回成本的部分。
编写验证部分。 说明在 Droid 宣布工作完成之前所需的证明。Copilot 的指令格式中没有任何内容要求这一点，所以您可能还没有它。
在第一天就决定 specs 的存放位置。 默认是仓库之外的每个用户目录。将 specSaveDir 指向共享位置，或者手动将推理移出。
结论
从 Copilot 到 Factory Droid 的迁移是一个文件复制过程加上两个非文件的内容。个人指令存在于 GitHub.com 的弹窗中，且优先级高于其他一切；组织指令存在于公司设置中，并且根据 Copilot 自身的文档，仅能到达某些特定界面。两者都无法通过复制任何内容来迁移，而且第一个通常包含从未打算私有化的项目规则。
后半部分的工作是解决 Copilot 优先级链之前所吸收的冲突。因为所有相关的指令集都会被提供，且优先级仅用于解决分歧，所以矛盾可能会在很长一段时间内未被察觉。Factory 要求一个包含具体、可检查规则的简短根文件——这意味着必须有人实际选出一个胜出者。
先处理两个非文件层，刻意解决冲突，决定 specs 的保存位置，并将推理保留在任何指令格式都无法孤立的地方。