Codex 一鍵省 Token 大法，親測有效

每次寫 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 數量，實現省錢的同時還能提高響應速度。

這些工具表面上是在幫用戶省 Token，背后其實是在教 Agent 學會克制。

過去一年，大家討論更多的是怎么讓 Agent 做得更多：更長的上下文、更復雜的規劃、更強的工具調用能力。于是 Agent 逐漸養成了一種習慣——遇到問題先開干，先生成，再修改，最后補丁摞補丁。

但隨著 Token 開始成為真實成本，另一條路線也開始出現：哪些步驟其實可以跳過，哪些代碼其實已經存在，哪些工作其實沒必要重復完成。

對于人類程序員來說，這并不是什么新理念。優秀工程師最大的價值，大多數時候體現在他的判斷力上，知道怎么寫出最優美的代碼。

如今，這種判斷力也開始被封裝成各種 Skill 和工作流，成為 Agent 學習的新內容。

以往 Claude Code 和 Codex 是最擅長從社區找各種 idea 然后打包成自己的產品，之前的做夢機制、桌面寵物等功能都是先有個人開發者做出來類似的小玩意，然后被 Claude Code 復制過去。

但現在這種省 Token 的機制，恐怕 Codex/Claude Code 那邊是只想等著你充錢，免費不夠，請開 Plus，Plus 不夠，請開 Pro，Pro 還不夠，請買點數。