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

代码会传输，并保持传输。 Lovable 的 GitHub 集成支持导出和双向同步：在 Lovable 中所做的更改会同步到 GitHub，而推送到活动 GitHub 分支的更改也会同步回 Lovable。这包含两个层级 —— 一个是通过其 GitHub 应用授权 Lovable 并可在项目间复用的工作区连接，以及一个将单个 Lovable 项目连接到单个仓库的项目仓库链接。

在依赖它之前，有一些实际的限制值得了解。Lovable 一次只能编辑和同步一个分支，通常是仓库的默认分支（通常是 main）；要在其他地方工作，你需要在项目的 GitHub 设置中选择一个不同的分支，你也可以在那里创建一个新分支。你无法将现有的 GitHub 仓库导入到 Lovable 中，并且在断开连接后无法重新连接到同一个仓库 —— 你会得到一个新仓库。GitHub 应用无法在同一个账户或组织上安装两次，超过 100 MB 的文件无法同步，重命名 GitHub 用户名或组织会破坏连接。

环境变量和机密通常是第一个绊脚石。 Lovable 的 GitHub 文档没有提及它们，而在实践中，仓库并不是存放你服务商密钥的地方 —— 经历过这种迁移的开发者一致反映，在克隆后需要手动配置 Supabase、Stripe 和类似的凭据。预留一个小时来解决那些“在 Lovable 中运行良好”但实际上是因为缺少环境变量而导致的失败。

Knowledge 无法传输，这也是 Cursor 显得不够聪明的原因。 Lovable 的 Knowledge 功能允许你向 Agent 提供持久的指令和上下文，分为两个层级：

• Workspace Knowledge —— 工作区内所有项目共享的规则：代码风格规范、命名规范、首选库或框架、共享架构模式、测试要求、代码质量或 linting 规则。只有工作区所有者和管理员可以管理它。
• Project Knowledge —— 单个项目的持久指令和上下文：应用程序的功能、用户画像、数据库模式、架构决策、领域术语、设计指南以及重要参考资料的链接。任何拥有项目编辑权限的人都可以编辑。

两者都位于 Settings → Knowledge 和 Project settings → Knowledge 下，两者的上限都是 10,000 字符，而且 —— 这是人们低估的部分 —— Knowledge 总是作为背景上下文包含在 Lovable 的每条消息中，尽管 Lovable 自己的文档指出在极长的对话中一致性可能会有所不同。

再读一遍那个列表，你会发现它其实就是一个规则文件。Lovable 之前做的事情正是 .cursor/rules 所做的；它只是把这些内容放在了一个你可能好几个月都没打开过的文本框里。

聊天记录无法传输，这是真正的损失。 你输入的每一个“不，不是那样的”、你通过碰壁发现的每一个约束、你拒绝的每一个方案 —— 这些都在对话中，而对话保留在 Lovable 中。如果你足够自律，其中一些内容可能在 Knowledge 中。但大部分都不在，这就是为什么 Lovable 在会话之间丢失项目上下文 也是该平台用户常抱怨的问题。

步骤 1：将代码导入 Cursor，并确认同步状态

在你的 Lovable 项目中，打开 Settings 并连接 GitHub（如果尚未连接），这将授权 Lovable 的 GitHub 应用并创建仓库。然后将其克隆到本地并在 Cursor 中打开该文件夹。

在开始编辑之前决定你的同步策略，因为双向同步是一把双刃剑：

• 彻底断开 —— 你不再使用 Lovable。克隆并正常工作；没有任何内容会流回 Lovable。
• 两者保留 —— 用 Lovable 进行快速 UI 迭代，用 Cursor 处理逻辑。这很合理且常见，两者并不是真正的竞争对手。只需记住 Lovable 只监视一个分支：你推送到该分支的提交会流回 Lovable，而在其他分支上的工作在切换分支选择器之前对它是不可见的。

然后处理环境。复制现有的 .env.example，填入来自服务商控制面板的真实值，并在更改任何代码之前验证应用是否能在本地运行。先做这一步意味着你看到的下一个失败将是你自己的代码问题，而不是缺失密钥。

注意：不要为了“清理项目”而断开 GitHub 集成。之后你将无法重新连接到同一个仓库 —— Lovable 会创建一个新仓库 —— 这会把清理工作变成你自己项目的分叉（fork）。

步骤 2：将 Lovable Knowledge 转换为 Cursor 规则

这部分决定了 Cursor 让你觉得是升级还是降级。

在 Lovable 中打开两个层级的 Knowledge 并将它们复制出来。然后将它们映射到 Cursor 的模型上，Cursor 的模型比 Lovable 的更细致：

Cursor 的项目规则以 .mdc 文件的形式存在于 .cursor/rules 中，受版本控制，包含 frontmatter 字段 description、globs 和 alwaysApply，以及四种激活模式：

• Always Apply (始终应用) —— 每次聊天会话
• Apply Intelligently (智能应用) —— 当 Agent 根据描述决定其相关时
• Apply to Specific Files (应用到特定文件) —— 当文件匹配某种模式时
• Apply Manually (手动应用) —— 在聊天中被 @ 提及（@-mentioned）时

因为 Lovable 的 Knowledge 是始终开启的，最懒惰的转换方法是将所有内容都设为 Always Apply。不要这样做。你每个层级有 10,000 字符的 Lovable Knowledge，而 Cursor 的文档建议将规则保持在 500 行以下，并拆分为可组合的片段 —— 因此，请利用刚刚获得的细粒度控制：

• Workspace Knowledge（编码标准、命名、首选库、linting）→ Cursor 的 User Rules，即 Customize → Rules 下适用于所有项目的全局偏好设置。这是最接近的结构对应，这意味着你的下一个项目会像在 Lovable 中一样继承它们。
• 真正属于全局仓库的 Project Knowledge（应用功能、领域术语）→ .cursor/rules 中的 Always Apply 规则，或者项目根目录下的 AGENTS.md（Cursor 支持将其作为 .cursor/rules 的替代方案，并会从子目录中读取）。
• 特定区域的 Project Knowledge（数据库模式、设计指南）→ 作用域规则。一个带有指向数据层 globs 的模式规则只有在你处于该目录下时才会加载。这显然比 Lovable 的做法更好，也是这次迁移的主要升级点。
• 重要参考资料的链接 → 将它们保留为你通过 @ 提及的规则，或者作为 AGENTS.md 指向的仓库中的文档。它们不需要出现在每个请求中。

然后写下那些从未存在于 Knowledge 中的内容。浏览你的 Lovable 聊天记录 —— 或者至少是过去两周的记录 —— 并提取出决策。不是代码，而是原因：为什么要采用这种组件结构、你尝试并放弃了哪个库、客户否决了什么。将每一个决策放入仓库中一个带日期的文档中。这很繁琐，但这是整个迁移中价值最高的一个小时，因为它是这个过程中唯一无法从现有产物中重建的内容。

在步骤 2 结束时，值得诚实地评估一下你构建了什么：一个组织得更好的同类系统。Cursor 自己的文档解释了这种机制存在的原因 —— “大型语言模型在补全之间不保留记忆。规则在提示词层级提供了持久、可复用的上下文。” 规则是每次重新提供上下文的一种方式。它们保存了你记得写下来的内容，而且它们只是某一个工具的格式，这正是你之前在使用 Knowledge 时所处的境地。

看看步骤 2 实际上做了什么：你把上下文从一个产品的 10,000 字符文本框复制到另一个产品的文件格式中，然后手动重建了从未存在于这两者中的部分。

现在考虑一下，许多进行这种迁移的人会继续同时使用这两个工具 —— 而这就是没人预料到的偏离。你的代码会自动保持同步，因为这就是 GitHub 集成所做的事情。但你的知识不会。你在 Cursor 中做出的决策永远不会传达到 Lovable 的 Knowledge 中，因此 Lovable 会继续针对一个已经过时一个月的项目画像进行生成，这种偏差会表现为重新生成的组件悄悄违反了你在其他地方建立的规则。双向代码同步加上单向知识同步是一个比完全不同步更糟糕的失败模式，因为它看起来毫无问题。

将知识保留在两个工具都能读取的统一图层中可以解决这个问题。MemoryLake 是一个位于工具之下的记忆层 —— 将决策、模式、领域术语及其背后的原因保存在一个存储库中，可以通过 MCP 从 Cursor 读取，也可以通过 API 从任何其他工具读取。该存储库不受文本框限制，也不是你在下次切换工具时需要再次转换的格式。

客观地说：Lovable 的 Knowledge 在其功能范围内是一个设计良好的功能。两个作用域层级、始终应用、可由合适的人编辑，并且确实能让 Agent 表现良好。同样，.cursor/rules 是纯文本、受版本控制、在拉取请求（PR）中进行审查，并由你的团队自动继承。继续将两者用于常规规则。而记忆层则用于积累记录 —— 这些记录对于 10,000 字符的字段来说太长，太具体而不便公开，且极易丢失，无法依赖人工录入。

步骤 1：创建 API 密钥

生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中 —— 你已经在为此项目设置环境变量，因此请将其添加在那里，而不是添加到同步到 GitHub 的文件中。

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

放入 Knowledge 无法容纳的文档、图像和文件：包含其历史记录的模式、架构决策及其原因、设计指南、客户约束。尽可能上传源文件而不是摘要。

步骤 3：连接你的 AI 和 Agent

允许 Claude、Codex、OpenClaw 和其他 AI Agent 通过 MCP 或 API 访问记忆。Cursor 支持 MCP 服务器，因此这是一个配置项。对于没有 MCP 客户端的工具，通过 API 检索你需要的内容并将其注入到提示词或工作流中。

第一个区别体现在你在 Cursor 中的第一个实际任务上。你得到的不再是一个只知道你的文件树而别无所知的编辑器，而是一个能够回答为什么身份验证流程是这样设计的编辑器 —— 因为决策保存在存储库中，而不是在 Lovable 的对话线程中。

第二个区别是作用域规则开始发挥 Lovable 无法做到的作用。当你处于数据层时，你的模式规范会加载，而在你编辑 CSS 时则不会干扰你。这是此次迁移带来的真正能力提升，而且只有在你抵制将所有内容都转换为 Always Apply 时才会实现。

第三个区别是上述的偏差问题。当两个工具都读取同一个存储库时，在 Cursor 中做出的决策对你接下来使用的任何工具都是可见的 —— 这就是两个工具协同工作与两个工具逐渐对你的项目产生分歧之间的区别。

而且它在下一步中依然适用。很多人在一年内会经历 Lovable → Cursor → 其他工具的路线。这种模式已经非常成熟，以至于 从原型平台到真实编辑器的迁移 现在已经成为一个独立的类别。工具中的知识意味着你需要重做这一切；而工具之下的知识则意味着你不需要。

在更改任何内容之前，验证应用是否能在本地运行

克隆、安装、配置环境变量、运行。最常见的“Lovable 代码损坏”报告其实是缺少凭据，而在重构的同时诊断这个问题是极其痛苦的。先确保成功运行一次，然后再开始工作。

不要将所有 Knowledge 转换为 Always Apply

Lovable 的 Knowledge 始终开启是因为那是唯一的选择。Cursor 提供了 globs 和基于描述的激活方式 —— 利用它们。将所有内容都设置为 Always Apply 会导致每次请求都加载这些内容，而臃肿的规则目录是这次迁移中最常见的遗憾。

迁移原因，而不仅仅是规则

Knowledge 告诉 Cursor 你的规范是什么。它很少说明为什么，而“为什么”才是阻止 Agent 兴高采烈地重新推荐你已经放弃的库的关键。在你还记得哪些对话线程重要时，从聊天记录中提取出这些原因。

明确决定你的同步策略

要么致力于彻底断开，要么致力于两者保留 —— 如果你保留两者，请记住 Lovable 一次只监视一个分支，并且它的 Knowledge 不会从你的 Cursor 工作中学习任何东西。半迁移的项目（没人知道哪个工具才是权威）往往会导致组件在手写修复的基础上被重新生成。

从 Lovable 到 Cursor 实际上并不是代码迁移 —— GitHub 双向同步处理了代码，但需要注意：一次只能同步一个分支、无法将现有仓库导入 Lovable，以及断开连接后无法重新连接仓库。迁移的核心是你的 Knowledge：应用于每条消息的两个 10,000 字符层级，它们需要变成用于工作区级规范的 User Rules，以及用于项目特定规范的作用域 .cursor/rules，外加为每个只存在于聊天线程中的决策准备的带日期的文档。

值得深思熟虑的选择是，这些知识此后存放在哪里。在 Cursor 的规则中，它在这个编辑器中为这个仓库服务，并在下次切换工具时需要再次转换。在两个工具都能读取的图层中，它在两者中都保持最新 —— 这在人们实际面临的情况下最为重要，即 Lovable 和 Cursor 仍然同时打开。