Ponytail：讓 AI 程式設計代理程式少寫程式碼

Ponytail 是什麼

Ponytail 是一組規則，可讓 AI 程式設計代理程式撰寫較少程式碼。此專案用一句話描述自身：「讓你的 AI 代理程式像團隊中最懶惰的資深開發人員一樣思考。最好的程式碼，就是你根本沒有撰寫的程式碼。」本專案採用 MIT 授權。它本身沒有執行階段，也不會執行任何內容。它是要放入代理程式指示中的文字，會以 skill 形式封裝，供可載入 skill 的主機使用；對於不支援 skill 的主機，則以純文字規則檔案提供。

該 repository 是 DietrichGebert/ponytail。它建立於 12 June 2026，並在 1 August 2026 前累積超過 90,000 顆星。1 August 2026 的最新標記版本是 v4.8.4，於 29 June 2026 發布；releases 頁面僅在 14 至 29 June 期間就列出十個標記。以這種速度變動的專案，在你讀到本文時可能已經更新，因此在以它為基礎進行任何建置前，請先固定使用某個標記版本。

工具之前的思考：停在第一個可行階梯

Ponytail 的核心是決策階梯。代理程式在寫入任何內容前會逐級檢查，並在第一個成立的階梯停止。

1. 這項功能是否根本不需要存在？這就是 YAGNI（不需要的功能不應預先實作）。如果答案是否定的，就略過它。
2. 這項功能是否已存在於此程式碼庫中？重複使用現有的輔助程式或模式。
3. 標準函式庫是否能處理？使用它。
4. 原生平台功能是否能涵蓋？使用它。
5. 已安裝的相依套件是否能解決？使用它。
6. 能否寫成一行？就寫成一行。
7. 只有在此之後，才撰寫能運作的最少程式碼。

真正發揮作用的是順序，而不是任何單一階梯。代理程式收到建立日期選擇器的要求時，就會建立日期選擇器，因為這正是被要求執行的工作。這個階梯會讓它先檢查第 4 階，而第 4 階指出瀏覽器已經提供 <input type="date">。專案自己的基準測試筆記正好記錄了這個案例：未套用此規則時，日期選擇器產生了 404 行；套用後則只有 23 行，因為代理程式採用了原生輸入控制項，而不是建立元件。色彩選擇器也基於相同原因，從 287 行減少到 23 行。

這裡的「懶惰」不代表粗心，規則集也直接說明了這點。其「絕不偷懶」清單涵蓋：在決策前理解問題、在信任邊界驗證輸入、防止資料遺失的錯誤處理、安全性、無障礙功能，以及任何明確要求的事項。它也要求每一段非簡單邏輯都搭配一個小型且可執行的檢查。這項規則會減少自行發明，不會犧牲正確性。

儲存庫實際提供的內容

• AGENTS.md，這是常駐規則集，將完整概念集中在一個檔案中，5 分鐘內即可讀完。
• skills/ponytail/SKILL.md，技能定義，參數提示為 lite、full 或 ultra。
• .cursor/rules/ 和 .windsurf/rules/ 等編輯器專用目錄下的規則檔案，適用於會讀取規則但不載入技能的主機。
• hooks/、benchmarks/、examples/ 和 scripts/。

強度參數會改變規則施加的力度。lite 會建立你要求的內容，並在一行中指出較寬鬆的選項。full 是預設值，會強制執行階梯式規則。ultra 是 YAGNI 的極端設定：它偏好刪除而非新增，甚至會質疑需求本身。

支援技能的主機也會取得斜線指令。/ponytail 設定層級，/ponytail-review 檢查差異是否過度工程化，/ponytail-audit 檢查整個儲存庫，/ponytail-debt 收集你延後處理的捷徑，而 /ponytail-gain 會輸出基準測試成績表。只讀取規則檔案的主機則只能取得規則集，沒有指令。

若要在信任來源前先閱讀原始碼，請複製標籤，而不是分支：

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

Claude Code 的專案改為記載 plugin 安裝方式，以下兩行是截至 1 August 2026 的文件內容：

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

plugin 路徑會跟隨預設分支，而不是標籤。因此，不同工作階段之間，用來引導 agent 的指示可能在你未察覺的情況下變更。這是你為更新指令便利性所接受的取捨。

為什麼精簡的 agent 在 VPS 上成本更低

agent 編寫的差異不會離開對話。在下一輪中，模型會再次讀取這些內容，以及它為產生差異而開啟的每個檔案。因此，500 行的變更不只會增加產生該變更那一輪的負擔，也會增加工作階段後續每一輪的負擔。這就是為什麼失控的重構會讓 agent 隨著工作階段進行而顯得越來越慢、越來越不可靠：上下文視窗會填滿 agent 自己的輸出，留給實際程式碼的空間因此縮小。如何控制這點，就是管理 coding agent 的上下文視窗的全部主題。

Token 會在輸入和輸出時分別計費，因此大小減半的差異會節省兩次成本：一次是在寫入時，另一次是在每一輪重新讀取時。如果您在自架環境中監控費用，指示檔案是一個不需成本即可調整的控制點。控制 AI agent 的使用成本要從輸出量開始，而coding agent 如何使用其 token則說明了為什麼重新讀取的影響比一般預期更大。

人員仍然必須檢閱差異。原本只需 20 行、卻變成 400 行的變更會消耗檢閱者的注意力，而注意力是最先耗盡的資源。沒有人能以檢閱當天第一個差異時的仔細程度，檢閱當天第四個冗長差異。因此，過度建置不只會浪費時間，也會悄悄降低原本應負責找出錯誤的檢閱品質。

在伺服器上，風險程度會改變，因為 agent 通常是在無人監看的情況下執行。agent 在 tmux 工作階段或計時器中運作時，可能有數小時的時間持續建立在錯誤決策之上，直到您看到結果。這就是在 VPS 上執行 coding agent的實際風險，也是進行迴圈工程的人會如此重視常駐指示，而非個別提示的原因。always-on 檔案中的規則會套用到第 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
  }
]

單次提示欄的數據來自未使用代理程式的模型。模型針對一小組提示，在套用和未套用該規則的情況下分別回答，並以 2026 年 6 月 13 日和 17 日的多次執行結果計算中位數。代理程式欄的數據來自無頭 Claude Code 工作階段。該工作階段編輯 tiangolo 的 full-stack-fastapi-template，這是一個實際的 FastAPI 和 React 儲存庫。測試涵蓋 12 個功能票證，每個票證在 Haiku 4.5 上執行 4 次，並根據最後留下的 git diff 評分。

請查看第二欄。代理程式結果的程式碼行數少 54%，成本低 20%，牆上時鐘時間少 27%。在單次提示設定中，相同指標分別為 93% 和 74%。README 誠實說明了原因：單次提示基準是未使用代理程式的模型，會「提供數個選項並附上說明」，而這很容易被超越。若改用實際代理程式執行實際工作進行比較，優勢就會縮小。這項結果仍然成立，而這才是更有用的事實。

專案也提出了一項限制，而這正是決定它是否對你有幫助的因素。節省幅度在確實存在過度建置陷阱的情況下最大；對原本已經精簡的程式碼，節省幅度接近零。在單一 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 歷史記錄中的原因。

規則不再適用的情況

這套階梯是針對已有程式碼庫中的功能開發所調整，而在這類情況下，通常可以重複使用現有內容，且通常能正確重複使用。它不適合從零開始的專案，因為第 2 級沒有可重複使用的內容，第 5 級也沒有已安裝的項目，因此代理程式每次都會落到第 7 級。當你確實想要抽象化時，它也不適用。如果你即將加入同一段複製區塊的第 4 個呼叫端，「最短差異」會再交給你第 5 份複本。

ultra 級會挑戰你的需求。這正是該級別的用途；但如果你已經做出決定，只想完成工作，這也確實會增加成本。一般工作使用 full；當你懷疑功能請求本身就是問題時，再使用 ultra。

沒有任何指示區塊能讓你免於誤解問題。規則集的第 1 項本身就是先了解程式碼再做決定，而這是最耗時的部分，也是本文無法替你完成的部分。在錯誤的函式中進行最小差異修改，仍然是錯誤的修正；而且現在它變成容易核准的小型錯誤修正。

坦白說，Ponytail 是一份撰寫周全、妥善發布並附有數字的提示。它不需要外掛才能運作。這個專案提供的是：有人正確整理了清單，使用實際儲存庫進行測試，並將方法與結果一併發布。

FAQ

Ponytail 是否能與 Claude Code 以外的代理程式搭配使用？

可以。它以 skill 形式提供給能載入 skill 的主機使用，README 列出的主機包括 Claude Code、Codex、OpenCode、Gemini 及其他幾種。能讀取規則檔但不會載入 skill 的編輯器，例如 Cursor、Windsurf、Cline 和 Copilot，會從對應的 rules 目錄取得一律啟用的規則集，但不會取得斜線命令。兩種方式使用的文字相同，真正的差異在於主機是否會在每一輪都將這些文字保留在上下文中，或只在觸發 skill 時載入。

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

不會，規則集也直接說明了這一點。其中「絕不對以下事項偷懶」清單列出信任邊界的輸入驗證、防止資料遺失的錯誤處理、安全性與無障礙功能；此外，它要求每段非簡單邏輯都提供一個可執行的小型檢查。這項規則移除的是臆造的結構：沒有人要求的抽象，以及沒有人需要的相依性。如果安裝後代理程式開始刪減測試，原因是你自己的設定中有另一項指示優先權高於這項規則。因此，請讀取代理程式最後載入的檔案。

已發布的速度與成本數據值得信任嗎？

這些是專案自行測量並依其方法發布的數據，應以此角度解讀。單次執行數據是與僅回覆選項和說明的基本模型比較，而 README 本身也指出這是較弱的基準。代理程式執行數據來自一個無頭 Claude Code 工作階段，使用單一 FastAPI 和 React 儲存庫、12 個 ticket，每種執行4次，並採用 Haiku 4.5。這些數據對該設定而言是可信的。但它們不是你自己程式碼庫的預測值，因為專案也表示，對於原本就已經精簡的程式碼，節省幅度會降至接近零。

若要獲得效益，是否需要安裝任何項目？

不需要。這套階梯是文字內容；將等效區塊貼到代理程式原本就會讀取的指示檔中，即可取得大部分效果。外掛程式提供維護中的文字、強度等級、審查命令及更新途徑。先嘗試貼上的區塊，可以回答「是否真的需要安裝」這個問題，也是第1級的做法。

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

將規則放在一律啟用的指示檔中，而不是聊天訊息裡。如此一來，規則會套用到長時間執行的第200輪，而不只適用於第3輪。接著，另外限制可能造成的損害：提供一份允許代理程式破壞的 checkout，不要提供唯一的副本；並要求人工審查 diff 後，才可合併任何變更。最小 diff 規則可減少你需要閱讀的內容。但它不會決定哪些變更可以提交，而且也不應該由它決定。