AI 為什麼總是寫太多？Ponytail 用 YAGNI 七層梯強制過濾

我在寫一個 API server，Claude Code 幫我加了 middleware chain、retry logic、事件發布機制。PR 送出去之後，reviewer 問的不是「這些設計有沒有問題」，而是：「這個 use case 需要這麼複雜嗎？」

我回去看，不需要。花了一個下午把 code 砍掉 60%，功能完全沒差。

AI 不是在亂設計，它只是把「API server」這個 prompt 對應到訓練資料裡最常見的架構模式，然後全部生出來了。沒有人告訴它這個 use case 不需要這些。

讀完精華版（2 分鐘），你會理解：

• Ponytail 是什麼，怎麼改變 AI 的判斷邏輯
• 七層決策梯的邏輯，以及三個 mode 各自的用法
• 真實使用中會踩到的坑，以及怎麼應對

這篇不是安裝指南，是讓你知道這個機制夠不夠信任、以及信任到哪裡為止。

精華版

三個 mode 各自的核心定位：

• full：Ponytail 的日常主力。AI 在每次動手前嚴格走一遍七層梯，發現更簡單解法就停下來，適合所有日常開發場景。
• lite：已確認需要複雜實作時使用。AI 實作你要的，但會順帶提一個更懶的替代方案，你可以選擇忽略。
• ultra：只在重構或清技術債時啟用。刪除優先於新增，主動質疑每個 requirement，平時開著會讓 AI 卡在質疑需求而不是推進工作。

使用前要知道的幾件事：

什麼場景會踩坑？複雜需求時 AI 可能先嘗試用 stdlib 硬撐，跑幾輪才放棄往下一層走；ultra mode 在新 feature 場景會誤殺有效需求；extended thinking 模型可能花更多 token 在質疑需求上而不是解決問題。

安全性會被 YAGNI 掉嗎？不會。Input validation、資料損失風險的 error handling、security、accessibility 是非協商項目，即使在 ultra mode 也不受七層梯影響。

Ponytail 的 benchmark 適用所有模型嗎？數字是對 Haiku 4.5 量的。terse reasoning 模型（特別是 extended thinking）行為有差異，建議先用 lite mode 觀察幾個 session 再決定要不要 full。

以下是完整版，按需取用。

AI 為什麼傾向過度設計？

AI 過度設計有個結構性的根源：模型的訓練語料幾乎全是「值得被寫成 blog post 的架構」，帶著 retry、middleware、抽象層，因為那些才是會被分享的實作。真實世界裡「夠用就好」的簡單解法，不會出現在語料裡。AI 沒有辦法自己知道你的 use case 不需要這個複雜度，除非你告訴它。

Ponytail 的核心假說是：大多數 AI 生成的 code 有 70% 是不必要的複雜度，這個問題靠每次 prompt 提醒是解不掉的，它需要一個在 session 開始就持續注入的判斷機制。

Ponytail 怎麼運作

Ponytail 是 instruction-based 的行為塑形，不碰 runtime、不攔截 API call。它唯一做的事是在每個 Claude Code session 開始時，透過 SessionStart hook 把 YAGNI 七層決策梯注入到 AI 的 context 裡。

這七層的邏輯是：

1. YAGNI          → 這功能真的需要嗎？先問
2. 已在 codebase  → 有沒有現成的可以 reuse？
3. Standard lib   → 語言標準庫有嗎？
4. Platform 原生  → 框架 / 平台有內建嗎？
5. 已安裝的 dep   → 現有套件能做嗎？
6. One-liner      → 一行能解決嗎？
7. 最小可行 code  → 最後才寫 custom code

每次 AI 準備動手，它必須先爬這七層——任何一層能解決就停下來，不往下走。日期選擇器 404 行 → 23 行（<input type="date"> 就夠），登入表單用 form element 取代自建 state machine，都是這個梯子實際發揮作用的結果。

注入的 ruleset 大約是 100-200 token 的固定開銷，每個 session 都有。這個成本本身很小，換來的是 AI 判斷邏輯的系統性轉變，而不是你每次 prompt 裡的提醒。

除了 SessionStart，Ponytail 也有 SubagentStart hook，確保 subagent 繼承相同的 mode——在 agentic workflow 裡這個細節很重要，否則主 agent 遵守七層梯，但它生出來的 subagent 還是會回到過度設計的預設行為。

這個 session-level 的設計也決定了 Ponytail 和其他工具的分工。以 Superpowers 為例，brainstorming、test-driven-development 這類 skill 是你主動觸發才啟動的 skill-level 工具，負責「怎麼把事情做好」的執行流程。Ponytail 在它們之前就已經作用了，負責更前一層的問題：這件事真的需要做嗎？做到哪個層級夠？

搭配使用時，Ponytail 先過濾掉不必要的複雜度，確認要做的部分再交給 brainstorming 或 TDD 流程去把它做對。兩者分工清楚，不重疊。Ponytail 也完全可以單獨使用，它不依賴任何其他工具。

三個 mode 的實際用法

Mode 透過 /ponytail [lite|full|ultra|off] 指令切換。

full mode 是預設，也是最常用的。你不需要改變工作方式，AI 只是在生成 code 之前多了一層自我確認。這個 mode 適合大部分日常開發場景，七層梯的效果在「原本就會過度設計」的 task 上最明顯。

lite mode 的用法是當你已經確認這個任務需要複雜實作。AI 還是會幫你做，但它會在旁邊附上一個「如果你接受這個限制，其實可以這樣更簡單」的方案。你可以直接忽略，不影響主線工作。這個 mode 也適合快速 spike，或是你對某個任務的複雜度已經有把握、不想讓 AI 在梯子上浪費時間。

ultra mode 只建議在重構或清理技術債時啟用，邏輯是刪除優先於新增，對每個 requirement 都保留質疑空間。清技術債的時候這很有效；但如果你把它開在新 feature 的開發上，AI 會不斷卡在「這個需求真的需要嗎」，而不是幫你往前走。

使用 Ponytail 會踩到哪些坑？

Ultra mode 在新 feature 場景會誤殺有效需求。 Ultra 的設計前提是你知道現在要做的是清理，不是建立。如果你開一個新 feature、需要從頭設計某個機制，ultra 的「質疑每個 requirement」邏輯會讓 AI 反覆確認而不是解決問題。明確的做法是：新 feature 用 full 開始，等到功能穩定、需要清理時才切 ultra。

複雜需求時 AI 可能先用 stdlib 硬撐幾輪才放棄。 七層梯的第三層是標準庫，AI 如果判斷「stdlib 能做」，它會先試。問題是有些需求表面看起來 stdlib 能解，但邊界條件一碰就撐不住。這種情況下你可能要多跑兩輪對話，AI 才會放棄往第七層走。應對方式是在需求說明裡補一句背景，例如：「這個場景需要處理 concurrent writes 和 partial failure，直接告訴我你覺得需要什麼層級的實作。」需求越具體，梯子停在正確層的機率越高。

Extended thinking 模型可能反向走。 對於使用 extended thinking 的模型，YAGNI 指令可能讓模型在 thinking 階段花更多 token 在「質疑需求」，而不是解決問題。這個 repo 的 benchmark 主要量的是 Haiku 4.5。如果你用的是 thinking-heavy 的模型，建議先用 lite mode 觀察幾個 session 的行為，再決定要不要切換到 full。

「懶夠了」和「夠用了」的判斷邊界依賴 AI 理解業務需求。 七層梯要停在正確的層，需要 AI 知道你這個 context 下的「夠用」定義是什麼。如果需求本身就是要建一個 custom protocol 或分散式系統，AI 可能試幾層才意識到 stdlib 撐不住。這不是 Ponytail 的 bug，是你需要在需求說明裡補足的資訊。

不同開發階段，mode 怎麼選

Ponytail 是 session-level 的工具，每個 session 開始時就決定好 mode，而不是等到 PR 整理時才啟用。

新 feature 開始時：用 full mode。這是 AI 最容易過度設計的時機，七層梯在這裡能發揮最大作用。在需求還沒完全清楚的情況下，full 幫你把「夠用就好」的選項留在桌上。

Bug fix 時：用 lite mode。你已經知道問題在哪、大概需要什麼解法，不需要 AI 一直質疑你要不要修。lite 讓 AI 做你要的事，但它如果看到更簡單的方法還是會提醒你。

重構或清技術債時：才切 ultra。這是 ultra 唯一適合的場景，刪除優先、主動質疑——這個姿態在清理舊 code 時是優點，在建新東西時是阻力。

PR 整理階段：mode 回到 lite 或 off。PR 的最後整理通常是確認 diff、補 test、寫 commit message，這些不需要 YAGNI 過濾，保持 AI 照你說的做就好。

結語：Ponytail 做的不是讓 AI 變笨，而是在它動手之前加一個人類工程師本來就該問的問題——這個複雜度，現在真的需要嗎？