別問 AI「幫我補測試」，要問「這段改動最怕哪些反例」。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你只是叫 coding-AI 工具修一個小 bug。它很乖，改了一行，順手補三個測試。你跑了一次，綠。心裡甚至有點感動：這不比我以前認真？兩天後線上服務(production)炸了，回頭看才發現：那三個測試都在測「資料正常、回傳正常、使用者正常」。對啊，就是那種看起來很努力、其實只是在陪 AI 演一切順利的劇本(happy path)。
真正的問題在哪？
最危險的不是 AI 編出不存在的套件。Simon Willison 提過，假內容(hallucination)反而常常沒那麼可怕，因為一跑就會錯；更麻煩的是「跑得起來，但邏輯不對」。測試全綠，就是這種錯誤最漂亮的包裝紙。
AI 很會從你給的改動附近，推一組「看起來合理」的測試。你修登入，它測成功登入；你改折扣，它測折扣有套上；你修排序，它測排序後第一筆是預期值。問題是，系統通常不是被正常資料弄壞的，而是被空值、重複請求、權限不足、資料順序反過來這些怪東西搞到翻桌。
CodeRabbit 2026 年 1 月的研究也很刺耳：AI 寫的 PR 比人寫的 PR 多 75% 邏輯錯誤，每 100 個 PR 多 194 個 bug。重點不是「AI 爛」，而是它補測試時常常在證明自己剛剛寫的程式沒問題，不是在替你找它哪裡可能出事。
常見的 3 種假安心
第一種：只測成功案例。 例如「使用者有權限、資料存在、API 回傳正常」，測試當然會過。但真實使用者很煩，他會沒權限硬點、資料刪掉後重整、網路斷掉又重送。你要抓的是這些「不照劇本走」的場景。
第二種：測了輸出，沒測副作用。 畫面回傳成功，不代表資料庫沒被多寫一筆；訂單建立成功，不代表庫存沒扣兩次。尤其遇到重複請求時，AI 補的測試常常只看第一次結果，沒看第二次會不會把系統戳穿。
第三種：照著新程式碼寫測試。 這最陰。AI 先改邏輯，再根據新邏輯補測試，等於自己出題自己改答案。測試看起來很完整，其實只是確認「現在這段程式照它自己的想法在跑」。如果原本商業規則被改歪，測試還會很熱情地幫它背書。
今天就能補穩的 4 個動作
第一，別再只說「幫我補測試」。改成這樣問： 「請先列出這次改動破壞系統的 5 種方式，包含空值、重複請求、權限不足、資料順序反、外部回傳失敗。每一種都寫一個反例測試。」 這句話的重點是先要風險清單，再要測試。
第二，要求 AI 反過來找假設。 可以貼這句： 「請指出這段程式目前假設了哪些事情必然成立？例如使用者存在、資料已排序、狀態只會變一次。把每個假設改成不成立，補測試。」 很多 bug 就藏在「理所當然」裡。你不是要它更會寫測試，你是要它先承認自己偷懶假設了什麼。
第三，把「重複做一次」放進測試。 很多線上事故不是第一次壞，是第二次、第三次才爆。像付款按鈕連點、排程重跑、通知重送。請 AI 補： 「同一個請求連續送兩次，結果應該不重複扣款、不重複寫入、不重複發通知。」 這類測試很煩，但很值錢。
第四，叫 AI 寫「會打臉自己的測試說明」。 例如： 「針對每個測試，說明它防的是哪一種真實事故。如果只是測正常流程，請標記為低價值。」 這招很派派，但有效。AI 很容易補出漂亮測試名稱；你要逼它講清楚：這個測試到底擋了哪顆雷？講不出來，多半只是綠燈裝飾品。
拿走的一句話
測試全綠不代表安全；真正有用的測試，是專門拿來打破 AI 那些「正常情況應該會這樣」的幻想。
