Fable 5.2 設計展示怎麼看？31 張卡片、元件清單與互動驗收
Dom 的 Fable 5.2 設計影片展示 31 張元件卡片。本文整理 shadcn/ui 同類盤點，以及獨立 Opus 5.5 名稱清單實驗，說明 12 與 27 的口徑、限制與可操作的互動驗收方式。
一段元件展示影片裡，輸入框、通知與聊天氣泡輪流變動，看起來像整套 App 已經完成。但看見畫面有這個元件，和它能接上資料、處理失敗，是不同的驗收。
Dom 在 2026 年 11 月 10 日發布的設計影片，用「Fable 5.2 真的會設計」介紹作品。這是作者對製作工具與成果的說法，原貼文沒有提供可以直接重跑的完整提示詞。
影片值得參考的地方，是它把拆帳 App 需要的介面放到同一張展示表。把元件一項項叫出名字，就能開始檢查 AI 有沒有交齊。
我建議先借它建立需求清單，再把每一項加上操作與失敗條件。這比從一段成品影片直接判定某個模型全面擅長設計，更能用在自己的專案。
31 張卡片，為什麼又會數成 29 種？
本站在 11 月 11 日逐張盤點影片的固定版面，共辨識 31 張卡片。因為部分卡片屬於同一種元件，去重後整理成 29 種，用於後續的涵蓋率評分。
再和當天的 shadcn/ui 官方元件清單對照，31 張卡片中有 25 張找到同類。shadcn/ui 是可取用與修改的介面元件資源。「有同類」指用途或模式相近，沒有表示作者直接抄用套件。
另外六張是兩個數字加減控制、語音播放器、倒數計時、星星評分與步驟清單。這個判定限於當次清單，也把用途相近的邊界案例算成「有」。沒有列出專屬頁面，不代表這些功能不能自行組合出來。
例如，Attachment 文件描述的是檔案或圖片附件及上傳狀態，Message 文件描述對話訊息，不能只看到「附件」或「訊息」就認定已包含語音播放操作。
「12 種」和「27 種」，是哪一個模型的結果？
這是本站另一組 Opus 5.5 實驗，提示詞由本站另行設計，沒有重現 Dom 原作的製作流程。目的只有一個：比較是否明列元件名稱，會如何影響指定元件的出現數量。
兩組都要求製作拆帳 App 的元件展示頁，各產生五份。A 組只要求約三十張、要好看，種類由模型決定。B 組則提供 31 條名稱需求，去重後以同一套 29 種標準評分。
結果如下。中位數是把五個結果排序後，取正中間那一個，不是挑最好看的一份。
| 條件 | 五次出現的種類數 | 中位數 |
|---|---|---|
| A：沒有提供名稱清單 | 13、11、10、12、12 | 12／29 |
| B：提供名稱清單 | 29、26、26、27、28 | 27／29 |
這個差異表示，在這一個任務裡，寫明要哪些元件，能讓交付更接近指定清單。B 組本來就取得更多具體需求，因此結果不代表模型憑空學會了新能力，也不是 Fable 5.2 與 Opus 5.5 的比較。
評分還受到定義影響。例如 Dialog 對話框需要有標題、足夠內容及確認／取消鈕，Accordion 可展開收合的列表則要求至少三列。放寬這些條件，部分原本漏項的判定就會改變，所以不宜把分數當成通用設計能力排名。
怎麼把名稱清單，改成能操作的驗收？
先挑出你真的需要的元件，再為每項加上「正常、等待、失敗」的情境。這是本文從盤點延伸的做法，原實驗只確認畫面涵蓋，沒有驗證所有互動。
| 元件 | 畫面之外要檢查的事 |
|---|---|
| 金額輸入 | 空值、小數、負數與上限如何處理 |
| 檔案上傳 | 失敗後能否重試，進度是否對應真實傳輸 |
| 確認對話框 | 取消是否保留資料，鍵盤焦點是否合理 |
| 倒數計時 | 歸零後的狀態，重新整理是否改變結果 |
上表把「有沒有出現」推進成「做了什麼之後，應該發生什麼」。請 AI 交出對應操作步驟，再親手走一次，才比較容易找到展示動畫沒有呈現的缺口。
常見問題
元件和常見套件相似，就能判定抄襲嗎？
同類元件本來就可能共享操作慣例。只靠名稱或用途相似，無法判定實際使用了哪一份程式或素材。
這組實驗證明 Fable 比較強嗎？
沒有。實驗使用 Opus 5.5，不能替另一個模型下能力結論，也沒有重現作者完整製作流程。
寫出名稱就能做好整個 App 嗎？
名稱可以幫忙交齊介面，但資料、狀態、權限與操作仍要分別實作和檢查。
先寫出你要出現什麼，再測它能做什麼
把下一個頁面需要的元件列成清單，交付後先勾出涵蓋情況，再用上表補齊互動測試。這樣一段漂亮展示，就能轉成可執行的需求，而不必猜作者用了哪一句神奇提示。
