安安～我是ChiYu～

我重新打開第一天做的 LumenDesk 成員管理後台，在搜尋框輸入 Orbit。

三筆資料，一筆都沒動。

下面是依照第一版需求重建的錯誤現場。畫面使用固定的虛構成員資料，不含真實個資：

圖 1：搜尋框收下 Orbit，Aurora、Nimbus 與 Solace 卻一筆都沒離開；篩選沒有條件，停用也沒有取消流程，90 秒任務卡直接得到 0／3。

側欄、摘要卡、搜尋、篩選、表格和分頁全都在。畫面每一區都很像有在工作，真的點下去，漏洞才開始排隊報到。

有一說一，它到現在都不算難看。如果明天就要交 Prototype，我只看十秒，很可能會說一句「差不多了」，然後去忙下一件事。

偏偏這 28 天一直在處理的，就是「差不多」後面那一大段。

同一句模糊 Prompt，這次不先看它漂不漂亮

第一天交給 AI 的要求只有一句：

幫我做一個現代、漂亮、好用的工作區成員管理後台。

只看外觀，我頂多能評論配色、間距和卡片排得整不整齊；把 Orbit 實際輸入後，搜尋到底有沒有作用才終於露餡。停用帳號能不能取消、載入失敗後怎麼回來，也不會因為卡片排整齊了就自動獲得答案。

所以這次不憑印象回顧，也不換一批比較討喜的資料。我沿用同一句 Prompt、同一組 LumenDesk 虛構成員與同一批管理任務，重新驗收前後兩個版本。

這個控制條件很重要。前後版本若換了資料、任務或裝置，就很難判斷改善到底來自規格，還是只是第二張畫面比較討喜。

90 秒任務卡：三個核心操作，第一版連找人都辦不到

我先替後台準備三個核心操作：

1. 找到 Orbit-04。
2. 只看研究組成員。
3. 勾選兩位成員，準備停用，再取消。

三題跑完後，再加兩個故障條件：模擬清單載入失敗，接著把畫面縮到 360px 重做主要操作。核心任務和故障演練分開記，才不會一張圖寫三題，正文又突然長出五題。

第一版的結果如下：

它有一張後台的臉，還沒有後台的工作能力。

第一版失敗的地方也替今天劃出範圍：我不需要再做一張更華麗的後台，而要讓搜尋、篩選、危險操作、錯誤復原和手機版都能被重複驗收。

第一次改寫：元件名稱變多，AI 要猜的事情沒少多少

認識一輪 UI 元件後，我先試了最直覺的改法：把正確名稱全部塞進 Prompt。

請幫我做一個成員管理後台。
要有 Search Field、Combobox、Data Table、Drawer、
Overflow Menu、Confirmation Dialog、Toast 和 Skeleton。

看起來專業多了，像原本的 Prompt 突然換上西裝。可惜工作內容仍然沒寫。

AI 還是不知道：

• Search Field 要搜尋哪些欄位。
• Combobox 能不能建立新部門。
• Data Table 的全選是本頁還是所有結果。
• Drawer 開啟後背景能不能操作。
• Confirmation Dialog 取消後資料與焦點去哪裡。
• Toast 出現後該不該搶走焦點。

元件名稱能幫我指出修改邊界，不能自動補出產品規則。再多塞五個英文名詞，猜測還是猜測。

八格 UI Spec：把「這應該很合理吧」逐格寫清楚

第二次改寫前，我先把需求拆成八格。每一格只處理一種責任，免得任務、資料和元件全部擠在同一句話裡。

圖 2：八格 UI Spec 固定使用者與任務、資料、元件理由、行為、狀態、手機版、鍵盤與辨識，以及最後的驗收條件。

元件選型也在這裡定下來：每列低頻命令收進 Overflow Menu；詳細資料放進 Drawer，保留原本清單脈絡；停用帳號會改變資料，先經過 Confirmation Dialog，再由 Toast 回報結果。

這些元件不是來湊一桌 UI 全餐。每一個都要回答一項任務，說不出理由的，就不該只因為名字很專業而出現。

改寫 Prompt：把第一版的失敗直接寫成考題

請建立 LumenDesk 工作區成員管理頁。

使用者是工作區管理員，他要搜尋、篩選、檢視、調整與停用成員。
資料只使用虛構代號，包含成員編號、顯示代號、部門、角色、狀態與最後活動時間。

- Search Field 搜尋成員編號與顯示代號；輸入 Orbit 後只顯示符合資料。
- 部門使用只接受既有值的 Combobox，不允許建立規格外的新部門。
- 角色與狀態使用固定選項篩選；條件改變後重設到有效頁碼。
- Data Table 支援排序、分頁、列選取、批次停用與每列 Overflow Menu；全選範圍必須明確。
- 詳細資料使用 Drawer；關閉後回到原列入口。
- 停用前開啟 Confirmation Dialog，初始焦點放在取消；取消後資料不變。
- 成功後顯示 Toast，但不要移動目前焦點。
- 提供 Loading、Empty、Error 與 Success；Error 保留篩選條件，只重試清單區域。
- 360px 保留成員代號、狀態與主要操作，不得造成整頁水平溢出。

驗收：
1. 搜尋 Orbit 後只顯示一筆符合資料。
2. 部門不能建立規格外的新值。
3. 選取兩列後才顯示 Bulk Action Toolbar，數量為 2。
4. 取消停用後資料不變，焦點回到停用按鈕。
5. Error State 能只重新載入清單。
6. 在 360px 不產生整頁水平捲動。

這段確實比第一天長，但不是多寫幾個「高級感」或「像 SaaS」。搜尋範圍直接寫成成員編號與顯示代號，不再讓 Orbit 剛好命中哪個欄位靠運氣。最後六條就是改善版的考卷；哪一題失敗，我就知道下一輪要改什麼。

Vibe UI Atlas 的成員管理配方保留完整 Demo，可以直接跟著任務操作。

改善版第一次實測：規格寫清楚，畫面仍然不會自動全綠

完整 UI Spec 減少了猜測，不代表第一個改善版本會直接通過。

第一次操作時，我抓到四個問題：

看起來沒有水平捲軸，不代表內容真的放得進 360px；選單從畫面消失，也不代表程式狀態已經關閉。這些都不是換顏色能處理的問題，只能靠真的操作抓出來。

第二版重新搜尋與篩選：這次資料真的會動

修正後，我從任務卡第一關重新開始。

圖 3：改善後桌面版把搜尋、既有部門篩選、排序、分頁、列選取與每列操作放回同一條管理流程。

輸入 Orbit 後，清單從五筆縮成一筆，結果數量同步更新。部門 Combobox 可以輸入文字尋找，但最後只能選產品組、營運組、客服組或研究組等既有值。「研究部門」不會因為有人打了四個字，就偷偷成為新部門。

表格預設每頁三筆，五筆資料真的分成兩頁；成員欄位也能切換遞增與遞減。Pagination 不再只是兩顆長得很像功能的裝飾按鈕，第一頁、第二頁和邊界都能實際測。

批次停用與 Drawer：紅色按鈕只是危險流程的入口

我勾選第一位成員後，Bulk Action Toolbar 才出現；再勾一位，數量從 1 變成 2。

圖 4：未選取資料時不顯示批次工具列；選取兩位成員後，才出現數量與停用操作。

按下「停用帳號」後，Confirmation Dialog 的初始焦點放在取消，不是紅色確認按鈕。按 Escape 或取消，資料維持原樣，焦點回到剛才的批次停用入口。

顏色只能提醒有風險；誰會被停用、能不能反悔、取消後回到哪裡，仍然要靠流程交代。

接著我打開每列 Overflow Menu，再進入 Drawer。清單仍留在畫面後方提供位置脈絡；Drawer 開啟期間背景不接受操作，關閉後焦點回到同一列。這裡選 Drawer，不是因為它從右邊滑出來，而是使用者需要查看詳細資料，又不能丟掉剛才的搜尋與選取位置。

Error State：清單失敗，不要把整個後台一起炸掉

圖 5：只有成員清單顯示錯誤，搜尋與篩選條件仍保留，使用者可以只重新載入失敗區域。

這次我會給通過。不是因為錯誤卡片特別漂亮，而是它說清楚哪個區域失敗、剛才的工作還在不在，以及使用者現在可以做什麼。

Loading、Empty 與 Error 都要接受同樣的盤問。只換插圖和標題，沒有處理資料、操作與復原方式，仍然只是三張不同口味的等待畫面。

360px：不是把桌面表格切掉就算響應式

圖 6：手機版保留成員代號、狀態、列選取與操作；其他欄位移到詳細資料，頁面沒有整體水平溢出。

桌面六個欄位不可能在手機上維持相同寬度。我保留成員代號、狀態、列選取與操作；部門、角色、最後活動時間移進詳細資料。

實際檢查時，頁面寬度沒有超過 360px，操作按鈕仍看得到。這個決定也不是永久答案：若真實使用者最常用手機追查「最後活動時間」，那一欄就不能藏。手機版沒有固定藏欄公式，只有哪個任務最不能失敗。

六項驗收有答案，還要留下可以重跑的證據

瀏覽器主控台也沒有出現本頁互動錯誤。這就是我對第二版的判斷：核心管理流程通過這次任務驗收，不是因為「感覺更完整」，而是搜尋、選取、取消、復原和手機版都有可重跑結果。

不過，AI 自我回報「六項都通過」仍然不是證據。每輪至少要留下：

• 使用的 Prompt 與固定測試資料。
• 測試日期、環境與版本。
• 每題操作步驟、預期與實際結果。
• 失敗項目、修正內容與複測結果。
• 目前仍未驗證的範圍。

沒有這些資訊，下一次重新生成或換模型後，就很難知道行為退步是從哪一輪開始。

目前仍未驗證：歷史問題修掉了，不等於產品全部完成

這次找到的 Combobox、Pagination、手機表格與 Overflow Menu 狀態問題，都已在修正後重新操作，不是目前仍存在的失敗。

尚未驗證的是正式螢幕閱讀器對動態訊息、Menu 與 Combobox 的宣告、200% 縮放，以及真實 API、後端權限、查詢競態與多人同時修改。Demo 使用固定虛構資料，也不能證明正式產品的資料量與延遲都成立。

寫成「尚未驗證」可能沒有「全面通過」好看，至少下一個接手的人知道證據停在哪裡，不會拿桌面版的一張截圖替整套系統背書。

28 天後，我先寫任務卡，再請 AI 做畫面

第一天，我拿「現代、漂亮、好用」當需求，AI 回給我一張看起來像後台的畫面。今天仍然讓 AI 做畫面，但生成前先固定使用者、資料、元件理由、行為、狀態與驗收；生成後，再拿同一張 90 秒任務卡重跑。

這 28 天累積下來的，不是一份更長的英文元件清單。下次遇到「幫我做一個後台」，我知道要先問搜尋哪些欄位、資料能不能自訂、危險操作如何取消、失敗後保留什麼，以及手機上哪件工作不能被藏起來。

Vibe Coding 到這一步，Prompt 不再負責祈禱 AI 猜對，而是把猜錯時能被抓到的條件先寫好。

明天不再增加第 30 組元件。我會回頭整理這 30 次驗收到底改變了什麼，也把至今仍不能交給 AI 決定的責任留下來。

參考來源

• W3C APG：Combobox Pattern
• W3C APG：Table Pattern
• W3C APG：Grid Pattern
• W3C APG：Dialog (Modal) Pattern
• W3C WCAG 2.2：Understanding Status Messages

資料查閱：2026-08-07。