AI控制瀏覽器的最佳方案:Playwright-cli + AI Coding ——寫不出來的爬蟲、跑不通的腳本,讓 AI 對着瀏覽器幫你調
整理版優先睇
Playwright-cli + AI:寫爬蟲同腳本唔再靠估,AI 睇住瀏覽器幫你搞掂曬
呢篇文章係微軟喺 GitHub 低調推出嘅 playwright-cli 工具介紹,作者係技術社羣嘅觀察者,整理咗呢個工具嘅用法同價值。佢想解決嘅問題有兩個:自己寫 Playwright 腳本跑唔通,要不停改同猜;每次靠 AI 完成操作,用完就冇,下次又要重新搞。整體結論係:playwright-cli 可以俾 AI 接管你嘅瀏覽器,邊睇真實頁面邊幫你調代碼,調完直接生成可獨立運行嘅 Python 腳本,之後定時跑、服務器跑、斷網跑都得,完全唔使依賴 AI 環境。
作者強調呢個工具嘅核心創新係「AI 負責探索同生產腳本,唔參與後續運行」。同傳統 Selenium、Playwright 呢啲工具唔同,playwright-cli 將瀏覽器操作封裝成簡單嘅 CLI 指令,AI 可以直接調用,你只需要用自然話講目標就得。文章仲比較咗 CLI 同 MCP 兩種 AI 操控瀏覽器嘅方式:CLI 省 Token,適合高效執行;MCP 適合深度探索,兩者互補。
最後,作者用咗七個真實場景示範點樣用 playwright-cli 解決日常問題,例如每日下載報表、排查按鈕冇反應、處理 iframe 嵌套、固化腳本等。佢嘅建議係:如果你已經用緊 Claude Code、GitHub Copilot 呢類工具,playwright-cli 係一個值得即刻安裝嘅擴展能力。
- Playwright-cli 嘅核心價值係「AI 探索→生成腳本→脱離 AI 獨立運行」,一次搞掂,以後唔使煩。
- 同 MCP 相比,CLI 方式更省 Token,適合編程代理同時處理大型代碼庫同瀏覽器操作。
- 傳統瀏覽器自動化要你寫代碼,而家你只需要用自然話講目標,AI 會睇住瀏覽器幫你搞。
- 實際應用涵蓋每日報表下載、按鈕問題排查、iframe 處理、繞過前端限制等,全部可以固化成 Python 腳本。
- 開始使用好簡單:npm install、安裝 Skills、開瀏覽器調試端口,之後就係叫 AI 做嘢。
playwright-cli GitHub 倉庫
微軟官方 GitHub 項目,目前 v0.1.8,已有 9000+ stars。
Playwright 官方文檔
Playwright 框架嘅完整文檔,用嚟參考 API 同進階用法。
內容片段
playwright-cli open
https://demo.playwright.dev/todomvc/playwright-cli type "Buy groceries"playwright-cli press Enterplaywright-cli check e21playwright-cli screenshot
傳統自動化嘅痛點同 playwright-cli 嘅解法
以前你寫 Playwright 腳本跑唔通,要加 print、猜原因、反覆改再跑;每次靠 AI 完成一個操作,用完就冇,下次又要重新嚟。呢兩個問題,playwright-cli 都解決曬。
微軟低調推出嘅 playwright-cli,核心能力係:讓 AI 接管你嘅瀏覽器,邊睇真實頁面邊幫你調代碼,調完直接生成可獨立運行嘅 Python 腳本。用一次,沉澱一個腳本,之後定時跑、服務器跑、斷網跑,完全唔依賴 AI 環境。
- 自己寫嘅腳本有 bug → AI 睇住真實瀏覽器幫你實時定位
- 想固化一套操作流程 → AI 探索完直接生成 .py 腳本
- 每日手動下載報表 → 腳本跑一下,自動完成
- 按鈕撳咗冇反應 → AI 直接扒出前端邏輯
- 政務系統全是 iframe → AI 自動識別 iframe 結構
CLI 點解比 MCP 更受編程代理歡迎?
目前 AI 操控瀏覽器有兩種主流方式:MCP(模型上下文協議)同 CLI(命令行)。微軟喺文檔裏面明確解釋咗兩者嘅區別。
CLI 嘅優勢在於「省 Token」。MCP 每次調用工具都要將大量工具描述、頁面可訪問性樹等信息塞入模型上下文,消耗大量 Token。而 CLI 命令簡潔,AI 只需要知道命令本身,避免咗冗餘信息嘅加載。
MCP 就適合「深度探索」,當你需要 AI 持續睇住一個頁面、反覆調整策略、做複雜自主推理時,MCP 嘅持久狀態更有優勢。簡單講:CLI 係高效執行,MCP 係深度分析,兩者唔係替代關係,而係互補。
七個真實場景,睇下點樣幫到手
- 1 每日下載報表:AI 接管瀏覽器,自動登錄、撳菜單、選條件、導出,完全唔使自己鬱。
- 2 按鈕撳咗冇反應:AI 可以直接扒出按鈕背後嘅 JavaScript 邏輯,例如發現導出按鈕只喺工作時間生效,前端直接寫死時間校驗。
- 3 下載文件捕獲唔到:用 form.submit() 觸發嘅下載,AI 可以用 CDP 協議繞過,直接 set download behavior。
- 4 政務/企業系統滿係 iframe:AI 自動識別 iframe 結構,選擇正確嘅進入方式,唔怕定位唔到元素。
- 5 自己寫嘅 Playwright 代碼跑唔通:AI 會讀你嘅代碼,接管瀏覽器,檢查事件綁定同網絡請求,直接改好代碼。
- 6 探索完成後固化成獨立腳本:AI 將操作流程寫成標準 .py 文件,支援命令行傳參,可直接放服務器定時執行。
- 7 接口有前端限制但後端冇:AI 分析請求,用 fetch 繞過前端直接拎數據,同樣可以固化成腳本。
點樣開始用?四個步驟就搞掂
- 1 安裝:`npm install -g @playwright/cli@latest`,需要 Node.js 18 或更高。
- 2 安裝 Skills:`playwright-cli install --skills`,呢步會裝操作指南,Claude Code、GitHub Copilot 等助手會自動讀取。
- 3 開瀏覽器調試端口:Chrome/Edge 啟動時加上 `--remote-debugging-port=9222`。
- 4 叫 AI 做嘢:例如「我嘅瀏覽器已經喺 localhost:9222 運行,已登錄 XX 系統,幫我將本月數據導出到 Excel」。
如果你偶爾想手動操作,呢啲命令夠用:open、snapshot、click、fill、screenshot、attach、state-save、state-load。
state-save 同 state-load 可以保存登錄狀態,下次直接用,唔使重新登錄
安全方面,AI 唔會主動亂操作,調試端口只喺本地暴露,會話相互隔離,敏感操作可以逐步確認。
你有冇遇到呢兩種情況?
自己寫嘅 Playwright 腳本跑唔通,唔知邊度出問題,淨係得不停改不停估 每次靠 AI 完成一個操作,用完就冇咗,下次又要重新嚟過一次 呢兩個問題,playwright-cli 都解決曬。
微軟最近喺 GitHub 低調發布咗 playwright-cli,而家已經有 9000+ stars。
核心能力得一句話:俾 AI 接管你嘅瀏覽器,一邊睇真實頁面一邊幫你改 code,改完直接生成可以獨立運行嘅 Python 腳本。
用一次,就有一個腳本,之後定時跑、伺服器跑、斷網跑,完全唔使依賴 AI 環境。
呢個係好多人未諗清楚嘅分別:AI 負責探索同生產腳本,唔參與之後嘅運行。
具體嚟講,佢可以幫你做呢啲嘢:
生成嘅腳本係標準 Python 檔案,唔依賴任何 AI 服務,放喺伺服器定時跑完全冇問題。
呢個同以前嘅瀏覽器自動化有咩唔同?
瀏覽器自動化唔係新鮮事。Selenium、Playwright、RPA 工具……大家可能都聽過。但呢啲工具都有一個共同嘅門檻:你要寫 code。
playwright-cli 嘅思路完全唔同。
佢將 Playwright 嘅能力封裝成一個個簡潔嘅命令列指令,AI 助手可以直接調用呢啲指令嚟操控瀏覽器。你只需要用自然語言話俾 AI 知你嘅目標,剩下嘅交俾佢。
舉個例子,你想測試一個待辦事項網站,只需要話俾 AI:
"用 playwright-cli 測試一下 https://demo.playwright.dev/todomvc/ 呢個網站,截圖保存所有成功同失敗嘅場景。"
AI 會自己執行一系列命令:
playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli check e21
playwright-cli screenshot
成個過程你唔使寫任何 code。
點解 CLI 比 MCP 更受編程代理青睞?
呢度有個值得留意嘅技術趨勢。
目前 AI 操控瀏覽器有兩種主流方式:MCP(模型上下文協議)同 CLI(命令列)。微軟喺文件入面明確解釋咗兩者嘅分別:
CLI 嘅優勢在於「省 Token」"。
MCP 每次調用工具,都要將大量嘅工具描述、頁面可訪問性樹等資訊塞入模型上下文,消耗大量 Token。而 CLI 命令簡潔,AI 只需要知道命令本身,避免咗冗餘資訊嘅加載。
對於需要同時處理大型代碼庫 + 瀏覽器操作嘅編程代理嚟講,Token 窗口就係生命線,CLI 方式明顯更實用。
MCP 則適合「深度探索」。當你需要 AI 持續睇住一個頁面、反覆調整策略、做複雜嘅自主推理時,MCP 嘅持久狀態更有優勢。
簡單講:CLI 係高效執行,MCP 係深度分析。 兩者唔係取代關係,而係互補。
五個真實場景,感受下
場景一:每日下載報表太煩人
好多企業系統嘅數據導出需要登入、㩒幾個菜單、揀條件、導出……每日重複。
而家你只需要:
啟動帶除錯埠嘅瀏覽器(一次性配置) 話俾 AI:「幫我將 XX 系統入面今個月嘅銷售報表導出嚟」 AI 接管瀏覽器,自動完成所有步驟
場景二:按鈕㩒咗冇反應,排查半日
有冇遇到過㩒「導出」按鈕完全冇反應,都唔報錯?
用 playwright-cli 可以俾 AI 直接挖出按鈕背後綁定咗啲乜 JavaScript 邏輯:
// 檢查按鈕是否有時間限制
jQuery._data(document.getElementById('export'), 'events')
有位用戶就係咁發現咗一個政務系統嘅隱藏限制:導出按鈕只喺工作時間生效,前端直接寫死咗時間校驗,從來唔話俾用戶知原因。
場景三:下載檔案捕獲唔到
Python Playwright 腳本入面用 expect_download() 卻捕獲唔到透過 form.submit() 觸發嘅下載?
AI 可以直接用 CDP 協議繞過:
const cdp = await page.context().newCDPSession(page);
cdp.send('Browser.setDownloadBehavior', {
behavior: 'allow',
downloadPath: 'D:\\Downloads',
});
話俾 AI 你嘅問題,佢會幫你揾到解法並直接改好 code。
場景四:政務/企業系統全部係 iframe
呢類系統幾乎全部係 iframe 嵌套,普通自動化腳本經常定位唔到元素。
AI 會自動識別 iframe 結構,揀啱嘅進入方式:
const frame = page.frames().find(f => f.name() === 'mainframe');
await frame.evaluate(() => { /* 在 iframe 內直接執行操作 */ });
場景五:自己寫嘅 Playwright code 跑唔通

好多人學咗 Playwright 之後自己寫腳本,結果運行起嚟好多問題:元素定位失敗、㩒擊冇效果、下載捕獲唔到……
傳統除錯方式係:加 print、睇報錯、對住文件估、改咗再跑……循環往復。
而家換另一種玩法:俾 AI 一邊睇住真實瀏覽器,一邊幫你改 code。
你只需要:
我有一個 Playwright 腳本 D:\...\export.py,
運行後點擊"導出"按鈕沒有觸發下載,
瀏覽器已經打開在 localhost:9222,幫我排查
AI 會:
讀你嘅 code,理解下載邏輯 接管瀏覽器,即時睇頁面狀態 檢查按鈕嘅事件綁定,睇網絡請求有冇發出去 直接定位問題,修改 code,儲存
全程你唔使自己打一行除錯 code,亦唔使重複「改→跑→報錯→再改」嘅循環。
場景六:探索完成後,固化做獨立腳本
呢個係 playwright-cli 最容易被忽略嘅價值:佢係探索工具,唔係運行環境。
好多人以為用咗 AI + playwright-cli 就永遠要依賴 AI 先可以運行。其實完全唔係咁。
正確嘅工作流程係:
第一階段(一次性):AI + playwright-cli 探索
→ AI 接管瀏覽器,找元素、測操作、排查問題
→ 確認操作路徑完全可行
第二階段(固化):AI 生成 Python 腳本
→ 把剛才的操作流程寫成標準 .py 文件
→ 保存到你的項目目錄
第三階段(後續):直接運行 .py,完全脱離 AI
→ python export.py
→ 定時任務、批處理、CI/CD 全都支持
→ 不需要 Claude,不需要網絡,不需要任何大模型環境
你可以話俾 AI:
剛才的操作流程已經驗證可行了,幫我把它整理成一個標準的
Python Playwright 腳本,保存到 D:\scripts\export.py,
要支持命令行傳參(開始日期、結束日期)
AI 生成嘅腳本可以直接掉去伺服器上面跑定時任務,同普通 Python 腳本完全冇分別——AI 只係參與咗生產呢個腳本嘅過程,唔參與運行。
呢個解決咗好多人對「AI 自動化」嘅顧慮:企業環境、內網伺服器、斷網場景,都冇問題。
場景七:接口有前端限制但後端冇
發現某個導出功能喺前端做咗權限限制,但後端接口其實可以直接調用?AI 可以幫你分析請求,用 fetch 繞過前端直接拎數據(生成好之後同樣可以固化做腳本):
const resp = await fetch('/api/exportData', {
method: 'POST',
credentials: 'include', // 帶上登錄態
body: formData
});
點樣開始用?
第一步:安裝
npm install -g @playwright/cli@latest
需要 Node.js 18 或更高版本。
第二步:安裝 Skills(令 AI 助手學識點用佢)
playwright-cli install --skills
呢一步會將操作指南安裝到本地,Claude Code、GitHub Copilot 等助手會自動讀取並學識點用。
第三步:啟動瀏覽器時加上除錯埠
# Chrome/Edge 啓動時加上這個參數
--remote-debugging-port=9222
之後 AI 就可以透過呢個埠接管你嘅瀏覽器。
第四步:話俾 AI 你想做啲乜
我的瀏覽器已經在 localhost:9222 運行了,已經登錄了 XX 系統,
幫我把本月的數據導出到 Excel
剩下嘅嘢交俾 AI。
一啲實用嘅命令速查
如果你間中想手動操作,呢啲命令夠用㗎喇:
# 打開網頁
playwright-cli open https://example.com --headed
# 看頁面結構(AI 最常用的命令)
playwright-cli snapshot
# 點擊元素
playwright-cli click e15
# 填寫表單
playwright-cli fill e5 "要輸入的內容"
# 截圖
playwright-cli screenshot --filename=result.png
# 接管已有瀏覽器
playwright-cli attach --cdp=http://localhost:9222
# 保存登錄狀態
playwright-cli state-save my-session
playwright-cli state-load my-session # 下次直接恢復,不用重新登錄
關於安全同邊界
有人會問:咁樣俾 AI 操控瀏覽器,安唔安全?
幾個注意點:
AI 唔會主動亂咁操作。設計良好嘅提示詞會令 AI 先話俾你知要做啲乜,確認之後先執行。 除錯埠只喺本地暴露。 localhost:9222只有本機可以訪問,唔會對外開放。敏感操作建議逐步確認。可以話俾 AI:「每一步先講清楚你要做啲乜,我確認之後先執行」。 會話互相隔離。唔同嘅會話( -s=name)使用獨立嘅瀏覽器實例,互不幹擾。
寫喺最後
瀏覽器自動化唔係乜嘢新技術,但 playwright-cli 嘅出現,令佢第一次真正對非程式員變得友好。
核心變化得一個:以前你要學工具,而家工具嚟適應你。
你只需要用自然語言描述目標,AI 負責翻譯成具體操作。嗰啲需要「先學 Selenium」、「先學 XPath」、「先搞懂異步等待」嘅門檻,全部消失曬。
更重要係,佢提供咗一條由探索到固化嘅完整路徑:
遇到新需求?俾 AI 接管瀏覽器探索,一邊試一邊確認 自己嘅腳本有 bug?俾 AI 睇住真實瀏覽器幫你改 路徑確認咗之後?俾 AI 生成標準 .py 腳本,之後完全脱離 AI 獨立運行
最後跑喺伺服器上面嘅,係一個普通嘅 Python 腳本,冇大模型依賴,冇網絡要求,冇額外嘅運行環境。AI 只係出現喺「生產腳本」呢一步,唔參與之後嘅運行。
如果你日常已經在用 Claude Code、GitHub Copilot 呢類工具,playwright-cli 係一個值得即刻安裝嘅擴展能力。
相關資源
playwright-cli GitHub 倉庫:github.com/microsoft/playwright-cli Playwright 官方文檔:playwright.dev 當前版本:v0.1.8(2026年4月)
如果你有具體嘅自動化需求想傾,歡迎留言。
你有沒有遇到這兩種情況:
自己寫的 Playwright 腳本跑不通,不知道哪裏出問題,只能反覆改反覆猜 每次靠 AI 完成一個操作,用完就沒了,下次還得重新來一遍 這兩個問題,playwright-cli 都解決了。
微軟最近在 GitHub 上低調發布了 playwright-cli,目前已有 9000+ stars。
核心能力只有一句話:讓 AI 接管你的瀏覽器,邊看真實頁面邊幫你調代碼,調完直接生成可獨立運行的 Python 腳本。
用一次,沉澱一個腳本,之後定時跑、服務器跑、斷網跑,完全不依賴 AI 環境。
這是很多人沒想清楚的區別:AI 負責探索和生產腳本,不參與後續運行。
具體來說,它能幫你做這些事:
生成的腳本是標準 Python 文件,不依賴任何 AI 服務,放服務器上定時跑沒有任何問題。
這跟以前的瀏覽器自動化有什麼不一樣?
瀏覽器自動化不是新鮮事。Selenium、Playwright、RPA 工具……大家可能都聽說過。但這些工具有一個共同的門檻:你得寫代碼。
playwright-cli 的思路完全不同。
它把 Playwright 的能力封裝成一個個簡潔的命令行指令,AI 助手可以直接調用這些指令來操控瀏覽器。你只需要用自然語言告訴 AI 你的目標,剩下的交給它。
舉個例子,你想測試一個待辦事項網站,只需要告訴 AI:
"用 playwright-cli 測試一下 https://demo.playwright.dev/todomvc/ 這個網站,截圖保存所有成功和失敗的場景。"
AI 會自己執行一系列命令:
playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli check e21
playwright-cli screenshot
整個過程你不需要寫任何代碼。
為什麼 CLI 比 MCP 更受編程代理青睞?
這裏有個值得關注的技術趨勢。
目前 AI 操控瀏覽器有兩種主流方式:MCP(模型上下文協議)和 CLI(命令行)。微軟在文檔裏明確解釋了兩者的區別:
CLI 的優勢在於"省 Token"。
MCP 每次調用工具,都需要把大量的工具描述、頁面可訪問性樹等信息塞入模型上下文,消耗大量 Token。而 CLI 命令簡潔,AI 只需要知道命令本身,避免了冗餘信息的加載。
對於需要同時處理大型代碼庫 + 瀏覽器操作的編程代理來說,Token 窗口就是生命線,CLI 方式明顯更實用。
MCP 則適合"深度探索"。當你需要 AI 持續盯着一個頁面、反覆調整策略、做複雜的自主推理時,MCP 的持久狀態更有優勢。
簡單說:CLI 是高效執行,MCP 是深度分析。 兩者不是替代關係,而是互補。
五個真實場景,感受一下
場景一:每天下載報表太煩人
很多企業系統的數據導出需要登錄、點幾個菜單、選條件、導出……每天重複。
現在你只需要:
啓動帶調試端口的瀏覽器(一次性配置) 告訴 AI:"幫我把 XX 系統裏本月的銷售報表導出來" AI 接管瀏覽器,自動完成所有步驟
場景二:按鈕點了沒反應,排查半天
有沒有遇到過點擊"導出"按鈕沒有任何反應,也不報錯?
用 playwright-cli 可以讓 AI 直接扒出按鈕背後綁定了什麼 JavaScript 邏輯:
// 檢查按鈕是否有時間限制
jQuery._data(document.getElementById('export'), 'events')
某位用戶就是這樣發現了一個政務系統的隱藏限制:導出按鈕只在工作時間生效,前端直接寫死了時間校驗,從不告訴用戶原因。
場景三:下載文件捕獲不到
Python Playwright 腳本里用 expect_download() 卻捕獲不到通過 form.submit() 觸發的下載?
AI 可以直接用 CDP 協議繞過:
const cdp = await page.context().newCDPSession(page);
cdp.send('Browser.setDownloadBehavior', {
behavior: 'allow',
downloadPath: 'D:\\Downloads',
});
告訴 AI 你的問題,它會幫你找到解法並直接改好代碼。
場景四:政務/企業系統滿是 iframe
這類系統幾乎全是 iframe 嵌套,普通自動化腳本經常定位不到元素。
AI 會自動識別 iframe 結構,選擇正確的進入方式:
const frame = page.frames().find(f => f.name() === 'mainframe');
await frame.evaluate(() => { /* 在 iframe 內直接執行操作 */ });
場景五:自己寫的 Playwright 代碼跑不通

很多人學了 Playwright 之後自己寫腳本,結果運行起來各種問題:元素定位失敗、點擊沒有效果、下載捕獲不到……
傳統調試方式是:加 print、看報錯、對着文檔猜、改了再跑……循環往復。
現在換一種玩法:讓 AI 邊看着真實瀏覽器,邊幫你改代碼。
你只需要:
我有一個 Playwright 腳本 D:\...\export.py,
運行後點擊"導出"按鈕沒有觸發下載,
瀏覽器已經打開在 localhost:9222,幫我排查
AI 會:
讀你的代碼,理解下載邏輯 接管瀏覽器,實時看頁面狀態 檢查按鈕的事件綁定,看網絡請求有沒有發出去 直接定位問題,修改代碼,保存
全程你不需要自己打一行調試代碼,也不需要重複"改→跑→報錯→再改"的循環。
場景六:探索完成後,固化成獨立腳本
這是 playwright-cli 最容易被忽略的價值:它是探索工具,不是運行環境。
很多人以為用了 AI + playwright-cli 就永遠依賴 AI 才能運行。其實完全不是這樣。
正確的工作流是:
第一階段(一次性):AI + playwright-cli 探索
→ AI 接管瀏覽器,找元素、測操作、排查問題
→ 確認操作路徑完全可行
第二階段(固化):AI 生成 Python 腳本
→ 把剛才的操作流程寫成標準 .py 文件
→ 保存到你的項目目錄
第三階段(後續):直接運行 .py,完全脱離 AI
→ python export.py
→ 定時任務、批處理、CI/CD 全都支持
→ 不需要 Claude,不需要網絡,不需要任何大模型環境
你可以告訴 AI:
剛才的操作流程已經驗證可行了,幫我把它整理成一個標準的
Python Playwright 腳本,保存到 D:\scripts\export.py,
要支持命令行傳參(開始日期、結束日期)
AI 生成的腳本可以直接丟到服務器上跑定時任務, 和普通 Python 腳本沒有任何區別——AI 只參與了生產這個腳本的過程,不參與運行。
這解決了很多人對"AI 自動化"的顧慮:企業環境、內網服務器、斷網場景,都沒有問題。
場景七:接口有前端限制但後端沒有
發現某個導出功能在前端做了權限限制,但後端接口其實可以直接調用?AI 可以幫你分析請求,用 fetch 繞過前端直接拿數據(生成好後同樣可以固化成腳本):
const resp = await fetch('/api/exportData', {
method: 'POST',
credentials: 'include', // 帶上登錄態
body: formData
});
怎麼開始用?
第一步:安裝
npm install -g @playwright/cli@latest
需要 Node.js 18 或更高版本。
第二步:安裝 Skills(讓 AI 助手學會使用它)
playwright-cli install --skills
這一步會把操作指南安裝到本地,Claude Code、GitHub Copilot 等助手會自動讀取並學會使用。
第三步:啓動瀏覽器時加上調試端口
# Chrome/Edge 啓動時加上這個參數
--remote-debugging-port=9222
之後 AI 就可以通過這個端口接管你的瀏覽器。
第四步:告訴 AI 你要幹什麼
我的瀏覽器已經在 localhost:9222 運行了,已經登錄了 XX 系統,
幫我把本月的數據導出到 Excel
剩下的事交給 AI。
一些實用的命令速查
如果你偶爾想手動操作,這些命令夠用了:
# 打開網頁
playwright-cli open https://example.com --headed
# 看頁面結構(AI 最常用的命令)
playwright-cli snapshot
# 點擊元素
playwright-cli click e15
# 填寫表單
playwright-cli fill e5 "要輸入的內容"
# 截圖
playwright-cli screenshot --filename=result.png
# 接管已有瀏覽器
playwright-cli attach --cdp=http://localhost:9222
# 保存登錄狀態
playwright-cli state-save my-session
playwright-cli state-load my-session # 下次直接恢復,不用重新登錄
關於安全和邊界
有人會問:這樣讓 AI 操控瀏覽器,安不安全?
幾個注意點:
AI 不會主動亂操作。設計良好的提示詞會讓 AI 先告訴你要做什麼,確認後再執行。 調試端口只在本地暴露。 localhost:9222只有本機能訪問,不會對外開放。敏感操作建議逐步確認。可以告訴 AI:"每一步先說明你要做什麼,我確認後再執行"。 會話相互隔離。不同的會話( -s=name)使用獨立的瀏覽器實例,互不干擾。
寫在最後
瀏覽器自動化並不是什麼新技術,但 playwright-cli 的出現,讓它第一次真正對非程序員變得友好。
核心變化只有一個:以前你要學工具,現在工具來適應你。
你只需要用自然語言描述目標,AI 負責翻譯成具體操作。那些需要"先學 Selenium"、"先學 XPath"、"先搞懂異步等待"的門檻,統統消失了。
更重要的是,它提供了一條從探索到固化的完整路徑:
遇到新需求?讓 AI 接管瀏覽器探索,邊試邊確認 自己的腳本有 bug?讓 AI 盯着真實瀏覽器幫你調 路徑確認後?讓 AI 生成標準 .py 腳本,之後完全脱離 AI 獨立運行
最終跑在服務器上的,是一個普通的 Python 腳本,沒有大模型依賴,沒有網絡要求,沒有額外的運行環境。AI 只出現在"生產腳本"這一步,不參與後續運行。
如果你日常已經在用 Claude Code、GitHub Copilot 這類工具,playwright-cli 是一個值得立刻安裝的擴展能力。
相關資源
playwright-cli GitHub 倉庫:github.com/microsoft/playwright-cli Playwright 官方文檔:playwright.dev 當前版本:v0.1.8(2026年4月)
如果你有具體的自動化需求想聊,歡迎留言。