Appearance
聊着聊着Claude突然"变笨"了——前半段回答得有理有据，后半段开始胡言乱语。想省钱切个便宜模型，账单反而涨了。这些都不是bug，是你没管好上下文。
为什么上下文工程是AI编程的天花板
AI编程这几年的进化：
- Tab补全（GitHub Copilot）
- IDE对话（Cursor、Windsurf）
- CLI Agent时代（Claude Code）
Prompt Engineering vs Context Engineering的区别是量级的。
Prompt写得花里胡哨，效果提升有限——现在的模型对自然语言的理解已经很好了。
但上下文管理好不好，效果差距可以是"能干"和"完全干不了"的区别。
核心洞察：问题不在容量，在信噪比
很多人把上下文当"容量问题"，但卡住的地方通常不是不够长，而是太吵了，有用的信息被大量无关内容淹没。
你塞进去150K tokens的内容，Claude真正需要的可能只有10K。剩下的140K全是噪音。
200K/1M上下文的真实构成
| 类型 | 占比 | 说明 |
|---|---|---|
| 系统提示词 | ~5K | CLAUDE.md、规则 |
| 对话历史 | ~变量 | 取决于对话长度 |
| 当前代码 | ~20-50K | 项目规模 |
| MCP上下文 | ~可配置 | 外部数据 |
| 模型输出 | ~50% | 会话越长越多 |
Prompt Caching：Claude Code的核心秘密
Claude Code的整个架构是围绕Prompt Caching设计的。当你用/compact命令时，它会：
- 把之前的对话历史压缩
- 保留关键决策和上下文
- 继续新的对话
但自动compact之后，之前定好的架构决策可能会丢——还得花半小时重新解释。
解决方案：用HANDOFF.md做跨会话的知识传递。
怎么让Claude"不忘事"
1. CLAUDE.md：项目级上下文
控制在200行以内，语气命令式。放真正高频、关键、会影响决策的规则。
2. HANDOFF.md：跨会话传递
markdown
# 项目关键决策
- 架构选择：...
- 放弃的方案：...
- 未完成的工作：...每次开新会话，先让Claude读这个文件。
3. 避免MCP Server塞太满
装了一堆好用的MCP Server，可用上下文急剧缩水。本来好好的200K窗口，没开始对话就感觉拥挤。
省钱技巧
对着Opus聊了半天，想问个简单问题切Haiku——账单可能比继续用Opus还贵。
因为上下文切换有成本，Haiku处理大上下文也要算钱。
写在最后
上下文工程是AI编程从"会用"到"用好"的分水岭。学会管理上下文，才是真正的效率倍增器。
