42 Context Window优化概述Context Window（上下文窗口）是LLM辅助编程的核心资源。然而，随着对话的持续，Context Window会面临一种被称为Context Rot（上下文腐烂）的现象——即上下文中积累了大量不再相关的信息，导致AI对当前问题的关注度降低、产生幻觉或回复质量下降。本文将深入分析Context Rot的成因、症状，并提供一套完整的预防策略和会话健康度维护方法论。1. Context Rot成因分析1.1 什么是Context RotContext Rot指的是在长时间对话中，上下文窗口中积累了大量陈旧、冗余或无关的信息，导致AI模型的注意力被稀释，从而影响回复质量的现象。1.2 主要成因成因1：信息堆积效应每次对话交互都会产生新的Token，随着轮次增加，上下文不断膨胀：对话轮次 Token用量 AI表现 0-20 0-15% 优秀 21-50 15-40% 良好 51-100 40-70% 一般（开始遗忘早期信息） 101+ 70-85%+ 下降（明显出现Context Rot症状）成因2：注意力稀释Transformer模型的注意力机制在处理长上下文时，注意力分布会变得分散：注意力分布（早期对话，20轮）： ┌────────────────────────────────────┐ │ ████████████████████████████ │ 对当前问题的注意力：85% │ ████ │ 对历史上下文的注意力：15% └────────────────────────────────────┘ 注意力分布（后期对话，120轮）： ┌────────────────────────────────────┐ │ ████████████ │ 对当前问题的注意力：40% │ ████████████ │ 对历史上下文的注意力：40% │ ████ │ 噪声/无关信息吸引：20% └────────────────────────────────────┘成因3：信息冲突与混淆后续对话中引入的新信息可能与早期信息产生矛盾，导致AI产生混淆：早期对话： "我们使用SQLite作为数据库" 中期对话： "数据库切换到了PostgreSQL" 后期对话： Codex可能同时引用SQLite和PostgreSQL 结果： AI推荐了使用SQLite特有的语法导致错误成因4：调试信息的累积在Bug排查过程中，大量的错误输出、调试日志和尝试记录会快速填满上下文：一次Bug排查的Token消耗： ├── 错误信息： ~2,000 Token ├── 调试日志（3次尝试）： ~6,000 Token ├── 修改的代码段（5个版本）： ~5,000 Token ├── AI的分析和建议： ~4,000 Token └── 最终解决方案： ~1,000 Token 总计： ~18,000 Token1.3 Context Rot的症状症状表现严重程度遗忘早期约定AI忘记了之前确定的架构决策⚠️ 轻度自相矛盾AI的建议与早期结论冲突⚠️ 中度重复建议AI多次推荐已经否定的方案⚠️ 中度产生幻觉AI引用了不存在的代码或配置🔴 严重响应变慢模型处理时间显著增加⚠️ 轻度关注偏离AI关注无关细节，忽略核心问题🔴 严重2. 预防策略2.1 主动上下文管理策略1：定期压缩保持定期使用/compact的习惯：# 推荐的压缩节奏 每完成一个子任务 → /compact 每30分钟对话 → /compact 每消耗25% Token → /compact策略2：及时分支发现对话开始偏离主题时，及时使用分支：# 对话开始讨论不相关的话题 # 不要在主线程中继续 /fork "新话题讨论" # 完成讨论后 /branch:main /compact策略3：使用检查点作为里程碑#