为 Claude Code 构建双层记忆 + Todo 数据库

你在笔记本上打开 Claude Code，它不知道昨晚你在家里那台服务器上改了什么。要花十分钟把 context 重新粘贴进去，然后 rate limit 中途打断，两小时后 context 消失得一干二净。

两个 setup 刚刚公开，说明缺失的既不是 prompt 也不是插件，而是 assistant 周围的基础设施：task 的事实来源、分层的记忆系统、一个开/关 session 的 routine，以及一个 token 计数器。本文逐一拆解，并附上你一个晚上就能搭起来的方法。

为什么 TODO.md 在你有第二台电脑的瞬间就死了

第一个 setup 的作者在五台机器的 "fleet" 上跑 Claude Code 达五个月之久——Proxmox 主机、Linux 服务器、几台笔记本、一台台式机，甚至还有一部在终端里跑 Claude Code 的 Android 手机。在这种规模下，最先崩溃的常见方案是："大多数 AI task 的 setup 都是一个由模型编辑的 markdown 文件。对一个人一台机器来说挺好用；一旦有两个 session 同时跑，或者你在手机上记了一个 task 但笔记本需要看到它，就垮了。"

他们的替代方案是一台服务器上的 SQLite 数据库，后面接一个带 auth 的 API，再加上一个 append-only event log——每次 add、close、edit、note 都记录谁做的、什么时候、为什么。最关键的是数据方向："TODO.md 文件仍然存在，但作为生成的只读镜像。Claude 不能手动编辑它们。数据库是真相；markdown 是它的一个视图。"

这个反转正好卡住了让你头疼的问题：两个并行 session 不会互相覆盖，在手机上记的 task 笔记本上也能看到。各台机器处于同一个 Tailscale tailnet，所以 CLI 在哪里都能调用数据库。

两层记忆系统：index 始终加载，详细内容按需加载

这部分即使你只有一台机器也能直接用。根本问题在于："Claude Code 把 instruction 文件加载到每个 session，而 context 是一个预算。常见的做法——一个不断膨胀的'记住这件事'文件——悄无声息地失败了：它臃肿到部分内容停止加载。"

他们使用的结构有两层清晰的分层：

始终加载的那层——global instructions 加上一个 memory index，"每条 memory 一行，包含标题和一句话的 hook。百余行，严格修剪，因为每一行在每个 session 都要付账。"

按需加载的那层——一个存放各类 memory 文件的文件夹：preferences、project state、runbook，以及用血换来的 correction。文中举例："never rsync --delete to a server"——记录的是某天一个 --delete flag 误删了十九个文件的那一幕。文件只在相关主题出现时被读取。

陷阱在于修剪环节："模糊的行永远不会被取到，行太多会撑爆预算，过了硬上限 index 会毫无预警地丢弃自己的尾巴。它只是悄悄忘记了。"也就是说，一个膨胀的 index 不会报错——它只是默默遗忘末尾部分。如果你正在把所有东西塞进一个单一的 instructions 文件，这就是该拆分的信号。

单独分析：第二层的价值在于错误历史，而不是"最佳实践"。一句"不要 rsync --delete 到服务器"是从任何地方都下载不来的。

两个命令的 routine：开 session 和关 session

工作 session 有固定形态，所以这个 setup 把这个形态变成了脚本。开启命令："Typing go pulls the dotfiles, re-runs the bootstrap and syncs every project repo — flushing the offline todo queue, regenerating the mirrors, and checking the servers for uncommitted drift on the way."

关闭命令不是开启命令的反面。按照文中所说："go restores a known-good state, fin captures what changed"——它更新所有刚改变主题的 doc（changelog、project state、相关 spec），reconcile 掉 todo flag，写一个 resume point，用 commit hash 作为原因关闭已完成的 todo，然后 commit、push 并 sync 出去。

有两个细节值得记录：

Resume point 是一个锚定在项目 doc 中的 comment，并有脚本为之建立索引——"任何机器上的任何 session 都能列出最新的 open 项并接起半成品工作。关闭关联的 todo，resume point 随之退役。"

Routine 附带时间测量：一个 timer 包装在每次 go 和 fin 周围，把 duration 推到一个中央 store，以便当某一步开始变慢时，数据能指出是哪一步。

配套的 guard rail 有一个 pre-commit hook 拒绝 commit 直到 changelog 被 stage，以及一个 deploy 在真正的浏览器上看过 dev 版本之前不会触碰 live site。作者说在写文的示例 repo 时，那个 hook 拦住了他们自己两次。

不要让 rate limit 在 session 中途切断你

第二个 setup 从开篇那个切肤之痛开始："六周前我在一个 debug session 中途被 Claude 的 rate limit 毫无预警地切断了。两小时的 context 没了。"结果是做了一个 Chrome extension MV3，把 token 进度条直接插在 Claude、ChatGPT、GitHub Copilot、Claude Code、DeepSeek 和 Grok 的输入框上，从已有的浏览器 session 读取，无需 API key。

对想自己搭的人来说，值得注意的技术细节：作者指出，"Claude 是唯一通过其内部 API 暴露真实 rate limit 数据的平台"——usage 端点返回 utilization 和 reset timestamp，格式为 five_hour/seven_day，即真实数字而非推测。其余平台只能从对话 DOM 中估算 token，作者称误差大约"±8%——足以知道自己是到了 context window 的 20% 还是 80%。"

默认警告阈值是 75%、90% 和 100%，每个阈值只在越过时触发一次，usage 回落时重置。维护风险也被直说了：Claude、ChatGPT 和 Gemini 的 DOM 会不经通知地变化，今天的 selector 到下周就坏了，所以需要多个 selector fallback 和防御性访问用 ?..。

今晚能搭什么

以下顺序是按机器数量的分析性建议，不是原始作者的建议——按你正在使用的机器数量选择：

一台机器：把正在膨胀的 instructions 文件拆分成每条 memory 一行的 index 加上详细内容的文件夹。这是成本最低的改动，正好阻止"悄悄遗忘"这个错误。

两台及以上机器：把 config、memory 和 script 放进一个 repo，配一个单一的 bootstrap script。原始 setup 让空白机器在十分钟内进入工作状态。

多个并行 session：放弃 markdown 作为事实来源，搭一个可查询可审计的 store。

经常在 session 中途被切断：在优化 prompt 之前先接上 usage 指示器。

值得持续关注的一点：第一层 index 是这个架构中最容易损坏的地方，因为它超出阈值时不会发出任何错误。在它自行截尾之前，设一个定期检查来计数 index 行数。

---