Claude Code 记忆系统真实运作：200 行索引上限如何在生产项目中制造沉默遗忘

你在 Claude Code 里连续迭代同一个项目三个月，它“记住”了你的编码偏好、一月敲定的架构决策、那个永远别在测试里碰的 flaky endpoint，还有团队热修复跳过 PR 的默契。直到某一天，你让它写一个新测试——它偏偏就去调了那个已知不稳定的 endpoint；再问它 PR 策略，它又把你上个月明确否决的方案重新端上来。

表面上看，Claude 依然在本地存着记忆文件，可实际表现却像彻底失忆。
我起初以为 Anthropic 给 Claude Code 配的记忆层已经是生产就绪的成熟设计，后来直接去挖 leaked 的 src/memdir/ 源码，才发现整个架构其实建立在一个极其简洁、也极其脆弱的 v1 实现上：纯 Markdown 文件 + 200 行硬上限 + 零向量检索。

Claude Code 到底把记忆存在哪里

所有记忆以普通 Markdown 文件形式落在磁盘：
~/.claude/projects/<你的仓库名>/memory/

每个项目独立目录，每轮对话都可以往里写，文件跨会话持久化。这就是全部的持久化模型。
目录根目录还有一个 MEMORY.md 索引文件，每次会话启动时 Claude 都会先读它，搞清楚当前有哪些记忆可用。

200 行 + 25KB 的双重硬上限

源码里写得清清楚楚：

• MEMORY.md 最多 200 行，超出一行就静默截断；
• 同时还有 25KB 字节上限，防止单行过长把文件撑爆。

截断后系统会在文件末尾追加一行警告，但这个警告只对人类可见——Claude 拿到的 system prompt 是干净的，它根本不知道索引被砍过。
于是第 201 条记忆直接从索引里消失，Claude 下次启动时就“看不到”它。没有报错，没有日志，没有任何外部信号。

四种记忆类型与严格的“可派生则不存”原则

源码明确限定了四类记忆：

• User memories：你的角色、专长、沟通偏好（仅自己可见）
• Feedback memories：你给过的纠正、验证过的做法、明确要停止的行为
• Project memories：代码本身无法通过 grep/git 推导的上下文（deadline、架构决策）
• Reference memories：外部系统指针（bug 跟踪链接、要盯的 Slack 频道）

核心规则写在代码里：凡是能从当前代码库里 grep 出来的信息，一律不许存成记忆。避免冗余，也避免内存膨胀。

每轮对话的 Sonnet 侧调用

每次用户发消息，Claude Code 都会额外调用一次 Claude Sonnet，任务只有一件：
把所有记忆文件的文件名 + 一行描述打包发给 Sonnet，让它挑出最相关的 5 个文件。
没有 embedding，没有向量检索，就是纯语言模型读列表做判断。
5 文件上限也是硬编码的。

记忆新鲜度警告与后台提取 Agent

源码里有个memoryFreshnessText()函数，对超过一天的记忆自动插入一段警告：
“This memory is X days old. Memories are point-in-time observations, not live state…”

这段警告直接塞进记忆内容里，Claude 能看到，但你看不到哪些记忆触发了它。
此外还有一个后台的 extract-memories Agent，在对话结束后自动审视整轮会话并提取记忆。主 Agent 和后台 Agent 同时往同一个目录写文件，形成了双写机制（部分 feature flag 控制，未对所有人开启）。

TEAMMEM 团队记忆开关

开启后部分记忆变成团队共享（项目约定、规范），个人偏好仍保持私有。源码里已经为多开发者协作预留了空间，只是默认关闭。

200 行记忆悬崖的真实杀伤力

想象一个真实场景：
项目跑了三个月，积累了 210 条记忆。
第 201 条开始，索引静默截断，最老的记忆（往往是最初的架构共识、最早的 flaky 警告）直接消失。
Claude 下次启动时加载的 MEMORY.md 只有 200 行，它“以为”自己知道一切，却对一月前的关键决策一无所知。
于是它开始：

• 重新问你 PR 审查政策
• 再次把已废弃的架构方案端上来
• 写出调用已知不稳定 endpoint 的测试代码

它不是在幻觉，它只是被系统设计“合法”地遗忘了。
更狠的是：新鲜度警告只对被加载的记忆生效，被截断的记忆连加载机会都没有——零信号。

类比一：200 页的笔记本

你有一本只有 200 页的笔记本，记满了就从最前面撕掉一页，再继续往后写。被撕掉的那页你永远不知道丢了什么，笔记本本身也绝不会提醒你“这本子已经满过”。

类比二：只有 5 个抽屉的文件柜

每次需要资料，你只能拉开 5 个抽屉，让一个助手（Sonnet）凭文件名快速判断哪个最相关。柜子里的抽屉总数超过 200 个后，最底层的永远拿不到——助手甚至不知道它们存在过。

Claude 原生记忆 vs mem0 插件决策矩阵

为什么说这是 v1 该有的样子，却也是该被替换的时刻

Claude Code 的内存设计极其克制、极其干净：四类记忆、严格的可派生原则、新鲜度警告、后台提取……它把“先把事情做对”这件事做到了极致。
但真实生产环境里，项目记忆从来不是 200 行就能封顶的。当你真正把 Claude Code 当作长期协作伙伴时，那条 200 行悬崖就会在你最需要历史上下文的时候突然出现。

mem0 插件正是为这一刻准备的。它把整个 ~/.claude/projects/… 目录替换成向量存储层：

• 安装两条命令即可完成切换
• 后续所有 add_memory / search_memories / update_memory / delete_memory 都走语义检索
• 六个月前的记忆，只要相关，就能被精准召回

不再有索引文件，不再有截断，不再有“Claude 以为自己知道一切”的假象。

在生产环境落地前你必须先做的三件事

1. 把当前项目目录下的 memory/ 文件夹完整备份（防止切换后想回滚）；
2. 安装 mem0 插件并用mem0 auth拿到免费 API Key（或自托管开源版）；
3. 先在非核心分支跑一次完整对话，验证新旧记忆召回一致性，再全量切换。

当记忆层真正成为可组合资产之后

Claude Code 的原生记忆是 Anthropic 给开发者的第一块积木——它足够好，让你立刻感受到“AI 真的在帮我记事”。
但当项目进入第二个月、第三个月，甚至跨团队协作时，你需要的已经不是“记事”，而是“可靠、可查询、可演进的长程记忆”。
把这层从 Markdown 升级为向量检索，不是在否定 v1，而是在 v1 撞墙之后，用最小的改动完成生产力跃迁。

你当前的项目记忆已经撞到 200 行天花板了吗？

欢迎在评论区分享：你在 Claude Code（或 Cursor / Windsurf / 其他本地 Agent）里遇到过“突然忘记历史决策”的情况吗？切换到向量记忆层之后，你的实际体验提升了多少？
我们一起把这个记忆工程话题继续推深。

（本文基于 @mem0ai 在 X 上的源码深度拆解整理，原帖已完整公开 Claude Code memory 目录的实现细节。mem0 插件已开源，GitHub 仓库可直接 star 并自托管。）

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。