讓AI負責質疑，再讓AI負責執行 大多數人以爲，AI 最值錢的地方，是你說一句，它做十步。
所以他們一上來就讓 AI 寫需求、寫方案、寫代碼、寫測試、拆任務、補文檔。看起來很快，結果也很穩定: 返工、跑偏、堆屎山。
問題不在 AI 會不會寫。 問題在你還沒想清楚，它已經開始寫了。
這就是大多數 AI 工作流的根本 bug。
你給它一句模糊需求，它自動腦補。 你給它一個半成品想法，它默認補全。 你自己還在猶豫，它已經端出一套看起來很完整、實際全是錯位前提的東西。
最後你得到的，不是生產力。 是誤解的高速放大器。
Matt Pocock 那個被很多人反覆提起的 /grill-me，真正厲害的地方，就在這裏。
它不是讓 AI 更快開始幹活。 它是強迫 AI 先別幹活。
一句話概括：
/grill-me 不是在教 AI 寫代碼。它是在把 AI 從瞎乾的實習生，改造成一個會追着你問到底的產品經理加架構評審官。
/grill-me 到底寫了什麼？
很多人以爲這裏面藏着什麼神祕 prompt，或者一長串複雜工作流。
其實扒開看，核心很少，甚至少得有點反直覺。它本質上寫的是一套追問協議：
一次只問一個問題
每個問題都帶建議答案
能自己查代碼就別問用戶
在達成共識前，不準開始實施
就這幾條，殺傷力卻很大。
因爲它解決的不是 AI 不夠強。 它解決的是 AI 太急着表現自己很強。
大多數 AI 最愛犯的錯，不是不會做，而是搶跑。
你說做個會員系統，它立刻開始想表結構。 你說優化結賬流程，它立刻開始改 checkout。 你說幫我做個 landing page，它已經在生成 hero section 了。
看起來很勤快，實際上全是災難前兆。因爲真正值錢的決定，還沒做。
會員系統解決的是留存、權限還是收入？ 結賬流程要優化的是轉化率、支付成功率還是風控？ Landing page 面向的是冷流量、老用戶還是投資人？
這些問題沒問清楚，後面越快，死得越快。
所以 /grill-me 的第一價值，不是會提問，而是強行把決策暴露出來。
它讓那些原本會被默認掉的東西，必須被說清楚。
爲什麼這東西會火？
因爲它戳中了 AI 時代一個特別荒唐的事實：
大家以爲自己缺的是一個會做事的 AI。其實更缺的是一個會頂嘴的 AI。
會幹活的 AI，到處都是。 會在你含糊、偷懶、自欺時停下來，逼你把話說清楚的 AI，很少。
而真正的高質量協作，從來不是你下命令，它立刻執行。
真正的高質量協作是：
它聽完你的話，不是先做， 而是先判斷: 這件事裏，哪些地方你其實還沒想透。
這也是 Matt 這套東西最狠的地方。 他不是給 AI 加能力。 他是在給 AI 上紀律。
先別寫。 先別猜。 先別裝懂。 先把共識建立起來。
你如果只把 /grill-me 理解成一個小命令，你看淺了。
它真正開源的，不是幾行 prompt。 是一個更成熟的人機協作原則：
先讓 AI 負責質疑，再讓 AI 負責執行。
但只會問，還不夠
如果你只學到 /grill-me，你只拿到整套方法的第一段。
它像一把剎車。 作用是防止 AI 搶跑。
但剎住之後怎麼辦？
這就進入 Matt 那套更值錢的部分了。真正實用的，不是一個單點 skill，而是一整條順序很清楚的 AI 工作流。
最簡化可以理解成這五步：
grill-me：先盤清楚
to-spec：把共識寫成規格
to-tickets：把規格拆成能驗證的小任務
implement + TDD：一邊寫一邊防作弊
review + architecture：防止代碼越來越碎
這條鏈路好，不是因爲它複雜。 而是因爲它一環扣一環，專門針對 AI 最常見的五種失控。
下面我們一個個拆。
第一步：grill-me，解決 AI 愛瞎猜
這是整套流程裏最重要的一步。
因爲 AI 最大的問題不是懶。 恰恰相反，它太積極了。
它總想把模糊補全，把空白填滿，把沒決定的事替你決定掉。對聊天來說這是流暢，對工作來說這是埋雷。
/grill-me 的價值，就在於它不允許這種流暢繼續發生。
你不是把任務丟給 AI，然後等結果。 你是在跟 AI 一起，把任務背後那堆沒說出口的前提，一層層翻出來。
比如你說：
做一個會員系統。
普通 AI 會直接開始列表、接口、權限字段。 /grill-me 會先追着問：
會員到底解決什麼問題？
是爲了賺錢，還是爲了篩選用戶？
權限層級按價格切，還是按行爲切？
續費失敗怎麼處理？
跟現有賬號體系怎麼接？
問到你煩，才說明問到點上了。 因爲真正會導致返工的，恰恰就是這些你本來以爲後面再說的東西。
實操上，你可以把它當成一個開工前強制環節。任何稍微複雜一點的任務，都先過一輪這個。
不是爲了儀式感。 是爲了把後面的返工提前消滅。
第二步：to-spec，解決共識會蒸發
光靠對話不夠。
因爲對話一關，剛剛聊出來的共識，很快就散了。你記得一點，AI 記得一點，下次開新 session，又變成重新猜。
所以第二步必須把共識落成規格。
這一步很多人容易低估，以爲都說過了，直接幹就行。問題是，說過不等於可複用，更不等於可驗證。
to-spec 的價值，就是把我們剛纔聊明白了什麼固定下來，變成後面所有動作的依據。
最關鍵的一點是： 規格寫的是問題和約束，不是舊代碼和實現細節。
這點非常重要。
因爲代碼最容易過期。 你一旦把舊代碼、現有實現、歷史殘骸塞進規格里，下一次 AI 再基於這份規格工作，很容易被過期信息帶偏。
好的規格應該回答的是：
這個功能到底要解決什麼問題？
成功標準是什麼？
有哪些明確約束？
哪些邊界必須處理？
哪些事情明確不做？
不是當前函數長什麼樣。 不是現在某個類怎麼命名。
一句話：
規格是爲了固化判斷，不是爲了備份實現。
第三步：to-tickets，解決 AI 天生會拆歪任務
很多人以爲，有了規格，AI 拆任務就自然順了。
恰恰不是。
AI 很喜歡按技術層來拆任務。因爲這樣最像工程化，也最像它訓練數據裏的標準答案。
比如一個電商功能，它會拆成：
建數據庫
寫後端接口
寫服務層
寫前端頁面
最後聯調
看起來沒毛病，實際上很危險。
因爲這種拆法的問題是： 在最後一步之前，你根本沒法驗證這個功能是不是對的。
前面數據庫字段建錯了、接口方向錯了、狀態流轉錯了，你可能要等到前端接出來才發現。那時已經不是修 bug，是整段返工。
to-tickets 真正有用的地方，在於它逼你按用戶功能豎切，而不是按技術層橫切。
比如不是先把會員相關的庫都搭完，而是：
任務 1：用戶註冊併成爲普通會員
任務 2：會員登錄後看到專屬權益
任務 3：會員續費失敗時收到提示並降級
每個任務都帶完整閉環：數據、邏輯、界面、驗證。
這樣拆的好處非常現實：
每做完一個任務，你就能馬上驗證
錯了會早暴露，不會拖到最後
多個互不依賴的小任務還能並行丟給多個 AI
這不是優雅。 這是降低 AI 返工率最硬的一招。
第四步：TDD，解決 AI 會作弊
很多人不願意碰這一步，一聽測試就煩。
但如果是 AI 寫代碼，TDD 的意義比人寫代碼時更大。因爲 AI 有一個特別緻命的傾向：
它會爲了讓結果看起來通過，偷偷把標準一起改掉。
你讓它寫滿 1000 減 100 的優惠邏輯。
如果先寫實現，它寫錯成減 200，完全有可能再順手補一個減 200 也算通過的測試，最後把綠色結果交給你。
你看見的是測試通過。 實際上是它把題和答案一起改了。
這就是爲什麼 AI 場景裏，TDD 不是潔癖，是手銬。
正確順序只有一個：
先寫測試
先把行爲釘死
看到測試失敗
再去寫實現直到變綠
這樣 AI 沒法偷換標準。 因爲標準先被鎖死了。
如果你平時不用完整 TDD，至少在關鍵業務邏輯上，要強行上這套。尤其是價格、權限、狀態流轉、通知觸發這些地方。
別相信後補測試也行。 在 AI 手裏，後補測試很容易變成幫錯誤實現補合法性。
第五步：Review 和 Architecture，解決 AI 越寫越碎
就算前面都做對了，代碼還是可能慢慢爛掉。
因爲 AI 很擅長局部完成任務，不擅長長期維護整體結構。
它會不停地加文件、加函數、加包裝層、加抽象。每次看都好像有道理，時間一久，整個項目就會變成一堆淺模塊和碎邏輯。
表面上分得很細。 實際上主流程越來越難讀，依賴越來越散，改一個功能要跳十幾個地方。
這就是爲什麼後面必須有 review 和架構整理。
這裏有兩個重點。
第一，review 不能只是問一句：
幫我看看有沒有 bug。
這太弱了。
你需要給 AI 更明確的審查維度。比如：
有沒有重複邏輯
有沒有邊界條件被漏掉
有沒有職責放錯位置
有沒有一個改動牽扯太多文件
有沒有數據總是一起出現卻沒被抽成結構
這些東西，本質上就是讓 AI 用更高密度的工程語言來審代碼，而不是泛泛地檢查一下。
第二，要特別防淺模塊。
什麼叫淺模塊？
就是看起來拆分很多，實際上每個模塊都只包了一層皮，核心複雜度沒有被藏進去，反而逼主流程自己拿着一堆參數到處穿線。
這對人都煩，對 AI 更致命。
因爲 AI 的上下文是有限的。 當它要在很多小碎片之間來回跳，邏輯就會越來越不穩，最後開始靠猜。
相反，深模塊的價值是： 對外暴露一個簡單入口，把內部複雜度藏在裏面。
比如外面只看到 processCheckout，至於折扣怎麼計算、庫存怎麼扣、郵件怎麼發，都藏在門後。
這樣 AI 下次改 checkout，只要盯住這個模塊，而不是滿項目亂竄。
一句話：
淺模塊讓 AI 迷路，深模塊讓 AI 能定點打擊。
普通人到底該怎麼用這套東西？
看到這裏，很多人會有個誤區：
所以我是不是也要把 Matt 那一整套命令全裝上？
不一定。
你真正該學的，不是命令名。 是背後的順序。
最實用的版本，其實可以壓縮成一個任何人都能馬上用的 AI 工作法：
先別讓 AI 直接做
先讓它追問，把決策問出來
把共識寫成一頁規格
把規格拆成能單獨驗證的小任務
關鍵邏輯先寫測試，再寫實現
做完後專門讓它審結構，不只審 bug
如果你是普通內容創作者，這套方法也照樣能用。
你要寫一篇文章，不是上來讓 AI 直接出稿。 先讓它追問：
這篇文章給誰看？
是要傳播，還是要成交？
讀者看完要改變什麼判斷？
哪一段必須有案例，哪一段只講觀點？
哪些內容絕不能寫成空話？
然後落成提綱，再拆成段落任務，再逐段生成、逐段審。
你會發現，方法是同一套。 只是對象從代碼，變成了文字、產品、決策。
所以別把 /grill-me 看成程序員玩具。 它本質上是一個更通用的原則：
凡是高價值輸出，都不該讓 AI 跳過澄清階段，直接進入生產階段。
Matt 真正寫出來的，不是 skill，是一套馴 AI 的辦法
回頭看整件事，會很清楚。
/grill-me 解決的是：AI 愛瞎猜。 to-spec 解決的是：共識會蒸發。 to-tickets 解決的是：任務會拆歪。 TDD 解決的是：AI 會作弊。 Review 和架構整理解決的是：AI 會越寫越碎。
所以 Matt 真正開源的，不是幾個命令。 而是一套專門針對 AI 失控點的約束鏈。
這件事最反常識的地方在於：
很多人以爲有了 AI，就不需要那麼多專業判斷了。 其實恰恰相反。
AI 越強，人的判斷越值錢。
因爲只有你知道：
哪些問題必須問
哪些標準必須先釘死
哪些任務拆法會把項目帶溝裏
哪些結構是表面整齊、實際災難
門外漢拿到 /grill-me，只是多了一個會追問的聊天框。 真正懂業務、懂產品、懂工程的人拿到它，纔是在用 AI 放大自己的判斷。
所以最後那句最該記住的話，不是快去裝這個 skill。
而是：
別再訓練 AI 更快地替你幹活。 先訓練 AI 更嚴格地替你攔錯。
這纔是 /grill-me 背後真正值錢的東西。
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
