開始，AI E2E 自動化測試這一段一共走了三條路：browser-use、Chrome DevTools MCP、還有團隊自己設計的一套架構。

這篇把這十天收斂成幾個結論，也誠實講講自己做的這套補上了什麼、還缺什麼、之後可以往哪裡長。

四個維度總表分析

自建架構不是每一格都贏，它是把分數從「上手速度」挪到了「可控性」跟「知識沉澱」。

這個取捨值不值得，要看你的團隊要的是什麼

這十天我最大的收穫：三件事

1. AI 該出場的時機，比 AI 多聰明更重要

browser-use 跟 CDP 都是每次執行都讓 AI 判斷，所以每次都花錢、每次都可能不一樣。

團隊自建架構只讓 AI 在產出跟修復時出場，每天跑的是程式

2. 大部分的設計，是在限制 AI 什麼時候該停

回頭看整套架構，真正花心思的地方幾乎都不是「讓 AI 做更多」，而是：

• 新頁面列完清單 => 停下來等人核可
• 功能行為變了=> 停手開單，不准修
• 修好了 => 不准自己生效
• 知識庫更新= > 不准自己寫回

讓 AI 做事很簡單，讓它在對的地方停下來才難

3. 最怕的不是紅燈，是綠燈說謊

從browser-use 的「錯誤的成功」，到自我修復的「把 bug 修成綠燈」，其實是同一個問題：

一個幾乎不會失敗的測試，跟一個沒有在測試的測試，從報表上看起來一模一樣。

選工具、設計架構，最終都在回答同一題：它說 PASS 的時候，你敢不敢相信？

這套架構，還缺什麼？

最大的風險：產物「全部」 AI 寫的

這套框架所有的產物，腳本、知識庫、報告，全部都是 AI 生成的。

若真的要人工手動排查的時候，邏輯上還是有一定的複雜度，基本上都得仰賴 AI 幫忙查。

一個能緩解的做法是：先訂好團隊的 codebase 範本，AI 產出腳本時一律照範本寫。至少結構是團隊熟悉的，能解決一部分可讀性的問題。

但如果有人還是覺得「程式碼就該由人來調整」，這部分應該就還是心裡會有點疙瘩。

我的看法是：AI 時代之下，人手動敲程式碼的情況只會越來越少。

重點不再只是程式碼要多乾淨、可讀性要多高，而是要把 AI 駕馭得跟以前的學程式碼一樣有結構性、邏輯性，這樣才是最應該要學會的事情。

千萬不要下意識只覺得 AI 產完做後執行 PASS 就當結束了！這會呼應這篇主軸：[Day2]「AI 說這錯誤只是 Flaky」，我是 QA！我應該要保持懷疑百次千次！，請一定要保持懷疑跟多重確認！

未來擴充

1. 探索改用 MCP，從失敗那步接著走

現在這套的探索，是靠 Python 腳本從頭執行到尾。

步驟 1～10 錯在第 6 步，AI 改完探索腳本，還是會從第 1 步重新跑。
但在探索階段，其實應該直接從第 6 步接著走下去。

現在：Python 腳本 → 錯在第 6 步 → 改完再從第 1 步重跑

未來：MCP 直接操作當下的畫面 → 從第 6 步接著探索
        ↓ 每一步都在背後記錄到 JSON / Markdown
      全部走完 → AI 一次轉換成正式腳本
        ↓ 轉完有問題
      再回到 MCP 探索

• Web：理應可以結合 Chrome DevTools MCP，直接在瀏覽器上接著探索
• App：像 agent-device 這類工具，讓 AI 直接操作 iOS / Android 模擬器，也支援 MCP，思路跟我們在做的很像

不過我的想法是借鏡它的模式，不一定直接換成它。

畢竟我們已經手刻了一套架構，定位器的寫法、輸出格式、技術棧都不一樣，直接換反而多一層轉譯成本。

另外要誠實講：這只能降低「判斷之後的執行成本」。
AI 看懂畫面、決定下一步的成本不會消失，那是任何探索都跑不掉的固定支出。

2. 讓 Spec 當唯一的真相來源

現在這套，AI 只以 TC 當作判斷依據。

但如果 TC 本身就寫錯了、或是過時了呢？AI 會很認真地照著錯的 TC，產出一支「驗證錯的東西」的測試。

所以下一步可以擴充的方向是：整合讀取 Spec，當作資料正確性的唯一來源。

          Spec（唯一真相來源）
         ↙        ↓        ↘
      TC       腳本的預期    實際畫面
       └─── 三方都拿去跟 Spec 對 ───┘

TC 跟 Spec 對不上、畫面跟 Spec 對不上，都能被抓出來。

當然，如果 Spec 本身是錯的，也沒人找出來，那就真的沒辦法了 XD

判斷力，最後還是回到人身上

AI 讓「寫測試」跟「修測試」變得很便宜。

但這十天走下來，真正決定結果對不對的，始終是這幾個問題：

• 什麼值得測？
• 這次是改版，還是 bug？
• TC 對嗎？Spec 對嗎？

整套架構在做的事，就是把這些判斷點寫進流程裡：哪裡該停、哪裡該問人、哪裡不准 AI 自己決定。

判斷力不能只存在一個人腦裡，所以要把它系統化。

這也是這一季從第一篇一路在講的事，只是這次載體換成了 E2E 測試。

老實說，這套到現在也還在長，每跑一輪就又發現新的坑 XD

但至少，它比十天前的我更知道自己什麼時候該停下來。

參考來源

• browser-use GitHub
• Chrome DevTools MCP GitHub
• agent-device GitHub