Day 07｜入職第一項任務：完成一次端到端產品操作

前言

新同事到職第一週，你不會馬上叫他去挑產品毛病。你會叫他自己走一遍流程，然後回來跟你講他看到什麼。

不是因為他還不夠格挑毛病，是因為在他能講清楚「產品正常時長什麼樣」之前，他講的「不正常」你不敢信。

今天這位同事做第一件真正的事：完整走一次產品流程。

為什麼第一項任務不是找 bug

三個理由。

一、先確認管線是通的。 前六天鋪的東西 —— 瀏覽器、帳號、產品知識、權限 —— 到底有沒有真的接上，只有跑一次才知道。這時候失敗是好事，因為你知道問題出在自己的設定，不在產品。

二、先確認它看得懂畫面。 它「看得到」畫面不代表「看得懂」。分不分得出哪個是主要按鈕、找不找得到購物車、知不知道結帳走到第幾步 —— 這些要看它實際操作才知道。

三、建立留證的習慣，趁還沒開始找 bug 的時候。 這一條最重要。等它開始回報問題，你才要求證據，就晚了 —— 那時候你會為了看它到底對不對，回頭自己重走一遍，那整件事就沒有意義了。

這次任務長什麼樣

我用的目標是一個公開的電商練習站。任務範圍：

登入 → 瀏覽商品 → 加入購物車 → 進結帳流程 → 停在付款前

這一輪停在這裡：結帳第 3 步的 Billing Address，再按下去才是付款。

停在付款前。 這是刻意的。第一次任務不要包含任何真的會產生後果的動作 —— 不送出訂單、不刪除資料、不寄信。等你信得過它再放。

不過要講清楚：「不要送出訂單」這句話只是約定，不是保險。它寫在指令裡，靠的是對方願意照做。真正擋得住的是昨天那組 deny 規則 —— 約定管的是意圖，權限管的是後果。第一次任務兩個都要有，因為信任還沒建立起來，而這正是不該只靠一句話的時候。

下指令的方式：不要寫成腳本

很多人這時候會這樣下指令：

1. 打開 https://practicesoftwaretesting.com
2. 點右上角 Sign in
3. 輸入帳號 xxx 密碼 yyy
4. 點 Login
5. 回首頁，點第一個商品
6. 點 Add to cart
...

這樣做等於白花錢。你把它當成一支很貴的錄製腳本用，而它最值錢的能力 —— 遇到畫面跟預期不同時自己判斷下一步 —— 完全沒有用到。

換成這樣：

用測試帳號登入，挑一個商品加進購物車，走到結帳流程的付款頁前面停下來。
每一步留截圖，記下 console 和 network 有沒有異常。不要真的送出訂單。

給的是目標、邊界、要交什麼。中間怎麼走它自己決定。

這是第三週「從逐步指令改成給目標」的預演，今天先讓你感覺一下差別。

它說做完了，那不算

任務跑完，它會回你一段話，大意是「已完成登入、加入購物車、進到結帳頁，一切正常」。

這段話沒有任何價值。

不是因為它會說謊，是因為「一切正常」這四個字沒有可查核的內容。你無法從這句話知道它到底走到第幾步、看到什麼數字、有沒有跳過某個環節。

要看的是它留下來的東西。一次操作跑完，資料夾應該長這樣：

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」的畫面，不是「我填了表單」。之後要比對，比的是狀態。

03-login-filled-before.png。檔名說的是這一刻畫面的狀態，所以三個月後打開它，你不必問任何人就知道這是哪一步。

console 和 network 是分開的檔案。 畫面看起來好好的，不代表底下沒事。這兩份是後面幾天的主角。

實驗：一趟四分鐘的操作，帳單 $3.5

跟著做到這裡，你已經開始燒 token 了。所以先把數字攤開。

這是我實際跑一次登入加購物車探索的帳單。約四分鐘、23 次瀏覽器操作，用 Opus 5：

一次探索三塊多美金。一天跑十輪就是三十幾塊。這個數字要自己判斷划不划算 —— 但至少你現在知道它長什麼樣，而不是月底才發現。

有一件事要多看兩眼：cache read 佔了六成三。

那不是它「寫了多少字」的錢，是它每一步都要重讀一次前面走過的路的錢。它走 23 步，每一步都把前面累積的畫面、操作紀錄、判斷重新讀一遍 —— 讀了四百四十萬個 token。

這次的數字顯示兩件事。第一，在沒有提早切段或壓縮 context 的這一輪裡，走得越久，後面的步驟通常要重讀越多內容；這不是每一種 agent 工作流都必然遵守的固定曲線。第二，第三天說的「MCP 每次對話都要把工具 schema 塞進 context」為什麼值得在意 —— 探索步驟一多，這筆成本就會反覆出現。

省錢的槓桿在「少讀」，不在「少寫」。這個系列不會另闢一週講成本，但這條原則後面會反覆出現：讓它讀該讀的，不要讓它把整間公司的文件都看一遍。

第一次跑完，通常有三種結果

都不是 bug。

一、它根本進不去。

登入失敗、頁面打不開、選擇器找不到。這時候通常先檢查環境或設定 —— 環境變數沒設、網址寫錯、帳號被鎖，再判斷是不是產品問題。回頭檢查前六天鋪的東西。

這種失敗最好處理，因為它明顯，而且修完就不會再犯。

二、它走完了，但漏了東西。

它回報「完成」，但你看截圖發現它跳過了搜尋、或者根本沒進到結帳第二步。

這是指令的問題，不是它的問題。你的邊界沒講清楚，它自己補了一個定義。修法是把任務講具體一點，不是罵它。

三、它看到怪東西，但不確定該不該講。

這才是有意思的情況。console 噴了一個 404、某個欄位空白、金額看起來怪怪的。

今天不要處理。 記下來就好。「這算不算問題」是一整套判斷，第二週會專門處理 —— 而且順序很重要：先學會分類異常，再學會判定 bug。今天跳過這一步，它會開始把每一個 404 都當成重大缺陷回報給你。

先立一條停止條件

前六天都在講怎麼往前推。現在該立一條什麼時候該停。

同一個障礙卡兩次就回來找人，不要自己想辦法繞過去。

登入失敗了，重試一次還是失敗 —— 停下來回報，不要開始試別的帳號、不要去猜密碼規則、不要跳過登入直接測別的頁面。那些「聰明的變通」是探索最大的成本來源：它會花掉大量 token 去繞一個你三十秒就能解決的環境問題，而且繞完之後你根本不知道它到底測了什麼。

這條規則之後會一直出現。第三週的探索迴圈要靠它決定什麼時候該收手，第五週的重跑閘門要靠它決定什麼時候該升級給人。現在先立起來，因為第一次任務正好是最容易卡住的一次。

順帶一提：證據會長大

那個資料夾裡有截圖、影片、trace。一輪幾十 MB，跑三十輪就是幾個 GB。

三條規矩現在先講清楚：

• 證據不進版控。 它是執行期產物，不是原始碼。
• 只在失敗時留影片和 trace。 綠燈的過程沒人會回去看，留著只是佔空間。
• 設一個保留期限，過期自己刪。 我用的是七天。

這件事不處理，兩個禮拜後你的磁碟就會提醒你。

驗收標準只有一條

不是「它有沒有完成任務」，是：

拿著它留下的紀錄，你能不能自己重走一次？

這一條同時檢查了三件事：步驟完整、證據對得上步驟、關鍵狀態有被記下來。

抽象的標準不好用，所以翻成四條對著資料夾勾：

• 截圖編號連不連續。 缺號代表它走了一步沒留下來，或者留了但你不知道那是哪一步。
• 每個寫「成功」的步驟，找不找得到對應的狀態證據。 可能是畫面文字、URL、資料狀態或 API 回應；若這一步涉及伺服器互動，再核對 request、response 與狀態碼。不是每個 UI 狀態都會產生新的 2xx。
• 有沒有出現「未留證」。 它應該要敢寫這三個字。全篇沒有，通常不是每件事都留了證，是它沒在分。
• console 和 network 是不是各自獨立的檔案。 混在敘述裡代表它只挑了想給你看的那幾行。

四條都過，你才拿得到一份能重走的紀錄。

過不了這一關，代表它交的是一份感想，不是一份紀錄。而感想在測試這一行沒有用 —— 你之後要拿它去開單、去請工程師修、去證明某個行為真的存在，靠的都是那份紀錄。

順帶一提，這一條標準之後會一直出現。它是後面「證據包」「盲驗」「開單閘門」共同的底層要求：任何結論都要能被另一個人照著重現。

小結

第一項任務不找 bug，先確認管線是通的、它看得懂畫面，順便把留證的習慣立起來。下指令給的是目標、邊界與要交什麼，不是步驟；跑完不看它說什麼，看它留下什麼，拿四條標準對著資料夾勾。跑不完也不要讓它自己想辦法繞，同一個障礙卡兩次就回來找人。

              給目標，不給步驟
        「登入 → 加購物車 → 停在付款前
          每步留截圖，記 console 與 network」
                      │
                      ▼
                它自己決定怎麼走
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
      走得動                   卡住了
          │                       │
          ▼                       ▼
    留下證據資料夾          同一障礙卡兩次
    截圖 ／ console ／        → 回來找人
    network ／ trace         不要自己繞
          │
          ▼
      四條驗收，對著資料夾勾
    ① 截圖編號連續嗎
    ② 每個「成功」找得到狀態證據嗎
    ③ 有沒有出現「未留證」
    ④ console 與 network 各自獨立嗎
          │
          ▼
    拿著它的紀錄，你能自己重走一次嗎
          │
          ▼
    能 → 那是紀錄；不能 → 那是感想

第一項任務的目的不是抓到東西，是確認管線通了；這時候失敗也有價值，因為它能幫你先排除自己的設定問題。「它說做完了」不算數，「一切正常」四個字沒有可查核的內容，要看的是它留下什麼。至於成本，這一輪 cache read 佔六成三，提醒我們要控制每一步重讀的內容，而不是只盯著輸出字數。

第一週結束了

回頭看這七天做的事：

它現在能操作產品，也留得下東西。但它留的東西還很粗糙 —— 截圖是隨手截的、console 是整包倒出來的、哪些重要哪些是雜訊分不出來。

下一步

明天開始第二週，教它做筆記。

從「有留」到「留得對」，中間差的東西比想像中多。

---

參考資料

1. Claude Code Docs — Best practices（Give Claude a way to verify its work） - 給 agent 一個可自行驗證的檢查點，是這一天驗收標準的來源
2. microsoft/playwright-mcp - browser_navigate／browser_click／browser_snapshot 等工具清單
3. Debbie O'Brien（Playwright 團隊）— Manual Testing with AI: Using Playwright MCP for No-Code Testing - Playwright 團隊示範用 MCP 做無腳本的手動測試
4. Debbie O'Brien — Supercharged Testing: AI-Powered Workflows with Playwright + MCP - 同一位講者的實作演示，看 agent 實際操作瀏覽器長什麼樣