學習如何用 AI 編程，最穩妥的方式是給它一個有界線的任務、足以理解該任務的背景，以及一個你能親自檢查的驗證目標。把模型當作一位能快速檢查、解釋並提出修改的結對編程夥伴，而不是有權決定程式碼何時正確的權威。

如你剛開始接觸結構化的 AI 工作，先閱讀較廣泛的AI 實用入門工作流程。本文把這個模式收窄到程式碼修改：在這裏，一個吸引的答案遠不及一個細小的 diff、可重複的測試和清晰的停止點重要。

關鍵要點

由一個有可見輸入、預期輸出和明確排除項目的任務開始。

只分享最小可用的背景資料包，並在它離開你的電腦前刪除密鑰。

要求修改之前，先要求提供計劃和檔案清單。

執行任何東西前，先審查 diff、依賴、權限和外部影響。

用你已信任的工具驗證正常、邊界和失敗情況下的行為。

如何用 AI 編程而不失去控制？

使用一個包含五道關卡的循環：界定、檢查、提議、審查和驗證。AI 可以在每道關卡內協助，但由你決定工作何時推進。GitHub 的負責任使用指引指出，生成的程式碼可能不準確或不安全，審查和測試仍是用戶的責任。［1］

這個流程適合細小的錯誤修正、有針對性的測試、本機程式碼或範圍受控的重構。它不適合範圍不明的重寫、緊急的正式環境變更，或會暴露憑證和客戶資料的要求。如任務無法用一份簡短的驗收清單說清楚，便先收窄範圍，再要求寫程式碼。

先選擇能明確失敗的任務

一個好的首項任務應有可觀察的約定。「令 parse_duration 拒絕負值，同時保留有效的秒和分鐘」比「整理一下解析器」更好。前者說明了行為和兼容性界線；後者則會引來沒有界線的重新設計。

寫下四項內容：

**現時行為：**現在會發生甚麼，包括能示範它的指令或測試。
**預期行為：**修改之後應該發生甚麼。
**範圍以外：**不得改變的檔案、公共介面、依賴或格式。
**證明：**決定任務是否完成的測試或人手觀察。

把這份清單保存在對話以外，作為你的依據。如模型之後提出範圍更大的改動，便拿它與清單比較，而不是憑記憶討價還價。

步驟一：準備小而安全的上下文

預設情況下，不要貼上整個程式庫。由失敗的測試、相關函數、它的呼叫方、必須保留的公共類型或結構描述，以及規管這次修改的程式庫說明開始。只有當你能說明現有證據為何不足時，才加入另一個檔案。

刪除或替換：

API 密鑰、密碼、cookie、私鑰和環境變數檔；
客戶姓名、電郵地址、客服對話紀錄和正式環境數據；
內部主機名稱、指令輸出中的權杖，以及附簽署的下載連結；
所屬機構尚未批准用於所選工具的專有程式碼。

如真正的問題是存取和連線，請使用另一份 AI 編程工具存取檢查清單。不要把帳戶或網絡排障混進程式碼生成任務，因為這會令背景資料更難審查，亦可能誘使人分享不必要的憑證。

用合成 fixture 代替正式環境資料

用合成輸入重現行為。一個六列的 CSV、一個臨時的 SQLite 資料庫或一棵很細的目錄樹，比正式環境匯出的資料更易檢查。令 fixture 保持確定性，這樣另一位開發者執行同一條指令便能看到同樣的結果。

首項編程任務，把容許使用的最小例子複製到一個隔離的分支、工作樹、容器或一次性項目中。隔離並不能證明生成的程式碼安全，但在你仍在了解工具可能做甚麼時，它能限制意外的寫入。

步驟二：先讓 AI 唯讀檢查並提交計劃

由唯讀要求開始。要求模型找出相關檔案、解釋現時的控制流程、列出不確定之處，並提出最小的修改。告訴它暫時不要編輯檔案或執行指令。

一條實用的提示詞如下：

檢查解析器及其測試。解釋為何負數時長會被接受。提出能拒絕負值、同時不改變公共返回類型也不加入依賴的最小修改。列出你會編輯的檔案、會加入的測試，以及任何你無法核實的假設。暫時不要修改檔案或執行指令。

回答應該可以證偽。檔案清單可以與程式庫對照；關於控制流程的說法可以透過追蹤呼叫方檢查；不確定之處可以在首次編輯前解決。一段關於「改善驗證」的空泛說法，則沒有任何可審核的內容。

關於某個供應商的終端代理程式操作示範，請參閱新手 Claude Code 指南。本文的流程與工具無關：重要的界線是所要求的動作，而不是介面的名稱。

步驟三：只要求最小補丁

當計劃與驗收清單一致後，只授權相關的編輯。在要求中重申排除項目：不升級依賴、不改變公共 API、不格式化未改動的行、不做無關的清理。要求模型在發現某項限制無法滿足時停下來。

優先選擇容易還原的補丁。一處行為修改加一個回歸測試，比一個「為將來的靈活性」引入的多檔案抽象更容易推理。如模型為了一個只需改一行的錯誤，想重新命名檔案、重組模組並更新設定，便回到計劃，問清楚哪項修改是嚴格必需的。

這是受控的本機示例，使用合成的解析器 fixture，不包含正式程式庫、帳戶、客戶資料或密鑰，也不表示生成的補丁已通過審查。

把指令與解釋分開審查

不要讓一段有用的解釋掩蓋一條有風險的指令。把每條建議的指令複製到審查清單，並在執行前分類：

類別	例子	預設處理
唯讀	搜尋檔案、輸出測試內容、查看 diff	在獲批的工作區內通常安全
本機建置	編譯、執行定向測試、建立快取	先檢查資源和程式碼的副作用
修改狀態	安裝依賴、重寫快照、執行遷移	需要明確理由並經審查
外部動作	呼叫 API、上載程式碼、推送、部署、發送通知	在授權和目標明確前停止
破壞性動作	刪除資料、重設狀態、覆蓋發佈版本	不作為探索性步驟執行

OpenAI 把沙盒和審批政策描述為互補的控制：沙盒設定技術界線，而審批決定某個動作何時可以越過它。［2］在提示中要求模型「小心一點」，不能取代對檔案系統、網絡、身份和指令的限制。

步驟四：執行前審查完整 diff

按電腦執行時經歷的次序細閱補丁。由設定和依賴開始，然後是公共介面、數據轉換、外部影響和測試。當修改涉及身份驗證、儲存、子程序、網絡呼叫或遷移時，使用詳細的執行前 AI 程式碼審查清單。

問以下問題：

每個被修改的檔案都屬於已批准的任務嗎？
補丁有否改動鎖定檔、依賴來源、建置鈎子或生成的產物？
不可信的輸入能否到達 shell、查詢、範本、路徑、URL 或反序列化器？
權限、預設數值、錯誤處理或重試行為有否改變？
新測試證明的是需求，還是只重複了實作？
當輸入為空、格式錯誤、過大、重複或被中斷時，會發生甚麼？

細閱最終的程式碼，而不只是模型的總結。總結可能遺漏某個被改動的預設數值或額外的檔案。如你不理解某一行，便要求解釋，並在執行前對照語言或框架文件核實。

步驟五：驗證正常、邊界及失敗路徑

執行能證明所改行為的最小可信指令。先執行新的回歸測試，再執行最近的現有測試組。只有在定向測試提供有用的訊號後，才執行範圍更大的 lint、類型檢查、建置和整合關卡。

使用三類證據：

路徑	時長解析器例子	能證明甚麼
正常	`15s` 和 `2m` 仍能解析	兼容的有效行為得以保留
邊界	`0s`、可接受的最大值、空白字元	邊界情況符合文件約定
失敗	`-1s`、空輸入、不支援的單位	無效輸入按預期方式失敗

不要讓同一個模型宣布它自己的補丁正確。可以讓它建議遺漏的情況，但要把程式庫測試、編譯器、lint 工具、靜態分析和人手審查作為獨立的證據。NIST 的安全軟件開發框架把程式碼審查和分析放在更廣泛的安全開發實務之中，而不是把某一個工具的結果當作發佈的證明。［3］

如測試失敗，保留失敗輸出，轉入以證據為本的 AI 除錯流程。不要即時授權另一次大範圍的重寫。

記錄尚未驗證的部分

本機測試通過，並不能證明正式環境設定、作業系統行為、外部服務狀態或部署會成功。寫一份簡短的交接說明，包括：

修改的檔案和預期的行為；
執行過的指令及其確實範圍；
沒有執行的測試及原因；
仍然依賴另一個環境的假設；
回退或還原的方法；
需要作出資訊保安、數據或架構決定的審核人。

這份交接說明是結果的一部分。它能防止「AI 說它能用」成為這次工作唯一的紀錄。

何時應該停止 AI 編程流程？

當任務越過你未授權的界線、模型需要敏感資料、補丁無法保持小範圍，或預期行為存在爭議時，便停下來。當同一個失敗在沒有新證據的情況下反覆出現時，亦應停止。如驗收準則不清楚，更多的迭代也無補於事。

當任務涉及正式環境憑證、破壞性遷移、法律或授權解讀、高影響的授權、事故應變，或一個你無法安全測試的系統時，把任務交給人手負責人。更有成效的選擇往往是交回一份聚焦的調查結果，而不是硬塞一個補丁。

如必須與外部服務分享日誌或程式碼，先應用 AI 私隱風險指南中的資料最小化做法。去識別和最低權限應在上載前落實，而不是在出現意外輸出之後。

總結

界定一項可觀察的行為和明確的排除項目。
盡可能以合成 fixture 為基礎，只分享最小、已去識別的背景資料包。
編輯之前，先要求檢查和計劃。
執行之前，審查完整的 diff 和每一條建議的指令。
用可信的程式庫工具驗證正常、邊界和失敗路徑。
記錄未經驗證的環境；當風險或不確定性超出你的權限時，把任務交回。

常見問題

新手可以用 AI 寫程式碼嗎？

可以，前提是任務細小到可以檢查，而且新手能執行獨立的檢查。先由解釋、測試和範圍受控的修改開始，而不是整個應用程式。

應該把整個程式庫貼給 AI 嗎？

不應該。只分享能說明任務的最小獲批檔案組合，並刪除密鑰和個人資料。使用外部服務前，遵守所屬機構的程式碼處理政策。

AI 生成程式碼可直接執行嗎？

預設不可以。審查 diff、依賴、權限、外部影響和指令，然後在適當受限的環境中配合相關測試執行。

可以讓 AI 自動安裝依賴嗎？

只有在你核實了為何需要這個依賴、它來自哪裏、鎖定檔會有甚麼變化，以及現有依賴能否解決問題後才可以。安裝依賴是一項會改變供應鏈的操作，而不是無害的解釋步驟。

看不懂生成程式碼怎麼辦？

不要執行或合併它。要求逐行解釋，把行為與官方文件對照，並請一位熟悉該語言和受影響系統的審核者參與。

第一項 AI 編程任務應該多大？

選擇一項行為、程式庫中的一個小範圍和一項明確的證明。如所需的修改需要新的架構、多次遷移或不明確的正式環境存取，便在使用 AI 前先拆分它。

測試通過能證明補丁正確嗎？

不能。測試只能證明它在該環境中所涵蓋的情境。把測試與 diff 審查、靜態檢查、相關的整合證據，以及關於哪些內容尚未驗證的明確說明結合起來。

免責聲明：本文只提供一般技術資訊。分享程式碼或執行生成改動前，請遵守機構的安全、私隱、授權及變更控制要求。

來源:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
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 編程：新手由限定任務到測試驗證的安全工作流程