每次寫 Codex 的教學或者使用案例，都有讀者詢問，這個 Token 消耗情況怎麼樣。
雖然免費也能用 Codex，但不同的檔次 Plus、Pro 5x、Pro 20x 所包含的 Token 額度完全不同，怎麼省 Token 成了這段時間以來社交媒體上的熱門話題。
之前 Claude Code 爆火的時候，有開發者設計了一款穴居人的 Skill。
在請求模型之前，它會自動壓縮 prompt 和上下文，讓傳輸的內容更短，但含義不丟。其次，它通過在本地持久化保存常用上下文或歷史對話，為 Agent 提供記憶以減少反覆調用。
這些壓縮策略和優化計劃能降低 Token 的消耗，項目主頁顯示可以省下 65% 的 AI 開支，目前在 GitHub 上即將達到 8 萬個 Star。
最近另一個叫「馬尾辮」的項目在 GitHub 上開始被瘋狂下載，直接拿下了 GitHub 熱門榜單連續三周的周榜第一。
這個項目的介紹圖也特別有意思，在項目描述里寫著，
你一定認識他，長長的馬尾辮，橢圓形眼鏡，在公司待的時間比版本控制系統的歷史還長。你給他看五十行代碼；他看了看，什麼也沒說，然後只用一行替換掉。
這套刻板印象不僅有點冒犯，給程序員看，他們大概還會表示，「女裝明明才是頂級程序員的底層邏輯」。
概括性地說，這根馬尾辮還是通過「少寫不必要的代碼」來減少 token 消耗。不過，它並非一個單純的壓縮或摘要工具，Ponytail 本身有一套 給 AI agent 的 Skill，讓 agent 在動筆之前先判斷好，怎麼用最少的 Token 可以完成這個任務。
而根據他們的測試，部分場景下，它能直接做到代碼量減少 80-94%，成本降低 47-77%，速度提升 3-6 倍。和其他類似工具的對比，馬尾辮要比穴居人在 Token 消耗、成本、時間和代碼行數上都要少，並且 100% 安全。
我們也把它安裝到 Codex 上體驗了一下，發現在部分場景下，Ponytail 確實能保證在結果一致的情況下，使用更少的 Token，但也會有新的麻煩點。
安裝到 Codex
如果在 Codex 插件市場輸入「Ponytail」可以直接搜索到的話，就能直接點擊安裝了。
如果沒有，我們需要打開電腦終端，在命令行中輸入「codex plugin marketplace add DietrichGebert/ponytail」，等待終端顯示已經安裝完成即可。
在 Codex 應用內，點擊插件主頁右上角的刷新按鈕，在 Personal 部分就會顯示已經安裝好的 Ponytail。
可以看到 Ponytail 的介紹裡面直接寫著「YAGNI」，即 You Aren't Gonna Need It 的縮寫，直譯過來就是「你不會需要它的」。這也是極限編程（XP）里的一條原則，核心意思是：在真正需要某個功能之前，別去實現它。
Ponytail 的插件內包含了 6 個 Skill，這些技能里只有第一個是真正會動手改代碼的，其餘五個都是圍繞這個理念做的檢查、記賬和展示工具。
第一個主 Skill Ponytail，開啟後強制走最精簡路線，支持三檔強度：lite（輕）、full（默認）、ultra（極端）。觸發詞包括 「ponytail」、「be lazy」、「簡單點」、「yagni」、「少做點」，或者在用戶吐槽某段代碼過度設計、充斥樣板代碼、依賴過多時也會觸發。
Ponytail Review 和 Ponytail Audit 主要是看代碼的改動以及整個倉庫的代碼，掃描整個代碼庫，給一份排好序的清單，什麼該刪、什麼該簡化、什麼能換成標準庫/原生實現。
Ponytail Debt 意思是技術債賬本，Ponytail 偷懶時會留下 ponytail: 注釋，標記「這裡先這麼糊弄，以後再說」。這個技能可以把全代碼庫里這些注釋收集起來，整理成一份債務清單，免得那些故意留下的捷徑毀了整個項目。
Ponytail Gain 則是把 Ponytail 的實測效果做成一個緊湊記分牌：少寫了多少代碼、省了多少成本、快了多少，數據來自基準測試的中位數。
不過技能是被動加載的，我們必須手動選擇使用該插件，或者在提示詞裡明確說出「Ponytail」等觸發詞，模型才會判斷該用某個技能了。
因此 Ponytail 還設置了 3 個鉤子，全部信任後，能保證 ponytail 在「會話開頭、每一輪對話、以及派給子智能體時」都不掉線。
了解了 Ponytail 的基本情況，我們做了一些簡單的小測試，像是實現同樣的提示詞任務，最後交付的成果和 Token 使用會不會有大的差別。
我們還沒有啟用鉤子，於是從插件市場的「在對話中試用」去開啟。最明顯的不同，就是 Ponytail 會一直問我問題，像是要做桌面鍵盤還是手機滑動。雖然說著如果懶得選，它會按 B 開工，但事實是我們必須輸入對應選項，任務才會繼續。
回答了這個問題之後，又有新的問題，要做什麼樣的視覺取向。我想在 Ponytail 的技能裡面，大概提到了如果要偷懶，還是要給用戶選擇，以何種形式來呈現最終的結果，Ponytail 自己無法決定是否真的採用極簡實現。
最後呈現的效果其實差不多，使用 Ponytail 消耗的 Token 是 103815，剩餘 60%，而沒有使用該插件是 109033，剩餘 58%，相差並不是很大，遊戲的體驗上，也都類似，簡單的 2D 風格，三個不同的跑道，設置的障礙物都類似。
而如果是讀同一個代碼倉庫，分別要求他們「幫我看看這個倉庫里有些什麼 bug，這個倉庫是一個什麼代碼倉庫」。
正常情況下，Codex 在當前的會話裡面使用 243923 個 Token，剩餘 6%，得出的結論是
這是一個股票智能分析系統倉庫：Python 後端 + FastAPI API + 多數據源行情抓取 + LLM 分析報告 + 通知推送，另外有 React Web 工作檯和 Electron 桌面端。覆蓋 A 股、港股、美股等，自選股分析、市場復盤、歷史報告、回測、配置管理、機器人/通知都在裡面。
而診斷出的 Bug/風險有 5 個，大多是在本地部署或者雲部署過程中，有裸奔風險的提醒。
在 Ponytail 的測試過程中，它的思考流程里則是很清楚地寫著「接下來我會跑最便宜的確定性檢查：先看 Python 語法和關鍵靜態錯誤。能被機器直接抓住的 bug，優先讓機器抓。」
Ponytail 用時 5 分鐘，得出的結論和不使用 Ponytail 插件的結果類似，掃描到的問題也有 5 個，基本和正常狀態的 Codex 一樣，同樣提到了在本地或者雲端部署時，可能會有風險。
但這次 Codex 還剩餘 26% 的 Token，而未使用 Ponytail 的任務里，只剩下了 6% 的上下文 Token 餘量，直接省下了 52277 個 Token。
所以，不同的任務，應用 Ponytail 的效果也可能有所不同。
馬尾辮的適用場景有哪些
根據 Ponytail 官方的測試，他們挑選了一些前端和後端任務。
比如寫一個日期選擇器、顏色選擇器、文件上傳框。普通 Agent 很可能上來就裝依賴、寫組件、加樣式、補狀態管理，最後一個小功能變成幾十行甚至幾百行代碼。
Ponytail 會先問一句：平台自己有沒有？標準庫有沒有？代碼庫里有沒有現成實現？
同樣用 Claude Code + Haiku 4.5 跑 12 個真實功能任務，不同省代碼策略相對普通 Claude Code 的表現。
測試的結果也顯示，Ponytail 在這些場景下省得最明顯。代碼行數 LOC 上，日期選擇器從 baseline 的 404 行降到 23 行，顏色選擇器從 287 行降到 23 行，文件上傳從 251 行降到 95 行。
所以它適合這幾類任務：
一類是前端小功能。表單控制項、設置項、簡單交互、上傳、篩選、排序、彈窗、評分、開關、日期和顏色選擇，都容易被 Agent 重複寫一遍。
其次是已有項目里的局部修改。比如「加一個欄位」「補一個校驗」「修一個邊界情況」「把這個頁面接上已有 API」。Ponytail 會優先讀現有代碼，復用項目里已經存在的函數、組件和模式。
還有代碼評審和項目瘦身等任務。對於「從零開始做一個完整產品」這類任務，省 Token 或者省代碼行數未必明顯。
就像 Ponytail 採用的方式是持續的判斷，Agent 動手前，要像爬梯子一樣，一關一關去檢查。
能不做，就跳過。代碼庫已經有，就復用。標準庫能做，就用標準庫。平台原生能做，就用平台。已安裝依賴能做，就用依賴。一行能做，就寫一行。走到這裡還不夠，再寫最小可用實現
。
。但這個判斷的過程，對於部分 LLM 來說也是一種新的負擔。也有網友說，代碼行數並不是越少越好，可讀性也是其中非常重要的一點。
也有網友說，用了 Ponytail 之後，實測 Token 消耗回到了當時兩倍促銷活動的水平。
其實除了 Ponytail 和 穴居人，類似的工具還有很多，例如 Headroom 淨空，同樣是在工具輸出、日誌、文件和 RAG 數據塊等上下文，到達 LLM 之前對其進行壓縮，顯示能減少 60-95% 的 Token， 並保持結果不變。
有意思的是，開發 Headroom 的作者還是一位 Netflix 的工程師。
還有 RTK-AI，一個命令行 Agent 工具，專門用於在各類 AI 編程助手，如 Claude Code、Cursor、Copilot 等，自動把命令的輸出壓縮 60%~90%，從而大幅減少發送給大模型的 token 數量，實現省錢的同時還能提高響應速度。
、Copilot 等，自動把命令的輸出壓縮 60%~90%，從而大幅減少發送給大模型的 token 數量，實現省錢的同時還能提高響應速度。
這些工具表面上是在幫用戶省 Token，背後其實是在教 Agent 學會克制。
過去一年，大家討論更多的是怎麼讓 Agent 做得更多：更長的上下文、更複雜的規劃、更強的工具調用能力。於是 Agent 逐漸養成了一種習慣——遇到問題先開干，先生成，再修改，最後補丁摞補丁。
但隨著 Token 開始成為真實成本，另一條路線也開始出現：哪些步驟其實可以跳過，哪些代碼其實已經存在，哪些工作其實沒必要重複完成。
對於人類程序員來說，這並不是什麼新理念。優秀工程師最大的價值，大多數時候體現在他的判斷力上，知道怎麼寫出最優美的代碼。
如今，這種判斷力也開始被封裝成各種 Skill 和工作流，成為 Agent 學習的新內容。
以往 Claude Code 和 Codex 是最擅長從社區找各種 idea 然後打包成自己的產品，之前的做夢機制、桌面寵物等功能都是先有個人開發者做出來類似的小玩意，然後被 Claude Code 複製過去。
但現在這種省 Token 的機制，恐怕 Codex/Claude Code 那邊是只想等著你充錢，免費不夠，請開 Plus，Plus 不夠，請開 Pro，Pro 還不夠，請買點數。
