AI 寫的網頁交付前，先測這五個行為

AI 寫的網頁能打開，接下來怎麼驗收？拿一個儲存在瀏覽器本地的待辦頁來說，可以沿着五個具體場景檢查。

它們不用覆蓋整個項目，卻能抓住不少「第一次點起來沒問題，刷新就壞了」的情況。

最後一項尤其容易漏掉。JSON.parse('{}') 不會報錯，但後續程式碼如果把它當陣列用，仍可能出問題。

先在演示副本裏構造異常

前三項可以直接點。後兩項請在複製的演示項目裏準備異常資料，不要拿真實資料試覆蓋。

讓 Codex 做時，可以把任務寫完整：

保持頁面樣式，為待辦頁補上表中五項獨立瀏覽器測試。
每項自己準備資料，斷言用戶能看到的結果。
結構錯誤場景要連續新增並刷新兩次，檢查兩項都保留。
報告指令、實際結果和未覆蓋部分，不為通過測試刪除斷言。

獨立準備資料能避免前一項測試留下的狀態掩蓋問題；可等待的網頁斷言則用於檢查最終行為。Playwright 測試實踐

原項目本來就有陣列結構校驗。2026年10月9日這次工作補齊了第5項迴歸測試，本地 Windows / Edge 共5項通過，不能把它寫成剛修復了一次線上故障。

如果你的實現選擇在壞資料時彈出恢復提示，而不是清空到空清單，驗收預期也應跟着產品設計調整。測試應該描述約定的行為，而不是把教學例子的策略硬套進所有項目。

原筆記發表於2026年10月11日；本文10月27日整理，沒有重新執行舊測試，也沒有擴大到手機、其他瀏覽器或跨裝置環境。

香港繁體版整理日期：2026年10月28日。原文引用的產品說明核對截至2026年10月27日；原實驗日期與範圍保留於文中。