【2026 最新】Ponytail Claude Code 真的省嗎？同 Repo 比較 Caveman／Headroom 的 A/B Test 教學

看到 Ponytail Claude Code 外掛主打「少寫程式」，再看到 Caveman 主打「少說廢話」、Headroom 主打「少送 context」，很容易把三種節省當成同一件事。其實它們動到不同層：程式碼、模型輸出、送入模型的內容。任何一層變短，都不保證一個可合併改動真的更便宜。

這篇不把作者 benchmark 或網友單次結果當答案，而是教你在自己的 Repo 做五組、八項任務的 A/B Test。你會同時記錄測試通過率、安全護欄、LOC、token、重試與耗時，最後用「每個驗收成功改動的成本」決定 Ponytail、Caveman、Headroom 該留下哪一個。

先說結論：Ponytail Claude Code 省不省，要看完成成本

真正的省＝同一品質下，少寫＋少傳＋少重跑；任何一項破功，都不算省。少 100 行程式卻拿掉權限檢查、少 1,000 個 token 卻多跑兩輪、壓縮 log 卻漏看關鍵錯誤，都只是把成本移到別處。

所以判讀順序固定：先看成果能不能合併，再看所有嘗試花了多少。這也呼應 AI 程式碼的認知負債：能跑不是終點，人還要能理解、審查與維護。

Ponytail、Caveman、Headroom 到底各自改什麼？

Ponytail：先問能不能不寫，再寫最小解

Ponytail 的官方 Repo 把方法整理成一座階梯：功能是否真的需要、Repo 是否已有做法、標準函式庫或平台原生能力能否完成、現有依賴能否重用，最後才新增最小實作。它也明列驗證、資料遺失處理、安全與無障礙不在刪減範圍。它最可能改變的是最終 diff 與完成路徑，不只是回答字數。

Caveman：壓短說明文字，程式碼與錯誤字串照留

Caveman 官方說明 的核心是讓 agent 少鋪陳，保留程式碼、指令、路徑與錯誤內容。它主要影響 output token；輸入與推理工作不會因回覆變短就一起消失，而且規則本身也會佔用輸入。對本來就簡潔的任務，它甚至可能沒有淨節省。

Headroom：在代理層壓縮送進模型的內容

Headroom 架構文件 描述的是另一層：proxy 位在 Claude Code 與模型服務之間，處理工具輸出、檔案、log 等 context。預設 cache 模式只處理最新增量、保留既有前綴，目標是維持 prefix cache；token 模式會更積極重寫先前內容。兩者的 cache 行為不同，因此不能混成同一實驗組。

把 Ponytail 想成「少蓋房間」、Caveman 是「少做口頭報告」、Headroom 是「少搬資料進會議室」。三者都可能有用，但收據位置完全不同。

公開 benchmark 告訴我們什麼、沒告訴我們什麼？

Ponytail 作者公開的 12 項 feature ticket 測試是自選工作負載，只能視為假說。較獨立的 JetBrains 80 組配對測試，在 SkillsBench、Claude Code 2.1.201、claude-sonnet-5 medium 的設定下，觀察到典型任務約少 15.4% 程式碼、成本低 10.3%、時間短 11%。但效果集中在有過度設計空間的任務；原本已很精簡的案例幾乎沒有典型改善。

同一團隊的 Caveman 82 組配對測試 使用 Claude Code 2.1.200、同模型 low，並強制啟用 skill，量到 output token 約少 8.5%。兩份測試都沒有偵測到顯著品質差異，但這是「未偵測到」，不是證明品質相等；兩組設定不同，數字也不能當成直接對決。Ponytail 那組另未專門驗證安全、輸入檢查或無障礙。

因此這些數字可以幫你挑指標，不能直接套進自己的帳單。模型版本、任務分布、安裝方式與驗收器不同，效果就可能換方向；10 項 smoke test 甚至曾在完整測試前給出相反訊號。Headroom 的作者數字也應比照處理：先當產品主張，等自己的配對資料。

Ponytail Claude Code A/B Test：先建立五個乾淨實驗組

截至 2026 年 9 月 3 日，Claude Code 官方提醒第三方 plugin 具有很高權限，可能以你的使用者權限執行程式。先檢查來源與程式碼，只在拋棄式 worktree、測試帳號或隔離環境跑，不要拿含正式 secrets 的工作目錄當試驗場。可先讀 Claude Code plugin 安全說明。

1. A｜Baseline：乾淨 Claude Code，不載入三個候選工具。
2. B｜短指令控制組：只加一句「先重用既有能力，完成後只回報必要結果」，用來分辨外掛效果與普通提示效果。
3. C｜Ponytail：安裝正式 plugin，維持預設 full；每次新 session 確認它確實啟用。
4. D｜Caveman：只啟用 Caveman skill，不開它的 proxy 或其他功能，避免一次改兩個變因。
5. E｜Headroom：用 headroom wrap claude --code-memory none，保留預設 cache 模式與官方 retrieval MCP，只關掉額外 code-memory 變因；另外核對 proxy 收到、轉送、壓縮與取回的次數。

Ponytail 與 Caveman 可依各自 Repo 的 Claude Code marketplace 指令安裝；若 CLI 支援 scope，實驗用 --scope local，並以 claude plugin list --json 留下啟用證據。Headroom 官方目前建議以獨立 Python 環境安裝 CLI，再由 wrapper 啟動。請記錄 commit 或版本，不要只寫「最新版」。

# 先在隔離環境審查來源，再逐組安裝；不要同時啟用
claude plugin marketplace add DietrichGebert/ponytail
claude plugin install ponytail@ponytail --scope local

claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman --scope local

# Caveman 組的每個新 session 都明確輸入
/caveman full

B 組也要鎖定原文，例如：「完整解決任務，採用最小正確修改；優先重用現有程式，不新增臆測式抽象；不得省略驗證、安全、無障礙、測試或錯誤處理。」開跑後不要為了讓某組變好看才改這句話。

# 每一組都要保存的環境指紋
git rev-parse HEAD
claude --version
claude plugin list --json

# Headroom 組：wrapper 會啟動本機 proxy；同時關閉匿名 beacon
DO_NOT_TRACK=1 headroom wrap claude --code-memory none

不要把 Headroom 的 token 模式塞進 E 組。若想測，另開 E2 探索組，因為它可能改變既有前綴與 cache 命中；結果要單獨報告。這正是 Agent Harness 的思路：模型不變，也要把外圍執行層當成正式變因。

八項任務怎麼挑：故意混合「有得省」與「本來就短」

• 2 項過度設計陷阱：標準函式庫或瀏覽器原生能力已能完成。
• 2 項 Repo 重用題：已有 helper、元件或錯誤處理模式可沿用。
• 2 項本來就精簡：局部 bug、文字或窄範圍測試修正。
• 2 項安全敏感題：碰到授權、輸入邊界、資料刪除或無障礙，明確要求護欄不得退步。

先為每題寫好看得見的測試、隱藏驗收與禁止事項，再凍結 prompt。五組都用同一 commit、完整模型 ID、effort、權限模式、網路條件、MCP/plugin 清單、turn 上限與 timeout；每次用新 worktree、新 session。把五組順序用固定 seed 隨機排列，避免第一組總是吃到冷 cache 或你第一次寫 prompt 的偏差。

每題先跑一輪確認流程，正式判斷至少做三次獨立重複。三次仍只適合個人決策，不足以宣稱普遍因果；如果差距落在日常波動內，就記「尚無結論」，不要挑最好看的一次。想把紀錄做得更細，可搭配 Tare 的 Claude Code token 稽核方法。

先過品質與安全 gate，再算 accepted-change cost

每個 patch 先交給自動測試與不知道組別的 reviewer。只要測試被弱化、需求漏做、範圍外修改、授權／輸入檢查消失，該 run 就不算成功；但它已花掉的 token、時間與重試仍留在分母。這能阻止「便宜但不能合併」的結果贏得排行榜。

accepted-change cost =
(所有嘗試的模型成本 + 重試成本 + 人工 review／修補時間成本)
÷ 驗收成功的改動數

每次 session 結束立刻保存 /usage：fresh input、cache write、cache read、output 與估算 cost，再記 wall time、turn、tool call、retry、最終 git diff --numstat。Claude Code 成本文件說明，API 帳務以 Console 為權威；Pro／Max 使用者看到的本機美元估算不是額外訂閱扣款。因此訂閱用戶可把 token 與耗時當主要比較單位。

task,repeat,seed,arm,order,commit,agent_version,tool_version
model,effort,input,cache_write,cache_read,output,cost
wall_time,turns,tool_calls,retries,added_loc,deleted_loc
tests,safety,blind_review,accepted,notes

盲評時先把組名、工具提示與 session 自述拿掉，只給 reviewer 看需求、diff、測試結果及必要執行紀錄。若 reviewer 意見不同，先由第三人裁決，再解盲。這不能消除所有偏誤，卻能降低「我剛裝的新工具一定比較好」的期待效應。報告結果時同時列出每組的失敗題與最差一題，不要只給平均數。

停止、移除與回滾規則要在開跑前寫好

• 立即停止：出現 secrets 外洩、越權寫入、資料遺失風險、測試被刪或安全護欄退步。
• 單次停止：超過預先設定的 token、turn、timeout 或工具呼叫上限。
• 暫停該組：連續三次沒過同一品質 gate，先查安裝、啟用與 prompt，不邊跑邊改規則。
• 保留條件：通過率不低於 baseline，且 accepted-change cost 的下降大到足以抵銷維護複雜度。

實驗後先保存結果與 diff，再用對應 CLI 停用或解除安裝；Headroom 用 headroom unwrap claude 回復 wrapper 設定，並以 claude plugin list --json 確認候選 plugin 不再啟用。拋棄 worktree 前先看 git status --short，不要讓未保存的測試證據一起消失。

結果怎麼選：不要硬挑一個總冠軍

• Ponytail 勝：過度設計題的 final diff 明顯縮小，通過率與安全 gate 不退步，總完成成本也下降。
• Caveman 勝：團隊主要痛點是冗長 narration，output 下降且沒有增加回合；即使帳單接近持平，可讀性也可獨立成為保留理由。
• Headroom 勝：長 session、工具輸出密集題的輸入與 cache 帳改善，重讀、漏訊息與 wall time 沒反向增加。
• Baseline 或短指令勝：代表你的工作本來就精簡，或外掛固定成本超過效益。少一個依賴也是有效結果。

若想先處理更大的槓桿，可回看 Claude 省 token 的 10 個方法；若要把 plan、tool、verify 固化成可重跑系統，接著做 自己的 AI Agent Harness。

Ponytail Claude Code 常見問題

Q1：Ponytail 一定能讓程式碼少 54% 嗎？

不能這樣推論。那是作者特定任務集的平均結果；獨立測試在另一組工作負載觀察到較小幅度，而且精簡任務接近沒有典型改善。

Q2：LOC 越少，品質就越好嗎？

不一定。LOC 是維護面積的提示，不是品質代理；刪掉重複包裝很好，刪掉驗證與錯誤處理就不及格。

Q3：為什麼要有短指令控制組？

因為它回答「plugin 是否勝過一句好 prompt」。若 B 與 C 效果接近，較簡單的提示可能已足夠。

Q4：Headroom 的 cache 與 token 模式能放一起算嗎？

不能。兩者對既有前綴的處理不同，會改變 prefix-cache 條件；應拆成兩組，預設先測 cache。

Q5：三個工具可以同時開嗎？

第一輪不要。先隔離各自效果；只有單獨組都通過後，才另開組合實驗，否則無法歸因。

Q6：只跑八題各一次夠嗎？

只夠找流程問題。agent 有非決定性；至少重複、交錯順序並看中位數，差異小就保留「尚無結論」。

Q7：Pro／Max 要看美元成本嗎？

可當相對估算，不是實際加收帳單。固定設定後比較 token、使用量與耗時，會比把本機美元欄當發票更合理。

Q8：什麼情況應直接移除工具？

安全 gate 失敗就立即移除；效益不足則回到最簡單設定。工具不是越多越成熟，可理解、可回滾的 baseline 本身就是資產。

給新手的 5 個實驗重點

• 先凍結品質 gate、prompt 與停止規則，再看任何成本數字。
• Baseline、短指令、Ponytail、Caveman、Headroom 一次只開一組。
• 五組都用同 commit、同模型、同設定、新 session，順序隨機交錯。
• 失敗 run 的 token、重試與人工修補照樣算進 accepted-change cost。
• 八題三輪只是一個 Repo 的操作決策；若差異不明顯，就保留簡單 baseline。