实际传输的内容
你的 skills——完全无需修改。 Zed 安装 skill 的说明是 "将 skill 的文件夹复制到 ~/.agents/skills/ 以供全局使用，或复制到项目的 .agents/skills/ 文件夹以供项目本地使用。" Cursor 从 .agents/skills/、.cursor/skills/、~/.agents/skills/ 和 ~/.cursor/skills/ 加载 skills。.agents/ 路径完全相同，两者都使用包含 SKILL.md 的文件夹，并且都采用了相同的开放标准。如果你的 skills 存在于 .agents/skills/ 中，那么在你打开仓库的那一刻，它们就会在 Cursor 中生效。
Cursor 为了兼容性做得更进一步：它 "还会从 Claude 和 Codex 目录加载 skills：.claude/skills/、.codex/skills/、~/.claude/skills/ 和 ~/.codex/skills/。"
你的指令内容——在确定哪个文件保存了它之后。 文本可以迁移。但它在哪个文件中，以及 Zed 正在读取哪个文件，是两个不同的问题。
个人指令——作为 User Rules。 Zed 的个人指令保存在 ~/.config/zed/AGENTS.md（在 Windows 上位于 %APPDATA%\Zed\）。Cursor 的对应功能是 User Rules，"全局适用于你的 Cursor 环境。"
不会迁移的内容：“首个匹配项胜出”机制。 Zed 只选择一个文件。而 Cursor 的 Project Rules 是有条件的——每个 .mdc 文件通过 frontmatter 决定自己的加载行为。这带来了更多的控制力，也意味着有更多需要配置正确的地方。
同样不会迁移的：对外部智能体的任何假设。 Zed 通过 ACP 运行外部智能体（External Agents）——包括 Claude、Codex、OpenCode、Copilot、Cursor 等——以及直接运行 CLI 的终端线程（Terminal Threads）。Zed 的文档在此处非常谨慎："外部智能体和终端线程可以直接读取它们自己的原生指令文件。不要假设 Zed 的指令加载器控制着这些智能体。" 如果你的 Zed 配置依赖于外部智能体，那么你的部分上下文行为最初就根本不属于 Zed。
坦白地说：这两个工具都没有记录记忆层。 Zed 的文档索引中没有记忆页面，Cursor 的文档索引中也没有。两者在设计上都是“指令与技能”工具，Cursor 直接阐明了底层前提："大型语言模型在不同补全之间不会保留记忆。规则在提示词级别提供持久、可重用的上下文。" 这是对规则是什么的准确描述，也是对它们不是什么的明确声明。这次迁移中的任何内容都不会改变这一点——你是在两个都期望你来提供连续性的工具之间进行迁移。
手动迁移
步骤 1：找出 Zed 实际一直在读取的文件
按顺序检查列表——.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md——并在你的仓库中存在的第一个文件处停下。那就是你真正的项目指令文件。它下面的所有内容一直处于闲置状态。
有两种常见的结果，都值得在迁移前注意：
过时的遗留文件胜出。 之前工具留下的 .cursorrules 或 .windsurfrules 排在 AGENTS.md 之前。注意这次迁移中的讽刺之处：.cursorrules 根本不在 Cursor 当前的文档中——Cursor 的四种规则类型是 .cursor/rules 中的 Project Rules、User Rules、Team Rules 和 AGENTS.md。一个过时的 .cursorrules 一直在引导 Zed，而它却是 Cursor 已经弃用的文件。
你维护的文件从未加载。 如果 AGENTS.md is 不是第一个匹配项，那么你认为生效的规则其实并没有生效。阅读那个胜出的文件；你以为起作用的一些内容可能从未被测试过。
还要检查个人与项目优先级的关系："当发生冲突时，项目指令会覆盖个人 AGENTS.md。" 如果你在某个仓库中对某个行为感到惊讶，而在另一个仓库中却没有，通常就是这个原因。
这里有一个术语说明，以免你寻找已被重命名的内容。Zed 的文档指出 "规则已被技能和指令取代"，可重用的按需规则变为 Skills，始终启用的规则变为个人 AGENTS.md，而项目 .rules 文件则保留用于兼容性。如果你参考的是较旧的 Zed 指南，这些概念仍然存在，只是名称不同。
步骤 2：将一个始终启用的文件重构为在需要时加载的规则
Cursor 的 Project Rules 以 .mdc 文件的形式存在于 .cursor/rules 中，且该扩展名是强制性的。文档明确指出："项目规则必须使用 .mdc 扩展名。.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它没有 frontmatter 来指定 description、globs 和 alwaysApply。如果你更喜欢普通 markdown，请改用 AGENTS.md。"
因此，你有两个落地选择，而最简单的通常也是最正确的：如果你的 Zed 指令是一个始终启用的文件，并且你希望保持这种状态，请将它们放入 AGENTS.md 中，Cursor 将其记录为 ".cursor/rules 的简单替代方案"。搞定。
如果你想要 Zed 无法实现的条件加载，请进行转换。Cursor 的四种规则类型可以清晰地映射到大多数人 AGENTS.md 中逐渐增加的各个部分：
| Zed 中的内容 | Cursor 规则类型 | Frontmatter |
|---|---|---|
| 始终启用的仓库约定 | Always Apply | alwaysApply: true |
| 代码库中某一区域的指南 | Apply to Specific Files | globs: src/components/**/*.tsx, alwaysApply: false |
| 智能体应自行判断的场景指南 | Apply Intelligently | description: …, alwaysApply: false |
| 你手动调用的内容 | Apply Manually | 既无 description 也无 globs |
这种交互在文档中以表格形式呈现，其行为与字面意思完全一致：alwaysApply: true 意味着 globs 和 description 会被忽略；alwaysApply: false 配合 globs 会在匹配的文件进入上下文时自动附加；false 配合 description 允许智能体在相关时将其拉入；而 false 且两者皆无则意味着该规则仅在你使用 @ 提及它时才会加载。
Apply Intelligently 类型是需要仔细编写的。description 是智能体用来判断相关性的依据，因此 "后端的 RPC 服务约定和模式" 有其存在的价值，而 "其他规则" 则没有。
实用提示：在 Agent 中使用 /create-rule 会生成带有正确 frontmatter 的文件，这是完全避免 .md 陷阱的最快方法。规则可以在 .cursor/rules 内部的文件夹中进行组织。嵌套的 .cursor/skills/ 目录会自动作用于该目录内的文件，因此单体仓库（monorepo）可以将 skills 与它们所属的包放在一起。如果你使用 Cursor 的云端或远程执行，还有一个注意事项：Cursor "不会将你本地的 ~/.cursor/skills/ 和 ~/.agents/skills/ 文件夹复制到 Cloud Agents"、远程 SSH 会话或自托管的工作节点中——仓库中的项目 skills 会随之传输，但个人 skills 不会。
至此，文件迁移就完成了。但未完成的是那些从未存在于文件中的内容。
更好的方法：为这两个工具都无法提供的推理提供一个归宿
这两个工具都能很好地处理指令，而且都没有声称能做更多。Cursor 自己的表述很坦诚：规则 "在提示词级别提供持久、可重用的上下文，" 并且规则内容 "包含在模型上下文的开头。"
在上下文的开头，在每一次相关的请求中。这一限制使得规则文件成为存放整类知识的错误容器。为什么存在某种约定、你已经尝试并拒绝了哪种方法、使显而易见的解决方案失效的约束、解释了捷径的截止日期——这些都不是指令。将它们放入 AGENTS.md 会使文件变长，而智能体并不会因此变得更听话。在经历了一次刚刚发现自己维护的文件甚至从未加载过的迁移之后，一个更短的指令文件的吸引力显而易见。
这就是 MemoryLake 所承载的：你项目的持久知识存在于一个供工具查询的层中，因此规则可以保持简短，而推理在无论你今年使用哪款编辑器时都保持可用。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建 API 密钥。一个凭证即可跨越你连接的所有工具。
步骤 2：上传你的第一批记忆
简短的条目，每条一个主张。最好的来源就是你正准备变长的那个指令文件：
每条规则背后的原因。 "组件保持在 200 行以内，因为审查工具会截断较大的 diff。" 规则写在 .mdc 文件中；而原因放在这里，正是它阻止了该规则在下个季度被废弃。
在此仓库中已被拒绝的方法。 这一类内容不会出现在任何规则文件或提交信息中，却在每次新会话中被重新提出。
无人宣告的环境事实。 未记录的速率限制、两个任务之间的顺序依赖关系、仅在 CI 中失败的测试。
迁移刚刚带给你的启示。 如果一个过时的 .cursorrules 之前排在你的 AGENTS.md 之前，写下因此从未真正执行过哪些约定。这是关于你代码库的事实，而不是规则。
步骤 3：连接你的 AI 和智能体
连接你使用的工具。可以通过 MCP 和 API 访问 MemoryLake，且 Zed 和 Cursor 都支持 MCP 服务器——这在尚未完全切换的过渡期非常有用。支持原生 MCP 的智能体（如 Claude Code、Codex 和 OpenClaw）会读取相同的记忆，其他任何工具则通过 API 访问它。
三个坦诚的限制。MemoryLake 不会编写你的 .mdc 文件、AGENTS.md 或 User Rules——这些是你引导 Cursor 的方式，上述加载行为是 Cursor 的。它仅保存你或你的智能体放入其中的内容，因此步骤 2 是刻意为之的。而且规则是上下文，而不是强制执行的配置：任何每次都必须遵守的内容都需要在 CI 中进行检查，而不是在 markdown 中写上一行。
这在实践中改变了什么
你找出了实际加载的内容。 “首个匹配项胜出”意味着答案往往不是你正在编辑的文件。
Skills 迁移零成本。 两个工具都读取 .agents/skills/。
加载变得有条件，而不是非全即无。 四种规则类型取代了一个始终启用的文件。
.md 陷阱不再是谜。 .cursor/rules 中的错误扩展名意味着该文件不存在。
指令文件变得更短。 推理被移出，因此剩下的全是指令。
下一次切换编辑器成本更低。 持久知识不再存在于单个工具的配置目录中。
从 Zed 迁移到 Cursor 的最佳实践
在复制任何内容之前，先确定胜出的文件。 Zed 会读取九个候选文件列表中的第一个匹配项。
在阅读完过时的遗留规则文件后将其删除。 遗留的 .cursorrules 在 Zed 中的优先级高于 AGENTS.md，而在当前的 Cursor 中是未记录的。
使用 /create-rule 而不是手动编写 .mdc frontmatter。 它会生成有效的 frontmatter，从而避免最常见的失败。
如果你想要普通 markdown，请使用 AGENTS.md。 Cursor 将其记录为简单的替代方案；不要与 .cursor/rules 较劲。
在 Apply Intelligently 规则上编写真实的描述。 描述是智能体用来判断相关性的依据。
使用 globs 限制范围，而不是使用一个巨大的始终启用的文件。 在每次请求中加载所有内容是导致 Zed 文件变得笨重的原因。
如果你使用 Cloud Agents，请将个人 skills 保留在仓库中。 本地的 ~/.agents/skills/ 不会被复制到远程执行环境中。
不要指望任何一个工具有记忆功能。 两者都没有记录记忆层——大致轮廓请参见 编码智能体实际读取的内容。
结论
这次迁移比大多数迁移都要容易，而且其中包含一个真正的惊喜。简单的一部分是 skills：Zed 和 Cursor 都从 .agents/skills/ 和 ~/.agents/skills/ 加载，都使用包含 SKILL.md 的文件夹，无需任何转换。惊喜在于源头——Zed 会读取九个候选文件列表中的第一个匹配文件，因此一直在塑造你智能体的指令文件可能并不是你一直在维护的那一个，而 AGENTS.md 在该顺序中排第七。
确定哪个文件胜出，仔细阅读它，然后决定它应该如何落地。一个始终启用的文件放入 AGENTS.md 即可完成。如果你想要条件加载，请将其转换为 .cursor/rules——记住该目录中的普通 .md 会被忽略，而 /create-rule 会为你编写有效的 frontmatter。
这两个工具都没有提供存放推理的地方。Cursor 明确指出：规则在提示词级别提供可重用的上下文，并在模型上下文的开头加载。这是对指令文件的正确描述，也是它不适合作为决策、被拒绝的方法和约束的容器的原因。将指令移入正确的规则类型中，保持它们简短，并将推理放在你下一个编辑器也能读取的地方。具体在 Cursor 侧是什么样子，请参见 如何在会话之间携带 Cursor 上下文。