从“母病速归”到“电报体 Skill”：AI 沟通中的 Token 节省真相
在 AI 编程与 Agent 协作中，一种新的沟通风格正在流行：它要求 AI 尽量少说话，删掉所有客套、连接词和修饰语，只保留最核心的技术要素。这种风格被形象地称为“电报体 Skill”。
为了让您快速理解，可以回忆一下小时候的语文课：老师让我们把“母亲生病了，让在外地工作的哥哥赶紧回家”这件事，用最少的字拟成电报文。最终答案往往是四个字：母病速归。再少不行，因为“母病”不知道该怎么办，“速归”不知道出了什么事。那时，电报按字收费，每一个字都是钱。如今，这种“电报体”在 AI 圈子里，借助 Skill 复活了。
一、新兴的“电报体”范式：Ca veman 项目
GitHub 上有一个名为 Ca veman 的项目，其思路极其简单：为 Claude Code、Codex 等 AI 编程工具添加一段提示词，让 Agent 像原始人一样说话。它要求 AI 删掉冠词、客套话、连接词，只保留技术要素。
例如，正常回复可能是：“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%。
小提示： 看到 65% 这个数字时，先别急着兴奋。它可能是一个特定价格和产品阶段里的过渡方案，在真实 Agent 工作流里省下的钱，远没有宣传数字看起来那么多。
二、宣传 vs 现实：65% 如何缩水成 8.5%
为了验证 Ca veman 的真实效果，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 变笨”，而是把省钱效果说得太大了。
三、为什么 65% 会缩水成 8.5%？
核心原因在于：Agent 的 Token 消耗大头，根本不在聊天。
65% 的节省主要来自聊天场景。你问 AI 一个问题，它回你一大段话，把“当然可以”、“很高兴帮你”、“下面我来详细解释”这些客套和铺垫全部砍掉，确实可能省下一大半。
但编程 Agent 不是聊天机器人。它的 Token 消耗大头通常包括：
- 系统提示词和不断累积的上下文
- 代码、文件内容和搜索结果
- 工具调用及返回结果
- 各种 Skills 和 MCP 工具描述
- diff、报错信息和测试日志
- 模型在多轮任务里反复读取的内容
Ca veman 主要压缩的是工具调用之间那几句自然语言说明。代码不能乱改，命令不能缩写，错误信息要原样保留，工具参数更不能写成原始人语法。它优化的那部分，在整张账单里本来就是零头。
这就像一家公司要压缩差旅费，机票、酒店和打车一项没动，先把员工每天 2 块钱的矿泉水取消了。省是省了，但别指望靠这个拯救财报。
四、电报体的代价：语言越短，默契要求越高
电报体也不是完全没有代价。比如 Agent 最后只回复一句：“Fixed auth. Tests pass.” 看起来非常干练，也很省 Token，但它没有告诉你：
- 修的是登录过期、权限校验，还是刷新令牌？
- 跑的是一个单元测试，还是完整测试套件？
- 有没有改数据库结构？
- 有没有留下兼容性风险？
开发者看不懂 Agent 做了什么，只好继续追问。Agent 再读一遍文件，再跑一遍测试，再解释一次。前面省下的几十个 Token，很快就会被新一轮工具调用吃回去。
这不代表 Ca veman 的基准测试已经证明会导致更多返工。JetBrains 的测试没有发现这种质量损失。问题在于，“任务最终做对了”和“过程对人足够透明”不是同一个指标。
电报体能工作，靠的是双方共享大量背景。“母病速归”只有四个字，收报人却知道母亲是谁、家在哪里、为什么要回去。而编程 Agent 面对的是不断变化的代码、陌生仓库和临时任务，共享背景没有那么可靠。表达越短，越依赖默契；而默契不足时，多说的那几句就是通信协议里的纠错码。
啰嗦有时不是浪费，而是为了避免下一轮更昂贵的误解。
五、未来趋势：Token 价格下降，电报体自然退场
电报体后来怎么样了？没有人宣布废除它。只是长途通信的价格降到可以忽略不计之后，“母病速归”自然变回了：“妈住院了，你买最早的票回来，到了给我打电话。”
省字数，是给按字计费时代做的优化。当价格降下去，信息完整和沟通体验重新变得更重要，这种优化也就自然退场了。
Token 很可能也会走同一条路。模型单价长期在下降，缓存技术也在把重复上下文变便宜。以 Anthropic 当前的提示词缓存价格为例，缓存命中的输入 Token 读取价格只有普通输入 Token 的 0.1 倍，也就是便宜约九成。当“重复读”已经可以打九折中的一折，再费很大力气把一句正常的话压成电报文，收益就更有限了。
六、真正有效的成本优化策略
如果真想降低 Agent 成本，更值得做的不是逼它少说几个字，而是：
- 少加载无关上下文。 不要一上来就把整个仓库、所有文档和历史对话塞给模型。
- 少挂没必要的 MCP 和 Skills。 工具描述本身也占上下文，装得越多不等于干得越好。
- 提高缓存命中率。 把稳定的系统提示词、工具定义和项目规则放在可复用的前缀里。
- 减少无效工具调用。 先定位问题再读文件，先确定范围再跑测试。
- 选择合适的模型。 简单任务用便宜模型，复杂任务用更可靠的模型，少一次返工往往比省几句说明更值钱。
常见问题：
Q：Ca veman 真的能省 Token 吗？
A：能，但效果远不及宣传。JetBrains 实测显示，在最佳情况下，输出 Token 节省约 8.5%，远低于宣传的 65%。日常使用中，实际节省通常更少。
Q：Ca veman 会导致任务质量下降吗？
A：JetBrains 测试并未发现显著的任务质量下降，但在一些场景下，过短的回复可能让开发者难以理解 Agent 的行为，从而引发额外的返工。
Q：我该不该用 Ca veman？
A：如果你喜欢简洁的回复，或者受够了 Agent 的客套话，它是个有趣而且基本无害的风格插件。但别把风格优化误当成成本革命。
Ca veman 当然可以用。你喜欢简洁的回复，或者受够了 Agent 的客套话，它是个有趣而且基本无害的风格插件。但别把风格优化误当成成本革命。
真正昂贵的从来不是 Agent 多说了几句话，而是它读了太多没用的东西，又把同一件事做了两遍。
引用链接
[1] Ca veman: https://github.com/JuliusBrussee/ca veman
[2] 《Does Speaking to Agents Like Ca vemen Really Sa ve 65% of Tokens? We Test》: https://blog.jetbrains.com/ai/2026/07/speak-to-ai-agents-like-ca vemen-tosa ve-tokens/