如果一款软件关掉服务器后什么都不剩，那些数据真的属于我吗？

前段时间我读到 Ink & Switch 写的 Local-first software。里面有个问题让我停了很久：云端软件给了我们协作，但旧式的本地软件给了我们所有权，我们能不能同时拥有两者？

这件事以前在我看来只是架构选择。数据放 MySQL，前端调接口，服务端是唯一真相，很正常。直到我开始用 Obsidian 写东西，才发现“文件就在我的电脑里”会改变我和软件的关系。

我不需要先相信某家公司会存在十年，才敢写下一篇笔记。哪天不用 Obsidian 了，这些 Markdown 还在，我可以用编辑器打开，也可以自己写脚本处理。软件只是入口，不是保管我思考的房东。

我以前把导出功能想得太轻了

做 Web 项目时，导出往往是需求列表里靠后的功能。主链路跑通、页面好看、接口稳定，这些都比导出优先。

但换个角度，导出可能是产品对用户最诚实的承诺：你在这里产生的东西，不会因为我们消失就一起消失。

我做 AI Novel to Script 时把最终结果导出为 YAML，最初只是觉得结构化文件方便后续系统消费。读完 local-first 的文章后，我才意识到它还有另一层意义。即使生成工作台停止运行，角色、事件、场景和对白依然是一份能被读取、修改和迁移的资产。

当然，这离真正的 local-first 还很远。项目仍然依赖数据库、消息队列和模型服务，离线时大部分能力都不能工作。我不想因为有一个 YAML 导出就给它贴上漂亮标签。

AI 应用尤其容易把用户锁进黑盒

传统软件至少还能解释数据去了哪里。AI 应用经常连“结果是怎样形成的”都说不清：提示词在服务端，记忆在向量库，工作流藏在代码里，模型版本随时变化。用户最后只拿到一段回答。

如果服务关闭，丢掉的不只是聊天记录，还有那套逐渐形成的上下文。

所以我现在会多问三个问题：

1. 用户能不能拿走原始输入，而不只是拿走模型整理后的版本？
2. 中间产物有没有稳定、可读的格式？
3. 换一个模型或换一个应用后，这些积累还能不能继续用？

这三个问题都不酷，也不会让 Demo 更惊艳，却决定了用户到底是在使用工具，还是暂住在工具里。

我想试一次“文件是真相”的 AI 工具

我有一个还没动手的想法：做一个以本地目录为核心的 AI 项目助手。任务、讨论、模型结论和人工修改都写成普通文件，AI 只负责读取和提出变更，Git 负责记录历史。服务端可以提供更强的推理，但不是数据唯一的家。

这里一定有很多麻烦，比如多人冲突、敏感信息、文件格式演进，以及模型生成大量无用内容后目录会不会变成垃圾场。

我现在还不知道它是否比普通 Web 应用好用。但 local-first 这个词至少帮我重新定义了一个问题：软件不只要考虑用户如何开始使用，也应该考虑用户如何完整地离开。

我以前总把“留住用户”当作产品能力。现在觉得，让用户随时能走，也是一种能力。