实用教程：Vibe Coding 怎么节省 Token
目录
- Token 都去哪了
- 把重复的话写进 CLAUDE.md
- Prompt 写短一点
- 别什么都往一个对话里塞
- 选对模型
- 少触发不必要的工具调用
- 一张表总结
- 小结
你打开 Claude Code，跟 AI 说"帮我重构一下这个模块"，然后看着它一顿操作猛如虎——读文件、改代码、跑测试、再改、再跑。二十分钟过去了，功能倒是实现了，你一看账单：这一轮对话烧掉了几百万 token。
Vibe coding 的核心就是"想到什么说什么，让 AI 自己搞定"。听起来很爽，但代价是 token 消耗像流水一样。你说一句"帮我改一下"，AI 可能要读三个文件、改两处代码、跑一次测试，每一步都在往上下文里堆东西。几轮下来，每次 API 调用都要把整个对话历史发给模型，token 数量指数级增长。
问题很明确：vibe coding 的自由度越高，token 消耗越不可控。 有没有办法既能保持"随口说"的爽感，又不把钱烧光？
有的，有的，兄弟，有的。
Token 都去哪了
在讲具体策略之前，先搞清楚 token 花在了哪里。
用户输入 ──→ 占比很小（通常几百 token）
系统提示词 ──→ 每次都发，但相对固定
工具定义 ──→ 每次都发，工具越多越大
对话历史 ──→ 重点，随轮次线性增长
工具输出 ──→ 重点，一个 ls -la 可能几百行
模型回复 ──→ 正常消耗
对话历史和工具输出，是Token花费最多的两个地方。
对话历史好理解——你说一句、AI 回一句、工具执行结果再塞进去，messages 数组越来越长。每一轮 API 调用，都要把整个数组重新发给模型，前面的内容反复发送，后面的内容不断累加。
工具输出就比较容易被忽略。AI 读一个文件，几百行代码全部塞进上下文；跑一个测试，控制台输出可能几千行。这些"原始数据"对模型决策可能只有一小部分是有用的，但它们全都要算 token。
因此，省 token 的思路就变得清晰了：要么少发，要么压缩，要么隔离。
把重复的话写进 CLAUDE.md
最简单的省 token 方式：把反复要说的话固化下来。
每次新开对话，你是否都要把某些偏好性指令重复一遍，“后端使用Java语言和SpringBoot框架”，“前端使用Vue3”、“RESTful接口风格”等等,那么你很需要CLAUDE.md。
CLAUDE.md 的作用就是把这些"默认配置"写死。模型每次对话开始时会自动读取，你不用再复述一遍，这一点也为我们的编码工作带来了很多便利，减少了重复性的操作。
没有 CLAUDE.md 的对话：
第1轮：用户说"用 SpringBoot，测试用 Junit" → 消耗 50 token
第2轮：用户再说一遍（新对话） → 消耗 50 token
第3轮：又说一遍 → 消耗 50 token
… 10 轮对话 = 500 token 只是在重复配置
有 CLAUDE.md 的对话：
CLAUDE.md 写一次 → 消耗 50 token（每次自动加载）
10 轮对话都不用再说 → 净省 450 token
虽然这点消耗在现在coding plan动辄几亿的情况下显得有点微不足道，但当你的偏好有十几条、对话开到几十轮的时候，CLAUDE.md 省下来的 token 还是比较可观的。更重要的是，它减少了"模型忘了你的偏好 → 输出不符合要求 → 你纠正 → 模型重来"这种返工循环，而每一次返工都在烧 token。笔者刚开始并没有意识到CLAUDE.md的神奇效果，后来开始使用后只能说：真香！！！
Prompt 写短一点
这条听起来好像有点反直觉，我们写提示词的时候不是讲究要写的细致入微，为何到你这变成了要写短一点，别着急反驳我，其实这两点并不矛盾，很多人并没有意识到自己的 prompt 有多浪费 token。
“帮我看看这个文件有没有问题，如果有就修一下，顺便看看能不能优化一下性能，如果能的话帮我优化一下，另外如果发现有安全漏洞也一并修了，对了测试也要跑一下确认没问题。”
这段 prompt 有多少有效信息？其实就三件事：检查、修复、测试。但表达方式太啰嗦，白白多花了 token。
更关键的是，prompt 越长、越模糊，模型的"探索行为"越多。 它不确定你到底要什么，就会多读几个文件、多试几种方案，每一步都在烧 token。
对比一下：
低效 prompt（60 token）：
"帮我看看这个文件有没有问题，如果有就修一下，顺便看看能不能优化一下性能，
如果能的话帮我优化一下，另外如果发现有安全漏洞也一并修了，对了测试也要跑一下确认没问题。"
→ 模型不确定优先级，可能什么都做一遍
高效 prompt（25 token）：
"审查 src/auth.ts，修复 bug 和安全问题，跑测试确认。"
→ 模型目标明确，动作精准
省了一半以上的 prompt token，而且模型的执行路径更短、更精准，间接省下了更多的工具调用 token。
不要什么都往一个对话里塞
对话历史是最大的 token 黑洞。用户能做的最直接的事：管好自己的对话生命周期。
很多人习惯在一个对话里干所有事，上午写登录模块，下午改订单逻辑，晚上调样式。对话越堆越长，每次 API 调用都要把前面所有内容重新发一遍。到后面 AI 开始"忘记"你前面说过的话，或者开始重复已经做过的事——这时候它还在烧 token，只是在做无用功。
下面有几个简单实用的判断标准（实际使用中还是要贴合自己使用习惯和项目结构）：
该开新对话了：
– AI 开始重复已经做过的事
– 你切换到了一个完全不同的任务
– 对话已经跑了超过 20 轮
能手动压缩的：
– 用 /clear 清空对话历史重新开始
– 在合适的时机开启新对话，而不是在旧对话里无限堆叠
一个类比：你的浏览器开了 50 个标签页，每个都在吃内存。对话历史也一样，越长越吃 token，而且大部分内容对当前任务已经没用了。
选对模型
不是所有任务都需要最强的模型。让 Opus 去跑一个 ls 命令，就像请一个院士来帮你查字典，完全是大材小用。
实际开发中，很多任务是"低认知负荷"的：读文件、执行命令、格式化代码、写简单的 CRUD。这些任务用 Haiku 就够了，成本可能是 Opus 的几十分之一。
任务复杂度 vs 模型选择：
简单任务（读文件、执行命令、格式化） → Haiku（便宜、快）
中等任务（写业务代码、调试、重构） → Sonnet（性价比高）
复杂任务（架构设计、复杂推理、安全审计） → Opus（最强、最贵）
Claude Code 支持在不同场景下切换模型。一个常见的省钱策略是：日常开发用 Sonnet，遇到真正需要深度思考的任务时手动切到 Opus。 很多时候你以为需要 Opus 的任务，Sonnet 其实也能搞定，只不过是你没有尝试过。
少触发不必要的工具调用
这一点很多人都没有想到，你的一句话可能触发 AI 的一系列工具调用，而每个工具调用的结果都会进入上下文算 token。
你说"帮我看看这个项目用了什么框架"，AI 可能会：先 glob 搜索所有文件 → 读 pom.xml → 读 application.yml → 读几个核心类（如 @SpringBootApplication、@RestController）→ 最后告诉你"这是一个 Spring Boot + MyBatis Plus 项目"。这个过程中产生了大量的工具输出，而你真正需要的只是最后那句话。
怎么减少不必要的工具调用？prompt 越具体，AI 的探索路径越短。
低效："帮我看看这个项目" → AI 可能翻遍整个项目
高效："看下 pom.xml 用了什么框架" → AI 只读一个文件
你不是在帮 AI 写代码，你是在引导它少走弯路。走的弯路越少，烧的 token 越少。
一张表总结
| CLAUDE.md | 减少重复 prompt | 中 |
| 写短 prompt | 减少 prompt + 探索行为 | 中 |
| 管好对话生命周期 | 压缩对话历史 | 高 |
| 选对模型 | 降低单价 | 高 |
| 精确引导工具调用 | 减少不必要的工具调用 | 中 |
小结
Vibe coding 省 token 的本质就一件事：让模型只看它需要看的东西。
本文讲到了五条策略，其实就两个维度。一个是"少发"：把固定偏好写进 CLAUDE.md 避免反复交代，把 prompt 写精炼减少冗余输入，用具体的指令引导 AI 缩短探索路径。另一个是"少留"：对话跑到一定长度就开新的，别让历史消息无限膨胀；根据任务复杂度选模型，别拿 Opus 干 Haiku 的活。两条线合在一起，就是"发出去的每一条信息都有用，留在上下文里的每一段内容都必要"。
如果这五条只能先落实一条，建议从 CLAUDE.md 开始。花十分钟把项目的技术栈、代码规范、常用命令写进去，后面每一次对话都在帮你省钱。这一步成本最低、见效最快，是所有策略里性价比最高的起点。等你用熟了 CLAUDE.md，其他几条自然会慢慢摸索出来，毕竟省 token 这件事，本身就是 vibe coding 的一部分，用着用着就有感觉了。
