在项目里用 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 CodeClaude 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之类的报错通常和网络稳定性、登录态过期、账户权限有关可以尝试以下顺序排查检查本机网络是否正常能否正常访问 Anthropic 服务。重新执行登录命令确保浏览器授权流程没有被拦截。如果是企业组织账号确认组织是否已经开通 Claude Code 的订阅访问权限。查看.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 个文件完成一个再继续下一个。例如把“重构订单模块”拆成第一步先梳理订单模块的现状输出改动计划。第二步重构订单状态流转逻辑并补充单元测试。第三步优化订单列表查询减少 N1 查询。第四步修改前端订单页面的字段映射。在实际执行时可以让 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 消耗却居高不下。有两种常用手段/clear清空当前会话的历史记录从零开始。/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 └── .claudeignore4.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. 常见问题与排查思路问题现象常见原因解决思路会话越往后越慢、越贵上下文历史太长使用/compact压缩历史或完成子任务后/clearClaude 总是完整输出大文件没有输出约束在 CLAUDE.md 中加入“只返回 diff”的规范登录报错提示 token exchange failed网络不稳定、登录态过期、账号权限未开启检查网络和登录状态确认账号订阅访问权限必要时重新登录组织账号无法使用 Claude Code组织策略关闭了订阅访问联系组织管理员开通访问权限修改时反复弹权限确认权限白名单没有配置在.claude/settings.json中按需配置 allow 规则模型总是读取无关文件没有使用.claudeignore或没有精确添加文件维护.claudeignore使用/add-file、/add-dir控制范围退出终端后无法恢复上下文没有使用会话恢复使用claude --resume或claude --continue配置了 settings.json 后没有生效配置字段名写错检查文件语法对照/help更新字段排查 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再挑一个老任务按六大技巧跑一遍应该很快就能感受到差别。