有了 Chrome DevTools MCP，AI 再次學會了睜眼說瞎話

Google 在 2025 年 9 月底把 Chrome DevTools MCP 放出來公測。

想一下如果你是 Google 的人，會怎麼介紹這個 MCP?
我可能會說:

讓 LLM 可以透過這個 mcp 中預先設計好的 tool，使用網頁瀏覽器的一些功能，裡面有 20 幾種 tool，首先第一個是...

......抬頭一看人都跑光了，留下來的有人睡到流口水，這邊是失眠治療營是吧?

或者我們可以換個方式介紹:

「只要把網址給 AI，就可以生成各種網站健檢報告、效能分析報告、資安弱點掃描、SEO 技術稽核、使用者體驗評估，一些專門只做稽核，產出問題報告就可以收錢的顧問公司或人員，將得到前所未有的強大武器...」
(如果沒看出這段問題在哪裡，請不要聽從陌生人指示操作提款機)

如果是小米出的，雷軍可能會這樣介紹:

朋友們，大家好！今天，我要跟大家分享一個足以改變程式開發世界的產品——Chrome DevTools MCP。這不是一個普通的工具，而是一個我們花了 987 個日夜、投入超過 87 名工程師、在 全球 87 個城市反覆測試與打磨後，才最終帶來的答案。我們調查了 超過 8787 名開發者，發現 87% 的人都遇到過同樣的問題......不僅如此，為了「交個朋友」，我們還提供了完整的工具參考文件、範例提示詞，甚至還贈送......，讓你立刻體驗「AI + 瀏覽器」的威力。未來，這不僅僅是一個工具，而是 開發者新時代的起點。

Google 官方 Chrome DevTools (MCP) for your AI agent 是這樣介紹的:

Coding agents face a fundamental problem: they are not able to see what the code they generate actually does when it runs in the browser. They're effectively programming with a blindfold on. (程式碼代理程式面臨一個基本問題：無法在瀏覽器中執行程式碼時，查看程式碼實際執行的動作。他們就像是蒙上眼睛編寫程式。)

The Chrome DevTools MCP server changes this. AI coding assistants are able to debug web pages directly in Chrome, and benefit from DevTools debugging capabilities and performance insights. This improves their accuracy when identifying and fixing issues.
(Chrome 開發人員工具 MCP 伺服器改變了這一現狀。AI 程式碼輔助工具可以直接在 Chrome 中偵錯網頁，並運用開發人員工具的偵錯功能和效能洞察資料。這有助於提升問題識別和修正的準確度。)

AI 可以直接連上瀏覽器幫忙檢查問題，第一眼覺得納悶，那跟 Playwright MCP 有何不同?

裝起來試試~

安裝 Chrome DevTools MCP：從懷疑到踩坑的初體驗

在 GitHub 頁面觀察了兩下，發 repo 的是一個叫 ChromeDevTools 的 GitHub 帳號，而不是 Google。

今天這連結是 Google 官方部落格內的連結，要是其他來路不明的 mcp，我才不敢裝。這帳號也沒有 organization verified 小綠標，真要說是某個詐騙釣魚集團假裝 Chrome 可能也不意外。

畢竟什麼 MCP 造成資安事故啦、加密貨幣詐騙集團在 GitHub 上煞有其事地開一些釣魚程式專案，這都是日常的慘業新聞，看看網路對我們做了什麼?

安裝過程有點波折，一開始沒有成功啟動，從輸出訊息看問題是 node 版本太低不符要求，重開機幾次後，終於成功升級，npm 跟 node 都恢復正常，Windows 就乖乖用 NVM for Windows就好了。

node 版本條件滿足後，在每個 CLI 或 Editor 內還是有各種錯誤訊息，無法正常啟動。最後去 ChromeDevTools MCP 的官方 issues 爬文，參考別人的設定改一下就好了。

AI 可以看到瀏覽器內發生了什麼錯誤訊息

確實是可以給個網址、簡單文字敘述需求，AI 就會自動呼叫設計好的 tool，一樣都可以做簡單的網頁互動操作，不用人類親自操作！

跟 Playwright 差不多，也能直接讀取瀏覽器內的各種資訊，不用人類複製貼上錯誤訊息！，然後 AI 可以根據剛剛獲得的資訊，回到程式碼那邊自動修改 bug。

想到前幾年的 AI 程式碼輔助工具，大都只是在側邊多一個 chat 視窗，然後碰到 terminal 有什麼建置問題，瀏覽器中實際執行碰到什麼問題，人類就要一直把錯誤訊息貼到 chat 視窗。

記得那時候還有一家 AI Editor 出了一個新功能，可以把 terminal 內的錯誤訊息選取起來，一鍵送進 AI chat sidebar 的對話視窗內，讓 AI 回答問題時有充分的 context，這麼方便的功能在當時被社群上的人大吹特吹。現在看起來真是唏噓。

而現在各大主流的 AI 程式碼輔助工具，基本都可以直接在 chat 中輸入 fix npm build error 之類的，然後 AI 就可以直接執行指令，看到錯誤訊息然後修正程式......不過也有時候會一行程式碼都不去改，然後一直 build error 然後一直 thinking 到系統卡死。或是社群上常見的案例，允許 AI 執行任意指令，結果 AI 把資料清空之類的。

開發中的一些勞務，透過 Chrome DevTools MCP 把更多東西輕鬆連接起來了，不需要花式雜耍了嗎? 其實失敗率還是挺高的。

自動化控制瀏覽器問題

原則上會另外開一個自動控制的瀏覽器視窗出來，但幸虧我們不用三天兩頭去更新什麼 ChromeDriver。也可以修改 MCP 的參數，使用 headless 模式(在背景執行)，但最討厭的是這種自動控制開出來的瀏覽器不一定能完整還原人類使用瀏覽器的狀態。

要模擬有裝擴充套件或各種瀏覽環境

有時候人類肉眼看到網頁程式明明在瀏覽器 console 內有錯誤，但 AI 卻說看不到錯誤訊息，人類肉眼檢查 AI 開出來的那個瀏覽器，console 內還真的沒有錯誤訊息，最後還是只能人工把錯誤訊息貼給 AI 看。畢竟真實各種網頁瀏覽器的環境更加複雜。

再來光是看到「Chrome DevTools MCP」這個名字，大家應該心裡有數。它無法啟動一個獨立的 Firefox 或 Safari 瀏覽器，也就沒辦法去處理那些只在特定瀏覽器核心下才會出現的奇特 CSS 樣式問題或 JavaScript 執行錯誤。它是一個深度整合的「Chrome 專家」，這在處理跨瀏覽器相容性問題時，是一個非常現實的侷限。

而隔壁 Playwright MCP 有提供更多設定參數，例如可以用 browser 指定幾種瀏覽器引擎，也可以用 executable-path 直接指定電腦中已安裝的瀏覽器的執行路徑，例如要跑的網頁廣告很多，干擾 AI 做事情，那把本機 Brave 瀏覽器路徑放上去，運氣好的話可以解決問題。

要保持登入狀態

如果要操作的網頁程式是需要 LINE 帳號社群登入或 Passkey 登入之類的，而這個另外開出來的瀏覽器根本就沒有登入狀態，那就有點麻煩。

最土炮的方法，就是人類去幫忙登入，這種瀏覽器操作類 MCP 會有 wait tool，通常打開網頁，等網頁載入完，等人類指令中講到的內容出現時，才會繼續操作。所以當人類看到瀏覽器視窗跑出來，有時候趁 AI 不注意，趕快去幫忙操作，打帳號密碼、按人機驗證、按 UI 上的選項，過一會兒 AI 就會自動繼續操作下去。

除此之外，Chrome DevTools MCP 和 Playwright MCP 雙方都有一些方式設法解決這問題，例如 Chrome 可以搞 CDP(Chrome DevTools Protocol)，在電腦本機的 Chrome 加一個 --remote-debugging-port 啟動參數，指定 port 號，然後到 chrome://inspect/#devices 去指定剛剛設的那個，然後再調整 MCP 的設定參數。

Playwright MCP 則是有一個 playwright-mcp-extension，把檔案下載下來，在瀏覽器擴充套件 chrome://extensions/ 中「載入未封裝項目」，會多一個 Playwright MCP Bridge 的擴充套件，然後再調整 MCP 的設定參數。接著自動化分頁會開在本來的瀏覽器內，而不是另開一個乾淨的視窗。

碰到登入畫面有擋自動控制瀏覽器的，還是有機會讓所有腦海中的計畫窒礙難行。

我是不太期待未來會有更方便的方法，畢竟「把瀏覽器的登入狀態搬到別的地方使用」本身就是一個有資安風險的議題，這是一把雙面刃，這能讓 AI 更方便輔助人類把工作自動化，也能讓灰產業的特殊用途使用者非常開心，真有這種好事，等未來來了再說，不必現在就開始大吹特吹。

AI 本身的問題

有了這些 MCP，號稱 AI 不再蒙上眼睛編寫程式? 但實際上還是非常容易出問題。

從整個流程邏輯上，要先看 MCP 開發者設計了多少 tool 給 LLM 使用，例如在網路上看到一個專門控制 Firefox 瀏覽器的 MCP，主要功能都是操作分頁相關的，還有讀取瀏覽紀錄，跟 Chrome Devtool 這個設計方向差異很大，AI 能做的事就少很多。

接著是使用的 LLM 有沒有呼叫工具的能力，有或沒有就是一個門檻，然後模型能力能不能好好判斷什麼時候要使用什麼工具，又是另一個門檻，各種小問題堆疊起來，就造就了 AI 與 mcp 的使用體驗。

希望有人看到這段之後可以理解，為什麼明明有免費的開源模型或工具，卻沒人想用；而有些 AI 工具，用幾小時會強制休息，規定一大堆，還貴得要死，大家還願意訂閱?

以下放一些使用 Chrome DevTools MCP 的失敗案例:

AI 宣稱看到了、修好問題了，但實際上根本沒執行

事實上有時候要讓 LLM 去瀏覽網頁就難如登天，例如「說執行後仍然卡在某某狀態，附上網址，請 LLM 去看錯誤訊息」，LLM 仍會有自己的主見，說「我看到問題了！」但看紀錄根本就沒有，我們的 AI 同事繼續瞎改一番。

最後還是人類手動貼上一些執行時的資訊，prompt 輸入使用 chrome devtools 來查，三催四請，好不容易終於讓 LLM 真的呼叫 mcp tool，降臨到瀏覽器上...。

也有時候讓 AI 修一個要登入，再操作 XXX 之後才能看到的一個功能問題，一頓操作之下，AI 說修好了。
但查看 tool 呼叫紀錄，它根本就沒到那一頁、或是根本沒有去操作指定的功能，又再蝦改😡問題有解決才怪。

還有明明看到出錯，卻假裝一切運作正常，很愛睜眼說瞎話。

給了明確步驟，AI 卻在奇怪的地方卡關。

又或者是已經寫明步驟，指引它操作哪些 element，主流的 LLM 都是多模態的，實在想不出有什麼理由會失敗? 但實際使用時就是卡在各種奇怪的地方，無法完成任務。

最後還是要人類把它停止，回歸古法乖乖寫 playwright 控制碼，或是手動把錯誤訊息貼上請 AI 修...或是自己修。

中途出錯，AI 卻能一本正經地提出分析建議

例如讓 Chrome DevTools MCP 檢查網頁效能，在中途有出錯，AI 根本沒看到網頁。

AI 還是會長篇大論講出一堆跟該網頁無關的修改建議，等人類戳破它之後，又會改口「您說得對，我剛才的工具調用確實遇到問題，讓我重新進行實際的網站診斷。」

這問題很好笑嗎? 等有人用這個方法生一堆牛頭不對馬嘴的網頁修改報告，叫你照著做，你還沒有上訴溝通機會，看各位怎麼笑得出來?

缺少特定工具而導致任務失敗。

有些網頁程式是做成根據 UserAgent 字串來顯示電腦版/行動版內容，如果 prompt 指定「切換成 iPhone 手機的 useragent，再瀏覽此網頁」，現階段兩家的 mcp 沒有設計這個 tool，AI 會一頓操作猛如虎，然後很大的機率操作失敗，瀏覽的網頁根本沒有切換過去。

最無腦的解決方法是人類把自動化控制視窗的 device toolbar 叫出來切換好，再讓 AI 來操作。雖然這樣切換只是第一步，跟實際的行動裝置還相差甚遠。

如果人類不直接指定要用什麼技術，AI 也是奇招盡出，例如對於「修改 UserAgent 再去讀取網頁」這種需求，有時候會直接生成一段 PowerShell 命令 Start-Process chrome 指定的 UserAgent來執行，有時候則是用 browser_evaluate 的 tool 生成一段程式碼。但共同點是不管有沒有操作成功，AI 都一樣滔滔不絕用力瞎掰，直到人類提出疑點戳破它，AI 就會冒出經典名言:「你說得對!」。

要改樣式或視覺問題，失敗率就更高了，例如頁面上有個 position:fixed 的固定置頂 header，在某些操作時頁面會有第二條 position:fixed 的固定置頂元素，而因為 header 中有一個寬度是 % 單位的圖片，所以在不同 viewport 寬度下，header 高度是不固定的。然後第二條 position:fixed 的固定置頂元素要嘛跟 header 疊在一起，要嘛中間有空隙。針對此問題，人類希望用純 CSS 的方式，生成一些 CSS 去微調第二條元素的 top 值。

Chrome DevTools MCP 賦予了瀏覽器 resize_page 的 tool 能力，也會看到 AI 一直呼叫 evaluate_script 之類的 tool 來取得 CSS 樣式資訊，但最後常常是白忙活一場，白白花了一堆 token 費用。

網頁本身的技術選型很難讓自動化工具操作

以網頁程式開發配上 MCP 當 debug 輔助工具的用途來說，有些技術架構特別麻煩，例如 SPA 這種每一支程式沒有獨立的網址，又或是按鈕上並沒有什麼獨特的 ID 或名稱之類的，甚至按鈕是圖片? 這都很難用文字指定讓 AI 去操作，這些本來在技術選型時看似無關緊要的問題，在加入 AI 夥伴來開發之後，反而是自討苦吃。

雖然 AI 沒辦法完美遂行任務，但人類也是會有問題，企業家也可以幻想說給法定基本工資、加油站等級時薪，可以找到做事非常靠譜的人類神隊友。

其他網頁自動化操作需求

剛剛大部分談的是拿 Chrome DevTools MCP 幫網頁程式除錯，輔助一些網頁開發雜務，如果要真的拿來取代一些自動化工具呢?

如果有人有些大膽的想法，例如自動化操作某些網頁、繞過人機驗證、繞過網站防爬之類的? 比起寫一堆 playwright 指令碼，使用自然語言下指令，確實更方便點，但也不要太樂觀，實測下來成功機率也沒這麼高，而且 LLM 有時候回應時間莫名其妙的久，增加很多不穩定的因素。

這邊測試一下國內某家很用心防爬的房仲網站，看似滴水不漏的網站，還是在 network_request 中被 AI 發現了蛛絲馬跡

那條紀錄是類似這樣: https://www.facebook.com/privacy_sandbox/pixel/register/trigger/?id=196265610716659&ev=ViewContent&dl=https://rent.591.com.tw/12728382&rl=&if=false&ts=1759079648236&cd[content_ids]=R12728382&cd[content_type]=product&cd[region_name]=台北市&cd[module_name]=租屋詳情頁&cd[device_id]=UfHdJh8R_p-mQ23Df_pPF&cd[kind_name]=雅房&cd[item_id]=R12728382&cd[item_name]=水電包！萬芳醫院捷運旁30米，超優質雅房(限男)&cd[section_name]=文山區&cd[price_name]=7000&cd[shape_name]=公寓&cd[layout_name]=0&cd[area_name]=6&cd[house_age_name]=&cd[direction_name]=&cd[floor_name]=5F&cd[fitment_name]=&cd[life_name]=&cd[label_name]=屋主直租,近捷運,近商圈,隨時可遷入,有陽台&cd[facility_name]=洗衣機,電視,冷氣,熱水器,床,衣櫃,第四台,網路,天然瓦斯,桌椅,陽台&cd[custom_params]={"ai_video_use":0,"ai_video_recommend_flag":0,"local_video_file_id":0,"ai_video_file_id":0,"link_video_id":0}&sw=2560&sh=1080&v=2.9.232&r=stable&ec=1&o=4126&ler=empty&cdl=API_unavailable&pmd[description]=台北市文山區雅房出租：租金?元/月，面積?坪，位於興隆路三段，更多出租詳情，就上591租屋網！&pmd[keywords]=水電包！萬芳醫院捷運旁30米，超優質雅房(限男),台北市文山區雅房出租,591租屋網&coo=false&expv2[0]=pl0&expv2[1]=el2&expv2[2]=bc1&expv2c=pl0_el2_bc1&rqm=FGET GET [success-200]

既然資料是這樣來的，那大家應該心裡有數，只要問「屋主姓什麼」之類上面那串 URL 中沒有的，就得不到答案了

最重要的是想要自動化的操作，必須有網頁版可以使用，例如想要線上預約、購物、點餐，要有一個 AI 可以瀏覽的網站網址，而不是一個手機 APP。想要讓 AI 找資料後修改本機 Excel 檔或簡報檔案，檔案要上傳到一些線上編輯器，

想要幫忙社群貼文、key 表單、線上編輯某些東西，經常也需要人類在旁邊幫忙操作卡住的地方，監督自動化視窗上的操作，不是真正的無人化全自動。

Chrome DevTools MCP 和 Playwright MCP 的差異

這種讓 AI 操作瀏覽器的 mcp，市面上已經有好幾套，例如:

• AgentDeskAI/browser-tools-mcp
• BrowserMCP/mcp
• lxman/safari-mcp-server 看名字應該就知道是專門用來開哪一種瀏覽器的吧

實際好不好用，還是要看裡面有設計哪些 tool，有沒有人在管理，Playwright 是微軟在維護，Chrome 更不用說，碰到問題還可以大家一起取暖。看 Chrome DevTools MCP 的 isue 上大家提 feature request 提得多熱烈就知道。

Playwright MCP 跟 Chrome DevTools MCP 跟兩邊的功能到底哪裡有差異? 首先從 Chrome DevTools MCP 提供了一些示範用的 prompt 可以看出:

• A few images on localhost:8080 are not loading. What's happening?
• Why does submitting the form fail after entering an email address?
• The page on localhost:8080 looks strange and off. Check what's happening there.
• Localhost:8080 is loading slowly. Make it load faster.

賣點之一就是說有「效能追蹤」相關功能。但基層工作人員大家都心知肚明，網頁跑起來慢?

• 要嘛把某些東西拿掉(但是又不准)
• 要嘛加錢升級設備，或是從海外機房搬回本地機房，還有費用砸下去
• 有時候就是一開始隨便做一版來用，然後一直發展沿用到現在，充滿不少歷史遺毒，整個打掉重做? 又沒人想要花費任何代價。

這不是技術問題，而是政治問題和商業問題，為什麼要讓 AI 捅破窗戶紙，把場面搞得這麼難看呢...

廢話講得差不多，總之我去抓了兩邊 MCP 的 tool 清單，開始玩連連看遊戲，有興趣的人參考看看...

• Playwright MCP - Tools
• Chrome DevTools MCP Tool Reference

在 AI 工具裡實際看到的 tool 數量可能會比較少，有些是要再參考 MCP 工具的說明，增加額外的參數，例如 Playwright MCP - Tools 最下面有幾項要另外設定才有的。

分成幾大類來比較:
(Firefox 跟 Safari 17.3 以下可能無法正常顯示以下內容)

提醒: 兩家的文件中有再概述說明每個 tool 是幹嘛的，如果看說明還有疑問，要去看開源的原始碼，

結語

看起來 Chrome DevTools MCP 和 Playwright MCP 各有特色，雖然有些功能重疊，但這不是二個只能選一個的問題，兩個都裝也行，我全都要！

不過 arxiv 有一些研究報告，測試一些主流的 LLM，發現 MCP 裝越多，並不會讓 AI 越強，反而會提高出錯的機率。

• LiveMCP-101: Stress Testing and Diagnosing MCP-enabled Agents on Challenging Queries
• Help or Hurdle? Rethinking Model Context Protocol-Augmented Large Language Models

所以根據需要，謹慎使用吧。

隨著 AI 各種生態系統的快速發展，相信未來會有更多整合性更高的解決方案。現在正是實驗和學習的最佳時機，不妨親自試試這兩個工具，找出最適合你工作流程的組合。

畢竟，最好的工具，就是你真正會用的工具。