最近兩個 GitHub repo 前後腳紅起來。一個叫 Caveman，教 agent 說話像原始人——省掉所有客套，直接輸出，token 砍掉六七成。另一個叫 Ponytail，讓 agent 扮演公司裡最懶、但也最資深那位工程師：你說要一個 date picker，它不幫你裝套件、不寫 wrapper component，只說，瀏覽器原生那個輸入框就夠用了。兩個項目剛好分工——一個管 agent 怎麼說話，一個管 agent 怎麼寫 code，連 README 都在互相點名，建議搭配使用。

把鏡頭拉遠一點看，這兩個不過是過去半年一連串浪潮裡最新的兩朵。去年十月有 Superpowers，走的是完全相反的路：先訪談需求、寫 spec、寫 plan，再嚴格走紅燈綠燈的 TDD 循環，半步不能省。今年初，有人把 Karpathy 對 AI agent 的幾條吐槽——亂猜需求、過度工程、亂改不相關代碼——包裝成一份指引，幾星期內衝到十幾萬星。Caveman 的起源也類似：先是 Reddit 上一句話，被人寫成幾千星的草稿，再被維護者加上分級和多工具支援，三星期後變成五六萬星。

節奏快到有點荒謬。Ponytail 紅起來那幾天，已經有人順手拿它的熱度發了一個 meme coin。這還不是工程常識，只是這一週的流行。

方法論衝突的背後

這半年看下來，這些項目真正教我的，與其說是某個具體技巧，不如說是一個更根本的觀察：很多時候，技巧本身沒有絕對的對或錯，背後是工程哲學的差異。

Superpowers 的鐵律是先寫測試，紅燈綠燈一步都不能省；Ponytail 剛好相反——不寫沒人要的抽象，連測試也只要求留一個能跑的就好。這不是同一套常識的兩個版本，是兩種不同的職業判斷，剛好被包裝成同一種格式。

如果你沒有自己的判斷框架，這種衝突很難消化。你可能第一週跟著 Superpowers 走，第二週又被 Ponytail 說服，但這兩套之間的張力從來沒有真正被解決。你只是一直在繼承別人的立場。

照單全收的代價

每見到一個新項目就跟著裝、跟著改，短期或許能省一點工夫，但走不遠。因為你抄的是別人的判斷，不是你自己的。

更麻煩的是，項目一多，你很快就忘了哪個項目裝了哪些設定、哪幾條規則來自哪套方法論、它們之間有沒有衝突。那些彼此可能矛盾的規則，靜靜地躺在你的 .cursorrules 或 system prompt 裡，等著在某個你沒預期的時刻互相干擾。光是管理這些，本身就是一種行政負擔——還沒開始做真正的事。

比起追熱門，更重要的是篩出一套真正跟自己工程哲學一致的判斷。

閘口的概念

我自己的做法，是把這套判斷寫進一個專屬的 repo，當成自己的開發方法論。

它的運作方式很簡單。遇到外面的新東西，我會叫 agent 去研究，再跟我討論——這個跟我已經寫下的判斷比起來，合不合，值不值得吸收進來。分歧的地方，先不急著決定，提出來討論。這樣一來，開新項目時，我只需要叫 agent 把這個方法論 import 進去就好，而不是東裝一個西裝一個技巧。

這個 repo 本身也可以做版本化，並且寫清楚，使用它的 agent 該怎麼正確套用，以及方法論更新的時候，又該怎麼正確同步到每個現有的項目。

它的真正功能是當一個閘口：一邊幫你篩選、吸收外面源源不絕的新技巧，一邊也給你所有的項目，提供需要的組織方式。

閘口裡裝的是什麼

老實說，我自己方法論裡放的東西，有從 Karpathy 那邊照搬過來的，也有從 Ponytail 這類項目吸收進來的，還有不少是我自己的 AI-first 開發習慣——比如 API 先行、按功能模組分工開發之類的。

但具體裡面寫了什麼，其實不是最重要的。每個人的技術棧不同、項目性質不同、對「夠好」的標準也不同。你最終需要的，是一套反映你自己判斷的東西，而不是別人的判斷換了一個容器。

真正重要的想法，是擁有這樣一個閘口本身。

幾個起手式

如果你也想試試讓自己的 coding agent 做這件事，以下是幾個可以直接拿去用、或根據自己情況調整的提示。

建立自己的方法論 repo：

我想建立一個屬於我自己的「開發方法論」repo，之後可以套用到我所有的項目裡。請你先問我幾個問題，了解我目前慣用的技術棧、項目管理習慣，以及我已經在用、但從來沒寫下來的規則（例如我怎麼決定要不要寫測試、怎麼決定要不要加抽象層）。根據我的答案，整理成一份方法論文件，並設計一個簡單的版本化機制，讓我之後可以把它套用到新項目裡。

看到新方法時，更新自己的方法論：

我看到 Ponytail 和 Caveman 這兩個給 coding agent 用的 instruction/skill。麻煩你研究一下，跟我們現有的開發方法論比對：有哪些地方類似、哪些地方不同，有沒有什麼值得併入我們的方法論裡；又有沒有明顯分歧的地方——分歧的部分先不要自己決定，提出來跟我討論再說。

把方法論套用到一個新項目：

請你先研究 https://github.com/your-org/dev-methodology ——這是我目前所有項目在用的開發方法論。請幫我把這套方法論 import 到這個項目裡。

幫已經在用的項目同步更新：

我們的開發方法論 repo 有新版本了，請你讀一下更新了什麼，幫我把這個項目同步到最新版本。

---

這套東西本身也還在調整。這不是一個你建完就不動的東西——它更像是你工程判斷的鏡子，會隨著你處理更多項目、見到更多方法論，慢慢變得更準確。重要的不是它現在寫了什麼，而是你有沒有一個地方，讓你的判斷有地方落腳。