让 Claude Code 不再失忆：基于 Obsidian 的会话管理机制实现
这是“如何让Claude Code真正好用，0门槛的使用指南”系列的第一篇
这是“如何让Claude Code真正好用，0门槛的使用指南”系列的第一篇，我们不说虚的，用最通俗的语言，最简单的方法，解决普遍存在的问题。技术应该平权，每个使用者都有让工具更好用的权利。如果对你有帮助，请点点关注~
以下进入正文：
用 Claude Code 桌面端的人，应该都有这种感觉：和它聊两小时搞清楚一个问题，关掉窗口，第二天再打开，一切归零。
这篇讲怎么解决这件事——几个本地脚本，把对话原文归档到 Obsidian，双向可同步。不装向量库，不跑后台进程，不调 AI 做摘要。存量 135 个历史会话一次性归档，之后每次对话自动入库。
01 失忆到底是怎么回事
「没记忆」听起来像个模糊的抱怨，拆开其实是四件很具体的事。
**第一件，桌面端重启后没有会话入口。**关掉窗口再打开，侧边栏不会列出本地已有的历史会话——每次看到的都是一个崭新的对话框。你的对话数据其实还在本地硬盘，躺在 ~/.claude/projects/ 下，但桌面端没有给使用者一个可以点进去看、或者接着聊的入口。
**第二件，桌面端没有 resume 命令。**所有 / 开头的斜杠命令在桌面端不可用。CLI 用户可以敲一句 claude --resume 拉出历史列表来选，桌面端用户没有这个能力。
**第三件，md 档案不完整。**你让 AI 帮你总结出来的 md 是二次加工，关键细节、被否决的方向、反复讨论的卡点，全部在压缩里丢掉了。
**第四件，jsonl 文件你打不开。**对话原文虽然在硬盘上，但这是机器格式，一行一个 JSON，人眼没法直接读。
四件事加起来，就是每次关掉桌面端都是一次失忆。
往深一层看，问题不是「Claude 没记忆」，而是数据还在，但既没入口又不可读。向量索引解决不了这些。
02 CLI 的 resume，为什么还不够
有人可能会说：桌面端没有 resume，CLI 不是有吗？claude --resume 能列出所有历史会话选一个接着聊，确实能解决一部分问题。
但即便愿意为了记忆切到 CLI，这个方案也只解决了一半。几个常见痛点：
**只能恢复单个会话，不能跨会话综合。**一个项目往往不是一次搞完的，前面讨论需求、中间拉代码、后面联调，常常分散在三四个会话里。resume 只能挑其中一个回去，跨会话的共识、被否决的方案、整条脉络的前后呼应，仍然各自躺在自己的 jsonl 里。
**每次恢复都是整会话全量载入。**resume 把一个会话的完整上下文全部读回来。你想接着聊的可能只是其中一段，也只能把整个历史都扛进去，token 消耗没得挑。
**它是 CLI 的能力，不是所有人的习惯。**resume 只在命令行环境可用。非开发者出身的使用者——PM、内容工作者、研究者，日常并不常驻终端。为了「回去接着聊」专门打开 CLI，既不直观也不自然。
所以 resume 只是局部解。真正要解决的是：一个可读的入口 + 按需取的能力 + 跨会话的视野。这些 CLI 本身都没有。
03 为什么不选 claude-mem
那换一个更重的方案呢？GitHub 上有个开源项目叫 claude-mem，定位是 Claude Code 的「自动记忆插件」——捕获每次工具调用，存进本地向量库，下次对话按需检索。
听起来像答案。但真要装之前，有几个隐形成本要想清楚。
环境依赖挺重：要装 Bun、uv、Chroma 三件套，还要跑一个常驻后台 worker。中文 embedding 检索质量项目方没给过数据。每次会话结束都调一次 AI 做摘要，即便选 Haiku 也是一笔长期的基线花销。worker 挂了、schema 迁移失败，都得自己排查。
更根本的问题是——它抓的是工具调用，不是对话内容。
钩子只在工具调用后才触发。纯对话里你说的话、AI 的反问、哪些方向被否决，这些不落盘就进不了库。对做开发的人价值大（大量 Read/Edit/Bash）；对以访谈、策划、教学为主的工作，能记的东西有限。
还有一个硬约束：通过 claude.ai 账号登录的 OAuth 用户没有独立 API key，跑不了它那套摘要流程。
claude-mem 不是不好，是和这个场景不合适。
04 方案：把 jsonl 转成 md，用 Obsidian 看
思路一句话：把 jsonl 自动转成可读 markdown，扔到 Obsidian 里，用 Obsidian 自己的全文搜索和反向链接做检索。
不装向量库，不跑后台进程，不调 AI 做摘要。
存储放在 ~/.claude/sessions-md/ 下，这个目录当成一个 Obsidian vault，所有归档 md 在里面，按项目分文件夹。数据源 jsonl 永远只读。分类不调外部 AI——当前会话的 AI 对上下文最清楚，让它在会话结束时直接把分类写进本地文件。基线 token 消耗为零。
整套系统按三层职责分工。
1 | `索引层 MEMORY.md ~200 行，永远自动加载 |
三层不是冗余，是递进——原始层管「全」，策划层管「精」，索引层管「轻」。AI 每次启动只读索引层，像翻目录页。需要深入才读策划层。只有精确回溯才去原始层翻。
拿图书馆打比方：索引层是借书卡，策划层是分类摆放的书架，原始层是整个库藏。库藏不可能全搬回家，但你知道去哪找。
05 怎么实现：几个脚本和几个设计点
整套系统是六个 Node 脚本，大概 800 行代码。核心逻辑其实就三件事。
第一件，把 jsonl 转成 md。
archive-convert.js 做的事：读 jsonl 每一行，按对话格式写成 md，工具调用这种中间过程默认过滤掉（只保留人能读懂的内容），生成的 md 头部带一段 YAML 元数据。
第二件，双向同步。
每个归档 md 头部都有一个 session_id，作为系统和这个文件的唯一绑定。
1 | `--- |
你在 Obsidian 里怎么折腾——移动、重命名、删除——都不影响这个 ID。archive-sync.js 会扫所有 md 的 frontmatter，反向更新索引。而且默认已有的 md 只生成不覆盖，你在 Obsidian 里的手动编辑不会被下次同步抹掉。
第三件，预分类。
这是整套系统里最容易被忽略、但最省 token 的设计。
原来的做法：今天聊完关窗口，明天打开新会话，AI 要先读历史 jsonl 前几条消息，推断「这个会话该分到哪个项目、起什么标题、一句话摘要是什么」——花的是明天的 token，而且只看到开头，推断还不准。
优化后：今天聊完说「归档」的那一刻，当前会话的 AI 最清楚这个对话讲了什么，它直接跑一条命令把分类写进本地文件。明天的 AI 看到已分类，直接生成 md 完事，零推断成本。
今天多一条 bash 命令（几乎不花 token），换明天省几千 token 的推断。
06 桌面端的约束：用自然语言触发
前面讲过，桌面端不能跑斜杠命令，不能配 hook，不能进 shell。要让这套系统在桌面端可用，就不能依赖命令触发。
解法是用 AI 的 Bash 工具作为中间层。你用自然语言告诉它，它自己跑脚本。
说「归档」/「再见」/「下次继续」——AI 预写当前会话分类，用得最多。
说「上次聊 X 的会话」——AI 读摘要文件，列出候选会话。
说「合并 A B C 会话」——AI 按时间线合并，原文软删除。
说「删掉 XX 对话」——md + jsonl 一起移到 trash。
说「重建归档」——强制重生成所有 md，出问题时用。
下次启动时——AI 自动扫未归档 + 反向同步 Obsidian 变更，无需手动触发。
日常其实只需要记住三条：聊完说「归档」，要彻底删了说「删掉 XX」，想重建全部说「重建归档」。
桌面端的约束不是 bug，是提醒——真正的好工具，不应该依赖特定平台命令。
07 怎么找回历史对话：按需取，分四层
归档下来 100 多个会话，每个平均一万 token，全部读进上下文既不现实也没必要。按需读取分四层：
L0（消耗：0）——直接打开 Obsidian 自己翻，不需要 AI 介入。
L1（消耗：~5K）——让 AI 读项目摘要文件，列出相关候选会话。
L2（消耗：~2K）——让 AI 读某个会话的头部元数据，确认是不是要找的那个。
L3（消耗：~1-2K）——让 AI 用 Grep 在会话原文里搜关键词，定位到具体段落。
极限用法——你在 Obsidian 里找到那段话，复制过来直接贴给 AI。消耗最低，精准度最高。
比如你说「继续聊上次某个项目的接口问题」——AI 先读项目摘要（2K），列 3 个相关会话；你选一个，再读那个会话的头部摘要（1K）确认；如需具体细节再 Grep 定位（~2K）。
总计 5K token 覆盖「从哪些会话里挑 → 确认是哪个 → 看到关键细节」。
对比一下：全量读整个项目文件夹是几十万 token 起步，直接把 context 打爆。这套按需取的基线是 0，用时 5K 起步。
08 日常怎么用
聊天习惯不用改。正常打开 Claude Code，想聊什么聊什么。
结束时说一句「归档」，AI 把当前会话的分类写入本地文件。花几百 token。
下次打开新窗口，AI 自动跑两步：扫昨天有没有漏归档的会话（有就自动转 md），然后反向同步 Obsidian 的变更（你删改过的 md 反向更新到索引）。
这两步的成本完全透明——无变化时大概 10 token，有删改大概 30 token，有新会话未归档大概 100 token。然后开始今天的对话，昨天的上下文完全不进入今天的 context，互不干扰。
09 几条不妥协的原则
整套系统的底线，当时讨论时想清楚的，事后回头看更觉得重要。
**原文永远不碰。**所有脚本只写 md，不改 jsonl。任何「为了方便起见动了原文」的设计都是埋雷。
**索引可以重建。**manifest 丢了不可怕，扫一遍 md 就能重建出来。任何「丢了索引就找不回数据」的系统都不合格。
**删除都是软的。**移到 trash 目录，永不自动清理，要硬删必须显式说。软删除是使用者的定心丸。
**分类由当前 AI 写，不等下次 AI 推断。**同一件事，现在做比以后做又准又省。
**系统不跑时不花一分 token。**跑起来每一步都可见、可预测。可预测性本身就是价值——这是和「自动注入记忆」这种黑盒方案最大的区别。
10 可复用的几个判断
这套方案解决的是一个看起来很窄的问题——如何让一个不可回溯的工具获得可回溯的记忆。剥开看，有三个可迁移的判断。
**痛点要说到最具体。**最开始以为问题是「Claude 没记忆」，差点装 claude-mem。真正说清楚才发现，是「数据既没入口又不可读」。前者是抽象需求，后者是具体数据问题。抽象需求会被复杂工具吸引，具体数据问题往往有最简解法。
**好的架构是分层的。**原始、策划、索引三层分工，每一层只回答一个问题：要全、要精、要轻。混在一起的系统一定会在某个维度失衡——要么体积爆炸，要么细节丢失，要么找不到东西。
**最好的工具不求智能，求可预测。**不做向量检索，不调 AI 摘要，不跑后台进程。但它每一个动作都清楚、可见、可回滚。可预测性就是价值本身。
写在最后
有人一直以为，工具越「智能」越好。但真正好用的工具，往往是那种你完全看得穿、完全控制得住的工具。
向量库会漂移。常驻进程会崩。自动摘要会丢关键细节。每一层「智能」都是一层黑盒，而黑盒是使用者的负担，不是福利。
真正的记忆，不是替你记住，是让你能自己找回。
再往下推一层。
Claude Code 的 CLI 确实强大——hook、slash 命令、session resume、settings.json 里精细的权限控制——每一条拿出来都是开发者喜欢的能力。但这些能力都有一个默认前提：你愿意、并且习惯在终端里工作。
现实是，越来越多的使用者不是开发者。PM 用它做调研和整理，内容创作者用它改稿，老师和学生用它学习。对他们来说，桌面端就是入口，不是「CLI 的降级版」。桌面端缺了一角，他们面对的不是「去学 CLI」，而是「放弃这个能力」。
工具的使用成本，不该由使用者承担。
这套机制的本意其实很简单：让一个不进 CLI 的人，在桌面端也能获得「回得去、找得到、翻得开」的体验。算不上完美，但至少证明这件事可以做，也应该做。
希望有更多人把桌面端使用者放在心上——他们不是能力更弱的使用者，是应该被正式对待的使用者。
所以这套系统的本质不是「让 Claude 不失忆」，是让你不失忆——Claude 不过是一个协作者，被你调用、被你校准、被你引导。对话的价值属于你，归档的方式应该由你决定。
从这个意义上说，最好的 AI 协作系统，最不该依赖 AI；最好的桌面端工具，最不该依赖 CLI。
调研 & 撰写：AI（Claude）、墨染
主导 & 审校：墨染
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，请给我个星标⭐～谢谢你对文章的认可，我们，下次再见。
💬 本文评论区已开启，但暂无读者留言。
本文转载自微信公众号，如有侵权请联系删除。
- 标题: 让 Claude Code 不再失忆：基于 Obsidian 的会话管理机制实现
- 作者: lxiol
- 创建于 : 2026-04-29 20:25:17
- 更新于 : 2026-05-12 16:32:44
- 链接: https://blog.lxiol.cn/2026/04/29/让-Claude-Code-不再失忆基于-Obsidian-的会话管理机制实现/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。