本文同步自 2026 iThome 鐵人賽原文 ，發布日期為 2026-08-03。完整系列可見 iThome 系列頁 。
安安～我是祈豫～
昨天留下來的後台有一個很麻煩的問題。
我知道搜尋沒反應、手機版壞掉，停用按鈕也像裝飾品，但真的要叫 AI 修改時，我只說得出：「那個東西幫我改一下。」
既然叫不出名字，我乾脆先請 AI 幫忙點名。還是同一張 LumenDesk 成員管理後台，這次先不看紅框，也不看昨天整理的答案：
圖 1：先不要往下找答案。你會把這張畫面裡的哪些東西叫作「元件」？
我只給 AI 一句：
分析這張管理後台畫面有哪些元件。
AI 很快整理出 Sidebar、搜尋欄、篩選按鈕、摘要卡、Data Table、Status Badge 和分頁。看到這裡都還算合理，接著它又把整張成員管理頁、版面配置，甚至顏色和間距一起放進「元件」清單。
每個詞單獨看都跟 UI 有關，排在同一層就開始不對勁了。這很像點名時把學生、分組活動、座位配置和整間教室全部算成同學。名單很完整，接下來卻不知道要叫誰上台。
AI 列出一串元件名稱，我還是畫不出修改範圍
我先不急著研究定義，直接拿這份清單寫下一輪需求：
把成員管理元件改得更清楚。
調整搜尋區塊。
手機版把側邊欄收起來。
三句都像人話，也都不夠準。
第一句的「成員管理元件」可能是整頁、Data Table，或其中一張成員卡。第二句的「搜尋區塊」可能只改 Search Field，也可能連部門條件、結果數量、無結果和 Reset 一起改。
第三句更麻煩。「把 Sidebar 收起來」只描述眼前的東西消失了，沒有交代手機上的完整導覽要搬去哪裡。照字面實作，AI 很可能真的把它藏起來，然後恭喜我們得到一個沒有導覽的手機版。
三句話都還沒交給 AI，我已經無法替它們畫出修改範圍。問題不在英文背得太少，而是我把不同責任塞進同一個「元件」抽屜，現在連抽屜都快關不起來了。
| AI 列出的項目 | 它真正負責的事 | 混在一起會發生什麼 |
|---|---|---|
| Status Badge | 顯示一筆帳號目前是啟用或停用 | 可能只改了顏色，卻沒有補狀態語意。 |
| 搜尋、篩選和結果清單 | 合作完成「找到成員」這項任務 | 可能只做出搜尋框，沒有 Reset、無結果與錯誤處理。 |
| Sidebar 和內容區 | 決定整張頁面的版面關係 | 可能在修改一個欄位時，把手機導覽也一起改掉。 |
| 成員管理頁 | 一類管理頁共用的內容骨架 | 可能把整頁誤認為一顆可以到處搬動的元件。 |
| 藍色、間距和圓角 | 讓多個畫面共用一致的設計值 | 可能以為換 Token 就能解決操作流程。 |
這些項目都和 UI 有關，只是工作的尺度完全不同。Vibe Coding 時如果不先拆開，AI 每次修改都像拿著一張「整間都可以動」的施工許可。
圖 2：左邊只說要改得更清楚；右邊先指出資料表、搜尋流程與手機版各自屬於哪一層。
同一張後台，要分成 Component、Pattern、Layout 與 Token
我把 LumenDesk 畫面中能直接指出來的內容，先分成五個責任層次：
| 名稱 | 在這張畫面裡的例子 | 描述需求時要補什麼 |
|---|---|---|
| Component（元件） | Button、Search Field、Status Badge、Data Table | 元件用途、資料、狀態和操作結果。 |
| Compound Component（一組元件） | 搜尋欄、部門篩選與 Reset 的固定組合 | 這幾個控制如何合作，以及共用什麼狀態。 |
| Pattern（操作方式） | 輸入關鍵字、加入條件、查看結果、清除條件 | 使用者完成任務的順序與失敗後的下一步。 |
| Layout（版面） | 左側導覽加右側內容區 | 桌面與手機如何重新排列、收合或保留。 |
| Design Token（設計值） | 主操作色、危險色、間距、圓角 | 哪些值要跨元件共用，以及它們代表什麼。 |
圖 3：五種虛線不是五塊互不相干的區域。Search Field 本身是 Component，同時也會參與更大的搜尋組合與操作 Pattern。
Component 與 Compound Component：單一責任，還是共用狀態的一組控制？
Component 是能單獨指出責任的控制或資訊單位。Button 負責觸發動作，Status Badge 顯示狀態，Search Field 接收搜尋文字。它們可以長得很簡單，責任要能說得出來。
Compound Component 則是一組必須合作的元件。以搜尋區為例，Search Field、部門條件和 Reset 各自能被辨認，但它們共用同一批篩選狀態。只改其中一顆，整段任務不一定會成立。
Pattern：從輸入條件到清除結果的完整任務
Pattern 最容易被誤認成畫面上的「一塊」。它其實描述使用者完成事情的方法，不一定有一條剛剛好的框線可以圈起來。
搜尋欄是一個 Component；輸入關鍵字、加入部門條件、查看結果、遇到無結果，再清除條件，合起來才是一段搜尋與篩選 Pattern。AI 只做出一顆有放大鏡的輸入框，頂多算道具到齊，流程還沒開演。
Layout：360px 時，Sidebar 與主要內容要怎麼重排？
Layout 負責各區域的位置與空間關係。昨天 360px 的問題就屬於這一層：Sidebar 沒有重新安排，只是照著桌面寬度繼續站在原地，把主要內容擠到畫面外。
所以「手機版把 Sidebar 縮小」不是完整策略。我們還要決定導覽入口放在哪裡、內容欄位保留哪些，以及使用者能不能回到其他頁面。
Design Token：統一顏色與間距，不能代替互動規則
Token 保存可以跨元件共用的設計值，例如主操作色、危險色、間距與圓角。把停用按鈕套上 color.danger，可以讓危險操作看起來一致。
不過紅色只負責提醒風險，不會自動長出 Confirmation Dialog，也不會替我們決定停用成功或失敗時要顯示什麼。看到 Danger Token 就以為危險操作已經完成，差不多像貼完警告貼紙就宣布消防驗收通過。
Page Template 與 Design System 要跨頁、跨產品才能看完整
圖 3 只有五層，因為 Page Template 和 Design System 很難靠一張頁面完整框出來。
Page Template 是同類頁面共用的骨架。成員、專案與活動紀錄頁，都可能保留頁面標題、篩選區、主要資料區和新增操作。資料換了，這組頁面結構仍然在。
Design System 的範圍更大。它會整理元件、Token、互動規則、內容寫法與使用說明。把它當成另一顆超級元件，或只加上一套色票，都不足以組成一套系統。
我刻意沒有把這兩個名詞塞進瀏覽器框線。Template 要跨幾張同類頁面比較，Design System 則要看整套產品的規則；硬畫進去，只會讓那張責任地圖重新變回昨天的元件大雜燴。
還有一件事要先講清楚：不同團隊對 Component、Pattern 或 Template 的邊界可能不完全一樣。這篇採用的分層是後續溝通的共用座標，不是唯一標準。團隊有自己的叫法也沒問題，只要每個名稱對應的責任和修改範圍一致。
補上責任層級後，三句需求終於有修改邊界
分完層後，我回頭重寫剛才那三句需求：
| 原本的說法 | 補上責任與邊界後 |
|---|---|
| 把成員管理元件改得更清楚 | 只調整 Data Table 的成員、部門、角色與狀態欄；Header、Sidebar 和整頁 Template 都不要改。 |
| 調整搜尋區塊 | 調整「搜尋與篩選 Pattern」：包含 Search Field、部門條件、結果數量、無結果與 Reset。 |
| 手機版把側邊欄收起來 | 重新設計 360px Layout：桌面 Sidebar 不保留在畫面上，完整導覽改由 Header 的選單入口開啟。 |
現在我可以在 AI 開始前先說「這次只動哪裡」，也能直接列出「哪些地方不要碰」。這才是分類真正帶來的好處。
英文名稱的用途是指出責任，不是增加 Prompt 的專業濃度。只把「那個東西」換成 Component，修改範圍仍然說不清楚，頂多是把模糊需求翻成英文。
叫 AI 改畫面前，先要求它標出責任層級
如果你拿到一張參考圖，可以先忍住「照這張做」的衝動，請 AI 把畫面拆開：
請先分析這張成員管理頁，不要直接改畫面。
請分開列出：
- Component：可單獨辨識與重用的控制或資訊單位。
- Compound Component：必須一起合作的一組元件。
- Pattern：使用者完成搜尋、篩選或管理任務的操作流程。
- Layout：側欄與內容區的版面關係，以及 360px 時的轉換。
- Page Template：同類管理頁會保留的骨架。
- Design Token：跨元件共用的顏色、間距與圓角決策。
請用表格列出畫面項目、分類理由和目前還缺的規格。
一個項目若同時參與多個層次，可以重複出現，但要說明責任差異。
先不要修改畫面，也不要把所有東西統稱為 Component。
拿到分類結果後，我會檢查四件事：
- 整張頁面有沒有被誤叫成單一 Component。
- Pattern 是否包含一段完整任務，不只是一顆控制項。
- Layout 有沒有交代 360px 的轉換方式。
- Token 是否被拿來假裝行為已經定義。
其中一項混在一起，後面的修改範圍就還有洞。先在分析階段抓出來，總比 AI 改完整頁後，再玩「大家來找碴」省事。
名稱只畫出邊界，互動規則還要交給 UI Spec
今天我們把 Button、搜尋流程、Sidebar Layout、Page Template 和 Token 放回各自的責任層次。現在我已經能說：「只改搜尋與篩選 Pattern，不動 Sidebar 和 Page Template。」
比昨天的「那個東西改好一點」準確多了。
但還不能交給 AI 開工。
這句話沒有說搜尋哪些欄位、輸入後何時更新、沒有結果怎麼辦，也沒寫清楚鍵盤和手機版要怎麼驗收。名稱替修改範圍畫出邊界，邊界裡面要發生什麼，依然是一大片空白。
明天，我們再把這片空白填成 AI 能執行、我也能驗收的 UI Spec。
參考資料
- W3C WAI-ARIA Authoring Practices Guide （查閱：2026-07-23）：互動元件的角色、狀態與鍵盤操作需要隨元件責任一起被說清楚。
- Material Design 3 Components （查閱：2026-07-23）：成熟設計系統會整理元件的用途與使用情境；本文不把它當成唯一的命名標準。
- Design Tokens Format Module 2025.10 （查閱：2026-07-23）：Token 是至少包含可讀名稱和值的設計資訊，可用於跨工具交換設計決策；該文件為 Design Tokens Community Group 報告，不是 W3C Standard。