🌏 Read this article in English
開場：一個反直覺的現象
「AI 要取代 QA 了！」
這句話你大概聽過很多次。每次有新的 AI 測試工具發布，這種標題就會出現一輪。
但如果你實際導入過 AI 測試工具，你會發現一個反直覺的現象：
QA 團隊的人數，短期內並不會減少。
為什麼？
首先，人力調整從來都不是說砍就能砍的。組織有慣性，有既有的職責分工，有人情世故。
但更重要的原因是：AI 產出的東西，需要人來驗證。
AI 可以在一個小時內跑完原本需要三天的測試。但跑完之後呢？
- 這些測試結果是對的嗎？
- 有沒有漏掉什麼重要的場景？
- AI 說「通過」，真的可以上線嗎？
這些問題，AI 回答不了。需要人來判斷。
所以真正的變化不是「QA 被取代」，而是「QA 的工作內容被重新定義」。
這篇文章要談的，就是這個重新定義。
先搞清楚：QA 到底在做什麼？
在討論 AI 能不能取代 QA 之前，我們需要先拆解 QA 的工作內容。
很多人以為 QA 就是「跑測試」。這是一個嚴重的誤解。
QA 的工作可以分成五種類型：
第一種：執行型
這是最基礎的工作。按照既定的測試案例，一個一個跑過去，記錄結果，截圖存證。
這種工作重複性高、規則明確、不需要太多判斷。
第二種：撰寫型
寫測試案例、寫自動化腳本。把測試需求轉化成可執行的步驟。
這需要技術能力，但本質上還是「把已知的東西文件化」。
第三種：設計型
決定「要測什麼」。設計測試策略、定義覆蓋範圍、決定優先順序。
這需要理解業務邏輯。你要知道哪些功能最重要、哪些場景風險最高、客戶最在意什麼。
第四種：探索型
Exploratory Testing。不按照腳本，而是用直覺和經驗去挖掘潛在問題。
「如果使用者這樣操作會怎樣？」「這個邊界條件有沒有被處理？」「這個流程感覺怪怪的，讓我試一下…」
這需要創意、懷疑精神、和對產品的深度理解。
第五種：驗收型
最終判斷。測試結果出來了，但這代表產品可以上線嗎？這個 bug 算嚴重還是輕微？這個風險可以接受嗎？
這涉及責任歸屬。最終拍板的人，要承擔「放行」的責任。
現在，讓我們看看 AI 能取代哪些：
| 類型 | AI 取代程度 | 原因 |
|---|---|---|
| 執行型 | 幾乎完全取代 | 重複性工作，AI 最擅長 |
| 撰寫型 | 大部分可取代 | AI 能寫腳本，但需要人審核 |
| 設計型 | 很難取代 | 需要業務知識，AI 沒有 |
| 探索型 | 很難取代 | 需要直覺和懷疑，AI 不會質疑自己 |
| 驗收型 | 無法取代 | 責任歸屬問題，必須是人 |
結論很清楚：AI 取代的是「執行」，不是「判斷」。
如果你的 QA 團隊大部分時間都在做執行型工作，那確實會受到衝擊。
但如果你的 QA 能做設計、探索、驗收——他們的價值不但不會下降，反而會上升。
核心問題：誰來驗證 AI 是對的？
這是整篇文章最重要的一節。
AI 測試工具的宣傳通常是這樣的：
- 「AI 自動產生測試案例，覆蓋率提升 300%！」
- 「AI 自動執行測試，節省 80% 時間！」
- 「AI 自動分析結果，產出詳細報告！」
聽起來很美好。但讓我問你一個問題：
AI 說「測試通過」，你敢直接上線嗎？
如果你的答案是「不敢」，那你就理解了問題所在。
AI 可以跑更多測試、產出更多報告、覆蓋更多場景。但這些產出本身需要被驗證。
問題一：AI 測的是對的東西嗎？
AI 可以根據程式碼自動產生測試案例。但它怎麼知道哪些功能對業務最重要？怎麼知道客戶最常抱怨什麼？怎麼知道上次出事的地方在哪裡？
它不知道。它只能根據程式碼的結構去猜。
一個有經驗的 QA 會說：「這個金流功能要重點測，因為上次出過事。」AI 不會，除非你明確告訴它。
問題二：AI 說「通過」，真的通過嗎？
AI 執行測試後說「通過」，這代表什麼？
代表測試腳本跑完了、沒有報錯、結果符合預期。
但測試腳本本身是對的嗎？預期值設得對嗎？有沒有漏掉什麼情況？
AI 不會質疑自己。它不會說「等等，這個測試好像沒有驗證到真正重要的東西」。
這種質疑，只有人能做。
問題三：出了問題，責任算誰的？
假設 AI 測試說「通過」，你上線了，結果出了嚴重 bug。
客戶來抱怨、老闆來問責。這時候你說「AI 說可以的」，有用嗎？
沒用。
最終承擔責任的是人，不是 AI。所以最終做決策的也必須是人。
這就是為什麼「驗收型」工作無法被取代。不是技術上做不到，是責任歸屬上不允許。
所以，QA 的新核心工作是什麼？
驗證 AI 的驗證。
聽起來有點繞，但這就是現實。
AI 產出測試 → QA 驗證測試是否正確 AI 執行測試 → QA 驗證結果是否可信 AI 產出報告 → QA 判斷是否可以上線
QA 從「第一線執行者」變成「AI 的監督者」。
這不是降級，這是升級。
AI 時代 QA 最重要的四種能力
既然 QA 的工作從「執行」變成「判斷」，那需要的能力也會改變。
我按重要性排序，這個排序可能跟你想的不一樣：
第一名：業務理解能力（最重要）
這是最反直覺的。
大家以為 AI 時代最重要的是技術能力、Prompt 能力。錯了。
最重要的是：你懂不懂這個產品在幹嘛？
- 哪些功能對客戶最重要？
- 哪些場景最常出問題？
- 哪些錯誤是致命的、哪些是可以容忍的？
- 業務邏輯的邊界條件在哪裡？
這些知識存在資深 QA 的腦袋裡，不在任何文件裡，更不在 AI 的訓練資料裡。
AI 可以幫你跑測試，但它不知道「什麼該測」。這個判斷，需要業務理解。
一個懂業務的 QA，可以看一眼 AI 產生的測試案例，立刻說：「這個漏掉了 XX 場景，那個才是客戶最常用的。」
一個不懂業務的 QA，只能說：「AI 產生了 200 個測試案例，看起來很多，應該夠了吧。」
這就是差距。
第二名：批判思考能力
AI 不會質疑自己。它會很有自信地給你一份漂亮的報告，即使報告裡有問題。
QA 需要有能力質疑：
- 「這個測試真的驗證了我們想驗證的東西嗎？」
- 「覆蓋率 90% 聽起來很高，但那 10% 是什麼？」
- 「AI 說這是 edge case 不用管，但真的嗎？」
- 「這個測試通過了，但結果看起來怪怪的…」
批判思考不是「不相信 AI」，是「不盲目相信任何東西」。
這種能力在 AI 時代反而更重要了。因為 AI 產出的東西量很大、看起來很專業、很容易讓人放下戒心。
能夠在一片「看起來都對」的報告中發現問題，這是高價值技能。
第三名：Prompt 能力
這是大家最常提到的「AI 時代新技能」。
確實重要，但被高估了。
Prompt 能力是「讓 AI 產出更好的東西」的能力。你要知道怎麼問、怎麼給 context、怎麼迭代。
但問題是：你要先知道什麼是「好的東西」，才能判斷 AI 產出的夠不夠好。
這又回到業務理解和批判思考。
一個不懂業務的人，就算 Prompt 寫得再漂亮，也不知道 AI 產出的測試案例對不對。
所以 Prompt 能力排第三。它是放大器，但前提是你本身要有東西可以被放大。
第四名：技術能力
這可能是最反直覺的：技術能力排最後。
不是說技術能力不重要。你還是要能看懂測試腳本、能 debug、能跟工程師溝通、能把測試整合進 CI/CD。
但技術能力的「門檻」被 AI 大幅降低了。
以前你要會寫 Selenium、會寫 Playwright、會處理各種環境問題。現在 AI 可以幫你寫、幫你 debug、幫你查文件。
技術能力從「稀缺資源」變成「基礎設施」。有是必要的，但不再是差異化的來源。
總結這個排序：
| 排名 | 能力 | 為什麼重要 | AI 能幫忙嗎？ |
|---|---|---|---|
| 1 | 業務理解 | 決定「測什麼」 | 不能 |
| 2 | 批判思考 | 判斷「AI 對不對」 | 不能 |
| 3 | Prompt | 讓 AI 產出更好 | 這就是跟 AI 協作 |
| 4 | 技術 | 看懂、debug、整合 | 可以輔助 |
前兩項是「不可被 AI 取代的」，後兩項是「可以被 AI 輔助的」。
反直覺的結論：AI 時代，「軟技能」比「硬技能」更重要。
對團隊的實際影響
講了這麼多理論，實際上會發生什麼事？
短期（導入後 1 年內）
人數不會明顯減少。
原因我前面說過：組織有慣性，而且 AI 的產出需要人來驗證。
但會有兩個明顯的變化：
第一，QA 報告的品質會提升。
因為 AI 可以跑更多測試、覆蓋更多場景。原本只能測 happy path 的，現在可以測到 edge case。原本只能做一輪的，現在可以做三輪。
如果 QA 有意識地使用 AI，報告會更精確、覆蓋範圍更大。
第二，QA 之間的能力差距會被放大。
會用 AI 的 QA，產出是原來的 3-5 倍，品質還更好。 不會用 AI 的 QA，產出跟以前一樣，相比之下就顯得很差。
這個差距會越來越明顯。
中期（1-3 年）
團隊結構會開始調整。
「執行型」QA 的需求會下降。因為 AI 可以做執行，不需要那麼多人手工跑測試。
「設計型」「驗收型」QA 的價值會上升。因為這些是 AI 做不了的，而且需求沒有減少。
具體來說：
原本一個 5 人的 QA 團隊，可能是這樣的配置： – 4 個人做執行、撰寫 – 1 個人做設計、驗收
導入 AI 之後，可能變成： – 2 個人操作 AI + 驗證結果 – 1 個人做設計、驗收
人數從 5 變成 3，但產出可能更高。
長期
最終的狀態不是「AI 取代 QA」，而是「會用 AI 的 QA 取代不會用 AI 的 QA」。
這跟其他職業的變化是一樣的。
不是 Excel 取代了會計，是會用 Excel 的人取代了只會用算盤的人。 不是 CAD 取代了製圖員，是會用 CAD 的人取代了只會手繪的人。
QA 也一樣。AI 是工具，會用工具的人取代不會用工具的人。
給 QA 的建議
如果你是 QA，看完這篇文章，可以做什麼？
第一，不要急著學 Prompt Engineering。
我知道這聽起來很奇怪。但根據前面的分析，Prompt 能力排第三，不是第一。
你應該先問自己：我對這個產品的業務邏輯夠熟嗎？我知道客戶最在意什麼嗎？我知道哪裡最容易出問題嗎？
如果答案是「不太確定」，那你應該先花時間搞懂業務，而不是學 Prompt。
第二，培養質疑的習慣。
從現在開始，對任何測試結果都多問一句：「這真的對嗎？」
不只是 AI 的產出。你自己寫的測試、工程師說的「這不會有問題」、PM 說的「這個 case 不重要」——都值得質疑。
這個習慣會讓你在 AI 時代變得更有價值。
第三，學習跟 AI 協作，而不是跟 AI 競爭。
AI 執行測試比你快，這是事實。跟它比速度沒有意義。
你應該思考的是：我怎麼利用 AI 的速度，加上我的判斷力，產出比以前更好的結果？
這是協作，不是競爭。
第四，累積你的業務知識，這是 AI 拿不走的。
你對這個產品的理解、對這個領域的經驗、對客戶行為的洞察——這些存在你腦袋裡，不在任何地方。
AI 可以學習公開的知識，但學不了你獨有的經驗。
這是你的護城河。持續累積。
給 Tech Lead 的建議
如果你是 Tech Lead 或管理者，考慮導入 AI 測試，要注意什麼？
第一，導入 AI 測試不等於可以裁 QA。
至少短期內不行。
AI 的產出需要驗證，驗證需要有經驗的人。如果你把 QA 都裁了，誰來驗證 AI？
而且 AI 測試工具也需要人來操作、調整、維護。這些工作還是需要人。
第二，短期效益是「提升品質」，不是「減少成本」。
導入 AI 測試之後，你應該期待的是： – 測試覆蓋率提升 – 報告更精確 – 發現更多之前沒發現的問題
而不是： – 可以少請兩個 QA
成本節省是中長期的事。短期內，你可能還要額外投資工具、培訓、調整流程。
第三，重新定義 QA 的職責。
既然工作內容改變了，職責定義也要跟著改。
以前的 QA 職責可能是：「執行測試案例，回報結果」
新的職責應該是：「確保測試策略正確，驗證 AI 產出的測試結果，對產品品質做最終把關」
把這個寫進 Job Description。讓團隊知道期望改變了。
第四，投資 QA 的業務理解能力。
讓 QA 參與需求討論、讓他們跟客戶接觸、讓他們理解商業目標。
這些以前可能被認為「不是 QA 該管的」。但在 AI 時代，這變成 QA 最重要的能力。
值得投資。
結論
回到標題：AI 不會取代 QA。
但這句話只對一半。
完整的說法是：
AI 不會取代「會判斷」的 QA，但會淘汰「只會執行」的 QA。
AI 擅長執行：跑測試、寫腳本、產報告。這些工作的需求會大幅下降。
AI 不擅長判斷：測什麼、結果對不對、能不能上線。這些工作的價值會大幅上升。
如果你是 QA，現在就開始轉型。從執行者變成判斷者。強化業務理解、培養批判思考。
如果你是管理者，重新定義團隊的職責。短期靠 AI 提升品質，中長期再談人力調整。
不管你是誰，記住這件事：
不是 AI 取代你，是會用 AI 的人取代你。
這句話適用於 QA，也適用於幾乎所有知識工作者。
如果你對 AI 測試的實際導入有興趣，可以參考這篇更技術性的文章：