安安～我是ChiYu～

昨天整理完八格 UI Spec 後，我終於能把「好用一點」拆成資料、操作、狀態與驗收條件。

今天就拿它處理 LumenDesk 的第一個完整任務：邀請成員。

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

我最早給 AI 的需求只有一句：

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

最初開發時，我沒有替每一篇保留第一張畫面。下面這張是在 2026 年 7 月 27 日重新執行原始 Prompt 的基準，使用 Codex Desktop 與當日的 GPT-5 系列模型；重跑時沒有補規格，也沒有人工加入狀態，更不會拿它冒充 7 月 23 日已遺失的原始截圖。

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

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

問題正是太公平了。

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

三顆按鈕排得很整齊，使用者卻得按下去才知道這次是前往別處、取消工作，還是送出資料。

可點不等於做同一件事，先看點下去的結果

我先把顏色、底線和圓角放到旁邊，只問一題：按下去後，使用者會留在目前工作裡，還是前往另一份內容？

這張表比「主要操作用藍色」可靠。品牌顏色會換，操作結果不會因為換主題就跟著轉職。

我把這組判斷放進 UI 元件百科 的 Button、Link 與操作元件比較頁。文章負責說明我怎麼選，網站則讓你真的按一次、切換狀態，再把適合的 Prompt 帶回專案。

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

如果還是不確定，就沿著判斷圖走一次：

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

Button 不只負責被按，還要交代處理中與失敗

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

我在 Button 元件頁 放了一個儲存成員資料的情境。預設畫面看不出多少問題，切到處理中、失敗與不可用後，元件到底有沒有接住工作才會露出來。

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

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

儲存失敗時，只把 Button 染紅還不夠

我把 Demo 切到「儲存失敗」。如果規格只寫 Error State，最省事的做法就是把原按鈕染紅，文字繼續寫「儲存變更」。

使用者看得出有事發生，卻不知道剛才到底有沒有成功。

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

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

Danger 是操作後果，不是另一種 Loading 狀態

Loading、Error、Disabled 描述同一個動作目前走到哪裡；Danger 描述的是這個動作可能造成的後果。

刪除、永久移除或覆寫資料，不會因為套上紅色 Token 就自動變安全。規格仍要交代影響範圍、能不能復原，以及使用者如何取消。

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

排列組合全部攤開，看起來很完整，實際上只會讓每顆 Button 都像在競選畫面主角。

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

Link 前往另一份內容，文字要先說出目的地

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

圖 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 沒有指定字型和圓角，因為這次真正要驗收的是操作分工。每個可點項目會做什麼、何時不能再按、失敗後怎麼回來，都能直接操作確認。

第二版能繼續工作，但還有兩項不能偷打勾

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

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

最後一列得留下來。aria-label 寫了，不代表我已經用螢幕閱讀器聽過；360px 看得下，也不能代替 200% 縮放測試。

收到成果後，我還會親手走一次：用 Enter 和 Space 啟動 Button、用 Enter 開啟 Link、讓儲存失敗、取消危險操作，再把畫面縮到 360px。哪一步失敗，就退回哪一步，不再用「看起來怪怪的」跟 AI 猜謎。

操作分工清楚後，四個輸入框又開始互相冒充

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

我把視線往 Dialog 上方移。帳號、密碼、搜尋和備註四份不同的工作，AI 倒是處理得相當公平：一人發一個單行輸入框，誰也別想比別人特別。

圖 8：四個欄位排得很整齊，卻只有 Placeholder 不同；資料規則與輸入後的反應完全沒有交代。

熟悉的配方又來了：複製同一個元件、換掉 Placeholder、收工。

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

參考來源與查閱日期

• WAI-ARIA APG：Button Pattern（2026-07-23 查閱）：Button 的用途、鍵盤操作、焦點與可存取名稱。
• WAI-ARIA APG：Link Pattern（2026-07-23 查閱）：原生連結、目的地與鍵盤操作。
• WCAG 2.2：Link Purpose (In Context)（2026-07-23 查閱）：連結目的必須可從文字與脈絡判斷。