Ponytail：讓 AI 代理像資深開發者一樣懶惰

什麼是 Ponytail

Ponytail 是一套規則集，旨在讓 AI 程式設計代理減少程式碼產出。該專案以一句話自我定義：「讓你的 AI 代理像辦公室裡最懶惰的資深開發者一樣思考。最好的程式碼就是你從未寫下的那些。」此專案採用 MIT 授權。它本身沒有執行時期，也不會執行任何內容。它是一段輸入至代理指令中的文字，對於支援載入技能的主機，它被封裝為一種技能；對於不支援的主機，則作為純文字規則檔使用。

該儲存庫位於 DietrichGebert/ponytail。它建立於 2026 年 6 月 12 日，並在 2026 年 8 月 1 日前突破 90,000 顆星。截至 2026 年 8 月 1 日，最新的標記版本為 v4.8.4，發布於 2026 年 6 月 29 日；僅在 6 月 14 日至 29 日期間，發布頁面就列出了十個標籤。一個發展如此迅速的專案在你閱讀此文時可能已經有所變動，因此在基於它進行開發前，請務必鎖定特定標籤版本。

工具之前的核心概念：在第一個穩固的階梯停下

Ponytail 的核心是一套決策階梯。代理程式在撰寫任何內容前會先爬上此階梯，並在第一個穩固的階梯停下。

1. 這真的有必要存在嗎？這是 YAGNI（你不會需要它）原則。如果答案是否定的，請跳過。
2. 這在現有的程式碼庫中已經存在了嗎？請重複使用現有的輔助程式或模式。
3. 標準函式庫能做到嗎？請使用它。
4. 原生平台功能有涵蓋嗎？請使用它。
5. 現有的已安裝相依套件能解決嗎？請使用它。
6. 能寫成一行嗎？請寫成一行。
7. 只有在上述條件都不適用時，才撰寫能運作的最小程式碼。

是這個順序在發揮作用，而非任何單一階梯。當代理程式被要求製作日期選擇器時，它會傾向於撰寫一個，因為這是它被賦予的任務。但決策階梯強迫它先檢查第 4 階，而第 4 階指出瀏覽器已經內建了 <input type="date">。該專案的基準測試正好記錄了此案例：在沒有此規則的情況下，日期選擇器寫了 404 行，但套用規則後僅需 23 行，因為代理程式選擇使用原生 input 而非自行建構元件。顏色選擇器也基於相同原因，從 287 行縮減至 23 行。

此處的「懶惰」並不代表草率，規則集對此有直接說明。其「絕不懶惰」清單涵蓋了：在決策前理解問題、在信任邊界進行輸入驗證、防止資料遺失的錯誤處理、安全性、無障礙存取，以及任何您明確要求的項目。它同時要求每一段非瑣碎的邏輯都必須包含一個小型可執行的檢查。此規則旨在減少發明，而非犧牲正確性。

此儲存庫實際發布的內容

• AGENTS.md：常駐規則集，這是整個概念的核心，您可以在五分鐘內讀完。
• skills/ponytail/SKILL.md：技能定義，包含 lite、full 或 ultra 的參數提示。
• 位於編輯器特定目錄（如 .cursor/rules/ 與 .windsurf/rules/）下的規則檔案，適用於僅讀取規則但不載入技能的主機。
• hooks/、benchmarks/、examples/ 與 scripts/。

intensity 參數會改變規則的執行強度。lite 會建構您要求的內容，並以單行指令列出更寬鬆的選項。full 為預設值，強制執行階梯式規則。ultra 是 YAGNI 極端設定：它傾向於刪除而非新增，甚至會質疑需求本身。

具備技能的主機亦支援斜線指令。/ponytail 用於設定層級，/ponytail-review 用於檢查差異以防過度設計，/ponytail-audit 用於檢查整個儲存庫，/ponytail-debt 用於收集您延後處理的捷徑，/ponytail-gain 則用於列印基準測試評分表。僅讀取規則檔案的主機則僅會獲得規則集，不包含任何指令。

若要在信任原始碼前進行審閱，請複製標籤（tag）而非分支（branch）：

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

針對 Claude Code，該專案改為記錄外掛程式的安裝方式，以下為 2026 年 8 月 1 日記錄的兩行指令：

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

外掛程式路徑會追蹤預設分支而非標籤，因此引導代理程式的指令可能會在您兩次工作階段之間發生變更。這是為了換取更新指令便利性所必須接受的權衡。

為什麼在 VPS 上使用「懶惰」的 Agent 更省成本

Agent 寫出的 diff 不會離開對話。在下一個回合中，這會成為模型再次讀取的上下文，連同它為了產生該 diff 所開啟的每個檔案一併讀取。因此，一個 500 行的變更會對會話中後續的每個回合造成負擔，而不僅僅是產生它的那個回合。這就是為什麼失控的重構會讓 Agent 隨著會話進行顯得越來越慢、越來越笨：視窗被 Agent 自己的輸出填滿，導致留給您實際程式碼的空間縮小。控制這一點正是 管理程式碼 Agent 上下文視窗 的核心課題。

Token 的計費包含輸入與輸出，因此大小減半的 diff 在成本上節省了兩次：一次是在寫入時，另一次是在每次重新讀取該 diff 的回合中。這種節省是否會反映在您的帳單上，取決於您的付費方式，因為 固定費率的 Pro 或 Max 訂閱 會吸收額外的 Token，而按 Token 計費的 API 則會對每一個 Token 收費。如果您是在自架環境中監控帳單，指令檔案就是一個無需成本即可操作的槓桿。控制 AI Agent 的成本 始於輸出量，而 程式碼 Agent 如何消耗 Token 則解釋了為什麼重新讀取的重要性超乎預期。

人類仍然需要閱讀 diff。一個本應只有 20 行卻寫成 400 行的變更，會消耗審閱者的注意力，而注意力是最先耗盡的資源。沒有人能以審閱第一份 diff 的專注度來審閱當天第四份冗長的 diff，因此過度建構不僅是浪費時間，還會悄悄降低本應攔截錯誤的審閱品質。

在伺服器上，風險會有所不同，因為 Agent 運作時通常無人監控。在 tmux session 或定時任務中運作的 Agent，在您發現之前，有數小時的時間基於錯誤的決策進行建構。這就是 在 VPS 上執行程式碼 Agent 的實際風險，也是為什麼進行 迴圈工程 (loop engineering) 的人會花費大量心力在常駐指令而非個別提示詞上的原因。寫在常駐檔案中的規則適用於第 200 個回合，而您在聊天中輸入的規則僅適用於第 3 個回合。

新增依賴項是另一個隱形成本。第 5 條規則要求使用已安裝的套件。Agent 自行新增的每個套件，都是您日後需要修補的項目，且會出現在您從該儲存庫建構的每個容器映像檔中。

Ponytail 自身基準測試數據的說明

該專案發布了兩組數據，且兩者之間存在顯著差異。這兩組數據均為專案自行發布，並非由第三方進行的獨立測試。

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

「單次執行」（single shot）欄位的數據來自於裸模型（bare model），針對一組小型提示詞（prompt）在有無套用規則的情況下進行回答，數據取自 2026 年 6 月 13 日與 17 日多次執行的中位數。「代理執行」（agentic）欄位的數據則來自於無頭模式（headless）的 Claude Code 工作階段，針對 tiangolo 的 full-stack-fastapi-template（一個真實的 FastAPI 與 React 儲存庫）進行編輯，共處理 12 張功能工單（feature ticket），並在 Haiku 4.5 上各執行 4 次，評分標準為最終產出的 git diff。

請參考第二欄數據。在代理執行模式下，程式碼行數減少了 54%，成本降低了 20%，實際執行時間（wall clock time）減少了 27%；而在單次執行設定中，對應的數據則分別為 93% 與 74%。README 文件誠實地說明了原因：單次執行的基準測試對象是一個「以多種選項外加評論進行回答」的裸模型，這非常容易被超越。若以執行實際工作的真實代理作為比較基準，其優勢就會縮小。但這也更貼近現實，是更具參考價值的資訊。

有一項專案方自行提出的注意事項，這也是決定該工具是否對你有幫助的關鍵：當程式碼存在嚴重的過度構建（over-build）問題時，節省效果最為顯著；若程式碼本身已極簡化，則幾乎沒有節省空間。在單一 Python 與 TypeScript 儲存庫中進行的 12 張工單測試，無法預測你自身儲存庫的表現。如果這些數據對你很重要，請在自己的工單上，分別在有無套用規則的情況下進行比較，並親自計算程式碼行數。

今日即可複製且無需安裝任何軟體的模式

此階梯結構為純文字，因此無需安裝外掛即可使用此概念。請將類似下方的區塊貼入您的代理程式已在讀取的指令檔案中，無論該檔案是 AGENTS.md、CLAUDE.md 還是您編輯器的規則檔案。

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

最後那條規則值得單獨說明。Ponytail 的慣例是使用標記了工具名稱的註解：

# ponytail: global lock, per-account locks if throughput matters

該註解僅佔兩行，卻能解決原本需要耗費一個審查週期才能釐清的問題。它向下一位閱讀者說明簡化版本是經過決策的結果，並指出了該決策失效的條件。若無此註解，審查者將無法分辨這是經過深思熟慮的捷徑，還是代理程式遺漏的項目，因而必須提出詢問。

放置區塊的位置與其內容同樣重要。代理程式每次執行時都會載入的檔案，能引導每一次的執行過程，包含您未在監控的那些次。此差異正是 撰寫代理程式確實會遵循的 AGENTS.md 的主題，也是此模式應存在於版本控制檔案中，而非您的 shell 歷史紀錄中的原因。

規則失效的場景

此階梯模型專為既有程式碼庫的功能開發而設計，在該環境下，程式碼重用通常可行且正確。它並不適用於從零開始的專案（greenfield project），因為第 2 階沒有可重用的內容，而第 5 階則沒有已安裝的元件，導致代理程式每次都會直接落入第 7 階。當您確實需要抽象化時，此模型也不適用。若您正準備為同一個複製區塊新增第四個呼叫者，「最短差異」（shortest diff）策略會讓您產生第五份副本。

ultra 層級將會挑戰您的需求。這正是該層級的目的，但當您已做出決定並希望完成工作時，這會成為實際的成本。請將 full 用於一般工作，並在懷疑功能需求本身有問題時，才使用 ultra。

任何指令集都無法避免您對問題的誤讀。規則集的第一項即是「在決策前先理解程式碼」，這是最耗費心力的部分，也是文字無法代勞之處。在錯誤的函式中進行最小差異修改，依然是錯誤的修復，且現在這變成了一個容易被核准的小型錯誤修復。

誠實的總結是，Ponytail 是一個經過精心編寫、分發完善且附帶編號的提示詞（prompt）。其中沒有任何內容強制要求使用外掛程式。該專案提供給您的價值在於，有人正確地編寫了這份清單，並在真實的儲存庫中進行了測試，最後將方法與結果一併公開。

FAQ

Ponytail 能與 Claude Code 以外的代理程式（agent）搭配使用嗎？

可以。它以技能（skill）形式發布，適用於支援載入技能的主機，清單包含 Claude Code、Codex、OpenCode、Gemini 以及 README 中提到的其他程式。至於會讀取規則檔案但無法載入技能的編輯器（如 Cursor、Windsurf、Cline 與 Copilot），則會從對應的規則目錄讀取常駐規則集（always-on ruleset），但無法使用斜線指令（slash commands）。無論哪種方式，文字內容皆相同，主要差異在於主機是在每一輪對話都將這些文字納入上下文，還是僅在觸發技能時才納入。

懶惰的代理程式會跳過測試、驗證或安全性檢查嗎？

不會，規則集對此有明確規範。其「絕不懶惰」（never lazy about）清單明確要求在信任邊界進行輸入驗證、實作能防止資料遺失的錯誤處理機制，並確保安全性與無障礙性；同時要求針對每一段非瑣碎的邏輯提供一個小型可執行檢查。此規則移除的是無謂的結構：即無人要求且不必要的抽象化與依賴。若安裝後代理程式開始忽略測試，原因通常是您設定檔中其他指令的優先級高於此規則，請檢查代理程式最後載入的檔案。

公布的速度與成本數據可信嗎？

這些數據是專案團隊自行測量並公開其方法，請以此角度解讀。單次執行（single shot）數據是與僅會回覆選項與評論的基礎模型進行比較，README 本身也指出這是一個較弱的基準。代理執行（agentic）數據則來自於一個 FastAPI 與 React 儲存庫的無頭（headless）Claude Code 工作階段，經由 12 個工單、每項執行 4 次，並使用 Haiku 4.5 模型測得。這些數據反映了該設定下的真實情況。但這並非您程式碼庫的預測數據，因為專案也提到，若程式碼本身已極簡化，節省效果將趨近於零。

我需要安裝任何東西才能獲得效益嗎？

不需要。這套規則本質上是文字，將對應的區塊貼入代理程式已讀取的指令檔中，即可獲得大部分效果。外掛程式提供的是維護好的措辭、強度等級、審查指令以及更新路徑。若想確認是否真的需要安裝，建議先嘗試複製該區塊作為第一步（rung 1）。

如何防止無人看管的代理程式在夜間過度建置？

將規則放入常駐指令檔（always-on instruction file）而非對話訊息中，這樣即使在長對話的第 200 輪也能生效，而不僅限於第 3 輪。此外，請另外限制損害範圍：給予代理程式一個允許被破壞的 checkout 版本，而非您的唯一副本，並要求在合併前必須經過人工 diff 審查。最小化 diff 規則能減少您的閱讀量，但它不應決定最終合併的內容。