當我在管理缺陷時，最難的問題往往不是如何重現一個 bug 或找出它的根本原因。有時候難的是：當好幾個問題都真實存在、而時間與資源有限時，要決定哪一個缺陷值得先被處理。一個 AI 助手可能憑空捏造退貨政策、未經確認就行動、回應得太慢，或者消耗好幾倍於預期的預算。這些全都是缺陷，但它們造成的後果不同，也不應該自動獲得相同的優先順序。

常見的錯誤是把嚴重度（severity）與優先順序（priority）當成可以互換的東西。嚴重度描述的是缺陷發生時後果有多嚴重；優先順序決定的則是團隊該多急著處理它。當 AI 輸出是機率性的、而缺陷無法隨叫隨到地重現時，這個決定變得更難，因為證據可能不完整。我需要問兩個實務問題：如果這件事發生，最壞的可量化後果是什麼？以及在真實流量下，它多久會發生一次？ 一旦影響與可能性被一致地記錄下來，排序就變成一個其他人可以審查的決定，而不是一場誰嗓門大的比賽。

1. 嚴重度不是優先順序

我用四個嚴重度等級來描述缺陷的後果。

• 等級 4：不可逆或高後果的行為，例如向客戶超額收費，或放任 AI 助手做出超出其權限的行動。
• 等級 3：可復原、但仍需要人工介入的問題，例如助手捏造了一條退貨期限條款，而客服人員必須逐案更正。
• 等級 2：使用者可以自行繞過的體驗降級，例如回應比預期慢，但最終仍給出正確答案。
• 等級 1：不會實質影響結果的外觀問題或文案問題。這些等級描述的是失敗的影響，而不是它發生的頻率。

可能性是另一個獨立的估計，分成三個區間。高：幾乎每次遇到相關條件時缺陷就會發生；中：它出現在特定意圖、特定輸入或特定客群中；低：它需要相當少見的條件組合才會出現。

舉例來說，一個幻覺出來的退貨政策，如果只出現在某個特定商品類別，它的可能性可能是「中」；而一個反應變慢的問題，在尖峰流量時可能是「高」。一個嚴重度 4 的缺陷，不應該只因為難以重現就被降成低優先：如果它可能造成一次未經授權的金流行為，它最壞的合理後果仍然存在。在本篇產出物的分類規則（triage rules）中，嚴重度 4 一律直接給 P0，不論估計的可能性；其他缺陷則用影響與可能性一起排序，並記錄下證據與假設。

2. AI 功能特有的缺陷類別

UI、API 與整合失敗這些傳統缺陷分類仍然有用，但 AI 功能帶來了需要另行分類的行為性失敗。

• 幻覺（hallucination）：斷言了不實的內容，例如捏造一條退貨期限條款。
• 偏見（bias）：對不同族群套用了不一致的標準，例如同一個退款請求，因為使用的語言不同而得到不同的處理。
• 越權（over-reach）：助手採取或宣稱了一個超出其權限的行動，例如未經確認就建立退款請求。
• 成本暴增（cost blowout）：回應是正確的，但消耗了好幾倍於預期的預算，也許是因為模型生成了一個不必要的長答案。
• 延遲回歸（latency regression）：答案正確，但是晚到超過可接受的等待時間，使用者可能早已放棄這場對話。

分類幫助我有系統地調查一個缺陷，而不是把每一個意外回應都當成籠統的「AI 問題」。如果 Aurora Shop 的助手在核准政策只允許 14 天的情況下，捏造出一條 30 天的退貨政策，我會把觀察到的失敗分類為幻覺，並把回應與權威的政策來源比對。如果助手在缺少必要確認的情況下建立了退款請求，我會把這個行為分類為越權，並去調查動作流程、權限與確認機制。這些分類引導根本原因的調查，但它們不是根本原因的證明：一個幻覺可能源自過期的檢索資訊、相互衝突的指令，或某個其他服務提供的錯誤上下文。類別描述的是哪裡錯了；為什麼錯，必須靠調查來建立。

分類規則（Triage Rules）

這張表把前面的原則變成一張可審查的分類表，欄位涵蓋缺陷 ID、類別、嚴重度、影響、估計可能性、優先順序、決定與依據。例如 A-101 是一個未經確認就建立退款請求的越權缺陷；它的嚴重度是 4、優先順序是 P0，即使它的可能性被估為「低」，決定是修復缺陷，並以停用自動送出的方式降級這項危險能力。A-102 捏造退貨期限，得到 P1 與「修復」的決定；A-103 則把成本暴增與「接上斷路器」的行動配在一起。

剩下的例子分別是一個被導向備援的延遲回歸，以及一個需要修復加上留案文件的語言相關偏見缺陷。排序規則是明確寫死的：嚴重度 4 一律 P0，不論可能性；其他缺陷按「影響 × 估計可能性」排序，平手時偏向涉及金錢、安全或合規的問題。每一筆可能性估計都必須指出它的證據來源——例如日誌抽樣、黃金集，或某次探索性測試——否則就標記為「未估計」。這樣，審查者就可以去質疑排序背後的證據與假設，而不是只爭論優先順序的標籤本身。

3. 分類必須推動一個決定

缺陷分類只有在引出決定時才有用。我使用四種可能的行動：修復、降級、切換備援，或接受並留案。

• 修復：排定修正工作，附上重現步驟、證據，以及明確的驗收條件。
• 降級：暫時停用或限制那項危險能力——例如關閉自動發起退款，同時保留一般客服回應。
• 切換備援：把受影響的意圖導向更安全的替代方案，例如基於規則的回覆，或轉人工。
• 接受並留案：明確記錄這個缺陷目前不修，連同日期、原因，以及什麼條件成立時會重新打開它。

以三個 Aurora Shop 的缺陷為例。助手捏造了退貨政策，團隊排定修復，並加進一條以核准政策比對答案的迴歸測試。另一個缺陷允許在沒有確認的情況下建立退款請求；因為後果更嚴重，團隊在確認流程驗證通過之前，先停用了那個自動動作。還有一個延遲回歸影響的是風險較低的詢問，團隊在調查效能問題的同時，先把該意圖導向較短、較可預測的回應。每一個決定處理的風險都不同。重點不是每個缺陷都必須立刻修好，而是每個缺陷都需要一個站得住腳的下一步動作，而不是待辦清單上一個任意擺放的位置。

排好序的佇列，不等於被證實的根本原因

弱點是明擺著的。可能性是估計出來的，而估計會隨流量、模型版本與使用者行為的變化而漂移。這些類別也把現實過度簡化了：一個幻覺可能同時造成成本暴增，一個越權缺陷可能同時帶來合規風險。保留「接受並留案」這個區間，可以防止佇列無限成長，但如果被接受的缺陷被遺忘、或它們的後果發生了變化，它就是高風險的。因此，分類需要定期回顧、可追溯的證據，以及重新打開一個決定的明確條件。影響 × 可能性是一個有紀律的工作排序方法，但它不是根本原因分析的替代品，也保證不了「最重要的缺陷已經被正確理解」。