將 AI 打造成職務代理人。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 新同事報到，IT 開的是他自己的帳號，不是把你的密碼抄一份給他。能開哪些系統看職務，不是一次全開。 這件事我們都覺得理所當然。但很多人讓 AI 上工的時候，是直接把密碼貼進對話框的。 今天要處理的就是這件事。而且「權限」在這裡不是一件事：前四件是一般 coding agent 也有的本機與工具控制，第五件是任務授權，最外面還有受測系統本身的強制控制。 為什麼 SDET 的權限題比一般 agent 大一圈 一般 coding agent 的副作用是改你的碼。它改壞了，git checkout 就回來了，最糟糕的是浪費了你半小時。 這位同事的副作用打到別人身上： * 開一張 issue，會通知一整個 channel 的人 * 重置共享測試環境，會擋掉別人正在跑的 pipeline * 刪測試資料，可能毀掉同事跑到一半的驗證 * 對正式站做安全測試，那是另一種等級的麻煩 這些動作的共同點是收不回來。
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天發了員工手冊，這位同事知道公司的規矩了。但它還不知道自己要測的東西長什麼樣。 先別急著餵文件。這一集要回答的是更前面的問題：它到底在哪些時候需要產品知識？ 這個問題的答案決定了你要準備多少東西。準備太少，它判不出真正的問題；準備太多，你會花兩個禮拜整理一份沒人看的文件。 為什麼不是先整理一份完整的產品文件 新人訓練最直覺的做法，是把手上所有文件丟給他：需求、規格、API 文件、歷史決策。對真人來說，這頂多是浪費幾天，對這位同事來說，並不需要這麼做。 所以問題要倒過來問：它在哪些時候真的需要規格？答案不是「隨時」。有一整類缺陷，它光看畫面就判得出來，那類完全不用你準備；剩下那類，不管你讀幾遍，畫面都判不出來，那類才值得你寫。 先看第一類長什麼樣，再看它的天花板在哪裡。 有一種 bug，不需要任何產品知識 先看一個真的抓到的例子。 我讓它去逛一個電商 demo 站的購物車，它回報了這個： 購物車頁面每一列商品的 Total 欄位一律顯示 $00.00，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 「下禮拜有個新功能要上線，要麻煩你幫忙看一下有沒有問題？」 收到這個任務之後，你的同事通常會先問一串問題，畢竟同事不會通靈，如果通靈可以的話，是不是觀落陰要變成每個測試人員的技能： * 功能相關的文件放在哪裡？ * 有沒有開發相關文件或測試計畫？ * 已經有手動測試案例了嗎？ * 目前有沒有自動化測試？ * 迴歸測試有包含這個功能嗎？ * 測試完之後，測試報告要放在哪裡？ 我的這位新同事也是一樣，如果每次開始工作前都要重新講一次專案結構、測試流程和相關操作限制，我會把時間全部花在重複交接上，不如我把這些工作須知，都寫進 CLAUDE.md 裡面。 它就是發給新同事的員工手冊：不會包含所有知識，但會告訴他開始工作前該知道什麼，以及需要更多資訊的時候該去哪裡找。 CLAUDE.md 是什麼 一份給 Claude Code 的專案指示，專案層級通常放這兩個位置之一： ./CLAUDE.md ./.claude/CLAUDE.md 每次新對話開始的時候，Claude Code 會把範圍內的 CLAUDE.md 載入自己的腦袋。除了專案底下這份，它也支援使用
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 昨天說到脫穎而出的是 Claude，今天先講為什麼。 Claude Code 有一套叫 skill 的機制：你可以把一段工作方法寫成 Markdown 檔，放進固定位置，之後它遇到對應的情境就會自己讀進來照做。這件事聽起來平凡，但它把兩樣東西分開了 —— 怎麼做是能力，做什麼是產品知識。能力寫成 skill，可以帶著走；產品知識放在另一個資料夾，換一個受測產品就換一份。 這正好是我這 30 天想建立的東西：這是一位換了公司甚至模型也還能繼續工作的同事，而並不需要綁死在某個專案裡的提示詞，當然針對公司產品還是要調整一番，但隨著模型越來越厲害，我相信這件事情會越來越容易。 好，先回到今天要做的事，就是幫這位同事準備辦公環境：一台電腦、一雙能看見畫面的眼睛、一本記事本，還有報到手續。 Claude Code 的工作方式 Claude 是 Anthropic 開發的 AI 模型，能理解人類語言、分析內容、產生程式碼，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 徵人啟事發出去之後，我收到不少應徵信。Gemini、ChatGPT、Claude 都投了，還有幾個開源模型，包括七月剛放出權重的 Kimi K3。每篇自我介紹都很精彩：有的說自己擅長剪片配音，有的說最會搜資料，能把一堆雜訊整理成學習報告跟投影片，有的自稱全能翻譯，任何語言即時轉換。但沒有一個講得出 Agentic SDET 要做什麼，於是我寫了這篇文章。 Agentic 之亂 我想起多年前的 Ops 之亂。當時的情況跟現在的 AI 差不多，大家喜歡在職稱前面加個字首：DevOps、TestOps、SecOps，接著是 DevTestOps，甚至 OpsOps。這樣說來，我把 Agentic 湊到 SDET 前面，應該也不為過。 但這個字首背後有實質差異。傳統測試的工作，不外乎寫測試計畫、測試策略、測試案例，
Claude × Playwright：30 天打造你的 Agentic SDET 同事
前言 最近真的忙爆了！新功能要手動測試、舊的功能要跑自動化測試，重點是新功能除了要瞭解原先的產品知識外，還需要瞭解新功能的內容與架構，再撰寫對應的測試計畫與測試案例，重點是原本負責的自動化測試常常動不動就在 CI 上面壞掉、而且測試環境還偶爾不穩定，我還要邊看分析失敗原因，才能確定是不是要修改測試程式碼。 常常處理其中某件事情，我的一天就過了，啊啊啊……下禮拜又是 sprint 的最後一天了，如果有個同事能夠幫我就好了，於是我決定撰寫一篇徵人啟事，讓我自己不需要再處理這類的事情，只需要在關鍵時刻找我判斷就好。 徵人啟事 首先，我希望這位同事能自行探索、判斷問題：只要給予目標與條件，他即可找出問題並記錄結果。當然，在自動化測試盛行的時代，他必須能撰寫測試腳本、理解產品知識，並在檢視錯誤後自行修復失敗的測試。 為什麼要找同事，而不是更好的工具？差別不只在功能，而在誰負責決定下一步。一般工具等你操作，遇到預期外的結果，通常還是由人判斷原因與接下來怎麼做；同事則可以接住一個目標，自己尋找解決方案，遇到超出權責的情況再停下來詢問。常常我們缺的不是更多工具，而是一個能幫你扛掉重複工作的