Day 3｜一份 AI 看得懂的 UI Spec，至少要交代這 8 件事

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天我把成員管理頁拆成 Component、Pattern 和 Layout，總算能指出：「這次只改部門篩選，不動整張頁面。」

修改範圍有了，照理說可以叫 AI 開工了吧？

還不行。因為我手上只剩下這句需求：

做一個好用、漂亮、可以搜尋的下拉選單。

「好用」沒有說明怎麼操作，「漂亮」每個人的答案都不同，「可以搜尋」也只交代了一小部分。於是我再補上昨天學會的元件名稱：

使用單選 Combobox 選擇既有部門。

這次聽起來專業多了。問題是，聽起來專業和真的能交付，中間還隔著一段不算短的路。

我把兩句需求各做成一個可操作頁面，接著在兩邊都輸入「研究」。

圖 1：左邊的清單完全沒變；右邊知道要篩選既有部門，但兩邊都還缺少選取後的結果、Reset 與非理想狀態。

同樣輸入「研究」，一邊沒反應，一邊只答對第一題

右邊確實比左邊好。說出 Combobox 之後，至少排除了 Menu、一般 Text Field 等錯誤方向，也限制成只能選擇既有部門。

但 Combobox 沒有附贈讀心術，更沒有兼任產品經理。選完要更新哪裡、載入失敗怎麼辦、手機上要保留什麼，元件名稱一個字都沒有說。

如果我只看右邊「有成功篩選」，很容易就把它當成改善版收下。等到真的接進成員管理頁，才會發現我們只決定了元件，其他產品規則依然整包交給 AI 猜。

Vibe Coding 最容易出現的誤會就在這裡：Prompt 多了一個英文名詞，畫面可能馬上變得比較像樣；一旦開始操作，沒寫的地方還是會一個個冒出來。

八格 UI Spec，把 AI 還在猜的事情攤開

「Spec」聽起來像是要打開一份四十頁文件。這個系列沒打算把事情搞成那樣，我只需要一張動手前的提醒卡。

圖 2：八格不是八段漂亮文字。每一格都要能落到畫面、操作或驗收。

前兩格先決定誰要完成什麼，以及要用哪種元件；中間把資料、互動和不順利的狀況補起來；最後一格則是收件標準。

我不要求八格每次都寫得一樣長，也不會為了排版整齊硬塞內容。它們只負責一件事：AI 交出畫面後，我可以把規格逐格換成操作，不必再靠「感覺好像可以」驗收。

還沒決定就寫「待確認」，別讓 AI 幫忙抽籤

八格列出來後，最容易犯的錯是每一格都想填滿。空白看起來像沒做完，隨手補個答案比較有安全感。

偏偏那個臨時補上的答案，過幾天通常會回來找麻煩。

例如「輸入幾個字後才查詢」，可能跟資料量和 API 成本有關。目前還不知道，就直接寫：

查詢觸發字數：待確認。
請先提供「輸入即篩選」與「輸入 2 個字後查詢」的差異，
不要自行替我選一種。

「待確認」會把尚未完成的決策留在看得到的地方。先讓 AI 提供差異，我再決定；總比它默默選一個數字，最後大家一起假裝那就是需求來得可靠。

把八格放回 Combobox，規格終於長出操作

我把這份規格放進元件百科網站的 Combobox｜組合式選擇框 Demo。這次不只看一張完成圖，右側還能切換預設、已選取、載入中、無結果、載入失敗與停用等狀態。

圖 3：輸入「研究」後只剩研究組；右側保留各種狀態入口，Reset 也沒有被藏在 Prompt 裡。

我照著八格規格跑了四項檢查：

1. 輸入「研究」，候選清單只留下符合的既有部門。
2. 不用滑鼠，以方向鍵和 Enter 完成選取，再用 Escape 關閉清單。
3. 切換無結果與載入失敗，畫面仍會說明現況和下一步。
4. 按 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 等可測試條件。