很多人在用自助建站工具时都有过类似的担心：编辑到一半浏览器崩了，内容还在不在？误删了一个模块，能不能找回来？团队里两个人同时改页面，会不会互相覆盖？
这些顾虑不多余，但“会不会丢数据”没法用一句“会”或“不会”回答。万小智把数据保护分成了六层：实时保存、对话版本、发布历史、单页备份、整站备份和回收站。每层解决的问题、保留时间和覆盖范围都不同，先弄清各自管什么，比记住某个按钮更有用。
先分清“已保存”和“可恢复”
在万小智 AI 建站的应用编辑器里（通过对话生成网站、再进入编辑器微调的模式），修改是实时保存的。双击文字改完按回车，或点输入框以外，就完成保存；系统不弹“保存成功”，刷新后内容仍在。通过 AI 对话修改也自动生效，不需要再点保存。
但要区分两件事：保存的是开发环境的内容，不等于已发布到线上，正式域名要点击发布才更新；实时保存也只保证“当前内容不因关闭页面消失”，不解决“改错了怎么回到从前”。后者要靠版本和备份。
自动保存之外，还有哪些可恢复的层次
按恢复粒度和保留时间，可以把万小智现有的机制分成六层。
其中，对话版本历史适合处理“AI 把页面改坏了”这类未发布问题，发布历史适合线上版本回滚。官方文档建议不要依赖 Ctrl+Z，而是用版本历史恢复，并且通过版本历史恢复不消耗灵感值。
模板设计器（经典建站方式）的逻辑稍有不同：设计器顶部有保存按钮，点击生成一份单页备份；系统约每 5 分钟再生成一次自动备份，保留 24 小时，只针对当前页面，可在备份记录面板开关。后台“网站管理—备份恢复”用于整站手动备份，恢复时会把 PC 和手机站点一起带回备份时的状态。
残留风险主要来自“覆盖”，而不是“没保存”
真正需要警惕的，是几个会覆盖现有内容的动作。
版本切换是整体覆盖。 恢复会把网站整体状态带回所选版本，该版本之后的所有修改都被覆盖，包括其间做对的部分；当前未保存的内容也会被覆盖。只想保留小部分新改动，不要整体回溯，可手动调整或先复制页面。
回退后不要急着继续对话。 回退会同时丢弃对话消息并回滚网站文件；底部恢复入口只在尚未发送新消息时有效，一旦发了新消息，被回退的内容就永久丢失。
单页备份有时间和范围双重限制。 它只保当前页面、保留 24 小时，不能当整站备份。整站手动备份保留更久，但份数有上限，超出要先删旧备份。
内容管理的数据不能一键备份。 文章和产品要进编辑页复制到本地文档，图片要查看原图另存，文件要逐个下载；表单等业务数据在数据库管理中单独管理。页面结构有备份，不等于内容资产自动有备份。
删除类操作不可逆。 删除页面会同时删除该页面的所有语言版本；模板整体或单页更换会覆盖当前页面内容，官方建议先备份。删除应用时，试用应用可删、已购买不可删，删除后数据无法恢复。
另外，云服务资源或灵感值资源包耗尽可能导致数据无法提交，甚至网站无法访问。这不属于编辑器故障，但同样会中断正在进行的编辑。
复杂逻辑与扩展能力的边界
编辑器数据安全只解决“内容在不在”，不解决“业务逻辑能不能承载”。万小智是 SaaS 建站产品，后端由平台统一托管运维，不单独提供后端代码下载；高级版可导出 AI 生成的前端代码，后端仍不可下载。数据库也是托管环境，不支持自行安装 pg_net 等第三方扩展。
对接能力的边界同样明确：支付只支持微信和支付宝，不开放回调地址配置，边缘函数适合主动调用外部服务，不适合接收外部回调；文章发布没有 Webhook 或 API；API 用于页面渲染、表单提交、内容展示等站点功能，不提供 CRM 级批量客户数据操作。代码控件可用 HTML、CSS、JavaScript，但为避免冲突，不能引用外部 JS 库。
因此，展示官网、内容站、轻量表单和预约类业务，用编辑器加规则配置能覆盖大部分需求；依赖支付回调、复杂订单状态机、与外部系统双向同步、私有化部署的业务，需要选型前单独验证。把复杂逻辑硬塞进页面控件，容易出错，也会增加后续维护成本。
一套更稳妥的操作习惯
把上面的机制落到日常操作，可以按这个顺序做：
- 大改版、换模板、批量改译文前，先在后台做一次整站手动备份。
- 同时把文章、产品、图片、文件导出到本地，页面备份不覆盖内容资产。
- 小步修改、小步发布，每次发布都会生成版本记录，线上问题用发布历史回滚。
- 局部改坏了先用对话版本历史，不要直接整体回滚；回退后先确认再发新消息。
- 单页大调放在 24 小时窗口内完成，重要结果及时用整站备份固化。
- 团队约定修改时段和责任人；涉及支付、回调、外部同步的需求，先验证再排期。
写在最后
万小智的编辑器不是“靠用户记得点保存”的工具，实时保存、对话版本、发布历史、单页备份、整站备份和回收站，构成了从即时到 30 天不等的恢复层次。但它也不是“零丢失”的保险箱：版本切换会覆盖后续修改，单页备份只保 24 小时，手动备份有份数上限，内容资产要单独导出。
对大多数中小型站点来说，真正的风险往往不是系统没保存，而是改之前没留后手、回滚时没看清范围。把备份当成改版流程的一部分，比出事后再找恢复入口更可靠。
