瀏覽器自動化工具清單裡，一半是新面孔：挑工具之前，先想清楚你要機器做什麼

2026年9月30日，掘金作者「狂師」發布了一篇整理二十款 Web 瀏覽器自動化工具的長文。文章本身是工具清單，但真正值得留意的變化寫在開頭：兩年前挑自動化工具，最後多半在 Playwright 和 Selenium 兩派之間二選一；現在打開任何一份清單，超過一半是帶 AI 特性的新產品，來搶位置的包括騰訊、微軟、亞馬遜，其中騰訊六月底釋出的 BrowserSkill，三個月就累積到七千多個 star。

這個現象對寫測試、寫爬蟲、做營運自動化的人都適用，值得把脈絡拆開來看。

舊框架沒有退場，它們變成了地基

先看清單裡的六個傳統框架。文章給出的排序訊息很明確：Playwright 是整份清單裡被依賴最多的一個，微軟出品，star 數超過九萬六千，三大瀏覽器引擎全支援，自動等待、失敗回放、腳本錄製都內建。Selenium 則靠 W3C WebDriver 標準和最完整的語言支援守住存量市場，配合 Grid 可以把用例分發到幾十臺機器上跑相容測試。

值得注意的是，這些框架的角色已經變了。作者點出一個關鍵結構：後面十幾款 AI 工具，一半以上是建立在傳統框架之上的。browser-use 和亞馬遜的 Nova Act 包著 Playwright，Notte 的 patchright 是 Playwright 的分支，Stagehand 直接建在 Playwright 上。換句話說，AI 工具沒有取代舊框架，它們在舊框架外面加了一層「聽得懂人話」的殼。

打個比方，Playwright 像是廚房裡那套基本功扎實的爐具鍋具，新出現的 AI 工具則是請了一位會聽指令的廚師。你不用再自己掌握火候，但廚師底下用的還是同一套爐子。

用法變了：從寫選擇器，到下指令

文章把這次的斷層講得很直白。以前的框架是給人寫腳本用的，每一步點擊、每次輸入都要寫成程式碼，選擇器一寫死，頁面改版腳本就掛。現在的 AI 工具反過來：一句自然語言說出目的，模型自己看頁面、自己找按鈕，文案改了也認得。

對日常工作的影響在這裡。如果你的團隊維護過一批 UI 自動化測試，大概經歷過那種「改一個按鈕文字，三十條用例一起紅」的夜晚。AI 工具承諾的正是把這種脆斷的依賴拿掉。這也和企業選才的變化互相呼應，攜程把 AI Coding 納入校招筆試的訊號說明，會指揮 AI 產出程式碼，正在變成工程師的基礎能力而不是加分項。

Playwright 本身也順著這條路在長。作者提醒它已經不是單一框架，而是一套工具集：Library 給寫腳本的人，Test 給跑用例的人，MCP 和 CLI 則是專門為 Cursor、Claude、Copilot 這類 agent 準備的介面。同一套地基，開始為人類和模型兩種使用者各開一扇門。

選型之前先問的問題

清單式文章容易讓人陷入「全都想要」的焦慮，但把二十款工具攤開後，實際的選擇邏輯反而變單純了。文章裡隱含的判斷流程是這樣的：

寫正式的測試用例，要可重跑、可審計、失敗原因清楚，傳統框架仍是主流答案，新專案選 Playwright 風險最低。做爬蟲、截圖、生成 PDF 這類一次性任務，Puppeteer 的輕量和低記憶體佔用是強項。要讓 agent 替你操作瀏覽器，才需要考慮 browser-use、Stagehand 這批新工具，而且選它們時該理解底下包的還是 Playwright。

還有一個更根本的問題：AI 工具的輸出不穩定時，你能不能退回腳本模式除錯。自然語言指令的除錯體驗目前沒有統一答案，這是清單文章沒有展開、但實際採用前必須自己驗證的部分。這與透過 MCP Tunnel 把工作搬進 Chat 模式是同一類問題：繞路的架構省了力氣，但你得先看懂那條路怎麼走。

工具熱潮的另一面

一個工具三個月衝到七千 star，速度確實快，但 star 數反映的是關注度，不是生產環境的成熟度。這篇文章列出的是市面上存在哪些選擇，至於每款工具在長期維護、穩定性、團隊協作上的表現，還需要時間和實際專案驗證。舊框架十幾年累積的文件、問答和接手成本優勢，短期內不會被稀釋掉。

比較務實的結論是：把這份清單當地圖用，不當購物清單用。傳統框架處理的是確定性任務，AI 工具處理的是多變頁面上的彈性任務，兩者在地圖上是互補的關係。下次頁面又改版、腳本又掛掉的時候，先問自己是選擇器寫死了，還是這件事本來就該交給看得懂頁面的模型，答案會決定你該翻清單的哪一頁。