Day 1｜AI 不是不會做，是你只說「做得好看一點」

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

安安～我是ChiYu～

我把一句很有 Vibe Coding 味道的 Prompt 交給 AI：

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

這句話看起來有需求、有風格，甚至還很貼心地補了「好用」。

2026 年 7 月 24 日，我用 Codex Desktop 與 GPT-5 產生一個能在瀏覽器開啟的靜態前端頁面。沒有補搜尋規則，沒有說明停用帳號的流程，也沒有偷偷提醒它記得處理手機版。

我想看的很簡單：只給「現代、漂亮、好用」，AI 到底會交出什麼？

它沒有追問，開工速度倒是很快。Sidebar、摘要卡、搜尋、篩選、Data Table、分頁，常見的 SaaS 後台全家餐很快就端上桌：

圖 1：AI 根據模糊 Prompt 產生的第一版。所有帳號、信箱與資料都是虛構內容。

第一眼像完成品，按三次就開始露餡

有一說一，我第一眼沒有討厭它。

版面乾淨，資訊排得像模像樣，AI 甚至主動補了三張摘要卡。假如驗收方式只有「截圖貼到群組，大家覺得像不像 SaaS」，它大概已經可以收工了。

但這是一個成員管理後台，不是後台形象照。

畫面裡既然有搜尋、有篩選、有停用帳號，我總得按按看。

我先在搜尋欄輸入 Aurora。

三筆資料一筆都沒少。

接著按下「篩選」，畫面沒有出現條件，也沒有任何狀態改變。最後，我點了第一列的「停用」。

它的情緒非常穩定，完全不為所動。

這三次操作都是管理員真的會做的事。再把手機版和非正常狀態一起檢查，缺口就更完整了：

圖 2：畫面縮到 360px 後，頁面仍很有原則地維持 1180px。主要內容沒有重排，只是離開了使用者的視線。

桌面版至少還看得到完整畫面，手機版就更直接了。左側 Sidebar 幾乎包辦整個 Viewport，真正要處理的成員資料被推到右邊。所謂手機版，現在連主要任務都進不了畫面。

我把剛才遇到的問題標回桌面版：

圖 3：元件都出現了。每個紅框仍缺少行為、狀態與驗收條件。

看到這裡，我沒辦法把責任全部推給 AI。

我的 Prompt 只交代「現代、漂亮、好用」。AI 確實完成了最容易展示的部分：外觀。至於搜尋比對哪些欄位、篩選有哪些條件、停用前要不要確認、失敗時怎麼辦，我一個字都沒說。

我給了三個形容詞，卻期待它自行補完一套產品規則。這筆帳算一算，真正漏寫需求的人好像還是我。

問題看得出來，修改對象卻叫不出來

發現功能沒做之後，我的下一個念頭當然是叫 AI 修改。

問題是，我要改哪裡？

「搜尋沒反應」聽起來很清楚，但我要調整的是 Search Field、搜尋與篩選組成的 Pattern，還是 Data Table 的資料狀態？手機上的左側區域，是 Sidebar 縮壞了，還是整個 Layout 根本沒有重新規劃？

畫面就在眼前，我卻只能說：

那個可以搜尋的東西幫我做好一點。
那個左邊的選單手機版不要佔那麼多。
那個停用按鈕按下去要有反應。

這幾句不算錯，但每一句都留下一大片修改邊界給 AI 猜。猜錯的部分，通常就會變成下一輪修改的新驚喜。

這也是我想寫這個系列的原因：很多人不是完全不知道自己要什麼，而是畫面出現後，還缺一套能把問題說清楚的 UI 語言。

這 30 天不只背元件名稱，而是學會跟 AI 交代工作

Vibe Coding 讓不熟悉程式的人也能開始做網站。這很好，但畫面真的出現後，新的問題也會跟著來：你看得出某個地方怪怪的，卻叫不出名稱；知道自己想要什麼感覺，卻說不清楚它該怎麼操作。

例如，一個「看起來像下拉選單」的東西，可能只是在既有選項裡選一個，也可能需要搜尋、允許多選，甚至可以建立新資料。外觀很像，工作完全不同。

我希望這 30 天結束後，Vibe Coder 至少能做到四件事：

• 看到一個東西時，知道它常見的名稱和用途。
• 分得出外觀相似、責任不同的元件。
• 跟 AI 說清楚真正需要的畫面與互動。
• AI 交出結果後，知道要操作什麼、檢查什麼。

所以這不會只是 30 天的元件名詞整理。每遇到一組元件，我都會先放進實際情境，操作 AI 產生的畫面，再說明我接受或退回它的理由。名稱只是起點，最後還是要回到能不能用、能不能驗收。

這套能力不要求你先成為前端工程師。後端工程師、PM、獨立開發者，或只是想用 AI 做一個 Prototype，都可以從畫面上的任務開始。

範圍也會收得很窄：只談 UI 元件。

後端、資料庫與商業邏輯當然重要，但那是另外幾座山。我們先把使用者看得到、摸得到，真的會按下去的東西弄懂。

為什麼這 30 天幾乎不談 Code？

接下來 30 天，你幾乎看不到程式碼。

不是因為 UI 元件不需要 Code，剛好相反，是它的寫法實在太多。同一顆 Button 放進 Vue、React、原生 HTML、開源套件或現成模板，可能就是完全不同的 API；有些專案還能用相當邪門的 CSS 與 JavaScript，拼出一顆外表正常、裡面另有乾坤的按鈕。

如果從第一天就開始比較框架語法，這個系列很快會變成前端門派大亂鬥。大家也許記住了好幾種寫法，卻還是不知道該叫 AI 做哪一種元件。

所以我要處理的是更前面的問題：它叫什麼、能做什麼、適合放在哪裡，以及怎麼確認 AI 沒有只做出外殼。

不同設計系統對名稱和邊界不一定完全相同，文章裡也不會假裝存在一套全球唯一答案。你可以採用不同做法，只要自己清楚，也能把操作結果與取捨說給 AI 聽。

先把常見語言學會。真的要打破規則時，至少知道自己正在打破哪一條。

用 LumenDesk 串起 30 天，不把元件寫成字典

如果接下來每天只是「今天介紹 Button、明天介紹 Text Field」，讀到第十天，我自己可能都會開始懷疑人生。

所以我準備了一個虛構產品 LumenDesk。它是一套工作區管理服務，所有帳號與資料都是假資料，不會使用任何真實個資或校務內容。

接下來，我們會替它邀請成員、建立活動、整理導覽、處理危險操作和錯誤狀態。每個元件都會在一個真的需要它的情境中出場，而不是排隊上台自我介紹。

圖 4：每個階段補上一種判斷能力，最後再回到同一個 LumenDesk 案例。

今天這張第一版會原封不動留到 28 天後。它不是黑歷史，是整個系列的基準答案。

「好用」無法驗收，先改寫成使用者任務

我不是說 Prompt 從此不能出現「漂亮」或「好用」。這些詞可以交代方向，只是不能單獨負責驗收。

畢竟「這頁要好用」沒有辦法直接測。兩個人都覺得自己做得很好用，最後還是只能坐在會議室裡互看。

也不用因此寫出二十頁需求文件。先把形容詞換成幾個能回答的問題，就已經差很多：

套回 LumenDesk，我可以先補成這樣：

工作區管理員要在成員清單裡找人、查看帳號狀態，必要時停用帳號。停用前要能取消；手機上至少要看得到成員、狀態和下一步操作。

這依然不是完整規格，但搜尋有沒有縮小資料、停用能不能取消、手機看不看得到主要操作，已經可以直接測了。大家終於不用再對著「好用」兩個字投票。

圖 5：規格開始描述任務、行為與狀態後，畫面才有可以驗收的契約。這不是 Day 1 已完成的改善版。

先不重做後台，請 AI 列出自行補上的假設

看到第一版後，最簡單的做法是再補一句：「幫我改好一點。」

這句話也最有機會開啟第二輪猜謎。

所以今天我不要求第二版，反而先請 AI 停手，把剛才替我決定的事情一項一項列出來。哪些是需求真的有寫，哪些是它根據常見後台自行補上的；沒有答案的地方，就老實標記「待確認」。

如果你也拿到一張看起來完成、實際上不知道怎麼驗收的畫面，可以把下面這段換成自己的情境：

我要做一個成員管理頁，給工作區管理員使用。
他需要搜尋成員、用部門和帳號狀態篩選，必要時停用帳號。

先不要重做畫面。請列出目前版本中你自行假設的內容：

1. 搜尋會比對哪些欄位，輸入後何時更新結果？
2. 篩選有哪些條件，套用後如何顯示與清除？
3. 「暫停」和「停用」各代表什麼？
4. 停用帳號前後會出現什麼確認與回饋？
5. Loading、Empty、Error、沒有權限與 360px 手機版要怎麼處理？

不要使用真實個資。沒有被說明的地方，請標記為「待確認」。

這段 Prompt 不會立刻生出第二張漂亮畫面。它甚至比叫 AI 直接重做慢，因為我們終於要面對那些原本一句話帶過的問題。

但它會把畫面背後的假設攤開：搜尋比對什麼、停用代表什麼、手機版保留什麼。可以接受的留下，需要調整的重寫，根本沒決定的就先別假裝完成。

完整改善版會留到 28 天後的 Day 29。現在先別急著救這張畫面，它還得替我們工作一整個系列。

今天先不救畫面，先換掉驗收問題

寫到這裡，第一版的搜尋仍然不會動，篩選依舊沒有內容，手機版也還維持 1180px。

這是刻意保留的結果。今天先保存模糊需求會得到什麼，以及我們為什麼無法驗收它；神奇 Prompt 不會在第一篇突然登場。

我真正改掉的只有一件事：第一個問題從「這張畫面漂不漂亮」，換成「使用者能在這裡完成什麼」。

接著又有一個問題。

我要怎麼告訴 AI，現在想改的是搜尋框、搜尋與篩選組成的功能，還是整張成員管理頁？如果連修改對象叫什麼都說不清楚，需求寫得再長，也可能只是把模糊的話寫得比較多。

明天先不碰這張畫面。

我們把裡面這些「那個東西」，一個一個叫出名字。

參考資料

• W3C WAI：Labeling Controls （查閱：2026-07-23）：輸入控制項需要可辨識的標籤，並與控制項建立正確關聯。
• W3C WCAG 2.2：Understanding SC 3.3.2 Labels or Instructions （查閱：2026-07-23）：需要使用者輸入時，必須提供足夠的標籤或說明，讓使用者理解應輸入什麼。
• W3C WAI-ARIA APG：Alert and Message Dialogs Pattern （查閱：2026-07-23）：涉及重要確認的對話框，需要有清楚的動作選項與可預期的鍵盤操作。