為什麼 AI 生成 dashboard 時特別容易犯「塞太滿」這個錯誤，跟生成一般畫面有什麼不同？
一般畫面（例如一個登入頁）通常有明確、有限的元素組成，模型比較容易判斷「這裡該放什麼、不該放什麼」。但 dashboard 的本質是呈現資料，而資料集裡往往有幾十個欄位、幾十種可能的切分方式——每個欄位理論上都能畫成一張圖，模型沒有被告知「哪些欄位是這次真正要看的」，就會傾向把所有能畫的都畫出來，因為漏掉一個可能有用的欄位，看起來比多畫一張不必要的圖表更「有風險」。
這個現象背後的機制是：模型在不確定「使用者真正想看什麼」的情況下，會選擇資訊量最大的輸出，而不是資訊量最精準的輸出，因為前者在表面上看起來更「完整」、更不容易被挑錯。這也是為什麼明確告訴模型「最多顯示幾個圖表、哪些是核心指標」，效果會比單純說「幫我做一個 dashboard」好很多——你等於是替模型先做了「篩選重要性」這個它自己不會主動做的判斷。
為什麼「太多圖表」跟「沒有比較基準」這兩個問題，都需要靠 prompt 明確要求，而不能等模型自己判斷出來？
因為這兩個問題的共通點是：正確答案取決於「使用情境」，而不是取決於「這份資料本身長什麼樣子」。同一份營收資料，給執行長看跟給財務分析師看，該顯示幾張圖表、該不該附上逐月明細，答案完全不同——但模型光看資料本身，沒辦法推斷出「這次是給誰看的」。同樣地，「120 萬營收」這個數字要不要附上比較基準，取決於這份 dashboard 的目的是「快速掃過去確認一切正常」還是「深入分析變化趨勢」，這也是資料本身回答不了的問題。
這代表這類問題不是模型能力不足，而是模型缺少關鍵的情境資訊。解法自然也就不是換一個更強的模型，而是把這些情境資訊講清楚——這次的 dashboard 是給誰看的、目的是快速掃視還是深入分析、核心指標是哪幾個。這些資訊只有使用者自己知道，模型沒有辦法憑空推測出來。
資料幻覺這個問題實際上有多嚴重，具體會怎麼發生？
資料幻覺指的是模型在生成 dashboard 時，編造出看起來合理、但實際上資料裡並不存在的欄位、關聯或計算方式。例如資料裡只有「訂單日期」跟「訂單金額」兩個欄位，模型卻生成了一張「客戶終身價值」的圖表——這個指標聽起來很合理、也是 dashboard 常見的內容，但如果原始資料裡沒有客戶 ID 跟重複購買紀錄，這張圖表的數字很可能是模型自己推算、甚至捏造出來的，不是真的從資料算出來的。
這個問題之所以特別危險，是因為它不會讓 dashboard 看起來「壞掉」，反而會讓它看起來更完整、更專業——正是這種表面上的完整性，讓人更容易放鬆戒心去相信這些數字。實務上建議至少抽樣核對一部分生成出來的數字，直接拿計算機或試算表驗算，確認每張圖表背後真的對應到你提供的原始欄位，而不是模型自己補完的內容；如果 dashboard 会被拿去做重要決策，這道核對工序不應該省略。
如果我不是資料分析背景，這五個 prompt 修法對我來說，哪一個最值得優先學會？
如果你只能先掌握一個，優先學會錯誤五的資料可追溯性修法（要求模型交代每個數字的資料來源）。原因是這個修法的效益不只是解決一個特定問題，還能幫你順便發現前面四個問題——如果你要求模型交代每張圖表的資料來源，一份塞滿了不必要圖表的 dashboard，交代來源這個動作本身就會花更多篇幅、暴露出「這張圖表其實不重要」；一份沒有比較基準的數字，被要求交代來源時也會更容易暴露出「這個數字缺少對照」。
換句話說，「要求可追溯性」這個習慣，某種程度上會反過來逼迫模型自己去精簡內容，因為交代不清楚來源的東西，通常也是不該放進去的東西。這比一開始就要背下五條規則更容易養成習慣，也更容易套用在其他 AI 生成內容的場景，不只是 dashboard。
把一份資料丟給 AI 設計工具、請它生成一個 dashboard，最常見的結果是：畫面上塞滿了圖表，卻看不出哪個數字真正重要。這不是工具做得不好，而是語言模型在處理「請幫我做一個 dashboard」這種開放式指令時，傾向把所有能畫的東西都畫出來——因為模型沒有被明確告知「哪些是次要細節、哪些才是真正要看的重點」，只好選擇最保險的做法：全部呈現。這篇整理五個最常見的具體錯誤，以及每一個錯誤對應的 prompt 層級修法，而不是重新設計整個流程。
模型會試著把資料裡能畫的每一個維度都畫成一張圖，結果是十幾張圖表擠在同一個畫面裡，讀者不知道該先看哪一張。修法是在 prompt 裡明確設定圖表數量上限，並要求先決定哪些是核心指標、哪些是次要細節，把細節延後到第二層畫面才顯示，例如：「最多顯示 5 個圖表，先列出這次要追蹤的核心指標，其餘資料點放進可展開的詳細檢視，不要放在第一畫面。」
如果沒有特別要求，模型的預設傾向是直接跳去畫完整圖表，而不是先給幾個一眼能看懂的關鍵數字。修法是明確要求先產生一列 KPI 卡片，並指定要有趨勢指標：「最上方先顯示 3 到 5 張 KPI 卡片，每張卡片包含當前數值與相對於上一期的變化方向，圖表放在 KPI 卡片下方。」
模型有時候會選擇視覺效果比較搶眼、但其實不適合這份資料的圖表類型——例如把只有三、四個項目的資料硬做成圓餅圖，或是把時間趨勢畫成長條圖而非折線圖。修法是直接在 prompt 裡指定圖表類型跟對應的資料性質：「類別比較用長條圖，時間趨勢用折線圖，圓餅圖或甜甜圈圖只在資料分成 3 到 5 個部分時使用，超過 5 個部分一律改用長條圖。」
一個單獨的數字（例如「本月營收 120 萬」）本身沒有意義，讀者不知道這個數字是變好還是變差。模型如果沒被要求，往往只會顯示當下的快照數字。修法是明確要求每個指標都要附帶比較基準：「每個指標都要同時顯示環比（跟上一期比）與年比（跟去年同期比），沒有比較基準的數字一律不要單獨呈現。」
這是最需要小心的一項——模型有時候會「捏造」看起來合理但實際上不存在的欄位、或是把不存在的資料關聯畫出來，讓 dashboard 看起來完整，但底層資料其實對不上。修法是要求模型只使用明確提供的欄位，並在生成後主動要求它交代每個圖表的資料來源：「只使用我提供的欄位，不要新增或推測任何欄位；每張圖表下方標註這個數字是從哪個欄位計算出來的，如果某個資料點無法從我提供的資料推導，直接說明缺少什麼，不要用合理的猜測填補。」
如果你正在用 Claude Design 這類工具快速生成內部使用的 dashboard，這五個修法不需要一次全部套用，可以先從最容易出問題的那一項開始——如果你發現生成的畫面總是塞了太多圖表，先套用錯誤一跟錯誤二的修法；如果你是要拿這份 dashboard 去做決策簡報，錯誤五的資料可追溯性修法優先順序應該最高，因為一個看起來很完整、但底層資料是幻覺出來的 dashboard，比一個明顯不完整的 dashboard 更危險——後者至少知道自己不能信，前者會讓人誤以為可以信。