Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.
如果你用 Claude Code 做过真实项目，大概率经历过这种事：
- 前几次对话很聪明，调试几轮后开始犯蠢
- 刚确认过的约束突然失效
- 你开始反复解释纠正，但效果越来越差
问题不全在模型，真正出问题的是一个容易被忽视但很重要的：上下文（Context Window）
Claude Code 官方文档反复强调 context window，但很多人仍然把它当成“聊天长度限制”
实际上，它更像是一种会被污染、会老化、需要管理的工程资源。
重新理解 Context Window
Context Window 不只是聊天记录，在 Claude Code 中，Context Window 包含：
- 整个对话历史
- Claude 读过的所有文件
- 每条命令的执行结果
- 所有失败尝试、中间结论和被推翻的假设
这些内容不只是被动记忆，而是会作为持续参与后续推理使用的输入材料
它更像是一个「推理现场」，不是日志
为什么上下文会失控
如果你不做任何管理，上下文几乎一定会走向失控：
- 调试是一个高噪声活动
- 探索与实现混在同一个会话里
- 错误假设不会自动失效
- 一个会话承载了太多目标
官方建议背后的逻辑
subagents、@file、/clear、/compact、Explore → Plan → Implement……
这些看似零散的建议，其实都在解决同一个问题：如何让有限的上下文，长期保持可用
换句话说，Claude Code 的所有最佳实践，本质上都是在回答一个问题：如何延缓上下文退化的速度
上下文管理的四条原则
短 · 净 · 可控 · 可重置
- 短：探索性工作不进入主上下文
- 净：错误必须尽快失效
- 可控：计划必须先于实现
- 可重置：上下文重置是工程能力的一部分
这四条不是技巧清单，而是判断标准
短：探索性工作不进入主上下文
一句话理解：别把「还没想清楚的东西」长期留在主上下文里
探索性工作一旦进入主上下文，推理质量就会开始退化
主上下文应该只承载稳定的、可复用的决策信息
而以下内容，天然是高噪声的：
- 文件扫描
- 代码结构探索
- 试探性 Debug
- 不确定假设的验证过程
它们有价值，但不适合长期驻留
SubAgents 的真正价值
SubAgent 常被当作「并行能力」来使用，它的真正更重要的价值是上下文隔离：
- 主 Agent：控制面 / 决策面
- Subagent：一次性计算单元
探索发生在子上下文中，主上下文只接收结论
用「引用」代替「注入」
粘贴大段代码或命令输出，是最常见的上下文杀手
更好的方式是：
- 用
@file引用文件 - 使用工具调用，而不是贴原始输出
- 让上下文知道「在哪里」，而不是「全部内容是什么」
净：错误必须尽快失效
一句话理解：错误一旦确认，就别再让它参与后续推理
错误假设在上下文中停留越久，修复成本越高
一个典型的错误路径：
- 错误假设进入上下文
- 实现基于错误前提展开
- 出现异常 → 局部修补
- 错误被反复引用和强化
最后你得到的不是「修复后的上下文」，而是一个被污染的上下文
为什么「在原地纠错」代价极高
在同一个会话里反复纠错，看似节省成本，实则相反：
- 错误不会被删除
- 纠错只是叠加更多 token
- 模型更容易「合理地犯同一个错」
同类错误出现两次以上，继续修补往往不划算
什么时候应该 clear 或重来
判断信号：
- Claude 开始忽略已确认的约束
- 输出质量明显下降
- 你需要反复强调同一前提
这通常不是你没讲清楚，而是：上下文已经不值得继续修补
可控：计划必须先于实现
一句话理解：先想清楚再让模型写，不要让上下文替你思考
没有显式计划的上下文，一定会失控
当你边想边写、边改边试时：
- 推理是隐式的
- 路径不断分叉
- 上下文不可逆的增长
最终你甚至无法判断：是方向错了，还是实现错了
Explore → Plan → Implement 的核心价值
这个流程的核心价值不是「规范」，而是压缩上下文：
- Explore：允许噪声和不确定
- Plan：把推理压缩成稳定结构
- Implement：在稳定约束下执行
好计划，本身就是上下文锚点
一个好的计划可以把上万 token 的探索，压缩成几百 token 的稳定约束
计划不是文档，而是上下文压缩器
可重置：上下文重置是工程能力的一部分
一句话理解：如果一个会话不能被丢弃，那它已经绑架你了
如果一个上下文不能被安全、低成本地重启，那它本身就是设计有问题的
为什么不敢重置反而是风险？
在真实使用中，很多人会下意识地「死扛」一个会话：
- 已经投入了大量对话和探索
- 担心重来会丢失进展
- 希望再解释一次就能「救回来」
但在 LLM 系统中，这种行为往往会带来更大的风险：
- 错误假设持续留在上下文中
- 冗余推理不断堆积
- 模型开始「看起来合理，但总是偏一点」
此时继续追加上下文，并不是在积累资产，而是在放大负债。
/compact、/clear 与直接重来
/compact：方向对，但上下文过长/clear：方向错或噪声过多- 直接重来：往往是成本最低的方案
丢掉的是噪声，而不是成果
设计「可重启」的工作方式
成熟的使用方式，通常具备：
- 可复制的输入
- 外置的规则（CLAUDE.md / skills）
- 不依赖单一会话状态
反模式清单
- 把探索过程塞进主上下文（违背「短」）
- 在错误假设上不断打补丁（违背「净」）
- 边想边写、边改边试（违背「可控」）
- 死扛一个已经失控的会话（违背「可重置」）
如果你发现自己四条全中，那不是你不专业，而是你还在用「人类调试人类代码」的方式调试 AI
上下文自检
继续一个会话前，快速自检：
- 主上下文是否只包含决策信息？
- 是否存在已被推翻但仍在上下文中的假设？
- 是否有明确、稳定的计划锚点？
- 如果现在重启，成本是否可接受？
结语
模型会继续变强，但上下文不会自动变干净
在 Agent 工程里，真正拉开差距的，从来不是谁的模型更新得更快，而是谁更早意识到：上下文是一等工程资源