本文同步自 2026 iThome 鐵人賽原文 ，發布日期為 2026-08-04。完整系列可見 iThome 系列頁 。
安安～我是ChiYu～
昨天，我把成員管理頁拆成 Component、Pattern 和 Layout，總算能指出：「這次只改部門篩選，不動整張頁面。」
修改範圍有了，照理說可以叫 AI 開工了吧？
還不行。因為我手上只剩下這句需求：
做一個好用、漂亮、可以搜尋的下拉選單。
「好用」沒有說明怎麼操作，「漂亮」每個人的答案都不同，「可以搜尋」也只交代了一小部分。於是我再補上昨天學會的元件名稱：
使用單選 Combobox 選擇既有部門。
這次聽起來專業多了。問題是，聽起來專業和真的能交付，中間還隔著一段不算短的路。
我把兩句需求各做成一個可操作頁面，接著在兩邊都輸入「研究」。
圖 1：左邊的清單完全沒變；右邊知道要篩選既有部門，但兩邊都還缺少選取後的結果、Reset 與非理想狀態。
同樣輸入「研究」，一邊沒反應，一邊只答對第一題
右邊確實比左邊好。說出 Combobox 之後，至少排除了 Menu、一般 Text Field 等錯誤方向，也限制成只能選擇既有部門。
但 Combobox 沒有附贈讀心術，更沒有兼任產品經理。選完要更新哪裡、載入失敗怎麼辦、手機上要保留什麼，元件名稱一個字都沒有說。
| 我實際做的事 | 模糊要求 | 只有元件名稱 |
|---|---|---|
| 輸入「研究」 | 三個選項全部保留 | 清單縮小為「研究組」 |
| 判斷能否建立新部門 | 無法判斷 | 已限制為既有部門 |
| 選取後是否更新成員清單 | 無法判斷 | 仍然無法判斷 |
| 檢查 Loading、Empty、Error | 沒有 | 沒有 |
| 清除條件與手機、鍵盤驗收 | 沒有 | 沒有 |
如果我只看右邊「有成功篩選」，很容易就把它當成改善版收下。等到真的接進成員管理頁，才會發現我們只決定了元件，其他產品規則依然整包交給 AI 猜。
Vibe Coding 最容易出現的誤會就在這裡：Prompt 多一個英文名詞，畫面可能馬上變得比較像樣；可是一旦開始操作，沒寫的地方還是會一個個冒出來。
八格 UI Spec 把 AI 還在猜的事逐一攤開
「Spec」聽起來像是要打開一份四十頁文件。這個系列沒打算把事情搞成那樣，我只需要一張動手前的提醒卡。
圖 2：八格不是八段漂亮文字。每一格都要能落到畫面、操作或驗收。
| 要寫的內容 | 用白話問自己 | LumenDesk 部門篩選 |
|---|---|---|
| 誰要用、要做什麼 | 使用者來這裡要完成哪件事？ | 管理員想找出某個部門的成員。 |
| 要用哪個元件 | 這個任務需要哪一種控制？ | 單選、可搜尋的 Combobox。 |
| 內容從哪裡來 | 使用者可以選什麼？有沒有不能選的？ | 只能從既有部門選，不能自己新增。 |
| 操作後會怎樣 | 輸入、選取、清除後，畫面怎麼變？ | 輸入會篩選；選到部門後更新清單；Reset 清除條件。 |
| 不順利時怎麼辦 | 載入中、找不到、失敗或停用時要看見什麼？ | 保留欄位標籤；無結果可清除；失敗時可以重試。 |
| 手機能不能用 | 小螢幕上，哪些東西不能被擠掉？ | Label、目前選擇、錯誤訊息和 Reset 都要看得到。 |
| 不用滑鼠能不能用 | 鍵盤按下去會發生什麼？焦點看得見嗎？ | ↓ 開啟、Enter 選取、Escape 關閉。 |
| 怎樣算完成 | 你要怎麼知道 AI 這次做對了？ | 不用滑鼠完成搜尋、選取、關閉與重設。 |
前兩格先決定誰要完成什麼，以及要用哪種元件。中間幾格把資料、互動和不順利的狀況補起來；最後一格則是收件標準。
我不要求八格每次都寫得一樣長，也不會為了排版整齊硬塞內容。它們只負責一件事：AI 交出畫面後，我可以把規格逐格換成操作，不必再靠「感覺好像可以」驗收。
規格還沒決定，就寫「待確認」，別讓 AI 幫忙抽籤
八格列出來後，最容易犯的錯是每一格都想填滿。空白看起來像沒做完，隨手補個答案比較有安全感。
偏偏那個臨時補上的答案，過幾天通常會回來找麻煩。
例如「輸入幾個字後才查詢」，可能跟資料量和 API 成本有關。目前還不知道，就直接寫：
查詢觸發字數：待確認。
請先提供「輸入即篩選」與「輸入 2 個字後查詢」的差異，
不要自行替我選一種。
「待確認」會把還沒做的決策留在看得到的地方。先讓 AI 提供差異，我再決定；總比它默默選一個數字，最後大家一起假裝那是需求來得可靠。
把八格放回 Combobox Demo，規格終於長出操作
我把這份規格放進元件百科網站的 Combobox｜組合式選擇框 Demo。這次不只看一張完成圖，右側還能切換預設、已選取、載入中、無結果、載入失敗與停用等狀態。
圖 3：輸入「研究」後只剩研究組；右側保留各種狀態入口，Reset 也沒有被藏在 Prompt 裡。
我照著八格規格跑了四項檢查：
- 輸入「研究」，候選清單只留下符合的既有部門。
- 不用滑鼠，以方向鍵和 Enter 完成選取，再用 Escape 關閉清單。
- 切換無結果與載入失敗，畫面仍會說明現況和下一步。
- 按 Reset 後清除篩選，360px 寬度下 Label、欄位和狀態訊息仍可閱讀。
前兩個版本只能告訴我「畫面上有一個選單」。補完規格後，我才有辦法指出哪個步驟通過、哪個狀態沒做，以及退回修改時該講哪一句。
Prompt 的字數不是重點。真正有差的是，每句話都有一個對得上的畫面或操作。
圖 4：規格補的是可觀察的操作與狀態，不是更多形容詞。
把八格整理成一份可以直接修改的 UI Prompt
下面這份 Prompt 依照八格規格排列。你不用逐字照抄，把方括號換成自己的情境；還沒決定的地方，就大方留下「待確認」。
我要做 [頁面或功能名稱]，給 [使用者角色] 使用。
他來這裡要完成的是：[一個主要任務]。
請使用 [UI 元件名稱]，讓他可以 [操作方式]。
資料來自 [資料來源或固定選項]；[允許／不允許的事情]。
使用者輸入、選取、清除或送出後，畫面要分別發生：[操作結果]。
載入中、沒有資料、失敗與停用時，請顯示：[狀態與下一步]。
360px 時必須保留：[不能省略的資訊或操作]。
鍵盤要能完成：[按鍵與預期結果]。
完成時，我會驗收：[可以實際操作或觀察的條件]。
還沒決定的地方請標示為「待確認」，不要自行假設。
這不是一段保證 AI 一次做對的咒語。它比較像工作單：哪裡做錯，我能指出欄位；哪裡沒決定，AI 也知道先停下來問。
UI Spec 讓我能指出哪裡沒過，不再只會說「不好用」
昨天，我學會替修改範圍畫邊界。今天再往裡面補上資料、行為、狀態和驗收方式，原本那句「做一個好用的下拉選單」才終於變成可以操作的工作。
現在如果結果不對，我不必再說「這個感覺怪怪的」。我可以直接指出：無結果時沒有清除入口、載入失敗後不能重試，或鍵盤焦點跑丟了。
明天開始，我們把這張八格工作單拿去處理 LumenDesk 的第一個完整任務：邀請成員。Dialog 底下有好幾個都能點的東西，但它們點下去的結果完全不同。先從 Button、Link 與操作元件分工開始。
參考資料
- W3C WAI-ARIA APG：Combobox Pattern （查閱：2026-07-23）：Combobox 可為可編輯或 select-only，並定義 popup、鍵盤與可存取名稱等行為。
- W3C WAI：Labeling Controls （查閱：2026-07-23）：控制項需要可辨識的標籤，並應與控制項建立關聯。
- WCAG 2.2 （查閱：2026-07-23）：可用於檢查鍵盤操作、標籤、名稱角色值與 Reflow 等可測試條件。