优化Claude Code上下文工程：提升AI编码效率的实用指南

你可能有过这样的经历：用Claude Code写代码时，有时候AI给出的结果精准又高效，有时候却产出毫无用处的“垃圾内容”（也就是文中说的“ai slop”）。很多人会把问题归咎于模型本身，但其实核心问题往往出在我们自己身上——在Claude Code这类黑盒AI系统中，“上下文”是我们唯一能掌控的输入项，能否优化好上下文，直接决定了AI编码的最终效果。本文会基于Jarrod Watts的实践经验，拆解Claude Code上下文工程的核心逻辑，从基础操作到进阶技巧，帮你找到最适合的上下文优化策略，让AI真正成为高效的编码助手。

先搞懂：Claude Code的“上下文”到底是什么？

首先要明确一个核心问题：到底什么是Claude Code的上下文？

简单来说，上下文是你向Claude Code发送消息时提供的所有信息——不仅包括你直接输入的提示词，还涵盖系统提示、元数据、你之前的对话内容、AI的思考过程、工具调用记录和回复内容等所有相关信息。可以说，Claude Code生成回复时，能参考的所有信息都属于上下文范畴。

为什么上下文这么关键？因为Claude Code的上下文窗口是有限的——官方标注的是200k tokens，听起来数量不少，但实际使用中会发现，这个空间很快就会被占满。通过/context命令，我们能清晰看到上下文的占用情况：

更重要的是，即便还没达到上下文窗口的上限，Claude Code的性能也会随着上下文内容的增加而下降。这意味着，我们不仅要关注上下文的“量”，更要关注“质”——找到那些“高信号token”，用最少的有效信息，让AI产出最优的结果。

上下文优化的80/20法则：做好基础就赢了大半

很多人会沉迷于Claude Code的各种高级功能——子代理、自定义命令、多代理编排等，但Jarrod Watts的实践经验告诉我们：80/20法则在这里同样适用，做好基础操作，就能达到80%的优化效果，复杂功能的增益其实远没有想象中那么大。

第一步：完成基础配置（必做）

想要让Claude Code的上下文发挥最大价值，先把这三个基础操作做好：

1. 执行/upgrade命令，升级到Max计划：这是发挥Claude Code全部能力的前提，没有这个基础，后续的上下文优化效果会大打折扣；
2. 执行/model命令，切换到Opus 4.5模型：模型的能力直接影响对上下文的理解和利用效率，Opus 4.5是当前Claude Code的旗舰模型，能更好地处理复杂的编码上下文；
3. 执行/init命令，创建配置文件：这个文件能帮助Claude Code快速理解你的项目架构、技术栈、编码规范等基础信息，减少后续沟通中的歧义，让上下文更有针对性。

第二步：遵循基础工作流（核心）

完成基础配置后，遵循简单的工作流就能进一步提升上下文效率：

1. 启动计划模式（Shift + Tab）：先规划再执行，是减少上下文冗余的关键；
2. 让Claude Code主动澄清歧义：请AI针对你的计划提出问题，直到它完全理解你的需求——这一步能提前消除模糊地带，避免后续AI因为理解偏差产出无效内容；
3. 执行并细化计划：先按规划落地，再根据实际效果调整，让上下文始终围绕明确的目标展开。

很多人会觉得高级功能才是提升效率的关键，但实际情况是，把这些基础操作做扎实，比盲目折腾复杂功能更重要。

落地上下文优化：按目标管理对话

做好基础配置后，核心的落地思路是：把每一次新的对话都当成一个明确的目标，严格控制对话的范围。

1. 为每个对话设定清晰的目标

比如，你可以给每个新线程设定这样的具体目标：

• “修复我在用户登录模块遇到的这个bug”
• “为电商APP开发商品收藏功能”
• “优化支付接口的响应速度”

如果是全新的项目，目标可以适当宽泛一些，但这也意味着需要更多的规划和细化——因为范围越广，AI产生理解偏差的可能性就越大。

2. 花足够的时间规划和细化

对于宽泛的项目目标，规划环节要做足功夫：

• 延长规划时间：不要急于让AI开始写代码，先让它输出详细的规划方案；
• 多次复盘规划：让Claude Code反复审查规划内容，覆盖架构设计、最佳实践、安全风险、生产就绪性、测试策略等维度；
• 消除所有歧义：直到AI的提问已经细致到“没什么可问”的程度，确保它完全理解你的项目需求、技术选型和预期结果。

这一步的核心是“用细节填充歧义”，让上下文里的每一个token都能为明确的目标服务，而不是充斥着模糊的、无意义的信息。

上下文出问题了？该重置时就重置

上下文不是一成不变的，我们需要根据实际情况调整，甚至重置——关键是判断什么时候该调整，以及用什么方式调整。

1. 不需要重置的情况

如果一切进展顺利，你接下来要做的任务和当前上下文里的内容相关或相似，那就继续使用当前线程即可——复用已有上下文能减少重复沟通，提升效率。

2. 空间不足时：先压缩，再继续

如果快要达到上下文窗口的上限，不用急着重置，先执行/compact命令——这个命令能压缩现有上下文，腾出更多空间；当然，Claude Code也会利用预留的22.5%缓冲区自动压缩，这也是预留空间的核心作用。

如果你想随时掌握上下文的占用情况，Jarrod Watts还开发了一个实用的Claude Code插件，能直观展示上下文的填充状态。

3. 效果变差时：及时回退或重启

最容易陷入的误区是：当AI产出的内容不符合预期时，还在同一个线程里反复要求“修改”，结果陷入“要求修复→产出更差的内容→更严厉的要求→更糟的结果”的恶性循环。

遇到这种情况，不要硬扛，而是选择以下两种方式：

• 执行/rewind命令：回到对话中进展顺利的节点，从那个位置重新开始；
• 执行/new命令：直接开启新线程。重启时，把原来的提示词优化一下，尤其要明确指出之前哪里出错了、需要避免什么问题，让新的上下文更有针对性。

避开复杂度陷阱：少即是多

在社交平台上，你可能会看到各种眼花缭乱的Claude Code高级玩法：MCP服务器、子代理、技能插件……很多人会觉得“不用这些就是落后了”，但Jarrod Watts的建议是：不要过度复杂化，核心目标是“找到最小的高信号token集合”。

为什么要避免过度复杂？因为很多高级功能会快速消耗你的上下文空间，还会增加成本——比如MCP服务器如果使用不当，会把大量低信号的信息塞进上下文，既占用空间，又降低AI的处理效率，最终得不偿失。

当然，这不是说高级功能没用，而是要学会“聪明地用”——接下来我们会拆解MCP服务器、子代理、技能这三类核心高级功能的正确用法，让它们为上下文优化服务，而不是添乱。

巧用MCP服务器：获取“即时”的优质上下文

MCP服务器本质上是第三方工具，能为Claude Code提供外部的上下文来源，比如技术文档、GitHub代码、Linear工单、Figma设计稿等。

这类工具刚推出时被大肆追捧，但很快有人发现：如果滥用MCP服务器，会疯狂消耗上下文空间，性价比极低。Jarrod Watts的实践经验是，精选少量实用的MCP服务器，聚焦“即时上下文策略”——让AI在需要的时候，自己通过工具获取所需信息。

推荐的3个实用MCP服务器

Jarrod Watts自己长期使用的、性价比很高的MCP服务器有这三个：

1. exa.ai：专为AI代理设计的网页搜索工具，能快速找到最新的技术资讯、解决方案；
2. context7：提供实时更新的AI代理相关文档，确保获取的文档内容是最新的；
3. grep.app：针对GitHub的搜索工具，能快速定位开源项目中的相关代码片段。

如何高效使用MCP服务器？

Jarrod Watts的用法是：让MCP服务器帮自己完成“代码实现相关的调研工作”——这些工作自己也能做，但需要花费大量时间查阅文档、找代码片段，而AI通过MCP服务器能快速完成，且能把调研结果整合到上下文中。

这种“即时上下文策略”的核心是：只在需要的时候获取信息，不提前塞一堆无关的内容到上下文里，让上下文始终保持“高信号、低冗余”。

用子代理省空间、降成本：被低估的实用技巧

子代理是Claude Code的一个强大功能——你可以把它理解为“主代理的助手”，通过/agents命令能查看已配置的子代理。子代理的核心价值，在于帮主代理节省上下文空间，同时降低使用成本。

子代理的核心特点

子代理和主代理相比，有两个关键差异：

1. 拥有独立的上下文窗口：子代理的上下文和主代理完全隔离，不会占用主代理的上下文空间；
2. 可使用不同的模型：子代理可以选择非Opus的模型（比如Sonnet），成本更低。

这两个特点意味着：我们可以让子代理去处理那些“耗token、低难度”的任务（比如技术调研），然后让子代理把调研结果总结成“精简、高价值”的内容，再反馈给主代理——这样主代理的上下文里只会出现核心信息，不会被大量调研数据占用。

实战案例：“图书管”子代理

Jarrod Watts最推荐的子代理用法，是搭建一个“图书管”子代理：

1. 模型选择：用Sonnet模型（比Opus便宜）；
2. 核心功能：扫描开源仓库、查阅技术文档；
3. 输出要求：把调研结果浓缩成简洁、准确的总结；
4. 使用方式：向主代理提出需求，比如“让图书管子代理调研如何用Y库实现X功能，然后基于调研结果开发Z模块”——主代理会触发子代理，子代理完成调研后反馈总结，主代理再基于这个总结写代码。

这个策略的好处很明显：

• 主代理的上下文不会被大量调研数据污染；
• 用更便宜的Sonnet模型做调研，降低整体使用成本；
• 调研结果经过浓缩，是高价值的token，能提升主代理的编码效率。

借助技能：把针对性上下文“拉进来”

如果说子代理是“把任务派出去”，那技能就是“把专业能力拉进来”——技能不会创建独立的上下文，而是把特定的专业提示词引入当前代理的上下文窗口，帮AI更好地处理特定类型的任务。

技能的核心逻辑

技能的本质是“预定义的专业提示词集合”。比如Claude Code内置的“前端设计师”技能，就是一段很长的提示词，里面包含了前端设计的“该做什么、不该做什么”，当启用这个技能时，这段提示词会被加入上下文，让AI按照前端设计的专业规范输出内容。

技能的使用要点

技能看似复杂，实则逻辑简单：当你需要处理某类专业任务时，启用对应的技能，让AI获取该领域的专业指引——这些指引会以提示词的形式进入上下文，帮AI规避常见错误，提升输出质量。需要注意的是，技能会占用当前上下文的空间，所以只在处理对应类型任务时启用，避免无意义的冗余。

核心总结：上下文优化的本质是“价值密集”

看完所有技巧，我们可以回到核心问题：到底该如何优化Claude Code的上下文？答案很简单——让上下文始终保持“价值密集”。

所谓“价值密集”，就是你添加到上下文中的每一条信息，都能直接帮助AI理解并回应你的下一个请求。如果某条信息做不到这一点，就不要让它留在上下文里；如果当前线程的上下文已经充斥着无价值的内容，就果断重置——这是避免AI产出“垃圾内容”的关键。

那些看似炫酷的高级功能（子代理、MCP服务器、技能），本质上都是为了帮我们打造“价值密集”的上下文：

• MCP服务器帮我们获取精准的外部信息；
• 子代理帮我们过滤冗余，只保留核心总结；
• 技能帮我们引入针对性的专业指引。

不用因为别人用了这些功能而焦虑，也不用盲目跟风——就像和同事协作一样，你只需要把清晰、准确、简洁的信息提供给AI，再给它合适的工具让它自己找需要的信息，就能让AI成为高效的编码助手。

FAQ：关于Claude Code上下文工程的常见问题

Q1：Claude Code标注的200k tokens上下文窗口，实际能用的有多少？

A1：根据/context命令的查看结果，22.5%的空间是预留缓冲区，10.2%被系统提示占用，再扣除MCP服务器、子代理、规则等模块的占用后，实际可用的大约是120k tokens。而且需要注意，即便没用到120k tokens，AI的性能也会随着上下文增加而下降，所以不要一味填充内容，要关注信息的质量。

Q2：什么时候该用/rewind，什么时候该用/new？

A2：如果当前对话只是某个节点出了问题，之前的内容还有价值（比如详细的项目规划、调研结果），就用/rewind回到问题出现前的节点；如果整个对话已经陷入恶性循环，上下文里充斥着无效的沟通记录，没有保留的价值，就直接用/new开启新线程，同时优化提示词，明确指出之前的问题。

Q3：子代理和技能的核心区别是什么？

A3：核心区别在于上下文的使用方式：

• 子代理有独立的上下文窗口，是“向外委派任务”，让子代理在自己的上下文里完成高耗token的任务，再反馈精简结果；
• 技能是把预定义的提示词引入当前代理的上下文窗口，是“向内引入能力”，帮当前AI处理特定专业任务。
  简单来说，子代理帮你“省上下文空间”，技能帮你“补专业信息”。

Q4：MCP服务器是不是用得越多越好？

A4：不是。MCP服务器会快速消耗上下文空间，而且很多MCP服务器提供的信息信号量低，反而会降低AI的处理效率。Jarrod Watts的建议是精选少量实用的MCP服务器（比如他自己用的exa.ai、context7、grep.app），只在需要的时候使用，遵循“即时上下文策略”，而不是盲目添加多个MCP服务器。

Q5：为什么做好基础操作（/upgrade、/model、/init）就够了80%？

A5：因为复杂功能（子代理、MCP、技能）的核心作用是“优化上下文的质量和效率”，而基础操作是让Claude Code具备处理高质量上下文的能力：Max计划解锁全部功能，Opus 4.5模型提升理解能力，/init文件让AI掌握项目基础信息。没有这些基础，再花哨的高级功能也无法发挥作用；做好这些基础，即便不用高级功能，也能让AI的输出质量达到较高水平。