Wayfinder 漸進式規劃 — 邊界思維實踐¶

來源：思思主播（脈報）對 Matt Pocock /wayfinder 規劃工具的深度解讀影片（2026-08-22，7 分 17 秒）。核心命題：規劃的本質不是「比誰想得遠」，而是依手頭現有資訊劃定決策邊界。本筆記在影片與原文文章之外，補上官方 SKILL.md 第一手資料——影片列出的多個「原文沒回答」的問題，官方文檔其實有答案。

目錄¶

#1. 核心痛點診斷：完美計畫為何走不完
#2. Frontier 設計哲學：把「還不能決定」寫進系統
#3. 系統架構：地圖持久化於 Issue Tracker
#4. 官方文檔補全：影片「原文沒回答」的問題
#5. 批判性視角與未解盲點
#6. 心法轉化：今天就能用的部分
#參考資料

1. 核心痛點診斷：完美計畫為何走不完¶

AI 生成的專案計畫通常「很漂亮」：階段清楚、里程碑明確、每步銜接下一步。但這種計畫最常見的下場是沒有被走完。問題不在寫得不夠細，而在於：計畫裡有一半的決定，在寫下的當下根本還沒有資訊可以下。

第三階段要用哪個方案，得看第一階段做出來長什麼樣
要不要拆成兩個模組，得等真的動手才知道
規劃工具不會說「這題現在不能決定」——它會給你一個答案，因為那是它被要求做的事

骨牌效應流程¶

資訊不足仍硬寫遠期方案
        │
        ▼
所有項目包裝成同等可信的待辦清單
        │
        ▼
照著執行 → 做到第三項才發現前提早就變了
        │
        ▼
整份計畫從那裡開始作廢（前期投入全成沉沒成本）

兩種規劃觀對比¶

維度	傳統/AI 完整路線圖	Frontier 漸進規劃
隱含前提	路線圖價值與完整度成正比	完整度過了資訊邊界就是負債
遠期決策	強行給出答案（硬猜）	標記「等資訊到再決定」
計畫壽命	前提一變整份作廢	邊界隨進度外推，持續有效
失敗模式	假象確定性，執行時骨牌崩塌	留白顯性化，不確定性被管理

最佳實踐¶

✅ 計畫卡住時，先問「是不是資訊還沒到」，而不是懷疑執行力
❌ 不要把「看起來完整」當成計畫品質指標——遠處的細節是猜出來的
❌ 不要讓工具的輸出格式（全部列成待辦）綁架你的決策成熟度判斷

2. Frontier 設計哲學：把「還不能決定」寫進系統¶

/wayfinder 的核心行為是原文的這句：Figure out the frontier of things that can be decided now（找出現在就能決定的事情的邊界）。它直接否定了「路線圖價值與完整度成正比」這個前提。

Frontier 是一條線：

        │  Frontier（決策邊界）           │
        │  ← 可決策區 →        │  待成熟區 →  │
        │                                │
        │  [任務A] 已定案可排程     [方案X?] 等第一階段結果  │
        │  [任務B] 資訊充足        [拆模組?] 等動手後才知道  │
        │                                │
        ─────── 第一階段完成，資訊解鎖 ────────
        │                                │
        │  [任務A][任務B][方案X ✓]   [新邊界外的留白...] │
        │           ▲ 邊界外推一格

線內（可決策區）：當前資訊充分、能立即定案並排程執行
線外（待成熟區）：明確標記「等前置資訊明確後再決定」——「暫不決定」被正式納入系統狀態，而非遺忘或硬猜
動態推移：第一階段做完 → 資訊到了 → 邊界線往外移一格 → 原本不能決定的事進入可決定範圍

這也解釋了工具定位为何是「最有野心的專案」：野心愈大，遠處的資訊愈少，硬規劃出來的部分作廢得愈快。計畫的邊界不是你的野心決定的，是你手上的資訊決定的。

線內外處理對比¶

面向	線內任務	線外決策
資訊狀態	充分	依賴前期產出，尚不足
系統動作	照常排程執行	標記「等 X 出來再決定」
外觀呈現	可信的待辦	顯性的留白（不被偽裝成待辦）
處理時機	現在	邊界外推後自動進入

判斷決策樹¶

這個決定現在能下嗎？
  │
  ├─ 不依賴任何未完成的產出 → 線內：直接定案排程
  │
  ├─ 依賴前期結果（方案選擇、架構取捨）
  │     ├─ 能用小原型/研究提前拿到資訊 → 先排「做原型」這個動作
  │     └─ 拿不到 → 線外：標記「等 X 產出後再定案」
  │
  └─ 分不清 → 預設線外（寧可留白，不要硬猜）

3. 系統架構：地圖持久化於 Issue Tracker¶

第四項行為「在你選定的 issue tracker 裡維護一張地圖」看起來像整合功能，解讀者認為它是立場，而且是 Frontier 能外推的前提：計畫得先有一個能被反覆更新的地方，「線往外移」才有東西可以移。

  對話框裡的計畫                Issue Tracker 裡的地圖
  ─────────────────           ──────────────────────
  讀者：AI + 當下的你            讀者：所有人（含未來的你）
  關掉視窗 → 狀態散落            持久狀態（Persistent State）
  下週接手 → 重讀整段對話         隨時可查「進度停在哪」
  一次性靜態文件                 會長大的地圖（持續迭代）

官方架構（SKILL.md 補充）¶

依官方文檔，這張「地圖」有明確的實體結構：

Map = issue tracker 上的單一 issue，標籤 wayfinder:map，是規範工件（canonical artifact）
Ticket = map 的子 issue，每張是一個「決策票」（decision ticket）——問題的解決本身就是一個決策，不是待執行的建置切片
Map 是索引不是儲存：決策只活在自己的 ticket 裡，map 只寫 gist + 連結，不重述
工作方式：一次處理一張決策票，直到路線清晰——「沒有剩下任何需要在動手前決定的事」

安裝與使用¶

# 安裝（免費）
npx skills add mattpocock/skills

# 之後在對話中調用 /wayfinder，給它一個目的地（destination）
# 命名目的地是製圖的第一步，它決定後面每張 ticket 的形狀

指標	數值
安裝量	328.6K
倉庫	mattpocock/skills（220.3K stars）
首次收錄	2026-07

4. 官方文檔補全：影片「原文沒回答」的問題¶

影片誠實交代了 X 貼文沒回答的問題（且作者後續還有一整串說明未讀）。本筆記用官方 SKILL.md 交叉比對，部分問題已有第一手答案：

影片的質疑（原文沒回答）	官方 SKILL.md 的答案
它怎麼判斷哪些事「現在可以決定」？	未給演算法。但機制以「決策票」為單位：ticket 是「解決即決策」的問題，處理順序由依賴與阻斷關係表達（blocking 關係記在 tracker 裡）——本質是 agent 與人協作判斷，不是固定分類器
跟 issue tracker 怎麼同步？	不「同步」——地圖本身就住在 issue tracker 裡（單一 map issue + 子 ticket），無雙寫問題。實體位置因 tracker 而異，見各 tracker 文檔的 "Wayfinding operations" 節
產出長什麼樣？	一張不斷更新的 map issue（決策索引）+ 一組決策票；完成條件是「路線清晰，沒有事要在動手前決定」
一人作業要先架 tracker 的成本？	有當地降級：未提供 tracker 時預設用 local-markdown tracker（本地 markdown 檔案），不一定需要 GitHub/Linear
環境要在哪裝？	標準 skills CLI：`npx skills add mattpocock/skills`，之後需跑 `/setup-matt-pocock-skills` 綁定 tracker

官方文檔揭示的三個設計原則（影片未提）¶

Plan, don't do（規劃而非執行）：每張 ticket 解決的是決策，map 完成即交棒。「想直接動手做」的衝動，通常正是抵達地圖邊緣、該交棒的信號
Refer by name（以名稱引用）：對人類的敘述一律用 ticket 名稱而非編號——#42, #43, #44 的牆無法閱讀
目的地決定一切：目的地可以是規格、鎖定的決策、或就地完成的變更；地圖是 domain-agnostic 的（工程、課程內容都行）——這部分回答了影片問的「以外是哪一種以外」

5. 批判性視角與未解盲點¶

解讀者對設計本身同意，分歧點只有一個：宣稱的強度對不對得起證據的強度。

Matt Pocock 原句：「It's revolutionised how I plan coding work - and I'm even using it outside of coding.」（它徹底改變了我規劃 coding 工作的方式）
用了「徹底改變」等級的詞，但貼文中：無前後對比、無具體專案例子、沒說清「以外」是哪種以外
作者立場判讀：東西做出來還免費送出去，不是騙人的姿態；但「作者說它改變了他的工作方式」≠「它會改變你的工作方式」，中間隔著整段你自己去試的距離

證據強度檢查清單¶

✅ 已驗證：工具存在、免費、開源（mattpocock/skills）、安裝量 328.6K、有完整 SKILL.md 定義行為邊界
✅ 已驗證：地圖持久化機制有官方文檔支撐（map issue + 決策票 + tracker 操作規範）
⚠️ 未驗證：frontier 判斷的實際品質（依賴 agent 判斷力，無量化機制）
⚠️ 未驗證：「徹底改變工作方式」的效果宣稱（無對照數據，僅作者自述）
❌ 不存在：第三方評測（所有說法均來自作者本人的 X 貼文）

判斷決策樹：該不該引入這套工具¶

你的專案形態是？
  │
  ├─ 大型、多階段、遠期決策依賴前期產出
  │     ├─ 已有 GitHub Issues/Linear 使用習慣 → 值得裝來試（零遷移成本）
  │     └─ 沒有 tracker 習慣 → 先用當地 markdown tracker 模式試 frontier 心法
  │
  ├─ 小型、單人、一兩週可完成
  │     └─ 不必裝工具，直接用 §6 的二分法手動實踐
  │
  └─ 執行內容大於決策內容（重工複製型工作）
        └─ 幫助有限——wayfinder 解的是「決策密度」問題

6. 心法轉化：今天就能用的部分¶

就算不裝工具，這套判斷直接拿走：規劃卡住往往不是執行力不足，而是當前資訊尚未成熟。

三步實踐法¶

1. 二分法梳理    2. 顯性化留白         3. 持久化地圖
─────────────   ─────────────────   ─────────────
列出所有決策     線外項目不編排細節     進度寫進可長期
    │           直接標註               追蹤的看板/清單
    ├─→ 資訊充足 → 定案排程    │
    └─→ 缺前置結果 ──────────→ 「等 X 產出後再定案」

二分法梳理決策：把待辦拆成「當下資訊充足可定案」與「需等前期結果才能判斷」兩組
正式標記留白：第二組不強行編排細節，明確寫上「待 X 產出後再定案」，把不確定性顯性化
建立持久化進度點：重要規劃不留在 AI 對話介面，落地到可長期追蹤狀態的工具裡持續迭代

留白 vs 拖延¶

	拖延	留白
定義	知道答案卻不做決定	誠實記錄資訊還沒到
對計畫的影響	讓計畫爛掉	讓計畫活下來
判別方式	資訊其實已充足	存在明確的前置依賴

最佳實踐¶

✅ 把「我還沒有足夠的資訊」當成合法的規劃狀態，正式寫進計畫
✅ 遠期部分只寫「需要被回答的問題」，不寫「猜出來的答案」
❌ 不要逼自己把計畫補完——那是把猜測包裝成承諾
❌ 不要把計畫只存在 AI 對話框裡——關掉視窗它就死了

Wayfinder 漸進式規劃 — 邊界思維實踐¶

目錄¶

1. 核心痛點診斷：完美計畫為何走不完¶

骨牌效應流程¶

兩種規劃觀對比¶

最佳實踐¶

2. Frontier 設計哲學：把「還不能決定」寫進系統¶

線內外處理對比¶

判斷決策樹¶

3. 系統架構：地圖持久化於 Issue Tracker¶

官方架構（SKILL.md 補充）¶

安裝與使用¶

4. 官方文檔補全：影片「原文沒回答」的問題¶

官方文檔揭示的三個設計原則（影片未提）¶

5. 批判性視角與未解盲點¶

證據強度檢查清單¶

判斷決策樹：該不該引入這套工具¶

6. 心法轉化：今天就能用的部分¶

三步實踐法¶

留白 vs 拖延¶

最佳實踐¶

參考資料¶

相關筆記¶