实际迁移了什么
Copilot 的自定义层面有五个层级，其中只有三个是文件。
个人指令（Personal instructions）。 文档对其范围和位置都做出了明确说明：它们“仅在 GitHub 中的 GitHub Copilot Chat 中受支持”，你在“GitHub.com 上的 Copilot Chat 页面的弹窗中”进行设置，并且 Copilot “将仅应用”于你。没有文件，没有仓库。每个人只有一个网页上的文本框。
仓库自定义指令（Repository custom instructions），共有三种类型。.github 目录中 copilot-instructions.md 文件中的仓库级指令。.github/instructions 内部或下方一个或多个以 .instructions.md 结尾的文件中的特定路径指令。以及智能体指令，文档将其描述为“类似于仓库级的自定义指令，但目前并非所有 Copilot 功能都支持”，在名为 AGENTS.md、CLAUDE.md 或 GEMINI.md 的文件中指定。
组织自定义指令（Organization custom instructions），由组织所有者在 Copilot 设置中设置，并应用——用文档的话说——“适用于组织的所有成员，无论他们是否从该组织获得 Copilot 订阅”。
现在来看看它们的解析顺序：
“多种类型的自定义指令可以应用于发送给 Copilot 的请求。个人指令优先级最高。仓库指令次之，组织指令优先级最低。然而，所有相关的指令集都会提供给 Copilot。”
最后那句话是人们常常忽略的。优先级解决的是冲突，它并不会移除层级。每个适用的指令仍然会被发送。因此，与组织标准相冲突的个人指令并不会取代它——它只是级别更高，而两者都保留在上下文中。
在 Tabnine 方面，等效的层面是准则（guidelines）。文档将其描述为“存储在项目 /.tabnine/guidelines/ 目录中的 Markdown 文件”，并指出该目录既可以存在于你的主目录中，也可以存在于每个项目中。它自己对它们的类比是：“以类似于其他智能体工具使用的 agents.md 文件的方式来思考这些文件。”关于大小的建议是“将你的 guidelines.md 文件保持在 500 行或以下”。
然后是颠覆你迁移过程的那句话。在描述管理控制台中输入的准则时：
“在此处输入的准则将与guidelines.md文件中列出的准则具有相同的效果，但它们将优先于guidelines.md文件中存在的个人准则。”
所以：文件可以迁移。特定路径的范围大致也可以迁移，因为 Tabnine 支持多个准则文件。无法迁移的是解析顺序。而完全没有去处的是那个弹窗——那些从未存在于仓库中、从未被审查过、也从未对其他人可见的个人指令。
需要将所有这些与一件事区分开来：这些层级中没有一个是代码库感知。指令文件告诉助手如何表现，而不是你的代码包含什么，这就是为什么 Copilot 遗忘代码库上下文 与 Copilot 忽略你的规则是不同的抱怨。Tabnine 对第一个问题的解决方案是个性化（Personalization）及其连接（Connection）功能；对第二个问题的解决方案是准则（guidelines）。不要指望通过迁移其中一个来解决另一个问题。
在规划工作之前，还有一个结构性差异值得了解，因为它会将你的团队一分为二。Tabnine 的 CLI 不会像 IDE 插件那样读取项目准则目录。其文档一开头就直白地说明了这一差异：
“Tabnine CLI 中智能体准则的管理方式与 Tabnine IDE 插件不同。”
在 CLI 中有两个流程。组织和系统账号（service-account）指令被“添加到智能体的运行上下文中”，并在 CLI 启动时为你的已认证账户自动获取。另外，编码准则可以通过内置的 Tabnine Coaching Guidelines 工具访问，智能体在需要特定语言的规则时会调用该工具。文档特意将两者分开，因为开关只控制其中一个：
“此设置并不控制是否获取组织或系统账号指令并将其添加到会话上下文中。”
手动迁移
分为两个步骤，而第一步是每个人都会跳过的步骤。
Step 1: 将个人指令从弹窗中导出
在动任何一个文件之前，让团队中的每个人打开 GitHub.com 上的 Copilot Chat 页面，并向你大声朗读他们的个人指令。不是转述——是朗读。
这听起来像是无用功，但它是整个迁移过程中价值最高的一小时，原因有二。首先，个人指令处于 Copilot 优先级顺序的顶端，这意味着其中的任何内容一直在默默地战胜你的仓库标准和组织设置。其次，它们是不可见的：没有文件可以 grep，没有 PR 可以审查，没有审计轨迹。如果有人在八个月前写了“始终使用旧版客户端库，新版会破坏我们的代理”，那么这条指令从那时起就一直在塑造他们的输出，而其他人根本不知道它的存在。
将导出的内容分成两堆。真正的个人偏好——回复语言、详细程度、每行解释一个概念——保留为个人偏好。披着个人外衣的项目事实则放入仓库，因为它们本来就属于那里。这与 智能体忽略你的指令文件 背后的失败模式相同：最终胜出的指令并不是你以为自己写的那个。
当你在那个弹窗中时，请注意 Copilot 的另一个每用户层面——IDE 中的记忆（memory）功能（在 在 VS Code 中设置 Copilot 记忆 中有介绍）——也是因人而异的，而且也不是文件。把这些也读一遍。
Step 2: 将文件层级重建为准则，然后重新决定每个冲突
现在是复制部分，这是机械性的，接着是非机械性的部分。
你的仓库级 copilot-instructions.md 将成为 .tabnine/guidelines/ 中的一个准则文件。你的特定路径 .instructions.md 文件将成为额外的准则文件——Tabnine 会读取该目录中的多个文件，因此请保持它们独立而不是合并，并根据它们涵盖的内容进行命名。你的 AGENTS.md 可以完全保留在原处，因为这是你技术栈中其他工具都会读取的开放约定；只需注意 Tabnine 的准则目录是其自身文档所指向的地方。如果你的指令文件最初是在另一边开始的，将 CLAUDE.md 移动到 Copilot 介绍了它们到达时的形态。
顺便提一个免费的纠错。Tabnine 的文档将这个类比写成了小写，即 agents.md。而读取相同约定的其他工具则需要大写文件名，并且会默默跳过小写文件名。在跨工具共享的仓库中，请将其命名为 AGENTS.md。
然后是真正的工作。对于你的组织标准和某些人的个人指令不一致的每个地方，你现在必须选出一个胜出者，因为 Tabnine 的管理控制台会为你选出一个，而且它会选择与 Copilot 相反的结果。逐个排查冲突，并决定每个规则应该存放在哪个层级。任何真正属于组织标准的内容都应该放入管理控制台，在控制台中它现在高于每个人的本地文件——并注意文档中提到的传播延迟：更改“将在 15 分钟后应用到 IDE 插件中，或者在重启 IDE 或插件时应用”。
这也是你发现任何迁移指南都无法为你做的事情的地方。决定哪个规则胜出需要知道每个规则存在的原因，而这两个工具中都没有这些信息。
更好的方法：管理控制台无法覆盖的决策层
你在步骤 2 中解决的冲突之所以困难，只是因为原因从未被记录下来。“使用旧版客户端库”与“标准化当前 SDK”作为两条命令是无法调和的。但一旦你知道其中一条是在代理损坏的那周写的，而代理已在 6 月份被更换，这就变得微不足道了。
MemoryLake 在这两个工具之外保存了这一层——决策、被否决的替代方案以及原因，并通过 MCP 或 API 将它们提供给任何发出请求的智能体。你的准则在 .tabnine/guidelines/ 中保持简短和命令式，你的管理控制台保存标准，而每个标准背后的“原因”可以由任何人在任何工具上进行查询。
Step 1: 创建 API 密钥
生成一个密钥，并在大约 30 秒内发出你的第一次请求。在上述步骤 2 之前执行此操作，这样在解决每个冲突时，你就有地方可以记录它们。
Step 2: 上传你的第一批记忆
对于你保留的每个规则，写下它决定了什么、排除了什么以及原因。你在步骤 1 中收集的个人指令是这里最丰富的来源——它们中的大多数都记录了一个真实的事件。支持文档和文件也放在同一个地方。
Step 3: 连接你的 AI 和智能体
让 Tabnine、Claude、Codex 以及你的其他智能体通过 MCP 或 API 进行访问。当提出下一个标准时，“我们以前不是试过那个吗”的答案就会附带其推理一起呈现。
这在实践中改变了什么
第一个改变是，隐形层不再隐形。Copilot 优先级最高的指令层面是一个因人而异的文本框；在这次迁移之后，等效的内容要么是明确的个人偏好，要么是记录下来的项目决策，而第二种内容是整个团队都可读的。
第二个改变是，管理控制台的优先级变成了一个功能，而不是陷阱。一旦组织标准真正成为组织性的——经过审查、推理和记录——让它们高于本地文件正是你所期望的。只有当管理控制台里装满猜测时，这种反转才会带来伤害。
第三个改变是，IDE 与 CLI 的分裂不再使你的团队四分五裂。IDE 中的开发人员读取准则文件；CLI 中的开发人员获取组织和系统账号指令以及 Coaching Guidelines 工具。这些是不同的机制，而一个双方都可以查询的共享推理层是使他们的答案保持一致的关键。
第四个改变是，下一次迁移将真正变成一次文件复制。让这次迁移变得困难的部分——从命令中重建意图——只需进行一次。这也是为什么 编码智能体实际读取的内容 比特定工具偏好哪种文件格式更重要的原因。
迁移到 Tabnine 后的最佳实践
在审计文件之前，先审计弹窗。 个人指令在 Copilot 中具有最高优先级，且没有文件痕迹。它们是旧设置中唯一无法在以后重建的部分。
将标准放在管理控制台中，将偏好放在本地文件中。 现在的优先级顺序鼓励这种划分，而通过在本地复制标准来对抗它，只会产生控制台无论如何都会胜出的冲突。
保持准则文件简短且独立。 文档建议每个文件 500 行或以下，并且该目录支持多个文件。每个文件一个主题优于一个长文件。
记住传播延迟。 管理控制台的更改在等待或重启后才会到达 IDE 插件。当标准发生变化时，请告知大家，而不是假设他们已经看到了。
不要假设 CLI 能看到你的项目准则。 CLI 的文档化流程是组织和系统账号指令以及 Coaching Guidelines 工具。如果你的团队分布在这两个层面上，请验证每个层面实际加载的内容。
使用大写的 AGENTS.md。 某个厂商的小写示例可能是另一个厂商的默默忽略，做对这一点毫无成本。
在规则旁边写下原因。 你在这次迁移中解决的每个冲突之所以存在，都是因为有人写了一条没有原因的命令。除非原因有地方存放，否则下一个冲突也会如此。
结论
从 GitHub Copilot 迁移到 Tabnine 可以干净地移动三个文件层级，并反转你看不见的那一件事。Copilot 将个人指令记录为最高优先级，将组织指令记录为最低优先级，同时仍将每个适用层级发送给模型。Tabnine 则记录管理控制台优先于个人 guidelines.md。如果在不解决这个问题的情况下复制文件，过去胜出的规则在相同的输入下就会开始默默地输掉。
让迁移安全的工作不是复制。而是清空弹窗，将真正的偏好与项目事实分开，并决定哪个层级应该拥有每个规则——只有当你了解规则存在的原因时，你才能做到这一点。在两个工具之外记录一次，未来的每一次迁移就会变成这次迁移从外部看起来的样子：移动一些 markdown 文件并登录。