AI 說「改好了」結果根本沒好？別讓它猜第二次，先做這兩件事

你請 AI 改一個小功能，它很快回報「改好了」，實際一測卻發現根本沒變。 你回一句「還是沒好」，它馬上道歉、換個地方再改；連試三四輪，畫面還是一樣，額度卻已經燒掉一大截。

這幾天休假，我都在讓 AI 改一款 2012 年的老遊戲，對這件事特別有感。還好自己對系統開發有一點概念，能及時幫它踩煞車；不然看它在錯的地方反覆打轉，token 根本經不起這樣燒。

其實不管是改老系統、寫網站，還是維護日常專案，AI 鬼打牆通常都卡在同一個死結。它第一次改在沒有決定權的地方，沒生效又不查原因，直接換個地方繼續瞎猜。

為甚麼 AI 明明改了檔案，畫面卻完全沒變？

因為它只挑名字最像的檔案下手，沒先查系統實際跑起來到底是誰說了算。

只要專案稍微有一點規模，硬碟上的檔案跟畫面最後顯示的結果之間，常隔著快取、背景服務或前後端分工。日常請 AI 改功能，最常撞見這三種「改對了字、卻改在沒決定權的地方」：

這三種情況裡，AI 寫的語法都沒錯，錯在動手前沒先搞清楚「系統跑起來的時候，到底是誰在讀這個值」。像我有一次請它調整功能限制與頁面跳轉條件，它一開始全在畫面端硬塞修補程式；直到我叫它去查伺服器，才發現判斷邏輯全在後端，改對地方重新載入只要 8 秒就生效。

第一次改完沒生效，讓它多試幾次不行嗎？

第一次沒生效如果不先喊停查原因，AI 往往會換個檔案或參數繼續瞎猜，不只白燒額度，還可能把原本正常的系統弄壞。

AI 遇到改了沒反應，很少主動承認找錯方向，而是直接猜下一個名字很像的位置。專案只要改版過幾次，常會留下廢棄的舊元件或備份設定；像我這次就遇過它抓著一個早就沒人呼叫的同名舊元件連改四次，還自己寫了 22 支臨時測試腳本。更危險的是放任它用試誤法亂試參數。另一次它沒先看資料表的載入檢查規則，連猜三次參數，隨手把一個欄位填成 0，當場害整台伺服器拒絕啟動而停機。

沒從程式碼找出第一次失敗的原因，後面的第二輪、第三輪都只是在碰運氣。猜不中燒的是你的時間與 token，猜歪了還會把原本沒壞的功能搞壞。

怎麼讓 AI 動手前先查清楚，不准直接瞎猜？

第一次改完沒生效，先貼一段停損指令叫它查出「誰握著決定權」與「上次失敗原因」；如果同一個專案常反覆踩坑，就用自動檢查腳本把這兩件事變成硬關卡。

平常請 AI 改既有系統，只要第一次改完沒變，千萬別只回「還是沒好」讓它直接改第二版。先把這段話貼給它：

先停下來，不要直接改第二版。請先查程式碼回答這兩件事，附上檔案名稱與行號：
1. 系統實際跑起來的時候，是哪個程序、在哪一行讀取這個設定或欄位？後面有沒有快取、自動存檔或後端邏輯會把它蓋掉？
2. 上一次修改為甚麼沒生效？請找出程式碼裡的實際原因，確認找對地方再動手。

光讓它先查這兩個問題，多數鬼打牆當場就會停下來。不過對話一長，你不可能每次手動貼；就算把「動手前先確認前提」寫進專案規則檔（像 CLAUDE.md），AI 忙起來照樣會忘記。前面提到它連改四次舊元件、亂猜參數害伺服器停機，全都發生在我寫下那條文字規則之後的 10 月 30 日。那天伺服器被弄停機後，我乾脆刪掉文字規則，改用 Claude Code 的 Hook（在 AI 改檔案前與回覆前自動執行的檢查腳本）替我守住三道關卡：

• 動手前，先驗程式碼行號：改設定、改程式碼或重啟服務前，AI 得先填一張理解卡，寫明「哪個檔案第幾行用到這個值」。腳本會直接去讀該行號的前後五列，找不到對應的字就當場擋下，不准寫入。
• 失敗後，沒寫原因不准重試：同一個問題只要改第二次以上，腳本會先檢查上一次的結果欄；沒寫出帶程式碼行號的失敗原因，就直接攔截，不准它換個參數再試。
• 說改好時，驗實際執行證據：只要那一輪改過系統、最後回報出現「修好了」或「完成」，就必須附上系統實際跑起來的畫面結果或執行紀錄，沒附證據一樣擋下。

甚麼時候不用這套機制？

如果是從零開始的新專案，或是已經確定位置、只在微調畫面參數，直接讓 AI 動手比較快：

• 從零開始的新專案或純靜態網頁：沒有舊系統的多層快取、背景服務或跨模組覆寫，改哪個檔案畫面就跟著變，不需要先過理解卡。
• 已經確定位置、正在微調畫面手感的參數：像是字體大小、畫面間距或動畫速度，既然已經確定由哪個變數控制，直接邊看畫面邊調最快，不用每改一個數字都重查一次。

下次 AI 跟你說「改好了」，一測卻發現根本沒變時，別再只回一句「還是沒變」讓它繼續猜。先叫它停下來，交出是哪個檔案、哪一行在讀這個值，以及上一次為甚麼沒生效，確認找對地方再動手。

如果你也常遇到「AI 放著現成工具不用、每次都重寫一次性腳本」的另一種燒額度情況，可以接著看上一篇〈AI 第三次用同一個笨方法時，叫它停下來做工具〉。