本文同步自 2026 iThome 鐵人賽原文 ，發布日期為 2026-08-05。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天，我們整理出一張八格 UI Spec，終於可以把「好用一點」拆成資料、操作、狀態與驗收條件。今天準備拿它處理 LumenDesk 的第一個完整任務：邀請成員。

不過在正式拆 Button 與 Link 之前，先讓我介紹一個接下來會一直出現的網站。畢竟我用一整段文字解釋「按下去會進入處理中」，你還是親手按一次比較快。

文章負責說明判斷，UI 元件百科讓你直接操作

我替這個系列做了 UI 元件百科 。30 篇文章不會整批搬進網站，網站只負責當工具箱：讓你看元件、操作狀態、比較容易混淆的選項，再把適合的 Prompt 帶回自己的專案。

首頁會用卡片顯示元件外觀，也能用正式名稱、俗稱或使用情境搜尋。進入單一元件頁後，可以先用 60 秒判斷是否適合，再往下看畫面規則、必要狀態、互動 Demo、可複製 Prompt 與驗收清單。

今天會用到三個入口：

文章會把判斷過程說清楚，網站則負責讓你真的按看看。兩邊搭在一起，寫 Prompt 時就不必只丟一句「做得像 SaaS 一點」給 AI 自由發揮。

比較頁一開始沒有問顏色，而是先問：點下去以後，使用者還在目前的工作裡嗎？

Button 與 Link 比較頁：先問點下去後會不會離開目前工作

圖 1：點擊結果才是 Button、Link 與其他操作元件的分界。藍色、底線和圓角都排在這題後面。

原始 Prompt 只寫「好用一點」，三個操作就長成同一種 Button

LumenDesk 的「邀請成員」Dialog 底下有三件事：查看權限說明、取消邀請、送出邀請。它們都能點，點完後的結果卻完全不同。

我先把 Brief 裡最早的需求原封不動交給 AI：

把成員管理頁的操作做得好用一點。

下面這張基準是在 2026 年 7 月 27 日重新執行，使用 Codex Desktop 與當日的 GPT-5 系列模型。最初開發時沒有替每一篇保存第一張畫面，所以我把它明確標成「重跑基準」，不會拿它冒充 7 月 23 日那次已經遺失的原始截圖。重跑時也沒有偷偷補 Prompt 或人工加入狀態。

只要求把操作做得好用一點時，AI 產生的第一版操作區

圖 2：角色欄位、權限說明、取消與儲存都有出現，但三個可點項目用了幾乎相同的 Button 外觀。

有一說一，第一版不醜，該出現的文字也都有。AI 甚至非常公平，每個操作都分到一顆差不多醒目的按鈕。

問題正是太公平了。

  • 「查看權限說明」會前往別處，卻被做成執行動作的 Button。
  • 儲存期間能不能重複按，畫面沒有答案。
  • 儲存失敗後，剛才輸入的內容是否保留，依然不知道。
  • 關閉或取消後，焦點要回到哪裡，也沒有交代。

我的選型判斷不會從「改成底線」或「換成灰色」開始。我要先按照點擊結果分工：前往內容用 Link；改變目前資料用 Button；危險操作要另外交代後果與取消路徑。執行中或失敗時，按鈕文字和附近訊息也得跟著目前狀態更新。

先看點擊結果，再選 Button、Link、Toggle 或 Menu Button

我們先不管外觀，把 LumenDesk 裡幾個操作寫成一張結果表：

可點的地方點下去後會發生什麼優先選擇
送出邀請驗證並送出資料，留在目前任務查看成功或錯誤。Button
查看權限說明前往另一份內容，不送出目前表單。Link
開啟通知在開與關之間切換同一項設定。Toggle Button
更多操作展開一組次級命令，例如停用或重寄邀請。Menu Button
刪除此草稿進入危險操作的確認流程。Danger Button + Confirmation

這張表比「主要操作用藍色」好用，因為顏色會跟著品牌改，點擊結果不會。你也能直接拿它反問 AI：「它會前往權限說明頁，為什麼做成 Button？」

如果還是不確定，就沿著比較頁的判斷圖走一次。

Button 與 Link 的判斷圖

圖 3：前往內容用 Link；改變目前資料或介面用 Button。同一設定的開關交給 Toggle Button，一組次級命令則由 Menu Button 收起來。

Button 留在目前任務，還得交代處理中與失敗

Button 用來觸發目前情境中的動作，例如送出表單、開啟 Dialog、取消編輯或刪除資料。焦點在 Button 上時，Enter 和 Space 都應能啟動它，這也是 WAI Button Pattern 定義的基本鍵盤行為。

我在 Button 元件頁 準備了一個成員資料的儲存情境。先看預設畫面，再切換處理中、失敗與不可用，差異才會出現。

Vibe UI Atlas 的 Button 實際 Demo：成員資料儲存操作、狀態切換與取消按鈕

圖 4：主要 Button 負責儲存，次要 Button 負責取消；處理狀態發生時，文字、可否重複點擊與回饋都要一起改變。

同一個任務區不需要開按鈕同樂會。邀請成員最重要的是「送出邀請」，它可以是唯一最醒目的操作；「取消」要找得到，但沒必要和送出搶注意力。

儲存失敗時，Button 不能只換成紅色

我把 Demo 切到「儲存失敗」。如果規格只寫 Error State，最省事的產出就是把原按鈕染紅，文字繼續寫「儲存變更」。使用者看得出有事發生，卻不知道剛才到底有沒有送成功。

網站上的版本會把主要操作改成「重新嘗試」，旁邊顯示「儲存失敗：請檢查連線後重新嘗試。」原本輸入的內容也會保留。

我檢查的地方只換外觀可以繼續工作的版本
按鈕文字仍寫「儲存變更」改成「重新嘗試」
錯誤回饋只有紅色說明尚未成功，並提供下一步
使用者資料不知道是否已送出或被清空保留原值，可以直接重試

Button 的責任不只停在「可以按」。它還要讓人知道操作走到哪裡，失敗後又能從哪裡接回來。

Danger Button 是操作情境，不是另一種執行狀態

Loading、Error、Disabled 描述的是同一個動作目前走到哪裡；Danger 描述的則是這個動作可能造成的後果。刪除、永久移除或覆寫資料不會因為套上紅色 Token 就自動變安全，規格仍要說清楚影響範圍、是否能復原，以及使用者如何取消。

操作層級與狀態

圖 5：主要、次要與危險操作屬於情境層級；進行中、失敗與不可用則是按鈕狀態。兩組問題分開看，畫面才不會一次長出八顆按鈕。

這也是網站把「按鈕情境」和「按鈕狀態」拆成兩個 Demo 的原因。排列組合全部攤開看似完整，實際上只會讓每顆 Button 都像在競選畫面主角。

純圖示 Button 還要補上可存取名稱。垃圾桶、三個點和叉叉不是每個人都會猜成同一件事，例如成員列上的編輯按鈕可以使用 aria-label="編輯專案 Aurora-01"，把動作與對象都說出來。

回到「查看權限說明」。它不會送出邀請，也不會改變 Dialog 裡的資料；它只是帶使用者前往另一份內容，這就是 Link 的工作。

Vibe UI Atlas 的 Link 實際 Demo：從成員設定前往權限說明

圖 6：連結文字直接寫出「權限說明」。使用者啟動前就知道目的地，不會誤以為它要送出目前表單。

Link 可以前往另一頁、外部網站、檔案或本頁段落。WAI Link Pattern 建議優先使用原生的 <a href>，讓瀏覽器保留導覽、右鍵選單與既有連結行為；鍵盤使用者則以 Enter 啟動。

「更多」和「點這裡」放在完整段落裡，也許勉強猜得到。但當使用者掃描畫面、用螢幕閱讀器逐一瀏覽連結，或把連結文字單獨截給同事時，這兩句幾乎沒有資訊。

「查看權限說明」、「閱讀通知規則」和「下載成員報表」會更清楚。WCAG 2.2 的 Link Purpose (In Context) 也要求使用者能從連結文字與脈絡判斷目的地。若連結會另開分頁、下載檔案或跳到長頁的某個位置，也應事先交代。

改寫 Prompt：替每個可點項目交代責任

原始 Prompt 只要求「好用一點」，AI 當然只能自行決定哪些是 Button、誰最重要、失敗後要留下什麼。把昨天的八格 UI Spec 套進來後，我改成下面這樣：

請為 LumenDesk 的「邀請成員」Dialog 設計操作區。

- 「查看權限說明」使用 Link，前往 /permissions-guide；文字必須能獨立說明目的地。
- 「取消」使用次要 Button，關閉 Dialog，不儲存已輸入內容；焦點回到原本開啟 Dialog 的位置。
- 「送出邀請」是唯一的主要 Button。送出期間顯示「邀請傳送中…」，並禁止重複點擊。
- 若送出失敗，保留表單內容，在操作區附近顯示可理解的錯誤與「重新嘗試」。
- 「移除成員」使用 Danger Button。執行前顯示無法復原的後果，並提供取消路徑。
- 純圖示的更多操作按鈕要有可存取名稱「更多成員操作」。
- 360px 寬度下，按鈕可換行或垂直排列，文字與錯誤訊息不可被截斷。

這份 Prompt 沒有替 AI 指定字型和圓角，因為這次真正要驗收的是操作分工。每個可點項目會做什麼、何時不能再按、失敗後怎麼回來，全部能在畫面上操作確認。

若你只需要其中一個元件，可以直接使用網站 Button 頁 或 Link 頁 的單一元件 Prompt，不必從整段規格裡剪貼。

第二版拆開操作責任，還有兩項不能假裝通過

補完 Prompt 後，我重新檢查 Button 元件頁。這次不看「感覺有沒有比較完整」，而是逐一切換預設、儲存中、儲存失敗與不可用狀態。

補上操作責任與狀態後的 Button 元件頁

圖 7：失敗時主要操作改成「重新嘗試」，錯誤訊息留在操作區，資料不消失；權限說明仍保留 Link 的目的地語意。

驗收項目第二版結果
動作與導頁分工通過。Button 改變目前工作，Link 前往權限說明。
儲存失敗通過。文字改成「重新嘗試」，資料與錯誤訊息保留。
危險操作通過目前 Demo 的確認與取消流程。
360px通過文章截圖與元件頁基本操作檢查。
螢幕閱讀器實聽、200% 縮放這輪尚未完成，不能只因為有 Accessible Name 就宣稱全面通過。

最後一列得留下來。aria-label 寫了，不代表我已經用螢幕閱讀器聽過；360px 看得下，也不能代替 200% 縮放測試。完成的寫完成，還沒驗證的就別急著蓋章。

  • 前往頁面、文件或資源的項目使用 Link，文字看得出目的地。
  • 改變目前資料或介面的項目使用 Button。
  • 一個任務區有清楚的主要操作，其他操作沒有搶走注意力。
  • 主要 Button 在處理中、失敗與不可用時，都讓使用者知道下一步。
  • 危險操作有後果說明和取消路徑。
  • 純圖示 Button 有名稱；Tab 焦點清楚，Button 可用 Enter／Space，Link 可用 Enter。
  • 360px 寬度下，Button 與 Link 的文字沒有被截斷或擠成難以點擊的一排。

這份清單也放在網站元件頁。讀完文章後，可以直接打開自己的 AI 成品逐項操作，哪一項沒過就退哪一項，不必再用「看起來怪怪的」跟 AI 猜謎。

操作區完成分工，四個輸入框又開始互相冒充

文章開頭那三個長得差不多的操作，現在有了明確責任：送出邀請用 Button，權限說明用 Link；儲存失敗時保留資料並提供重試。危險操作也不再只靠紅色嚇人。

我再把視線往 Dialog 上方移，帳號、密碼、搜尋和備註四個欄位排得整整齊齊，也長得一模一樣。

AI 對它們一視同仁：複製同一個輸入框，換掉 Placeholder，收工。

看來明天要處理的，是這四個「都能打字，所以被當成同一種元件」的欄位。

參考來源與查閱日期