当前位置：首页 > news >正文

AI 1M 上下文时代，你的 session 管理正在悄然决定编码天花板

news 2026/4/16 15:58:04

在终端里用 Claude Code 构建全栈应用，两个小时的调试会话后，你输入一句“现在处理 bar.ts 里的另一个 warning”，结果 Claude 给出的方案完全忽略了之前反复确认的 auth 约束——这不是模型笨，而是上下文管理出了问题。Anthropic 最近在 /usage 里推出一系列更新，正是为了帮开发者看清这个 1M 上下文窗口背后的真实变量。

我起初以为 1M tokens 够大，就能随便开长会话，后来深入源码和真实用户对话才发现：上下文腐化（context rot）才是真正拉开效率差距的隐形杀手。模型注意力被稀释，老旧无关信息像噪音一样干扰当前任务，compaction 又在性能最差的时刻做总结，天然容易丢关键信息。

上下文窗口到底是什么，以及它为什么会“腐化”

上下文窗口就是模型一次性“看得见”的全部内容：系统提示 + 历史对话 + 每一次 tool call 及其输出 + 已读取的文件。Claude Code 当前支持 100 万 tokens，这意味着你可以一次性让它从零搭建完整应用，而不用频繁切 session。

但代价是上下文腐化：token 越多，注意力越分散，早期无关内容反而会拖累最新决策。这就像一场持续 3 小时的会议，前半小时的闲聊最后反而让大家记不清真正要解决的核心问题。生产环境中，这直接表现为：模型突然“变笨”、方案重复、或者干脆忘记你之前明确否决过的技术路线。

每一次模型回复，都是一个关键分叉点

当 Claude 完成一次响应，你其实站在五个选项的路口，而大多数人只知道“继续打字”这一条：

Continue：最自然，但会持续累积上下文。
/rewind（双击 Esc）：直接跳回任意历史消息，后续内容从上下文里彻底丢弃。
/clear：新建 session，自己手写精炼摘要。
Compact：让模型自动总结当前会话，替换历史。
Subagents：委托子代理，用全新干净上下文完成子任务，只拉回最终结果。

生活里的类比很直观：继续就像在同一张纸上一直写备忘录，越写越乱；rewind 则是把纸撕掉重来，只保留需要的那几行；subagent 则是把任务甩给实习生，让他独立完成后再给你最终报告。

为什么 rewind 才是修正错误的最高效方式

我见过太多开发者犯的典型错误：Claude 读了五份文件，尝试了方案 A 失败后，直接打字“方案 A 不行，换 B”。这会把失败路径也塞进上下文，加剧腐化。

正确做法是 rewind 到刚读完文件的节点，重新 prompt：“不要用方案 A，foo module 没暴露那个 API，直接上 B。” 这样失败路径被彻底丢弃，上下文保持干净。还可以让 Claude “summarize from here”，生成一条给“未来自己”的交接消息——就像给下一个迭代的 Claude 留了一封来自未来的邮件。

Compact vs 新建 session：两者的本质差异与适用边界

两者看起来都是“减负”，行为却完全不同：

操作	上下文保留方式	操作成本	信息损失风险	适用场景	开发者心智负担
Compact	模型自动总结	低	中高（lossy）	信息高度结构化、方向明确	低
/clear	自己手写精炼摘要	高	低	跨任务切换、需要极致控制	高
Subagent	子代理独立全新上下文	中	极低	明确只需结论、无需中间过程	中

实测性能与架构参数维度下，compact 最省力，但模型在上下文最满、注意力最分散的时刻做总结，天然容易出错。长尾风险与潜在技术债维度下，手写 /clear 最可靠，却会增加心智负担。开发者心智负担与上手门槛维度下，subagent 是最佳平衡点——尤其适合“验证结果”或“读其他代码库对齐实现”这类子任务。

什么情况下 compact 会特别糟糕，以及如何主动规避

最常见的坏 compact 发生在长调试会话后：模型总结时以为任务已经结束，你下一句却是“现在去修 bar.ts 里另一个 warning”。由于调试上下文里根本没提这个 warning，它就被丢掉了。

底层逻辑其实很简单——compaction 时刻正是模型最“笨”的时候。1M 上下文给了我们更多提前量：主动 compact，并附带明确指令（/compact focus on the auth refactor, drop the test debugging），远比被动等待 autocompact 可靠。这就像长途自驾，油箱快空了才去加油站，容易慌乱；提前看导航，在高速服务区主动总结行程、丢掉不必要的行李，效率完全不同。