前两天我在技术社区翻到一条分享标题写的是 “Boris Cherny, head of Claude Code at Anthropic, on optimizing token cost and model use. I use Fab…”。后半句被截断了看不出那个 Fab 具体指什么但光是前小半句就已经很戳人连 Claude Code 的负责人都在公开聊 token 成本和模型使用策略。我过去大半年几乎天天用 Claude Code 干活从写新功能、做老项目重构到追一些藏得很深的 bug花的 token 一度多到肉疼。后来慢慢摸出一些门道今天就把这件事彻底拆开讲清楚token 到底花哪了、模型该怎么挑、有哪些细节能实实在在省钱顺便把安装和使用里我踩过的坑也一并列出来。如果你刚开始接触 Claude Code或者用了挺久但对成本一直没什么概念这篇应该都能帮上忙。1. 聊 Claude Code 之前得先知道它为什么这么火1.1 Boris Cherny 和 Claude Code 的关系Boris Cherny 这名字在 TypeScript 圈子里不算陌生写过那本《Programming TypeScript》现在在 Anthropic 负责 Claude Code 的整体方向。标题里那句 “I use Fab…” 虽然被截断了但基本能看出来他在分享的是自己实际工作里的提效方案。一个负责 Claude Code 的人对外第一落点不是“我们的功能又多强”而是“我是怎么省 token 的、我是怎么用模型的”这件事本身就说明了很多——在真实的生产环境里成本和模型使用策略往往比功能列表更能决定一款工具能不能长期用下去。我一开始也觉得工具都上了那当然是用最贵的模型、给最多的上下文效果越好越值。但真跑起来才发现那是一种很奢侈的用法。尤其当 Claude Code 开始承担项目里越来越核心的任务时token 账单的增长速度会逼着你重新思考每一个使用习惯。1.2 终端编程代理和传统 AI 辅助工具有什么不同Claude Code 是 Anthropic 官方推出的命令行编程代理。它和你熟悉的“编辑器里补全代码”是两码事它能读取整个项目结构、定位相关文件、直接执行命令、跑测试看到报错后自己改代码再跑一遍验证结果。跟 Copilot 这类补全工具一比Claude Code 更像一个坐在你终端里的初级开发你把任务丢给它它自己走完读代码、改代码、验证的完整闭环。这也是它最近热度极高的原因。热度不只体现在 GitHub 的 star 数上更体现在周围那一圈生态上——Skills 技能机制、MCP 外部系统连接、第三方配置切换工具甚至有人专门写文章拿它和 Codex 做对比。在那么多终端编程工具里Claude Code 能跑出来靠的不只是模型本身强还有它对复杂多文件项目的理解能力以及对整个工具链的整合能力。1.3 到底适合谁来用我不是说所有人都需要换到 Claude Code。它适合的场景其实相对明确第一全职写代码、经常要在多个文件之间来回改的人第二接手的代码库很大、但你不可能通读所有代码的人第三愿意接受命令行工作流、不排斥把任务拆给 AI 去跑的人。如果你是那种只想要“AI 帮忙补几行”的轻量用户用编辑器自带的 AI 就够了没必要上终端编程代理。另外最近 “选 Codex 还是 Claude Code” 的讨论特别多。我的看法是它们的核心功能正在变得越来越接近真正的区别在生态。Claude Code 的 Skills、MCP、第三方集成更丰富Codex 在某些自动化流程上有自己的优势。选型的时候别只看谁热度高而要看你的项目是什么语言、团队怎么协作、你更习惯单品深度还是组合扩展。成本和模型策略在选型阶段就该一起想后面才不会被账单吓到。2. token 都花在哪了看清消耗的四个大头再说省钱2.1 token 到底是什么怎么计费的先补基础。token 是模型处理和生成文本的基本单位一个 token 大约对应 0.75 个英文单词中文场景下一个汉字差不多要 1 到 2 个 token。Claude Code 调用模型 API 时计费主要看两块输入 token 和输出 token。输入是你发给模型的全部内容包括指令、文件代码、历史对话输出是模型生成的回复。某些情况下还有缓存读写费用。很多人只盯着输出觉得模型回答越长越费钱。但从我实际观察来看真正的大头往往是输入而且是最容易被忽略的那部分输入。代码文件、搜索结果、命令的输出、历史对话全都会被折算成输入 token。稍微复杂一点的任务一次请求送出去几千甚至上万 token 是很正常的事而这些钱在屏幕上完全看不见等账单出来才会意识到用量有多大。2.2 输入上下文是最容易被忽视的无底洞我见过不少新手在 Claude Code 里一个会话从头聊到尾几个小时后每一次新请求都会携带前面全部对话的历史。假设你一开始粘了几百行代码进去后面又让它改了十几次那每次请求都要重新带上这些历史token 消耗不是线性增长而是像滚雪球一样越来越夸张。再加上 Claude Code 本身有个特征它会主动读取文件、执行命令把这些结果塞回上下文里。比如为了定位一个 bug它可能一口气读十几个相关文件这些文件的完整内容都会进入上下文。这部分开销你不主动留意根本感知不到等真正理解了消耗结构才会意识到长会话有多费钱。我自己做过一次实测在较长会话里历史对话加上文件读取的输入 token足足占了总输入量的七八成。2.3 一次典型会话的消耗构成我把一次完整的 bug 定位与修复会话拆开看了一下大致是这样的结构消耗来源占输入 token 比例说明项目上下文与 CLAUDE.md10%-15%每次请求都会携带精简后能明显下降历史对话消息40%-60%会话越长占比越高需要主动清理工具读取的文件内容20%-30%高频读取文件时膨胀速度最快命令执行输出与报错信息5%-10%取决于命令输出的长度和频率这个表格不是精确测算不同任务之间差异还挺大但它能说明一个结论历史对话和文件读取才是 token 消耗的大头输出只占零头。所以想省钱别盯着“让它少说几句话”而是要对着自己喂进去的上下文下手。你给模型的每一份材料都会变成账单上的一串数字关键是想清楚哪些必须给、哪些其实没必要。2.4 控制上下文膨胀的三个习惯我总结下来最有效的三个习惯都是围绕“别让上下文无限膨胀”展开的。第一小步提交一任务一会话。每完成一个明确的小任务就把成果 commit 掉然后开新会话继续下一件事。这比在同一个会话里不停说“继续”要省太多因为新会话不会背上旧会话的历史包袱。第二及时清理历史。Claude Code 有自动压缩机制但自动触发往往发生得太晚等你发现上下文已经膨胀里面早就混进了大量没用的中间过程。我的习惯是感觉到模型开始“忘事”、或者回答质量明显下降时直接 /compact 压缩历史如果任务切换跨度大干脆 /clear。第三精简 CLAUDE.md。项目说明文件每次请求都会带进上下文写得太长等于每一次请求都在为那些冗余内容买单。这个后面专门展开说。3. 模型选择是做减法Opus、Sonnet、Haiku 各管一段3.1 不同模型定位完全不同Claude Code 背后可以挂不同档次的模型Opus 系、Sonnet 系、Haiku 系。如果所有任务都用最强的那档成本会迅速失控反过来如果所有任务都用最便宜的遇到复杂问题就会反复翻车返工成本更高。正确的思路是按任务难度分层大型项目重构、长链路 bug 定位、系统设计方案生成这些高难度任务才值得上 Opus 那一档日常写功能、改测试、做小范围调整用 Sonnet 系列就够了速度和性价比都更好简单问答、格式化、加注释这种机械操作Haiku 系列完全能顶住。这里有个容易被忽略的点模型能力和任务错配时损失的不只是钱还有时间。用强模型处理琐碎任务响应慢且贵用弱模型处理复杂任务经常会给你一个表面看起来合理、实际经不起推敲的方案。合理的模型使用策略本身就应该是“让不同层级的模型承担各自最适合的那部分工作”。3.2 在 Claude Code 里怎么指定模型Claude Code 里切换模型有几种常用方式。最简单的是在交互界面里输入/model候选模型会列出来直接选就行。这种方式适合临时切换比如写代码写到一半遇到难题临时切到能力更强的模型。也可以通过环境变量设置默认模型比如把ANTHROPIC_MODEL指向你希望的主力档位。这个方式适合“平时固定用某一档遇到特殊任务再临时切”的节奏更稳定不会出现每次开会话都忘记选的尴尬。如果你是通过 API 方式接入的还可以在代码层面动态决定每一轮请求用哪个模型。自由度最高但代价是你得自己管好请求分发和成本账。我个人的配置习惯是默认模型设为 Sonnet 系列大部分日常任务都能高质量完成只有当任务明确涉及多文件大重构或者连续几轮排查都找不到根因时才手动切到 Opus 系列。3.3 我常用的任务-模型匹配表任务类型推荐模型理由多文件大范围重构Opus 系列需要全局理解低档模型容易改坏依赖关系日常业务功能开发Sonnet 系列速度与效果平衡成本可控测试用例补充Sonnet 系列需要理解代码逻辑但不需要极致推理格式化、补注释、改写Haiku 系列机械任务用高档次是纯浪费长时间排查复杂 bugOpus 系列推理链路长低档模型容易漏掉关键线索一开始我其实是一条规则走天下默认都让最高档模型处理。后来一个月账单出来就醒过来了。改成这种分层策略之后成本大概降了一半还多而实际开发体验几乎没打折扣因为真正费脑子的场景本来就不多大部分任务 Sonnet 就能扛住。3.4 为什么“最强模型做所有事”是伪命题很多人有这样一个错觉反正预算够全都用最强模型不就完了实际上模型越强单次调用的延迟和成本就越高而且有些简单任务用强模型未必更稳定反而可能出现“过度推断”——把一个简单问题想复杂给出多余的处理方案。这在小改动场景里特别明显本来只想格式化一段代码强模型却给你重构了一整块逻辑。所谓 model use本质是根据任务难度和失败成本来决定投入多少推理资源。这也是标题里 Boris Cherny 强调 model use 的原因。模型选择不是看哪个绝对更好而是看哪个更合适。钱要花在刀刃上推理能力也要花在刀刃上。4. 安装、登录、连接报错这些高频问题我都遇到过4.1 安装环节最容易踩的坑Claude Code 的官方安装方式是 npm 全局安装运行npm install -g anthropic-ai/claude-code。命令本身不复杂但有几个环境问题容易卡住。第一个是 Node.js 版本太旧。官方对版本有要求太旧了装不上或者装完以后行为异常。建议先node -v确认版本不符合要求就先升级。第二个是全局目录没有写入权限npm 装包时会报 EACCES 这类权限错误。这个问题在 macOS 和 Linux 上很常见用 nvm 管理 Node 环境的话一般能避开但如果是系统自带 Node就容易撞上。第三个是装完之后命令不在 PATH 里尤其 Windows 上容易出现“输入 claude 提示找不到命令”的情况需要确认安装目录有没有被加进环境变量。升级这件事也值得多说一句。Claude Code 迭代速度非常快很多奇怪的状态问题其实在下一个版本里就已经修复了。我遇到过几次莫名其妙的报错检查一圈发现是版本太旧跑一遍npm update -g anthropic-ai/claude-code再试就恢复正常。如果你用的版本已经超过一两周遇到诡异表现先把升级作为第一排查动作。4.2 认真对待 403登录与权限问题的排查链路最近热搜里一堆 “unable to connect to anthropic services” 和 “status 403”说明这个报错真的非常普遍。403 本质是服务端拒绝了请求但具体原因可以有很多。我这里整理一条我常用的排查链路按顺序走一遍基本能定位到问题先重新登录一次。终端里重新走一遍登录流程排除登录态过期的可能性。很多 403 都是由旧凭证引起的重登之后问题就消失了。再检查环境变量里是否设置了ANTHROPIC_API_KEY如果这个是旧的或无效的所有请求都会被拒更新或清掉它。接着确认账号本身有没有 Claude Code 的使用权限不是所有订阅方案都包含这个功能。最后考虑是不是暂时限流Claude Code 会对用量做限制如果提示里出现类似 “your limits are temporarily boosted” 或 “your weekly claude code limit is 50%”那就是额度层面的事不是代码问题。403 的报错文本本身非常模糊不会告诉你到底是哪一环出了问题。与其瞎试不如按顺序排查。我自己最常遇到的就是登录态过期重登一下就能解决。另外要留意地区可用性Claude Code 对使用地区有明确要求如果你的账号所在区域不在官方支持列表里连接请求就会被拒绝。4.3 其他高频报错的现场还原安装 IDE 插件时经常会看到 “failed to install anthropic marketplace”这个多半和网络访问、IDE 配置有关。重试几次或者手动下载插件包安装通常能解决。桌面版卡在登录账号界面的情况我也碰到过关掉进程重新打开才好。还有人说桌面版打开 PDF 总提示有密码这大概率不是 AI 的问题而是那个 PDF 本身设置了权限Claude Code 读取时没有权限解密换一个未加密的 PDF 源就能解决。另外想提醒一点很多“报错”其实不是错误而是额度提醒。比如 weekly Claude Code limit 的提示。如果频繁触顶说明你的使用强度已经超过了当前订阅方案的配额这时候该调整的是成本和使用策略而不是硬着头皮继续冲。5. 让模型“只做正事”CLAUDE.md 与会话管理的省钱细节5.1 CLAUDE.md 是 token 优化的第一道关卡CLAUDE.md 是放在项目根目录的说明文件Claude Code 每次开始工作都会把它读进上下文。很多人把它当成“给 AI 的备忘录”想到什么写什么一写就是几百行。但从 token 角度看每多一行都意味着每次请求多付一次费用。我的建议是只写那些模型自己推断不出来的东西项目用的包管理器是 npm 还是 pnpm、代码规范里没有被工具强制执行的约定、某些目录里藏着的踩坑记录。至于“这个项目是一个电商系统”这种从代码里一眼就能读出来的内容写了反而占用上下文。CLAUDE.md 越精简每次请求的固定开销就越低模型反而更容易抓住真正重要的项目约束。我在好几个项目里做过对照精简前和精简后同样的任务量token 消耗能差 10% 到 15%。这不是一笔小数目尤其是长期大量使用的时候。5.2 会话压缩该手动时就手动Claude Code 有自动压缩机制但自动触发通常发生在上下文已经膨胀到一定程度之后。等它自己触发的时候历史里早就混进了大量没用的中间过程——读过的旧文件、已经推翻的改法、重复出现的报错日志。更主动的做法是控制会话长度每完成一个可交付的子任务就想想接下来的工作还需要刚才全部上下文吗如果下一步是独立任务直接/clear完全没有问题如果还需要前面的结论用/compact把历史压缩留下关键信息丢掉过程噪音。我见过有人一个会话用一周每天往里加需求最后模型连最初的架构都快记不全了回答质量下滑但 token 还在不断燃烧。其实只要养成“换任务先清上下文”的习惯很多问题自然就消失了。这不只是省钱也是保持模型输出质量的重要手段。5.3 大需求拆小把一次巨型会话拆成多个独立会话真正能省大钱的是任务拆解。把一个全栈项目从零开始做如果放在同一个会话里从头聊到尾上下文里会堆积大量中间状态已经改过的旧版本代码、各种中间报错、一堆临时方案。这些东西最后都会变成 token 账单。我更推荐把项目拆成阶段先让 AI 生成项目结构和核心模块你验收、commit然后开一个新会话只告诉它当前项目的目标、上一阶段完成的内容以及这一阶段要做什么。每个独立会话只需要加载自己真正用到的上下文整体成本会低很多。这个思路听起来很朴素但实际做下来同规模项目的 token 消耗能差出两三倍。本质原因是多轮长会话的上下文膨胀是复利式的越到后面越贵而短会话每次都是从白纸开始没有历史包袱。6. 进阶整合Skills、MCP 与本地模型组合的真实体验6.1 Skills 机制让复杂流程可复用Claude Code 的 Skills 机制简单说就是把一套操作流程封装成可复用的技能。比如团队约定的代码审查流程、发布检查清单、某个框架的排错手册都可以写成 Skill。好处有两点一个是流程标准化每次执行都有稳定步骤不会因为模型的随机性而跑偏另一个是注意力集中Skill 加载后模型只围绕这个流程工作不会发散到无关上下文对 token 消耗也是正向影响。我自己写了一个代码审查的 Skill 之后每次让 Claude Code 做 review 都会先加载技能再传入具体的改动范围。对比之前直接在对话里描述流程token 开销少了输出质量也更稳定。Skill 的价值不是“炫技”而是把每一次任务都拉回到既定的框架里减少无效试错。6.2 MCP 连接外部系统时的取舍MCP 让 Claude Code 能连数据库、外部 API、内部工具实用性很强。但从 token 优化的角度我的建议是别把所有 MCP 服务器都挂上去。每个 MCP 服务器的工具描述和参数 schema 都会进入上下文挂得越多每次请求的固定 token 开销就越大。只挂当前任务真正需要的用到的时候再启用这样最稳妥。比如你想让它直接查数据库来定位问题可以专门配一个数据库 MCP用完就关掉。把 MCP 当成按需加载的插件而不是常驻服务能在成本和灵活性之间找到更好的平衡点。这个道理和 CLAUDE.md 一样上下文里的每一件东西都要为它的存在付出代价。6.3 接入 Ollama、DeepSeek 等模型时的成本权衡社区里已经有不少人用 Claude Code 搭配本地模型比如 Ollama或者接入 DeepSeek 等其他提供方核心诉求基本都是控制成本。本地模型的优势在私密性和按需使用DeepSeek 这类服务价格也有明显优势用第三方切换工具换 provider 也非常方便。但我必须提醒一句模型切换不是没有代价的。Claude Code 的高级能力比如复杂代码库的工程理解、工具调用的稳定性、长链路推理和模型本身的能力高度相关。便宜的模型能完成简单任务但在复杂重构场景里返工成本可能反而更高。我的做法是“混用”关键任务继续走官方模型链路确保输出质量格式化、重命名、补注释这类低风险工作落到本地或第三方模型上。这样省钱和质量两头都能照顾到。6.4 全栈项目稳定交付的个人实践社区里最近流传一个说法叫 “Claude Code OpenSpec Superpowers 三件套”核心思路是用规范化的需求描述、项目规范和可复用的技能模板让 AI 更稳定地交付全栈项目。我实际跟了一段时间体会是规范化确实能提升交付稳定性。OpenSpec 负责把需求写清楚Superpowers 提供一套技能模板Claude Code 执行具体开发。本质上这还是在做同一件事——让模型在更明确的上下文里工作减少无效输出控制总体成本。如果你是做偏长期、多阶段的全栈项目这套思路值得试。但不要照搬所有模板先挑一两个环节跑起来确认有效再扩展。规范化是手段不是目的最终目标永远是更高质量、更低成本地完成项目。最后说一个我自己的体会token 优化不是设某个开关就能一劳永逸的事它更像持续的习惯。我现在每次开新会话之前都会先想三个问题这个任务需要哪些前提信息哪些旧对话可以不再用了当前模型的档次和任务难度匹配吗想清楚再开始token 消耗会自然降下来。Claude Code 的能力边界还在不断扩展但无论它以后加多少功能成本意识都得自己心里有数。希望这篇能帮你在用 Claude Code 的路上少走点弯路省下该省的钱。
Claude Code token优化实战：模型选择与上下文管理
前两天我在技术社区翻到一条分享标题写的是 “Boris Cherny, head of Claude Code at Anthropic, on optimizing token cost and model use. I use Fab…”。后半句被截断了看不出那个 Fab 具体指什么但光是前小半句就已经很戳人连 Claude Code 的负责人都在公开聊 token 成本和模型使用策略。我过去大半年几乎天天用 Claude Code 干活从写新功能、做老项目重构到追一些藏得很深的 bug花的 token 一度多到肉疼。后来慢慢摸出一些门道今天就把这件事彻底拆开讲清楚token 到底花哪了、模型该怎么挑、有哪些细节能实实在在省钱顺便把安装和使用里我踩过的坑也一并列出来。如果你刚开始接触 Claude Code或者用了挺久但对成本一直没什么概念这篇应该都能帮上忙。1. 聊 Claude Code 之前得先知道它为什么这么火1.1 Boris Cherny 和 Claude Code 的关系Boris Cherny 这名字在 TypeScript 圈子里不算陌生写过那本《Programming TypeScript》现在在 Anthropic 负责 Claude Code 的整体方向。标题里那句 “I use Fab…” 虽然被截断了但基本能看出来他在分享的是自己实际工作里的提效方案。一个负责 Claude Code 的人对外第一落点不是“我们的功能又多强”而是“我是怎么省 token 的、我是怎么用模型的”这件事本身就说明了很多——在真实的生产环境里成本和模型使用策略往往比功能列表更能决定一款工具能不能长期用下去。我一开始也觉得工具都上了那当然是用最贵的模型、给最多的上下文效果越好越值。但真跑起来才发现那是一种很奢侈的用法。尤其当 Claude Code 开始承担项目里越来越核心的任务时token 账单的增长速度会逼着你重新思考每一个使用习惯。1.2 终端编程代理和传统 AI 辅助工具有什么不同Claude Code 是 Anthropic 官方推出的命令行编程代理。它和你熟悉的“编辑器里补全代码”是两码事它能读取整个项目结构、定位相关文件、直接执行命令、跑测试看到报错后自己改代码再跑一遍验证结果。跟 Copilot 这类补全工具一比Claude Code 更像一个坐在你终端里的初级开发你把任务丢给它它自己走完读代码、改代码、验证的完整闭环。这也是它最近热度极高的原因。热度不只体现在 GitHub 的 star 数上更体现在周围那一圈生态上——Skills 技能机制、MCP 外部系统连接、第三方配置切换工具甚至有人专门写文章拿它和 Codex 做对比。在那么多终端编程工具里Claude Code 能跑出来靠的不只是模型本身强还有它对复杂多文件项目的理解能力以及对整个工具链的整合能力。1.3 到底适合谁来用我不是说所有人都需要换到 Claude Code。它适合的场景其实相对明确第一全职写代码、经常要在多个文件之间来回改的人第二接手的代码库很大、但你不可能通读所有代码的人第三愿意接受命令行工作流、不排斥把任务拆给 AI 去跑的人。如果你是那种只想要“AI 帮忙补几行”的轻量用户用编辑器自带的 AI 就够了没必要上终端编程代理。另外最近 “选 Codex 还是 Claude Code” 的讨论特别多。我的看法是它们的核心功能正在变得越来越接近真正的区别在生态。Claude Code 的 Skills、MCP、第三方集成更丰富Codex 在某些自动化流程上有自己的优势。选型的时候别只看谁热度高而要看你的项目是什么语言、团队怎么协作、你更习惯单品深度还是组合扩展。成本和模型策略在选型阶段就该一起想后面才不会被账单吓到。2. token 都花在哪了看清消耗的四个大头再说省钱2.1 token 到底是什么怎么计费的先补基础。token 是模型处理和生成文本的基本单位一个 token 大约对应 0.75 个英文单词中文场景下一个汉字差不多要 1 到 2 个 token。Claude Code 调用模型 API 时计费主要看两块输入 token 和输出 token。输入是你发给模型的全部内容包括指令、文件代码、历史对话输出是模型生成的回复。某些情况下还有缓存读写费用。很多人只盯着输出觉得模型回答越长越费钱。但从我实际观察来看真正的大头往往是输入而且是最容易被忽略的那部分输入。代码文件、搜索结果、命令的输出、历史对话全都会被折算成输入 token。稍微复杂一点的任务一次请求送出去几千甚至上万 token 是很正常的事而这些钱在屏幕上完全看不见等账单出来才会意识到用量有多大。2.2 输入上下文是最容易被忽视的无底洞我见过不少新手在 Claude Code 里一个会话从头聊到尾几个小时后每一次新请求都会携带前面全部对话的历史。假设你一开始粘了几百行代码进去后面又让它改了十几次那每次请求都要重新带上这些历史token 消耗不是线性增长而是像滚雪球一样越来越夸张。再加上 Claude Code 本身有个特征它会主动读取文件、执行命令把这些结果塞回上下文里。比如为了定位一个 bug它可能一口气读十几个相关文件这些文件的完整内容都会进入上下文。这部分开销你不主动留意根本感知不到等真正理解了消耗结构才会意识到长会话有多费钱。我自己做过一次实测在较长会话里历史对话加上文件读取的输入 token足足占了总输入量的七八成。2.3 一次典型会话的消耗构成我把一次完整的 bug 定位与修复会话拆开看了一下大致是这样的结构消耗来源占输入 token 比例说明项目上下文与 CLAUDE.md10%-15%每次请求都会携带精简后能明显下降历史对话消息40%-60%会话越长占比越高需要主动清理工具读取的文件内容20%-30%高频读取文件时膨胀速度最快命令执行输出与报错信息5%-10%取决于命令输出的长度和频率这个表格不是精确测算不同任务之间差异还挺大但它能说明一个结论历史对话和文件读取才是 token 消耗的大头输出只占零头。所以想省钱别盯着“让它少说几句话”而是要对着自己喂进去的上下文下手。你给模型的每一份材料都会变成账单上的一串数字关键是想清楚哪些必须给、哪些其实没必要。2.4 控制上下文膨胀的三个习惯我总结下来最有效的三个习惯都是围绕“别让上下文无限膨胀”展开的。第一小步提交一任务一会话。每完成一个明确的小任务就把成果 commit 掉然后开新会话继续下一件事。这比在同一个会话里不停说“继续”要省太多因为新会话不会背上旧会话的历史包袱。第二及时清理历史。Claude Code 有自动压缩机制但自动触发往往发生得太晚等你发现上下文已经膨胀里面早就混进了大量没用的中间过程。我的习惯是感觉到模型开始“忘事”、或者回答质量明显下降时直接 /compact 压缩历史如果任务切换跨度大干脆 /clear。第三精简 CLAUDE.md。项目说明文件每次请求都会带进上下文写得太长等于每一次请求都在为那些冗余内容买单。这个后面专门展开说。3. 模型选择是做减法Opus、Sonnet、Haiku 各管一段3.1 不同模型定位完全不同Claude Code 背后可以挂不同档次的模型Opus 系、Sonnet 系、Haiku 系。如果所有任务都用最强的那档成本会迅速失控反过来如果所有任务都用最便宜的遇到复杂问题就会反复翻车返工成本更高。正确的思路是按任务难度分层大型项目重构、长链路 bug 定位、系统设计方案生成这些高难度任务才值得上 Opus 那一档日常写功能、改测试、做小范围调整用 Sonnet 系列就够了速度和性价比都更好简单问答、格式化、加注释这种机械操作Haiku 系列完全能顶住。这里有个容易被忽略的点模型能力和任务错配时损失的不只是钱还有时间。用强模型处理琐碎任务响应慢且贵用弱模型处理复杂任务经常会给你一个表面看起来合理、实际经不起推敲的方案。合理的模型使用策略本身就应该是“让不同层级的模型承担各自最适合的那部分工作”。3.2 在 Claude Code 里怎么指定模型Claude Code 里切换模型有几种常用方式。最简单的是在交互界面里输入/model候选模型会列出来直接选就行。这种方式适合临时切换比如写代码写到一半遇到难题临时切到能力更强的模型。也可以通过环境变量设置默认模型比如把ANTHROPIC_MODEL指向你希望的主力档位。这个方式适合“平时固定用某一档遇到特殊任务再临时切”的节奏更稳定不会出现每次开会话都忘记选的尴尬。如果你是通过 API 方式接入的还可以在代码层面动态决定每一轮请求用哪个模型。自由度最高但代价是你得自己管好请求分发和成本账。我个人的配置习惯是默认模型设为 Sonnet 系列大部分日常任务都能高质量完成只有当任务明确涉及多文件大重构或者连续几轮排查都找不到根因时才手动切到 Opus 系列。3.3 我常用的任务-模型匹配表任务类型推荐模型理由多文件大范围重构Opus 系列需要全局理解低档模型容易改坏依赖关系日常业务功能开发Sonnet 系列速度与效果平衡成本可控测试用例补充Sonnet 系列需要理解代码逻辑但不需要极致推理格式化、补注释、改写Haiku 系列机械任务用高档次是纯浪费长时间排查复杂 bugOpus 系列推理链路长低档模型容易漏掉关键线索一开始我其实是一条规则走天下默认都让最高档模型处理。后来一个月账单出来就醒过来了。改成这种分层策略之后成本大概降了一半还多而实际开发体验几乎没打折扣因为真正费脑子的场景本来就不多大部分任务 Sonnet 就能扛住。3.4 为什么“最强模型做所有事”是伪命题很多人有这样一个错觉反正预算够全都用最强模型不就完了实际上模型越强单次调用的延迟和成本就越高而且有些简单任务用强模型未必更稳定反而可能出现“过度推断”——把一个简单问题想复杂给出多余的处理方案。这在小改动场景里特别明显本来只想格式化一段代码强模型却给你重构了一整块逻辑。所谓 model use本质是根据任务难度和失败成本来决定投入多少推理资源。这也是标题里 Boris Cherny 强调 model use 的原因。模型选择不是看哪个绝对更好而是看哪个更合适。钱要花在刀刃上推理能力也要花在刀刃上。4. 安装、登录、连接报错这些高频问题我都遇到过4.1 安装环节最容易踩的坑Claude Code 的官方安装方式是 npm 全局安装运行npm install -g anthropic-ai/claude-code。命令本身不复杂但有几个环境问题容易卡住。第一个是 Node.js 版本太旧。官方对版本有要求太旧了装不上或者装完以后行为异常。建议先node -v确认版本不符合要求就先升级。第二个是全局目录没有写入权限npm 装包时会报 EACCES 这类权限错误。这个问题在 macOS 和 Linux 上很常见用 nvm 管理 Node 环境的话一般能避开但如果是系统自带 Node就容易撞上。第三个是装完之后命令不在 PATH 里尤其 Windows 上容易出现“输入 claude 提示找不到命令”的情况需要确认安装目录有没有被加进环境变量。升级这件事也值得多说一句。Claude Code 迭代速度非常快很多奇怪的状态问题其实在下一个版本里就已经修复了。我遇到过几次莫名其妙的报错检查一圈发现是版本太旧跑一遍npm update -g anthropic-ai/claude-code再试就恢复正常。如果你用的版本已经超过一两周遇到诡异表现先把升级作为第一排查动作。4.2 认真对待 403登录与权限问题的排查链路最近热搜里一堆 “unable to connect to anthropic services” 和 “status 403”说明这个报错真的非常普遍。403 本质是服务端拒绝了请求但具体原因可以有很多。我这里整理一条我常用的排查链路按顺序走一遍基本能定位到问题先重新登录一次。终端里重新走一遍登录流程排除登录态过期的可能性。很多 403 都是由旧凭证引起的重登之后问题就消失了。再检查环境变量里是否设置了ANTHROPIC_API_KEY如果这个是旧的或无效的所有请求都会被拒更新或清掉它。接着确认账号本身有没有 Claude Code 的使用权限不是所有订阅方案都包含这个功能。最后考虑是不是暂时限流Claude Code 会对用量做限制如果提示里出现类似 “your limits are temporarily boosted” 或 “your weekly claude code limit is 50%”那就是额度层面的事不是代码问题。403 的报错文本本身非常模糊不会告诉你到底是哪一环出了问题。与其瞎试不如按顺序排查。我自己最常遇到的就是登录态过期重登一下就能解决。另外要留意地区可用性Claude Code 对使用地区有明确要求如果你的账号所在区域不在官方支持列表里连接请求就会被拒绝。4.3 其他高频报错的现场还原安装 IDE 插件时经常会看到 “failed to install anthropic marketplace”这个多半和网络访问、IDE 配置有关。重试几次或者手动下载插件包安装通常能解决。桌面版卡在登录账号界面的情况我也碰到过关掉进程重新打开才好。还有人说桌面版打开 PDF 总提示有密码这大概率不是 AI 的问题而是那个 PDF 本身设置了权限Claude Code 读取时没有权限解密换一个未加密的 PDF 源就能解决。另外想提醒一点很多“报错”其实不是错误而是额度提醒。比如 weekly Claude Code limit 的提示。如果频繁触顶说明你的使用强度已经超过了当前订阅方案的配额这时候该调整的是成本和使用策略而不是硬着头皮继续冲。5. 让模型“只做正事”CLAUDE.md 与会话管理的省钱细节5.1 CLAUDE.md 是 token 优化的第一道关卡CLAUDE.md 是放在项目根目录的说明文件Claude Code 每次开始工作都会把它读进上下文。很多人把它当成“给 AI 的备忘录”想到什么写什么一写就是几百行。但从 token 角度看每多一行都意味着每次请求多付一次费用。我的建议是只写那些模型自己推断不出来的东西项目用的包管理器是 npm 还是 pnpm、代码规范里没有被工具强制执行的约定、某些目录里藏着的踩坑记录。至于“这个项目是一个电商系统”这种从代码里一眼就能读出来的内容写了反而占用上下文。CLAUDE.md 越精简每次请求的固定开销就越低模型反而更容易抓住真正重要的项目约束。我在好几个项目里做过对照精简前和精简后同样的任务量token 消耗能差 10% 到 15%。这不是一笔小数目尤其是长期大量使用的时候。5.2 会话压缩该手动时就手动Claude Code 有自动压缩机制但自动触发通常发生在上下文已经膨胀到一定程度之后。等它自己触发的时候历史里早就混进了大量没用的中间过程——读过的旧文件、已经推翻的改法、重复出现的报错日志。更主动的做法是控制会话长度每完成一个可交付的子任务就想想接下来的工作还需要刚才全部上下文吗如果下一步是独立任务直接/clear完全没有问题如果还需要前面的结论用/compact把历史压缩留下关键信息丢掉过程噪音。我见过有人一个会话用一周每天往里加需求最后模型连最初的架构都快记不全了回答质量下滑但 token 还在不断燃烧。其实只要养成“换任务先清上下文”的习惯很多问题自然就消失了。这不只是省钱也是保持模型输出质量的重要手段。5.3 大需求拆小把一次巨型会话拆成多个独立会话真正能省大钱的是任务拆解。把一个全栈项目从零开始做如果放在同一个会话里从头聊到尾上下文里会堆积大量中间状态已经改过的旧版本代码、各种中间报错、一堆临时方案。这些东西最后都会变成 token 账单。我更推荐把项目拆成阶段先让 AI 生成项目结构和核心模块你验收、commit然后开一个新会话只告诉它当前项目的目标、上一阶段完成的内容以及这一阶段要做什么。每个独立会话只需要加载自己真正用到的上下文整体成本会低很多。这个思路听起来很朴素但实际做下来同规模项目的 token 消耗能差出两三倍。本质原因是多轮长会话的上下文膨胀是复利式的越到后面越贵而短会话每次都是从白纸开始没有历史包袱。6. 进阶整合Skills、MCP 与本地模型组合的真实体验6.1 Skills 机制让复杂流程可复用Claude Code 的 Skills 机制简单说就是把一套操作流程封装成可复用的技能。比如团队约定的代码审查流程、发布检查清单、某个框架的排错手册都可以写成 Skill。好处有两点一个是流程标准化每次执行都有稳定步骤不会因为模型的随机性而跑偏另一个是注意力集中Skill 加载后模型只围绕这个流程工作不会发散到无关上下文对 token 消耗也是正向影响。我自己写了一个代码审查的 Skill 之后每次让 Claude Code 做 review 都会先加载技能再传入具体的改动范围。对比之前直接在对话里描述流程token 开销少了输出质量也更稳定。Skill 的价值不是“炫技”而是把每一次任务都拉回到既定的框架里减少无效试错。6.2 MCP 连接外部系统时的取舍MCP 让 Claude Code 能连数据库、外部 API、内部工具实用性很强。但从 token 优化的角度我的建议是别把所有 MCP 服务器都挂上去。每个 MCP 服务器的工具描述和参数 schema 都会进入上下文挂得越多每次请求的固定 token 开销就越大。只挂当前任务真正需要的用到的时候再启用这样最稳妥。比如你想让它直接查数据库来定位问题可以专门配一个数据库 MCP用完就关掉。把 MCP 当成按需加载的插件而不是常驻服务能在成本和灵活性之间找到更好的平衡点。这个道理和 CLAUDE.md 一样上下文里的每一件东西都要为它的存在付出代价。6.3 接入 Ollama、DeepSeek 等模型时的成本权衡社区里已经有不少人用 Claude Code 搭配本地模型比如 Ollama或者接入 DeepSeek 等其他提供方核心诉求基本都是控制成本。本地模型的优势在私密性和按需使用DeepSeek 这类服务价格也有明显优势用第三方切换工具换 provider 也非常方便。但我必须提醒一句模型切换不是没有代价的。Claude Code 的高级能力比如复杂代码库的工程理解、工具调用的稳定性、长链路推理和模型本身的能力高度相关。便宜的模型能完成简单任务但在复杂重构场景里返工成本可能反而更高。我的做法是“混用”关键任务继续走官方模型链路确保输出质量格式化、重命名、补注释这类低风险工作落到本地或第三方模型上。这样省钱和质量两头都能照顾到。6.4 全栈项目稳定交付的个人实践社区里最近流传一个说法叫 “Claude Code OpenSpec Superpowers 三件套”核心思路是用规范化的需求描述、项目规范和可复用的技能模板让 AI 更稳定地交付全栈项目。我实际跟了一段时间体会是规范化确实能提升交付稳定性。OpenSpec 负责把需求写清楚Superpowers 提供一套技能模板Claude Code 执行具体开发。本质上这还是在做同一件事——让模型在更明确的上下文里工作减少无效输出控制总体成本。如果你是做偏长期、多阶段的全栈项目这套思路值得试。但不要照搬所有模板先挑一两个环节跑起来确认有效再扩展。规范化是手段不是目的最终目标永远是更高质量、更低成本地完成项目。最后说一个我自己的体会token 优化不是设某个开关就能一劳永逸的事它更像持续的习惯。我现在每次开新会话之前都会先想三个问题这个任务需要哪些前提信息哪些旧对话可以不再用了当前模型的档次和任务难度匹配吗想清楚再开始token 消耗会自然降下来。Claude Code 的能力边界还在不断扩展但无论它以后加多少功能成本意识都得自己心里有数。希望这篇能帮你在用 Claude Code 的路上少走点弯路省下该省的钱。
