Caveman：叫 AI 少說一點，真的比較省 token 嗎？

假設 coding agent 看到資料庫連線失敗。一般回答可能是這樣：

ECONNREFUSED localhost:5432 表示該位址沒有服務接受連線，通常是 PostgreSQL 尚未啟動或 port 沒有對外開放。先執行 pg_isready -h localhost -p 5432；如果失敗，再檢查容器狀態與 DATABASE_URL。

Caveman 模式會把同一件事壓成：

ECONNREFUSED localhost:5432：該位址無服務。先跑 pg_isready -h localhost -p 5432，失敗再查容器與 DATABASE_URL。

技術資訊沒有故意刪掉，客套、鋪陳和重複說明先消失。這就是 JuliusBrussee/caveman 的主要用途。模型照樣讀完整的程式碼與對話，Caveman 只管代理最後怎麼說。

它是 Skill，還是 Prompt？

兩種說法都碰到一部分事實。skills/caveman/SKILL.md 的核心是行為 Prompt，內容要求代理刪除贅字、允許片段句，並保留程式碼、命令、錯誤訊息、數字與否定詞。它同時有 frontmatter、觸發條件、強度等級與停止方式，所以發布形式確實是一個 Agent Skill。

整個 repo 的範圍又比單一 Prompt 大。除了主要 Skill，裡面還有安裝器、Claude Code plugin、hooks、統計工具、測試與其他任務型 Skills。

它只壓輸出，context 還是原來那麼大

Caveman 主要處理自然語言輸出。它會刪掉 Sure、I'd recommend 這類開場，把完整句改成較短的片段，也要求代理直接呼叫工具，不必先解釋接下來要做什麼。

幾類內容不能跟著縮水：

• 保留下來的程式碼、shell commands 與錯誤字串維持原樣；長 log 可以只引用關鍵行。
• 技術名詞、檔案路徑、數字、單位和否定詞。
• 安全警告、不可逆操作的確認，以及省略後可能產生歧義的步驟。

主 Skill 還提供 lite、full、ultra 與三種 wenyan 等級。wenyan 會刻意使用文言文式中文，趣味很明顯，但不一定適合團隊文件或需要讓新手理解原因的場合。實際工作通常先從 lite 或預設的 full 開始，比直接追求最短更容易判斷資訊有沒有留下來。

代理仍然要讀相同的 input、工具結果與對話歷史，reasoning 和 context window 也沒有因此縮短。回答變短，不代表整段任務消耗會按同一比例下降。

65% 和 8.5% 為什麼差這麼多

Caveman repo 首頁最醒目的數字是 65% output reduction。這是專案自己的測試：10 個 chat-style prompts，拿 Caveman 回答和模型預設的較長回答比較，平均少 65%，個別題目介於 22% 到 87%。

JetBrains 在 2026 年 7 月做了另一組測試。他們用 Claude Code 跑 SkillsBench 的 86 項 coding tasks，並強制每次回答都啟用 Caveman。完整一輪有 82 組可配對結果，output tokens 減少 8.5%；任務品質沒有測出統計上顯著的差異。

兩組百分比不衝突。一般技術問答大部分都是自然語言，能刪的字很多。Coding agent 的輸出還包含 tool calls、diff、程式碼與錯誤訊息，而 Caveman 刻意不改這些內容，能省的只剩工具之間的旁白。

repo 自己的 HONEST-NUMBERS.md 也提醒，主 Skill 可能讓每回合 input 增加約 1 到 1.5k tokens。這是專案提供的估算，實際數字取決於代理怎麼載入 Skill。若原本的回答只有一兩百 tokens，新增的 instructions 可能比省下的 output 還多。固定按 request 收費的方案，也不會因回答少幾行就自動少扣一次額度。

安裝前，先用一句 Prompt 試跑

Caveman 的 evals 已經把 Answer concisely. 當成獨立 control arm。較有意義的比較基準是一句簡短指令，而不是完全不限制長度的預設回答。

先拿同一個真實任務測三次：第一次不加限制，第二次加上這句 Prompt，第三次才使用 Caveman。

請簡短回答，保留程式碼、命令、錯誤訊息、數字與否定詞。
遇到安全風險、不可逆操作或容易誤解的步驟時，請完整說明。

比較時不要只數最後一則訊息。把整段 session 的 input、output、任務是否完成，以及實際帳單放在一起看。回答少 500 tokens，卻因為漏掉限制而重做一次，總成本通常更高。

如果一句 Prompt 已經能得到穩定結果，就沒有急著安裝常駐 Skill 的理由。當你經常處理長篇解釋、review 或文件，而且每次都要重貼相同規則，Caveman 的封裝才開始有價值。

在 Codex 使用 Caveman

先閱讀 repo 的 SKILL.md，確認持續模式與安全例外符合你的工作方式。只安裝給 Codex 可使用專案文件提供的 per-agent command：

npx skills add JuliusBrussee/caveman -a codex

Codex CLI 與 IDE 可以開啟 /skills 選擇 caveman，或直接在 prompt 裡輸入：

$caveman

想恢復一般回答，可以告訴代理 stop caveman 或 normal mode。若不再需要，可依專案的解除安裝說明執行：

npx skills remove caveman

repo 也提供會自動偵測多個 agents 的統一安裝器。它可能安裝 plugin、hooks、statusline 或專案規則，寫入範圍比單一 Skill 大。不要因為 README 的 one-liner 很短就直接略過檢查。若真的需要統一安裝，先下載或 clone repo，閱讀 INSTALL.md，再使用 --dry-run 查看它準備執行的命令。

Commit、review 和檔案壓縮是另外三件事

caveman-commit 會產生精簡的 Conventional Commits 訊息，caveman-review 把每項 review finding 壓成位置、問題和修法。兩者都只產生文字，不會替你 commit、修改程式或送出 review。

caveman-compress 不一樣。它用 script 壓縮 CLAUDE.md、todos 或 preferences 等自然語言檔案，會把正文交給 Claude 處理，再改寫你指定的原始檔並建立備份。含有憑證、個資或其他機密內容的檔案不適合直接使用。這是檔案修改工作流，不是單純的回答風格。第一次使用前應另外閱讀它的 SKILL.md 與壓縮腳本，確認資料處理方式、檔案範圍、備份與失敗處理，不要把它和 $caveman 視為同一個開關。

先看你的輸出是不是以文字為主

Caveman 比較適合原本會產生大量自然語言的工作，例如架構解釋、debugging walkthrough、文件初稿與 code review 摘要。使用者已經熟悉技術背景，只想快速看到結論與下一步時，短回答也能減少閱讀負擔。

若任務本來就只有短問答、工具呼叫和程式碼，能壓縮的空間很小。新手教學、安全分析、資料遷移與不可逆操作則需要保留原因和完整步驟。這些場景即使啟用 Caveman，也應確認它的 auto-clarity 規則真的有生效。

三個相近但不同的 Skills

• write-concisely 根據《The Elements of Style》改善文件的清楚度、結構和用字。它服務的是人類讀者，不以代理 token 成本為主要目標。
• context-compression 壓縮長 session 的歷史脈絡，重點是保留決策、檔案與下一步。它處理 input context，不是縮短當前回答。
• Humanizer 會移除套話與 AI 寫作痕跡，但仍要保留自然節奏和作者語氣。Caveman 可以接受片段句，兩者對最終文章的期待並不相同。

這三個 Skills 都可能讓文字變短，但處理的問題不同。沒有必要因為都和「少字」有關就全部安裝。Codex 會先載入 Skill 的名稱與 description，而且初始清單有 context 預算；裝得太多時，描述可能被縮短，部分 Skills 甚至不會出現在初始清單。按問題挑一個，比疊上多套相近輸出規則可靠。

比較實際的定位，是把 Caveman 當成閱讀介面設定。只有整段 session 的 A/B 結果顯示資訊完整、總成本也真的下降，才值得常用；如果前面那句短 Prompt 已經有相同效果，就繼續用 Prompt。

參考資料

• JuliusBrussee/caveman GitHub 專案
• Caveman SKILL.md
• Caveman 安裝說明
• Honest Numbers
• Caveman evals
• JetBrains SkillsBench 實測
• OpenAI：Build skills