scout

/scout —— 我究竟要去哪，以及如何到達那裡？

你有一個問題或想法，但誠實的狀態是你還不知道如何處理它。不是「三種方法中選哪一種」——你還無法看透彼岸，以至於無法提出三種方法。此集合中的其他所有技能都假設目標已經存在。這個技能是去尋找目標的。

這項工作的任務是勘察地形，然後選擇路線——而不是直接衝向目的地，也不是開始建造第一眼看起來可以建的東西。

這不是什麼——以便你正確調用：

• 不是 grill-me——那是針對你已有的計劃進行訪談，以深度優先的方式走一條決策樹。這是在計劃存在之前進行，並且特意採用廣度優先。當 scout 結束時，grill-me 是合理的下一步。
• 不是 explain——那是用來映射已存在的程式碼。這用來映射尚未存在的工作。
• 不是 root-cause——那是針對有已知症狀的損壞事物。如果某個東西出錯，先使用那個；如果修復不明顯，再對回應進行 scout。
• 不是 validate-plan / ship-check——那些是用來評判計劃和差異的。Scout 在它們的上游運行，並產出它們要評判的內容。

克制閘門——先閱讀。 失敗的模式是製造一段旅程。如果初始的掃視顯示你已經可以陳述目的地和到達的步驟，就說出來並停止：「這不需要偵察——以下是計劃，開始執行。」大多數問題都是這樣的。在清晰的路徑上多做儀式是純粹的成本。同樣地，如果你主動使用了這個技能，而不是使用者輸入 /scout，請在開始前確認——未經請求的二十個問題訪談是個糟糕的驚喜。

各階段

1. 命名目的地——在任何其他問題之前

詢問完成的樣貌，並將其壓縮成一兩行。可能是鎖定一個決策、要移交的規格、原地完成的遷移、或一個端到端可運作的功能。不同的目的地會產生完全不同的路線，所以這是最優先解決的，且永遠不做假設。

目的地固定了範圍——以下每個問題都以此為衡量標準。如果使用者還無法命名，那就是首先要處理的事，在命名之前，其他什麼都不開始。

2. 展開——廣度優先，並抵制回答的誘惑

掃描從這裡到目的地之間的整個空間，收集所有的開放問題。暫時不要解決任何一個。立即回答第一個問題的衝動正是這個階段要克服的：你注意到的第一個問題很少是決定整體形狀的那個，過早回答它意味著非常仔細地規劃錯誤的事情。

要廣泛，不要深入。目標是浮現你原本不知道存在的問題。

可以查詢的事實；需要詢問的決策。 如果某件事可以查證——例如 schema、呼叫者、真實資料、函式庫的文件、程式碼目前的實際行為——就去查證，不要在問題上耗費唇舌。只有真正的決策才需要詢問使用者。

3. 分類為三個分類

分類	測試方法	你要做的事
銳利	你現在可以精確地陳述這個問題	處理它（第 4 階段）
模糊	你感覺有個問題存在，但還無法表達清楚	寫下一行粗略的描述，然後擱置
超出範圍	它在目的地之外	記錄下來；它不會再回來

銳利/模糊的測試是你是否能陳述它，而不是是否能回答它。 一個有困難或未知答案的問題仍然是銳利的，如果你能精確地表述它——那些往往是最重要的問題。

超出範圍使用一個不同的測試——範圍，而不是銳利度。某件事可以非常銳利但仍然超出範圍，因為它在目的地之外。明確地排除它並說明原因；它只會在目的地本身移動時才會回來，而那將是一次全新的 scout。

然後將銳利的問題按最能解除阻塞的順序排序——能夠消除最多其他問題的那個答案優先。

4. 逐個解決

一次問一個問題並等待。每個問題都附上你推薦的答案——但這是推薦，決定權在使用者手中。永遠不要代替他們做決定，也永遠不要批量提問；一次提出五個問題會讓人不知所措，並得到一個敷衍的回答。

每次回答後，更新分類：

• 它是否將模糊的問題銳化成一個真實、可陳述的問題？升級它。
• 它是否消滅了不再重要的問題？刪除它們。
• 它是否改變了目的地？大聲說出來，並根據新的目的地重新檢查其他分類——一切都是以舊的界線為衡量的。

不要為了讓自己看起來有效率而將模糊的問題預先切割成假問題。模糊是一個路標，不是待辦事項清單。

5. 當路徑清晰時停止

完成意味著：沒有遺留的銳利問題，而剩餘的模糊問題確實可以推遲或超出範圍。最後總結目的地、達成的決策以及具體的下一步。

然後移交——不要開始建構。 Scout 產出的是路線，而不是可交付成果。轉到計劃模式（或如果計劃從中產生則轉到 /validate-plan），然後再實作。如果你發現自己在 scout 階段內撰寫正式程式碼，你已經超出了這個技能的範圍。

唯一的例外是拋棄式原型——當一個問題確實無法在紙上解決時（例如「這個狀態模型感覺對嗎」、「這應該長什麼樣子」），建立一個能回答問題的最小粗糙版本，看一看它，保留答案並丟棄程式碼。

跨越對話階段——只有當真正需要時

預設為單一階段，不儲存檔案。大多數 scout 都符合這個範圍，為一個二十分鐘後就結束的對話寫一個檔案只是徒增雜物。

僅在以下其中一種情況成立時升級到 /handover-save：

• 對話時間變長到你可能會失去脈絡，
• 使用者想要停下來稍後再繼續，
• 某個問題被對話外的因素阻塞（其他人的回覆、權限申請、需先收集的資料）。

交接文件會承載目的地和三個分類。用 /handover-resume 恢復，它會在繼續之前重新同步偏移。跨越階段在這裡是一個逃生艙口，而不是設計目標。

輸出格式

在地圖發生實質變化時顯示它——在目的地命名後、展開後、以及當某個答案重新調整了分類時。不是每次轉折都顯示。

## 偵察：<想法，一行>

**目的地：** <完成的樣貌——以下所有內容都以這個為衡量標準>

**已決定**
- <問題> → <答案>

**開放——銳利**
1. <精確陳述的問題>   ← 正在處理這個
2. <...>

**仍然模糊**
- <粗略的一行描述> — 一旦 <X> 確定後就會變得銳利

**超出範圍**
- <被排除的內容> — <為何它在目的地之外>

結束時包含：目的地、按順序排列的決策，以及單一的下一個步驟。

護欄

• 廣度先於深度。 在你看清整個空間之前就回答第一個問題，正是這個技能要防止的失敗。
• 去查詢，不要問問題。 一個你原本可以用 grep 回答的問題，是在浪費使用者的回合和他們的耐心。
• 一次一個問題，然後等待。 每次都推薦一個答案；永遠不要代替他們決定。
• 銳利度 ≠ 可回答性。 模糊測試是「我能陳述它」，而不是「我能回答它」。
• 模糊不是待辦事項。 讓它保持鬆散。預先將其切割成任務，會創造出下一個答案可能刪除的工作。
• 超出範圍是範圍判斷，不是一個步驟。 它放在自己的分類中，永遠不會進入決策列表。
• 目的地可以移動——移動時要宣布。 默默地重新瞄準會使之前做出的所有判斷失效。
• 不要建構。 輸出的是決策，而不是可交付成果。拋棄式原型是唯一的例外。
• 預設不留檔案。 僅在工作確實超出當前階段時才使用 /handover-save。
• 克制閘門。 「這裡沒有模糊地帶——你已經知道如何處理這個」是一個真實且有價值的結果。永遠不要為了證明使用這個技能的正當性而發明開放問題。

---

以目的地為優先的框架、廣度優先的展開、陳述它 vs 回答它的模糊測試，以及範圍 vs 銳利度的區分，改編自 Matt Pocock 的 wayfinder（github.com/mattpocock/skills）。其問題追蹤地圖、子任務機制以及一任務一階段的規則被刻意移除——這個集合透過 /handover-save 跨階段持續存在。