Caveman 账本:caveman 技能的诚实数字、净亏损场景与自测方法
【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman
Caveman 项目 README 宣称平均节省 65% 输出 token,但同一仓库的docs/HONEST-NUMBERS.md明确告诉你:这个技能在某些工作负载下是净亏损的。本文以该文档为主线,结合仓库中的评测脚手架(evals/README.md、evals/measure.py)与基准脚本(benchmarks/run.py),完整讲清 caveman 技能的真实成本结构:它只压缩什么、每回合固定花多少、何时回本、何时该关掉,以及如何用仓库自带工具复现和自测这些数字。
响应技能到底改变了什么
先划清边界,这是理解所有数字的前提。Caveman 响应技能(skills/caveman/SKILL.md)做的事情只有一件:让模型写出更短的回答。它是一条注入系统上下文的行为指令,不压缩输入、不压缩上下文、不压缩文件、不压缩模型的思考 token。
从 docs/technical/product-model.md 的分层表可以确认这一点:
| 层 | 职责 | 许可 |
|---|---|---|
| Skill、hooks、plugins | 让代理用更少废话回答,同时保留技术文本 | MIT |
| Engine | 检测负载形态、应用匹配变换、估算 token、存储恢复记录 | BSL 1.1 |
| Local proxy | 把提供商请求路由经过 Engine 并记录本地用量 | BSL 1.1 |
也就是说,"压缩可恢复输入"是 Engine 和本地 proxy 这两层单独组件的能力,与响应技能无关。把两者的账混在一起,是大多数"省 token"误会的来源。
反过来,技能本身有实打实的输入成本。skills/caveman/SKILL.md 实测约 6.5KB 文本(含 frontmatter、规则表与示例),其中核心规则段落会随每次技能激活进入上下文,另有技能列表条目开销。docs/HONEST-NUMBERS.md给出的估算为每回合约 1–1.5k 输入 token。注意 SKILL.md 里的规则本身就在解释为什么省 token:例如明确禁止自造缩写(cfg/impl/req/res/fn)和因果箭头→,因为分词器会把它们拆成和完整词同样多的 token——"零节省、还伤可读性"。这条规则从侧面印证了作者对分词粒度的实测态度:连规则文本都在拒绝无效压缩。
实测数字总表
docs/HONEST-NUMBERS.md的核心是一张"什么算数、什么不算数"的表,完整继承如下(链接已转换为仓库根路径):
| 项目 | 数字 | 如何测得 | 来源 |
|---|---|---|---|
| 相对默认冗长回复的输出缩减 | 未发布 | 评测脚手架存在,但仓库未提交已评审的原始结果 | benchmarks/ |
| 技能带来的输入缩减 | 0% | 它是一条输出风格指令 | 不适用 |
| 技能额外增加的输入成本 | 每回合约 1–1.5k token | SKILL.md 规则(约 5KB)注入上下文,外加技能列表条目 | skills/caveman/SKILL.md |
/caveman-compress作用于记忆文件 | 五个示例文件平均约 46% 输入缩减 | 文件 token 计数加结构校验;不做普遍质量等价声明 | caveman-compress fixtures |
两个容易被忽略的注释:
- "Token-count runs measure output length only"——token 计数只测输出长度,不能证明语义或技术等价性。发布一个缩减数字,必须伴随已提交的原始成对输出(raw pairs)和独立的质量评审。这条纪律在代码里能看到落实:benchmarks/run.py 写结果时,元数据中固定写入
"quality_evaluated": false及说明"token 计数不建立语义等价性"。 /caveman-compress的 46% 是另一条账,别和输出缩减混用。它压缩的是CLAUDE.md、todos、偏好文件等输入侧的自然语言文件。skills/caveman-compress/README.md 给出了五个真实项目文件的完整数据:
| 文件 | 原始 token | 压缩后 | 节省 |
|---|---|---|---|
claude-md-preferences.md | 706 | 285 | 59.6% |
project-notes.md | 1145 | 535 | 53.3% |
claude-md-project.md | 1122 | 636 | 43.3% |
todo-list.md | 627 | 388 | 38.1% |
mixed-with-code.md | 888 | 560 | 36.9% |
| 平均 | 898 | 481 | 46% |
对应原始文件与压缩结果都提交在 tests/caveman-compress/,结构校验(标题、代码块、URL、文件路径逐字保留)全部通过,但文档明确声明:校验不建立跨文件、跨模型的一般语义等价。
关于 README 主表中"平均 65%"的数字,需要结合本表理解:该表由 benchmarks/run.py 通过--update-readme写入<!-- BENCHMARK-TABLE-START/END -->标记之间,而 benchmarks/results/ 目录当前为空——即"脚手架在、已评审原始结果未提交",这正是表中第一行写"未发布"的原因。读者应把 65% 视为脚手架产出而非已评审结论。
评测脚手架:三臂对照才是"诚实差值"
evals/README.md 记录了这套评测的关键设计修正:早期版本把技能直接和无系统提示的基线对比,把"变得简洁"这个通用指令的效果也算到了技能头上,数字因此虚高。修正后采用三臂设计:
| 臂 | 系统提示 |
|---|---|
__baseline__ | 无 |
__terse__ | Answer concisely. |
<skill> | Answer concisely.\n\n{SKILL.md} |
任何技能诚实的差值是<skill>对比__terse__——即技能在一句通用"请简洁"之上额外贡献了多少。benchmarks/run.py 同样实现了这个控制臂:TERSE_SYSTEM = "Answer concisely."与 evals 脚手架使用同一字符串,两个工具的口径保持一致;统计函数会分别计算"vs terse"和"vs baseline"两组缩减率并在输出中分开标注,避免读者把两者混用。
配套工具链:
- evals/llm_run.py:按
claude -p --system-prompt …逐(prompt × 臂)运行,捕获真实 LLM 输出并写入提交到 git 的snapshots/results.json,附带模型、CLI 版本、时间戳等元数据。当前快照(evals/snapshots/results.json)元数据显示:模型claude-opus-4-6、Claude Code CLI2.1.97、10 条开发问题 prompt(evals/prompts/en.txt)。 - evals/measure.py:离线读取快照,用 tiktoken
o200k_base计 token,打印中位数/均值/最小/最大/标准差。文档特别强调:o200k_base是 OpenAI 的 BPE,只是对 Claude 分词器的近似——各臂之间的比率有意义,绝对数值是近似的。运行方式:uv run --with tiktoken python evals/measure.py。 - 快照提交进 git 有两个目的:CI 运行确定且免费;任何数字变化都以 diff 形式可评审。
同时,evals/README.md 坦陈这套工具不测什么:保真度(回复全写k也能"赢" −99%)、时延与成本、跨模型行为、统计显著性(每臂单次运行,非功效实验)。这些边界正是docs/HONEST-NUMBERS.md坚持"未发布聚合缩减"的底气所在。
什么时候 caveman 赢
继承原文档的三个成立条件:
- 长而啰嗦的输出给简洁风格留出更多可删的散文。具体缩减多少要自己 A/B 实测——仓库当前没有发布聚合缩减数字。
- 长会话 + 啰嗦的代理:每回合的输出缩减会累积,而固定的规则成本每回合重复支付。会话越长,累积收益相对固定成本越占优。
- 更短的回答更早结束、更省阅读时间——这是文档承认的"真实收益"所在:可读性与速度是主要红利,省钱是副产品。
什么时候 caveman 亏(净亏损)
技能每回合花约 1–1.5k 输入 token。如果它省下的输出少于这个数,你是在付费用它。原文档列举了四类净亏损场景,均来自社区反馈与实测:
- 简短编码问答。有用户在 issue #145 中实测净亏损:固定提示词开销超过了输出缩减。任务越短,"每回合 1–1.5k"的固定成本占比越高。
- 按请求/信用计费的代理。GitHub Copilot 按 premium请求计费(issue #506)。回答变短不等于请求变少,Copilot 信用消耗不变;任何按消息计价的方案同理。对这类计费模型,输出缩减在账面上归零。
- 会话总量可能和"仅输出变化"差很远。因为提示词、上下文、文件、注入规则都消耗 token,会话级的 A/B 总量会吸收这些项。文档的结论很硬:提供商计费的 A/B 总量优于仅输出的估算。
- 工具侧计数器可能指错方向(issue #550)。一次 Cursor A/B 显示开 caveman 4.3M token、关 caveman 1M token,且墙钟时间翻倍。由于原始运行不可复现,文档只保留最保守的结论:规则重注入、重试、缓存或上下文记账都可能压过输出节省。如果你的 A/B 是净亏损,就把 Caveman 关掉。
自己测一遍
原文档给出三步自测法,逐步展开如下。
1./caveman-stats(Claude Code):读取会话日志,打印真实的输出/缓存计数。文档特别注明:在已评审的基准结果提交之前,它不发布反事实节省数字。实现位于 src/hooks/caveman-stats.js:直接运行是node hooks/caveman-stats.js;在 Claude Code 内由 UserPromptSubmit hook 触发,并传--session-file <transcript_path>确保读的是当前会话而非最近修改的 JSONL。
2. 同一任务带/不带 Caveman 各跑一遍,对比提供商用量或账单页。这一步优先级高于仓库内任何估算——文档原话:"That A/B outranks repository estimates."
3. 复现仓库数字,两条离线/在线路径:
benchmarks/run.py(需要 Anthropic API key):从ANTHROPIC_API_KEY环境变量或仓库根.env.local读取密钥——benchmarks/run.py 刻意只读这一个键,不再把.env.local的其他键导出到环境(issue #528 的收敛结果)。关键参数:参数 默认 说明 --trials3 每 prompt 每模式运行次数 --modelclaude-sonnet-4-20250514使用模型 --dry-run关 只打印配置,不发 API 请求 --update-readme关 把基准表写回 README.md 标记区间 运行形态为
10 个 prompt × 3 臂(normal / terse / caveman)× trials,temperature=0、max_tokens=4096,对 429 限流做 5s/10s/20s 退避重试。结果连同skill_md_sha256(SKILL.md 内容指纹)写入 benchmarks/results/ 的带时间戳 JSON。evals/measure.py(离线,读已提交快照):uv run --with tiktoken python evals/measure.py,无需 LLM 或 API key,可直接在 CI 跑。刷新快照才需要claudeCLI 登录态:uv run python evals/llm_run.py,省钱技巧是CAVEMAN_EVAL_MODEL=claude-haiku-4-5指定小模型。
经验法则
原文档的收尾结论,原样继承:
在同一任务上,对比带与不带 Caveman 的提供商计费总量。如果固定提示词开销超过输出缩减,就该工作负载把 Caveman 关掉。
一句话总结这套文档的立场:输出缩减数字必须带着"vs terse 控制臂"的口径看,会话成本必须以提供商账单为准,任何与上述数字矛盾的自测结果都值得提交回来校准这张诚实的账本。
【免费下载链接】caveman🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考