先判斷改版破壞了哪一層契約
RPA 操作網頁或桌面系統時，實際上依賴多層契約：元素如何被辨識、畫面何時可操作、欄位代表什麼業務意義，以及送出後應出現什麼結果。畫面改版可能只改了 CSS class，也可能同時調整頁面流程、欄位名稱、驗證規則或權限。若一看到找不到元素就立刻改 XPath，很容易修好表面問題，卻忽略後續步驟已不再符合原本的業務流程。
排查時應先把故障分成三類。第一類是定位失敗，例如元素屬性、iframe 或 DOM 結構改變；第二類是同步失敗，例如元件改成延遲載入，機器人點得太早；第三類是業務契約改變，例如必填欄位增加、按鈕改成多階段確認。分類後再決定要修改選擇器、等待條件，還是重新確認流程需求。
用分層策略設計選擇器
選擇器的核心原則不是愈短愈好，而是依賴穩定且具有語意的訊號。開發時應先詢問系統團隊能否提供專用的 automation ID、data 屬性或穩定的 accessibility name；這些欄位不應隨視覺排版或前端建置而改變。若無法控制來源系統，再依照穩定性由高到低組合其他訊號。
- 優先使用穩定識別：automation ID、資料鍵值、可存取性角色與名稱，通常比動態產生的 class 或完整 XPath 更可靠。
- 限制搜尋範圍：先定位表單、對話框或表格列，再尋找其中的按鈕與欄位，避免頁面出現同名元素時誤點。
- 利用結構關係：以欄位標籤、表頭或相鄰容器建立相對定位，但不要依賴固定的第幾個子元素。
- 文字定位要有邊界：適合穩定的功能名稱，但須考慮語系、空白、文案調整及同名按鈕。
- 影像與座標作為末端方案：只有在 Canvas、遠端桌面或無法取得元素樹時使用，並搭配解析度、縮放與辨識信心檢查。
重要操作不宜使用過度寬鬆的備援選擇器。例如找不到「核准」後，不能退而點擊畫面上第一個主要按鈕。涉及付款、刪除、送出或狀態變更時，寧可停止並告警，也不要以模糊匹配繼續。較安全的做法是使用多個必要條件確認目標，並在動作後驗證業務結果。
讓測試在上線前發現脆弱點
只測完整流程通常回饋太慢，也難以指出故障位置。可以把測試拆成幾層：對選擇器做靜態檢查，確認沒有依賴明顯的動態 ID 或過長絕對路徑；針對共用登入、搜尋、表格選列等元件做獨立測試；最後保留少量端到端測試，驗證真正的業務結果。測試環境若與正式環境差異過大，至少要保留相同的前端版本與主要權限組合。
- 改版前：取得測試環境或預覽版本，執行關鍵流程與選擇器掃描。
- 部署後：先跑不會寫入資料的冒煙測試，再測可回復或專用測試帳號的交易流程。
- 排程中：記錄每個步驟的開始、等待、定位與驗證結果，而不只記錄整體成功或失敗。
- 失敗時：保存截圖、頁面網址、視窗標題、元素樹或 DOM 摘要、應用程式版本與執行輸入的安全摘要。
等待條件也必須納入測試。固定暫停幾秒會讓正常流程變慢，遇到尖峰時又可能不夠。應等待可觀察的狀態，例如元素可見且可操作、載入指示消失、資料列數穩定，或後端回傳完成。若等待逾時，錯誤訊息應指出正在等待哪一個狀態，而不是只留下通用的 timeout。
建立可在壓力下執行的快速修復流程
事故發生後，第一步不是立即重跑。必須先確認前一次執行是否已部分完成，特別是建立訂單、傳送通知或更新 ERP 狀態的流程。沒有冪等性或重複檢查時，盲目重試可能比停機更危險。
- 控制影響：暫停相關排程，保留佇列與執行紀錄，不刪除現場證據。
- 重現與分類：使用相同帳號角色、資料條件與前端版本，判斷是定位、同步、權限或業務規則問題。
- 比較變更：檢查 DOM、可存取性樹、iframe、視窗階層與畫面文案，而非只比較截圖。
- 做最小修正：更新共用元件或集中管理的選擇器，避免在多個流程各自貼上臨時修補。
- 驗證副作用：測試正常、空資料、重複資料、逾時與權限不足等路徑，並確認實際業務狀態。
- 分段恢復：先以測試帳號或小範圍佇列執行，確認監控正常後再恢復完整排程。
長期可維護性來自可替換的頁面元件、集中式選擇器、清楚的步驟名稱，以及每個流程的負責人與回復程序。對無法控制的第三方介面，還應保留人工接手機制與安全停止點。當流程同時跨越 LINE、ERP、CRM、雲端服務與舊系統時，整合團隊的價值不只在開發機器人，更在建立這些跨系統的驗證、監控與變更管理邊界。