用可驗證假設除錯

提出修正前，先描述失敗

有用的除錯請求會說明預期行為、觀察結果和受影響範圍，並提供版本、相關輸入和錯誤。將記錄檔提供給 AI 工具前，先移除存取憑證與私密紀錄。

「匯出壞了」幾乎沒有方向。更好的描述是：「匯出在本機成功。最近部署後，在預備環境中，相同主管請求回傳 403。其他路由仍然正常。」

這段描述不能確立原因，但指出了能引導調查的差異。

保留多種可能解釋

請代理程式提出少量合理原因，以及各自證據。不要要求它認定第一個有說服力的解釋。

對虛構匯出失敗而言，可能原因包括服務身分缺少權限、角色對應改變，或請求送到錯誤環境。每種解釋會預測不同證據。

表格是起點。403 回應可能來自不同層。假設應用程式授權失敗前，先找出是哪個元件產生回應。

選擇安全觀察

從能以低成本區分解釋的觀察開始。比較已部署版本與不含機密值的設定，檢查相關錯誤和請求識別碼。可行時，在獲授權測試環境重現問題。

不要只是為了看看錯誤會不會消失，就授予廣泛權限。這會改變安全邊界，也可能掩蓋真正缺少的權限。如果遮蔽敏感資訊的錯誤訊息與請求路徑已足夠，就不要把正式環境完整記錄檔貼給模型。

說明哪些證據會削弱每項假設。這能幫助代理程式修正解釋，而不是替第一個答案辯護。

一次修改一個原因

證據指向可能原因後，進行聚焦修正。避免同時改權限、升級函式庫及重寫處理函式。否則即使症狀消失，也無法知道哪項變更有效。

驗證原本失敗的條件，也檢查鄰近邊界。如果修正主管存取權，應確認未授權使用者仍遭拒絕。

對反覆出現的缺陷，在能偵測它的層加入迴歸檢查。單元測試無法偵測所有部署設定錯誤；有些失敗需要整合檢查，或受控的部署後驗證。

沒有新證據時，停止重複嘗試

代理程式可以產生許多修正變體，但更多嘗試不一定改善診斷。如果相同失敗反覆出現，應問下一次嘗試會提供什麼新觀察。

為不確定的調查設定時間或嘗試次數上限。到達上限時，回報目前證據、已排除假設和尚未解決的問題。這份紀錄能讓其他人接續，不必重做相同實驗。

復原後，記錄原因，以及讓問題進入受影響環境的條件。修正移除眼前缺陷，有用的後續行動則降低相同失敗再次發生的機會。