前兩天把手冊的規格問題、產品特性、以及工具的軟硬需求都定清楚了。今天終於要把工具選出來。

需求

確定「要有截圖、截圖要能標註」之後，必須有一個能把操作應用程式的過程寫成固定腳本、可以重複執行的工具。這個工具是整條產線的地基，它決定了截圖能不能穩定重現、腳本能不能被 AI 寫、後續能不能接進 CI。選錯了，後面每一天的實作都會建立在不穩固的基礎上。

自動化操作應用程式

說到自動化操作應用程式，不知道大家第一個想到的會是什麼？是自動搶票機器人？還是打遊戲的掛機腳本？又或者是這兩年很熱門的 n8n？這幾種應該都可以算是自動化操作，如果要再進一步分類一下的話，可以分成三個類型：

1. 模擬鍵盤、滑鼠、觸控

這應該是最直覺的方式了，有很多種工具都可以用來模擬人類的操作 (e.g. 手機模擬器、滑鼠精靈)，只要先手動操作一遍並把點擊座標錄製下來，之後就可以重複使用了。甚至更進階一點還可以加入判斷邏輯 (e.g. 根據某個位置的顏色來判斷)，讓這些錄製下來的腳本更彈性。

雖然很直覺，但這也是最脆弱的。只要 UI 版面稍微調整，或甚至調整畫面解析度，座標就會全部失效。

2. 透過作業系統或瀏覽器的 UI 結構樹定位，直接操作

這就比較進階一點，它的邏輯是：與其記錄座標，不如直接紀錄 UI 元件本身，例如：「點擊 id=submit-button 這個元件」。這種方式因為不用管 UI 元件在畫面上的實際位置，因此操作上穩定的很多。基本上只要元件不要消失，或是定位 UI 的方法不要完全寫死，都不太會失效。

3. 直接呼叫 API

如果在意的只是功能，就可以考慮跳過畫面，直接跟後端 API 或是應用程式的介面溝通。這是最穩定的方法，幾乎不會因為 UI 改動而失效。

小小總結

雖然有很多種選擇，但由於我們使用手冊的核心是要有畫面 (需要截圖)，所以很明顯第三種作法 (呼叫 API) 就可以直接放棄了。而上面第一種 (紀錄座標) 與第二種方法 (紀錄元件) 相比，第二種方法比較穩定，也比較符合我們對使用手冊產線的需求。因此，結論很清楚，優先選擇可以「透過 UI 結構樹定位」的工具。

選擇「UI 結構樹定位」工具

這類型的工具也不少，常見的選項有 Playwright、Puppeteer、Selenium、Cypress。這幾種工具其實也是常見的爬蟲工具和網站測試工具，相信對於有寫過爬蟲或是 E2E 測試的讀者來說，這些工具應該不陌生，甚至應該都很熟練了。

經過一番比較後，最後我選擇的是 Playwright，最直接的原因是：

有支援 Electron

這是最主要的原因，儘管 Playwright 網站上明確寫出這只是實驗性的支援 (experimental support)，也實驗很久了， 但我這幾年用起來沒遇到什麼問題。

當然，也有可能是自動化測試寫太少，所以才沒遇到問題😅 如果各位有遇過什麼問題的話，歡迎留言分享~

雖然可以硬是用其他工具用瀏覽器的方式查看 Electron 的網頁本體，但我覺得有直接支援應該還是比較好。

另外，Playwright 還有一個加分項，那就是它還有 MCP 與 CLI，這個特點讓我們後續在 AI Agent 的整合上會方便很多，不過，這邊就不深入討論了，留到後面再分享~

工具選定之後，差不多可以開始動手實作了。不過在那之前，明天會先把整條產線的全景圖攤開來看，建立一張後面每天實作都能回頭對照的地圖，各位明天見！