安安～我是ChiYu～
重新驗收 LumenDesk 成員管理後台後，我開始寫這個系列的最後一篇。
第一版很快就完成了。
七段工作回顧、四步驟流程、三輪 Prompt、八題檢查表，全部排得整整齊齊。該有的都有。
我從頭讀了一次。
很像結案報告。
如果把標題換成《年度工作成果彙整》，整篇大概也不會抗議。每一句都對，讀完卻只剩「需求要寫清楚、成果要記得驗收」這種誰都不會反對，也很難真的帶回去用的結論。
所以我先不替檢查表加第九題。我重新打開三張舊畫面，拿滑鼠和鍵盤再走一次。它們都曾經看起來可以交差，操作後卻各自露出問題。
這也替最後一篇定下範圍：
AI 把畫面生成出來之後，我到底要做什麼，才能判斷這版 UI 可以交付？
三張截圖分別來自導覽、資料階層與等待狀態。它們的問題沒有寫在配色或間距上，靜態畫面自然也不會主動招供。
圖 1：頁面結構與側邊導覽正常顯示；只有實際收合並用鍵盤操作，才會發現部分入口失去可辨識名稱。
第一版桌面導覽可以展開，也能收合，圖示都還留在原位。我原本準備讓它過關，直到用鍵盤重新走一次：部分入口收合後只剩圖示，連可辨識名稱也一起不見了。
看得到的人或許還能猜圖示，輔助科技拿到的卻是一個沒有名字的入口。驗收問題不是「Sidebar 收得漂不漂亮」，而是「收合後還能不能知道這個入口會去哪裡」。
圖 2：Tree View 看得到階層、焦點框與選取底色；切換節點後的錯誤摘要值和 Console 裡的 SVG 錯誤不會出現在截圖上。
第一版有展開箭頭、有選取底色，也看得到鍵盤焦點。外觀條件幾乎全數到齊，切換節點後，畫面摘要卻拿到錯的值，Console 還留下一組 SVG 錯誤。
如果我只截圖，這棵 Tree View 會是一位模範生。讓它真的走兩步，答案就寫到隔壁題去了。
圖 3：可見百分比與進度條正在前進；完成後還要核對畫面文字與輔助科技取得的進度值是否一致。
第一版裡，我真的把它從 0% 看到完成。畫面文字說「24 位成員已匯入」，可存取進度值卻還停在 0%。同一個任務，畫面和輔助科技各自宣布了一種結果。
這三個問題後來分別補上收合導覽的名稱、Tree View 的節點摘要與 SVG 設定，以及 Progress Bar 的完成值。2026 年 7 月 27 日重新在本機操作，三項都已通過。
它們是歷史上曾經失敗、目前已修正的項目。把它們留在最後一篇，是因為三張圖都指向同一件事：
畫面出現了，只能證明畫面出現了。
昨天已經用第一天那句模糊 Prompt、同一批 LumenDesk 虛構資料和 90 秒任務卡，完整跑過第一版、UI Spec、改寫 Prompt、改善版失敗與修正複測。Day 29 負責保存那次實驗，最後一篇不再把同一場考試重新印一次。
開啟 Day 29 使用的 Vibe UI Atlas 成員管理配方
我從這些結果裡留下三種紀錄：
| 狀態 | 代表什麼 | 需要留下的證據 |
|---|---|---|
| 通過 | 依固定步驟操作，實際結果符合預期 | 測試資料、環境、步驟與結果 |
| 曾失敗、已修正 | 問題確實發生，修正後重新操作通過 | 失敗畫面、修正內容與複測結果 |
| 尚未驗證 | 目前沒有足夠證據判斷 | 明確範圍與後續測試方式 |
這次已修正的項目包括 Search Field 沒有篩選、Combobox 重新展開、Pagination 沒有第二頁、手機表格只裁掉溢出內容，以及 Overflow Menu 狀態沒有關閉。
仍未驗證的則是正式螢幕閱讀器對動態訊息、Menu 與 Combobox 的宣告、200% 縮放，以及真實 API、後端權限、查詢競態與多人同時修改。
前一列要保留修正與複測證據，後一列不能偷偷打勾。把兩者混成一句「大致完成」，下一個接手的人只會拿到一份看不出哪些已修、哪些根本沒測的清單。
第一天最困擾我的，是看到一個東西卻說不出它叫什麼。想請 AI 修改，只能指著畫面說「那個會跳出來的東西」，或者再補一句「幫我做得像 SaaS 一點」。
現在我能分辨 Dialog、Drawer、Popover，也知道 Select、Combobox、Autocomplete 不是同一種下拉。至少我和 AI 不必再玩 UI 比手畫腳。
名稱說完後，產品判斷才剛輪到我：
AI 可以列出選項，卻不知道這個產品最不能犧牲哪一件事。手機只能保留三個欄位時，該留下哪三個？危險操作要多快，又要多慎重？特殊互動看起來很酷，使用者願不願意重新學？這些問題沒有任何一個元件名稱能代答。
下次碰到陌生介面，我不會先重讀 30 篇文章，而是走下面四步。
圖 4：工作流程依序是描述任務、比較相似元件、補成 UI Spec，再用真實操作驗收 AI。
先寫「管理員要從既有部門選一個值」，不要直接指定 Dropdown。
任務、資料與限制先說清楚，候選元件才有比較基礎。只給外觀名稱，AI 很容易先挑一個長得像答案的控制項，再回頭替它補理由。
Select 不方便搜尋大量選項；Menu 負責命令，不該拿來填部門；Combobox 可以輸入文字，再從既有清單完成選取。
這次會選 Combobox，因為部門很多、需要搜尋，又不能臨時新增。元件比較沒有替所有產品頒發同一個冠軍，它只是讓做錯工作的候選者早點離場。
UI Spec 至少要交代資料來源、允許值、操作結果、載入與失敗、手機策略、鍵盤與焦點，以及驗收條件。
還沒決定的內容就寫「待確認」。讓未決策事項留在桌上，比 AI 默默替產品抽籤安全得多。
輸入不存在的值、按 Escape、切斷載入、模擬部分失敗、縮到 360px，再確認資料、焦點與下一步還在不在。
只看畫面時，我會問「像不像我想要的？」真的操作後，問題才會變成：「剛才的輸入為什麼消失？」「取消後資料有沒有變？」「錯誤發生時，我還剩下哪條路？」
這些失敗結果，就是下一輪 Prompt 最需要的內容。
Prompt 不需要在開工前變成一張超長訂單。我把它拆成三輪，每一輪只回答當下需要的問題。
我要製作［頁面或功能］，主要使用者是［角色］，
他要完成［任務］。
先不要產生畫面。
請列出建議的 UI 元件、選型理由，以及目前需求裡仍需確認的資料與操作規則。
沒有答案的地方標記「待確認」，不要自行補成既定需求。
這一輪先抓出「AI 覺得合理，產品其實還沒決定」的事情。畫面晚幾分鐘出現，通常比做完後再拆掉整段互動便宜。
資料包含［欄位、來源與限制］。
操作後應發生［可見結果與資料結果］。
提供本功能需要的預設、載入、空白、錯誤、成功與停用狀態。
說明 360px 如何保留主要任務，以及鍵盤、焦點、取消與重試行為。
這一頁用不到的狀態就刪掉。真正會改變資料、操作與復原方式的才留下來。
請依下列任務逐項自我檢查，回報通過或不通過，
不要只描述目前畫面：
［主要任務］
［取消、錯誤、部分失敗與重試］
［360px、鍵盤與焦點返回］
若不通過，指出是哪個元件、狀態或資料規則造成，
並保留失敗結果供下一輪複測。
AI 回報通過後，我仍然會親自再跑一次。前面三個案例已經示範：AI 和截圖都很擅長交出「看起來應該可以」的答案。
圖 5：左側是可以替換角色、任務與規格的 Prompt；右側每一題都必須能回答通過、不通過或尚未驗證。
這八題不是通用品質保證書。真實產品仍要補上自己的資料量、後端一致性、權限、裝置、使用者與效能條件。
| 範圍 | 當時完成的工作 | 留下的問題 |
|---|---|---|
| Day 1～3 | 把「好看的後台」改成有任務、資料、狀態與驗收的 UI Spec | 規格要放進哪一段真實流程？ |
| Day 4～7 | 完成邀請成員的操作、欄位、通知設定與人員選擇 | 成員進來後，要如何建立活動？ |
| Day 8～12 | 完成數值、日期、附件與表單修正路徑 | 資料能輸入後，整個工作區要怎麼走？ |
| Day 13～17 | 建立導覽、位置線索、內容切換、命令與資料階層 | 找到危險命令後，怎麼安全執行？ |
| Day 18～24 | 補上確認、查看明細、訊息、等待與失敗復原 | 資料恢復後，怎麼讓人有效閱讀與管理？ |
| Day 25～28 | 整理內容容器、狀態標記、Data Table 與媒體控制 | 這些判斷能不能回頭改善第一版？ |
| Day 29～30 | 用同一批資料與任務重測，區分已修正與仍未驗證 | 留給正式產品繼續回答。 |
邀請成員之後才有活動資料；資料能輸入後，才需要導覽、命令與階層；命令會失敗，才需要中斷、回饋與復原。最後再把這些責任帶回第一天的管理後台。
30 篇文章沒有讓 UI 變成一張可以照著點餐的菜單。它讓我遇到模糊需求時，知道先問哪一個問題，也知道畫面出現後該怎麼把它弄壞一次。
最讓我改變看法的，不是哪一個元件名字，而是那些「看起來已經完成」的瞬間。
Sidebar 收得很順，我差點就停在動畫；Tree View 的焦點和底色都有，我差點只截一張圖；Progress Bar 跑到終點，我也差點把「24 位成員已匯入」當作整段流程的答案。真正讓問題出現的，都是再多做一步：用鍵盤走一次、看一下可存取結構、把流程跑到完成。
同時製作文章與 Vibe UI Atlas，比我一開始想得更麻煩。文章不能只把元件定義搬過來，網站也不能只做一張供截圖的 Demo。只要文章寫了「按 Escape 會回到入口」，Demo 就真的得做到；Demo 如果驗出失敗，文章也要誠實保留那次失敗，而不是只留下修好後的漂亮版本。
這也是我目前最不滿意、但不想假裝不存在的地方：正式螢幕閱讀器、200% 縮放、更多觸控裝置、真實 API 與多人資料競態，還沒有全部走完。30 天能建立一套方法，不能替正式產品完成所有驗證。
不過，這個系列已經幫我改掉一個很具體的習慣。以前 AI 交出第一版，我會先看畫面哪裡不夠漂亮；現在我先拿任務卡去操作。搜尋不會動、取消會改資料、錯誤後回不去，再漂亮都不能收工。
這大概也是我最希望讀者帶走的事情：不要停止要求 AI 把畫面做好看，但把「好看」從完成條件，移到任務真的走得通之後。
回到第一天那句「幫我做得現代、漂亮、好用」。
30 天後，我仍然想要漂亮的畫面。差別是第一張截圖出現時，我不會直接收工。我會搜尋一筆資料、取消一次危險操作、切到錯誤狀態、把視窗縮到 360px，再用鍵盤走一遍主要流程。
能走完，我才有證據說這版可以交付；走不完，失敗結果就寫回下一輪 Prompt。圓角和陰影當然可以繼續調，只是它們終於排在任務後面。
Vibe UI Atlas 會繼續保留元件名稱、比較、Demo 與 Prompt，讓下一個「好像哪裡不太對」有地方可以查。這 30 天的文章則留下一個工作習慣：不要只問 AI 畫面能不能更好看，先確認使用者能不能把事情做完。
AI 可以很快交出第一版。
是否能交付，要由實際任務決定。
資料查閱：2026-08-07。
iThome鐵人賽
看影片追技術