安安～我是ChiYu～
專案資料恢復後，AI 很貼心地替每一筆套上圓角、陰影和滑過去會浮起來的效果。三張 Card 排在一起，SaaS 感可以說是相當充足。
我當時給的需求只有一句：
請把近期專案做成現代、好看的 Card。
結果同一個「下一個里程碑」，分別被放到卡片上方、中間與底部。
圖 1：同樣都是里程碑日期，卻待在三個不同位置。三張 Card 個別能讀，放在一起卻很難比較。
接著我只做了一件事：找出哪個專案的下一個里程碑最早。
這下就不太充足了。我得先進第一張 Card 找日期，再把視線移到第二張、第三張；標題、摘要、狀態和操作還輪流跑出來搶版面。
Card 沒壞，是我把需要跨筆比較的任務，塞進了適合獨立閱讀的容器。
Vibe Coding 很容易在這裡被畫面帶著走。只要 Prompt 出現「現代後台」「近期專案」和「好看一點」，Card 幾乎是標準答案。但容器選錯，陰影減半、圓角改成 12px，資料還是一樣難找。
所以今天拿同一批專案做兩個任務：
Card、List、Description List、Media Object 與 Metadata 都會出場，但裁判不是誰長得比較像 SaaS，而是讀者到底要怎麼讀。
完整 Demo 與選型流程已整理在 Vibe UI Atlas 的內容結構比較頁。
我把三筆專案分別放進 Card 和 List，刻意做兩個方向相反的任務。
第一題是「哪個專案的下一個里程碑最早？」Card 把每筆資料包成獨立區塊，我得逐張鑽進去找日期。換成 List 後，里程碑固定在每列同一位置，視線往下掃就能比較。
第二題改成「收藏 LumenCore 後台改版，晚點再回來看。」這次 Card 反而更自然。專案名稱、狀態、負責人、里程碑和收藏操作都屬於同一筆內容，我不用先理解整張清單，就知道自己正在操作誰。
| 任務 | Card 的結果 | List 的結果 | 我的選擇 |
|---|---|---|---|
| 比較三筆里程碑 | 日期散在各張卡片內，視線來回移動 | 日期維持固定位置，可以直接往下掃 | List |
| 理解並收藏一筆專案 | 摘要與操作能獨立成立 | 操作仍依賴整列與清單脈絡 | Card |
這輪沒有容器冠軍。結果很明確：
比較多筆資料時用規律結構；理解並操作單筆內容時，才讓它獨立成卡。
先用同一筆「LumenCore 後台改版」建立資料地圖：
資料不變，閱讀任務不同，容器就會分工：
| 讀者正在做什麼 | 適合的元件 | 它負責整理什麼 |
|---|---|---|
| 瀏覽幾個可以各自打開的專案摘要 | Card | 把一筆能獨立成立的內容與操作收在一起 |
| 快速掃過多筆專案名稱與狀態 | List | 讓同類項目維持重複、規律的閱讀順序 |
| 查看單一專案的負責人、日期與狀態 | Description List | 配對一組欄位名稱和值 |
| 閱讀帶有縮圖、標題與摘要的動態 | Media Object | 讓媒體與文字共同辨識一筆內容 |
| 補充作者、時間、分類或狀態 | Metadata | 說明主內容的來源與脈絡 |
這五個名稱不在同一層競爭。Card 和 List 會改變整批內容的排列；Description List 整理單筆詳細資料；Media Object 是其中一種內容組合；Metadata 則貼著主內容當配角。
如果一開始把它們全部當成容器候選，AI 很容易做出「Card 裡放 List，List 裡再放 Description List，每一列還帶 Media Object 和 Metadata」的俄羅斯娃娃。技術上都能塞，閱讀上不一定需要。
Card 適合把一筆完整但精簡的內容組成可辨識單位。標題、摘要、狀態與操作都要指向同一個對象；把它從其他卡片旁邊拿走，讀者仍知道這是什麼、可以做什麼。
圖 2：LumenCore 後台改版以獨立 Card 呈現，收藏和查看專案各自有清楚入口。
我在網站按下「收藏專案」後，按鈕名稱改成「取消收藏專案」，畫面同時顯示「已收藏 LumenCore 專案」。專案名稱、里程碑和「查看專案」都沒有被改掉。收藏是這筆專案的狀態；查看內容是另一個入口，兩件事沒有混在一起。
Card 最容易出問題的地方，是「整張都能點」和「裡面還有其他按鈕」同時出現。
若外層是一個連結，裡面又放收藏按鈕、三點選單或 Checkbox，就不能把互動元素互相巢狀，也不該用透明連結蓋住整張卡。那種做法滑鼠看起來很方便，鍵盤焦點、事件觸發和可存取名稱卻會開始互相打架。
比較穩定的做法是：
卡片裡再塞三四顆同等醒目的按鈕，也會讓主要入口失焦。Card 能獨立成立，不等於它要獨自承擔整個後台。
我也不會因為資料很多就全部改成 Card。卡片高度不同、欄位位置不固定時，跨筆比較會越來越慢。需要比較價格、權限或狀態，結構規律的 List 或 Table 通常更直接。
List 是一組彼此相關、結構重複的項目。它可以只供閱讀，也可以讓每列帶連結或操作；同一層級的項目要維持一致節奏，讀者才不用每看一列就重新學一次版型。
LumenDesk 的 List 把專案名稱、負責人與日期放在固定位置。
圖 3：每筆專案沿用相同欄位順序，負責人與里程碑可以由上往下快速掃讀。
把三筆里程碑放回同一位置後，我不必在卡片內找日期，第一個任務也就成立了。若順序本身有意義，例如「最早里程碑」或「最後更新」，畫面還要把排序方式說出來。
List 也有失控的時候。當每一列開始出現：
這時 List 已經在偷偷扮演沒有表頭的資料表。後天要談的 Table 會更適合，不用硬把 List 養成另一種元件。
相反地，若每筆只有標題、摘要和一個入口，Table 反而會顯得過重。選型不是看資料筆數，而是看使用者是否需要沿著欄位比較。
Description List 適合描述單一對象，例如專案負責人、預算、建立日期與目前狀態。它處理的是「這個欄位的值是什麼」，不是拿來比較很多筆資料的迷你 Table。
圖 4：單一專案的負責人、日期與狀態以名稱和值成對呈現，展開後仍保留欄位關係。
W3C 的內容結構教學也將 Description List 說明為彼此關聯的詞語與描述群組。內容確實是名稱和值的關係時，可以使用原生 <dl>、<dt> 與 <dd>。
一個欄名可以有多個值，一個值也可以對應一組名稱，但資料關係要清楚。不要只因版面看起來像左右兩欄，就把所有屬性面板硬塞成 Description List。
語意選對後，手機版改成上下排列，欄位和值的關係仍存在，不會因左右位置消失就斷線。
如果要比較五位成員的部門與角色，Description List 會重複產生五組欄名，讀者還是得一組一組找。這種跨筆比較交給 Table 會比較乾脆。
Media Object 常見排列是左邊媒體、右邊文字，適合動態消息、留言、文章摘要或人員資訊。真正的判斷不是「我想在左邊放張圖」，而是圖片或 Avatar 是否真的能幫助辨識這筆內容。
圖 5：媒體與文字共同呈現一筆內容；Demo 可模擬圖片載入失敗，檢查標題與摘要是否仍能辨識內容。
圖片失敗後，標題與摘要仍要足以完成閱讀，否則這個元件把太多責任壓在一個不保證永遠載得到的資源上。
圖片若只是裝飾，不必讓替代文字重複朗讀標題；圖片本身若提供必要資訊，替代文字就要把那份資訊說出來。若是人物 Avatar，姓名不能只存在於圖片 alt；原頁仍應有可讀姓名。
版面也要測極端內容：沒有圖片、超長標題、兩行摘要、不同長寬比，以及 200% 縮放。固定高度若只適合範例資料，正式內容一來就會開始裁字或把操作推到卡片外面。
目前 Demo 已保留圖片故障情境，正式發布前仍要複驗故障後的閱讀順序與輔助科技結果。畫面沒有散掉，不等於閱讀體驗已經全部通過。
作者、更新時間、閱讀時間、狀態與分類常被統稱為 Metadata。它們幫忙交代主內容的新舊、來源與脈絡，位置要靠近主內容，視覺上卻不該搶過標題。
圖 6：作者、更新時間與狀態靠近主內容；相對時間與精確時間可依閱讀任務切換。
「剛剛更新」適合快速閱讀，但到了稽核或多人協作情境，使用者可能需要真正時間點。這不是二選一：畫面可以先顯示相對時間，再用 <time datetime="…"> 或清楚補充文字提供精確值。
時間還要交代時區。跨國團隊若只看到「8 月 18 日 09:00」，很容易各自在腦中補一個不同時區。日期是否包含年份，也要依資料的新舊與任務決定。
Metadata 字比較小，不代表什麼都能往同一行塞。內容過長時應換行或重新排序；一律截斷，最後留下的可能剛好是最沒用的半句。狀態如果會影響操作，也不能只藏在低對比的小字裡。
圖 7：先判斷內容能否獨立成立、是否需要快速掃描，以及目前是不是在閱讀一組名稱和值。
我會照這個順序問：
選擇流程沒有硬把所有資料送進今天的五個終點。元件百科不是吃到飽，看到名字不代表一定得選一個。
最後，我把「近期專案」改成結構一致的 List。專案名稱、負責人、狀態與里程碑各自留在固定位置，沿著日期往下掃就能比較。
Card 沒有被刪掉。當使用者要收藏、理解或前往一筆獨立專案時，Card 仍然保留；進入詳細內容後，再由 Description List 配對負責人、日期與狀態。Media Object 只在縮圖確實幫助辨識時出場，Metadata 則貼著標題補充作者與時間。
同一份資料會因閱讀任務不同，進入不同層次的容器。這才是分工，不是把 Card 改醜一點逼它退休。
桌面 List 可能把負責人、狀態與里程碑排在同一列，到了 360px 就要重新決定優先順序。
如果手機版為了保留所有桌面欄位，最後每列高到像一張 Card，那就要重新評估：是否改成摘要 List 加詳細頁，而不是硬把整張桌面表格折進口袋。
請為 LumenDesk 的近期專案設計內容區塊。
- 使用者主要任務是快速掃過專案名稱、負責人、狀態與里程碑，不是欣賞獨立卡片。
- 預設使用結構一致的 List；每列欄位位置固定，專案標題或明確的「查看專案」負責導覽。
- 收藏與更多操作各自使用 Button，不要用透明 Link 覆蓋整列，也不要巢狀互動元素。
- 當欄位增加到需要共同表頭、排序、批次選取或跨欄比較時，改用 Table，不要把 List 養成沒有表頭的資料表。
- 單一專案詳細資訊使用 Description List，清楚配對欄名和值；手機重排後仍要維持關係。
- 只有一筆專案能獨立成立、需要自己的摘要與操作時才使用 Card。
- 作者、更新時間與狀態是 Metadata，視覺層級低於標題；相對時間要能取得精確時間與時區。
- 圖片載入失敗後，文字仍能辨識內容；裝飾圖片不要重複朗讀標題。
- 提供 Loading、Empty、Error 與 360px 手機版；手機版依任務重新排序欄位，不要只靠縮小文字塞下全部內容。
這份 Prompt 沒有規定 Card 要幾度圓角。它把 AI 不能自行猜測的部分寫清楚：主要閱讀任務、哪些內容能獨立、互動入口如何分工、何時升級成 Table，以及圖片與手機版出問題時要留下什麼。
目前已確認 Card 的收藏狀態會從「收藏專案」改為「取消收藏專案」，並顯示「已收藏 LumenCore 專案」；近期專案也已改用 List 支援跨筆掃讀。圖片故障後的閱讀順序、200% 縮放與正式輔助科技結果仍待發布前複驗，這幾項先不假裝打勾。
開頭那三張 Card 不是做錯元件，而是被交付了不適合的任務。現在 List 負責跨筆掃讀，Card 處理獨立摘要與操作，Description List 整理單筆欄位；Media Object 和 Metadata 也回到需要它們的位置。
資料排整齊後，下一個問題反而更顯眼。每列旁邊都有一排彩色小膠囊：待處理數量、分類、已選成員、篩選條件、同步狀態和負責人全部長得很像，有些能按、有些不能按。
我當時又補了一句：
請在每筆專案旁加上彩色標籤，顯示數量、分類、已選成員、篩選、同步狀態和負責人。
圖 8：六顆膠囊外觀完全相同，只有「陳怡安 ×」和「進行中」會改變資料。其餘四顆看起來也能按，實際上只是資訊。
有一說一，彩色版本至少還能靠顏色硬記；我把顏色拿掉後，這排元件直接集體失去身分。哪一顆能按、哪一顆只是說明，畫面完全沒有答案。
明天就從同一張灰階畫面繼續。Badge、Tag、Chip、Filter Chip、Status Indicator 與 Avatar 都很小，但它們承諾的事情可不能一起縮水。
資料查閱：2026-08-07。
iThome鐵人賽
看影片追技術