15-Claude Code 上下文工程与 Memory 系统 —— 让 AI 不再“失忆“

发布时间：2026/6/11 10:06:52

Claude Code 上下文工程与 Memory 系统 —— 让 AI 不再失忆你用 Claude Code 做了一上午的功能开发AI 对你的项目越来越熟。中午吃了个饭回来重开一个会话——AI 又回到了第一次见面的状态。这就是上下文断裂。这篇文章教你如何让 AI 跨会话记住关键信息以及如何管理上下文不让它被污染。上下文五层模型Claude Code 在处理你的请求时实际上有多层信息在同时起作用┌─────────────────────────────────────────────────────────┐ │ 第五层即时层Immediate Context │ │ 当前对话的内容——你说的、AI 回复的、它读的文件。 │ │ 生命周期当前会话。窗口关闭就消失。 │ │ 容量~200K TokenClaude Opus │ ├─────────────────────────────────────────────────────────┤ │ 第四层任务层Task Context │ │ 当前任务的上下文——相关文件、相关讨论、中间产物。 │ │ 生命周期当前任务。任务结束可能就不再需要。 │ │ 容量随任务复杂度变化 │ ├─────────────────────────────────────────────────────────┤ │ 第三层记忆层Memory │ │ 跨会话持久化的关键信息——用户偏好、项目决策、已知问题。 │ │ 生命周期持久化写入文件 │ │ 容量受 MEMORY.md 索引限制200 条但存储无硬上限 │ ├─────────────────────────────────────────────────────────┤ │ 第二层项目层Project Context │ │ CLAUDE.md、AGENTS.md、Skills 配置、项目结构。 │ │ 生命周期随 Git 版本管理 │ │ 容量CLAUDE.md 建议 200 行Skills 按需加载 │ ├─────────────────────────────────────────────────────────┤ │ 第一层系统层System Prompt │ │ Claude Code 内置的系统指令——工具定义、权限规则、格式要求。 │ │ 生命周期由 Anthropic 维护 │ │ 容量固定不可修改 │ └─────────────────────────────────────────────────────────┘每一层的问题和策略层核心问题管理策略即时层容量有限新信息会挤掉旧信息只加载当前需要的内容用完就释放任务层任务切换时上下文残留一个任务一个会话完成就 /clear记忆层写什么、什么时候写、写了怎么找有触发条件地写有结构地存项目层写太多 AI 记不住写太少 AI 乱来精炼到 200 行以内只写决策和约束系统层不可控通过 Permissions 间接影响Memory 五种类型Claude Code 的 Memory 不是一个大文件而是按类型分门别类存储的.claude/memory/ ├── MEMORY.md # 索引文件AI 每次启动都会读 ├── user_role.md # 用户角色和偏好 ├── project_context.md # 项目背景和决策 ├── feedback_*.md # 用户反馈和修正记录 ├── reference_*.md # 外部系统引用Slack 频道、Jira 项目等 └── decision_*.md # 关键决策记录类型一User用户记忆存什么 - 你的角色和背景我是后端工程师前端不太熟 - 你的偏好解释概念时用 Python 示例 - 你的知识盲区异步编程不太熟 什么时候写 - 你明确告诉 AI 记住这个 - AI 发现你反复问某一类基础问题时 - 你纠正了 AI 对你角色的判断 示例 # user_role.md 用户是后端工程师Go/Python前端经验有限。 解释前端概念时用后端类比。代码示例首选 Python。 偏好简洁回复不喜欢啰嗦。类型二Project项目记忆存什么 - 项目的核心目标和架构决策 - 为什么选了 A 技术而不是 B - 已知的技术债和待解决问题 - 重要的里程碑和截止日期 什么时候写 - 重大架构决策之后 - Sprint 计划确定时 - 记录了新的技术债 示例 # project_context.md 项目内部 CMS 系统重构 决策从 Django 单体 → FastAPI 微服务 原因Django ORM 在 50 万行数据下性能不足#42 已知问题旧系统 3 个 API 的调用方还没迁移完 截止日期2026-07-15 MVP 上线类型三Feedback反馈记忆存什么 - 你纠正 AI 的方式不是这样做应该... - AI 犯过的错误和正确的做法 - 你的代码风格偏好 什么时候写 - 你说了不要这样然后给了正确的做法 - AI 的输出被多次修改后才符合你的要求 示例 # feedback_testing.md 规则集成测试必须连真实数据库不要 Mock 原因上次 Mock 的测试全过了但生产数据迁移失败2026-03-15 应用写数据库相关测试时用 Docker 启动临时 PostgreSQL 做测试库类型四Reference引用记忆存什么 - 外部资源的位置不是内容本身 - 相关文档的链接 - 团队频道的引用 什么时候写 - AI 需要知道去哪找而不是是什么时 - 链接了外部资源后 示例 # reference_monitoring.md Grafana Dashboardgrafana.internal/d/api-latencyAPI 延迟监控 Oncall Slack#ops-alerts Jira 项目CMSKey: CMS-xxx Postman Collectionhttps://postman.internal/workspace/cms类型五Decision决策记忆存什么 - 为什么做了某个技术决策 - 考虑过哪些替代方案 - 当时的约束条件是什么 什么时候写 - 每次重要技术决策之后 示例 # decision_cache_strategy.md 决策用 Redis 做 API 响应缓存TTL 5 分钟 考虑过的方案 - 内存缓存 → 放弃多实例不同步 - CDN 缓存 → 放弃API 响应多变不适合 - Redis → 选中团队已有 Redis 运维经验 约束当时的架构还没上消息队列所以没做主动失效 日期2026-05-20MEMORY.md 索引文件AI 启动时不会读所有 Memory 文件——那样 Token 开销太大。它只读 MEMORY.md 索引# MEMORY.md - [用户角色与偏好](user_role.md) — 后端工程师Python/Go简洁风格 - [项目 CMS 重构背景](project_context.md) — Django→FastAPI7 月 MVP - [测试策略要求](feedback_testing.md) — 集成测试用真实 DB不 Mock - [监控相关引用](reference_monitoring.md) — Grafana 面板、Oncall 频道 - [Redis 缓存决策](decision_cache_strategy.md) — 为什么选 RedisTTL 5 分钟每行一个链接 一句话描述。AI 读到这个索引就能判断需要打开哪个 Memory 文件。关键约束MEMORY.md 的前 200 行会被加载。超出部分可能被截断。所以要精简——只保留最活跃的 Memory不常用的归档。上下文污染AI 变笨的三大元凶场景一累积太多无关信息你的会话进行了 2 小时 ├── 开头讨论了数据库选型8000 Token ├── 中间修了一个 CSS 样式 bug3000 Token ├── 然后讨论 API 设计5000 Token ├── 现在在处理用户认证逻辑已经消耗 120K Token └── 上下文里还留着前面三个话题的全部内容 结果 AI 在写认证代码时脑子里还装着 CSS 样式和数据库选型的讨论。 → 它的注意力被分散了 → 认证代码里出现数据库相关的错误假设 → 你感觉 AI 变笨了解决方案一个会话只做一件事。做完了就/clear开始新会话。❌ 一个长会话做完所有事 ✅ 数据库选型 → /clear → CSS 修 bug → /clear → API 设计 → /clear → 认证逻辑场景二错误信息被反复引用第 1 轮AI 生成了一段有 bug 的代码 第 2 轮你指出 bugAI 修复了 第 3 轮AI 在另一个函数里又写了类似的代码 第 4 轮你发现这和第 1 轮的 bug 是同一类问题 原因 AI 在第 3 轮写代码时上下文里既有第 1 轮的错误版本 也有第 2 轮的修复版本。它不确定哪个是最终模式。解决方案修复 bug 后明确告诉 AI 这是新模式你: 这个修复是最终版本。后续所有类似代码都按这个模式写。 → AI 把这个结论记入 Memory → 后续写代码时优先参考这个已确认的模式场景三上下文接近容量极限Token 用量诊断 /status → Context: 185K / 200K (92%) 此时 AI 的行为会变得异常 - 读文件时只能读片段可能漏掉关键上下文 - 生成代码时容易做出不连贯的假设 - 处理复杂逻辑时容易出错 - 但它不会主动告诉你上下文满了解决方案# 如果上下文 80%立即执行/compact# 压缩上下文——去掉已完成的讨论保留关键决策# 或/clear# 清空重来——新会话 重新描述当前要做什么习惯每次做重要决策前先/status看一眼上下文用量。PreCompaction Hook自动归档配合第 12-13 篇的 Hook 知识可以配置 PreCompaction Hook 在上下文压缩前自动保存关键信息#!/bin/bash# hooks/pre-compaction.sh# 在 AI 即将失忆之前把关键信息写入 MemorySESSION_ID$1CONTEXT_SIZE$2PROJECT_DIR$3MEMORY_DIR$PROJECT_DIR/.claude/memorymkdir-p$MEMORY_DIR# 保存当前任务进度echo## 会话$SESSION_ID压缩记录$MEMORY_DIR/session_archive.mdecho- 压缩时间:$(date)$MEMORY_DIR/session_archive.mdecho- 压缩前上下文:$CONTEXT_SIZEToken$MEMORY_DIR/session_archive.md# 引导 AI 在压缩前输出关键决策摘要echoecho 上下文即将压缩当前${CONTEXT_SIZE}Tokenecho 请在压缩前确认以下内容已保存到 Memoryecho - 本次会话做的重要决策echo - 待继续的未完成任务echo - 新发现的已知问题echoexit0跨会话知识持久化实践策略一每次会话结束时做脑转储会话结束前的 2 分钟问 AI 在结束前列出这次会话的 5 个关键产出 1. 做了什么1-2 句话 2. 做了什么决策为什么 3. 有什么没做完的事 4. 有什么新发现的坑 5. 下次会话第一件要做什么 AI 的输出直接写入 Memory 或会话笔记。 下次启动时 AI 读到这些就像从未断过。策略二决策即记录不是工作了 3 小时然后总结而是每做一个决策就立即记录 这个 API 用 POST 还是 PUT 用 PUT因为它是幂等的更新操作。 好记住这个决策用户信息更新用 PUT /users/:id 理由是幂等性。因为前端可能会重试请求。 → AI 写入 decision_api_methods.md → 下次讨论 API 设计时AI 自动引用这个决策策略三Memory 的定期清理每月花 5 分钟清理 Memory □ 过期的决策技术栈换了、截止日期过了 □ 已解决的已知问题 □ 不再活跃的外部引用 □ 重复的记录不同文件里记录了同一件事 清理的好处 - MEMORY.md 索引更短AI 加载更快 - 不会出现过期的信息误导 AI - 留下的都是真正有用的上下文上下文工程的原则总结1. 分层管理 → 项目级的放 CLAUDE.md全团队共享 → 跨会话的放 MemoryAI 自动读取 → 当前任务的放即时上下文会话结束就释放 2. 精炼优先 → Memory 索引不超过 200 行 → 每个 Memory 文件不超过 500 字 → 一句话能说清的决策不要写三段 3. 及时清理 → 上下文 80% 就 /compact 或 /clear → 会话结束后 2 分钟脑转储 → 每月清理过期 Memory 4. 决策即记录 → 不是做完总结而是做了就记 → 记录决策的理由不只是结论 → 后续的 AI 才能理解为什么而不只是是什么延伸阅读Claude Code Memory 文档