实际上能迁移什么
你的技能（Skills），只需移动目录。 Zed 技能会安装“到 ~/.agents/skills/ 以供全局使用，或者安装到项目的 .agents/skills/ 文件夹中以供项目本地使用”，而技能是“一个包含 SKILL.md 文件（带有元数据和指令）的文件夹”。Claude Code 的布局思路相同，只是路径不同：个人技能位于 ~/.claude/skills/<skill-name>/SKILL.md，项目技能位于 .claude/skills/<skill-name>/SKILL.md。复制这些文件夹，重命名父目录，即可完成。
双方加载它们的方式也相同。Zed：“默认情况下，智能体会自主获取技能。它在系统提示词中会看到所有已安装技能（名称和描述）的目录，并在任务与技能描述匹配时调用 skill 工具。”Claude Code：“Claude 会在相关时使用技能，或者你也可以直接使用 /skill-name 来调用。”
你的指令内容，只需重命名。 无论 Zed 实际读取的文件是什么，将其重命名为 CLAUDE.md 即可。如果该文件已经是 CLAUDE.md，那么你就完成了，但你应该仔细检查下一节，因为这意味着只有在列表中没有更靠前的文件存在时，Zed 才会读取它。
你的个人层，移至新位置。 Zed 的个人指令位于 ~/.config/zed/AGENTS.md，在 Windows 上为 %APPDATA%\Zed\AGENTS.md。Claude Code 的对应文件是 ~/.claude/CLAUDE.md，被描述为“所有项目的个人偏好”。
其他内容都无法无缝迁移，且有两处行为差异。
优先级在两个方向上都发生了反转。 Zed 明确指出：“当发生冲突时，项目指令会覆盖个人 AGENTS.md。”而 Claude Code 根本不会覆盖——“所有发现的文件都会被拼接进上下文中，而不是相互覆盖”，顺序从文件系统根目录向下排列，如果两个文件不一致，“Claude 可能会任意选择一个”。
而对于技能，情况则相反：Claude Code 的规则是“跨层级中，企业级覆盖个人，个人覆盖项目”，并举例说明“如果 ~/.claude/skills/ 和项目的 .claude/skills/ 中都存在 deploy 技能，/deploy 将运行个人技能”。在 Zed 中，项目作用域的文件在冲突中胜出。而在 Claude Code 中，你的个人技能胜出。如果你和队友拥有同名的技能，在同一个仓库中你们会得到不同的行为。
Zed 的兼容性文件将不再被读取。 .rules、.cursorrules、.windsurfrules 和 .github/copilot-instructions.md 都是 Zed 会乐意作为项目指令加载的文件。Claude Code 默认不会读取其中任何一个。.clinerules 是唯一的局部特例——只有在设置了 CLAUDE_CODE_NEW_INIT=1 时，/init 才会读取它，否则会静默跳过。如果你的指令一直存在于这些兼容性文件名中，它们即将变得不可见。
Zed 的技能分发机制无法迁移。 Zed 可以将技能作为独立的 zed://skill?data=… 链接分发给队友，该链接“嵌入了完整的 SKILL.md 内容（base64url 编码），因此接收者不需要访问你的项目或任何注册表”——这有一个很好的特性：“在他们显式保存之前，不会向磁盘写入任何内容，因此共享链接永远不会静默地将指令安装到某人的智能体中。”它还可以从社区注册表 skills.sh 安装。这些是分发路径，而不是技能本身；文件可以迁移，但共享工作流无法迁移。
每个技能的权限行为有所不同。 在 Zed 中，“当智能体调用你创建或安装的技能时，Zed 会提示你允许或拒绝，使用与其他工具相同的权限流程”，并且你可以设置每个技能的默认值。Claude Code 有自己的权限模型；你可能在 Zed 技能上设置的 disable-model-invocation 开关在你要复制的文件中没有直接的对应项。
手动迁移步骤
步骤 1：找出 Zed 实际读取的是哪个文件
这是最关键的一步，只需要运行一行命令。
在你的仓库根目录下，按照 Zed 的优先级顺序，列出候选文件，并留意第一个存在的文件：
ls -1 .rules .cursorrules .windsurfrules .clinerules \
.github/copilot-instructions.md AGENT.md AGENTS.md CLAUDE.md GEMINI.md 2>/dev/null输出的第一行就是你当前处于启用状态的指令文件。在它之下的所有文件在 Zed 中都是无用的死重——可能已经存在了几个月，甚至可能与胜出的文件相冲突。
需要规划三种结果。如果胜出的是 CLAUDE.md，则无需任何操作。如果是 AGENTS.md，Claude Code 将不会读取它，解决方法是重命名或导入（见下一步）。如果是像 .cursorrules 这样的兼容性文件，其内容需要移动到 CLAUDE.md 中，因为另一侧没有读取该文件名的机制。
同时检查你位于 ~/.config/zed/AGENTS.md 的个人文件。Zed 的“项目优先于个人”的优先级意味着，其中任何与项目文件冲突的内容之前都失效了——而在 Claude Code 中，它现在将被拼接进来，因此你以为被覆盖的偏好设置即将重新生效。
步骤 2：移动技能，然后重建指令层
先处理技能，因为这只是机械性的操作。 将 ~/.agents/skills/* 复制到 ~/.claude/skills/ 中，并将任何项目本地的 .agents/skills/* 复制到 .claude/skills/ 中。目录名称会变成你输入的命令，Claude Code 会读取 frontmatter 中的 description（描述）来决定何时自动加载它，因此相同的描述将继续发挥作用。
技能移入后，需要了解两件事。自定义命令和技能在 Claude Code 侧现在是同一种东西：“位于 .claude/commands/deploy.md 的文件和位于 .claude/skills/deploy/SKILL.md 的技能都会创建 /deploy，且工作方式相同。” 并且嵌套技能会根据上下文加载——“技能也会从工作目录之下的嵌套 .claude/skills/ 目录中加载”，这在“Claude 读取或编辑子目录中的文件时”会变得可用。这比顶层目录所暗示的更接近 Zed 的项目作用域。
注意与内置技能集的名称冲突。项目技能可以替换内置技能：“项目 .claude/skills/ 中的 code-review 技能会替换内置的 /code-review。” 这通常没问题，但偶尔会带来意外。
然后处理指令文件，并选择一种形式。 有两个干净的选择。
如果 Claude Code 现在是你在该仓库中唯一的智能体，直接重命名为 CLAUDE.md。或者保留 AGENTS.md 作为单一事实来源，并添加一个导入它的 CLAUDE.md——文档中给之的模式是在顶部写上单行 @AGENTS.md，之后“Claude 会在会话开始时加载导入的文件，然后追加其余内容”。如果队友仍在使用 Zed，或者有其他智能体读取 AGENTS.md，这是正确的选择，因为这样可以保持一个文件具有权威性，而不是产生两个逐渐偏离的副本。
将原本的一个文件拆分为有作用域的规则。 Claude Code 提供了一个 Zed 所没有的容器：带有 paths: frontmatter 字段（支持 glob 模式）的 .claude/rules/ 文件，这些规则“仅在 Claude 处理与指定模式匹配的文件时适用”。没有 paths 字段的规则“在启动时加载，其优先级与 .claude/CLAUDE.md 相同”。如果你的 Zed 指令文件包含“在处理前端时……”这一节，那么这一节现在应该是一个路径作用域的规则，而不是一直启用的文本。
并了解哪些内容会自动启用。 Claude Code 拥有第二个 Zed 所没有的机制：自动记忆（auto memory），它默认开启，并将 Claude 为自己记录的笔记存储在 ~/.claude/projects/<project>/memory/。它记录四种类型——user、feedback、project 和 reference——并且它会“跳过任何它可以从代码库中推导出的内容”以及“你的 CLAUDE.md 文件中已经说明的内容”。运行一周后执行 /memory 并阅读它。其通用机制在为什么 Claude Code 会遗忘项目上下文中进行了介绍。
要确认实际加载了什么，请运行 /context 并检查 Memory files 下的列表。这是最权威的答案，官方文档将其作为调试的第一步，因为“如果那里缺少某个文件，Claude 就无法看到它”。
更好的方法：不要再让文件名决定你智能体所掌握的知识
退一步看看这次迁移实际上是什么。一个文件被重命名了。一个文件夹被移动了。而有风险的部分——行为在静默中发生改变的部分——完全取决于加载器选择了哪个文件。
这既不是 Zed 的问题，也不是 Claude Code 的问题。当持久知识存在于发现规则因工具而异的文件中时，就会发生这种情况。Zed 从九个候选列表中选择第一个匹配项。Claude Code 拼接它找到的所有内容，并在冲突中任意选择。两者都会限制它们所承载的内容，因为每次请求都会附带一直启用的内容。
这就是 MemoryLake 所承载的：将你项目的持久知识保存在一个供你工具查询的层中，这样文件名只是一种偏好，而不是你智能体理解所依赖的基础。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭据即可连接你所有的工具。
步骤 2：上传你的第一批记忆
简短的条目，每条只包含一个主张。在步骤 1 的审计记忆犹新时，可以写下这些内容：
埋藏在失效文件中的决策。 如果 .cursorrules 已经被 AGENTS.md 遮蔽了六个月，它里面可能包含了一些从未被执行过的约束。在删除它之前先阅读它。
附带原因的决策。 “由于只读副本在负载下存在延迟，迁移只能是增量式的。” 指令只陈述了策略；只有附带原因才能阻止替代方案被再次提出。
在此代码库中已被拒绝的方法。 这一类内容既不会出现在任何指令文件中，也不会出现在任何提交信息中，却在每次新会话中被重新提出。
没有任何提示的环境事实。 仅在 CI 中失败的测试、未记录的速率限制、两个迁移之间的顺序要求。
步骤 3：连接你的 AI 和智能体
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此支持原生 MCP 的智能体（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。这意味着你可以在同一个仓库中并排运行 Zed 和 Claude Code，而无需维护两份相同的推理副本。
三个坦诚的限制。MemoryLake 不会编写你的 CLAUDE.md、AGENTS.md 或你的技能——这些是你引导每个工具的方式，上述加载器行为是它们自身的，而不是记忆层可以改变的。它只保存你或你的智能体放入其中的内容，因此步骤 2 是手动的。此外，指令是上下文，而不是强制执行的配置；对于每次都必须遵守的任何内容，Claude Code 自身的解决方案是钩子（hook），而不是文件。
这在实践中改变了什么
“哪个文件处于启用状态？”变成了一行命令的检查。 Zed 从九个候选文件中获取第一个匹配项。现在你了解了列表和顺序。
被遮蔽的文件不再是地雷。 一旦你阅读了未生效的文件并合并了重要的内容，就不会再有遗忘的 .cursorrules 等着让下一个人感到困惑。
技能不再特定于工具。 相同的 SKILL.md 可以在 Zed、Claude Code、Cursor 和 Codex 中运行。你只需编写一次。
指令文件变得更短。 路径作用域的规则意味着“在处理 X 时”这些章节不再随每条消息一起加载。
使用不同编辑器的队友不再导致分支分化。 一个权威的指令文件加上一个可查询的记忆层，胜过两个逐渐偏离的文件——这种形式在持久记忆的真正含义中进行了介绍。
从 Zed 切换到 Claude Code 的最佳实践
在更改任何内容之前，先找出胜出的文件。 Zed 读取从 .rules 到 GEMINI.md 的第一个匹配项；其后的所有内容都是无效的。
阅读被遮蔽的文件，然后删除它们。 它们可能包含数月未曾适用的约束。
重命名为 CLAUDE.md，或者从中导入 AGENTS.md。 当其他智能体或队友仍需读取 AGENTS.md 时使用导入；否则直接重命名。
逐个文件夹移动技能，然后检查名称冲突。 在 Claude Code 中，个人技能优先于项目技能，这与 Zed 的指令优先级相反。
预料到你的个人文件会变得更重要，而不是更不重要。 Zed 的项目指令会覆盖它；而 Claude Code 会将两者拼接。
将一直启用的文本拆分为路径作用域的规则。 paths: frontmatter 字段是 Zed 所没有的容器。
使用 /context 进行验证，而不是 memory。 Memory files 列表才是实际加载的内容。
一周后打开自动记忆文件夹。 它默认开启，保存着你指令文件刻意不包含的内容。
不要将推理过程写在指令文件中。 这两个工具都会限制它们所承载的内容，而推理过程是首先被裁剪的部分——这一普遍问题在为什么智能体会忽略你编写的指令文件中进行了探讨。
结论
从 Zed 迁移到 Claude Code 看起来只是重命名，而且大部分情况下确实如此，但风险恰恰存在于重命名之中。Zed 从包含九个候选文件的列表中选择第一个匹配的项目指令文件，其中 AGENTS.md 排在 CLAUDE.md 之前；而 Claude Code 读取 CLAUDE.md，不读取 AGENTS.md。因此，今天引导你智能体的文件可能不再是明天引导它的文件，而且 Zed 的文档已经警告过你，不要假设其加载器可以控制其他智能体。
技能是简单的一半：这两个工具都是包含 SKILL.md 的文件夹，因此 ~/.agents/skills/ 变成了 ~/.claude/skills/，并且描述信息将继续有效。注意优先级的反转——在 Claude Code 中个人技能胜出，而在 Zed 中项目指令胜出——并记住 Zed 的兼容性文件名在另一侧没有读取机制。
审计哪个文件处于启用状态，合并未生效的文件，在重命名和导入之间做出选择，将一直启用的文本拆分为路径作用域的规则，并将决策和被拒绝的方法放在两个编辑器都可以查询的地方。这样，加载器的优先级列表就不再是需要你时刻记在脑子里的负担了。