AI 生成程式碼審查與驗收清單：用證據核實結果

審查 AI 生成的程式碼，要先查差異，再查行為：確認每個新的相依套件和 API 真的存在，先看測試改動再看程式碼改動，證明至少有一個測試在沒有修復時會失敗，自己在最終差異上重新執行檢查，最後從正常入口使用功能，並讀回儲存後的結果。下面的清單涵蓋這兩部分，並附一份可留存的簡短證據記錄。

能跑通一次示範，只是一項觀察。驗收要回答的是：這個具體版本，是否在約定條件下完成了使用者任務，結論是否有可複查的證據？

本清單適用於獲授權環境中的小型應用功能、API 改動或缺陷修復。從使用者正常入口開始，檢查到最終可持久保留的結果。清單可以手動使用；相關 Skill 用來組織工作，並非填寫範本的前提。

先做這些

當你需要決定「這段 AI 寫的改動，在約定範圍內能不能驗收通過」時，依下面五步執行，再填寫後文的證據紀錄。

1. 固定準確版本（commit 或 diff 雜湊）、角色、環境和一條可觀察的驗收標準。
2. 做完四項 AI 專屬檢查：相依套件真實存在、先看測試差異、證明測試能失敗、在最終差異上自己重跑檢查。
3. 從使用者正常入口走到可持久讀回的結果——不要只看成功提示。
4. 至少填一行證據：PASS / FAIL / BLOCKED / NOT RUN / N/A（N/A 必須寫理由）。空白證據不能支撐 PASS。
5. 由人明確拍板：本範圍接受、拒絕，或暫停。不要把智慧體摘要當成最終決定。

這是本指南可直接執行的結論；後文展開每一步並給出教學演練，不能代替證據紀錄。

適合與不適合的範圍

適合審查範圍明確、基準和需求可識別、能夠存取相關執行環境的改動。檢查深度由行為風險決定，不由修改檔案數決定。

它不取代滲透測試、無障礙符合性評估、受監管系統認證或正式環境負載測試方案。支付、身分、敏感資料、破壞性遷移和安全關鍵系統需要額外的專業審查。打勾不構成法律或安全保證。

程式碼審查還是驗收：這次改動需要哪一個？

大多數 AI 生成的改動兩者都需要。程式碼審查回答差異是否安全、合理；驗收回答這個功能對使用者是否真的可用。GitHub 的 AI 生成程式碼審查指南、Sentry 的 AI 生成程式碼審查手冊等常見指南，重點都放在閱讀差異。本文補上後半部分。

程式碼審查回答：這份差異是否正確、安全、沒有超出範圍？

• 主要輸入：差異、測試和相依套件。
• 典型檢查：憑空捏造的 API 或套件、超出範圍的改動、權限、密鑰、測試品質。
• 典型證據：審查紀錄、掃描結果、CI 記錄檔。
• 單獨使用會漏掉：能編譯、但儲存後就出錯的流程。

驗收回答：這個具體版本能否為真實使用者完成約定任務？

• 主要輸入：執行中的應用程式、測試帳號和儲存後的資料。
• 典型檢查：正常入口、持久化讀回、失敗與復原路徑。
• 典型證據：對應到具體版本的修改前後證據。
• 單獨使用會漏掉：使用者看不到的安全漏洞。

本清單適合用 Claude Code、Codex、Copilot 等 AI 代理交付小範圍改動的獨立開發者和小團隊。

1. 固定驗收對象

記錄基準、候選提交或建置產物、環境、瀏覽器或執行階段、角色、獲准的資料來源及副作用範圍。存在未提交修改時，還需保存差異快照或雜湊。先附上需求來源並分配 REQ/AC 編號，再看測試結果。

每項需求都寫成獨立於程式實作的可觀察結果。「執行了 Save 處理函式」不夠；「有權限的使用者重新開啟記錄後仍看到新值」才是結果。關鍵規則缺失時標為 BLOCKED，不從生成程式碼反推正確需求。

使用 PASS、FAIL、BLOCKED、NOT RUN 或 N/A。N/A 必須說明為何確實不適用，不能用來掩蓋工具缺失。沒有證據不能判 PASS。例外應記錄決策人、範圍和後續事項，不可悄悄改成通過。

2. 執行適用檢查

• [ ] 需求: 將每項 REQ/AC 對應到實作入口、案例和結果。檢查差異中完全缺失的承諾，記錄已同意的排除項，並確認沒有擅自增加業務規則或權限。

• [ ] 核心功能與持久化: 從對應角色的正常入口完成任務。寫入後重新整理或重新開啟，在允許的存取範圍內讀回權威狀態，並關聯同一物件和請求。成功提示不能單獨證明儲存成功。

• [ ] 邊界與狀態: 按實際規則檢查缺省、空值、非法值及上下界兩側，確認計數單位。按風險涵蓋合法和非法狀態轉換、重複點擊、舊頁面及並行更新。

• [ ] 錯誤與復原: 僅在獲准的隔離環境測試逾時、拒絕、部分失敗和中斷。確認使用者能理解錯誤並恢復操作；重試不重複產生副作用，延遲回應不能覆蓋更新的操作。

• [ ] 安全基礎: 檢查實際動作及物件的伺服器端授權，包括歸屬不同的第二個測試帳號。拒絕請求不得改動資料；按攻擊面檢查輸入驗證、輸出編碼及建置檔案或記錄中的憑證洩漏。只做授權檢查，不攻擊無關系統。

• [ ] 可及性與互動: 用鍵盤完成受影響流程，檢查焦點、名稱和標籤、錯誤及對話框關閉。檢查縮放、窄螢幕、可讀對比度和有意義的替代文字；按產品需要增加輔助科技檢查。這些基礎檢查不等於符合性評估。

• [ ] 效能: 先約定操作、資料規模、裝置和網路條件、測量方法與門檻。測完整使用者操作，不只測 API 耗時；同條件比較基準並保留樣本及資源觀測。無門檻時報告測量結果並等待決策，不自設及格線。

• [ ] 迴歸與審查: 執行受影響的現有檢查及儲存庫要求的 lint、型別、建置和測試。涵蓋共用呼叫端及相鄰合法和非法路徑，審查最終差異是否遺漏需求或削弱斷言。修復要保留修復前失敗、修復後通過的訊號。

• [ ] 證據與交付: 每個結論都關聯被測版本、實際步驟或命令、預期、實測及原始證據。明確標示 Mock、固定樣本、合成資料及靜態審查；確認最終差異沒有使證據過期。本地驗證、部署和目標執行環境驗收分開報告。

一般審查常漏掉的四項 AI 專屬檢查

這四項檢查針對上述審查指南特別點出的 AI 改動問題：憑空捏造的相依套件、被削弱的測試、不可能失敗的測試，以及從未在最終差異上執行過的「測試已通過」。

1. 確認每個新的相依套件都存在，而且就是你要的那個。 安裝前，在官方套件庫和鎖定檔裡逐一核對新套件。一項發表於 USENIX Security 2025 的研究測試了 2024 年 1 月選定的 16 個程式碼生成模型：生成的 Python 和 JavaScript 程式碼共引用約 223 萬個套件，其中 19.7% 並不存在；商業模型平均至少 5.2%，開源模型平均 21.7%。較新的模型可能表現更好，但今天不存在的套件名稱，明天可能被攻擊者搶先註冊。

2. 先看測試差異，再看程式碼差異。 刪除的測試、新加的 skip、被改動的預期值、取代受測程式碼的 Mock，都是 AI 代理在替你決定什麼叫「正確」。GitHub 的指南特別提醒要留意被刪除或跳過、而不是被修好的測試。先確認這些決定，再讀實作。

3. 證明至少有一個測試會失敗。 把新增或修改的測試放到修復前的版本上執行，或暫時破壞它保護的那一行，確認它會失敗。如果仍然通過，它就什麼也沒保護到。Stryker 等變異測試工具會自動植入小缺陷，再檢查測試是否失敗，原理相同。

4. 自己在最終差異上重新執行檢查。 AI 代理的總結不是測試結果。記錄指令、實際執行的測試數量、結束代碼，以及對應的提交或差異。最後一次修改之前的結果不算數。

這次改動需要檢查到什麼程度？

依改動涉及的範圍決定檢查深度，而不是依行數。以下分級是我們的實務判斷；高風險觸發條件參考了 OWASP 安全程式碼審查指南中關於何時加深審查的建議。

• 低： 文案、樣式、文件，或測試不變的獨立重構。最低要求：建置、lint、現有測試，並看一眼結果。
• 中： 現有邊界內的功能、介面狀態，或不涉及新權限的新 API 端點。最低要求：低級全部要求、上面四項 AI 專屬檢查，以及一個從正常入口出發並讀回結果的驗收案例。
• 高： 登入驗證、權限、付款、個人資料、資料遷移、刪除、CI/CD 或部署設定、新的相依套件。最低要求：中級全部要求、清單中所有適用部分，以及合併前的第二次獨立審查。

一個人審查：沒有第二位審查者時怎麼辦

獨自工作時，讓檢查獨立於寫程式碼的那個 AI 代理，並寫下哪些部分沒有被審查。團隊指南預設有第二個人：OWASP 要求由作者以外的人核准。獨立開發者無法完全做到，那就盡量接近：

• 用全新的工作階段或另一個 AI 代理做審查，只給它需求和差異，要求它提出有證據的問題，而不是一句結論。
• 對照執行中的系統核實，而不是對照 AI 代理的報告：開啟頁面、重新開啟記錄、確認已部署的版本。
• 高風險改動保持夠小，小到你能逐行讀完。
• 在證據記錄裡把「沒有獨立的人工審查」記為尚未解決的缺口，而不是悄悄跳過。

3. 保存可複查的小型證據記錄

每例記錄：CASE 編號 → REQ/AC → 角色和資料來源 → 精確步驟 → 預期 → 實際 → 狀態 → 通過或失敗證據 → 環境及版本 → 缺口與負責人。

螢幕截圖只能證明可見狀態，不能證明持久化；200 回應不能證明目標物件正確變更；Mock 測試通過不能證明真實相依服務可用。證據必須匹配結論，隱去秘密，只分享給獲准查看的人。

可使用配套 Markdown 範本，或複製下方記錄格式。範本包含九個起始檢查項及可複製的案例記錄；每列是涵蓋提示，不代表整個類別已通過。

• CASE / REQ / AC: ____
• 角色 / 初始狀態 / 資料來源與替代資料許可: ____
• 可重現的精確步驟或命令: ____
• 預期結果與規則來源: ____
• 實際結果: ____
• 狀態（PASS / FAIL / BLOCKED / NOT RUN / N/A）: ____
• 通過證據：產物或去識別化記錄、時間、版本: ____
• 失敗證據：準確差異及產物、時間、版本: ____
• 持久化 / 外部最終狀態讀回: ____
• N/A 理由或剩餘缺口 / 負責人 / 下一步: ____
• 修復前結果 / 修復後結果 / 受影響迴歸: ____
• 最終差異審查證據: ____

4. 合成示範：儲存顯示名稱

以下僅為合成教學示範。輸入和觀察結果均為說明記錄方式而虛構，未在使用者正式專案或任何真實驗收工作階段中執行。

假設已明確約定：移除首尾空白後，顯示名稱允許 1–40 個 Unicode 碼點，使用者只能修改自己的名稱。這只是示例規則，不是通用建議限制。

CASE-NAME-01 / AC-NAME-01：從正常選單開啟個人資料，儲存「River」，重新開啟。預期：名稱仍為「River」，獲准的讀回結果屬於同一帳號。假設觀察：成功提示出現，但重新開啟顯示舊名稱。示範狀態：FAIL。真實執行時應蒐集修改前後畫面、去識別化請求及同帳號同版本的權威讀回證據；本文並未提供這些執行證據。

CASE-NAME-02：嘗試移除空白後為空，以及 1、40、41 個碼點的輸入。按假設規則，空值和 41 應拒絕，1 和 40 應接受。這些僅為規劃案例，狀態 NOT RUN；使用前先核實樣本實際計數，碼點、位元組和使用者感知字元並不相同。

CASE-NAME-03：在授權測試環境用帳號 A 嘗試修改帳號 B。預期拒絕且 B 不變。CASE-NAME-04：中斷儲存，按約定復原規則重試並檢查最終狀態。未使用授權測試帳號和故障條件執行前，兩項均保留 NOT RUN。

完整教學演練（合成資料——不是線上驗收）

上面的案例是計畫清單。下面這一列示範：中等風險「儲存顯示名稱」在真實觀察後，證據表可以長什麼樣。資料均為虛構，只教格式；不是 Boloop 生產證據，也不是任何使用者專案的實測結果。

| 欄位 | 教學填寫 | |---|---| | 範圍 | 僅登入使用者改自己的顯示名稱 | | 風險分級 | 中（既有邊界、無新權限） | | 版本 | 教學 diff demo-name-001（非真實部署） | | CASE / AC | CASE-NAME-01 / AC-NAME-01 | | 角色 / 入口 | 使用者 A / 個人資料選單 | | 步驟 | 開啟資料 → 填 “River” → 儲存 → 再開啟 → 讀回 | | 預期 | 同一帳號讀回為 “River” | | 修復前 / 弱提示 | Toast「已儲存」但讀回仍是 “Old” → 驗收 FAIL | | 修復後（示意） | 持久化後讀回 “River” → 僅本案例 PASS | | 相依 / 安全 | 無新相依套件；第二帳號不得改使用者 A（此處 NOT RUN） | | 未跑測試 | 空值/長度 CASE-NAME-02（NOT RUN）；跨帳號 CASE-NAME-03（NOT RUN） | | 人工決策 | 拒絕合併，直到最終 diff 上 CASE-NAME-01 為 PASS，且 CASE-NAME-03 已跑或書面延期並指定負責人 |

5. 決定哪些部分真正就緒

分別報告儲存庫規範、需求涵蓋和執行階段驗收。約定範圍內仍有 FAIL、BLOCKED 或 NOT RUN 的驗收項，就不能宣稱整體完成。「本次差異未發現可證明的缺陷」只是限定範圍的審查結果，不是無缺陷保證。

失敗後保留證據，區分產品、測試、環境、資料或需求問題。不要削弱斷言、刪除案例或反覆重跑碰運氣。僅在授權範圍內修復，再跑原始案例及受影響路徑，審查最新差異。

用準確交付狀態：已實作、本地已驗證、已部署、真實路徑已驗收。本地驗收不授權部署；部署也不能單獨證明使用者任務可完成。

常見問題

只做程式碼審查，對 AI 生成的程式碼夠嗎？

不夠。程式碼審查能看出差異是否正確、安全，但看不出功能在儲存、重新整理或請求失敗之後是否仍然正常。只要是使用者會用到的改動，兩者都要做。

AI 代理能審查自己寫的程式碼嗎？

可以輔助，但不應該當成最後一道檢查。寫程式碼的 AI 代理可能把同一個錯誤假設帶進審查；OWASP 的 AI 安全驗證標準（AISVS）也明確寫道，AI 代理本身不算人工審查者。請用另一個工作階段審查，並親自核實結果。

怎麼知道 AI 寫的測試真的有效？

讓每個重要測試故意失敗一次：放到修復前的版本上執行，或破壞它保護的那一行，確認它會失敗。再檢查它斷言的是具體結果，而不只是某個 Mock 被呼叫，或沒有拋出錯誤。如果是缺陷修復，如何驗證 AI 生成的缺陷修復逐步說明了修復前後的記錄方式。

審查 AI 生成的 PR，先看什麼？

先看範圍和測試：差異是否符合需求，有沒有測試被刪除、跳過或改動？接著看新的相依套件、權限和密鑰，最後實際執行這個功能。

每一行都要讀嗎？

高風險改動要。低風險改動通常檢查通過、再看一眼結果就夠了。依上面的分級執行，並寫下你選了哪一級。

我不太會看程式碼，還能檢查 AI 做出來的軟體嗎？

可以。檢查你看得到的行為：用白話寫下預期結果，以新使用者身分使用功能，重新開啟儲存過的資料，試試空白輸入和錯誤輸入，再用第二個帳號確認看不到第一個帳號的資料。涉及登入、付款和個人資料時，請找懂技術的人審查。

選擇相關工作流程

• talking-us: 成功規則不明確或產品決策待定：釐清需求，不修改產品。
• write-design-doc: 需求已確認，但 API、資料或狀態契約不清：整理可直接實作的設計。
• test-case: 由需求推導案例。design 用於規劃，validation 用於已授權的現有檢查；模式名不授予修復或替代資料權限。
• bug-fixing: 已有可重現失敗：追蹤首先破壞規則的地方，獲准後修復並驗證相關路徑。
• code-review-multiagent: 對照需求和呼叫端審查最終差異。預設深入 Solo；獨立 AI 代理按風險和宿主能力啟用。
• develop-closed-loop: 將已授權且規格明確的改動推進至實作、測試、修復、迴歸、審查和交付證據。所需配套流程須另行安裝。

已知局限與參考資料

本文是基於六個工作流程套件整理的原創實用指南，不是它們跨模型行為的測試報告。Skill 不提供帳號、瀏覽器、資料、部署存取或權限；單個下載不等於完整合集。部分介面設計分支依賴未打包的外部 frontend-design-lab。

範本用於記錄證據，不能自行發現缺陷。抽樣需要說明等價依據及未涵蓋分支；合成示例不能取代要求的真實業務資料。存取缺失時，保留待驗收狀態，繼續不依賴該條件的安全檢查。

安全基礎可參考 OWASP 關於逐請求權限驗證及在正確可信邊界執行授權的建議：OWASP Authorization Cheat Sheet。基礎可及性檢查及其局限見 W3C WAI Easy Checks。這些參考不意味本清單構成完整稽核。

關於 AI 專屬的審查風險，可參考 GitHub 的 AI 生成程式碼審查指南、Sentry 的審查手冊和 OWASP 安全程式碼審查指南。套件數據來自 Spracklen 等人的論文〈We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs〉（USENIX Security 2025）。「證明測試會失敗」背後的思路，可參考 Stryker 的變異測試文件。

下載 Markdown 範本