本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 25 篇。
這篇是中場報告，不是成功案例。
我維護一套服務多個 App 的冒煙測試框架，一個人。AI 進來一段時間了，我可以講清楚它實際接手了哪幾塊，以及哪幾塊我到現在還不敢交。
我本來以為 AI 會幫我的是「想測試案例」。
實際上它接手最順的是我原本以為最不值得談的那一塊：在畫面結構裡找元素、校正定位。
給它一份畫面的元素結構、告訴它我要點哪個東西，它找得又快又準。改版之後定位壞掉，它比對新舊結構，多半能自己修好。
這件事機械、可窮舉、有明確的對錯。那正是該交出去的特徵。
而且它一直是我最花時間的部分。Day 18 我講過自己怎麼把 locator 寫得越來越聰明，那些工夫現在大半可以外包。
我試過讓 AI 自己判斷一個頁面「對不對」。
它會說對。它幾乎總是說對。
因為它看得到畫面上有什麼，但它不知道這一頁應該有什麼。少了一個按鈕、少了一筆資料、某個欄位顯示的是上一版的格式——這些它看不出來，因為它手上沒有那個產品的真相。
Day 12 我講過 oracle：測試要成立，得有一個你事先知道的預期結果。
AI 缺的就是這個。它能執行、能定位、能描述畫面，但它不知道正確答案。
而給它正確答案的人是我。
| AI 接手的 | 我留著的 |
|---|---|
| 在畫面結構裡找元素、校正定位 | 提供產品真相：這一頁該長什麼樣、該不該有這個功能 |
| 框架的小幅修改 | 判斷對錯、下決策 |
| 部分診斷：把 log 和截圖整理成假設 | 驗證 AI 有沒有在唬爛 |
| 跨人協調、環境和帳號的一次性設定 |
右邊那一欄有一個共同點：它們都需要「這個組織、這個產品、現在」的知識。
那不是模型能力問題。是資訊在不在它手上的問題。
這是我目前覺得最有價值的改動。
第一次校正一個測項的時候，我會把「這一頁的真相」寫進那個測項的註解裡。這一頁應該出現哪幾個區塊、哪個數字必須大於零、哪個狀態才算登入成功。
下一次 AI 處理同一個測項，它讀得到那段註解，就判得出來了。
換句話說，我不是每次都在餵它答案。我是把答案變成資產，讓它累積。
這跟 Day 17 那份給新人的導讀文件是同一個動作，只是讀者換成了機器：把我腦袋裡的東西，寫到一個會被重複使用的地方。
有些事 AI 現在做不到，我也還沒找到繞法。
它判斷不了「合理但錯誤」的畫面。 一個數字顯示成 0，可能是真的沒資料，也可能是資料沒接上。這正是 Day 12 那個查無資料的問題，而 AI 會比我更容易放它過去，因為畫面確實沒有報錯。
它不知道什麼時候該停。 它會一直嘗試修一個定位，而不會抬頭問「這個功能是不是根本被移掉了」。Day 13 那個停損的判準，它沒有。
它的自信跟正確率不相關。 它修好定位的時候很肯定，修錯的時候一樣肯定。所以每一次我都還是要驗。
我實習的時候，我的價值大部分在手工上：我會寫腳本、我會定位、我跑得比別人快。
那部分正在被接手，而且我覺得那是好事——它本來就是勞力。
留下來的是另一種東西：知道這個產品該長什麼樣、判斷一個結果算不算通過、在 AI 給出一個看起來很專業的答案時還願意去驗它。
這不是升級成更厲害的執行者。是從執行者換到餵真相、驗結果、然後為那個判斷簽名的位置。
而簽名這件事，第一週講的那個一直沒有變過：交出去的不是綠燈，是一份讓有權力的人做得了決定的資訊。差別只在於，現在有一部分的活是機器幫我做的。
要判斷一件測試工作能不能交給 AI，問一句：
這件事的正確答案，寫得下來嗎？
寫得下來的（這個按鈕的定位、這段 log 代表什麼），交出去，而且把答案寫進註解讓它下次自己用。
寫不下來的（這一頁看起來對不對、這個結果算不算通過），留著。那不是因為 AI 笨，是因為那個答案只存在於你跟這個產品相處的時間裡。
明天聊：pass 和 fail 兩個欄位，對 AI 還夠用嗎。
iThome鐵人賽
看影片追技術