如何審查 AI 生成的程式碼

要審查 AI 生成的程式碼，先從改動的內容開始：哪些檔案被改動，以及為什麼；然後在閱讀任何一行程式碼之前，先親自測試行為。之後，檢查 AI 程式碼最常出錯的地方：伺服器端權限檢查缺失、機密資料暴露於瀏覽器、未經驗證的輸入、不存在的套件或函式，以及你從未要求它改動的地方。

AI 寫出的程式碼通常能夠執行，而且看起來整齊，因此很容易不加細看就批准。本指南提供的審查流程，無論你是否熟悉閱讀程式碼，都適用。

按風險調整審查力度

並非每一項改動都需要同樣的關注。

第 1 步：查看改動了什麼

在判斷程式碼之前，先取得改動的清單：

• 如果專案使用 Git，請查看 diff：即自上次提交以來被改動的檔案及行。參閱如何為 AI 建置的應用程式使用 Git。
• 或直接問 AI：

列出你在上一次改動中修改的每個檔案，並用一句話解釋每個檔案改了什麼，以及為什麼改。

這個階段的警號包括：與要求無關的檔案、被刪除的檔案，以及你沒有要求改動的設定或依賴項目。

第 2 步：先測試行為

閱讀程式碼告訴你它原本應該做什麼；測試則告訴你它實際做了什麼。在閱讀之前：

• 以一般用戶的身分嘗試這項改動，分別在桌面及手機尺寸的螢幕上操作。
• 輸入不正確的資料，例如空白欄位、極長的文字、負數、過去的日期。
• 在未登入的狀態下嘗試，並以另一位用戶的身分嘗試。
• 重新測試最重要的流程：註冊、登入、主要操作、付款。

如果測試失敗，你已經省下了閱讀程式碼的時間；清楚地回報問題，並讓 AI 修正。參閱如何寫出好的錯誤報告。

第 3 步：在伺服器端檢查權限

這是最重要的檢查。AI 工具常見的問題是：在頁面上隱藏了按鈕，但伺服器仍然願意為任何提出要求的人執行該操作。

對於每一個讀取或更改資料的路由或函式，請問：

• 它有否檢查用戶是否已登入？
• 它有否檢查此用戶是否有權存取這筆記錄？
• 這項檢查是在伺服器端進行，而不只是在頁面上？

對於你新增或修改的每個 API 路由，告訴我它在伺服器端做了什麼權限檢查，並引述相關的程式碼行。標示出任何沒有權限檢查的路由。

然後進行測試：以用戶 A 登入，記下某筆記錄的 ID；再以用戶 B 登入，嘗試存取該記錄。AI 建置應用程式的安全檢查清單載有完整的測試方法。

第 4 步：查找外洩的機密資料

• 在被改動的檔案中搜尋任何看起來像金鑰或密碼的內容。
• 確認機密金鑰是從環境變數讀取，並且只在伺服器程式碼中使用。
• 留意機密變數上是否帶有公開前綴，例如 VITE_ 或 NEXT_PUBLIC_；這些變數會被打包進瀏覽器的程式碼中。

參閱如何妥善保管 API 金鑰。

第 5 步：檢查輸入與錯誤處理

• 伺服器端驗證。 瀏覽器端的檢查可以被繞過。必填欄位、長度、格式及允許的值，伺服器也應該檢查。
• 資料庫查詢使用參數，而不是把用戶輸入直接拼接到查詢文字中。
• 錯誤不應被靜默吞掉。 一個什麼都不做的 try/catch 會隱藏失敗。錯誤應該被記錄下來，而用戶應該看到簡潔的訊息。
• 不要向用戶顯示內部細節。堆疊追蹤及資料庫錯誤應該只出現在日誌中。

第 6 步：確認它是真實存在的

AI 模型有時會生成看似正確、但實際上引用了不存在事物的程式碼。

• 套件：每一個新增的依賴項目，都應該是真實、仍在維護、名稱完全相符的套件。對於名稱看起來像熱門套件拼錯字的，要特別小心。
• 函式與 API 選項：如果程式碼呼叫了你從未見過的函式庫函式或外部 API 選項，請查閱官方文件。
• 預留位置程式碼：搜尋 TODO、mock、fake、硬編碼的範例資料，或永遠回傳固定值的函式。

你有否新增任何套件？對每一個套件，請給出確切名稱、用途，並說明我們能否不用它。

第 7 步：檢查是否配合整體

程式碼可能運作正常，卻令應用程式日後更難修改：

• 重複。 同一段邏輯被複製到多個地方，日後會出現不一致。
• 一致性。 應遵循應用程式其他部分已採用的模式。
• 規模。 一個 20 行的要求卻生成了 600 行程式碼，就值得提出疑問。
• 無用程式碼。 舊版本被遺留在新版本旁邊。

由於這次改動，專案中是否有任何程式碼已不再被使用，或有邏輯在其他地方重複出現？請先不要更改任何東西，只列出來即可。

常見錯誤

• 因為看起來整齊而批准。 整齊的程式碼仍然可能缺少權限檢查。
• 只閱讀而不測試。 先測試，再閱讀。
• 只測試順利的情況。 也要嘗試錯誤的輸入、錯誤的用戶，以及未登入的狀態。
• 忽略無關的檔案改動。 詢問為什麼每個檔案都被改動。
• 完全信任自我審查。 把 AI 的審查當作第一輪，並以測試作確認。
• 一次審查一整週的改動。 應該在改動發生時，逐步審查小型改動。

檢查清單

• 我知道哪些檔案被改動、為什麼改動，而且沒有與要求無關的改動。
• 改動在桌面及手機上運作正常，並已在錯誤輸入、未登入及以其他用戶身分的情況下測試。
• 每一條資料路由都在伺服器端檢查了登入狀態及資料擁有權。
• 程式碼及瀏覽器打包檔案中沒有機密資料。
• 輸入在伺服器端經過驗證；查詢使用參數。
• 錯誤有被記錄而非被吞掉，也沒有向用戶顯示詳細內容。
• 新增的套件真實且有需要；沒有虛構的函式或預留位置程式碼殘留。
• 高風險的改動經過仔細閱讀，並在有需要時由第二位審查者檢視。

在 Mythex 審查程式碼

• 問答模式可在不編輯程式碼的情況下回答有關程式碼的問題，非常適合用來提出「解釋每一項改動」或「哪些路由缺少權限檢查」這類問題。參閱對話。
• 程式碼檢視在每個計劃中都提供檔案樹、編輯器及終端機（免費計劃為唯讀，Pro 計劃可編輯），讓你自行閱讀改動的內容。參閱程式碼編輯器。
• /test 會讓 agent 以用戶身分在預覽中操作，並回報失效的流程。
• 檢查點讓你可以還原未能通過審查的改動。

如果有開發人員協助審查，如何與開發人員合作處理 AI 建置的應用程式 會講解交接的方式；如果審查時發現錯誤，請參閱如何為 AI 建置的應用程式除錯。

常見問題