在軟體工程界，TypeScript 頂尖大神 Matt Pocock 所開源的 AI 協作套件，在 GitHub 上獲得了極高的關注，下載量更突破了 700 萬次。大神的實戰經驗指明了一個殘酷的現實：與 AI 協作最難的不是寫程式的速度，而是「如何控制 AI」。
AI 本質上是一個充滿隨機性的黑盒子。如果你習慣把含糊的想法直接丟給 AI「憑感覺盲目動工（Vibe Coding）」，你其實是把這幾百個微觀決策的控制權，雙手奉送給了 AI。AI 為了急於討好你，通常會瞎編出一套最容易交差、但最難維護的淺模組架構，這在生產環境中簡直是一場噩夢。
我們必須套用 Matt Pocock 的防禦工作流，將主導權強行奪回人類手中。
[ 大神防禦工作流 ] | +----------------------+----------------------+ | | v v [ 事前拷問 (/grill-me) ] [ 按功能拆解 (to-tickets) ] - 雙方共識達成前，絕對不准動筆寫程式 - 拒絕技術分工 (先建 DB 再寫後端) - AI 負責無情挖盲點，人負責拍板決策 - 強制用「使用者功能」切小 Ticket 執行
實戰步驟一：動工前的事前拷問——用 /grill-me 逼出大腦盲點
大神的防禦起手式，是一個名為 /grill-me 的神級技能。令人驚訝的是，這份被數百萬人下載的 Skill 指令，原始碼居然只有短短短的五行字。
這五行字的精髓，是強行在開發前架設一道思想審查關卡：
「共識達成前，絕對不准偷跑寫程式」：在我們對接下來的計畫達成共識之前，嚴格禁止 AI 撰寫任何一行程式碼。這條死規定，直接封殺了 AI 喜歡「先寫再說」的通靈惡習。
一問一答，像畫心智圖一樣深挖細節：指令要求 AI 必須像畫心智圖一樣，順著你的決策思路，把背後可能會引發的連鎖反應、盲點與極端情況（邊角案例）一個個挖出來刨根問底。
每次只問一題，並附上建議選項：AI 每次只能問一個問題，且必須提供幾個建議的 A、B、C 答案選項。
寫程式本身就是由幾百個微觀決策堆疊出來的。Matt Pocock 透過這五行字，把「尋找漏洞、提供選項」的苦差事丟給推理力強大的 AI，而人類只負責坐在決策者的位子，輕鬆點選 A 或 B 來拍板定案。透過這種強制的一問一答，雙方才能真正對齊需求，穩穩地把決策權握在人類手裡。
實戰步驟二：使用者導向的任務拆解——用 to-tickets 打碎技術黑箱
當 /grill-me 拷問結束並收斂出規格書後，下一步絕不能讓 AI 自由發揮去排定待辦清單，因為 AI 天生有一種極壞的技術直覺：喜歡按照「技術架構」來分工。
如果讓 AI 自由分工，它會先花三天把所有資料庫建好，再寫後端的邏輯，最後才去畫前端的網頁。這種拆法最大的盲點在於：在最後一步畫面出來前，你完全無法測試任何東西。一旦它第一步的資料庫欄位設計錯了，你得等到最後一天畫前端時才會發現，這時整條產線都得砍掉重練。
為了解決這個致命缺點，Matt 的工作流引入了 to-tickets（或 draft-tickets）這個 Skill，強制 AI 改用「使用者功能（User Features）」來打碎任務：
按功能切片（Feature Slicing）：同樣做電商網站，to-tickets 會拆解成：
任務一：只做「會員登入」功能（包含登入所需的專屬資料庫、後端邏輯、與前端畫面）。
任務二：只做「商品加入購物車」功能（同樣包含獨立的資料庫、後端與前端）。
做完一個、測試一個，杜絕黑箱：按功能拆解的好處是，當第一個任務做完時，雖然整個網站只有登入可用，但你馬上就能打開瀏覽器親自測試它會不會動。你不再是蒙著眼睛看著 AI 盲寫幾千行代碼，而是每做完一個小功能，就能立刻驗證、即時糾偏。