昨天講完 AI E2E 架構的前三個階段，腳本產出來了，每天也能用純程式跑。

但自動化真正痛的地方，是網站改版之後。

這篇講剩下三個階段：自我修復、收斂知識庫、代碼檢查與 AI 審核，也就是「讓測試養得起」的部分。

最怕的不是錯誤，是「假綠燈(假PASS)」

錯誤有人會去看，真正危險的是明明有問題卻顯示通過。

在 AI 自我修復的情境下，最常見的假綠燈長這樣：

開發不小心把功能改壞了
      ↓
測試顯示錯誤
      ↓
AI 以為是「測試寫得太舊」，把預期改成符合現在（壞掉）的畫面
      ↓
測試變綠 → 一個真實的 bug 被自動化「認證」成正常

階段 3：自我修復

測試壞掉時，AI 不是直接動手修，而是先判斷是哪種壞法：

分界線定成三條硬規則：

寧可多一次人工確認，不可放過一個真 bug。

而且就算修好了，也不會自己生效，要送人審核過才算數。

階段 4：收斂知識庫、比對新舊版

知識庫幫每個頁面存一份「它長什麼樣」：元素位置、頁面結構與截圖、還有哪些測試依賴這個元素。

它有兩個用途：

• 改版裁判：測試壞掉時，拿新舊版比對，判斷是「頁面改版了」還是「別的原因」，這就是階段 3 判斷壞法的依據
• 下一支測試不用重探：讀取已存在找過的頁面，直接查就好

但回寫知識庫是有條件的：只有「確認是正常改版」而且「經人審核」才能更新。

不然就會把壞掉的頁面凍成新標準，bug 直接被蓋掉。

🧑 唯一 AI 做不了的事：業務語意

「這個欄位在業務上代表什麼意思」，例如「顯示『已送出』代表對方看得到了」。

知識庫其他部分都能自動重建，只有這個要人補。留空的話，下一個接手的人或 AI 就得從零重新理解這頁。

階段 5：代碼檢查、AI 審核

交付前要過兩層把關：

最後還有一道驗收：重複跑，確認穩定才算完成。

⚠️ 時好時壞（flaky）比直接失敗更糟。
一支偶爾會錯誤的測試，久了大家就不信它，真的壞掉那次也會被當成「又是老毛病」放過去。

人一定要介入的地方

整套流程刻意留了幾個「停下來問人」的點：

AI 負責把事情做完，人負責把關「做得對不對」。

總結

• 最怕的不是紅燈，是假綠燈：AI 為了讓測試變綠，把 bug 修成正常
• 階段 3 自我修復：改版就修，行為變了就停手，拿不準一律當 bug；修好也要人審
• 階段 4 知識庫：當改版裁判、讓下一支不用重探；回寫要經人審，業務語意要人補
• 階段 5 兩層把關：程式擋明文規則、獨立 AI 擋判斷題；第一天就要打開