Caveman实测

Caveman实测 – AI Agent 的极简输出压缩插件

今天来分享一个能让 AI Agent 输出“直击要害”的神器——Caveman。

我们都知道，在使用 AI Agent 时，它们常常会喋喋不休，输出大量不必要的铺垫和客套话，这不仅浪费我们的宝贵时间和精力，也消耗了不必要的 Token 资源。而今天介绍的 Caveman 项目，正是为了解决这个问题而生。

01. 项目概览

Caveman，顾名思义，是一款专为 AI Agent 设计的“压缩表达”插件。它的核心目标是让 Claude Code、Codex、Gemini、Cursor、Windsurf、Cline、Copilot 等 AI 模型，减少冗余的开场白和场面话，转而提供更精炼、更有价值的信息。

项目地址：https://github.com/JuliusBrussee/caveman

需要强调的是，Caveman 压缩的是“表达方式”，而非模型的思考过程、上下文信息、文件内容或工具调用本身。官方提及的 65% 输出 Token 节省，指的是平均输出 Token 数量的减少，并不直接等同于整体账单费用的同比例下降。

Caveman 的设计理念是将语言习惯固化为强规则，并持续注入到 Agent 的提示中。这包括删除冠词、寒暄语、弱化词汇，以及精简连接性废话，允许句子碎片化，同时保留代码、命令、错误信息、API 名称和技术术语等关键信息。

其主要功能模块包括：

• /caveman：启用输出压缩功能。支持 lite（轻度）、full（标准）、ultra（极致）、wenyan（文言）等多种压缩强度。full 模式为默认设置。
• /caveman-commit：用于生成简洁的 Conventional Commit 信息，侧重于解释修改的原因，而非流水账式地描述修改内容。
• /caveman-review：在代码审查场景下，生成单行的评审意见，省略客套和不必要的赞美。
• /caveman-stats：读取 Claude Code 的本地会话日志，用于估算 Token 使用量和节省情况。
• /caveman-compress <file>：用于压缩 CLAUDE.md、偏好设置、项目笔记等自然语言记忆文件。
• caveman-shrink：作为 MCP proxy，包装上游 MCP server，以压缩 tools/list、prompts/list、resources/list 中的描述字段。

Caveman 不同模式的特点：

• lite：仅移除冗余的废话，句子结构相对完整。
• full：标准模式。句子更短，允许出现句子碎片。
• ultra：进一步压缩，省略更多连接词，表达更为精炼。
• wenyan：文言压缩模式，主要针对中文场景，利用汉字信息密度高的特性。此模式趣味性十足，但可能不适用于需要团队协作、PR 评论或面向新手解释的场景。

caveman-compress 在处理文件时遵循一套审慎的规则：

• 仅处理自然语言文件，如 .md、.txt、.tex。
• 不处理代码文件（如 .py、.js、.json、.yaml、.env、.sql、.sh）。
• 代码块、行内代码、URL、路径、命令、技术术语将保持原样。
• 原文件会备份为 FILE.original.md。
• 若验证失败，则不会覆盖原文件。

这一设计体现了作者对“压缩记忆文件”可能带来的信息破坏风险的警惕，因此设置了文件类型限制和验证流程。

02. 项目实测

案例 1：Bug 解释

提示词：

请解释以下 React 组件为何会重复渲染，并提供最精简的修复方案：

function UserCard({ user }) {
const options = { showEmail: true };
return <Profile user={user} options={options} />;
}
const Profile = React.memo(function Profile({ user， options }) {
console.log(“render profile”);
return <div>{user.name}</div>;
});

未使用 Caveman 的输出：

（此处省略具体内容，但描述为较长）

使用 Caveman 的输出：

（此处省略具体内容，但描述为更短）

Caveman 的输出明显更为简洁，长度约缩减三分之一到一半，且未出现明显错误。

案例 2：Debug 修复

提示词：
请协助排查此 Node.js 登录中间件的问题。用户 token 已过期，但有时仍能通过校验。请指出 bug 并提供修复代码。
function auth(req， res， next) {
const token = parseToken(req.headers.authorization);
if (!token) return res.status(401).send(“missing token”);
if (token.exp < Date.now() / 1000) {
return res.status(401).send(“expired”);
}
req.user = token.user;
next();
}

未使用 Caveman 的输出：

（此处省略具体内容，但描述为较长）

使用 Caveman 的输出：

（此处省略具体内容，但描述为更短）

Caveman 版本的输出 Token 显著减少，正文和代码部分都更为精炼。两种输出均指出了 exp 字段缺失/非法可能导致放行、边界判断应为 now >= exp，以及 JWT 需要验签等问题。

案例 3：架构权衡

提示词：我们正在开发一个 B2B SaaS 产品，团队有 8 位工程师。目前应用为单体 Rails 架构，包含计费、通知和报表三个模块。老板希望拆分为微服务。请分析是否应该拆分，并给出建议和迁移路径。

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 1400 到 1600 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 650 到 800 token）

Caveman 版本输出 Token 减少约 50%，阅读成本显著降低。其核心建议，如不建议全面拆分、先进行模块化单体改造、优先拆分通知和报表模块、最后再考虑计费模块，这些关键判断均得到了保留。

案例 4：PR Review

提示词：

请审查以下代码，重点关注安全性、并发性和边界条件。只指出实际问题，无需表扬。

async function transfer(fromUserId， toUserId， amount) {
const from = await db.users.findById(fromUserId);
const to = await db.users.findById(toUserId);
if (from.balance < amount) {
throw new Error(“insufficient funds”);
}
from.balance -= amount;
to.balance += amount;
await db.users.update(fromUserId， { balance: from.balance });
await db.users.update(toUserId， { balance: to.balance });
return true;
}

未使用 Caveman 的输出：

（此处省略具体内容，但描述为问题清单式）

使用 Caveman 的输出：

（此处省略具体内容，但描述为较短）

此案例中，Caveman 的输出差距较小，约减少 10% 到 15%。原因是代码审查场景下，未使用 Caveman 的输出本身已趋向于问题清单，压缩空间有限。不过，Caveman 额外补充了“幂等”问题的考量。

案例 5：Docker 优化

提示词：

请帮我优化这个 Dockerfile，目标是减小镜像体积、提高构建缓存命中率，并避免敏感文件泄露到镜像中。

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD [“npm”， “start”]

未使用 Caveman 的输出：

（此处省略具体内容，但描述为使用 bookworm-slim 镜像）

使用 Caveman 的输出：

（此处省略具体内容，但描述为使用 alpine 镜像）

Caveman 版本减少了约 35% 到 45% 的 Token。主要差异在于基础镜像的选择：普通版本使用了兼容性更稳的 bookworm-slim，而 Caveman 版本则选择了体积更小的 alpine。

案例 6：数据库问题

提示词：

请解释此 PostgreSQL 查询为何运行缓慢，并提供排查和优化方案。

表 orders 包含 8000 万行数据，字段包括 id， user_id， status， created_at， total_amount。

常见查询：

SELECT *
FROM orders
WHERE user_id = $1
AND status = ‘paid’
ORDER BY created_at DESC
LIMIT 20;

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 1000 到 1200 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 500 到 650 token）

Caveman 版本 Token 减少约 45% 到 50%。普通版本包含了一个 Caveman 遗漏的实用细节：为 created_at 字段添加索引以稳定排序。

案例 7：重构任务

function loadUser(id， callback) {
db.findUser(id， function(err， user) {
if (err) return callback(err);
api.fetchProfile(user.profileId， function(err， profile) {
if (err) return callback(err);
cache.set(id， profile， function(err) {
if (err) return callback(err);
callback(null， { user， profile });
});
});
});
}

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 850 到 1000 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 650 到 800 token）

Caveman 版本 Token 减少约 20% 到 30%。此场景下优势不明显，因为代码块占比较高，压缩空间有限。

案例 8：新功能设计

提示词：设计一个“导出报表为 CSV”的后端接口。要求支持大数据量、权限校验、异步任务、下载链接过期。请给出 API 设计、数据流和主要表结构。

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 1300 到 1600 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 900 到 1100 token）

Caveman 版本 Token 减少约 25% 到 35%。普通版本包含了一些 Caveman 遗漏的细节，如 Idempotency-Key、的 report_export_files 表以及 CSV 注入防护。

案例 9：事故复盘

提示词：我们线上服务昨天 10:05 到 10:27 出现大量 500 错误。初步发现 Redis 连接池耗尽，应用持续重试，同时数据库 QPS 飙升。请撰写一份内部事故复盘报告，包含时间线、根本原因、影响范围、修复措施和后续行动。

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 900 到 1100 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 550 到 700 token）

Caveman 版本 Token 减少约 35% 到 45%。普通版本包含了占位符提示、数据一致性核查和单飞机制等内容；Caveman 则更侧重于重试预算、抖动（jitter）、熔断和数据库保护。

案例 10：代码解释

提示词：请向新入职的后端同事解释什么是数据库连接池，为何不能为每个请求都新建连接，并举一个实际服务中的例子。

未使用 Caveman 的输出：

（此处省略具体内容，但描述为约 700 到 850 token）

使用 Caveman 的输出：

（此处省略具体内容，但描述为约 300 到 400 token）

Caveman 版本 Token 减少约 50% 到 60%。两版输出都准确地指出了连接复用、建连成本和连接数限制的重要性。普通版本包含了一个完整的代码示例和“第 21 个请求等待”的直观说明。

通过这 10 个案例的测试，Caveman 在没有出现明显技术错误的前提下，有效保留了核心判断，但在细节上有所取舍。在明确问题和面向有经验的开发者场景下，其收益尤为显著。

此外，还需要注意以下几点：

• Caveman 仅减少输出 Token，输入 Token 不会自动减少。
• Caveman 插件本身每轮会增加约 1k 到 1.5k 的输入 Token。
• 如果原始回答的输出 Token 本来就很少（例如 150 tokens），启用 Caveman 反而可能增加总 Token 消耗。
• 若平台按请求计费而非按 Token 计费，短输出并不会减少请求次数。

03. 深入分析

Caveman 这类工具的出现，并非仅仅为了节省几个 Token。它反映了 AI Agent 深度融入日常开发后，我们对输出效率、阅读成本和协作质量提出了更高的要求。

本次实测结果清晰地展示了 Caveman 的价值。在架构权衡、数据库优化、事故复盘、概念解释等易于展开的场景，输出 Token 普遍能减少 35% 到 60%；而对于代码块占比较高的任务，压缩幅度则降至 10% 到 30%。它特别适合处理 AI 模型容易冗余输出，而工程师只希望快速获取结论的场景。

对我们而言，Caveman 能够节省我们每天阅读 AI 回复的时间；使代码审查、调试和方案讨论更接近工程沟通的本质；并有助于统一输出风格，降低来回确认的成本。

Caveman 不应被简单视为“省钱神器”。其主要价值在于压缩输出 Token，而输入 Token 和推理成本并不会因此消失。当 AI Agent 真正进入生产流程时，关键的差异不仅在于能否生成答案，更在于生成的答案是否能被快速有效地利用。