從人工測試到閉環開發：AI 幫你「長出雙眼」，自己寫程式、自己抓 Bug 一句「Claude，啟用 Playwright」就能讓 AI 自動測試、截圖、修復前端版面？這不是科幻，而是正在引爆開發社群的真實革命。 前言：那個讓數百位開發者狂讚的貼文 最近在開發者討論區上，一則標題極度簡潔的貼文引發了熱烈迴響——「直接叫 Claude 啟用 Playwright 就對了」。短短一句話，讓無數開發者驚呼：這替他們省下了無數個爆肝的夜晚。 為什麼這麼有魔力？因為它解決了一個存在已久、卻始終沒有被完美克服的痛點：AI 能寫程式，但它看不到畫面。 第 1 章｜開發者的真實痛點：我恨透前端除錯 有網友坦言，自己極度討厭前端開發，簡直打從心底抗拒。每次調整一個按鈕顏色、對齊一個邊框，都要在程式碼和瀏覽器之間來回切換無數次。這番話一語道破了無數後端工程師的心聲。 他原本只是抱著試試看的心態下載了 Claude Code（Claude 的命令列工具），結果這個好奇心讓他發現了新大陸。 他敏銳地察覺到：Claude Code 的本質不只是一台會聊天的文字視窗，它是一個真真實實運作在你電腦底層的 Node 執行環境。 這代表什麼？代表 AI 突然有了「雙手」。 第 2 章｜AI 如何「長出雙眼」？ 只要在你的應用程式工作區（workspace）裡，把測試框架 Playwright 以及極速執行環境設定好，魔法就發生了： Claude 可以自己導航到 localhost 親自幫你截圖 直接與前端網頁介面進行點擊與互動 為了讓大家更好理解，我們可以用一個比喻： 原本廚房裡有一位蒙著眼的天才主廚（大型語言模型）。他能照著食譜寫出完美的程式碼邏輯，但他自己卻看不到最後端上桌的擺盤長什麼樣子——完全不知道 UI 有沒有跑版。 而這個突破性的做法，等於是幫這位天才主廚解下了眼罩。他現在能親自看見、並且試吃自己做出來的視覺饗宴了。 過去，文字生成與視覺驗證之間一直存在一道極難跨越的斷層。AI 可以在幾秒內寫出幾百行完美的邏輯，但它根本不知道那個「送出」按鈕是不是被其他圖片遮住了。 當 AI 在您的工作區中具備了自主執行的權限與能力，它就不再只是一台被動的打字機，而是真正進化成一個能主動出擊、自己看自己修的自動化代理人。 第 3 章｜閉環開發模式：效率的指數級飛躍 這就是網友們公認的最大贏家——閉環開發模式。 過去，我們寫完程式還要自己打開瀏覽器，點點看有沒有壞掉。但現在： 每次你修改完程式碼，Claude 會自動觸發 Playwright 去跑測試腳本，自己截圖比對。 最誇張的是：在人眼甚至還沒打開瀏覽器之前，AI 就已經默默把回歸錯誤抓出來，並且可能已經把程式碼修好了。 更進階的實戰：在 Godot 遊戲引擎裡開「後門」 有一位正在開發 Godot 應用程式的網友，因為厭倦了手動截圖丟給 Claude 修復排版錯誤，於是他直接在架構裡為 Claude 開了一個專屬的後門通訊埠。 透過這個後門，AI 可以自己下指令截圖、在應用程式裡四處導航。為了把效率逼到極限，他甚至要求 AI 一次修復多個排版問題，讓 AI 在背景自己反覆測試與修正，直到畫面完美為止。 第 4 章｜AI 的視覺盲點：它真的懂「好看」嗎？ 聽起來很完美，但事情沒有這麼簡單。有網友無奈地表示：Claude 結合 Playwright 在某些時候簡直像是瞎了一樣。 舉例來說： 明明網頁上的文字已經超出了按鈕的邊界，整個排版擠成一團，AI 看了截圖卻還是沾沾自喜地回報：「看起來棒極了，沒有任何問題。」 這種將功能與美感混淆的現象，是目前 AI 視覺驗證最大的盲點。 結論很明確： ✅ AI 在功能性驗證上非常強大——按鈕能不能按、購物車流程走不走得通，它測得又快又好。 ❌ 但在美感判斷或極度細微的視覺像素對齊上，它還是有極限。 人類的審美把關與最終確認，依然是整個開發流程中不可或缺的靈魂環節。 第 5 章｜Token 成本戰：精打細算的 AI 經濟學 這麼強大的自動化測試，背後消耗的可是白花花的 Token。如何享受自動化紅利，同時避免 API 預算徹底失控？ 討論區裡的網友們都是精算大師，大家為了省錢絞盡腦汁。幾個主流策略： 方案 優點 缺點 Playwright MCP 上下文豐富，結構完整 Token 消耗巨大 Playwright CLI 只回傳終端機文字，相對省錢 缺少上下文結構 Vercel AI Agent Browser 專為 AI 打造的輕量級工具，幾乎不耗 Token 功能較簡化 Claude 官方 Chrome 擴充 整合原生，不佔上下文空間 常斷線、速度慢 Cypress 底層架構比 Playwright 更快 缺乏 Safari 原生支援 網友們也強烈建議：透過 claude.ignore 這樣的設定檔，嚴格把關 AI 能讀取的檔案，避免它把專案裡幾百個無關緊要的日誌檔案通通讀一遍——那對成本來說絕對是一場災難。 每一個提示詞設計、每一次自動化呼叫，都是真金白銀的支出。我們必須在 AI 的自主性與預算控制之間，找到最完美的黃金平衡點。 第 6 章｜落地實戰：打造輕量級自動化測試帝國 對台灣中小企業來說，這套模式有極高的參考價值。一位網友受到 Y Combinator 執行長的觀點啟發，打造了一套令人驚豔的持續整合流程： 讓 Claude 仔細閱讀需求，詳細描述不同使用者在 App 中的操作路徑 讓 AI 直接把這些路徑轉換成 Playwright 的自動化測試腳本 把腳本整合進 GitHub Actions 或 GitLab CI 程式碼一推上去，遇到錯誤或測試失敗，系統就會自動截圖並拋給 Claude Claude 讀取錯誤日誌，修復程式碼 最後發一個包含截圖的 Pull Request，讓人類審查 即使是較大型的應用程式，跑完這套 CI 流程大約只需要 20 分鐘。雖然不是即時，但這 20 分鐘卻能完美充當輕量級的回歸測試。 那位網友驕傲地表示：這套流程讓他達成了「零人工導航測試」的最高境界——工程師再也不用自己狂點滑鼠了。 對台灣中小企業的意義：科技平權 許多台灣中小企業預算有限，甚至根本沒有編制專職的 QA 團隊。這套 AI 協作測試的新思維，大幅降低了開發團隊在測試上的日常負擔： 審核者不需要再浪費寶貴的時間去做枯燥的手動點擊測試 而是能透過 AI 整理好的一覽表與截圖，輕易且迅速地抓出錯誤 台灣中小企業本來就以靈活性與超強的適應力著稱。如果我們的團隊能迅速擁抱這種 AI 協作測試，將開源或輕量級的工具整合進日常開發中，就能用極低的人力與時間成本，展現出完全不輸給矽谷大型科技公司的軟體品質與產品迭代速度。 這正是彎道超車的絕佳機會。 第 7 章｜未來的軟體工程師：從「碼農」到「產品導演」 最後，讓我們拋出一個值得深思的問題： 如果大型語言模型已經可以寫出邏輯程式碼、自己打開瀏覽器測試、自己修復視覺排版，甚至在發現畫面錯誤時還懂得自己去修正排版——那麼未來的軟體工程師，是不是將不再是那個整天對著鍵盤寫程式的人？ 我們會不會全面蛻變，成為一位負責制定商業規則、定義系統邊界、與審視最終品味的「產品導演」？ 這是一個非常值得你在擁抱 AI 工具的同時，繼續深思的美妙課題。 我的評價與看法 1. 這不是「未來」，而是「現在」 過去我們談 AI 輔助開發，多半停留在「程式碼自動完成」或「對話式除錯」。但 Claude + Playwright 的閉環模式，第一次讓 AI 真正具備了視覺回饋能力。這意味著 AI 不再憑空猜測 UI 的狀態，而是能像人類一樣「看到」畫面並做出反應。 2. 優點非常具體，但盲點也很真實 優點： 大幅降低手動回歸測試的工時 實現「修改 → 驗證 → 修復」的全自動迴圈 對沒有專職 QA 的團隊來說，是極低成本的安全網 盲點： AI 無法真正理解「美觀」與「使用者體驗」，只會比對結構性差異 Token 成本可能失控，需要仔細設定範圍與工具選型 對於複雜的互動邏輯或動態內容，Playwright 腳本的穩定性仍依賴人工調教 3. 給開發者與企業主的具體建議 不要急著全面取代人工測試。比較務實的做法是：先讓 AI 負責回歸測試與冒煙測試，把複雜的探索性測試留給人類。 嚴格控制 Token 預算。善用 CLI 模式、輕量級工具（如 Vercel AI Agent Browser），並用 .ignore 檔案限制 AI 的讀取範圍。 把 AI 當成「實習生」來管理。給它明確的任務邊界，讓它反覆執行，然後由人類做最終審核。 4. 最終的贏家，是懂得「導演」AI 的人 回到那個「產品導演」的比喻——我認為這不是誇大，而是正在發生的轉變。當 AI 可以執行具體的編碼與測試任務，人類的核心價值將越來越集中在： 定義什麼是「正確」 判斷什麼是「好」 設計系統邊界與商業邏輯 如果你只會「寫程式」，AI 確實可能取代你。但如果你懂得「指揮 AI 寫程式」，你將擁有前所未有的槓桿。 你準備好從「碼農」升級成「產品導演」了嗎？ 歡迎在留言區分享你的看法與實戰經驗。