AI 編程代理在後端開發表現出色，但面對複雜的前端介面時卻力不從心。核心問題在於：後端的回饋循環完全基於文字（測試、Linting、Type Checking），而前端開發高度依賴視覺回饋。本影片展示了如何透過 MCP 瀏覽器工具為 AI 代理加入視覺回饋循環，讓它像真正的前端開發者一樣「看見」自己的作品，從根本上解決這個問題。

原影片連結：https://www.youtube.com/watch?v=pSritFeoYFo

影片重點

• AI 編程代理寫後端程式碼的能力遠勝於前端，原因在於回饋循環的差異
• 後端的回饋循環完全基於文字（單元測試、Linting、型別檢查），LLM 天生擅長處理文字
• 前端開發的回饋循環高度依賴視覺：開發者需要看 UI、感受動畫、測試互動
• 透過 Chrome DevTools MCP Server 可以讓 AI 代理「看見」瀏覽器畫面
• Claude Code 搭配 MCP 和 Skill 設定，能自動截圖、模擬深色模式並進行 QA 測試
• Playwright MCP 等瀏覽器工具雖然有用，但會消耗大量 context token
• 視覺回饋循環對 AFK（離開鍵盤）AI 編程模式帶來巨大提升

詳細內容

[00:00] 問題定義：AI 擅長後端卻不擅長前端

AI 編程代理目前存在一個明顯的問題：它們寫後端程式碼的能力遠優於前端。這裡指的不是那些簡單的行銷頁面或一鍵生成的 demo，而是複雜的使用者互動、多步驟表單、以及細膩的動畫效果。如果你曾嘗試用 LLM 來處理這些需求，就會發現它的表現不盡理想。

根本原因在於回饋循環（feedback loop）的精確度差異。在後端，你寫程式碼，然後用更多程式碼來測試它，測試結果以文字呈現，整個環境和文件都是文字編碼的——而 LLM 天生就擅長處理文字。

[00:55] 前端回饋循環的視覺本質

前端開發的回饋循環本質上是視覺的。作為前端開發者，你的工作流程是：寫程式碼 → 看 UI 變化 → 再寫程式碼 → 再看 UI。人類開發者不僅在看文字，還在接收視覺資訊——我們會運用天生的設計感來判斷元素位置是否正確，並親自測試使用者互動。

更進一步說，我們不只是處理靜態圖片，還在處理「動態影像」：我們會感受捲動的流暢度、滑鼠懸停時動畫的手感。換句話說，前端開發的回饋循環大部分是視覺的，而非文字的，這正是 AI 編程代理的致命傷。

[01:30] 後端 vs 前端的回饋工具差異

後端的回饋循環可以透過單元測試、Linting、型別檢查來強化，這些都可以設定在 pre-commit hook 中，確保 AI 代理提交程式碼時能看到錯誤訊息。前端同樣可以掛上這些文字工具，但光靠文字還不夠——我們仍然需要視覺元素，讓 AI 代理理解它做了什麼、以及它做的東西是否真的正常運作。

[01:55] 實戰示範：用 Claude Code 做前端 QA

作者展示了他用 AI 重建部落格的實際案例。他請 Claude Code 檢查首頁的 light mode 和 dark mode 是否正常顯示，並傳入本地伺服器位址（localhost:5175）。

Claude Code 透過 Chrome DevTools 自動執行了以下步驟：開啟新頁面並截圖、發現頁面沒有可見的切換按鈕、判斷網站使用系統偏好設定（prefers-color-scheme）、嘗試用 JavaScript 模擬深色模式、確認網站使用 media query 來實現深色模式、最終成功模擬並截圖驗證兩種模式都正常顯示。

[02:55] 設定方式：MCP + Skill

這套視覺回饋系統的設定相當簡單。在專案中加入一個 mcp.json 檔案，指向 Chrome DevTools MCP Server 和一個執行中的瀏覽器 URL。此外，還需要一個 Claude Code Skill 來提供 Chrome 除錯的前置指令。

Skill 的概念類似於你在 CLAUDE.md 檔案中寫的指令，但差別在於代理可以按需載入，而非永遠佔用 context。例如這個 Skill 只需寫上：「使用 Chrome DevTools MCP 前，必須先啟動 headless Chrome 並開啟遠端除錯。」就是這麼簡單。

[03:25] 瀏覽器讓 LLM 更像真正的開發者

有了瀏覽器作為工具，LLM 就更像一個真正的人類開發者了——它可以使用你擁有的所有回饋循環。而且重要的是，LLM 並不是在寫正式的端對端測試，而是在做和人類開發者一樣的事：對自己剛完成的功能做臨時性的手動測試（ad hoc testing），確認功能正常運作。

[03:50] 社群回饋與替代工具

作者在 X（Twitter）上分享這個方法後收到許多回饋。社群指出 Playwright MCP（作者當時使用的工具）表現不是最好，有幾個替代方案值得關注：DevBrowser 被評為不錯的選擇，另一個基於 Playwright 的 MCP 也被推薦。

這些工具的共同問題是「context 消耗過大」——它們會佔用大量 token 來把截圖傳回 LLM，而且 MCP Server 的工具描述非常詳細、工具數量也很多，進一步加重了 context 負擔。此外，Claude Code 也可以透過 Claude Chrome Extension 直接使用 Chrome，但目前在 WSL 環境下不支援。

[04:45] AFK AI 編程的重大提升

最後，作者強調視覺回饋循環對 AFK（離開鍵盤）AI 編程模式帶來的巨大提升。如果你在使用像 Ralph Wiggum 這類 AI 自動循環的設定，為你的前端或全端工作插入一個瀏覽器將是巨大的改進。因為沒有瀏覽器的話，LLM 基本上是在「盲飛」——它看不到程式碼變更實際執行的環境。加入視覺回饋循環後，效果的提升是顯著的。

我的想法

這部影片精準點出了一個許多開發者都有感觸但很少被系統性分析的問題。後端和前端對 AI 代理的難度差異，本質上就是「文字世界」和「視覺世界」的差異。LLM 的世界是文字的，而前端的世界是視覺的——這個鴻溝需要工具來橋接。

MCP 作為橋接方案是目前最實用的方向，但 context 消耗的問題值得關注。隨著影像壓縮技術和多模態模型的進步，這個問題應該會逐步緩解。未來如果 LLM 能原生支援更高效的視覺理解（比如直接處理 DOM 結構而非截圖），前端的 AI 輔助開發體驗可能會有質的飛躍。

另一個值得思考的點是：這套方法目前主要解決的是「驗證」層面的問題（確認結果是否正確），但前端開發中更困難的「創作」層面（設計直覺、使用者體驗判斷）仍然是 AI 的弱項。不過至少有了視覺回饋，AI 可以不斷嘗試和修正，這已經是很大的進步了。