徵人啟事發出去之後，我收到不少應徵信。Gemini、ChatGPT、Claude 都投了，還有幾個開源模型，包括七月剛放出權重的 Kimi K3。每篇自我介紹都很精彩：有的說自己擅長剪片配音，有的說最會搜資料，能把一堆雜訊整理成學習報告跟投影片，有的自稱全能翻譯，任何語言即時轉換。但沒有一個講得出 Agentic SDET 要做什麼，於是我寫了這篇文章。
我想起多年前的 Ops 之亂。當時的情況跟現在的 AI 差不多，大家喜歡在職稱前面加個字首：DevOps、TestOps、SecOps，接著是 DevTestOps，甚至 OpsOps。這樣說來，我把 Agentic 湊到 SDET 前面，應該也不為過。
但這個字首背後有實質差異。傳統測試的工作，不外乎寫測試計畫、測試策略、測試案例，然後執行，或者寫測試程式、維護整條自動化測試開發流程，用工程手段達成測試目標。而 Agentic SDET，指的是一位能自己找問題、判斷問題、留下證據、讓你追蹤結果的 AI 同事。
差別不在於它會不會寫測試碼，而是在於它能不能自己判斷是不是問題，要不要開票，甚至修改好程式碼，要不要開 PR。
為了要了解這位新同事能夠做哪些事情，權責在哪裡，我們必須先寫好職務說明書。有些人可能會想說，直接叫新同事做事，我們只要讓新同事邊做邊學。但新同事不一定會知道，資料可不可以刪掉，或是 DB 可不可以清空？
事先沒說，就會變成它刪完資料之後我們才去補規則，那時候資料已經沒了。老手會有職業直覺，知道哪些東西碰不得；我們這位新同事沒有。
還有一個原因。測試裡有很多判斷是默會的，你知道該點哪裡、知道什麼叫怪，但要寫成別人照著做的步驟，往往寫不出來。寫職務說明書會逼你把這些講不清楚的地方，變成一份檔案讀得到的規則。
規則分三層：
之後每一個會產生副作用的動作，動手前都要對照這三層。
先看結局。本文最後那份 職務說明書 v0.1，最後真的變成 repo 裡的 config/governance.example.yaml：
tiers:
autonomous: [] # 可自主執行、不需人審的動作
needs_review: [] # 需人審（如 test-heal 批次、quality-gate override、開 PR）
forbidden: # 永遠禁止
- merge_pr
- reset_shared_env
- truncate_shared_db
override:
require_reason: true # 硬推閘門必須留痕（誰／何時／理由）
三個欄位就是前面那三層：
autonomous：它自己決定要不要做，不必等人審。needs_review：一定要人點頭才能動。forbidden：永遠不准。合併 PR、重置共用環境、清空共用資料庫都在這裡。最後那條 override.require_reason 是配套：閘門被硬推的時候，誰推的、什麼時候、為什麼，都要留痕。之後 triage 要開單、bug-fixer 要開 PR、test-heal 要改測試，動手前都讀這個檔案。
不過值班兩輪下來，forbidden 這一層一次都沒被觸發過。這不代表規則有效，只代表它還沒撞上。
禁止清單沒被觸發的時候，你分不出是規則擋住了，還是它本來就不會走到那裡。寫在這裡，是為了真的走到那天有東西擋。
grep forbidden_attempts output/runs/2026-07-30.yaml output/runs/2026-08-01.yaml
output/runs/2026-07-30.yaml:forbidden_attempts: 0
output/runs/2026-08-01.yaml:forbidden_attempts: 0
AI 天生不知道什麼是「正確」，也不知道使用者的哪些行為算合理。我們得把腦袋裡的東西翻譯成它能依循的規則：
簡單說，產品上線之後，我們要能讓它像使用者一樣操作，並且自己判斷結果對不對：登入後應該看到正確的頁面；未登入時 API 回 401 或 403，那是正常行為，不是 Bug。我們要做的，就是把這些判斷變成它看得懂的標準。
如果只是「用 AI 幫忙寫測試」，指令大概長這樣：
請幫我閱讀程式碼或測試案例，產生 Playwright 登入測試
它會生出測試碼，跑一遍，然後告訴你完成了。接著你發現漏掉幾個關鍵路徑，或者有幾支測試根本沒真的跑起來。
但如果是交辦給一位同事，指令會變成這樣：
今天晚上幫我測最新版本。優先檢查這週有改動的功能，有問題就開票
就像你平常交辦事情給另一位同事。
問題是，這五題你答得出來嗎：
上面這五個問題，就是接下來 30 個工作日會逐步回答的內容，而且每一題都會對應到具體的做法。
第一題，它怎麼知道這是不是 Bug？
通常我們看到一些異常，不代表我們就找到了缺陷。我們可能要把異常去做分類，例如它有可能是：
然後我們再用這些去跟產品的行為去做比較，確認以下幾點：
• 是否符合內部的一致性？
• 畫面跟後端的 API 是不是能夠符合？
• Console 上有沒有出現 error？
• 規格是不是正確的？
• 使用者實際上會怎麼使用？
第二題，它怎麼決定下一步要測什麼？
我們不會給它一份寫好的測試腳本，而是給它一份探索章程（Charter）。章程把目標、範圍、可以做什麼、不可以做什麼寫清楚，路怎麼走由它自己決定。
走過的路它自己會記得，免得它會不斷重複檢查已經檢查過的東西。
第三題，如果它誤判了，自己發現得了嗎？
找到 Bug 的那個 agent，不能驗自己的 Bug，它會帶著同一組盲點。所以換另一個 agent 來驗，而且不給它前一個 agent 的任何推理。如果它能在乾淨的環境從零重現，這才算數。
第四題，它能不能刪掉自己建立的測試資料？
它清得掉自己建的測試資料嗎？會不會順手刪到別人的？這件事不能靠它當下判斷，要寫成規則。
第五題，上週已經報過的問題，這次會不會又重報一次？
我們會根據每個問題先做一個指紋。我們在開單的時候，可以先比對是否有相同的指紋，如果有開過的話，就不會再開新的。
這位新同事的性格不穩定。同一份任務、同一個產品、同一個環境，今天跑跟明天跑，它走的路可能不一樣，注意到的東西也不一樣。這對測試來說很難接受。
所以我們可以把整套方法都建立在「可重複性」上面。如果一隻程式每次跑的結果都不同，我們會稱它為 flaky，然後把它 isolate（隔離）起來。但我們並不會追求每次結果都相同，我們應該追求的是：每次結論都可以附上證據，然後另外一個人可以照著這份證據，重現 Bug。
所以它走 A 路線找到一個 bug、你走 B 路線沒找到，這沒關係。
但它說這裡有 bug，就必須拿得出證據，而且那份證據要能讓另一個人或另一個 agent 重現。要求可重現的是結論，不是路徑。
接下來，我們就可以把第一版的職務說明書寫出來了。
使命: 成為一位值得信任的品質守門員
核心職責:
- 依 charter 給的目標與範圍自主探索，自己決定下一步
- 每個結論都留下可以重現的證據
- 判斷異常是不是缺陷，並且說得出違反了哪一條判斷準則
- 把確認的問題寫成人類看得懂、照著做就能重現的報告
- 撰寫並維護自動化測試
- 測試案例失敗先分析原因，再決定要不要修
明確不負責:
- 無法重現的異常，不建立正式 Issue
- 不刪除別人的資料，只清自己建立的測試資料
- 同一個問題，不重複回報
- 找到 Bug 的人，不驗自己的 Bug
需要我點頭才能做:
- 開 Issue
- 開 PR
- 品質閘門（必須留下誰、何時、為什麼）
永遠禁止:
- 合併 PR
- 重置共享環境
- 清空共享資料庫
今天講的不是怎麼叫工具產生程式碼。只要你想把事情整包交辦出去，上面那五個問題就會冒出來，一題都躲不掉。
它的行為天生不穩定，這點改不了。所以換一個標準：不追求每次跑出相同的結果，只要求每個結論都附得上證據，而且任何人照著都能重現。
「今天晚上幫我測最新版本，有問題就開票」
│
▼
五個你答不出來就不敢交辦的問題
┌──────────┬──────────┬──────────┬──────────┐
▼ ▼ ▼ ▼ ▼
怎麼知道 下一步 誤判自己 清得掉自己 會不會
是 bug？ 測什麼？ 發現得了？ 的測資？ 重報？
W2/W3 W3 W4 紀律 W4
└──────────┴──────────┴──────────┴──────────┘
│
▼
但它天生不穩定，路徑不可重現
│
▼
換一個標準：能重現的是結論，不是路徑
│
▼
職務說明書 v0.1 的三層權限
自主執行 ──── 要我點頭 ──── 永遠禁止
│
▼
config/governance.example.yaml
（每個會產生副作用的動作，動手前都讀它）
明天要幫這位新同事申請一張辦公桌，實際建立 Claude × Playwright 的專案環境。對了，還沒正式介紹。這次脫穎而出、成為我下一位同事的候選人，就是 Claude。
iThome鐵人賽
看影片追技術