今天發點適合寫代碼的東西。

寫項目的時候，剛開始代碼都很清爽：兩個頁面、三個接口、幾段工具函數，目錄一眼能看完。

功能多了之後，又是加 wrapper，又是塞 options，功能沒漲多少，代碼量翻了幾倍。

不過只要你用了 GitHub 上的這個 Ponytail（馬尾辮） 項目，AI 寫代碼會突然變得很精簡。

01. 項目簡介

Ponytail 是開源的 AI 編程代理規則集和插件系統。

項目地址：https://github.com/DietrichGebert/ponytail

項目能讓 Claude Code、Codex 等 AI coding agent 寫代碼時優先選擇最小、最直接、最不容易留下維護債的實現。

Ponytail 會讓 AI agent 在寫代碼前走一遍固定判斷鏈：

• 這個功能真的需要存在嗎？不需要就跳過。
• 標準庫已經有能力嗎？有就用標準庫。
• 瀏覽器、數據庫、操作系統、框架原生能力能解決嗎？有就用原生能力。
• 項目裏已有依賴能解決嗎？有就複用已有依賴。
• 一行代碼能完成嗎？能就寫一行。
• 以上都不行，再寫能工作的最小實現。

Ponytail 還提供了幾個常用命令，專門處理代碼複雜度問題。

/ponytail-review 負責審查過度設計。Ponytail 會指出哪些代碼可以刪除、內聯，或者直接換成標準庫和平台原生能力。

/ponytail-audit 負責掃描整個倉庫。Ponytail 會找出抽象過頭、依賴過重、配置過多、文件拆得太碎的地方。

/ponytail-debt 負責整理技術債。Ponytail 會收集代碼裏的 ponytail: 註釋，把當時爲什麼選擇簡化、後面什麼時候需要升級，整理成一份清單。

/ponytail-help 負責顯示速查信息。Ponytail 會列出可用命令、模式切換方式和基本用法。

Ponytail 在保證代碼簡潔的同時，也有邊界：不會爲了少寫代碼刪掉信任邊界的輸入校驗、避免數據丟失的錯誤處理、安全措施、可訪問性要求，以及用戶明確要求的功能。

02. 項目實測

Ponytail 安裝完會自動生效，Claude Code 和 Codex 會在每個新會話啓動時，通過 lifecycle hook 把規則注入上下文。項目分爲 4 種模式，通過 /ponytail 命令切換 lite、full、ultra、off，默認是 full。

case 1  代碼減少測試

不用Ponytail：

提示詞：

【測試組】Baseline

【運行環境】

只允許修改：

D:\360MoveData\Users\win\Desktop\蒸餾\full-stack-fastapi-template-baseline

目錄不存在時，從 https://github.com/fastapi/full-stack-fastapi-template 克隆，並檢出 cd83fc1。

開始前確認 HEAD 爲 cd83fc1，git status –short 爲空。

使用全新線程、獨立 node_modules、獨立 Python 虛擬環境和獨立構建緩存。

確認 Ponytail 插件、hook、Skill 和 Ponytail 規則均未加載。不要用 @ponytail off 代替環境隔離。

不得讀取或複製 full-stack-fastapi-template-ponytail 中的代碼。

無法滿足任一條件時停止執行，不要修改代碼，並報告“Baseline 環境無效”。

【開發任務】

爲 full-stack-fastapi-template 增加可選的 due_date 日期字段。

1. 在 frontend/src/components/Items/AddItem.tsx 的 Item 創建表單中加入 due_date 日期選擇控件。
2. 在 frontend/src/components/Items/EditItem.tsx 的 Item 編輯表單中加入 due_date 日期選擇控件。
3. 在 backend/app/models.py 中爲 ItemBase、ItemCreate、ItemUpdate 和 ItemPublic 增加 due_date。
4. 在 backend/app/alembic/versions/ 中新增數據庫遷移，爲 item 表加入可空的 due_date 日期列。
5. 使用 full-stack-fastapi-template 現有生成流程更新 frontend/src/client/ 中的 Item 類型。
6. 在 frontend/tests/items.spec.ts 中測試日期選擇、修改和清空。
7. 在 backend/tests/api/routes/test_items.py 中測試 due_date 的創建、讀取、更新和清空。
8. due_date 使用 YYYY-MM-DD 格式，不包含時間和時區。
9. 遵循 full-stack-fastapi-template 現有代碼風格並運行相關測試。

按 AI coding agent 的默認方式完成需求，不引用 Ponytail，不加入“少寫代碼”“優先一行實現”等額外要求。

【結果記錄】

完成後運行 git diff –numstat、git diff –stat 和 git status –short。

統計新增行數、刪除行數、修改文件數、新增依賴數、測試結果、耗時和 token 消耗。

無法獲取耗時或 token 時填寫 unavailable。

 

測試報告不得寫入 full-stack-fastapi-template-baseline。

將測試報告保存到：

D:\360MoveData\Users\win\Desktop\蒸餾\ponytail-ab-results\baseline.md

不用Ponytail：

提示詞：

@ponytail full

 

【測試組】Ponytail Full

 

【運行環境】

只允許修改：

D:\360MoveData\Users\win\Desktop\蒸餾\full-stack-fastapi-template-ponytail

 

目錄不存在時，從 https://github.com/fastapi/full-stack-fastapi-template 克隆，並檢出 cd83fc1。

開始前確認 HEAD 爲 cd83fc1，git status –short 爲空。

使用全新線程、獨立 node_modules、獨立 Python 虛擬環境和獨立構建緩存。

確認 Ponytail 插件和 lifecycle hook 已啓用，Ponytail 當前模式爲 full。

Claude Code 使用 /ponytail full，Codex 使用 @ponytail full。

不得讀取或複製 full-stack-fastapi-template-baseline 中的代碼。

無法滿足任一條件時停止執行，不要修改代碼，並報告“Ponytail 環境無效”。

 

【開發任務】

爲 full-stack-fastapi-template 增加可選的 due_date 日期字段。

1. 在 frontend/src/components/Items/AddItem.tsx 的 Item 創建表單中加入 due_date 日期選擇控件。
2. 在 frontend/src/components/Items/EditItem.tsx 的 Item 編輯表單中加入 due_date 日期選擇控件。
3. 在 backend/app/models.py 中爲 ItemBase、ItemCreate、ItemUpdate 和 ItemPublic 增加 due_date。
4. 在 backend/app/alembic/versions/ 中新增數據庫遷移，爲 item 表加入可空的 due_date 日期列。
5. 使用 full-stack-fastapi-template 現有生成流程更新 frontend/src/client/ 中的 Item 類型。
6. 在 frontend/tests/items.spec.ts 中測試日期選擇、修改和清空。
7. 在 backend/tests/api/routes/test_items.py 中測試 due_date 的創建、讀取、更新和清空。
8. due_date 使用 YYYY-MM-DD 格式，不包含時間和時區。
9. 遵循 full-stack-fastapi-template 現有代碼風格並運行相關測試。

只應用 Ponytail Full 已加載的規則，不追加其他 YAGNI、一行實現或精簡提示。

 

【結果記錄】

完成後運行 git diff –numstat、git diff –stat 和 git status –short。

統計新增行數、刪除行數、修改文件數、新增依賴數、測試結果、耗時和 token 消耗。

無法獲取耗時或 token 時填寫 unavailable。

 

測試報告不得寫入 full-stack-fastapi-template-ponytail。

將測試報告保存到：

D:\360MoveData\Users\win\Desktop\蒸餾\ponytail-ab-results\ponytail.md

在本輪對比中，Baseline 組新增 225 行代碼，Ponytail Full 組新增 149 行，Ponytail 讓總新增代碼減少約 34%，修改文件從 10 個降到 8 個，已經能說明 Ponytail 可以減少需求外功能、重複校驗和不必要改動。

case 2 項目審查

提示詞：

/ponytail-review

請只審查過度設計，不要重寫代碼。重點找出可以刪除、內聯、替換成標準庫或瀏覽器原生能力的地方。

審查這段 React 代碼：

import { useState } from “react”;

import dayjs from “dayjs”;

 

class DateInputAdapter {

constructor(formatter) {

this.formatter = formatter;

}

 

normalize(value) {

return this.formatter(value);

}

}

 

const createDateFormatter = () => {

return (value) => dayjs(value).format(“YYYY-MM-DD”);

};

 

export function BirthdayPicker() {

const [date, setDate] = useState(“”);

const adapter = new DateInputAdapter(createDateFormatter());

 

function handleChange(event) {

const normalized = adapter.normalize(event.target.value);

setDate(normalized);

}

 

return (

<input

type=”text”

placeholder=”YYYY-MM-DD”

value={date}

onChange={handleChange}

/>

);

}

Ponytail 準確找出了預埋的四處過度設計，標出了行號、問題類型和修改方向，沒有跑去討論命名、代碼風格或異常處理，符合 /ponytail-review 只審查過度設計的定位。

case 3 倉庫檢查

這個 case 中，倉庫故意加入了單實現接口、工廠、適配器、管理器、Facade、多餘配置和可替換依賴，看看能不能檢查出來。

提示詞：

/ponytail-audit

請掃描/D:/360MoveData/Users/win/Desktop/蒸餾/ponytail-case2-audit倉庫，只找複雜度浪費。輸出時按文件列出問題，並說明每處複雜度可以怎樣減少。

重點檢查這些問題：

1. 爲單一實現創建 interface、factory、manager、adapter。
2. 爲簡單數據轉換引入第三方依賴。
3. 爲未來可能出現的需求預留配置。
4. 多個文件之間只有一層轉發，沒有真實邏輯。
5. 能用標準庫、框架能力、數據庫能力完成，卻手寫了一套邏輯。

 

不要做業務功能審查，不要檢查代碼風格，只關注 Ponytail 關心的過度設計。

Ponytail 的 13 條發現基本覆蓋了 Case 3 預埋的度問題，而且沒有誤刪 CSV 轉義、JSON 讀取和自動測試。找得全，建議也夠具體。

case 4 收集技術債

提示詞：

/ponytail-debt

請收集/D:/360MoveData/Users/win/Desktop/蒸餾/ponytail-case3-debt倉庫裏的 ponytail: 註釋，整理成技術債清單。

請按下面格式輸出：

– 文件路徑

– 註釋原文

– 當時選擇簡化的原因

– 未來需要升級的觸發條件

– 當前是否需要處理

 

請特別關注下面幾類註釋：

 

// ponytail: keep native date input until timezone support is required

// ponytail: inline this mapper until a second provider appears

// ponytail: use in-memory cache until requests exceed 1000/min

// ponytail: avoid queue dependency until retry semantics are needed

 

不要添加代碼裏沒有的技術債。

Ponytail 把 5 條 ponytail 註釋全部找到，文件和行號準確。每條記錄都拆出了簡化原因、升級條件和當前狀態。

03. 挖一挖

Claude Code、Codex 正在接管越來越完整的開發任務。

代碼生成速度提高後，改動帶來的審查、驗證和維護成本也會提高。DORA 2025 調查顯示，90% 的受訪者已在工作中使用 AI，比 2024 年增加 14.1%，但AI 使用程度提高與軟件交付不穩定性上升相關。

Ponytail 可以縮短 MVP 的開發和返工時間，減少代碼審查壓力，還可以作爲一套固定的 AI 編碼規則，限制無意義的依賴、抽象和文件增長。

34% 只是一次本地測試結果，不能直接套到所有代碼庫。原有實現已經足夠精簡時，Ponytail 很難繼續減少代碼；需求存在原生能力、重複封裝或過度設計時，Ponytail 纔會拉開明顯差距。

Ponytail 的價值還是落在減少後續維護、審查和返工成本上。

原文鏈接：GitHub 狂攬 47K Stars，代碼寫出來再也不臃腫