如何審查 AI 產生的程式碼

要審查 AI 產生的程式碼，先看改了什麼——哪些檔案，以及為什麼——然後在閱讀任何一行程式碼之前，先自己測試其行為。接著檢查 AI 程式碼最常出錯的地方：伺服器端缺少權限檢查、機密資訊暴露給瀏覽器、未經驗證的輸入、不存在的套件或函式，以及修改了你從未要求改動的東西。

AI 寫出的程式碼通常能執行，而且經常看起來很整齊。這使得人們很容易不經仔細檢查就予以核准。本指南提供一套審查流程，無論你能否流暢閱讀程式碼都能使用。

依風險程度調整審查力度

並非每次改動都需要同等的注意。

步驟 1：查看改了什麼

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

• 如果專案使用 Git，請查看 diff：自上次 commit 以來變更的檔案與行。請參閱如何在 AI 建置的 App 中使用 Git。
• 或直接請 AI 說明：

列出你在上一次修改中改動的每一個檔案，並用一句話說明每個檔案改了什麼、為什麼要改。

在這個階段的危險訊號：與請求無關的檔案、被刪除的檔案、你沒有要求的設定或相依套件變更。

步驟 2：先測試行為

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

• 以一般使用者的身分嘗試這項改動，分別在桌面與手機尺寸上操作。
• 輸入錯誤的資料：空白欄位、非常長的文字、負數、過去的日期。
• 在未登入狀態下嘗試，也以另一位使用者的身分嘗試。
• 重新執行最重要的流程：註冊、登入、主要操作、付款。

如果測試失敗，你就省下了閱讀程式碼的時間——請清楚回報，並讓 AI 修正。請參閱如何撰寫良好的錯誤回報。

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

這是最重要的檢查。AI 工具常常只在頁面上隱藏按鈕，卻讓伺服器對任何提出請求的人都願意執行該操作。

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

• 它是否檢查使用者已登入？
• 它是否檢查此使用者有權存取這一筆紀錄？
• 這個檢查是在伺服器上進行，而不只是在頁面中？

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

接著進行測試：以使用者 A 登入，記下某筆紀錄的 ID，再以使用者 B 登入並請求該紀錄。AI 建置 App 的安全檢查清單包含完整的測試方法。

步驟 4：檢查是否有機密外洩

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

請參閱如何安全地保管 API 金鑰。

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

• 伺服器端驗證。 瀏覽器端的檢查可以被略過。必填欄位、長度、格式與允許的值，也都應由伺服器驗證。
• 資料庫查詢使用參數化寫法，而不是把使用者輸入直接拼接進查詢語句中。
• 錯誤不應被吞掉。 什麼都不做的 try/catch 會隱藏失敗。錯誤應該被記錄，並且使用者應看到清楚的訊息。
• 不要向使用者顯示內部細節——堆疊追蹤與資料庫錯誤應只存在於紀錄中。

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

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

• 套件：每個新增的相依套件都應該是真實、有人維護、且名稱完全正確的套件。對於名稱看起來像熱門套件拼錯的，要提高警覺。
• 函式與 API 選項：如果程式碼呼叫了你從未見過的函式庫函式或外部 API 選項，請查閱官方文件確認。
• 預留程式碼：搜尋 TODO、mock、fake、寫死的範例資料，或永遠回傳固定值的函式。

你有新增任何套件嗎？請針對每一個套件，給出確切名稱、用途，以及我們是否可以不用它。

步驟 7：確認它符合專案架構

程式碼可以正常運作，但仍可能讓 App 日後更難修改：

• 重複。 同一段邏輯被複製到多個地方，將來會各自走樣。
• 一致性。 它應該遵循 App 其他部分已使用的模式。
• 規模。 一個 20 行的請求卻產生了 600 行程式碼，就值得提出疑問。
• 無用程式碼。 留在新版本旁邊的舊版本。

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

常見錯誤

• 因為看起來整齊就核准。 整潔的程式碼仍可能漏掉權限檢查。
• 只閱讀而不測試。 先測試，再閱讀。
• 只測試順利的情況。 嘗試錯誤的輸入、錯誤的使用者，以及未登入的狀態。
• 忽略與功能無關的檔案變更。 詢問每個檔案為什麼被改動。
• 完全相信自我審查的結果。 把 AI 的審查當作第一輪，並以測試來確認。
• 一次審查一週的改動。 應該在改動發生時就小批次審查。

檢查清單

• 我知道哪些檔案被改動、為什麼改動，而且沒有與功能無關的變更。
• 這項改動在桌面與手機上、在錯誤輸入的情況下、未登入時、以及以其他使用者身分操作時都能正常運作。
• 每一條資料路由都在伺服器端檢查了登入與擁有權。
• 程式碼與瀏覽器打包檔中沒有機密資訊。
• 輸入在伺服器端經過驗證；查詢使用參數化寫法。
• 錯誤有被記錄而不是被吞掉，且不會向使用者顯示詳細內容。
• 新增的套件是真實且必要的；沒有虛構的函式或預留程式碼。
• 高風險的改動經過仔細閱讀，必要時還有第二位審查人員。

在 Mythex 上審查程式碼

• Ask 模式可以回答關於程式碼的問題，而不會編輯它——非常適合用來提出「解釋每一項改動」與「哪些路由缺少權限檢查」這類提示。請參閱對話。
• 程式碼檢視在每個方案中都會顯示檔案樹、編輯器與終端機（免費方案為唯讀，Pro 方案可編輯），讓你自己閱讀改動內容。請參閱程式碼編輯器。
• /test 會讓 Agent 以使用者的身分在預覽中操作，並回報壞掉的流程。
• 檢查點讓你可以還原未通過審查的改動。

如果由開發人員替你審查，如何與開發人員合作開發 AI 建置的 App說明了交接的方式；如果審查中發現了錯誤，請參閱如何除錯 AI 建置的 App。

常見問題