AI 程式碼審查可以加快找問題，卻不能替你核准上線。AI 生成程式碼即使能執行，也可能誤解需求、漏掉權限檢查，或引入不安全的相依套件。與其問「AI 寫得對不對」，更實用的做法是把變更、輸入、套件、敏感資料與軟體測試分開查核，最後保留人工核准。 先把 AI 當副駕，不是安全核准人 GitHub 的 Copilot code review 說明指出，AI 能協助檢視程式變更並建議修改；但這仍是審查回饋，不是上線許可。GitHub 的負責任使用指南也提醒，建議可能不準確、不完整，甚至語法正確卻不安全，使用者必須自行審查與測試。 因此，單元測試全過或掃描沒有警告，不代表程式碼安全；AI 自己撰寫的測試，還可能與實作共享同一個盲點。登入、付款、權限、個資、資料庫結構等高風險變更，應先由人確認設計，再在沙盒或測試環境驗證，不能讓 AI 直接取得生產憑證或操作真實資料。 檢查點一：理解變更，先守最小權限 不要只讀 AI 摘要。先問「這次改了什麼、為什麼改、影響哪些角色與資料」，再逐檔閱讀程式差異（diff）。特別留意權限判斷是否被移動、原本僅供內部使用的功能是否被暴露，以及錯誤處理是否意外放寬存取。 採用最小權限原則：服務帳號、API 權杖、資料庫連線各自只取得工作所需的功能與資料，高風險動作則需明確授權。可用提示詞：「請根據這份 diff 列出受影響的角色、資料與權限邊界；不要改程式，先標記高風險變更、未知假設與需要人工決定的地方。」若說不清楚資料流，就先補文件，不要急著合併。 檢查點二：輸入驗證，查詢採參數化 任何來自瀏覽器、API、檔案、佇列或外部服務的資料，都應在可信任的伺服器端檢查型別、長度、格式與合理範圍，採允許清單，而不是只排除幾個可疑字元。輸出到網頁時應採適合情境的編碼；資料庫查詢則使用參數化方式，讓資料和查詢結構分開，不把輸入直接拼入查詢字串。OWASP 安全編碼清單提供輸入驗證、輸出編碼與查詢安全等檢查方向。 虛構例子：會員查詢自己的訂單時，訂單編號格式正確，不等於這張訂單屬於該會員。審查不能只問「編號是不是數字」，還要確認伺服器端有核對使用者與訂單的存取權限；測試預期也應明訂：其他會員的資料不可被讀取。 檢查點三：核實相依套件的來源、版本與授權 AI 建議「順手安裝」套件時，不要盲目接受。先確認套件是否真實存在、來源與維護者是否可信、名稱是否精確、版本是否符合專案支援範圍，再檢查鎖定檔（lockfile）、間接相依套件、已知漏洞與授權條款。登錄於套件平台本身，也不等於取得安全保證。 原創 AI 概念插圖：套件名稱、來源與版本需要查證，不能因為 AI 推薦就直接安裝。 GitHub dependency review可顯示拉取請求中新增加、移除或更新的相依套件、版本與漏洞資料，也提供授權資訊；部分設定可把檢查列為合併前必要條件，實際可用性仍須核對儲存庫與方案。 讓 AI 做整理，不替你作信任決定。提示詞可寫：「請依套件清單與 lockfile 列出本次新增或升級的直接／間接相依套件，標記來源、版本、授權及尚待人工查證項目；不要執行安裝，也不要把未查證的漏洞資訊寫成事實。」授權不明或版本不相容時，交由維護者確認並留下理由。 檢查點四：祕密、個資與紀錄檔不得外洩 逐行檢查 API 金鑰、密碼、權杖、連線字串、測試用個資，以及把完整請求或回應寫入紀錄檔（log）的程式。GitHub secret scanning能掃描 Git 歷史中的受支援憑證模式；一旦發現外洩，官方建議立即輪替受影響憑證，而不是只刪掉目前檔案。掃描仍有涵蓋範圍，不能代替提交前檢查。 OWASP 也建議錯誤回應不要暴露敏感系統或帳戶資訊，紀錄檔不應保存密碼等敏感資料。可要求 AI：「請檢查這個 diff 可能記錄的祕密、個資與完整請求內容，提出遮罩與資料最小化建議；不要重現任何祕密值。」提供上下文前先去識別化，並確認組織授權與工具資料政策，不餵入生產憑證或未經授權的私有程式碼。 檢查點五：獨立設計測試，再由人工審查 先由人根據需求寫出預期結果與不可接受的行為，再請 AI 補測試案例，避免「看著實作猜答案」。至少涵蓋正常流程、缺少欄位、型別或長度邊界、逾時、重試、權限不足、依賴服務失敗，以及重複提交。測試放在隔離環境，不直接對生產執行生成指令。 原創 AI 概念插圖：測試結果只是審查依據，正式上線仍需人負責判斷。 以上述訂單情境為例，不只測「本人成功查詢」，也要測「其他會員被拒絕」、「不存在的訂單如何回應」、「查詢失敗時是否外洩資訊」。可要求 AI：「根據需求規格，先列出預期結果與風險，再提出測試案例；將每項標為可自動化或需人工觀察。」最後由審查者重新閱讀 diff、測試與警告，確認修正沒有引入新問題。 通過測試只代表已覆蓋的行為符合預期，掃描無警告仍可能漏掉設計與商業邏輯風險。NIST SSDF強調把安全實務整合進軟體開發生命週期；這不是跑完一次工具就能結案的工作。 FAQ：AI 程式碼審查常見疑問 AI 建議看起來合理，可以直接合併嗎？不應只憑語句合理就合併。AI 可能誤解上下文或提出不安全建議；仍須驗證需求、資料流、測試與安全影響，高風險變更需人工核准。 掃描全綠、單元測試全過就安全了嗎？不是。設計缺陷、權限錯誤、未知相依漏洞與測試盲點，仍需要人工判斷和持續檢查。 新手最先做哪一步？先確定自己理解變更，並只在沙盒或測試環境嘗試。若無法說明權限、資料去向與失敗後果，就請有經驗的開發者審查，不讓 AI 代替你承擔上線責任。
