Claude Code省Token指南：6个官方推荐的效率优化技巧

Anthropic近期发布了一篇关于如何最大化Claude Code使用效率的长文，其中涉及大量关于Token消耗、上下文管理和资源优化的实用技巧。本文提炼了其中最核心的六个要点，并将它们归为三大类别：上下文管理、资源效率和噪音减少。

对于长期使用Claude Code Max或类似订阅计划的开发者来说，理解这些机制不仅能提升性能，更能在成本控制上带来实质性的改善。

上下文管理：控制Token膨胀的根本

上下文管理是六个技巧中最容易被忽视、却最关键的一类。很多用户抱怨自己在Claude Code Max计划上总是耗尽Token，而问题的根源往往就出在上下文的失控膨胀上。

技巧一：任务切换时使用 /clear 命令

第一个技巧也是最被低估的：在切换任务时，务必在终端中使用 /clear 命令来清空上下文。它的价值在于能彻底清除你不再需要的历史信息。当你从一个任务转向另一个完全不相关的任务时，之前积累的所有上下文都成了负担——它们会持续消耗Token，却对新任务毫无帮助。

原作者提到，这也是他偏爱**规范驱动（spec-driven）**开发工具的原因：这类工具会把每个阶段的成果保存到包含所需上下文的"工件"中，因此可以放心地随时清空对话。正是因为大量使用 /clear，他几乎从未遇到过Token耗尽的问题。

技巧二：谨慎且规律地使用 /compact 命令

很多人对 /compact（压缩）命令的理解存在误区，反而在长期使用中花费了更多Token。关键点在于理解**提示缓存（prompt caching）**的工作原理：语言模型会缓存你发送过的所有消息，这样就无需反复重新处理相同的内容。

然而，如果你的对话已经进行了超过一个小时（即距离上次发消息超过一小时），此时运行 /compact，缓存往往已经失效，你实际上是在强迫模型重新读取整个上下文。因此建议是：如果你要用 /compact，就应该更频繁、更规律地使用——比如在第一个小时内就执行，这样才能真正帮助你长期控制成本。虽然它不会带来惊人的性能提升，但在Token管理上会轻松很多。

技巧三：用 /context 命令定期检查上下文加载

/context 命令能让你可视化每条消息发送前实际加载的所有内容。原作者举例，在Opus的上下文窗口里，即便还没输入任何内容，就已经默认加载了约47000个Token——这个数字在早期小上下文窗口时代几乎相当于一整段代码。

这些默认加载的内容包括用户记忆、项目记忆，以及你可能早已遗忘的MCP服务器、自定义代理和技能。像Graphify这类工具通常自带MCP服务器，且常常是全局安装，随时间不断累积膨胀，最终可能导致对话在开始前就加载了十万个Token。

建议每周或每两三周定期运行 /context 检查一次，并配合 /memory 命令查看保存的记忆内容，及时修剪无关信息。原作者提到自己曾清理到两万Token，几周后又回升到四万，可见"膨胀"是每次对话都会自然累积的常态。

资源效率：减少无谓的Token消耗

第二类技巧关注如何在完成同样任务的前提下，让每一次交互都更高效。

技巧四：避免对话中途更改模型或努力程度

Claude Code允许你设置模型和努力程度（effort level）。模型选择器较为直观，努力程度则常被初学者忽视。但一个关键细节是：如果在对话中途更改模型或努力程度，会完全使提示缓存失效。

假设你的对话已经积累了10万个Token，此时从Opus换成Sonnet，或调整了努力程度，下一条消息就必须重新读取所有内容——之前的缓存全部作废，长期来看会消耗更多Token。

更优的做法是：如果你需要不同模型处理不同任务，最简单的办法是启动一个子代理（sub-agent），让它去调用你需要的模型处理特定事务，从而避免破坏主对话的缓存。

技巧五：用 @ 符号直接引用文件

第二个资源效率技巧是使用 @ 符号来提及文件。虽然很多人知道可以这么做，但其真正价值在于：当你用 @ 引用一个文件（如 @smoketest.md）时，这个实际文件会被直接附加到发送的请求中。

这比让模型"自己去找那个文件"要高效得多。后者是许多人默认的"懒模式"——模型需要搜索所有目录、读取搜索结果，每一步都消耗Token，最终越来越低效。而 @ 引用意味着更少的工具调用、更少的读取和搜索操作，能节省大量资源。

噪音减少：过滤无关的上下文污染

第三类技巧针对那些会产生大量无用输出、污染上下文的操作。

技巧六：隔离并过滤嘈杂命令

第一种做法是使用标志（flags）或其他系统来过滤嘈杂的命令。举例来说，如果你的Git项目里有很多未跟踪的更改，让模型随意运行 git status，它就必须读取全部输出——这不仅污染了上下文窗口，还因为需要读取和解析所有这些Token而额外消耗资源。

第二种、也是原作者常用的做法：任何你明知会产生大量噪音的操作，都放进子代理里运行。比如启动一个Sonnet或Haiku子代理去执行这些命令，隔离出真正需要的输出，再传回主模型。这样主编排窗口就不会被无关信息淹没，只保留必要的结论（如"这些是未跟踪的更改"）。

这看似小题大做，但在很多明知不需要全部上下文、只需特定部分的场景下，这种隔离策略极具价值。

为什么这些技巧越来越重要

作者最后指出，这一切之所以重要，是因为在"实际完成任务所需的成本"上正在形成一场真正的博弈。目前我们习惯了高度补贴的产品——比如Claude Code Max或Codex等固定费用计划，成本由模型提供商承担，因此大家很少关心完成一件事究竟消耗了多少Token。

但"让它随便跑、不关心它怎么做"是一种非常糟糕的习惯，不仅浪费金钱，而且随着按量计费模型变得越来越主流，这种低效将直接反映在账单上。理解提示缓存如何工作、Token如何在GPU和服务器上被处理，是每个想真正擅长用AI构建应用的人——尤其是使用Agent SDK开发的人——最终需要掌握的基础概念。这些控制选项之所以被提供出来，正是因为它们真正影响着效率与成本。