AI 编程上下文窗口管理，决定的不只是速度
一句话结论：AI 编程上下文窗口管理的核心不是”塞得更多”，而是”留得更干净”——任务切换用 /clear 、长任务用 /compact 、探索类工作丢给子智能体，三招分工明确，代码质量和 token 成本都会明显改善。
很多人以为上下文窗口越大越好用，实际恰恰相反：随着对话变长，注意力被摊薄到大量历史消息和文件内容上，模型对当前任务的专注度会下降，这就是常说的 context rot 。上下文越大，越需要主动管理。
四种动作，各自解决什么问题
以 Claude Code 为例（其他智能体工具逻辑类似），每轮对话结束其实都是一个分支点，你有四种选择：
| 动作 | 做了什么 | 适用场景 |
|---|---|---|
| 继续对话 | 原上下文追加新消息 | 任务高度连续，前文都还有用 |
| /clear | 清空对话历史，全新开始 | 切换到不相关的新任务 |
| /compact | 把历史压缩成摘要后继续 | 任务没做完，但上下文快满了 |
| 子智能体 | 独立上下文探索，只回传结论 | 调研、代码审查等中间产物多的工作 |
/clear：最便宜也最有效的一招
每条新消息都要重发整个历史。一个在三个不相关问题之间来回切换的会话，等于每个问题都在为另外两个付费。判断标准很简单：如果这条提示词放在全新终端里也完全说得通，那就先 /clear 再发。
/compact：主动压，别等自动压
自动压缩触发时模型往往处于上下文最臃肿、表现最差的时刻，容易丢掉关键信息。更好的做法是趁窗口还充裕时手动执行，并附上指令，比如 /compact 保留 API 改造的决策和已修改文件清单。也可以在 CLAUDE.md 里写死压缩偏好，让关键上下文永远活过摘要。
子智能体：给探索性工作一个独立房间
让主会话直接调研代码库，它会读大量文件，全部占用主上下文。正确做法是把”调研鉴权模块怎么处理 token 刷新”这类任务委托给子智能体——它自己开一个干净的上下文窗口，读完之后只回传结论。审查别人写的代码也同理：一个全新上下文的审查者，不会被”刚写完这段代码”的偏见污染。
三条可以直接套用的规则
- 新任务 = 新会话：文档里反复出现的经验法则，没有例外值得打破。
- 指向文件而不是粘贴文件：粘贴的内容会永久占住上下文，给路径让模型按需读。
- 把专用指令从 CLAUDE.md 移到技能里：CLAUDE.md 每轮都在场，技能按需加载，基础上下文越小越好。
配合钩子自动过滤测试输出、只保留失败行这类技巧，能把一次测试运行占用的上下文从上万 token 压到几百。具体的钩子写法可以参考之前写的 Claude Code Hooks 用法详解；CLAUDE.md 本身怎么精简，见 CLAUDE.md 与 AGENTS.md 项目记忆文件怎么写。
常见误区
一是把 1M 上下文当无限缓存，什么历史都留着——大窗口只是给你更多时间做主动管理，不是免除管理。二是所有探索都在主会话做，然后惊讶于模型”变笨了”。三是纠错时靠追加消息解释”刚才那样不对”，其实回退（rewind）到分歧点重新提示更干净，还省 token 。更系统的分支管理思路，可以延伸阅读 子智能体拆分与上下文隔离 和 AI 编程的 Plan/Act 分离。
上下文窗口越大，是不是就不需要管理了？
/clear 和 /compact 到底选哪个？
什么时候该用子智能体？
参考来源：Claude Code 官方文档 Best Practices 与成本管理章节、 Anthropic 博客 Using Claude Code: session management and 1M context 。
评论 (0)