Claude × Playwright：30 天打造你的 Agentic SDET 同事

Claude × Playwright：30 天打造你的 Agentic SDET 同事

Claude × Playwright：從新進同事到 Agentic SDET 代理人

第一週：歡迎新同事的入職準備

準備工作環境和產品相關知識，設定工作權現與工作規範，讓 Agent 知道誰是老大！

Day 1｜歡迎新同事：我要打造一位 Agentic SDET

Day 2 | 撰寫職務說明書：Agentic SDET 到底負責什麼？

Day 3｜準備辦公環境：建立 Claude × Playwright 專案

Day 4｜準備員工手冊：用 CLAUDE.md 定義工作規則

Day 5｜產品新人訓練：讓 Claude 看懂系統與功能

Day 6｜申請帳號與權限：讓 Agent 安全登入產品

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

第二週：同事的教育訓練

教 Agent 如何觀察產品、留下證據、並且判斷異常情況，並且能夠寫出能夠被其他工程師閱讀的報告。

Day 8｜先學會做筆記：建立測試證據蒐集流程

Day 9｜不只看畫面：教同事檢查 Console

Day 10｜從 UI 追到 API：教同事觀察 Network

Day 11｜每個結論都要有證據：建立 Evidence Package

Day 12｜測試不能只有 Pass 和 Fail：設計結構化結果

Day 13｜看到異常不代表找到 Bug：教同事先分類

Day 14｜第一次寫 Bug Report：從發現到可重現報告

第三週：成為同事的 Mentor

不再逐步命令 Agent，而是透過目標、回饋與審查，培養它進行自主探索和品質判斷。

Day 15｜不要再告訴它每一步：從 Test Case 到 Exploration Charter

Day 16｜給方向，不給答案：設計自主探索任務

Day 17｜教它自己選擇下一步：建立 Action Selection

Day 18｜不要讓新同事鬼打牆：建立狀態與路徑記憶

Day 19｜別只測 Happy Path：帶它挑戰產品假設

Day 20｜這到底是不是 Bug？教它建立 Test Oracle

Day 21｜Mentor 第一次放手：完成自主探索任務

第四週：同事成為你的代理人

讓 Agent 能在明確治理機制下，代表 SDET 執行探索、驗證、回報與修復流程。

Day 22｜能工作不代表值得信任：建立 Confidence Score

Day 23｜不要把公司的 Issue Tracker 塞爆：控制 False Positive

Day 24｜同一個 Bug 不要報十次：Issue 去重

Day 25｜第一位代理人上線：打造 Bug Hunter Agent

Day 26｜找另一位同事交叉確認：打造 Bug Verifier Agent

Day 27｜無法重現就不能回報：建立 Issue Quality Gate

Day 28｜無法重現就不能修：打造 Bug Fixer Agent

Day 29｜代理人可以開 PR，但不能自行合併

Day 30｜正式授權：Agentic SDET 同事獨立值班

第五週：測試維護

Day 31｜從探索到測試：寫第一支自動化測試（test-author）

Day 32｜寫出好維護的測試：避開 flaky 三根源（test-design）

Day 33｜讓測試進 CI：GitHub Actions 跑 Playwright（ci-setup）

Day 34｜讀懂紅色：從 Actions run 拉失敗與 artifact（用 gh）

Day 35｜測試紅了先別修：失敗根因分析（failure-analysis）

Day 36｜測試的錯 vs 產品的錯：分流（核心判斷）

Day 37｜flaky 不是 fail：量化重現率、隔離、去 flaky

Day 38｜自我修復：修好壞掉的測試，改測試不改產品（test-heal）

Day 39｜修完要重跑到綠：Re-run Gate 與停止條件（re-run-gate）

Day 40｜同事能自己改到哪：測試變更的治理與授權分級（governance）

第六週：CI Pipeline 與 Testing Infra

<TBD, skip it>

第七週：當個慣老闆，壓榨 AI 同事的薪水

Day 41｜AI 同事沒有勞健保，但薪水很貴：如何節省 Token 使用量

Day 42｜不要每次都從自我介紹開始：建立可重用的 Context

Day 43｜小事不要都找資深同事：建立模型分級與任務路由

Day 44｜不要讓同事把整間公司文件都看一遍：控制 Context 範圍

Day 45｜同樣的問題不要查十次：快取、記憶與結果重用

Day 46｜不要讓同事無限加班：設定 Budget 與停止條件

Day 47｜只做高價值工作：用風險決定 Agent 要測什麼

Day 48｜一個 Bug 值多少錢？衡量 Agentic SDET 的 ROI

Day 49｜便宜不代表划算：成本、品質與信任的三角關係

Day 50｜慣老闆的年終考核：替 Agentic SDET 做績效評估

---

新版 Day 15-30（2026-08-06 拍板）

上面那份保留不動，當作原始構想。以下是目前的文章順序，標題已依現有稿件更新。

改了什麼： 把原本第五週「測試維護」的四題搬進 30 天內，空間從第三、第四週合併四天騰出來。Day 01–14 維持原順序。

為什麼要搬： 兩個洞。一是系列名字掛 Playwright，三十天卻沒有一行測試碼；二是競品柯仁傑 Day 3 就講完失敗分流，本系列原本排在 Day 35，等賽後發已經冷掉（見 output/ithome-2026/competitor-scan-20260802.md）。

併掉的四天： 15+16、17+18、23+24、28+29。四組都是同一件事，拆成兩天講，合併不掉內容。

第一週：歡迎新同事的入職準備（01–07）

Day 01｜忙不過來了，我想找個 AI 同事幫忙測試

Day 02｜這位 Agentic SDET 到底要做哪些事？

Day 03｜先把 Claude Code 和 Playwright 裝好

Day 04｜把新同事該知道的事寫進 CLAUDE.md

Day 05｜開始測試前，要先告訴它多少產品知識？

Day 06｜幫新同事準備帳號，也說清楚哪些事不能做

Day 07｜新同事的第一份工作：走完一條產品流程

第二週：同事的教育訓練（08–14）

Day 08｜測試做過什麼，截圖和紀錄要留下來

Day 09｜Console 裡這些錯誤，哪些需要處理？

Day 10｜按下加入購物車，API 真的有收到嗎？

Day 11｜新同事交回 21 個檔案，我還是得逐一檢查

Day 12｜測試結果不能只填通過或失敗

Day 13｜先查清楚異常的原因，再決定要不要報 Bug

Day 14｜新同事寫的 Bug Report，別人照著做得出來嗎？

第三週：成為同事的 Mentor（15-19，原 7 天併成 5 天）

Day 15｜這次只給測試目標，操作步驟讓它自己想 　└ 併原 15＋16。「給方向不給答案」就是 charter 的定義，不必分兩天。素材：charters/

Day 16｜讓它自己選下一步，別一直測同樣的地方 　└ 併原 17＋18。兩題都在答「它怎麼決定下一步」，記憶是不重複走的手段。skill：explore

Day 17｜登入前先進結帳頁，會發生什麼事？ 　└ 原 19。素材：output/ithome-2026/parked-cases.md 那三個案例終於有家了

Day 18｜它說這是 Bug，判斷的依據在哪裡？ 　└ 原 20。skill：test-oracle。接得住 Day 13 分類完之後的判定

Day 19｜讓新同事自己測一輪，結果卡在登入頁 　└ 原 21。第三週的驗收

第四週：同事成為你的代理人（20-25，原 9 天併成 6 天，值班移到 Day 30）

Day 20｜新同事報了八個問題，我該先看哪個？ 　└ 原 22

Day 21｜報過的 Bug 別再開單，誤報也要記下來 　└ 併原 23＋24。同一個目的：進 tracker 的東西要夠格、而且不重複

Day 22｜讓 Bug Hunter 自己找問題，再交證據給我 　└ 原 25。skill： bug-hunter

Day 23｜請另一位同事照步驟重做，確認 Bug 能不能重現 　└ 原 26。skill：bug-verifier。Day 11 埋的盲驗伏筆在這裡回收

Day 24｜新同事找到八個問題，只有六個能開單 　└ 原 27。skill：issue-quality-gate

Day 25｜第一次修 Bug，才發現原本的測試也錯了 　└ 併原 28＋29。「不能 merge」本來就是 bug-fixer 的授權邊界，不必獨立一天

從修 Bug 到顧測試（26-29，原第五週搬進來的四題）

接點在 Day 25：bug-fixer 的 PR 裡本來就要附一支先紅後綠的回歸測試。 那支測試就是第一支自動化測試，Day 26 把它正式展開。

Day 26｜替購物車寫支自動化測試 　└ 原 31。skill：test-author。素材：tests/e2e/，寫測試前先跑 tests/tools/probe-selectors.ts

Day 27｜本機測試都通過了，放到 GitHub Actions 卻失敗 　└ 併原 33＋34。跑起來跟讀 artifact 是同一天的事。skill：ci-pipeline、pipeline-read。素材：repo 既有的 e2e workflow 與實測數字

Day 28｜測試在 CI 上失敗，我連續猜錯兩次原因 　└ 併原 35＋36。全季的核心判斷，接得上 Day 18 的 oracle 與 Day 23 的 verifier。skill：failure-analysis。素材：tests/broken/ 與 tests/README.md 那次誤診

Day 29｜這支測試怎麼有時通過、有時失敗？ 　└ 原 37。skill：flaky-detect。素材：tests/flaky/，以及本專案 retries: 0 的理由

收尾（30）

Day 30｜三十天後，這位新同事能幫我做多少事？ 　└ 原 30 不動。把探索、開單、修復、測試、維護全部收進值班流程，config/governance.yaml 的授權分級在這天講完

順延到賽後的六題

原 Day 32（test-design 避開 flaky 三根源）、38（test-heal）、39（re-run-gate）、40（governance 分級）、以及原第六、第七週。

其中 40 的內容有一半在新版 Day 30 講掉了，賽後那篇要重新定位。

進度與節奏（2026-08-15 更新）

首發定 8/15，就是今天。 日更不斷的話，Day 30 落在 9/13。

三十篇全部成文，Day 1 到 Day 30 各有對應的 book/day-NN-*.md，每篇至少一張圖，圖檔引用沒有斷的。

狀態	篇數	是哪幾篇
成文，且過了出刊前檢查	1	Day 1
成文，未逐篇校對	29	Day 2-30

出刊前檢查指的是：標題與大綱一致、錯字、圖有插進去、參考連結還活著、scripts/check-de-ai-tone.py 通過。Day 1 已經跑過一輪，其餘 29 篇還沒有，日更途中要邊發邊補。

字數落在 1382（Day 27）到 4422（Day 4）之間，中位數約 2200。短的那幾篇集中在 Day 20-24 與 Day 26-29，都在 1400-1900，出刊前值得再看一次夠不夠撐一篇。

完賽期限已確認，9/13 沒問題。 賽事辦法寫的是報名與開賽期間 08/01 至 09/15，開賽日自選，從開賽日起連續三十天發表不中斷就完賽。8/15 起算、9/13 收尾，離最晚開賽日還有一個月餘裕；真的中斷了，只要 9/15 前都還能重新起算三十天。出處：https://ithelp.ithome.com.tw/2026ironman/event。

要接受的是名次上的落差。 8/15 場上多數系列已經在 Day 14 到 Day 15，本系列的 Day 1 會跟他們的 Day 15 排在同一天的新文章列表上。競品的逐篇進度與應對記在 output/ithome-2026/competitor-tracker.md。