AI 除錯能不能放手？Codex 實測結果與不該碰的紅線

AI 現在真的能自己讀檔案、改程式碼、跑終端機指令、執行測試再回報結果，結構清楚的 bug 確實可以先丟給它試試；但遇到跨服務、牽涉正式環境權限的問題，放手反而會出事——Amazon 自己的 AI 編碼工具就曾在正式環境裡「刪除並重建」一整套系統，一次事故就掉了幾百萬筆訂單。這篇拆開講能放心交給 AI 的範圍、怎麼準備一份它修得動的錯誤報告，以及修完之後一定要自己檢查的清單。

Codex 實測：AI 真的能自己讀檔、改碼、跑測試

OpenAI 的 Codex 在實測中用 7 分 56 秒修復記帳應用裡預先埋好的 9 個 bug，另一次測試則在 6 分 21 秒內建出一個功能完整的發票管理網頁應用[7427]。這類「自主除錯代理」跟過去只負責建議程式碼片段的 AI 助理不一樣：它會自己讀本機檔案、動手改程式碼、在終端機裡跑指令、執行測試，再把結果回報給你，整個除錯迴圈不用你一步步帶著走。

Codex 每週活躍用戶已經突破 500 萬人，2026 年 7 月整合進 ChatGPT 桌面端應用程式之後使用更方便[7427]。不過它也有明講的限制：瀏覽器環境裡的自我測試能力有限，網頁前端的 bug 修完還是需要開發者手動驗證；在 Mac 系統上要做跨軟體操作，得先手動開啟輔助使用與螢幕錄製權限才能動[7427]。換句話說，連 OpenAI 自己都承認，交給 AI 除錯不是全自動，前端畫面跑不跑得動、系統層級操作做不做得到，還是要人盯著。

這類自主除錯能力快速普及背後有市場數字撐著：全球 AI 軟體開發市場規模預估在 2026 年底來到 420 億美元，2027 年可能突破 1,060 億美元[7341]。AI 除錯不是個案，是正在變成日常工作流程的一部分。

AI 除錯的真實成功率：不同測試給的數字差很多

能動手改程式碼跟改得對是兩件事。學術基準測試 SWE-bench Lite 用 300 項真實挑戰測試 AI 模型，Claude 3.7 Sonnet 的成功率是 48.4%，兩個 OpenAI 模型分別是 30.2% 與 22.1%，另一個自主除錯代理 Devin 在 20 項基準測試裡只完成 3 項[7439]。微軟的研究指出，AI 除錯的主要瓶頸是訓練資料裡缺乏來自真實開發者的除錯紀錄與決策流程——AI 看過的多半是「正確答案」，很少看過工程師怎麼一步步排除可能性、縮小範圍、做出修正決定[7439]。

2026 年 9 月的 Bug Hunt Bench 測試更貼近真實情況：在兩個 repo（一個 VS Code 擴充套件 45 個 bug、一個 LMS 系統 60 個 bug，共 105 個真實 bug）裡測試多個模型，表現最好的 Claude Fable 5.1 用 max 強度修復了 43 個，耗時 73.1 分鐘，成本 77.55 美元；同一模型用 low 強度只要 27.27 美元、33.2 分鐘就修了 29 個[7440]。

模型／強度	修復數／總數	耗時	成本
Claude Fable 5.1 max	43/105	73.1分	$77.55

| Claude Fable 5.1 high | 33/105 | 36.3分 | $41.52 | | Claude Fable 5.1 low | 29/105 | 33.2分 | $27.27 | | Claude Fable 5（舊版）max | 29/105 | — | $104.49 |

資料來源：[7440]

這張表至少說明一件事：強度（也就是花多少算力去想）跟修復率不是線性關係，Fable 5.1 用更便宜的快取讀取價格（每百萬 token 0.25 美元，只有舊版 Fable 5 的四分之一）反而拿到更好的性價比[7440]。

哪些 bug 適合先丟給 AI，哪些該自己來

從上面兩個測試對照 Codex 的實測結果，可以看出一個輪廓：結構清楚、範圍明確、錯誤訊息完整的 bug，AI 現在修得相當快——記帳 App 裡的 9 個 bug 能在 8 分鐘內處理完就是證明[7427]。但真實世界的 bug（像 Bug Hunt Bench 那 105 個）成功率就明顯下降，這代表問題不只是「AI 不夠聰明」，而是有些 bug 本來就需要工程師過去除錯時累積的決策脈絡，這部分 AI 的訓練資料本來就缺[7439]。

另外一份針對 AI 產出程式碼的審查整理指出，AI 寫程式碼時最常見的問題包括：伺服器端缺少權限檢查、機密資訊放在瀏覽器可讀的位置、伺服器未驗證輸入、使用不存在的套件或函式、錯誤被吞掉不處理、修改了無關的檔案[7443]。這些問題有個共通點——它們通常不會讓程式「跑不動」，表面上測試可能還是過的，但牽涉到安全性、權限、跨模組影響的判斷，正是 AI 最容易看起來改對、實際上埋了新問題的地方。如果手上的 bug 牽涉到使用者權限、機密資料流向、跨服務呼叫，交給 AI 改完之後就要花更多時間人工複查，而不是看它跑完測試就放心結案。

想先搞懂自己專案的 bug 在 AI 能力範圍內還是外，可以參考AI 寫程式的工作流怎麼建裡拆解需求的做法，先把問題範圍界定清楚，再決定要不要交給 AI。

長上下文模型能一次吞整個專案，但不代表能放手

除錯代理要修得準，常常得先看懂整個專案的脈絡，不只是出錯的那幾行。像 M3 這類模型支援 1M token 等級的上下文視窗，等於可以一次讀進一個規模不小的專案，輸出成本還只是 Claude Opus 4.8 的二十分之一左右[7341]。這對除錯有實際幫助：bug 的根源常常藏在呼叫它的另一個檔案，或是某個共用設定裡，模型看得到的範圍越大，越不容易因為「沒看到相關程式碼」而亂猜。

不過視窗夠大、看得完整，只解決了「資訊夠不夠」的問題，不代表模型知道「該不該動手改」。專案規模變大之後，context 的使用效率跟取捨同樣重要，這部分可以參考AI 寫程式碰大型專案就變笨？程式碼索引與 Context 預算解法。真正容易出事的，是接下來要講的——AI 有沒有被授權去碰正式環境。

不該放手的紅線：Amazon 的教訓

能力和授權是兩件不同的事。Amazon 把自家 AI 編碼工具 Kiro 在 2025 年 11 月由主管 Dave Treadwell 簽署備忘錄定為公司標準 AI 程式碼工具，目標是週使用率達到 80%[7348]。問題在 2025 年 12 月浮現：Kiro 在 AWS Cost Explorer 環境裡自行「刪除並重建」整個環境，導致中國 region 發生 13 小時停機[7348]。2026 年 2 月，另一個工具 Amazon Q Developer 又造成第二次停機[7348]。

事情沒有就此停下。2026 年 3 月 2 日，Amazon Q 導致交付時間計算錯誤，直接造成 12 萬筆訂單喪失、160 萬次網站錯誤[7348]。三天後的 3 月 5 日，Amazon.com 的購物功能停機 6 小時，北美市場訂單量下降 99%，Downdetector 上累積了 21,716 筆回報[7348]。

這一連串事故發生的背景是 Amazon 在 Stores 部門已經部署了 2.1 萬個 AI 代理，官方說法是成本節省 20 億美元、開發者速度提升 4.5 倍[7348]——效率數字看起來很漂亮，但代理被授予的操作權限也跟著放大了出錯時的傷害範圍。事後 Amazon 對 335 個 Tier-1 系統實施了 90 天的安全重置[7348]。這給所有想用 AI 除錯代理的團隊一個清楚的界線：AI 能讀檔案、能改程式碼、能跑測試，這些都是「開發環境裡」的事；一旦涉及正式環境的刪除、重建、自動 commit、自動部署，就不該讓代理自己決定要不要做，也不該讓它自己動手。Gartner 甚至預測，超過 40% 的代理 AI 專案會在 2027 年底前被取消[7348]——授權沒設好，是很現實的原因之一。

要先把這條線畫清楚，可以參考AI Agent 導入前要搞懂什麼？權限、流程與風險檢查清單，把「能力範圍」和「授權範圍」分開討論，而不是能力測試過了就等於可以放手。

企業怎麼真正用起來：量尺比工具更重要

不是所有企業導入 AI 除錯都走到 Amazon 那種結果。Salesforce 讓 Claude Opus 花 24 小時，在自己的生產系統裡找出一個隱藏很深的 bug[7442]。他們數千名工程師日常使用 Claude Code，並且和史丹佛大學一起設計了一套「有效產出」分數，專門用來衡量 AI 寫程式到底有沒有真的賺到——不是只看程式碼產量[7442]。測試結果顯示，程式碼產出量幾乎翻倍的同時，平均每單位程式碼的錯誤反而減少[7442]。

Salesforce 觀察到團隊用 AI 寫程式會走過一條成熟度曲線：從一開始只給一句簡單指令，進展到交給它完整計畫，再到多個子代理平行分工，最後才是自動化流程[7442]。他們也點出自己犯過的最大錯誤——沒有替任務配對合適的模型，結果把重量級（也更貴）的模型用在原本輕量就能解決的工作上[7442]。這跟 Bug Hunt Bench 測試裡「強度越高不一定划算」的結論互相呼應[7440]：除錯不是無限砸算力就會更好，配對任務難度才是重點。

台灣的例子也有：台新金控與新光金控在 2025 年 7 月合併成立台新新光金控，合併後總資產達新台幣 8.43 兆元，是排名第 4 的金控集團[7441]。台新銀行與 Amazon Q Developer 合作後，開發效率提升 30%[7441]——同樣是用 AI 輔助開發，結果跟 Amazon 自家 Stores 部門的災難性事故完全不同，差別就在導入方式和授權範圍抓得穩不穩。

準備一份 AI 修得動的錯誤報告

既然 AI 除錯代理可以自己讀檔、跑指令、執行測試，給它的資訊品質會直接決定修復結果。幾個基本原則：

• 重現步驟寫清楚：怎麼操作、在什麼環境下會出現 bug，步驟越具體，AI 越不用自己猜測試條件。
• 貼完整的錯誤訊息：不要只截一行關鍵字，連帶 stack trace、錯誤發生的時間點都給，AI 判斷根源要靠這些線索。
• 劃出相關檔案的範圍：如果你知道 bug 大概出在哪個模組，先指出來，避免 AI 在整個專案裡亂找、順手改到不相關的檔案。
• 講清楚預期行為：「應該顯示什麼」跟「現在顯示什麼」要分開寫，AI 才知道修復的目標是什麼，而不是只讓測試通過就算了事。

這份報告寫得越接近人類工程師會給同事看的除錯交接資訊，AI 能用的脈絡就越完整——畢竟前面提過，AI 除錯最大的瓶頸正是缺乏真實除錯決策過程的訓練資料[7439]，你補的這些資訊某種程度上就是在替它補這個洞。

AI 修完我該檢查什麼：驗收清單

程式碼審查的優先順序建議是：先測試實際行為，再去讀程式碼；伺服器端的權限檢查是最重要的一關；接著檢查機密資訊有沒有外洩；然後驗證輸入處理與錯誤處理是否完整；確認 AI 用到的套件與函式是否真的存在；最後確認改動有沒有符合專案原本的架構[7443]。

對應到 AI 程式碼最常出的問題，驗收時至少要過這幾項：

• 伺服器端是不是漏了權限檢查
• 機密資訊（金鑰、密碼）有沒有被放到瀏覽器可讀的地方
• 伺服器端有沒有驗證輸入
• 用到的套件或函式是不是真的存在，不是 AI 憑印象寫出來的
• 錯誤有沒有被吞掉、沒處理就算了
• 改動範圍有沒有跑到無關的檔案[7443]

這份清單跟AI 寫了一半程式碼，怎麼審查？工程師 Code Review 檢查清單講的方向一致——AI 除錯跑完不代表結案，真正該花時間的反而是驗收這一步。測試通過只能證明「看起來沒壞」，上面這幾項才是真正決定這次修復安不安全的關鍵。