反直觉核心结论：上下文窗口越大 ≠ 模型越聪明。真正决定效能的是上下文质量——窗口越大、信息越杂，注意力越分散，模型越容易"跑偏"。
1
1M Token 到底多大？
英文约 75 万字
- 相当于约 10 本普通小说
- 或数百篇长文章
中文约 50 万字
- 相当于《三体》三册中的 2 本
- 中文 Token 密度更高
超大窗口的代价
- 1M 以上时自动压缩率提升约 15%
- 上下文越大并不代表越好用
在线计算器
Token 容量计算器 — 输入任意 Token 数，即时换算为文字、页面、书籍等实际容量
关键认知：大窗口给了容量，但不保证质量。堆满无关信息的上下文，反而会让模型"分心"。
2
什么是 Context Rot（上下文腐化）？
原因
- 上下文越长，模型注意力逐渐分散
- Token 消耗过多，关键信息被稀释
- 对前期输出的理解可能变得模糊
典型症状
- 开始重复之前说过的内容
- 回答与问题逐渐偏离
- 遗忘了早期建立的约定或规则
- 输出质量逐步下降
一句话：Context Rot 不是 Bug，是模型在超长上下文下的结构性退化。主动管理是唯一出路。
3
Compaction：四阶段防腐体系
✅ Compaction 运作流程
阶段一
预加载：结构化注入 CLAUDE.md 等高优先级信息
阶段二
自动压缩决策：LLM 自动生成对话摘要，保留关键信息
阶段三
超窗截载（触发阈值 >38.5%）：截断过旧内容，防止溢出
阶段四
会话恢复：最近 413 时，保留系统提示和安全档位，确保连续性
核心设计：Compaction 不是简单截断，而是「有损压缩 + 关键保留」的智能机制。
4
主动管理三大工具
/compact
压缩摘要
- 手动触发上下文压缩
- 建议在用量 60%～70% 时主动执行
- 执行前确保关键约定已写入 CLAUDE.md
/clear
彻底清空
- 彻底清空当前上下文
- 适合切换到全新任务时使用
- 清空后从 CLAUDE.md 重新加载上下文
AUTO_COMPACT_WINDOW
自动配置
- 设置为 200000（20 万 Token）
- 控制自动压缩触发的窗口大小
- 根据任务复杂度灵活调整阈值
最佳实践：手动 /compact 优于被动等待自动压缩——主动压缩时你可以控制摘要质量，被动压缩时模型自行决定。
5
三层持久化机制
L1 · CLAUDE.md
- 项目级核心信息，每次会话自动注入
- 存放：项目规范、技术约定、工作流程
- 最高优先级，Compaction 不会清除
L2 · Memory
- 个人偏好与跨会话记忆
- 存放：用户习惯、历史决策记录
- 用于维护跨会话的个性化设定
L3 · Sub-agent
- 独立上下文的子任务执行器
- 主 Agent 派发，独立运行不污染主上下文
- 减少主 Agent 的上下文消耗次数
分层逻辑：持久信息 → CLAUDE.md，个人记忆 → Memory，复杂子任务 → Sub-agent，三层分工各司其职。
6
信息生命周期
进入上下文
用户输入 / CLAUDE.md 注入
参与推理
模型基于上下文生成回答
判断权重
模型评估信息的重要程度
Compaction 压缩
低权重内容被摘要或截断
Memory 持久化
关键信息写入持久层
新会话引用
下次会话从持久层重新加载
信息不会永久存在于上下文，主动持久化才能跨会话保留。
7
实操建议
✅ 主动压缩优先
- 不要等 Claude 自动压缩
- 在 60%～70% 用量时手动 /compact
- 压缩前确认关键约定已入 CLAUDE.md
✅ 关键约定写进 CLAUDE.md
- 不要只在对话中告知规则
- 对话约定会随 Compaction 丢失
- CLAUDE.md 是唯一可靠的持久化入口
✅ 复杂任务拆给 Sub-agent
- 大型任务主动拆分为子任务
- 每个 Sub-agent 独立上下文运行
- 主 Agent 只做汇总，不参与细节执行
✅ 定义好 Sub-agent Prompt
- 为每个子任务提供清晰的 Schema
- 输入/输出格式需明确约定
- 减少主 Agent 二次沟通的上下文消耗
最终结论：Claude Code 的关键不只是大窗口，而是让高价值信息留在正确的位置——通过任务化、结构化和轻量化，持续提升上下文质量。
一图总结全部内容 ↓
