Context Engineering：如何管理 Claude 最稀缺的资源

这是「Claude Code Skills 完全指南」系列的第五篇。建议先阅读前四篇再继续。

写在前面

前四篇文章教你构建了 Skill——从理解本质、设计触发器、选择模式，到组织内容架构。

但如果你在实战中认真用过 Skill，你大概率遇到了一个前四篇没有正面解决的问题：

你的 Skill 明明写得很好，在新会话的前 20 分钟表现完美。但半小时后，Claude 开始"忘记"你的 Skill 指令。它不再遵循输出格式，跳过 KPI 树的第三级，甚至在你明确要求用脚本的步骤上自行估算数值。

你以为是 Skill 写得不好，于是花时间调试正文和 description。但问题反复出现——有时好、有时差，毫无规律。

真正的原因不在 Skill 本身。

问题在于 Claude 的上下文窗口——它保存着你整个对话的内容，包括每一条消息、Claude 读取的每一个文件、每一个命令输出。它可以很快填满。一次调试或代码库探索可能就产生和消耗数万个 token。当上下文窗口接近满时，Claude 可能开始"遗忘"早期指令或犯更多错误。上下文窗口是最重要的需要管理的资源。

这就是本文的主题。不是"上下文窗口是什么"这种百科知识，而是：作为一个每天使用 Claude Code 的人，你到底应该怎么管理这个最稀缺的资源？

一、从 Prompt Engineering 到 Context Engineering

1.1 一个定义的演进

要理解 Context Engineering，先看它和 Prompt Engineering 的区别。

在 Anthropic，我们将 Context Engineering 视为 Prompt Engineering 的自然演进。Prompt Engineering 是为了获得最优结果而编写和组织 LLM 指令的方法。Context Engineering 是策划和维护 LLM 推理过程中最优 token 集合（信息）的策略集，包括所有可能进入上下文的其他信息。在 LLM 工程的早期，Prompt 是 AI 工程工作的最大组成部分。随着这个术语所暗示的，Prompt Engineering 的主要焦点是如何编写有效的提示，特别是系统提示。

换句话说：Prompt Engineering 关心的是"怎么问"。Context Engineering 关心的是"模型看到什么"。

一位 Thoughtworks 的杰出工程师给出了一个简洁的定义："Context Engineering 就是策划模型看到的内容，以便获得更好的结果。"

用一位作者更通俗的类比：Prompt Engineering 是你怎么问问题，而 Context Engineering 是确保模型在开始思考之前，拥有正确的教科书、计算器、甚至你们上次对话的笔记。

1.2 为什么这个区分对 Skill 构建至关重要？

回忆第一篇的核心原理：Skill 本质上是一种上下文注入机制。它的价值在于"在正确的时间给 Claude 正确的信息"。

但这里有一个前四篇没有强调的关键约束：你注入的上下文，和其他所有信息一起，共享同一个有限的窗口。 你的 Skill 指令、CLAUDE.md 规则、MCP 工具定义、对话历史、Claude 读取的文件——全部在竞争同一块空间。

鉴于 LLM 受到有限注意力预算的约束，好的 Context Engineering 意味着找到最小的高信号 token 集合来最大化某种期望结果的概率。

这一句话，是本文所有内容的根基。

二、Context Rot：你最大的敌人

2.1 它是什么？

更大的上下文窗口允许模型处理更复杂和冗长的提示，但更多上下文不是自动更好。随着 token 数增长，准确性和召回率下降，这种现象称为 Context Rot（上下文腐烂）。这使得策划上下文中的内容与可用空间一样重要。

Context Rot 不是 bug，而是 transformer 注意力机制的根本性质。

Context Rot 是 LLM 随着输入长度增加而经历的可测量的性能退化。Chroma 测试了 18 个前沿模型，发现每一个都会变差。它是随着输入上下文变长，LLM 输出质量发生的退化。更多的 token 输入，更差的输出，即使模型的上下文窗口远未接近填满。不是某些模型。不是大多数。所有模型都是如此。

对 Claude Code 来说，影响是直接的：

当你的上下文使用达到三分之二容量时，响应质量会明显下降——不是因为模型变差了，而是因为上下文充满了噪音，模型必须对所有内容平等地投入注意力。子代理通过给每个委派任务提供自己独立的 200K token 上下文来解决这个问题。父代理派生子代理执行工作，子代理完成后只返回最终输出给父代理。所有中间噪音留在子代理的上下文中，永远不会触及父代理的对话。父代理得到的是信号，不是噪音。

2.2 三种 Context 失败模式

Context Engineering 失败围绕三种失败模式：Context Poisoning（上下文污染）——一个幻觉进入上下文并腐蚀其后的每一个响应。一旦错误信息进入，它就会扩散。Context Confusion（上下文混淆）——不相关的上下文把模型的注意力拉向错误方向。你问的是数据库设计，但你的前端文档淹没了信号。Context Clash（上下文冲突）——同一上下文中的矛盾信息。模型在相互冲突的指令或事实之间被拉扯。

让我用 Skill 的具体场景来说明每种失败模式：

Context Poisoning：你的电商分析 Skill 在第一轮运行时产生了一个错误的 KPI 数值（Claude 跳过了脚本，自己估算了）。这个错误数字留在对话历史中。后续的所有分析都基于这个错误数字——毒已经扩散了。

Context Confusion：你同时安装了 15 个 Skill，你在做安全审查，但 Claude 同时看到了前端设计 Skill、数据分析 Skill、文档生成 Skill 的所有元数据。这些无关信息稀释了它对安全审查 Skill 指令的注意力。

Context Clash：你的 CLAUDE.md 说"输出必须简洁"，但你的报告生成 Skill 说"包含完整的五段式分析"。Claude 在两条矛盾指令之间犹豫不决。

2.3 一个反直觉的真相：1M 窗口不是解药

2026 年 3 月，Anthropic 将上下文窗口从 200K 扩展到了 1M token，且无额外收费。很多人以为这意味着上下文管理不再重要了。

上下文纪律仍然重要。1M 窗口不是让你把所有东西都倒进去然后祈祷的邀请。加载不相关的文件浪费 token 并稀释 Claude 用来优先分配注意力的信号。CLAUDE.md 文件、Skills 优先加载和结构化会话管理仍然是最佳实践。它们只是有了更多的余地。

修复 Context Rot 的方法不是让模型更擅长处理长上下文。而是保持它们的上下文短。Anthropic 的多代理研究系统直接证明了这一点。他们的架构（一个 Opus 4 主代理委派给 Sonnet 4 子代理）在研究任务上超越了单个 Opus 4 代理 90.2%。

保持上下文短，比拥有更大的上下文窗口更重要。

三、四大策略：Write、Select、Compress、Isolate

Context Engineering 是用恰到好处的正确信息填充上下文窗口的艺术和科学。

LangChain 团队将 Context Engineering 的策略分为四类。这个分类框架异常清晰，我用 Claude Code 的具体工具来填充每一个类别。

策略 1：Write —— 把持久化知识写到文件中

"Write" 策略的核心理念是：不要每次都重新告诉 Claude 同样的事情，而是把它写到文件里让 Claude 按需读取。

在 Claude Code 中，Write 策略对应的工具有三个层级：

项目级（./CLAUDE.md）：项目特定的上下文。技术栈、规范、架构。这是 /init 创建的。动态导入：散布在代码库中的其他 CLAUDE.md 文件。在 src/auth/ 目录放一个来解释你的认证模式。Claude 在该目录中工作时会自动找到并加载它。建议从 /init 开始，然后花 10 分钟编辑生成的 CLAUDE.md。添加你团队的 PR 规范、测试要求、以及新工程师需要一周才能发现的坑。这 10 分钟将为你节省数小时纠正 Claude 的时间。

CLAUDE.md 的管理原则：

保持 CLAUDE.md 在 200 行和 2,000 token 以内。它在每次请求时都加载到上下文中，所以臃肿的 CLAUDE.md 会消耗自己的那份窗口。为模型写，不是为人类写：简洁、结构化、具体。

建议逐步构建规则文件之类的上下文，不要一开始就塞太多东西进去。模型已经变得相当强大，所以你半年前可能需要放入上下文的东西现在可能已经不必要了。

而 Skills 则是 Write 策略的按需加载版本：

MCP 工具始终存在于上下文中，无论你是否使用它们都会消耗 token。Skills 基于相关性按需加载。Simon Willison 将 Skills 称为"可能比 MCP 更重要"，正是因为这个原因。将 Skills 用于情境性适用的领域知识。

这是 Skills 相对于 CLAUDE.md 和 MCP 的核心竞争力——按需加载意味着不用的 Skill 不占空间。

策略 2：Select —— 只加载相关的信息

成功使用 AI 编码助手根本上是关于 Context Engineering。不仅是问对问题——而是提供正确的知识基础。有效的 AI 辅助开发需要三个核心组件：a) 项目架构知识——对类层次结构、库、框架和设计模式的理解，主要存储在 CLAUDE 文件中。b) 产品需求文档——产品应该做什么的清晰规格。c) 深层技术知识——对核心技术、数学概念、算法和关键中间件的专业理解。

Select 策略的核心操作是：不要让 Claude 自己去找，也不要把所有东西都给它——主动选择它需要的信息。

一位开发者分享了一个实用的方法：

他发现一个非常有效的方法是从一个简单的前提开始：他已经理解了自己在处理的代码，但他想验证这种理解并与 Claude Code 创建共享上下文。他从用自己的话描述某个特性的工作方式开始。他不是在让 Claude 向他解释代码，他是自己解释然后请求验证。

一旦对共同理解满意了，他让 Claude Code 把它写到一个 Markdown 文件中。这样他就有了一个结构化的、书面形式的特性描述。注意——他在记录一个特定的特性，而不是整个代码库。这种聚焦的方式保持了事物的可管理和相关。有了文档化的上下文，他用 /clear 命令开始一个全新的会话。这个干净的开始是有意为之的：它迫使你明确表述下一个阶段需要什么上下文。

这是一个极其实用的模式：理解 → 文档化 → 清理 → 用文档启动新会话。 你把"Claude 需要知道的"从对话历史中提取到文件中，然后用文件——而不是冗长的对话——来提供上下文。

策略 3：Compress —— 压缩过长的上下文

当对话不可避免地变长时，你需要压缩策略。

Claude Code 提供了三种压缩机制：

/clear——彻底清除

当你完成一个功能的实现并开始调试一个不相关的问题时，运行 /clear。这会完全重置上下文窗口。第一个任务的上下文对第二个任务来说纯粹是噪音。重新开始给了代理一个干净的 160K+ token 空间，而不是一个被污染的 80K。

/compact——有选择性的压缩

使用 /clear 在任务之间频繁重置上下文。当自动压缩触发时，Claude 会总结最重要的内容，包括代码模式、文件状态和关键决策。要获得更多控制，运行 /compact <指令>，比如 /compact 聚焦于 API 变更。

不要等自动压缩。在完成一个功能、修复一个 bug 或达到任何自然停顿点后，运行 /compact 加上自定义保留指令。总结的质量会更高，因为在那个时刻上下文是干净的。

自动压缩（Auto-compaction）

对于长时间运行的对话和代理式工作流，服务器端压缩是上下文管理的主要策略。压缩通过在接近上下文窗口限制时自动总结较早的上下文来扩展长时间运行对话的有效上下文长度。这不仅仅是关于保持在 token 上限之下。随着对话变长，模型难以在完整历史中保持专注。压缩通过用简洁的总结替换陈旧内容来保持活跃上下文的聚焦和高效。

关键的设计细节：

在 CLAUDE.md 中自定义压缩行为，加上类似"压缩时，始终保留修改文件的完整列表和所有测试命令"的指令，以确保关键上下文在总结过程中保存下来。

这是一个被大多数人忽略的技巧——你可以在 CLAUDE.md 中告诉 Claude "压缩时什么必须保留"。 默认的压缩可能会丢掉你最关心的细节，但自定义指令可以改变这一点。

/btw——零上下文成本查询

对于不需要留在上下文中的快速问题，使用 /btw。答案出现在一个可关闭的浮层中，永远不会进入对话历史，所以你可以检查一个细节而不增长上下文。

策略 4：Isolate —— 隔离上下文

用"使用子代理来调查 X"来委派研究任务。它们在独立上下文中探索，保持你的主对话干净用于实现。由于上下文是你的根本约束，子代理是最强大的可用工具之一。当 Claude 研究代码库时，它读取大量文件，所有这些都消耗你的上下文。子代理在独立上下文窗口中运行并报回摘要。

子代理帮你通过将探索和实现保持在主对话之外来保留上下文，通过限制子代理可以使用的工具来强制约束。最有效的子代理用途之一是隔离产生大量输出的操作。在子代理中运行测试、获取文档或处理日志文件，冗长的输出保持在子代理的上下文中，只有相关的摘要返回到你的主对话。

子代理是 Context Engineering 的终极武器。 让我画一张对比图来说明：

text

没有子代理：
┌─────────────────────────────────────────┐
│ 主上下文窗口                               │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌──────┐      │
│ │指令  │ │文件1 │ │文件2 │ │ ...  │      │
│ │     │ │     │ │     │ │文件15 │      │
│ └─────┘ └─────┘ └─────┘ └──────┘      │
│ ← 上下文被 15 个文件的内容淹没              │
│ ← 指令被推到角落，注意力被稀释              │
└─────────────────────────────────────────┘

有子代理：
┌──────────────────────┐   ┌──────────────┐
│ 主上下文窗口           │   │ 子代理上下文   │
│ ┌─────┐  ┌─────────┐ │   │ 文件1..15    │
│ │指令  │  │50 token │ │   │ 搜索结果     │
│ │     │  │摘要     │ │   │ 中间推理     │
│ └─────┘  └─────────┘ │   │ ← 所有噪音   │
│ ← 干净、聚焦           │   │   留在这里    │
└──────────────────────┘   └──────────────┘

这就是实际的价值。不是并行性，不是专业化，不是命名代理的组织整洁性。而是隔离防止了在长会话中复合积累的 Context Rot。

四、Context Engineering 的六个实操层级

四大策略提供了概念框架。现在让我把它们转化为你在 Claude Code 中可以直接执行的六个具体层级，从最简单到最高级。

层级 1：管好你的 CLAUDE.md

这是最基础的层级，但大多数人在这里就已经出了问题。

这些工具拥有广泛的编程知识，但它们缺乏项目记忆：每次会话开始时都没有对先前会话、已建立的规范或过去错误的感知。单文件清单（.cursorrules、CLAUDE.md、AGENTS.md）无法扩展到中等代码库之上。

这引出了 CLAUDE.md 设计的核心矛盾：它在每次会话都加载（所以要精简），但它是 Claude 唯一的持久记忆（所以要全面）。

解决方案是分层：

text

project-root/
├── CLAUDE.md                    # 顶层：200 行以内，核心规则
├── src/
│   ├── auth/
│   │   └── CLAUDE.md            # 认证模块的特定规范
│   ├── api/
│   │   └── CLAUDE.md            # API 层的特定规范
│   └── frontend/
│       └── CLAUDE.md            # 前端规范
└── .claude/
    └── skills/                  # 按需加载的 Skill

当 Claude 在 src/auth/ 目录工作时，它会自动加载该目录的 CLAUDE.md。在 src/frontend/ 工作时，加载前端的 CLAUDE.md。每一层只包含该层需要的信息。

在 Claude Code 项目中，72.6% 会指定应用架构，这种模式在跨 Claude Code、Codex 和 GitHub Copilot 的 2,303 个文件中普遍适用。而在 使用配置清单的项目中，定量的效力证据正在涌现：AGENTS.md 文件的存在与中位运行时减少 29% 和输出 token 减少 17% 相关。

层级 2：主动使用 /clear 和 /compact

大多数人把 /clear 和 /compact 当作"出了问题才用"的应急工具。但它们应该是你的日常节律。

反直觉地——越早越好。在 60-65% 的上下文使用率时，代理仍然能写出清晰、结构化的、包含具体细节的交接文档。在 75%+ 时，交接质量下降——模糊的总结，遗漏的状态。在你注意到退化之前就轮换，而不是之后。Claude Code 的自动压缩在大约 80% 时触发，所以在 65% 轮换给了足够的余量来干净地完成交接。

实操建议：

text

会话模式 1：任务切换 → /clear
  完成功能 A → /clear → 开始调试 B
  理由：A 的上下文对 B 是纯噪音

会话模式 2：长任务中间 → /compact 加自定义指令
  实现了 3 个子功能 → /compact 保留文件列表和测试命令
  理由：保留关键信息，丢弃中间细节

会话模式 3：快速查询 → /btw
  "这个函数的返回类型是什么？" → /btw
  理由：答案不需要留在对话历史中

层级 3：规划和实现分会话

对于较大的功能，让 Claude 先面试你。从一个简短的提示开始，让 Claude 用 AskUserQuestion 工具来面试你。Claude 会问你可能没有考虑到的事情，包括技术实现、UI/UX、边缘情况和权衡。

我想构建 [简要描述]。用 AskUserQuestion 工具详细面试我。问技术实现、UI/UX、边缘情况、关注点和权衡。不要问显而易见的问题，深入我可能没有考虑到的困难部分。持续面试直到我们覆盖了所有内容，然后写一份完整的规格到 SPEC.md。

一旦规格完成，启动一个全新的会话来执行它。新会话有干净的上下文，完全聚焦于实现，而且你有一份可以参考的书面规格。

这是一种非常强大的模式：用一个会话来规划，用另一个会话来实现。

规划会话产生大量的中间思考和讨论——对实现来说全是噪音。通过把规划输出写到 SPEC.md 文件中，然后 /clear 开始新会话，你给了实现会话一个干净的、完全聚焦的上下文。

层级 4：子代理隔离

子代理启动时需要时间来收集上下文。使用子代理的场景：任务产生你不需要在主上下文中的冗长输出；你想强制特定的工具限制或权限；工作是自包含的且可以返回一个摘要。当你需要可复用的提示或在主对话上下文中运行的工作流时，考虑使用 Skills 而非子代理。对于关于对话中已有内容的快速问题，使用 /btw 而非子代理。子代理不能派生其他子代理。

关键决策：Skill vs 子代理，什么时候用哪个？

text

Skill（在主上下文中运行）：
  ✅ 你需要 Claude 按照特定流程工作（编码规范、审查标准）
  ✅ 输出是你需要在对话中继续使用的
  ✅ 工作流需要你的交互（Inversion 模式的问答）

子代理（在独立上下文中运行）：
  ✅ 任务产生大量你不需要看的中间输出
  ✅ 你在做研究/探索（读很多文件，大部分无关）
  ✅ 你想防止搜索噪音污染主上下文

层级 5：MCP 工具的上下文管理

MCP（模型上下文协议）工具是最常见的隐藏上下文消耗者。每个 MCP 服务器在每次请求时都将其完整的工具 schema 加载到上下文中，即使没有调用其任何工具。一个有 20 个工具的服务器仅仅因为存在就可能消耗 5,000-10,000 个 token。

Claude Code 现在在 MCP 工具将消耗超过 10% 的上下文时自动启用工具搜索。工具搜索不是预先加载每个工具 schema，而是延迟工具定义并按需加载。在一个基准测试中，这将 MCP token 开销从 51K 减少到 8.5K——总上下文使用减少了 46.9%。

实操建议：

• 禁用你当前任务不需要的 MCP 服务器
• 如果同时有 3+ 个 MCP 服务器，确认工具搜索是否已自动启用
• 定期审计你的 MCP 配置——每个服务器的 token 开销是多少？

层级 6：自定义压缩指令 + Context Rotation

最高级的策略是主动控制 Claude 在压缩时保留什么。

在 CLAUDE.md 中自定义压缩行为，使用类似"压缩时，始终保留修改文件的完整列表和所有测试命令"的指令。

以及 Context Rotation——在上下文退化之前主动切换：

自动上下文轮换是 Context Engineering 中的一种模式。其他的包括子代理委派、渐进式上下文加载和结构化交接契约。解决方案不必和我的一模一样。但这个模式——检测压力、检查点状态、清理、恢复——是普遍的。无论它实现为 hooks + tmux、原生 IDE 支持还是语言服务器协议扩展，需求都是一样的：AI 编码会话需要一种方法来轮换上下文而不丢失连续性。

五、Context Engineering 在 Skill 设计中的具体应用

所有前面的理论，最终要落回我们的核心话题——Skill。Context Engineering 如何改变你设计和使用 Skill 的方式？

5.1 SKILL.md 的每一行都有成本

你写在 SKILL.md 中的每一个字符，在 Skill 被调用时都会消耗上下文空间。这意味着第三篇提到的"500 行限制"不只是样式建议——它是 Context Engineering 的强制约束。

好的做法是过程放 SKILL.md，知识放 references/：

text

SKILL.md（被调用时加载）：
  ✅ 工作流步骤
  ✅ 输出格式
  ✅ Gotchas
  ❌ 详细的 KPI 定义 → 移到 references/kpi-definitions.md
  ❌ 完整的风格指南 → 移到 references/style-guide.md
  ❌ 所有示例 → 移到 examples/

references/ 中的文件只在 SKILL.md 明确引用时才加载——这就是渐进式披露的价值。一个 500 行的 SKILL.md 比一个 200 行的 SKILL.md + 300 行的 references 多消耗一倍的即时上下文。

5.2 Description 的 token 成本

回忆第二篇：所有 Skill 的 description 加起来有大约 15,000 字符的预算上限。这不只是"触发精度"的问题——每一个安装但不使用的 Skill 都在消耗这个预算，稀释其他 Skill 被发现的概率。

实操建议：定期清理你安装的 Skills。如果一个 Skill 过去两周没有被触发过，卸载它。

5.3 Skill + 子代理 = 最优组合

Skill 和子代理的结合是最符合 Context Engineering 原则的设计：

使用 context: fork 在 Skill 中，Skill 内容被注入到你指定的代理中。两者使用相同的底层系统。

这意味着你可以设计一个 Skill，让它的指令在独立的子代理上下文中运行——主对话只收到最终结果。

YAML

---
name: deep-code-review
description: >
  ALWAYS invoke this skill for comprehensive code reviews.
context: fork
---

加了 context: fork 后，这个 Skill 的整个执行过程——读取文件、对照清单逐项检查、生成报告——都在隔离的上下文中完成。主对话只看到最终的审查报告。

这是 Context Engineering 的理想状态：高信号输出，零噪音泄露。

六、一个完整的 Context Engineering 工作流

把上述所有内容串联起来，这是我推荐的 Claude Code 工作流：

text

阶段 1：会话初始化（每次会话必做）
┌──────────────────────────────────────────┐
│ ✅ CLAUDE.md 自动加载（< 200 行）          │
│ ✅ 目录级 CLAUDE.md 按位置自动加载          │
│ ✅ Skills 元数据加载（~100 token/Skill）   │
│ ✅ 禁用不需要的 MCP 服务器                  │
│ 总成本：2,000-5,000 token                  │
└──────────────────────────────────────────┘
            ↓
阶段 2：规划（独立会话）
┌──────────────────────────────────────────┐
│ ✅ 让 Claude 面试你（Inversion 模式）       │
│ ✅ 输出写入 SPEC.md 或 PRD.md              │
│ ✅ /clear 结束规划会话                      │
└──────────────────────────────────────────┘
            ↓
阶段 3：实现（干净会话）
┌──────────────────────────────────────────┐
│ ✅ 引用 SPEC.md 开始实现                    │
│ ✅ 研究性工作委派给子代理                    │
│ ✅ 每 30-45 分钟检查上下文使用率             │
│ ✅ 达到 60-65% 时主动 /compact              │
│ ✅ 任务切换时 /clear                        │
│ ✅ 快速查询用 /btw                          │
└──────────────────────────────────────────┘
            ↓
阶段 4：验证（可选的独立会话）
┌──────────────────────────────────────────┐
│ ✅ /clear 后启动全新会话                    │
│ ✅ 用审查型 Skill 检查实现结果               │
│ ✅ 干净上下文 = 更准确的审查                  │
└──────────────────────────────────────────┘

七、常见误区

误区 1：「1M 上下文意味着不用管上下文了」

1M 窗口不是让你把所有东西都倒进去然后祈祷的邀请。加载不相关的文件浪费 token 并稀释 Claude 用来优先分配注意力的信号。

任何具有固定上下文窗口的 AI 代理——Cursor、Cline、Codex CLI、Gemini Code——都会在窗口填满时退化。"Lost in the Middle"研究（斯坦福，2024）表明这是一个根本性的 LLM 限制：随着上下文增长，性能下降 15-47%。

1M 窗口给了你更多的余地，但 Context Rot 的基本物理定律没有改变。

误区 2：「子代理解决一切」

子代理在独立上下文窗口中运行并只返回摘要，保持你的主上下文干净。但子代理不能解决核心问题：你的主会话在多小时的实现工作中仍然会填满。子代理减缓了 Rot 的速率；上下文轮换解决的是 Rot 本身。两者一起使用以获得最长的会话寿命。

误区 3：「等自动压缩就好」

生产测试中最大的惊喜是：65% 已经算迟了。目前在尝试 60% 就轮换——对于上下文质量至关重要的复杂任务甚至 55%。原因：上下文质量不是线性退化的。这与研究一致——"Lost in the Middle"论文表明退化在上下文窗口的后半段加速，而不是在整个长度上均匀分布。

自动压缩是安全网，不是策略。主动管理总是优于被动触发。

误区 4：「Context Engineering 很复杂」

从简单开始——用静态提示和工具开始，只在需要时添加动态元素。逐步测试——每次添加一个 Context Engineering 特性。监控性能——跟踪模型调用、token 使用和延迟。

你不需要一开始就实施所有六个层级。从层级 1（管好 CLAUDE.md）和层级 2（主动使用 /clear）开始，这两个动作就能解决 80% 的上下文问题。

八、你今天就应该做的 3 件事

✅ 行动 1：审计你的上下文消耗

下次使用 Claude Code 时，持续关注上下文使用率。观察：

• 你的 CLAUDE.md 有多少行？超过 200 行请精简。
• 你安装了多少 MCP 服务器？每个消耗多少 token？
• 你安装了多少 Skills？过去两周没触发的请卸载。

✅ 行动 2：建立 /clear 的习惯

从现在开始，在以下时刻无条件运行 /clear：

• 完成一个任务后，开始另一个任务前
• 规划完成后，开始实现前
• 调试完成后，开始新功能前

这是成本最低、收益最高的 Context Engineering 动作。

✅ 行动 3：把一个研究任务委派给子代理

下次你需要 Claude 读取多个文件来理解某个问题时，不要直接让它在主会话中做。改用：

text

请派一个子代理去调查我们的认证系统如何处理 token 刷新，
以及是否有现成的 OAuth 工具可以复用。

观察两件事：主会话的上下文增长了多少（应该很少），以及子代理返回的摘要质量如何。

本文的知识框架总结

text

Context Engineering
│
├── 定义
│   ├── 从 Prompt Engineering（怎么问）到 Context Engineering（模型看到什么）
│   └── 核心目标：最小的高信号 token 集合 → 最大化期望结果
│
├── 核心威胁：Context Rot
│   ├── 所有 18 个前沿模型都受影响
│   ├── 三种失败模式：Poisoning / Confusion / Clash
│   └── 1M 窗口不是解药（Context Rot 的物理定律不变）
│
├── 四大策略
│   ├── Write：CLAUDE.md + Skills（持久化知识到文件）
│   ├── Select：只加载相关信息（三层知识架构）
│   ├── Compress：/clear + /compact + 自定义压缩指令
│   └── Isolate：子代理（独立上下文 → 只返回摘要）
│
├── 六个实操层级
│   ├── 1. 管好 CLAUDE.md（< 200 行 + 目录级分层）
│   ├── 2. 主动 /clear 和 /compact（60-65% 就行动）
│   ├── 3. 规划和实现分会话（SPEC.md 作为桥梁）
│   ├── 4. 子代理隔离（研究/探索任务委派）
│   ├── 5. MCP 工具管理（禁用无关服务器）
│   └── 6. 自定义压缩指令 + Context Rotation
│
└── 对 Skill 设计的影响
    ├── SKILL.md 的每一行都有 token 成本
    ├── 过程放 SKILL.md，知识放 references/
    ├── 未使用的 Skill 也消耗 description 预算
    └── context: fork = Skill 在隔离上下文中运行

下一篇预告

你现在掌握了单个 Skill 的完整知识体系：本质、触发、模式、架构、上下文管理。

下一个问题是：多个 Skill 如何协同工作？

第 6 篇将深入编排模式——Command → Agent → Skill 的三层架构、子代理调度、并行执行和结果汇聚。我们将讨论一个更大的问题：当你有 5 个以上的 Skills 时，如何把它们编排成一个完整的工作流，而不是一堆独立的工具？

本文是「Claude Code Skills 完全指南」系列的第 5 篇，共 10 篇。全系列目录：