Onepage/ agent workflow
Matt Pocock · YouTube Live
/wayfinder 示範：先替 AI Agent 找路，再讓它開始寫程式
當工作比一個 agent session 更大、目的地仍被迷霧遮住時，最缺的不是一份更長的 implementation plan，而是一張能把未知拆成決策問題的共享地圖。
Published: 2026-07-13Video ID: 251hsWgoTPMSource: Matt Pocock
01 / 適用時機
工作太大，路徑未明
Wayfinder 處理的不是一眼就能寫成 spec 的小功能，而是跨多次 session、你知道目標輪廓卻尚不知道如何抵達的探索型工作。
02 / 主要產物
決策地圖，不是交付物
每一張 ticket 應回答一個要釐清的問題，而不是切出一段程式。它們共同描述哪些假設已確認、哪些問題仍阻塞前進。
03 / 結束條件
不再有待決定的事
地圖完成的標誌不是完成了某個介面或 PR，而是通往目標的必要決策都已解開，團隊可以據此進入規格與實作。
Key signals
這場 live demo 想解決的四個問題
Scope
multi-session
將無法在單次對話裝下的探索，留成持續可讀的工作地圖。
Unit
decision
每張 ticket 針對一個要確認的問題，而非一段預設的實作切片。
State
shared map
把發現、阻塞與下一個 frontier 放到 repo 的 issue tracker 中保存。
Guardrail
plan ≠ build
先縮小不確定性，再派發建置工作，避免 agent 在錯的假設上高速前進。
Method
把「做什麼」之前的霧，變成可排隊處理的問題
01
從目標與未知開始，而不是假裝已有答案
一個大任務常混著架構選擇、資料邊界、既有系統限制與產品取捨。Wayfinder 要先承認這些未解事項，將它們寫成可被驗證的決策問題。
02
用 ticket 連起依賴與阻塞關係
不是所有問題都能同時回答。地圖會呈現哪些探索可平行、哪一項結論會解鎖下一項，讓 agent 與人都能看見目前最值得推進的 frontier。
03
一項一項消除不確定性
調查、讀 code、做小實驗或和利害關係人確認，都只為結清某個決策。結論回寫後，地圖更新；直到它不再需要靠猜測連接目標與實作。
Practical reading
怎麼判斷你的任務需要 wayfinding
需求很大，但暫時寫不出可信的 spec這不是失敗，而是訊號：先把「還不知道什麼」顯性化，比立刻要求 agent 產生大計畫更有價值。
探索會跨越多次工作階段聊天紀錄不該是唯一狀態。把地圖放在問題追蹤系統中，讓下次 session 能從已驗證的結論接續。
多個問題有明確的前後依賴先決定資料來源與邊界，才談 UI 或服務切分；地圖能避免團隊把後段工作錯當成第一步。
已經知道怎麼做的小任務不需要過度流程化。若問題清楚、範圍小、驗收可寫，直接進入 spec 或實作通常更快。
Demo reading
把影片當成一個 agent 工作流的分層
Wayfinder 管理方向，不搶走實作責任它處理「往哪裡走、還缺哪些決策」；真正的 build 仍應由對應的 implementation workflow 承接。
Issue tracker 是跨 session 的記憶體把決策、子問題、阻塞與 frontier 外化，能讓人與 agent 在長期工作中共用同一份可查證狀態。
把 ticket 寫成問題，避免過早鎖定方案「資料應從何處取得？」比「建立某某 service」更能保留探索空間，也更容易判斷何時真的已找到答案。
先完成決策，才讓速度有意義AI 可以很快地實作錯的假設。Wayfinding 是在速度提升後，替方向與可回溯性補上的一層控制。
References