將 AI 打造成職務代理人。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天那一輪交回來的東西裡，有一筆很刺眼。 結帳地址那一步，postcode 欄位預填的值是字串 missing value。任何人看到都會皺眉：那明顯是程式內部代表「查不到值」的字面字串，怎麼會跑到使用者的表單裡，而且還通得過必填驗證。 value="missing value"、placeholder="Your Postcode *"。它是真的值，不是提示文字，不改就會被送出去。 但 finding 上寫的是 status: anomaly，不是 fail。 它看到了，卻不敢說那是錯的。今天要回答為什麼，答案是判準沒寫進 charter，它就不敢判。 為什麼沒有 oracle 就沒有 bug 「這是錯的」這句話，比大多數人以為的難講。 你說 postcode 不該顯示
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天新同事學會了如何收集證據，並且學會自己決定如何去探索我們給他的目標。然而在測試功能的時候，除了快樂路徑（ Happy Path）之外，我們也必須要去檢查一些不是正常路線的非正常路徑。 所以今天要教這位新同事，怎麼走 Happy Path 以外的路徑。 為什麼要離開 happy path Happy path 有個很誘人的性質：它幾乎不會紅。 使用者照順序走、每一步都填對、不重整不返回不開第二個分頁 —— 這條路是產品被設計出來的樣子，也是開發自己測過最多次的路。你沿著它跑一百輪，得到的是一百次「正常」。 問題是缺陷不住在那裡。真實使用者會按上一步、會連點兩下、會把分頁放到隔天再回來、會直接把網址貼給同事。這些行為在 happy path 上一條都不會發生，所以那條路上的一百次綠燈，證明不了它們。 那為什麼不乾脆隨便亂點？因為亂點沒有依據，你事後說不出自己測了什麼、還有哪裡沒測。「非 happy path」不是一個地方，是無限多個地方，沒有一張表幫你挑，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 探索章程（Charter）的目標與內容都寫好了，今天讓新同事拿著它，自己決定怎麼探索這個產品。 今天的主角是 explore，它是 model-invoked，agent 遇到「依照這份 charter 去探索」這類任務會自行觸發，名字不用記。 用 charters/toolshop-checkout-payment.yaml 跑一輪探索 但如果你想指定 skill，可以這樣把它明確叫出來。 /sdet-skills:explore 用 charters/toolshop-checkout-payment.yaml 跑一輪探索 如果手上還沒有章程，先照昨天那篇把它生出來。 第三種方式是你可以不寫成 charter 檔。你可以在告訴這位新同事時，把目標、範圍、oracle、邊界四樣直接講給他聽。 這種方式適合一次性、不打算重跑的探索。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 在前幾天，我們都是告訴新同事我們需要什麼，而新同事幫我們去做這些工作。但今天呢，我們希望我們的同事可以更獨立一點，所以我們將不會告訴他要做哪些事情了。 從今天開始，新同事自己決定目標、自己決定界線，並且要如何探索。我們的角色將會從原本決策者變成一個 Mentor，而新同事則是除了執行者也是決策者。 而今天要教會他的東西就是，撰寫一份 Exploration Charter。 為什麼不繼續寫 test case Test case 有個很難承認的限制：它只驗得到你已經想到的那條路。 你寫「購買兩件商品，把數量改成零，檢查總金額不是負數」，它就永遠只會做這件事。負數這個點子是你想到的，那 charter 產生的價值就等於你的想像力，一個字都不會多。 這件事在人身上還算划算，因為人邊走邊想。但交給 agent 之後就不划算了：你多寫一步，它就多走一步，你沒寫的它一步都不會走。把每一步都寫死，等於花錢請它幫你按滑鼠。 要讓它走出你沒想過的路，你能給的就只剩三樣：要達成什麼、憑什麼算對、哪裡不准去。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天把異常分了類，七類裡只有 product-bug 有資格往下。今天處理往下的第一步：把它寫成一份報告。 素材是 2026-07-30 那批實際產出的 18 份 Bug Report（output/reports/issues/）。底下第三節那兩筆缺陷是比對報告與檔案系統查出來的，不是設想的。 為什麼這一天不是教你填範本 「寫 Bug Report」聽起來是全書最沒有技術含量的一天。範本網路上都有，欄位就那幾個。 但範本不是這一天的問題。真正的問題是：交給 agent 寫，結果會不會比人寫的差？ 答案有點意外。人寫的報告最常見的死法不是寫太少，是寫太懂： CartComponent 的 lineTotal 沒綁到 currency pipe。 寫的當下很有價值，工程師看一眼就知道去哪改。三個月後那個檔案被重構掉，這張單就沒人看得懂了 —— 而且更糟的是，你也不確定它到底修好了沒有，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天把一輪的結果寫成 results.yaml，六個狀態各司其職，那一包分出 4 個 pass、6 個 fail、1 個 inconclusive、1 個 anomaly。 但 status 只回答了一半的問題。它說的是「這筆判不判得動」，沒說「這筆帳算誰的」。同樣是 fail，可能是產品寫錯，也可能是測試環境掛了、帳號被別人鎖了，或者根本是我自己操作順序弄反。 今天處理後面那一半。素材是 2026-07-26 到 07-30 十二輪的狀態檔，加上 output/known-false-positives.yaml。 為什麼不分類就報，等於開一間誤報工廠 回到昨天那筆「console
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天新同事交回了完整的證據包，我們也讀完了 notes.md 裡記錄的現象與結論——每個結論背後都掛著證據。但讀完之後，我們還沒判斷過：這些觀察裡，哪些行為符合我們的預期，哪些又不符合。 所以我們今天就要根據新同事提供的這個 notes.md，去看看是不是還有東西是我們要處理的。 先看看 notes.md 裡面寫了哪些 ... 畫面小計顯示 0 購物車列：Combination Pliers / 單價 $14.15 / 小計 $00.00，而表格底部總計是 $14.15。資料層的 total 明明是 14.15。 標題欄位重複 購物車表頭為 Item | Quantity | Price | Total | Total，最後兩欄同名。 使用者選單顯示查無使用者 登入後導覽列顯示「User
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 教會新同事從畫面觀察 API 並收集相關證據，今天終於有空可以來仔細看看這份證據包。 我記得自己是測試新手的時候，常常因為興奮而發現 Bug，我迅速寫好標題、列出重現步驟，甚至附上 log ，開票給開發人員，送出。但卻常常因 log 未完整收集或缺少關鍵資訊，就必須要重現問題再收集 log，這樣一來一回超級浪費時間的。為了避免我們的新同事重蹈覆轍，作為一個資深前輩，我們要檢查這位新同事是否已完整收集證據，還是草率了事。 為什麼證據包要能交棒 「留了證據」跟「這包證據能交給別人」是兩件事，而中間那道差距只有在你需要交出去的那一刻才會現形 —— 通常是你已經把單開出去、工程師回你一句「我這邊重現不出來」的時候。 那道差距長什麼樣？把同一包東西放在兩個讀者面前就看得出來： 你自己讀 別人讀 「登入成功」 記得是用哪個帳號 哪個帳號？哪個環境？ 一張購物車截圖 記得那是按下去之後 按之前還是之後？ 「network 沒問題」 記得看過哪幾筆 哪幾筆？在哪個檔案？
前言 昨天是被動讀已經留下的證據，東西都在檔案裡，差別只在開哪一份。今天換一種姿勢：挑一個 UI 動作，主動追它到底做了什麼，然後面對昨天四種來源全部乾淨、卻確實有缺陷的那種情況。底下的數字都是 2026-08-02 實跑量到的，證據在 output/evidence/20260802-withbugs-network/，對照組在 output/evidence/20260802-toolshop-checkout/。 為什麼要追到 network UI 是最會騙人的一層。畫面上的每一個數字、每一個狀態，都可以是前端自己畫的。徽章從 0 變 1，可能是因為後端建了購物車，也可能只是前端把一個變數加一。這兩件事在畫面上長得一模一樣。 不追到 network，你驗的就是前端的渲染邏輯，不是產品的行為。而昨天那四種來源有個共同的盲點：它們都只回答「發生了什麼」，不回答「
前言 Day 8 教會它留證，一輪跑完會交回截圖、console、network、trace 四份檔案。今天面對下一個問題：四份檔案攤在面前，你怎麼知道該看哪一份？底下的數字都是 2026-08-02 對 automationexercise.com 實跑量到的，證據在 output/evidence/20260802-automationexercise/。 為什麼要分辨證據來源 留證有個陷阱：檔案愈多，愈像做完了。實際上那四份檔案回答的是四個不同的問題，而它們之間有縫。 截圖說得出症狀，說不出原因。network 說得出發了哪些請求，說不出回 200 的那一筆內容是錯的。console 說得出程式報了什麼錯，說不出畫面因此長成什麼樣。 縫的代價是漏。缺陷同時落在兩份檔案上，一份寫症狀、一份寫原因，只讀其中一份的人會判它通過。更糟的是這種漏不會留下痕跡：你手上有完整的證據包，報告寫「未發現異常」
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 第一週結束時它已經能操作產品，也留得下東西，只是留得很粗糙：截圖是隨手截的、console 是整包倒出來的，哪些重要、哪些是雜訊分不出來。今天把「有留」變成「留得對」，主角是 evidence-package 這個 skill，底下靠 Playwright 的 screenshot、trace、network 產出硬證據。段落順序照 2026-08-02 拍板的節次走，數字都是那天實跑量到的。 為什麼第一件事是留證 現在還沒開始找 bug，先教蒐證看起來像繞路。反過來想：等到真的找到東西才學留證，那一刻你手上只有一句「我剛剛看到它壞掉」，重現要重跑、細節靠回憶、開單前還得再走一次。這是新手最常付的一種學費。 留證還會逼出誠實。一份證據包會逼出兩件事：你只能寫得出檔案接得住的結論，而且你必須把看到的跟推論的分開寫。趁還沒有「我找到大 bug
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 新同事到職的第一週，我通常不會急著請他找產品的問題，而是先讓他把流程完整走過一次。跑完之後，再請他說說看：他做了哪些操作、畫面上看到了什麼，又在哪些地方停下來確認。 原因很簡單。如果連產品正常運作的樣子都還說不清楚，這時候提出的「異常」多半也很難判斷。 所以今天先讓這位 AI 同事做第一件實際工作：自己走完一條產品流程。 為什麼第一項任務不急著找 bug 我想先確認三件事。 第一，前六天準備的環境到底能不能用。瀏覽器、測試帳號、產品知識和權限都已經設定好了，但這些東西只有真正跑過一次，才知道有沒有接好。如果現在失敗，反而容易處理，因為問題大多還在環境或設定，不必立刻懷疑產品。 第二，它是否真的讀得懂畫面。瀏覽器能把頁面內容交給它，不代表它知道哪個是主要按鈕、購物車在哪裡，或目前走到結帳的哪一步。這些能力不能靠設定檔確認，只能看它實際操作。 第三，從第一趟任務開始就要求它留證據。這個習慣越早建立越好。若等到它開始回報問題，才發現截圖、console 或 network 紀錄都不完整，最後還是得自己重跑一次確認，