同一個 bug 重修，先補「上次怎麼錯」的防呆，再叫 AI 動手。
你昨天用 coding-AI 寫的東西，今天才發現結果不對
上週你叫 AI 寫程式助手修一個 bug，當下測起來很順，心裡還小小感動：可以，今天不用加班。結果隔週同一個問題又冒出來。你再丟給它修，它看起來很認真，改出來的方向卻跟上次差不多，甚至把旁邊本來沒壞的邏輯也扯歪。這時候很容易冒出一句：它是不會學嗎？
問題不是它笨，是它沒看到前情提要
結論先講：目前多數 AI 寫程式助手，不太像坐在你旁邊、記得上週會議的同事。它比較像每次進會議室才拿到資料的外包幫手。你沒把「上次怎麼修、哪裡修錯、這次不要再碰哪裡」塞進任務裡，它就容易把這次當成全新的問題。
這不是單純的智商問題，而是工作記憶問題。你給它的提示詞(prompt)如果只有「這個按鈕又壞了，幫我修」，它看到的是症狀，不是病史。症狀一樣，它很可能走回上次那條看似合理、其實已經證明不穩的路。
更煩的是，這類錯誤常常不是「跑不起來」那種好抓的錯。Simon Willison 提過，假套件這類幻想(hallucination)反而沒那麼危險，因為一跑就爆；真正麻煩的是「跑得起來但邏輯不對」。同一個 bug 反覆回來，通常就是這種。
它是怎麼悄悄重踩坑的
第一種：你只描述結果，沒描述上次修法。像是「訂單金額偶爾算錯」，工具會先找最直覺的地方下手。上次它也是改那裡，這次它還是改那裡，因為你沒有告訴它：那條路已經試過，而且是假解。
第二種：你只說「修好了」，沒有留下判斷標準。當下頁面正常、測試資料正常，它就以為任務完成。隔週換一筆極端情境(edge case)：折扣疊加、空值、舊資料格式，問題又冒出來。它不是記仇，是根本沒拿到那張雷區地圖。
第三種：你把錯誤記在聊天裡，卻沒放進它這次能讀到的地方。上次對話、同事留言、你的腦內筆記，對新任務來說都像不存在。AI 看到的上下文太乾淨，乾淨到它可以很自信地重演悲劇。
今天就能補穩的 4 個動作
第一，開場先寫「上次事故卡」。不要一上來就說「幫我修」。改成這樣：上次問題是什麼、上次改了哪個檔案、為什麼後來證明修錯、這次哪些方向先不要動。這段不用長，五行就很有用。重點是把歷史錯誤變成任務材料。
第二，要求它先復述防呆，再寫程式。可以直接下指令：「先說明你理解的上次失敗原因，列出這次會避開的修法，等我確認再改。」如果它復述不出上次怎麼錯，先別讓它動手。這一步很像請人開工前先對答案，省得它邊猜邊改。
第三，把 bug 變成測試，而不是只變成抱怨。請它先寫一個會失敗的回歸測試(regression test)：用上次出事的資料、操作步驟、預期結果重現問題。測試先紅，再修到綠。這比「你小心一點」有用，因為工具終於有一個不准它重踩的地雷線。
第四，把修錯紀錄放進專案裡。可以開一個「AI 修錯紀錄」檔，或在相關資料夾放簡短備註：這個功能曾經因為某種輸入壞過、某個修法試過但失敗、未來修改要先跑哪個測試。下次叫工具處理前，先叫它讀這份紀錄。別只把記憶放在聊天視窗，聊天很容易散，檔案比較像專案的長期記憶。
拿走的一句話
AI 會不會重修同一個 bug，常常取決於你有沒有把「上次怎麼錯」寫成這次的防呆。
