找到缺陷只是工作的一半。當另一個人——開發者、QA 工程師、產品負責人，或幾週後回來查看該問題的人——能夠理解發生了什麼並獨立重現它時，這個缺陷才真正變得有用。一份好的缺陷報告應該保留足夠的上下文，讓原始測試者不需要站在下一個人身旁解釋他們所看到的情況。

1. 讓修復可獨立驗證的五個要素

一個可重現的缺陷始於重現步驟，它描述了從已知起點到故障的最短可靠路徑。「篩選功能不能用」會讓下一個測試者自行猜測；報告應該指出觸發問題所需的設定、輸入、操作和順序。目標不是記錄每一次點擊，而是消除各種假設，讓另一個人能沿著相同的路徑到達相同的狀態。

接下來是環境與版本，然後是預期結果與實際結果。在 staging 環境發現的缺陷，可能在 pre-production 環境中消失，或在部署另一個版本後表現不同，因此報告應該說明觀察是在哪裡、哪個版本上進行的。預期與實際結果則清楚確立矛盾所在：需求、設計或既有行為所說的應該發生的事，與測試者實際觀察到的情況之間的對比。

最後，證據與影響範圍把一個觀察轉變為可以調查的東西。截圖、錄影、請求／回應資料、主控台錯誤、時間戳記、日誌或相關記錄 ID 可以記錄發生了什麼，而影響範圍則說明缺陷是影響單一輸入、單一角色、單一瀏覽器、單一工作流程，還是可能影響整個功能。這五個要素共同構成一個重要的 QA 測試，用以檢驗報告本身：如果原始回報者不在場，其他人能否正確驗證這個修復？

2. 記錄不穩定（Flaky）與無法重現的缺陷

並非每個缺陷都會穩定地出現故障。某個功能可能在多次嘗試中只失敗一次、重新整理後就消失、只在特定操作順序後才發生，或在首次觀察到之後就再也不出現。與其簡單地標記為「無法重現」，報告應該記錄已知的一切：發生頻率、環境與版本、故障發生前緊接著的操作，以及成功與失敗的嘗試之間有任何差異之處。

當故障無法穩定觸發時，證據變得格外重要。即使 QA 之後無法重現它，螢幕錄影、網路請求、時間戳記、主控台錯誤和日誌仍能保留當時發生的情況。寫下「在 staging 版本 X 上觀察到一次；後續十次嘗試皆未重現」比把問題稱為隨機問題更有用，因為它同時記錄了缺陷本身以及圍繞它的不確定性。

3. 描述與分類 AI 缺陷

AI 缺陷需要按照實際出了什麼問題來分類。內容錯誤包括幻覺或對政策的錯誤陳述，應該記錄輸入、可用的上下文、生成的回應，以及正確的預期行為。延遲問題應記錄可量測的回應時間，而不是籠統地說 AI 很慢；成本異常則可以找出某些特定對話的資源消耗（例如 token 用量）相較於類似互動意外暴增的情況。

行為不穩定是指同等的輸入在相近條件下產生了實質上相互矛盾的結果，例如同一個問題得到兩個在某個重要事實或動作上不一致的答案。僅措辭不同並不一定是缺陷，因為生成式 AI 本來就會使回應產生變化；關鍵在於語義或所需行為是否改變。因此，一份有效的 AI 缺陷報告應保留提示詞、上下文、條件、重複執行的結果以及故障類型，讓另一個人能夠調查該行為，而不是試圖從單一截圖重現它。

缺陷報告範本

標題：<模組> 在 <條件> 下 <錯誤行為>，導致 <影響>
環境與版本：<環境>／<服務版本>／<模型與提示詞版本>／<資料快照日期>
前置條件：<帳號、資料狀態、開關設定>
重現步驟：1. … 2. … 3. …
期望結果：
實際結果：
證據：<截圖／日誌片段／請求與回應／對話 ID>
影響範圍：<受影響的功能、情境與範圍>
頻率：<每次／間歇；n 次中出現 m 次>
驗證方法：<修好後要跑哪條案例、看哪個指標>
歸類：<資料／提示詞／模型／工具／成本／效能>

Aurora Shop 範例缺陷報告

標題：AI 客服在退款諮詢情境下提供錯誤的 30 天退貨政策

環境與版本：Aurora Shop Staging / Customer Support Service v2.8.4 / AuroraAssist-3B，Prompt v1.14 / 資料快照：2026-09-25

前置條件：客戶帳號 QA-CUST-1042；已出貨訂單 AS-84721 於 18 天前送達；Aurora Shop 退貨政策允許出貨後 14 天內退貨；AI 客服開關 ai_support_v2 = ON

重現步驟：

1. 使用扮演客戶 QA-CUST-1042 的測試帳號登入。 
2. 針對訂單 AS-84721 開啟 AI 客服對話。  
3. 提問：「這筆訂單我已在 18 天前收到，還能退貨退款嗎？」  
4. 觀察助理的回應，並與現行的 14 天退貨政策比對。

期望結果：
助理應說明該訂單已超過 14 天退貨期限，且不應聲稱客戶符合標準退貨資格。它可以提供 Aurora Shop 政策所定義的核准升級管道或支援選項。

實際結果：  
助理聲稱 Aurora Shop 接受 30 天內退貨，並告訴客戶該訂單仍符合退款資格。

證據：對話 ID：CONV-QA-92841；截圖 refund_policy_wrong_response.png；來自 /api/support/conversations/CONV-QA-92841/messages 的回應顯示：「您可以在出貨後 30 天內退貨。」

影響範圍：面向客戶的出貨後退貨諮詢 AI 支援。可能影響詢問出貨超過 14 天但未滿 30 天訂單的客戶，導致其對退款資格產生錯誤預期。

頻率：每次；使用相同訂單狀態的新對話，5 次中重現 5 次。

驗證方法：重跑 AI-RETURN-014——使用 14 與 15 天的邊界值驗證「拒絕超過 14 天期限的退貨請求」。確認政策準確度指標記錄了正確的退貨期限，且重複對話不會產生相互矛盾的資格判定。

歸類：提示詞／模型——政策資訊錯誤（幻覺）

這份範本讓其他人更容易重現並驗證缺陷，但它無法取代 QA 工程師的判斷。發生頻率應有足夠的嘗試次數支持才有意義，對於不穩定的缺陷尤其如此；而資料、提示詞、模型、工具、成本或效能等分類，起初都應視為假說，而非已確認的根本原因。詳細的範本也有其成本，因此每個欄位都應提供有用的證據，而不是把報告變成文書作業。

報告完成後，缺陷可能也會呈現出與最初觀察不同的面貌。一個錯誤的 AI 回應起初看似模型或提示詞的問題，但證據最終可能指向過時的資料、相互衝突的政策來源、整合失敗，或另一個服務提供了錯誤的上下文。缺陷報告應描述 QA 能夠證明的事實；調查過程才負責找出它為何發生。