700 萬人下載的 /grill-me，Matt Pocock 到底寫了什麼？

最近AI圈有一個很紅的skill叫做Grill Me 這是Maplecock在GitHub上的開源專案的其中一個skill 這個專案目前已經有超過16萬顆星 被下載了700萬次 如果不認識Maplecock的人 我簡單介紹一下他 他是TypeScript領域最頂尖的專家和老師 在工程師圈子裡絕對是大神級的人物 非常多開發者都是靠他出的教材 把技術練起來的 這次爆紅的專案 其實就是這位大神 把自己的AI工作流開源出來 這個專案裡面放了一整套skill 從寫規格、猜任務到寫測試都有 其中最先紅起來的就是Grill Me 他的功能就是強制你在動工之前 先讓AI反過來把你拷問一輪 一題一題問 問到你完全扛不住 非得想清楚不可 但很多人只盯著Grill Me這一個 我認為非常可惜 打開整個專案會發現 裡面不只是幾個skill 他其實是Maplecock這些年寫程式 與AI開發經驗的集大成 他等於是把自己的程式功力 打包進這整個專案裡了 為了搞懂他是怎麼控制AI的 今天我們就來把這套專案拆開來看 我們會先從Grill Me開頭 然後依序介紹後面的skill 是怎麼互相配合寫程式的 接著我會挑出幾個我覺得很有料的skill 帶你拆解Matt為什麼這樣寫的底層邏輯 一起看懂大神腦袋裡到底在裝什麼 最後我會把這套專案 跟另外一套很熱門的開發skill套件 Superpowers 做個比較 讓你知道他們的差異是什麼 以及你到底適合哪一種 那我們開始 Matt Polcott這一年 幾乎把重心整個搬到AI上 在大量依賴AI開發後 他發現比起寫code的速度 更難的是怎麼控制AI 因為AI本質上是一個充滿隨機性的黑盒子 所以他打造這套工具的終極目標 就是要控制AI的隨機性 要控制這種隨機性 其實市面上已經有好幾套 很紅的框架 在試著做這件事了 像是GashatDone SpecKit 或Superpowers 但Matt覺得這些大框架的毛病 在於他們想把你整個開發流程接管過去 什麼意思 以SpecKit來說 他會把重寫規格 做計畫到實作 全綁成一條又重又硬的固定流程 只要你前面一步定歪了 錯誤就會順著整條線傳染到後面 等你想改 往往整條都得重跑 特別難救 所以他的skill走完全相反的路 每個都可以做得很小很好改 還能自由拼裝 這個小而且模組化的理念 就是他後面所有東西的底層邏輯 那我們先來介紹Matt Polcott本人最喜歡 也是整條工作流起點的skill 叫做Grooming 它的作用很簡單 就是讓AI反過來拷問你 如果你真的去打開這個檔案 你會發現這個被幾百萬人下載的skill 裡面居然只有短短五行字 我們來看看這五行字的原文 第一句 是叫AI在我們對接下來的計畫沒有達成共識之前 把我往死裡問 第二句 他要AI像是在畫心智圖一樣 順著你的思路去延伸 把你每一個決定背後會引發的連鎖反應 一個一個抓出來 問到底 接下來 他要求AI每次只能問一個問題 而且必須附上建議答案 最後還嚴格規定 在整體設計達成共識之前 絕對不準偷偷跑去寫程式 為什麼大神要特地寫這五行字 這就要說到軟體開發的本質 寫程式的本質是連續做出幾百個微觀的決定 像是防呆怎麼做 斷線怎麼辦 極端資料怎麼處理 如果你習慣把模糊的想法 直接丟給AI憑感覺做 也就是Vive Coding 你其實是把這幾百個決定的決策權 全部外包給AI這個黑盒子 而AI為了討好你 通常會瞎掰出一套最難維護的架構 這是做生產級別的軟體產品的噩夢 所以 Groovy裡面這五行字的唯一目的 是要把決策權搶回人類手裡 Matt知道 要人類面對空白螢幕 從零寫出一份涵蓋所有極端狀況的完美企劃書 太痛苦了 所以他用這五行字 把找漏洞的苦差事丟給AI AI負責順著決策數 無情地把你腦袋裡沒想清楚的盲點 一個個挖出來 AI只負責給選項 拍板定案的 永遠是人類 透過這種強制的一問一答 人類才能穩穩坐在架構詞的位置上 現在你已經用Groovy被AI拷問完了 但只要你一關掉對話 AI就會立刻失憶 剛纔好不容易炒出來的共識直接蒸發 所以生產線的第二戰 就是用ToSpec這個Skill 趕快把共識寫下來 變成一份規格書存起來 但Matt在這個Skill裡 完全禁止AI在寫Spec的時候 引用或是寫任何的程式碼 為什麼要這麼極端? 因為軟體工程界有一個最大的痛 也就是文件永遠跟不上程式碼更新的速度 比起整體的業務邏輯 具體的程式碼是最容易變動的 如果你讓AI把程式碼寫進規格裡 未來當你的程式碼改動 跟規格對不上的時候 下一次你再請AI照規格去修改功能 它就會被規格書裡面過期 錯誤的舊Code給搞混 越改越亂 所以Matt直接封殺這個選項 就是要確保規格書永遠只專注在思考 這項功能到底要解決什麼問題 規格有了 接下來是第三個Skill 也就是Two Tickets 它的作用 就是把剛剛上一部所寫出來的規格書 拆解成具體的代辦任務 那Two Tickets究竟是怎麼去拆分任務的呢? 它裡面其實蘊含了一個非常重要的開發方法論 專門用來對付AI規劃任務 總是很爛的這個致命缺點 如果讓AI自己決定代辦清單 它天生有一種壞習慣 喜歡按照技術架構來分工 舉個例子 如果我們今天讓AI自己做一個電商網站 而且讓它自己規劃任務的話 它會先把全部的資料庫建好 然後再把背後處理資料的邏輯全部寫完 最後才畫出大家看得到的前段畫面 這樣分工最可怕的盲點是 在最後一部畫面出來之前 你完全沒辦法測試任何東西 如果它第一部的資料庫建錯了 你得等到做前段畫面時才會發現 那前面的心血就全毀了 為瞭解決這個問題 Two Tickets這個Skill強制逼AI改變習慣 改用使用者功能來拆任務 同樣是電商網站 Two Tickets會切出來兩個任務 第一個任務 我們只做會員登入這個功能 這個任務裡 就已經包含了專屬登入的資料庫 登入的邏輯 以及登入的畫面 第二個任務 再去做 把商品加入購物車 同樣也包含完整的資料庫 後段的邏輯 以及前段的畫面 你看懂差別了嗎? 按照功能拆的好處是 當第一個任務做完 雖然網站只有登入能用 但你馬上就可以打開瀏覽器測試 你不是蒙著眼把幾千行程式碼寫完 才開始審核AI的產出 你會每做完一個小功能 就能立刻確認它到底會不會動 除了能隨時測試 Two Tickets還會幫你排好任務順序 那些互不幹擾的任務 你可以同時發包給好幾個AI平行處理 開發速度直接翻倍 好 任務都排好了 接下來終於要進入實作階段了 MacBook的這套系統裡 有一個專門負責寫程式的Skill 就叫做Implement 你只要下載實作的指令 它就會照著任務清單開始寫code 寫的過程中 它會自動用TDD的方式引導開發 寫完還會自己呼叫code的review skill來做審查 說到這 你可能會好奇 這個TDD到底是什麼 TDD的全名是測試驅動開發 平時寫程式 工程師不可能每次改完功能 都手動去點網頁檢查有沒有壞掉 所謂的測試 其實就是寫一段用來檢查對錯的程式 比如現在你要開發一個新功能 要讓用戶在結帳時金額滿千送百 寫測試 就是提早定下一條死規矩 購物車滿一千元時 結帳金額必須扣一百 以後只要有人改壞了購物車的程式 這段測試一跑就會立刻報錯 幫你攔截漏洞 而TDD 也就是測試驅動開發的核心精神 就是規定你在寫功能之前 必須先寫好這個測試 為什麼對AI開發來說 這件事這麼重要 因為AI骨子裡是個作弊仔 如果你讓AI先寫算錢的程式 再補測試的話 萬一AI寫出bug 像是把滿一千扣一百 寫成了扣兩百怎麼辦 它為了交差 AI會直接幫你生出一個假的測試 這個測試會直接說 金額滿一千元必須扣兩百 檢查通過 它拿自己寫錯的邏輯 去配上一個絕對會通過的測試 這樣你根本抓不住bug 所以TDD就是用來防作弊的 在寫任何一行程式之前 AI必須先把測試定死 滿一千就是隻能扣一百 因為這時候程式根本還沒寫 測試一跑下去絕對會失敗 亮起紅燈 等到紅燈出現了 才準AI開始寫真正算錢的程式 直到紅燈變成過關的綠燈為止 用這種先寫測試再寫程式的順序 才能徹底鎖死AI亂寫交差的空間 程式寫完 測試也過了 這套開發流程 接下來會自動觸發一個審查的skill 它會開一個全新的session來做code review 這樣做 是為了讓AI保持在最乾淨 最聰明的狀態下做檢查 避免被原本寫程式時的記憶幹擾 我仔細看了這個skill的原始碼 覺得非常值得我們學習 因為它不是隻寫一行空泛的 請幫我做code review 檢查有沒有bug 它是把軟體工程界幾十年來公認的 Langcode的症狀 全部寫成具體的檢查清單 這裡我挑三個新手最容易踩坑 也最重要的原則 分享給你 第一個常見的坑叫做 改A卻要同時動到B跟C 你明明只是想改一個按鈕的顏色 結果居然要打開十幾個不同的檔案去修改 這代表每次改動 都像散彈槍打出去一樣散落各處 這時候code review 就會要求你把它們重新集中起來 這個狀況在skill裡面叫做shotgun surgery 第二個常見的坑叫做 把邏輯寫在了錯誤的檔案裡 如果一段處理訂單的程式碼 老是跑去管庫存的檔案那邊拿資料來算 code review就會警告你 這段邏輯放錯位置了 應該直接搬去訂單那邊 這個症狀在skill裡面叫做feature ending 第三個常見的坑叫做 讓同一組變數散落在各處 比如在你的程式裡 買家姓名、電話、地址 這三個東西總是同時出現 既然它們永遠綁在一起 就該把它們打包成一個叫做聯絡人的包裹 而不是每次都在程式碼裡散著傳來傳去 這個現象在skill裡面叫做data clumps Matt Pocock在這套skill裡 就直接點名了12種這樣的爛code的現象 這些現象都來自 寫程式的經典名著refactoring這本書裡 Matt Pocock就是把這套歷久不衰的智慧 直接寫進skill裡當作指引詞 不要小看這些指引詞 我覺得這是Matt Pocock這個skill 可以這麼厲害的關鍵之一 如果你仔細看他寫的prompt 你會發現Matt的skill跟別人很不一樣 他的每一個skill都非常短非常精煉 每一個字都是刻意挑過的 他到底是怎麼把字句磨得這麼精煉的 其實專案裡有一個skill叫做writing great skills 裡面就藏著這個祕密 它的核心理念是 在AI面前你多寫一句廢話 AI就多一分分心的可能 所以他提出了第一個原則叫做修剪pruning 意思就是要修剪掉所有廢話 還有會讓AI分心的文字 甚至是那些你不說 模型也知道該怎麼做的指令 全部都要刪掉 這就是為什麼那個要拷問你的grillme 居然只用五行字就能寫完 他必須確保skill裡面的每一句指令都有實際作用 但字數這麼少 AI聽得懂嗎 這就來到他的第二個原則指引詞 指引詞你可以理解為一種資訊被極度壓縮 但含金量超高的專用名詞 就像剛剛提到的data clumps 就是一個絕佳的指引詞 你只要對AI說了這個字 就等於跟AI說了 請幫我檢查程式碼裡 有沒有總是綁在一起出現的變數 有的話請把它們打包成一個獨立的物件 Matt在他的skill裡面 非常大量的運用這種 深植在AI訓練資料裡的經典專用名詞 他利用這些術語來精準傳達他的意思 直接用一個字取代了一百字的廢話解釋 最後加上第三個原則完成標準 給AI一個明確的終點 他就是用這三個原則 把會亂發散的AI 變成了乖乖聽話的奴隸 Matt用這整套流程把AI訓練成了頂級工程師 但即便如此 你的專案依然有一個致命的隱形炸彈 這顆炸彈叫做邏輯過度的碎片化 AI寫程式的速度實在太快了 但它天生沒有大局觀 每次只能盯著眼前的那幾個檔案 為了方便交差 AI最容易寫出一堆所謂的潛模組 什麼叫潛模組? 想像一棟房子 裡面有廚房、客廳、臥室 房間分得很乾淨 但這棟房子卻沒有大門 你要進廚房要走外面的窗戶 進客廳要爬煙囪 為什麼這會是一場災難? 因為這種設計的溝通成本極高 這就像是你要進房子 卻得被迫記住五個房間的獨立密碼跟路線 AI寫購物車結帳時 最喜歡蓋這種房子 它把結帳接成了五個小房間 計算折扣、驗證信用卡、建立訂單、扣除庫存 自己信 結果就是 它沒有幫這棟房子蓋一個統一的大門來隱藏細節 這導致主程師必須親自去處理這五間房的資料傳遞 這不僅讓主程師的負擔極大 更致命的是 這種架構對AI來說是完全無法維護的 因為AI的Context Windows是有限的 當結帳系統出bug時 你請AI去修 它一打開檔案 發現邏輯竟然散落在這五個房間裡 為了看懂整個結帳流程 AI必須在房間之間瘋狂跳轉 一旦同時塞進太多瑣碎的邏輯 超過了它的記憶範圍 它就會開始瞎猜 最後很容易把你原本正常的程式碼也一起改壞 Matt認為 真正能讓AI發揮權力的好架構 應該是聲模組 聲模組並不是叫你把一萬行code 塞在同一個大房間裡不準切分 而是要蓋一扇極度簡單的大門 把複雜的房間藏在裡面 同樣是結帳 聲模組對外只提供一個簡單的購物車大門 在程式裡面可能叫process checkout這個函數 至於折扣怎麼算 信用卡怎麼驗的小房間 全部藏在大門背後 組程式只要敲一次門 事情就辦妥了 完全不需要知道裡面長怎樣 聲模組為什麼對AI比較好 因為它具備極強的局部性 當結帳出問題時 AI只要專注閱讀這一個模組就好 所有的來龍去脈跟邏輯 都完整的集中在它眼前的視野裡 它不需要去別的地方找線索 所以能極度精準的抓出bug並修復 簡單來說 淺模組會讓AI迷路並瞎猜 聲模組能讓AI專注並精準打擊 為了對抗AI造成的淺模組危機 Matt開發了Improved Codebase Architecture 這個大掃除skill 它不會傻傻的只看語法 而是會對你的程式碼進行殘酷的刪除測試 它會去檢視每一個模組並在腦中想像 如果我把這個模組直接拔掉 讓主程式自己處理會發生什麼事 如果拔掉它之後 天下大亂 原本隱藏的複雜邏輯 全部榨回主程式裡 那代表這個模組是有在做事的聲模組 但如果拔掉它之後 你發現程式碼反而變清爽了 原本要跳來跳去看兩個檔案 現在全部集中在一個地方就好 這就代表 這個模組根本沒有隱藏任何細節 它只是一個多餘的空殼 AI就是透過這個測試 精準把這些假裝在做事 只會害人迷路的淺模組給揪出來 並建議你把它們清理掉 那一般人要怎麼實際運用它呢 MAT建議是把它當成日常保養 每隔幾天 就在終端機叫AI跑一次這個指令 它會掃描你整個專案 然後在你的電腦上生成一份HTML診斷報告 畫出前後的架構對比圖 你連程式碼都不用看 只要看著這份視覺化圖表 挑一個覺得最急迫的建議 然後對AI說 好 就照這個方案重構 它就會幫你把四散的程式碼 重新聚攏成一個完美的聲模組 回顧今天拆解的這整套工作流 你會發現 這不僅僅是一套軟體開發的工作流 這簡直是Matt Polcock與AI密集合作後 總結出來該如何馴化AI的完整攻略 AI很容易自己猜 做的東西跟你想像不一樣 所以Matt用GrowMe TwoSpec逼出細節 AI喜歡寫無法測試的半成品 所以用TwoTickets強制告訴它 應該怎麼規劃任務 AI愛作弊 所以用TDD綁死它的手腳 AI的記憶有限 所以我們用精煉的引導詞或專業名詞來溝通 並用架構大掃除的工具 讓它設計出好維護的聲模組 到這裡 Matt Polcock這套技術的主要用法就講完了 不過我要先說 今天講的只是這套系統的主幹道 實際去翻它的Repo 再去看它自己平常是怎麼用的 你會發現裡面還藏了一大堆細節 是我今天還沒有時間講到的 像是GrowMe好了 它其實有一個進化版 叫做GrowWithDocs 這是為瞭解決GrowMe的一個罩門 也就是AI越熟悉你的專案 拷問才問得越深 但GrowMe每次開工 都要重新摸一次你的專案 而且有些東西 它翻遍程式碼也查不到 像你的專有名詞的定義 當初為什麼這樣決定 所以前半場都在問背景 真正尖銳的問題 要等它摸熟了纔出得來 GrowWithDocs 會在每一場拷問裡 順手把這些專有名詞和重要的決策 寫成文件留下來 之後AI帶著這些資料來拷問你 一開場就能切進重點 Matt自己寫程式 也比較常用這個版本 另外 我還在他的Repo裡面 挖到一個沒什麼人注意到 但是我覺得比他寫程式的Skill 更值錢的東西 就是三個專門拿來 與AI寫作的Skill 我看到這個的時候 覺得它完全顛覆了 我對AI寫作的認知 我們平常叫AI寫作 就是跟GPT說幫我寫一篇Blog 或幫我寫一個影片腳本 但Matt的Skill 完全走的是另外一條路 我覺得這纔是正確 駕馭AI寫作的方法 這些影片沒講到的細節 加上這套寫作 工作流的完整拆解 我全部整理在 這一期的Patreon文章裡 有興趣的朋友 可以在影片下方資訊欄 找到連結 最後 我想拿Matt Pocock的Skill 跟我之前很常用的 Superpowers稍微比一下 Superpowers最強的地方 是他把整套AI工作流 定義得很完整 他會用寫死的九個步驟 逼你把目標想清楚 寫好文件 才準你動工 在模型還不夠聰明 很容易偏題的時候 這種保姆級的防呆流程 非常管用 但如果你現在是用 GPT 5.6 Soul 或是FEVO 5這種等級的模型 你會發現 Superpowers的這套死規矩 反而變成了一種累贅 當然 不管模型多聰明 動工前 我們一樣需要釐清目標 但最大的差別在於 現在這些模型的理解力極強 我們不再需要像田表一樣 被強迫走完九個 繁瑣的防呆步驟 才能確保模型不會失控翻車 既然不再需要 重度的防呆機制 把整個設計跟執行階段 包山包海 塞進一個巨大流程裡 就顯得太笨重了 這也是為什麼 Matt Pocock的做法 反而更適合現在的生態 Matt的哲學 跟Superpowers完全相反 他走的是極簡主義跟模組化 他堅持一個Skill 只解決一個問題 如果你還沒想清楚目標 就呼叫Grooming來拷問需求 如果你只需要規格 就讓TwoSpec幫你寫 如果你準備好要動工了 就交給TwoTickets來拆任務 每一個工具做完就收工 絕對不囉嗦 把工具切得這麼小 最大的好處就是 他不會用死流程綁架你 面對一個新需求 Superpowers會希望你乖乖從頭開始 一路走完設計、寫計畫 執行的完整流程 他確保你不會漏掉步驟 但產出的文件 也都是為他自己的下一步量身打造的 別人很難接受 但用Matt的Skill 只要你手上有份規格 不管是你自己寫的 主管給的 還是別的AI產的 你都能直接跳過前面的步驟 直接丟給TwoTickets 叫他拆任務 拆完之後 你想從哪一步開始寫程式 哪一步結束 完全由你決定 簡單來說 在過去模型還很笨的時候 Superpowers給了我們一套 已經組好的自動化生產線 確保品質穩定 但在模型越來越聰明的現在 Matt給的這盒 隨插即用的樂高積木 才真正把工作的主導權 交還到了我們手上 好 那回頭看這整套系統 回答一個問題 Matt到底是怎麼把不受控的AI 製得服服貼貼的 其實說穿了 他靠的就是他非常深厚的 軟體工程底子 而他把這個底子 巧妙地用在了兩個地方 第一個地方 是用在架構上 他把過去這幾十年 軟體工程界早就證明有效的老方法 像是深模組 LAN-code的徵兆 全部融入到scale的架構裡 來規範AI的行為 第二個地方 是用在與AI溝通上 既然他懂那麼多 軟體工程的專有名詞 他乾脆就把這些詞 拿來當作prompt的一部分 你想想看 與其寫一大堆廢話 去跟AI解釋 不如直接丟一個精準的專業術語 AI一聽就懂 就像一位快退休的老教練 給球員的一句話 聽起來很簡單 但裡面蘊含好幾十年的經驗 Matt用最精簡的語言 表達最深奧的道理 讓AI根本沒有分心 這兩招加起來 徹底打破了一個迷思 很多人以為有了AI 我們就不需要在自己的領域精進了 但Matt證明瞭 只有成為專業領域的專家 你才能真正控制好AI 我認為Matt真正開源給我們的 從來都不是幾個scale 他是在教我們 在AI時代 該怎麼用你在專業領域 所積累的思維和語言 去真正駕馭AI這個黑盒子 那以上就是今天的內容 希望對你有所幫助 也能給你一點啟發 如果你喜歡 記得幫我按讚 追蹤加分享 我們下次見