用 AI 視覺代理（Computer Use）完全取代 Playwright？談談前端自動化測試的喧囂與實務抉擇
隨著 Anthropic 的 Computer Use API 與各類多模態大語言模型（LLM）的爆發，軟體工程界掀起了一股「AI 視覺代理（Agentic Testing）將完全取代傳統測試程式碼」的輿論熱潮。許多宣傳聲稱，未來開發者不再需要手寫任何 Playwright 或 Cypress 腳本，只需給 AI 一句指令，AI 就能自己看著螢幕、像人類一樣點擊與驗證網頁。
這幅「全自動、無代碼」的遠景確實極具吸引力。然而，當這股技術熱潮落實到每天需要頻繁運行、且要求高穩定度的企業生產環境時，事情真的有這麼簡單嗎？AI 視覺代理真的已經準備好完全取代 Playwright 了嗎？
本文將剝離市場行銷的喧囂，站在中立的工程視角，深入分析「AI 視覺代理」、「自適應自我修復（Self-Healing）」與「確定性代碼驗證（Playwright/Cypress）」這三大前端驗證流派的優劣勢，幫助開發團隊根據自身的專案場景，做出最務實的技術抉擇。
1. AI 視覺代理（Computer Use）：探索性測試的革命，但離生產回歸測試尚遠
AI 視覺代理技術的本質是「感知與自主決策」。AI 透過不斷擷取網頁畫面、將截圖送給多模態模型分析，並計算操作座標來驅動瀏覽器。
優勢分析
- 極低的編寫與維護門檻：測試人員完全不需要了解 DOM 結構，也不用手寫任何 CSS 定位器（Selectors）。只需以自然語言下達任務，AI 就能自主探索網頁並完成操作。
- 跨平台與探索性測試：AI 不限於單一網頁，它可以跨應用程式、跨視窗進行端到端的驗證，非常適合用來進行「探索性測試（Exploratory Testing）」，找出人類未曾預料到的邊界錯誤。
痛點與劣勢
- 高昂的 Token 財務成本：每次操作都需要傳送高解析度截圖，隨時間累積的對話上下文（Context）會使 Token 消耗呈雪崩式增長。在 CI/CD 中頻繁跑測試，會產生高昂的 LLM API 帳單。
- 非確定性的隨機失敗（Flaky Tests）：模型天生存在隨機性。AI 偶爾會因為微小的視覺變更（如載入中的動畫多跑了半秒）而點錯坐標，這在最講求「100% 可重現性」的自動化測試中是致命傷。
- 高延遲與本地阻塞：AI 的「截圖-傳送-思考-點擊」循環需要數秒到數十秒的推理時間。此外，在本地調試時，部分代理會直接強佔作業系統的游標與視窗焦點，阻礙開發人員同時進行其他工作。
- 資安合規紅線：將包含敏感資料（PII）或測試環境密鑰的截圖傳送給第三方公有雲模型，是許多注重合規性（如金融、醫療）企業的禁區。
2. 確定性代碼驗證（Playwright/Cypress）：極速且安全的防守基石
傳統的代碼驗證框架依靠工程師手寫精準的 Selector 與 Assertion，並運行在無頭瀏覽器（Headless Browser）中。
優勢分析
- 百分之百的可重現性：代碼如何寫，瀏覽器就如何執行，沒有隨機性，結果完全可預期，非常適合作為 CI/CD 流程中的回歸測試（Regression Testing）。
- 極致的速度與效率：直接在記憶體中操作 DOM 樹，毫秒級響應，整個測試套件通常可在數分鐘內執行完畢，且不產生任何外部 API 呼叫的 Token 費用。
- 完全的本地安全隔離：測試代碼與畫面完全保留在本地主機或企業內部的私有 CI 伺服器中，資料絕不外流。
痛點與劣勢
- 高昂的編寫與維護成本：工程師必須耗費時間編寫測試代碼。當前端介面頻繁重構或樣式大幅變更時，Selector 容易失效，導致測試腳本頻繁崩潰（Test Flakiness），需要人工反覆修復。
3. 自適應自我修復（Self-Healing / Hybrid）：結合兩者優勢的中間流派
為了結合 Playwright 的速度與 AI 的靈活性，近年許多團隊採用了「自適應定位器與自我修復」的混合模式。
優勢分析
- 降低維護難度：以傳統的 Playwright 或 Cypress 程式碼為骨架，但引入機器學習/AI 作為運行期的容錯機制。當指定的 Selector（如
#submit-btn）失效時，AI 會實時分析 DOM 樹特徵，自動尋找最相似的元件完成操作，並在測試後自動產生修正建議。 - 保留速度與安全性：大部分時間依然是本地端的高速代碼執行，只有在發生異常時才觸發 AI 介入，因此 Token 成本與延遲皆在可控範圍內。
痛點與劣勢
- 依賴特定工具鏈：通常需要導入第三方的測試平台（如 Mabl、Testim.io 等），可能涉及額外的訂閱授權費用，且較難完全在純開源的環境下靈活定製。
4. 實務抉擇：我的專案應該選哪一個？
沒有一個方案是完美的，最佳的技術決策取決於您專案的業務特徵、團隊編制與財務預算。
| 評估維度 | AI 視覺代理 (Computer Use) | 自適應自我修復 (Hybrid) | 確定性代碼 (Playwright) |
|---|---|---|---|
| 執行成本 | 極高（每輪測試皆需 LLM API 費用） | 低至中等（僅在出錯修復時觸發 AI） | 極低（本地運行，零 Token 費用） |
| 執行速度 | 慢（受限於截圖上傳與模型推理延遲） | 快（底層依然是 Headless 程式碼執行） | 極快（記憶體級 DOM 操作） |
| 可重現性 | 中等至偏低（存在模型隨機性） | 高（有程式碼骨架把關） | 極高（完全確定性） |
| 數據安全性 | 較低（截圖需外傳至公有雲模型） | 高（資料多保留在本地，僅 metadata 輔助） | 極高（完全本地隔離運行） |
| 維護成本 | 極低（無 Selector 需要維護） | 低（AI 會在運行期自動修復失效定位） | 高（介面變更時需人工重寫代碼） |
決策建議
- 選擇「AI 視覺代理（Computer Use）」：如果您的團隊缺乏專業的測試工程師，專案屬於初期的產品雛形（MVP），且對測試運行速度與隱私安全沒有極端要求，希望以最快速度實現端到端的覆蓋。
- 選擇「自適應自我修復（Hybrid）」：如果您的產品介面變更極其頻繁，導致工程師每天花大量時間修復崩潰的測試，希望在不犧牲 CI 速度的前提下降低維護成本。
- 選擇「確定性代碼（Playwright/Cypress）」：如果您身處金融、醫療等有嚴格資安合規紅線的行業，或者您的專案每日需要跑數千次 CI/CD 回歸測試，對執行速度、可重現性與預算有著嚴苛要求。
不論技術如何喧囂，理解每項工具的邊界，並將 AI 定位在「開發期加速撰寫代碼，運行期回歸確定性引擎把關」的務實軌道上，才是當前軟體工程最穩健的落地實踐。