如何在不丢失上下文的情况下从 Cline 迁移到 Cursor (2026)

你的规则只是作为文本迁移，而不是作为行为。 Cline 的文档指出，工作区规则存放在项目根目录的 .clinerules/ 中，Cline 会处理「.clinerules/ 内的所有 .md 和 .txt 文件，并将它们合并为一个统一的规则集」。全局规则在 macOS 和 Linux 上位于 ~/Documents/Cline/Rules，当发生冲突时，工作区规则优先。

Cursor 的模式本质上有所不同。项目规则是 .cursor/rules 下的 .mdc 文件，受版本控制，并且有三个 frontmatter 字段——alwaysApply、description、globs——决定每个规则何时进入上下文。其文档明确指出，该文件夹中的普通 .md 文件会被规则系统忽略，因为它们缺少这些字段，而普通的 Markdown 应该放在 AGENTS.md 中。

特别注意 .txt 的情况：Cline 可以读取 .txt 规则，而 Cursor 的规则系统根本没有它们的位置。这些规则会无声无息地消失。

激活语义大致对应，但形式却不尽相同。 Cline 的条件规则「仅在当前文件与定义的范围匹配时激活」，而且——对转换最重要的一句话是——「没有 frontmatter 的规则始终处于激活状态」。

因此，一个典型的 .clinerules/ 文件夹就是一堆始终激活并合并在一起的文件。这实际上是一个巨大的、始终开启的指令块。如果将其一对一地转换为带有 alwaysApply: true 的 .mdc 文件，你确实忠实地重现了这个指令块，但 Cursor 官方的建议是将规则保持在 500 行以内。这种「忠实」反而是错误的。

Memory Bank 作为文件迁移，但失去了其运行机制。 这是最关键的部分。根据文档，Cline 的 Memory Bank 是「一个结构化的文档系统，可帮助 Cline 在不同会话之间保持上下文」，从而将 Cline 「从一个无状态的助手转变为一个持久的开发伙伴」。它规定了六个核心文件：projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md 和 progress.md。

请看它所基于的前提，这在 Cline 自己的文档中以第一人称表述：「我的记忆在会话之间会完全重置。这并不是一个限制——正是它促使我保持完美的文档记录。」以及运行规则：「每次重置后，我完全依赖我的 Memory Bank 来理解项目并有效地继续工作。」

这之所以有效，是因为 Cline 被指示在每次任务开始时读取所有这些内容。Cursor 没有等效的约定。即使你把文件夹复制过去，文档虽然在，也是最新的，但却处于未被读取的状态。

作为替代，Cursor 为你提供了什么。 根据其文档，有四种规则类型：在 .cursor/rules 中作用于代码库并受版本控制的项目规则、适用于整个 Cursor 环境的用户规则、在 Team 和 Enterprise 方案中通过仪表板管理的团队规则，以及作为 .cursor/rules 的纯 Markdown 替代方案的 AGENTS.md。规则会被添加到模型上下文的前面。Cursor 同样直白地陈述了底层现实：「大型语言模型在补全之间不会保留记忆。规则在提示词级别提供了持久且可重用的上下文。」

这两种工具都承认没有记忆。它们的分歧在于你应该如何应对——Cline 认为应该虔诚地维护文档，而 Cursor 认为应该精确地配置规则。这次迁移是这两种哲学之间的转换，而不仅仅是两种文件格式之间的转换。

步骤 1：在转换任何内容之前拆分统一的规则块

不要进行文件对文件的转换。将 .clinerules/ 的合并内容作为一个文档来阅读（这也是 Cline 对待它的方式），并根据每个部分应该在何时应用来重新划分：

• 始终，在每次补全中：两到三个如果违反就会导致回答错误的约束条件。例如版权头信息、「切勿编辑生成的文件」、硬性架构规则等。
• 仅在触及特定文件时：任何提及目录、语言或层级的内容。这通常占了大部分。
• 仅在模型判断相关时：无法映射到具体路径的领域约定。
• 仅在你要求时：长清单、发布流程、评审协议。

然后在 .cursor/rules 中为每个组编写一个 .mdc 文件，并设置相应的 frontmatter：

• 始终 → alwaysApply: true（忽略 globs 和 description）
• 文件范围 → globs: src/api/**/*.ts 且 alwaysApply: false
• 模型选择 → 填写好 description: 且不设 globs
• 手动 → 两者都不设置，在聊天中通过 @rule-name 调用

在此过程中有两个陷阱。文件扩展名必须是 .mdc——.cursor/rules 中的 .md 文件会被直接忽略，且不会报错。此外，你的 Cline 全局规则（~/Documents/Cline/Rules）是个人规则，而非项目规则，因此它们应该放在 Cursor 的「Customize」下的「User Rules」中，而不是放在代码库中。如果你的团队共享标准，在 Team 和 Enterprise 方案中，通过仪表板管理的团队规则是更上层的选择。

在这里也要做好清理工作。迁移是唯一一个有人会用全新的眼光审视每条规则的时刻；否则，为已经废弃的服务编写的规则将会被无限期地遵守下去。

步骤 2：决定如何处理 Memory Bank

你有三个选择，深思熟虑地做出选择比选择哪一个更重要。

选项 A：保留它并让 Cursor 指向它。 编写一个 alwaysApply: true 的 .mdc 规则，指示智能体在开始工作前读取 memory-bank/activeContext.md 和 memory-bank/progress.md，并在结束时更新它们。这是对 Cline 行为最接近的重现。但代价也是实实在在的：你在每个会话中都重新添加了一个始终开启的指令，以及它所触发的文件读取操作。

选项 B：将持久部分融入规则，其余部分保留为文档。 systemPatterns.md 和 techContext.md 大多是稳定的架构和技术栈事实——这些可以转化为项目规则或 AGENTS.md。projectbrief.md 和 productContext.md 是供人类阅读一次的引导文档，可以将它们保留为代码库文档。activeContext.md 和 progress.md 是会话状态，在这里你必须坦诚面对：Cursor 中没有任何机制会为你维护它们，因此你要么手动更新它们，要么任由它们腐烂，变成对项目现状的「自信且错误」的描述。

选项 C：弃用这种格式，但保留内容。 这六个文件的结构之所以存在，是因为 Cline 需要在每次重置后有一个固定的地方来寻找信息。如果你不再运行 Cline，这个结构就只是脚手架——真正重要的是其中的决策、架构和约束能够保存在某个可以检索的地方。

无论你选择哪种方式，都不要静默地什么都不做。代码库中一个过期的 activeContext.md 比没有 memory bank 还要糟糕，因为下一个人——或者下一个偶然读到它的智能体——会信以为真。

在关闭旧设置之前，还有一项需要盘点的内容：Cline 学到过但你从未写入 Memory Bank 的任何东西。在会话中问问它，它对项目的奇特之处了解多少，以及它会给新开发人员提出什么警告。把答案粘贴到某个地方。这是本次迁移中唯一有截止期限的部分。

请注意 Cline 的 Memory Bank 哪些地方做对了，因为这就是人们喜爱它的原因：它将知识视为一等公民（first-class artifact），而不是聊天的副产品。它的弱点在于这些资产存放的位置以及由谁来维护——一个代码库中的六个文件，由一个工具的约定来更新，对你使用的其他任何助手都是不可见的。

因此，保留这种直觉，但改变存放地址。规则留在代码库中，采用 Cursor 的格式，保持精简。而规则背后的知识——决策、架构、事件、合同——则存放在任何工具都可以读写的存储库中。

MemoryLake 就是为此设计的记忆层——一个存放你的文档、决策和项目知识的统一存储库，支持 MCP 的工具（如 Claude 和 Codex）可以直接读取，ChatGPT 也可以通过 API 读取。这实现了 Memory Bank 的理念，同时摆脱了必须依赖单一智能体约定来维持其生命力的限制。

步骤 1：创建 API 密钥

生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是直接粘贴到聊天中。

步骤 2：上传你的第一批记忆

放入你的 Memory Bank 曾代表的文档、图像和文件：原封不动的 systemPatterns.md 和 techContext.md、架构决策及其原因、事件记录、API 合同以及你积累的约束条件。上传源文件而不是精简版——精简往往会丢失规则背后的原因。

步骤 3：连接你的 AI 和智能体

通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆的权限。支持 MCP 的工具可以直接读取同一个存储库，因此知识可以传递给你本月正在使用的任何智能体，而不是你去年采用其文件夹约定的那个智能体。

第一个区别是，你的始终开启规则可以缩减为三条。过去之所以迫切地想让所有内容都始终应用，是因为没有其他地方可以存放上下文；有了可用的检索机制后，alwaysApply: true 就可以专门留给那些一旦违反就会导致回答错误的内容。

第二个区别是，activeContext.md 不再是一个迟早会失效的谎言。无人维护的状态会逐渐失效；而存放在存储库中的状态，随着智能体在工作时不断写回，可以保持最新，并且那些真正稳定的部分（如决策、架构）根本不需要维护。

第三个区别是，知识不再受限于工具的形式。Memory Bank 是 Cline 的约定，.cursor/rules 是 Cursor 的约定，CLAUDE.md 是 Claude Code 的约定。这三者中的实质内容是完全相同的，这就是为什么在知识独立于它们存在之前，切换编辑器总是要耗费一个周末的时间。

而且它与 Cursor 的原生功能相得益彰。规则继续按照文档说明在提示词级别提供上下文，团队规则继续分发标准，而两者都不必承载项目的历史——这就是为什么 Cursor 的规则让人感觉总是被遗忘，而实际上它们在设计上本就是精简的。

按激活条件重新划分规则，绝不进行文件对文件的转换

Cline 会合并所有内容；Cursor 则独立评估每个文件。一对一的复制要么会失去条件限制，要么会让所有内容都变成始终开启。花一个小时重新划分——这决定了你的规则是只在相关时触发，还是作为一个臃肿的整体稀释每一个提示词。

在调试任何内容之前，先检查文件扩展名

必须是 .mdc，否则它就不存在。.cursor/rules 中的 .md 文件会被规则系统忽略，而 .txt 文件则根本没有容身之所。如果迁移后 Cursor 「不遵守你的规则」，请先检查这一点。

将个人规则放入 User Rules，团队标准放入团队规则

Cline 的全局规则文件夹是个人层面的，而代码库不是。Cursor 的 User Rules 涵盖了你跨项目的习惯，而在 Team 和 Enterprise 方案中，通过仪表板管理的团队规则涵盖了组织标准。将这三者混入项目规则中，会导致团队中的每个人都不得不继承某个人的个人偏好。

在第一天就决定 Memory Bank 的去留

通过始终开启的规则保留它、将其融入规则和文档中，或者弃用该格式并迁移内容。这三种做法都是合理的。但在代码库中留下六个无人维护的文件是不合理的，因为它们的核心价值就在于保持最新。

在停止使用旧智能体之前，问问它知道些什么

任何未写入 Memory Bank 的内容都只存在于你即将放弃的会话中。花十分钟询问 Cline 它会给新开发人员提出什么警告，是整个过程中成本最低的保险。

不要指指望规则能起到强制执行的作用

Cursor 直接指出：规则在提示词级别提供持久且可重用的上下文。上下文是引导，而非强制。格式化、受保护的文件、禁用的导入和提交策略应该属于格式化工具、Linter 和 CI——然后规则文件可以解释它们存在的原因。

从 Cline 到 Cursor 的迁移，实际上是包裹在同一件外衣下的两次迁移。规则部分需要重新划分而不是直接复制，因为 Cline 会将 .clinerules/ 中的每个 .md 和 .txt 文件合并为一个统一的规则集，而 Cursor 则根据每个 .mdc 文件的 frontmatter 来决定其去留——并且 .cursor/rules 中的普通 .md 文件会被直接忽略且不报错。Memory Bank 部分则是会悄然失效的部分：这六个 Markdown 文件虽然完好无损地迁移了过来，却失去了让 Cline 在每次重置后读取它们的约定。

这两种工具都告诉你了底层问题的真相。Cline 说它的记忆在会话之间会完全重置，这就是它坚持要求记录文档的原因。Cursor 说模型在补全之间不会保留记忆，这就是它坚持使用规则的原因。认真对待 Memory Bank 的设计初衷，保持规则的精简和针对性，并将知识本身存放在不属于任何一种工具的存储库中。这样，下一次迁移就只是配置的更改，而不是一次大动干戈的挖掘工作。