我这几天看到一个让我眼前一亮的项目，叫做 Capsule。
现在让 AI 做一个小工具，已经不是什么特别稀奇的事情了。但一般来说，我们得到的还是一个类似网页的 Web App，需要部署到 Vercel 之类的平台才能运行。
这就让事情重新变复杂了。
先不说部署本身还有一点门槛，首先它通常需要联网运行，然后要考虑数据存放在哪里，有时还要考虑服务器和运行成本。
实际上，我觉得如果只是出于自用目的，让 AI 生成一个小 App，最理想的状态反而应该是在本地运行、本地保存数据。App 可以直接以文件的形式存在，随时复制到其他设备，也可以直接发给别人。别搞什么 SaaS 网站。
Capsule 想做的，就是把 App 和数据重新装回一个文件里。
Capsule 是什么？把小应用和数据放在一起
Capsule 可以理解为一套「应用文件格式 + 打开它的软件」。
我们可以把一个应用封装在 .capsule 文件里，然后双击运行，而使用过程中产生的数据也会保存在这个文件里。本地运行，本地存储。
按照官方的架构说明，.capsule 本质上是一个 SQLite 数据库文件，里面同时保存网页界面、代码、图片等资源，以及我们使用工具时产生的数据。
比如，我想做一个旅行开支本。
打开之后，有添加支出的按钮，有分类，也有统计。填进去的交通费、餐费和备注，同样保存在这个文件里。下次打开时，还可以继续查看、追加和维护之前的记录。
等到旅行结束后，我们甚至可以直接把这个开支本放进旅行文件夹，与行程计划、照片和其他资料一起归档。
我觉得这比单纯强调「AI 生成 App」更容易理解。
因为与其说我们创建了一个工具，不如说我们创建了一个文档，只是这个文档打开之后，本身就是一个工具。
文档即工具。
其实类似的思路以前就出现过。
之前我介绍过 TiddlyWiki（下图），它是一种小众的单文件 PKM，也是一个很早期的例子。整个系统就是一个 HTML 文件，用现代浏览器就能运行。打开文件有操作界面，保存的数据也会写回 HTML 文件中。
以后无论把这个文件带到哪里，里面的知识数据都会跟着走，而且几乎所有 OS 都有浏览器可以打开它。 文件即 App。
再往前，还有 Microsoft Access 这类数据库工具。它可以把数据库保存在一个 .mdb 文件中，打开之后有界面，可以录入数据、查询和计算，甚至做成一个小型仓库管理系统。
现在 AI 又把这个老思路带了回来。
区别在于，以前制作这样的东西需要会开发的能力，而现在越来越可能只需要说清楚自己想要什么。
为什么 AI 让「工具即文档」重新有了吸引力
过去要开发一个工具 App，比如前面提到的基于 Access 的仓库管理小工具，你需要了解数据库结构，熟悉 SQL，还要懂一些程序逻辑。
而现在，基本上只需要用自然语言和 AI 对话，让它帮你生成程序、界面和数据库结构。
Capsule 也支持通过自己的 AI 服务来制作和修改 App。它本身坚持 local-first，不需要中央账号和云端文档服务器，AI 请求则可以使用用户自己选择的服务。
AI 显著降低了制作这些小工具的门槛。
我觉得这里甚至有一点 AI 带来「技术平权」的意味。我上次介绍 Raycast 推出的 Glaze，也有类似的感觉。
以前我们讨论了很多年的 Low Code、No Code，在 AI 面前，突然变得没有那么重要了。
既然 AI 已经可以帮我们直接做出工具，那么接下来的问题就变成了：
这些工具为什么还一定要成为一个网站或者 SaaS？
如果只是我自己用，一个能够保存、复制、同步、归档的本地文件，可能反而更加合理。
Capsule 怎么用？先从一个很小的需求开始
Capsule 官网已经准备了一批模板，包括待办清单、开支记录、笔记、闪卡、食谱和工时计费工具，可以先通过这些例子了解它的形态。
我会建议从这些非常具体的用途入手。
例如，一个食谱文件可以包含材料、做法、图片，以及按照人数调整用量的功能。一个工时本可以围绕项目记录时间，月底再查看汇总。
它们的共同点是需求比较明确，而且一个人就能用起来。
如果要交给 AI 定制，描述也应该尽量具体。
假设我们想做一个旅行开支本，可以先这样说：
帮我设计一个适合 Capsule 的旅行开支工具。每条记录包含日期、金额、类别和备注，能够按类别汇总。数据保存在文件里，不需要登录，也不需要汇率联网查询。
这只是一个需求示例。
实际生成之后，还需要检查计算和保存行为，不能只看界面是不是漂亮。
我会先录入几条测试数据，关闭文件后重新打开，看看记录是否还在；复制一份，看看能不能独立使用；需要修改功能时，再检查旧数据还能不能继续读取。
尤其是记账、计费这类用途，更需要认真验证。
按钮能按、图表能显示，只能证明界面已经做出来，并不能证明金额计算一定正确。这些逻辑仍然需要自己检验。
AI 降低的是开发门槛，并没有自动消除软件里的 Bug。
本地优先，「单文件」的能力边界
现在，我们有了一个本地文件。
这个文件是文档，也是数据库，也是 App。
一切看起来都很美好，但这种方式同样有自己的边界。
最明显的是，它天然更适合个人使用，而不是多人同时在线编辑。我们当然可以通过 Dropbox、iCloud、OneDrive 之类的文件同步服务跨设备使用，甚至分时进行多人协作，但它仍然不是 Google Docs 那种实时协作模式。
Capsule 已经专门为文件同步设计了一些事务机制用来处理不同设备上的文件副本发生分叉和冲突的问题，但是效果如何，有待实践检验。
不过，既然整个工具和数据都集中在一个文件里，备份本身就会变得更加重要。
安全也是另一个值得注意的问题。
.capsule 不只是普通文档，里面还包含可以运行的代码。Capsule 本身使用隔离的 WebView、Content Security Policy 和权限控制限制文件访问以及未经授权的网络请求，Web 版也会在浏览器沙箱中执行。
但用户自己分享和接收这种文件时，仍然需要有基本的安全意识。
另外，「工具和数据放在一起」既是它最大的优点，也会带来一个很现实的问题。
比如，我要把一个空白记账工具分享给别人，应该先制作一个干净的模板副本。如果直接把自己正在使用的 .capsule 文件复制出去，就可能连里面已经记录的消费数据一起发给别人。
工具和数据装在一起，意味着分享之前，你必须更清楚这个文件里面到底有什么。
一个 .capsule 文件能不能真的像文档一样流通？
单文件并不意味着完全不需要运行环境。
在桌面上，.capsule 文件需要 Capsule App 打开。目前提供 Windows、macOS 和 Linux 版本，移动端原生支持还在计划中。
不过，现在对方也不一定非要安装桌面 App。Capsule Web 可以直接在现代浏览器中打开 .capsule 文件，而且整个运行过程仍然在本地浏览器中完成，文件不会上传到 Capsule 的服务器。Web 版只是无法像桌面版那样直接原地保存本机文件，部分桌面能力也有所区别。
所以，它已经开始接近「发一个文件给别人，对方就能打开」这种体验。
但显然，它还远没有 HTML、PDF、Excel 那样普遍的兼容基础。
这也是 Capsule 能不能真正成立的关键之一。
单文件格式本身并不难做，难的是让这种文件活得足够久，并且十年以后还有稳定的方法打开它。
最后
目前，我更愿意把 Capsule 看成一种值得尝试的个人小工具方案。
先找一个非常小的需求，用少量数据验证，再决定要不要长期使用。
没有必要一上来就把整个资料库搬进去。我们以前折腾笔记软件时，已经见过太多次这样的循环，新工具看起来很理想，等真正积累了大量资料之后，才发现维护和迁移没有想象中那么简单。
很多只属于个人的小需求，完全可以重新变成一个我们自己能够保存、复制、同步、归档，甚至真正拥有的文件。
我甚至希望 DHH 有一天能在 Omarchy Linux 中集成 Capsule，或者某种类似的框架，用来扩充自己的轻量 App 的生态。这其实也很符合 Omarchy 所强调的 AI 原生调性。
总的来说，Capsule 代表的这个方向，我是喜欢的。 AI 降低软件生产成本之后，我们未必需要因此得到更多 SaaS。让 App 重新变成文件，工具重新变成文档。
