上下文管理

上下文管理是 Claude Code 中最重要的概念。上下文就是 Claude 的”工作记忆”，理解并管理好它，直接决定了你的使用效率和成本。

什么是上下文？

上下文是 Claude 在对话中的”工作记忆”，包括：

对话中的所有消息
Claude 读取的文件内容
命令执行的输出
工具调用的结果

Claude 拥有 200,000 token 的上下文窗口。可以把它想象成内存 — 当它填满时，性能会下降甚至出错。

上下文区域速查

绿色区域 0-50%

自由工作，无需担心上下文用量。

黄色区域 50-75%

开始有选择地操作，避免不必要的文件读取。

红色区域 75-90%

立即使用 /compact 压缩上下文。

危险区域 90%+

必须执行 /clear 清除，否则可能出错。

读取状态栏

状态栏实时显示上下文用量：

Claude Code │ Ctx(u): 45% │ Cost: $0.23 │ Session: 1h 23m

指标	含义
`Ctx(u): 45%`	已使用 45% 的上下文
`Cost: $0.23`	当前会话的 API 费用
`Session: 1h 23m`	已用时间

自定义状态栏

推荐使用 ccstatusline，在 ~/.claude/settings.json 中添加：

{
  "statusLine": {
    "type": "command",
    "command": "npx -y ccstatusline@latest",
    "padding": 0
  }
}

上下文恢复策略

当上下文使用率过高时，有以下几种选择：

总结对话内容
保留关键上下文
通常可减少约 50% 的用量
适用于：需要继续当前对话时

使用 /rewind（或 Esc + Esc）打开检查点列表
选择一个检查点，然后选择”从此处总结”
Claude 会总结该点之后的所有内容，保留之前的上下文
比完整 /compact 更精确
需要 v2.1.32+

查询时尽量具体
避免”读取整个文件”
使用符号引用："读取 calculateTotal 函数"

上下文分类：保留 vs 清除

当接近红色区域（75%+）时，需要主动决定哪些信息要保留。

保留优先
清除优先

保留项	原因
CLAUDE.md 内容	核心指令必须持续存在
当前正在编辑的文件	当前工作上下文
当前组件的测试	验证上下文
已做的关键决策	架构选择
正在调试的错误信息	问题上下文

清除项	原因
已读但不再相关的文件	一次性查阅
已解决问题的调试输出	历史杂物
冗长的对话历史	被 /compact 总结
已完成任务的文件	不再需要
大型配置文件	需要时可重新读取

压缩前检查清单

在 CLAUDE.md 或会话笔记中记录关键决策
将待处理的更改提交到 git（创建恢复点）
明确记下当前任务（“我们正在实现 X”）
执行 /compact 进行总结和释放空间

什么消耗上下文？

操作	上下文成本
读取小文件	低（约 500 token）
读取大文件	高（约 5K+ token）
运行命令	中（约 1K token）
多文件搜索	高（约 3K+ token）
长对话	持续累积

上下文耗尽症状

学会识别上下文即将耗尽的信号：

症状	严重程度	应对措施
回复比平时短	警告	谨慎继续
忘记 CLAUDE.md 指令	严重	记录状态，准备检查点
与之前对话不一致	危急	需要新会话
对已讨论的代码出错	危急	需要新会话
”我无法访问那个文件”（但之前已读取）	危急	立即开始新会话

上下文检查

使用 /context 命令查看详细用量：

┌─────────────────────────────────────────────────────────────┐
│ CONTEXT USAGE                                    67% used   │
├─────────────────────────────────────────────────────────────┤
│ System Prompt          ████████░░░░░░░░░░░░░░░░  12,450 tk  │
│ System Tools           ██░░░░░░░░░░░░░░░░░░░░░░   3,200 tk  │
│ MCP Tools (5 servers)  ████████████░░░░░░░░░░░░  18,600 tk  │
│ Conversation           ████████████████████░░░░  89,200 tk  │
├─────────────────────────────────────────────────────────────┤
│ TOTAL                                           123,450 tk  │
│ REMAINING                                        76,550 tk  │
└─────────────────────────────────────────────────────────────┘

记忆系统

Claude Code 有三种不同的记忆系统，理解它们的区别对长期工作至关重要：

方面	会话记忆	自动记忆（原生）	持久记忆（Serena）
范围	仅当前对话	跨会话，按项目	跨所有会话
管理方式	`/compact`、`/clear`	`/memory` 命令	Serena MCP `write_memory()`
丢失条件	会话结束或 `/clear`	通过 `/memory` 手动删除	从 Serena 手动删除
需要	无	无（v2.1.59+）	Serena MCP 服务器
适用场景	即时工作上下文	关键决策和上下文片段	架构决策和模式

使用建议

会话记忆：活跃的问题解决、调试、探索
自动记忆：希望 Claude 下次会话自动重新发现的决策和上下文（v2.1.59+）
持久记忆（Serena）：跨多个项目的架构决策结构化存储
CLAUDE.md：团队约定、项目结构（通过 git 版本控制）

新鲜上下文模式（Ralph Loop）

问题：上下文腐化

研究表明，LLM 性能会随着累积上下文显著下降：

聚焦提示与污染提示之间有 20-30% 的性能差距
Claude 模型在约 16K token 时开始性能退化
失败尝试、错误追踪和迭代历史会分散注意力

解决方案

不在会话内管理上下文，而是每个任务都使用新会话，通过外部文件持久化状态：

# 经典 "Ralph Loop"（Geoffrey Huntley）
while :; do cat TASK.md PROGRESS.md | claude -p ; done

状态通过以下方式持久化：

TASK.md — 当前任务定义和验收标准
PROGRESS.md — 学习成果、已完成任务、阻碍
Git 提交 — 每次迭代原子提交

传统方式 vs 新鲜上下文

传统方式	新鲜上下文
在聊天历史中累积	每个任务重置
`/compact` 压缩	状态保存在文件 + git 中
上下文在任务间泄漏	每个任务获得全部注意力

适用场景

场景	推荐
上下文 70-90%，保持交互	`/compact`
上下文 90%+，需要全新开始	`/clear` 然后继续
长期自主运行，基于任务	新鲜上下文模式
夜间/离开时执行	新鲜上下文模式

任务定义模板

## 当前焦点
[单一原子任务，有明确的交付物]

## 验收标准
- [ ] 测试通过
- [ ] 构建成功
- [ ] [特定验证]

## 上下文
- 相关文件：[路径]
- 约束：[规则]

## 不要做
- 开始其他任务
- 重构无关代码

上下文污染（泄漏）

常见模式

任务 1："创建一个蓝色按钮"
Claude：[创建蓝色按钮]

任务 2："创建一个表单"
Claude：[创建表单... 所有按钮都是蓝色的！]
        ↑ "蓝色"泄漏到了新任务

解决方案：使用明确的边界
"---新任务---
创建一个表单。使用默认设计系统颜色。"

指令 1："总是使用箭头函数"
指令 2："遵循项目约定"（使用 function）

Claude：[困惑，在两种风格间交替]

解决方案：明确优先级
"如有冲突，项目约定优先于我的偏好。"

会话早期："auth.ts 包含登录逻辑"
... 2 小时的工作 ...
你将 auth.ts 重命名为 authentication.ts

Claude："我将修改 auth.ts..."
        ↑ 使用了过时的信息

解决方案：显式更新
"注意：auth.ts 已重命名为 authentication.ts"

上下文卫生检查清单

新任务 = 使用明确的 markdown 分隔
结构更改 = 显式通知 Claude
矛盾指令 = 明确优先级
长会话（>2小时） = 考虑 /clear 或新会话
异常行为 = 使用 /context 检查

成本感知与优化

Claude Code 使用 API 额度，理解成本有助于优化使用。

定价概览

模型	输入（每百万 token）	输出（每百万 token）	上下文窗口
Sonnet 4.6	$3.00	$15.00	200K
Opus 4.6（标准）	$5.00	$25.00	200K
Opus 4.6（1M 上下文 beta）	$10.00	$37.50	1M
Haiku 4.5	$0.80	$4.00	200K

成本优化策略

精准查询 — 指定行号范围而非整个文件："检查 auth.ts:45-60 中的登录函数"
主动压缩 — 在 70% 上下文时使用 /compact，而不是等到 90%
选择合适模型 — 简单任务用 Haiku，标准工作用 Sonnet，复杂任务才用 Opus
限制 MCP 服务器 — 只加载当前项目需要的 MCP 服务器
批量操作 — 一次请求读取多个文件，而非逐个读取
提示缓存 — 使用 API 时对重复前缀使用缓存（可节省高达 90%）

200K vs 1M 上下文

场景	推荐
Bug 修复、PR 审查、日常编码	Sonnet 4.6 @ 200K
全仓库审计、整个代码库加载	Opus 4.6 @ 1M
跨模块重构	Sonnet 4.6 @ 1M（权衡成本与分块 + RAG）
架构分析、Agent 团队	Opus 4.6 @ 1M

费用跟踪

实时跟踪：状态栏显示当前会话费用
详细分析：使用 ccusage CLI 工具

ccusage                    # 概览所有周期
ccusage --today            # 今天的费用
ccusage --month            # 本月
ccusage --model-breakdown  # 按模型分类

成本预算参考

使用者类型	每月预算估算
个人开发者（精打细算）	$5-$15（20-30 小时）
专业开发者	$20-$50（40-80 小时）
团队（5-10 人）	$50-$200

健全性检查技巧

验证 Claude 是否正确加载了你的配置：

在 CLAUDE.md 顶部添加：

# My name is [你的名字]
# Project: [项目名称]
# Stack: [技术栈]

问 Claude：“我的名字是什么？我在做什么项目？”
如果回答正确，说明配置已正确加载

失败症状	可能原因	解决方案
不知道你的名字	CLAUDE.md 未加载	检查文件位置
回答不一致	文件名拼写错误	必须是 `CLAUDE.md`
只知道部分信息	上下文已耗尽	`/clear` 或新会话

会话交接模式

当结束会话或切换上下文时，创建交接文档以保持连续性。

交接文档模板

# 会话交接 - [日期] [时间]

## 已完成的工作
- [关键任务 1]
- [关键任务 2]
- [修改的文件：列表]

## 当前状态
- [已完成的部分]
- [部分完成的工作]
- [已知问题或阻碍]

## 已做的决策
- [架构选择 1：原因]
- [技术选择：理由]
- [接受的权衡]

## 下一步
1. [下一个即时任务]
2. [依赖任务]
3. [后续验证]

## 下次会话上下文
- 分支：[branch-name]
- 关键文件：[列出 3-5 个最相关的文件]
- 依赖项：[外部因素]

何时创建交接文档

场景	原因
工作日结束	明天无缝恢复
上下文即将到限	在 `/clear` 之前保存状态
切换关注领域	不同任务需要新鲜上下文
预期中断	紧急情况或会议打断工作
复杂调试	记录假设和已尝试的测试