压缩模式不是万能药这些场景千万别开 ultra【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman过去一年caveman 用一句 why many token when few token do trick 横扫 GitHub Trending 与 Hacker News 榜首在 GitHub 上积累起六位数的 Star社区里到处是装上之后 API 账单立省 65%的实测。但很少有人细读项目自己维护的那份诚实数字清单——它明确写着caveman 有时省钱有时花钱而这恰恰取决于你在哪个档位、哪个场景下使用它。本文不再复述65%的营销口径而是反过来拆解压缩模式的失效边界什么样的任务开 ultra 会翻车自动回退机制能兜底到什么程度以及一套经得起账单验证的保守档位默认值。所有结论均来自仓库源码与官方自测数据而非宣传文案。一、压缩的本质它不是删废话而是在赌语义冗余要理解 ultra 为什么会翻车先要看它到底在做什么。caveman 三个档位本质是三层递进的丢字策略/caveman删冠词、删寒暄、删连接词但保留完整句子结构Answer first, fluff gone/ultracave在 caveman 基础上连语法一起剥掉只留碎片——官方原话是Ultracave is caveman with the grammar stripped. Payload only.skills/ultracave/SKILL.md/megacave切到文言文靠句法本身的省略再压缩但官方自己承认 Token savings are small and noisy; never claim themskills/megacave/SKILL.md。官方基准给出的增量收益是在Answer concisely.基线之上/caveman中位再省 3%/ultracave省 35%/megacave反而只有 9% 且波动极大README.md 与 docs/HONEST-NUMBERS.md 的实测表。注意ultra 的高收益来自把语法也当作冗余剪掉——这个前提只在读者能靠碎片脑补回原意时成立而错误排查、API 名密集的对话恰恰是最难脑补的场景。二、哪些任务开 ultra 会翻车1. 错误排查被剪掉的恰恰是判案依据调试类任务的产出是结论 证据链。一个典型的排查会话里agent 需要输出报错原文、触发链路、前后对比、修复建议。而 skills/ultracave/SKILL.md 的规则 3 明确写着Each fact once: No restating, no summary after a list——它主动禁止复述与总结。问题在于排查场景里复述不是废话是用户用来交叉验证的判案依据。当 agent 只丢出一句Token expiry check usenot. Fix:...用户拿到的是结论而非推理过程一旦结论方向有误整个会话没有任何中间产物可供回溯只能重新喂上下文再跑一轮。此时 ultra 省下的 35% 输出 token被多轮纠错的输入 token 完全抵消甚至反向亏损。这一点在 skills/caveman/SKILL.md 的When to break the rules里有明文兜底User confused or repeats the question必须回到完整句子。但问题在于这条兜底依赖模型自觉判断用户困惑了——而困惑往往在若干轮之后才暴露损失已经发生。2. API 名密集场景非代码块里的标识符没有护身符很多人误以为代码与 API 名逐字保留是绝对保险。确实skills/caveman/SKILL.md 的规则 6 写着 payload verbatimskills/ultracave/SKILL.md 的 Floor 也要求 code/commands/paths/API names/error strings 一字不改。但注意保护范围只有反引号包裹的 inline code、代码块、路径与报错字符串才享受逐字待遇。散落在自然语言里的 API 名、函数签名、枚举值、SDK 方法链——比如一句确保client.fetch()失败时走retry策略并检查rate_limit_remaining头——一旦写法不规范缺反引号压缩时就会被当作普通名词自由裁剪。规则里那句 Never cut: ... API names 是写给模型的纪律而不是写给校验器的硬约束。真正的硬约束在 skills/caveman-compress/scripts/validate.py它机械比对原文件与压缩结果的代码块、URL、路径、inline code 是否逐字一致heading 文本一个字符都不许改。这套校验能拦住/caveman-compress这类文件压缩的篡改却拦不住会话对话里的 ultra 输出——对话没有 validate.py 把关只有模型的自律和 Pre-send check。更要命的是标识符的部分匹配问题ultra 允许 One word when one word is enoughskills/ultracave/SKILL.md 规则 2而UserAlreadyExistsException这类长名字恰恰是碎片化改写的高危对象——截成UserExists后语义近似但精确匹配失败用户复制进代码直接编译不过。3. 按请求计费与工具侧统计压缩在账本上失效压缩的经济学前提是按 token 计费。一旦计费模型改变整个前提崩塌——这正是 docs/HONEST-NUMBERS.md 用三个真实案例记录的翻车现场按请求/积分计费GitHub Copilot 按 premiumrequests收费输出短一截也是同一个请求caveman 无法降低成本固定提示开销吞收益实测案例 #145 中规则注入带来的输入 token 开销超过了输出削减整体净亏损统计方向反向案例 #550 的一次 Cursor A/B 显示开 caveman 后会话消耗 4.3M token、对照组 1M墙钟耗时翻倍——规则反复注入、重试、缓存与上下文记账把输出省下的全吞了还倒贴。官方结论写得很直白Turn Caveman off if your A/B is net-negative.压缩是优化手段不是账本定律。4. 安全警告与不可逆操作规则强制要求说人话这是 ultra 唯一自带硬性回退的场景。三个档位的 SKILL 都列了同一条When to break the rules安全警告、不可逆操作先确认、歧义句子两个读法、任何会持久化到聊天之外的内容代码、注释、commit、issue、文档——全部回到完整句子事后再恢复压缩腔。也就是说高危场景压缩器自己也知道不该压。这既是优点也是陷阱回退逻辑是规则驱动的软约束取决于模型能否识别这是安全警告当模型把DELETE FROM users的确认流程误判为常规操作时规则再漂亮也救不了你。ultra 的 Pre-send check 要求 Negations present?——它把否定词当作最高优先级保全对象因为一个被剪掉的not比省下的所有 token 都贵。三、自动回退机制什么时候救你什么时候救不了caveman 不是只有一层回退而是三层递进的保守设计。理解每层的边界才知道何时可以放心、何时必须手动干预。第一层内容管线回退。代理proxy端的输入压缩引擎是 fail-open 设计engine/detect.go 的注释写明anything it is not confident about is text, which routes to a conservative compressor——识别不了的内容默认走最保守的text压缩器engine/compressors/text.go只折叠长文段落、保留标题和显式重要的段落。HTML 压缩器更极端解析失败、找不到 body、找不到主容器、链接密度过高一律bail to pass-throughengine/compressors/html.go。这一层救你它宁可少省绝不瞎改。第二层文件压缩的校验回退。/caveman-compress在覆盖文件前跑六项校验代码块、URL、路径、heading、bullet、inline code任何一个 error 都阻止覆盖并触发最多 2 次定点修复而非重新压缩skills/caveman-compress/scripts/validate.py。这一层救你它用机械比对兜住模型幻觉。而且它只压缩自然语言文件.py/.json/.yaml等一律跳过敏感文件名credentials.md、secrets.txt、.ssh/*在读取前就被硬拒绝skills/caveman-compress/scripts/detect.py。第三层救不了的地方计费模型与整会话统计。前面两层都拦不住这三件事按请求计费的账单——压缩不产生任何收益回退机制无从谈起整会话的 token 总账——#550 证明规则注入与重试开销可以在会话级吞掉全部收益而只看输出长度的局部数字完全看不出来没有压缩器的输入类型——README 的代理基准里HTML 档 21,670 → 21,670整会话不省反增 9.9% 开销压缩器缺失的类型回退机制只能保证不乱改不能保证省钱。此外还有一个被广泛误用的场景压缩用户自己的 prompt。README 引述 Adobe Research 的发现——把用户的 prompt 也 caveman 化会让回答更长更糟所以 caveman 明确规定Your prompts stay yours. Never rewritten.任何宣称连 prompt 一起压的用法都在跟这条结论对着干。四、一套保守的档位选择默认值综合上面的失效边界可以给出一个可执行的默认策略——原则只有一个让压缩的激进程度与内容的可恢复性成正比。场景推荐档位理由日常编码问答、常规 CR/caveman语义风险最低中位仍有 3% 增量收益规则开销可接受长会话、工具调用密集/caveman 代理输入压缩大头在输入侧proxy 平均省 33.2% 输入 token别把宝押在输出上排查类、多轮调试、API 名密集不开压缩或开/caveman后手动关闭证据链被剪、标识符被改的代价 ≫ 35% 输出收益按请求计费Copilot 等关闭账本上零收益docs/HONEST-NUMBERS.md 案例 #506安全相关、不可逆操作、写文档/commit/issue强制完整句规则本身就要求 break the rules记忆文件CLAUDE.md 等/caveman-compress有校验回退 备份兜底改动可回滚想炫技/megacave官方明示 never claim the savings收益噪声大落地时还有两条纪律值得刻进习惯。第一任何档位都先做一次真实验证。官方在 docs/HONEST-NUMBERS.md 里给出了唯一可信的度量方法同任务、开与不开、对比 provider 账单的整会话总额。仓库自带的benchmarks/run.py与evals/measure.py只负责复现官方数字不能证明你的会话省钱。另外注意缓存行为规则注入会给每次调用增加约 1,000 输入 token而 docs/technical/cache-planner.md 明说缓存提示不证明缓存命中——本地推断永远低于 provider 账单的可信度。想看清自己 token 到底花在哪可以用caveman learn生成会话分析报告第二把压缩用在工具输出上而不是对话腔调上。真正性价比最高的是输入侧日志、CSV、测试输出、JSON 经代理压缩可省 98.5%–99.1%且原始文件始终留在磁盘、可随时拉回。对话输出侧的 ultra 省的是读的成本代价是脑补的负担——这恰好是把压缩收益从机器账单转移成了人的时间。当读者是人而不是模型时请记住 skills/caveman/SKILL.md 里的底层逻辑Reader pays per token and reads in a terminal.省下的 token 如果换来用户三遍重读这笔交易并不划算。压缩模式不是万能药官方也从未打算把它说成万能药——docs/HONEST-NUMBERS.md 开篇第一句就是Caveman save tokens sometimes. Caveman cost tokens sometimes.把这句话当作默认配置把开 ultra当作显式决策你的压缩才不会从省钱变成负债。【免费下载链接】caveman why use many token when few token do trick. Viral skill proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考