有位客戶跟我說，他現在很怕改網站。

改一個字，就要把首頁、活動頁、報名表、結帳頁全部走一遍，因為之前有一次只改了文案，結帳按鈕就不見了。改到後來，他寧願不改。

答案是有的，而且不需要你會寫程式。你要做的是把「你每次手動點的那些步驟」寫成一份固定清單，然後讓一個看不見的瀏覽器照著清單跑。這種做法叫 headless 瀏覽器測試（無畫面瀏覽器測試）。

它的原則只有一句話：可信的不是 AI，是瀏覽器。

一、先把你手動點的變成一張清單

你現在一頁一頁點，其實腦子裡已經有一份清單，只是沒寫下來。

打開首頁，主圖要在。點活動頁，價格要對。填報名表，送出後要看到「報名成功」。後台要多一筆。

把這些寫成「做什麼動作、應該看到什麼」。一行一個。不用漂亮，但每一行都要有「應該看到什麼」，這一半是關鍵，沒有它就不算檢查，只是逛網站。

這張清單寫出來你會發現一件事：你每次手動點的其實就那十幾條，而且每次都一樣。會一樣的事情，就是機器該做的事情。

二、讓瀏覽器去跑，不要讓 AI 去「試試看」

這裡有一個很常見的岔路。

有些人的做法是叫一個 AI 瀏覽器「幫我測一下結帳」，讓 AI 當下自己決定要點哪裡、看什麼。聽起來很聰明，但這其實是退化的做法。每次跑的結果可能不一樣、很慢、每一步都在燒錢，而且你不知道它這次到底有沒有照做。

一個無法重現的測試，根本不算測試。它測的是「AI 這次有沒有照做」，不是「網站對不對」。

正確的拆法是把兩件事分開：

執行，也就是點按鈕、填表單、走結帳，這一半交給瀏覽器。瀏覽器是決定性的，你叫它點哪裡它就點哪裡，不會幻覺。

斷言，也就是「這一步應該看到什麼」，這一半是 AI 會出錯的地方，所以由你決定，AI 幫你寫成程式。

自動化的前提是決定性，不是聰明。

三、我自己怎麼做

我維運的站將近兩百個，每次系統更新都要確認前台跟後台流程沒壞。我不可能一個一個點。

所以我的做法是用 headless 瀏覽器跑前台與後台的流程，跑完給我結果。連系統說明書上的截圖，都是同一套機器人走過整站拍出來的。它走得過，代表流程沒斷。

今年初我教 AI 寫這種測試腳本的時候，它不太會寫測試條件，常常出錯。最近再用，問題少很多。原因很清楚：執行的那一半從頭到尾都準，變好的是模型「寫斷言、設計測試條件」的能力。

這件事給我的提醒是：測試很準，但只準在你有寫斷言的地方。你沒想到要測的路徑，它是瞎的。所以清單要測什麼，決定權還是在人。

四、從零開始的三步

第一步，挑三條你最怕壞的路徑。通常是：首頁打得開、報名或購買走得完、後台看得到那筆資料。這三條斷了，就是會直接影響收入的事，其他的可以慢一點。

第二步，把清單交給 AI，請它用 Playwright 這類工具寫成腳本。你的要求要講清楚：每一步都要有「應該看到什麼」，看不到就要報錯停下來。

第三步，之後每次改完網站，先跑腳本，再決定要不要自己看。腳本綠了，你只需要看這次改的那個地方；腳本紅了，它會告訴你斷在哪一步。你會從「每次改完花半小時點」變成「每次改完等兩分鐘看結果」，而且那兩分鐘比你點的半小時可靠。

三條路徑跑順了，再慢慢加。不用一開始就追求全部。每次網站出一次問題，就把那條路徑補進清單，半年下來這份清單會比你自己的記憶可靠得多。

兩個常見的誤區

第一個是「叫 AI 自己測就好」。寫程式的 AI 說「我測過了」，等於讓寫作業的人自己改考卷。沒有獨立的驗收層，遲早卡在自己身上。

第二個是以為腳本會幫你發現你沒想到的問題。不會。腳本只會檢查你寫進去的那幾行。它幫你省的是重複勞動，不是判斷。

所以真正的問題是：你現在腦子裡那份清單，有沒有把「應該看到什麼」寫出來？寫得出來，剩下的機器可以接手。

如果你做到一半卡住，可以把狀況寫信給我。我每週會在電子報聊這類做網站、用 AI 的判斷，訂閱在這裡：https://iamlouis.ai/subscribe/edm