真正可以迁移的内容
编辑器级别的内容会自动迁移。 两者都是 VS Code 的分支，因此插件、主题、快捷键绑定和设置都可以毫不费力地迁移过来。这部分让迁移看起来很容易，却掩盖了不容易的部分。
你的规则只能作为文本迁移，而不能作为行为迁移。 社区文档描述了 Windsurf 同时运行两个规则系统：项目根目录下的旧版 .windsurfrules 文件，以及 .windsurf/rules/ 下较新的局部 Markdown 文件，总字符预算据称在 12,000 字符左右。Cursor 的模式则本质上不同。项目规则作为 .mdc 文件保存在 .cursor/rules 中并进行版本控制，通过三个 frontmatter 字段——alwaysApply、description、globs——来决定每个规则何时进入上下文。
因此，复制操作保留了内容，但激活机制丢失了，这就是为什么复制过去的规则集看起来在工作，实际上却悄无声息地失效了。
Cascade 记忆完全无法迁移。 它们是自动生成的，保存在生成它们的本地机器上，无法与团队成员共享，也没有导出路径。请注意这意味着什么：它们曾为你做过实际的工作，是迁移中唯一有硬性截止期限的部分，而提取它们的唯一方法是在旧助手仍在运行时询问它知道些什么。
任何你从未写下来的东西也无法迁移。 比如某个目录为什么不能动、部署顺序、客户的限制等。如果它既不在规则文件中，也不在 Cascade 的记忆中以可读形式存在，那么它就只存在于你的脑海中，或者存在于某个记得它的队友脑海中。
Cursor 在另一端为你提供了比以前更有结构性的系统。 根据其文档，有四种规则类型：.cursor/rules 中的项目规则（版本控制、仓库范围）、适用于整个 Cursor 环境的用户规则、在团队和企业版方案的仪表盘中管理的团队规则，以及作为 .cursor/rules 的纯 Markdown 替代方案的 AGENTS.md。Cursor 也清楚地说明了这一机制："大型语言模型在补全之间不会保留记忆。规则在提示词级别提供了持久、可复用的上下文。" 规则会被添加到模型上下文的前面。它们不是记忆，Cursor 也没有这样声称。
手动迁移步骤
步骤 1：在卸载任何内容前询问 Cascade
首先做这件事，并且要在旧编辑器还能打开的时候做。打开 Cascade，用通俗的语言问它对这个项目学到了什么——约定、注意事项、决策，以及它记得的关于你工作方式的任何事情。用不同的提问方式反复询问，并将答案粘贴到临时文件中。然后问它，它认为在这个代码库中不应该做什么，这会引出与正面问题不同的一组记忆。
这是迁移中唯一不可逆的一小时。规则文件保存在磁盘上，下周依然会在那里。而 Cascade 的记忆是本地生成的机器状态，无法导出，一旦编辑器被卸载，它们也就消失了。
在旧项目中，还要盘点文件本身：
- 项目根目录下的
.windsurfrules（如果还有的话） .windsurf/rules/下的所有内容- 你配置的工作流和任何工具定义
- MCP 服务器配置，你将重新添加而不是转换它们
然后按来源将规则分为三类：源自仓库的（README 里也有写——删除）、你写的且仍然有效的（这是需要迁移的部分），以及你写的但已过时的（现在就果断删除，趁你还记得哪个是哪个）。迁移是重新审视每一条规则的唯一时刻。好好利用它。
步骤 2：将每条规则重新编写为合适的激活模式
现在，逐条转换规则，并有针对性地选择类型。Cursor 的四种模式对应四种不同的成本：
- 始终应用 (
alwaysApply: true) —— 包含在每个聊天会话中，忽略 globs 和 description。将此模式保留给少数如果不遵守会导致答案错误的规则：版权头信息、"切勿修改dist/中的生成文件"、硬性的架构约束。 - 应用于特定文件 (设置了
globs:，且alwaysApply: false) —— 当匹配的文件处于上下文中时自动附加。这是你大部分 Windsurf 局部规则应该去的地方：globs: src/components/**/*.tsx将"前端规则"表达为一个具体的模式，而不是一种期望。 - 智能应用 (设置了
description:，无 globs) —— 智能体阅读描述，并在判断其相关时引入该规则。适用于无法映射到特定路径的领域规则，其效果完全取决于你编写的描述质量。 - 手动应用 (无描述，无 globs) —— 仅在你使用 @ 提及它时引入，例如
@my-rule。适合存放你希望按需获取、而不是在每次补全中都出现的长清单。
在此过程中要避免的三个技术陷阱：
文件后缀很重要。 项目规则必须使用 .mdc。Cursor 的文档指出，.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它们缺少 frontmatter 字段。如果你更喜欢纯 Markdown，文档中指定的路径是 AGENTS.md，而不是 rules 文件夹中的 .md 文件。
不要把所有内容都标记为“始终应用”。 这是让迁移快速“生效”的最快方法，也是让它变得毫无用处的最稳妥方法：每次补全中都包含所有规则会稀释真正重要的规则，而且 Cursor 的建议是将规则保持在 500 行以内。如果你的 Windsurf 配置之前受限于字符预算，那么该预算实际上是在通过迫使你做出选择来帮你的忙。而在 Cursor 中，没有机制会强制限制这一点。
将共享标准放在团队成员可以获取的地方。 项目规则是进行版本控制的，因此提交它们是团队继承你工作成果的方式。在团队和企业版方案中，仪表盘中的团队规则是更高的一层。你的个人习惯应该放在用户规则中，而不是代码仓库中。
最后，将你在步骤 1 中提取的 Cascade 知识妥善安置。其中大部分并不是规则的形式——而是上下文、历史和推理。有些可以变成规则；其余的则属于仓库文档或你的助手可以读取的存储库，这就是下一节的内容。
更好的方法：统一的记忆层，适用于任何编辑器
看看你刚才做了什么。你把一个厂商的规则格式转换成了另一个厂商的规则格式，并且因为没有其他办法，你手动从聊天窗口中复制了一组记忆。如果明年 Cursor 易主——而你阅读本文的原因正是因为你上一个编辑器易主了——你还得再做一次。
持久的划分方式是：规则留在仓库中，因为这是编程智能体眼前所需要的。而规则背后的知识则存放在不属于任何编辑器的第三方地方。
MemoryLake 就是为此而生的记忆层——你的规则所浓缩自的决策、事故记录和源文档，都保存在一个存储库中，可以直接从支持 MCP 的工具（如 Claude 和 Codex）中读取，也可以通过 API 从 ChatGPT 中读取。.mdc 文件说明做什么；存储库说明为什么，并且在编辑器更换后依然存在。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是粘贴到聊天窗口中。
步骤 2：上传你的第一批记忆
放入你刚刚转换的规则背后的文档、图片和文件：导致某个模块被禁用的事故记录、架构决策及其日期、客户需求、API 契约，以及你提取的 Cascade 知识。上传源文件，而不是整理好的摘要——摘要正是你在步骤 1 中费力试图重建的内容。
步骤 3：连接你的 AI 和智能体
通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆的权限。支持 MCP 的工具可以直接读取该存储库，并与它们自己的规则文件并存。对于 ChatGPT，通过 API 检索你需要的内容，并将其注入到提示词或调用模型的 workflow 中。
这在实践中带来了什么改变
第一个区别是，你的“始终应用”规则集可以保持很小。加载所有内容的压力来自于无处安放；当细节可以被检索时，始终加载的规则就只需保留那三个真正会改变答案的约束条件。
第二个区别是，原因会随规则一起流转。"不要修改 generated/ 中的文件" 会受到每个新工程师和每个新智能体的质疑。但如果同一条规则附带了工单和事故记录，就不会受到质疑，这就是约定与得以延续的架构决策之间的区别。
第三个区别是，提取工作变成了一次性成本。你为 Cascade 做过一次。你不需要为 Cursor 再做一次，因为知识不会被困在 Cursor 中——这也意味着当队友询问时，这些知识就在那里，而不是只存在于你的笔记本电脑上，这解决了规则无法在机器之间同步所带来的同样差距。
并且它与 Cursor 的原生功能相辅相成。规则继续在提示词级别发挥作用，正如文档所描述的那样。而存储库则保存了规则本不该保存的内容：历史、原理和文档本身。
离开已停用编辑器的最佳实践
假设应用中存在的所有内容都无法导出
规则文件是属于你的。但在任何工具中自动生成的记忆，通常都不属于你。在卸载之前，询问助手它知道些什么，并将答案复制出来。将所有仅存在于 UI 中的内容视为易失的。
转换范围，而不仅仅是文本
在这次迁移中，单次价值最高的行为是将"这些是我的前端规则"转换为 globs: src/components/**/*.tsx。路径范围的规则在相关时加载，在不相关时保持在上下文之外，这比寄希望于模型注意到限定词的规则既更便宜也更准确。
提交规则，并使用团队层来管理标准
版本控制中的规则是可评审和可继承的；而你个人设置中的规则则不然。在团队或企业版方案中，将组织范围的标准放在团队规则中，这样它们就不会依赖于每个开发人员的本地设置。
在迁移过程中进行删除
你带过去的每一条过时规则都会被智能体默默遵守，而它无法知道该规则已过时。删除一条你仍然需要的规则的代价是花一分钟重新编写它。而保留一条错误的规则的代价是一周令人困惑的代码差异（diffs）。
不要将规则视为强制手段
Cursor 明确指出，规则在提示词级别提供上下文。这是一种引导，而不是保证。任何每次都必须正确的事情——格式化、禁止直接推送至 main 分支、生成的文件保持原样——都应该放在格式化工具、钩子（hook）或 CI 中。规则负责解释，工具负责强制执行。
结论
从 Windsurf 迁移到 Cursor 看起来像是一个文件复制过程，但事实并非如此。两个编辑器都是 VS Code 的分支，因此编辑器层会自动迁移，然后关键的部分——每条规则何时适用——必须用 Cursor 的术语进行重建：通过 .mdc 文件的 frontmatter 来选择“始终应用”、文件模式、智能体选择或手动应用。如果直接将普通的 .md 文件复制到 .cursor/rules 中，它们会被完全忽略，且不会有任何错误提示。
因此，请按正确的顺序做好这两件事。在卸载之前询问 Cascade，因为自动生成的本地记忆无法导出，也没有第二次机会。然后将每条规则重新编写为合适的激活模式，删除过时的内容，提交团队需要的内容，并将这些规则背后的推理放入一个不在编辑器内部的存储库中。下一次 IDE 易主时，这个存储库将是让你只需花费一个下午而不是一整周时间进行迁移的关键原因。