如何驗證 AI 生成的缺陷修復

驗證 AI 生成的修復，要證明原始故障在修復前能被偵測到，修復後消失，且相關路徑沒有被破壞。記錄準確版本、輸入、實際觀察和剩餘缺口。建置成功是有用證據，但不足以證明所報缺陷已經修復。

先寫一個可驗證的結論

評估修補前，寫清預期行為，例如：「獲授權的使用者儲存欄位並重新開啟記錄後，應讀到已儲存的值。」同時記錄角色、正常入口、輸入、環境和版本。若正確規則仍有爭議，先解決產品決策。

明確本次範圍：診斷、驗證、修改程式碼、修改測試、修復歷史資料和部署是不同操作。要求驗證，不等於授權所有操作。執行前閱讀儲存庫規則，並檢查測試命令的副作用。

1. 保留修復前的失敗

保存原始步驟及實際結果。檢查必須斷言所報症狀，不能只判斷是否收到回應。瀏覽器故障應從使用者的正常頁面和角色出發，內部 API 呼叫不能替代完整使用者路徑；純 API 或背景工作故障則在對應執行邊界驗證，無需硬加瀏覽器步驟。

條件允許且安全時，在隔離環境對已知有缺陷的版本執行同一迴歸檢查，保留命令、版本、輸入、預期和輸出。縮小案例可以幫助診斷，但最終必須保留原始完整路徑。不要為了得到一個失敗測試，在正式環境重播破壞性行為。

2. 將修復與原因連起來

沿真實路徑檢查：入口、驗證或轉換、儲存或外部操作、讀回及使用者結果。找出第一個違反已確認規則的邊界。合理解釋或一行程式碼變更，在觀察支持之前仍只是推測。

審查最終差異，確認修復落在負責該規則的層，同時查同一原因的其他影響及同類錯誤位置。避免無關重構。程式碼修復不會自動修正已有錯誤資料，歷史資料修復須另行明確範圍及授權。

3. 修復後重走原始路徑

在修復版本上使用相同的相關輸入、角色和條件，記錄必要差異。重跑原始完整情境和迴歸檢查。儲存類問題要重新整理或重新開啟，並核對權威讀回結果；成功提示不夠。拒絕類操作還要確認沒有發生禁止的寫入或外部副作用。

不要把本機結果寫成已部署。分別記錄已實作、本機驗證、已部署及正式環境路徑驗收。審查後若修補再次修改，應在最終版本重跑受影響檢查。

4. 按原因選擇迴歸路徑

根據故障機制選檢查，不湊固定案例數量：

• 共用驗證：合法輸入、相關邊界及拒絕行為
• 權限：允許的角色及適用的被拒角色或資源，包括副作用
• 持久化：儲存、讀回、重新開啟及適用的舊狀態問題
• 非同步行為：相關重試、取消、重複或亂序路徑
• 共用呼叫：使用被修改規則的其他入口

只有實作、資料繫結及失敗條件確實等價時才重用證據。頁面長得相似，不代表等價；未檢查的獨立分支仍是缺口。按儲存庫要求和變更影響執行 lint、建置、整合或端對端檢查。審查最新差異，缺少獨立審查時如實說明。

合成示範：儲存成功，重新整理後舊值回來

這是虛構教學情境，不是 Boloop 事故，也未實際執行。

假定已確認的需求是：授權的個人資料編輯必須持久化。修復前計畫按正常入口開啟資料、修改欄位、儲存、重新整理，再比較回傳欄位。對同一記錄及時間線保存請求和權威讀回。不要因為重新整理暴露症狀就認定快取是根因。

提出修復後重走上述路徑，補充相關拒絕儲存檢查；若有其他入口使用被修改規則，也應檢查。觀察前所有結果均保持 NOT RUN。本例提供驗證計畫，不提供已證實的根因、修補或成功結論。

Boloop 真實案例：六秒逾時被誤判為 Google 查詢失敗

2026 年 10 月 20 日，Boloop 的統計郵件能讀取網站地圖，卻無法傳回六個頁面的索引檢查。頁面如實顯示檢查暫不可用。這說明查詢失敗，不能解釋為 Google 收錄了零個頁面。

第一步是找出請求在哪裡停止。對照使用同一個唯讀帳號與相同六個 URL：

• 原截止時間下，六個請求均在約 6,002–6,011ms 被取消，例外為 AbortError。
• 暫時延長診斷截止時間後，相同六個請求在約 7,042–7,907ms 傳回 HTTP 200。

這組觀察支持「本機逾時過短」是本輪故障的直接原因，不能證明過去每一次供應商失敗都來自同一原因。本次對照也沒有提供需要擴大 Google 權限的證據。

修復範圍很小：只給 URL Inspection 設定獨立的十五秒截止時間。權杖、GA4、搜尋表現與網站地圖仍維持六秒；六個檢查繼續平行執行，回應大小限制、部分結果、快取及唯讀權限維持。沒有增加自動重試，也沒有提交頁面索引。

關閉修復前，分別檢查三種結果：

• 八秒後正常傳回的檢查，能取得全部六頁結果。
• 始終不傳回的檢查，十五秒後仍會取消，並保留已經成功的網站地圖結果。
• 其他報表仍在六秒截止。

這些自動回歸使用模擬供應商回應與測試時鐘，用於驗證逾時行為，不是對 Google 當前速度的測量。八秒回應的回歸在舊實作中失敗，修後通過；本次整理案例又重跑了該檢查與不傳回時的截止檢查。

真實供應商讀回另行驗證：修後的呼叫耗時 8,188ms，傳回六頁結果。經授權部署後，正常正式後台也顯示全部六列。英文首頁當時已收錄，其餘固定頁面被 Google 回報為未知。修好查詢本身並沒有讓這些頁面自動收錄。

這個案例支持一個有邊界的結論：本輪觀察中，過短的本機截止時間拒絕了有效回應，獨立截止時間恢復了檢查。它不證明普遍效能提升，不保證供應商以後一直可用，也不證明部署後的排程郵件已經正常執行；這些結果需要另行觀察。

複用這個方法時，先寫清原始症狀、首個失敗邊界、修復前後證據與相鄰失敗路徑，再用下面的結果範本分別記錄本機回歸、真實供應商讀回與正式環境驗收。

驗證失敗或無法執行時

• 原始症狀仍存在：記為 FAIL，回到診斷；不要降低預期以換取通過
• 缺少權限、資料或環境：記為 BLOCKED，寫清前置條件及下一步
• 計畫檢查尚未嘗試：記為 NOT RUN，不是 PASS 或 N/A
• 間歇故障：記錄嘗試次數、失敗次數、時序條件和不確定性；一批未失敗樣本不能證明問題消失
• 無法重現原始故障：保留記錄、輸入及暫定根因，尋找獨立支持證據；沒有對缺陷敏感的迴歸訊號時，停在診斷，不聲稱修復已驗證

Mock 可隔離機制，不能證明未觀察的真實系統結果。未經許可不要用合成資料替代實際驗收資料。分享證據前移除金鑰和個人資訊。

何時可以停止

只有最終版本的原始情境及適用受影響路徑都有對應證據、必要檢查和審查完成，且沒有使結論失效的未解決缺陷，才可關閉該範圍的驗證。保留剩餘限制和最短復原方式。只通過一部分，就只能對那部分作結論。

重要前置條件缺失時，停止依賴它的工作並說明如何解除阻塞。證據充分後，也不要重複增加無法改變結論的檢查。目標是有邊界、可解釋的結果，不是無限增加綠色測試數量。

記錄結果並開始下一步

配套 Markdown 結果範本可記錄前後證據、迴歸、審查、狀態邊界及復原。

已有故障從 $bug-fixing 開始；最終差異的獨立唯讀審查用 $code-review-multiagent；按確認需求執行獲授權驗證時，明確選擇 $test-case 模式。這些是流程說明，不提供權限或執行工具。

現在先填寫預期行為、已知有缺陷的版本和原始重現步驟，再請 Agent 判斷修復是否成立。

對應 Skill 頁面：bug-fixing · code-review-multiagent · test-case

下載 Markdown 範本