審查 AI 生成的程式碼

先讀需求，再看摘要

從要求的行為和驗收標準開始，再檢查實際 diff。代理程式的摘要可以協助掌握方向，但可能漏掉變更，或不準確地描述檢查。

確認受審查的分支和提交。除了應用程式碼，也檢查設定、相依項目、基礎設施和測試變更。畫面上很小的功能，可能包含重大的權限或部署行為變動。

先審查後果最重大的行為。格式和命名很重要，但不應因此忽略缺少的資料邊界。

從身分追查到資源

以下是不完整的虛構端點，用來說明審查問題，不是正式環境程式碼。

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

函式取得已通過身分驗證的使用者，卻沒有展示對發票的授權決策。審查者必須檢查是否由其他層落實。未使用的 user 值是調查理由，本身不能證明存在可利用的缺陷。

沿實際系統追查請求，辨識可信的使用者與組織。檢查查詢如何限制對請求紀錄的存取，並查看錯誤行為和禁止請求的測試。

不要假設隱藏按鈕就能保護 API。呼叫者可以不經介面送出請求。也不要假設有效紀錄 ID 就代表有存取權。

問哪些證據能拒絕變更

通過的測試可能使用管理員測試資料，或模擬授權。檢查測試是否涵蓋重要邊界。適當時，加入不同組織與真實授權路徑的案例。

使用者介面變更，應檢查實際呈現結果，包括鍵盤操作、空白狀態、載入行為和錯誤。型別檢查不能證明對話方塊可用鍵盤操作。

相依項目變更，應驗證必要原因，審查版本、授權條款和資安發現。不要只因代理程式在任務中生成了不相關升級，就接受它。

保持審查獨立

第二個模型可能找出有用問題，也可能重複實作中的假設。給審查者需求和 diff，避免先告訴它變更已經正確。

要求每項發現指出具體失敗路徑和相關程式碼。把沒有根據的警告當成待調查問題。重要說法取得證據前，語氣肯定的批准仍只是另一個意見。

人工審查仍是涉及責任的決策。審查者應充分了解變更，能解釋行為、風險和驗證。Diff 太大時，縮小範圍，或拆成可審查的變更。

以最終版本完成審查

修正後，重新執行受影響檢查，確認修正是否造成新問題。依照儲存庫政策，確保必要審查適用於最終版本。

用行為和證據記錄驗收決定。為剩餘限制指定負責人和下一步行動。不要將未解決問題改寫成所有檢查都通過。

檢查真實變更前，可透過程式碼審查練習，練習找出缺少的決定。