Claude Code 省钱实战：六大技巧降低 token 消耗

在项目里用 Claude Code 做日常开发，最头疼的往往不是模型“听不懂”，而是聊着聊着上下文越来越大，回答越来越慢，token 消耗却肉眼可见地往上飙。你只是让它改一个小函数，它却把整个文件重新输出一遍；你只是稍微没交代清楚背景，它又花掉几千 token 来“确认你的意图”。最近我把自己的使用方式重新梳理了一遍，总结出六个对成本最敏感的实操技巧，从上下文管理到输出约束都做了调整。按这套方式跑了两周，项目里的 token 成本大概下降了一半左右，而且代码质量不但没缩水，反而因为工作流更清晰，整体协作效率更高了。

这篇文章会从“ Claude Code 的 token 到底消耗在哪里”讲起，逐步拆解六个技巧，并给出可以直接复制到项目里的 CLAUDE.md 模板、提示词片段、命令组合和常见报错排查方法。无论你是刚接触 Claude Code 的新手，还是已经在团队里大规模使用的老手，应该都能从中找到可落地的省钱思路。

1. 为什么 Claude Code 的 token 消耗那么高？

先说一个容易被忽略的事实：Claude Code 不止是“一个聊天机器人”，它的本质是“一个运行在终端里的 AI 编程代理”。它需要读取文件、执行命令、接收命令输出、再根据这些信息继续修改代码。每一次工具调用和命令行回显，都会被折算成 token 计入上下文。

如果你只是把 Claude Code 当成一个“能多聊几句的代码助手”，你会发现它特别费 token。原因是很多浪费场景是隐性的：

• 上下文历史增长：一次会话如果持续几小时，前面所有轮次的对话都会保留在上下文里。模型每次回答都要“重新读”一遍完整历史，上下文越长，单轮开销越大。
• 冗余输出：默认情况下，Claude 为了让你确认修改结果，往往会输出完整的文件内容或大段的解释说明。这些输出 token 很快就会把额度耗尽。
• 反复请求权限：当 Claude Code 准备写入文件或执行 shell 命令时，如果权限没提前配置好，它每执行一步都会停下来问你“是否允许”。这种大量交互轮次，既费时间又费 token。
• 不合理的文件读取：你让它改一个模块，它却把整个项目目录扫描一遍，或者读取了十几个不相关文件，这些内容都会一起进入上下文。

所以，想要控制 token 成本，核心并不是“少用几次”，而是把上下文管理好、把输出格式约束好、把无效交互剪掉。下面这六个技巧，就是从这几个方向展开的。

2. 环境准备与版本确认

在开始优化之前，先确认你的环境是干净的、可复现的。

2.1 安装 Claude Code

Claude Code 是 Anthropic 官方的终端工具，通常通过 npm 安装：

npm install -g @anthropic-ai/claude-code

安装完成后，检查版本和帮助信息：

claude --version claude --help

不同版本的命令和参数可能有细微差异，本文后续内容主要面向较新的 CLI 版本。如果你发现自己环境中没有某个命令，可以使用claude --help或会话内输入/help查看当前版本支持的具体能力。

2.2 登录与环境变量

首次启动时，在终端输入claude，按提示完成登录授权。如果在登录过程中出现类似token exchange failed、sign-in could not be completed之类的报错，通常和网络稳定性、登录态过期、账户权限有关，可以尝试以下顺序排查：

1. 检查本机网络是否正常，能否正常访问 Anthropic 服务。
2. 重新执行登录命令，确保浏览器授权流程没有被拦截。
3. 如果是企业组织账号，确认组织是否已经开通 Claude Code 的订阅访问权限。
4. 查看.claude/目录下的日志或配置文件，确认没有残留的过期登录凭据。

另外，不要把 API 密钥直接硬编码到项目代码或提交到 Git 仓库。建议通过环境变量注入，例如：

export ANTHROPIC_API_KEY="你的密钥"

需要注意的是，API 密钥属于敏感凭据，生产环境中要遵循最小权限原则，并定期轮换。

2.3 项目配置目录

Claude Code 会读取两个层面的配置：

• 用户级配置：通常位于用户主目录~/.claude/，例如用户级 CLAUDE.md、settings.json。
• 项目级配置：位于项目根目录.claude/目录，例如.claude/settings.json、.claude/settings.local.json。

如果你使用 VSCode，可以安装官方 Claude Code 扩展，在编辑器内直接打开对话面板。需要注意的是，编辑器里使用 Claude Code 和终端里使用，底层逻辑是一致的，上下文和 token 计费方式也没有区别，因此本文的技巧同样适用。

3. 六大实用技巧

下面逐一展开六个技巧。每个技巧都包含“为什么能省钱”、“具体怎么做”、“注意事项”三部分。

3.1 技巧一：把项目规范写进 CLAUDE.md

很多人在用 Claude Code 时，每开一个新会话都要花一大段话解释项目背景：“我们这个项目是微服务架构，后端用 Java 17，数据库是 MySQL，代码规范是……”这些话每说一次，就会被当成输入 token 消耗一次。更糟的是，下次新会话还得重新解释。

Claude Code 支持项目级记忆文件CLAUDE.md。当你在项目根目录运行claude时，它会自动读取这个文件，把它作为项目背景注入到上下文里。你可以把我们希望模型一直记得的信息全部写进这个文件。

建议在项目根目录执行：

claude

然后在会话中输入：

/init

/init会根据当前仓库的代码结构，自动生成一个初始版的 CLAUDE.md。不过自动生成的内容往往不够个性化，建议基于它继续完善，加入团队的“私有约定”。

下面是一个可以直接参考的模板：

# 项目规范 ## 技术栈 - 后端：Python 3.11 + FastAPI - 数据库：PostgreSQL 15 - 缓存：Redis 7 - 代码风格：Black + isort + ruff ## 常用命令 - 启动开发服务器：uvicorn app.main:app --reload - 运行测试：pytest -q - 代码格式化：ruff format . - 数据库迁移：alembic upgrade head ## 目录结构 - src/api/ 路由层，只处理请求参数和响应格式 - src/service/ 业务逻辑层，核心业务放这里 - src/repo/ 数据访问层，所有 SQL/ORM 操作放这里 - tests/ 单元测试和集成测试 ## 约束 1. 修改数据库表结构时，必须同步提供 Alembic 迁移脚本。 2. 不要修改 generated/ 目录下的任何代码。 3. 对外 API 字段只增不改，保持兼容。 4. 新增依赖前先确认是否真的必要，并更新 requirements.txt。

这样设置之后，每轮对话 Claude 都会参考这份规范，不再需要你反复口头说明。从 token 角度看，相当于把一次可能重复十几次的“项目介绍”压缩成了一次固定消耗，而且越长的项目收益越明显。

另外，CLAUDE.md 是文本文件，应该提交到 Git 仓库，让团队成员共享。每个开发者还可以在用户级目录放置自己的~/.claude/CLAUDE.md，保存个人偏好。

3.2 技巧二：拆解任务，小步提交

很多开发者习惯把一个大需求一次性丢给 Claude Code：

“帮我重构这个订单模块，顺便优化一下数据库查询，然后把前端页面也调整了。”

这种需求听起来很爽，实际上会让 Claude Code 在一个很长的会话里处理大量文件。每次工具调用、每次读取、每次输出，都会累计进同一个上下文。做到后半段时，前面读过的几百行代码还被保留着，模型每回答一次都要“重新过一遍”旧历史，token 开销会快速膨胀。

更合理的方式，是把大型任务拆解成若干小任务，每个任务只涉及 1 到 3 个文件，完成一个再继续下一个。

例如，把“重构订单模块”拆成：

• 第一步：先梳理订单模块的现状，输出改动计划。
• 第二步：重构订单状态流转逻辑，并补充单元测试。
• 第三步：优化订单列表查询，减少 N+1 查询。
• 第四步：修改前端订单页面的字段映射。

在实际执行时，可以让 Claude 开启“计划模式”或输出一个 todo 列表：

请先不要修改代码。先阅读 src/service/order_service.py，梳理当前订单状态流转的流程，然后输出一份重构计划。计划里需要列出： 1. 要修改的函数 2. 每个函数的改动点 3. 对应的测试用例 4. 可能影响到的其他模块 确认计划后，再逐步执行。

这样做的好处是，前期的“计划和确认”阶段只需要较少上下文，你可以及时发现问题并调整方向，避免模型实现到一半跑偏，浪费大量 token 在错误方向上反复修改。

小步提交还有另一个隐藏收益：当任务足够小，你可以在完成一个子任务后直接/clear清空上下文，下一个子任务在新会话中开始。这样上下文永远不会无限制膨胀，单轮消耗会稳定得多。

3.3 技巧三：限制输出格式，少让模型“复读”

节省 token 不能只盯输入，输出 token 同样很重要，而且在很多计费模型里，输出 token 的单价往往更高。

Claude Code 在完成代码修改时，默认会把修改后的文件内容或 diff 展示出来。当文件很大时，光输出完整文件就能消耗掉上千 token。你可以明确要求它“只输出关键信息”。

在 CLAUDE.md 的约束里，可以加入这样的约定：

## 输出要求 1. 修改代码后，默认只展示 diff，不要输出完整文件内容。 2. 如果只是回答简单问题，用三句话以内总结。 3. 不要重复粘贴未修改的代码。 4. 不要求解释代码原理时，不要主动展开原理说明。

在对话中，也可以使用这样的提示：

请修改 src/service/order_service.py 中的 create_order 函数，要求： 1. 支持传入优惠券 ID。 2. 校验优惠券状态。 3. 其他逻辑保持不变。 输出时只返回修改后的函数完整代码，以及你改动的 3 个关键点，不要贴整个文件。

这样会明显压缩输出 token。特别是当你在做一个大型仓库的批量修改时，如果每个文件默认少输出几百行“未修改内容”，累计节省量非常可观。

另外，如果你在命令行非交互模式下使用 Claude Code，比如在脚本里执行一次性任务，可以考虑使用-p或--print模式，并结合--output-format把输出结果限定为文本或 JSON。这样既方便程序解析，也能减少不必要的富文本信息。

3.4 技巧四：及时清理上下文，使用 /clear 和 /compact

上下文窗口是有限的。即使你做好了拆解任务，一个任务也可能因为调试、测试、反复修改而积累很多历史轮次。这时候继续在旧会话里“追加修改”，模型的注意力会被前面大量历史占据，回答质量下降，token 消耗却居高不下。

有两种常用手段：

1. /clear：清空当前会话的历史记录，从零开始。
2. /compact：压缩当前会话历史，把过去的对话摘要成更短的记忆，并保留关键上下文。

/clear适合任务之间切换时使用。比如你刚完成“优化订单列表查询”，接下来要做“修改订单导出功能”，两者关联不大，就可以在新会话中重开。

/compact适合长任务的中间阶段。比如你正在做一个复杂的跨模块重构，已经聊了几十轮，上下文快满了，但你还希望 Claude 记得前面确认过的方案。此时可以输入/compact，它会生成一份摘要，把重要的历史信息压缩进模型上下文，同时丢弃大量冗余对话。

你还可以在实战中利用会话恢复功能：

# 继续最近一次会话 claude --continue # 恢复某个指定会话 claude --resume 会话ID

这样即使你清了会话或关闭了终端，下次仍能带着关键结论继续，而不必把原需求重新粘贴一遍，也就避免了重复的输入 token。

使用技巧：会话中随时输入/context查看当前上下文占用情况，输入/cost查看当前会话已经消耗的 token 情况。定期检查这两个指标，能帮你建立对 token 消耗的“肌肉记忆”。

3.5 技巧五：精准引入文件，别把整个仓库喂进上下文

Claude Code 的一个常见误区是，当用户说“帮我看看整个项目”，它会读取很多文件来建立全局理解。这个“全局理解”听起来很智能，实际上会消耗大量 token。尤其当项目里有node_modules、dist、build、logs这类目录时，一次扫描可能就把上下文撑爆。

更聪明的做法是“按需加载”。你可以使用/add-dir把某个具体目录加入上下文：

/add-dir src/api

也可以使用/add-file精准添加某个文件：

/add-file src/service/order_service.py

如果你要改一个跨模块的功能，优先把“目标文件”和“被依赖文件”加进去，而不是把整个项目根目录拖进来。

同时，建议在项目根目录维护一个类似.gitignore的文件.claudeignore。Claude Code 会读取这个文件，跳过里面指定的目录和文件，避免无关内容进入上下文。例如：

node_modules/ dist/ build/ logs/ *.min.js *.map .env

如果你需要解决一个关于“某个函数在哪定义”的问题，与其让 Claude 直接搜索整个仓库，不如先在终端里用grep或rg缩小范围，再把找到的文件手动添加进上下文。这样模型不需要自行探索，也省掉了很多工具调用的开销。

3.6 技巧六：用权限和 hooks 降低无效重试

在默认情况下，Claude Code 每次准备执行命令或写文件时，都会弹出确认提示。当一个大任务包含几十次文件操作时，你就要反复按确认键，模型也要反复等待。这些交互虽然单次不贵，但累计起来仍然是一笔不小的 token 消耗，而且整个流程会被拖得很长。

如果你已经通过 CLAUDE.md 明确了项目规范，并且对 Claude 的改动范围有清晰预期，就可以在.claude/settings.json中提前配置权限白名单。下面是一个示例片段：

{ "permissions": { "allow": [ "Bash(npm test)", "Bash(pytest)", "FileWrite(src/**)" ] } }

这个配置的意思是：允许 Claude 直接执行npm test、pytest命令，允许直接修改src/目录下的文件。具体字段名可能随版本变化，你可以先查看版本的帮助文档或配置文件说明，再按实际结构调整。

hooks 是另一个降低无效操作的手段。你可以配置一些钩子，例如在每次 Claude 执行命令之前先校验当前分支，或者在执行完命令后自动记录工具调用日志。通过 hooks 自动化一部分流程，可以减少“继续执行”类对话，也能让 Claude 在错误发生前就主动避坑。

不过要注意：权限配置越宽，风险也越高。如果把Bash(*)和FileWrite(**/*)全部放开，虽然 token 省了，但项目被误改的风险也上来了。生产项目中更推荐“按目录、按命令”的最小化授权，而不是一刀切全放行。

4. 实战案例：一次代码重构中的 token 控制

下面用一个简化例子，串起上面的技巧。假设我们要在一个 FastAPI 项目里，把订单模块的响应格式从直接返回字典改成统一包装格式。

4.1 项目结构

my-api/ ├── app/ │ ├── main.py │ ├── api/ │ │ └── order_api.py │ ├── service/ │ │ └── order_service.py │ └── repo/ │ └── order_repo.py ├── tests/ │ └── test_order.py ├── CLAUDE.md └── .claudeignore

4.2 在 CLAUDE.md 中声明约束

在CLAUDE.md中加入本次重构的约束：

# 订单响应格式重构说明 ## 当前目标 把所有订单接口的返回结构从裸 JSON 改为统一包装格式： { "code": 0, "message": "ok", "data": ... } ## 改动范围 - 只允许修改 app/api/ 下的路由层，以及新增统一响应工具类。 - 不允许修改 app/repo/ 下的数据访问层。 - 兼容旧的字段名，不删除已有字段。 ## 输出格式 - 每个文件只输出 diff 和简要说明。 - 不要修改无关代码。

4.3 拆解提示词

不要直接说“帮我重构订单模块”。像这样拆解：

第一轮：

请先读取 app/api/order_api.py，列出当前所有订单接口，以及每个接口返回的字段。然后给出统一响应格式的修改计划，计划要包含： 1. 新增工具类的位置和代码结构。 2. 每个接口需要改动的位置。 3. 对应的测试用例。 先不要写代码。

第二轮，在确认计划后执行：

请按照刚才确认的计划，新增 utils/response_wrapper.py 工具类。只输出新文件的完整代码。

第三轮：

现在修改 app/api/order_api.py，把 get_order_list 接口的返回值改为新版格式。只输出 diff，不要贴整个文件。

如果做到后面已经积累了较多轮次，可以在修改完一个文件后输入/clear，然后在下一轮用claude --continue接着继续，同时附上一句简洁的背景：

继续之前的订单响应格式重构，现在需要修改 order_api.py 中的 create_order 接口。

这样每一轮上下文都保持精简，历史冗余不会越积越多。

4.4 运行验证与成本观察

执行测试：

pytest -q

如果测试失败，把失败信息交给 Claude 时，只粘贴关键报错片段和堆栈，不要把整页日志全部塞进提示。你还可以要求：

只分析报错原因，给出修复建议，不要重写整个文件。

在会话中随时输入/cost观察 token 使用情况。你可能会发现，同样一个重构任务，优化前的会话轮次更多、输出更冗长；优化后虽然需要你手动拆步骤，但整体开销明显更小。

5. 常见问题与排查思路

排查 token 消耗异常时，优先看三个点：

• 上下文是否已经接近窗口上限；
• 每轮输出是否包含了大量无关内容；
• 是否因为权限确认或工具调用失败，产生了大量无意义交互。

6. 最佳实践与工程建议

6.1 把成本控制纳入开发习惯，而不是事后补救

建议在每天开始使用 Claude Code 前，先想清楚“今天这个任务需要哪些文件”和“希望它输出什么格式”。把这两点写进提示词，比事后抱怨“它怎么消耗这么多 token”有效得多。

6.2 用 CLAUDE.md 沉淀团队约定

CLAUDE.md 不只是项目背景，它还是团队开发约定的“执行手册”。依赖管理、测试命令、目录边界、禁止改动区域、代码风格、输出规范，都可以写进去。团队项目里，把 CLAUDE.md 的维护纳入 Code Review 流程，谁改了项目约束，提交记录里要能看出来。

6.3 慎用全自动执行

如果你在 CI 管道里批量运行 Claude Code，建议把任务限制在“只读分析”和“生成代码片段”两类场景。需要自动提交代码的场景，必须配合严格的权限白名单和静态检查流水线，避免 AI 生成的代码绕过测试直接进入主干。

对于权限配置，始终遵循最小权限原则：只允许它执行它真正需要的命令，只允许它修改它真正负责的目录。宁可在配置时多写几条规则，也不要直接放开所有权限。

6.4 定期观察成本和上下文指标

在交互式会话中，多使用/cost、/context观察单次会话的消耗构成；在自动化脚本中，可以定期记录工具调用日志和输出 token 量。观察几次之后，你会逐渐形成一种“哪些提示词容易引发高成本”的直觉。

6.5 注意日志和敏感信息

不要让 Claude Code 读取生产环境的日志、配置文件或数据库凭据。如果排查问题时需要用到线上日志，先脱敏再交给模型。对所有敏感操作，要求在测试环境验证通过后，再在受控流程中执行。

7. 总结与下一步学习路线

回到最开始的问题：Claude Code 的 token 消耗为什么高？不是因为模型“贪吃”，而是因为默认工作流里充满了上下文冗余、输出冗余和无效交互。通过把项目规范固化到 CLAUDE.md、拆分任务、限制输出格式、及时清理上下文、精准引入文件、配置权限与 hooks，六个技巧组合起来，可以很稳定地把 token 成本压到原来的五到六成。

下一步，你可以继续沿着这几个方向深入：

• 研究 Claude Code 的 MCP 工具接入，看能否把外部数据源操作也纳入规范化流程。
• 学习在团队协作中统一管理.claude/settings.json和 CLAUDE.md 的版本。
• 尝试把 Claude Code 接入自动化测试和代码审查流程，让它在受限环境里批量完成低风险任务。

这篇文章里给出的命令和配置，在不同版本中可能会有所调整，建议先在自己的环境里用/help确认。省钱的核心不在于记住某条命令，而在于建立“每次使用都清楚上下文边界”的习惯。你现在打开一个项目，先写一份像样的 CLAUDE.md，再挑一个老任务按六大技巧跑一遍，应该很快就能感受到差别。