第 進階 章
用 AI 自動化
瀏覽器上的雜事
給不會寫程式、但願意碰一點終端機的台灣上班族：先從低風險的讀資料、篩選、截圖、匯出開始
很多網頁上的重複雜事已經能交出去，但真正省時間的關鍵不是會跑，而是你有沒有把任務講成可驗收條件，還留得下證據。
網頁雜事，其實能交出去
每天打開同一個後台，切日期，點篩選，抄 3 個數字，截圖留存，再貼去 Excel。做一次只是煩，天天做、每週做、每月做，就會變成很實際的時間黑洞。好消息是，很多這種「在瀏覽器上重複按來按去」的工作，現在已經可以慢慢交給 AI。
這篇走的是比較誠實的進階手把手路線。你不用會寫程式，但要願意碰一點終端機，也願意先裝好 Node、Playwright，看得懂基本指令在做什麼。適合你的是：有固定網頁雜事、想從低風險的讀資料與截圖開始、願意先做一次再慢慢變成可重複用的小工具。
如果你完全不想碰終端機，或只是偶爾想叫 AI 幫你操作幾步，那 Atlas、Comet、Claude in Chrome 這類比較消費級的瀏覽器 AI，反而可能更適合你。這篇比較在意的是可控、可驗證、可慢慢做成 SOP 的路線。
每天手動
- 開報表頁
- 切日期
- 選門市
- 抄 3 個數字
- 截圖存證
一段指令跑完
open
goto report
snapshot
eval e40
screenshot先判斷值不值得自動化
不要一看到 AI 就想把所有工作都丟進去。先問自己 4 個問題：這件事是不是會重複做？流程是不是大致固定？成功標準能不能講清楚？失敗會不會造成高風險後果？
像每天早上看同一頁報表、每週一抓上週數字、每月初下載月結單，這種越重複、越固定、越能講清楚成功條件的任務，就越值得先做。相反地，如果每次都要臨場判斷很多，或一失敗就可能付款、刪除、正式送出資料，入門先不要碰。
你可以把判斷口訣記成一句話：前 3 題大多是「是」，第 4 題是「否」，這件事就很適合當第一個自動化練習。
先問這 4 題
口訣：前 3 題是，第 4 題否，就很適合拿來當第一個練習。
動手：先跑一個讀取型任務
第一個案例，先不要做自動送出，而是用最安全也最實用的類型：打開報表頁、套條件、讀數字、截圖留證。這裡用 playwright-cli 示範，它很適合第一次上手，因為你可以一個動作一個動作做，邊看畫面、邊確認自己在哪裡。
白話講，snapshot 可以先把它想成「AI 讀得懂的頁面地圖」，裡面會出現像 e3、e12、e40 這種 ref，也就是頁面元素的臨時代號。你後面不用硬寫很長的 selector，而是直接用 ref 點按鈕、抓文字。網站不同，網址與 ref 編號一定會變，所以你要照自己的畫面替換。
照著跑一次，你會更快抓到節奏
典型順序就是：open 開瀏覽器，goto 去指定頁面，snapshot 看頁面地圖與 ref，click eXX 套日期與篩選條件，eval 抓文字，screenshot 留證，--raw eval 把乾淨結果導出成文字檔，最後 close 關閉。
真正難的不是背指令，而是養成一個習慣：每做完一個關鍵步驟，都要確認畫面證據真的對。不要只憑感覺覺得剛剛有按到。
playwright-cli open
playwright-cli goto https://example.com/report
playwright-cli snapshot
playwright-cli click e3
playwright-cli snapshot
playwright-cli click e18
playwright-cli click e22
playwright-cli snapshot
playwright-cli click e12
playwright-cli snapshot
playwright-cli click e30
playwright-cli click e33
playwright-cli snapshot
playwright-cli eval "el => el.textContent" e40
playwright-cli screenshot --filename=report-proof.png
playwright-cli --raw eval "el => el.textContent" e40 > revenue.txt
playwright-cli close會跑，不代表做對
很多人一開始做瀏覽器自動化，最容易犯的錯就是：指令跑完了，就以為任務完成了。但真正能拿來工作的流程，不是只有「會跑」，而是「有證據證明它做對」。你可以把 plan.md 想成任務的驗收單，先把 critical points，也就是關鍵驗收點，列清楚。
例如報表任務不要只寫「抓昨天的報表」，而要拆成：已打開正確報表頁、日期條件已切到昨日、門市篩選已設為台北門市、已讀出營收/訂單數/新會員 3 個數字、已留下可核對的截圖證據。這樣你才知道後面該留什麼證據。
跑完後要 self-verify，也就是自己再驗一次。最少看 4 件事：截圖裡是不是看得到正確頁面、看得到正確條件已套用、log 裡是不是有記到關鍵步驟、最終數字是不是跟畫面上的值對得起來。只要有一件模糊，就不要急著把結果貼給主管。
證據自查 4 點
證據模糊就不算過，先補截圖或補 log。
重複使用：把一次代工變成小工具
第一次成功，通常只是開始。真正省時間，是第二次、第三次不用重做。最先能做的，是重用登入狀態。登入一次之後用 state-save 存下來，下次流程前再用 state-load 載回去，很多站就不用每次重新輸入帳密。
如果你有不同站點或不同用途，也可以用具名 session。像 -s=mysession 這種做法，適合把不同網站、不同帳號、不同任務分開管理。比起每次都從零開始，比較不容易混亂。
再往前一步，是把流程做成 CLI tool。你可以把 one-shot 想成同事幫你做一次，把 CLI tool 想成同事把 SOP 寫成可重用模板。像 --month、--store、--customer 這些可變的值，都可以參數化，還要有預設值、--help，log 第一行最好記下這次實際用了哪些參數。
playwright-cli state-save auth.json
playwright-cli open
playwright-cli state-load auth.json
playwright-cli goto https://example.com/report
playwright-cli -s=mysession open https://example.com/report --persistent
playwright-cli -s=mysession click e6
playwright-cli -s=mysession close
# 之後做成可換參數的小工具
--month 2026-05
--store 台北門市
--customer ACME風險守則：先保守，再放大
瀏覽器 AI 自動化很好用，但也很容易因為太方便而出事。研究底稿特別提醒一個風險叫間接 prompt injection，也就是攻擊者把惡意指令藏在網頁內容裡，等 AI 去讀網頁時，把那些字誤認成它該遵守的新指令。Comet 就曾出現過相關案例：攻擊者把隱藏指令塞進 Reddit spoiler，誘導瀏覽器 AI 去抓 email 與一次性驗證碼。
所以入門請一律從讀取型任務開始，不要讓 AI 在送出、付款、刪除的頁面自主亂跑。帳密與登入也要保守處理，優先用測試帳號或權限較低的帳號，確認截圖與 log 不會亂存到公開位置。
另外也要有心理準備：網站只要改版，按鈕文字、篩選器位置、登入流程一變，腳本就可能壞掉。再加上目標網站的 ToS 與公司內部規範，不是所有網站都歡迎自動化操作或大量擷取資料。把它當成需要維護的小工具，而不是一次做完永遠穩定。
先守住這些底線
- 留意間接 prompt injection
- 不要自主送出、付款、刪除
- 帳密與登入狀態要保守管理
- 網站改版了，腳本就可能壞
- 先看 ToS 與公司內規
學完這章你可以…
一句話記住重點
很多重複的網頁雜事已經能交給 AI，但會跑不等於做對。把任務講成可驗收條件，再用截圖和 log 留下證據，你才是真的在省時間。
現在就試
這週先挑一個你每週都會看的報表頁。只做最小版本就好：套一個日期條件，抓 1 到 3 個數字，存一張截圖，再用 --raw 把其中 1 個數字存成文字檔。先證明這件事真的能穩定被讀出來，不用第一天就做成排程。