分清Claude Code的上下文与记忆

我反复看到一种情况（我自己也一直这么干）：Claude 忽略了某条规则，于是你打开 CLAUDE.md，重新措辞。换成更强硬的动词、全大写，再加上一两句警告。但什么都没改变——因为这个文件压根就没有进入 context window。你一直在修改一份根本没人读取的文档。

Claude Code 有两个经常在这里被混为一谈的 slash command，但它们回答的是不同的问题：

/context 回答：究竟有哪些内容真正进入了当前 session？

/memory 回答：未来的 session 应该从哪些内容开始？

一个用于审计，另一个用于编辑。混淆两者，你就可能浪费整整一个下午，反复打磨一段从未被加载的文字。

在 session 进行到一半时运行 /context，你会看到当前有哪些内容正在占用 context window——其中包括一份 Memory files 列表，显示实际加载了哪些 CLAUDE.md 文件（以及你的 auto memory 索引）。

在修改任何文件之前，都应该先运行这项诊断。官方文档明确强调了验证步骤：设置好项目级 CLAUDE.md 后，“要确认文件是否已加载，请在 session 中运行 /context，并检查 Memory files 下的列表。”

这很重要，因为并非每个 CLAUDE.md 都会在启动时加载。项目根目录及其上级目录中的文件会被完整加载；子目录中的文件则采用 lazy load，只有当 Claude 读取该目录中的内容时才会加载。位于 packages/api/CLAUDE.md 的规则，在 session 触及这个子树之前都是不可见的。如果你从未在 /context 列表中看到嵌套目录里的文件，那么问题从来都不在措辞上。（我在《Claude Code 到底会加载哪些 CLAUDE.md 文件》中深入介绍了加载顺序，也在《Claude Code 真的加载了你的规则吗？》中讲解了如何发现静默加载失败。）

/memory 会打开 memory 文件选择器，其中包含适用于当前项目的各个 CLAUDE.md scope（用户级 ~/.claude/CLAUDE.md、项目级 ./CLAUDE.md 或 ./.claude/CLAUDE.md、本地 CLAUDE.local.md），以及 auto memory 开关。

这里有两点很容易被忽略：

它编辑的是下一个 session 将加载的内容，而不是当前已经加载的内容。指令会在 session 启动时进入 context。在 session 中途编辑 memory 文件，并不会把修改后的内容追溯注入当前 context。

你选择的 scope，比写下的具体文字更重要。把个人偏好写进项目级 CLAUDE.md，会将它推送给整个团队；把团队约定写进用户级文件，则会让你的配置在不知不觉中与同事产生分歧。如果你不确定某项内容应该放在哪里，我在《CLAUDE.md 里到底应该放什么？》中整理了一套分类规则。

用六十秒了解 Auto memory

/memory 管理的第二项内容，是 Claude 自己写入的 memory——它会主动记录关于项目的信息，例如构建命令、调试心得，以及你重复纠正过两次的问题。

根据文档，其工作机制如下：

位置：~/.claude/projects/<project>/memory/，其中项目路径根据 git repository 推导，因此同一 repo 的所有 worktree 共享同一个 memory 目录。它只保存在本机，不会同步。

结构：一个 MEMORY.md 索引，以及可选的主题文件（debugging.md、api-conventions.md 等）。启动时只会加载索引；主题文件则按需读取。

真正值得了解的是加载上限：MEMORY.md 的前 200 行或 25KB（以先达到者为准）会被加载到每个 session 中。超过该阈值的所有内容都会被静默忽略。Claude Code 会提示模型保持索引简短，并将详细信息放入主题文件；从 v2.1.211 开始，统计时会先剔除 YAML frontmatter 和 HTML comments。

开关：/memory 面板会把 autoMemoryEnabled 写入用户设置；项目也可以在自身设置中使用相同的 key 来选择退出，还可以通过环境变量 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 将其彻底禁用。如果希望存储在其他位置，可以使用 autoMemoryDirectory 更改存储目录。

相比之下，CLAUDE.md 没有加载上限——无论多长，都会被完整加载。这是一把双刃剑：一方面不会有任何内容被截断；另一方面，也没有任何机制阻止你发布一个 900 行的文件，进而降低其中所有指令的遵循效果。

我实际采用的对应关系如下：

这两种机制都属于 context，而不是 enforcement。文档说得很直白：Claude 将 memory “视为 context，而非强制执行的配置”。一条规则即使已经加载、在 /context 中得到验证、措辞也无可挑剔，仍然可能在实际执行时败给更强烈的即时驱动力。对于绝对不能发生的事情，答案并不是在这两个文件中写出更好的文字，而是使用 PreToolUse hook，以机械方式阻止该操作。我在《Claude Code hooks 详解》中完整演示了这套配置方法。

/context 告诉你现在真实加载了什么。/memory 改变明天会加载什么。至于那些不能依赖二者的关键事项，则应该交给 hooks。

我维护着 Rulestack——一套面向 Claude Code、Cursor 和 Codex，经过测试的规则包、skills 与模板。

我每天都会在 Bluesky 上分享有关 AI coding agents 的笔记：@ai-shop.bsky.social

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。