一個開源專案在自己的說明文件裡，開了一頁叫「誠實的數字」，然後告訴你：如果你是這種用法，請把它關掉。
一句話結論：caveman 宣稱省 65％ token 是真的，但那只算輸出；它每輪固定多吃你 1–1.5k 輸入 token，整場實際只省 14–21％，短回覆的工作流會倒虧錢。
caveman 是給 Claude Code、Codex、Cursor 這類 AI 編程工具用的一個技能，作用是讓 AI 改用「穴居人語法」回話：砍掉客套、鋪陳、贅字，只留下結論和程式碼。截至 2026 年 8 月 21 日實查，GitHub 上約 8.5 萬顆星。
我七月寫過一篇 pxpipe 的實測，文章裡把 caveman 放進比較表當成「溫和的替代方案」。今天重讀它的官方文件，我得回來更正：那張表我寫錯了方向。
我七月把 caveman 寫錯了什麼？
錯在機制。我當時寫 caveman 是「把 prompt 改寫成穴居人語法」，也就是壓縮你送出去的東西。官方的 HONEST-NUMBERS.md 第一段就把這件事講死了：
caveman 是一個系統提示技能。它讓模型寫出更短的輸出。這就是全部的機制。它不壓縮你的輸入、你的 context、你的檔案，也不壓縮模型的思考 token。
方向剛好相反。它縮的是 AI 的嘴，不是你的話。輸入端的縮減幅度，官方自己填的數字是 0％。
| 項目 | 我七月寫的 | 官方文件實際寫的 |
|---|---|---|
| 壓縮對象 | 把 prompt 改寫，砍虛詞 | 只縮模型的輸出，輸入 0％ |
| 省多少 | 「視內容而定，通常一到三成」 | 輸出平均 65％；整場 14–21％ |
| 代價 | 語氣變生硬、複雜語意可能失真 | 語氣之外，每輪固定多收 1–1.5k 輸入 token |
| 風險等級 | 「介於中間」，比 pxpipe 安全 | 可能淨負，也就是比不裝更貴 |
| 適合誰 | 喜歡手動控制、不想多裝東西的人 | 回覆長的人；回覆短的人該關掉 |
有意思的是「一到三成」這個數字，誤打誤撞落在官方整場口徑 14–21％ 附近。但我當時是拿它當輸入端的壓縮率在講，理由是錯的。
那個 65％ 是怎麼量出來的？
10 道題，用 Claude API 的真實 token 計數，對照組是沒加任何指示的預設回覆。平均砍掉 65％ 輸出，區間 22％ 到 87％。benchmark 腳本和快照都提交在 repo 裡，可以自己跑。
| 題目 | 一般回覆 | caveman | 省下 |
|---|---|---|---|
| 解釋 React 重新渲染的 bug | 1,180 | 159 | 87％ |
| 實作 React error boundary | 3,454 | 456 | 87％ |
| 設定 PostgreSQL 連線池 | 2,347 | 380 | 84％ |
| 解釋 git rebase 和 merge 的差別 | 702 | 292 | 58％ |
| 架構討論：微服務還是單體 | 446 | 310 | 30％ |
| 把 callback 改寫成 async/await | 387 | 301 | 22％ |
| 平均 | 1,214 | 294 | 65％ |
看最後兩行就懂了。要解釋、要鋪陳的長題目，砍得動 87％；本來就短的改寫題，只砍得動 22％。原始回覆越長，它越有用，這句話等一下會變成判斷你該不該裝的那把尺。
為什麼它自己說有人用了會倒虧？
因為這個技能本身要佔位置。規則檔約 5KB，每一輪都要塞進 context，官方估算是每輪 1–1.5k 輸入 token。這是固定成本，不管你這輪省下多少輸出都要付。
講白一點：這個技能每輪成本約 1–1.5k 輸入 token。如果它省下的輸出比這個少，你就是在付錢使用它。
文件列了三種確定會虧的情況，每一種都掛著 GitHub issue 編號：
- 簡短的編程問答（issue #145）。正常回覆大約 150 個輸出 token，caveman 幫你省 70 到 100 個，卻收你 1,000 以上的輸入。提報的使用者實測就是這個結果，官方在文件裡直接寫「他是對的」。
- 按次計費的工具（issue #506）。GitHub Copilot 算的是請求數，回覆短一點還是同一個請求。任何按訊息計價的產品都一樣，caveman 幫不了你。
- 某些工具的計數器會反過來跑（issue #550）。一次 Cursor 的 A/B 測試，開了 caveman 是 430 萬 token，沒開是 100 萬，而且耗時多一倍。官方說重現不了那次執行，但誠實的讀法是：規則重複注入、重試、快取記帳，在某些工具裡會蓋過輸出端省下的量。
然後是那句我認為整份文件最狠的話：
如果你的 A/B 測試長這樣，caveman 對你就是淨負的。關掉它。希望石頭有用，不會讓石頭真的有用。
另外，獨立的整場量測落在 14–21％，而且那還是輸出偏重的工作流。原因不難懂：在 AI 編程裡，你的 prompt、你的 context、你的檔案加起來，本來就遠大於模型回你的字數。輸出砍再兇，佔的比例就那麼點。
你會賺還是會蝕？自己算一次
官方給了一條拇指規則：正常回覆長過大約 1.5k 到 2k 輸出 token，多半省錢；短過這個數，或你是按次計費，多半賠錢。
我把這條規則的算式拆開來看。1,250 ÷ 0.65 ≈ 1,923，正好落在它說的 1.5k 到 2k 之間，所以它算的是純 token 數量的打平點。
但你付的是錢，不是 token 數。輸出 token 通常比輸入貴好幾倍（多數模型大約 5 倍）。把價格加權進去，打平點會往下掉一大截：1,250 ÷ (0.65 × 5) ≈ 385。
換句話說，如果你在意的是帳單而不是 token 計數器，caveman 的實際門檻比官方那條規則寬鬆得多。下面這個試算機兩種口徑都會算給你看：
拉一下滑桿你會發現一件事：預設那組數字（600 token 的回覆）在純 token 口徑下是虧的，在價格加權口徑下是賺的。同一個工作流，換一把尺就換一個答案。這也是為什麼官方那句「唯一誠實的測試是自己跑 A/B」寫得很對。
回覆短一點，AI 會不會答得比較差？
直覺上會，實測上不一定。README 引了一篇 2026 年 3 月的論文，《Brevity Constraints Reverse Performance Hierarchies in Language Models》，作者 MD Azizul Hakim，3 月 11 日投稿。我去核了一下，論文是真的，而且結論比 README 引的那句更有意思。
- 測了 31 個模型，參數量從 0.5B 到 405B，橫跨 5 個資料集共 1,485 題。
- 在 7.7％ 的題目上，大模型的表現比小模型差 28.4 個百分點，儘管參數多了 10 到 100 倍。
- 研究者把原因指向「隨規模而來的自發囉嗦」：模型越大越愛展開，展開的過程中把自己講錯。
- 限制大模型只能簡短回答，準確率回升約 26 個百分點，並把落差收窄最多三分之二。
所以「講少一點」這件事，省錢只是副作用，在某些題型上它同時買到準確率。這是我認為 caveman 最被低估的價值，也是官方文件自己排在成本前面的那一項：讀起來快、答案先出來。
pxpipe 去哪了？兩條路在上游合流了
我七月那張表把 caveman 和 pxpipe 放在兩欄，還特別寫了 caveman「不碰圖片、沒有讀錯精確值的問題」。這句今天要補充。
caveman 這個名字現在指兩樣東西：
| caveman 技能（GitHub repo） | Caveman Engine（另一個產品） | |
|---|---|---|
| 做什麼 | 讓模型講短一點 | 在送出前壓縮 agent 要讀的東西 |
| 動哪一端 | 輸出 | 輸入 |
| 授權 | MIT | BSL-1.1（可讀可改可自架，第三方託管或嵌入服務要商業授權） |
| 有沒有 pixel 模式 | 沒有 | 有，而且內嵌 pxpipe |
Engine 的 engine/pixel 內嵌了 pxpipe（MIT），加上從 Spleen 5×8 和 GNU Unifont 衍生的字形圖集。做法跟我七月寫的 pxpipe 一模一樣：把密集文字畫成 PNG，用圖片 token 取代文字 token。官方給的例子是一份 63.7k 字元的最小化工具目錄，加上一份 93k 字元的長行 log，從約 55k 估算文字 token 降到約 11k 圖片 token。
兩個設計細節值得記，因為正好回應我七月提過的兩個坑：
- 划算閘門。pixel 只對允許清單上的模型生效，而且要先確認「畫成圖」真的比「送文字」便宜才動手。短行的稀疏程式碼老實說划不來，PNG 的額外開銷大過它取代的文字，閘門會直接拒絕，原樣送出。
- 逐位元還原。壓縮結果可以用 handle 取回原始位元組，handle 由內容本身推導，同樣的輸入永遠得到同樣的 handle。有損結果只有在原件成功存下來時才會送出；沒地方存，引擎就不壓縮。
另外 BSL 授權有落日條款：每個版本會在 2030 年 6 月 21 日、或該版本首次發布後四年，兩者較早者，自動轉成 Apache-2.0。
所以我七月寫的「二選一」，在上游確實變成同一個東西了，但合流發生在 Engine，不在那個 8.5 萬星的 MIT repo。把兩者混著講，授權會講錯。
省 token 這幾條路，現在該怎麼選？
這是我七月那張表的更新版。改動最大的是 caveman 那行。
| 方法 | 動哪一端 | 實際省多少 | 什麼時候會反效果 |
|---|---|---|---|
| 官方 prompt caching | 輸入（重複前綴） | 看重複率，重複讀取約 1 折 | context 每輪都在變，快取打不中 |
| caveman 技能 | 輸出 | 輸出 65％；整場 14–21％ | 回覆本來就短，或按次計費，會淨負 |
| pxpipe / Caveman Engine pixel | 輸入（大塊靜態內容） | 密集內容約 55k→11k | 稀疏短行程式碼，閘門會拒絕 |
| 記憶類工具 | 輸入（重複讀檔） | 看重讀比例 | 記憶本身要維護，錯的記憶更貴 |
疊起來的順序我會這樣排：prompt caching 打底，因為它零風險；輸入端的大塊靜態內容交給 pixel 那條路；輸出端如果你的 AI 平常回得很長，再加 caveman。精確字串（雜湊、UUID、金鑰）永遠留成純文字，這條線七月講過，今天沒變。
誰該裝，誰該直接跳過？
值得裝：你常常叫 AI 解釋架構、寫文件、做程式碼審查、debug 走查，回覆動輒上千字；或者你受不了 AI 回你三段客套才講重點。後者是不用算帳就成立的理由。
直接跳過：你用的是 Copilot 這類按請求計費的產品；或你平常只問「這行為什麼報錯」這種一兩句就答完的問題；或你已經在 CLAUDE.md 裡寫了「請簡短回答」，那句話本來就拿得到一部分效果，而且它不用每輪付 1–1.5k。
最後這點我要特別點出來，因為 benchmark 的對照組是完全沒給過任何指示的預設 AI，不是一個已經被要求答簡短的 AI。那 65％ 裡面，有一部分是任何一句「請簡短回答」都能拿到的。
怎麼自己量一次？
別信任何人給的百分比，包括我上面那個試算機。官方給的驗證方式只有三步：
- 挑一件你真的會做的任務。不要用 benchmark 題目，用你這禮拜實際做過的那種活。
- 同一件事跑兩次，一次開 caveman 一次不開，其他條件保持一樣。
- 去看服務商自己的用量頁，不要看工具內建的計數器。Claude Code 的
/caveman-stats讀的是你真實的 session log，但「省下多少」那行是估算：它拿 benchmark 的比例去外推一個沒發生過的基準線，所以輸出會標est.。
官方那句話值得抄下來：服務商帳單頁的數字，勝過這個 repo 印出來的任何東西。
一個開源專案為什麼要自己拆自己台？
我看過很多 README。把「本工具在這些情況下會讓你更貴」寫成獨立一頁、附上反對者的 issue 編號、還在文末寫「發現我們的數字錯了就開 issue，我們放上這一頁」的，這是我第一次遇到。
順帶一提，這篇我也踩到同一個問題。這個 repo 的星數，第三方彙總站顯示 9.9 萬，我今天實查 GitHub 主頁，兩次讀到 8.38 萬和 8.56 萬（GitHub 有多層快取，短時間內會給出不同的數）。所以文中一律寫「約 8.5 萬」並標實查日期。一篇講誠實數字的文章，自己那個數也得說清楚是怎麼來的。
省 token 這條賽道我追了幾個月，看過太多「省 90％」的標題。真正該問的從來不是省幾成，而是：這個數字量的是哪一端、對照組是什麼、什麼情況下會反過來。caveman 把這三題自己答完了。至於它適不適合你，拉一下上面那個滑桿，答案是你自己的。
常見問題
caveman 會不會讓 AI 寫出來的程式碼變差？
不會。它的規則明確要求程式碼、指令、錯誤訊息維持逐字不動，只壓縮敘述文字。它縮的是解釋的部分，不是內容本身。
caveman 是免費的嗎？
GitHub 上那個技能是 MIT 授權，免費。但 Caveman Engine 是另一個產品，走 BSL-1.1：你可以讀、可以改、可以自架跑自己的流量，第三方託管或嵌入服務則需要商業授權。兩者常被混為一談。
它會不會把我的資料傳出去？
官方說明是安裝後零網路呼叫：沒有遙測、沒有分析、沒有帳號、沒有後端。技能本身是一段提示詞，掛鉤是本地腳本，統計指令讀的是你硬碟上已經存在的 log。安裝當下會向 GitHub 和各家 agent 的註冊表抓檔，這部分寫在它的 SECURITY.md。
中文使用者有沒有特別的模式？
有，叫 wenyan，用文言文回話。它預設會跟隨你的語言（你寫葡萄牙文它就用葡萄牙文回），只壓縮風格不做翻譯；wenyan 是刻意的例外，因為文言文的每個 token 裝得下最多意思。可切換的等級是 lite、full（預設）、ultra、wenyan 四級。
那 65％ 到底能不能信？
作為「輸出 token 減少幅度」可以信，benchmark 腳本和快照都提交在 repo 裡可以重跑。但它不等於你的帳單降 65％：整場口徑是 14–21％，短回覆的工作流會是負數。
延伸閱讀
- pxpipe 是什麼？把 Claude Code 的 token 帳單砍 70％ 的開源神器：本篇更正的那一篇，pixel 那條路的原始出處
- 190 萬個 Agent Skills，平均分 6.2／12：為什麼裝越多，你的 AI 反而越笨：每輪 1–1.5k 的固定成本，正是這個問題的具體版本
- OpenViking 準確率 24%→82%、token 省 91%：但「取代向量資料庫」這句是錯的：同一種「數字要問量的是哪一端」
- code-review-graph：讓 Claude Code、Cursor 只讀該讀的檔，token 中位省 82 倍：輸入端減量的另一條路
- LoopX：讓 AI agent 跑 200 小時不忘記目標的開源內核，但那個數字要拆開看
- Apache 收編的 AI agent 出自華人團隊：Maka 把每一步變成刪不掉的帳
- OpenAI Codex harness 是什麼？官方開源的 agent 引擎：同一個模型，分數翻 3 倍
免責聲明：本文為工具介紹與數據拆解，不構成投資或採購建議。文中數據截至 2026 年 8 月 21 日，取自 caveman 官方 repo、官方文件與 Caveman Engine 文件；GitHub 星數為當日實查值，會隨時間變動。試算機為依官方公布參數所做的估算，實際成本以你的服務商帳單為準。安裝任何會進入 AI 工作流的工具前，請自行評估資料安全與授權條款。
發表迴響