Hello，我是Niko。16年程序员老兵，专注分享 AI编程实战经验、宝藏工具资源、前沿技术动态。不玩套路，多讲干货。
前几天刷 X 的时候看到一篇推文，标题很直接：
Never Hit Claude Usage Limits Ever Again
点进去一看，505 万浏览，4500 多转发。作者 Miles Deutscher 是个 AI 领域的博主，洋洋洒洒写了 5 个省 Claude Token 的策略。
我把这 5 条逐个过了一遍。有些确实管用，有些放到 AI 编程的场景下就不太对了，还有些关键的东西他压根没提。
逐条聊聊，哪些值得学，哪些得打个问号。
太长不看版
- "先规划再动手"的建议没毛病，但"先用便宜模型规划"要看任务类型，AI 编程的规划阶段往往需要强推理
- 对话长度控制是基本功，不知道什么时候该切对话，说明你还有很多东西要学
- 推文里的"超级提示词"技巧很实用，本质上就是 Claude Code 里 /clear 的使用方式
- Claude Code 的记忆机制已经内置了 CLAUDE.md 和自动 Memory，不需要手动维护额外文件
- 模型选择的关键不是贵不贵，是你的任务需不需要深度推理
- /effort 能调节推理深度，官方说法是不增加 Token 消耗，只是推理时间变长
- 推文完全没提的一个关键技巧：用一句话让 Claude Code 状态栏帮你实时监控消耗
- 省 Token 的本质不是省钱，是让 AI 把算力花在刀刃上
第一条：先规划再动手 -- 对了一半
Miles 的第一条建议是：
在发送任何 Claude 提示之前，先想清楚你要什么。
大方向没问题。他举了个例子：两个人都要用 AI 写一个财务追踪应用，A 花 2 分钟规划然后重建了 3 次，B 花 20 分钟规划只建了 1 次，B 省了大约 67% 的开销。
道理我认可。我自己用 Claude Code 做项目，也是先在 Plan Mode 里把需求理清楚再动手。按两次 Shift+Tab 或者输入 /plan 就能进入规划模式，这时候 Claude 只做分析和规划，不动代码。
但他接下来说的"用便宜模型做规划"，得打个问号。
原话大意是：
用 Haiku 做头脑风暴，等想清楚了再切到 Opus。
听起来合理，但在 AI 编程场景下，规划阶段恰恰是最需要强推理能力的环节。你需要模型理解项目的整体架构、现有代码的设计意图、新需求和旧代码之间的逻辑关系。这些事情，便宜模型大概率搞不定。
当然，如果你还处于"我到底要做什么"的阶段，连需求都没想清楚，那用便宜模型先聊聊没问题。但一旦进入"怎么做"的规划阶段，尤其涉及代码架构的决策，别在模型能力上省这个钱。
我的判断： 规划先行没毛病。但模型选择要看你规划的是"做什么"还是"怎么做"。前者可以用轻量模型，后者上最强的。
第二条：控制对话长度 -- 基本功，但他漏了个好招
Miles 说：
长对话是隐形杀手。
因为每次发消息，Claude 都要重新读一遍之前所有的对话历史。对话越长，每条消息消耗的 Token 越多，输出质量也会被无关信息稀释。
老生常谈，但确实很多人忽略。你用 Claude Code 用了一段时间，还不知道什么时候该切换新对话、什么时候该清空上下文，那说明还有不少东西要补。
他给了两个方案：一是用 Projects 管理多个子对话，二是用"超级提示词"迁移上下文。
第二个方案挺有意思。做法是在切换新对话前，让 Claude 生成一段提示词，把当前对话的关键上下文浓缩进去，然后在新对话里粘贴这段提示词，无缝接续。
这个技巧在 Claude Code 里有更利索的实现方式：/clear 命令。
/clear 会清空当前对话的历史上下文，但不关闭对话窗口。你可以在清空前让 Claude 把关键信息总结一下，清空后把总结粘贴回去，效果和"超级提示词"一样，但不用开新对话。或者更省事，直接用 /compact，让 Claude 自动压缩上下文，保留关键信息，丢掉冗余的中间过程。
我的判断： 控制对话长度没错。"超级提示词"的思路也好，但 Claude Code 用户直接 /clear 或 /compact 更利索。
第三条：记忆管理 -- 方向对了，方法过时了
Miles 说 Claude 最大的问题之一是经常忘记上下文，你得反复解释自己要什么，浪费 Token。他的方案是创建两个 Markdown 文件：
- Instructions.md：写你的规则和指令，告诉 Claude 你是谁、你要做什么、有什么规矩
- Memory.md：让 Claude 持续更新的"大脑"，记录你的偏好、纠正过的错误、行为模式
他还特别强调要在 Instructions 里加一句：
Update Memory.MD with my preferences over time.
让 Claude 主动往记忆文件里写东西。
思路方向没问题。但如果你用的是 Claude Code，这套手动方案已经不需要了。
Claude Code 有两套内置的记忆机制：
第一套是 CLAUDE.md。 项目级配置文件，放在项目根目录下。你可以在里面写项目背景、技术栈、编码规范、个人偏好。Claude Code 每次启动对话都会自动读取。作用和 Miles 说的 Instructions.md 基本一致，但不需要手动挂载，原生支持。
第二套是自动 Memory。 Claude Code 会在对话过程中自动识别值得记住的信息，保存到 Memory 文件里。你也可以用自然语言主动触发，比如直接说"记住：我不喜欢用分号"，Claude 就会把这条偏好写进记忆。下次对话自动加载，不用手动维护。
Miles 的两个文件方案，在 Claude Code 里已经被产品化了。不需要自己建文件夹、写 Markdown、手动挂载。直接用就行。
我的判断： 记忆管理的需求是真实的，但 Claude Code 用户不需要手动搞这套。用好 CLAUDE.md + 自动 Memory 就够了。
第四条：模型分层使用 -- 思路对，但判断标准说错了
Miles 建议用"逐级升级"的策略：Haiku 处理轻任务，Sonnet 处理中等任务，Opus 只用在重任务和最终执行上。他还给了几个额外建议：关掉 Extended Thinking、把风格切到 Concise、在 Claude Code 里用 Low effort。
模型分层的思路没问题，但判断标准有点粗糙。"轻任务用便宜模型，重任务用贵模型"听起来直觉上对，但什么算轻、什么算重？
我的经验是，关键不在于任务的"大小"，而在于任务是否需要深度推理。
比如让 AI 批量重命名一堆文件，任务量不小，但逻辑简单，Haiku 完全能搞定。反过来，让 AI 分析一段 50 行的代码为什么在特定边界条件下会出 bug，任务量很小，但需要理解上下文和逻辑链条，这时候你需要 Opus。
判断标准应该是：这个任务需不需要模型去理解逻辑关系、推断因果、做出判断？ 需要就上强模型，不需要就用便宜的。
另外他提到的 /effort，值得单独说一下。Claude Code 里可以通过 /effort 调节模型的推理深度，有 low、medium、high 三档。根据 Anthropic 官方的说法，调低 effort 不会减少 Token 消耗，只是让模型推理时间变短。换句话说，它影响的是速度和推理深度，不是账单。
你的目的是省钱？调 /effort 帮助不大。你的目的是让简单任务跑得更快？low effort 确实有用。
我的判断： 模型分层思路正确，但判断标准应该是"是否需要推理"，不是"任务大不大"。/effort 影响速度不影响花费。
第五条：工具分流 -- 有道理，但对 Claude Code 用户意义有限
Miles 最后一条建议是：Claude 的不同工具有不同的用量额度。比如 Claude Code 和 Claude Chat 共享一个额度池，但 Claude Design 是独立的。不要用 Code 的额度去做设计，该用 Design 的时候用 Design。
对 Claude 网页版用户来说确实有用。但对 Claude Code 用户来说，你的主要工作场景就是在终端里写代码，很少会在 Code 里做视觉设计。实际收益不大。
不过他提到的一个思路我觉得值得延伸：不是所有任务都需要用 Claude。 简单的信息查询、新闻搜索、翻译这些事情，用 DeepSeek、Kimi 这些免费或便宜的模型就够了。把 Claude 的额度留给真正需要它的场景。
我的判断： 工具分流的意识没错，但对 Claude Code 用户来说更实际的做法是：把非编程任务分流到其他模型，而不是在 Claude 的不同工具之间倒腾。
他没提到的：用状态栏实时监控你的消耗
整篇推文讲了 5 条省钱策略，但有一个我觉得最实用的技巧他完全没提：让 Claude Code 在底部状态栏实时显示你的消耗信息。
你只需要跟 Claude Code 说一句话：
在我 Claude Code 底部状态栏，以清晰易读的格式展示：我当前使用的模型、上下文使用占比、本次对话花费、当前目录和 Git 分支。
Claude Code 就会帮你配置好状态栏。之后你每时每刻都能看到自己在用什么模型、上下文用了多少、这次对话花了多少钱。
这比"定期检查 /usage"好得多。/usage 是事后查看，状态栏是实时感知。就像开车时仪表盘上的油量表，比到了加油站才看油箱有用得多。
当你能实时看到上下文占比在涨，你自然会在合适的时候主动 /clear 或 /compact。看到对话花费在飙升，你会本能地去想"是不是该换个思路了"。
这才是省 Token 最根本的方法：不是靠记住一堆技巧，而是让消耗信息始终在你眼前。
总结：省 Token 的本质是什么
Miles 这篇推文能火有道理。505 万浏览说明大家确实被 Claude 的用量限制困扰着，他给出的框架整体方向没问题：先规划、控长度、管记忆、选模型、分工具。
但如果你是 Claude Code 用户，他的很多具体建议需要调整：
| Miles 的建议 | 我的修正 |
|---|---|
| 用便宜模型做规划 | 看任务类型，架构规划需要强模型 |
| 开新对话迁移上下文 | 用 /clear 或 /compact 更方便 |
| 手动维护 Instructions + Memory 文件 | Claude Code 内置了 CLAUDE.md + 自动 Memory |
| 按任务大小选模型 | 按是否需要推理选模型 |
| 用 Low effort 省 Token | /effort 影响速度不影响花费 |
| 定期检查 /usage | 配置状态栏实时监控 |
说到底，省 Token 的本质不是省钱，是让 AI 把有限的算力花在真正需要的地方。规划清楚了，上下文干净了，模型选对了，你不光省了 Token，输出质量也会更好。
不是"怎么少花钱"，而是"怎么花得值"。
参考资料：
