【2026 最新】Wayfinder 怎麼驗收？6 關跨 Session A/B 評估教學

你把一個模糊、跨好幾個 Session 的專案交給 AI：第一輪談好權限，第二輪改了資料模型，第三輪卻又拿舊前提繼續拆任務。Wayfinder 想處理的，正是這種「對話還在前進，決策已經失真」的風險。

但多一張 map、十幾張 ticket，不等於真的少漏決策。本文專為第一次接觸 Wayfinder 的讀者寫：不假裝 AlphaLab 已跑出勝負，而是提供一套可照做的 A/B 驗收法，帶你比較單一路線與 Wayfinder 路線的決策保存、過期前提、拆票膨脹與 map-to-spec 完整度。

先說結論：Wayfinder Decision Map 不是記憶體

Wayfinder 比較像一張外接航海圖：map 只保留目的地、已決定事項、未解迷霧與範圍邊界；每個細節則由一張 ticket 單獨承載。本文用「決策地圖」幫新手理解，但這不是現行官方名稱；作者已把前身 decision-mapping 改名為 Wayfinder，因為研究、原型與任務票不全是決策。它能讓新 Session 找回航向，卻不會自動保證新決策已傳到所有舊 ticket。

請先記住這個錨點：可靠的 Decision Map ＝決策可追溯 × 前提會傳播 × 規模能收斂。三項任何一項趨近於零，ticket 再多也只是更昂貴的筆記。

Wayfinder 到底把什麼搬出對話框？

截至 2026 年 8 月 22 日，我們檢查的 Wayfinder SKILL.md 把工作拆成三層：

1. Map 是低解析度索引。一張標記為 wayfinder:map 的 issue，固定放 Destination、Notes、Decisions so far、Not yet specified 與 Out of scope；決策細節留在各自 ticket，map 只寫摘要與連結。
2. Ticket 是單一決策容器。研究、原型、追問與任務各有用途；預設是「規劃，不實作」，只有為了解除決策阻塞才開 task。
3. Frontier 是下一步。只有仍開啟、沒有 blocker、也沒人認領的子 ticket 才能進 frontier。Session 先認領一張，再工作、回報、關閉，最後更新 map 指標。

官方流程把「畫地圖」與「走地圖」刻意分開。Charting Session 建 map、建票、串 blockers、派研究後就停止；Working Session 每次只解一張 ticket；迷霧清完才執行 /to-spec #<map_issue>，再把 spec 轉成實作 tickets。官方長篇指南也直言，若工作本來一個 Session 就能完成，Wayfinder 會更慢、更重；這時可先讀 Specification-first 收斂方法，直接把需求問清楚再寫 spec。

為什麼不能用「ticket 有沒有關完」判定成功？

關票只代表 tracker 的狀態改了，不代表前提沒有變舊。三則原始使用者回報剛好顯示不同失真路徑，但它們都是個案，不能當成整體失敗率：

• Issue #476 的一個多 Session 專案出現兩個 Session 幾乎同時解同一張票，之後整張 map 的舊版本覆蓋新加入的一行決策。
• Issue #540 回報 charting 完成後仍繼續解票，跳過需要人確認的原型／追問流程。
• Issue #828 的回報中，一項新決策推翻 event log 概念後，四張未關 ticket 仍保留舊前提。

這些例子支持的是「該測什麼」，不是「Wayfinder 一定會怎樣」。截至同日，我們檢查的 官方 Wayfinder 指南、SKILL.md 與 Latent Space 專訪 提供流程、案例與現場回報，但沒有一組可直接拿來宣稱勝負的受控 A/B 指標。因此，下面教你自己建立可驗收的證據。

Wayfinder Decision Map 六關 A/B 驗收法

第 1 關：先凍結同一份題目與環境

痛點：如果兩組拿到不同需求、模型或工具權限，最後差異就不能歸因於工作流。做法：把題目、repo commit、agent／模型、可用工具、時間或 token 預算、Session 上限寫進一份 manifest；兩組都從乾淨副本開始。

A 組只允許一般 Session 先規劃再產出 spec；B 組依官方方式安裝 npx skills@latest add mattpocock/skills --skill=wayfinder，執行 /wayfinder 建圖，之後每張決策票換一個 fresh Session，最後才執行 /to-spec。記錄實際套件版本、Wayfinder SKILL.md commit 與 hash，避免日後無法比對。

第 2 關：先寫 Gold Manifest，不要事後改答案

痛點：讀到輸出才挑評分點，很容易偏袒看起來比較漂亮的一組。做法：在開跑前列出必須保存的需求、風險、相依關係與刻意保留的未知；每項給穩定 ID，例如 R-01、D-03。評分者只看匿名化後的 Spec A／Spec B，不看是哪條路線。

第 3 關：中途注入一個會推翻前提的決策

痛點：只處理一路不變的需求，測不到跨 Session 最危險的「舊前提復活」。做法：預先安排一個變更點，例如原本允許事件日誌，到了第 3 個 Session 改成「敏感內容不得進 event log」。檢查新決策是否更新 map、相關開票、blocker 與最終 spec，而不是只在一則 comment 出現。

第 4 關：用六項指標評分，不只看完成時間

1. 決策保存率：最終 spec 正確保留的 Gold 決策數 ÷ Gold 決策總數。
2. 過期前提數：map、未關 ticket 與 spec 中，仍引用已被推翻前提的項目數；每個可回查 ticket ID。
3. 來源覆蓋率：spec 裡可追到決策 ticket 或明確證據的主張 ÷ 需要追溯的主張總數。
4. 拆票膨脹率：建立過的 ticket 總數 ÷ 最後真正不同的決策數。它衡量 tracker 長得多快，不預設越低越好。
5. Map-to-spec 完整度：spec 正確納入的已驗證決策 ÷ map 清空前已驗證決策總數。
6. 人類維護成本：記錄重複追問、衝突解票、人工救援、總 Session、時間與 token；不要硬湊成一個漂亮分數。

門檻要在開跑前寫。例如你的專案可以要求「過期前提為 0、所有安全決策都能追溯」，並為拆票膨脹與人工救援設預算。這些是專案自己的驗收條件，不是 Wayfinder 的通用基準。

第 5 關：把停止規則寫成硬閘門

痛點：Agent 很容易把「幫我釐清」理解成「順手做完」。做法：把下列規則放進每個 Session 的入口檢查；任一條失敗，就停止並記錄，不讓它靠多做工作掩蓋流程破口：

• Charting 只建圖、拆票、連 blockers、派研究，完成後必須停止。
• 每個 Working Session 開始前重新抓取 map 與目標 ticket，只能認領一張。
• 需要人判斷的 grilling／prototype 不得由 Agent 自行代答；未拿到答案就保持開票。
• 解票後先把新前提傳播到受影響的未關 ticket，再追加 map 指標；禁止整張舊 map 覆寫。
• 任何 task 若開始修改 production code，而它不是解決決策所需的最小原型，就判定越界。
• map 尚有未解 fog 或 spec 無法追到已決策項目時，不得進入 /to-tickets。

第 6 關：匿名審查 spec，再看成本

痛點：Wayfinder 產出的 tracker 看起來更有秩序，容易讓人把「文件多」誤認成「資訊完整」。做法：先讓不知組別的審查者只評 Spec A／B，再打開 trace 看每個決策如何抵達 spec，最後才比較時間與票數。先比正確性，再比成本。

完整走一次：多租戶資料匯出中心

假設你要規劃一個 SaaS 資料匯出中心。起始 brief 只有一句：「企業管理員能匯出組織資料，完成後通知使用者。」Gold Manifest 先藏好六個必查點：角色權限、資料駐留、保留期限、稽核證據、速率限制、失敗重試；另標記「通知內容與管道」仍未知，且整個 map 階段不得改 production code。

1. Session 1：A 組直接追問並草擬 spec；B 組只建 Destination、fog 與 decision tickets，串起「資料駐留先於儲存設計」等 blockers，然後停止。
2. Session 2：兩組都拿到新答案：匯出檔 24 小時失效，完成通知只可透露狀態，不可附敏感檔名。B 組要把答案寫回決策票與 map 指標。
3. Session 3：注入反轉：安全團隊禁止把匯出內容與檔名寫入通用 event log。此時檢查既有稽核、通知、失敗重試 tickets 是否同步改前提。
4. 收斂：A 組交 spec；B 組在 fog 清空後執行 /to-spec。把兩份 spec 去除組別標記，逐項對照 Gold Manifest，再查 trace 與成本。

如果 B 組保留了新決策，卻有兩張舊 ticket 仍要求 event log 保存檔名，就不能只因最終 spec 寫對而算全過：這代表下一個拿票實作的 Session 仍可能被舊前提帶偏。反過來，如果 A 組同樣完整、成本更低，這個題目就沒有證明需要 Wayfinder。

決策層：什麼時候該用 Wayfinder？

• 用 Wayfinder：目的地大致知道，但關鍵決策互相阻塞；工作確定跨多個 Session／Agent；人類需要在途中回答問題；決策來源日後必須回查。
• 先用 grilling 或 specification-first：需求模糊，但一個 Session 內能問完、沒有大規模並行，也不需要長期 tracker。可搭配 AGENTS.md 規則與 gate 教學 把不能越過的邊界寫進 repo。
• 直接做：範圍小、決策已完成、驗收條件明確。多一層 map 只會增加同步成本。

若你的核心問題是如何讓 fresh Session 接棒，可延伸看 AI Agent Harness 的 fresh-context handoff；若你更在意跨輪次留下可檢查的中間表示，Huzzah 持久化 pseudocode 提供另一種做法。Wayfinder 的差異，是把「尚未決定什麼」也變成可排程的 tracker 狀態。

四個常見坑與修正方式

1. Ticket 爆炸：每個小念頭都開票，frontier 很快失去訊號。修正方式是讓 ticket 對應「需要一個決定的問題」，純背景放 Notes，重複問題合併。
2. 整張 map 覆寫：某個 Session 以舊副本重寫 issue，蓋掉他人剛加的決策。修正方式是更新前重抓最新版，只做窄幅 append／patch，並以 ticket comment 保存完整歷程。
3. 決策沒有傳播：關掉原始票，卻沒搜尋依賴舊前提的開票。修正方式是在 resolution 模板加入「affected open tickets」，逐張更新或標記 obsolete。
4. 把規劃偷換成實作：Agent 認為做出 production 功能比較快。修正方式是預先定義 prototype 的刪除條件與輸出範圍；越界即停，不用「結果看起來能跑」抵銷流程違規。

這也說明為什麼 AI Agent 可觀測性 很重要：沒有 Session、ticket、claim 與 artifact 的對應紀錄，事後只能猜它在哪一步遺失前提。

Wayfinder Decision Map 常見問題

1. Wayfinder 能保證跨 Session 不失憶嗎？

不能保證。它把狀態移到外部 tracker，降低只依賴聊天上下文的風險；但認領衝突、舊 map 覆寫與決策未傳播仍要靠流程 gate 偵測。

2. Ticket 越多，規劃就越完整嗎？

不一定。票數只代表拆分量。應同時看不同決策數、過期票、重複問題與 map-to-spec 完整度。

3. 一張 ticket 可以解多個決策嗎？

這次評估先不要。單票單決策比較容易追溯、認領與判斷 blocker；若答案會一起成立或一起推翻，才合併並清楚寫出邊界。

4. Map 清空後就能開始寫程式嗎？

還差一個轉換。依目前官方流程，先以 /to-spec 把已解決決策收斂成規格，驗收完整度，再以 /to-tickets 產生可實作工作。

5. A/B 一定要用相同模型嗎？

若要比較工作流，就要固定。模型、工具、repo、提示與預算都應一致；否則你測到的可能是模型差異。

6. 可以讓多個 Agent 同時解票嗎？

可以並行獨立 frontier，但要先認領。共享 blocker 或需要同一位人類回答的票，先序列化，並在更新前重抓 tracker 狀態。

7. 哪個指標應優先保留？

過期前提數。最終 spec 即使看起來正確，只要開票仍保留被推翻的安全或架構前提，下一個實作 Session 就可能走錯。

8. 新手第一次該測多大？

從 6～10 個關鍵決策的題目開始。規模要足以跨 Session、包含一次前提反轉，又要小到你能人工讀完所有 ticket 與兩份 spec。

給新手的 5 個重點

1. Map 是索引，不是所有細節的倉庫。
2. 先固定題目與 Gold Manifest，再開始比較。
3. 刻意注入一次決策反轉，才測得到前提傳播。
4. 先看決策正確性與 trace，再比較時間、token 與票數。
5. 如果單一 Session 已能完整收斂，就不必為了形式使用 Wayfinder。

想把這套驗收法擴展成完整 AI Agent 開發流程，可到 AI Evals 評測教學 補上資料集、評分器與回歸測試，再從 AlphaLab 線上課程 建立可重複的實作能力。