AI導向RPA：點擊無API老舊網頁的自動化實作

企業內部有大量仍在使用的老舊系統，例如十幾年前建置的進銷存系統或政府申報網站，這些系統往往沒有提供任何可供程式呼叫的API，唯一的操作方式就是打開瀏覽器，依照固定步驟點擊、輸入、送出。當這類重複性的資料登錄工作量很大，企業很自然會想用自動化工具取代人工操作，但傳統RPA工具依賴座標或固定元素位置來定位按鈕與輸入框，一旦頁面排版有任何微小變動，整套自動化流程就會失效。AI導向RPA要解決的，正是讓自動化操作不再死板地依賴固定座標，而是能像人類一樣，依据頁面內容判斷該點擊哪裡。

這種能力的關鍵轉變，在於把畫面理解這件事交給語言模型或視覺模型來處理，而不是預先寫死每一個元素的絕對位置。當頁面結構出現微調，系統依然能依据元素的語意內容重新定位，這讓自動化流程的維護成本大幅降低，不必每次系統更新就要重新校正一次自動化腳本。

這種轉變的意義，不只是讓自動化流程變得更穩定，更重要的是讓非工程背景的業務人員，也有機會用接近自然語言描述的方式設定自動化任務，而不需要逐一寫出每個元素的精確座標或識別碼，這降低了企業導入自動化的技術門檻。

一、為什麼傳統座標式RPA在老舊網頁上容易失效

傳統RPA工具的運作方式，多數是記錄使用者操作時滑鼠點擊的螢幕座標或頁面元素的固定識別碼，之後重複執行這些記錄下來的動作。這種方式在頁面結構完全不變的情況下運作良好，但老舊系統往往會因為瀏覽器版本更新、視窗大小調整，甚至作業系統的些微差異，導致頁面元素的實際位置產生偏移，傳統RPA一旦定位失準，就會點擊到錯誤的位置，甚至完全無法找到目標元素而中斷整個流程。

更棘手的是，許多老舊系統並非由企業自行維護，而是委外廠商開發後就不再頻繁更新，這意味著企業無法主動配合RPA腳本去調整頁面結構，只能被動接受系統偶爾出現的版面變動。當這種變動發生時，傳統RPA腳本往往需要工程人員重新打開頁面、重新記錄座標，這種維護負擔長期累積下來，會讓企業對導入RPA的信心逐漸下降，甚至因為頻繁故障而放棄使用。

這種維護負擔還會衍生出另一個問題，當企業內部同時存在多套需要自動化的老舊系統，且每套系統的版面變動頻率不同，工程團隊往往需要分散精力在多個腳本的修補工作上，難以將時間集中投入在真正能提升整體效率的新功能開發，長期下來會讓自動化專案的投資回報顯得不如預期。

二、AI導向RPA的核心運作原理

AI導向RPA的運作邏輯，可以拆成四個環節。第一個環節是頁面理解，系統擷取當前畫面的結構資訊或視覺截圖，交由模型判斷頁面上有哪些可互動的元素，例如輸入框、按鈕與下拉選單，以及這些元素各自的語意角色。第二個環節是動作決策，依据當前任務目標與頁面理解結果，模型判斷下一步應該執行什麼動作，例如在某個標註為訂單編號的輸入框中填入特定數值。第三個環節是執行與驗證，系統實際執行這個動作後，會重新檢查頁面狀態，確認動作執行後的結果是否符合預期，例如確認資料是否成功送出。第四個環節是例外處理，當頁面出現非預期的彈出視窗或錯誤訊息，系統能依据當前畫面內容重新判斷該如何應對，而不是直接卡死中斷。

這種以語意理解取代固定座標的設計，讓自動化流程具備一定程度的容錯能力，當頁面排版出現合理範圍內的變動，系統仍然能透過重新理解畫面內容，找到正確的操作目標，這是傳統座標式RPA難以做到的彈性。

值得補充的是，頁面理解的準確度，會受到頁面本身設計品質的影響，如果目標系統的介面缺乏清楚的標籤文字，僅依賴圖示或顏色區分功能，模型在判斷元素語意角色時的難度會明顯提高，這也是為什麼在導入初期，針對目標系統的介面特性進行充分的理解測試，是不可省略的步驟。

三、系統架構示意

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│ 頁面理解層 │ → │ 動作決策層 │ → │ 執行驗證層 │ → │ 例外處理層 │
│ 截圖/結構解析│   │ 判斷下一步  │   │ 點擊/輸入/確認│   │ 異常重新判斷│
└──────────┘   └──────────┘   └──────────┘   └─────┬────┘
                     ▲                              │
                     └──────────回流重新理解頁面───────┘

例外處理層與動作決策層之間的回流路徑，是這套架構能夠應付老舊系統各種突發狀況的關鍵，少了這條路徑，系統一旦遇到非預期畫面就只能直接失敗，與傳統RPA的脆弱性並無太大差異。

四、實作案例：假設性的老舊訂單系統資料登錄自動化

假設企業內部使用一套十年前建置的訂單管理系統，沒有任何API可供呼叫，每天需要將新訂單資料人工輸入這套系統。導入AI導向RPA後，系統先擷取當前頁面截圖，模型辨識出頁面上有客戶名稱、訂單編號、商品項目與數量四個輸入框，以及一個送出按鈕。系統依据待輸入的訂單資料，逐一判斷該在哪個輸入框填入對應的數值，填寫完成後點擊送出按鈕。如果送出後系統彈出一個提示視窗，要求確認商品庫存是否足夠，模型會重新理解這個彈出視窗的內容，判斷這是一個需要點擊確認的提示，而不是誤判為輸入錯誤，並完成後續的確認動作。

這個案例的關鍵，在於彈出視窗這類非預期畫面的處理。如果是傳統座標式RPA，遇到原本記錄流程中沒有出現過的彈出視窗，多數情況下會直接卡住或誤觸到錯誤的按鈕，而AI導向RPA因為每一步都重新理解當前畫面內容，能夠正確識別這類偶發性的介面變化，並做出合理的應對。

進一步假設，如果這套老舊系統在某次更新後，將原本的客戶名稱輸入框移動到頁面的不同位置，並且調整了標籤文字的措辭，傳統座標式RPA會因為位置改變而完全失效，但AI導向RPA能依据新的標籤文字與欄位排列，重新理解這是同一個語意角色的輸入框，只要欄位的語意核心沒有改變，系統依然能正確完成填寫，這正是語意理解相較於固定座標的實際優勢所在。

五、Prompt範例：判斷頁面元素與下一步動作

你是一位頁面自動化操作助理。
請根據下方的頁面結構描述與待完成的任務目標，判斷下一步應該執行的動作：
1. 列出當前畫面中所有可互動的元素，並標註每個元素的語意角色。
2. 依据任務目標，判斷接下來應該對哪個元素執行什麼動作，例如填入特定文字或點擊。
3. 如果畫面中出現與預期流程不符的彈出視窗或錯誤訊息，請先說明這個異常的可能原因，再判斷應對方式。
4. 動作執行後，請說明應該如何驗證這個動作是否成功。

六、導入SOP

第一步為流程盤點，列出企業內部哪些老舊系統的操作流程適合導入自動化，並評估這些系統的頁面結構是否具備可被擷取與理解的基本條件。第二步為任務拆解，將完整的操作流程拆解成一系列具體的子步驟，每個步驟對應明確的判斷與動作。第三步為頁面理解測試，先針對目標系統的各個頁面進行理解測試，確認模型能正確辨識頁面上的關鍵元素。第四步為例外情境蒐集，整理過去人工操作時曾經遇到的各種異常畫面，作為例外處理層的訓練與測試素材。第五步為灰度試運行，先在少量真實案例上執行完整流程，比對自動化結果與人工操作結果是否一致。第六步為持續監控，建立執行成功率的追蹤機制，當成功率出現異常下降，及時排查是否因為目標系統介面有重大變動。

除了上述六個步驟，企業也應該針對每套已導入自動化的老舊系統，建立一份簡要的介面變更記錄，每當發現系統版面有任何調整，即使當次自動化流程仍然成功運作，也應該記錄下這次變動的內容，作為未來排查問題或評估系統是否需要更新理解邏輯的參考依据。

七、成本與效益分析

上表為說明性假設，實際成本與穩定性差異需以企業自身目標系統的變動頻率重新評估，不應直接套用作為決策依据。

八、風險與限制：誤點擊與介面變動風險

AI導向RPA雖然提升了容錯能力，但並非完全沒有風險。第一個風險是誤判風險，模型對頁面元素的語意判斷並非百分之百準確，在某些版面複雜或元素標示不清的頁面上，仍可能誤判該點擊哪個按鈕，導致執行錯誤的動作，因此涉及資金異動或不可逆操作的流程，建議搭配人工核准關卡，而不是完全交由系統自動執行。第二個風險是執行速度與成本的取捨，由模型即時理解每一步畫面內容，相較於傳統座標式RPA直接執行預先記錄的固定動作，通常會增加額外的處理時間與運算成本，企業需要評估這個額外成本是否能被維護成本的降低所抵銷。第三個風險是過度依賴自動容錯能力，如果目標系統的介面變動幅度過大，例如整套系統改版，即使是AI導向RPA也難以單靠語意理解就完全應對，這種情況仍然需要人工重新檢視並更新整套自動化流程的任務拆解邏輯。

此外，企業也應該留意這類自動化技術仍然依賴底層模型的視覺與語意理解能力，如果目標系統的介面本身設計得極不直觀，例如大量使用沒有明確標示的圖示按鈕，即使是AI導向RPA，也可能需要額外的人工標註或訓練資料，才能達到可接受的判斷準確率，這部分的前期投入不應被忽略。

結語與下一步

AI導向RPA的核心價值，在於用語意理解取代固定座標，讓自動化流程在面對老舊系統偶發的介面變動時，具備一定程度的自我調適能力。下一步建議先針對企業內部變動頻率較高、傳統RPA故障率較高的流程優先導入，並建立例外情境的持續蒐集機制。若想進一步理解Agent與RPA在概念上的差異，可延伸閱讀相關主題。