跨產業
網頁自動化：重複操作交給它跑
多視窗同時執行，等待時間彼此重疊，不是一筆一筆排隊
以 Playwright 為核心的網頁自動化排程器，支援多視窗並發執行。把重複的網頁操作交給程式跑，人力回到需要判斷的工作上；沒有 API 可接的系統也能自動化。
多視窗並發
同時開啟多個相互獨立的瀏覽器情境各自處理任務。總時長接近「最慢的那一批」，而不是全部相加。
情境完全隔離
每個視窗持有自己的 cookie 與工作階段。某個任務登出或失敗，不會拖垮其他任務。
沒有 API 也能接
對方系統不提供 API、內部系統老舊到沒人敢動——這些原本只能靠人做的流程，可以交給它。
怎麼運作
定義任務流程
設定要操作的網頁步驟與資料來源，可批次匯入待處理清單。
排程器分派
任務分派到多個獨立的瀏覽器情境並發執行，失敗自動重試。
回報結果
完成與失敗的項目分別列出，失敗原因可追。
規格
- 並發方式
- 多視窗
- 情境隔離
- cookie 各自獨立
- 失敗處理
- 自動重試
- 部署方式
- Docker
- 目前版本
- v2.6.3
問題：有些工作不需要人，但也還沒有 API
企業內部有大量「打開網頁、登入、貼資料、送出、換下一筆」的作業。這些流程通常沒有 API 可接——對方系統不提供，或是內部系統老舊到沒人敢動。於是只能靠人做，一天兩三小時，做一整年。重複工作自動化的價值不在省下那幾小時，在於這幾小時本來就不需要人的判斷。
這類工具一般歸在 RPA 流程自動化底下。差別在做法：傳統 RPA 多半錄製滑鼠與鍵盤動作，畫面一改就失效；這套走的是瀏覽器自動化，用 Playwright 直接對元素操作，穩定度與可維護性都在另一個量級。
為什麼是多視窗，而不是排隊跑
單一瀏覽器循序執行是最直覺的做法，也是最慢的。一百筆資料若每筆等待網頁回應三秒，光是等待就是五分鐘，而 CPU 幾乎閒置。
系統核心是多視窗並發：同時開啟多個相互獨立的瀏覽器情境，各自持有自己的 cookie 與工作階段，由排程器分派任務。等待時間彼此重疊，總時長接近「最慢的那一批」而非「全部相加」。
隔離是這裡的關鍵——多個視窗如果共用登入狀態，一個任務登出就會拖垮全部。每個情境獨立，某個任務失敗不影響其他。
繼續看：架構、工程紀律與據實說明
工程紀律
這套工具的測試涵蓋率，我們刻意拉得比自己其他專案都高。
原因很實際：網頁自動化的失敗模式極多（元素改名、載入時序、彈窗、逾時），而這些錯誤在正式環境才會出現。沒有測試網的自動化工具，最後花在除錯的時間會超過它省下的時間。
專案提供 Docker 環境，變更紀錄與技術文件跟著版本一起維護，交接時不需要口頭傳承。
適用與不適用
適合：內部系統的批次資料維護、跨系統的資料搬運、定期報表擷取、無 API 的合作夥伴平台對接——共同點是規則明確、量大、且沒有判斷成分。
不適合：對方明確禁止自動化的服務、需要繞過人機驗證的場景、有限資源的搶佔式操作。這條界線我們不會為了成交而模糊。
關於這個案子，常被問到的是
網頁自動化跟一般說的 RPA 是同一件事嗎？
目標一樣，做法不同。傳統 RPA 多半錄製滑鼠座標與鍵盤動作，版面一改就整個失效。這套走的是 Playwright 自動化，直接對頁面元素操作，並在等待、重試與逾時上做處理，改版時要修的是選擇器，不是重錄一遍。
為什麼要多視窗並發，不能一筆一筆跑就好？
因為瓶頸是等待，不是運算。一百筆資料每筆等網頁回應三秒，光等待就五分鐘，而 CPU 幾乎閒置。多視窗讓等待時間彼此重疊，總時長接近最慢的那一批，而不是全部相加。
多個視窗會不會因為共用登入而互相干擾？
這正是要隔離的原因。每個視窗是獨立的瀏覽器情境，各自持有 cookie 與工作階段；若共用登入狀態，一個任務登出就會拖垮全部。情境獨立之後，某個任務失敗不影響其他。
哪些情況你們不會接？
對方明確禁止自動化的服務、需要繞過人機驗證的場景、有限資源的搶佔式操作。這條界線不會為了成交而模糊。