Bubble 到代码迁移：何时、为何以及所需费用

一份为离开 Bubble 的团队准备的指南，围绕 Claude Code 和 Codex 构建。这份指南适用于那些在 Bubble 上建立了业务，并开始感受到平台局限性的创始人及 CEO。

TLDR

迁移首先是一个商业决策，其次才是一个技术决策。一个拥有付费客户和工作流的真实 Bubble 应用，需要几个月才能妥善重建。完成此项工作的团队表示，每个应用需要三到五个月，而且这个估计没有虚报。

预算方面，根据功能和数据复杂性，大多数团队的完整重建成本在 1.5 万到 2.5 万美元之间。如果你倾向于自己动手，那成本就是团队的时间而非现金。

迁移的好处是，你拥有代码，应用运行速度更快，并且以 Bubble 应用无法实现的方式获得融资和被收购的潜力。你所承担的是 Bubble 曾为你默默完成的工作，例如安全补丁、备份和正常运行时间，这些现在都由你负责。

但有了 Claude Code 和 Codex，一个规模小得多的团队就能重建过去需要一个完整团队六个月才能完成的工作。

你应该从 Bubble 迁移到自定义代码吗？

Bubble 在很多方面表现出色。它可以在没有开发团队的情况下，将你的想法呈现在付费用户面前，但它有其上限，而且有一些迹象表明你已经触及了上限。

• 随着用户增长，应用性能下降
• 微小的改动可能会破坏你未触及的部分
• 你需要 Bubble 无法实现的功能，例如繁重的后台处理
• 你的团队将三分之一到一半的时间用于修复 bug，而不是改进功能
• 工作负载单元成本不断增加，并且随着使用量的扩大而恶化，而非改善

但人们在这里犯的错误是，将迁移视为全有或全无。事实并非如此。

在完全重建你的 Bubble 应用之前，你有几个选择。你可以只重建实际出现问题的部分，其余部分保留在 Bubble 上。

我们的一位客户有一个管理良好的 Bubble 应用，需要一个 WebSocket 服务来管理连接的冰箱群。我们没有建议进行全面迁移。

他们只需要一个自定义后端组件，将硬件连接到现有应用。其他一切都保留在 Bubble 中。

在开始迁移你的 Bubble 应用之前，这种判断是值得做出的。我们会在团队决定重建之前，帮助他们进行迁移审计。如果你在决定迁移之前，还在评估AI智能体是否适合你的流程，可以先了解一下AI智能体究竟是什么。

如果 Bubble 有一项功能无法实现，你仍然可以用代码构建该功能，而其他一切都使用 Bubble。

如果性能和成本造成问题，但应用仍在运行，则分阶段规划全面重建。

如果你在所有方面都触及了上限，例如融资，或者你想拥有源代码，则规划全面迁移。

然而，如果你仍在寻找产品市场契合点，或者应用每周都在变化，请继续使用 Bubble。现在迁移为时过早。

自定义代码能给你 Bubble 无法提供的东西

一个常见的错误是将此举框定为摆脱 Bubble 问题的途径。这是正确的，但不够完整。

实时功能 (WebSockets)

你可以创建实时仪表板、协作编辑和即时通知。用户无需刷新页面即可立即看到更新，使应用程序感觉响应迅速且现代化。

直接访问 AI/ML 模型

你可以将 AI 模型直接集成到你的产品中，而不是依赖受限制的第三方插件。这让你完全控制模型的选择、性能、功能和成本。

真正的原生移动应用

构建具有原生性能、设备集成和精致用户体验的真正 iOS 和 Android 应用程序，而不是创建封装的 Web 应用。

后台处理

你可以在后台可靠地运行长时间运行和计算密集型任务，而不受使用配额的限制。

亚秒级性能优化

你可以优化数据库查询、缓存和应用程序架构，以改善用户体验。

完全的基础设施控制

选择你的云提供商、部署策略和扩展方法，同时满足你的安全、合规性和成本要求。

无按操作计费

通过支付你使用的基础设施费用来保持成本可预测，而不是为每次工作流执行或用户操作付费。

Bubble 与代码中如何实现相同功能

添加表和字段

Bubble： 在“数据”选项卡中创建数据类型并添加字段。

代码： 定义数据库 schema，由 AI 代理生成迁移。

搜索或查询数据

Bubble： 使用“Do a search for”并添加约束。

代码： 使用 SQL 或 ORM 编写查询，由 AI 代理生成大部分实现。

业务规则和工作流

Bubble： 通过将操作拖放到工作流画布上构建工作流。

代码： 定义响应事件运行的函数，由 AI 代理实现逻辑。

条件逻辑

Bubble： 为操作添加“Only when”条件。

代码： 使用标准的 if 语句和其他编程结构。

用户认证

Bubble： 认证内置且开箱即用。

代码： 选择一个认证提供商并将其集成到你的应用程序中。

文件上传

Bubble： 文件自动上传和存储。

代码： 配置对象存储并自行实现上传流程。

第三方 API 集成

Bubble： 使用 API 连接器连接 API，无需编写代码。

代码： 直接进行 API 调用，让你完全控制请求、认证和错误处理。

电子邮件发送

Bubble： 使用内置操作或插件。

代码： 集成电子邮件服务并配置可送达性设置，例如 SPF 和 DKIM。

定时任务

Bubble： 使用“Schedule API Workflow”。

代码： 使用 cron 作业或后台工作器运行定时任务。

访问控制

Bubble： 配置隐私规则。

代码： 实现行级安全和服务器端授权。

部署更改

Bubble： 点击预览或部署。

代码： 将更改提交到 Git，让 CI 运行测试，并通过发布管道部署。

调试

Bubble： 使用调试器逐步执行工作流。

代码： 检查日志、运行自动化测试并在本地重现问题。

版本控制

Bubble： 依赖 Bubble 的保存点和版本历史记录。

代码： 使用 Git 进行完整的版本历史记录、分支、代码审查和可靠的回滚。

Bubble 迁移失败的原因

Bubble 迁移中几乎所有代价高昂的错误都源于思维模式的必要转变。

可视化工作流变为代码

在 Bubble 中，你拖动工作流步骤。在代码中，逻辑存在于响应事件（用户点击、API 触发或计时器启动）运行的函数中。

逻辑是相同的。“我在哪里看到它”则完全不同，这是第一个让人困惑的地方。

你的 Bubble 数据库变为真正的数据库

Bubble 的数据类型变为表。字段变为列。

你现在需要创建规则。一个应该包含数字的字段将拒绝文本。Bubble 很容易。Postgres 则不然，严格性既是其特点，也是迁移过程中许多错误发生的地方。

隐私规则变为你需要构建的东西

在 Bubble 中，隐私规则决定了谁可以看到什么。在自定义代码中，除非你编写保护措施，否则没有任何东西受到保护。新应用的默认状态是开放的。你在 Bubble 中拥有的每条规则都必须重建。如果你跳过这一步，你将容易遭受数据泄露。

你需要不同的服务来处理前端和后端

Bubble 将前端、后端、数据库和托管捆绑在一个编辑器中。使用自定义代码，这些都是独立的服务。这听起来需要管理更多，确实如此，但这也正是让两个 AI 代理能够同时处理不同部分的原因。

插件变为包和 API

你一键安装的 Bubble 插件变为你直接调用的库或 API。这意味着更多的控制和更高的可靠性，但设置稍微复杂一些。

准备你的 Bubble 应用迁移

Bubble 中没有“一键应用迁移”按钮。你无法导出你的 HTML 或工作流。你可以导出的是你的数据，即使这也有一些挑战。

“数据”选项卡允许你将每种数据类型下载为 CSV。因为你拥有编辑器访问权限，这绕过了隐私规则，所以你可以看到所有内容。

数据 API 每次请求返回 100 条记录，这意味着你需要基于游标的分页来获取所有内容。

然后是文件和图片问题。当你导出 CSV 时，你的文件和图片不在其中。其中包含的是指向 Bubble 托管这些文件的 URL。如果你在不传输文件的情况下进行迁移，这些 URL 将失效，资产也将丢失。

工作流和 UI 必须从头创建，因为你的任何逻辑都无法导出。有人必须记录每个工作流的功能。

这很繁琐，你将在这里花费大量时间。但你正在生成的文件是你的规范。这正是 AI 代理将据此构建的内容。

现在就审计你的隐私规则，在你失去访问权限之前。记录下每一条，因为它定义了你的整个授权模型。如果它不完整，你的新应用将缺少你不知道自己拥有的安全规则。

媒体和文件托管

每当用户将个人资料照片或 PDF 上传到你的 Bubble 应用时，Bubble 都会将其存储在 AWS 中并返回一个 URL。在自定义代码中，你选择 S3 或 Cloudflare R2，并且必须为此创建管道。

迁移本身有一个特定的操作顺序，如果操作不当将导致永久性数据丢失。

首先，导出你的数据，记住你得到的是 URL，而不是文件。然后运行一个脚本，从每个 URL 下载每个文件，直到 Bubble 托管服务消失。然后将所有内容重新上传到你的新存储中。最后，重写数据库中存储的每个 URL，使其指向新位置。

1. 1 导出数据（URL，非文件） →
2. 2 下载每个文件 →
3. 3 重新上传到新存储 →
4. 4 重写存储的 URL

一些 Bubble URL 是签名的且会过期，因此你必须决定哪些文件是公开的，哪些是私有的。Bubble 曾使用 CDN 在全球范围内快速提供文件，同时强制执行文件大小和访问规则。所有这些现在都由你来设置。

这些单独来看都不难。问题是，直到用户报告他们的文件丢失时，你才意识到这些问题的存在。

数据清理

从未迁移过应用程序的人不会认为这是一个重大挑战。

Bubble 的数据库很简单。字段可能在不应该为空时为空。一个字段可能在 9,000 条记录中保存数字，而在其他 12 条记录中保存文本。事物之间的关系通过引用存储，并在多年的实际使用中逐渐不同步。这些在 Bubble 中都没有引起明显问题，因为 Bubble 不强制严格性。

然后你迁移到 Supabase 或 Xano，导入失败。因为你的数据违反了规则。

在需要值的地方出现空值。指向已删除记录的孤立引用。在应该唯一的字段中出现重复的电子邮件。日期以三种不同的格式存储。

你的选项集导出为 ID 或显示文本，而不是外键，这使得将它们链接到正确的关联数据变得困难。

Bubble 会将链接的“事物”导出为引用 ID，而不是你在编辑器中看到的易读关系，重建所有连接方式需要大量工作。

你花在清理、去重和协调导出的 Bubble 数据上的时间，总是会超过编写导入本身的时间。

处理用户认证和迁移账户

Bubble 不会让你导出用户的密码哈希。这些很难提取是件好事。但这意味你不能简单地将用户的密码移动到新系统，然后让每个人都像什么都没发生一样登录。

第一个解决方案是强制重置密码。所有人都一次性迁移。在切换时，每个用户都必须重置密码，你通过电子邮件向他们发送重置链接。好处是干净、简单、一次性切换。对于我们帮助迁移的公司，我们选择一个流量较低的时段，例如周末。

第二个是渐进式迁移。你将新旧认证系统并存。每个用户在切换后第一次登录时，新系统会一次性检查他们在旧 Bubble 系统中的凭据，然后存储密码。从那时起，他们就完全迁移了。

对于大多数用户少于几千的应用程序，强制重置更简单，并且值得付出小小的摩擦。当强制重置会让你失去用户或停机时间成本高昂时，才使用渐进式方法。

除了密码，你还需要迁移用户的其他所有信息。个人资料、角色、权限，所有这些都作为数据迁移。

还有一些事情需要计划：所有活动会话在切换时都会失效，所以每个人都会被登出一次；Google 等社交登录必须重新链接；任何多因素设置都必须重新注册。

你可以选择像 Auth0 或 Clerk 这样的托管认证提供商，他们会为你处理困难的部分并收取费用，或者选择一个你自己运行的认证库，拥有更多的控制权和责任。

我总是建议支付托管提供商的费用，除非你有特殊原因不这样做。认证是那些稍微出错成本就非常高的领域之一。

数据安全

在 Bubble 中，安全大多在你是否考虑过它时都会发生。在代码中，你的应用程序的默认状态是不受保护的，每一层安全都是你刻意添加的。

每个 Bubble 隐私规则都必须重建为真实的服务器端逻辑，通常在数据库中具有行级安全性。

秘密管理是下一步。API 密钥等秘密应存储在服务器端环境变量中。

当你构建的框架发布安全更新时，由你来应用它。Bubble 在后台为你完成了这项工作。除此之外，你现在还拥有传输中和静态数据的加密，这主要由良好的默认设置和你的托管选择处理，但现在你有责任确认而不是假设，以及输入验证，因为你自己的 API 端点暴露给世界，必须防御不良输入。

数据安全是为什么独自完成，没有经验丰富的人帮助，可能会悄悄地、代价高昂地出错的原因之一。

Bubble 曾为你默默完成的工作

现在应该很清楚，Bubble 为你做了很多事情。但只要你知道自己需要做什么，你也可以自己完成同样的事情。

列出它们的原因不是为了吓跑你。而是为了让你能计划“我们需要设置备份”这样的事情。

选择技术栈

你可以选择 React、Next.js 或任何其他前端框架。所有 AI 代理都了解所有框架。

有了 AI 代理编写大部分代码，给定技术栈选择的成本比以前低了。尽管 LLM 倾向于并擅长 React 和 Next.js。

首先迁移什么

你应该始终专注于后端。你的数据库、认证和核心 API 是所有一切的基础。

首先构建它们可以让你确认数据完好无损。如果我必须为此推荐一个 LLM，请选择 Codex。它擅长后端和数据密集型操作。

首先关注前端在 UI 是问题所在时有效，你可以将新的前端连接到 Bubble 现有的数据 API。你可以模块化地替换应用程序，同时 Bubble 作为后端。

我建议模块化地进行迁移。选择一个模块，并从上到下完整地构建它，包括数据库、API 和 UI。

这样，你将在事情出错之前（因为它们会出错）学到很多东西，而不是在承诺迁移所有内容之后。

无论你选择哪种方式，都应以相同的逻辑选择你的第一个模块：最低依赖性。

在开始之前，绘制出哪些其他模块依赖于它。将最相互关联的模块留到基础稳固之后。

首先跳入最困难的任务会给你带来麻烦。

构建前端和设计系统

如果你在没有系统的情况下开始构建页面，你就会得到每个人都认为是 AI 生成的应用程序。

解决方案是设计系统。这意味着你的颜色、间距和排版。然后，组件由这些令牌构建，例如按钮、卡片和输入框。接着，页面由组件组装而成。

如果你按这个顺序构建，一致性是自动的。但如果你先构建页面，你的应用程序将永远不会看起来一致。

如果你在 Figma 中有设计稿，你可以将 Figma 直接连接到 Claude Code 和 Codex，让代理构建 UI。

在前端方面，Claude 比 Codex 更好。让代理使用 Playwright 截取它构建的屏幕截图，并进行审查。这大大改善了 UI 的输出。

摆脱默认外观主要取决于经验，而不是接受 AI 代理构建的第一个东西。这就是拥有良好品味的人与“看起来像模板”和“看起来像产品”之间的区别。

构建后端和逻辑

后端构建主要是将你之前生成的文档进行翻译。每个 Bubble 工作流现在都将是一个 API 端点。

首先，重新实现隐私规则。你之前审计的每条规则都将成为服务器端逻辑和数据库中的行级安全性。不要让代理向你保证它“添加了安全性”。验证你的审计中的每条特定规则都存在并有效。代理有时会声称某些东西正在运行，但实际上并非如此。

其次，开始数据迁移。将清理后的数据导入新 schema，运行文件重新托管过程，然后验证记录计数是否匹配。计算旧系统中的记录，计算新系统中的记录，并确认它们匹配。

最后，移动定时和后台工作。Bubble 的定时 API 工作流应转换为 cron 作业或队列工作器。

设置 LLM 代理可以工作的代码库

你可能会使用 Claude Code 或 Codex 来帮助迁移。如果不是，我强烈建议你这样做，并且你需要做一些事情来确保代理有效。

CLAUDE.md 是一个文件，你可以在其中为 Claude Code 编写指令和规则。它作为指南，告诉 Claude 你的项目如何运作，要遵循哪些编码标准，以及你希望它记住你对偏好的哪些信息。

它在每个会话开始时加载，并帮助 Claude 对你的代码做出更好的决策。将特定领域的规则拆分到单独的文件中，仅在相关时加载。

然后，构建仓库，使前端和后端分离，因为这将使并行代理成为可能。如果边界清晰，两个代理可以协同工作而不会相互干扰。

你之前创建的文档现在成为你的产品需求，分解成小的、完整的垂直切片。

从第一天起就使用 Git。它将帮助你创建分支和提交，并保留完整的历史记录。这是你的安全网。当代理做出你不喜欢的更改时，Git 是你干净地撤销它的方式。

LLM 每天都在改进，但它们仍然会犯错误。如果没有版本控制，你将使你的整个项目面临风险。

Claude Code 擅长前端和 UI 工作。Codex 擅长后端密集型、数据库工作。因此，最简单的划分是沿着前端-后端任务进行。

并使用一个代理（Claude 或 Codex）进行构建，然后让另一个代理对结果进行对抗性审查。Codex 的审查模式在这方面表现出色。一个代理编写，另一个代理审查，你将获得比任何一个单独代理都能产生的更好的代码。

保持上下文分离。不要给两个代理相同的信息。将每个代理专注于其特定领域以提高性能。后端代理不需要知道你的 CSS 规则。

你可以使用一个分成多个窗格的终端（使用 tmux 或 zellij），或者通过将每个代理指向一个单独的目录，或者使用 git worktrees 来同时运行两个代理，这让代理可以在没有合并冲突的情况下工作。

保持共享任务列表并明确标记依赖关系，这样就不会有一个代理开始依赖于另一个代理尚未完成的工作。不断检查 git 状态。在提交更改之前进行审查。并且绝不允许两个代理同时编辑相同的文件。

如果任务定义不明确，质量就会下降。如果你给代理不明确的任务，它们可能会承担重叠的角色，最终创建出无法很好协同工作的部分。因此，始终给出具体且明确定义的任务。

添加质量门

你需要一个安全网，它能为 LLM 代理所做的每一次更改运行，而无需任何人记住触发它。这就是这些门的作用。

预提交钩子会在任何代码提交之前自动运行。格式化程序、linter、秘密扫描器（以防止 API 密钥意外提交）和基本测试。

你可以自动化正确性检查，使其在代码到达审查之前发生。Linting 和格式化配置为代理提供了一致的风格，即使不同的代理编写了不同的部分，也能保持代码库的可读性。

持续集成确保你的代码通过确保其可执行性来满足“完成”的定义。如果测试必须在部署前通过，那么“在我的机器上可以工作”的问题就被消除了，因为 CI 每次都会运行相同的检查。

在将代理的输出推送到产品之前，务必进行测试。审查比你自己重新运行所有内容更快，即使是你没有观看的会话也有效。更好的是，让第二个具有全新上下文的代理尝试找出第一个代理工作中的漏洞。完成工作的代理不应该是评估它的人。

AI 代理失败的地方

每个人都在炒作 AI 编码。它们擅长快速生成代码、处理多个文件、处理明确定义的任务以及遵循清晰的约定。将它们用于所有这些方面。但不要依赖它们来处理业务逻辑。

它们可能会出现一些容易被忽视的小错误，并且设计不佳的测试可能无法识别它们。它们还倾向于声称已采取保护措施，例如声称已添加授权规则但实际上没有，或者声称存在隐私规则但实际上没有。

如果你不审查并分享反馈，它们会更喜欢使用方便的库，而不是正确的库，因为 AI 代理会优化完成任务，而不是选择最佳的长期方案。

AI 代理可以帮助你迁移 Bubble 应用。它们不能取代了解什么是正确的。一个了解“正确”是什么样子的团队工作效率会快得多。一个不了解的团队很快就会得到一个损坏、不可靠的应用程序。

很多人会告诉你此时只需雇佣一家代理机构。我只想说，快速的 AI 代理与知道何时出现问题之间的差距，正是经验丰富的帮助能带来回报的原因。无论是我们还是其他人，都不要让代理来评估自己的工作。

发布后由谁维护？

一旦你完成迁移，你现在就需要维护它。你可以雇佣一名工程师，保留构建它的代理机构，或者如果产品简单，可以使用 Claude 或 Codex。这些都可以。

运行 Bubble 应用与代码的成本

你以前的 Bubble 账单很简单。Bubble 套餐，加上使用量激增时的工作负载单元超额费用。但现在你的新账单多了几个供应商。托管、数据库、文件对象存储、认证提供商、电子邮件服务、监控和域名。

起初，你的成本会上升。但随着你的应用程序的增长，它会比 Bubble 更便宜，特别是对于高使用量的应用程序。回报不仅仅是更低的月度成本。你最终会得到一个更快的应用程序和一个你完全拥有的资产。

从 Bubble 迁移失败的原因

这份清单在其中一个问题发生在你身上之前，可能会觉得有些多余。

• 相信 Bubble 有一键导出到代码的功能。没有，围绕这个计划会浪费数周时间。
• 忘记导出的文件只是 URL，并在 Bubble 托管失效时丢失所有资产。
• 在一个请求中通过数据 API 拉取一个大表，并默默地只获得 100 条记录。
• 试图迁移无法导出的密码哈希，而不是计划重置或渐进式策略。
• 未重新实现隐私规则，导致新应用程序的数据完全暴露。
• 将所有内容塞进一个巨大的 CLAUDE.md 文件。
• 给代理模糊的提示，例如“构建一个仪表板”。
• 让代理一次性进行大型、多文件重写。进行小改动。
• 两个代理同时编辑相同的文件。
• 相信代理说某个功能有效，而不是自己检查。
• 没有花一周时间进行数据清理。
• 忘记你现在拥有备份、补丁和正常运行时间。
• 在没有回滚计划的情况下进行切换。