Caveman实测 - AI Agent 的极简输出压缩插件
今天发点适合让 AI Agent 简洁输出的东西。 平时我们用 AI Agent 时，输出的内容不管对不对都会有一些啰里八嗦的废话，读起来很浪费我们的时间和精力，用起...
今天发点适合让 AI Agent 简洁输出的东西。
平时我们用 AI Agent 时，输出的内容不管对不对都会有一些啰里八嗦的废话，读起来很浪费我们的时间和精力，用起来也浪费 Token。
只要给你的 AI Agent 装上这个叫 Caveman 的GitHub项目之后，输出的内容立马变得简洁起来，只有在重点，没有废话。
Caveman 是一个给 AI Agent 用的压缩表达插件。
项目地址：https://github.com/JuliusBrussee/caveman
Caveman能让 Claude Code、Codex、Gemini、Cursor、Windsurf、Cline、Copilot 等少说铺垫话、场面话，多给有效信息。
重点是压缩“表达方式”，不是压缩模型思考、上下文、文件内容或工具调用本身。官方说的 65% 节省，指的是输出 token 平均减少，不等于总账单直接减少 65%。
Caveman 的思路是把语言习惯写成强规则，持续塞给代理。包括删除冠词、寒暄、弱化语、连接废话，允许句子碎片化，保留代码、命令、错误、API 名称和技术术语。
核心技能包括 caveman、caveman-commit、caveman-review、caveman-stats、caveman-compress、caveman-shrink。
- /caveman：开启输出压缩。支持 lite、full、ultra、wenyan 等强度。full 是默认模式。
- /caveman-commit：生成短 Conventional Commit 信息，强调为什么改，而不是流水账描述改了什么。
- /caveman-review：做代码 review 时输出一行式意见，跳过客套和无用表扬。
- /caveman-stats：读取 Claude Code 本地会话日志，估算 token 使用和节省情况。
- /caveman-compress
：压缩 CLAUDE.md、偏好、项目笔记这类自然语言记忆文件。 - caveman-shrink：作为 MCP proxy 包一层上游 MCP server，压缩 tools/list、prompts/list、resources/list 里的描述字段。
Caveman 几个模式的差异：
- lite：只是去掉废话，句子仍然比较正常。
- full：默认模式。句子更短，允许 fragment。
- ultra：更压缩，省掉更多连接词。
- wenyan：文言压缩模式，主要面向中文，因为中文字符承载信息密度更高。这个模式很有趣，但不适合所有场景，尤其不适合需要面向团队协作、PR 评论或新手解释的内容。
caveman-compress 有一套谨慎的文件规则：
- 只处理自然语言文件，比如 .md、.txt、.tex
- 不处理 .py、.js、.json、.yaml、.env、.sql、.sh
- 代码块、inline code、URL、路径、命令、技术名词必须原样保留
- 原文件会备份成 FILE.original.md
- 如果验证失败，不覆盖原文件
这个设计说明作者知道“压缩记忆文件”有破坏信息的风险，所以做了文件类型限制和验证流程。
case 1 Bug 解释
提示词：
解释一下为什么这个 React 组件会重复渲染，并给出最小修复方案：
function UserCard({ user }) {
const options = { showEmail: true };
return
; }
const Profile = React.memo(function Profile({ user, options }) {
console.log("render profile");
return
{user.name};});
不用Caveman：
用Caveman：
Caveman 明显更短，大概砍掉三分之一到一半内容，且没有明显错误。
case 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 需要验签。
case 3 架构权衡
提示词：我们正在做一个 B2B SaaS，团队 8 个工程师，当前是单体 Rails 应用。现在有 3 个模块：计费、通知、报表。老板想拆微服务。请分析是否应该拆，给出建议和迁移路径。
不用Caveman：
用Caveman：
普通版约 1400 到 1600 token，Caveman 版约 650 到 800 token，减少大约 50%，扫读成本明显低。而且重点内容：不建议全面拆、先做模块化单体、通知/报表优先、计费最后拆，这些判断都保住了。
case 4 PR Review
提示词：
请 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 多补了“幂等”问题。
而且代码 review 场景，不用 Caveman 已经是问题清单式写法，压缩空间有限。
case 5 Docker 优化
提示词：
帮我优化这个 Dockerfile，目标是减少镜像体积、提高构建缓存命中率，并避免把敏感文件带进镜像。
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
CMD ["npm", "start"]
不用Caveman：
用Caveman：
Caveman 版减少大约 35% 到 45% Token的。差异在基础镜像：普通版用 bookworm-slim，兼容性更稳；Caveman 用 alpine，体积更小。
case 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：
用Caveman：
不用 Caveman 约 1000 到 1200 token；Caveman 版约 500 到 650 token，减少大约 45% 到 50%。
普通版多了稳定排序 created_at, id，这是 Caveman 漏掉的实用细节。
case 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：
用Caveman：
不用 Caveman 约 850 到 1000 token；Caveman 约 650 到 800 token，减少大约 20% 到 30%。
Caveman Token稍低，但优势不大。因为这题天然需要代码块，token 主要花在代码上，风格压缩空间有限。
case 8 新功能设计
提示词：设计一个“导出报表为 CSV”的后端接口。要求支持大数据量、权限校验、异步任务、下载链接过期。请给出 API 设计、数据流和主要表结构。
不用Caveman：
用Caveman：
不用 Caveman 约 1300 到 1600 token；Caveman 约 900 到 1100 token，减少大约 25% 到 35%。
普通版多了 Idempotency-Key、report_export_files 独立表、CSV 注入防护细节。
case 9 事故复盘
提示词：我们线上服务昨天 10:05 到 10:27 出现大量 500。初步发现 Redis 连接池耗尽，应用不断重试，数据库 QPS 同时升高。请写一份工程内部事故复盘，包含时间线、根因、影响、修复、后续行动。
不用Caveman：
用Caveman：
不用 Caveman 约 900 到 1100 token；Caveman 约 550 到 700 token，减少大约 35% 到 45%。
普通版多了占位符提示、数据一致性核查、单飞机制；Caveman 多强调 retry budget、jitter、熔断和保护 DB。
case 10 代码解释
提示词：请给刚入职的后端新人解释什么是数据库连接池，为什么不能每个请求都新建连接，并举一个实际服务里的例子。
不用Caveman：
用Caveman：
不用 Caveman 约 700 到 850 token；Caveman 约 300 到 400 token，减少大约 50% 到 60%。
两版都命中连接复用、建连成本、连接数限制、池大小不能乱配。普通版多了完整代码例子和“第 21 个请求等待”的直观说明。
这 10 个 case 跑下来，Caveman 没有出现明显技术错误，核心判断都保住了，但 Caveman 会牺牲一部分细节，在明确问题和熟手场景里，收益很高。
最后还要给大家说几个需要注意的点：
- Caveman 只减少输出 token，输入 token 不会自动减少
- skill 本身每轮会增加约 1k 到 1.5k input tokens
- 如果普通回答本来只有 150 output tokens，启用 Caveman 可能反而更贵
- 如果平台按请求计费，而不是按 token 计费，短回答不会降低请求数
Caveman 这类工不是省几个 token的小需求，而是 AI Agent 进入我们的日常开发后，对输出效率、阅读成本和协作质量的要求变高了。
这次 10 个 case 测下来，Caveman 的价值也比较清楚。架构权衡、数据库优化、事故复盘、概念解释这类容易展开的任务，输出大多能减少 35% 到 60%；代码块占比高的任务，压缩幅度会降到 10% 到 30%。很适合处理模型容易啰嗦，但工程师只想看结论的场景。
对我们来说，Caveman 能减少每天读 AI 回复的时间；让 review、debug、方案讨论更像工程沟通，帮助统一输出风格，降低来回确认的成本。
Caveman 不该只被理解成省钱神器。它主要压缩输出 token，输入 token 和推理成本不会自动消失。
AI Agent 真正进入生产流程后，差距不只在会不会生成答案，也在生成的答案能不能被人快速使用。