點擊上方藍字關注我，加個??標不迷路。
大家好，我是 cxuan，一個和 AI Agent 互相折磨的 builder。
這兩天我注意到一個 Github，剛看到的時候，還是有些幽默的。
看到這個 readme ，你第一反應是不是會想到又是哪個大聰明在惡搞。
或者覺得這又是一個什么惡趣味的 Github 。
其實不是，這是一個正經的能幫助大家減少 Token 消耗的 Github。
它的介紹是這么說的
Makes your AI agent think like the laziest senior dev in the room. The best code is the code you never wrote. |
讓你的 Agent 一樣像個成熟的高級開發人員一樣，最好的代碼就是你不寫代碼。
你現在看到這個介紹，會不會想起來你接觸的高級開發，他們發量有些不足，有的甚至很極客，帶著眼鏡，不修邊幅。
他們在公司的時間比版本控制的歷史還長。
但是當他們坐在電腦前面的時候，你用 50 行的代碼被他用一行就搞定了。
這個“馬尾辮”老哥的形象，在項目里也描述得活靈活現。
Long ponytail. Oval glasses. Has been at the company longer than the version control. You show him fifty lines; he looks at them, says nothing, and replaces them with one. |
長馬尾，橢圓眼鏡，工齡比公司的版本控制系統還老。你給他看五十行代碼，他瞅一眼，啥也不說，反手給你換成一行。Ponytail 干的事，就是把這位老哥的靈魂塞進你的 AI Agent 里。
然后 Repo 給你展示了一個 benchmark 效果。
（我實際看了一下，現在的 benchmark 測試比前兩天的不一樣了）
如果只看早期 benchmark，最吸引人的數字是：代碼少 80%-94%，成本低 42%-75%，速度快 3-6 倍。
現在它寫的是：
平均少 54% 代碼，最高少 94%；成本低 20%；速度快 27%；安全率 100%。
很多開源項目如果拿到了一個好看的數字，會恨不得把它釘死在 Readme 首頁。
但 Ponytail 的作者承認舊 benchmark 有問題，然后重新做了一套更接近真實 Agent 使用場景的測試。
這說明這個 Github ，不像是一個專門用來刷數據、洗評分的 Github。
不過，重新做 benchmark 測試，其實是有緣由的。
Ponytail 一開始的 benchmark，是單次生成。
也就是給模型一個 prompt，讓它吐一段答案，然后數代碼行。
這種 benchmark 的測試跟我們真實用 Coding Agent 的方式不太一樣。
真實情況里，Agent 不是只在聊天框里回你一段代碼。
它會進項目目錄，看文件，改代碼，留下一個 git diff。
所以有人在 issue #126 里提出了一個質疑。
單次生成里的基準線太容易“話多”，模型會寫解釋、寫注意事項、寫多個方案，于是最后統計“回答里的代碼行數”，很容易把基準線放大。
這里還有一個更關鍵的問題：有人提出下面這個質疑。
如果只是讓 Agent 少寫，會不會把安全校驗也省掉？比如路徑拼接、SQL 參數、用戶輸入、token 校驗，這些東西不能因為 Ponytail 的懶得做而省略這些步驟。
不過，Ponytail 的作者沒有忽略這個質疑，他重新做了一個 agentic benchmark。
這次不是單次補全，這次是讓真實 Claude Code session 去改一個真實開源倉庫。
倉庫選的是 tiangolo/full-stack-fastapi-template，一個 FastAPI + React 項目。
模型是 Haiku 4.5，任務是 12 個真實 feature ticket，每組跑 4 次。
最后統計的對象也換了，直接看 Agent 留下來的 git diff 新增行數。
而且它還加了安全任務。
讓生成出來的函數去跑路徑穿越、SQL 注入、偽造 token、異常 CSV、配額耗盡這類對抗輸入。
這才像一個正常人類會關心的 benchmark。
我把官方 benchmark 里的 setup 翻成中文，大概是這樣。
整理依據：Ponytail agentic benchmark。
安全任務這塊也可以翻成一張圖。
整理依據：Ponytail agentic benchmark。
我覺得新數據更可信了。
12 個 feature task 平均下來：
這里有兩個點很重要。
第一個點，Ponytail 不是在所有任務里都減少了 90%，它在“Agent 容易過度設計”的地方容易努力過度，比如日期選擇器。
原因很簡單，瀏覽器原生就有 <input type="date">、<input type="color">、<input type="file">。
Agent 如果不被約束，很容易自己寫一套組件。
Ponytail 會先問一句：平臺自己有沒有？
有，那就別寫了。
第二個點，它在沒什么可省的地方，也不會硬省。
現在它告訴你：有些任務能省很多，有些后端任務省不了。
這就比較真實了。
這個項目它不是個插件，也不是個新工具，它就是一套“決策規則集”。
在 AI 動手寫代碼之前，必須要先過一下他的六類核心判斷：
1. 這東西需要存在嗎？ → 不需要就直接跳過（YAGNI 原則）
2. 標準庫能搞定嗎？ → 能用就用
3. 平臺原生功能有嗎？ → 有就直接用
4. 已安裝的依賴里有嗎？ → 有就別重復造輪子
5. 能一行搞定嗎？ → 就寫一行
6. 以上都不行？ → 才寫最少量的必要代碼
進過這六步判斷，你的 Agent 根本水不了。
然后這個判斷下方還有一行小字，這行小字容易注意到
“懶惰，并不是疏忽；信任邊界驗證、數據丟失處理、安全性和可訪問性永遠不會被忽視” |
大家更關心的，其實是它裝完之后到底怎么用。
我把它分成三種情況說。
第一種，你用 Codex 。
官方 README 里把 Claude Code、Codex、GitHub Copilot CLI 的安裝方式都列出來了。
圖源：DietrichGebert/ponytail README。
先在終端里加 Ponytail marketplace：
codex plugin marketplace add DietrichGebert/ponytail
codex
然后進入 Codex 之后，打開 /plugins。
選擇 Ponytail marketplace，安裝 Ponytail。
裝完之后再打開 /hooks。
這里會看到它的兩個 lifecycle hooks。
不要直接閉眼信任，先看一下它要做什么，再點 trust。
它的作用是讓 Ponytail 在新 session 里自動注入規則，并追蹤當前模式。
如果你用的是 Codex desktop app，需要安裝后重啟一下 app。
在 Codex 里，一般可以這樣用。
普通小改動，直接讓它帶 Ponytail 干活：
Use Ponytail mode for this task.
只改這個 bug，優先用現有代碼和標準庫，不要新增依賴。
如果它已經給了一個很大的 diff，不要著急讓他繼續改。
可以先用
@ponytail-review
這個命令看的不是 bug。
它專門看“哪里寫多了”。
比如手寫了標準庫已有的東西、為了一個實現抽了 interface、為了一個調用者加了 factory、為了一個永遠沒人改的值加了 config。
它最后會給你一個 delete-list。
第二種，你用 Claude Code。
Claude Code 的安裝方式：
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail
裝完以后，Ponytail 默認是 full 模式。
你可以用 /ponytail 看當前狀態，也可以手動切：
圖源：DietrichGebert/ponytail README。
一般來說 ponytail 分為下面幾種模式：
/ponytail lite
/ponytail full
/ponytail ultra
/ponytail off
lite 更像提醒，它會告訴你更懶惰一點的方案，但不會強行替你決定。
full 是我覺得最適合日常使用的模式。它會按照上面提到的六步決策法。這是他的那條決策流程：先標準庫，再平臺原生，再已有依賴，最后才寫代碼。
ultra 就比較牛批了。這個模式適合那種你打開項目看到一堆 wrapper、factory、abstract class，血壓已經飆升的時候。
但我不建議你把 ultra 當默認模式。
它適合清理過度工程，不適合所有開發場景。
第三種，如果你不想裝插件，那就用 instruction 文件。
Ponytail 的 agent portability 文檔里，把不同工具該放哪個文件也列出來了。
圖源：Ponytail agent portability。
比如在項目根目錄放 AGENTS.md。
Ponytail 倉庫本身就提供了一份 AGENTS.md，你可以復制到自己的項目里。
Codex、VS Code Codex extension、CodeWhale 這類能讀 AGENTS.md 的工具，就適用于這條規則。
Cursor 可以放到 .cursor/rules/。
Windsurf 可以放到 .windsurf/rules/。
Cline 可以放到 .clinerules/。
GitHub Copilot editor 可以放到 .github/copilot-instructions.md。
這種方式沒有插件的模式切換和 hooks，但最核心的規則能生效。
對很多項目來說，這已經夠用了。
Ponytail 這個項目看起來像個梗。
但它最近幾天的更新，讓我覺得它不是純梗。
它補了真實 Agent session 的 benchmark。
它測了安全護欄。
它承認短 prompt 有時也能贏，但不穩定。
它也承認有些任務本來就省不了多少。
AI Coding 現在已經過了“能不能寫代碼”的階段。
接下來更重要的問題是：
Agent 能不能知道什么時候不寫。
能不能知道什么時候用標準庫。
能不能知道什么時候用平臺原生能力。
能不能知道哪里必須保留校驗。
這才是 Ponytail 需要考慮的地方。
一個會寫很多代碼的 Agent，現在已經不稀奇了。
一個知道少寫、會刪、還亂拆安全護欄的 Agent，才更像一個靠譜的同事。
