实际上可以迁移的内容
技能可以原样迁移。 这是个好消息，而且比大多数工具组合的表现都要好。Windsurf 将工作区技能保存在 .windsurf/skills/ 中，将全局技能保存在 ~/.codeium/windsurf/skills/ 中，但其文档补充道：“为了实现跨智能体兼容性，Devin Desktop 也会在 .agents/skills/ 和 ~/.agents/skills/ 中寻找技能。”Zed 仅从两个位置加载技能——全局技能从 ~/.agents/skills/ 加载，项目本地技能从 <worktree>/.agents/skills/ 加载。如果你的技能已经存在于 .agents/skills/ 中，那么这两个工具都会读取相同的文件，无需进行任何转换。
两者也都使用渐进式披露（progressive disclosure），并包含相同的两个字段。Windsurf：“默认情况下，模型仅能看到技能的名称和描述。只有当 Cascade 决定调用该技能（或当你 @ 提及它）时，才会加载完整的 SKILL.md 内容和支持文件。”Zed：“它在系统提示词中会看到所有已安装技能的目录（名称和描述），并在任务与技能描述匹配时调用 skill 工具。”相同的机制，相同的 name 和 description 前置元数据（frontmatter），以及双方都支持的相同的 disable-model-invocation 标志。
规则文件会原样传输，但其含义会发生变化。 Windsurf 的工作区规则以单文件形式保存在 .devin/rules/*.md（首选）或 .windsurf/rules/*.md（备用）中，其文档确认“工作区根目录下的遗留单文件 .windsurfrules 仍会被读取。”根目录下的 AGENTS.md 则“由相同的规则引擎处理——根目录级别 = 始终开启，子目录级别 = 自动匹配该目录的 glob 模式。”
Zed 的项目指令加载机制则有所不同。其文档指出：“项目指令文件适用于当前项目。Zed 会使用此列表中第一个匹配的文件：”
.rules,.cursorrules,.windsurfrules,.clinerules,.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,GEMINI.md
数一下位置。.windsurfrules 排在第三位。AGENTS.md 排在第七位。第一个匹配的获胜，且只使用一个文件。如果一个仓库中仍保留着 2025 年的 .windsurfrules，Zed 将会读取该文件，并忽略你今天早上编写的 AGENTS.md——没有警告，没有错误，你可能想去检查的任何日志中也不会有任何记录。
激活模式无法迁移。 Windsurf 记录了四种激活模式，每种都在 trigger 前置元数据字段中声明，其表格给出了每种模式的上下文成本：always_on（“在每条消息的系统提示词中都包含完整的规则内容”）、model_decision（“系统提示词中仅显示描述。当 Cascade 认为描述相关时，会读取完整的规则文件”）、glob（“当 Cascade 读取或编辑匹配 glob 模式的文件时应用规则”）以及 manual（“规则不在系统提示词中。你通过输入 @rule-name 来激活它”）。
这四种模式是 Windsurf 用户最常调整的控制界面，而失去这种区分是导致我们在Windsurf 遗忘你的项目规则中记录的抱怨的最常见原因——只不过在这里，规则仍然存在于磁盘上，而它们被声明的模式已不复存在。
Zed 拥有两个界面，而不是四个。指令是“Zed Agent 的始终开启的上下文。”技能由智能体从目录中调用，或者通过斜杠命令或 @skill 提及手动调用。Zed 的技能前置元数据记录了三个字段——name、description 和 disable-model-invocation——该页面指出：“我们计划在不久的将来加入 Agent Skills 规范推广的其他字段。”因此，目前在 Zed 侧，没有字段可以承载由 glob 模式限定范围的 Windsurf 规则；它必须被重新表达为智能体进行匹配的描述。
目录范围的指令会失去其范围限制。 在 Windsurf 中，子目录中的 AGENTS.md 会变成“具有自动生成的 <directory>/** 模式的 glob 规则”，因此单体仓库（monorepo）可以免费为每个区域携带一个指令文件。Zed 的指令页面描述了从该排序列表中选择的单个项目指令文件，并没有描述在子目录中寻找指令文件的机制。在四个层级上的四个 AGENTS.md 文件在 Zed 中，其中三个将没有任何有文档记录的作用。
自动生成的记忆会保留在原处。 Windsurf 自身对此的指导非常直接：自动生成的记忆“与创建它们的工作区相关联，并本地存储在 ~/.codeium/windsurf/memories/ 中”，“它们不会被提交到你的仓库”，并且“自动生成的记忆仅存在于你的机器上”。Windsurf 的建议是在你前往任何地方之前，将你依赖的任何内容提升为规则或 AGENTS.md。Zed 的文档将指令和技能描述为其智能体上下文的持久化界面；它没有描述自动生成的记忆存储，因此在 Zed 侧没有这些文件的落脚点。如果你一直依赖它们，请先提升它们——该建议背后的工作区范围行为是阻止 Windsurf 的 Cascade 丢失上下文的主题。
在阅读源文档时，关于品牌的一点说明：Windsurf 的文档现在通篇采用 Devin Desktop 的命名，其记忆页面仍以现在时态描述 Cascade，并指向“Devin: Open Cascade Migration Wizard”命令，尽管 Devin Desktop 变更日志已于 2026 年 9 月 8 日移除了 Cascade。如果你正在参考该页面，请做好准备，它描述的智能体在你的构建版本中可能已不复存在。我们在合并 Windsurf 和 Devin 规则文件夹中单独介绍了该过渡的规则文件夹部分；本指南是关于迁移到 Zed，而不是在 Windsurf 内部进行重组。
手动迁移
步骤 1：选择唯一的项目指令文件，然后清除干扰项
在编写任何新内容之前，列出你仓库根目录下出现在 Zed 排序列表中的每一个文件。在具有 Windsurf 历史的仓库中，预计至少会有 .windsurfrules，可能还有 .rules，可能还有来自早期工具的 .cursorrules，以及一个 AGENTS.md。
决定哪一个是权威的。AGENTS.md 是合理的答案——它是 Windsurf 也会处理的文件，是其他工具也能识别的文件，并且它在 Zed 的列表中排在第七位，这意味着它之上的所有内容都必须清除。删除或重命名优先级较高的文件。重命名更安全：将 .windsurfrules 移动到 docs/legacy-windsurf-rules.md，这样内容仍然可读，同时对加载器不可见。
然后进行合并。Windsurf 允许你每个规则使用一个文件，每个文件限制 12,000 个字符；而 Zed 只给你总共一个文件。将你的 .devin/rules/*.md 内容合并到 AGENTS.md 中，保留每个规则的标题，以便你仍能区分它们。如果某个规则在 Windsurf 中是 always_on，它就属于这里。如果不是，请留到下一步。
通过反证法而不是阅读来验证。在 AGENTS.md 中添加一行故意显得反常的内容——例如你平时不使用的命名规范——并要求智能体应用它。如果智能体忽略了它，说明优先级更高的文件仍然胜出。这与我们在为什么智能体会忽略你的指令文件中推荐的检查方法相同，而且比审计目录树更快。
步骤 2：将三种条件模式转换为技能，并注意目录预算
所有不是 always_on 的内容都会变成技能。Zed 自身针对其已退役的 Rules 功能的迁移说明也表达了这一点：“可重用的、按需使用的 Rules 变成 Skills”，而“默认的、始终开启的 Rules 变成个人的 AGENTS.md”。
转换取决于你从哪种模式开始。manual 规则可以干净地映射——它变成一个技能，输入 /skill-name 或 @skill-name 即可调用它，就像以前使用 @rule-name 一样。model_decision 规则也可以干净地映射，因为这两个工具都是根据描述做出决定的；你可以原封不动地重用描述文本。glob 规则是需要重写的规则：模式必须变成一句话。**/*.test.ts 变成一段描述，说明该技能在编写或修改测试文件时适用，Zed 的指南明确说明了如何表述它——“包含特定的任务类型和触发短语。”
Zed 侧的三个限制在 Windsurf 中没有对应项，且这三个限制都会静默失败。
目录有预算限制：“所有技能名称和描述的总大小上限为 50KB。不符合要求的技能将从目录中丢弃，并在 UI 中显示警告。”描述应保持在“1024 字节以下”。移植数十个冗长 Windsurf 规则描述的团队可能会超出此限制。
布局必须是扁平的：“技能必须是技能根目录的直接子项。像 ~/.agents/skills/group/my-skill/ 这样的嵌套文件夹是无法被发现的。”如果你将 Windsurf 技能组织到了子文件夹中，请将它们扁平化。
项目本地技能需要信任：“项目本地技能仅从受信任的工作区（worktrees）加载。在授予信任之前，来自新克隆或不受信任项目的技能将被排除在目录和斜杠命令之外。”在新克隆的仓库上，你的项目技能在授予信任之前将直接缺失——这是一个合理的安全默认设置，但也会让人在第一个小时感到困惑。
还有两个值得了解的微小差异。Zed 解决名称冲突的方向与全局优先习惯所期望的相反：“如果全局技能和项目本地技能共享相同的名称，则项目本地技能优先。”并且项目指令胜过个人指令——“当发生冲突时，项目指令会覆盖个人 AGENTS.md”——这与将个人设置排在最高优先级的工具相反。
更好的方法：两个编辑器都能读取的决策层
上述迁移只是移动了文件。它并没有解决根本问题，即这些规则背后的推理最初根本不在这些文件中。
你的 AGENTS.md 规定使用一个 HTTP 客户端。但它并没有说明，另一个客户端因为没人想要的重试行为而被尝试并放弃了。当规则在合并过程中被丢弃时——将十二个文件合并为一个文件必然会导致一些丢弃——规则会随着它存在的原因一起消失，而下一位工程师又得从头开始重新论证它。
MemoryLake 承载了这第二类内容：决策、被拒绝的备选方案，以及无论打开哪个编辑器都成立的约束条件。它存在于这两个工具之外，因此像这样的迁移只会移动配置，而保留完整的推理。从这里开始。
步骤 1：创建 API 密钥
为项目创建一个工作区并生成一个 API 密钥。将其范围限定在项目而不是编辑器上，这样该层在下一次工具更改以及本次更改中都能保留下来。
步骤 2：上传你的第一批记忆
在合并之前进行此操作，而不是在合并之后。逐个查看你的 .devin/rules/*.md 文件，并记录每个规则存在的原因——不是规则本身（它将进入 AGENTS.md），而是其背后的决策。添加你的 Windsurf 自动记忆捕获的、你实际依赖的任何内容；这些文件仅存在于一台机器上，没有提交到任何地方。
步骤 3：连接你的 AI 和智能体
连接 Zed 的智能体，如果在过渡期间同时运行两者，也连接 Windsurf。两者都读取相同的决策集，这意味着你尚未移植的规则，其推理在你已经切换到的编辑器中仍然可用。
这在实践中带来了什么改变
静默覆盖问题变得一目了然。你只需检查排序列表，清除干扰项，就大功告成了——而不是在三个月后才发现一个过期的 .windsurfrules 一直在默默地主导着每一次会话。
合并不再具有破坏性。当推理存在于其他地方时，将十二个规则文件折叠为一个按规则分段的 AGENTS.md 是完全没有问题的。如果该文件是唯一的记录，那将是真正的损失——这也是干净切换与Zed 遗忘你的项目上下文中描述的模式之间的区别，在后一种模式中，编辑器配置正确，但知识根本不存在。
在过渡期间运行两个编辑器不再会产生偏差。团队很少会在一个下午完成切换；总会有人在某次迭代中继续使用 Windsurf。通过一个共享层，团队的两部分成员都在基于同一套决策工作，即使他们的指令文件有所不同。
在 Zed 上第一个月的最佳实践
审计每个仓库的排序列表，而不仅仅是你测试的那一个。.cursorrules 和 .clinerules 的优先级也高于 AGENTS.md，一个经历了三种工具的单体仓库可能会同时包含所有这些文件。
将技能描述写成触发条件，而不是摘要。Zed 的指导是，“在处理 PDF、提取文本或填写表单时使用”优于“帮助处理 PDF”。由于描述现在承担了你以前的 glob 模式所做的工作，因此这是每个技能中杠杆率最高的句子。
刻意保持目录精简。每个描述都在竞争相同的 50KB 额度，而丢弃的技能只会在 UI 中显示为警告。更少、更精准的技能优于面面俱到的技能。
请记住，Zed 的加载器并不管辖其他智能体。其指令页面直接说明了这一点：“外部智能体和终端线程可以直接读取它们自己的原生指令文件。不要假设 Zed 的指令加载器控制这些智能体。”如果你通过 Zed 将 Claude 或 Codex 作为外部智能体运行，它们会读取自己的文件——我们在为 Zed 的外部智能体提供它们无法继承的上下文中绘制了这一边界。
注意编辑技能时的缓存细节：“对技能的 name 或 description 的更改会使当前会话中模型的提示词缓存失效。”在会话中期可以自由编辑主体内容；将你的描述重写进行批量处理。
结论
Windsurf 和 Zed 在很多方面的共识超过了大多数工具组合。它们共享相同的技能路径、技能格式和渐进式披露模型，这就是为什么这次迁移中技能部分的成本几乎为零的原因。
它们在一个会让人耗费数天时间的问题上存在分歧：Windsurf 会发现许多规则文件，并逐个文件决定是否注入它们，而 Zed 则从固定的九项列表中读取第一个匹配项。如果你要从本指南中采取行动，第一步就是清除仓库根目录下所有优先级高于 AGENTS.md 的文件——如果要采取第二步，那就是在将十二个文件合并为一个文件之前，写下你的规则存在的原因。