RPA 的暴力美學
前陣子去 AI 新手村的活動，第一次聽到「RPA」這個詞。
我以前不是沒做過這件事，我一直在做，只是不知道它有名字。後來想想，知道你早就在做的事原來有個專有名詞，感覺其實滿特別的——代表夠多人在做這件事，多到需要一個詞來稱呼它。
RPA 全名是 Robotic Process Automation（機器人流程自動化），泛指讓程式代替人去點按鈕、填表單、複製貼上。它跟 API 剛好是同一個目標的兩條路：一條是廠商開給你的那道門，一條是使用者自己走的那道門。
標題那個「暴力」不是貶義。它指的是不跟廠商談、不等對方排開發時程，直接從使用者看得到的那一面把事情做完。醜歸醜，但事情有做完。
這篇會聊：我自己哪裡在用 RPA、它跟 API 差在哪、以前的 RPA 為什麼一改版就壞、AI 進來之後真正改變的是哪一段，還有「我們沒有 API」這句話還算不算護城河。
我早就在做，只是不知道它叫什麼
我現在的自動發文系統就是標準的 RPA。
它沒有走任何一家平台的官方 API。做法是用 Playwright 開一個真的瀏覽器，把每個網站要怎麼操作先摸過一遍——按鈕在哪、要先點哪一個才會跳出輸入框、發完之後怎麼確認真的送出去了——試到走得通之後，把那條路徑寫成固定的腳本，之後每天就跑那支腳本。
我用 Gemini 生圖也是同一套做法。
這兩件事我做的時候完全沒想過它有個名字。聽到 RPA 之後回頭看，才發現我做的每一步都在這個詞的定義裡面。
API 是廠商開的門，RPA 是使用者走的門
先把兩條路攤開來看：
| API | RPA | |
|---|---|---|
| 誰決定你能不能用 | 廠商 | 你自己 |
| 能做到的範圍 | 廠商開放多少就多少 | 畫面上看得到的都能做 |
| 穩定度 | 有版本、有文件，要改會先公告 | 介面一改就可能壞 |
| 速度 | 一次請求就回來 | 要真的把畫面一頁一頁點過去 |
| 出錯的時候 | 回傳錯誤碼，好抓 | 卡在某一頁，不一定知道卡在哪 |
| 前提條件 | 一把金鑰 | 要有一個已經登入好的瀏覽器 |
看完這張表，直覺反應通常是：能走 API 當然走 API。這個直覺沒錯，API 在大部分面向都比較文明。
問題是很多軟體根本沒有 API。企業內部那套用了十年的系統沒有，政府的申報網站沒有，某些線上軟體只開給企業方案，或是文件上寫著有、實際上你要的那個欄位沒開。這種時候你不是在 API 跟 RPA 之間選，你是在 RPA 跟「叫人自己點」之間選。
以前的 RPA 為什麼介面一改就壞
傳統 RPA 的做法是把流程錄下來：點畫面上哪一個按鈕（靠它的座標或屬性去認）、在哪個欄位輸入什麼、等幾秒、再點下一個。錄完存成腳本，之後照著重播。
問題是這種腳本綁的是元素怎麼被定位、以及執行的順序，不是意圖。廠商改版把按鈕挪個位置、多跳一個公告視窗、欄位順序調一下，整條流程就斷掉。而且斷掉不一定會報錯——它可能點到隔壁那個東西，然後很有自信地繼續往下跑。
所以 RPA 一直有個尷尬的定位：導入很快，維護很貴。真正的成本不在第一次寫，而在往後每一次對方改版都要有人回來修。這也是為什麼 RPA 專案常常第一年很漂亮、第三年沒人敢動。
AI 改變的是探索那一段，不是執行那一段
這是我聽到 RPA 之後想最久的一段。
我在課堂上一直強調 AI 適合探索。不確定路要怎麼走的時候，就讓它去試——它會看畫面、會判斷、走錯了會自己換一條再試，這正是傳統腳本做不到的事。Day 140 那篇寫 AI 操作本機 app（Cua、Hermes Agent）時，我當時在意的是它怎麼做到不搶我的游標；現在回頭看，更關鍵的是它讓「摸清楚一套介面怎麼操作」的成本變得很低。
但探索成功之後呢？
不少人的直覺是「那就讓 AI 每次都重跑一遍」。我的做法相反：一旦探索成功，就要把那條成功路徑收斂成固定執行的腳本。
原因很實際。探索是為了找到路，不是為了每天重新找一次路。每天重新找的代價是慢、貴，而且結果不保證一樣——同一句指令今天走這條、明天走那條，出錯了你連要修哪裡都不知道。收斂成腳本之後它每次都跑同一條路，至少每次壞的地方都一樣，能重現才修得動。
這其實就是 RPA 的基本精神：把人重複做的事變成固定流程。AI 沒有改變這件事，AI 改變的是「找出那個流程」要花多少力氣。以前要靠人一步一步試、一步一步錄，現在可以丟給 AI 去試。找到之後，一樣要收斂。
那「我們沒有 API」還算護城河嗎
過去「不開 API」是一種很有效的防守。資料進得來、出不去，客戶要搬家就得靠人工複製貼上，光是這點麻煩就足以把人留住。整合廠商想接你，得先跟你談合作、談分潤。
探索介面的成本被 AI 壓低之後，這道防線就守不住了。因為只要是人類使用者做得到的事，就沒辦法只靠「不開 API」擋住——你要擋的對象，在畫面上做的事跟付費使用者一模一樣。
但我不想把話講太滿。這條路也有代價：
- 它慢。API 一次請求的事，走介面要真的把頁面跑過一遍。
- 它需要一個真的登進去的環境，而不是一把可以直接丟進自動化流程裡用的金鑰。
- 它會被偵測。平台不用靠 API 擋，靠的是瀏覽器指紋、操作節奏跟頻率限制——被判定成機器人一樣進不去。
- 不少服務的使用條款本來就限制非官方 API 的自動化操作，能不能做跟該不該做是兩件事。
所以比較準確的講法可能是：不開 API 還是有防守效果，只是它從一道牆，變成一個減速丘。
探索歸探索，重複的事交給腳本——這是我本來就在做的事，差別只在探索那一段現在可以交給 AI，而且它有名字了。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/