如果你現在有在玩 vibe coding，或開始讓 Claude Code、Codex、Cursor 這類 AI agent 幫你改網站、改前端、改 WordPress 外掛，我會很直接地說：Playwright 會變成必學工具。
原因不是因為每個人都要變測試工程師，而是 AI agent 很會寫程式，但它不一定真的知道「畫面有沒有壞」、「按鈕能不能點」、「表單送出後是不是成功」、「手機版是不是跑版」。你只跟 AI 說「幫我改好」，它可能真的改了，但改完之後有沒有驗證？這才是 AI 開發時代真正麻煩的地方。
Playwright 的價值，就是把「我用眼睛看一下」變成一套可以被 AI agent 重複執行的瀏覽器測試流程。它不只跑測試，也能開瀏覽器、點按鈕、填表單、截圖、錄 trace，讓 AI 比較有機會看懂你的畫面到底發生什麼事。
為什麼 vibe coding 更需要 Playwright？
以前我們自己寫程式，至少知道剛剛改了哪一段。AI agent 不一樣，它可能一次改三個檔案、五個元件、十幾個 CSS class。你看 diff 看得懂是一回事，前台真的可不可以用又是另一回事。
vibe coding 最容易發生的問題，是「感覺完成了」。AI 回你一段很漂亮的總結：
- 已修正 RWD。
- 已完成表單驗證。
- 已優化 UI。
- 已新增錯誤提示。
但你真的打開頁面才發現：手機版按鈕被蓋住、表單送不出去、彈窗關不掉、某個文字在小螢幕爆版。這些問題不是 AI 不聰明，而是它缺少一個穩定的「看畫面與驗證畫面」流程。
AI coding 的下一個基本功，不是只會寫 prompt，而是讓 AI 改完之後可以自己跑瀏覽器、自己檢查畫面、自己回報哪裡失敗。
Playwright 到底在測什麼？
Playwright 是 Microsoft 維護的端對端測試框架，可以控制 Chromium、Firefox、WebKit，在本機或 CI 裡跑瀏覽器測試。官方文件也明確把它定位成 modern web apps 的 end-to-end test framework，內建 test runner、assertions、parallelization 和 trace 等工具。
用白話講，它可以幫你測這些事情：
- 首頁是否正常載入。
- CTA 按鈕是否看得到、點得到。
- 表單能不能填寫與送出。
- 登入、結帳、查詢、搜尋這類流程是否正常。
- 手機、桌機、不同瀏覽器是否都能用。
- 頁面截圖是否跟預期差太多。
- 測試失敗時留下 trace，方便回放問題發生的過程。
這些事情對一般工程師重要，對 AI agent 更重要。因為 agent 不能只靠「我覺得改好了」，它需要一個外部驗證機制。
AI agent 怎麼「看懂」我們的畫面？
很多人以為 AI agent 看網頁，就是像人一樣看 screenshot。這是其中一種方式，但不是唯一方式，也不一定是最穩的方式。
以 Playwright MCP 來說，它的重點是讓 LLM 透過結構化的 accessibility snapshot 跟網頁互動。也就是說，AI 不一定要靠純視覺模型看一張圖，它可以讀到頁面上的按鈕、連結、輸入框、文字區塊、角色與可操作元素。
這件事很關鍵。因為對 AI agent 來說，「畫面」不只是像素，而是一棵可以理解的介面結構：
- 這裡有一個按鈕，文字是「免費網站健檢」。
- 這裡有一個輸入框，label 是「Email」。
- 這裡有一段錯誤訊息，內容是「請填寫必填欄位」。
- 這裡有一個導覽列，裡面有「SEO 服務」「AI SEO / GEO」。
AI 讀得懂這些結構，就比較能穩定操作網頁，而不是猜「畫面左上角那個藍色東西應該可以點」。
Playwright 讓 AI agent 可以做的 5 件事
1. 真的打開頁面，而不是只看程式碼
AI 看程式碼可以推測畫面，但推測就是推測。Playwright 可以讓它真的打開瀏覽器，確認頁面是否載入、文字是否出現、按鈕是否可見。
2. 模擬使用者操作
很多 bug 不是靜態畫面看得出來的，而是使用者點下去才會發生。Playwright 可以模擬 click、fill、select、submit，讓 AI agent 驗證整個使用流程。
3. 用 locator 讓操作更穩
Playwright 的 test generator 會優先產生 role、text、test id 這類 locator。這比叫 AI 用「第 3 個 div 裡面的第 2 個 button」穩定很多。對 AI agent 來說，穩定 locator 就是它能不能長期可靠操作畫面的關鍵。
4. 失敗時留下 trace，不用靠猜
Playwright Trace Viewer 可以記錄測試過程，包含每一步操作、DOM snapshot、網路請求、console、錯誤資訊。這對 AI agent 很有幫助，因為失敗時它可以根據 trace 判斷是 selector 壞了、資料沒載入，還是 UI 被蓋住。
5. 做視覺回歸測試
Playwright 支援 screenshot comparison，可以把現在畫面跟基準圖比較。這對網站改版、Elementor 區塊、Landing Page、表單頁很實用。AI agent 改 CSS 時，至少有機會知道「畫面跟之前差太多」。
最小可用 Playwright 測試範例
你不需要一開始就寫很複雜。先讓 AI agent 能驗證一個頁面是不是正常，就已經很有價值。
import { test, expect } from '@playwright/test';
test('首頁 CTA 可以正常出現', async ({ page }) => {
await page.goto('https://iambigd.tw/');
await expect(page.getByRole('link', { name: '免費網站健檢' })).toBeVisible();
});
這段看起來很簡單，但意義很大。因為它把「我打開首頁看一下 CTA 有沒有出現」變成一個可以每天跑、每次部署後跑、AI 改完後也能跑的檢查。
如果你要測表單，可以再往下走：
test('聯絡表單基本欄位可以填寫', async ({ page }) => {
await page.goto('https://iambigd.tw/contact');
await page.getByLabel('姓名').fill('測試使用者');
await page.getByLabel('Email').fill('[email protected]');
await page.getByLabel('訊息').fill('我想了解網站健檢服務');
await expect(page.getByRole('button', { name: /送出|提交|傳送/ })).toBeVisible();
});
這種測試不一定要一開始就真的送出表單。先確認欄位看得到、填得進去、送出按鈕存在，就能抓到很多低級但致命的 UI 問題。
我會怎麼把 Playwright 放進 AI 開發流程？
如果你是用 Claude Code、Codex 或 Cursor，我會建議把 Playwright 放進工作流，而不是把它當成最後才補的測試。
第一步：先列出關鍵使用流程
- 首頁 CTA 是否正常。
- 聯絡表單是否能填寫。
- 主選單是否有正確項目。
- 文章頁 H2、FAQ、內連是否正常顯示。
- 手機版是否沒有重大遮擋。
第二步：讓 AI 先寫測試，再改功能
這點跟傳統 TDD 很像，但在 AI 時代更實際。你可以跟 agent 說：「先用 Playwright 寫一個測試，描述這個功能應該怎麼運作，測試失敗後再修改程式。」
第三步：改完一定跑測試
AI agent 每次改 UI、表單、路由、登入、結帳流程後，都應該跑相關 Playwright 測試。測試沒過，不要讓它用文字說「應該可以了」。
第四步：用 trace 和 screenshot 回報問題
當測試失敗時，不要只回「失敗」。比較好的 agent 回報應該包含：哪一步失敗、預期看到什麼、實際看到什麼、有沒有 screenshot 或 trace 可以追。這樣人類接手時才不會像拆盲盒。
Playwright MCP 跟一般 Playwright 測試差在哪？
一般 Playwright 測試比較像固定腳本：你寫好 test spec，之後重複跑。Playwright MCP 則比較像給 AI agent 一組瀏覽器操作工具，讓它在任務中探索頁面、點擊元素、讀取結構，再決定下一步。
| 工具 | 適合用途 | 我的看法 |
|---|---|---|
| Playwright Test | 固定流程、回歸測試、CI 驗證 | 必學，因為它能把人工檢查變成可重複測試 |
| Playwright Codegen | 快速錄製操作、產生 locator | 很適合新手和 AI agent 起手式 |
| Playwright Trace Viewer | 測試失敗後回放與 debug | AI 改壞畫面時，這是找原因的關鍵 |
| Playwright MCP | 讓 AI agent 動態操作瀏覽器 | 適合探索式自動化，但要注意權限與邊界 |
如果你只是要穩定驗證網站，先學 Playwright Test。等你想讓 agent 自己探索頁面、修測試、回報 UI 問題，再研究 Playwright MCP。
這跟 Loop Engineering 有什麼關係？
我前面寫過 Loop Engineering，重點是 AI 不應該只靠一次 prompt，而是要有「執行、驗證、記錄狀態、下一輪」的循環。
Playwright 剛好就是 AI coding loop 裡的「驗證眼睛」。
- AI agent 修改前端或網站內容。
- Playwright 打開頁面。
- 測試 CTA、表單、選單、RWD、FAQ。
- 失敗時截圖或留下 trace。
- AI 根據錯誤修正。
- 再次執行測試。
- 超過次數或風險太高就交給人。
這個 loop 跑得起來，AI 才不只是幫你寫程式，而是開始接近「能自己檢查自己工作成果」的協作者。
如果你在看 Codex App GUI、Claude Cowork、Claude Code 這類工具，Playwright 就是把這些 agent 從「會改」推進到「改完能驗證」的那一塊拼圖。
中小企業或 WordPress 站長要學到什麼程度？
你不一定要變成測試工程師。對中小企業和 WordPress 站長來說，我會建議先學到這個程度就好：
- 會安裝 Playwright。
- 會用 Codegen 錄一段基本流程。
- 會寫 `expect(…).toBeVisible()` 這類基本 assertion。
- 會測首頁、聯絡頁、文章頁、表單頁。
- 知道測試失敗時怎麼看 trace 或 screenshot。
- 知道哪些測試可以交給 AI agent 跑，哪些一定要人看。
做到這樣，你就已經比「只靠眼睛巡網站」穩很多。尤其是網站選單、CTA、FAQ、表單、文章樣式這些東西，一旦開始用 AI 協助修改，就很需要自動化測試守住底線。
我的結論：AI 越會寫，測試越重要
以前很多小團隊不寫測試，是因為人力不夠，覺得測試很花時間。AI 時代反而相反。因為 AI 寫程式太快，改畫面太快，如果沒有測試，你根本追不上它到底改壞了什麼。
Playwright 不是讓你變慢，而是讓你敢讓 AI 跑快一點。它幫你建立一條底線：AI 可以改，但改完要打開瀏覽器驗證；AI 可以調 UI，但調完要看 CTA 還在不在；AI 可以幫你做 vibe coding，但不能只靠 vibe 收工。
所以這篇如果只記一件事，我會希望你記這句：
在 AI agent 時代，Playwright 不是測試工程師專用工具，而是讓 AI 看懂畫面、驗證畫面、避免亂改網站的基本安全帶。
常見問題 FAQ
Playwright 是什麼？
Playwright 是一套端對端瀏覽器測試框架，可以控制 Chromium、Firefox、WebKit 來測試網頁流程，例如載入頁面、點擊按鈕、填寫表單、檢查文字、截圖與產生 trace。它很適合用來驗證 AI agent 改完網站後是否真的正常。
為什麼 vibe coding 需要 Playwright？
vibe coding 很容易讓 AI 快速改出功能，但也容易忽略前台畫面、互動流程和手機版細節。Playwright 可以讓 AI 改完後自動打開瀏覽器驗證，避免只靠文字總結就以為功能完成。
AI agent 是用 screenshot 看懂網頁嗎？
不一定。AI agent 可以看 screenshot，但 Playwright MCP 更常用 accessibility snapshot，讓模型讀到按鈕、連結、輸入框、文字與角色等結構化資訊。這通常比只看像素更穩，也更適合自動化操作。
WordPress 站長需要學 Playwright 嗎？
如果你會讓 AI 幫你改網站、改 Elementor、改選單、改文章樣式或表單流程，我會建議至少學基本 Playwright。你不用成為測試工程師，但要能驗證首頁 CTA、聯絡表單、文章頁 FAQ、手機版顯示這些關鍵流程。
Playwright MCP 跟 Playwright Test 要先學哪個？
先學 Playwright Test。它比較適合建立穩定、可重複的測試。Playwright MCP 比較適合讓 AI agent 動態探索網頁與操作瀏覽器。基礎測試流程穩了，再導入 MCP 會比較安全。
