你請 Cursor 幫你補了 30 個單元測試。全部綠燈。Coverage 從 62% 拉到 89%。你 commit、push、merge，覺得這禮拜的技術債清得很爽。
兩週後上線，炸了。一個 null 處理的 edge case，user 一進去就 500。
你回頭看那 30 個測試——它們確實都在跑，確實都過了。但仔細看會發現：它們測的全都是「正常 happy path 跑得通」，沒有任何一個在測「壞掉的時候會怎樣」。
這不是你運氣不好。這是現在用 AI 寫測試的 RD 普遍會遇到的情境。而且學術界已經有研究把這件事量化出來了。
數據：AI 寫測試的「綠燈幻覺」
2025 年 ICLR 發表的 TestGenEval[1] 是目前最具代表性的測試生成評測。它不只看 AI 能不能寫出「會跑」的測試，還看品質——用 mutation score（突變分數）量「真的抓得到 bug 的能力」。
結果很反直覺：Llama 3.1 405B 寫出最多能通過的測試，但 mutation score 反而比 GPT-4o 低。 寫得多不代表寫得好，能跑不代表有抓到問題。
更尖銳的是 2026 年 3 月的一篇 preprint SWE-ABS[2]（注意，未經同儕審查）。研究團隊重新檢視業界最權威的 SWE-Bench Verified 排行榜，把測試套件強化過後重新跑分，發現：
頂尖 AI agent 的「修 bug 成功率」從 78.80% 掉到 62.20%——每 5 個被判定修好的 bug，有 1 個其實是錯的。
它們之所以被當成「修好了」，只是因為原本的測試太弱、抓不到語義錯誤。
把這兩個發現合起來看：AI 不只「寫測試的能力」不夠，連幫 AI 打分數的測試本身都不夠強。整個產業正在用一把不準的尺量 AI 的測試能力，然後得出「AI 已經很會測試」的結論。
根因：AI 是從一個不重視測試的產業學東西
為什麼會這樣？答案不在 AI，在訓練資料。
LLM 學測試主要從 GitHub 開源 repo 學。但這些 repo 的測試是誰寫的？大多是開發者自己順手寫的，不是測試專業工作者寫的。 結果就是：
- 測試形式以 unit test 為主，因為這是開發者最熟的形式
- 案例反映「我這段 code 怎麼寫」，而不是「這段 code 會怎麼壞」
- 邊界值、等價類、決策表這些黑箱測試方法論在 code 裡幾乎不存在
- 風險分析、規格 ambiguity 識別根本不會以程式碼形式出現
LLM 從這些資料學到的是「測試大概長什麼樣子」，沒學到「測試應該抓到什麼」。
回頭看 SWE-ABS 那個 1/5 灌水率——它的測試套件來自真實 GitHub PR。翻譯一下就是：「真實世界開發者寫的測試，有 1/5 的機率連『修錯了』都看不出來。」
AI 不是特別爛，它只是把整個產業日常的測試脆弱性放大暴露出來而已。
那不是等 AI agent 更強就好了嗎？——目前沒有路
業界現在很流行一個說法：LLM 本身不用更聰明，把它包在更強的 agent 框架裡——讓它能自己跑測試、自己看結果、自己 retry——問題就解決了。這套在「寫程式」上確實管用：程式跑不出來、AI 看一眼錯誤訊息就知道哪裡錯了，改一次就好。
但這套在「測試」上行不通，原因只有一個：「測試夠不夠好」這件事，沒辦法讓機器自己判斷。
AI 寫了一個測試，跑起來綠燈——agent 怎麼判斷它有沒有抓到該抓的 bug？它不知道，因為 bug 還沒發生。Mutation testing（自動改壞 production code 看測試會不會 fail）是目前最接近的工具，但它能改的就是 > 改成 >=、if 改成 if ! 這種已知的小錯誤。真實世界的 bug 從來不長這樣——真實的 bug 是「需求寫得不清楚」、「兩個狀態加在一起沒人想到」、「A 模組改了害 B 模組壞」。這些 mutation 工具一個都生不出來，agent 也就學不到要去找。
也有人提議讓「另一個更強的 AI」去判斷測試寫得好不好。聽起來合理，但問題是：「好測試」沒有標準答案——不像數學有對錯，測試的好壞要看「會不會抓到還沒發生的 bug」，這件事連人類專家都會吵。讓 AI 去評 AI，等於用一把不準的尺量另一把不準的尺。
更根本的問題是：agent 框架擅長解的是「AI 知道方向、但執行容易出錯」——retry 幾次就修正。但測試的問題卡在更前面——AI 連方向都沒抓對，因為它從來沒從訓練資料學到「測試該怎麼想」。要解這個，靠的不是更聰明的 agent，是更高品質、帶著測試思維的訓練資料。而這在「開發者順手寫測試」當主流的產業生態下，短期內看不到出路。
對 RD 的真正意義：你的個人風險
這件事為什麼跟你有關？因為你正在用 AI 寫的測試做兩個重大決定：
- 「這個 PR 可以 merge 嗎？」——你依賴測試結果判斷
- 「這個功能可以 release 嗎？」——你依賴測試覆蓋率判斷
如果 AI 寫的測試系統性地偏向「綠燈但不抓 bug」，你這兩個決定的可靠度都被高估了。事故發生時被叫去 root cause 的是你，不是 AI。
更現實的是：會用 AI 的人多，會用 AI 又懂測試的人少。前者會用 AI 快速生產脆弱的測試套件，把品質債堆得比以前更快。後者能用 AI 加速並維持品質。中間沒有自動補救機制——AI 不會主動告訴你「你的測試有問題」，因為它自己也不知道，而 agent 框架也補不上這個洞。
你下週可以做的三件事
不是 QA 的工作，是 RD 自己的工作：
第一，AI 寫的測試，驗證它會不會真的抓到 bug 最快的方式是用 mutation testing 工具（Java 用 PIT、JavaScript 用 Stryker、Python 用 mutmut），讓它自動改壞 production code、看你的測試會不會 fail。如果 mutation score 低於 60%，代表大部分測試是綠燈幻覺。沒裝工具的話，手動版也可以：隨機挑幾段 production code，故意改壞一個運算子或條件，看測試會不會 fail。
第二，請 AI 寫測試之前，先逼它列出「這個功能可能怎麼壞」 直接寫 prompt：「在寫測試之前，先列出這個功能可能的 10 種失效情境，包含邊界值、非預期輸入、狀態組合、外部依賴掛掉。」這一步逼 AI 從「寫測試」切換到「想 bug」，產出的測試品質會明顯不同。重點不是 AI 想得多好，是這個動作會逼你自己也想一遍。
第三，補一點黑箱測試方法論的基本功 等價類劃分、邊界值分析、決策表——這三個就夠。學起來大概一個下午，但能讓你看出「AI 寫的測試漏了哪些 case」。這是 AI 訓練資料裡最稀缺的能力，也是你個人最有 ROI 的補強點。
別誤會，這篇不是叫你少用 AI。AI 寫測試還是該用，速度太重要。重點是：用 AI 寫測試的同時，建立一層你自己的驗證機制。否則你就是在用 AI 加速生產一堆綠燈幻覺，而且事故發生時，扛責任的還是你。
資料來源
[1] TestGenEval：真實 repository 規模的測試生成 benchmark Jain, K. et al. (2025). TestGenEval: A Real World Unit Test Generation and Test Completion Benchmark. ICLR 2025. https://arxiv.org/abs/2410.00752
[2] SWE-ABS：揭露 SWE-Bench Verified 1/5 patch 語義錯誤 Yu, B. et al. (2026). SWE-ABS: Adversarial Benchmark Strengthening Exposes Inflated Success Rates on Test-based Benchmark. arXiv preprint, March 2026. https://arxiv.org/abs/2603.00520 （注意：preprint 尚未經同儕審查）
發表迴響