我把那種號稱能省 Token、要求 AI 儘量少說話的 Skill，叫做 “電報體 Skill” 。
我們小時候上語文課，學過怎麼寫電報文。
老師先給出一件事：母親生病了，要讓在外地工作的哥哥趕緊回家。然後全班比賽擬電文，看誰能用最少的字把事情說清楚。
最後可以精簡成四個字：
母病速歸。
再少就不行了。
只寫“母病”，收到的人不知道該做什麼；只寫“速歸”，又不知道家裏出了什麼事。
那時候必須惜字如金，因爲電報按字收費， 每一個字都是錢。
現在，這種說話方式在 AI 圈子裏藉着 Skill 復活了。
GitHub 上有個叫 Caveman [1] 的項目，做的事情極其簡單：給 Claude Code、Codex 等 AI 編程工具加一段提示詞，讓 Agent 像原始人一樣說話。
刪掉冠詞，刪掉客套，刪掉連接詞，只保留技術要素。
正常回復可能是：
The issue is caused by a new object reference being created on every render...
換成 Caveman 之後，就變成：
New object ref each render. Wrap in
useMemo.
項目由荷蘭萊頓大學一名 19 歲學生 Julius Brussee 做出來。倉庫 2026 年 4 月初上線，幾天內衝上 GitHub Trending 第一。截至 7 月 12 日，已經攢下約 8.85 萬顆 Star 。
它的 README 聲稱能大幅壓縮輸出 Token，項目介紹裏最常出現的數字是 65% 。
聽起來很厲害。
但跟電報體一樣，這很可能是一個特定價格和產品階段裏的過渡方案。而且它在真實 Agent 工作流裏省下的錢，遠沒有宣傳數字看起來那麼多。
號稱省 65%，實測只有 8.5%
JetBrains 最近專門做了一次測試，文章標題就叫：《Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? We Test》 [2] 。
他們用 Claude Code 跑 SkillsBench 裏的 86 個真實編程任務，安裝 Caveman 和不安裝各跑一遍。兩邊使用相同任務、相同模型、相同配置和相同預算。
整個實驗分 3 輪，做了大約 240 次計費試驗，總共花了約 106 美元。
爲了給 Caveman 最大的發揮空間，測試還強制它在每一次回覆裏生效。也就是說，這不是日常使用的平均情況，而是它能拿到的 最佳情況 。
結果是：
-
• 宣傳節省： 65% 輸出 Token -
• 大樣本實測： 8.5% 輸出 Token -
• 輸出 Token：從約 59.2 萬 降到 54.2 萬 -
• 有效配對任務： 82 組
因爲每次回覆都被強制壓縮，這個 8.5% 已經接近天花板。日常使用時，Skill 還要自己判斷是否觸發，實際節省通常只會更少。
有一點也要替 Caveman 說清楚： JetBrains 沒有測出顯著的任務質量下降。
82 組配對任務裏，64 個結果相同，Caveman 版本有 8 個更好、10 個更差，差異在統計上不顯著。它的問題不是“讓 Agent 變笨”，而是 把省錢效果說得太大了。
Agent 的 Token，大頭根本不在聊天
爲什麼 65% 會縮水成 8.5%？
因爲 65% 主要來自聊天場景。
你問 AI 一個問題，它回你一大段話。把“當然可以”“很高興幫你”“下面我來詳細解釋”這些客套和鋪墊全部砍掉，確實可能省下一大半。
但編程 Agent 不是聊天機器人。
它的 Token 消耗大頭通常包括：
-
• 系統提示詞和不斷累積的上下文 -
• 代碼、文件內容和搜索結果 -
• 工具調用及返回結果 -
• 各種 Skills 和 MCP 工具描述 -
• diff、報錯信息和測試日誌 -
• 模型在多輪任務裏反覆讀取的內容
Caveman 主要壓縮的是工具調用之間那幾句自然語言說明。代碼不能亂改，命令不能縮寫，錯誤信息要原樣保留，工具參數更不能寫成原始人語法。
它優化的那部分，在整張賬單裏本來就是零頭。
這就像一家公司要壓縮差旅費，機票、酒店和打車一項沒動，先把員工每天 2 塊錢的礦泉水取消了。
省是省了，但別指望靠這個拯救財報。
語言越短，對默契的要求越高
電報體也不是完全沒有代價。
比如 Agent 最後只回復一句：
Fixed auth. Tests pass.
看起來非常幹練，也很省 Token。
但它沒有告訴你：
-
• 修的是登錄過期、權限校驗，還是刷新令牌？ -
• 跑的是一個單元測試，還是完整測試套件？ -
• 有沒有改數據庫結構？ -
• 有沒有留下兼容性風險？
這些信息不一定每次都要展開成小論文，但也不能因爲“說話像穴居人”就固定刪掉。
開發者看不懂 Agent 做了什麼，只好繼續追問。Agent 再讀一遍文件，再跑一遍測試，再解釋一次。前面省下的幾十個 Token，很快就會被新一輪工具調用喫回去。
這不代表 Caveman 的基準測試已經證明會導致更多返工。JetBrains 的測試沒有發現這種質量損失。問題在於， “任務最終做對了”和“過程對人足夠透明”不是同一個指標。
電報體能工作，靠的是雙方共享大量背景。
“母病速歸”只有四個字，收報人卻知道母親是誰、家在哪裏、爲什麼要回去。
編程 Agent 面對的是不斷變化的代碼、陌生倉庫和臨時任務，共享背景沒有那麼可靠。表達越短，越依賴默契；而默契不足時，多說的那幾句就是通信協議裏的糾錯碼。
囉嗦有時不是浪費，而是爲了避免下一輪更昂貴的誤解。
電報體沒有被淘汰，只是失去了存在的理由
電報體後來怎麼樣了？
沒有人宣佈廢除它。
只是長途通信的價格降到可以忽略不計之後，“母病速歸”自然變回了：
媽住院了，你買最早的票回來，到了給我打電話。
省字數，是給按字計費時代做的優化。當價格降下去，信息完整和溝通體驗重新變得更重要，這種優化也就自然退場了。
Token 很可能也會走同一條路。
模型單價長期在下降，緩存技術也在把重複上下文變便宜。以 Anthropic 當前的提示詞緩存價格爲例，緩存命中的輸入 Token 讀取價格只有普通輸入 Token 的 0.1 倍 ，也就是便宜約九成。
當“重複讀”已經可以打九折中的一折，再費很大力氣把一句正常的話壓成電報文，收益就更有限了。
真正該省的，是上下文和返工
如果真想降低 Agent 成本，更值得做的不是逼它少說幾個字，而是：
-
1. 少加載無關上下文。 不要一上來就把整個倉庫、所有文檔和歷史對話塞給模型。 -
2. 少掛沒必要的 MCP 和 Skills。 工具描述本身也占上下文，裝得越多不等於幹得越好。 -
3. 提高緩存命中率。 把穩定的系統提示詞、工具定義和項目規則放在可複用的前綴裏。 -
4. 減少無效工具調用。 先定位問題再讀文件，先確定範圍再跑測試。 -
5. 選擇合適的模型。 簡單任務用便宜模型，複雜任務用更可靠的模型，少一次返工往往比省幾句說明更值錢。
Caveman 當然可以用。你喜歡簡潔的回覆，或者受夠了 Agent 的客套話，它是個有趣而且基本無害的風格插件。
但別把風格優化誤當成成本革命。
真正昂貴的從來不是 Agent 多說了幾句話，而是它讀了太多沒用的東西，又把同一件事做了兩遍。
引用鏈接
[1]
Caveman:
https://github.com/JuliusBrussee/caveman
[2]
《Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? We Test》:
https://blog.jetbrains.com/ai/2026/07/speak-to-ai-agents-like-cavemen-tosave-tokens/