之前博客的《目录》页面用的是 List category posts 这个插件生成。可这个插件虽然功能比较多，但是不支持（还是我不知道？）我要生成的页面。

再往前用的插件是 Dagon Design Sitemap Generator，它可以生成一个以「分类目录」为主题的文章页面列表（例子可以看文章存档 – 木遥的窗子）。但是这个插件很长时间没更新了，甚至它的官网都打不开了，没办法重新下载这个插件。

考虑到这个插件功能并不复杂，索性自己写好了。我的文章本身不多，因此也不用做分页或者其他的配置，用最简单的方式即可。这个插件应该符合以下功能：

• 生成一个双层级的 bullet list
  • 以「分类目录」为第一层，排序方式按单词字母正序
  • 以该分类目录下属的文章为第二层，排序方式按文章创建时间倒序
• 「分类目录」的展示需要加前缀 “Category”，且这个前缀需要加粗
• 「分类目录」的内容为分类标题，该标题为该分类的 URL
• 文章列表都是可点击的 URL
• 文章标题后面增加文章创建的时间

以上功能其实不复杂，最后只用把它们拼成 HTML 语法的代码即可。

问题在于，我从来没写过 WordPress 插件，甚至我也不会 PHP。换在两年前，如果需要完成这项任务我应该需要：

1. 用至少 2 天时间学习 PHP 的基本语法，其中可能包括：
   • 找到合适的上手文档/教材
   • 搜索无数次 StackOverflow 搭一套可运行环境
   • 学点基础语法，并且在写的过程中反复查文档
2. 用至少 2 天时间学习 WordPress 的开发过程，其中可能包括：
   • 为了性能和效率，先在本地机器跑起一个 WordPress 页面
   • 从 WordPress 的文档看怎么写出一个 Hello World 插件
   • 搜索无数次 StackOverflow 看别人怎么解决各种意想不到的问题

但是自从有了生成式 AI 后，完成这么一项任务变得无比简单。以这次写插件为例，用的是 Anthropic 新发布的模型 Claude 3.5 Sonnet，前后只用了 30 分钟就完成了。我并没有学 PHP 的基础语法，也没有查过 WordPress 的文档。只需要通过合适的 Prompt 引导 AI 生成合适的代码，同时让 AI 告诉我怎么把插件安装到 WordPress 即可。

当然，初次生成的代码不是完美的，但是把需要改进的内容告诉 AI 即可慢慢引导到正确的结果。

这与程序员目前写代码是一样的过程：刚开始写好的大概率是不完善的，有错误或此前没考虑到的地方，一步步改好重新运行，通过不断的试错达到最终的效果。

这就是 Sam Altman 提到的完全使用自然语言编程。几十年前的程序员写的是汇编语言，而今天绝大多数的程序员都不再用，而是通过 Python 等高级语言（这里的高级并非褒义词，而是高度封装的意思，类似于预制菜和炒菜的区别）完成任务。而如今的 AI 是一个新的编译器，它可以让大多数人直接通过自然语言编程。

或者类比一下，coder 有点类似于国内较早学习英文的人，有能力将中英文互相翻译。而现在的 AI 可以充当一个翻译器，让人可以直接用自然语言和计算机交流。

但这并不意味着编程就成为一件无门槛的事—尽管门槛降低了些。我们依然要整理好需求和思路才能完成任务。以刚刚的 WordPress 插件为例，如果只是说「做一个插件支持以『分类目录』归类展示文章列表」，那么有可能会作出很多不同版本的插件。

事实上，这也是 software engineer 和 coder 的区别。前者更多的工作在于将一个较大的任务拆分成小任务，通过合适的方式组合起来完成；而后者更强调翻译这项工作。

这也让我想起，前段时间和朋友聊起，我们这行未来能做什么。我并没有想好这个问题，但是会让我想到如果要转行，什么能力是通用的？在我看来其中一个就是解决问题的思路。小的问题比如家里一颗灯泡坏了怎么修？大的问题类似如果要设计一套银行系统需要怎么完成（我现在自然还不能胜任这项工作）？

也正是因此，前段时间教两个朋友编程的时候，我并没有怎么注重语法，而是更关注解决问题的思路。通过自然语言把问题拆解出步骤，然后翻译成代码。回想起当年自己自学的时候那种无力感实在痛苦，已经忘记是怎么熬过来的了。幸运的是，现在的人不必如此。

前段时间去了趟大英博物馆，看到了镇馆之宝罗塞塔石碑。两百多年前，法国人商博良 (Jean-François Champollion) 以这块石碑为突破口，破译了古埃及圣书体，成为埃及学创始人。这块石碑上印有三种文字，分别是古埃及圣书体、世俗体及古希腊文。或许在未来，非自然语言的代码都会被人遗忘。而某一段写着自然语言注释的代码会成为新的罗塞塔石碑。

TL;DR 本文8200+字，全文阅读约需15分钟。本文简要回顾了从感知机到深度学习最新大模型应用 ChatGPT 的历史。

TL;DR 本文8200+字，全文阅读约需15分钟。从去年开始，我读了十余本人工智能方面入门的书籍（参见文末附2），酝酿了两个月，花了两周时间写作此文。本文简要回顾了从感知机到深度学习及Hugging Face的历史，并试图以通俗的语言来介绍神经网络和深度学习的原理。

19世纪末，弗雷德里克·泰勒在美国一些工厂推广他的科学管理方法，这包括用科学的方法来代替人工经验判断、对工人进行专业训练以及按专业分工。亨利·福特在他的汽车工厂里也开始应用泰勒科学管理，并且在汽车生产上创新性的采用了流水线作业。1908年，第一辆福特T型车从流水线上面世，而经过优化的流水线在几年后甚至可以达到93分钟内生产一部汽车，强大的生产效率让福特超过了其他所有汽车厂商生产能力的总和。福特的流水线生产很快被其他厂商所借鉴，也迅速普及到了其他工业领域。可以说，福特T型车流水线作业的发明开启了大规模工业生产的时代，人类的生产力得到了巨大的提升。从英国移居到美国的阿道司·赫胥黎对此深受启发，在他的带有科幻色彩的反乌托邦小说《美丽新世界》中，描写未来的人类“文明社会”，人们不再用公元纪年，也不信仰上帝，改尊亨利·福特为唯一的神，以福特为纪元，并以第一辆福特T型车流水线生产的1908年为福特元年。

19世纪末，弗雷德里克·泰勒在美国一些工厂推广他的科学管理方法，这包括用科学的方法来代替人工经验判断、对工人进行专业训练以及按专业分工。亨利·福特在他的汽车工厂里也开始应用泰勒科学管理，并且在汽车生产上创新性的采用了流水线作业。1908年，第一辆福特T型车从流水线上面世，而经过优化的流水线在几年后甚至可以达到93分钟内生产一部汽车，强大的生产效率让福特超过了其他所有汽车厂商生产能力的总和。福特的流水线生产很快被其他厂商所借鉴，也迅速普及到了其他工业领域。可以说，福特T型车流水线作业的发明开启了大规模工业生产的时代，人类的生产力得到了巨大的提升。从英国移居到美国的阿道司·赫胥黎对此深受启发，在他的带有科幻色彩的反乌托邦小说《美丽新世界》中，描写未来的人类“文明社会”，人们不再用公元纪年，也不信仰上帝，改尊亨利·福特为唯一的神，以福特为纪元，并以第一辆福特T型车流水线生产的1908年为福特元年。

一、应用

写这篇文章的时候我想起来的是之前看到的一段轶事。具体的文字已经不可考，但大致如下：

在一节计算机课堂上，教授跟学生说：「请大家打开 C 盘下的 xxx 文件。」这时有学生问道：「教授，请问我要用哪个 App 来做到这件事？」后来教授惊讶地发现，这一代的学生有些从来没有接触过文件管理器这个概念。他们从小到大接触到的都是一个个的 App，以及 App 内一个个具象的视频、音乐、文档等。对于他们来说，文件及文件夹是一个陌生的概念。

这一现象是什么时候开始的？或许有些人会认为是 iPhone 的诞生作为开端，但我更倾向与认为是 2004 年 Gmail 的诞生引领了这一趋势。

2004 年的愚人节，Google 正式发布了第一个版本的 Gmail，并宣布提供给每个用户 1GB 的存储空间。这在当年是非常具有轰动性的产品。在那之前，用户使用邮箱是通过客户端（Outlook 或者 Thunderbird）把邮件下载到本地后使用。因为当年邮箱提供商给予用户的免费空间一般按 MB 来计算，因此 Gmail 的推出一下子引发大量用户的迁移。

或许有很多人对 2004 年这一概念感到模糊，但我印象还算比较深。因为 2004 年正是我家刚买入第一台个人电脑的那年。当年我们家选配的硬盘为 80GB。

可能你会疑惑，只是增大免费容量为什么会作为一个趋势的起点？在我看来，这带来了用户使用习惯的改变。前文提到，在那之前用户使用邮箱是需要把邮件下载到本地后处理，因为邮箱提供商分配的空间有限，这意味着邮件的处理都是发生在本地的行为。邮箱提供商主要的服务仅仅在于发送与接收。但是当存储空间提升后，用户为什么还要将邮件下载到本地后处理呢？用户可不可以直接在网页上处理呢？事实上，当时已经有人这么做了。

注意，在以上的描述中我还没引入云的概念。对于大多数用户来说，最先让用户意识到云这一概念的产品是 iCloud。但在这之前还有一项划时代的产品需要介绍。同样出自 Google 之手，那便是今天大多数人的浏览器 — Google Chrome 的内核 Chromium。

二、基础设施

今天，除了苹果的 Safari 和 Mozilla 的 Firefox，大多数现代浏览器都是以 Chromium 为内核的应用。在当年，IE6 已经很久没有人维护了，网页技术的发展停滞不前。Chrome 的推出迅速刺激了沉寂已久的技术发展，人们意识到原来浏览器可以如此的快。注意，这里的快不仅是网页加载得快，而是在网页上做出复杂操作的时候响应速度的快。

同时，Chrome 也将 Web App 这一概念第一次让广大用户认知。但 Web App 这一概念并非由 Google 提出，

让我们把时间再往前几年，1995 年 Netscape 推出了 Javascript 编程语言。这一编程语言允许浏览器在网页上进行动态处理。2007 年，在 Chrome 推出的一年前，Mozilla 便推出了一个项目 — Mozilla Prism。Prism 将 Web App 和桌面操作系统深度整合，用户可以在桌面上直接打开某个 Web App。与在桌面建立某个网页书签不同，Prism 允许用户针对不同的网页配置不同的偏好设置。

以上一项为技术基础，一项更偏向理念，Google 在推出 Chrome 的时候便充分受益于此。在 Chrome 发布前夕，Google Blogoscoped 的作者 Philipp Lenssen 便将 Chrome 的主要特性总结为以下几点：

• Chrome 是 Google 的开源浏览器项目（编者注：此处说法有误，Chromium 才是开源的项目）
• Chrome 会包含一个新的 Javascript 引擎叫 V8
• Chrome 的标签页会放置在地址栏顶部
• Chrome 会有快速拨号页
• Chrome 会有隐私浏览模式
• Web App 拥有自己的浏览器窗口
• Chrome 内置防病毒及恶意软件功能

在我看来，以上特性中，真正具有革命性的功能为 V8 引擎以及将 Web App 的概念在浏览器设计之初便作为其重要特性。前者是后者的技术基础，而后者是消灭文件的基础。

三、云

2011 年，随着 iOS 5 一起发布的还有 iCloud 服务。至此，所有的拼图都完成了。iCloud 类的远程存储让广大用户意识到数据存储在本地不一定是安全的。这里的安全并不是私密性上的安全，而是能极大地降低数据丢失的风险。同时，只要网络条件允许，用户可以在任何物理设备上访问到自己的数据。换言之，本地存储不再是唯一选项。甚至随着网速的提升及网络延迟的降低，除了数据敏感性高的内容外，一切数据都可以放在云端。

但 iCloud 并不是第一个做云端硬盘的公司，早在 2005 年，Aaron Levie 就发布了 Box.net 这一云端硬盘产品。它允许用户将自己的文件放置于网盘上，并且可以像在本地文件一样管理。更先进的产品是 2008 年发布的 Dropbox，与 Box.net 一样提供云端硬盘服务。不同的是它提供了增量同步功能。这意味着如果用户对一个文件进行修改，Dropbox 可以做到只同步修改的部分。

从技术上看，Dropbox 将用户的文件拆分为许多小块，并将这些小块的属性计算出一个数值。我们只需要知道如果某一小块的数据有变更，那么这一小块的数值便会改变。通过对比本地和云端的数值便可以决定需要同步本地及云端的哪些内容。

增量同步除了提高同步速度外，还意味着文件存储形式的改变。用户的文件不再是原来的文件，而是被拆分成一段段数据，通过后期的拼接组合成用户原来的文件。虽然文件在本地硬盘的存储方式也是类似，但与本地存储不同，云端硬盘可以将用户文件拆分出来的一段段数据分散存储在不同的硬盘，甚至不同的数据中心。这一特性还有什么应用我们在此按下不表，后面会讲到。

iCloud 更为激进，在刚开始发布时它直接屏蔽了用户访问具体文件的选项。与 iOS 类似，用户使用 iCloud 是通过一个个 App 来实现。iCloud 和系统的整合更深，用户无法感知文件的存储及同步过程，本地存储和云端存储的边界更模糊了。用乔布斯的话来说就是 It Just Works。

但在这一步走得更远的依旧不是苹果。作为一家卖硬件为主要利润的公司，iCloud 主要的服务对象依然是苹果用户。对于其他操作系统，iCloud 显得过于封闭。而打破这一局面的仍然是 Google。在 iCloud 发布一年后，Google 也推出了自己的云端网盘 Google Drive。一开始发布时我以为这是一款比上不足比下有余的产品。它没有 Dropbox 的增量同步，也没有 iCloud 那般与操作系统深度整合的能力。似乎是一款可有可无的产品。但经过这些年发展，我发现它走的是另一条路，一条真正杀死用户文件的路。

四、文件的消逝

让我们暂且把目光转向更娱乐的地方 — 音乐。

我还记得以前听音乐的流程。在酷狗音乐上搜索自己喜欢的作品，然后点击下载。通过酷狗或者其他播放器打开刚才下载的 mp3 文件收听。有些音乐在各大音乐平台找不到，便到百度搜索，通过 BT 或者网盘下载到本地并整理好文件的元数据（歌手、专辑等）。在整理好后，将一些最近比较火的音乐整理好传到 MP3 里听。

后来我发现了豆瓣 FM。豆瓣 FM 和酷狗音乐最大的区别在于，豆瓣 FM 是纯流媒体的模式，即我们没法下载单曲，而只能在网页上播放。与之带来的变化是，我不再与一个个 mp3 文件打交道，将其手动整理好存到电脑里。甚至我不再需要下载程序，只需要登上豆瓣 FM 的网页就能开始听音乐。另外在存储空间不再是掣肘后，收听的音乐种类大大拓宽。通过不同的电台，我可以听到许多未曾接触的音乐。

这便是流媒体。

在今天这显得非常普遍，我们在 Netflix 上看电影，在 Spotify 上听音乐。理想情况下，我们不再需要下载这些内容，甚至下载这一概念已经变得陌生，取而代之的是离线观看（收听）。用户不再需要跟文件打交道，服务商也可以将这些内容用 DRM 锁定防止盗版，并更激进地使用私有协议。比如苹果通过 Apple Music 推出 Spatial Audio，在以往是很难实现的。

同时得益于流媒体的发展，获取新内容的成本大大降低。因为大多数流媒体都是按月收费，即用户付出一定的成本后，获取新内容的边际成本几乎为 0。这便带来了更多长尾内容。以往一个创作者创作出一张专辑，要说服未曾听过的人购买是很难的。但当获取新内容的边际成本降低为 0 后，用户消费新内容的门槛更低了，独立创作者的内容也更容易被消费到。

用户失去了文件的所有权，但也换来了更蓬勃的生态，以及更方便的使用体验。

这不仅发生在内容消费领域，在内容生产领域也略显端倪。

以文档处理为例，以往文档处理工具便是 Microsoft Office 三件套。诚然，Office 三件套功能十分强大，但它一开始的设计并没有考虑到云时代，所有文档的操作都是基于单一文件。而 Google Docs 则完全建立在云时代的基础上，也正是得益于这一后发优势，Google Docs 从设计之初就考虑到团队协作。也正是对用户屏蔽了文件这一形式，在线协作才成为可能，因为单一文件在修改的时候总是具有排他性的。

事实上，Google Docs 的文档会在 Google Drive 上显示出来，但如果我们将其下载下来会发现，这个文件只是一个链接。这也是我在前面提到的 Google Drive 设计的更先进之处 — 对于用户来说，文件并没有用，用户需要的是文件的应用。而与苹果的 iCloud 不同，Google Drive 真正做到了全平台。用户在本地不需要安装任何应用，在 Google Drive 上无数开发者提供了许多 Web App 让用户使用这些文件。与 Dropbox 不同的是，Google Drive 本身不实现增量同步，而是将这一工作下放给应用方实现。在线协作正是增量同步的体现。

Google Drive 的设计真正得益于前面三部分 — 应用、基础设施、云。通过应用（Google Docs）随时随地在基础设施（Google Chrome）上打开云（Google Drive）上的数据生产或消费。Google Drive 并不是传统的网盘，它更像是一个入口。

不止 Google，如今许多其他的应用也如雨后春笋般出现。比如 Figma，在 2016 年推出后迅速成为设计师最爱的生产力工具。比如 Notion，几乎只需要维护一份代码便可以提供全平台应用。

上述两个应用在创立之初都摒弃了传统文件的概念，比如在 Figma 里，我们不需要关心一个项目的所有 Page 是否是同一个文件。也正得益于屏蔽文件的设计，协作办公可以非常自然地实现。设计师和产品经理不再需要传输一个个 Sketch 文件，在某个有疑问的地方圈圈点点地沟通，而是直接在设计的过程中添加注释（改需求）。

即便是对文件系统最熟悉的程序员也逐步有屏蔽文件系统的趋势。在 Golang 里，外部依赖包是通过包的自定义地址引入。比如我要引用 MySQL 包，只需要在引入里写上 github.com/go-sql-driver/mysql 即可。在未来，Golang 是否还需要将外部包下载到本地再使用呢？进一步来推进，是否可以有一款新的编程工具如 Figma 那样，用户不再需要像现在一样整理文件的编排，而是用类似 Page 的形式整理，通过类似标签的形式引用别处的代码？

上述应用的发展都充分体现了一点：传统操作系统正在式微，而浏览器正在取代操作系统。事实上，Chrome 也推出了 ChromeOS 操作系统以及对应的 ChromeBook 笔记本。

目前这一替代还未成熟，对于计算密集型的应用还无法替代。比如音视频剪辑的应用还未成熟，虽然已经有产品正在尝试（比如 Dropbox Replay）。更难替代的是专业的工业软件。但对于大多数用户，文件确实已经消失了。尽管文件是操作系统最基本的单位，但用户并不需要知道这些。

毕业后工作一段时间以来感觉自己的花销越来越不可控，之前听闻一个朋友说毕业后第一年基本是存不下钱的，当时还不以为然，结果后来真的应验了。于是在今年国庆后正式开始记账。作为整天与纯文本打交道的程序员自然更青睐于纯文本的记账工具，于是在看了 BYVoid 兄的这个系列文章以及 SKYue 兄的这篇文章后也开始用上了 Beancount+Fava。

与之而来的问题是账本作为一种私密性极高的数据，我不希望在他人的服务器上有留下任何明文的数据。Dropbox 或者类似的网盘同步显然不合适，棱镜计划的存在让我放不下心。虽说自己的数据并没有涉及到犯罪，但是这些监控行为在价值观上也与我相悖。账本一旦有他人获得明文数据后几乎可以勾勒出我从记账开始后的生活轨迹，我不希望除了自己以外有其他人能看到。墙的存在也是一个考虑因素，虽说在用上 Clash/Surge 后已经可以做到在中国/国际互联网上无缝自由穿梭，但始终会有顾虑。

在 BYVoid 兄的文章 4 中提到了用 Git+git-crypt 的组合，但是使用了 git-crypt 也有弊端。因为 git-crypt 加密后在 Git 的记录都是加密的二进制信息，这就带来了在多设备环境中 merge 的问题。如果在编辑前忘记把最新的 commit pull 下来，在解决 conflict 的时候就没法像明文数据那样比较。虽说可以看 commit 时候的 message 来区分，但是因为是账本信息 commit 的 message 不应该写得很具体，否则也会泄露隐私。

于是在试过几次解决 merge conflict 后我放弃了这个方案，转而使用 P2P 同步的方式在多设备同步。目前我已经切换到 Syncthing 并且（在折腾了一段时间搞不懂它的同步逻辑失败多次后）稳步运行了起来。目前账本的信息保存在家里的电脑、家里的树莓派和自己的笔记本上，这样每次修改账本都可以几乎实时同步到另外几台设备上。

但是在听了《内核恐慌》的 56 期后了解了备份的 3-2-1 原则，想到事实上数据做了同步但是并没有做到很好的备份，而如果家里电脑、树莓派、笔记本一起挂掉（考虑到自己瞎折腾的频率和水平这种可能性并不低）那我的账本就消失了。于是开始着手于完成那个 1，即一份数据在远程。但是如我在上文提到的不能明文存储在他人服务器，在存储到另一台服务器的时候则需要先加密后上传。

（下文偏技术向）

首先我们需要准备几个东西：

1. 一个 GPG 密钥
2. 一个远程服务的帐号（我用的是 Backblaze B2）
3. 一台 24*7 运行的设备（非必需）

一、准备 GPG 密钥

首先生成一个 GPG 密钥：

gpg --full-generate-key

一路选默认就可以，如果你之前已经有一个 GPG 密钥，那么可以导入。

gpg --import /path/to/keyfile

之后信任这个密钥

gpg --edit-key YOURKEYFINGERPRINT

如果你导入了你的密钥，按一下 Tab 后应该就会出现了，或者可以用 gpg --list-keys 找到你的密钥，输入 pub 的第二行就好。之后键入 trust。因为是我自己生成的密钥，我就选了 I trust ultimately。

二、注册个 Backblaze 的帐号

略……同时创建好一个 B2 的 bucket。

三、安装工具

首先要有 Python 环境，如果你是在 Debian/Ubuntu 上也直接可以通过 apt 安装 backblaze-b2，或者在其他设备可以通过 pip 来安装，具体可以参考官方文档。

sudo apt install backblaze-b2 -y / pip3 install b2

安装往后把 backblaze-b2 或者 b2 路径添加到 PATH 里，一般已经自动添加好了。

之后授权 b2 绑定到自己帐号，具体可以看官方文档。

b2 authorize-account [<applicationKeyId>] [<applicationKey>]

准备工作就完成了，接下来写个自动化脚本定时跑备份就好了。

四、备份

首先压缩成一个文件，因为只是作为备份而且 Backblaze 有10G 的免费空间，我们尽量把文件压缩到最小。另外可能账本中有些文件是不想包含在压缩包里的，比如编辑器的配置，或者 Git 的记录，可以把它们剔除掉。然后我们用我们的密钥加密这个压缩文件。之后上传到 Backblaze B2 上。

跑脚本前先定义几个变量：

1. LEDGER_DIR 是存放我们账本的文件夹的上级目录，比如账本在 /home/user/Private/Ledger，那么这个参数就是 /home/user/Private。
2. LEDGER_NAME 即账本文件夹的名字，比如上面的例子就是 Ledger。
3. NOW 就是现在的时间，因为定时备份脚本是把历史都备份起来，所以通过时间命名文件可以知道该备份是何时生成的。可以通过 $($(which date) --iso-8601=seconds) 获得。
4. GPG_PUB_KEY 是 GPG 密钥的 Fingerprint，即 edit-key 时的那串字符。
5. BACKBLAZE_BUCKET 是在 B2 上创建的 bucket 名字。
6. BACKBLAZE_REMOTE_FILE_DIR 是在 bucket 里备份账本的文件夹的名字。

（我在上文或者下文用了很多 $(which xxx)，这样可以获得 xxx 程序的绝对位置。因为不知道为什么在 crontab 上有时不这样写会有问题。）

然后跑下面这段脚本。

$(which tar) --exclude=".vscode" --exclude=".git" --create --directory $LEDGER_DIR $LEDGER_NAME | $(which gzip) --best | $(which gpg) --encrypt --recipient $GPG_PUB_KEY --output /tmp/$LEDGER_NAME.$NOW.tgz.gpg

exclude 很好理解，剔除掉部分文件，这里的 --create 即创建一个压缩文件，--directory 是我们先移动到存放我们账本的文件夹的上级目录，之后压缩我们的账本。如果不使用这个参数那么我们的压缩文件会把整个路径的文件夹都放进来，虽然不会把整个路径下所有的文件到包含进来但是就不太好看了。然后我们用 Gzip 进一步压缩文件到最小体积，再交由 GPG 加密，保存到 /tmp 文件夹下。最后就是上传到 Backblaze B2 上。

$(which b2) upload-file $BACKBLAZE_BUCKET /tmp/$LEDGER_NAME.$NOW.tgz.gpg $BACKBLAZE_REMOTE_FILE_DIR/$LEDGER_NAME.$NOW.tgz.gpg

这样就大功告成了。完整的脚本地址我已经存在 GitHub 上，chmod +x backup_ledger.sh 给予可执行权限后在 crontab 里设置定时任务就好了。比如每 3 个小时配分一次的话：

0 */3 * * * /path/to/backup_ledger.sh >/dev/null 2>&1

以上就是我的部分备份工作流。当然这样不止可以备份账本，还有其他重要的私密文件，比如录音录像这些也可以这样保存。这样也可以做到在保护隐私的同时保护数据安全。

（最后希望 Backblaze 不要被墙_(:3」∠)_