作者： Ponytail：讓 AI 代理像資深工程師般懶惰的技巧
Ponytail 是一套能讓 AI 代理優先選擇最小變更的規則集。本文解析其決策階梯機制、v5.3.2 版本更新重點，並說明如何透過 DietrichGebert/ponytail 儲存庫設定，有效減少不必要的程式碼產出。
什麼是 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 日間就發布了十個標籤。其發展速度未曾減緩：截至 2026 年 10 月 17 日，最新版本為 v5.3.2（發布於 10 月 16 日深夜），這是該日繼 v5.3.0 與 v5.3.1 之後的第三個版本。在此之前，10 月 13 日發布了 v5.2.0，而 10 月 8 日則同時推出了 v5.0.0 與 v5.1.0，目前該儲存庫已累積超過 165,000 顆星。由於專案迭代速度極快，當你閱讀此文時內容可能已有變動，因此在基於此專案進行開發前，請務必鎖定特定標籤版本。
工具之前的核心概念：在第一個可行的層級停下
Ponytail 的核心是一套決策階梯。代理程式在撰寫任何程式碼前會先爬上階梯，並在第一個可行的層級停下。
- 這真的有必要存在嗎？這是 YAGNI（你不會需要它）原則。如果答案是否定的，請跳過。
- 這個程式碼庫中是否已經存在？請重複使用現有的輔助函式或模式。
- 標準函式庫是否已提供？請直接使用。
- 原生平台功能是否已涵蓋？請直接使用。
- 現有的已安裝相依套件是否能解決？請直接使用。
- 能否寫成一行？請寫成一行。
- 只有在上述條件皆不適用時，才撰寫能運作的最小程式碼。
這就是 v4.8.4 所記載的階梯，本文其餘部分的層級編號皆依此順序。目前的 main 分支將第 3 與第 4 層級合併為「標準函式庫或平台功能？若專案本身無特殊需求，請直接使用」，並補充「自製元件優於原生元件」，因此共有六個層級。順序保持不變。
發揮作用的是整個順序，而非單一層級。若要求代理程式製作日期選擇器，它會直接撰寫一個，因為這是它被賦予的任務。階梯機制強迫它在建置前先檢查現有資源：第 2 層級要求檢查儲存庫是否已有相關元件，而第 4 層級則指出瀏覽器已內建 <input type="date">。專案目前的基準測試正好記錄了此案例：在沒有規則的情況下，日期選擇器需 335 行程式碼，但在使用 Ponytail 5 後縮減至 10 行，因為代理程式重複使用了儲存庫內部的 Input 元件並搭配 type="date"，同時讓瀏覽器提供日曆功能。顏色選擇器的縮減幅度較小，從 135 行降至 26 行。第 2 層級最容易悄無聲息地失敗，因為若代理程式無法看見你現有的輔助函式，它會很樂意再寫一個重複的，這正是 可查詢的程式碼庫地圖 旨在彌補的缺口。
這裡的「懶惰」並不代表草率，規則集對此有直接說明。其「絕不懶惰」清單涵蓋了：在決策前理解問題、在信任邊界進行輸入驗證、防止資料遺失的錯誤處理、安全性、無障礙設計，以及任何你明確要求的項目。它同時要求針對每段非瑣碎的邏輯，編寫一個小型且可執行的檢查。此規則旨在減少重複發明，而非犧牲正確性。
此儲存庫實際發布的內容
AGENTS.md：常駐規則集，這是整個概念的核心，您可以在五分鐘內讀完。skills/ponytail/SKILL.md：技能定義，包含lite、full、ultra或off的參數提示。- 位於編輯器專屬目錄（如
.cursor/rules/和.windsurf/rules/）下的規則檔案，適用於僅讀取規則但不載入技能的主機。 hooks/、benchmarks/、examples/與scripts/。
intensity 參數會改變規則的執行強度。lite 會建立您要求的內容，並在一行內列出較寬鬆的選項。full 為預設值，強制執行階梯式規則。ultra 是 YAGNI 極端設定：它傾向於刪除而非新增，甚至會質疑需求本身。
支援技能的主機亦可使用斜線指令。/ponytail 用於設定層級，/ponytail-review 用於檢查是否存在過度設計的差異，/ponytail-audit 用於檢查整個儲存庫，/ponytail-debt 用於收集您延後處理的捷徑，/ponytail-gain 則用於列印基準測試評分表。僅讀取規則檔案的主機將獲得不含指令的規則集。自 2026 年 10 月 16 日發布的 v5.3.0 起，Claude Code 在提示詞上方新增了一個顯示任務成本、程式碼重用率與測試狀態的橫幅。此功能需要 Claude Code 2.1.290 或更新版本，它不會出現在 VS Code 聊天面板、雲端工作階段或 claude -p 中，且 /ponytail band off 會將其隱藏。自 v5.3.2 起，/ponytail band import 會讀取您過去的 Claude Code 工作階段一次，並將其成本、代理執行時間與 Token 用量加入儀表板，以便您與規則執行下的工作階段進行比較。
若要在信任前閱讀原始碼，請複製標籤（tag）而非分支（branch）。上述階梯式規則即來自此標籤；請替換為 2026 年 10 月 17 日最新的 v5.3.2 以閱讀當前版本：
git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git在 Claude Code 上，專案改為記錄外掛程式安裝方式，以下兩行為 2026 年 10 月 17 日記錄的內容：
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail外掛程式路徑追蹤的是預設分支而非標籤，因此引導代理的指令可能會在不同工作階段間發生變更。這是為了換取更新指令的便利性所必須接受的權衡。
為何在 VPS 上使用「懶惰」的 Agent 更省錢
Agent 寫入的 diff 不會離開對話。在下一個回合中，這些內容會成為模型再次讀取的上下文，連同它為了產生該 diff 所開啟的每個檔案一併讀取。因此，一個 500 行的變更會對該對話後續的每個回合造成負擔，直到壓縮機制以摘要取代舊回合為止，而不僅僅是產生該變更的回合。這就是為什麼失控的重構會讓 Agent 隨著對話進行顯得越來越慢且笨拙：視窗被 Agent 自身的輸出填滿，導致留給您實際程式碼的空間縮小。控制這一點正是 管理 AI 程式設計 Agent 的上下文視窗 的核心主題。
Token 的計費包含輸入與輸出，因此體積減半的 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 個回合。它也適用於您在同一台機器上啟動的第二個 session，該 session 會讀取已提交的檔案，但不會繼承您在第一個 session 中輸入的任何內容，即使 這兩個 session 可以互相傳遞訊息 也是如此。
新的相依套件是另一個隱性成本。第 5 條規則要求使用已安裝的套件。Agent 自行新增的每個套件，都是您日後需要修補的項目，且最終會進入您從該儲存庫建構的每個容器映像檔中。
Ponytail 自身的基準測試數據說明
該專案發布了兩類結果，且兩者之間存在顯著差異。這兩組數據皆為專案官方發布，並非獨立測試。
此圖表背後的資料
[
{
"label": "Lines of code",
"v4_13_pct": 48,
"v5_pct": 53
},
{
"label": "Cost per run",
"v4_13_pct": 16,
"v5_pct": 26
},
{
"label": "Wall clock time",
"v4_13_pct": 38,
"v5_pct": 41
}
]此圖表為該專案目前的代理基準測試，日期為 2026 年 10 月 7 日。測試使用 Opus 5.5 模型，在預設努力程度下執行 Headless Claude Code 2.1.288 工作階段，共處理 39 項任務，每個任務與分支執行 5 次，總計 585 個工作階段，涵蓋無技能、Ponytail v4.13.0 與 Ponytail 5 三種情境。其中 12 項任務為 tiangolo 的 full-stack-fastapi-template 專案中的功能需求單（這是一個真實的 FastAPI 與 React 儲存庫），評分標準為產生的 git diff。其餘任務包含 18 項帶有隱藏檢查的修復任務、6 項小型應用程式請求以及 3 項「展示範例」請求。所有分支皆停用 Bash。Ponytail 5 的輸出 token 減少了 45%。
將此數據與該專案於 2026 年 6 月發布的單次執行（single shot）數據進行對比。後者來自於單純模型回答 5 個日常提示，並比較有無使用該規則的結果，數據為多次執行的中位數。當時報告顯示 Haiku、Sonnet 與 Opus 的程式碼量減少了 80% 至 94%，且 2026 年 6 月 17 日的成本驗證顯示 Haiku 成本降低了 63%。目前 Ponytail 5 的代理測試結果為程式碼行數減少 53%，成本降低 26%，執行時間縮短 41%。該專案很快修正了單次執行數據。到了 2026 年 6 月 29 日，如 v4.8.4 所示，README 已將代理測試結果作為標題，標註為「減少約 54% 程式碼（最高可達 94%）」，並註明先前 80% 至 94% 的數據為「單項任務上限，而非平均值」，並將單次執行數據移至標題為「較舊的單次執行數據」的摺疊區塊中。該區塊誠實說明了差異存在的原因：單次執行基準是基於「以冗長文字與選項填充答案」的單純模型，這很容易被超越。若以執行實際工作的真實代理進行衡量，優勢會縮小。但這項數據依然真實，且更具參考價值。該次 6 月的代理測試（在 Haiku 4.5 上執行 12 張需求單，每張執行 4 次）結果與今日數據相近，程式碼行數減少了 54%，而目前的 README 已不再列出單次執行數據。
該專案本身提出了一個注意事項，這也是決定此工具是否對您有幫助的關鍵：當存在嚴重的過度建構陷阱時，節省效果最為顯著；而對於已經精簡的程式碼，節省效果幾乎為零。10 月份的單項任務表格證實了這一點，多項修復任務在三種情境下的程式碼行數相同。在單一模型與單一主機上、且停用 Bash 的情況下進行 39 項任務測試，無法預測您儲存庫的實際表現。若您在意這些數據，請使用您自己的需求單，在有無該規則的情況下進行對比測試，並親自計算行數。
您可以立即複製且無需安裝任何軟體的模式
此階梯結構為純文字，因此您不需要外掛程式即可使用此概念。請將類似下方的區塊貼入您的代理程式已在讀取的指令檔案中，無論該檔案是 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 在目前的發行版本中，採用了標記為 shortcut: 的註解慣例，用以說明限制條件與升級時機（6 月份的發行版本，包含 v4.8.4，改為標記 ponytail:）：
# shortcut: global lock, per-account locks if throughput matters該註解僅需兩行工作量，卻能解決一個原本需要耗費審查週期才能釐清的問題。它告知下一位閱讀者，採用簡易版本是經過決策的結果，並指明了該決策失效的條件。若無此註解，審查者無法分辨這是經過深思熟慮的捷徑，還是代理程式遺漏的項目，因此必須額外詢問。
區塊放置的位置與其內容同樣重要。代理程式每次執行時都會載入的檔案，會引導每一次的執行過程，包含您未監控的那些次數。該差異正是 撰寫代理程式確實會遵循的 AGENTS.md 的主題，這也是為何此模式應存放在已提交的檔案中，而非您的 shell 歷史紀錄內。在 monorepo 中，它應存在於多個已提交的檔案中，因為 每個套件配置一個 AGENTS.md 能保持各目錄規則的簡潔，而不必讓代理程式在每次執行時都讀取整個樹狀結構的慣例。不過，放置位置並非萬無一失，在您斷定該階梯需要更強硬的措辭之前，值得先了解 為何代理程式會忽略已載入的規則。
規則失效的場景
此階梯式方法適用於既有程式碼庫的功能開發，因為通常已有可重複使用的資源。它較不適合全新專案（greenfield project），因為第 2 階沒有資源可供重用，第 5 階也沒有已安裝的套件。代理程式仍可停留在第 1 階（標準函式庫、平台功能或單行程式碼），但兩個成本最低的出口已不存在，導致更多任務必須透過撰寫新程式碼來解決。當您確實需要抽象化時，此方法也不適用。若您正準備為同一段複製的程式碼區塊新增第四個呼叫者，「最短差異（shortest diff）」原則會讓您產生第五份副本。
ultra 層級將挑戰您的需求。這正是該層級的目的，但當您已做出決定並希望完成工作時，這會成為實際的成本。請將 full 用於一般工作，並在懷疑功能需求本身有問題時，改用 ultra。
任何指令區塊都無法避免您對問題的誤讀。此規則集的第一項即是「在決策前理解程式碼」，這是最耗時的部分，也是文字無法代勞的部分。在錯誤的函式中進行最小差異修改，依然是錯誤的修復，且這會變成一個容易被核准的小型錯誤修復。
誠實的總結是，Ponytail 是一個經過精心撰寫、分發良好且附帶編號的提示詞（prompt）。其中沒有任何內容強制要求使用外掛程式。該專案提供的價值在於，有人正確地編寫了此清單，並在真實的儲存庫中進行測試，最後將方法與結果一併公開。
FAQ
Ponytail 是否支援 Claude Code 以外的代理程式？
支援。它以技能（skill）形式發布，適用於支援載入技能的宿主程式，包括 Claude Code、Codex、OpenCode、Gemini 以及 README 中提到的其他程式。對於僅讀取規則檔案但不載入技能的編輯器（如 Cursor、Windsurf、Cline 和 Copilot），它們會採用對應規則目錄中的常駐規則集（always-on ruleset），但無法使用斜線指令（slash commands）。無論哪種方式，文字內容皆相同，主要差異在於宿主程式是將這些文字持續保留在上下文（context）中，還是僅在觸發技能時才載入。
懶惰的代理程式會跳過測試、驗證或安全性檢查嗎？
不會，規則集對此有明確規範。其「絕不懶惰」（never lazy about）清單列出了信任邊界（trust boundaries）的輸入驗證、防止資料遺失的錯誤處理、安全性與無障礙設計，並要求針對每一段非瑣碎的邏輯提供一個小型可執行檢查。此規則移除的是無謂的結構：無人要求的抽象化與不必要的依賴。若安裝後代理程式開始忽略測試，原因在於您個人設定檔中存在優先級更高的指令，請檢查代理程式最後載入的檔案。
公布的速度與成本數據可信嗎？
這些數據為專案自行測量，並已附上測量方法，請依此解讀。2026 年 6 月的單次執行數據是與一個會用冗長文字與選項填充答案的基礎模型進行比較，當時的 README 已標註該基準（baseline）較弱。目前的代理程式數據來自 Opus 5.5 上的無頭（headless）Claude Code 工作階段，共 39 個任務，每個任務執行 5 次，其中 12 個為 FastAPI 與 React 儲存庫的功能需求單（feature tickets）。對於該設定而言，這些數據是誠實的。它們並非您程式碼庫的效能預測，因為專案本身的單一任務結果顯示，對於已經極簡化的程式碼，節省效果趨近於零。
我需要安裝任何東西才能獲得效益嗎？
不需要。這套規則本質上是文字，將等效的區塊貼入代理程式已讀取的指令檔中，即可獲得大部分效果。外掛程式提供的是維護好的措辭、強度等級、審查指令與更新路徑。先嘗試複製區塊是評估是否需要安裝的第一步。
如何防止無人看管的代理程式在夜間過度建構？
將規則放入常駐指令檔（always-on instruction file）而非聊天訊息中，這樣它在長任務執行到第 200 回合時依然有效，而不僅限於第 3 回合。接著將損害控制分開處理：給予代理程式一個允許被破壞的 checkout 版本，而非直接操作您的唯一副本，並要求在合併前進行人工 diff 審查。最小化 diff 規則可減少您的閱讀量，但它不應決定最終合併的內容。