AI 做出來的東西不是你要的，根因通常在流程：你太晚才發現走錯。解法是把「發現走錯」這件事往前挪，挪到還沒動手之前。Matt Pocock 公開的那套免費 skill（累計安裝 1,680 萬次、整包約 25 支）就是在做這件事，主線四個指令：先拷問你一輪、寫成規格、拆成看得出對錯的小塊、做完當場驗。以下是完整用法，還有兩個我自己接在後面的做法。
🔥 文章最下方有完整教學影片
快速摘要：這套東西是什麼、怎麼用
- 是什麼：Matt Pocock 公開的一組 AI 指令檔（skill），免費、MIT 授權、原始碼公開。
- 裝在哪：Claude Code、Codex 等主流 AI 工具都能裝；裝完在對話框打一個斜線就叫得出來，第一次要先跑
/setup-matt-pocock-skills。 - 主線四步：
/grill-with-docs（先拷問你）→/to-spec（寫成規格）→/to-tickets（拆成看得出對錯的小塊）→/implement（先寫測試再寫程式）。四步要在同一個對話視窗跑完。 - 三種分流：方向都還沒定打
/wayfinder；東西壞了打/diagnosing-bugs；想不起來該打哪一個就問/ask-matt。 - 兩個延伸做法：讓第二個 AI 挑計畫（只給它圈問題的權限，不讓它動手改），以及用 Claude Code 的
/loop讓它照一份寫好的清單自己跑完。 - 什麼時候不用走：改一句文案、換一個按鈕的字，直接叫它改就好。
你請 AI 幫你做一個東西。前面幾輪都很順，你講一句它做一句，東西一塊一塊做出來。到第四輪你覺得差不多了，打開來從頭看一遍，發現不是你要的。
而且它沒有做壞。它做的那一個，跟你腦袋裡的那一個，從第一輪就分岔了。你花在後面三輪的時間，全部都疊在那條岔路上。
你可能不寫程式，只是想做一個自己每天要用的小工具；你也可能是工程師，讓 AI 進到公司的專案裡幫你改東西。兩種人踩到的是同一件事：你是在做完之後，才發現走錯的。
問題不是 AI 不夠聰明，是你打算在哪一刻發現自己走錯。大部分人是在整批做完之後。我自己也是在整批做完之後才發現的，那一次花掉我一個晚上。
這套東西(grill-me)是什麼
這件事有人已經處理過了。他叫 Matt Pocock，很多工程師的 TypeScript 是看他的教學學會的，他把自己每天在用的一套東西公開了出來。
它不是一個應用程式，是一組寫好的指令檔。你現在在用哪個 AI 工具，就能裝進哪一個；裝完之後在對話框裡打一個斜線，它就會跳出來讓你選。這種指令檔有個名字叫技能（skill）。
整包我全部開來看過，最後固定在用的是四個。
四種失敗，其實是同一個問題
先講四個失敗。你大概至少踩過其中一個。
第一種，它做的不是我要的。 你說「幫我做一個可以記錄每天工作的東西」，它給你一個有登入、有分類、有標籤的系統。你其實只想要一個能打字、存得起來的框。根因不在它笨，在於一開始沒有人講得清楚自己要什麼，包括你自己。
第二種，它很囉唆。 同一群人，你這次叫「客戶」，下次叫「會員」，再下次叫「使用者」。它每一次都要停下來確認你講的是不是同一個東西。你跟它之間沒有共同的說法，所以每一輪都要重新對一次。
第三種，它不知道自己做得對不對。 這就像儀表板全黑還在開飛機。你還是在開、還是在做決定，但沒有一個數字回頭告訴你高度對不對、油還剩多少。出事的時候，你是靠撞上去才知道的。
這件事不是 AI 時代才有的。他在說明文件裡引了一本一九九九年的老書《The Pragmatic Programmer》，裡面有一句話：回饋的速度，就是你的速限。你多久才知道自己做對了沒有，決定了你能跑多快，跟用不用 AI 沒有關係。
第四種，越做越爛。 AI 加速的不只是把東西做出來，還有整個東西變亂的速度。以前它變亂的速度，受限於一個人打字的速度。現在不是了。
你回想一下最近一次不順，多半就落在這四個裡面。所以「AI 做不出我要的東西」可以換一個更有用的講法：這是流程的問題。而且這四個是同一件事的四種長相，就是你太晚才發現自己走錯了。講不清楚要什麼，是一開始就走錯；沒有共同說法，是每次都要重新走一次；不知道對不對，是走錯了沒人告訴你；越做越爛，是走錯的東西一直疊上去。
解法：把「發現走錯」往前挪
四個病灶同一個解法：把「發現走錯」這件事，一路往前挪。往前挪到最前面，就是還沒動手之前。
這套東西的主線有四步，第一步的設計就是不准你動手。你打下去，它不會開始做事，它會反過來問你問題，一輪一輪問，問到你自己講得出來為止。
所以你要的不是把需求講得更詳細，是在你開始之前，先有一個東西逼你把話講完整。被問完之後，那份規格是你自己寫出來的。這一輪拷問是四步裡最值得花時間的一步，後面三步都建立在它上面。
四個指令，一條主線
第一步：/grill-with-docs，先不准你動手
這個拷問有兩個版本，差別只有一件事：grill-with-docs 會順手把你們討論的過程寫下來留著，grill-me 不會。留著的好處是，等你之後要做別的東西，它問過什麼、你答過什麼、最後決定了什麼都還在，不用從頭再解釋一次你的狀況。我固定用會留紀錄的那個。
講一個具體的。假設有一個人叫阿凱，他想做一個排班表的小工具。阿凱一開始很確定不需要「自動算工時」這件事：就那幾個人，月底自己加一加就好。他還把這個理由寫了下來。
拷問到最後，這個判斷被推翻了。推翻它的不是「其實你需要自動算」，是它問出了一件阿凱自己沒想到的事：班一改，上個月加好的工時就過期了，而表上看起來完全正常。沒有任何東西會告訴你那個數字已經不對了。
所以「我自己很確定」不能拿來當跳過拷問的理由。阿凱也很確定，還把理由寫下來了。真正能跳過的只有一種：做錯了重做也就幾分鐘的那種事。
第二步：/to-spec，把談出來的東西寫下來
被問完之後你會踩到第一件事：那些決定只活在那一次對話裡。你關掉視窗它就忘了，明天再開一個新的，你得從頭再講一遍。
所以第二步是把它寫下來。指令名稱裡那個 spec 就是規格，一份講清楚「要做成什麼樣」的文件。打下去它不再拷問你了，但它會先停一次，要你確認它打算怎麼驗這東西做對了沒有，跟你想的一不一樣。你點頭，它才開始寫。
回到阿凱那個例子，開發說明的結論是一件很具體的事：真正的修法不是提醒自己「改完班表記得回去重算」，是把「工時」那個要人自己填的欄位整個拿掉，改成從班表直接算出來。要人記得的事，遲早會忘。把它變成不可能填錯，才算修好。
/to-spec 有個前提：你得先被拷問過。它整理的是你們談出來的東西，前面沒談過就直接打它，它沒有東西可以整理，只能自己猜著寫。
第三步：/to-tickets，切成看得出對錯的小塊
說明寫好了，下一個問題馬上來：它是一整包。一整包丟下去做，要等全部做完你才知道對不對，錯了就是整包重來。
/to-tickets 打下去，它會列出一張清單，而且標明每一件卡在誰後面，你才知道哪幾件可以同時開始。
拆到什麼程度算對？每一件做完，你自己打開就看得出來它對不對。以阿凱那個工具來說，「先把整個畫面做完，再來接資料」是壞的拆法，因為畫面做完你什麼都驗不了；「先做一個能新增一筆班、而且存得起來的」才是好的，那一件做完他打開就看得到。
那要拆多細？只要每一件都還維持得住「做完打開就看得出來對不對」，就不用再往下拆。拆得太碎，只是多幾個檔案要互相同步。
第四步：/implement，唯一真的動手的那一步
前面三步一行程式都沒寫。/implement 只做兩件事：先寫測試再寫程式，做完再叫兩個 AI 來抓錯。
先寫測試，白話講就是先把「怎麼算做對了」寫下來，再去做那件事。這樣你不用等到全部做完才知道對不對，每做完一件，馬上有東西告訴你。
至於抓錯，它會同時開兩個 AI：一個只看有沒有照這個專案原本的寫法寫，另一個只看有沒有做到你當初要的。兩個分開看、分開報，不然其中一邊過了，就會把另一邊蓋掉。
四步要在同一個對話視窗跑完
這四步是一環扣一環的：只有第一步可以單獨打，後面三步都要等前面那一步的產出。
也因為這樣，你做同一件事的這四步，要在同一個對話視窗裡從頭跑到尾。中間不要另開新的視窗，也不要叫它把前面談過的內容摘要掉。後面三步都建立在第一步那份思考上，前面的談話一旦不見，它就是在重新猜。
不是每件事都要走完整條
先講一個護欄：改一句文案、換一個按鈕的字，不用走這些，直接叫它改就好。為了用工具而用工具，是在浪費你自己的時間。
真正要分的是三種情況，差別只在你站在主線的哪個位置。
第一種，你已經知道要做什麼，只是有些決定還沒講清楚。比如加一個「收藏文章」的功能，功能你想得到，但「可不可以分類」「別人看不看得到」還沒決定。這時候打 /grill-with-docs，照剛剛那四步走完就好。
第二種，東西壞了，而且你知道正確行為應該是什麼。比如使用者手快點了兩下送出，結果建立了兩張訂單。你不需要想清楚要做什麼，你要的是找出它為什麼壞。這時候打 /diagnosing-bugs，它會繞過整條主線。它的第一個動作是不准你先猜原因，要你先做出一個會對這個問題亮紅燈的東西。因為你先猜，你會找到一個能自圓其說的答案，然後修錯地方。
第三種，你連方向都還不確定。比如你想做一個 AI 客服，但你不知道該先做知識庫、先做草稿回覆、還是先做自動回信。這種情況下打第一步是白費的，它會開始問你細節，而你連要做哪一個都還沒決定。這時候打 /wayfinder，它會先幫你把「該先決定什麼」排出來。方向清楚了，才回到主線的第一步。
記不住也沒關係。有一個指令叫 /ask-matt，你把要做的事講給它聽，它只告訴你該走哪一條、下一個指令打什麼，不會自己動手。
一個延遲爆炸的坑：你以為指令跑了，其實沒有
這些指令分成兩種，差別只有一件事：誰可以叫它。
第一種要你自己打，剛剛那四步都是。它們負責的是指揮，決定接下來走哪一條路。你不打，它就不會動。第二種 AI 可以自己叫，像 /diagnosing-bugs。它們負責的是做法，一件事該怎麼做才對，AI 遇到對的場合會自己去拿來用。
坑就在第一種，而且它是延遲爆炸的。你用講的「幫我想清楚這個」，那個指令根本沒有跑，但它照樣回了你一大套。看起來挺好，你就往下走。直到第二步才發現前面根本沒有東西可以整理。你以為你在第二步，其實你連第一步都還沒開始。
辨認的方法只有一個：打下去，看它的第一個動作對不對。叫它拷問，它就該先反問你，而不是給你一整套方案。對不上就停，重打。
另外，裝完先跑一次 /setup-matt-pocock-skills，不然 /to-spec 跟 /to-tickets 不知道要把東西寫去哪。
為什麼設計成「你不叫它就不動」
「你不打它就不會動」是他刻意設計的。他在說明文件的第一段就寫了為什麼，而且直接點名了三套：GSD、BMAD、Spec-Kit。你不用記這些名字，記住它們的共同點就好：它們想幫你的方式，是把你整條開發流程接管過去。
他反對的理由只有一句：這樣一來，流程本身出錯的時候，那個錯很難解。
注意他在意的是什麼。他不是在比哪一套比較好用，他在意的是出事的時候你查不查得出來，跟我們從第一段就在講的是同一件事。所以他反過來做：每一個都很小、你叫它才動、不合用你自己換得掉。壞了的時候，你知道是哪一個壞的。
那份計畫，從頭到尾沒人檢查
前面那四步，最後都在做同一件事：東西做出來，然後確認做對了。但有一個東西從頭到尾沒有人檢查過，就是那份計畫本身。
計畫一開始就寫錯，後面每一步都會很順利地通過，因為它們檢查的是「有沒有照計畫做」，不是「這個計畫對不對」。而這種錯最貴，你要等到全部做完才看得出來。
你大概有過這種經驗：自己寫的東西，自己校對永遠看不出錯字，別人瞄一眼就指出來。不是你不認真，是你腦袋裡已經有正確的版本，眼睛就自動幫你補上去了。AI 也一樣。寫計畫的那一個，不適合拿來檢查那份計畫。
所以我的做法是找第二個 AI 來挑。一個負責想，另一個負責挑；挑完回第一個定案，才開始動手，做完再換回第一個檢查一遍。我自己用的是 Claude 跟 Codex 這兩家，這一段我做成一個指令叫 /codex-plan-pipeline。哪兩個不是重點，重點是它們不是同一個，兩邊犯錯的方式不一樣，它才看得到你看不到的地方。
挑的時候有一個小設計：那個負責挑的，我不讓它動手改。它看得到全部，但一個字都改不了。還是校對那件事，你請人幫你看稿，你要的是他把有問題的地方圈起來，不是他直接幫你改寫。改寫過的稿子，你反而看不出他原本覺得哪裡有問題。只要它改得動，它就會開始改，然後你會分不清哪些是它挑出來的、哪些是它自己順手加的。
它會來回幾輪，那什麼時候停？不是看輪數，是看它開始挑什麼。前面幾輪它會說「這一整段方向不對」，到後面變成「這句話可以寫得更清楚」。當意見從「做錯了」變成「寫得不夠好」，就可以停了。
還有一條紀律：它反對的東西，你要先試著證明它是錯的。沒有這一步，你會把它每一句話都吸進計畫裡，計畫越改越胖，而且開始自相矛盾。
代價是計畫階段會多吃掉一段時間，而且那段時間你就是在等，很容易手癢。所以小改動不值得，我只在「做錯了要整批重來」的那種改動上才開這一套。
動手做的三種做法，差別在你最怕什麼
講到這裡，「真正動手做」那一步已經出現三種做法了，我怕你混掉，先停下來說清楚。三種做法的差別只有一件事：你這次最怕的是什麼。
第一種，就照原本那樣做。一件一件叫它做，你在旁邊看著。大部分時候這樣就夠了。
第二種，怕方向一開始就錯。那就先讓另一個 AI 挑計畫，挑完你定案，它才動手，做完再換回來檢查。成本是你要在計畫階段多等一段時間。
第三種，方向已經確定了，剩下的是量，而且量大到你不想坐在旁邊。那就寫一份清單讓它自己跑完。
這裡有一個實際的限制要先講：「讓它自己連續跑」這件事，目前只有 Claude Code 做得到。所以我的實際做法是，要人抓錯的時候找兩個 AI，要它自己跑很久的時候用 Claude Code。這不是哪一個比較好，是它們各自能做的事不一樣。
讓它自己跑完一整份清單：/loop
第三種用的不是前面那套東西，是 Claude Code 自己內建的一個功能，叫 /loop。它做的事情很單純：讓它照一份你先寫好的清單，一項一項自己做完，中間不回頭問你。
我用它的理由只有一個：我想讓它連續做很久，而我不想坐在旁邊。
但它有一個前提：中途不能有需要你拍板的事。只要有一項需要你決定，它會替你決定，而且不會停下來問。
我實際下的指令只有一行，裡面一句工作內容都沒有，它只是在點名那份清單要有什麼。清單裡要有三件事，而且要在你按下去之前就寫好：怎麼繼續、怎麼算做完、什麼時候停。這三件事分別對應三種翻車。
第一種，它提早結束。 你沒告訴它「做完一項之後要幹嘛」，它做完覺得告一段落就收工了，清單還有一大半。所以清單要寫繼續的條件：一項做完直接做下一項，不要回頭問我。
第二種，它做完了，但沒有真的做完。 每一項都打了勾，可是沒有人檢查、沒有存檔、也沒有送出去。你看到的是一片綠，東西還躺在原地。所以每一項都要有驗收條件，條件沒過不准打勾，而且要寫成你回來打開看得到的東西，不要只寫「完成」。拿阿凱那個排班表來說，「做好排班畫面」不算驗收條件；「排三個人一週的班，存檔之後重新打開，三個人都還在」才算。還要跟一句：不要為了讓條件過而放寬條件。沒有這句，它會為了把清單跑完自己把標準改鬆，而且它不會告訴你。
第三種，它該停的時候不停。 卡住了就在原地空轉，或者跑到一半開始花錢。所以停止條件要寫在檔案裡：連續三個被跳過就停，需要花錢就停。卡住怎麼處理也要寫：標記跳過、寫一句原因、直接做下一個，不要停在那裡等我。
還有一件小事，但它救過我很多次：每做完一項，就叫它留一個可以回頭的存檔點。因為它是連續跑的，你不在旁邊。等你回來發現第七項做壞了，中間沒有存檔點你只能整包重來；有的話，退回第六項就好。這件事有現成的工具在做，叫 GitHub，你就想成一個幫你保管每一版的地方，每存一次記一筆，之後隨時挑一筆退回去。
我還會多做一步：每做完一項，叫它開一張變更單（在 GitHub 上這叫 PR），把這一項到底改了什麼寫清楚。這樣我回來不用讀程式，看那張單子就知道它做了什麼。
最後一件：事情多的話，我不會只寫一份清單。我會寫成好幾份，第一批、第二批、第三批這樣排下去。跑完第一批我回來看一眼，確認方向沒歪，才讓它跑第二批。理由跟這整篇在講的是同一件事：你想早一點知道自己走錯。一口氣跑完五十項才發現第三項就歪了，那後面四十七項全部白做，而且每一項看起來都好好的。
所以 /loop 省下來的，就是那幾個小時你人不用在。但那幾個小時要真的省到，靠的是清單寫得夠好。沒寫好，你省下的時間會在回來重做的時候全部還回去。
你這禮拜可以做的一件事
今天講的這些拆開看是不同的工具，但它們在回答同一個問題：你打算在哪一刻發現自己走錯了。
回頭看那條路：先被問到講得出來、寫成說明、拆成一件一件、做完驗一次，然後在計畫還只是一份文件的時候就先讓人抓錯，最後讓它自己跑完一整份清單。每一步都在做同一件事，只是把「發現走錯」這件事一路往前挪。
這也是它跟「多一個好用工具」的差別。一個工具幫你把這一步做好；一條會接回來的路，讓你下一步不會踩在錯的上面。而且你不用一次走到底，只做第一步就有用，走到哪裡是你自己決定的。
這套東西是免費開源的，照 GitHub 上的說明裝就好。想簡單一點的話，在 Claude Code 或 Codex 的外掛市集搜「Matt」也找得到。
裝好之後，下次你要動一個做錯了要整批重來的東西之前，第一行打 /grill-with-docs，然後什麼都不要做，讓它問完。這禮拜只做這一件就夠了。
我把 25 支指令什麼時候用哪一支的速查表、我自己那支 /codex-plan-pipeline，還有一份真的跑得動的 Loop 清單範本，都整理放在付費社群《AI 效率革命聯盟》裡，裝起來就能跑。
如果你還在更前面一點的位置，我另外有一個免費社群《AI 效率啟動營》，裡面有我整理好、免費送你的幾套資源包。
常見問題
Matt Pocock 的 skill 要付費嗎？怎麼安裝？
免費，MIT 授權，原始碼公開在 GitHub（github.com/mattpocock/skills），照上面的說明裝即可。想省事的話，在 Claude Code 或 Codex 的外掛市集搜「Matt」也找得到，裝起來是整包約 25 支。裝完務必先跑一次 /setup-matt-pocock-skills，否則 /to-spec 和 /to-tickets 不知道要把產出寫到哪裡。
一定要四個指令全部跑完嗎？
不用。判準是「做錯了要付出多少代價」：改一句文案、換一個按鈕的字，直接叫 AI 改就好，走完整條只是浪費時間。真正值得走完的是「做錯了要整批重來」的那種改動。另外，就算走完整條，只做第一步的 /grill-with-docs 也已經有用，往下走到哪裡是你自己決定的。
為什麼 /to-spec 一定要先被拷問過？
/to-spec 整理的是你跟 AI 在拷問階段談出來的內容。前面沒談過就直接打它，它沒有材料可以整理，只能自己猜著寫，你會拿到一份看起來完整、實際上沒人確認過的規格。這也是這套指令最常見的坑：你用講的「幫我想清楚這個」，那個指令其實根本沒有跑，但 AI 照樣回你一大套，直到第二步才爆開。辨認方法只有一個：打下去看它的第一個動作，叫它拷問就該先反問你。
/loop 只有 Claude Code 有嗎？
「讓 AI 照一份清單連續跑完、中間不回頭問你」這件事，目前只有 Claude Code 做得到，/loop 是它內建的功能，不屬於 Matt Pocock 那套 skill。前面四個指令則是跨工具的，你現在用哪個 AI 工具就裝進哪一個。所以實務上可以分工：要人抓錯的時候找兩個不同的 AI，要它自己跑很久的時候用 Claude Code。
觀看完整影片
關於作者：追日Gucci（Gucci Chang）
全球前三大記憶體廠美光（Micron）大數據工程師出身，IT 產業 20 年，2019 年離開高薪工作全職創業。2014 年起經營自媒體，出過一本投資書，上過《Smart 智富》、《鏡週刊》和非凡新聞的專訪。2024 年起把重心轉到 AI，帶領付費社群《AI 效率革命聯盟》，把 AI 自動化與 AI Agent 接進真實工作流。現在帶著老婆和女兒在東南亞旅居，一邊照常工作、女兒照常上學。
