「幫我做一個現代、漂亮、好用的工作區成員管理後台。」
我把這句話原封不動交給 AI，沒有補資料欄位、操作流程或手機版規則。為了能在瀏覽器裡檢查，我只要求它產生可開啟的靜態前端頁面，不替它補功能。
它交出的畫面是這樣：
圖 1：只看第一眼，它很像一個已經做完的 SaaS 後台。所有帳號、信箱與資料皆為虛構。
老實說，第一眼我沒有討厭它。版面乾淨，側欄、搜尋、篩選、分頁和操作按鈕都有，甚至還準備了三張摘要卡。如果我只用「像不像後台」評分，它很容易過關。
接著我真的操作了一次。
這不是在挑剔 AI 沒有讀心。原始需求只給了三個形容詞，它自然只能拿常見的後台外觀把空白補起來。問題是，外觀補完了，任務還沒有。
| 我做的事 | 實際結果 | 需求裡少了什麼 |
|---|---|---|
在搜尋欄輸入 Aurora |
三筆資料全部留在畫面上 | 搜尋範圍、觸發時機與無結果狀態。 |
| 按下「篩選」 | 沒有出現條件，也看不到目前套用的篩選 | 可用條件、套用方式與 Reset。 |
| 按下第一列的「停用」 | 沒有確認、結果或錯誤回饋 | 影響對象、取消路徑與完成後的狀態。 |
| 將瀏覽器縮到 360px | 頁面實際寬度仍有 1180px，只看得到左側與一小部分內容 | 手機版保留哪些資料，以及導覽要怎麼收起來。 |
| 檢查非正常情況 | 只有一般資料表畫面 | Loading、Empty、Error 與沒有權限時的下一步。 |
圖 2：我把同一頁縮到 360px。不是版面稍微擠了一點，而是主要資料直接跑到可視範圍外。
把這些缺口標回原本的桌面畫面後，就能看出問題不在配色。
圖 3：畫面已經有元件，但每個紅框都還缺少可以驗收的行為。
這張圖會保留到 Day 29。今天不急著把它修成完整後台，因為這正是整個系列需要的起點：同一份模糊需求，經過 28 天的元件選型與驗收練習後，我們再回來看能不能做得更清楚。
你不需要先成為前端工程師或 UI 設計師。這個系列希望讓 Vibe Coder 多幾種很實用的能力：
整個系列只聚焦 UI 元件。後端、資料庫和商業邏輯當然重要，但這 30 天先把「使用者眼前會看到、會操作的東西」練熟。
同一個 Button，放進 Vue、React、原生 HTML、開源套件或現成模板，程式寫法都可能不一樣。有些專案還會用相當邪門的 CSS 和腳本，把看似正常的元件拼出來。
如果每一篇都開始比較框架 API，這個系列很快就會偏離原本的問題：你到底要 AI 做出哪一種元件，它要負責什麼，又要怎麼判斷它做對了。
UI 元件也不是由某一個人替所有產品訂下唯一答案。很多名稱和使用習慣，是產品、設計系統與使用者長期磨合後留下來的做法；部分原生控制項與無障礙互動，則有更明確的規範。
你當然可以採用不同設計。只是做法越偏離常見習慣，越要把操作結果、狀態和驗收方式說清楚。AI 的第一個答案通常會回到它熟悉的介面模式；你想走另一條路，就要提供更多資訊，也要多做幾輪檢查。
所以這 30 天會維持常見、容易理解的設計，不刻意追求高度客製化。程式碼不是重點，元件怎麼用才是。
前面三天先建立共同語言，後面再進入操作、輸入、導覽、訊息和資料呈現。Day 29 會回到今天這張模糊需求產生的後台，完成真正的前後比較。
圖 4：每個階段補上一種判斷能力，最後再回到同一個 LumenDesk 案例。
| 階段 | 天數 | 會處理什麼 |
|---|---|---|
| 先把話說清楚 | Day 1–3 | 看懂畫面、說對名稱，把想法整理成可檢查的 UI Spec。 |
| 操作與輸入 | Day 4–12 | Button、表單、選擇、數值、日期與檔案上傳。 |
| 導覽與資訊架構 | Day 13–17 | 讓使用者知道自己在哪裡，以及命令和階層資料怎麼找。 |
| 浮動介面與狀態 | Day 18–24 | Dialog、訊息、載入、錯誤和沒有資料時的下一步。 |
| 內容與資料呈現 | Day 25–28 | Card、List、Table 和媒體內容如何依資料關係選擇。 |
| 把整件事串起來 | Day 29–30 | 用完整 UI Spec 重做同一案例，並驗收前後差異。 |
不用立刻寫一份很長的規格。先把形容詞換成問題就好。
| 當你想說 | 可以改問 |
|---|---|
| 「這頁要好用。」 | 誰會用這頁？他來這裡最常要完成什麼？ |
| 「資料要清楚。」 | 哪些欄位一定要看到？手機版可以先收起哪些？ |
| 「操作要直覺。」 | 搜尋、篩選或停用後，使用者會看到什麼？ |
| 「不要出錯。」 | 載入中、沒資料、失敗或沒有權限時，下一步是什麼？ |
套回 LumenDesk，可以先說成這樣：管理員要在成員清單裡找人、看帳號狀態，必要時停用帳號。停用前要能取消；手機上至少要看得到成員、狀態和下一步操作。
這還不是完整規格。它只是把「好用」拆成幾個可以繼續討論的決定。
圖 5：這是後續要逐步補齊的介面契約，不是 Day 1 已經完成的改善版。
第一版讓我更確定一件事：在 Vibe Coding 裡，下一句不一定是「幫我改好」。有時候更有效的做法，是先叫 AI 把它剛才偷偷替你決定的事情列出來。
你可以把下面這段換成自己的情境：
我要做一個成員管理頁，給工作區管理員使用。
他需要搜尋成員、用部門和帳號狀態篩選，必要時停用帳號。
先不要重做畫面。請列出目前版本中你自行假設的內容：
1. 搜尋會比對哪些欄位，輸入後何時更新結果？
2. 篩選有哪些條件，套用後如何顯示與清除？
3. 「暫停」和「停用」各代表什麼？
4. 停用帳號前後會出現什麼確認與回饋？
5. Loading、Empty、Error、沒有權限與 360px 手機版要怎麼處理？
不要使用真實個資。沒有被說明的地方，請標記為「待確認」。
這段 Prompt 沒有要求 AI 立刻生出第二張漂亮畫面。它先把看不見的假設攤開，讓你決定哪些可以接受、哪些必須改。Day 2 和 Day 3 會接著處理元件名稱與 UI Spec；完整改善版留到 Day 29。
這次實驗裡，AI 確實做出一張像後台的畫面。但搜尋、篩選、停用、失敗狀態和手機版都無法驗收，因為原始需求沒有提供那些規則。
Day 1 不追求完美 Prompt，也不急著修完介面。先學會在一張「看起來完成」的畫面上，指出自己還不知道什麼。這就是接下來 29 天要補回來的東西。
iThome鐵人賽
看影片追技術