browse

browse 技能總覽

browse 是用來做什麼的

browse 技能是一個快速的無頭瀏覽器工具，適合 QA、dogfooding 與瀏覽器自動化。當你需要打開頁面、與頁面互動、驗證狀態、比較操作前後差異，或擷取截圖與元素狀態檢查這類證據時，browse 特別合適。如果你的工作是「在瀏覽器裡測這個流程，然後告訴我發生了什麼」，browse 就是對的選擇。

誰應該安裝 browse

如果你經常驗證網頁、Demo、表單、響應式版面、上傳、對話框，或部署檢查，就應該安裝 browse。對於必須用截圖或狀態斷言來證明 UI 行為、而不是只靠一般提示詞的 agent，browse 特別有用。相較之下，它對純後端任務或單純讀頁內容的需求就沒那麼適合。

browse 的差異在哪裡

browse 技能建立在真實瀏覽器執行之上，而不只是文字式的頁面檢視。這個 repo 顯示它支援命令路由、瀏覽器管理、CDP 橋接、網路擷取、cookie 處理，以及帶註解的視覺檢查。這代表 browse 的定位是帶證據的實務型瀏覽器自動化，而不是一個輕量級的「幫我摘要這個網站」工具。

如何使用 browse 技能

正確安裝 browse

請使用技能文件中顯示的安裝路徑，或你的 skill manager 提供的 add 指令，接著確認這個技能已能在本機 skill 目錄中被找到。repo 內包含像 bin/find-browse 這類輔助 shim，表示 browse 的設計是讓它能從 aware of workspace 的安裝位置被定位與呼叫。如果找不到 binary，第一個要修的通常是重新跑技能設定／建置流程，而不是改寫提示詞。

給 browse 明確任務，不要只丟模糊目標

好的 browse 使用方式，會先把瀏覽器工作講清楚：URL、動作、預期結果，以及你要回傳什麼證據。好的輸入像是：「打開登入頁，提交有效憑證，確認重新導向到 /dashboard，並回傳截圖與任何 console 或 network 錯誤。」像「幫我測這個網站」這種說法太模糊，會讓路由判斷與執行重點都不夠明確。

先讀這些檔案

在做安裝與使用決策時，先看 SKILL.md，再查看 PLAN-snapshot-dropdown-interactive.md，了解已知的工作流程限制；接著看 SKILL.md.tmpl，理解這個技能是怎麼產生的；另外也要看 bin/find-browse 與 bin/remote-slug，了解路徑與 repo 解析行為。如果你是在評估瀏覽器自動化是否適合你的情境，也建議掃過 src/browser-manager.ts、src/cdp-bridge.ts、src/browser-skill-commands.ts，確認這個技能實際能執行哪些動作。

把 browse 放進工作流程裡使用

可靠的 browse 工作流程通常是：先定義你要的頁面狀態，執行瀏覽器動作，驗證輸出，然後再處理下一個限制條件。舉例來說，先明確指定響應式寬度、表單輸入或預期的 DOM 變化，讓 browse 能一次檢查完。這樣可以減少來回溝通，也讓第一次執行比泛泛的提示詞更有價值。

browse 技能 FAQ

browse 只能用來截圖嗎？

不是。截圖只是其中一種輸出。這個技能也設計來做導覽、互動、狀態驗證、響應式檢查、表單測試、上傳，以及 Bug 證據蒐集。如果你的真正需求是「證明這個瀏覽器行為」，browse 比只會截圖的工具更完整。

browse 跟一般提示詞有什麼不同？

一般提示詞是要 agent 去推理一個瀏覽器任務；browse 技能則提供 agent 一條專門為瀏覽器設計的執行路徑，包括命令路由和瀏覽器狀態檢查。通常這代表更少猜測、更高可重現性，以及在流程失敗時更清楚的證據。

browse 對新手友善嗎？

是，只要你能把瀏覽器任務描述清楚。新手最適合的做法，是提供一個 URL、一個動作、一個預期結果，以及一個證據需求。如果你本來就會寫測試案例，通常第一次就能有效使用 browse。

什麼情況下不該用 browse？

如果你只需要靜態內容擷取、repo 檢視，或單純的程式設計回答，就不要用 browse。當你無法指定瀏覽器目標，或任務根本不需要真實渲染頁面時，它也不是好選擇。這些情況下，直接用一般 agent 提示詞會更簡單。

如何提升 browse 技能

提供更強的瀏覽器輸入

browse 最好的結果，通常來自把頁面、使用者動作、成功條件，以及你要回傳的產物都講清楚的輸入。例子像是：「在價格頁切換成年繳，確認總價更新，並擷取最終狀態的截圖。」這比「檢查價格」更好，因為它消除了對成功定義的歧義。

注意常見失敗模式

browse 最常見的失敗是規格不完整：少了 URL、少了狀態，或少了預期結果。第二種常見問題是只要求視覺證明，卻沒說頁面哪一部分最重要。如果任務包含表單、選單、對話框或動態內容，請明確寫出來；這些細節會實質影響 browse 的使用方式。

第一次執行後要迭代

如果第一次結果已經接近，但還不完整，就用下一輪提示詞把差異講精準：視窗大小不對、漏掉元素、狀態過期，或缺少網路證據。browse 的價值最大化，通常來自每一輪都進一步縮小不確定性。請用輸出結果補充限制條件，而不是只是把同一個請求再說一次。

將 browse 調整為 Browser Automation

如果是用在 browser automation，請加入具體測試條件：測試帳號類型、裝置尺寸、語言地區，以及 cookie 或登入狀態是否重要。如果你是在驗證 Bug，也要附上重現步驟與預期／實際差異。這會讓 browse 更像一個瀏覽器自動化助理，而不是一般 QA 記錄員，通常也能在第一輪就產出更好的證據。