為什麼 AI 專案一變大就失控？
Matt Pocock 最近用一套 AI 規劃工具在自家花園蓋辦公室：委託場勘、找廠商、把要決定的事一項項排出來。這套工具叫 /wayfinder，這意味著，這個 Skills 不只能用來做關於軟體的事情，它的本質是一個由 AI 生成的決策系統，蓋房子只是它可以拿來進行的任務之一。
Matt Pocock 曾任職於 Vercel，現在已轉為全職教 AI 工程，經營教學站 AI Hero；他開源的 mattpocock/skills 專案截至 2026 年 8 月 4 日累積約 20.2 萬顆星。/wayfinder 原本要解決的是 AI 寫程式的一個老問題。
你有一個很大的想法，比如「我要在應用裡加一整組新功能」。一般做法有兩種：整包丟給 AI 讓它開工，或者自己先切小塊、一塊塊餵。
Matt 在影片裡形容第二種的下場：你全程都在管 token、盡量不踩出模型的「聰明區間」，然後走到某個你答不出來的問題前面，就卡在霧裡了。
/wayfinder 的做法是同一個模糊念頭進來，先不動工，讓 AI 把「現在還不能決定的事」全部攤成一張地圖。他說這建立在軟體基本功上，是他「在 AI 之前當一個真正的開發者時」學到的規劃方法。
這套方法為什麼有效？
它針對的正是 AI 寫程式最常出事的環節：在你還沒決定的事情上先動手。等你發現方向不對，它已經照著錯的假設寫完三個檔案。
官方文件用三個概念把這件事變成可管理的：終點（destination）要最先命名，因為終點決定了每張票長什麼樣；**霧（fog of war）**是你已經預感到、但還講不清楚的決策；**前緣（frontier）**是現在就能處理的票，定義很嚴格：開著的、沒被其他票卡住的、還沒有人認領的。
解掉一張票，前緣就往前推一格，霧也跟著散掉一塊。
還有一條原則直接寫在規格檔裡：Plan, don't do。票以解決決策為主，預設不生產交付物。但規格明寫例外：Notes 區塊可以把執行工作納進地圖，原型票會做出粗略的東西讓人有反應，可能是大綱、粗稿或程式框架，雜務票則直接去完成卡住決策的前置作業。
地圖長什麼樣？
地圖是一張貼上 wayfinder:map 標籤的 issue，上面固定五塊：終點（Destination）用一兩行寫清楚、已決定的事（Decisions so far）只放一句摘要加連結、還沒講清楚的事（Not yet specified）就是前面說的霧，另外兩塊放領域背景與你的偏好（Notes），以及刻意排除的工作與理由（Out of scope）。
換句話說，地圖只是索引，決策內容都留在各自的票裡。
每個決策各自一張子票，上面寫著要決定什麼、屬於哪一型、誰認領，以及它卡在哪張票後面。四種票型分工如下：
| 票型 | 要真人參與嗎 | 這張票在做什麼 |
|---|---|---|
| 研究（research） | 不用 | 交給子 agent 平行去查外部事實，查完回報 |
| 原型（prototype） | 要 | 做出粗略的東西讓人有反應：大綱、粗稿、程式框架或介面 |
| 拷問（grilling） | 要 | 用對話把某個實作細節或方向逼清楚 |
| 雜務（task） | 兩者皆可 | 現實世界的前置作業，例如申請帳號、開通資源、搬資料 |
需要真人參與的那兩種票，規格明訂 agent 不得代替人回答。原型票也是這套流程不會變成紙上作業的原因：前期規劃再多，都要靠做出來的粗胚換真實回饋。
實際怎麼跑一輪？
Matt 在 7 月 30 日發布的影片裡示範的案例，是替自家應用加一組指令面板功能（圖示挑選器、跨圖搜尋、複製元件）。動線是這樣：
先講終點。 他叫出 /wayfinder 並描述想要什麼，它先探了一遍專案，接著用拷問 skill 反問他「完成長什麼樣、要不要一份規格書」，並主動建議產出規格書。
第一次只畫地圖。 這一輪開出 7 張票，但當下只有 3 張能動：圖示名稱從哪來、元件怎麼儲存（元件儲存結構）、面板資訊架構怎麼排。其餘要等前面的決策定了才解得開。官方流程寫明畫完地圖就停，不在同一輪繼續手動解票，但研究票是例外，它會在這時就派出子 agent 平行去查。
一票一場對話。 走某張票的方式，是開一場新對話、再叫一次 /wayfinder 並帶上票的名稱。比如要解剛剛三張能動票裡的「元件儲存結構」，官方文件沒有規定寫法，Matt 影片裡的做法是這樣：
/wayfinder 元件儲存結構（註：就是開出票的名稱）
規格要求用票名、不要用編號。官方成功指標寫得很白：除了研究票可以交給子 agent 平行跑，一場 session 最多解一張票。
解完寫回地圖。 答案以留言形式留在票上、關票，主地圖只補一行摘要與連結。原本在霧裡、現在夠清楚的問題，這時升級成新的票。
最後收成。 地圖走完後，在同一場對話裡打 /to-spec，它不吃參數，直接把對話中的地圖合成一份規格書（Matt 說他那份初稿長到超過 GitHub 的字數上限）。接著用 /to-tickets 切成可實作的票，這個可以另外帶上規格書的編號或網址。
規格書裡每個決策都連回原始的票，AI 之後有疑問可以回去看當時的討論。
怎麼裝？兩條路徑選一條
官方 README 講得很直接：兩種安裝方式代表兩種哲學，選一條就好，兩個都裝會讓每個 skill 出現兩次。
動手前先確認兩件事。走 skills.sh 那條路要先有 Node.js，npx 是它附帶的指令，沒裝就會直接報錯。之後如果選 GitHub 或 GitLab 存放 issue，要先裝好並登入 gh 或 glab；不想處理這些就選本機 Markdown。
Claude Code 使用者走官方 plugin，等於訂閱制，檔案是唯讀的、作者更新就自動更新：
claude plugins install mattpocock-skills
Codex 或其他 agent 使用者，以及想自己改內容的人，走 skills.sh 安裝器：
npx skills@latest add mattpocock/skills
這條路把 skill 當普通檔案寫進你的專案，你可以隨意改，代價是不會自動更新，要自己跑 npx skills update。安裝時會讓你勾選要裝哪些 skill，官方特別提醒務必勾上 setup-matt-pocock-skills。
裝完之後，每個專案跑一次 /setup-matt-pocock-skills，它會問你要把 issue 放在哪裡。內建三個選項：GitHub（透過 gh 指令）、GitLab（透過 glab 指令）、本機 Markdown（issue 變成專案裡 .scratch/ 底下的檔案）。想用 Jira、Linear 這類工具就選第四個選項，用一段話描述你的流程。如果你也裝了 triage skill，它會多問一句要不要保留預設的分類標籤。
要強調的是，/wayfinder 理想狀態需要一個支援卡關關係的 issue tracker，但沒有也能跑，它會退回本機 Markdown 地圖。所以不必為了試它先去辦一套 Jira。
這條路只需要一個資料夾：開一個新的空資料夾、在裡面啟動 agent 就能跑，地圖會變成 .scratch/ 底下的檔案，不必真的是一個程式專案。它也不會自己跳出來接手，要你自己打 /wayfinder。
哪些情境適合用，哪些不必？
適合的條件很明確：工作量大過一場對話，而且你只有大概方向、中間的路還看不清楚。Matt 自己的用法橫跨工程與非工程，除了功能開發，他也拿它規劃線上課程與蓋花園辦公室。地圖不綁定領域，這是它對沒有軟體背景的人也成立的原因。
不必用它的判準是他自己講的：如果這件事你在一場對話裡就規劃得完、路你已經知道，就別畫地圖，直接做。 官方文件也寫，工作已經清楚就直接用 /to-spec 或 /to-tickets。
有一個前提要先有心理準備：它產出的是決策，成品要等後面的實作票；原型票與拷問票還要你本人在場。省下的力氣在後面的重工，前期時間反而要多花。
規劃的價值從來不是把每一步都想清楚，而是先認出你現在還不能決定什麼。
資料來源：Matt Pocock「/wayfinder: Nothing is too big to plan anymore」影片、wayfinder SKILL.md、wayfinder 官方文件、setup-matt-pocock-skills SKILL.md、mattpocock/skills README、Matt Pocock 個人網站、AI Hero
本文初稿為AI編撰，整理．編輯/ 李先泰
