緣起：一個 Claude Code Skill 引起我的興趣
前陣子在 Facebook 上滑到一個 GitHub 連結，Hao0321/ai-media-generator，標榜「無需專業知識就能用自然語言生成 AI 媒體內容」，自動跨 14+ 個生成平台跑提示詞。
我做 RPA 平台（自家的 WebOP / chrome-cli-bridge），對「自動操作瀏覽器」這件事天天打交道。看到對方號稱用 LLM 直接驅動瀏覽器、不用寫腳本就能跨平台跑，我第一反應是：
這跟我做的是同一條路線，但走的方向完全不同。到底哪一派穩、哪一派強？
於是把 repo clone 下來細看了 automation/ 跟 references/，順便把我自家平台的架構拿來對比，得到的結論跟我一開始的直覺有點出入。整理成這篇給同樣在思考「LLM Agent 該不該取代傳統 RPA」的朋友參考。
ai-media-generator 是什麼？
讀完整個 repo 後可以一句話總結：它完全沒有可執行程式碼，全部是 markdown。
SKILL.md ← 20KB 主指令，告訴 LLM 怎麼分派任務
references/ ← 25 份各平台 prompt 寫法 + 鏡頭語言詞典
templates/ ← storyboard、preset-packs、auto-pilot 等模板
automation/
├ browser-guide.md ← 各站高層流程
├ click-protocol.md ← 11 part 通用 click SOP（這份最有料）
└ site-profiles/ ← 12 個網站的 UI 地圖、座標、已知陷阱它的運作模式是：
- 使用者跟 Claude Code 說「幫我在 Kling 上生這段影片」
- Claude 讀對應的 markdown，知道流程跟陷阱
- 透過
claude_in_chromeMCP 開使用者的 Chrome - 用「截圖 → 看畫面 → 推理下一步 → 點擊/打字 → 再截圖驗證」的循環推進
所有自動化邏輯都活在 LLM 當下的推理裡，沒有任何寫死的腳本。每次執行 LLM 重新讀 markdown、重新看畫面、重新決定。
這跟我自家的 WebOP 完全是兩個世界。
兩種架構流派的本質差異
| 維度 | ai-media-generator (LLM + MCP) | 我的 WebOP (Extension + Server) |
|---|---|---|
| 誰在驅動瀏覽器 | LLM 每步推理，呼叫 MCP tool | Extension 跑寫死的 JS 腳本 |
| 狀態判斷 | screenshot + 視覺辨識 | CSS/XPath selector + DOM 事件 |
| 腳本形態 | 自然語言 markdown（給 LLM 讀） | 確定性 JS（給瀏覽器執行） |
| 執行單位成本 | 每次 ~$0.5-2 美元、3-15 分鐘 | 幾乎為零、秒級 |
| 需要 LLM 在線 | 必要（LLM 是 runtime） | 不需要（cron 就能跑） |
| 可在服務模式跑 | 不行 | 可以（NSSM 服務化部署） |
我把這兩派叫做：LLM 驅動派 vs 腳本驅動派。
第一輪分析：穩定度誰贏？
LLM 驅動派的穩定性是「軟性」的
看 ai-media-generator 的 click-protocol.md（這份文件寫得真的非常細，11 個 Part），會發現對方自己承認的踩雷：
- ref 活不過 2 個 tool call — find 完不能 screenshot，要立刻點
- 座標會漂移 — scroll 一下整個變
- selected vs hover ring 容易誤判 — 要看填底色不是看邊框
- silent failure — click 沒中不會報錯，要 before/after screenshot 對比
\n觸發送出 — type 帶換行內容直接被截斷
裡面甚至有一段慘痛教訓：
「OiiOii Seedance 戰鬥生成跑 4-5 次才成功，浪費 40+ 分鐘 + 數千 token」
LLM+MCP 的穩定性是這樣的特性：出錯能自我修正、能繞、能換策略，但每次都從零推理 → 結果不可重現。同一個流程跑 10 次可能走 10 種路徑、3 次失敗。
腳本驅動派的穩定性是「硬性」的
我自家 WebOP 累積到現在的工程作為：
- per-origin 分頁鎖、watchdog、5 分鐘自癒
- selector 改一次寫一次，不同銀行平台 selector 全表實測對照
- 重啟即用、cron 排程 OK、可在 LocalSystem 服務帳號下跑
- 多服務並行各管自己分頁，不搶焦點
selector 對就 100% 過、selector 壞就 100% 掛，但可重現、可監控、可自癒。網站改版時是 loud failure（爆掉立刻知道），不是 silent drift。
穩定度的結論很清楚：要 24/7 跑生產線型任務，腳本驅動派完勝。LLM 驅動派根本沒資格上場。
第二輪分析：LLM 真的「能」自己操作瀏覽器嗎？
這是我自己第二輪冷靜下來問的問題。坦白說，我前面把 LLM+MCP 講得太美。實際的時間/成本帳是：
「在 FB 發一篇貼文」實測估算：
| 動作 | 耗時 | Token |
|---|---|---|
| 一次 screenshot | 1-2 秒 | ~1500 token（一張 1568×708 圖） |
| LLM 看圖+想下一步 | 5-30 秒 | 2-5k token（含 thinking） |
| 一次 click/type | 1 秒執行 | 幾百 token |
| 一個「點按鈕」完整 cycle | 10-30 秒 | 3-7k token |
發一篇 FB 貼文 = 開頁 → 等載入 → 找輸入框 → 點 → 打字 → 找送出 → 點 → 驗證 ≈ 7-10 個 cycle
= 2-5 分鐘、30-70k token、$0.3-1 美元
我寫腳本：200ms、$0
而且 LLM 燒 token 是常態，不是意外。click-protocol.md 整份文件就是在防這件事。常見燒法：
- ref 失效 → 重 find → 又失效 → 改座標 → 漂移 → screenshot → 又重來
- click 沒中（hover ring 被誤判成 selected）→ 又點 → 又看 → 又點
- 每個 action 後習慣性 screenshot 驗證（每張 1.5k token）
- 等待長任務時每 60 秒 polling screenshot
LLM+MCP 跑單一已知任務，本質是用 $1 + 5 分鐘做完 selector $0 + 0.5 秒能做完的事。
它真正划算只有兩種情況：
- 這任務你只會做一次（不值得寫腳本）
- 這任務每次都不一樣（腳本寫不出來，例如「找今天最有梗的 reddit 貼文翻譯成中文」）
第三輪：那 LLM+MCP 到底有沒有結構性優勢？
我一開始列了 7 個「LLM 才做得到」的場景，後來發現其中一條是我自己騙自己。
我講錯的部分：OS 層級存取
我前面說 LLM+MCP 強在「能處理 Windows 系統 Dialog（UAC、另存對話框、Chrome 權限彈窗）」，因為它在 OS 層運作，不被 Chrome sandbox 限制。
這是錯的。我自家架構也有 OS 層級存取。
我的 WebOP 不只是 Chrome Extension，它是：
Chrome Extension (in-browser)
↓ HTTP
localhost Python Server (OS-level)
↓ HTTP
privileged broker on local port (privileged)實際具備的 OS 層能力：
| 我之前說「LLM+MCP 才能」 | 我其實有的解法 |
|---|---|
| 攔 Windows 另存對話框 | 發票憑證模組已經用 pywinauto 在做 |
| 系統 UAC 提示 | privileged broker 已經繞過了 |
| 截圖整個畫面 | localhost server 一行 PIL.ImageGrab |
| 滑鼠移到 Chrome 視窗外點別處 | pyautogui 從 server.py 呼叫 |
| 殺 elevated 程序 | privileged broker 已有 |
我的架構在 OS 層的能力，跟 computer-use agent 是同一個量級的，差別只是「誰決定下一步動作」。
修正後：LLM+MCP 真正結構性贏的場景只剩 4 個
砍掉錯誤的「OS 層」優勢，剩下這 4 類是真的腳本派打不過：
1. Canvas / WebGL 介面（沒有 DOM 可選）
tldraw、Figma、Konva、Three.js、線上影音剪輯、3D 設計工具 — 整塊畫面只有一個 <canvas> 元素，所有內容是 GPU 繪製。document.querySelector 物理上拿不到「那個按鈕」「那個圖層」。
OiiOii 整個中央區就是 tldraw canvas。LLM+MCP 看 screenshot + 點座標可以操作，selector 寫了等於對著一張圖片發呆。
2. Closed Shadow DOM / 高隔離 widget
attachShadow({mode: 'closed'}) 的元素，content script 100% 進不去。某些客戶側登入框、付款元件、第三方 widget 用這招防爬。LLM 看 screenshot 不受影響。
3. 視覺品質判斷（生成式內容的核心）
「這四張生圖選最像產品實物的那張」「這段影片人臉有沒有崩」「這個 logo 有沒有亂碼」— selector 拿到的是 URL，但 URL 不會告訴你圖好不好看。
4. 反偵測敏感站
某些網站（Cloudflare Turnstile、PerimeterX、部分券商/博弈站）會偵測：
- DOM 是否被注入過（content script 留痕）
- 事件是否來自真實 trusted user gesture
- mouse trajectory 是否平滑
LLM+MCP 走 computer use 是 OS 級的真 mouse/keyboard，反爬蟲基本看不出來。Extension 注入痕跡很明顯。
外加一個工程效率問題（不是結構限制）
零工程上線一次性任務：新接一個服務，腳本派要開 DevTools → 找 selector → 寫 JS → 加進腳本登記檔 → 改 server endpoint → 改 control panel 設定，至少 1-2 小時。
LLM+MCP 寫一份 markdown profile（甚至不寫直接讓它探索）就能跑。新站邊際成本 ≈ 0。
別騙自己：這些其實腳本派也做得到
避免高估「LLM 才能做」的範圍，列一張對照表：
| 看似只能 LLM 做 | 腳本派其實有解 |
|---|---|
| OCR 抓圖內文字 | 截圖 → 丟 Claude Vision API |
| 判斷錯誤訊息語意 | toast 文字抓出來 → Claude API 分類 |
| 圖好不好看 | 截圖 → Claude Vision 評分 |
| 多步驟條件邏輯 | server 寫條件分支 |
| 跨網站串接 | server 當 orchestrator 調多個 modules |
| 動態 className（hash class） | 用 text content / aria-label / 位置選 |
| Trusted Types 禁 innerHTML | 用 textContent + dispatchEvent 解（Gemini 生圖模組已實作） |
這些不是架構限制，是工程實作問題。瓶頸是工程時間，不是技術可能性。
戰略結論：兩派各有歸宿
LLM 驅動派的真正定位
不是「取代傳統 RPA」，而是：
- 新領域探索：沒人寫過腳本的網站、一次性任務
- 創作判斷：需要美感、文意理解的場景
- 無 DOM 介面：Canvas、3D、繪圖工具
- 反爬蟲對抗：高端反偵測網站
它是「人類助理」級別的工作模式 — 慢、貴、彈性高、會犯錯但會自己改。
腳本驅動派的真正定位
- 生產線型重複任務：發票、銀行對帳、報表、廣告投放
- 24/7 無人值守：cron + service 模式
- 批次大量處理：每月 1000 筆發票上傳
- 與本地系統深度整合：寫 CSV 到 NAS、串 ERP
它是「機台」級別的工作模式 — 快、便宜、可重現、可監控、要工程治具但治具寫好了一勞永逸。
比喻
- LLM+MCP ≈ 雇個臨時工坐在電腦前，每次都看 SOP 手冊操作。彈性高、薪水貴、會打錯字。
- Extension+Server ≈ 寫了個自動化機台。便宜、快、可靠，但每個新產品線要重新設計治具。
做生產線（記帳、發票、銀行對帳、廣告投放）就走腳本派；做創意工坊（看心情生圖/影片）就走 LLM 派。架構選擇都對，因為目標不一樣。
從 ai-media-generator 我會偷的東西
雖然路線不同，這個 repo 有一些資產直接可以借用，跟架構無關：
純資產（直接搬到自家平台）
references/community-prompt-patterns.md、camera-language.md、cinematic-direction.md— 把這些塞進自家 ChatGPT/Gemini 生圖模組的 prompt 預處理，輸出品質立刻提升templates/storyboard.md、preset-packs.md— 一鍵生宣傳片的模板click-protocol.mdPart 4「selected vs hover 視覺辨識」、Part 9「驗證循環」— 寫成自家 RPA 腳本的標準後處理
架構靈感
它的 site-profiles/ 一站一份 markdown 寫陷阱、座標、實測筆記的組織方式，比我目前 rpa_modules.json + 散落腳本好讀很多。可以給每個 RPA 模組配一份 profiles/<service>.md。
不要學的
不要把生產線流程改成 LLM 驅動。發票下載絕對不要靠 LLM 看 screenshot 判斷。
給正在選型的朋友的最後一句話
最近 AI Agent 概念很熱，到處都在喊「Computer Use 時代來了，傳統 RPA 要被淘汰」。從技術可行性來看，LLM 確實能直接操作瀏覽器；但從成本 / 速度 / 穩定性三項指標看，它跟成熟的腳本式 RPA 不在同一個賽道。
真正的問題從來不是「能不能做」，而是「值不值得這樣做」。
如果你的場景是：
- 已知流程 + 高頻重複 + 要 24 小時跑 → 腳本派（Selenium / Playwright / 自家 Extension）
- 未知網站 + 一次性 + 容忍慢容忍貴 → LLM 派（Claude Computer Use / browser MCP）
- 需要視覺判斷 + 創作品質 → LLM 派
- 兩種都有 → 兩個架構共存，不要硬要統一
LLM 不會殺死 RPA，但會搶走 RPA 不擅長的那部分新需求。理解兩派的真正邊界，比追熱點重要。