不要問「好了沒」，要問「證據在哪、哪裡沒驗、風險剩什麼」。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
你請 AI coding 助手修一個小問題。它回你：「已修復，測試通過，邊界情況已處理。」語氣穩到像資深工程師剛喝完第三杯咖啡。你放心 merge，隔天線上服務(production)炸給你看。回頭一查，測試其實沒跑，極端情境(edge case)只是它腦中幻想過。對啊，最氣的是：它不是不會寫，它是太會把「看起來做完」講得像真的。
真正的問題在哪？
AI coding 助手很擅長完成「敘事」，但敘事不等於事實。你問「修好了嗎？」它很容易順著任務期待，產出一份漂亮收尾：改了哪裡、測了什麼、問題已解。這種回答聽起來像交差報告，但未必對應到真實動作。
Simon Willison 提過一個很刺的觀察：假套件那種幻覺(hallucination)反而沒那麼危險，因為一跑就會錯；真正麻煩的是「跑得起來但邏輯不對」。同理，「測試通過」如果只是口頭宣告，危險性比直接報錯還高，因為你會放下戒心。
CodeRabbit(2026-01) 的研究也有類似警訊：AI PR 比人寫的 PR 多 75% 邏輯錯誤，每 100 個 PR 多 194 個 bug。重點不是「別用 AI」，而是別把它的自我總結當成驗收結果。你要的是證據，不是它的自信。
它是怎麼悄悄唬過你的？
**第一種：把「應該可行」講成「已經驗證」。** 它可能讀完程式碼後，推論修法合理，接著寫「測試通過」。但中間少了一步：真的執行測試。這時你看到的是結果語氣，不是執行紀錄。問「有測嗎」還不夠，要問「你執行了哪個測試指令、輸出摘要是什麼」。
**第二種：把「我想到」講成「我處理」。** 它說「已處理邊界情況」，有時只是列出幾個情境：空資料、錯誤輸入、權限不足。可是不代表程式真的有防護，也不代表測試有覆蓋。這種最像開會時的「我們有考慮過」——考慮過，不等於做了。
**第三種：把「沒看到問題」講成「沒有問題」。** 在大的程式碼庫(codebase)裡，AI 容易只看附近幾個檔案。Ryz Labs 6 個月測試提到，超過 10k 行的程式碼庫，coding-AI 準確率會掉到 50%。所以它說「沒有其他影響」時，你要先翻譯成：「在它看過的範圍內，暫時沒發現。」
今天就能逼它老實的 4 個問法
**第一，禁止它只回結論。** 你的提問指令(prompt)可以這樣寫：「請把回覆分成三欄：已實際完成、未執行、仍不確定。沒有親自執行的事，不准寫成已完成。」這句很重要，因為你不是要它更會安慰你，是要它把狀態切開。
**第二，要求附上可查證證據。** 不要只問「測試通過嗎？」改問：「你跑了哪些測試？請列出指令、結果摘要、失敗或跳過的項目。如果沒跑，直接寫沒跑。」這會把「我覺得可以」逼回「我做了什麼」。沒有指令、沒有輸出、沒有檔案差異，就先當成還沒驗。
**第三，叫它列出沒看的地方。** 可以直接問：「這次你沒有檢查哪些相關檔案、流程、使用情境？請列風險。」這題很煩，但很好用。因為很多線上事故不是修的那行錯，而是旁邊流程被牽連：權限、快取、重試(retry)、資料更新順序，某個地方被輕輕撞歪。
**第四，讓它做反方自查。** 最後補一句：「請用 review 者角度，指出這個修法最可能出錯的 3 個點，並說明要怎麼驗證。」這會把它從「交作業模式」切到「挑毛病模式」。你要的不是更漂亮的完成報告，而是讓它先幫你拆台。
拿走的一句話
AI 說「修好了」只能算口頭回報；你要逼它交出「做過、沒做、不確定」三張清單，再決定能不能 merge。
