開發者在使用 AI 助手寫程式時犯的錯誤有哪些？

Copilot、Claude 和 Cursor 內建模型這類 AI 助手改變了程式碼的編寫速度。但它們並未改變程式碼需要被審查的謹慎程度。我看過的 AI 輔助編程造成的大多數傷害，來自於少數可重複的習慣，而不是模型本身。

接受建議而不讀過內容

最大的問題是因為一個補完看起來合理且能編譯，就按 tab 接受它。合理並不等於正確。我看過有人在重構時接受了一個刪掉 WHERE 子句的 SQL 查詢建議，因為變數名稱相符。如果你沒有以閱讀同事 pull request 的速度來讀每一行助手給你的程式碼，你就會釋出自己不理解的東西。把每個建議都當作一個速度快但不記得你的程式碼庫慣例的初級開發者的初稿。

讓它處理安全敏感的程式碼

AI 助手是在海量的公開程式碼上訓練的，其中有很多程式碼內含安全問題。要求一個快速的檔案上傳處理器，你常常會得到沒有副檔名檢查、沒有大小限制、且路徑由字串串接而非 os.path.join 或安全函式庫呼叫構建的東西。驗證的故事也一樣：助手喜歡建議把 JWT 存在 localStorage，或用 == 而不是常數時間比較來比較密鑰。這都不是惡意的，只是在訓練資料中統計上常見。對於任何涉及認證、檔案 I/O、反序列化或 SQL 的東西，自己寫邏輯或將 AI 的輸出通過你對任何新程式碼會問的相同威脅建模問題：如果輸入是惡意的會發生什麼、如果這個呼叫失敗會發生什麼、還有誰可以到達這個端點。

讓它虛構依賴和 API

模型會毫不懷疑地虛構套件名稱和函式簽名。這就是「slopsquatting」問題──攻擊者註冊模型經常建議的假套件名稱，所以未驗證的 pip install 或 npm install 可能會拉下完全不是你的日誌函式庫的東西。在添加助手推薦的任何依賴之前，檢查它是否真的存在於 PyPI 或 npm 上，檢查它的下載次數和最後發佈日期，如果夠小的話瀏覽一下原始碼。同樣的謹慎也適用於 API 呼叫：如果助手引用你不認識的方法，在假設它存在之前檢查實際文件。

失去對自己程式碼的心智模型

當你自己寫程式碼時，你會建立一個每一塊為什麼存在的心智地圖。當你在一個 session 中接受大塊的 AI 生成程式碼時，那個地圖很快就變薄了。然後三週後出現一個錯誤，你在偵錯自己從未真正寫過且不完全記得的程式碼。修正不是避免 AI 生成的程式碼，而是放慢速度，在合併每一塊之前向自己或隊友解釋它。如果你無法解釋函式做什麼以及為什麼這樣做，就別急著合併。

因為程式碼而跳過測試