跳转到主要内容

Claude Code 架构 · Layer 1:长期上下文层(CLAUDE.md / Memory)

2026年6月16日
10 分钟阅读
AI
LLM
Claude
Agent
上下文工程

Layer 1：长期上下文层

在六层架构中的位置：最底层，告诉 Claude "你是谁、在哪个项目、有什么规矩"。每次对话自动加载，是 CC 的"性格设定"和"工作手册"。

前置阅读：00-总览与主线地图.md（三条主线的关系）

关联层：Layer 2（工具能力）和 Layer 3（Skills）都建立在 Layer 1 的基础上。Layer 1 定义"是什么"，Layer 2 定义"能做什么"，Layer 3 定义"怎么做"。

一、一句话理解

长期上下文 = 每次对话自动加载的背景信息。 包括 CLAUDE.md（全局/项目级规则）、Memory 文件（跨会话记忆）、rules 配置。

这是 CC 系统的地基。如果 Layer 1 写得好，CC 在任何会话中都知道该用什么技术栈、该遵守什么规矩、该注意什么偏好。如果写得差，你每个会话都要重复交代一遍"用 Streamlit 不用 React""Python 用 miniforge3"。

二、三层体系

你现在有一个清晰的三层上下文体系：

2.1 全局 CLAUDE.md（~/.claude/CLAUDE.md）

作用：所有项目、所有会话都会自动加载的通用规则。

目前内容：

区块内容估算 tokens
核心规则先描述方案再执行、列问题建议测试~200
协作模式教练+助手、多问多讨论多教~300
行为规范需求理解、决策格式、任务执行、重构操作~500
技术栈规则Streamlit、Python miniforge3、pnpm~150
路径规范标准路径表、已废弃路径~300
短规则包管理器、Skill 结构、文档存放等~200
合计~1.5-2K

好的地方：

  • 规则是"可执行的"而非解释性的。比如"技术栈用 Streamlit"直接告诉 CC 该做什么，而不是"我们有时候用 Streamlit 有时候用 React"
  • 有"禁止行为"清单，明确什么不该做
  • 路径规范统一，避免 CC 把文件写到错误的地方

写 CLAUDE.md 的原则：短、硬、可执行。

好规则坏规则为什么
"技术栈用 Streamlit，不用 React""我们的技术栈比较灵活，通常用 Streamlit"好规则没有歧义，CC 不需要判断
"任务超 5 分钟必须拆分""大任务建议拆分"好规则有量化标准
"Python 用 /Users/tianli/miniforge3/bin/python3""用系统 Python"好规则指定了绝对路径

经验法则：如果一条规则在 3 个以上的会话中都要用到，就该写进 CLAUDE.md。如果只在某个会话中用一次，别写进来——直接在会话中说就行。

2.2 项目级 CLAUDE.md

作用：某个项目特有的规则，只在该项目目录下启动 CC 时加载。

示例：你的 ~/Work/zdwp/CLAUDE.md 包含：

  • PARA 目录结构规范
  • Git 策略（commit 规则、分支命名）
  • 水利行业特有的业务约束

全局 vs 项目级的分界线：

规则放哪里判断依据
"用 Streamlit"全局所有项目都适用
"PARA 目录结构"zdwp 项目级只有水利项目用 PARA
"禁止 bullet point"全局（如果所有公文都要求）或项目级看适用范围
"投标单位名称禁止出现"项目级每个项目的投标单位不同

2.3 Memory 文件

作用：跨会话的"记忆"，CC 会自动读取。

你的 Memory 路径：~/.claude/projects/-Users-tianli/memory/MEMORY.md

目前内容：

  • 工作追踪系统的设计决策
  • 用户偏好（多用 Agent Teams、模型选择策略）
  • OA 秘书系统的数据源和 AI 精简原则
  • 系统状态（家目录空间）
  • 对话导出工具路径

Memory 的特点：

  • 由 CC 自动维护（CC 可以往里写）
  • 适合放"关键决策"和"偏好"
  • 不适合放"规则"（规则放 CLAUDE.md，更可控）

三、rules 目录的用法

除了 CLAUDE.md 和 Memory，CC 还支持 rules 目录来组织规则。

全局 rules：~/.claude/rules/ 项目级 rules：项目目录/.claude/rules/

每个 .md 文件是一条或一组规则，CC 会自动加载该目录下的所有 .md 文件。

什么时候用 rules 目录而不是 CLAUDE.md？

场景用 CLAUDE.md用 rules 目录
规则数量少（<20条）合适没必要
规则数量多（>20条），需要分类管理会变得很长按主题拆分成多个文件
多人协作，不同人负责不同规则容易冲突各管各的文件
规则需要频繁启用/禁用要手动注释移出/移入目录即可

你的现状：目前规则量不大，CLAUDE.md 已经够用。如果将来规则膨胀到超过 3K tokens，可以考虑拆分到 rules 目录。

四、Compact Instructions

4.1 什么是 Compact Instructions

当对话变长、context 窗口接近满载时，CC 会自动"压缩"上下文——把长对话精简为摘要。

问题是：CC 压缩时不知道哪些信息对你最重要，可能把关键规则压缩掉。

Compact Instructions 就是告诉 CC："压缩时必须保留以下内容"。

4.2 怎么写

在 CLAUDE.md 中加一段：

## Compact Instructions

压缩上下文时必须保留以下规则（按优先级排列）：

1. 技术栈：Streamlit + Python miniforge3，禁止 React/Next.js
2. 协作模式：教练+助手，先描述方案等待批准再执行
3. 路径规范：全局配置 ~/.claude/，脚本库 ~/Dev/scripts/，水利公司 ~/Work/zdwp/
4. 任务管理：超 5 分钟必须拆分，多 agents 并行
5. 决策格式：必须写选项列表，标记推荐，说明理由
6. 4 维度框架（D1 来龙去脉、D2 乙方立场与措辞、D3 报告结构、D4 预判评审）

4.3 为什么重要

你的工作场景中经常有长会话——标书写作可能持续几个小时，中间多次 compact。如果 compact 后 CC 忘了"用 Streamlit 不用 React"，你在后续讨论中让它做 Web 应用时它可能提议用 React，你又要纠正一遍。

Compact Instructions 避免了这种重复纠正。

五、我们的现状 vs 最佳实践

维度我们现在最佳实践差距
CLAUDE.md 长度~2K tokens控制在 2.5K 以内接近达标，注意不要膨胀
全局/项目分层已做到通用放全局，项目特有放项目目录达标
规则是否可执行基本做到每条规则都是"CC 能直接执行的指令"达标
Compact Instructions没有告诉 CC 压缩时保留什么TODO
Memory 定期清理没有机制定期审计，删除过时记忆TODO
区分硬规则/偏好没有区分用 MUST/SHOULD/MAY 标记优先级TODO，考虑加
HANDOFF.md没有系统化跨会话接力标准格式TODO

六、常见误区

这层不该放什么：

  • 大段背景介绍：比如"我是一名水利工程师，工作了 X 年......"——CC 不需要你的简历，只需要影响行为的规则
  • 完整 API 文档：比如把 python-docx 的 API 贴进来——白白占用 tokens，CC 本来就知道这些
  • 一次性指令：比如"今天帮我整理下载目录"——直接在对话中说，不要写进永久规则
  • 重复内容：全局写了"用 Streamlit"，项目级又写一遍——CC 两层都会读到

最容易犯的错：把 CLAUDE.md 当"笔记本"用，什么都往里塞。记住：CLAUDE.md 的每一行都在消耗 context 窗口。写进去的每条规则，都应该值得在每个会话中都被 CC 读到。

七、Token 成本意识

上下文窗口是有限的（约 200K tokens），Layer 1 的内容是"固定开销"——每个会话都会付出。

固定开销（每次会话）：
├── 系统指令                    ~8K
├── Skill 描述（25+ 个）        ~5K
├── MCP 工具定义                ~2K
├── 全局 CLAUDE.md              ~2K
├── 项目 CLAUDE.md              ~1.5K
├── Memory 文件                 ~1.5K
└── 合计                       ~20K

实际工作可用空间：~180K

这意味着：

  • CLAUDE.md 不是越多越好——2.5K tokens 是好上限
  • 每加一个 MCP Server 约 4-6K tokens——不要随便加
  • 你的"脚本 > Skill > CC 直接"三级优先级，本质上就是在节省 token

八、TODO

  • 写 Compact Instructions（P0）：在 CLAUDE.md 中加一段，列出压缩时必须保留的规则
  • Memory 清理（P1）：审计现有 Memory 文件，删除不再相关的内容（比如过时的"家目录空间"数据）
  • 考虑规则优先级标记（P2）：给 CLAUDE.md 规则加 MUST/SHOULD/MAY
  • HANDOFF.md 模板（P2）：标准化跨会话接力的格式

补充：上下文分层加载与 Token 经济学

以下内容合并自 tw93 Ch03（上下文工程）的独有段落。

上下文的三层分配

┌─────────────────────────────────────────────┐
│  固定开销（每次会话自动加载）                    │
│  ├── 系统提示（系统指令）        ~8K            │
│  ├── CLAUDE.md（全局+项目级）    ~3.5K          │
│  ├── Memory 文件                ~1.5K          │
│  ├── Skill 描述（25+ 个）        ~5K            │
│  └── MCP 工具定义               ~2K            │
│  合计                           ~20K           │
├─────────────────────────────────────────────┤
│  半固定（连接时加载）                           │
│  └── MCP Server schema（每个 4-6K）            │
├─────────────────────────────────────────────┤
│  动态（随对话增长）                             │
│  └── 用户消息、CC 回复、工具调用输出...          │
├─────────────────────────────────────────────┤
│  实际可用空间 ~180K（3个 MCP 则降到 ~165K）      │
└─────────────────────────────────────────────┘

MCP 的 Token 成本

MCP 数量固定 token 开销占 200K 总量
0 个0K0%
1 个~5K2.5%
3 个~15K7.5%
5 个~25K12.5%

什么时候才该考虑 MCP：CC 反复忘记脚本用法、需要复杂认证/状态管理、需要非 Bash 协议。

"脚本 > Skill > CC 直接" 的 Token 对比

以"检查标书中有没有 bullet point"为例：

方式消耗
脚本 report_quality_check.py~35 token
Skill 加载 + CC 按指引检查~2,800 token
CC 直接读文件逐行扫描~5,000+ token

12 章标书每章多次检查时，差距放大到不可忽视。

分层加载核心策略

  • 始终加载（CLAUDE.md）→ 精简
  • 按需加载（Skills）→ 可以写详细
  • 临时加载（工具输出）→ 控制长度，脚本输出 30 行以内

参考

  • 00-总览与主线地图.md — 三条主线的全局视图
  • Layer2-工具能力.md — Layer 2 工具层，建立在 Layer 1 之上
  • Layer3-工作流Skills.md — Layer 3 工作流层，使用 Layer 1 的规则约束
  • ~/.claude/CLAUDE.md — 你的全局规则文件（实物）
  • ~/.claude/projects/-Users-tianli/memory/MEMORY.md — 你的 Memory 文件（实物）