新同事到職的第一週，我通常不會急著請他找產品的問題，而是先讓他把流程完整走過一次。跑完之後，再請他說說看：他做了哪些操作、畫面上看到了什麼，又在哪些地方停下來確認。
原因很簡單。如果連產品正常運作的樣子都還說不清楚，這時候提出的「異常」多半也很難判斷。
所以今天先讓這位 AI 同事做第一件實際工作：自己走完一條產品流程。
我想先確認三件事。
第一，前六天準備的環境到底能不能用。瀏覽器、測試帳號、產品知識和權限都已經設定好了，但這些東西只有真正跑過一次，才知道有沒有接好。如果現在失敗，反而容易處理，因為問題大多還在環境或設定，不必立刻懷疑產品。
第二，它是否真的讀得懂畫面。瀏覽器能把頁面內容交給它，不代表它知道哪個是主要按鈕、購物車在哪裡，或目前走到結帳的哪一步。這些能力不能靠設定檔確認，只能看它實際操作。
第三，從第一趟任務開始就要求它留證據。這個習慣越早建立越好。若等到它開始回報問題，才發現截圖、console 或 network 紀錄都不完整，最後還是得自己重跑一次確認，那就省不了多少時間。
我使用的是一個公開的電商練習站，任務範圍很單純：
登入 → 瀏覽商品 → 加入購物車 → 進入結帳流程 → 停在付款前
這一輪走到結帳第 3 步的 Billing Address 就停下來，再繼續才會進入付款。
停在付款前是刻意安排的。第一次執行任務，先不要碰真的會產生後果的操作，例如送出訂單、刪除資料或寄信。等它的行為穩定，再逐步開放。
不過，指令裡寫著「不要送出訂單」並不等於真的有防護。那只是一項工作約定，仍然建立在 AI 會照指令執行的前提上。昨天設定的 deny 規則才是最後一道限制：指令約束它打算做什麼，權限則限制它實際能造成什麼結果。第一次任務最好兩者都保留。
最直覺的做法，可能是把每一步都列出來：
1. 打開 https://practicesoftwaretesting.com
2. 點右上角 Sign in
3. 輸入帳號 xxx 密碼 yyy
4. 點 Login
5. 回首頁，點第一個商品
6. 點 Add to cart
...
這樣雖然可控，卻把 AI 用成了一支昂貴的錄製腳本。只要實際畫面和預期稍有不同，它最有用的能力——觀察當下狀態並決定下一步——就派不上用場。
我改成這樣交代：
用測試帳號登入，挑一個商品加進購物車，走到結帳流程的付款頁前面停下來。
每一步留截圖，記下 console 和 network 有沒有異常。不要真的送出訂單。
這段指令只交代目標、邊界和交付物，實際怎麼走由它自己判斷。
第三週會正式把工作方式從「逐步下指令」改成「交付目標」。今天先用一條範圍清楚的流程試跑，感受兩者的差別。
任務結束後，AI 很可能會回覆：「已完成登入、加入購物車並進入結帳頁，一切正常。」
這句話沒辦法驗證。從「一切正常」看不出它實際走到哪一頁、畫面出現什麼數字，也不知道它是否跳過了某個環節。
所以我先看它留下的資料。一次操作完成後，證據資料夾大致會是這樣：
output/evidence/20260802-toolshop-checkout/
01-home-after.png
02-login-before.png
03-login-filled-before.png
04-account-after-login.png
05-home-loggedin-after.png
06-product-before-addcart.png
07-product-after-addcart.png
08-cart-after.png
09-checkout-step2-signin-after.png
10-checkout-step3-billing-after.png
console.log
network.log
manifest.md
notes.md
trace.zip
這裡有幾個細節值得注意。
截圖要編號。01-、02-、03- 本身就代表操作順序，即使不讀說明，也能大致重建當時走過的路。
檔名描述的是畫面狀態，而不是剛才做了什麼。像 03-login-filled-before 表示「帳號密碼已填好，但還沒按 Login」。日後回頭比對時，我們關心的是當下留下了什麼狀態，而不是一段籠統的操作敘述。
console 和 network 也要各自存成檔案。頁面看起來能操作，不代表底層沒有錯誤；後面幾天還會繼續用到這兩份紀錄。
跑到這裡已經開始產生 token 成本，先看看實際數字。
以下是我執行一次登入與購物車探索的帳單。整段約四分鐘，包含 23 次瀏覽器操作，使用 Opus 5：
| 項目 | tokens | 單價／MTok | 成本 |
|---|---|---|---|
| output | 17,061 | $25 | $0.43 |
| cache write | 135,444 | $6.25 | $0.85 |
| cache read | 4,438,251 | $0.50 | $2.22 |
| input | 132 | $5 | $0.00 |
| 合計 | 約 $3.5（新台幣 110 元左右） |
一次探索約 3.5 美元。如果一天跑十輪，費用很快就會累積。值不值得要看實際用途，但最好在開始大量執行前就知道成本大概落在哪裡。
這份帳單裡，cache read 佔了約 63%。這筆費用不是來自它最後寫了多少文字，而是操作過程中必須持續讀取前面累積的畫面、紀錄與判斷。這次走了 23 步，最後讀取的快取內容超過 440 萬個 token。
這次數據可以看出兩件事。首先，這一輪沒有提早切段或壓縮 context，因此流程越長，後面的步驟通常要重讀越多內容；這是本次工作流的觀察，不代表所有 agent 都一定遵循相同的成本曲線。其次，第三天提到 MCP 工具 schema 會進入 context，實際操作次數一多，這些內容也會反覆被讀取。
要控制成本，重點通常是減少不必要的重讀，而不只是限制最後輸出幾個字。後面的實作也會沿用這個原則：只提供當下需要的資料，不要一開始就把整間公司的文件全部塞給它。
第一次跑完，通常會遇到以下三種情況。先別急著把它們當成產品 bug。
可能是登入失敗、頁面打不開，或找不到預期的元件。先回頭檢查環境變數、網址、測試帳號與前六天設定的權限，再決定是不是產品本身有問題。
這類失敗通常不難處理，因為現象明顯，原因也比較集中。
它回報已完成，截圖卻顯示沒有使用搜尋，甚至沒進到結帳第二步。
這時先檢查任務描述是否講清楚。若邊界含糊，AI 就只能自己補上一個「完成」的定義。修正方式是把必要的結果和範圍說得更具體。
例如 console 出現 404、某個欄位是空的，或金額看起來不太合理。
今天先記錄，不急著判定。異常是否構成 bug，需要另一套分類與查證方法，第二週會專門處理。若現在就要求它看到什麼都報，很快便會收到一堆沒有優先順序的 404 和雜訊。
前六天談的都是如何讓它開始工作，第一次實際執行時，還需要告訴它何時應該停下來。
我使用的規則是：同一個障礙嘗試兩次仍無法通過，就停止並回報給人。
以登入失敗為例，重試一次仍然失敗，就不該繼續換帳號、猜密碼規則，或跳過登入改測其他頁面。這些看似靈活的做法往往最花 token，而且等它繞完，我們反而更難確定它實際測過什麼。一個人可能三十秒就能排除的環境問題，沒必要讓 AI 自己摸索十幾分鐘。
這條規則後面還會用到。第三週的探索迴圈要靠它決定何時收手，第五週的重跑閘門也需要它判斷何時升級給人。第一次任務容易碰到環境問題，正好可以先把停止條件建立起來。
一份證據包可能包含截圖、影片和 trace，一輪就有幾十 MB。連續跑三十輪，很容易累積到幾 GB。
我先訂三條規則：
如果完全不管理，用不了多久，磁碟空間就會先替你提出警告。
驗收時，我只問一個問題：
只看它留下的紀錄，我能不能自己把這條流程重走一次？
這個問題同時涵蓋了步驟是否完整、證據能否對上操作，以及關鍵狀態有沒有被記錄。
實際檢查時，可以拆成四項：
四項都通過，才算拿到一份可供重現的紀錄。
如果另一個人無法照著它重走流程，那份交付物頂多是操作心得。後續不論要開 issue、請工程師修正，或證明某個行為曾經發生，都需要可查核的紀錄。
這項標準之後還會出現在「證據包」、「盲驗」和「開單閘門」裡。名稱不同，要求其實相同：每一項結論，都要讓別人有辦法重現。
第一項任務先不追求找到 bug。我們要確認瀏覽器、帳號、知識和權限能順利串起來，也要觀察 AI 能否理解畫面並留下足夠的操作證據。
交代任務時，給它目標、邊界與交付物，讓它自己判斷中間的操作。完成之後，也不要只看文字回覆；真正要驗收的是證據資料夾。若同一個問題嘗試兩次仍過不去，就停下來交給人處理。
給目標，不給步驟
「登入 → 加購物車 → 停在付款前
每步留截圖，記 console 與 network」
│
▼
它自己決定怎麼走
│
┌───────────┴───────────┐
▼ ▼
走得動 卡住了
│ │
▼ ▼
留下證據資料夾 同一障礙卡兩次
截圖 ／ console ／ → 回來找人
network ／ trace 不要自己繞
│
▼
四條驗收，對著資料夾勾
① 截圖編號連續嗎
② 每個「成功」找得到狀態證據嗎
③ 有沒有出現「未留證」
④ console 與 network 各自獨立嗎
│
▼
拿著它的紀錄，你能自己重走一次嗎
│
▼
能 → 那是紀錄；不能 → 那是感想
這一輪的成本也提供了一個提醒：cache read 佔總費用的 63%，後續應優先控制每一步需要重讀的內容，而不是只盯著最後輸出的字數。
回頭看這七天完成的準備：
| 做了什麼 | |
|---|---|
| Day 1–2 | 想清楚要找什麼樣的同事、它負責什麼 |
| Day 3 | 辦公環境：Claude Code 與 Playwright |
| Day 4 | 員工手冊：CLAUDE.md 的規則 |
| Day 5 | 產品知識：knowledge/ 與規格判準 |
| Day 6 | 帳號與權限：身分、動作、工具、外部服務 |
| Day 7 | 第一次完整走一遍，並留下可供重現的紀錄 |
目前它已經能操作產品，也知道要留下證據。不過這些資料仍然很粗糙：截圖時機未必一致、console 可能整包輸出，重要資訊和雜訊也還混在一起。
第二週要開始教它做筆記，把「有留下資料」推進到「留下來的資料真的有用」。
browser_navigate／browser_click／browser_snapshot 等工具清單
iThome鐵人賽
看影片追技術