本文是「Claude Code Skills 完全指南」系列的第五篇。如果你尚未构建过自己的 Skill，建议先阅读本系列的前四篇文章。
写在前面
前四篇文章已经为你搭建了构建 Skill 的完整框架——从理解其本质、设计精准触发器、选择合适的模式，到组织内容架构。
但实战过的人很可能都遇到过这样一个前四篇未曾正面解答的窘境：
你的 Skill 明明设计精良，在会话开始后的前 20 分钟表现出色。可半小时后，Claude 似乎开始“忘记”你的 Skill 指令。它不再遵循你设定的输出格式，跳过了 KPI 树的第三级细节，甚至在你明确要求执行脚本的地方自行估算数值。
你可能会怀疑是 Skill 写得不好，于是反复调试正文和描述。但问题像幽灵一样时好时坏，毫无规律可循。
真正的原因，往往不在 Skill 本身。
问题出在 Claude 的上下文窗口（Context Window） 上。这个窗口保存着你整个对话的内容：每一条消息、Claude 读取的每一个文件、每一个命令输出。它容量有限，却极易被填满。一次简单的调试或代码库探索，就可能产生并消耗数万个 token。当上下文窗口接近饱和时，Claude 的性能会自然衰减，表现为“遗忘”早期指令或犯更多错误。
上下文窗口，正是你在使用 Claude Code 时需要管理的、最稀缺的资源。
本文将聚焦于此。我们不谈“上下文窗口是什么”这种百科知识，而是直击核心痛点：作为一名日常使用 Claude Code 的开发者，究竟该如何有效管理这一关键资源？ 欢迎在 云栈社区 与其他开发者交流你的实战心得。
一、从 Prompt Engineering 到 Context Engineering
1.1 一个定义的演进
要理解 Context Engineering（上下文工程），首先要看清它与 Prompt Engineering（提示词工程）的区别。
我们可以将 Context Engineering 视为 Prompt Engineering 的自然演进。Prompt Engineering 研究的是如何编写和组织指令，以从大语言模型（LLM）中获得最优结果。而 Context Engineering 则是一套策略集合，旨在策划和维护 LLM 在推理过程中所能“看到”的最优 token 集合，这包括了所有可能进入上下文的其他信息。
简单来说：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 并非软件缺陷，而是 Transformer 注意力机制的一个根本性质。
研究机构 Chroma 测试了 18 个前沿模型，发现每一个都存在 Context Rot。它是随着输入上下文变长，LLM 输出质量发生的可测量的退化。输入越多 token，输出质量越差，即使模型的上下文窗口远未填满。不是某些模型，也不是大多数，而是所有模型都如此。
对 Claude Code 而言，其影响是直接的：
当你的上下文使用量达到约三分之二容量时，响应质量会明显下降——并非因为模型本身变差，而是因为上下文充满了噪音，模型必须对所有内容平等地分散其有限的注意力。一个经典的解决方案是多代理（Agent）架构：父代理派生子代理去执行具体任务，每个子代理拥有自己独立的上下文窗口。任务完成后，子代理仅将最终输出返回给父代理，所有中间过程的噪音都留在了子代理的上下文中，永远不会污染父代理的主对话。父代理得到的始终是高纯度的信号。
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 的所有元数据。这些无关信息严重稀释了它对当前“安全审查”这一核心任务的注意力。
- Context Clash：你的项目
CLAUDE.md 中规定“输出必须简洁”，但你调用的报告生成 Skill 却要求“包含完整的五段式分析”。Claude 陷入两条矛盾指令的夹缝中，输出结果可能不伦不类。
2.3 一个反直觉的真相：1M 窗口不是解药
2026年3月，Anthropic 将 Claude 的上下文窗口从 200K 扩展到了 1M token，且未额外收费。许多人以为这意味着上下文管理可以放松了。
这是一个误区。上下文纪律依然至关重要。 1M 的窗口不是邀请你把所有东西都倒进去然后祈祷的许可证。加载不相关的文件只会浪费 token 并稀释 Claude 本应用于优先任务的注意力信号。编写良好的 CLAUDE.md 文件、精心设计的 Skills、有意识的会话管理仍然是最佳实践。1M 窗口只是给了你更多容错和操作的余地。
修复 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.md 来解释你的认证模式。当 Claude 在该目录下工作时，它会自动找到并加载这个文件。建议从 /init 生成的基线文件开始，然后花10分钟编辑它，添加你团队的 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.md 类文件中。
b) 产品需求文档——产品应该做什么的清晰规格。
c) 深层技术知识——对核心技术、数学概念、算法和关键中间件的专业理解，这部分内容常常可以在专业的 技术文档 中找到参考。
“Select” 策略的核心操作是：不要让 Claude 自己在浩瀚的信息海洋中盲目搜寻，也不要一股脑把所有东西都丢给它——你需要主动选择并交付它完成当前任务所必需的信息。
一位开发者分享了一个极其实用的“Select”方法：
他发现，一个非常有效的工作流是从一个简单的前提开始：假设自己已经理解了正在处理的代码，但想验证这种理解并与 Claude Code 建立共享上下文。 他首先用自己的话描述某个功能的工作方式。他不是在让 Claude 向他解释代码，而是自己在解释，然后请求 Claude 验证。
一旦对共同理解感到满意，他就让 Claude Code 将这段描述写到一个 Markdown 文件中。这样，他就拥有了一个结构化的、书面形式的功能规格说明。关键点在于——他记录的是一个特定的功能，而非整个代码库。这种聚焦的方式保持了事物的可管理性和相关性。
随后，他使用 /clear 命令开始一个全新的会话。这个“干净的起点”是刻意为之的：它迫使你明确表述下一个阶段具体需要什么上下文。
这是一个极其实用的模式：理解 → 文档化 → 清理 → 用文档启动新会话。 你把“Claude 需要知道的”从冗长的对话历史中提取出来，沉淀到文件里，然后用文件——而非历史记录——来提供精准的上下文。
策略 3：Compress —— 压缩过长的上下文
当对话不可避免地变长时，你需要“压缩”策略。
Claude Code 提供了三种主要的压缩机制：
-
/clear —— 彻底清除
当你完成一个功能的实现，并要开始调试一个不相关的问题时，果断运行 /clear。这会完全重置上下文窗口。第一个任务的上下文对第二个任务而言纯粹是噪音。重新开始给了 AI 一个干净的、完整的上下文空间，而不是一个已被污染的、半满的窗口。
-
/compact —— 有选择性的压缩
使用 /clear 在不同任务间频繁重置上下文。当自动压缩触发时，Claude 会尝试总结之前会话中最重要的内容，包括代码模式、文件状态和关键决策。但你可以获得更多控制权：运行 /compact <指令>，例如 /compact 聚焦于API变更。
不要等待自动压缩。 在完成一个功能、修复一个 bug 或达到任何自然停顿点后，主动运行 /compact 并附上自定义的保留指令。这样生成的总结质量会更高，因为在那时上下文是相对干净和聚焦的。
-
自动压缩（Auto-compaction）
对于长时间运行的对话和代理式工作流，服务器端压缩是上下文管理的主要后台策略。当上下文长度接近窗口限制时，压缩机制会自动总结较早的对话内容，用简洁的摘要替换冗长的原始文本，从而扩展有效上下文长度。这不仅仅是为了保持在 token 上限之下。随着对话变长，模型难以在完整历史中保持专注，压缩通过用总结替换陈旧内容来保持活跃上下文的聚焦和高效。
关键技巧：
你可以在 CLAUDE.md 中自定义压缩行为！添加类似 “压缩时，始终保留修改文件的完整列表和所有运行过的测试命令” 的指令，以确保关键上下文在总结过程中被保留下来。
这是一个被大多数人忽略的强大功能——你可以在 CLAUDE.md 中明确告诉 Claude “压缩时什么必须保留”。 默认的压缩算法可能会丢掉你最关心的细节，但一条自定义指令就能改变这一点。
-
/btw —— 零上下文成本查询
对于那些不需要留在上下文中的、快速的、一次性问题，使用 /btw。答案会出现在一个可关闭的浮动层中，永远不会进入主对话历史，因此你可以查询一个细节而不导致上下文增长。
策略 4：Isolate —— 隔离上下文
使用类似“请派一个子代理去调查 X”这样的指令来委派研究型任务。子代理在独立的上下文窗口中运行探索，完成后仅将摘要返回主对话，从而保持你的主对话上下文干净，专注于核心实现。
由于上下文是根本性约束，子代理是最强大的可用工具之一。当 Claude 研究代码库时，它会读取大量文件，所有这些都消耗你的主上下文。子代理将这些探索活动隔离在自己的窗口中，只报回精华。
子代理最有效的用途之一是隔离那些会产生大量输出的操作。在子代理中运行测试套件、获取冗长的文档或处理日志文件，让这些冗长的输出留在子代理的上下文中，只有相关的摘要返回到你的主对话。
可以说，子代理是 Context Engineering 的终极武器。 让我们通过一个对比图来直观理解：
没有子代理：
┌─────────────────────────────────────────┐
│ 主上下文窗口 │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌──────┐ │
│ │指令 │ │文件1 │ │文件2 │ │ ... │ │
│ │ │ │ │ │ │ │文件15 │ │
│ └─────┘ └─────┘ └─────┘ └──────┘ │
│ ← 上下文被 15 个文件的内容淹没 │
│ ← 指令被推到角落，注意力被稀释 │
└─────────────────────────────────────────┘
有子代理：
┌──────────────────────┐ ┌──────────────┐
│ 主上下文窗口 │ │ 子代理上下文 │
│ ┌─────┐ ┌─────────┐ │ │ 文件1..15 │
│ │指令 │ │50 token │ │ │ 搜索结果 │
│ │ │ │摘要 │ │ │ 中间推理 │
│ └─────┘ └─────────┘ │ │ ← 所有噪音 │
│ ← 干净、聚焦 │ │ 留在这里 │
└──────────────────────┘ └──────────────┘
这就是其实际价值。主要优势并非并行性、专业化或组织整洁性，而在于隔离有效防止了在长会话中不断累积、复合放大的 Context Rot。
四、Context Engineering 的六个实操层级
四大策略提供了概念框架。现在，让我们把它们转化为你在 Claude Code 中可以直接执行的六个具体层级，从最简单到最高级。
层级 1：管好你的 CLAUDE.md
这是最基础的层级，但大多数人在这里就已经出了问题。
AI 编码助手拥有广泛的编程知识，但它们缺乏“项目记忆”：每次新会话开始时，它们对之前的会话、已建立的规范或过去犯过的错误都没有感知。而传统的单文件清单（如 .cursorrules、CLAUDE.md、AGENTS.md）无法扩展到中等及以上规模的代码库。
这引出了 CLAUDE.md 设计的核心矛盾：它需要在每次会话开始时都被加载（所以要力求精简），但它又是 Claude 关于你项目的唯一持久化记忆（所以要力求全面）。
解决方案是分层：
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/ 下工作时，则加载前端的规范。每一层只包含该层工作所需的最相关信息。
层级 2：主动使用 /clear 和 /compact
大多数人把 /clear 和 /compact 当作“出了问题才用”的急救工具。但它们应该成为你编码的日常节律。
一个反直觉的结论是：越早使用，效果越好。 观察发现，在上下文使用率达到 60-65% 时，AI 代理仍然能写出清晰、结构化、包含具体细节的“交接文档”。但当使用率超过 75% 时，交接质量会显著下降——总结变得模糊，关键状态被遗漏。在你注意到性能退化之前就主动轮换上下文，而不是在之后。 Claude Code 的自动压缩大约在 80% 使用率时触发，因此在 65% 时就主动轮换，能给你留出足够的余量来干净地完成“交接”。
实操建议：
会话模式 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：子代理隔离
子代理在启动时需要一些时间来收集其任务上下文。使用子代理的典型场景是：
- 任务会产生你不需要保留在主上下文中的冗长输出（如日志、完整搜索结果）。
- 你想强制实施特定的工具限制或权限。
- 工作是自包含的，并且可以返回一个简洁的摘要。
何时使用 Skill？何时使用子代理？关键决策：
Skill（在主上下文中运行）：
✅ 你需要 Claude 按照特定流程工作（如严格的编码规范、审查标准）
✅ 输出结果是你需要在主对话中继续使用和讨论的
✅ 工作流需要你的持续交互（例如 Inversion 模式下的问答）
子代理（在独立上下文中运行）：
✅ 任务会产生大量你不需要看到的中间输出
✅ 你在做研究/探索（需要读取很多文件，其中大部分可能无关）
✅ 你想防止搜索噪音或探索过程的混乱污染主上下文
层级 5：MCP 工具的上下文管理
MCP（模型上下文协议）工具是最常见的隐藏“上下文消耗者”。每个 MCP 服务器在每次请求时，都会将其完整的工具模式定义（schema）加载到上下文中，即使你没有调用它的任何工具。 一个拥有 20 个工具的服务器，仅仅因为其存在，就可能消耗 5，000-10，000 个 token。
为此，Claude Code 现在会在 MCP 工具可能消耗超过 10% 上下文时，自动启用“工具搜索”功能。工具搜索不会预先加载每个工具的完整定义，而是延迟加载，仅在可能相关时按需引入。在一个基准测试中，这将 MCP 的 token 开销从 51K 减少到了 8.5K——总上下文使用量减少了 46.9%。
实操建议：
- 禁用你当前任务不需要的 MCP 服务器。
- 如果同时启用了 3 个或更多 MCP 服务器，确认“工具搜索”功能是否已自动启用（或手动检查）。
- 定期审计你的 MCP 配置——估算每个服务器大致的 token 开销是多少？
层级 6：自定义压缩指令 + 上下文轮换
最高级的策略是 主动控制 Claude 在压缩上下文时具体保留什么。
如上所述，在 CLAUDE.md 中加入自定义压缩指令，例如：“压缩时，始终保留修改文件的完整列表和所有运行过的测试命令。”
以及实践 Context Rotation（上下文轮换）——在上下文质量明显退化之前就主动切换：
自动上下文轮换是 Context Engineering 中的一种高级模式。其核心思想是：检测到上下文压力（如达到 60% 使用率）-> 检查点保存当前关键状态 -> 清理（/clear 或 /compact） -> 从检查点恢复工作。无论这个模式是通过脚本钩子、原生 IDE 支持还是其他方式实现，需求都是一样的：AI 编码会话需要一种方法来轮换上下文，同时不丢失工作的连续性。
五、Context Engineering 在 Skill 设计中的具体应用
所有前面的理论，最终要落回我们的核心话题——Skill。Context Engineering 将如何改变你设计和使用 Skill 的方式？
5.1 SKILL.md 的每一行都有成本
你写在 SKILL.md 中的每一个字符，在该 Skill 被触发调用时，都会消耗实时的上下文空间。这意味着本系列第三篇提到的“500 行左右”限制，不只是一种样式建议——它更是 Context Engineering 的强制性约束。
好的做法是 “过程放 SKILL.md，详细知识放 references/ 目录”：
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 原则的顶级设计：
在 Skill 的 Frontmatter 中使用 context: fork 参数。添加此参数后，该 Skill 的内容将被注入到一个独立的子代理中执行。这意味着你可以设计一个 Skill，让它的全套复杂指令都在独立的上下文中运行——主对话只会收到最终的结果。
示例 (deep-code-review.skill.yml):
---
name: deep-code-review
description: >
ALWAYS invoke this skill for comprehensive code reviews.
context: fork
---
添加了 context: fork 后，这个“深度代码审查” Skill 的整个执行过程——读取相关文件、对照检查清单逐项审查、生成报告——都在一个隔离的子代理上下文中完成。主对话最终看到的，只是一份干净、简洁的审查报告。
这是 Context Engineering 所追求的理想状态：高价值的信号输出，零过程噪音的泄露。
六、一个完整的 Context Engineering 工作流
把上述所有内容串联起来，以下是我推荐的 Claude Code 日常使用工作流：
阶段 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、GitHub Copilot等）都会在窗口填满时经历性能退化。“迷失在中间”（Lost in the Middle）的研究（斯坦福，2024）表明这是一个根本性的 LLM 限制：随着上下文增长，性能可能下降 15-47%。1M 窗口给了你更多缓冲余地，但 Context Rot 的基本物理定律没有改变。
误区 2：「子代理解决一切」
子代理通过在独立上下文中运行并只返回摘要，确实能保持你的主上下文干净。但子代理不能解决核心问题：你的主会话在长达数小时的实现工作中，仍然会逐渐被填满。子代理减缓了 Context Rot 累积的速率；而主动的上下文轮换（/clear， /compact）解决的才是 Rot 本身。两者结合使用，才能获得最长的、高质量的会话寿命。
误区 3：「等自动压缩就好」
生产环境测试中的一个关键发现是：等到 65% 使用率才行动，已经算晚了。目前最佳的实践是尝试在 60% 左右就主动轮换——对于那些上下文质量至关重要的复杂任务，甚至可以考虑提前到 55%。原因在于：上下文质量的退化不是线性的。这与“Lost in the Middle”论文的结论一致——退化在上下文窗口的后半段会加速，而非在整个长度上均匀分布。自动压缩是安全网，而不是你的核心策略。主动管理永远优于被动触发。
误区 4：「Context Engineering 很复杂」
从简单的开始——先用好静态提示（CLAUDE.md）和基本工具。逐步测试——每次只添加一个 Context Engineering 特性（比如先养成 /clear 的习惯）。监控性能——留意模型调用次数、token 使用情况和响应质量。
你不需要一开始就实施所有六个层级。从层级 1（管好 CLAUDE.md）和层级 2（主动使用 /clear）开始，这两个动作就能解决你 80% 的上下文管理问题。
八、你今天就应该做的 3 件事
✅ 行动 1：审计你的上下文消耗
下次使用 Claude Code 时，有意识地持续关注右下角的上下文使用率（百分比）。并问自己：
- 你的项目
CLAUDE.md 有多少行？如果超过 200 行，请立即着手精简。
- 你安装启用了多少个 MCP 服务器？每个大概会消耗多少 token？（可以估算）
- 你安装了多少个 Skills？过去两周一次都没触发过的，请考虑卸载。
✅ 行动 2：建立 /clear 的习惯
从现在开始，在以下时刻无条件地运行 /clear：
- 完成一个开发任务后，开始另一个不相关的任务前。
- 功能规划完成后，开始具体实现前。
- 调试完一个问题后，开始编写新功能前。
这是成本最低、收益最高的 Context Engineering 动作，没有之一。
✅ 行动 3：把一个研究任务委派给子代理
下次你需要 Claude 通读多个文件来理解某个复杂模块或问题时，不要直接在主会话中下达指令。改用这个模式：
请派一个子代理去调查我们的认证系统如何处理 token 刷新，
以及代码库中是否有现成的 OAuth 工具函数可以复用。
然后观察两件事：1) 你的主会话的上下文长度增长了多少（应该微乎其微）；2) 子代理返回的摘要质量如何，是否包含了关键信息。
本文的知识框架总结
Context Engineering
│
├── 定义
│ ├── 从 Prompt Engineering（怎么问）到 Context Engineering（模型看到什么）
│ └── 核心目标：最小的高信号 token 集合 → 最大化期望结果概率
│
├── 核心威胁：Context Rot
│ ├── 所有前沿模型都受影响的根本现象
│ ├── 三种失败模式：Poisoning（污染） / Confusion（混淆） / Clash（冲突）
│ └── 1M 窗口不是解药（物理定律不变）
│
├── 四大策略
│ ├── 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 的完整知识体系：从本质、触发机制、设计模式、内容架构到本章的上下文管理。
那么，下一个自然浮现的问题是：当拥有多个 Skills 时，它们应该如何协同工作？
第 6 篇我们将深入探讨 编排模式 —— 包括 Command → Agent → Skill 的三层架构、子代理的调度、并行执行与结果汇聚。我们将讨论一个更大的课题：当你的工具箱里积累了 5 个、10 个甚至更多 Skills 时，如何将它们编排成一个流畅、高效的完整工作流，而非一堆孤立散落的工具？
探索更前沿的 人工智能 应用模式，或许能给你带来新的启发。
本文是「Claude Code Skills 完全指南」系列的第 5 篇。
发表于 3 小时前
|
查看: 4|
回复: 0
