ponytail 基准实验中的 caveman 技能文件：一份把 Agent 通信 Token 压缩约 75% 的提示词工程设计解析

本文围绕 benchmarks/arms/caveman-SKILL.md 展开——这是一个被"领养"（vendored）进 ponytail 仓库的第三方提示词技能文件，它让 AI Agent 以"原始人式"极简口吻回复，在保留完整技术信息量的同时把 token 消耗压低。读完本文，你既能完整掌握这份技能文件的规则结构、六级强度体系与"自动回退清晰模式"安全阀的设计，也能看懂 ponytail 仓库如何把它作为基准实验对照组之一（caveman arm）驱动，以及实测数据揭示了"压缩散文"与"压缩代码"两条优化路线各自的边界。

1. caveman 是什么：一份可复用的"压缩通信"提示词

caveman-SKILL.md 是 JuliusBrussee/caveman 项目（MIT 许可）的 SKILL.md 文件，被原样存放于本仓库 benchmarks/arms/ 目录下，作为 ponytail 基准实验中与 baseline、ponytail 并列的第三组（arm）提示词来源（见 benchmarks/promptfooconfig.yaml 第 8 行注释）。

它的文件头是标准的技能元数据（YAML front matter），定义了技能的身份、定位与触发方式：

name: caveman
description: >
  Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman
  while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra,
  wenyan-lite, wenyan-full, wenyan-ultra.
  Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
  "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.

注意两点：

• "Cuts token usage ~75%" 是技能自身描述中的预期目标（对散文类回答而言），而非基准实验的通用结论——实测数字见第 5 节；
• 触发方式覆盖自然语言（"less tokens"、"be brief"）、斜杠命令（/caveman）和意图触发（用户要求 token 效率时），这说明一份技能文件的 description 本身就是"路由提示词"：Agent 依据它决定何时加载该技能。

一句话概括其定位：caveman 压缩的是"说"，不是"写"。ponytail 的 skills/ponytail/SKILL.md 在 Boundaries 一节明确两者分工："Ponytail governs what you build, not how you talk (pair with Caveman for terse prose)"；仓库根 README 的 FAQ 也总结为 "Caveman shrinks what the agent says; ponytail shrinks what it builds"。

2. 核心规则一：Persistence——跨轮次不衰减，且有明确的关闭开关

文件正文第一条指令是：

Respond terse like smart caveman. All technical substance stay. Only fluff die.

紧接着是 Persistence（持久化）小节：

ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".

Default: full. Switch: /caveman lite|full|ultra.

这里的设计值得提示词工程师注意：

1. 对抗"风格漂移"。多轮对话中，系统提示词的约束力会随轮次稀释，Agent 容易"漂回"正常措辞。"No revert after many turns. No filler drift" 直接点名这个失败模式；"Still active if unsure" 则把默认行为从"不确定时回退"反转为"不确定时保持"——这是廉价的健壮性设计。
2. 显式且唯一的退出路径。只有 "stop caveman" 或 "normal mode" 能关闭模式，避免模糊措辞导致的状态混乱。
3. 默认值显式声明：默认 full 强度，切换命令为 /caveman lite|full|ultra。

3. 核心规则二：Rules——精确的"删什么 / 留什么"清单

压缩类提示词最常见的失败是过度压缩：把技术细节一起压没了。caveman 的做法是把规则写成白名单与黑名单：

Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.

逐条拆解：

删除项	示例	保留项	原因
冠词	a / an / the	技术术语原样	术语是接口，动它会损失精确性
填充词	just / really / basically / actually / simply	代码块逐字节不变	代码不是通信对象
客套话	sure / certainly / of course / happy to	报错信息原样引用	报错是用户排查的锚点
含糊措辞（hedging）	"might / probably" 类	短句替代长表达	"big" 替代 "extensive"，"fix" 替代 "implement a solution for"

并给出统一的句法模板：

Pattern: [thing] [action] [reason]. [next step].

用一个具体对照示范"删与留"的分界：

Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..." Yes: "Bug in auth middleware. Token expiry check use < not <=. Fix:"

注意 Yes 版本里 < 与 <= 的区别被原样保留——压缩散文，绝不压缩语义。这正是第 6 节基准实验里"caveman 在代码行数上介于 baseline 与 ponytail 之间"的根源：它的 Rules 明确写了 "Code blocks unchanged"。

4. 核心规则三：Intensity——六级压缩强度体系

文件用一张表定义了六档强度，覆盖"现代英语压缩"与"文言文压缩"两条路线：

Level	What change
lite	No filler/hedging. Keep articles + full sentences. Professional but tight
full	Drop articles, fragments OK, short synonyms. Classic caveman
ultra	Abbreviate (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough
wenyan-lite	Semi-classical. Drop filler/hedging but keep grammar structure, classical register
wenyan-full	Maximum classical terseness. Fully 文言文. 80-90% character reduction. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其)
wenyan-ultra	Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse

设计上有两个值得借鉴的点：

• 强度是正交参数。同一套"删什么"规则，通过强度档位调节"删多狠"，而默认档位（full）写在 Persistence 小节里，使切换命令 /caveman lite|full|ultra 有明确语义；
• 为中文场景专门设计了 wenyan 系列。英文的 ultra 靠缩写（DB/auth/fn）压缩，但中文再"删虚词"空间有限，于是改用文言文这一天然高信息密度的语体，并给出可操作的语言学约束（动词前置于宾语、省略主语、使用之/乃/為/其等文言虚词），甚至量化了预期压缩率（80-90% 字符缩减）。

文件随后用两道真实技术题演示六档的梯度输出。

例 1："Why React component re-render?"（为什么 React 组件会重新渲染？）

• lite: "Your component re-renders because you create a new object reference each render. Wrap it in useMemo."
• full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo."
• ultra: "Inline obj prop → new ref → re-render. useMemo."
• wenyan-lite: "組件頻重繪，以每繪新生對象參照故。以 useMemo 包之。"
• wenyan-full: "物出新參照，致重繪。useMemo .Wrap之。"
• wenyan-ultra: "新參照→重繪。useMemo Wrap。"

例 2："Explain database connection pooling."（解释数据库连接池）

• lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
• full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
• ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
• wenyan-full: "池reuse open connection。不每req新開。skip handshake overhead。"
• wenyan-ultra: "池reuse conn。skip handshake → fast。"

注意两个例子里技术实体（useMemo、DB connection pooling 的机制）在所有档位都完整存活，变的只是包装。强度梯度不改变技术内容，只改变信息密度——这是该技能区别于"随意让它少说点"的可靠之处。

5. 核心规则四：Auto-Clarity——在关键时刻自动回退到清晰模式

"极简口吻"最大的风险是：在安全警告、不可逆操作确认这类场景中，碎片化表达可能引发误读。caveman 用 Auto-Clarity 小节为这个风险装了保险丝：

Drop caveman for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.

四类强制回退场景：

1. 安全警告；
2. 不可逆操作的确认；
3. 步骤顺序被碎片化后可能误读的多步流程；
4. 用户要求澄清或重复提问（用户信号优先于风格指令）。

文件给了一个破坏性操作的示范输出：

Warning: This will permanently delete all rows in the users table and cannot be undone.

DROP TABLE users;

Caveman resume. Verify backup exist first.

结构是"清晰部分 → 明确宣告恢复模式（Caveman resume）→ 回到极简"。可以推断这条规则在 ponytail 的基准实验中被刻意保留：benchmarks/ 的 agentic 基准把"安全性 100%"列为独立考核维度（见 benchmarks/results/2026-06-18-agentic.md），一个会在危险操作上含糊其辞的提示词无法通过。

最后 Boundaries 小节收束全文：

Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.

代码、commit message、PR 描述一律正常书写——再次确认它只治理"对话"。

6. 在 ponytail 仓库中的落地：作为基准实验的 caveman arm

理解完技能文件本身，再看 ponytail 仓库如何"用它说话"。

6.1 装载机制：整份文件即系统提示词

benchmarks/arms/caveman.js（共 8 行）是 promptfoo 的自定义 prompt 工厂：

// Caveman arm: caveman SKILL.md (full) as the system prompt.
const fs = require('fs');
const path = require('path');
const system = fs.readFileSync(path.join(__dirname, 'caveman-SKILL.md'), 'utf8');
module.exports = ({ vars }) => [
  { role: 'system', content: system },
  { role: 'user', content: vars.task },
];

要点：它读取整个 caveman-SKILL.md 作为 system 消息（含 front matter），user 消息只放任务文本。对照组同样简单直接——benchmarks/arms/baseline.js 是"无技能、只有任务"，benchmarks/arms/ponytail.js 则是把本仓库自己的 skills/ponytail/SKILL.md 作为 system 提示词。三组臂在 benchmarks/promptfooconfig.yaml 中注册为三个 prompt（file://arms/baseline.js、file://arms/caveman.js、file://arms/ponytail.js），配合 3 个 Anthropic 模型（Haiku 4.5 / Sonnet 4.6 / Opus 4.8）与 5 个日常编码任务（邮箱校验、JS debounce、CSV 求和、React 倒计时、FastAPI 限流），每格 10 次重复、取中位数。

度量侧由两个 JS 断言构成（见 benchmarks/README.md 的 Metrics 表）：

• benchmarks/loc.js：确定性代码行数指标，统计围栏代码块中非空、非注释的行（pass: true 恒真，只做测量不做门控）；
• benchmarks/correctness.js：正确性门控，对 email/debounce/CSV 任务实际执行生成的代码，对 React/FastAPI 做结构性检查。

6.2 实测定位：caveman 赢散文、输代码，恰好落在中间

benchmarks/README.md 公布的单轮（single-shot）中位数结果（10 次运行；成本经 30 次复核）：

代码行数（5 任务合计）

arm	Haiku	Sonnet	Opus
baseline (no skill)	518	693	256
caveman	116	120	67
ponytail	39	44	51

成本（USD，5 任务）

arm	Haiku	Sonnet	Opus
baseline (no skill)	0.030	0.137	0.137
caveman	0.014	0.046	0.072
ponytail	0.011	0.035	0.079

时延（秒）

arm	Haiku	Sonnet	Opus
baseline (no skill)	37.7	124.1	58.7
caveman	14.9	34.7	23.1
ponytail	9.9	20.1	18.0

数据形状与技能设计完全吻合：baseline 的 518~693 行里混着大量散文与多个备选方案，caveman 靠 "Code blocks unchanged + prose 全删" 把代码行数压到 baseline 的约 1/4~1/5，而 ponytail 从"不写代码"层面再压 2~3 倍。benchmarks/README.md 的 Notes 对这一分工的表述最精确："Caveman is a prose-compression skill (it leaves code 'normal'), so it lands between baseline and ponytail on code size and wins mainly on prose tokens."

6.3 逐任务对照：caveman 在 agentic 会话中的另一面

benchmarks/results/2026-06-12-caveman-vs-ponytail.md 记录了每个任务一个全新 subagent 的 5 任务 agentic 跑分（agent 总 token，含 thinking）：

汇总	Baseline	Caveman	Ponytail v1
总 token	161,955	138,410	143,588
总墙钟时间	479s	136s	228s
交付代码行数	~293	~117	~53

两个细节值得注意：

• caveman 的 136s 比 baseline 的 479s 快 3.5 倍，且总 token 比 ponytail v1 少约 4%——在"总对话开销"维度，纯压缩通信技能甚至短暂胜过最小代码技能，因为 ponytail v1 当时写了大量"skipped on purpose"的解释散文；
• 但 ponytail 的后续版本（v2 输出上限、v3 压缩 SKILL.md 本身）追平并反超，最终 verdict 中 ponytail 在代码量、散文量、总 token 与时间上全部领先。这说明单靠"caveman 式省话"是必要不充分的，代码侧的决策纪律（ladder/YAGNI）才是更大的杠杆。

更严格的同模型三臂对照见 benchmarks/results/2026-06-12-v4-hardening-vs-caveman.md：6 个生产规格任务 + 扩展阶段 + 对抗性安全探针，全部 arm 同模型、每格新 subagent：

全基准（6 构建 + C/D 扩展）	Control2	Caveman	Ponytail v4
Build LOC	3,629	1,440	490
构建后扩展改动行数（C, D）	378, 737	156, 257	41, 55
Agent 总 token	430,697	290,546	229,370
安全探针	8/8 + 6/6	8/8 + 6/6	8/8 + 6/6

该文结论一针见血："Caveman is a prose-compression skill that explicitly writes code 'normal' — it loses on code size by design." 而 ponytail 加"测试反射"等加固规则后 token 仍比 caveman 少 21%（229k vs 290k），且安全探针零回归——即 Auto-Clarity 类边界规则在两个技能里都经受住了对抗测试。

一个诚实的边界说明（benchmarks/README.md Notes）：以上成本数字反映单轮调用，不是真实多轮 agent 会话的会话成本；在多轮会话中规则文件会被反复重注入、决策阶梯每轮都要过一遍，单会话成本可能高于也可能低于这些数字。

7. 从这份技能文件能提炼的提示词工程要点

把 caveman-SKILL.md 从"一份有趣的提示词"抽离出来看，它对任何想给 Agent 做"输出压缩 / 风格约束"的开发者都有可复用的结构：

1. front matter 即路由：name + 多触发语 description + 默认强度声明，让"何时加载、默认多强"无歧义；
2. 持久化条款要双向写：既写"每轮都生效、不确定时保持"，又写唯一关闭词，防止多轮漂移与状态失控；
3. 压缩规则写成删/留双清单，并显式声明保护区（技术术语、代码块、报错原文），把"技术实质全部保留"作为第一约束；
4. 强度做成档位而非布尔：lite/full/ultra + 面向目标语种的专用档（wenyan 系列），档位间用同一组题目做梯度示例，让 Agent 有可对齐的输出锚点；
5. 为高风险场景保留自动回退（Auto-Clarity），并用"清晰段 → 宣告恢复 → 回到极简"的显式三段式示范，让安全表达不被风格淹没；
6. 明确治理边界：code/commits/PRs 正常书写，防止风格指令越界污染交付物。

这份文件在 ponytail 仓库中的存在本身也是一次示范：一个提示词技能不需要任何运行时支持，fs.readFileSync 读全文塞进 system 角色即可被完整复用为实验变量——benchmarks/arms/caveman.js 八行代码即完成"技能 → 可控实验臂"的转换，配合 benchmarks/loc.js、benchmarks/correctness.js 两个度量断言，构成了一套可复现的提示词 A/B 实验装置（复现步骤见 benchmarks/README.md 的 Reproduce 一节，要求 Node.js ≥ 22.22.0 与 Anthropic API key）。