实际可以迁移的内容
AGENTS.md——真正的桥梁，两者皆可读取。 Cursor 支持“在项目根目录和子目录中”使用 AGENTS.md，并将嵌套文件与其父级文件合并，从而使“更具体的指令具有更高的优先级”。Cline 的支持规则表格中将 AGENTS.md 和 ~/.agents/AGENTS.md 列为“跨工具兼容的标准格式”。如果你的规则已经写在 AGENTS.md 中，那么你已经完成了大部分工作，你可以在做决定期间让这两个工具同时运行在同一个文件上。
Skills（技能）——通过一个完全共享的目录。 Cursor 从 .agents/skills/、.cursor/skills/、~/.agents/skills/ 和 ~/.cursor/skills/ 加载技能，此外还有一个兼容性列表：“为了兼容性，Cursor 还会从 Claude 和 Codex 目录加载技能：.claude/skills/、.codex/skills/、~/.claude/skills/ 和 ~/.codex/skills/。”而 Cline 则从 .cline/skills/、.clinerules/skills/ 和 .claude/skills/ 读取项目技能。对比这两个列表，你会发现两者都有一个共同的目录：.claude/skills/，它不属于这两个工具中的任何一个。将你的技能放在那里，两个工具就都能读取它们。两边的 SKILL.md 格式是相同的，所以这只是移动，而不是重写。
你的模型——包括 OpenAI 模型，如果这是你阅读本文的原因。 Cline 记录了两种使用 OpenAI 的途径：在设置中输入 API 密钥，以及“OpenAI Codex (Subscription OAuth)”，即你“使用 OpenAI 登录并完成浏览器 OAuth 授权”，“无需输入 API 密钥”，且“可用模型取决于你的 OpenAI 计划”。这值得与 Cursor 自己的“自带密钥”页面进行对比，后者将 OpenAI 限制为“标准的非推理聊天模型”，并指出“自定义 API 密钥仅适用于聊天模型”。
无法迁移的内容：作为范围限定语言的 .mdc frontmatter。 这是真正的核心工作。Cursor 的四种规则类型构建在三个 frontmatter 字段之上，其文档详细说明了它们之间的交互：alwaysApply: true 意味着“始终包含。忽略 Globs 和描述”；false 且带有 globs 意味着“当匹配的文件处于上下文中时自动附加”；false 且带有 description 意味着“智能体读取描述并在相关时拉入规则”；false 且两者都没有则意味着“仅在你在聊天中 @ 提及该规则时才包含”。Cline 没有等效的元数据。它“处理 .clinerules/ 内的所有 .md 和 .txt 文件，并将它们合并为一套统一的规则”。所有内容要么启用，要么禁用，每个文件都有一个手动开关。
同样不复存在：作为强制执行手段的 Team Rules（团队规则）。 Cursor 的 Team Rules 是在仪表板中创建的，遵循文档中记录的优先级顺序：“Team Rules → Project Rules → User Rules”，并且可以标记为“所有团队成员必用，且无法在自定义中禁用”。Cline 的模式在设计上恰恰相反：“所有检测到的规则类型都会显示在 Rules 面板中，你可以在其中单独切换它们。”每个规则都可以由使用者自行开关。对于依赖强制执行的团队来说，这是一个真正的损失，而且没有任何文件能将其迁移过去。
还有：远程规则同步也消失了。 Cursor 可以将 GitHub 仓库中的规则导入到 .cursor/rules/imported/<repoName> 中并进行“拉取和同步”。Cline 的等效做法是将 .clinerules/ 放在你的仓库中，这解决了单个项目的相同需求，但无法解决跨多个项目共享规则的需求。
手动迁移步骤
步骤 1：根据规则的激活方式而非所在文件来整理你的规则
打开 .cursor/rules 并根据 frontmatter 对每个 .mdc 文件进行分类，因为这是决定它应该落脚何处的唯一依据。分为四堆。
alwaysApply: true。 这些是你的常驻规则，可以直接移动。如果你希望两个工具读取同一个文件，请将它们放入 AGENTS.md 中；如果你决定完全使用 Cline，请放入 .clinerules/ 中。两者都可行，前者能让你保留更多选择。
设置了 globs。 这些没有直接的等效项。Cline 的规则不会根据文件模式条件性地附加，因此仅适用于 src/components/**/*.tsx 的规则要么变成常驻规则（在每个任务上都要付出上下文成本），要么变成你在该区域工作时手动开启的切换规则。请针对每个规则进行选择，不要进行一刀切的转换。
设置了 description 且 alwaysApply: false。 这些规则有一个比你想象中更好的归宿，而且它不是规则系统。Cursor 将这种类型描述为“当智能体根据描述决定其相关时”应用。Cline 的 skills（技能）工作方式相同：“当你发送消息时，Cline 会看到可用技能及其描述的列表。如果你的请求与某个技能的描述相匹配，Cline 会使用 use_skill 工具激活它，该工具会从 SKILL.md 加载完整的指令。”机制相同，只是名称不同。描述触发的规则转换为技能比转换为规则文件更为贴切。
未设置任何字段。 这些是仅限 @ 提及的规则。在 Cline 中，它们会变成保持关闭状态的规则文件，或者你显式调用的技能。两种方式都可以，手动开关更接近原始体验。
在此过程中，请勿删除 .mdc 文件。它们是记录哪些规则限定在哪些范围内的唯一凭证。
步骤 2：放置文件、配置模型并关注上下文成本
在项目根目录下创建 .clinerules/，并保持每个文件只关注一个主题——这是 Cline 官方的建议，在这里尤为重要，因为手动开关是你唯一的范围限定工具：“按主题拆分规则……这使得轻松开启或关闭特定规则变得容易。”
需要做对的三件事：
注意 Token 账单。 Cline 对此提出了警告：“规则会消耗上下文 Token。避免冗长的解释或粘贴整个样式指南。保持规则简洁，并在需要详细参考时链接到外部文档。”在 Cursor 中，在匹配的文件进入上下文之前，glob 规则不会消耗你任何成本。如果将其中几个转换为常驻规则，你就悄无声息地将该成本转移到了每个任务中。
了解全局规则存放在哪里以及谁会胜出。 Cline 的全局规则目录在 macOS 和 Linux 上是 ~/Documents/Cline/Rules，在 Windows 上是 Documents\Cline\Rules，它还会读取 ~/.agents/AGENTS.md。当两者同时存在时，“当工作区规则与全局规则冲突时，工作区规则优先”——这与 Cursor 的项目优先于用户的顺序相同，因此你的直觉依然适用。
注意技能层的一个反转。 Cline 指出：“当全局技能和项目技能同名时，全局技能优先。”这与规则的解析方式相反，也与大多数工具相反。如果你保留了一个同名的个人技能和项目技能，个人技能会胜出。
然后配置你的服务商——在 Cline 设置中的 OpenAI 下配置 API 密钥或 Codex OAuth——并重新添加你的 MCP 服务器，这些服务器不会从任何编辑器中自动迁移过来。
以上涵盖了书面规则的部分。剩下的是其背后的推理，而这两个工具都没有存放这些内容的地方。
更好的方法：将推理放在不属于任何编辑器的第三方位置
Cline 解决持久性问题的方法是 Memory Bank，这非常值得了解，因为它坦诚地说明了自己是什么。你的仓库中有六个 Markdown 文件——projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、progress.md——外加一个告诉 Cline 读取它们的规则文件。它附带的指令开头有一行非常值得完整引用的话：“我是 Cline，一名优秀的软件工程师，我有一个独特的特征：我的记忆在每次会话之间都会完全重置。这不是一个限制——正是这一点驱使我保持完美的文档记录。”
这是一种文档方法论，而且非常不错。它的范围也限定在代码库中：六个描述单个项目状态的文件，通过要求 Cline “更新 memory bank” 来进行更新。而无法放入其中的，是那些从来不关乎代码本身的事情——例如为什么存在某个标准、你的团队尝试过并拒绝了什么、该问谁、哪个截止日期变动了。
MemoryLake 是一个独立于任何单一工具之外的记忆层，因此这些资料可以在这次迁移以及下一次迁移中幸存下来。设置只需三个步骤。
步骤 1：创建 API 密钥
登录并创建一个 API 密钥。一个凭证即可连接你所使用的所有工具。
步骤 2：上传你的第一批记忆
简短的条目，每条记录一个要点。你的源材料就是那些你无法放入 frontmatter 的内容：
为什么每个常驻规则都是常驻的。 你刚刚对转换的每个 glob 规则做出了判断。记录下这个决定和原因，否则三个月后你又会做出不同的选择。
被强制执行的 Team Rules 保护的是什么。 强制执行机制无法在迁移中保留，但它存在的原因应该保留下来。
行之有效的修正。 团队尝试过并放弃的方法。两边的规则格式都没有为此提供字段。
非代码的工作上下文。 所有权、冻结区域、当前优先级、运行手册。Memory Bank 的 activeContext.md 为单个仓库涵盖了其中一部分；而这可以跨所有仓库涵盖这些内容。
步骤 3：连接你的 AI 和智能体
连接你所使用的工具。MemoryLake 可以通过 MCP 和 API 访问，而 Cline 支持 MCP 服务器，因此相同的记忆可以立即在 Cline 中使用。Cursor、Claude Code、Codex 和 OpenClaw 也以同样的方式连接——这意味着你可以在过渡期间同时打开两个编辑器，而无需维护两份你所掌握的知识副本。
三个客观的局限性。这不会转换你的 .mdc 文件——步骤 1 中的 frontmatter 映射是手动的，而且理应如此，因为这涉及选择。它不会恢复强制执行；记忆层无法让 Cline 的 Rules 面板中的规则变得不可禁用。而且记忆是上下文，而不是强制执行——Cursor 的文档在其自身的强制规则中也提到了这一点：“AI 指导不应是你唯一的安全控制手段。”
这在实践中带来了什么改变
规则范围限定变成了一个明确的决定。 Cursor 是通过 frontmatter 来决定的。Cline 则让你公开地针对每个文件进行一次选择。
描述触发的规则有了真正的归宿。 转换为技能而不是塞进常驻文件中，它们保留了你真正想要的行为了。
技能不再属于某个特定的编辑器。 两个工具都读取同一个目录，因此切换编辑器不再需要进行技能迁移。
推理不再只存在于聊天窗口中。 这是让所有这些内容在下一次工具更换中幸存下来的唯一原因。
从 Cursor 迁移到 Cline 的最佳实践
按激活模式转换，而不是按文件转换。 frontmatter 就是规范。文件名说明不了任何问题。
在做决定期间，使用 AGENTS.md 存放常驻规则。 两个工具都会读取它，因此如果你改变主意，也不会有任何内容被遗弃。
将描述触发的规则发送到技能。 Cline 的技能激活比任何规则文件都更接近 Cursor 的“智能应用”行为。
如果你想同时使用两个编辑器，请将技能放在 .claude/skills/ 中。 这是两个支持列表中唯一重合的目录。
审计你设置为常驻的内容。 每个转换后的 glob 规则现在都会在每个任务上消耗上下文，而 Cline 恰恰对此提出了警告。
写下强制执行的目的是什么。 这是唯一无法保留的属性，而它通常是因为某个至今仍能说得清的原因而存在的。
在尘埃落定之前，保留 .mdc 文件。 它们记录了你即将重新实现的范围限定。
不要将 Memory Bank 与跨项目记忆混淆。 它描述的是单个代码库的状态——更广泛的区别请参考为什么长上下文不是记忆。
结论
Cline 表面上提供的免费迁移并不是你所需要的。它的规则表格检测的是 .cursorrules，这是 Cursor 当前文档中已不再提及的格式，而你实际拥有的格式——装满 .mdc 文件的 .cursor/rules——在 Cline 的文档中无处寻觅。确实存在的桥梁是 AGENTS.md（两个工具都会读取），以及 .claude/skills/（出现在两个支持列表中的唯一技能目录）。
耗费你时间的是 frontmatter。Cursor 的三个字段产生了四种激活行为，而 Cline 的规则则是非全即无的手动开关。在复制任何内容之前，请先按 alwaysApply、globs 和 description 进行分类：常驻规则直接移动，glob 规则变成关于上下文成本的逐条规则判断，描述触发的规则最适合转换为技能，而 @ 提及的规则变成开关。Team Rules 的强制执行则完全无法转换。
而这一切之下的底层逻辑——为什么存在这些规则、尝试过并放弃了什么、谁拥有什么——从未存在于任何一个工具’的格式中。Cline 的 Memory Bank 坦诚地说明了它在会话之间会完全重置，这正是为什么推理应该放在不属于任何编辑器的第三方位置。如果带你来到这里的症状是规则在悄无声息地失效，那么这个故事的两面都已在为什么 Cursor 会忘记你的项目规则和为什么 Cline 会忘记你的项目上下文中进行了阐述。