AI Design Hallucination

AI 設計幻覺是什麼，跟一般「AI 生成的設計不夠好」有什麼不同？

AI 設計幻覺特指生成結果裡出現了「看起來很合理，但實際上站不住腳」的具體元素——可能是一個引用了不存在的圖示庫名稱、一個宣稱符合某個無障礙標準但實際違反該標準的互動模式，或是一段看起來能運作但背後邏輯根本兜不起來的狀態切換流程。這跟「設計品質不夠好」是兩個不同層次的問題：品質不夠好是美感或細節的落差，使用者一看就知道哪裡需要改；設計幻覺的問題在於它的「自信程度」跟「正確程度」不成比例——輸出看起來完全沒問題，缺陷藏在表面底下，需要額外驗證才會發現。

這個概念借用了大型語言模型「幻覺」（hallucination）的既有定義——模型生成了語氣確定、但內容錯誤的文字——只是把這個現象套用到視覺與互動設計的輸出上。

為什麼會出現 AI 設計幻覺，它解決或對應了什麼背景問題？

「幻覺」不是設計 AI 刻意要犯的錯，而是生成式模型運作方式的副產物。模型在訓練過程中學到的是「什麼樣的設計描述通常搭配什麼樣的視覺或程式碼模式」的統計關聯，而不是「這個元件在這個框架裡實際存不存在」的事實查核機制。當 Prompt 描述的情境在訓練資料裡不夠常見，或要求的元件組合是訓練資料裡沒出現過的新鮮組合，模型仍然會依照統計上最接近的模式產生一個答案，而不是回答「我不確定」或「這個元件可能不存在」。

這個現象之所以值得特別命名與討論，是因為設計與程式碼輸出的幻覺比純文字幻覺更難察覺——文字幻覺通常可以直接用搜尋或查證來比對事實，但一個視覺上合理、程式碼語法也正確的元件呼叫，往往要等到實際整合進專案、執行到那一行才會爆出錯誤，中間拖延的時間成本比文字幻覺高得多。

AI 設計幻覺具體會以哪些形式出現，各自怎麼辨識？

常見的三種形式：第一種是「幻覺式元件引用」——輸出的程式碼或規格裡引用了一個聽起來很合理、但在指定的設計系統或元件庫裡根本不存在的元件名稱（例如引用一個該框架沒有的 <Stepper variant="compact">），這種最容易在實際整合時被發現，因為程式會直接報錯。第二種是「幻覺式標準聲明」——輸出聲稱自己符合某個無障礙或設計規範（例如 WCAG 的某個等級），但實際檢查對比度或結構後發現根本不符合，這種比第一種更難察覺，因為沒有明顯的錯誤訊息，只有實際用檢測工具跑過才會發現。第三種是「幻覺式互動邏輯」——描述了一個看起來合理的狀態切換流程（例如「點擊後進入編輯模式，再次點擊儲存」），但沒有處理邊界情況（如果使用者在編輯模式切到別的頁面怎麼辦），這種通常要到實際測試邊界情境時才會暴露。

辨識的共同原則是：不要只看輸出「讀起來順不順」，要針對每個具體宣稱（這個元件存在嗎、這個標準真的符合嗎、這個流程的邊界情況處理了嗎）做逐項核實，而不是整體憑感覺判斷。

對讀者實際有什麼影響，使用 AI 設計工具時該怎麼應對？

最直接的影響是時間成本的轉移：如果不特別留意設計幻覺，省下的生成時間可能全部賠在後面的除錯與驗證上，尤其是幻覺式標準聲明這種沒有明顯錯誤訊息的類型，很可能一路上線到使用者投訴才被發現，屆時修正成本遠高於在生成階段就抓到。

實際應對方式有三個層次：第一，對任何「宣稱符合某個外部標準」的輸出（無障礙等級、瀏覽器相容性、效能數字），一律用對應的檢測工具實際跑一次，不要只看輸出文字描述；第二，對任何引用了特定元件或 API 名稱的程式碼輸出，先在該框架的官方文件或程式碼庫裡確認這個名稱真的存在；第三，對涉及狀態切換的互動邏輯，主動測試至少兩個邊界情境（使用者中途離開、使用者快速重複操作），而不是只測試「正常路徑」。這三步都不是否定 AI 設計工具的價值，而是把它當成一個產出速度很快、但需要人工驗證的協作者，而不是一個可以盲目信任的最終決定者。