# 2026 年如何备份抽认卡：Anki 备份、Quizlet 导出，以及真正属于你的卡组

*2026-06-15*

一副抽认卡卡组，在你还没试过重建它之前，看起来总是没多大。

可一旦真要重建，它突然就成了 1,800 张卡、两年的复习记录、一堆截图，再加上一个你原本根本没打算拿来清理导出文件的烦人周末。

这也是为什么到了 2026 年，**备份抽认卡** 会成为一个很实际的搜索需求。人们去搜，不是因为“备份很负责任”听起来很正确，而是终于意识到，自己投入进去的大量学习时间，其实被困在了某一个应用里。

这篇指南只讲一件事：如果你现在用的是 Anki、偶尔依赖 Quizlet 导出，或者只是希望下一副卡组更容易真正归自己所有，怎样把卡片保留得可迁移、可阅读，也可恢复。

![温暖书桌上的抽认卡备份场景，摆着源笔记、媒体文件和笔记本电脑上的导出界面](/blog/how-to-back-up-flashcards.png)

## 为什么这件事在 2026 年显得更紧迫

**2026 年 2 月 2 日**，Anki 论坛发布了关于项目所有权交接的公告：[“Anki's Growing Up”](https://forums.ankiweb.net/t/ankis-growing-up/68610)。

这并不意味着你的卡组会在一夜之间变得不安全。但它确实提醒了很多人一个很有用的区别：信任一个工具，不等于真正拥有自己的学习数据。

Quizlet 这边也有类似的问题，只是没那么戏剧化。导出路径虽然还在，但比大多数人以为的要窄得多。如果你的卡组真的重要，可迁移性就不该等到“哪天要迁移了再说”。

## 同步有帮助。备份才能救你。

很多人说自己“已经备份了”，其实他们真正的意思只是：卡组会在不同设备之间同步。

这当然比没有强，但两者不是一回事。

同步保护的是便利。备份保护的是恢复能力。

如果一次错误编辑、一次损坏的导入，或者一次误删，被同步到了所有设备上，那你只是更快地把问题扩散了出去。

## 我自己真的会用的那套朴素备份方案

第一条真正有用的规则，就是别再找什么“唯一完美的备份格式”。

我会保留四层：

1. 一份应用原生的完整备份
2. 一份重要卡片内容的纯文本或 Markdown 副本
3. 一份媒体文件或原始资料文件的副本
4. 一份放在日常使用设备之外的第二存储位置

乍看有点过头，但只要其中一层失效、另外三层把卡组救回来时，你就不会再这么想了。

每一层都在覆盖不同的故障场景：

- 应用原生备份，方便你恢复卡组结构和复习状态
- 纯文本副本，让内容保持可迁移
- 媒体备份，保护文本格式里可能丢失的图片、音频和附件
- 第二存储位置，防止你因为丢了电脑、手机或本地硬盘而全盘失去数据

如果你只保留应用原生那一层，本质上是在赌这个产品永远都还能被读取。如果你只保留纯文本，就会失去复习状态，而且通常也会丢掉媒体。分层之所以有用，是因为每一层解决的问题根本不同。

## 对 Anki 来说，恢复副本和可迁移副本都要留

很多人的 Anki 备份方案，其实做到一半就停了。

[Anki 的备份文档](https://docs.ankiweb.net/backups.html) 对这个区分说得很清楚：

- 自动备份会包含卡片文本和排程信息
- 自动备份不包含声音或图片文件
- 手动导出的 `.colpkg`，如果勾选 `include media`，才会生成更完整的集合副本

[Anki 的导出文档](https://docs.ankiweb.net/exporting.html) 还补上了另一个关键点：collection package 会导出你的整个 collection，并保留排程信息。

所以我对 Anki 会保留三种习惯，而不是一种：

1. 让 Anki 的常规自动备份继续存在，作为快速恢复手段
2. 定期导出带媒体的 `.colpkg`，作为真正可恢复的还原点
3. 把重要笔记内容另行导出成纯文本，作为 Anki 之外的可迁移副本

第三步很重要，因为 Anki 备份非常擅长“恢复回 Anki”，却不太擅长让你日后用普通工具直接检查卡组内容。

还有一个细节值得直接说出来，因为很多人都是吃过亏才知道：更安全的做法，是先干净地导出，再把导出文件存起来。不是“把 Dropbox 对准正在使用的数据库，然后希望这也算 Anki 备份”。

## 对 Quizlet 来说，尽早导出，并且少做幻想

Quizlet 导出是有用的，但它不是你整个学习环境的完整克隆。

截至 **2026 年 6 月 15 日**，[Quizlet 的导出帮助页面](https://help.quizlet.com/hc/en-us/articles/360034345672-Exporting-your-sets) 说明你可以导出自己创建的卡组里的术语和定义。真正重要的是它的实际限制：

- 复制来的卡组不能导出
- 图片不能被导出
- 导出功能在网站上可用，不在 App 里

所以，只要某套 Quizlet 卡组真的重要，就该趁它还符合这些条件时尽早导出：

- 还是你自己的
- 内容主要还是文字
- 还容易识别
- 离原始资料还不算太远

不要等到某天晚上突然想迁移才开始。不要等到连哪些卡组是复制来的都忘了。也不要把截图当成什么像样的备份格式。

这也是为什么仓库里已经有一篇专门讲[如何导出 Quizlet 卡组并把它们整理成 FSRS 抽认卡](/zh/blog/how-to-export-quizlet-sets-and-turn-them-into-fsrs-flashcards/)的文章。导出这一步并不光鲜，但它决定了你以后到底有没有一条真实可走的退出路径。

## 纯文本，是最被低估的抽认卡备份

如果除了应用原生备份之外，我只能多留一份副本，那我几乎总会选纯文本或 Markdown。

它当然保不住一切。也正因为如此，它才有价值。它能让卡片内容继续活在今年恰好承载它的那个产品之外。

纯文本的“丑”，恰恰是它好的地方：

- 你可以在任何机器上打开它
- 不需要特殊工具就能检查它
- 可以很快搜索
- 可以做版本管理
- 以后可以送进新的导入路径
- 也可以直接交给别的工具，而不用靠屏幕抓取自己的学习内容

这一点现在尤其重要，因为很多卡组都来自笔记、转录、OCR、PDF，以及 AI 辅助清理流程。一旦真正有用的部分被保存成可读文本，你未来的选择就会多很多。

这也是为什么，清理完成之后，[Flashcards](/zh/features/) 会是一个合理的落点。当前产品支持基于纯文本和文件附件的 AI chat，所以整理好的导出内容，不必只是躺在那里当“死备份”。它可以直接变成更好卡组的草稿输入。

## 备份的不只是最终卡片，也包括原始资料

很多人只按“应用”来思考，于是就跳过了这个习惯。

如果你的学习材料来自：

- 你自己的 Markdown 笔记
- 从别的应用导出的纯文本
- 手写页面做出来的 OCR
- 转录片段
- 自己整理的词汇表
- 题库错题记录

那么这些原始文件本身，也属于备份的一部分。

有时候，从源材料重建，反而比恢复一副乱糟糟的旧卡组更容易。有时候卡组已经很臃肿了，但源笔记仍然是干净的。

有时候，你甚至不想把所有旧卡都拿回来。你想要的，是基于那些现在仍然重要的材料，重新做出一副更小也更好的卡组。

这就是为什么源文件备份也重要。它会在以后给你两个都很诚实的选择：要么恢复旧卡组，如果那样最省事；要么只重建其中真正值得保留的部分，如果那样更聪明。

## 很多备份方案，都是在媒体文件这里悄悄失效的

纯文本卡组是最简单的情况。真正的麻烦，往往出现在卡组依赖这些东西时：

- 解剖图片
- 图示截图
- 发音音频
- 白板照片
- 手写笔记裁切图
- 遮挡式图片学习材料

如果你的备份只保住了文字，却丢掉了这些文件，那你也许在技术上“保住了卡组”，但在实际使用上已经失去了真正要学的东西。

所以媒体文件需要它自己的检查点和文件夹，而不是一种“应该已经附在某个地方了吧”的模糊期待。

对 Anki 来说，这意味着当你想要一份真正可恢复的集合备份时，要走包含媒体的导出路径。对 Quizlet 来说，这意味着要早点接受它的导出限制，并把原始图片或原始资料单独存好。对你自己的 AI 辅助工作流来说，这意味着原始 PDF、截图批次、转录内容或笔记导出，也都该放在一个明确、好找的位置。

我宁愿有一个无聊但清晰的文件夹，名字就叫 `flashcards-sources-2026-06`，也不想在某个糟糕的晚上才发现，自己保存了提示词，却没保存图。

## 一个好的抽认卡备份，也会让迁移变容易

很多人会漏掉这一点。备份不只是为了灾难恢复。

它也是为了某一天，当你意识到“这个工作流已经长大到超出这个工具”时，迁移不会变成一场戏剧。

这也是为什么 Anki 所有权讨论会有意义。哪怕不是马上要离开的人，也开始重新思考可迁移性。这种本能是健康的。

如果你的资料已经被备份成：

- 一份完整卡组集合导出
- 一份可迁移的文本副本
- 一份保留下来的原始资料文件

那以后再迁移，冲击就会小很多。

无论你是从 Anki 迁、从 Quizlet 迁，还是从某个很擅长生成、却不擅长长期复习的 AI 学习工具迁，这都成立。

如果你现在主要卡在 Anki 这边，下一篇最实际的文章已经在这里：

- [2026 年如何从 Anki 迁移](/zh/blog/migrate-from-anki-txt-export-open-source-flashcards/)

如果你更关心的是“所有权”和“可检查性”，那接着看这篇会更合适：

- [适用于间隔重复的自托管开源抽认卡应用](/zh/blog/self-hosted-open-source-flashcards-app-for-spaced-repetition/)

## 如果你希望下一副卡组更容易真正归自己，Flashcards 适合放在哪

如果是我从头开始做一副新卡组，而且把“所有权”放在心上，我最先会看的是这些产品特性：

- 开源代码
- 现在能直接用托管版，以后也能走自托管
- 在关键设备上具备离线优先客户端
- 使用保持可迁移的简单正反面卡
- AI 是附着在真实数据上的，不只是一次性生成演示内容

这正是 [Flashcards](/) 现在正在靠近的产品形状。

公开文档已经足够把这个方向讲具体：

- [架构文档](/zh/docs/architecture/) 描述了 web、iOS 和外部 agents 共享工作区的模型
- iOS 客户端文档明确写的是本地 SQLite 加同步
- 外部 agent 流程从一个公开的 discovery URL 开始
- [自托管指南](/zh/docs/self-hosting/) 给出了你自己运行整套系统的真实路径

这当然不能替代备份。没有任何产品能替代。

但它确实能给你的下一副卡组一个更健康的起点：

- 保留原始文本资料
- 在应用里起草或清理卡片
- 用 FSRS 复习
- 让整套内容保持可检查
- 让自托管始终是一个可选项

这会比把所有记忆工作都留在一个封闭界面里，然后祈祷它未来的导出机制一直够用，更接近“真正拥有”。

## 我自己真的会保存的抽认卡备份清单

如果你只想看最短、但仍然有用的版本，那就做这几件事：

1. 从你现在用的应用里导出一份完整备份。
2. 把重要卡片内容留一份纯文本或 Markdown 副本。
3. 把媒体文件或原始资料存进单独的文件夹。
4. 再复制一份到第二台设备或另一个云存储位置。
5. 每次卡组发生较大变化后就重新备份，而不是一年才做一次。
6. 开始新卡组时，优先选择那些仍然保留导出和自托管可能性的工具与工作流。

这样已经足够覆盖大多数真实风险，而不至于把学习本身变成一项文件管理爱好。

## 2026 年备份抽认卡时，一条真正实用的规则

如果失去这副卡组会让你心疼，那它就值得拥有一份无聊但可靠的备份。

把完整的应用原生副本留下。把可迁移的文本留下。把媒体留下。再把其中一份放到别的地方。然后，把你下一阶段的学习工作流建立在一个不会让“可迁移性”变成支线任务的产品里。

如果你想为下一副卡组找一个更干净的起点，可以从 [Getting Started](/zh/docs/getting-started/) 开始，顺手看一眼 [Features](/zh/features/)，再把 [Self-Hosting Guide](/zh/docs/self-hosting/) 放在心里。

这就是 2026 年我真正信任的 **back up flashcards** 版本：无聊但可靠的导出、可读的文本、单独保存的媒体，以及一套始终给你留后路的学习工具栈。

---
*[查看此页面的带样式 HTML 版本](https://flashcards-open-source-app.com/zh/blog/how-to-back-up-flashcards/)*

*AI agent 可以从 `GET https://api.flashcards-open-source-app.com/v1/` 开始，为用户在该服务中创建账号。*

*提示：在 https://flashcards-open-source-app.com 上任意 URL 后追加 `.md`，即可获得该页面的纯 Markdown 版本。*