一位學員跟我說：「我請 AI 加了一個新的付款方式，它說做好了。三天後有人跟我說報名表送不出去。我完全不知道是什麼時候壞的。」

這是用 AI 做網站最常見的一種痛：新的東西做好了，舊的東西壞了，而你是最後一個知道的。

先講結論：你要有一份「哪些事情必須一直可以動」的清單，而且每次改完都要用同一種方法、走一遍同樣的步驟去確認。可重現才叫測試。做不到重現的，都只是「這次看起來沒問題」。

為什麼 AI 說沒問題不能信

AI 改完東西會告訴你「已經測試過了」。這句話常常在唬你。

不是它故意騙，而是它測的範圍只有它剛剛改的那一塊。它改了付款，就測付款；報名表跟它這次的工作無關，它不會去碰。但程式是連在一起的，改 A 影響到 B 是很平常的事。

更根本的問題是：讓寫程式的 AI 自己說測過了，等於讓寫作業的人自己當裁判。沒有獨立的驗收層，你遲早會卡在這裡。

我自己做系統，修正之後還要確認沒有影響其他客戶，這一步從來不能省。因為客戶可能正在招生、開賣、收款，系統一出問題，影響的是他的生意。

什麼叫可重現

我講一個區分。

有人測試的方式是「叫 AI 打開瀏覽器去點點看」。這種做法每次跑出來可能不一樣，因為執行當下的每一步都是 AI 即時判斷的。它今天點了報名表，明天可能跳過。

另一種做法是事先寫死一份腳本：打開哪一頁、填什麼、按哪裡、應該看到什麼。每次都照這份跑，每次結果都一樣。

第二種才叫測試。一個無法重現的測試，測的是 AI 這次有沒有照做，不是網站對不對。

可信的不是 AI，是那個真的去點按鈕的瀏覽器。

把兩件事拆開

我的做法是把測試拆成兩半。

執行那一半交給瀏覽器。用 headless 瀏覽器（沒有畫面、由程式控制的瀏覽器）真的去填表單、走結帳、登入後台。它不會幻覺，叫它點就點。

決定測什麼那一半交給 AI。要驗哪些頁面、每一步應該看到什麼、什麼情況算失敗，這種斷言的設計，AI 現在做得不錯。

年初我教 AI 寫這種測試的時候，它不太會寫測試條件，常常出錯。最近再用，問題少很多。變好的不是執行，執行一直都準；變好的是模型在設計測試條件上的能力。

我連系統的說明書都是用同一套機制產出的：一個機器人走完整個網站，順便拍截圖。同一個機器人，把輸出從截圖換成斷言，就是一條自動驗收的線。

你現在就能做的最小版本

不用一開始就搞自動化。先做這件事：

• 列一份清單，寫下你的網站「一定要能動」的五到十件事：首頁打得開、報名表送得出、付款走得完、通知信收得到、後台登得進
• 每次 AI 改完東西，不管改的是什麼，把這份清單從頭走一遍
• 走的順序、填的資料每次一樣，這樣壞了才知道是哪一步壞的
• 走完再說做好了

等這份清單穩定了，再請 AI 把它變成腳本。清單就是腳本的規格。

還有一個時間點的問題：什麼時候跑。我的答案是每次改完都跑，不管改的多小。改一行文字也跑。因為「這次改得很小不用測」這句話，幾乎每一次出事前都有人講過。

如果你的網站正在招生或開賣，那段時間乾脆不要改東西。要改，等這一波結束。系統壞掉的成本，在有人正要付錢的時候是最高的。

常見的誤區：只測新的

改了什麼就測什麼，這是最自然的反應，也是最容易漏的地方。

還有一個更隱蔽的坑：測試只準在你有寫下來的地方。你沒想到要測的路徑，它是瞎的。所以那份清單要花心思，覆蓋哪裡的決定權在你，不在 AI。

我「先分析再動手」的習慣，正好是在補這個洞：動手前先想這次會碰到哪些東西，那些東西就要進清單。

留一個問題給你

你的網站有沒有一份「一定要能動」的清單？如果沒有，現在寫的話，第一條是什麼？

如果你在建這條驗收線的時候卡住了，可以把狀況寫信給我。我的電子報每週會寫這類做網站的實際方法，可以先訂起來：https://iamlouis.ai/subscribe/edm