Ponytail 安裝教學：Codex、Claude Code 和 Gemini CLI 怎麼用

Ponytail 是一個很有意思的 AI 編碼外掛。

它不是讓 AI 更會「炫技」，而是反過來提醒 AI：先別急著寫程式，先看看這件事能不能不寫、能不能複用、能不能用標準函式庫、能不能用瀏覽器或平台自帶能力解決。

如果你經常遇到這種情況：

1
2
3


只是想要一個日期選擇器，AI 卻裝了元件庫、寫了封裝、加了樣式，還開始討論時區。
只是想改一個小邏輯，AI 卻順手抽象出三層 helper。
只是想修一個 bug，AI 卻重構了半個檔案。

那 Ponytail 的思路就很對味：讓 AI 像一個懶但可靠的資深開發者一樣，先找最小改動。

Ponytail 是什麼

Ponytail 可以理解成一組給 AI 編碼代理看的工作規則。

它會提醒代理在寫程式前先按一條「階梯」判斷：

1
2
3
4
5
6
7


1. 這個東西真的需要存在嗎？
2. 程式庫裡是不是已經有了？
3. 標準函式庫能不能做？
4. 平台原生能力能不能做？
5. 已安裝依賴能不能做？
6. 一行程式碼能不能解決？
7. 最後才寫剛好夠用的新程式碼。

這不是 code golf，也不是盲目追求短。它強調的是少做無效工作：能刪就刪，能複用就複用，能用原生能力就別造輪子。

README 裡有一個很典型的例子：日期選擇器。

普通 AI 可能會裝 flatpickr，寫 wrapper，補樣式，再解釋一堆邊界情況。

Ponytail 風格會先想到：

1

<input type="date">

這就是它想訓練 AI 做的判斷。

它解決的不是「程式碼短」，而是「別過度設計」

Ponytail 最容易被誤解成「讓 AI 寫一行程式碼」。

其實更準確的說法是：讓 AI 少做沒必要的設計。

它保留安全邊界，不鼓勵刪掉必要的校驗、錯誤處理、安全處理和可訪問性。該做的仍然要做，只是不要為了一個很小的需求引入一堆額外複雜度。

適合它處理的場景包括：

前端小功能；
表單控制項；
簡單工具函式；
設定檔調整；
小型 bug 修復；
程式碼審查時發現過度實作；
AI 改程式前的約束提醒；
讓代理優先查找現有實作。

不適合把它理解成：

永遠只寫一行；
永遠不加依賴；
永遠不重構；
為了少程式碼犧牲可維護性；
為了速度跳過閱讀程式碼。

Ponytail 的重點是「懶於實作，不懶於閱讀」。

支援哪些 AI 編碼工具

從 README 看，Ponytail 覆蓋的工具很多，包括：

Claude Code；
Codex；
GitHub Copilot CLI；
Pi agent harness；
OpenCode；
Gemini CLI；
Antigravity CLI；
CodeWhale；
Swival；
OpenClaw；
Cursor、Windsurf、Cline、Aider、Kiro、Zed 等規則檔方式。

這類專案的好處是：你不一定非要換主力 AI 工具。

如果你現在用的是 Codex，就按 Codex 外掛方式裝；如果你用 Claude Code，就走 Claude Code 外掛市場；如果只是想把規則放進編輯器，也可以複製對應的規則檔。

Codex 裡怎麼安裝 Ponytail

如果你使用的是 Codex CLI，README 給出的入口是：

1
2


codex plugin marketplace add DietrichGebert/ponytail
codex

然後在 Codex 裡：

打開 /plugins；
選擇 Ponytail marketplace；
安裝 Ponytail；
打開 /hooks；
檢查並信任它的兩個 lifecycle hooks；
開一個新對話開始使用。

如果你用的是 Codex 桌面版，README 也提到：安裝完成後重新啟動應用程式，外掛會被識別。

注意一點：Ponytail 的 Claude Code 和 Codex 外掛會執行兩個很小的 Node.js lifecycle hooks，所以 node 需要在 PATH 裡。README 也說明，如果沒有 node，skills 仍然可以工作，只是 always-on 啟用不會自動生效。

可以先檢查：

1

node -v

如果命令找不到，先安裝 Node.js，或者確認目前非互動 shell 的 PATH 能找到 node。

Claude Code 怎麼安裝

Claude Code 的安裝命令是：

1

/plugin marketplace add DietrichGebert/ponytail

然後再發一條：

1

/plugin install ponytail@ponytail

README 特別提醒，這兩條需要分兩次傳送。

如果你用的是 Claude 桌面應用程式，沒有 /plugin 命令，需要從 UI 裡新增個人外掛市場：

打開 Customize；
點擊 personal plugins 旁邊的加號；
建立外掛並新增 marketplace；
選擇 Add from repository；
輸入 Ponytail 的 GitHub 倉庫地址。

GitHub Copilot CLI 怎麼安裝

Copilot CLI 可以用：

1
2


copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

在互動式 Copilot CLI 會話裡，也可以用 slash 命令：

1
2


/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

安裝後，Copilot CLI 裡可以透過 Ponytail 命令使用不同能力，例如 README 中提到的：

1
2


/ponytail:ponytail ultra
/ponytail:ponytail-review

Gemini CLI 和 Antigravity CLI

Gemini CLI 的安裝方式是：

1

gemini extensions install https://github.com/DietrichGebert/ponytail

它會把規則集作為每次會話的上下文載入，並註冊 /ponytail 相關命令。

Antigravity CLI 可以用：

1

agy plugin install https://github.com/DietrichGebert/ponytail

README 裡還提到，Google 正在把 Gemini CLI 改名為 Antigravity CLI，所以一段時間內兩種路徑可能會並存。實際使用時，按你目前安裝的 CLI 名稱來。

OpenCode 怎麼用

OpenCode 可以在 opencode.json 中加入：

1

{ "plugin": ["@dietrichgebert/ponytail"] }

如果你從本地 checkout 執行，也可以指向本地外掛檔：

1

{ "plugin": ["./.opencode/plugins/ponytail.mjs"] }

這種方式適合已經在 OpenCode 裡管理專案設定的人。

只想用規則，不想裝外掛怎麼辦

Ponytail 倉庫裡還放了很多不同工具的規則檔。

例如：

AGENTS.md；
.cursor/rules/；
.windsurf/rules/；
.clinerules；
.github/copilot-instructions.md；
.kiro/steering/。

如果你的工具支援讀取專案級規則，可以直接複製對應檔案。

比如 VS Code 的 Codex 擴充會讀取 AGENTS.md。如果你把 Ponytail 的 AGENTS.md 放到專案根目錄，或者放到全域 Codex 設定位置，就可以用規則方式讓 Codex 遵循這套思路。

外掛方式更完整，規則檔方式更輕。

Ponytail 適合怎麼提示

裝完以後，不要只期待它「自動變聰明」。你也可以在任務裡主動配合它。

比如：

1

請先檢查現有程式碼裡是否已經有類似實作，優先複用；只有確實沒有時再新增最小實作。

或者：

1

這個需求不要過度設計。先判斷是否可以用標準函式庫、原生 HTML 控制項或已有依賴解決。

再比如做 code review：

1

請按 Ponytail 思路審查這次改動，重點找過度抽象、重複實作、不必要依賴和可以用原生能力替代的地方。

這類提示和 Ponytail 的規則方向一致，效果會更穩定。

適合用 Ponytail 的典型任務

1. 前端控制項

比如日期、顏色、檔案上傳、數字輸入、開關、下拉選擇。

AI 很容易一上來裝元件庫，但很多場景原生 HTML 控制項已經夠用。

2. 工具函式

比如去重、排序、格式化、路徑處理、日期處理。

先看語言標準函式庫和專案已有 helper，再決定要不要寫新函式。

3. 設定改動

比如 ESLint、TypeScript、Hugo、Vite、Docker、CI 設定。

很多設定問題只需要改一行，不需要寫腳本或新增工具鏈。

4. 小 bug 修復

Ponytail 思路適合先找最小修復點，避免 AI 為了修一個 bug 引出大重構。

5. 程式碼審查

它很適合當作「過度設計檢查器」。

你可以讓 AI 看 diff，專門回答：

有沒有重複造輪子；
有沒有沒必要的新依賴；
有沒有可以直接刪除的程式碼；
有沒有複雜度超過需求的實作；
有沒有可以複用現有模組的地方。

使用時要注意什麼

Ponytail 的方向很好，但不要把它變成新的教條。

下面這些場景不能為了少程式碼而硬省：

輸入校驗；
權限檢查；
資料丟失保護；
並發和交易安全；
使用者隱私；
可訪問性；
錯誤處理；
關鍵日誌；
測試覆蓋。

簡單不是粗糙。

如果一個功能涉及安全邊界、資金、使用者資料、生產環境操作，最小實作也必須把邊界處理清楚。

我的建議用法

如果你第一次用 Ponytail，可以按這個順序試：

先在一個小專案裡安裝；
用一個很容易過度實作的需求測試，比如日期選擇器或顏色選擇器；
對比沒有 Ponytail 時 AI 會寫什麼；
再讓它審查一次已有 diff；
最後再放到日常專案裡。

不要一上來就拿大重構測試。

Ponytail 最能體現價值的場景，是那些「本來很小，但 AI 特別容易寫大」的任務。

一句話總結

Ponytail 不是讓 AI 變成只會寫短程式碼的工具，而是讓 AI 在動手前多問一句：

1

這段程式碼真的需要寫嗎？

如果你用 Codex、Claude Code、Copilot CLI、Gemini CLI 這類 AI 編碼代理，經常被它們的過度實作煩到，可以試試 Ponytail。它不能替你判斷所有架構問題，但很適合給 AI 加上一層「少造輪子、少繞路、先複用」的約束。