安安～我是ChiYu～
我把一句很有 Vibe Coding 味道的 Prompt 交給 AI：
幫我做一個現代、漂亮、好用的工作區成員管理後台。
這句話看起來有需求、有風格，甚至還很貼心地補了「好用」。
2026 年 7 月 24 日，我用 Codex Desktop 與 GPT-5 產生一個能在瀏覽器開啟的靜態前端頁面。沒有補搜尋規則，沒有說明停用帳號的流程，也沒有偷偷提醒它記得處理手機版。
我想看的很簡單：只給「現代、漂亮、好用」，AI 到底會交出什麼？
它沒有追問，開工速度倒是很快。Sidebar、摘要卡、搜尋、篩選、Data Table、分頁，常見的 SaaS 後台全家餐很快就端上桌：
圖 1：AI 根據模糊 Prompt 產生的第一版。所有帳號、信箱與資料都是虛構內容。
有一說一，我第一眼沒有討厭它。
版面乾淨，資訊排得像模像樣，AI 甚至主動補了三張摘要卡。假如驗收方式只有「截圖貼到群組，大家覺得像不像 SaaS」，它大概已經可以收工了。
但這是一個成員管理後台，不是後台形象照。
畫面裡既然有搜尋、有篩選、有停用帳號，我總得按按看。
我先在搜尋欄輸入 Aurora。
三筆資料一筆都沒少。
接著按下「篩選」，畫面沒有出現條件，也沒有任何狀態改變。最後，我點了第一列的「停用」。
它的情緒非常穩定，完全不為所動。
這三次操作都是管理員真的會做的事。再把手機版和非正常狀態一起檢查，缺口就更完整了：
| 我做的事 | 實際結果 | 需求裡少了什麼 |
|---|---|---|
在搜尋欄輸入 Aurora |
三筆資料全部留在畫面上 | 搜尋範圍、觸發時機與無結果狀態。 |
| 按下「篩選」 | 沒有出現條件，也看不到目前套用的篩選 | 可用條件、套用方式與 Reset。 |
| 按下第一列的「停用」 | 沒有確認、結果或錯誤回饋 | 影響對象、取消路徑與完成後的狀態。 |
| 將瀏覽器縮到 360px | 頁面實際寬度仍有 1180px，只看得到左側與一小部分內容 | 手機版保留哪些資料，以及導覽要怎麼收起來。 |
| 檢查非正常情況 | 只有一般資料表畫面 | Loading、Empty、Error 與沒有權限時的下一步。 |
圖 2：畫面縮到 360px 後，頁面仍很有原則地維持 1180px。主要內容沒有重排，只是離開了使用者的視線。
桌面版至少還看得到完整畫面，手機版就更直接了。左側 Sidebar 幾乎包辦整個 Viewport，真正要處理的成員資料被推到右邊。所謂手機版，現在連主要任務都進不了畫面。
我把剛才遇到的問題標回桌面版：
圖 3：元件都出現了。每個紅框仍缺少行為、狀態與驗收條件。
看到這裡，我沒辦法把責任全部推給 AI。
我的 Prompt 只交代「現代、漂亮、好用」。AI 確實完成了最容易展示的部分：外觀。至於搜尋比對哪些欄位、篩選有哪些條件、停用前要不要確認、失敗時怎麼辦，我一個字都沒說。
我給了三個形容詞，卻期待它自行補完一套產品規則。這筆帳算一算，真正漏寫需求的人好像還是我。
發現功能沒做之後，我的下一個念頭當然是叫 AI 修改。
問題是，我要改哪裡？
「搜尋沒反應」聽起來很清楚，但我要調整的是 Search Field、搜尋與篩選組成的 Pattern，還是 Data Table 的資料狀態？手機上的左側區域，是 Sidebar 縮壞了，還是整個 Layout 根本沒有重新規劃？
畫面就在眼前，我卻只能說：
那個可以搜尋的東西幫我做好一點。
那個左邊的選單手機版不要佔那麼多。
那個停用按鈕按下去要有反應。
這幾句不算錯，但每一句都留下一大片修改邊界給 AI 猜。猜錯的部分，通常就會變成下一輪修改的新驚喜。
這也是我想寫這個系列的原因：很多人不是完全不知道自己要什麼，而是畫面出現後，還缺一套能把問題說清楚的 UI 語言。
Vibe Coding 讓不熟悉程式的人也能開始做網站。這很好，但畫面真的出現後，新的問題也會跟著來：你看得出某個地方怪怪的，卻叫不出名稱；知道自己想要什麼感覺，卻說不清楚它該怎麼操作。
例如，一個「看起來像下拉選單」的東西，可能只是在既有選項裡選一個，也可能需要搜尋、允許多選，甚至可以建立新資料。外觀很像，工作完全不同。
我希望這 30 天結束後，Vibe Coder 至少能做到四件事：
所以這不會只是 30 天的元件名詞整理。每遇到一組元件，我都會先放進實際情境，操作 AI 產生的畫面，再說明我接受或退回它的理由。名稱只是起點，最後還是要回到能不能用、能不能驗收。
這套能力不要求你先成為前端工程師。後端工程師、PM、獨立開發者，或只是想用 AI 做一個 Prototype，都可以從畫面上的任務開始。
範圍也會收得很窄：只談 UI 元件。
後端、資料庫與商業邏輯當然重要，但那是另外幾座山。我們先把使用者看得到、摸得到，真的會按下去的東西弄懂。
接下來 30 天，你幾乎看不到程式碼。
不是因為 UI 元件不需要 Code，剛好相反，是它的寫法實在太多。同一顆 Button 放進 Vue、React、原生 HTML、開源套件或現成模板，可能就是完全不同的 API；有些專案還能用相當邪門的 CSS 與 JavaScript，拼出一顆外表正常、裡面另有乾坤的按鈕。
如果從第一天就開始比較框架語法，這個系列很快會變成前端門派大亂鬥。大家也許記住了好幾種寫法，卻還是不知道該叫 AI 做哪一種元件。
所以我要處理的是更前面的問題：它叫什麼、能做什麼、適合放在哪裡，以及怎麼確認 AI 沒有只做出外殼。
不同設計系統對名稱和邊界不一定完全相同，文章裡也不會假裝存在一套全球唯一答案。你可以採用不同做法，只要自己清楚，也能把操作結果與取捨說給 AI 聽。
先把常見語言學會。真的要打破規則時，至少知道自己正在打破哪一條。
如果接下來每天只是「今天介紹 Button、明天介紹 Text Field」，讀到第十天，我自己可能都會開始懷疑人生。
所以我準備了一個虛構產品 LumenDesk。它是一套工作區管理服務，所有帳號與資料都是假資料，不會使用任何真實個資或校務內容。
接下來，我們會替它邀請成員、建立活動、整理導覽、處理危險操作和錯誤狀態。每個元件都會在一個真的需要它的情境中出場，而不是排隊上台自我介紹。
圖 4：每個階段補上一種判斷能力，最後再回到同一個 LumenDesk 案例。
| 階段 | 天數 | 會處理什麼 |
|---|---|---|
| 先把話說清楚 | Day 1–3 | 從「看得出問題，卻說不清修改範圍」一路整理出可執行、可驗收的 UI Spec。 |
| 操作與輸入 | Day 4–12 | 從邀請成員做到活動表單，拆開按鈕、文字、選項、數字、日期與檔案的責任。 |
| 導覽與資訊架構 | Day 13–17 | 功能變多後，重新安排頁面、命令與階層資料的位置。 |
| 浮動介面與狀態 | Day 18–24 | 處理危險操作、詳細資料、訊息、等待與失敗復原。 |
| 內容與資料呈現 | Day 25–28 | 比較 Card、List、標記、表格與媒體元件怎麼分工。 |
| 把整件事串起來 | Day 29–30 | 回到今天的同一句 Prompt，用任務重新驗收整張後台。 |
今天這張第一版會原封不動留到 28 天後。它不是黑歷史，是整個系列的基準答案。
我不是說 Prompt 從此不能出現「漂亮」或「好用」。這些詞可以交代方向，只是不能單獨負責驗收。
畢竟「這頁要好用」沒有辦法直接測。兩個人都覺得自己做得很好用，最後還是只能坐在會議室裡互看。
也不用因此寫出二十頁需求文件。先把形容詞換成幾個能回答的問題，就已經差很多：
| 當你想說 | 可以改問 |
|---|---|
| 「這頁要好用。」 | 誰會用這頁？他來這裡最常要完成什麼？ |
| 「資料要清楚。」 | 哪些欄位一定要看到？手機版可以先收起哪些？ |
| 「操作要直覺。」 | 搜尋、篩選或停用後，使用者會看到什麼？ |
| 「不要出錯。」 | 載入中、沒資料、失敗或沒有權限時，下一步是什麼？ |
套回 LumenDesk，我可以先補成這樣：
工作區管理員要在成員清單裡找人、查看帳號狀態，必要時停用帳號。停用前要能取消；手機上至少要看得到成員、狀態和下一步操作。
這依然不是完整規格，但搜尋有沒有縮小資料、停用能不能取消、手機看不看得到主要操作，已經可以直接測了。大家終於不用再對著「好用」兩個字投票。
圖 5：規格開始描述任務、行為與狀態後，畫面才有可以驗收的契約。這不是 Day 1 已完成的改善版。
看到第一版後，最簡單的做法是再補一句：「幫我改好一點。」
這句話也最有機會開啟第二輪猜謎。
所以今天我不要求第二版，反而先請 AI 停手，把剛才替我決定的事情一項一項列出來。哪些是需求真的有寫，哪些是它根據常見後台自行補上的；沒有答案的地方，就老實標記「待確認」。
如果你也拿到一張看起來完成、實際上不知道怎麼驗收的畫面，可以把下面這段換成自己的情境：
我要做一個成員管理頁，給工作區管理員使用。
他需要搜尋成員、用部門和帳號狀態篩選，必要時停用帳號。
先不要重做畫面。請列出目前版本中你自行假設的內容：
1. 搜尋會比對哪些欄位，輸入後何時更新結果？
2. 篩選有哪些條件，套用後如何顯示與清除？
3. 「暫停」和「停用」各代表什麼？
4. 停用帳號前後會出現什麼確認與回饋？
5. Loading、Empty、Error、沒有權限與 360px 手機版要怎麼處理？
不要使用真實個資。沒有被說明的地方，請標記為「待確認」。
這段 Prompt 不會立刻生出第二張漂亮畫面。它甚至比叫 AI 直接重做慢，因為我們終於要面對那些原本一句話帶過的問題。
但它會把畫面背後的假設攤開：搜尋比對什麼、停用代表什麼、手機版保留什麼。可以接受的留下，需要調整的重寫，根本沒決定的就先別假裝完成。
完整改善版會留到 28 天後的 Day 29。現在先別急著救這張畫面，它還得替我們工作一整個系列。
寫到這裡，第一版的搜尋仍然不會動，篩選依舊沒有內容，手機版也還維持 1180px。
這是刻意保留的結果。今天先保存模糊需求會得到什麼，以及我們為什麼無法驗收它；神奇 Prompt 不會在第一篇突然登場。
我真正改掉的只有一件事：第一個問題從「這張畫面漂不漂亮」，換成「使用者能在這裡完成什麼」。
接著又有一個問題。
我要怎麼告訴 AI，現在想改的是搜尋框、搜尋與篩選組成的功能，還是整張成員管理頁？如果連修改對象叫什麼都說不清楚，需求寫得再長，也可能只是把模糊的話寫得比較多。
明天先不碰這張畫面。
我們把裡面這些「那個東西」，一個一個叫出名字。
iThome鐵人賽
看影片追技術