如何给你 AI 做的应用做备份 —— 以及你为什么真的需要

我认识的一位创业者，把他整个预约生意 —— 三个门店、每周大约 200 位客户 —— 都跑在一个他用 AI 应用构建器亲手做出来的应用上。一个周二他给我看了它，特别自豪。到了周三，他略带紧张地问我：“要是这玩意儿坏了，我是不是就……什么都没了？”

诚实的回答是：也许吧。看你说的”坏了”是什么意思。看他有什么样的备份（他一个都没有）。看他能不能及时把它重建出来。

那场对话，是我和那些用 AI 做过应用的人最常有的一场对话。做出来这件事本身，感觉像个小小的奇迹。而”万一它消失了会怎样”这个问题，几乎总是要等到这个应用已经在干真活儿之后才会冒出来 —— 可到那时候，弄丢它的后果已经变得严重了。

这篇文章写给任何一个 —— 没靠自己写代码就做出了一个真实可用的应用、如今又靠它来做某件要紧事 —— 的人。我们会讲清楚：到底什么有风险、该备份什么、多久备一次，以及出了岔子该怎么办。它不技术。没有脚本要跑。目标只有一个：确保不管你做出了什么，你都不会因为没人告诉过你”备份是个正经事”而把它弄丢。

你 AI 做的应用里到底装着什么（以及什么可能消失）

一个 AI 做的应用，是由两样截然不同的东西构成的，你得用不同的方式去分别备份它们。

第一样是应用本身 —— 那些界面、逻辑、设计、集成。这是你的 AI 构建器为你生成的东西。它存在于你 AI 构建器的账户里，通常装在某个项目内。如果你弄丢了那个账户的访问权限、或者构建器出了故障、又或者项目损坏了，你就丢掉了这一样。

第二样是你的数据 —— 用户、订单、消息、预约、人们上传的文件。它通常存在某处的一个数据库里。有时它在 AI 构建器内部。有时它在 Supabase、Firebase 或 Airtable 这样的服务里。有时它散落在好几个地方。

这两样东西的风险特性完全不同。应用结构只在你让 AI 去改它时才变。而你的数据，每次有用户做点什么时都在变。所以它们需要不同的备份策略。

有个好用的思路是：如果一栋楼烧掉了，应用是图纸，数据是楼烧掉时里面装着的东西。你能照着图纸重建。但你拿不回里面那些东西了。

哪些有风险：四种真实会发生的情况

下面每一种，我都见过它发生在用 AI 应用构建器的人身上。没有一个是纸上谈兵。

**1. 你不小心让 AI 把应用弄坏了。**你累了，在深更半夜干活，你说”把用户注册页面删掉”，因为你想重新设计它。AI 照做了。它顺手也删掉了让现有用户登录的那部分。现在没人能用这个应用了，而 AI 上一个能用的版本也没了 —— 除非你打开了版本历史（很多构建器默认是不开的）。

**2. AI 构建器出了故障或数据问题。**罕见，但真实。2024 年，一个热门的无代码平台发生过一次 6 小时的故障，客户数据无法访问。没人永久丢失数据，但很多生意丢了一整天。如果你的预约应用在一个周六早上宕机，而你的客户正想约周六下午的服务，那可不是”没有数据损失” —— 那是你再也找不回来的、白白损失的收入。

**3. 你的账户被锁了。**也许是个账单问题，也许是某个新地点的登录被标记了，也许是一次没生效的邮箱变更。应用好好的，数据也好好的，可你就是进不去。如果你没有一份导出的副本，那你就只能听天由命，看客服多久才回应了。

**4. 你离开了这个平台。**这一种是人们不会去预备的。一年之后，你可能想换一个不同的工具，或者请一名开发者来接手你做出来的东西。如果你应用和数据的唯一一份副本就存在一个构建器里面，那你的选择就既窄又贵。

在上面每一种情况里，“烦人”和”灾难”之间的区别，就在于你有没有备份。

该备份什么，以及多久备一次

你不需要一套花哨的系统。你需要的是一个习惯。下面是我给一个不写代码、用 AI 做东西的人推荐的最低限度。

你的数据 —— 每天，尽可能自动化。

如果你的数据存在 Supabase 或 Airtable 这类东西里，两者都提供定时导出或备份。把它打开。大多数人会跳过这步，因为它就三下点击，他们寻思着以后再弄。上线那天就把它做了。

如果你的数据存在 AI 构建器内部、又没有自动导出，那就设个日历提醒，每个周日手动导出一次。按表导出成 CSV。把它存到构建器之外的某个地方 —— Google Drive、Dropbox、一块移动硬盘。任何不是同一个服务的地方都行。

至少保留四个星期的这些导出。别每次都覆盖同一个文件。如果你的数据周二就坏了、你到周五才发现，那你可不想让你唯一的备份是周五那份已经坏掉的数据。

你的应用结构 —— 每次做出重大改动时。

大多数 AI 应用构建器都有某种形式的版本历史或快照。找到这个功能。用它。在你对应用做大改动之前 —— 这里的”大”是指”那种你没法在一小时内凭记忆重做出来的东西” —— 拍一个命名的快照。给它起个有用的名字，比如”加支付页面之前”或”改用户角色之前”。

如果你的构建器没有快照功能，那就让 AI 用一份长文档把应用做的事总结出来。把那份文档存好。它不是应用的真正备份，但它是一份配方 —— 万一最糟的情况发生了，你可以拿那份文档当提示词去重建。

你的账户和凭证 —— 一次，就在上线那天。

把每样东西都在哪里，写在一个地方。哪个构建器账户里有应用。哪个数据库服务里有数据。哪个邮箱是管理员登录账号。接的是哪个支付处理商。接了哪些集成。

把这些存进一个密码管理器，而不是一个 Google 文档。万一你明天被车撞了，你的生意伙伴得能找到所有这些。如果你是个单打独斗的创始人，那你未来的自己（六个月后，筋疲力尽，努力回想上线时都干了什么）也得能找到这些。

你的文件 —— 不管你的用户上传到哪里。

如果你的应用接受文件上传 —— 图片、PDF，什么都算 —— 那些文件就存在某处。找到它在哪儿。大多数构建器用的是某种存储桶。查一下它有没有被备份。如果没有，就设一个周期性的复制，把它复制到你自己的存储里。

一套每周大约 20 分钟的简单备份流程

周日晚上，反正你也没在工作的时候：

打开你的 AI 构建器。给当前的应用状态拍一个命名的快照。标上日期。
把每个数据表导出成 CSV。把它们丢进你云存储里一个带日期的文件夹。（大多数数据就存在 3 到 10 个表里 —— 不是个大工程。）
瞄一眼你的存储桶。确认没什么怪事在发生（文件数量暴增、可疑的上传）。
如果这周有什么变动，更新一下你那份”每样东西都在哪里”的文档。

就这些。二十分钟，一周一次。相对于它所保护的东西而言，这是一份分量大得离谱的保险。

如果你不想手动做这些，那就看看你的数据是不是存在某个自带备份的地方。比方说，Supabase 就能替你做每天自动备份。如果你用的是它的免费档，那些备份是有限的；上了付费方案，它们能往回保留得更久。对一个靠应用吃饭的生意来说，那个付费方案是你这辈子能买到的最便宜的保险。

出了岔子该怎么办

如果你的应用因为一个 AI 构建器的 bug、或者一次糟糕的改动而坏了：

**别慌乱地发提示词。**本能会让你立刻去让 AI 修它。忍住，憋十分钟。一个朝错误方向去的慌乱修补会让事情更糟，而且大多数构建器不会轻易撤销一连串的提示词。
**回滚到你上一个快照。**如果你有的话。这正是你当初拍它的全部理由。
如果你没有快照，那就让 AI 构建器撤销上一处具体的改动。说得精确点。“撤销我们删掉注册页面那次改动”，胜过”让它重新能用”。

如果你的数据坏了：

**立刻停止写入。**能下线就把应用下线。数据坏着的时候，每一次新的用户操作，都是你以后要去对账的更多数据。
**从你最近一份没问题的备份恢复。**如果你不知道哪份没问题，那就一次恢复一份到你环境的一个副本里，直到找到最后一个干净的版本。
**把缺失的部分对上账。**如果你周五恢复了周日的备份，那你就丢了五天的活动。给受影响的用户发邮件，请他们重做一遍做过的事，并道个歉。只要你诚实又迅速，人们的理解程度会让你意外。

如果你弄丢了账户的访问权限：

**立刻联系客服。**别想着”熬一熬就过去了”。构建器的客服队列各不相同；有的很棒，有的很慢。
**把你的身份信息备好。**最初的注册邮箱、账单卡的详情、你注册的日期、任何旧的发票。没有这些，账户找回会很难。

没人告诉那位创始人的事

我开头说的那位做预约生意的创始人，跟我聊过之后给他的数据服务买了个付费方案。他设好了每天自动备份。他给应用拍了个快照。他把所有账户都写进了一个密码管理器。整件事花了他一个周日大约一小时。

一个月后，一次他要求的 AI 改动，不小心弄坏了他的循环预约逻辑。客户看不到自己的下一次预约了。他在二十分钟内就注意到了。他两下点击就恢复了快照。他保住了数据，保住了应用，他的客户什么异常都没看到。

他后来跟我说，那是他花过的最便宜的一小时。他没说错。给一个 AI 做的应用做备份，无非是大约一小时的设置，加上每周二十分钟的习惯。而它所防范的，正是那件每一个弄丢过它的人都从没想过会落到自己头上的事。

如果你做出了什么真实的东西，今天就拍个快照。