在 GitHub 上，有個 2026 年 2 月 3 日才建立的專案，截至 2026 年 7 月 28 日已累積超過 19.1 萬顆星，平均每天新增約 1,100 顆；同一時間，它在 skills.sh 平台的累計安裝次數已達約 1,170 萬。
這個專案的核心不是一套應用程式，而是一組以 Markdown 為主的 AI 工作指令；儲存庫另含安裝、維護與自動化所需的腳本及設定檔。最先爆紅的那個skill，最初只有短短約四句話，功能是 「叫AI反過來拷問你」。
這個專案叫 skills，作者是 TypeScript 教學大神 Matt Pocock。他把自己與 AI 協作的整套工作流開源。本文將拆解這套系統怎麼運作，更重要的是，就算你完全不寫程式，也有可以直接複製帶走的中文prompt可以運用。
Matt Pocock 是誰？為什麼工程師搶著被 AI「拷問」
Matt Pocock 的出身相當非典型。他原本是聲音教練（voice coach），半路轉行成工程師，曾是開源狀態管理工具 XState 的核心團隊成員，也擔任過網站部署平台 Vercel 的開發者布道師。但真正讓他打開知名度的是 TypeScript 教學：他打造的 Total TypeScript 課程，被許多工程師視為這門語言的標準教材。目前他全職投入 AI 工程教育，並經營 AI Hero。
而為什麼此刻值得學Pocock的工作方式？Matt Pocock 在影片中的說法很傳神：「你的指尖隨時有一支可以立刻部署、水準中上的工程師艦隊，但詭異的是，這些工程師沒有記憶，不記得自己做過什麼。」
這是因為AI 時代的瓶頸不是產能，而是控制：你需要極度嚴格、定義清楚的流程，這些 AI 代理才會做出真正有用的東西。
Matt Pocock的Github如下：
https://github.com/mattpocock/skills
爆紅起點 grill-me：把決策權從 AI 手上搶回來
整條工作流的起點，是讓這個專案一炮而紅的 grill-me。它的功能是：在動工之前，強制 AI 反過來拷問你，一題一題問，問到你把計畫想清楚為止。
Matt Pocock 表示，這個 skill 最初只有約四句話，後來的完整版也不過一小段文字：
1. 決策樹建模
把使用者的計畫或設計視為一棵決策樹，系統性地走訪每一個分支與邊界情況（Edge Cases），確保沒有任何被隱含假設的死角。
2. 一次只問一個問題
嚴禁一次拋出大量問題清單。每次提問後必須暫停並等待使用者回應，避免造成使用者的認知負荷。
3. 事實靠查閱，決策才發問
嚴格區分「事實（Facts）」與「決策（Decisions）」。只要是能透過閱讀程式碼庫或環境檔案找到答案的事實，AI 必須先自行讀取，絕不向使用者提問。
4. 提供建議解答
拋出問題時，必須同時附上 AI 自身的建議答案與理由，讓使用者是以「審查提案」的方式做決策，而不是面對空白提示詞。
5. 確認後才動工
在所有決策樹分支尚未確認並達成共識之前，絕不提前撰寫程式碼或執行修改。
Matt Pocock 說，「決策樹」的靈感來自《人月神話》作者布魯克斯（Frederick P. Brooks）的另一本著作《The Design of Design》：所謂設計，就是走完一棵樹的每個分枝，把選擇一個個定下來。
為什麼要這樣做？因為寫程式其實是連續做出幾百個微觀決定：防呆怎麼做？斷線怎麼辦？極端資料怎麼處理？如果把模糊想法直接交給 AI，等於把這些決定一併外包。grill-me 讓 AI 沿著決策樹挖出盲點，但拍板定案仍由人負責。
這個 skill 的用途也早就超出寫程式。Matt Pocock 分享過一個故事：有位使用者要為過世的母親寫悼詞，就用 grill-me 讓 AI 訪問自己，挖出一個個關於母親的故事。
若認為上段元祖Prompt工程味太濃，你也可以直接把下面這段prompt貼進任何 AI 對話，用在企劃、報告、簡報，任何需要想清楚的事：
針對我接下來提出的計畫，毫不留情地訪問我，直到我們達成共識為止。
沿著決策樹一層一層往下走，把每個決定之間的依賴關係逐一解開。
每個問題都要附上你建議的答案。
一次只問一題，等我回答後再問下一題；一次丟出多個問題只會讓人混亂。
如果某件「事實」你自己查得到（搜尋、讀檔案），就自己查，不要問我；但所有「決策」都必須由我拍板。
在我確認我們達成共識之前，不准動手執行任何東西。
如果想把這段拷問用在季報、簡報或換工作這類需要先想清楚的決定上，也可以參考怎麼把 grill-me 裝成 Claude 技能，用「/」隨時叫出來拷問自己，不必每次重貼提示詞。
完全體工作流：五個站點，每一站都是可拆的樂高
grill-me 只是起手式。整套系統的主幹道，是一條從「想法」到「成品」的裝配線，共五站。
第一站：拷問出共識（grill-with-docs）
寫程式的場景用的是 grill-me 的進化版 grill-with-docs，它會在拷問的同時，順手把兩種文件寫下來。
一是「名詞表」：讓你、AI、程式碼三方說同一種語言，這在經典方法論「領域驅動設計」（Domain-Driven Design，DDD）中稱為通用語言（ubiquitous language）。
二是「架構決策紀錄」（ADR）：只記那些難以回頭、沒有背景說明會讓後人意外的決定。效果是 AI 越用越懂你。有使用者回饋，用了四、五次之後，「AI 神奇地跟我腦中還沒說出口的想法對齊了」。
第二站：把共識寫成規格（to-spec）
拷問出來的共識，一關掉對話就會蒸發，所以要立刻寫成一份規格書。Matt Pocock 在這個 skill 裡訂下一條嚴格原則：規格書原則上不放具體檔案路徑與程式碼片段，因為它們很快就會過期；只有 prototype 產生的片段能比文字更精確保存決策時，才節錄必要部分。過期的實作細節容易誤導 AI，讓規格與程式碼逐漸脫節。
第三站：把規格拆成任務（to-tickets）
這站藏著一個重要方法論：垂直切片（vertical slice）。讓 AI 自己拆任務，它天生喜歡按技術架構分工：先建完所有資料庫、再寫完所有邏輯、最後才做畫面。最可怕的盲點是，在最後一步之前，你完全沒辦法測試任何東西。
因此，to-tickets 強制 AI 改用「使用者功能」拆任務：先做完整的「會員登入」（含資料庫、邏輯、畫面），再做完整的「加入購物車」。每做完一小塊就能立刻驗收，互不相依的任務還能同時發包給多個 AI 平行處理。
第四站：動工，並用 TDD 防作弊（implement）
實作站的核心是「測試驅動開發」（TDD）：先把檢查對錯的測試寫死，再寫功能。為什麼順序這麼重要？因為 AI 骨子裡是個作弊仔。如果讓它先寫功能再補測試，萬一功能寫錯，它為了交差，會直接生出一個「配合錯誤答案」的假測試，讓一切看起來都過關。先寫測試（此時必定亮紅燈），再寫程式讓紅燈變綠燈，才能鎖死 AI 亂寫交差的空間。
第五站：換一顆乾淨的腦袋做審查（code-review）
程式寫完，流程會派出兩個平行子代理，分別檢查程式是否符合專案規範，以及成果是否忠實實現原始規格，避免兩種判斷互相干擾。這份審查也不是空泛的「幫我看看有沒有 bug」，而是把軟體工程名著《重構》（Refactoring）作者 Martin Fowler 歸納的約 12 種「爛 code 症狀」當成檢查基線；專案自身規範優先，每種症狀都是需要判斷的警訊，不代表必然違規。
例如「散彈槍手術」（Shotgun Surgery）：只想改一個按鈕的顏色，卻得動十幾個檔案；又如「資料泥團」（Data Clumps），像是姓名、電話、地址三個欄位永遠一起出現，就該打包成一個「聯絡人」物件。
Wayfinder：當計畫大到一次對話裝不下
前面五站適合一次對話能處理完的工作；Wayfinder 面對的，則是規模大到必須拆成多次對話的計畫。2026 年 7 月 8 日發布的 1.1 版，新增了 Matt Pocock 自稱「什麼都拿它來規劃」的 Wayfinder。
AI 的工作記憶（context window）有限，對話越長，表現越容易失去穩定。Wayfinder 會在 GitHub Issues 等議題追蹤系統建立一張總覽地圖，再把待解決事項拆成彼此相依的子票。子票分為 research（研究）、grilling（拷問）、prototype（原型）與 task（雜務）四種。
每次開工只挑一張子票，用全新對話解決，再把結論記回地圖。每張票都控制在一次對話能處理的範圍，既減少管理 AI 記憶的負擔，也讓全團隊看得到進度並隨時接手。Matt Pocock 甚至用它規劃自己的下一門課程。
底層哲學：越聰明的 AI，越需要老派基本功
拆完整條生產線，你可能已經發現：這套系統幾乎沒有任何新發明。 決策樹出自《人月神話》作者布魯克斯 2010 年的著作《The Design of Design》；通用語言來自 2003 年的《領域驅動設計》；12 種爛 code 症狀來自 1999 年初版的《重構》；TDD 更是老派工程師的日常。
這正是 Matt Pocock 在 AI Engineer 大會演講的核心主張：「軟體基本功比以往任何時候都重要。」他親自試過「只改規格、不看程式碼」的 specs-to-code 流派，結果每重跑一次，產出的程式碼就爛一點，「這只是換了個名字的 vibe coding」。
他的結論是一記警鐘：很多人說 AI 讓程式碼變便宜了，恰恰相反，爛程式碼從未像現在這麼昂貴。因為 codebase 一爛，AI 在裡面就只會繼續生產垃圾，你反而拿不到 AI 的紅利。
那什麼樣的架構能讓 AI 發揮全力？Matt Pocock 借用史丹佛大學教授 John Ousterhout 提出的「深模組」（deep module）概念：把複雜的細節藏在裡面，只留下一個簡單好用的入口。
就像使用微波爐時，你只要按幾個按鈕，不需要了解裡面的電路如何運作。對 AI 來說也是如此，入口越清楚，需要同時理解的東西就越少。所以如果一項功能散落在許多檔案裡，改一個地方又會牽動好幾處，AI 就更容易漏看或改錯。
簡單說，好的架構能幫 AI 縮小問題範圍，讓它把力氣用在真正需要處理的地方。
還有一層更值得一般工作者偷學的功夫：Matt Pocock 怎麼把 skill 寫得這麼短？專案裡有一個 skill 叫 writing-great-skills，藏著他的三條心法。
一是修剪（pruning）：在 AI 面前每多一句廢話，它就多一分分心的可能，連「不說它也知道」的指令都要刪。
二是指引詞：大量使用深植在 AI 訓練資料裡的經典術語，對 AI 說一句「Data Clumps」，等於說了一百字的解釋。
三是完成標準：給 AI 一個明確的終點，它才不會發散。換言之，與其寫一千字的完美 prompt，不如用對三個關鍵詞。
一般工作者能帶走什麼？
回頭看整套系統，Matt Pocock 真正開源的不是幾個檔案，而是一個示範：**如何用軟體工程基本功，約束 AI 這個充滿隨機性的黑盒子。
如果你不寫程式，這套系統至少有三件事可以立刻帶走。
第一，讓 AI 當拷問者，而不是代筆者。重要的企劃、提案、決定，先貼上前面那段拷問 prompt，被 AI 問過一輪再動工。
第二，跟 AI 建立共同語言。長期合作的專案，請 AI 順手維護一份名詞表：「把我們對話中用到的專有名詞和定義整理成名詞表，之後的討論都用這些詞。」你會發現彼此的溝通越來越省力。
第三，把重複的流程寫成自己的 skill。任何你做過三次以上的工作（寫週報、整理會議紀錄、審預算），都值得寫成一段短短的 SOP 存起來。
若想把「拷問後的共識」落地成行動，也可以直接用這段：
我們已經達成共識。請依序完成三件事：
1. 用一頁篇幅寫下這個計畫的「規格」：要解決什麼問題、成功長什麼樣子、明確排除哪些範圍。只寫目標與行為，不寫執行細節。
2. 把規格拆成可以獨立完成、獨立驗收的小任務，每個任務完成後都要能單獨檢驗成果，並標出任務之間的先後依賴。
3. 附上一份驗收 checklist，讓我每完成一項就能勾掉一項。
先讓 AI 拷問你，再動工；先建立共同語言，再談效率；先定好完成標準，再交給 AI 執行。這就是 Matt Pocock 這套工作流所傳達的事：AI 越強，你的專業和流程就越值錢。
延伸閱讀：
別再給AI寫範例！Anthropic揭Claude 5世代新規，CLAUDE.md與Skills怎麼寫才聰明？
