成功 Demo 很容易記住，真正能改善流程的通常是失敗。今天不把錯誤藏在最後結果後面，而是依原因整理：需求理解、程式探索、實作範圍、虛構假設、驗證不足、安全越界和過度自信。每類都要對應實際例子與可行的防護。

第一類：做對了錯的事情

模糊需求讓 AI 快速完成一個不符合使用者期待的功能。改善方式是先寫成功與失敗案例、把未決選項交回人類。若 Prompt 已很清楚仍誤解，則檢查 Context 是否缺少最新版 PRD，或文件和程式是否互相矛盾。

第二類：修改太多或找到錯地方

代理可能看到局部問題就重寫整個元件，或依檔名猜根因。對策是固定起始狀態、先探索和回報計畫、限制任務範圍、分段查看 diff。陌生 Repo 中要求引用檔案與測試證據，比單純要求「小心一點」更有效。

第三類：程式看起來合理，證據卻不足

常見情況包括假設不存在的 API、說測試通過卻沒有輸出、只測 Happy Path、把一次手動成功當完整驗收。對策是要求實際指令和結果，無法執行就明確標示；讓測試從 PRD 生長，並保留紅燈到綠燈的過程。

第四類：忽略信任邊界

把 Secret 寫進 Log、照外部文件中的惡意指令行動、未經確認部署或修改資料，影響可能超過一個 Bug。對策是縮小工具權限、把外部內容視為資料、對不可逆或外部動作設明確人類決策點，並檢查 diff 和紀錄中是否洩漏資訊。

第五類：兩個 AI 一起相信錯誤假設

讓 ChatGPT Review Codex 不會自動消除偏差。如果兩者都只看到不完整需求，可能互相確認同一個錯誤。Review 必須引用程式位置、觸發條件和重現方法；人類再用測試、執行結果與產品決策核對。

今天的結果與限制

這份圖鑑目前是依前述實驗設計建立的分類框架，尚不能聲稱哪些類型「最常」發生。只有在真實任務完成、錯誤紀錄可核對後，才加入頻率與代表案例。

今天學到什麼？

失敗不是 AI 開發的例外，而是設計流程時必須預期的輸入。最後一天會回到第一個問題：經過需求、程式、測試、部署與 Review，我還需要自己寫 Code 嗎？