AI 不再等你貼報錯給它：Chrome DevTools MCP 讓模型自己打開瀏覽器點按鈕

2026年10月19日，掘金作者「濤濤ing」刊出一篇長文，標題下得很直白：Chrome DevTools MCP 正式可用，AI 終於能自己開瀏覽器調試你的頁面了。這篇文章在開發者社羣裡被轉發與收藏，討論的重點不是又一個模型升級，而是一個更實際的問題：AI 寫完的程式碼，到底跑不跑得起來？

以前的 AI，像被蒙住眼睛的工程師

文章用了一個很有畫面的比喻。過去的前端除錯流程是這樣的：使用者回報「點提交按鈕沒反應」，你打開瀏覽器重現問題，開 Console 看報錯，開 Network 發現請求回了 401，再開 Elements 才看到按鈕被一層透明遮罩擋住了。

接著你把這三條資訊複製貼給 AI，等它給方案。作者形容，這時的 AI 像一個被蒙住眼睛的工程師，只能靠你轉述來猜問題在哪。大量的時間，其實花在「人替 AI 採集資訊」這件事上。

這個描述之所以引發共鳴，是因為它戳中了不少開發者的日常。這種「讀完長文想立刻收藏」的反應，也出現在其他前端實戰文的傳播裡，例如先前在掘金被大量收藏的半截 JSON 邊收邊渲染的工程指南，同樣是把一個日常痛點講到底的長文。

MCP 是什麼，這次又補上了哪一塊

先把名詞補上。MCP 全名 Model Context Protocol，是一個開放協定，讓 AI 工具能連接外部資料源與工具。作者的比喻是「AI 與工具之間的 USB 介面」。在 MCP 出現之前，AI 能看的就是你專案裡的檔案和你貼上的報錯，它看不到瀏覽器裡實際發生了什麼。

Chrome DevTools MCP 做的事，是把 Chrome DevTools 變成一個 AI 可以呼叫的工具伺服器。依文章整理，它暴露的能力涵蓋幾個層面：

• 頁面導航與截圖：打開 URL、前進後退、擷取視口
• DOM 檢查：元素結構、計算樣式、盒模型、可存取性樹
• 控制臺：讀取 console 日誌、錯誤、警告
• 網路：請求列表、回應標頭、狀態碼、耗時、失敗原因
• JavaScript 執行：在頁面上下文求值，讀取執行時狀態
• 效能與 Lighthouse：效能追蹤、Long Task、LCP、CLS、INP 等訊號與審計清單
• 互動模擬：點擊、輸入、滾動、懸停

一句話總結：以前你替 AI 看瀏覽器，現在 AI 自己看。

作者強調，這補上了 AI 編程流程裡一直缺的那一塊，也就是驗證。AI 生成程式碼的能力在2026年已經夠強，真正卡住落地效率的並非寫不出來，而是寫出來之後沒人驗證。

接入方式不複雜，但有一條但書

配置上遵循標準 MCP 寫法。以 Claude Code 為例，一行指令把 chrome-devtools 加進去；在 Cursor 則是在 MCP 設定裡加一個 server。設定完成後，你可以直接在對話裡說：打開 localhost:3000 的登入頁，點登入按鈕，讀控制臺錯誤和網路請求，告訴我為什麼沒有跳轉。AI 會按步驟呼叫工具，導航、找按鈕、點擊、讀 Console、讀 Network，最後給出結論。

不過文章也留了一條但書：它操作的是你本地的 Chrome 實例。這代表它看得到你本地開發環境裡的登入態、Cookie 與 LocalStorage。這既是能力，也是風險。這類「工具會動手」的討論，在近一年的開發者社羣裡並不陌生，像是先前騰訊微信團隊開源的會自己產出 Word 檔的知識庫 WeKnora，也走紅於同樣的「AI 開始幹活」氛圍。

圍觀的重點：流程被壓縮了

回到原作者的觀察。典型的除錯流程有七步，Chrome DevTools MCP 改變的是第二到第五步。AI 可以自己開頁面、自己點按鈕、自己讀 Console 與 Network。它從只能推理，變成可以觀察和驗證。

至於安全面與更多使用細節，來源文章有預告但本次引文的內容在此截斷，具體風險討論以原文後續段落為準，這裡不替它補話。

一篇九分鐘的長文，能在技術社羣被收藏，靠的從來不是新名詞，而是它把「你每天都在做、卻沒想過可以不用自己做」的那段流程，攤開來給所有人看。至於 AI 接手瀏覽器之後，開發者自己要做什麼，大概是下一步才會長出答案的問題。