AI 把網站做出來了，聯絡表單也會顯示「成功」。這時最該確認的是：空白資料能不能送出？失敗後要不要重填？負責收件的人究竟有沒有收到？
這篇要帶你完成六項前端操作檢查，留下「做了什麼、看到什麼、哪些還沒測」的紀錄。適合用 AI 建站的個人、工作室，以及要驗收網站的小企業。只需要瀏覽器，不必會寫程式，也不用購買測試工具。
如果還沒說清楚表單要做什麼，先完成網站需求與驗收規格。那篇教你寫驗收情境，這篇則用可以操作的範例，把預期結果變成實際紀錄。
一、先分清畫面、伺服器與收件端
一次表單操作，至少有三個地方要確認：瀏覽器有沒有檢查輸入、伺服器有沒有接收並處理，以及指定信箱或通知管道有沒有收到正確內容。
畫面顯示成功，只能按網站實際設計解讀。它可能代表已送出請求、伺服器已接受，或只是前端播放了一段成功訊息。驗收前要問清楚「成功」的定義，再決定需要什麼證據。
MDN 表單驗證文件說明，瀏覽器可以用必填與欄位格式先檢查輸入，但伺服器仍須獨立驗證。本篇只做前端練習，不把這些操作當成後端、安全性或收件已通過的證明。
二、開啟不會寄信的練習表單
先開啟網站表單驗收練習。這是客脈為本文製作的教學範例，有 Email、需求說明與模擬結果三個欄位。所有操作留在目前頁面，不寄信、不儲存，也不呼叫後端；重新載入可重新開始。
準備以下資料：Email 填 demo@example.com，需求說明填「這是表單驗收練習，不需回覆。」兩者都只用於練習，請勿換成客戶資料。頁面刻意等待 2 秒，方便觀察處理中的狀態，這個時間不是效能測量。
另開一份表單驗收紀錄表（TXT），記下日期、網址、瀏覽器、視窗大小、測試編號、預期與實際結果。結果分為通過、失敗、未測；AI 寫出清單時，實際結果應先留白。
這份 HTML 也可用瀏覽器「另存新檔」保存後練習，不需要註冊。本文實測的是本機提供的網頁版本；不同瀏覽器對本機檔案與下載有不同處理，存檔後仍要自行開啟確認。
三、照順序做六個操作
先重新載入練習頁，確認顯示「尚未開始」，模擬次數為 0。以下成功或失敗都只指教學表單的前端狀態。
- 空白必填。 不填資料，按「送出練習」。應停在需要補填的欄位，模擬次數不增加。再只填正確 Email、留空需求說明，重做一次，確認另一個必填欄位也會擋下操作。只測第一欄，容易漏掉後面的欄位。
- 錯誤 Email 格式。 將 Email 填為 abc，需求說明填入練習文字，再送出。應被格式檢查擋下，模擬次數不增加。改成 demo@example.com 後才能繼續。格式通過不代表信箱存在或能收到信。
- 失敗後保留內容。 兩欄都填妥，模擬結果選「失敗」，按送出。等待結束後，應顯示「模擬失敗；已保留輸入，請選成功後重試。」核對剛才的 Email 與需求文字仍在，不必重打。
- 修正後重試。 保留資料，把模擬結果改成「成功」，再按送出。應顯示「模擬成功；沒有寄信或儲存資料。」這項驗收的是重試流程能繼續，不能填成真實信件已寄達。
- 處理中狀態。 再選一次模擬結果並送出，觀察那 2 秒：按鈕應變成「模擬處理中…」且暫時不能操作，結果選單也暫停使用。結束後恢復「送出練習」。次數應按每次有效操作增加，不因空白或格式錯誤而增加。這仍未測到正式後端防止重複建單的能力。
- 鍵盤與窄螢幕。 用 Tab 依序移動到欄位、結果選單與送出按鈕，確認看得出焦點在哪裡。再用手機或瀏覽器的 390px 寬度檢查，欄位、按鈕及結果應讀得清楚，不需要左右拖動整頁。測試視窗與真實手機要分別記錄。
瀏覽器的原生提示文字可能隨語言與版本不同，不必要求每台電腦顯示一模一樣的句子。你要記錄的是能否理解要修正哪裡，以及無效輸入是否真的擋下操作。
四、本次實際測到了什麼
2026-09-19，我們在 Codex 內建瀏覽器操作本文的本機練習頁，使用上述虛構資料，並切換到 390×844 的視窗檢查手機版面。
- 空白 Email、空白需求與 abc 格式檢查都擋下操作，模擬次數沒有因這些無效輸入增加；空白欄位檢查時，焦點落在需要補填的位置。
- 有效資料選失敗後，畫面顯示模擬失敗，輸入保留；選成功再試，得到明確的模擬成功訊息。
- 處理中觀察到按鈕與結果選單暫停操作，結束後恢復。另以本機程式檢查重複觸發時只啟動一輪模擬，這是範例程式的檢查，沒有測試真實後端。
- 鍵盤可從需求欄移到結果選單，再到送出按鈕；390×844 視窗未見整頁左右溢出，畫面可讀。沒有做 iPhone、Android 實機或螢幕閱讀器測試。
第一次用操作工具清空需求欄時，內容並未清除。我們確認欄位狀態後，改用全選與刪除再測，才完成空白情境。這也提醒你：按過清空不等於欄位已空白，記錄前先確認測試條件。
練習頁沒有 API、資料庫、寄信或通知服務，所以實際收件、資料保存與伺服器驗證全部列為未測。它適合練習怎麼驗收，不能直接拿來當正式詢價功能。
五、把問題寫成製作者能重現的紀錄
「表單怪怪的」很難修。請留下這樣的資訊：測試環境、測試資料、操作順序、預期結果、實際結果，以及必要截圖。截圖若含個資，先遮掉再分享。
例如，假設某個測試站發生「選失敗後，需求欄被清空」，可記成：「桌面瀏覽器，需求欄輸入練習文字後送出；預期失敗提示出現且文字保留，實際顯示失敗但欄位變空白；重新載入後依相同步驟仍可重現。」這是缺陷紀錄的示範寫法，不是本次練習頁發現的問題。
如果想請 AI 幫忙整理，可以貼上以下提示詞，再附上自己的測試紀錄：
請把我的觀察整理成網站表單驗收報告。每項保留環境、前置條件、操作、預期、實際結果與證據；分成通過、失敗、未測。不要把預期結果當成已通過，也不要把前端成功訊息推論為信件送達。資訊不足時指出缺少的觀察，先不要猜測原因或改程式。若我提供多輪結果，保留各輪日期與差異。
整理後仍要對照原始紀錄。AI 可以幫你排清楚資訊，但「我實際看到什麼」必須由測試證據決定。若你還在準備官網內容，可接著用客服知識庫整理方法核對表單旁的服務說明，避免網站與客服各說各話。
六、正式上線還缺哪些驗收
把這份紀錄交給製作者時，至少另列以下待辦，並約定誰負責、在哪個測試環境執行：
- 收件核對： 先設定雙方同意的測試信箱或通知管道，送出標明測試的內容，由收件端確認欄位與內容正確。不要直接往真實客戶的正式表單灌測試資料。
- 失敗處理： 在測試環境安排接收失敗，確認不會假報成功；若資料已保存但通知失敗，應按事先約定的規則顯示狀態。
- 重複送出： 前端暫停按鈕能減少連點，但重新載入、重試或多個頁面仍需由後端處理。請製作者提供相應測試結果，別把按鈕變灰當成重複建單已解決。
- 裝置與輔助操作： 補上約定的手機、瀏覽器與必要的輔助科技測試。窄視窗檢查通過，不能代表手機鍵盤、自動填寫或所有裝置都通過。
W3C 的表單通知教學建議用清楚、簡短的訊息說明錯誤及修正方式，也需要適當的成功回饋。不能只靠紅色或綠色讓使用者猜結果。開發者若使用 disabled 暫停按鈕，也要了解它對焦點與操作的影響，詳見 MDN disabled 說明。
這些是驗收範圍，不等於要求每個小網站都加一套大型測試平台。先把最重要的聯絡流程測清楚，留下可重做的紀錄；需要委託時，可參考網站廠商比較與交付問題。
七、費用限制與你的練習
本文的練習頁與 TXT 免費開啟，不需登入、寄信額度或 API。使用 AI 整理報告是可選的，依你已有帳號的額度與資料政策辦理，不必為這個練習升級方案。正式站的寄信、儲存或其他服務費用要另按實際方案確認，本篇沒有替它們做免費承諾。
請重做六項檢查，交出一份寫有實際結果的紀錄，再另外列出至少三項「練習頁無法驗證、正式站仍需確認」的項目。判斷不出來就填未測，不要為了讓整張表好看而全部打勾。
完成標準是另一個人看得懂你用什麼資料、怎麼操作、看到什麼，而且能照著重做。若要把練習換成自己的網站，先確認使用的是核准的測試環境與測試收件人。
查核日期：2026-09-19。本文由 AI 輔助查閱官方文件、製作教學範例與整理實際操作紀錄；未宣稱真人審稿、客戶案例或正式站收件已通過，沒有購買 API 額度或提交真實詢價。