「知言归藏」：一个个人 AI 记忆系统的诞生 作者: zhaoyang 时间: 2026-08-25 分类: AI 开发 > 从“能不能把聊天都存下来”，到一套跨平台、跨设备、自托管的 AI 会话归档与项目演进系统。 最初，我只是厌倦了到处找聊天记录。 家里的电脑、公司的电脑、手机；ChatGPT、Gemini、Grok、腾讯元宝、MiniMax、OpenClaw……我每天在不同设备和不同 AI 之间切换。很多当时非常有价值的回答，过几天再想找，已经记不清是在哪个平台、哪个账号、哪段对话里看到的。 AI 帮我解决了越来越多问题，但这些答案并没有因此成为我的长期资产。它们只是散落在一个又一个聊天窗口里。 <!--more--> ## 一粒种子：ChatMemo 让我看见“AI 对话可以被积累” 这个产品最早受到 [Chat Memo](https://chatmemo.ai/) 的启发。它把 ChatGPT、Gemini、DeepSeek 等平台的对话聚合起来，自动增量保存，并提供统一检索。它传递了一个非常打动我的观念：AI 对话不是一次性消费品，而是一种值得长期沉淀的个人记忆资产。 但当我真正把自己的使用场景放进去时，缺口也很快出现了。 我经常使用的 Grok、OpenClaw 和 Codex，当时并不在它覆盖的采集范围里。更重要的是，Chat Memo 强调数据保存在本地设备。这对隐私很好，却也意味着家里电脑、公司电脑和其他设备上的数据难以自然汇聚。 我需要的并不只是另一个浏览器收藏夹，而是一套真正属于自己的“AI 记忆中枢”：不管对话发生在哪个平台、哪台设备，最终都能回到同一个地方。 于是，一个朴素的问题出现了：能不能把我与所有 AI 的对话都保存下来，并且定期分析？ 这就是「知言归藏」的起点。 ## 第一次把想法变成产品定义 2026 年 7 月 18 日，我把需求写得很直接：我要收集家里电脑、公司电脑和手机上产生的 AI 对话；要自动收集一段会话的全量内容；要根据 Session 区分不同对话；还要补上 DeepSeek、千问和 Kimi。 随着讨论深入，这个想法被拆成了三个部分。 第一是采集。网页平台交给 Chrome 扩展，在用户打开对话时自动读取；OpenClaw、Codex、Claude Code 这类本地工具，则通过 Windows 和 macOS 同步代理读取本地会话。 第二是汇聚。所有设备不再各自保存一份孤岛数据，而是统一上传到部署在群晖 NAS 上的私人服务，由 PostgreSQL 集中管理。手机端暂时不直接抓取 App，而是在会话同步到同账号网页端后，由电脑自动补录。 第三是理解。系统不仅要保存原文，还要支持全文搜索、项目归类、标签、时间线、周报和月报，让过去的对话能重新进入今天的工作。 至此，它第一次有了完整的产品轮廓：浏览器插件负责网页采集，本地代理负责桌面 AI 工具，NAS 负责统一存储，Web 端负责检索、管理和分析。 但“架构完整”并不等于“产品可用”。真正塑造它的，是随后一个多月里密集出现的真实问题。 ## 真正的研发，从第一批失败开始 第一版上线后，问题几乎来自每一个角落。 Grok 无法稳定识别；ChatGPT 的标题没有采集回来；Gemini 会把第二个对话并入第一个；腾讯元宝取错了 URL 中的会话 ID，导致不同会话被当成同一个；千问只能识别 AI 的回答，却识别不到用户的问题；MiniMax 页面看不到采集入口。长对话还有另一类问题：如果没有先滚动到最早一轮，页面没有加载的历史内容就永远不会被采集。 这些故障逼着系统从“写一个通用网页抓取器”，转向“为每个平台维护独立、可版本化的适配器”。平台的 URL 结构、DOM 标签、虚拟列表、流式回答、重新生成和分支切换都不一样，不能靠几条通用选择器解决。 数据去重也比想象中复杂。仅凭标题不可靠，仅凭页面地址也可能取错。最后，系统逐渐形成了稳定的数据身份：以“平台 + 外部 Session ID”标识会话，通过内容哈希判断内容是否真的变化，再用 Revision 保存历史版本。 这样，同一段对话从两台电脑上传不会生成两个副本；对话新增内容时只生成增量修订；编辑问题、重新生成答案或切换分支时，旧版本也不会被粗暴覆盖。 “完整”也不再是一句模糊的状态。系统要确认已经覆盖对话的第一轮和最后一轮，并且内容停止变化，才能把一次采集标记为完整。否则，它只能诚实地显示“不完整”。 这是产品的第一个重要转折：归档的核心不是“抓到了多少字”，而是能否证明这些数据来自哪段会话、是否完整、是否重复、是否还能追溯。 ## 从“自动化”到“无感”：不要让归档打断对话 第二个转折来自体验。 早期插件为了拿到全量内容，会反复刷新或从头扫描页面。只要浏览器停留在同一个对话里，它就可能一遍遍重采，既制造冗余，也会打断正在进行的对话。技术上它在工作，产品上却令人厌烦。 于是目标从“自动采集”进一步变成“无感采集”。 首次打开一段会话时，系统完成一次全量扫描；此后不再从头读取，而是跟随聊天状态，只同步新增加或真正发生变化的部分。插件的悬浮入口靠在页面右上方，采集时只做轻微状态变化；重新安装新版本后尽量保留配对信息；网络中断时先进入离线队列，恢复后再上传。 Windows 和 macOS 的本地代理也经历了同样的变化。最初需要手动运行脚本、保持窗口开启，后来逐步变成后台常驻服务，支持安装、卸载、自动启动和状态检查。客户端安装包也被放进设备页面，减少查找、配置和反复输入。 这让我越来越确定：自动化的最高标准，不是“机器替用户做了多少动作”，而是用户几乎感受不到机器在做动作。 ## 从“存下来”到“真的有用” 如果只做到采集，「知言归藏」仍然只是一个更大的聊天记录库。 最初，我曾设想过“项目知识”和“问知识库”：让模型把所有历史都读一遍，再回答问题。但实际使用很快暴露出两个问题。第一，简单的一句话摘要很难代表一段复杂对话；第二，把大量历史塞进上下文，成本高，结果也未必更好。一次智能归类甚至能迅速消耗掉大部分模型额度。 因此，产品没有继续堆叠“万能 AI 问答”，而是开始收敛。 会话可以归入一个主项目，同时拥有多个标签；分类结果允许人工修正和锁定；项目可以创建、编辑、归档、合并，也可以按单个会话或整个项目导出为 Markdown、CSV 或 XLSX。Codex 的工具链调用、插件推荐等过程信息默认折叠，导出时也会被过滤，避免机器过程淹没真正有价值的内容。 报告也从一个“生成按钮”变成了完整流程：按历史日期补生成周报和月报，展示运行状态、进度、错误和重试；报告以中文为主，并直接关联原始会话、项目和标签。与其让 AI 假装无所不知，不如让每个结论都能回到它的来源。 后来的产品形态还加入了全文搜索、附近摘要、项目时间线、标签词云和按需生成的 Project Context。它们不试图代替通用 AI，而是完成一件更具体的事：把分散的对话整理成可检索、可追溯、可继续使用的项目记忆。 ## 一个产品成熟的标志，是开始认真处理“坏情况” 研发后期，讨论的重点明显发生了变化。 我们不再只问“还要增加什么功能”，而开始问：任务卡住时怎么办？按钮为什么没有进度？日志能不能看出来自哪台设备？筛选状态是否可信？模型接口能否先测试？邮件配置是否可用？误删数据如何恢复？为什么数据目录接近 7GB？为什么增量采集还在重复保存历史内容？ 这些看似零碎的问题，最后变成了产品的运行中心、设备管理、日志体系、失败重试、增量存储、备份恢复和安全边界。 自托管也不再只是“把 Docker 跑起来”。系统逐步补上了 TOTP、设备令牌哈希、HTTPS 安全头、上传限流、SSRF 与 DNS Rebinding 防护、入库前和调用大模型前的双重脱敏，以及非 root、只读容器等措施。数据可以集中，但集中不意味着失去控制。 界面也经历了多轮收敛：几百条会话需要更紧凑的列表；项目创建和合并改成弹窗，避免挤占页面；标签需要可搜索，而不是堆在页面末尾；周报应该全宽阅读；运行状态不能把主要内容顶到屏幕下方；版本号、更新摘要、日志来源都要清楚。 这些细节共同把一个“能运行的个人项目”，推向了一个“可以长期使用和维护的产品”。 ## 「知言归藏」：名字是在产品完成之后才真正成立的 到 V2.1 阶段，产品完成了一次重要的体系重构，也终于有了自己的名字——「知言归藏」。 “知言”，是理解人与 AI 在对话中留下的思想、问题和答案；“归藏”，是让它们不再散落，而是回到一个可以长期保存、检索和继续生长的地方。产品的标语也因此确定为： > 汇智能之言，成项目之知。 现在，它的定义已经非常清晰：这是一套个人自托管的 AI 会话归档、历史检索与项目演进系统。它统一保存网页 AI 平台以及 OpenClaw、Codex、Claude Code 的会话，通过 Revision 保留历史，并提供项目、多标签、全文搜索、时间线、Project Context、周报月报、导出和备份恢复。 回头看，这个产品并不是从一份完美的 PRD 开始的。它始于一句很生活化的话：我的 AI 记录存在太多地方，有没有办法把它们都存下来？ 后面的每一步，也不是凭空设计出来的。重复采集带来了幂等和增量修订；跨设备带来了集中存储和设备身份；平台差异带来了独立适配器；模型成本带来了按需分析和可控队列；误删风险带来了备份恢复；难用的页面带来了信息架构重构；对“知识库”的怀疑，反而让产品找到了更克制、更有价值的定位。 这也是我在整个过程中最大的感受：完整的产品，不是功能列表越来越长，而是一个最初模糊的愿望，经过真实使用、失败、取舍和反复修正，最终长出了清晰的边界。 「知言归藏」保存的表面上是聊天记录，真正想留下的，是人与 AI 一起思考过的痕迹。 标签: none
评论已关闭