外观
Claude Code 为什么越用越贵？这 12 个习惯能帮你少烧 Token
用过 Claude Code 的人都知道，Token 就是钱。每一次对话、每一次文件读取、每一次上下文传递，都在消耗你的额度。
很多人刚上手时觉得"怎么这么快就用完了"，其实不是工具贵，而是用法有问题。
今天分享 12 条经过实战验证的省 Token 技巧，按影响力从高到低排列，帮你用更少的消耗，完成更多的事。
第一梯队：上下文管理（影响最大）
1. 新任务开新 Session
这是最重要的一条。
当你完成一个任务，准备开始下一个完全不同的任务时，不要在同一个 Session 里继续。因为之前所有的对话历史都会作为上下文被带入，即使跟新任务毫无关系。
一个累积了几十轮对话的 Session，每次新请求都在为那些无关内容买单。
具体操作： 在 Claude Code 中输入 /clear 命令即可清除当前对话，开启全新 Session：
Plain
/clear也可以直接在终端中退出后重新运行 claude 命令来启动新会话。
干净的上下文 = 更少的 Token 消耗 + 更精准的回答。
2. 主动压缩上下文
对话进行到一定程度后，上下文会变得越来越长。很多早期的对话内容已经没用了，但它们仍然占着 Token。
正确做法： 使用 /compact 命令主动压缩上下文。Claude 会总结之前的对话要点，丢弃冗余内容，大幅减少后续每次请求的 Token 消耗。
具体操作： 直接在输入框中输入：
Plain
/compact你还可以在后面加上提示词，告诉 Claude 压缩时重点保留什么：
Plain
/compact 保留关于数据库迁移的所有讨论细节此外，你也可以在 /config 中配置自动压缩，当上下文超过一定比例时让 Claude 自动执行。
两个关键时机一定要压缩：
- 对话变长时 —— 感觉聊了很多轮了，主动压缩一次
- 长时间离开前 —— 午饭、开会、下班前，先 /compact 一下。回来时起点就是精简过的上下文，而不是几个小时前的臃肿历史
3. 多个问题合并成一条消息
很多人习惯想到什么问什么，一条一条地发。但每条消息都会带上完整的上下文历史，意味着你发得越多，重复传递的内容就越多。
正确做法： 把相关的问题整理好，一次性发出去。在 Claude Code 输入框中按 Shift + Enter 可以换行，方便你组织多行内容。比如：
帮我做三件事：修复 login 页面的样式问题 给 API 接口加上错误处理 更新 README 中的部署说明
一条消息解决三个问题，比分三次问节省大量 Token。
第二梯队：工作方式（避免返工浪费）
4. 写清楚 Prompt，一次说明白
这是大多数人最大的 Token 浪费来源，却最容易被忽略。
模糊的指令会导致 Claude 猜你的意思——猜错了你纠正，纠正又带来新的上下文……几个来回下来，Token 消耗翻倍，事情还没做对。
反面教材：
帮我改一下那个页面
Claude 不知道哪个页面、改什么、改成什么样。它只能猜，猜错概率极大。
正确做法： 一次性说清楚背景、目标和约束：
帮我修改 @src/pages/UserProfile.tsx，把用户头像从方形改为圆形，使用 TailwindCSS 的 rounded-full 类，不要改动其他样式
指令越精准，Claude 一次做对的概率越高，后续纠正的 Token 消耗就越少。
5. 复杂任务先用 Plan
面对一个复杂需求，很多人上来就让 Claude 开干。结果方向不对，改来改去，Token 刷刷地烧。
正确做法： 先让 Claude 制定一个计划（Plan），确认方向和步骤没问题后再动手实现。
具体操作： 按 Shift + Tab 可以在输入框中切换到 Plan 模式（你会看到输入框提示变为 “Plan mode”）。在 Plan 模式下，Claude 只会思考和规划，不会直接修改代码。
你也可以直接用自然语言要求 Claude 先做计划：
先帮我规划一下这个功能的实现方案，列出步骤，不要写代码。
确认计划没问题后，再按 Shift + Tab 切回正常模式让 Claude 执行。
Plan 阶段消耗的 Token 很少，但能帮你避免后面大量的返工浪费。
想清楚再动手，永远比边做边改更省。
6. 出错不纠正，编辑原消息
Claude 回答不满意怎么办？很多人会接着发一条"不对，我的意思是……"。
这样做的问题是：之前那条错误的回复也会留在上下文里，白白浪费 Token。
正确做法： 直接编辑你原来的消息，重新表述清楚。这样 Claude 会基于修改后的消息重新生成，不会保留之前的错误回复。
具体操作： 在对话中，按 ↑ 方向键可以快速调出上一条消息进行编辑。修改后回车发送，Claude 会丢弃之前的错误回复，基于新消息重新生成。
第三梯队：操作技巧（积少成多）
7. 引用文件时 @文件名指定路径
不要跟 Claude 说"看一下那个组件文件"或者"我有个 utils 文件"。这种模糊描述会逼 Claude 去猜、去搜索，搜索本身就消耗大量 Token。
正确做法： 用 @ 直接指定文件路径。Claude 直接读取目标文件，省去搜索的开销。
具体操作： 在输入框中使用 @ 加文件路径即可引用：
Plain
帮我优化 @src/components/Header.tsx 中的渲染性能你也可以输入 @ 后按 Tab 键触发文件路径自动补全，快速定位目标文件。
8. 临时提问用 /btw
写代码写到一半，突然有个不相关的小问题想问？
如果直接问，这个问题和回答都会进入上下文，污染后续的代码任务。
正确做法： 使用 /btw 命令。它会在不影响当前对话上下文的情况下处理你的临时提问，问完就丢，干干净净。
具体操作： 在输入框中直接输入：
Plain
/btw JavaScript 中 map 和 flatMap 有什么区别？回答完毕后，这段问答不会被计入主对话的上下文。
9. 控制输出长度，别让 Claude 写废话
Claude 默认会给你详细的解释、注释、甚至使用示例。但输出 Token 也是要花钱的。
如果你只需要代码，那些解释就是在烧钱。
正确做法： 在 Prompt 中明确告诉 Claude 你要什么、不要什么：
Plain
只给代码，不要解释Plain
用 diff 格式输出改动，不要输出完整文件Plain
简要回答，不超过三句话养成这个习惯后，每次对话都能省下不少输出 Token。
10. 用 --resume 恢复会话，别从头再来
中途关了终端，或者第二天想继续昨天的任务？很多人会开一个新 Session，然后把背景重新说一遍。
这等于从零开始重建上下文，极其浪费。
正确做法： 使用 --resume 参数恢复上一次会话：
Plain
claude --resume如果你想恢复特定的历史会话，可以用：
Plain
claude --resume <session-id>Claude 会加载之前的对话记录继续工作，不需要重新解释背景。
第四梯队：配置优化（一劳永逸）
11. 精简 CLAUDE.md 配置
CLAUDE.md 是 Claude Code 的系统提示文件，每次对话都会被加载到上下文中。
如果你往里面塞了大量的规则、偏好、示例代码，每一次对话都在为这些内容买单。
文件位置： CLAUDE.md 存在于两个层级：
- 全局配置： ~/.claude/CLAUDE.md —— 对所有项目生效
- 项目配置： 项目根目录下的 CLAUDE.md 或 .claude/CLAUDE.md —— 仅对当前项目生效
正确做法：
- 只保留真正必要的配置
- 删除冗余的示例和说明
- 定期审视和精简
- 项目专属的规则放项目级配置，不要全塞到全局配置里
你可以用以下命令快速查看当前生效的配置文件大小：
Plain
wc -c ~/.claude/CLAUDE.md
wc -c ./CLAUDE.md你的 CLAUDE.md 每精简一行，就是每次对话都省一点。日积月累，差距巨大。
12. 配置状态栏，让上下文消耗可见
你不知道自己花了多少，就不可能真正省下来。
Claude Code 支持通过 /statusline 自定义状态栏。把上下文占用、Token 消耗或当前成本显示在状态栏里，你就能随时看到这次会话是不是已经变得太重。
具体操作： 在 Claude Code 中输入：
Plain
/statusline然后按提示配置你想显示的信息，比如当前模型、上下文占用、Token 使用情况或成本信息。配置好之后，每次对话时状态栏都会持续显示这些信息，让你更容易判断什么时候该 /compact，什么时候该 /clear 开新会话。
看得见，才管得住。
写在最后
这 12 条技巧的核心思想其实就一句话：减少不必要的上下文传递。
Token 的消耗本质上就是信息的传递量。你传得越精准、越干净，消耗就越少，效果反而越好。
按影响力总结一下：
- 最重要： 新 Session、压缩上下文、合并消息——管住上下文大小
- 次重要： 写清楚 Prompt、先 Plan、编辑原消息——减少返工浪费
- 锦上添花： @文件、/btw、控制输出、–resume——细节处积少成多
- 一劳永逸： 精简配置、开启状态栏——设置一次，长期受益
省 Token 不是抠门，是高效。
把这些习惯养成，你会发现同样的额度能做多得多的事。
觉得有用？分享给你身边也在用 Claude Code 的朋友，帮他们也省一笔。
你有自己的省 Token 妙招？欢迎在评论区分享，一起把效率拉满。
文章同步公众号：雨哥聊AI
来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/LMnywcVMIikF6qkwFENccRRVnLI ｜ 归档：2026-06-04