功能做完了不代表做對了。在軟體開發裡，「能跑」和「沒 bug」之間有很大的距離。這一篇講的是我怎麼用自動化工具來驗證網站的功能、找出問題、以及確保程式碼品質。
Playwright MCP：瀏覽器裡的自動化操作
Playwright MCP 是這個專案裡用得最頻繁的測試工具之一。它讓你可以用程式控制瀏覽器——導覽頁面、點擊按鈕、填寫表單、截圖、檢查 DOM 結構，全部自動化。
跟傳統的 E2E 測試框架不同，Playwright MCP 是以 MCP server 的形式運作，直接整合在 Claude Code 的工作流程裡。你不需要寫測試腳本，而是用自然語言描述你要測試什麼，工具就會操作瀏覽器執行。
我最常用的幾個操作：
browser_navigate：開啟指定的 URL，驗證頁面是否正確載入
browser_snapshot：擷取頁面的 accessibility snapshot，比截圖更結構化，可以看到所有元素的 role、ref、文字內容
browser_click + browser_fill_form：模擬使用者操作，測試互動功能
browser_evaluate：在頁面上執行 JavaScript，處理那些標準操作做不到的事（比如操作 contenteditable 的 TipTap editor）
舉個實際的例子：測試管理後台的文章發布流程。Playwright MCP 可以自動開啟新增文章頁面、填入標題和內文、選擇分類和系列、點擊翻譯按鈕、等待翻譯完成、最後儲存。整個流程跟人工操作一模一樣，但不會漏掉任何步驟。
QA Skill：系統化的找 bug 流程
QA skill 提供了一套系統化的品質檢查流程。不是隨機亂點，而是有結構地檢查每個功能模組。
它的運作方式是：先列出所有需要檢查的功能點，然後逐一執行。對於每個功能點，它會：
描述預期行為
執行實際操作（通常搭配 Playwright MCP）
比對實際結果和預期結果
如果有差異，記錄為 bug 並附上截圖或 snapshot
這套流程最大的好處是覆蓋率。人工測試很容易忽略邊界情況（比如空狀態、多語系切換、長文字溢出），但系統化的流程會把這些都列進檢查清單。
在這個專案裡，QA skill 幫我找到了好幾個不容易發現的 bug：
EN/JA 的 series 頁面顯示 0 篇文章（因為 seriesId 跨語系的關聯邏輯有誤）
文章詳情頁的 series breadcrumb 顯示的是 zh-TW 的 series 名稱而非當前語系
某些頁面在行動裝置寬度下佈局錯位
Review 與 Code Review：程式碼品質把關
找到 bug 並修好之後，還需要確認修復本身的品質。這裡用到兩個不同層次的審查工具。
review skill 做的是功能層面的審查——修改是否完整解決了問題、有沒有引入新的問題、邊界情況是否都考慮到了。
code-review skill 做的是程式碼品質層面的審查——程式碼風格是否一致、有沒有潛在的效能問題、錯誤處理是否完善、是否遵循了專案的慣例。
兩者的差別在於 review 關注「做對了嗎」，code-review 關注「寫好了嗎」。在這個專案裡，每次完成一個功能或修復一個 bug，都會經過這兩層審查。
一個具體的例子：修復 series 跨語系文章查詢的 bug 時，review 確認了 EN/JA 頁面現在能正確顯示文章列表和 series 名稱；code-review 則檢查了新增的 translationGroupId 查詢邏輯是否高效、是否有適當的 fallback 處理。
驗證的節奏
回頭看整個驗證流程，它形成了一個清楚的節奏：
用 Playwright MCP 自動化操作，快速驗證基本功能
用 QA skill 系統化地檢查所有功能點，找出問題
修復問題後，用 review 確認功能正確
最後用 code-review 確保程式碼品質
這個流程不是做一次就結束，而是在每次重大修改後都會跑一遍。聽起來很繁瑣，但因為大部分都是自動化的，實際花費的時間比想像中少很多。
下一篇是這個系列的最後一篇，會講部署與維運——怎麼把做好的東西從本地推到線上，以及上線後的維護策略。