让 AI 编程助手闭嘴省字：一个"穴居人"技能背后的 Token 压缩原理与实操全拆解

本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想拿走一句话的结论：给大模型立一条"有话直说、只留干货"的硬规矩，它的输出 Token 平均能砍掉六成上下，代码、命令、报错这些关键信息一个字不少，回答反而更容易抓到重点。 我这段时间在 Claude Code、Codex 这类 AI 编程助手上反复折腾一个叫 Caveman（直译"穴居人"）的开源技能，它干的事简单粗暴——逼着模型像发电报一样说话，客套、铺垫、"我很乐意帮你"这类废话统统砍掉，只保留真正解决问题的部分。作者跑了 10 个真实开发任务实测，输出 Token 平均省下约 65%，最狠的一个任务省了 87%。但它有个必须先说清楚的前提：省的只是"输出" Token，输入和推理部分不省，而且技能本身每轮还要额外吃掉一千多 Token，所以它真正的价值不在省钱，而在于让你读得更快、模型答得更准。

这篇文章我不打算只停在"这插件真好用"的层面。我会把三件事讲透：AI 为什么会越写越啰嗦（这背后有实打实的训练机制原因）、这个技能到底靠什么把话变短、以及就算你一个插件都不装，怎么自己复刻出同样的效果。想看完整拆解，往下翻。

一、先搞明白：AI 为什么越来越像"话痨"

要理解一个"让 AI 闭嘴"的工具凭什么有用，得先回答一个更根本的问题——好端端的模型，怎么就变得这么爱铺垫、爱绕圈、爱说正确的废话了？

我一开始也以为是错觉。直到有一次我只是问 Claude Code："这个 React 组件为什么重复渲染？"它先给我讲了一段渲染机制的科普，又铺垫了一句"这是个很常见的问题，别担心"，再列了三种可能性，最后才吐出那句真正有用的答案。整段话读下来七八行，真正的信息量其实就一句。

1.1 这不是模型"性格问题"，是训练留下的偏好

现在主流大模型基本都经过一道叫 RLHF（基于人类反馈的强化学习） 的工序。用大白话说，就是让一堆人去给模型的多个回答打分排序，模型再朝着"人类更喜欢的那种回答"去调整自己。听起来很合理，问题就出在人类的偏好本身是有系统性偏差的。

学术界给这个偏差起了个专门的名字——长度偏置（length bias）。多篇研究反复观察到同一个现象：在给回答打分时，人更倾向于把"更长的那个"标记为更好，哪怕多出来的那部分内容并没有让答案更正确、更有用。有研究统计过,在一些常用的偏好训练数据集里，更长的回答被选为"更优"的比例能到六成以上。

这里的因果链条是这样的：

人类打分时偏爱长答案
        ↓
奖励模型学到"长 = 好"这条捷径
        ↓
模型为了拿高分，拼命把话说长
        ↓
你看到的每个回答都裹着一层废话

一旦奖励模型把"篇幅"和"质量"这两件本来无关的事画上了等号，被它训练出来的模型就会顺着这条捷径一路狂奔，产出大量同义反复的措辞、连接词、铺垫句——研究里管这叫"奖励作弊（reward hacking）"，模型不是真变笨了，而是学会了用注水来骗分。

1.2 还有一层：模型不确定时会"用废话补位"

除了训练偏好，还有个更微妙的机制，学界叫 verbosity compensation（冗长补偿）。意思是当模型对某个问题没那么有把握、上下文比较模糊的时候，它会下意识地多说,靠堆叠泛泛的、放之四海皆准的内容来"填满"回答，就像人紧张的时候会不自觉地多解释几句。

我自己踩过一个很典型的坑能印证这点：越是那种边界模糊、需要权衡的问题（"这个架构该拆微服务还是保持单体？"），模型给我的回答就越长、越绕；反倒是有标准答案的问题（"这行报错什么意思？"），它答得干脆利落。有研究测过，几乎所有主流模型都存在这种"冗长补偿"行为，不同模型、不同任务下触发的频率从百分之十几到百分之七十几不等，差异非常大。

你不妨自己做个小测试来体会一下：拿同一个模型，先问它一个有明确答案的事实问题，再问它一个开放的、需要权衡取舍的判断题，对比两次回答的长度和"含水量"。你多半会发现，后者明显更长，而且长出来的那部分里，"这取决于……""一方面……另一方面……""需要综合考虑……"这类既正确又没什么信息量的句子占了大头。这就是"用不确定性催生篇幅"最直观的现场。看清了这一点，你对"啰嗦"的容忍度会直线下降——因为你知道，那里面有相当一部分，是模型在用长度掩饰它自己也拿不太准。

1.3 啰嗦不只是烦，是真金白银

如果只是读着累也就罢了。但在 API 计费的世界里，每一个多出来的字都要花钱。大模型的计费单位是 Token（可以粗略理解成"词元"——模型眼里的最小语言单位，一个汉字大约算一到两个 Token，一个英文单词大约算一个多），输入和输出分开计价，输出通常还更贵。

于是这套逻辑就串起来了：训练偏好让模型爱说废话 → 废话变成多出来的输出 Token → 输出 Token 直接换算成你的账单和额度。你用 Claude Code 写一天代码，账单里可能有相当一部分钱，是花在了那些"我很乐意帮你""这是个好问题""让我来分析一下"上面。

我给你算笔更直观的账。假设你是个重度用户，一天和 AI 编程助手来回问答两百轮，每轮回答里"注水"的部分大约占三成——这在实测里其实是个偏保守的估计。一轮里如果输出是四百个 Token，那废话就是一百二十个左右，两百轮下来就是两万四千个纯废话 Token，一天。乘上三十天，一个月光是替这些"我很乐意帮你"买单，就是七十多万个 Token。这些字你一个都没读进心里，却实实在在从你的额度或账单里划走了。这还只是一个人的量，放到一个十几人的开发团队身上，数字会相当可观。

更隐蔽的一笔损失是上下文窗口的挤占。模型每次能"记住"的内容有个上限（也就是上下文窗口），废话占的位置多了，真正有用的代码、历史对话就得更早地被挤出去。换句话说，啰嗦不只花钱，还在偷偷缩短你和模型之间"有效记忆"的长度。

辛梓煜@词元二号站折腾这一圈下来最大的感受是：这不是某个模型的毛病，是整个 RLHF 范式带来的系统性副作用。想治它，要么等厂商在训练层面优化（这事迟早会发生），要么就在使用层面自己动手——给模型套一道"少说废话"的紧箍咒。Caveman 走的就是后一条路。

1.4 为什么"每次喊一句简短点"根本不管用

你可能会说：那我每次问完加一句"请简短回答"不就完了？我一开始也是这么干的，后来发现这招基本失效，原因有三个，理解了它们，你才会明白为什么需要一个"常驻规矩"而不是"临时喊话"。

• 第一，它权重太低。 你那句"请简短"只是本轮上下文里的一句普通话，模型在生成时受训练偏好、系统设定、历史对话一堆因素拉扯，你这一句很容易被淹没。
• 第二，它会衰减。 就算这一轮听进去了，聊上三五轮，前面那句叮嘱早就滑出了模型的"注意力焦点"，它又开始故态复萌。你得不停地重新喊，累且低效。
• 第三，它模糊。 "简短"到底是多短？模型自己也拿不准。研究里早就发现，模型对"简洁""详细"这类定性词的执行是飘忽的，对"不超过 50 字"这类硬约束反而更难精确遵守。一句含糊的"简短点"，换来的往往是"稍微短了一点点"。

真正稳的做法，是把这条要求从"对话内容"提升到"对话规则"的层级——写进那种每轮都会被自动加载、优先级更高的配置里。这正是这个工具的价值所在，也是第七节我会教你自己动手复刻的核心。

二、"穴居人"技能到底做了什么

搞清楚了病根，再看这个工具就通透多了。它的名字很形象——Caveman，穴居人，核心创意就是让 AI"学原始人说话"：短句、关键词、直给结论，客套话一律省掉。

2.1 它的本质：一份注入到模型上下文里的"说话规矩"

先破除一个误解：这东西不是什么复杂的压缩算法，也不会去改模型本身。它的技术形态朴素得让人意外——就是一组预先写好的技能文件（本质是一段结构化的提示词/规则），在你每次对话时被塞进模型的上下文窗口里，告诉它：

丢掉铺垫和客套，保留全部实质内容，用短句和词组作答——但代码、命令、报错信息一个字节都不许动。

就这么简单。它靠的不是技术魔法，而是把"简洁"这条要求，从你每次手动叮嘱，变成了一条常驻的、写死的系统级规则。你不用再在每个问题后面追一句"请简短回答"，装上之后它默认就闭嘴省字。

我们可以用一张图看清它在整条链路里插在哪个位置：

flowchart LR
    A[你的提问] --> B[模型上下文窗口]
    C[Caveman 规则<br/>压缩说话风格] --> B
    B --> D[模型生成回答]
    D --> E{内容分类}
    E -->|客套/铺垫/连接词| F[砍掉]
    E -->|代码/命令/报错/路径| G[原样保留]
    F --> H[精简后的回答]
    G --> H

2.2 它砍什么、绝不砍什么

这是我觉得这个工具设计得最克制、也最靠谱的地方。它不是无脑地把回答削短，而是有一条明确的保留红线：

• 会被砍掉的：开场白（"当然！我很乐意帮你"）、安全铺垫（"别担心，这很常见"）、无信息的连接词（"此外""值得注意的是""换句话说"）、把一句话拆成三句的注水式解释。
• 绝不会动的：代码块、终端命令、报错信息、文件路径、URL 链接——这些内容逐字节原样保留。

举个我自己对比过的例子。同样是问"React 组件为什么重复渲染"：

两个回答给出的修复方案一模一样，一个 useMemo 都不少，但后者只用了前者约三成的篇幅。技术信息零损失，废话全没了——这就是它想要的效果。

别小看这条"代码、命令、报错原样保留"的红线，它其实是这类工具能不能用的生死线。你可以想象一个反面案例：如果一个压缩工具为了追求极致短，把报错信息里的行号删了、把命令里的参数缩写了、把配置路径截断了——那省下来的那点 Token，远远抵不上你因为信息残缺而重新折腾的时间，甚至可能被一段"看起来对、实则少了个参数"的命令坑得更惨。所以真正靠谱的压缩，压的必须是冗余的自然语言，而不是精确的技术符号。这个工具把这条界线守得很死，代码块逐字节不动，这也是我敢把它用在真实项目里的底气所在。换句话说，它的克制，比它的激进更值得称道。

2.3 它不挑语言

还有个细节值得一提：这个技能改变的是说话风格，不是内容本身，所以它不会强行翻译你的语言。你用中文提问，它就用精简的中文回答；用其他语言也一样，只压缩"啰嗦度"，不动语种。这一点对咱们中文用户挺友好，不用担心装上之后回答全变成英文。

2.4 它不是单打独斗，背后是一整套"省字"工具链

我越挖越发现，这个"让 AI 少说话"的技能只是一个入口，作者围绕"同一个念头——让智能体用更少的资源做更多的事"，搭了一整套配套工具。它们各自压缩链路上的不同环节，理解了这套版图，你会对"压缩"这件事有更立体的认识。我把它们按"压缩对象"整理成一张表：

除此之外还有两个我觉得对进阶用户特别有用的组件：

• 一个 MCP 中间件：它能包在任意 MCP 服务外面，把那些工具描述信息也压缩掉。做过 Agent 开发的都知道，工具描述往往又长又占上下文，这块能省下来很实在。（MCP 这里指的是一种让 AI 智能体调用外部工具的开放协议，你可以理解成"给 AI 装外挂的标准插座"。）
• 一组精简版子智能体：作者把"调研、构建、审查"三个角色都做成了会用精简风格说话的子智能体，据其数据比常规版本省约六成 Token，好处是主上下文能撑得更久、聊得更深。

我列这些不是让你全都装上——大多数人用好主技能这一个就够了。我想让你看到的是背后那个统一的方法论：从"说什么"到"记什么"、到"整个智能体怎么运转"，压缩这件事可以贯穿到 AI 协作的每一层。这种把一个小切口做深、做成体系的思路，本身就挺值得琢磨。顺带一提，这套东西是开源的、MIT 协议，也就是说你可以自由使用、修改甚至商用，这也是它能在短时间内滚起这么大社区的原因之一。

2.5 顺手澄清三个常见误解

聊到这儿，我把身边朋友最容易搞错的三个点集中说一下，省得你也踩坑。

误解一：它会让 AI 变笨。 恰恰相反，它不动模型的"脑子"，只管"嘴"。模型知道的、能想到的一点没少，只是不再把知道的东西啰啰嗦嗦全倒给你。用它的一句话概括就是：让模型的嘴变小，脑子还是那个脑子。

误解二：它是某种玄乎的压缩黑科技。 不是。它朴素到就是一段写好的规则文本，靠"约定"而非"算法"起作用。理解这一点很重要——因为这意味着它的效果本质上取决于模型对规则的遵守程度，不同模型、不同版本执行力会有差异，别指望它像 zip 压缩那样给你一个精确恒定的压缩比。

误解三：装上就一劳永逸、全程开着最好。 前面反复讲了，它有输入侧的固定成本，也有不适合的任务。真正会用的人是"按需切换"，而不是"一装了之"。工具是死的，判断力是活的——什么时候开、开哪一档，才是你要掌握的东西。

想清楚这三点，你对它的预期就摆正了：一个朴素、诚实、需要你带着判断去用的效率工具，而不是包治百病的银弹。

三、五档"压缩强度"逐个拆解

光有一个开关还不够精细。这个技能提供了多档压缩强度，你可以随时切换，选定后会一直保持到你手动改或对话结束。我把它们从松到紧梳理一遍，配上同一句话在不同档位下的样子，你一眼就能看出区别。

3.1 从"客气"到"极简"的光谱

我们拿同一句技术建议——"你应该把这个对象用 useMemo 包起来，因为每次渲染都会创建一个新的引用"——走一遍全档位：

3.2 三档"力度"怎么选

• lite：只去掉最表层的客套和铺垫，句子结构基本完整，读起来还是正常人话，只是不废话了。适合你需要把回答直接贴进文档、给同事看的场景。
• full：默认档，也是我日常用得最多的。它会进一步把完整句压成信息片段，语气偏"电报体"，但逻辑清清楚楚。日常写代码、查 Bug 用这档最顺手。
• ultra：极限压缩，几乎只剩关键词和符号。适合你已经是老手、一眼就能看懂缩写和残句、只想要模型把"答案本体"糊你脸上的时候。新手别一上来就用这档，容易看不懂。

3.3 单独说说"文言文模式"

这档我个人觉得最有巧思。作者把咱们老祖宗"惜字如金"那套表达直接搬了过来——同样的意思，用文言文承载往往字数更少，因为文言的信息密度天生就高。一句"每渲染皆生新引，故以 useMemo 裹之"，比白话短了一大截，意思却一点没丢。

当然这档更多是好玩和秀操作的成分，实际开发里我不太会天天用文言文看报错。但它背后那个思路——同样的信息，换一种更凝练的表达载体，就能压缩篇幅——其实点破了整个工具的底层逻辑：压缩不是删信息，是换一种更省的方式装信息。

3.4 我自己的选档决策：一张图看懂

档位这么多，实际用起来其实不用纠结。我把自己踩下来的选择逻辑画成一张决策图，你照着走基本不会错：

flowchart TD
    A[要开压缩吗？] --> B{我看得懂缩写/残句吗？}
    B -->|新手，需要讲解| C[别开，用普通模式]
    B -->|老手，只要答案| D{任务需要展开推理吗？}
    D -->|需要多步推理/调试| E[最多用 lite]
    D -->|事实性/有标准答案| F{追求极致速度？}
    F -->|想快速扫重点| G[用 full 默认档]
    F -->|一眼看结论即可| H[用 ultra 极致档]

我的日常配置很稳定：绝大多数写代码、查报错的场景用 full，因为它在"省"和"读得懂"之间平衡得最好；只有在我特别熟、只想瞄一眼结论的时候切 ultra；遇到要它一步步帮我理清复杂逻辑的活儿，我会退回 lite 甚至干脆关掉。你不用一开始就追求极致，从 full 用起，用顺了再按需微调，这是我给新手最实在的建议。

四、安装与上手：命令、开关、实用指令

原理讲完，落到手上其实特别简单。这一节我把从安装到日常使用的完整链路走一遍，命令我都核实过，能直接照抄。

4.1 一条命令装好

它提供了自动安装脚本，会自己识别你机器上装了哪些 AI 编程工具，然后逐个装好。

macOS / Linux（以及 WSL、Git Bash） 执行：

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

Windows（PowerShell 5.1 及以上） 执行：

irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

整个过程大约半分钟，需要本机装了 Node（版本 18 以上）。脚本会跳过你没装的工具，重复运行也安全，不会装重。

小提示：从公开仓库拉脚本这种操作，装之前顺手看一眼脚本内容是个好习惯，尤其是这种 curl | bash 的一键式安装。这个项目本身是开源的，脚本、hook 都能在仓库里翻到，作者也明确说了它不联网上报、没有任何遥测，装完之后零网络请求。

4.2 它能装到哪些工具上

这是它让我比较惊喜的一点——覆盖面非常广，不是只服务某一家。目前支持 Claude Code、Codex、Gemini CLI、Cursor、Windsurf、Cline、Copilot 等三十多种主流 Agent 工具。

为什么它能支持这么多工具？这恰恰源于它"本质是提示词"的朴素设计。因为它不依赖任何一家工具的底层接口，只是往各家的"规则文件/记忆文件"里塞同一套约束，所以哪个工具支持自定义规则，它就能装到哪个上——适配成本极低。这也给了我们一个反向的启发：这种"用规则约束行为"的做法，本身就是跨工具通用的，你今天在这家工具上练熟的心法，换一家几乎零成本迁移。相比之下，那些深度绑定某一家接口的方案，虽然可能做得更精细，但你一换工具就得重学。朴素有朴素的好处，通用性就是其中之一。

如果你只想给其中某一个装，也能单独指定，比如通过技能注册表给 Cursor 单独装：

npx skills add JuliusBrussee/caveman -a cursor

4.3 日常怎么用

装好之后，在 Claude Code、Codex、Gemini 上它默认就是开启的，从第一句话就开始省字，不用敲任何命令。想手动控制的话，几条命令就够了：

其中 /caveman-compress 我要单独夸一句：前面说过这工具只省输出 Token，但这条命令是个例外——它会把你的长期记忆文件（比如项目里那份 CLAUDE.md）本身改写成精简版，据作者给的数据能压掉四成多的体积。这个文件每次开新会话都要被加载进上下文，所以它一次压缩、后续每次会话都省输入，这部分是实打实一直省下去的。它还会贴心地把原文件备份成 .original.md，不怕改坏。

4.4 隐私、安全与"想卸载怎么办"

装第三方工具，我一向最先看两件事：它会不会偷偷上传我的东西，以及好不好卸干净。这两点这个工具的表现都让我放心。

隐私方面，它的本质是一段本地提示词加几个本地脚本，作者明确说了它不做任何遥测、不上报数据、没有账号也没有后端服务。装完之后除了安装那一下要从公开仓库拉文件，运行时是零网络请求的——那条查看统计的命令，读的也是你本地磁盘上已有的日志。对于要接触你代码和工作流的工具来说，这种"本地优先、不联网"的设计是加分项。

安全方面，还是那句老话：任何 curl ... | bash 这种一键脚本，装之前花一分钟把脚本内容扫一眼是个好习惯，尤其是要装到你天天写代码的环境里。好在这个项目全程开源，脚本、安装逻辑、安全说明都在仓库里摆着，你完全可以先看明白再动手。

卸载方面，因为它没往你系统深处塞什么东西，卸载也很干净——安装脚本一般都配了对应的卸载参数，跑一下就能移除它写进各工具的规则文件，不会污染你其他配置。这种"来去都清爽"的特性，让人敢放心一试，不用担心装了就甩不掉。

4.5 装完好像没生效？先排查这几点

我第一次装的时候也遇到过"感觉没变化"的情况，后来发现多半是下面几个原因，你按顺序排查一遍基本能解决：

• 工具没重开：不少工具是在启动时读取规则文件的，装完记得把你的编程助手关掉重开一次，让它重新加载。
• 默认开启与否因工具而异：在一部分工具上它装完就自动生效，另一部分则需要你手动触发一下（比如敲那条开启命令，或者在对话里说一句"精简模式"）。没生效时先试试手动开一下。
• 规则文件没被识别：有些工具的规则文件放在特定目录、用特定文件名才会被读取。如果手动开也没用，去确认一下它写入的文件路径，是不是你这个工具真正会加载的那个。
• 实在搞不定，让 AI 自己修：这是我觉得最妙的一招——直接在仓库目录里打开你的编程助手，让它读一读项目里的说明文档，然后自己把安装修好。等于让 AI 读懂工具、自己给自己动手术，很符合这套工具"让智能体自助"的气质。

排障这事别硬扛，大多是"没重开"或"没手动开"这种小问题，对着上面几条走一遍，八九不离十。

五、实测数据与那本"诚实账本"

一个工具好不好，光看宣传没用，得看数据，尤其得看它敢不敢把不利的数据也摆出来。这一点上，作者的态度让我挺有好感——他在项目里专门放了一份叫"诚实数字（Honest Numbers）"的文档，把这工具省不了的地方也一五一十讲清楚了。

5.1 十个真实任务的实测

作者用 Claude API 跑了 10 个日常开发任务，覆盖写代码、修 Bug、配数据库连接池、代码审查、Docker 多阶段构建等场景，用真实 Token 计数对比了"普通模式"和"穴居人模式"的输出量：

从这张表能读出一个很有意思的规律：越是那种"容易被模型过度解释"的任务，省得越狠。像"实现错误边界""解释重渲染"这种，模型平时特别爱长篇大论，压缩后能省八成以上；而像"回调改 async/await"这种本身就没什么可废话的任务，只省了两成——因为原本也没多少水分可挤。测试脚本作者一并开源了，你可以自己复现，这点我很认可。

我想特别提醒一句怎么"正确地读"这张表。别只盯着那个 65% 的平均值，更值得看的是22% 到 87% 这个巨大的区间。它恰恰说明这工具的效果高度依赖任务类型，不是一个恒定的固定值。真正会用它的人，看的不是"平均能省多少"，而是"我手头这类活儿，落在区间的哪一头"。如果你的日常大量集中在表格里那些高压缩率的任务（解释、排查、构建这类容易展开的），那这工具对你就是净省；如果你天天干的是短平快的小改动，那它给你的价值就更多在"读着舒服"而非"账单变薄"。同一个工具，对不同人的价值可以差出好几倍，关键看你把它放进什么样的工作流。 这也是我一贯不迷信"平均数"的原因——平均值会把差异抹平，而差异里才藏着对你真正有用的信息。

5.2 必须泼的三盆冷水

现在说说那份"诚实账本"里最该被划重点的部分。如果只看 65% 就冲进去装，你多半会失望。

第一盆冷水：只省"输出"，不省"输入"和"推理"。 大模型一次调用的开销由输