主題: AI agents
Caveman：讓 AI 助手少說廢話，卻不減技術含量
從 JuliusBrussee/caveman 的 README 出發，理解這個為 Claude Code、Codex 與其他 AI agent 打造的精簡回覆工具，為什麼值得注意。
動態迷因（展開／收合）
如果你每天都在用 Claude Code、Codex、Cursor 或其他 coding agent，你大概很熟悉一種情況：答案其實是對的，但回覆又長、又繞、又客套，真正有用的技術資訊反而被埋在段落裡。
caveman 想解的，就是這個問題。
這個專案由 Julius Brussee 製作，核心概念非常直接：保留技術內容，砍掉語氣填充、贅字與過度包裝的句子。它不是改模型本身，而是把 AI 助手的回覆風格，變成一種可以切換、可以安裝、甚至可以自動啟用的「壓縮層」。
1. Caveman 是什麼？
根據 README，caveman 同時提供：
- 給 Claude Code 使用的 skill / plugin
- 給 Codex 使用的 plugin
- 給 Gemini CLI、Cursor、Windsurf、Cline、Copilot 等工具安裝的 skill
它的目標不是讓模型回答得更少，而是讓模型用更短的形式表達相同的技術判斷。換句話說，caveman 想優化的不是「懂不懂」，而是「怎麼說」。
這也是它最有趣的地方。大部分 prompt engineering 都在追求更完整、更穩定、更強的推理；caveman 反而把重點放在輸出密度與閱讀效率。
2. 為什麼這件事值得做？
在 CLI 型 agent 工作流裡，回覆冗長其實有三個成本：
- 閱讀成本：你要自己從一大段文字裡撈出真正重要的兩三句
- 互動延遲：輸出 token 越多，通常回覆越慢
- 金錢成本：使用按 token 計費的模型時，冗字就是成本
所以 caveman 的價值，不只是幽默風格而已。它把「少說一點」變成一種具體的生產力優化。
README 直接把這件事講得很清楚：同樣的修正建議，如果一般模式會解釋成一整段，caveman 會縮成幾個高密度片語，但保留技術判斷與下一步行動。
在實際開發情境裡，這非常合理。很多時候你不是要看一篇文章，你只想知道：
- 問題在哪裡？
- 為什麼會發生？
- 下一步要改什麼？
caveman 的輸出風格，就是圍繞這三件事設計的。
3. 它到底怎麼壓縮？
README 把 caveman 設計成幾個層級：
- Lite：保留完整文法，但去掉 filler 與客套語
- Full：預設模式，允許片語化，刪掉多餘連接詞與修飾
- Ultra：更像電報文，追求極限簡短
- Wenyan 系列：進一步用文言文風格壓縮語言
這裡最值得注意的是：caveman 並不是單純要求「簡短回答」，而是把壓縮風格制度化。不同模式對應不同壓縮強度，使用者可以按自己的閱讀習慣切換。
也就是說，這不是一句 prompt 小技巧而已，而是一個有安裝方式、有觸發命令、有模式切換、有跨 agent 支援矩陣的完整產品化設計。
動態迷因（展開／收合）
4. 不只會「少說話」，還會幫你壓縮工作流
README 裡不只介紹了對話模式，還補了幾個衍生技能：
- caveman-commit：把 commit message 寫得更短、更聚焦
- caveman-review：把 PR review comment 壓成高密度單行評論
- caveman-help：快速查看模式與指令
- caveman-compress：壓縮像
CLAUDE.md這種每次 session 都會讀入的記憶檔
其中我覺得最有產品感的是 caveman-compress。
因為前面那些功能，優化的是輸出 token；但 caveman-compress 處理的是輸入 token。README 的做法是把原始的人類可讀檔案備份起來，再產生一份壓縮版供 agent 每次 session 啟動時載入。對經常使用長篇記憶檔的人來說，這個方向很實用。
換句話說，caveman 不只是在玩語氣，而是在把「token 預算」當成一種可以管理的資源。
5. README 提出的數據，代表什麼？
README 裡列了兩組很關鍵的數字：
- 多個任務平均約 65% 的輸出 token 節省
- 記憶檔壓縮平均約 46% 的輸入 token 節省
它也特別提醒一件重要的事：caveman 影響的是輸出，不是模型內部的思考 token。也就是說，它不是讓模型少想，而是讓模型少講。
這個 distinction 很重要。因為很多人看到「token 變少」會誤以為整體推理也被削弱。但從 README 的定位來看，caveman 更像是輸出層的格式控制，而不是能力層的閹割。
README 另外還引用了一篇 2026 年的論文，主張在某些基準裡，強制模型簡短回答反而可能提升正確率。就算先不把這件事當成定論，至少它指出了一個值得注意的方向：冗長不一定更聰明，很多時候只是更吵。
6. 什麼情境最適合用 Caveman？
我覺得這個專案特別適合下面幾種工作流：
- 終端機裡的日常除錯
- 快速 code review
- 反覆 ask / patch / verify 的 agent 迭代
- 你已經熟悉上下文，不需要長篇教學時
這類情境的共同點是：你要的是高密度回應，不是陪聊。
但反過來說，也有幾種場景未必適合開到最強壓縮：
- 安全警告或不可逆操作確認
- 要交付給新手看的教學內容
- 要給團隊長期保存的正式文件
README 本身也有類似界線：某些需要避免誤解的情境，仍然要保留清楚、完整的說明。這代表 caveman 並不是要取代所有寫作風格，而是替高頻技術互動提供一種更有效率的預設值。
7. 安裝與啟用，為什麼 README 寫得這麼細？
這份 README 很有意思的一點，是它花了很多篇幅解釋「安裝 skill」與「每次自動啟用」其實是兩件不同的事。
例如：
- Claude Code 依賴 plugin 與 hook
- Codex 依賴 plugin 與 repo hook
- 部分其他 agent 只會安裝 skill，不會自動把它設成 always-on
這種說明看起來瑣碎，但其實很重要。因為很多 agent 生態現在都卡在同一個問題：功能本身不難，難的是怎麼穩定地進入使用者預設工作流。
caveman 的 README 之所以值得一讀，不只是因為它有趣，而是因為它把跨 agent 的安裝、觸發、模式切換與 always-on 行為都拆開講清楚了。這表示作者不是只做了一個 prompt，而是認真把它當成產品在維護。
8. 我的看法：這個專案真正有趣之處
如果只看表面，caveman 很像一個迷因專案：把 AI 助手變成原始人語氣，順便讓回覆更短。
但如果你往下看 README 的設計，你會發現它其實在處理三個很實際的問題：
- 如何降低 agent 互動的閱讀摩擦
- 如何把回覆風格做成可切換的層
- 如何把 token 成本當成工程資源管理
這也是我覺得它值得寫成一篇文章的原因。它提醒我們，AI 工具的優化不只在模型大小、上下文長度或 benchmark 分數；有時候真正影響日常體驗的，是一個看似很小的問題：
模型是不是可以別再說那麼多廢話？
caveman 給出的答案很簡單：可以，而且還能做成一個安裝即用的跨工具插件。