Claude Code 成本到底怎么控？手把手教你 3 招把 token 开销压下来

直接回答：Claude Code 的成本几乎全部由消耗的 token 决定，而 token 又直接跟着上下文体积走。控成本就三件事：把上下文压小、把提示写精炼、把大探索丢给子 Agent 隔离。做到这三点，同样的工作能少花一大截 token。

很多人以为「省钱」是靠换更便宜的档位，其实最大的浪费来源是上下文里塞了太多用不上的东西——整仓代码、冗长对话、每轮重复的背景。Claude Code 成本的高低，七成取决于你喂给它多少无效信息，而不是你问了多少问题。

先看结论

• 上下文体积是 token 消耗的第一来源，先把无关文件和不必要的历史清出去。
• 提示词越啰嗦，每轮往返消耗的 token 越多，给明确指令比写长篇背景更省。
• 用子 Agent 隔离大型探索任务，主会话只收结论，避免整段资料进入主上下文。
• 不要为省 token 而砍掉必要上下文，关键约束缺失反而会让它反复试错、更贵。

一、第一招：控制上下文体积

Claude Code 每生成一次回复，都要把当前上下文重新送进去算一遍，所以上下文越大，单轮成本越高。所谓省 token，第一步就是把上下文里「这一轮用不上」的东西拿掉。

下面这张图帮你判断三招分别适合哪种浪费场景。

关于上下文到底装了什么、怎么清理，上下文管理教程 讲得更系统，建议搭配着看。

1.1 精准引用，别整仓塞入

用 @ 精确指定这次要改的文件，而不是让它自己把整个目录读进来。仓库越大，这一条省得越多。只把相关模块放进上下文，无关文件根本不占 token。

1.2 定期压缩历史

长对话会累积大量往返内容。Claude Code 提供压缩对话历史的机制，把已经「得出结论」的中间过程收成摘要，保留关键决策、丢掉冗余细节，上下文体积立刻降下来。

1.3 验证清理是否真的生效

清理完别凭感觉。运行项目后观察上下文面板，检查当前还加载了哪些文件，对比清理前后体积，验证 token 是否真的降下来；若某类文件仍在反复占用，回到 1.1 收紧 @ 引用范围来修复。

二、第二招：精简提示词

提示词不是越长越好。每一轮你发的背景、客套、重复说明，都会变成 token 反复计费。把提示写精炼，是成本最低的一招。

▶ 啰嗦版（每轮多花 token，且容易跑偏）
你好，我现在在做一个 Spring Boot 项目，之前我们聊过用户模块，
我想让你帮我看一下 UserService 里的分页查询，能不能麻烦你
帮我改一下，让它支持按创建时间排序，谢谢，辛苦了。

▶ 精炼版（同样的信息，token 少一半）
在 UserService 的分页查询里增加按 create_time 降序排序，
保持现有分页参数不变。

上面这段对比的是同一个需求的两种写法：啰嗦版每轮都会把「Spring Boot 项目、之前聊过、客套话」这些对本次任务无用的信息反复送进上下文；精炼版只保留「改哪个文件、改什么、约束是什么」，信息密度高、token 少。具体的提示写法可参考 AI 编程指南 里的指令设计部分。

正常输出描述：用精炼版提示后，Claude Code 直接定位 UserService、给出只改 ORDER BY 一处的小改动，回复短、上下文增量小；相比啰嗦版，同样十轮对话累计少消耗相当可观的 token。

失败分支及处理：如果提示精简到把关键约束也删了（比如没说「保持分页参数不变」），它会自作主张改掉分页逻辑，你再让它改回来，反而多花两轮 token。处理方式是「砍客套、留约束」——删掉语气词和背景复述，但把不可违反的边界写清楚。

三、第三招：用子 Agent 隔离大上下文

最隐蔽的 token 黑洞，是让主会话去「翻遍整个仓库找某个实现」。这一翻，成千上万行代码全进主上下文，而你可能只想要一句话结论。

// 把大型探索任务派给子 Agent，主会话只收结论
// 在主会话里这样委派（示意）：
// 「派一个子 Agent 去找出支付模块里所有调用第三方 SDK 的地方，
//   只回报文件路径和行号，不要贴代码全文」

// 子 Agent 在隔离上下文里干活，主会话上下文不受影响
// 主会话最终只拿到类似下面的紧凑结论：
// pay/OrderService.java:88
// pay/RefundService.java:142
// pay/GatewayClient.java:30

上面这段做的是把一个「全仓搜索」的大任务委派给子 Agent，子 Agent 在自己的隔离上下文里读代码、整理结果，主会话只接收压缩后的结论（几行路径），那些被读过的源码全文不会污染主会话上下文。子 Agent 的隔离与委派机制详见 Claude 子 Agent。

正常输出描述：原本要在主上下文里加载上百个文件才能完成的检索，被子 Agent 在隔离环境消化掉，主会话上下文几乎零增长，单轮 token 成本明显下降，且主会话依旧能基于结论继续下达下一步指令。

失败分支及处理：如果把「需要边看边讨论」的细活也甩给子 Agent，主会话会因为它回传信息不足而反复追问，子 Agent 又反复重跑，总成本反而上升。正确做法是：纯检索、纯批量改动交给子 Agent 隔离；需要你逐步拍板的开放性问题，留在主会话处理。

想系统掌握技能配置，可以先读 Claude Code 技能教程。

总结

Claude Code 成本的控制，本质是对上下文的克制：体积压小、提示精炼、大任务隔离。三招叠加，同样的产出能省下明显的 token 开销。

要点带走：

• 上下文体积是 token 消耗大头，先清无关文件和冗余历史；
• 提示词砍掉客套和复述背景，但务必保留不可违反的约束；
• 全仓搜索、批量改动这类大上下文任务，交给子 Agent 隔离处理；
• 不要为省而省，关键约束缺失导致的反复试错，比多几行上下文更贵。

常见问题

Q：换个更便宜的档位是不是最省事？

A：档位只是单价，上下文体积才是总量。不控制上下文，再便宜的档位也会被大上下文堆高的 token 数吃掉优势。先压体积，再谈档位。

Q：压缩对话历史会不会丢重要信息？

A：压缩会保留关键决策、丢掉中间过程细节。只要你在 CLAUDE.md 里写清长期约束，压缩后那些规矩依然在，不会凭空丢失项目常识。

Q：子 Agent 一定能省钱吗？

A：不一定。纯检索、纯批量改动用它最划算；需要你逐步拍板的开放性问题留在主会话更合适，否则来回追问反而更贵。

Q：提示词写到多短算合适？

A：以「人看了能照做、AI 不缺约束」为度。删掉谢谢、背景复述、语气词，但保留文件路径、改动范围、不可违反的边界。

Q：怎么判断自己的上下文是不是太大了？

A：如果一次普通回复就要处理大量你这轮根本没提到的文件，或对话越聊回复越慢、越长，基本就是上下文被无关内容撑大了，该清理或隔离了。

延伸学习

想进一步压低成本，可以按这个顺序：

1. 系统学一遍技能体系，AI 编程技能课 覆盖从配置到实战的完整链路；
2. 概念想先搞懂计费口径，读一篇相关笔记 Token 计费笔记；
3. 想把多 Agent 协作固化下来，可以看 Agent Teams 教程。