借鏡前兩個工具後，會發現 AI E2E 自動化測試的每套工具都有各自的優缺點。

一開始我是用「一步到位」的標準去看它們，所以始終覺得少了什麼。
但其實那兩套要套用在團隊也可以，只是需要自己實作很多邏輯去補。

既然都要補，那如果我直接整合前面學到的邏輯，是不是也能打造一套專屬的 AI E2E 流程？

瓶頸不在「跑測試」

寫自動化很花時間，網站一改版又整批失效，得回頭一支一支慢慢修。

做自動化省下的時間，幾乎都被「維護自動化」吃回去。

所以真正要交給 AI 的，是 「寫」跟「修」，不是「跑」。

核心原則：貴的判斷交給 AI，重複的執行交給程式

AI 只在產出跟修復時出場，每天跑的是腳本。跑一百次行為都一樣，不花 token，知識沉澱也終於有地方放。

👉（這就像請資深師傅把工法寫成一張標準作業卡，之後每天照卡操作的是產線，不用每天都請師傅來。）

架構總覽

這篇講前三個階段，後三個留到明天。

這套邏輯 Web、App 都通用，E2E 的思維是同一套，差別只在底層怎麼看畫面、怎麼操作。

以下每個階段說明，僅說明重點概念，大多都是要 SKILL+腳本 一併執行，才能讓 AI 達到準確又盡量省成本

階段 0：建立環境、自動安裝套件、引導

讓 AI 檢查缺什麼、直接幫你裝好，環境建一次就好。
ex. chrome、playwright、appium、python 等等...

讓 AI 引導需要取得什麼 api key
ex. TestRail、Jira、Github/Gitlab 等等

但有兩條線 AI 不能碰：

• 帳號密碼一律人自己填：AI 不代填、不讀值、不印出來
• 只打測試環境：產測試的過程會反覆操作、建資料，不能放在正式環境

當然如果能用 dockerfile 方式也可以！只是這套工具如果對象是 PM/非技術職的人來用時，可能 docker 應用對他們來說會過於複雜

階段 1：蒐集相關內容、計畫階段

這階段很重要，會決定 AI 是否容易走偏繞遠路

• TC 是唯一的判斷依據：貼連結、直接貼步驟都行，不會寫的話就讓 AI 給範本
• 先讀知識庫：讀取先前寫好的的頁面、業務術語、測試腳本等等
• 列出驗收點（Critical Points）：每條步驟、預期結果，要看到什麼證據才算通過
• 新頁面先列清單，停下來等人核可：「什麼值得測」是業務判斷，不交給 AI 決定

另外，TC 寫得清不清楚，直接決定成本：TC 過時或籠統，AI 就得反覆探索、反覆確認，花費明顯偏高。

階段 2：探索頁面、產出腳本

探索靠兩種手段互補：看畫面（懂視覺狀態，但給不出定位）＋ 擷取 DOM 元素（拿得到定位，但只抓得到當下）。

AI 產腳本的流程：

寫腳本 → 實際執行 → 截圖檢查
              ↓
      驗收點全部通過？
       ├─ 沒過 → 先診斷（定位失效？時序太快？彈窗擋住？）→ 修腳本再跑
       └─ 全過 → 轉正成正式測試腳本

重點是看真實畫面是否符合預期，不猜；

定位器記得需要定義優先順序。ex. 先判斷 test-id？判斷 id？判斷 class name？

草稿區隨便產，通過才轉正

探索本來就是反覆試錯，所以放手讓 AI 在草稿區亂試；只有正常執行、驗收全過的腳本，才會轉到正式架構的 TC 腳本區。

正式區永遠乾淨，因為試錯都留在草稿區。

🧨 小坑洞：知識庫只拍得到「進頁當下」

• 當下以為的：進頁把所有元素撈一次存起來，之後就都查得到
• 實際發生的：下拉選單、月曆、彈窗這種互動後才出現的元素，進頁當下撈不到；自訂樣式的勾選框，程式也問不出有沒有打勾
• 怎麼解：互動後才出現的元素另外記回知識庫；視覺狀態現階段還是靠看畫面

定位靠事先存好的知識庫，視覺狀態和出錯診斷靠當下看畫面。

總結

• 瓶頸不在跑測試，而在寫跟修
• 貴的判斷交給 AI，重複的執行交給程式，每天跑測試不花 token
• 前三個階段：建環境 → 蒐集與計畫 → 探索與產腳本，全部通過才轉正

腳本是產出來了，但自動化真正痛的從來不是第一天，是E2E 改版之後。

測試錯了，AI 要去修，它怎麼知道這次是「按鈕搬家」該修，還是「功能真的壞了」不該修？

明天講剩下三個階段：自我修復、收斂知識庫，還有怎麼防止 AI 為了讓畫面變綠而說謊。