Scout

競品調查（Scout）

目的：找出設計背後的假設，然後檢驗那個假設在我們的情境成不成立。

不是看別人長什麼樣。描述性的功能對照表沒有辦法拿來做決定，因為它不解釋為什麼。有假設、有適用條件、有失效情境的結論才能被反駁，也才能綁回自家規格檢驗。

該不該用這個 skill：手上有規格或需求，而且有幾種做法還沒決定 → 用。想找版面或視覺靈感 → 不用，那是另一種活動。想知道某產品某個畫面長怎樣 → 那是查資料，直接搜就好。

步驟

1. 讀材料、定位參考對象 讀規格（Notion / SPEC.md / ticket）與使用者提供的任何截圖或連結。截圖裡是哪個產品要當場認出來並說出口——使用者往往不知道自己貼的是什麼，而那張圖的角色會決定整個搜尋方向。

2. 前置提問——不問就搜是最大的浪費 搜錯方向的成本遠高於問四題的成本。用 AskUserQuestion 一次問完，每題都要有一個「這正是我想看競品怎麼解」的選項，讓使用者可以把問題丟回給研究：

   • 你提供的這個參考，角色是什麼？（照這個做／只是例子去找更好的／我想知道這樣好不好）——這三種會導向完全不同的搜尋。
   • 規格裡哪一處還沒定、希望這份研究來回答？沒有對象的研究會變成通論。
   • 使用者是誰、不是誰？「不是誰」一句話刪掉一整類不相關的競品。
   • 平台範圍與硬限制？（桌機／手機／兩者、數量上限、後端能不能配合）

   什麼時候改跑 /interview：如果回答顯示模糊在更深的層次——使用者自己也說不清楚要解決誰的問題、或這個需求其實是好幾個該拆開的子專案、或四題裡有三題答「不確定」——停下來，先跑 /interview 把骨架層釐清，不要帶著模糊去搜。帶著模糊搜出來的報告，看起來很豐富但沒有一條結論能用。

3. 平行開工：裸推導 ＋ 多角度搜尋 ＋ 現有程式碼盤點

   裸推導（搜尋開跑前先寫，這是防抄的地基）：先假裝世界上沒有任何競品可看，從我們的規格、硬限制、使用者要完成的工作，寫下三到五行「我們自己會怎麼推導這個問題」。這份第一性原理底稿之後不可刪——競品素材只用來修正這份推導（哪個假設錯了、哪個限制沒想到），不是取代它。先搜再推導會被案例錨定，整份報告就會從「別人做了什麼」出發而不是從「我們的問題」出發。

   搜尋：同一個需求至少拆成四到六個角度分別搜，不要把需求整句丟進去搜一次。通用的角度類型——

   • 入口形態（這個能力從哪裡被叫出來）
   • 狀態呈現（開啟中／進行中怎麼被看見）
   • 長時間或非同步行為（要跑很久的東西怎麼處理）
   • 喚醒與輸入方式（斜線、提及、快捷鍵）
   • 過程與結果的顯示（系統做了什麼怎麼回報）
   • 窄螢幕降級（手機上先犧牲什麼）
   • 權限與設定來源（誰決定使用者能用什麼）

   工具分工（需要 Mobbin MCP connector；未安裝時改用網路搜尋與產品官網、評測文章的截圖，其餘步驟不變）：單一畫面用 search_screens，多步驟流程用 search_flows，網站區塊用 search_sections。桌機與手機分開搜，不要假設手機是桌機的縮小版。明確要求找互相矛盾的案例——全部一致代表只搜到了慣例，慣例告訴你什麼常見，不告訴你為什麼。

   程式碼盤點（有 repo 就做，這一步最容易被漏掉）：同時派一個 Explore agent 盤點現有程式碼，要求輸出「已經有 ／ 全新」的對照表。這一步常常把結論從「要做一整套」改成「多數零件已經存在」，直接改變範圍評估。沒有它，報告會停在「別人怎麼做」而到不了「我們該做多少」。

4. 建立判斷框架——先於寫報告 收集完素材，先產出三樣東西，再開始寫任何一節：

   • 一句話的問題：這些產品到底在替使用者解決什麼？（例如「不是設定問題，是期待校準問題」）
   • 心智模型：這個題目下使用者可能持有的二到四種想像，以及它們的分歧軸（例如「誰決定」與「作用範圍」）。畫成一張圖。
   • 旅程時刻：把體驗切成幾個時刻，每個時刻標出使用者心裡的問題，以及我們現在答不答得出來。

   ⚠️ 心智模型每次都要重新推導。 上一次的那組是從上一個題目長出來的，換題目就換一組。把舊的套上去是這個 skill 最容易壞掉的地方。

5. 把案例放進框架 每一個做法固定三行標註：

   • 它假設使用者腦中是怎麼想的
   • 它在旅程的哪一步發言
   • 假設落空時會怎麼壞

   設計沒有絕對的優劣。一個做法只有在「它假設的心智模型」與「我們使用者真正持有的」對得上時才成立。每個結論都要附「什麼條件下該換另一種做法」。

   案例是假設的證據，不是可選的菜單：報告中不允許「跟著 X 做」式的結論，只允許「X 賭了假設 P；P 在我們的情境成立／不成立，證據是⋯」。假設檢驗通過，才把該做法納入方向；檢驗不了的，標「未驗證」。

6. 反例盤（交付前必做，不要等使用者要求） 挑出自己最強、最像定論的那個結論，主動找反證：有沒有產品刻意用相反的做法？他們怎麼處理我列出的問題？找不到反例要說明找過哪些方向，不能因為找不到就當作結論被證實。報告裡最脆弱的地方，通常正是那個「大家都這樣做所以應該是對的」的段落，而它讀起來最有說服力。

   同時做兩項檢查：

   • 觀察 vs 推論要分開標。Mobbin 給的是靜態截圖，從一張圖推論動態或時序行為（「輸入框在跑的時候被鎖住」）其實是推測。競品分析是「單張穩態截圖不能推論時序行為」這條規則最容易被違反的場合，因為所有素材都是靜態的。
   • 可反駁性。隨機挑一段結論，問「要拿什麼事實才能推翻它」。答不出來，那段就沒有內容，重寫。

7. 產出報告 單一 HTML 檔存在專案 docs/，骨架用 assets/report-skeleton.html（四種區塊：框架區、案例卡、方向卡、邊界清單）。骨架只定樣式，章節結構由題目決定，不要照抄上一份的節數。

   報告一律內嵌留言層＋頁尾「複製全部意見」出口：現成片段 assets/html-comment-layer.html，照片段開頭的三步驟嵌入。讀者讀報告時的段落級反饋是這份研究最有價值的回收，沒有留言欄等於丟掉。

   截圖規則：

   • 一律下載到同名的 -assets/ 資料夾。來源網址是短效的，直接引用會爛掉。
   • 每張圖可點回原始來源。
   • 圖要大到看得清楚介面文字；兩欄以上就開始犧牲細節，寧可版面加寬。

   必備內容：判斷框架先行、每節先講結論、三個方向從「小到不好意思」到最完整並附 pros/cons 與建議——每張方向卡的第一行必須是「它賭的假設＋該假設在我們情境的檢驗結果」（引用我們的規格或使用者證據），競品案例只能從第二行起作為佐證；「某產品這樣做」不構成理由、邊界情況清單（數量上限／截斷／空值／權限不足／中途取消／狀態衝突）、現有程式碼對照表、以及一段搜尋紀錄（用了哪些角度、掃過多少畫面、淘汰了什麼方向）。

8. 交付前自查

   • 有沒有互相矛盾的案例？全部一致代表搜得太窄。
   • 有幾個「但是」「除非」「什麼情況下不適用」？一個都沒有代表只收集沒判斷。
   • 每個做法都有三行標註嗎？
   • 反例盤做了嗎？
   • 字眼掃描只是症狀檢查：出現「抄」「照搬」「值得抄」，代表那一段的推理鏈斷了，不是換個詞就好。每個建議方向要能回答三題——賭什麼假設？憑什麼相信它在我們的情境成立？什麼證據會推翻它？答不出來的方向刪掉，或明標「未驗證」降級。
   • 裸推導底稿還在報告裡嗎？競品修正了它哪幾行要說清楚——底稿完全沒被修正，代表搜尋沒帶回資訊；底稿被整份丟掉，代表被案例錨定了。
   • 截圖都在本機、都點得回原始來源、文字看得清楚嗎？
   • 用瀏覽器實際開過嗎？（截圖驗證時先確認捲動位置在頂端或改用整頁截圖，否則會截到內容下方的空白區而誤判頁面壞掉）

9. 交棒 報告交付後，使用者要選方向。選定之後：

   • 要寫規格 → /kickoff（這份報告的方向比較與邊界清單，正好是 kickoff 第四步與未知清單的材料）
   • 邊界清單裡有需要使用者拍板的 → /interview

原則

• 先問再搜。 四題的成本遠低於搜錯方向。
• 找矛盾不找共識。 互相衝突的案例才有資訊量，一致的案例只是慣例。
• 心智模型每次重新推導。 舊的那組是上一個題目的產物。
• 靜態素材不能推論動態行為。 推論就標成推論。
• 結論要能被反駁。 不能被反駁的句子等於沒說。
• 競品是假設的證據庫，不是解法菜單。 結論從「我們的問題＋通過檢驗的假設」推導出來；競品只作為佐證引用，不作為理由。
• 描述別人不是目的。 每一段都要能回答「所以我們該怎麼做、為什麼」。