[AI 觀察] AI 寫程式愈快，程式碼稽核為何更重要？

[AI 觀察] AI 寫程式愈快，程式碼稽核為何更重要？

摘要：Anthropic 分享 AI 開發經驗：加快產出之餘，仍須以獨立驗證、風險分級與人工判斷守住品質。

內容:

一個 AI 寫程式、另一個 AI 找錯，兩者整夜往返修改超過五十輪，最後仍由人叫停。這是 Claude Code 團隊披露的經歷，也點出 AI 開發的難題：產出速度提高，不代表稽核能同樣加速。

Anthropic 在 2026 年 10 月 15 日的開發者部落格表示，Claude 編寫了 Claude Code 約九成的程式碼；6 月至 9 月，合併的變更請求增加逾一倍，回滾比例下降逾四成。這些是團隊的內部數據，不能直接推論其他團隊也會得到相同成效。回滾「比例」下降，也不等於回滾「次數」或事故一定減少。

稽核的難處不只在讀懂程式碼，更在確認它解決了正確的問題。代理可能寫出清楚的註解和通過測試的程式，卻誤解業務規則。例如取消訂單後恢復優惠券，還必須釐清重複取消通知是否會重複發券、部分退款該如何處理。若需求與不可接受的後果沒有先說清楚，程式寫得愈快，誤解也可能擴散得愈快。

因此，測試綠燈需要有可核對的依據：測試是否真的執行、環境和輸出是什麼、案例是否檢查了關鍵結果。讓同一個代理依照自己的錯誤實作補測試，可能只會讓兩者在同一套誤解中互相證明。較可靠的做法是結合不同證據來源——程式碼檢查、實際執行、型別與安全檢查，以及人對業務意圖的確認，而不是把多個代理的同意當成完全獨立的保證。

稽核投入也應隨風險調整。一行權限設定的變更，可能比數百行介面調整更危險；低風險修改可在驗證可靠、影響可控等條件下採用較輕流程，敏感修改則仍需人工批准。代理的批准不能取代規則要求的人類審批，而審批者也不能只看摘要點選同意，必須知道證據涵蓋了什麼、還有哪些後果需要判斷。

檢查不應止於合併前。並行修改可能各自通過測試，合在一起卻互相衝突；分階段發布需要觀察指標，回滾方案也須按實際系統驗證。尤其資料遷移可能刪除舊欄位，即使重新部署舊程式碼，也未必能恢復原始資料。功能正確之外，真實資料量下的效能同樣可能成為問題。

自動稽核也要避免過度報錯。每項發現都應指出具體位置、觸發方式與後果；大量不重要或不正確的意見，會耗費審查時間，甚至讓代理為迎合建議而引入新問題。團隊需要明確規則、停止條件，以及誰有權接受理由並關閉意見。

對準備採用 AI 開發的小團隊，更穩妥的起點是選擇影響有限的變更，寫明行為要求，建立可執行的驗證，記錄真實故障與誤報，再依證據調整人工流程。AI 可以降低寫程式碼的成本；決定什麼值得做、如何證明它可用，以及出事後如何恢復，仍是團隊必須承擔的工作。