最近兩個 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，當成自己的開發方法論。我一直在維護一個叫 ai-dev-methodologies 的 repo——最近也把它公開了。

它的運作方式很簡單。遇到外面的新東西，我會叫 agent 去研究，再跟我討論——這個跟我已經寫下的判斷比起來，合不合，值不值得吸收進來。分歧的地方，先不急著決定，提出來討論。開新項目時，我會跑一個 bootstrap script，把方法論 bundle 複製進項目裡——AGENTS.md、.cursor/rules 這類薄入口，加上 agent 實際讀取的 .agents/instructions/ 目錄——而不是東裝一個西裝一個技巧。

這個 repo 本身有版本化（VERSION、CHANGELOG.md）。每個被套用過的項目，會在 .agents/METHODOLOGY.lock 裡釘住當時的版本。方法論更新時，agent 照 framework-adoption.md 的指引：先讀上游改了什麼，只替換框架擁有的檔案，項目自己的客製化不動。

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

閘口裡裝的是什麼

在我的 repo 裡，內容按層級整理在 METHODOLOGIES.md：Karpathy 的 coding discipline、決策權限（什麼時候 agent 該問而不是自己決定）、多模組項目的 lane-based 開發、API-first 分層、session handoff 文件，還有一些可選的部署預設。有些直接來自 Karpathy，有些從 Ponytail 這類項目吸收進來，其餘是我自己的 AI-first 習慣長出來的。

但具體裡面寫了什麼，其實不是最重要的。真正重要的，是擁有一個反映你自己判斷的閘口——而不是把別人的判斷換了一個容器。

公開，但不是請你照搬

我決定把 ai-dev-methodologies 公開，重點並不是要大家直接套用。

我想分享的，是一個「閘口」可以長成什麼樣子——目錄怎麼分層、版本怎麼釘、新技巧怎麼篩進去、項目之間怎麼保持一致。你可以拿去當參考，研究結構，挑幾條你認同的規則，寫進你自己的方法論 repo 裡。

我始終認為，每個人自行維護一套屬於自己的系統，才是最適合的做法。如果你把我這套照單全收，跟你之前東裝一個西裝一個 skill、或者追 Ponytail 之後再追 Caveman，其實沒有多大分別——只是換了一個更大的包裹而已。

尤其這個 repo 是為我自己服務的：我會隨時依照自己的工作習慣調整，未必每次更新都會另寫公告，解釋為什麼我改了這裡、刪了那裡。你若是整套跟著走，等於把一個會不定期變動的個人偏好，當成穩定標準來依賴。

所以請把它當參考，不要當產品。下面幾個起手式，也是為了幫你建立自己的閘口——不是我的閘口。

幾個起手式

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

建立自己的方法論 repo：

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

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

我看到 Ponytail 和 Caveman 這兩個給 coding agent 用的 instruction/skill。麻煩你研究一下，跟我們自己的開發方法論比對（若還沒建立，可先參考 https://github.com/jackyckma/ai-dev-methodologies 了解一個閘口 repo 怎麼組織，但不要照搬其內容）：有哪些地方類似、哪些地方不同，有沒有什麼值得併入我們的方法論裡；又有沒有明顯分歧的地方——分歧的部分先不要自己決定，提出來跟我討論再說。

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

請參考 https://github.com/jackyckma/ai-dev-methodologies 的目錄結構與版本化做法，但不要把裡面的規則照抄。請先問我幾個問題，了解這個項目的技術棧與習慣，再幫我建立（或套用）我們自己的開發方法論，從 .agents/instructions/project-guidelines.md 開始寫起。

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

我們自己的開發方法論 repo 有新版本了。請讀 CHANGELOG.md，照 framework-adoption.md 幫我同步這個項目——只替換框架擁有的檔案、更新 .agents/METHODOLOGY.lock，如果跟我們項目自己的客製化有衝突，先提出來討論。

---

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