别怪额度少：18个Claude Code省Token实战技巧

---

核心观点速览

1. Token 成本是指数增长，不是线性的。 每条消息都会让 Claude 从头重读整段对话历史，消息越多单条成本越高。有开发者实测：100+条消息的会话中，98.5% 的 token 只是在重读旧历史。
2. 隐形开销无处不在。 你的 CLAUDE.md、MCP 服务器、系统提示词、技能文件……每一轮对话都会被重新加载，即使你什么都没说，光这些"基础设施"就可能吃掉 51,000 个 token。
3. 膨胀的上下文不只费钱，还会让输出变差。 "Lost in the Middle"（中间丢失）现象意味着模型对会话中间部分的关注度最低，上下文越长，遗漏越严重。
4. 核心策略就一句话：保持上下文干净。 从及时清理对话、精简 CLAUDE.md 到手动提前压缩，所有技巧都围绕这个原则展开。
5. 撞限额不一定是坏事。 如果你已经在做优化但仍然撞了限额，说明你在充分利用这个工具——这恰恰是你应该追求的状态。

---

一、先搞懂原理：你的 Token 到底怎么被花掉的

在讲任何技巧之前，Nate 花了整整三分钟解释 token 的工作机制，因为不理解原理，优化就是瞎猜。

Token 成本是复利，不是加法

一个 token 大约等于一个英文单词（不完全精确，但可以作为基准）。关键在于：每次你发消息，Claude 都会从头重读整段对话历史。 不是只读你的新消息——它要读消息 1、回复 1、消息 2、回复 2……一直到你最新的输入。

这意味着成本是指数级复合增长：

"Message one might cost 500 tokens, message 30 costs 15,000 because it's rereading everything before it."（第一条消息可能只花 500 个 token，但第 30 条就要花 15,000，因为它在重读之前所有的内容。）

Nate 展示了一张图表：30 条消息之后，累计 token 消耗可能已接近 25 万。有一个开发者专门追踪了 100 多条消息的会话，发现 98.5% 的 token 纯粹用在了重读旧历史上——只有 1.5% 是"有效工作"。

隐形的"基础设施税"

除了对话本身，Claude 在每一轮还会重新加载：

• CLAUDE.md（你的项目配置文件）
• MCP 服务器（每个连接的工具定义）
• 系统提示词
• 自定义技能和记忆文件

Nate 在一个完全空白的会话中跑了 /context，发现还没说一句话就已经用掉了 51,000 个 token。这些都是"看不见但一直在烧"的隐形开销。

上下文膨胀的双重代价

"Bloated context doesn't just cost you more money, but it also produces worse output."（膨胀的上下文不只让你花更多钱，还会让输出质量变差。）

这里涉及一个被称为 ​"Lost in the Middle"（中间丢失）的现象：AI 模型对会话开头和结尾的关注度最高，中间部分的内容会被"半忽略"。上下文越长，中间的"盲区"越大，你花了更多 token，得到的却是更差的回答。

延伸思考：这解释了一个很多人的直觉体验——"跟 Claude 聊久了它好像变笨了"。不是模型真的变笨了，而是它的注意力被稀释了。这个机制反过来也说明了为什么"及时清理"不只是省钱，更是提升输出质量的关键。

---

二、Tier 1 入门技巧：九个人人都能立刻用上的习惯

这一层的技巧不需要技术背景，纯粹是使用习惯的改变。

1. 及时开新对话（/clear）

"Every single message in a long chat is exponentially more expensive than the same message in a fresh chat."（长对话里的每条消息都比新对话里的同一条消息贵得多。）

不相关的任务之间用 /clear 切换。 不要把讨论话题 A 的上下文带进话题 B。这是所有技巧中最简单但效果最立竿见影的一个。

2. 断开不用的 MCP 服务器

每个连接的 MCP 服务器会在每条消息中加载其全部工具定义。一个服务器就可能是 18,000 token/条消息。

操作建议：

• 每次开始新会话时跑 /mcp，断开不需要的
• 更好的替代方案：用 CLI 代替 MCP。比如用 Google Workspace CLI 替代 Google Calendar MCP 服务器——更快、更省

Nate 认为未来趋势是 Agent 使用 CLI 而非 MCP，因为 CLI 不需要加载工具定义到上下文中。

3. 把多个指令合并成一条消息

三条单独的消息成本 = 一条合并消息的三倍。不要分成：

• "帮我总结一下这个"
• "现在提取问题"
• "建议一个修复方案"

而是一条消息写完所有指令。

还有一个 Nate 提到的小技巧：如果 Claude 的回答有小问题，编辑你的原始消息重新生成，而不是发一条纠正消息。因为纠正消息会永久堆积到历史中，而编辑则是直接替换掉错误的那轮对话。

不过 Nate 也坦率承认：一次给一个任务，输出质量可能更好，因为模型更专注。这是一个质量与成本的权衡，需要根据具体场景判断。

4. 先用 Plan Mode 再动手

"The single biggest source of token waste is having Claude go down the wrong path, writing code, and then basically everything it just did, you have to scrap and redo."（最大的 token 浪费来源就是让 Claude 走错方向、写了一堆代码、然后全部推倒重来。）

在 CLAUDE.md 中加上这段话：

​"Do not make any changes until you have 95% confidence in what you need to build. Ask me follow-up questions until you reach that confidence level."（在你有 95% 信心确认要构建什么之前，不要做任何改动。一直问我后续问题，直到达到这个信心水平。）

这个"95% 置信度规则"Nate 说他放到了自己所有项目的 CLAUDE.md 里。

5. 用 /context 和 /cost 让隐形变可见

• /context 会显示你的 token 被什么东西占用——对话历史、MCP 开销、加载的文件等
• /cost 会显示当前会话的实际 token 使用量和估算花费

"Most people have no idea where their tokens are going."（大多数人根本不知道自己的 token 花在哪了。）

不知道问题在哪，怎么优化？ 这两个命令是诊断工具，建议在每次感觉"好像消耗好快"的时候就跑一下。

6. 设置 Status Line（状态栏）

在终端里设置一个始终可见的状态栏，显示：

• 当前使用的模型
• 上下文使用百分比的可视进度条
• 具体 token 数（如 52K / 1,000K）

操作：在终端的 Claude Code 中输入 /status line 并说明你想要的显示格式。

7. 打开 Claude 使用量仪表板

最朴素但有效的方法：把使用量页面常驻在浏览器标签页，每 20-40 分钟看一眼。 甚至可以设一个自动化，每 30 分钟给你发 Slack/短信提醒当前用量。

8. 聪明地粘贴

"Before you drop a document or a file or something large, just ask yourself, does Claude need to read this whole thing?"（在你丢一个大文件进去之前，问自己：Claude 真的需要读全部吗？）

• Bug 只在一个函数里？只粘那个函数
• 只需要一段上下文？只粘那一段

Claude 需要精确地读，你也需要精确地喂。

9. 盯着 Claude 工作

不要发完指令就切标签页或走开。尤其是较长的任务，一定要看着它做。

原因：Claude 有时会陷入死循环——反复读同一个文件、走错方向又不停往下走。如果你在看，发现不对可以立刻叫停。

"In a bad loop, 80% of the tokens are being used producing zero value."（在一个糟糕的循环里，80% 的 token 产出的价值是零。）

---

三、Tier 2 进阶技巧：五个需要一点配置的优化

这一层需要你对 Claude Code 的工作方式有更深的理解。

1. 保持 CLAUDE.md 精简

CLAUDE.md 在每一条消息（不是每个会话，是每条消息）都会被重新读取。如果它有 1000 行，每条消息都要重读这 1000 行。

核心原则：控制在 200 行以内，只放最重要的信息——技术栈、编码规范、构建命令、95% 置信度规则。

关键心智转变：把 CLAUDE.md 当成索引，而不是文档本身。

"It basically just tells Claude Code where is everything that it needs and what to do. It can point to files that are huge, but that way it just says, 'I don't need this right now, but if I do, I know exactly where to look.'"（它基本上只是告诉 Claude Code 所有东西在哪、该怎么做。它可以指向很大的文件，但这样它就能说："我现在不需要这个，但如果需要，我精确地知道去哪找。"）

有人创建了一个精简的索引文件，指向 Claude Code 文档的具体 URL，这样 Claude 不需要搜索整个文档库，直接按索引查找就行。这个"索引思维"也适用于技能文件、参考手册等所有 Claude 会自动加载的文件。

2. 精确定位文件引用

不要说："看看我的整个代码仓库，找出 bug。"

要说："检查 auth.js 文件里的 verifyUser 函数。" 或者用 @文件名 直接指向特定文件。

核心理念跟 CLAUDE.md 一样：路由，不是漫游。 你越精确，Claude 搜索和读取的文件越少，token 消耗越低。

3. 在 60% 容量时手动 Compact

Claude Code 的自动压缩（auto-compact）在 95% 容量时才触发，但到那时上下文质量已经严重下降。

Nate 的建议：

• 用 /context 或状态栏监控容量
• 在 60% 时就手动运行 /compact
• 压缩时要告诉它保留什么（不要默认让它自己决定）
• 3-4 次连续 compact 之后，质量会开始下降，这时候应该：获取会话摘要 → /clear → 把摘要粘贴回去继续

这是一个非常实用的节奏感知识：60% 手动压缩 → 压缩3-4次后清理重来 → 循环往复。

4. 短暂离开也有成本

Claude Code 使用 prompt caching（提示缓存）来避免重复处理不变的上下文，但这个缓存只有五分钟有效期。

"If you step away and you come back and it's been longer than 5 minutes, your next message reprocesses everything from scratch at full cost."（如果你离开超过5分钟回来，下一条消息会从零开始全价重新处理所有内容。）

这解释了为什么有些人觉得用量"突然飙升"——可能只是中间去泡了杯咖啡回来。

建议：如果要离开，先 /compact 或 /clear。回来时会话更精简，即使缓存失效，重新处理的量也小得多。

5. 命令输出膨胀

当 Claude 运行 shell 命令（比如 git log、ls 等），完整的输出会进入你的上下文窗口。如果一条命令返回了 200 条 commit 记录或者大量数据，这些全部变成了你的 token 消耗。

解决方案：

• 有意识地控制 Claude 可以运行什么命令
• 如果某个项目不需要某些命令，在项目设置中禁止它们
• 这些输出在界面上可能只显示一行，但背后加载的 token 量是隐形的

---

四、关于撞限额的心态重构

Nate 在讲完 Tier 2 之后插入了一段"编辑时加的话"，值得单独拿出来说。

"I don't think that you should associate hitting your limit with a negative connotation."（我不觉得你应该把撞限额跟负面联系在一起。）

他的逻辑是：如果你已经在做各种优化，仍然撞了限额，说明你在高强度使用这个工具。那些从来不撞限额的人，可能根本没有充分利用。

"People that are using it so much are going to be so much more productive and so much farther ahead than people who are never hitting their limits."（使用得这么多的人，会比那些从来不撞限额的人高效得多、领先得多。）

延伸思考：这个心态跟健身很像——如果你从来不觉得累，可能说明你训练强度不够。当然前提是你的"累"来自有效训练而不是错误姿势，对应到 Claude Code 就是：先优化习惯，然后坦然接受限额。

---

五、Tier 3 高阶技巧：四个需要策略思维的优化

这一层涉及模型选择、架构规划和时间管理。

1. 选对模型

不是所有任务都需要最强的模型：

模型	适用场景
Sonnet	日常编码工作的默认选择
Haiku	子 Agent、格式化、简单任务
Opus	深度架构规划，仅在 Sonnet 不够时使用（控制在 20% 以内）

Nate 还提到了一个巧妙的组合：用 Opus + Sonnet 协作构建项目，然后引入 Codex 做代码审查。Codex 有官方插件，可以在不消耗 Claude token 的情况下完成审查工作。

2. 理解子 Agent 的成本

"Agent workflows use roughly 7 to 10 times more tokens than a standard single agent session."（Agent 工作流使用的 token 大约是标准单 Agent 会话的 7 到 10 倍。）

原因：每个子 Agent 都会从零开始加载自己的完整上下文——所有文件、系统工具、配置，全部重来一遍。

但子 Agent 并非完全不该用。Nate 的建议：

• 一次性任务委托给子 Agent，尤其是可以用 Haiku 完成的
• 比如处理大量信息、做研究然后只返回摘要
• 如果 80% 的 token 能用便宜模型（Haiku）而不是贵模型（Opus），整体成本就降下来了

至于 Agent 团队（多个 Agent 协作），Nate 说"很酷，有时确实能提升输出质量"，但非常贵，要非常克制地使用。

3. 利用高峰/低峰时段

Anthropic 已经引入了时段机制：

• 高峰时段：美东时间 8:00-14:00 工作日——同样的操作消耗更快
• 低峰时段：下午、晚上、周末——消耗正常或更慢

策略性安排：

• 大型重构、多 Agent 会话、复杂项目 → 安排在低峰时段
• 接近重置但还有余量 → 放开用，全力榨干剩余额度
• 接近限额但还有很多时间 → 停下来，休息，带着满额度回来

"Come back with a full budget instead of burning the last 5% on something small and getting stuck mid-task."（带着满额度回来，而不是把最后 5% 烧在小事上然后卡在任务中间。）

4. 让 CLAUDE.md 成为"系统宪法"

这是对 Tier 2 第一条的升级版。CLAUDE.md 不只是配置文件，而应该是你项目的制度文件：

• 存决策，不存对话——每一条架构决定存进去，就是以后不用再解释的一段话
• 可以加入 token 优化规则，比如："对任何研究或探索任务都使用子 Agent"、"如果任务涉及三个以上文件，生成子 Agent（用 Haiku）并只返回摘要"

Nate 还展示了一个自学习机制：在 CLAUDE.md 底部加入这段提示词——

"Applied Learning: When something fails repeatedly, when Nate has to re-explain, or when a workaround is found for a platform, tool, or limitation, add a one-line bullet here. Keep each bullet under 15 words. No explanations. Only add things that will save time in future sessions."（应用学习：当某件事反复失败、当 Nate 不得不重新解释、或发现了某个平台/工具/限制的变通方案时，在这里添加一条一行的要点。每条控制在 15 个词以内。不需要解释。只添加能为未来会话节省时间的东西。）

注意事项：这种自学习/自演化的文件需要经常检查，防止它不知不觉膨胀。

---

六、立刻可以做的事（行动清单）

Nate 在结尾给出了一份可以马上执行的清单：

1. 跑 /context，看看你的 token 都花在哪
2. 跑 /cost，设好 status line，实时监控模型、上下文百分比和 token 数
3. 打开 Claude 使用量仪表板，掌握剩余额度和重置时间
4. 断开不用的 MCP 服务器
5. 复杂任务先进 Plan Mode
6. 切换无关任务时用 /clear
7. 60% 容量时手动 /compact
8. 多步指令合并成一条消息
9. 重型会话安排在低峰时段

---

总结

Nate 在视频最后留了两个核心信息：

第一，质量与成本之间永远存在权衡，有时你确实需要选择高质量（更贵的模型、更多的上下文），这是正常的。

第二，也是整个视频最有穿透力的一句话：

​"Most people don't need a bigger plan, they need to stop resending their entire conversation history 30 times. It's not a limits problem. It's a context hygiene problem."（大多数人不需要更高的套餐，他们需要停止把整段对话历史重发 30 遍。这不是额度问题，这是上下文卫生问题。）

这句话精准地点出了本质：工具给你的额度是够用的，但前提是你要懂得怎么用。不是给更多的水就能解决漏水的问题——你得先把管道修好。

---

附录

金句收录

1. "Message one might cost 500 tokens, message 30 costs 15,000 because it's rereading everything before it." 第一条消息可能只花 500 个 token，但第 30 条就要花 15,000，因为它在重读之前所有的内容。——Nate Herk

2. "98.5% of all the tokens were just spent rereading the old chat history." 98.5% 的 token 纯粹花在了重读旧对话历史上。——Nate Herk

3. "Bloated context doesn't just cost you more money, but it also produces worse output." 膨胀的上下文不只让你花更多钱，还会让输出质量变差。——Nate Herk

4. "Do not make any changes until you have 95% confidence in what you need to build." 在你有 95% 信心确认要构建什么之前，不要做任何改动。——Nate Herk

5. "Most people have no idea where their tokens are going." 大多数人根本不知道自己的 token 花在哪了。——Nate Herk

6. "Claude needs to be precise about what it reads, but you also need to be precise about what you feed it." Claude 需要精确地读，你也需要精确地喂。——Nate Herk

7. "In a bad loop, 80% of the tokens are being used producing zero value." 在一个糟糕的循环里，80% 的 token 产出的价值是零。——Nate Herk

8. "Treat this like an index route to where more data lives." 把它当成一个索引路由，指向更详细数据的位置。——Nate Herk（谈 CLAUDE.md）

9. "After three to four compacts in a row, the quality does start to degrade." 连续压缩三四次之后，质量确实会开始下降。——Nate Herk

10. "The cache has a five-minute timeout." 缓存有五分钟的超时时间。——Nate Herk

11. "People that are using it so much are going to be so much more productive and so much farther ahead." 使用得这么多的人，会比别人高效得多、领先得多。——Nate Herk

12. "Most people don't need a bigger plan, they need to stop resending their entire conversation history 30 times. It's not a limits problem. It's a context hygiene problem." 大多数人不需要更高的套餐，他们需要停止把整段对话历史重发 30 遍。这不是额度问题，这是上下文卫生问题。——Nate Herk

时间线索引

时间	内容
[00:00]	用户大量抱怨 Claude Code 额度消耗过快的问题背景
[00:48]	Token 的工作原理——指数级复合增长，98.5% 花在重读历史
[03:04]	Tier 1 入门技巧（9个）：/clear、断开MCP、合并消息、Plan Mode、/context和/cost、状态栏、仪表板、精准粘贴、看着它做
[08:48]	Tier 2 进阶技巧（5个）：精简CLAUDE.md、精确文件引用、60%手动compact、5分钟缓存超时、命令输出膨胀
[12:15]	心态重构：撞限额不一定是坏事
[13:17]	Tier 3 高阶技巧（4个）：选对模型、子Agent成本、高峰低峰时段、CLAUDE.md自学习机制
[17:32]	立刻可以执行的行动清单
[18:12]	总结：不是额度问题，是上下文卫生问题