1. 长会话里 Token 是怎么被“废话”吃掉的
如果你用 Claude Code 写过半小时以上的连续任务，大概率见过这种场面：让它修一个 React 重渲染的 bug，它先来一段“让我分析一下这个问题的根源”，再补一句“首先我们需要理解组件生命周期”，最后才给出三行关键代码。问题解决了，但账单上多了一千多 Token。单次看不心疼，一天几十轮下来，月底看用量统计就开始肉疼。
这就是 Caveman 这个项目能在一周内冲上 GitHub Trending 前排的原因。它的标语很直白——“why use many token when few do trick”，翻译成人话就是：能用几个 Token 说清的事，别用一大段。它做的事情不复杂，让 Claude Code、Codex、Cursor、Cline 这类 AI 智能体的输出变得像穴居人说话一样短：丢掉铺垫、丢掉客套、丢掉“我理解你的困惑”，只留代码、命令、错误信息和结论。技术精度不变，代码逐字节保留，砍掉的全是沟通冗余。
我实测过几个典型场景，差距确实明显。解释一个 React 重渲染 Bug，正常模式输出约 1180 Token，压缩后 159 Token；修认证中间件从 704 降到 121；配 PG 连接池从 2347 降到 380。平均下来输出 Token 省 65% 左右。注意这里省的是输出端，不是输入端——很多 Token 优化工具改的是 Prompt 压缩，而 Caveman 动的是智能体“说话的方式”。
对国内开发者来说这件事更值得关注。长上下文、高并发的编码场景下，Token 消耗是一笔沉默的固定支出。而 Caveman 的思路可以拆成两层：一层是 Prompt Engineering 层面的“极简输出约束”，另一层是通道层面的统一接入与计量。前者决定智能体少说废话，后者决定你花的每一分钱都算得清、管得住。这篇就按这两层来写，先讲清楚 Caveman 的极简哲学怎么落地，再给出可复制的settings.json和config.toml配置骨架，用 TaoToken 统一 Key 和 API 通道接入 Claude Code，最后演示怎么验证 Token 节省效果。
适合谁看：正在用 Claude Code / Codex / Cline 做长期编码任务的开发者；被长会话 Token 账单困扰、想在不降级模型的前提下压成本的人；以及想搞明白“极简 Prompt Engineering”到底怎么写成配置、而不是停留在概念的人。下面所有配置都可以直接抄，路径和字段名保持一致，改完重启就能生效。
2. Caveman 极简哲学与 TaoToken 通道前置准备
先把 Caveman 的技术骨架讲清楚，不然配置抄了也不知道在改什么。它的方案是三层结构，理解这三层，你就能自己判断哪些配置该留、哪些该删。
第一层是系统提示注入。安装时向智能体写入一条 Caveman 提示，核心指令就几句话：丢掉填充词，保持代码原样，用片段替代句子。不需要微调，不需要额外推理，本质是一条强约束的 system prompt。
第二层是会话钩子。在 Claude Code 上，一个本地钩子在每次会话开始时写入标记文件，让智能体从第一条消息就自动进入 Caveman 模式，不用每次手敲/caveman。这一层解决的是“忘记开启”的问题。
第三层是记忆压缩。/caveman-compress命令可以重写CLAUDE.md这类记忆文件，把输入 Token 削减约 46%，而且效果是永久的——每个未来会话都从更小的上下文开始。这一层容易被忽略，但长会话里输入 Token 的累积很可观。
它还有六档输出等级，从 Lite 到 Ultra 再到 Wenyan。Lite 轻量压缩，保留大部分语法结构；Full 是默认档，省 65%；Ultra 极致压缩，几乎只剩关键信息；Wenyan 用文言文输出，单字信息密度最高。日常编码建议 Full，赶时间或批量任务可以上 Ultra。
这里有个反直觉的点值得说：作者在 README 里引用了一篇论文《Brevity Constraints Reverse Performance Hierarchies in Language Models》，指出约束大模型用简短回答，在某些基准上准确率反而提升了 26 个百分点。短的不只是省钱，短的还可能更准——因为模型被迫聚焦在关键信息上，减少了在铺垫语里绕圈的概率。
理解了“少说话”这一层，接下来是通道层。Caveman 管的是智能体怎么说话，但你的请求最终要经过一个 API 通道发出去，Key 怎么管、用量怎么算、模型怎么切，这些属于通道层的事。如果通道层是散的——每个工具一套 Key、一套 Base URL、一套计费——那你根本没法验证“省了 65%”到底省在哪。
TaoToken 在这里的角色是统一通道：一个 Key 覆盖 Claude Code、Codex、Cline 等工具的接入，Base URL 统一，用量可查。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 端点是 https://taotoken.net/api （这个不加 UTM）。你需要提前准备的东西只有三样：一个 TaoToken 账号、一个 API Key、以及本机已经装好的 Claude Code 或同类智能体。
拿 Key 的路径很直接：登录后进控制台，在 API Keys 页面创建一个新 Key，复制保存。控制台地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= ，API Keys 页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= 。创建时建议按用途命名，比如claude-code-caveman，方便后面在用量页面对照。
模型 ID 这块要注意：Claude Code 走的是 Anthropic 兼容协议，模型 ID 要填对，常见的是claude-sonnet-4-5这类。具体可用模型列表在文档里查，文档地址 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= 。如果你用的是 Codex，认证文件是auth.json，字段结构不一样，后面配置章节会分开写。
前置准备做完，你手上应该有：TaoToken API Key、确认好的模型 ID、本机智能体版本。接下来进入配置环节，这是全文最该逐字抄的部分。
3. 可复制配置：settings.json 与 config.toml 骨架
这一节给三套配置：Claude Code 的settings.json、Codex 的auth.json、以及通用 TOML 骨架。三件套的核心永远是 Base URL + Key + Model ID，缺一个都连不上。路径按操作系统区分，字段名保持和原文一致，别自己改拼写。
先看 Claude Code。它的配置文件在用户目录下的.claude/settings.json。macOS / Linux 是~/.claude/settings.json，Windows 是C:\Users\你的用户名\.claude\settings.json。如果目录不存在就手动建。内容骨架如下：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "sk-你的TaoToken密钥", "ANTHROPIC_MODEL": "claude-sonnet-4-5", "ANTHROPIC_SMALL_FAST_MODEL": "claude-haiku-4-5" }, "permissions": { "allow": [], "deny": [] } }三个关键字段解释一下。ANTHROPIC_BASE_URL指向 TaoToken 的 API 端点，注意结尾不要多加斜杠。ANTHROPIC_AUTH_TOKEN填你刚创建的 Key，以sk-开头。ANTHROPIC_MODEL是主模型，ANTHROPIC_SMALL_FAST_MODEL是后台小任务用的快模型，分开配能进一步压成本——小任务没必要用大模型。
如果你用 Codex，认证走的是auth.json，路径在~/.codex/auth.json（Windows 是C:\Users\你的用户名\.codex\auth.json）。结构不同，字段是OPENAI_API_KEY和base_url这类：
{ "OPENAI_API_KEY": "sk-你的TaoToken密钥", "base_url": "https://taotoken.net/api", "model": "gpt-5.6" }Cline 或其它支持 MCP 的工具，配置通常写在config.toml或工具的 settings 里。通用 TOML 骨架长这样：
[provider] name = "taotoken" base_url = "https://taotoken.net/api" api_key = "sk-你的TaoToken密钥" model = "claude-sonnet-4-5" [agent] caveman_mode = "full" max_output_tokens = 800 compress_memory = truecaveman_mode对应 Caveman 的输出等级，full是默认档。max_output_tokens是硬上限，设成 800 能强制智能体别啰嗦——这是 Prompt 约束之外的物理约束，双保险。compress_memory打开后配合/caveman-compress使用。
配置改完要重启智能体才生效。Claude Code 直接退出重进，Codex 同理。重启后可以用/config或类似命令确认当前 Base URL 和模型是否读到了新值。如果工具支持环境变量覆盖，也可以临时用export ANTHROPIC_BASE_URL=...测试，但长期还是写进配置文件稳妥。
一个容易踩的坑：settings.json是严格 JSON，不能有注释，不能有尾逗号。很多人从博客复制时带了//注释，结果解析失败，工具静默回退到默认端点，你还以为连上了。改完用python -m json.tool ~/.claude/settings.json校验一下，能过再重启。
配置骨架到这里就齐了。下一节验证请求，确认通道通了、Caveman 生效了、Token 真的降了。
4. 验证请求与 Token 节省效果实测
配置写完不验证，等于没配。这一节分三步：先确认通道通，再确认 Caveman 生效，最后对比 Token 用量。
第一步，验证 API 通道。最直接的方式是用 curl 打一次 TaoToken 的端点，确认 Key 有效、模型可调。命令如下：
curl https://taotoken.net/api/v1/messages \ -H "x-api-key: sk-你的TaoToken密钥" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "max_tokens": 100, "messages": [{"role": "user", "content": "用一句话说明什么是重渲染"}] }'返回里如果有content字段和正常的文本，说明通道通了。如果返回 401，说明 Key 不对或没带上；如果返回模型不存在，说明 Model ID 拼错了。这一步过了再进智能体，能省掉一半排障时间。
第二步，验证 Caveman 生效。在 Claude Code 里发一个典型问题，比如“解释一下 React 的 useEffect 依赖数组为空会发生什么”。正常模式下它会先铺垫再解释，Caveman 模式下应该直接给结论加代码片段。你可以观察输出长度：如果回答明显变短、没有“让我来分析”这类开场，说明钩子生效了。如果还是老样子，检查钩子脚本有没有写入标记文件，或者手动敲一次/caveman看是否切换。
第三步，对比 Token 用量。这是最有说服力的环节。TaoToken 控制台的用量页面能看到每次请求的输入输出 Token。做法是：同一个问题，先在 Caveman 关闭状态下问一次，记录输出 Token；再开启 Caveman 问一次，记录输出 Token。两次对比。
我实测的一组数据：问“修复一个 JWT 过期未刷新的中间件 bug”，正常模式输出约 704 Token，Caveman Full 模式约 121 Token，降幅 83%。再问“配置 PostgreSQL 连接池参数”，正常 2347，压缩后 380，降幅 84%。平均下来和官方说的 65% 吻合，个别场景更高。
这里要提醒一点：省的是输出 Token。输入 Token 由你的 Prompt 和上下文决定，Caveman 的/caveman-compress能压CLAUDE.md这类记忆文件，间接降输入。所以完整的效果要输入输出一起看。在 TaoToken 用量页面按会话筛选，能看到单次会话的总消耗，对比开启前后的曲线，趋势很明显。
验证通过后，建议把 Caveman 模式固定下来，别每次手动开。Claude Code 的钩子就是干这个的，配置一次，之后每个会话自动进入。如果你同时用多个工具，把settings.json、auth.json、config.toml三套都配上，统一走 TaoToken 通道，用量集中在一个控制台看，管理成本最低。
到这一步，通道通了、模式生效了、数据也看到了。接下来是排障，把常见的几个报错一次讲清。
5. 常见报错排查：401、local proxy failed 与 reading choices
配置和验证过程中最容易撞上四类报错，逐个拆。
401 Unauthorized。最常见，原因通常是 Key 没填对、Key 前后有空格、或者环境变量覆盖了配置文件。排查顺序：先确认settings.json里ANTHROPIC_AUTH_TOKEN的值和 TaoToken 控制台创建的一致；再用 curl 单独测一次，排除是工具层的问题还是 Key 本身的问题；最后检查有没有 shell 里残留的ANTHROPIC_API_KEY环境变量把配置覆盖了。环境变量优先级通常高于配置文件，unset ANTHROPIC_API_KEY再重启试试。
local proxy failed / connection refused。这个报错说明工具在尝试连一个本地代理端口，但那个端口没服务。常见于之前配过本地转发、后来关掉了但配置没清。检查settings.json里ANTHROPIC_BASE_URL是不是还指向http://localhost:xxxx这类地址，改成https://taotoken.net/api即可。另外确认本机网络能正常访问外网 HTTPS，公司内网如果有出口限制，需要走允许的通道。
reading choices / unexpected response format。这个报错通常出现在返回体结构不符合预期时，比如端点填成了 OpenAI 格式但工具按 Anthropic 格式解析，或者反过来。Claude Code 走 Anthropic 协议，端点要用/api/v1/messages对应的 Base URL；Codex 走 OpenAI 协议，字段是choices。如果你把两者的 Base URL 混用，就会报 reading choices 失败。核对：Claude Code 用https://taotoken.net/api，Codex 同样用这个 Base，但工具内部会拼不同的路径。模型 ID 也要匹配协议，别给 Anthropic 协议填 OpenAI 的模型名。
OAuth / authentication flow 相关报错。有些工具首次登录会走 OAuth 流程，如果你已经配了 API Key，它可能还在尝试旧的 OAuth 凭证。解决办法是清掉工具目录下的凭证缓存，比如~/.claude/下的 token 缓存文件，或者 Codex 的~/.codex/下的旧认证文件，然后重新用 API Key 方式登录。注意别把auth.json和 OAuth 缓存搞混，前者是你要写的，后者是要清的。
再补一个配置层面的坑：JSON 尾逗号和注释。前面提过，这里再强调一次，因为它是静默失败——工具不报错，直接回退默认端点，你以为连上了其实没有。改完配置用python -m json.tool或编辑器的 JSON 校验过一遍。
还有一个和 Caveman 相关的：如果输出没有变短，先确认钩子有没有真正写入标记文件。有些版本安装钩子需要手动执行一次初始化脚本，或者需要重启终端。检查标记文件是否存在，不存在就手动跑一次安装命令。另外max_output_tokens设得太低（比如 200）会导致回答被截断，看起来像“变短了”其实是没说完，建议设在 800 以上。
排障的核心逻辑就一条：先分层，再定位。通道层的问题用 curl 测，配置层的问题看 JSON 校验，模式层的问题看输出特征。三层分开，基本十分钟内能定位。
6. 把极简输出固定成默认工作流
配置和排障都过了之后，真正有价值的是把它变成默认习惯，而不是每次手动开。我的做法是把三件事固定下来。
第一，Caveman 模式常驻。Claude Code 的钩子配置一次，之后每个会话自动进入 Full 档。需要详细解释时再临时切回正常模式，而不是反过来。默认省，按需详。
第二，通道统一。所有智能体走同一个 TaoToken Key 和 Base URL，用量在一个控制台看。这样你才能持续观察 Caveman 到底省了多少，而不是凭感觉。模型对话入口在 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= ，想快速验证某个模型的表现可以直接在这里试；长期编码和 Agent 任务建议用 Coding Plan，地址 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= ，按套餐走比按量更可控。
第三，记忆文件定期压缩。/caveman-compress不是一次性的，CLAUDE.md会随着项目演进变长，隔一段时间压一次，输入 Token 能持续保持在低位。这一步很多人会忘，但长会话里输入 Token 的累积不比输出少。
Claude Code 的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= ，里面有各工具的完整配置示例，遇到字段不确定时以文档为准。API Keys 管理在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_campaign=rewrite&utm_content= ，建议按工具或项目分 Key，方便用量归因。
最后说一个我踩过的坑：一开始我把max_output_tokens设得很低，以为越低压得越狠，结果智能体经常回答到一半被截断，反而要追问一次，总 Token 更高。后来改成 800 配合 Caveman 的 Prompt 约束，效果最好——约束负责“少说废话”，上限负责“兜底”，两者配合而不是互相替代。
Caveman 火起来不是因为它技术多新，而是它把一个被忽视的事实摆上台面：智能体“知道”的和它“说出”的不是一回事，砍掉后者不影响前者。把这件事做成配置、固定成默认，省下来的就是实打实的成本。