ponytail 這個 Claude Code skill 我實測了：三題程式碼少 44%，但有一題完全沒差
直接回答
ponytail 有效，但不是每題都有戲劇性差別。我用同一組題目、同一個模型、溫度 0 跑對照，唯一變因是有沒有帶 ponytail 的規則：三題合計程式碼行數從 59 行降到 33 行（少 44%），輸出 token 從 888 降到 567（少 36%）。差最多的一題少 69%，因為沒帶規則的版本自己裝了 express 開了一整台伺服器；但剪貼簿那題兩邊都用了瀏覽器內建的 API，差距只有排版級。
ponytail 在 2026 年 8 月衝到 10.8 萬星，一句話宣稱：讓你的 AI 代理像公司裡最懶的資深工程師，看到五十行就換成一行。
README 上寫程式碼少 54%。我決定自己測一次，因為別人的 benchmark 是別人的題目。
—
測法很簡單，簡單到可以被複製。
同一個模型、溫度 0、同一句基準指示，同一個題目送兩次。唯一的差別是第二次把 ponytail 的 SKILL.md 正文塞進 system prompt。量兩件事：程式碼區塊裡的非空行數，還有輸出 token。
題目我挑三個跟真實工作有關的，而且刻意避開它 README 裡那個日期選擇器的示範題。拿它自己的示範題去測等於作弊。
- 把數字格式化成台幣千分位
- 網頁上加一個複製到剪貼簿的按鈕
- 一個 API 回傳最近 7 天的花費總和
第 2 題是我埋的陷阱。很多人會去裝剪貼簿套件，但瀏覽器本來就有。
—
ponytail 對照實測（2026-08-23，同模型、溫度 0、單次 API 呼叫）：台幣千分位 12 行 → 10 行；剪貼簿按鈕 21 行 → 15 行；7 天總和 API 26 行 → 8 行。三題合計 59 行 → 33 行，少 44%；輸出 token 888 → 567，少 36%。
數字出來是這樣：
台幣千分位 12 行變 10 行，少 17%，token 少 21% 剪貼簿按鈕 21 行變 15 行，少 29%，token 少 19% 7 天花費 API 26 行變 8 行，少 69%，token 少 55%
合計程式碼少 44%，輸出 token 少 36%。
—
差最多那題的差別值得看實際的東西。
我要的是一個回傳最近 7 天花費總和的 endpoint。沒帶 ponytail 的時候，它給我這些：
裝了 express，開了一整台伺服器，最後還 app.listen(3000)。
自己編了 8 筆假資料塞進函式裡。
然後把同一個陣列 filter 了兩次，一次算總和一次算筆數。
那個 filter 兩次不只是囉嗦，是真的多跑一遍。
帶了 ponytail 之後只剩 8 行，就是那個 endpoint 本身，後面補一句：假設資料已經在記憶體或資料庫裡，資料量大或需要持久化就改用資料庫查詢。
我要的是一個加總的 endpoint，不是一台伺服器。這就是它在解的問題。
—
但我要講一題它沒發揮作用的，因為只講贏的部分那篇文章就不值得看。
剪貼簿那題，我埋的陷阱沒有抓到任何人。有裝沒裝兩邊都用了瀏覽器內建的 navigator.clipboard，都沒有去裝套件。差距只剩下寫法精簡程度，21 行對 15 行，功能完全一樣。
結論是：ponytail 發揮作用的地方是有明確過度設計陷阱的題目。題目本身已經沒有偷懶空間的時候，它幫不上什麼忙。
還有一個誠實的對照：我測的是單次 API 呼叫，它 README 那個 54% 測的是完整的 agent 工作階段，會讀檔案、改多個地方。兩個數字量級接近但不能直接比。
—
跑完之後我去讀它的 SKILL.md，想知道為什麼一個 6,616 字元的純文字檔可以做到這件事。歸納出 6 個設計。
第一，它給的是階梯不是原則。
七個有順序的關卡，停在第一個站得住的：這東西需要存在嗎、codebase 裡已經有了嗎、標準函式庫做得到嗎、平台原生功能覆蓋得了嗎、已裝好的套件解得掉嗎、可以一行嗎，到這裡才輪到自己寫。
「寫簡潔一點」是價值觀，模型每次都要重新詮釋一遍什麼叫簡潔。階梯只要照跑。這是結果穩定的根本原因。
第二，它先定義詞義再給人格。
開頭第一句是「你是一個懶惰的資深工程師，懶惰是指有效率，不是隨便」。先把會被誤解的那個詞釘死，再給形象：看過每一種過度設計的爛程式碼，凌晨三點被叫起來過。
給人格的好處是模型可以推論規則沒寫到的狀況。只給規則，遇到規則沒涵蓋的它就亂猜；給一個人，它會問這個人會怎麼做。
第三，它處理了跑久了會漂回去的問題。
有一整段叫 Persistence，寫著每一次回應都生效、不准漂回過度建構、不確定的時候也還是生效、只有明確說停才關。
多數人寫規則寫完就沒了，對話跑三十輪之後那條規則早就被稀釋掉。它明講不確定的時候預設仍然生效，這一句把預設值從關改成開。
第四，反例跟邊界寫得比正例還重。
它花很大篇幅寫什麼時候不要懶：輸入驗證、防資料遺失的錯誤處理、安全、無障礙、使用者明確要求的，這些絕不簡化。理解問題的時候絕不能懶，階梯縮短的是解法不是閱讀。它甚至寫「在錯的地方做最小的修改不叫懶，那叫第二個 bug」。
這一段的作用不是限制是授權。模型知道邊界在哪，才敢在邊界內用力。沒有邊界的規則模型只會保守地小用一點。
第五，它規定輸出格式，而且解釋為什麼。
格式是程式碼在前，後面最多三行短句，講跳過了什麼、什麼時候該加回來。然後這句是我覺得最漂亮的：如果解釋比程式碼還長就刪掉解釋，因為每一段替簡化辯護的散文，都是把複雜度用文字偷渡回來。
它不只說不要囉嗦，它說明了囉嗦的本質。給了理由，模型才不會為了討好而多寫。
第六，觸發條件寫在 description 不是寫在正文。
它的 description 欄位塞滿觸發詞跟排除項，包含那句「不要用在非程式的請求，一般知識、散文、翻譯、摘要、食譜都不要」。
這是有意的。description 是被拿去做匹配、決定要不要載入的那段。寫在正文裡的排除條款要載入之後才看得到，那就太晚了。
—
ponytail 的核心是 skills/ponytail/SKILL.md 一個檔案，6,616 字元，MIT 授權。repo 裡另外有 10 幾種工具的外掛目錄、hooks、MCP server，對已有自己 skill 架構的人都不需要。社群已出現 ponytail-lite，理由是「不要那些外掛雜訊」。
實務建議：只拿那一個檔案。
它的 repo 裡有給十幾種編程工具的外掛目錄、hooks、一個 MCP server、多國語言的說明文件。核心就是 skills/ponytail/SKILL.md，6,616 個字元，frontmatter 裡寫著 MIT。
社群已經出現 ponytail-lite 跟 impeccable-lite，說明寫得很直白，一個說不要那些外掛瘋狂，一個說不要那些外掛機械。這些爆紅的 skill 正在變重，已經有人在反彈。
對已經有自己一套架構的人來說，整包裝進去的代價是把自己灌胖。
—
那為什麼不選 caveman？它同期 10 萬星，也是省 token 的。
兩個理由。
它壓縮的是模型講話的方式，叫它像穴居人一樣講短句、砍掉冠詞跟語助詞。如果你對助理的語氣有既定設定，這兩件事會直接打架。
而且它最亮眼的那個數字，輸入 token 少 33.2%，不是 skill 做到的，是它另一個產品做到的：一個代理程式，把你發給模型的東西先攔下來壓縮再送出去。那部分的授權是 BSL 不是 MIT。如果你手上有客戶資料，讓第三方代理程式經手你的請求，這個決定不該為了省 token 隨便做。
反過來說，ponytail 那句「不要用在非程式的請求」看起來是限制，對工作組成很雜的人反而是優點：寫文案的時候它是關的，零干擾。
—
最後一件事，跟 skill 本身無關但更重要。
裝了不等於會用。skill 會被工具主動秀出來，這點比寫在規則檔裡好，但中間那一步還是人要去叫它。
我的作法是把那七關直接印進動手前的攔截提示裡，不是只印「記得用 ponytail」。只印名字我還是要自己回想七關是什麼，印進去就不用回想。
靠記得的一律不可靠，要靠攔截。
補一句界線：這篇的數字是我真的跑出來的，6 次 API 呼叫、三題對照。但那六個設計的分析是我讀 SKILL.md 歸納的，不是實測。至於長期用下來省多少，我還沒有資料，有了再寫。