072、上下文窗口管理：长对话的自动压缩策略与关键信息保留技巧
072、上下文窗口管理：长对话的自动压缩策略与关键信息保留技巧
上周五凌晨两点，我盯着终端里Claude Code的报错日志，第17次确认同一个问题：对话进行到第43轮时，模型突然忘记了我们在第12轮约定的项目结构规范。它开始生成与之前完全矛盾的代码，把src/utils下的工具函数又写了一遍，还用了不同的命名风格。那一刻我意识到，上下文窗口不是无限大的，而Claude Code的“记忆”其实是一场精心设计的幻觉。
这个坑我踩了整整三个月。从最初盲目相信“对话越长越智能”，到后来手动清理历史记录导致丢失关键上下文，再到最终摸索出一套自动压缩策略——今天这篇笔记，就是我把这些血泪教训整理成的工程化方案。
上下文窗口的物理极限与心理错觉
Claude Code的上下文窗口大约在100K token左右，听起来很大对吧？但你要知道，一个中等规模项目的代码库，光是package.json加上几个核心模块的import链，就能吃掉20K。再加上你之前讨论的架构决策、模型给出的长段解释、来回修改的diff——实际留给“有效思考”的空间，远比你想象的小。
更隐蔽的问题是：模型对早期内容的注意力会自然衰减。这不是bug，是transformer架构的固有特性。即使上下文窗口没满，模型也会倾向于“遗忘”对话前半段的内容。我做过实验：在第50轮提问“我们第5轮讨论的那个接口签名是什么”，正确率不到40%。
所以，上下文管理不是“满了才处理”，而是从第一轮对话开始就要有策略。