我管那种要求 AI 尽可能少说话、号称能省 Token 的 Skill，叫做“电报体 Skill”。
聊这个话题之前，先讲个故事。大家小时候上语文课，多半都学过怎么写电报文。老师给一件事：母亲生病了，要让在外地工作的哥哥赶紧回家。全班比赛拟电文，看谁用字最少还把事情说清楚。最后全班最优解往往就四个字：
母病速归。
再少就不行了。只写“母病”，收到的人不知道该做什么；只写“速归”，又不知道家里出了什么事。那个时候必须惜字如金，因为电报按字收费，每一个字都是钱。
现在，这种说话方式在 AI 圈子里借着 Skill 复活了。
一个让 AI 像原始人说话的 Skill
GitHub 上有个叫 Ca veman 的项目，做的事情极其简单：给 Claude Code、Codex 等 AI 编程工具加一段提示词，让 Agent 像原始人一样说话。删掉冠词，删掉客套，删掉连接词，只保留技术要素。
正常回复可能是：
The issue is caused by a new object reference being created on every render...
换成 Ca veman 之后，就变成：
New object ref each render. Wrap in
useMemo.
项目的作者是荷兰莱顿大学一名 19 岁学生，叫 Julius Brussee。仓库 2026 年 4 月初上线，几天内冲上 GitHub Trending 第一。截至 7 月 12 日，已经攒下约 8.85 万颗 Star。它的 README 声称能大幅压缩输出 Token，项目介绍里最常出现的数字是 65%。
听起来很厉害。
但跟电报体一样，这很可能是一个特定价格和产品阶段里的过渡方案。而且它在真实 Agent 工作流里省下的钱，远没有宣传数字看起来那么多。
JetBrains 最近就专门做了一次测试，文章标题就叫：《Does Speaking to Agents Like Ca vemen Really Sa ve 65% of Tokens? We Test》。他们用 Claude Code 跑 SkillsBench 里的 86 个真实编程任务，安装 Ca veman 和不安装各跑一遍。两边使用相同任务、相同模型、相同配置和相同预算。整个实验分 3 轮，做了大约 240 次计费试验，总共花了约 106 美元。
为了给 Ca veman 最大的发挥空间，测试还强制它在每一次回复里生效。也就是说，这不是日常使用的平均情况，而是它能拿到的最佳情况。
结果是：
- 宣传节省：65% 输出 Token
- 大样本实测：8.5% 输出 Token
- 输出 Token：从约 59.2 万降到 54.2 万
- 有效配对任务：82 组
因为每次回复都被强制压缩，这个 8.5% 已经接近天花板。日常使用时，Skill 还要自己判断是否触发，实际节省通常只会更少。
有一点也要替 Ca veman 说清楚：JetBrains 没有测出显著的任务质量下降。 82 组配对任务里，64 个结果相同，Ca veman 版本有 8 个更好、10 个更差，差异在统计上不显著。它的问题不是“让 Agent 变笨”，而是把省钱效果说得太大了。
Agent 的 Token，大头根本不在聊天
为什么 65% 会缩水成 8.5%？
因为 65% 主要来自聊天场景。你问 AI 一个问题，它回你一大段话。把“当然可以”“很高兴帮你”“下面我来详细解释”这些客套和铺垫全部砍掉，确实可能省下一大半。
但编程 Agent 不是聊天机器人。它的 Token 消耗大头通常包括：系统提示词和不断累积的上下文、代码和文件内容及搜索结果、工具调用及返回结果、各种 Skills 和 MCP 工具描述、diff、报错信息和测试日志，以及模型在多轮任务里反复读取的内容。
Ca veman 主要压缩的是工具调用之间那几句自然语言说明。代码不能乱改，命令不能缩写，错误信息要原样保留，工具参数更不能写成原始人语法。它优化的那部分，在整张账单里本来就是零头。
这就好比一家公司要压缩差旅费，机票、酒店和打车一项没动，先把员工每天 2 块钱的矿泉水取消了。省是省了，但别指望靠这个拯救财报。
语言越短，对默契的要求越高
电报体也不是完全没有代价。
比如 Agent 最后只回复一句：
Fixed auth. Tests pass.
看起来非常干练，也很省 Token。但它没有告诉你：修的是登录过期、权限校验，还是刷新令牌？跑的是一个单元测试，还是完整测试套件？有没有改数据库结构？有没有留下兼容性风险？
这些信息不一定每次都要展开成小论文，但也不能因为“说话像xue居人”就固定删掉。开发者看不懂 Agent 做了什么，只好继续追问。Agent 再读一遍文件，再跑一遍测试，再解释一次。前面省下的几十个 Token，很快就会被新一轮工具调用吃回去。
这不代表 Ca veman 的基准测试已经证明会导致更多返工。JetBrains 的测试没有发现这种质量损失。问题在于，“任务最终做对了”和“过程对人足够透明”不是同一个指标。
电报体能工作，靠的是双方共享大量背景。“母病速归”只有四个字，收报人却知道母亲是谁、家在哪里、为什么要回去。编程 Agent 面对的是不断变化的代码、陌生仓库和临时任务，共享背景没有那么可靠。表达越短，越依赖默契；而默契不足时，多说的那几句就是通信协议里的纠错码。
啰嗦有时不是浪费，而是为了避免下一轮更昂贵的误解。
电报体没有被淘汰，只是失去了存在的理由
电报体后来怎么样了？没有人宣布废除它。只是长途通信的价格降到可以忽略不计之后，“母病速归”自然变回了：
妈住院了，你买最早的票回来，到了给我打电话。
省字数，是给按字计费时代做的优化。当价格降下去，信息完整和沟通体验重新变得更重要，这种优化也就自然退场了。
Token 很可能也会走同一条路。模型单价长期在下降，缓存技术也在把重复上下文变便宜。以 Anthropic 当前的提示词缓存价格为例，缓存命中的输入 Token 读取价格只有普通输入 Token 的 0.1 倍，也就是便宜约九成。当“重复读”已经可以打九折中的一折，再费很大力气把一句正常的话压成电报文，收益就更有限了。
真正该省的，是上下文和返工
如果真想降低 Agent 成本，更值得做的不是逼它少说几个字，而是：
- 少加载无关上下文。 不要一上来就把整个仓库、所有文档和历史对话塞给模型。
- 少挂没必要的 MCP 和 Skills。 工具描述本身也占上下文，装得越多不等于干得越好。
- 提高缓存命中率。 把稳定的系统提示词、工具定义和项目规则放在可复用的前缀里。
- 减少无效工具调用。 先定位问题再读文件，先确定范围再跑测试。
- 选择合适的模型。 简单任务用便宜模型，复杂任务用更可靠的模型，少一次返工往往比省几句说明更值钱。
Ca veman 当然可以用。你喜欢简洁的回复，或者受够了 Agent 的客套话，它是个有趣而且基本无害的风格插件。但别把风格优化误当成成本革命。
真正昂贵的从来不是 Agent 多说了几句话，而是它读了太多没用的东西，又把同一件事做了两遍。