每个人都有一种方式来追踪那些对他们生活产生影响的事物，无论是一本书、一部电影、一部电视剧、一部动漫，还是一首歌曲。有时候，这是一项拥有庞大目录的在线服务，但你总是被平台决定哪些留存和哪些被删除所左右。其他时候，它是一个令人愉悦、设计精美的离线移动应用，但你的各种兴趣很难适应单一的预定义目录或数据模型。此外，那些应用和服务随时可能消失。在经历了无数工具之后，我意识到我想要一些我可以真正控制的东西。我开始在 Airtable 中构建自定义数据库，然后转向 Notion，最后尝试自托管 NocoDB。最终，我决定接受“文件优于应用”的哲学，放弃了不断迁移数据库的做法。我选择了一个 Obsidian Vault，其中我关心的一切都是一个 Markdown 文件，配有前置事项，并使用 Dataview 和后来的 Obsidian Bases 进行组织。但是，手动管理超过 2000 个 Markdown 文件的数据库引入了一种新的摩擦：寻找元数据、更新状态和跟踪日期。像图书管理员一样的繁琐工作取代了发现下一步要享受之物的实际乐趣。KizunaShelf 正是对此的答案。设计理念 我始终铭记的一项原则是，KizunaShelf 不仅仅是另一个媒体追踪工具。相反，它带来了类似 Airtable 数据库的动态灵活性，让用户可以精确定义他们的数据意义。模式是你可以检查和更改的，并作为意义的真实来源。单个 KizunaShelf/config.yaml 文件保存在你的 Vault 文件夹中，声明了你的类型、字段及每个字段的具体角色。它定义了：哪个字段代表条目的标题，以及该标题使用的语言。哪个字段描述一个日期及其代表的内容（例如，一款游戏的发布日期、你开始观看动漫的时间，或特定事件发生的时间）。哪个字段代表状态及其自定义选项列表。对象之间如何关联以及如何连接不同类型。但不需要因为模式的复杂性而感到畏惧。开箱即用，KizunaShelf 提供了你从传统媒体追踪器所期望的所有默认预设。您可以立即从预定义的预设中选择，例如动漫、电视剧、电影、游戏、桌面游戏、书籍、漫画与小说、音乐专辑、播客、艺术家与创作者，以及角色。这些类型还可以直接连接到你已经知道的外部元数据提供者，包括 TMDB、TheTVDB、IGDB、Bangumi、Apple Music、MyAnimeList、Google Books 等等。向 KizunaShelf 添加项目非常快速且简单：只需点击加号按钮，搜索你想要的内容，然后点击添加。封面可以在本地下载，而状态和日期可以在你自己的步伐下稍后记录。KizunaShelf 还了解“子项目”的概念，例如动漫的剧集或 CD 的曲目列表，允许你在同一个 Markdown 文件中以清单或项目符号列表的形式单独跟踪它们。工程架构 在幕后，这是一项有趣的工程实验。我对这个项目有一个非常具体且雄心勃勃的清单：一个可以随时随地访问的自托管网络应用程序。一个在 macOS、Linux 和 Windows 上的轻量级桌面应用程序，打开与 Obsidian 完全相同的本地文件夹。一个真正的移动应用程序，令人愉悦、快速，且原生于我的手机。桌面应用的解答是 Tauri。但是解决移动应用的问题导致了一个“如果”时刻：如果我通过 UniFFI 将 Rust 核心直接桥接到 Swift 模块，并围绕它编写一个原生 SwiftUI 应用呢？这又引发了另一个挑战：我如何在本质上为“2.5 客户端”保持 Rust 核心的完美对齐（因为 Tauri 桌面应用几乎与 Web 应用共享了所有前端代码）？我的解决方案是直接从 Rust 后端生成 OpenAPI（Swagger）规范，然后使用该规范来自动生成 TypeScript 和 Swift 客户端。最终结果是一个真正的跨平台架构。iOS 应用程序是完全的原生 SwiftUI，而桌面应用避免了 Electron 的重量。未来的 Android 应用程序可以遵循相同的架构，与其他客户端匹配功能，同时完全原生于该平台。在构建应用程序时遇到的一个小问题是不同平台上的 Unicode NFC 与 NFD 规范化。这已经解决，可以安全地在文件名中使用 Pokémon 或 ポケモン。维基链接和关系匹配在 NFC/NFD 差异之间是规范化的。kizuna（絆）：持续连接事物之间的纽带 许多作品对我来说意义重大，无论是动漫系列、视频游戏，还是启发这个应用名称的音乐项目。它们值得被记住，并且应与我们生活中的特定时刻联系起来。KizunaShelf 的设计就是为了描绘这些联系。日历跟踪即将发布的内容、计划和其他内容。