企业官网建设流程全解析

1. 先搞清楚 tokens 到底被谁吃掉了

很多人用 Claude Code 写着写着发现额度掉得飞快，第一反应是「模型太贵」，其实大部分消耗跟你的提问质量没关系，而是上下文在反复重发。Claude Code 每一轮对话都会把历史消息、系统提示、工具定义、项目文件一起打包发给模型，你问的越久，这个包越大。

我实测过一个很典型的场景：清空上下文后什么都不干，先跑一次/context，能看到基础开销大概在 19k tokens 左右，其中system tools这一项就占了 15.5k。也就是说你还没开始干活，光是把工具定义塞进去就已经花掉一大截。接着随便发一句hello，再跑/context，数字涨到 24k 上下，真正属于「打招呼」的增量大约是 2.9k。

这个数字说明两件事：一是固定开销躲不掉，工具定义和系统提示是 Claude Code 的底座；二是可变开销才是你能控制的，也就是历史对话、项目文件读取、重复的上下文。省钱的核心思路不是砍固定开销，而是让可变开销别失控。

这篇就围绕三个入口来讲：settings.json的环境变量配置、CLAUDE.md的项目记忆、以及/compact的压缩时机。目标很明确——让每一轮请求带上去的 tokens 都是「有用的」，而不是把整个项目历史反复搬运。

适合谁看：已经在用 Claude Code 做日常开发、发现额度消耗比预期快、想在不降低体验的前提下把 tokens 花在刀刃上的同学。如果你还没配好接入环境，后面第二节会给一个可复制的骨架。

2. 接入前置：把 settings.json 和 API 环境搭好

Claude Code 的配置分两层：一层是接入层，决定请求发到哪里、用哪个模型；另一层是行为层，决定它怎么读项目、怎么压缩上下文。两层都写在settings.json里。

配置文件位置按系统区分：

• Linux / macOS：~/.claude/settings.json
• Windows：C:/Users/你的用户名/.claude/settings.json

如果目录不存在，手动建一个.claude文件夹再放settings.json即可。接入层需要一个可用的 API 端点和 Key，我用的是 TaoToken 的接口，它的地址和 Key 管理入口在控制台里能直接拿到，配置时把ANTHROPIC_BASE_URL指向https://taotoken.net/api，ANTHROPIC_AUTH_TOKEN填你自己的 Key。

这里有个容易踩的坑：ANTHROPIC_BASE_URL不要带多余的路径后缀，直接写域名加/api就行，带错了会出现 404 或者握手失败。Key 的获取和模型列表可以在控制台里核对，确认你要用的模型名拼写正确，模型名写错不会报「模型不存在」，而是静默回退到默认模型，你会以为配置生效了其实没有。

行为层的关键变量有两个：

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC设为1，作用是关掉非必要的后台通信。类比一下就是浏览器的 cookies，很多请求你根本没主动发起，但它在后台悄悄跑，关掉之后能省掉一部分隐性开销。

MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES设为3，意思是自动压缩连续失败 3 次就停止重试。这个变量是防止压缩逻辑卡死时无限重试，反而把 tokens 烧光。设成 3 是个比较稳的值，太小容易误停，太大等于没限制。

把这两层配好之后，Claude Code 每次启动读的就是你这份配置，而不是默认值。下一步再谈怎么让它在项目里少读无用文件。

3. 可复制配置：settings.json 骨架与 CLAUDE.md 写法

先给一份可以直接改的settings.json骨架。注意 JSON 不支持注释，下面用引用块单独说明每个字段，实际文件里把注释删掉。

{ "autoUpdatesChannel": "latest", "env": { "ANTHROPIC_AUTH_TOKEN": "你的API_KEY", "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "你的轻量模型名", "ANTHROPIC_DEFAULT_SONNET_MODEL": "你的主力模型名", "ANTHROPIC_DEFAULT_OPUS_MODEL": "你的高配模型名", "ANTHROPIC_MODEL": "你的默认模型名", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1" }, "MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES": "3", "model": "你的默认模型名" }

注意：ANTHROPIC_DEFAULT_HAIKU_MODEL这类变量是给不同档位任务用的，轻量任务走 Haiku 档、复杂推理走 Opus 档，分档配置能避免所有请求都走高配模型。模型名以你控制台里实际可用的为准，别照抄示例里的占位符。

配好接入层之后，真正决定「每轮读多少项目内容」的是CLAUDE.md。它的作用是给 Claude Code 一份项目说明书，让它进项目时直接读这份摘要，而不是每次重新扫描整个代码库。

CLAUDE.md放在项目根目录，写法上要克制，别把整个 README 复制进去。它应该只包含三类信息：项目结构的关键路径、常用命令、以及你希望它遵守的约定。给一个骨架：

# 项目说明 ## 技术栈 - 前端：React + Vite - 后端：Node.js + Express - 数据库：PostgreSQL ## 关键目录 - src/components：UI 组件 - src/api：接口封装 - server/routes：后端路由 ## 常用命令 - 启动开发：npm run dev - 跑测试：npm test - 构建：npm run build ## 约定 - 组件用函数式写法，不用 class - 接口请求统一走 src/api/request.js - 提交前必须跑 lint

这份文件控制在 50 行以内比较理想。写太长等于每轮都多带一份文档，反而增加固定开销。它的价值在于替代重复扫描，而不是替代文档。

还有一个容易被忽略的点：不同项目维护各自的CLAUDE.md和.claude文件夹。项目 A 需要的 skills 和 MCP 配置，没必要让项目 B 也加载。如果两个项目共用同一套配置，那就把它提到全局的~/.claude里维护，而不是在每个项目里重复一份。这就是「专项专立」的意思——按项目隔离，公共部分上提。

4. 验证请求：用 /context 和 /compact 看效果

配置写完不算完，得验证它真的生效了。Claude Code 里有两个命令特别有用：/context和/compact。

先验证基础开销。打开 Claude Code，先执行/clear清空上下文，然后跑/context。你会看到一份分项列表，类似这样：

System prompt: 2.4k System tools: 15.5k Messages: 1.2k Free space: 286 Total: 19.3k

这个数字就是你的「地板价」，什么都不干也要花这么多。接着发一句hello，再跑/context，看 Messages 那一项涨了多少。如果涨得很少（几百 tokens），说明你的配置没在后台乱拉东西；如果一次涨好几千，就要回头检查是不是有插件或者 MCP 在偷偷加载。

再验证CLAUDE.md的效果。进项目后问一个跟项目结构相关的问题，比如「这个项目的接口封装在哪个目录」，观察它是不是直接答出来而不是先扫描一遍。如果它开始列目录、读一堆文件才回答，说明CLAUDE.md没被读到，检查文件名拼写和位置。

/compact的验证更直接。做一段连续相关的开发，比如先让它实现功能 A，再基于 A 实现功能 B，两轮之后跑/context看 Messages 有多大。然后执行/compact，再跑一次/context，Messages 会明显缩小，因为历史被提炼成了摘要。

压缩前 Messages: 48.2k 执行 /compact 压缩后 Messages: 12.6k

这个对比就是/compact的价值。它适合上下文强相关的连续任务，比如同一个功能的多个子步骤。如果两轮任务根本不相干，用/clear更干脆，直接归零。

判断用哪个的简单规则：新任务和旧任务有没有依赖关系？有依赖用/compact，没依赖用/clear。别在无关任务之间硬扛着不清理，那是最烧 tokens 的用法。

5. 本篇常见错排查

配置和命令都给了，实际用起来还是会遇到一些具体报错。下面几个是我和身边人踩过的。

报错一：settings.json 改了没生效。最常见的原因是 JSON 格式错误，比如多了一个逗号、少了引号。Claude Code 读配置失败时不一定报错，可能直接回退默认值。排查方法：用cat ~/.claude/settings.json | python -m json.tool校验格式，能解析通过才说明语法没问题。另外确认你改的是当前用户目录下的配置，不是项目里的。

报错二：请求返回 401 或握手失败。检查ANTHROPIC_AUTH_TOKEN有没有多余空格，Key 是否过期。ANTHROPIC_BASE_URL确认是https://taotoken.net/api，不要带尾部斜杠或者多余路径。如果还是失败，去控制台确认 Key 的权限和额度状态。

报错三：模型名写错但没报错。前面提过，模型名拼错会静默回退。验证方法是跑一次请求后看返回的模型标识，或者直接在配置里用一个明显不存在的名字，看它是不是还正常返回——如果正常返回，说明它根本没在用你写的名字。

报错四：/compact 之后上下文还是很大。压缩不是万能的，如果单轮消息本身就特别长（比如你贴了一整个大文件进去），压缩后的摘要也会偏大。这种情况应该先/clear，然后重新提问时只贴必要的代码片段，而不是整个文件。

报错五：CLAUDE.md 被忽略。确认文件名大小写完全一致，必须是CLAUDE.md全大写。放在项目根目录，不要放在子目录。如果项目有多个根（比如 monorepo），每个子项目根目录各放一份。

报错六：tokens 消耗突然暴涨。先跑/context看是哪一项涨了。如果是 System tools 涨了，可能是装了新的插件或 MCP；如果是 Messages 涨了，说明历史太长该压缩或清理了。定位到具体项再处理，别盲目清空。

6. 把 tokens 花在刀刃上的长期做法

省 tokens 不是靠某一个开关，而是靠一套习惯。配置层用settings.json关掉非必要通信、分档配模型；项目层用CLAUDE.md替代重复扫描、按项目隔离配置；会话层用/clear和/compact控制上下文体积。三层配合，才能让每一轮请求带上去的都是有效信息。

如果你还在搭接入环境，建议先把 API Key 和接入文档过一遍，把settings.json的骨架跑通，再谈优化。Key 管理和模型列表在控制台里能直接看到，接入文档里有完整的变量说明。

日常编码和 Agent 类任务如果跑得比较多，可以看看 Coding Plan 这类长期方案，比按次调用更划算。想先验证模型效果、确认配置对不对，用模型对话快速试一轮最省事。

真正稳定的体验来自「知道钱花在哪」。每次觉得消耗异常，先跑/context定位，再决定是清空、压缩还是改配置。这个习惯养成之后，你会发现同样的额度能撑更久，而且回答质量不会下降——因为省掉的都是无效上下文，留下的都是真正有用的信息。