02 - 上下文管理
200K 上下文并非全部可用
很多人把上下文当”容量问题”,但卡住的地方通常不是不够长,而是太吵了——有用信息被大量无关内容淹没。
200K 总上下文
├── 固定开销 (~15-20K)
│ ├── 系统指令: ~2K
│ ├── 所有启用的 Skill 描述符: ~1-5K
│ ├── MCP Server 工具定义: ~10-20K ← 最大隐形杀手
│ └── LSP 状态: ~2-5K
│
├── 半固定 (~5-10K)
│ ├── CLAUDE.md: ~2-5K
│ └── Memory: ~1-2K
│
└── 动态可用 (~160-180K)
├── 对话历史
├── 文件内容
└── 工具调用结果
MCP 的隐形开销:一个典型 MCP Server(如 GitHub)包含 20-30 个工具定义,每个约 200 tokens,合计 4,000-6,000 tokens。接 5 个 Server,光这部分固定开销就到 25,000 tokens(12.5%)。在需要读大量代码的场景,这 12.5% 非常关键。
加载策略
始终常驻 → CLAUDE.md:项目契约 / 构建命令 / 禁止事项
按路径加载 → rules:语言 / 目录 / 文件类型特定规则
按需加载 → Skills:工作流 / 领域知识
隔离加载 → Subagents:大量探索 / 并行研究
不进上下文 → Hooks:确定性脚本 / 审计 / 阻断
偶尔用的东西就不要每次都加载进来。
优化要点
- 保持 CLAUDE.md 短、硬、可执行,优先写命令、约束、架构边界。Anthropic 官方自己的 CLAUDE.md 大约只有 2.5K tokens
- 把大型参考文档拆到 Skills 的 supporting files,不要塞进 SKILL.md 正文
- 使用
.claude/rules/做路径/语言规则,不让根 CLAUDE.md 承担所有差异 - 长会话主动用
/context观察消耗,不要等系统自动压缩后再补救 - 任务切换优先
/clear,同一任务进入新阶段用/compact
RTK:自动过滤命令输出
Tool Output 是另一个容易被忽视的上下文杀手。cargo test 一次完整输出动辄几千行,git log、find、grep 在稍大的仓库里也能轻松塞满屏幕。
RTK 的思路是在命令输出到 Claude 之前自动过滤,只留决策需要的核心信息:
# Claude 看到的原始输出
running 262 tests
test auth::test_login ... ok
...(几千行)
# 走 RTK 之后
✓ cargo test: 262 passed (1 suite, 0.08s)
通过 Hook 透明重写命令,对 Claude Code 完全无感。类似 | head -30 手动截断,但覆盖面更广。
Compact Instructions
默认压缩算法按”可重新读取”判断,早期的 Tool Output 和文件内容会被优先删掉,顺带把架构决策和约束理由也一起扔了。两小时后再改,可能根本不记得两小时前定了什么。
在 CLAUDE.md 里写明压缩保留策略:
## Compact Instructions
When compressing, preserve in priority order:
1. Architecture decisions (NEVER summarize)
2. Modified files and their key changes
3. Current verification status (pass/fail)
4. Open TODOs and rollback notes
5. Tool outputs (can delete, keep pass/fail only)HANDOFF.md
更主动的方案:在开新会话前,先让 Claude 写一份 HANDOFF.md,把当前进度、尝试过什么、哪些走通了、哪些是死路、下一步该做什么写清楚。下一个 Claude 实例只读这个文件就能接着做,不依赖压缩算法的摘要质量。
写完后快速扫一眼,有缺漏直接让它补,然后开新会话,把 HANDOFF.md 的路径发过去。
Plan Mode
Plan Mode 的核心是把探索和执行拆开:
- 探索阶段以只读操作为主
- Claude 可以先澄清目标和边界,再提交具体方案
- 执行成本在计划确认之后才发生
按两下 Shift+Tab 进入 Plan Mode。进阶玩法:开一个 Claude 写计划,再开一个 Codex 以”高级工程师”身份审这个计划,让 AI 审 AI。
Prev: 01 - 六层架构总览 | Next: 03 - Skills 设计