1-1 Context Engineering：核心原则
Context Window 是零和资源
模型在处理一次请求时，能"看到"的所有信息就是 context window。它有上限，放进去的每一个 token 都在挤占其他内容的空间。
这意味着填什么、不填什么，都是一个主动决策，不是"越多越好"。
常见的错误认知是：给模型的信息越详细，结果越好。实际情况是——无关信息会稀释关键信息的权重，模型的注意力是有限的，噪音越多，信号越容易被淹没。
工程上要想的问题不是"我还能再加什么"，而是"这条信息如果不在这里，模型会犯什么错"。如果答案是"不会犯错"，就不该放。
Context Rot：为什么越长越烂
Context Rot 指的是：随着对话轮次增加，context 里会积累大量对当前任务已经无用的内容——早期的错误推理、被推翻的方案、重复的澄清、过时的状态描述。
模型没有能力自动忽略这些内容。它会平等地"读"进去，结果是：
- 旧的死路会影响新的判断
- 模型容易在"之前讨论过但已放弃"的方向上兜圈子
- 长 session 的表现普遍差于短 session + 清晰状态摘要
这就是 3-3 要讲 Ralph 模式的根本原因——状态应该活在磁盘里，不应该活在对话里。
Lost-in-the-Middle：关键信息放中间会被遗忘
这是有实验支撑的现象。给模型一个很长的 context，把关键信息放在开头或结尾，命中率高；放在中间，命中率显著下降。
直觉上理解：模型对序列的"首因"和"近因"更敏感，中间内容会在注意力竞争中被边缘化。
工程含义：
- 最重要的约束、目标、当前任务状态，放开头
- 参考资料、历史背景，如果必须放，放结尾
- 不要让关键指令淹没在一大段说明文字的中间
实操：CLAUDE.md 该写什么 vs 不该写什么
CLAUDE.md 是 Claude Code 每次启动都会自动读入的文件，是你影响 agent 行为最直接的工程杠杆。但很多人把它写成"项目 README 的副本"，效果很差。
该写的：
- 当前项目的约束边界（哪些文件/目录不能动、哪些操作需要问人）
- 关键技术决策和它的原因（"我们用 X 不用 Y，因为…"，避免模型替你"优化"掉）
- 常见坑和已知限制（CI 的特殊配置、某个依赖的版本锁定原因）
- agent 完成任务后需要做的检查清单（跑测试、格式化、更新文档）
不该写的：
- 项目的完整背景介绍（模型不需要"了解你"，需要"知道边界"）
- 通用编程规范（"写好注释"、"变量名要语义化"——这些是废话，模型默认就会）
- 已经过时的信息（比决策本身更危险，会主动误导）
- 超长的上下文说明——CLAUDE.md 本身也在消耗 window，要精
一个实用测试：写完之后，逐条问自己"如果没有这条，agent 会犯什么具体的错"。答不上来的，删掉。
本节核心一句话
Context 不是越多越好，是越准越好。填 context 是决策，不是堆料。
