前言 第一週結束時它已經能操作產品，也留得下東西，只是留得很粗糙：截圖是隨手截的、console 是整包倒出來的，哪些重要、哪些是雜訊分不出來。今天把「有留」變成「留得對」，主角是 evidence-package 這個 skill，底下靠 Playwright 的 screenshot、trace、network 產出硬證據。段落順序照 2026-08-02 拍板的節次走，數字都是那天實跑量到的。 為什麼第一件事是留證 現在還沒開始找 bug，先教蒐證看起來像繞路。反過來想：等到真的找到東西才學留證，那一刻你手上只有一句「我剛剛看到它壞掉」，重現要重跑、細節靠回憶、開單前還得再走一次。這是新手最常付的一種學費。 留證還會逼出誠實。一份證據包會逼出兩件事：你只能寫得出檔案接得住的結論，而且你必須把看到的跟推論的分開寫。趁還沒有「我找到大 bug

前言 新同事到職第一週，你不會馬上叫他去挑產品毛病。你會叫他自己走一遍流程，然後回來跟你講他看到什麼。 不是因為他還不夠格挑毛病，是因為在他能講清楚「產品正常時長什麼樣」之前，他講的「不正常」你不敢信。 今天這位同事做第一件真正的事：完整走一次產品流程。 為什麼第一項任務不是找 bug 三個理由。 一、先確認管線是通的。 前六天鋪的東西 —— 瀏覽器、帳號、產品知識、權限 —— 到底有沒有真的接上，只有跑一次才知道。這時候失敗是好事，因為你知道問題出在自己的設定，不在產品。 二、先確認它看得懂畫面。 它「看得到」畫面不代表「看得懂」。分不分得出哪個是主要按鈕、找不找得到購物車、知不知道結帳走到第幾步 —— 這些要看它實際操作才知道。 三、建立留證的習慣，趁還沒開始找 bug 的時候。 這一條最重要。等它開始回報問題，你才要求證據，就晚了 —— 那時候你會為了看它到底對不對，回頭自己重走一遍，

前言 新同事報到，IT 開的是他自己的帳號，不是把你的密碼抄一份給他。能開哪些系統看職務，不是一次全開。 這件事我們都覺得理所當然。但很多人讓 AI 上工的時候，是直接把密碼貼進對話框的。 今天要處理的就是這件事。而且「權限」在這裡不是一件事：前四件是一般 coding agent 也有的本機與工具控制，第五件是任務授權，最外面還有受測系統本身的強制控制。 為什麼 SDET 的權限題比一般 agent 大一圈 一般 coding agent 的副作用是改你的碼。它改壞了，git checkout 就回來了，最糟糕的是浪費你半小時。 這位同事的副作用打到別人身上： * 開一張 issue，會通知一整個 channel 的人 * 重置共享測試環境，會擋掉別人正在跑的 pipeline * 刪測試資料，可能毀掉同事跑到一半的驗證 * 對正式站做安全測試，那是另一種等級的麻煩 這些動作的共同點是收不回來。

前言 昨天發了員工手冊，這位同事知道公司的規矩了。但它還不知道自己要測的東西長什麼樣。 先別急著餵文件。這一集要回答的是更前面的問題：它到底在哪些時候需要產品知識？ 這個問題的答案決定了你要準備多少東西。準備太少，它判不出真正的問題；準備太多，你會花兩個禮拜整理一份沒人看的文件。 為什麼不是先整理一份完整的產品文件 新人訓練最直覺的做法，是把手上所有文件丟給他：需求、規格、API 文件、歷史決策。對真人來說，這頂多是浪費幾天，對這位同事來說，並不需要這麼做。 所以問題要倒過來問：它在哪些時候真的需要規格？答案不是「隨時」。有一整類缺陷，它光看畫面就判得出來，那類完全不用你準備；剩下那類，不管你讀幾遍，畫面都判不出來，那類才值得你寫。 先看第一類長什麼樣，再看它的天花板在哪裡。 有一種 bug，不需要任何產品知識 先看一個真的抓到的例子。 我讓它去逛一個電商 demo 站的購物車，它回報了這個： 購物車頁面每一列商品的 Total 欄位一律顯示 $00.00，

前言 「下禮拜有個新功能要上線，要麻煩你幫忙看一下有沒有問題？」 收到這個任務之後，你的同事通常會先問一串問題，畢竟同事不會通靈，如果通靈可以的話，是不是觀落陰要變成每個測試人員的技能： * 功能相關的文件放在哪裡？ * 有沒有開發相關文件或測試計畫？ * 已經有手動測試案例了嗎？ * 目前有沒有自動化測試？ * 迴歸測試有包含這個功能嗎？ * 測試完之後，測試報告要放在哪裡？ 我的這位新同事也是一樣，如果每次開始工作前都要重新講一次專案結構、測試流程和相關操作限制，我會把時間全部花在重複交接上，不如我把這些工作須知，都寫進 CLAUDE.md 裡面。 它就是發給新同事的員工手冊：不會包含所有知識，但會告訴他開始工作前該知道什麼，以及需要更多資訊的時候該去哪裡找。 CLAUDE.md 是什麼 一份給 Claude Code 的專案指示，專案層級通常放這兩個位置之一： ./CLAUDE.md ./.claude/CLAUDE.md 每次新對話開始的時候，Claude Code 會把範圍內的 CLAUDE.md 載入自己的腦袋。除了專案底下這份，它也支援使

前言 昨天說到脫穎而出的是 Claude，今天先講為什麼。 Claude Code 有一套叫 skill 的機制：你可以把一段工作方法寫成 Markdown 檔，放進固定位置，之後它遇到對應的情境就會自己讀進來照做。這件事聽起來平凡，但它把兩樣東西分開了 —— 怎麼做是能力，做什麼是產品知識。能力寫成 skill，可以帶著走；產品知識放在另一個資料夾，換一個受測產品就換一份。 這正好是我這 30 天想建立的東西：這是一位換了公司甚至模型也還能繼續工作的同事，而並不需要綁死在某個專案裡的提示詞，當然針對公司產品還是要調整一番，但隨著模型越來越厲害，我相信這件事情會越來越容易。 好，先回到今天要做的事，就是幫這位同事準備辦公環境：一台電腦、一雙能看見畫面的眼睛、一本記事本，還有報到手續。 Claude Code 的工作方式 Claude 是 Anthropic 開發的 AI 模型，能理解人類語言、分析內容、產生程式碼，

前言 徵人啟事發出去之後，我收到不少應徵信。Gemini、ChatGPT、Claude 都投了，還有幾個開源模型，包括七月剛放出權重的 Kimi K3。每篇自我介紹都很精彩：有的說自己擅長剪片配音，有的說最會搜資料，能把一堆雜訊整理成學習報告跟投影片，有的自稱全能翻譯，任何語言即時轉換。但沒有一個講得出 Agentic SDET 要做什麼，於是我寫了這篇文章。 Agentic 之亂 我想起多年前的 Ops 之亂。當時的情況跟現在的 AI 差不多，大家喜歡在職稱前面加個字首：DevOps、TestOps、SecOps，接著是 DevTestOps，甚至 OpsOps。這樣說來，我把 Agentic 湊到 SDET 前面，應該也不為過。 但這個字首背後有實質差異。傳統測試的工作，不外乎寫測試計畫、測試策略、測試案例，

前言 最近真的忙爆了！新功能要手動測試、舊的功能要跑自動化測試，重點是新功能除了要瞭解原先的產品知識外，還需要瞭解新功能的內容與架構，再撰寫對應的測試計畫與測試案例，重點是原本負責的自動化測試常常動不動就在 CI 上面壞掉、而且測試環境還偶爾不穩定，我還要邊看分析失敗原因，才能確定是不是要修改測試程式碼。 常常處理其中某件事情，我的一天就過了，啊啊啊……下禮拜又是 sprint 的最後一天了，如果有個同事能夠幫我就好了，於是我決定撰寫一篇徵人啟事，讓我自己不需要再處理這類的事情，只需要在關鍵時刻找我判斷就好。 徵人啟事 首先，我希望這位同事能自行探索、判斷問題：只要給予目標與條件，他即可找出問題並記錄結果。當然，在自動化測試盛行的時代，他必須能撰寫測試腳本、理解產品知識，並在檢視錯誤後自行修復失敗的測試。 為什麼要找同事，而不是更好的工具？差別不只在功能，而在誰負責決定下一步。一般工具等你操作，遇到預期外的結果，通常還是由人判斷原因與接下來怎麼做；同事則可以接住一個目標，自己尋找解決方案，遇到超出權責的情況再停下來詢問。常常我們缺的不是更多工具，而是一個能幫你扛掉重複工作的