Claude Code 用得好不好很多时候不是看它会不会写代码而是看你会不会控制成本。上个月我做了一次成本复盘发现一个很扎心的事实功能都完成了token 消耗却比我预想的高出一大截。翻细节后才发现真正烧钱的不是模型不够聪明而是我一直在让它背着一堆无用上下文往前走。Claude Code 这类终端 AI 编程工具本质上是在一个长对话里反复调用模型。每次你让它改一个东西它都要把之前的对话历史、项目文件、工具输出重新处理一遍。历史越长单次请求越贵。这篇文章不聊抽象的“省 token 技巧”而是六条我在实际项目里验证过、能直接落地的做法。如果你的浪费主要出在上下文不干净、任务边界模糊、失败重试太多这些地方组合起来成本降一半并不是夸张话。1. 先把账算清楚token 到底花在哪三个地方想省钱先要知道钱花在哪。模型计费通常按输入 token 和输出 token 分开算Claude Code 的消耗不只是你打字的那几行而是它“看得见的一切”。1.1 输入 token 的三大入口Claude Code 执行任务时会把系统提示、项目规则、对话历史、工具调用结果、你主动提供的文件内容一起打包发给模型。很多人有个误区我输入的提示词不多应该不太贵。实际情况下真正占大头的是下面三类对话历史。包括你之前所有的提问、模型的所有回答、工具调用的中间日志。只要这个会话不结束每一轮新请求都会把前面内容重新发送一遍。主动粘贴的上下文。整份源码文件、一整段报错日志、一个超大 JSON都是常见浪费源。Agent 自己读取的文件和目录结构。它执行搜索、读文件、看目录时可能一次把大量内容拖进上下文虽然你看不到但它确实已经计费。1.2 会话越长单次成本越高这个模型有一个容易被忽略的特性对话越到后面每次新请求的输入都会被前面所有内容占满。比如一个会话断断续续聊了三个小时可能当前真正的问题只有几十个 token但模型在回答前要先消化前面几千甚至上万的历史 token。我见过连续跑一整天的 Claude Code 会话到下午处理一个很简单的小需求时响应明显变慢费用也在肉眼可见地涨。原因不是模型变笨而是它每次都要背着整个上午的上下文往前走。所以省 token 的第一个思路不是换更便宜的模型而是让模型每次只看它该看的那部分。如果你用的是支持上下文占用检查的工具可以先看每个会话到底用了多少上下文就算不看从响应速度和费用变化也能判断出来。别等月底账单出来才后知后觉。2. 技巧一用项目规则把“想当然”变成硬约束2.1 项目指令为什么能省 token让 AI 帮你写代码时它面临的最大问题往往不是不会写而是不知道你的项目约定测试框架用哪个、目录结构怎么组织、变量命名习惯是什么、能不能直接改依赖文件。如果你不告诉它它就会猜猜错了再修修的过程又是一整轮对话。Claude Code 这类工具通常会读取项目根目录下的规则文件比如 CLAUDE.md。项目启动时先初始化一份项目说明把项目背景、常用命令、代码风格、禁止改动区域写清楚。之后每次启动会话模型都会自动带上这些规则。你可能会问这不就是在多消耗 token 吗确实规则文件本身会占一部分输入但它减少的是大量来回确认。一次猜错可能花掉几百个 token来回试探几轮就是几千。规则文件只有几行却能避免多次返工这是典型的花小钱省大钱。2.2 落地时的具体写法初始化规则文件时至少写这几类信息项目是做什么的哪些目录绝对不能乱动。测试和构建命令的固定写法。代码风格约定比如 TypeScript、组件命名、样式方案。工作流约定先写测试再改实现最后跑命令。# 项目约定 - 技术栈: TypeScript React - 禁止修改: vendor/ 和 generated/ - 测试命令: pnpm test - 构建命令: pnpm build - 组件命名: 使用 PascalCase - 提交前必须跑测试写完以后如果第二天模型还在问“这个项目用什么包管理器”说明规则还不够细把它补进去。这样每轮会话省下的数量不大但积累一个月省下的是一大批重复确认的开销。注意规则文件最好不要写满一屏。它应该是一份有效索引不是项目百科。太长的指令本身也会占 token而且会稀释真正重要的约束。3. 技巧二喂给 agent 的不是文件是定位信息3.1 少贴文件多给路径我见过很多人在终端工具里习惯把整个文件内容复制进来甚至一口气贴十几个文件。对模型来说一次性看到完整文件确实更安全能减少理解偏差。但绝大多数情况下文件里只有一小块和当前任务相关。大文件一旦进入上下文即使你不引用它它也已经占用了输入 token。更省钱的做法是只给文件路径和问题描述让模型自己按需读取。例如“看 src/components/pricing.tsx把定价区改成三列布局”它会先读文件再定位到相关段落。如果你担心它找不到关键位置可以在需求里补上函数名或行号范围。平时可以先在命令行用 grep 或类似工具找到关键词位置然后把“关键词 文件路径 具体问题”传给模型。这比粘贴整个文件更准因为模型知道该看哪里而不是在噪声里找线索。3.2 让模型看 diff而不是全集另一个常见浪费源是改代码时把整个文件重新贴一遍。更符合版本控制思维的做法是把改动差异说明给模型或者直接用git diff生成片段。修 bug 时git diff能把变更点压缩到几十行而整个源文件可能几千行。我一般会让模型先看 diff 和报错日志判断问题来源再去读具体文件。这个顺序可以避免它把整个项目从头扫一遍。以前我习惯让 agent 先“浏览项目结构”听起来很专业实际它会读目录列表和大量关键文件一轮下来比改代码本身还贵。改成“先看 diff 报错再看相关文件”之后单次修复的成本降了不少。4. 技巧三一个会话只做一件事4.1 历史记录是隐形成本这是最容易被忽视的一点。很多人用 Claude Code 像用聊天软件想到什么问什么先让写个函数又让它顺便看看刚才的样式再让它重新解释一遍上一轮代码全部挤在同一个会话里。问题在于每轮新请求都会带着前面所有对话一起发送给模型。哪怕前面的讨论已经结束模型还是要重新读一遍。如果历史里有大段工具输出、报错堆栈这个会话就变成了一个不断膨胀的“上下文包袱”。我的判断标准很简单一个问题已经解决就立刻开新会话后续问题和当前主题关系不大也换新会话需要继续但历史已经很长先压缩会话。压缩就是把长对话浓缩成一段摘要保留关键结论删掉中间的大段完整轮次。4.2 什么时候压缩什么时候清空可以按场景快速判断任务完成了开新会话。任务进行中但对话已经很多轮压缩历史。任务换方向了直接清空避免旧思路干扰新任务。只是临时查一下资料可以用独立短会话处理完就关掉。清空也有代价模型会忘记你刚才改到哪需要重新提供文件路径和当前状态。所以更推荐“压缩”而不是“清空”除非旧上下文本身不重要。把会话状态当成工作台不要让它变成仓库。工作台上只放当前任务要用的东西做完就清下一次任务重新摆。5. 技巧四把输出“管短”也是一种优化5.1 在指令里直接要求短输出很多人只盯着输入 token忽略了输出 token。模型生成的每个字都要计费而且生成的长解释会继续留在上下文里影响后续请求。比如你让它“优化这段代码”默认它可能会先解释思路再给出完整修改版本。但你可以明确写不要解释思路直接输出修改后的代码只要关键改动不要重复整个文件解释控制在三行以内。这些约束不需要额外配置在支持自然语言指令的工具里基本都有效。用一段时间后你会发现降低输出长度不只是省 token还能让模型更聚焦。输出越短留给后续任务的上下文空间越大准确率反而可能提升。5.2 要求“定位修改”而不是“整体重写”同一个需求不同的表达方式消耗差异很大。“把这个函数重构一遍”可能让它输出几十行换成“只修改第 12 行到第 18 行保持其它不变”它就会只输出那几行片段。在批量调整样式或重构时我会先让模型列出所有需要改的文件和具体改动点确认范围后再执行修改。虽然多了一轮“列计划”但避免了它在错误方向上一口气生成大量无用代码。这个小流程表面上多花几十个 token实际上把返工成本压下来了。5.3 让输出落地到文件而不是终端如果你需要生成一个完整文件尤其是比较长的内容不建议让模型在终端里把内容全部打印出来。终端输出会占用显示和上下文而且一旦打印完它又成为历史的一部分。可以用重定向把输出写到文件或者让工具直接修改文件。这样既能查看落地结果又避免整段内容反复出现在对话历史中。6. 技巧五失败重试前先问“为什么失败”6.1 重试链的 token 放大效应终端工具里最常见的费用失控场景是反复试错。模型第一次执行代码失败你说“再试一次”失败后你又换个说法重来。每重试一次失败信息和前一次尝试都会作为历史重新发送下一轮输入变得更大。尤其是当报错信息本身非常长时比如一个依赖栈、一段测试失败日志再叠加模型自己的分析全部会累加。重试三次费用可能不是三倍而是更多因为历史在滚动累积。遇到失败不要急着说“再试一次”。先让模型“只总结失败原因不要改代码”把日志里最核心的报错行提炼出来。确认原因后再让模型给一个最小修改方案。如果报错和当前任务无关直接用新会话处理避免污染当前上下文。6.2 先跑最小样例再放真实任务批量场景下更危险。很多人拿到新需求直接让模型同时处理十个文件。模型走到第三个文件时发现格式不对回头改提示词结果所有文件都要重跑。正确的顺序是先用一条最少量的样例验证提示词是否有效确认输出符合预期再扩大到全部数据。这个验证成本很低却能拦截大多数“提示词理解偏差”问题。一旦发现提示词有误调整的只是一个小对话而不是整批重跑。这本质上和写代码前先写单测是同一个思路先保证最小的路径正确再让它规模化。建议给 agent 的每个批量任务都加上“先处理一个样本停止并等待确认”这样的约束。没有这个约束太多情况是它一口气执行完出了问题再整体返工。7. 技巧六用脚本和批处理替代长时间对话7.1 把重复操作变成可复用脚本Claude Code 最大的价值在于处理复杂、不可预知的任务但它并不适合做重复率高、规则明确的事情。如果你发现自己每天都要让它做同一件事比如“把所有图片压缩一遍”“给每个接口补参数校验”更省 token 的方式是把这些重复操作脚本化让脚本批量执行。脚本先把逻辑固化下来后续执行时不需要模型参与也就没有 token 消耗。如果必须让模型生成脚本就让它生成一次你保存下来长期复用。这个做法把“每次让 AI 重新理解需求”变成“一次性投资”长期成本下降非常明显。常见可脚本化的场景包括文件重命名、格式转换、批量替换。代码样式检查和简单修复。测试数据生成。文档模板生成。重复性的 API 调用。7.2 使用非交互模式处理单一任务如果你已经明确知道要做什么不需要现场讨论可以试试非交互模式。比如通过一条命令直接给出明确指令让模型执行完就退出。这种方式不会维护长会话历史单次请求的上下文非常干净。需要多步处理时也尽量在一个命令里把步骤写清楚而不是分多条消息慢慢挤牙膏。这等于把“聊天式开发”变成“命令式开发”。聊天适合探索命令适合执行。探索过程本身很贵执行过程相对便宜。能提前把结论写清楚就不要在终端里慢慢试。8. 最省 token 的工作流一个综合流程8.1 把它变成每天都能用的检查单上面的六个技巧单独看都不难难的是组合起来。组合后的理想流程是写清目标一句话描述任务附上相关文件路径或函数名。确认规则项目指令文件存在且完整不用模型靠猜。最小上下文优先使用 diff、报错关键行、单文件局部内容。限制输出明确要求短输出只改指定位置。小步验证先执行一个样本确认无异常再扩大范围。及时清理完成一个子任务就压缩或新建会话保持历史干净。固化重复频繁操作沉淀成脚本不再每次开对话。这可以当作团队规范也可以当作个人检查清单。用久了会形成一种肌肉记忆每次打开终端工具前先问一句“这次任务需要模型看到什么” 这个问题的答案基本决定了你会花多少 token。8.2 边界哪些情况下效果有限需要诚实说这六个技巧并不是在所有场景下都能让 token 下降一半。如果你的任务本质是长链条推理比如分析一个大型代码库的调用关系、重写一个复杂模块那模型必须看很多文件“减少上下文”就很难执行token 下降空间有限。相反如果你的痛点主要是闲聊式提问、反复修改、贴了一大段代码之后又说“刚才不算”那这六个技巧组合起来成本降一半并不是夸张。不同模型和工具的计费结构也不一样有些按输入输出统一计费有些分开算还有缓存机制。实际优化效果要结合你用的具体计费方式来看思路可以借鉴但不要当成万能公式。如果你刚接触这类工具第一步不是研究怎么省 token而是先把安装和登录跑通。很多人在安装后卡在登录环节看到类似 “token exchange failed” 的报错就慌了。这里的 token 指的是访问凭据和我们前面一直在说的模型计费 token 是两回事。遇到这种报错先检查网络是否连通、系统时间是否准确、登录授权是否过期再重新登录。如果是在团队环境还要确认当前网络策略是否允许访问对应域名。把登录问题解决掉再回来按这个流程优化成本。8.3 从省 token 到省时间关于 token 成本一个更底层的看法是不要只盯着费用更要看它是否在改变你的工作流程。当模型每次只处理它该处理的内容时你的需求也会变得更清晰需求清晰了返工自然变少。这时候省下来的不只是 token还有时间。后者往往比 token 成本更值得长期关注。