技能作者能从 Caveman 的 SKILL.md 学到什么

Caveman 是公开发布的输出风格技能里 star 最多的之一，而它的 SKILL.md 只有 89 行。对技能作者来说，这是一个很好的标本，和“像原始人一样说话”能不能帮你省钱是两回事。这份文件展示了一个热门技能怎样措辞规则、什么时候让模型打破规则、怎样把状态放在 markdown 之外，以及在哪里把工作交给兄弟技能。项目文档还有一个大多数技能仓库没有的习惯：专门有一页列出它没有的节省数字。

本文把这份文件当作模板来读。读者是构建和维护技能、子智能体和 SKILL.md 工作流的人，所以不讲安装步骤，也不做产品对比。关于节省量的证据只在会改变你编写或测试自己技能的方式时才简要提及。来源于 2026 年 10 月 29 日打开阅读，本文没有亲手运行过 Caveman，凡属项目自己的数字都标明是项目自己的。

这份文件里有什么

v4.0.1 的 SKILL.md 有一小段 frontmatter，正文是九条编号规则、七种规则不再适用的情形，以及发送前的四项检查。用 tiktoken 的 o200k_base 分词器在本地数了一遍（它只是近似，并不等同于任何 Claude 或 Codex 模型实际计费的分词器），整份文件是 1,158 个 token：frontmatter 约 70 个，正文 1,087 个。项目 README 估计其语音规则约占 1,160 个输入 token，两个数字吻合。

在做任何分析之前，有两个细节值得注意。这份文件完全没有提到项目的代理、CLI 或账号，所以这个技能作为一个普通 markdown 文件，在任何会加载技能的宿主里都能用。而且它里面没有超过一两行的示例，这让正文的体量保持在项目所说的成本附近。这些选择是第一课：风格技能要想便宜，应当是一份规则清单加少量对比样例，而不是一篇教程。

写出站得住的简洁输出规则

大多数“请简洁”的指令会以两种方式失败：要么太含糊，改不了行为；要么压缩得太狠，少掉一个“not”就把指令变成了它的反面。Caveman 的规则走了一条有启发性的中间路线，其中几个习惯可以迁移到任何控制模型写作方式的技能上。

写明每条规则防止的失败。 “为什么”部分给出四条编号理由，第四条是护栏：清晰优先于压缩。规则 4 接着说冠词可省但“meaning never”，并列出必须保留的词：not、never、no、only 和 except。点名“绝不能丢的具体东西”的规则，比笼统地要求小心更容易让模型遵守。

成对给出坏例子和好例子。 规则 1 把一段先道歉再诊断的长回答，对比为一句话：说明令牌过期检查用错了比较运算符。规则 4 把一条被写坏的迁移警告对比为一条干净的。每一对只花几十个 token，比一段描述更管用。样例要留给模型通常会出错的情形，不要用在本来就显而易见的情形上。

限制单位，而不是长度。 规则 5 采用借自 ASD-STE100 的下限，这是一种用于飞机维护手册的受控英语标准：最多 20 个词、主动语态、一物一词、只有指代明确时才用代词。句长上限比“要简短”更容易检查，也能在不让模型猜目标字数的情况下产生短输出。

明确保护载荷。 规则 6 让代码块、命令、路径、API 名称和引用的错误信息保持原样，并要求展示改动的行加上下一两行上下文，而不是整个文件。这与 JetBrains 测试这个技能时发现的划分一致：智能体的输出以代码、diff、工具调用和精确的错误文本为主，技能不动它们，所以只有叙述部分可以压缩。如果你自己的输出类技能没有说明什么不可动，模型就得猜，而猜的地方正是静默损坏的来源。

把工具使用期间的文字单独处理。 规则 7 针对工具调用之间的闲聊：常规调用之间不写文字，多步运行前一行，阶段切换一行，结束时一行结果。在智能体循环里，大量 token 花在这里，而且它和回答问题是不同的行为。如果你的技能会用在智能体会话里，给工具运行的叙述单独写一条规则，而不要把它并入笼统的风格段落。

禁止表演。 规则 9 说：绝不宣告模式、绝不加前缀、绝不为了像原始人而多加一个词，更短时就用平实的措辞。强加人设的技能往往会长出装饰性行为，花 token 却没有价值。“如果修饰没有更短就去掉”这样一条规则，从源头上消除了这种失败模式。

规则 8 对任何会被多种语言用户使用的技能作者都值得再看一眼。它说压缩的是风格，不是语言，明确的回复语言指令优先，技术术语和错误信息保持原样。只用英文示例写成的风格技能可能悄悄地强迫英文回复；一行规则就能防止这一点。

注册表里的相邻技能从其他方向覆盖了同一片领域。humanizer 技能对抗的是听起来像 AI 的文字，这是和长度不同的另一条轴；writing-skills 是编写和测试技能本身的指南。把任何一个和 Caveman 的文件并排阅读，就能看出这门手艺有多少是相通的：说明行为、点名失败、做测试。

Frontmatter 与激活

Caveman 的 description 很短，而且触发词密集：先是一行概述，然后是斜杠命令，再是短语“caveman mode”“talk like caveman”“be brief”和“less tokens”，最后是一句关于怎么关掉它的话。Claude Code 技能文档说，描述会加载进上下文，让模型知道有哪些技能；完整正文只在技能被调用时加载；description 与 when_to_use 合起来的文字在技能列表里会在 1,536 个字符处被截断，所以主要用途应当放在前面。Caveman 的描述远低于这个上限，除非你真的需要更多空间，描述就应该待在那个水平。

项目里有三种激活方式值得照搬或改造。

1. 状态放在 markdown 之外。 持久性部分告诉模型保持这个模式，直到用户说“stop caveman”或“normal mode”，并且在有钩子时转述钩子给出的 Caveman mode: <mode> 值。在没有钩子的宿主上，它退回到报告自己遵循的模式。markdown 规则可以说“保持开启”，却不能保证模型在很长的会话后还记得；重新注入模式的钩子可以。项目的 INSTALL.md 记录了 Claude Code、Codex 和 Cursor 上基于钩子的启动方式。这是项目对其设计的描述，本文没有找到对 Codex 或 Cursor 钩子的独立测试。
2. 脚本化运行默认关闭。 INSTALL.md 说，claude -p 和 Agent SDK 运行无论配置如何都以 Caveman 关闭的状态启动，这样解析回复的工具拿到的是纯文本，要开启就用 /caveman 或环境变量 CAVEMAN_DEFAULT_MODE。如果你的技能会改变输出格式，要决定非交互运行默认得到什么，并把开关写进文档。
3. 别名路由到兄弟技能。 文件说 /caveman ultra 和 /caveman wenyan 是别名，应遵循 ultracave 或 megacave 技能而不是这个技能，而 /caveman status 只报告模式、不改变任何东西。基础技能之所以小，是因为更重的模式放在其他技能里，下一节会接着讲。

对于你不希望模型自行触发的技能，同一份文档描述了 disable-model-invocation: true，它会阻止自动加载，也会阻止该技能被预加载进子智能体。具有持久影响的风格技能适合手动调用，因为模型在错误的时刻自动加载它，会改变这场对话里之后每一条回复。

渐进式披露的实际做法

渐进式披露的意思是模型先读一点，需要时再加载更多。对技能而言，宿主里有两层：始终可见的描述，以及调用时加载的正文；你自己还可以建第三层：正文指向的辅助文件和兄弟技能。Caveman 三层都用了。

语音技能刻意保持狭窄。更强的压缩放在 ultracave 和 megacave 里，记忆文件压缩器 /caveman-compress 是自己的技能，有自己的基准测试。README 的输出表来自对 3.1.0 规则的 10 个问题的测试，项目说它还没有重跑，这个表说明了为什么这样拆分有用：对照一个简单的“Answer concisely.”基线，/caveman 在中位数上多省约 3%，/ultracave 多省约 35%。想要轻量的用户得到一个便宜的技能；想要更多的用户选择另一个文件，而不是每次加载都为它的文字付费。

Claude Code 文档从成本角度强化了这一点：技能一旦加载，其内容会在之后的轮次里一直留在上下文中，所以每一行都是反复发生的 token 成本，指导原则是说明要做什么，而不是叙述怎么做和为什么。Caveman 的文件在规则部分遵循了这条指导，把字数花在对比样例和例外上。如果你想更深入地了解怎样拆分大技能，skill-creator 技能和 claude-md-progressive-disclosurer 技能是注册表里与本主题最接近的条目；后者把同样的思路用在 CLAUDE.md 文件上。

与其他技能组合

输出风格类技能是最难组合的一种，因为它会碰到每一条回复，所以会和同时加载的任何其他东西冲突。Caveman 的文件用文字解决了这些冲突，它的做法本身就是一个模板。

点明风格不碰什么。 例外清单说，凡是持久化到聊天之外的内容都用平实语言写：代码、注释、提交信息、文档、issue、拉取请求、工单、记忆文件和发给第三方的消息，/caveman-compress 例外，因为压缩就是它的工作。如果另一个技能要生成提交信息或拉取请求描述，Caveman 就让开。没有这一条，简短的语气就会渗进别人以后要读的产物里。

让框架决定何时说，让技能决定怎么说。 第六条例外说，当框架要求状态行或确认时，模型就给出。文件自己的措辞是：框架决定你何时说话，技能决定你如何说话。这一句话是个优先级规则，你可以直接搬进自己的技能：风格技能永远不应压制工作流所要求的输出。

给安全内容单独的模式。 安全警告、不可逆操作、一个片段可能搞乱的步骤顺序，以及困惑的用户，都会触发完整的句子，然后再恢复简短风格。例外中的第七条补充说，当模型向用户提问或给出选项时要写完整的句子，这样回答第一次就能回对。任何改变语气的技能都应该说明什么时候安全信息可以压过它。

预期会和写作质量类技能冲突。 要求更完整、更自然文字的技能，和要求更少字数的技能，会对同一句话有分歧。文件没有按名字解决这种情况，而是按范围解决：持久化的写作被豁免。如果你要发布一个风格技能，就列出它不该碰的产物类型，并说明两条风格规则相遇时哪个技能优先。关于在按模型路由的智能体里同时运行多个技能的成本，GPT-6 面向智能体技能的模型路由和 Opus 5.5 与 Sonnet 5.5 面向智能体技能这两篇文章讲的是模型这一侧的取舍。

代理和 CLI 部分是另一种组合。Caveman 的 v4.0.0 发布说明把 CLI 描述为唯一的安装方式，项目的 SECURITY.md 有一张数据流表，表明技能和经典钩子不会调用 Caveman 的任何服务，本地代理把请求转发给你选的提供商，而可选的已登录路由器会把最近的轮次发给 Caveman Cloud。对于你在 markdown 文件之外发布的任何东西，这张表都是个好榜样：按组件说明内容去哪里、是否需要账号。本文没有审计代码、签名设置或服务。

省 token 数字教会我们的关于“说法”的事

技能作者很想在 README 里写一个百分比。Caveman 的历史是个案例，说明这样做的代价，而其中的更正才是有用的部分。

2026 年 4 月 4 日的发布帖说“75% less word”，早期 README 截图重复了“cutting ~75% of tokens”。项目当前的“诚实数字”页面说，早期的统计版本套用了固定的 65% 输出比例，没有提交过经审阅的结果，现在的报告忽略那些估算字段，而且基准测试工具里没有提交经审阅的、针对默认冗长回复的输出减少原始结果，这一行被标为未公布。它还把技能增加的输入成本列为尚未测量，并有一节专讲技能亏的场景：简短的编码问答，固定的提示词开销可能超过任何节省；按请求计费的智能体，比如 GitHub Copilot；以及一个 Cursor 对比，用技能是 4.3M token，不用是 1M，项目说无法复现。

README 自己的测试也标注了局限。输出表里有一个对照行“Answer concisely.”，它完成了大部分缩短：按 README 的数字，无指令是 6,983 个 token，加这句话是 4,334 个，用 /caveman 是 4,119 个，对照组比基线低 37.9%，技能又比对照组低 5.0%。这些百分比是本文根据 README 的总数推算的，不是项目自己声明的数字。测试是在 3.1.0 规则下用 claude-opus-5-5 对 10 个问题跑了一次。输入侧的数字，输入 token 少 33.2% 和用可选路由器成本降低 54%，属于语音技能之外的组件，是自报数字，并带着关于旧引擎和只完成一半的运行的注意事项。

由此得出两点。第一，为你没有测量的东西保留一个“未公布”行。项目把这种状态写出来的习惯比应有的少见，也正是这个习惯让本文能够不靠猜测，就把 75% 那句话归为营销文案。第二，把每个数字和设置绑在一起。JetBrains 的第一次运行和最终运行，同一团队、同一基准，相差三倍多，原因是样本太小；一个没有运行次数的百分比，什么也告诉不了读者。

在这个设计之下还有一项相关的研究结果。arXiv 上的一篇论文 2606.24083，在八个模型和五个数据集上分别评估了输出压缩和输入压缩。作者报告说，输出压缩让大多数 API 模型的实际成本每个模型降低 1.4 到 2.4 倍，输入压缩则抬高了净成本，而且输出端的节省在短答案基准上有一部分是机械性的。README 把这篇论文标为 Adobe Research，本文没有对照论文首页核实这一点，而且这篇论文测的是基准问题上的提示词级约束，不是编码智能体。对作者的实用教训与 Caveman 自己的一致：缩短模型说的话，不要动用户的提示词。

测量你自己的 SKILL.md

技能有两种成本，是 README 里的百分比藏起来的。第一种是文件本身：它的 frontmatter 一直在上下文里，正文在调用时加载并在对话剩余部分里一直保留。第二种是对输出的影响。第一种可以精确测量，第二种只能靠比较真实运行。

第 1 步：给文件计数。 下面的脚本把 SKILL.md 分成 frontmatter 和正文并输出 token 数，同时给出在几种输出对输入价格比下，抵回一次未命中缓存的读取所需节省的输出 token 数。它用的是 o200k_base，一个近似分词器。如果你能用提供商自己的 token 计数接口跑你的技能，就优先用那个数字。

"""Count the tokens a SKILL.md adds, split into frontmatter and body.

Usage: python skill_tokens.py path/to/SKILL.md [output_price_ratio ...]
Tokenizer: tiktoken o200k_base, an approximation, not Claude's tokenizer.
"""
import sys, re
import tiktoken

enc = tiktoken.get_encoding("o200k_base")
text = open(sys.argv[1], encoding="utf-8").read()
m = re.match(r"^---\n(.*?)\n---\n(.*)$", text, re.S)
front, body = (m.group(1), m.group(2)) if m else ("", text)
n_front, n_body, n_all = (len(enc.encode(x)) for x in (front, body, text))
print(f"chars={len(text)} words={len(text.split())}")
print(f"frontmatter_tokens={n_front} body_tokens={n_body} file_tokens={n_all}")
ratios = [float(x) for x in sys.argv[2:]] or [4, 5, 8]
for r in ratios:
    # saved output tokens that repay one uncached read of the whole file
    print(f"output/input price ratio {r:g}: break-even saved output tokens = {n_all / r:.0f}")

在 v4.0.1 的 Caveman 文件上，这个脚本输出总计 1,158 个 token。盈亏平衡模型很简单：如果一个输出 token 的价格是一个输入 token 的 r 倍，那么文件在节省约等于它自身 token 数除以 r 个输出 token 时，就抵回了一次未命中缓存的读取。上面引用的论文说输出 token 的定价通常是输入 token 的四到八倍，对一个 1,158 个 token 的文件，就得到下面的门槛。

这是你的技能必须做到的工作量下限，不是预测。缓存命中的读取更便宜，而留在上下文里的正文每一轮都会被再读一次，所以真实的平衡取决于缓存和对话长度。项目自己也把技能的输入成本列为尚未测量。关于缓存占主导的智能体会话的成本结构，本站上最接近的同类文章是 Codex 用量限制与智能体工作流和超快与专业档位的成本规划。

第 2 步：跑成对的 A/B 对比。 从你自己的使用里选一个可重复的任务，有技能和没技能各跑，每组至少五次。JetBrains 的成对设计是个好模板：两组跑同样的任务，一组强制激活技能，让你看到上限，然后再跑第二遍，让技能自己触发。记录提供商计费的总量，来自用量或账单页面，不要用输出长度。项目自己的建议是：在同一任务上比较开启和关闭技能时提供商计费的总量，总量上升就关掉。

第 3 步：加一个简单指令的对照。 README 对作者最强的教训就是“Answer concisely.”那一行。如果你系统提示里的一句话就拿到了技能的大部分缩减，技能的边际价值就在超出它的那部分。每次对比都要跑这个对照。

第 4 步：单独给质量打分。 token 数不能证明简短的回答保留了某个注意事项。JetBrains 按任务统计结果，8 个更好、10 个更差、64 个持平，并用符号检验检验差异。更小的版本是为每个任务列一份必须包含的事实清单，手工打分。

第 5 步：看成本，不只看 token。 JetBrains 有一个任务超过 20 万 token 的计价档位，计费 8.29 美元对 0.33 美元，把整次运行的成本合计从 36.39 美元推到 40.60 美元，尽管输出 token 下降了。一次社区运行报告计费输出下降 44.1%，总成本却上升 0.06%。要看发票上的那一行，求平均之前先看离群值。

上面的报告指出了你自己的测量接下来该往哪里看。在这个样例里，最大的消耗来源是一个始终加载的大 CLAUDE.md，而不是模型的回复。作者在自己关于记忆文件压缩器的帖子里也说了同样的意思，直接看比转述更清楚。

压缩每一轮都要加载的文件的技能，处理的是输入，项目报告 /caveman-compress 把五个文件从 6,198 个 token 降到 4,138 个，每个文件降幅 22.8% 到 49.1%。这是自报数字，而且和语音技能是不同的机制。对作者来说，要点在于最大的杠杆可能是你一直在加载的某个文件。如果你想把上下文成本纳入自己的工作流来追踪，注册表里的 context-compression 和 token-budget 技能值得看看。

发布前检查清单

对任何改变智能体写作方式或阅读量的技能，都可以用这份清单。

1. 描述把主要用途和触发短语放在前面，并且远低于 1,536 字符的列表上限。
2. 每条规则命名一个行为，并在有帮助时说明它防止的失败。
3. 每条容易被过度应用的规则都有一个坏例子和一个好例子。
4. 文件列出必须保持原样的东西：代码、命令、路径、错误信息、数字和否定词。
5. 例外说明了安全、不可逆操作或用户困惑在什么时候压过风格。
6. 提交信息、文档、工单和记忆文件这类持久化产物被豁免，或者技能解释了为什么不豁免。
7. 需要状态行或确认的框架优先于风格。
8. 必须撑过长会话的状态由 markdown 之外的东西保存，或者技能说明它可能漂移。
9. 可选的深度放在兄弟文件或兄弟技能里，而不是基础正文里。
10. 文件的 token 数和盈亏平衡点已经写下来，并说明了测量方式。
11. README 里的任何节省数字都写明设置、运行次数、模型和日期，未测量的项目要说明未测量。
12. 脚本化和非交互运行有文档化的默认值。

局限

• 本文没有运行 Caveman。本地唯一的计算是对 v4.0.1 SKILL.md 的 tiktoken 计数，而 o200k_base 不是 Claude 或 Codex 计费所用的分词器。
• 所有标为项目自己的数字，包括输出测试、33.2%、54% 以及从 6,198 到 4,138，都来自仓库文档，没有复现。5.0% 和 37.9% 是本文根据 README 总数推算的。
• JetBrains 的结果涵盖单一模型、低推理强度、单一基准、强制激活。论文的所属机构取自 README，没有对照论文首页核实。
• 外部 A/B 结果，包括计费输出下降 44.1% 的结果和 Cursor 对比，是按项目“诚实数字”页面的转述阅读的，没有读原始 issue 帖子。
• Codex 和 Cursor 的激活方式只依据 INSTALL.md 描述。没有找到对这些钩子的独立测试。
• 截至 2026 年 10 月 29 日，agentskills.codes 注册表里没有官方 JuliusBrussee/caveman 仓库的页面。有几个名为 caveman 的页面来自其他仓库的副本，例如 caveman-damian87x，本文没有把那些文件与官方文件做比较。
• v4.0 的 CLI、代理、路由器和签名设置没有审计。star 数、fork 数和版本变化很快；2026 年 10 月 29 日的 star 数约为 115,900。

常见问题

Caveman 的 SKILL.md 对技能作者的主要启发是什么？

让常驻的风格技能保持小而具体。这份文件用九条规则、对比样例、一份例外清单和一个简短的自查，大约 1,158 个 token，并把更重的模式移到兄弟技能里。

Caveman 的 SKILL.md 增加多少 token？

用 tiktoken 的 o200k_base 分词器在本地数 v4.0.1 的文件，得到 1,158 个 token：frontmatter 约 70 个，正文 1,087 个。这个分词器是近似的。README 估计约 1,160 个输入 token。

像 Caveman 这样的风格技能在智能体工作里真的省钱吗？

最好的独立测量来自 JetBrains，在强制激活下输出 token 少 8.5%，没有检测到质量损失，但因为有一个任务超过了计价档位，它的完整运行成本合计高出 11.6%。输出 token 预期是个位数，请自己测量账单。

我该如何测量自己写的技能？

先给文件计数，再跑成对的 A/B 任务，每组至少五次，加上一个一句话指令的对照、提供商计费的总量和打过分的结果。一次只切换一个组件，这样你就知道是哪一个改变了数字。

我能把 Caveman 和其他技能一起用吗？

这份文件按范围组合：持久化的写作如代码、提交信息和文档保持平实，框架的状态行总是照给，安全信息用完整句子。如果另一个技能设定了不同的写作风格，要为每种产物类型决定哪个优先。

agentskills.codes 注册表里有 Caveman 的页面吗？

截至 2026 年 10 月 29 日，官方 JuliusBrussee/caveman 仓库没有。注册表里有些名为 caveman 的页面来自其他仓库，它们是不同的文件。

来源

来源于 2026 年 10 月 29 日打开阅读。

• GitHub 上的 JuliusBrussee/caveman，README 和仓库元数据
• Caveman INSTALL.md 和 SECURITY.md
• Caveman Honest Numbers（诚实数字）
• Caveman v4.0.0 发布说明和 v4.0.1 的 SKILL.md
• JetBrains AI 博客：Speaking to AI Agents Like Cavemen Saves 65% of Tokens. We Test.
• arXiv 2606.24083：Cavewoman，对 caveman 风格压缩的双通道评估
• Elasticsearch Labs：elastic-caveman
• Claude Code 文档：Skills
• JetBrains 在 X 上的帖子和 Julius Brussee 在 X 上的帖子