Edge Case

邊角案例是什麼，跟「一般的錯誤」或「bug」有什麼不同？

邊角案例指的是發生在正常參數邊界或極端值的情況——例如一個只設計來處理三到五個項目的清單，突然被塞進一千筆資料；一個假設使用者會依序填寫表單的流程，卻遇到使用者用瀏覽器的自動填入功能一次性填滿所有欄位。這些情況的共通點是，它們發生在「典型使用情境」的邊界之外，設計或開發過程中如果只以最常見的情境為基準，這些邊界情況很容易被忽略。

邊角案例跟一般的 bug 不同，bug 通常是「程式碼寫錯了」，邊角案例則是「程式碼寫得完全正確，但沒有人事先想過會發生這種情況」。也就是說，邊角案例不是執行上的失誤，而是設計階段的思考範圍沒有涵蓋到某個真實會發生、只是不常發生的情境。

為什麼邊角案例值得花時間去特別處理，即使它們發生的機率很低？

因為邊角案例的影響力，通常跟它發生的機率不成比例。一個只有百分之一機率會遇到的情況，如果沒被處理好，造成的後果可能是資料遺失、介面完全卡死、或是使用者完全搞不清楚發生了什麼事——這種嚴重後果，遠遠不是「發生機率低」這件事能抵銷的。而且邊角案例往往不是隨機分布在所有使用者身上，而是集中出現在特定族群，例如視障使用者、網路連線不穩定的使用者、或是資料量特別大的重度使用者，這些人正是最需要產品可靠運作、卻也最容易先撞到邊角案例的族群。

另一個常被忽略的原因是，邊角案例的發生時機通常跟一般測試的時機不一致。日常測試多半在正常工作時間、網路穩定、資料量適中的情況下進行，但邊角案例往往是在使用者最疲憊、最急迫、環境最不理想的時候被觸發——半夜的緊急操作、訊號不穩的通勤路上、或是連續操作導致的意外重複點擊。這些正是使用者對產品觀感形成得最深刻的時刻，如果邊角案例在這時候讓介面看起來「壞掉」，造成的信任損傷會遠大於平時。

實際上要怎麼系統性地找出一個設計裡可能存在的邊角案例，而不是靠運氣碰到？

最基本的方法是針對每一個輸入或互動點，主動去想「這個欄位或這個動作的極端值是什麼」——資料可以是空的嗎、可以極端長或極端多嗎、使用者可以連續快速操作嗎、網路可以在操作中途斷線嗎。這種思考方式本質上是把「正常情境」的假設拿掉，去問「如果不是這樣呢」，針對每一個假設反過來想一次。

更系統性的做法，是分析既有的客服工單跟使用者回饋，這些紀錄裡經常藏著已經真實發生過、但沒被納入原始設計考量的邊角案例；也可以主動用不常見的使用族群跟極端情境去測試，例如網路速度刻意調慢、輸入超長文字、快速連續點擊同一個按鈕。近年也有 AI 測試工具，能透過分析應用程式結構跟過去的使用數據，自動推測可能的邊角案例組合，例如描述一個登入流程後，工具會自動生成空白帳密、特殊字元密碼、超長使用者名稱、併發登入等測試情境，用來輔助人工測試容易遺漏的部分，而不是取代人工判斷。

如果我用 AI 設計工具生成原型，怎麼確保邊角案例有被考慮到，而不是等到工程團隊接手才發現？

最直接的做法是在生成 prompt 裡明確要求。AI 生成內容時，如果沒被特別要求，傾向只呈現「快樂路徑」——也就是一切都順利進行的理想情境，因為這是訓練資料裡最常見的樣式。要讓 AI 主動考慮邊角案例，可以在 prompt 裡明確列出想涵蓋的極端情況：資料是空的時候畫面該長什麼樣子、載入中的狀態、操作失敗時的錯誤訊息、使用者連續點擊時該怎麼防呆。

生成完之後，也可以直接請 AI 反過來檢查自己的產出：問它「這個設計可能會在什麼情況下出問題」，這個提問本身常常能揭露一開始沒被想到的邊角案例。這個習慣的價值不只在於補齊細節，更在於把「這個東西可能在什麼情況下壞掉」這個問題，從工程團隊接手後才第一次被問，提前到原型階段就先被問過一輪，讓後續交接時要處理的邊角案例大幅減少。