Claude Code 上下文管理别再只会压缩了——三个任务类型三种喂法，这才是正确的路由思路

很多人在用 Claude Code 的时候，遇到上下文不够用，第一反应就是「压缩」——删历史记录、简化 prompt、减少文件数量。但我跑了半年下来发现，这条路走到一定程度就不通了。

压缩是有极限的。你把 context 压到 200K token，任务复杂了还是不够用。你继续压，压到 100K，结果模型开始「失忆」，前面讨论过的技术决策到后面就不认了。

真正管用的思路，不是压缩，是路由。

什么叫路由？就是你得先搞清楚这个任务需要什么类型的上下文，然后只喂它需要的那些。

举个例子。你让 Claude Code 修一个 bug，它最需要的不是项目全貌，是这个 bug 相关的代码片段和调用栈。你让它写一个新功能，它最需要的不是历史对话，是这个功能的规格说明和相关的接口文档。你让它做 code review，它最需要的不是代码全文，是最近的 commit diff 和相关的测试用例。

不同的任务类型，需要的上下文完全不一样。你把它们混在一起全扔进去，模型自己要在噪声里找信号，效果自然差。

具体怎么做？三个层次。

第一层：任务分类。你得先有个判断框架——这个任务是修复类、实现类、审查类、还是探索类？修复类优先喂错误日志和相邻代码；实现类优先喂接口契约和设计文档；审查类优先喂 diff 和测试；探索类可以多给一些结构性的东西，比如项目 README 和目录结构。

第二层：上下文分段。不要把整个项目 context 当成一个整体塞进去。把它拆成「技术上下文」「业务上下文」「协作上下文」三段。技术上下文是代码和架构，业务上下文是需求和约束，协作上下文是团队约定和历史决策。针对不同任务类型，动态组合这三段的权重。

第三层：动态调整。任务进行到一半，上下文需求会变。比如你开始修 bug，后来发现这是个架构问题，你需要从「修复类」切到「探索类」，对应的上下文策略也要跟着切。Claude Code 支持多 session，你可以为不同阶段开不同的 session，每个 session 维护自己独立的上下文。

我试了三个月，结论是：上下文够不够用，不在于你塞了多少进去，而在于你塞对了没有。

给一个马上能用的下一步：你今天打开 Claude Code 下次做任务之前，先停下来想三秒钟——这个任务最需要的是什么？然后只喂它最需要的，把剩下的先关掉。试试看，token 账单会给你惊喜的。