要在執行前審查 AI 生成程式碼，就檢查完整 diff 和每條擬執行指令，再核對範圍、依賴、權限、secret、外部副作用、測試和回退。不要只因修補在模型解釋裏「能編譯」或附有肯定的撮要就執行。

這份清單由程式碼生成後開始。任務界定和安全分享上下文，請看 AI 編程入門工作流程；遇到具體故障時，先用以證據為本的 AI 除錯流程，再決定是否真的需要修補。

關鍵要點

閱讀實作細節前，先把 diff 與獲授權的任務對照。

把依賴、鎖定檔、建置鈎子、權限和遷移的改動視為獨立的風險決定。

搜尋 secret，以及跨越指令、查詢、路徑、URL 和範本界線的不可信資料。

執行前覆核指令，並由受限、可棄置的環境開始。

要求測試；風險需要時安排獨立覆核人，並準備可行的回退途徑。

由外至內審查：任務界線、檔案清單、供應鏈、介面、資料流、副作用、失敗行為、測試和執行計劃。GitHub 的負責任使用指引指出，生成的程式碼可能不準確或不安全，應徹底審查和測試。［1］

這份清單不能證明程式碼安全。它用來找出「暫時不能執行」的常見原因，並把較高風險的改動交給合適的覆核人。修正錯字和遷移驗證系統，不應受同等審查。

審查開始前要凍結哪些輸入？

保存確切的提示詞或任務、驗收準則、生成的 diff 和擬執行指令。確認 diff 完整，而非挑選的片段。審查期間檔案有改動，就作廢過時的審查，重查新版本。

記錄模型能存取甚麼：程式庫路徑、環境變數、網絡、外部工具和帳戶身份。這有助解釋意外的檔案或指令如何進入結果。

步驟一：審查 AI 生成程式碼的範圍及檔案意圖

列出每個新增、修改、改名和刪除的檔案，各寫一行理由說明其必要性。無法解釋的檔案是停止訊號，不是順手清理的機會。

問一問：

修補是在解決所要求的行為，還是在重新設計更大的子系統？
自動產生的檔案是否與人手編輯的原始碼混在一起？
格式化有否改寫無關的行，從而掩蓋語意上的 diff？
測試、文件、設定或 schema 是否同步修改？
修補有否刪除防護、驗證分支、錯誤處理或審計事件？

除非事先明確批准，否則否決「順道重構」。diff 小不保證正確，但令意圖和回退較易評估。

先讀設定，再讀應用程式碼

設定能改變未修改原始碼的含義。關注看似實現功能的函數前，先檢查權限、功能開關、建置腳本、CI 工作流程、環境預設設定、路由和部署檔案。

留意由「拒絕」改為「容許」的預設設定、從 CI 刪去的驗證指令，或更寬的萬用字元路徑。這些改動的風險可能比主要程式碼改動更大。

步驟二：檢查依賴及供應鏈

把新增或升級依賴視為獨立改動。核實套件名稱、儲存庫或登記處、版本限制、鎖定檔條目、間接依賴的改變、安裝腳本、維護狀況和授權條款。留意與常見套件只差一個字元的名稱。

「這個程式庫很受歡迎」不是證據。問一問：是否已有合適的依賴？幾行標準程式庫程式碼是否更清晰？審查後，在正確環境執行項目既有的依賴審計。

AI 建議可能與公開程式碼相符。GitHub 程式碼引用文件說明，受支援的 Copilot 體驗可顯示相符的儲存庫和發現的授權資料，也寫明了索引和涵蓋範圍的限制。［2］把相符提示視為覆核來源和授權的線索，而非證明未被標示的程式碼就是原創。

檢查 build 及 install 行為

檢查套件腳本、編譯器外掛、程式碼生成、鈎子和下載的二進制檔。很小的原始碼修補也可能在安裝或建置時觸發程式碼執行。確認項目要求的校驗和、簽署或固定來源仍完好；不要只因由 AI 生成就另加一套完整性方案。

步驟三：追蹤資料、secret 及權限

由入口到影響，追蹤不可信輸入的流向。輸入包括請求欄位、標頭、檔案名稱、壓縮檔、URL、Issue 文字、程式碼註解、環境變數、資料庫記錄和工具輸出。

檢查輸入會否到達：

敏感終點	核對問題
Shell 或子程序	參數是否與 shell 語法分開？可執行檔是否固定？
資料庫查詢	數值是否參數化？授權篩選可否被繞過？
檔案路徑	路徑是否規範化並限制在准許的根目錄下？連結是否安全處理？
URL 或網絡調用	協議、主機、重新導向、憑證和回應大小是否受限？
範本或渲染器	不可信內容是否按實際輸出情境轉義？
反序列化器	類型、深度、大小和意外欄位是否設有上限？

在修改的行及附近搜尋憑證、權杖、私鑰、Cookie、連接字串和簽署 URL，再檢查修補會否把敏感數值寫入記錄、傳回、快取或發往新目的地。secret 掃描工具有用，但執行時拼湊的數值未必符合靜態模式。

覆核每項副作用所用的身份。工具不應只因生成的實作處理不了較窄的角色便取得管理員權限。

步驟四：審查外部及破壞性副作用

把計算與副作用分開：準備請求的程式碼不同於發送請求的程式碼；驗證遷移的程式碼也不同於執行遷移的程式碼。

這份受控的本地審查材料使用合成的 diff 和指令清單，不含生產程式碼或 secret，也不代表該示例已獲批准或已執行。

就每項外部副作用，確認目的地、身份、發送的資料、冪等行為、逾時、重試策略、回應驗證、審計事件和復原途徑。網絡重試可能重複付款或訊息；檔案系統重試可能覆寫較新檔案；悄悄的後備處理可能把安全的失敗變成意外的成功。

OpenAI 把 sandbox、審批政策、受限的網絡存取、憑證管理和遙測描述為編碼 Agent 的不同管治控制。［3］覆核擬議的執行是否真的使用了項目的控制措施；一句「在 sandbox 中執行」的註解，不會憑空建立 sandbox。

Migration 要獨立 Review

schema 或資料遷移要檢查正向和回退行為、交易界線、鎖、長時間操作、與新舊應用程式版本的兼容性，以及重新啟動後的行為。接觸共享資料前，先用副本或 fixture。回退會遺失資料時，要清楚寫明，並要求相應負責人批准。

步驟五：閱讀失敗行為和 concurrency 假設

覆核每條新的錯誤路徑：程式碼是否失敗即拒絕（fail closed）、是否在不洩露 secret 的前提下提供足夠上下文、是否釋放資源，以及持久狀態是否保持一致。留意把錯誤變成空結果或成功的籠統例外處理。

不要為一次性本地腳本憑空增加並行複雜度，但要檢查真實執行模型。多個 worker、webhook、部署或用戶可能接觸同一狀態時，檢查鎖定、唯一性、冪等、過時讀取和重試歸屬。「先檢查再寫入」在單一程序中或許正確，在共享服務中卻可能不安全。

由 Agent 產生的多步驟改動，甚麼是 AI Agent一文說明了工具權限、狀態、退出條件和交接為何與模型的回應本身同樣重要。

步驟六：執行測試前先閱讀測試

把測試當作主張閱讀：確認它們在舊行為下會失敗、測試的是公共契約，而且沒有把聲稱涵蓋的風險 mock 掉。

要求相應的情境：

保持預期行為的正常個案；
空白、最大值、重複或 Unicode 輸入等邊界值；
格式錯誤和未經授權的輸入；
相關時，依賴、網絡、磁碟或子程序故障；
就共享狀態而言，重試、重新啟動、回退或重複傳遞；
捕捉所報告 bug 的回歸個案。

檢查有否被刪的斷言、大範圍快照更新、被略過的測試、放寬的逾時，或為避開失敗而收窄的測試指令。生成的測試可能只是覆述實作，仍遺漏需求。

NIST 的安全軟件開發框架同樣把程式碼覆核、分析和測試納入更廣泛的驗證實務。［4］因此，可讀的 diff 和獨立的測試證據是互補的，不能互相取代。

步驟七：規劃受限執行和回退

由靜態和唯讀檢查開始，再用適合項目的可棄置 fixture、sandbox、容器、臨時資料庫或隔離工作樹。除非測試需要存取已批准的目的地，否則禁用網絡。使用低權限身份，別為方便而載入生產憑證。

執行前，寫下：

確切的指令；
它可能影響的檔案、服務和帳戶；
預期的輸出和所需時間；
停止條件；
清理和回退步驟；
必須保存的證據。

回退須與副作用相符。回退原始碼不能還原被刪資料、撤銷洩露的權杖、收回已發訊息，也不能降級不兼容的 schema。無法測試復原程序時，批准前寫明這個缺口。

取得對應領域覆核

涉及驗證、密碼學、付款、個人資料、遷移、部署控制、授權條款或不熟悉的語言功能時，請相關範疇的覆核人參與。模型可協助準備審查材料包，但無法授予接受風險所需的機構權限。

執行前的最終判斷：程式碼可以開始受控測試了嗎？

以下任何一項答案未明，便先不要執行：

任務與修改的檔案清單一致。
新依賴和公開程式碼引用已經弄清。
secret 和不可信資料不會到達不安全的終點。
權限和外部副作用有界線並已獲授權。
失敗、重試、遷移和回退行為可以接受。
測試涵蓋的是契約和風險，而不只是實作。
首次執行環境盡量受限並可棄置。
影響重大的改動由一名具名人士作最終決定。

通過這份清單，只代表可開始受控測試，並非可以上生產。

總結

先審查獲授權的範圍和完整 diff，再看實作細節。
檢查設定、依賴、鎖定檔、安裝鈎子和程式碼來源。
追蹤不可信輸入、secret、權限和外部副作用。
檢查失敗、重試、並行、遷移和回退行為。
執行測試前先閱讀測試，並保留獨立覆核。
在受限環境開始執行，生產驗證另行進行。

常見問題

AI 生成程式碼比人寫的更危險嗎？

兩者都可能含有缺陷和不安全的假設。AI 輸出應受同樣的工程控制，並額外留意虛構的 API、意外的範圍、與公開程式碼相符之處，以及肯定卻缺乏根據的撮要。

能 compile 就可以執行嗎？

編譯檢查的是語法和部分類型契約，並不能證明授權、資料安全、依賴可信度、失敗行為或業務正確性。

應接受 AI 建議的新依賴嗎？

只有在核實其身份、來源、版本、對鎖定檔的影響、安裝行為、授權條款、維護狀況和必要性後才接受。如果項目已有的依賴能滿足需要，應優先使用。

如何檢查 secret？

使用程式庫的 secret 掃描工具，檢查修改的行和記錄，並追蹤執行時拼湊的數值。任何已暴露的真實憑證都要刪除並更換。

執行生成指令前要檢查甚麼？

確認可執行檔、參數、工作目錄、環境、檔案、網絡目的地、身份、預期輸出和破壞性潛力。不要複製一條你看不懂的複合指令。

Sandbox 測試能證明 production 安全嗎？

不能。它能減低影響，並為已涵蓋的情境提供證據。生產環境的身份、設定、流量、作業系統、依賴和外部服務，仍需另行驗證。

何時需要 security reviewer？

當程式碼改動涉及驗證、授權、secret、密碼學、不可信輸入的終點、供應鏈控制、個人資料、外部行動或保安監察時，就需要保安覆核人參與。

免責聲明：本文只提供一般技術資訊，不能取代機構的安全、法律、licensing、私隱及變更審批流程。

來源:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
GitHub Docs — GitHub Copilot code referencing — https://docs.github.com/en/copilot/concepts/completions/code-referencing
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 2026 年 8 月 24 日。

延伸閱讀：

執行前如何審查 AI 生成程式碼：由 diff、依賴到權限和回退逐項檢查