Ponytail：讓 AI 懶得有效率，少寫一點也能做好

你請 coding agent 加一個日期選擇器。它立刻忙起來：安裝 flatpickr、建立 wrapper component、補 stylesheet，再寫一套日期格式轉換。幾分鐘後，一個表單欄位長成了需要長期照顧的小型專案。

瀏覽器其實早就準備好了：

<input type="date">

DietrichGebert/ponytail 專門攔住前面那種過度開發。它把 coding agent 調成一位「懶惰但不馬虎的資深工程師」：先找已經存在的 helper、stdlib 或原生平台功能，真的沒有現成答案，才寫最少且能通過驗證的程式。

這是一種很資深的懶。懶得維護第五個日期 wrapper，懶得替一行程式開一個 abstraction，但該讀的 caller、資料流和測試一樣不能省。小 diff 如果改錯位置，仍然只是另一個 bug，只是比較短而已。

它是一個 Skill，也是一套 plugin

核心規則放在 skills/ponytail/SKILL.md。內容其實很樸素：這是一組 coding behavior Prompt，用 Agent Skill 格式封裝，沒有新的模型，也不需要把程式送到另一個遠端服務。

本文以 2026 年 8 月 5 日查閱的 v4.8.4 為準。這個 repo 更新速度快，日後安裝時仍要以當下的 README 與 plugin manifest 為準。

整個 repo 還多了 host adapters、lifecycle hooks 和六個 Skills。主 Skill 管平常的實作；ponytail-review 檢查目前 diff 的過度設計，ponytail-audit 掃描整個 repo，其他指令則處理技術債、benchmark 結果與說明。

要讓規則在每個 session 自動進入 context，得靠 plugin 層。它會追蹤 lite、full、ultra 模式，也能把規則帶進 subagents。單獨放入 SKILL.md 仍可手動呼叫，但不一定會在每次 coding task 自動啟用。

七階梯：能不寫，就先別寫

Ponytail 在動手前依序檢查七個問題。只要其中一層已有夠用的答案就停，不會因為還有 token，便硬把事情做到第七層。

順序	先問什麼	常見結果
1	這個功能現在真的需要嗎？	刪掉推測中的需求，遵守 YAGNI
2	codebase 已經有相同能力嗎？	重用 helper、type 或既有 pattern
3	stdlib 能完成嗎？	不建立自己的日期、cache 或 parser 工具
4	平台原生功能能完成嗎？	HTML、CSS、資料庫 constraint 優先
5	已安裝的 dependency 能完成嗎？	不為幾行程式再加入一個 package
6	一行就能完成嗎？	直接使用最短而且正確的寫法
7	前面都不行嗎？	只寫能完成任務的最小實作

順序不能倒過來。代理若先決定寫一個 abstraction，替它取好名字、建好 interface，再回頭問能否簡化，通常只會得到「比較精簡的 abstraction」。所以 Ponytail 把問題放到動手之前問，省得 interface 都建好了才捨不得刪。

Bug fix 也不是只改 ticket 指到的那條 path。主 Skill 要求代理先搜尋 caller，確認問題是否應該在 shared function 修一次。它追求的是最小的正確修改，不是看起來最短的 patch。

懶歸懶，該守的不能省

Ponytail 的規則明確保留 trust boundary 的 input validation、防止 data loss 的 error handling、security measures 與 accessibility basics。非單純的一行邏輯也要留下最小可執行檢查，例如一個 assert self-check 或小型 test file。

懶得寫 wrapper 是取捨，懶得做 validation 可能就是事故。這些邊界讓 Ponytail 和一句「請全部寫成 one-liner」有實質差異。專案自己的 safety benchmark 用 adversarial inputs 測 path traversal、SQL injection、forged token 等情境。Ponytail 在 20 次 security runs 全部通過；單純的 YAGNI 加 one-liner Prompt 則有一次漏掉 path traversal guard。

20 次測試不能證明任何專案都安全。它只能說明 Ponytail 的設計沒有把 guard 當成可刪的 boilerplate。正式上線前仍要跑原本的 tests、security review 和 accessibility checks。

54% 看起來很香，但不是每個 diff 都打五折

Ponytail 自己重新設計過 benchmark。舊版用單輪回答計算程式行數，預設模型的解釋與選項也被算進去，得到 80% 到 94% 的降幅。Issue #126 指出這個 baseline 不公平後，作者改用 headless Claude Code 實際修改 FastAPI 加 React repo，再從 git diff 計算新增行數。

新版第一方測試使用 Haiku 4.5，跑 12 個 feature tickets，每個 arm 重複四次。Ponytail 平均少寫 54% 程式、少 22% tokens、成本少 20%，時間少 27%。日期選擇器從 404 行降到 23 行；已經很短的 backend CRUD 幾乎沒有差別。

JetBrains 又用 Sonnet 5 和 SkillsBench 做了 80 組配對測試。他們量到典型任務少寫 15.4% 程式，成本中位數少 10.3%，時間少 11%。在原本會產生較大實作的任務中，程式量減少約 31%；本來就很精簡的任務，中位數沒有變化。

來源	工作負載	程式量	成本與時間
Ponytail 第一方	12 個刻意包含 over-build 空間的 feature tickets，Haiku 4.5	平均少 54%	成本少 20%，時間少 27%
JetBrains	80 個 SkillsBench tasks，Sonnet 5 medium reasoning	典型任務少 15.4%	成本少 10.3%，時間少 11%

JetBrains 沒有測到任務品質的顯著差異：65 個結果相同，9 個稍差，6 個稍好。這是「沒有偵測到差異」，不是證明兩邊完全等效。他們的 verifier 也不是 security 或 accessibility suite，因此無法替第一方的 100% safety claim 背書。

Ponytail 碰到容易重造輪子的功能時效果很大，碰到已經沒有贅肉的程式時幫助有限。把 54% 當成每次任務都能輸入的折扣碼，幾次後大概會失望。比較準確的期待是：它會降低代理 over-build 的機率，不會憑空把所有任務砍掉一半。

裝了卻像沒裝？問題可能在啟用方式

JetBrains 先試過只安裝 Skill，再讓 Claude Code 自己判斷何時啟用。10 次 coding sessions 裡，Ponytail 自動觸發了 0 次。這不表示 SKILL.md 無效，而是模型沒有主動選它。

Ponytail 的完整安裝方式是 plugin。Plugin 的 hooks 會在 session 開始時注入規則，使用者切換模式時更新狀態，啟動 subagent 時再把規則帶過去。若你只想偶爾手動使用，單一 Skill 已經足夠；若期待每個 coding task 都套用七階梯，就應該裝 plugin。

Plugin 的 lifecycle hooks 使用 Node.js，所以 node 必須存在於 non-interactive shell 的 PATH。缺少 Node 時 Skills 還能手動使用，但自動啟用不會正常運作。

在 Codex 安裝

依目前 repo 文件，只需要先加入 marketplace，再安裝 plugin：

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

指令雖然只有兩行，也不要一路按 Enter 當作沒看見。啟動 codex 後開啟 /hooks，逐一檢查 Ponytail 準備執行的 lifecycle hooks，再決定是否信任。開始新 task 才會套用 session-start 行為。Codex desktop app 安裝後要重新啟動。

預設模式是 full。目前 Codex 可以用 /skills 選擇 Skill，或在 prompt 裡用 $ 提及：

$ponytail lite
$ponytail ultra
$ponytail-review
$ponytail-audit

lite 會照需求實作，再補一句更省的替代方案；full 直接執行七階梯；ultra 看到新 abstraction 時會更積極追問「真的需要嗎？」剛開始建議先用 lite，看看它都嫌哪些程式多餘，再決定是否讓 full 常駐。想關閉可用 $ponytail off，或直接告訴代理 stop ponytail。

解除安裝使用：

codex plugin remove ponytail

若你修改過 default mode 或接受過 statusline 設定，repo 的 uninstall 章節另有清理 state 的步驟。先閱讀腳本內容，再在移除 plugin 前執行，因為 host remove 會一併刪掉 plugin 內的 cleanup script。

在 Claude Code 安裝

Claude Code 要分成兩次輸入：

/plugin marketplace add DietrichGebert/ponytail

/plugin install ponytail@ponytail

安裝後重新開始 session。模式使用 /ponytail lite、/ponytail full、/ponytail ultra 或 /ponytail off；review 與 audit 則是 /ponytail-review 和 /ponytail-audit。

Cursor、Windsurf、Cline 等工具主要透過專案 rules file 載入，沒有完整的 plugin hooks 與模式切換。各平台的檔案位置容易變動，安裝前應回到 repo 的 Agent portability 核對。

別靠感覺，讓同一張 ticket 跑兩次

拿改一個常數來測 Ponytail，像是請極簡收納師整理一張空桌子，最後多半看不出差別。比較適合的任務，是你懷疑代理會建立額外 dependency、wrapper 或 abstraction 的功能。挑一個已完成的 ticket，在乾淨 branch 上重跑：

關閉 Ponytail，讓相同模型完成任務，保存 git diff、測試結果、token 或成本資料。
開新 task，啟用 full 並使用完全相同的需求。
比較新增行數、檔案數、dependency 變化與測試結果，不只比較模型最後說了幾句話。
對較短版本再做正常 code review。ponytail-review 只找過度設計，不負責 correctness、security 或效能問題。

如果 Ponytail 只是把 40 行改成 35 行，卻讓團隊更難看懂，就沒有非用不可。若 A/B 結果少了一個 dependency、重用了現有 helper，或用瀏覽器原生功能取代整個 component，差異才值得保留下來。

和 Caveman、Karpathy guidelines 有什麼差別

Caveman 縮短代理的自然語言輸出，原則上不改程式碼。Ponytail 管的是代理決定要建立什麼。兩者可以一起用，但都屬於會影響很多回合的行為規則，仍要確認額外 context 是否值得。

andrej-karpathy-skills 也要求保持簡單、避免 scope creep 並驗證結果，和 Ponytail 的重疊很高。Ponytail 多了具體七階梯、不同強度、plugin hooks 與 over-engineering review；Karpathy guidelines 比較短，也更容易直接合併進現有 AGENTS.md。

站內收錄的 MOYU 同樣定位為 anti-over-engineering Skill。這三套沒有必要全部常駐。先選一套通用簡化規則，再按任務使用 TDD、debugging 或 review Skill，比疊上多份近似 instructions 更容易知道哪條規則正在生效。

我會把 Ponytail 當成 code review 旁邊那位看到新 dependency 就先咳一聲的同事。代理經常新增 package、建立只有一個實作的 interface，或為瀏覽器原生功能重造 component 時，它很有用。若團隊本來就有嚴格的 review、lint 和架構規範，它可能只省下少量程式。讓 full 常駐前，拿一個真實 diff 確認它刪掉的是維護負擔，不只是讓行數看起來漂亮。