如果你把一个 AI 编程助手当"能自己动手的同事"用，很容易一开就是一下午：贴日志、读代码、跑命令、改文件，全都塞在同一个对话框里。然后某一刻，它突然不动了。
现象
接口直接返回 400，提示大致如下：
Error 400: maximum context length is 1048576 tokens.
You requested 1050000 tokens (...)
任务当场中断。麻烦的地方在于，这时候你连"让它自己总结一下再继续"都做不到——它已经发不出请求了，任何补救的指令都会撞在同一个 400 上。
根因：硬上限和"估算窗口"不同步
要理解三件事。
第一，上下文长度是服务端的硬上限。 它不是建议值，超了就是拒绝，没有降级处理、没有自动截断帮你兜底。
第二，客户端触发自动压缩，看的是"估算窗口的百分比"，而不是硬上限本身。 默认阈值大约是 83%。问题在于：估算本身有误差，而 83% 到 100% 之间剩下的这点空间，可能你贴一个大文件、跑一次长日志输出就填满了。也就是说，"自动压缩还没来得及触发，就已经越界了"。
第三，配置不一定真的生效。 管自动压缩的相关环境变量，如果你只在当前终端里 export 了一下，它不会传给主进程——GUI 应用的主进程并不继承你那个 shell 的环境。你改了参数，以为生效了，其实没有。
解决：主动做上下文纪律
关键心态是：把爆窗当成"确定会发生"的工程问题，提前管理，而不是等它发生再救。
- 把自动压缩阈值调低。 默认 83% 太靠边，调到 70% 左右，给自己留缓冲。
- 用系统级方式设置环境变量并重启应用。 只
export不够。Windows 上写进系统环境变量，Linux / macOS 写进桌面会话或服务管理器能读到的地方，然后重启应用。 - 定期看会话文件大小。 会话是落盘的，看文件增长就大概知道离上限还有多远，不必等红灯。
- 大任务拆到独立会话。 别把一个项目从调研到落地的全过程塞进一个对话框。
- 大段输出写进磁盘文件，而不是贴进对话。 让助手去读文件的摘要，而不是把整份日志粘进来。
- 能交给子代理的重活，只把摘要带回主会话。 子代理有自己的上下文窗口，主会话只保留结论和关键路径。
- 压缩前确认关键信息已落到记忆或存档文件里。 否则压缩后它自己都找不回上下文。
延伸与预防
这套思路可以推广到任何"窗口固定"的 AI 用法：本地大模型、RAG 检索增强、长文档摘要，边界都一样。判断标准很简单——这个工具能不能准确知道自己快满了？ 多数做不到，只能粗略估计。所以"什么时候该收手"，必须由人来判断，不能指望它自己刹车。
把"会话拆小、输出落盘、结论进记忆"变成习惯，比任何一次性的抢救都管用。
一句话教训
上下文爆窗是"确定会发生"的工程问题，不该等它发生才处理。