消失的n年與「永不結案」的自動化
在大型企業的開發職涯中，我們偶爾會遇到一種令人費解的現象：一個原本應提升效率、簡化流程的 RPA（流程自動化）專案，執行了n年卻依然無法穩定「結案」。
每當腳本失效，開發人員總是以「網銀改版」、「網路不穩」或「環境變動」作為理由。但身為技術人員，我們必須誠實地自問：這究竟是外部環境的限制，還是我們選用的工具與思維，早已跟不上現代網頁架構的演進？
座標模擬的窮途末路：AutoIt 的侷限性
在過去的桌面軟體時代，AutoIt 憑藉簡單腳本邏輯與 UI 模擬能力，確實解決了不少問題。然而面對現代複雜網頁，傳統 UI 模擬（甚至包含 UIA 模式）已顯得力不從心：
- 「盲人摸象」的操作邏輯：AutoIt 的 UIA 本質上是透過作業系統層級的輔助介面去「窺探」瀏覽器。它並不真正理解網頁 DOM 結構，面對動態渲染（React/Vue）時，常發生定位偏移或找不到元素。
- 無法感知的網路狀態：這是最致命的缺點。AutoIt 難以判斷瀏覽器底層請求是否真的完成，開發者被迫塞入大量
Sleep，靠「猜測」與「盲等」維持運作。這不僅效率低，更是穩定性問題的核心來源。 - 數據傳輸的風險：依賴系統剪貼簿（Ctrl+C / Ctrl+V）進行數據交換，極易受到系統彈窗、輸入法切換或人為操作干擾。
職場的慣性陷阱：當「習慣錯誤」成為阻力
比技術債更可怕的，是「心態債」。在推動轉型時，最常遇到的阻力往往來自於：
- 承辦人員的舒適圈：長期合作的承辦人員往往習慣了與原維護人員的對話模式：「出錯、報修、微調」。雖然效率低下，但因為熟悉而感到安全。面對更先進、穩定的新技術，反而可能因擔心失去流程掌控感而排斥。
- 技術壟斷下的資訊不透明：當開發者不與同仁交流，並將工具缺陷包裝成環境限制時，主管與承辦人就會被誤導，認為現狀已是最好。這種閉門造車，本質上是把個人技術瓶頸，強加成公司的發展上限。
現代化轉型：Playwright + C# 的實戰優勢
為了終結惡性循環，我們需要的是具備「可觀測性」與「可維護性」的現代化架構：
- 原生驅動（Playwright）：直接與瀏覽器引擎溝通，並可搭配等待條件與斷言（load state、locator assertions）降低流程不確定性。相較傳統 UI 模擬，在動態網頁場景通常有更高穩定性。
- 精準定位與自動等待：透過語意化 locator 與內建 auto-wait，可大幅減少使用
Sleep。即使網頁小幅改版，通常也能以較小成本完成調整。 - 無感數據整合（C#）：透過 C# 直接處理資料流（檔案、記憶體物件、API），降低對剪貼簿與前景視窗的依賴，明顯減少非預期干擾。
成效要能被驗證：用 KPI 讓轉型不是口號
若要讓主管與承辦人信服，除了技術語言，更需要可被追蹤的成果。建議至少建立以下三個指標，按月回顧：
- 自動化失敗率：定義每月排程總次數中，失敗任務所占比例。目標不是零失敗，而是持續下降且可解釋。
- 平均修復時間（MTTR）：從告警到恢復正常所需時間。框架標準化後，MTTR 應顯著縮短。
- 人工介入次數：統計每月需要人工接手的次數。若轉型有效，介入頻率應下降，且集中在真正例外情境。
警惕「技術斷層」與營運危機
大型企業面臨最嚴重的危機，莫過於「人退程式亡」。當關鍵自動化流程依賴單一人員，且工具過時又無人願意接手時，企業營運連續性將面臨巨大考驗。
引入現代化、標準化開發框架（如 C# 與 Playwright），目的不只是讓專案結案，更是建立一套透明、可維護且具備知識傳承價值的企業數位資產。
結論
一個專案做了n年還沒結案，本身就是對效率的警示。身為開發者，我們不應滿足於「程式會動」，而應追求「程式優雅且穩定」。
打破技術孤島，主動引進更高效的工具，是我們對專業的負責，也是對企業價值的守護。真正成熟的技術人，不只會把功能做出來，更能把流程做穩、把知識交接出去、把風險透明化。
當團隊從「靠人撐系統」走向「靠系統撐營運」，這才是企業數位轉型真正的完成態。