Kioku 最初不是一个 lifelogging 项目。它源于一个更具体的问题：LLM 没有我的上下文，而关于我的数据散落在每一个需要使用它的产品里。
Ghostty 的 tab 当项目槽，tmux 当分屏管理器 —— 为什么 tab 要看得见、为什么分屏交给 tmux、以及让八个项目同时开着还不会乱的那些配置选择。
4 分钟 · 4月22日开发十个让我每天开发更顺手的 Mac 应用 —— 终端、编辑器、数据库、翻译、截图，每个都不可替代。
2 分钟 · 4月14日开发用代码示例和数据流讲清楚 Next.js App Router 下四种渲染策略的区别和实际用法。
2 分钟 · 6月5日从 LLM 缺失的上下文，到 Kioku 的个人数据边界。
Kioku 最初并不是一个“记录人生”的项目。我没有先读完 lifelogging 的历史，再决定实现其中一种方案。它的起点要普通得多：我每天都在使用 LLM，但 LLM 并不认识我。
模型可以帮我写代码、分析架构、修改简历，也可以在获得工具之后替我完成一些操作。但每次打开一个新的 Provider，我都要重新解释自己是谁：我使用哪些语言，做什么工作，有哪些项目，习惯怎样组织代码，哪些技术限制不能被忽略。
Provider 通常会提供一个类似 things about me 的位置。我可以把这些信息写进去，问题似乎就解决了。但当我开始认真维护它时，我发现自己只是在建立又一份关于我的数据副本。
我的个人网站已经保存了工作经历、技能、项目和个人简介。修改简历的应用也需要这些数据，于是它会再 import 一份。LLM Provider 有自己的个人资料，未来开发的其他产品也会各自要求一份 profile。
这些系统保存的不是不同的数据，而是同一个人的不同投影。问题是，每一个投影都逐渐开始把自己当成源头。
只要数据被复制，漂移就会发生。
我更新了一段工作经历，应该先修改个人网站、简历应用，还是 LLM 的个人资料？某个项目换了技术栈，哪个系统里的版本才算正确？Provider 记住的偏好过期以后，我甚至不一定知道它仍在用一条旧信息影响回答。
最初我把它理解成 context 问题：也许我需要一份更好的 system prompt，或者一份可以导入不同模型的 JSON。后来我意识到，这只是换了一种复制方式。
Context 是数据被某个消费者使用时的形态，不是数据本身。Prompt、RAG 文档、简历页面和网站 API 都可以是消费方式，但它们不应该分别拥有一份事实来源。
这变成了一个很熟悉的工程问题：我违反了 SSOT。
一旦把个人网站、LLM 和简历应用都看成客户端，Kioku 的轮廓就自然出现了。
关于我的数据需要独立于任何一个客户端存在。个人网站不应该拥有我的职业数据，它只是公开展示其中一部分；简历应用不应该 import 后永久接管一份副本，它应该在需要时读取经过授权的版本；LLM 更不应该成为事实来源，它只能读取适合当前任务的上下文。
在 Kioku 里，PostgreSQL 是唯一真相来源。Kioku 拥有 schema、迁移、权限和 API。个人网站通过公开 API 读取可以发布的内容，管理界面负责写入，LLM 客户端通过 MCP 检索知识和结构化生活数据。
这样做并没有消灭重复。缓存、搜索索引、向量和 prompt 仍然会产生派生副本。区别在于，这些副本现在知道自己是副本：它们可以从源头重建，也没有资格反过来定义事实。
后来我发现，Kioku 最重要的设计并不是选了 PostgreSQL，也不是增加了 MCP。真正改变的是数据库边界。
今天的大型平台通常这样组织数据：
一个领域 × 大量用户
健康平台收集许多人的健康数据，音乐平台收集许多人的收听记录，招聘平台收集许多人的职业经历。它们的领域边界非常清楚，但同一个人的数据被垂直切开，分别留在不同公司里。
Kioku 把这个方向旋转了九十度：
一个人 × 多个生活领域
职业、知识、照片、音乐、健康、旅行和浏览记录属于同一个人的数据空间。它们可能来自不同产品，却不应该永远以产品为最终边界。
这不意味着把一切塞进一张万能表。Kioku 内部仍然使用 career、content、media、health、life 等 schema 保留领域语义。不同数据也有不同的读取规则：网站可以公开读取文章和项目，但健康与生活数据没有公开视图。
所以我现在更愿意这样描述它：
外部边界按人，内部边界按领域。
开始研究之后，我才发现“一个人的数据库”并不是新想法。
Vannevar Bush 在 1945 年提出 Memex，想象一种能够保存并连接个人资料的外部记忆。2001 年，Gordon Bell、Jim Gemmell 和 Roger Lueder 在微软研究院开始了 MyLifeBits：一个基于 SQL 的 “personal database for everything”。它保存文档、邮件、照片、网页、录音以及传感器产生的生活记录，并探索全文检索、标注、链接和相似性。
之后，Personal Data Store 和 Solid 从另一个方向处理相同矛盾：数据不应该被绑定在应用里，应用应当在获得授权后访问由个人选择的存储。到 2026 年，W3C 仍在推进 Linked Web Storage，尝试标准化应用对外部存储的安全、授权访问。
还有一条更务实的工程路线。HPI 不等待整个互联网先接受统一协议，而是通过导出文件和适配器，把聊天、音乐、浏览、位置和健康等数据转换成可以由个人程序查询的接口。
这些项目不是一个连续、统一的产品谱系，但它们反复回答着同一个问题：当一个人的数字生活横跨许多应用时，数据是否可以重新围绕这个人组织？
这条路线反复出现，也反复停留在研究项目、开源工具和少数自托管用户之间。障碍从来不只是硬盘容量。
首先，平台没有很强的动力交出持续、完整、机器可读的数据。即使提供导出，得到的也经常是一次性归档，而不是稳定的增量接口。一个人的数据可以被取回，不代表它已经可以可靠同步。
其次，跨来源的数据很难自动统一。同一个地点、联系人或活动在不同系统里可能没有共同标识；时间戳包含不同的时区假设；设备可能重复记录同一次运动。把文件放进同一个目录很容易，让它们在语义上成为同一个数据库则困难得多。
再次，集中化会扩大安全爆炸半径。分散的数据不方便使用，但聚合后的健康、位置、职业和浏览记录一旦被错误授权，损失也更集中。个人数据主权不能只意味着“数据都在我这里”，还必须包括最小权限、审计、备份和可恢复性。
最后，普通用户不应该为了拥有自己的数据而成为数据库管理员。对我这样的开发者，一人一个 PostgreSQL 是可以接受的；如果这种模式要服务更多人，合理的形态更可能是托管 Pod、加密的个人空间或逻辑隔离的数据账户，而不是要求每个人维护一台服务器。
过去，一个跨领域个人数据库缺少足够强的日常消费者。做一张健康图表或搜索旧消息很有用，却未必足以支撑整个生态改变数据边界。
个人 AI 可能是第一个天然需要这些数据的消费者。一个能够帮助我规划工作、修改简历、回顾项目或分析生活状态的 Agent，不能只知道某一个领域。它需要跨越职业、知识、偏好和历史，但每次任务只应获得完成任务所需的那部分。
同时，外部条件也在变化。欧盟 Data Act 已经推动联网产品向用户提供其产生的数据和必要元数据；DMA 也在推动大型平台提供更及时的数据可携带接口。这些规则不会自动创造一个个人数据库，但它们让“把数据拿回来”逐渐从逆向工程变成可以被要求的能力。
不过，AI 只是让需求变强，并没有替我们解决数据治理。
LLM 不能成为 SSOT。向量索引不保留精确数量，模型推断出的关系也不等于事实。一个 Agent 可以建议两条记录可能有关联，却不应该因为一次生成就重写我的职业经历。自然语言让数据更容易使用，但来源、权限和确定性仍然必须由系统明确表达。
MyLifeBits 后期探索过尽可能完整的被动捕获。今天也有持续录屏、记录键盘操作和保存每个数字活动的工具。Kioku 刻意没有把“完整”作为目标。
我更关心的是哪些数据值得在未来被可靠地取回：做过的项目、写下的知识、拍摄的照片、听过的音乐、到过的地方，以及能够被正确解释的健康记录。选择性并不是功能不足，而是数据模型的一部分。没有明确用途、来源或保留理由的数据，不会因为“以后也许有用”就自动获得永久保存的权利。
同样，公开也不是默认结果。个人网站和个人数据库可以使用同一个源头，但读取面必须不同。在 Kioku 里，可见性不是每个调用者都要记得加上的一条 WHERE，而是数据库角色和视图共同建立的边界。
这也是为什么我把 Kioku 看成个人数据基础设施，而不是 lifelogging App。记录只是进入系统的一种动作；更重要的是数据以什么结构存在，如何被验证，谁可以读取，以及换掉上层工具后它是否仍然属于我。
Kioku 目前仍然是为一个人构建的系统。它不能迫使所有平台提供实时接口，也没有消除维护导入器和数据模型的成本。把它推广成面向所有人的产品，还需要解决托管、密钥、授权体验和标准互操作等问题。
但对我来说，最关键的边界已经清楚了。
以后更换 LLM Provider，我不需要再迁移一份由 Provider 定义的“我”；重做个人网站，也不需要重新发明职业、项目和照片的数据模型；新的产品如果需要我的数据，它应该成为另一个经过授权的客户端，而不是新的真相来源。
Kioku 不是为了让 AI 记住更多。
它是为了让关于我的数据，第一次拥有正确的归属。