網頁從設計到上線只需幾小時？AI + No-Code 正在改變設計師的工作模式

No-code 浪潮下，為什麼設計師更需要談 AI？

隨著近年生成式人工智慧（GenAI）與低程式碼（Low-Code）、無程式碼（No-Code）工具的崛起，設計流程正面臨前所未有的轉變。產業預測早在幾年前就指出，到 2025 年會有相當高比例的新應用建立在低程式碼或無程式碼平台上。也就是說，「不會寫很多程式的人也能做出產品」會變成常態，而這群人裡面，設計師一定佔很大一塊。現在已經來到 2025 年底，從各種 AI 平台的數量與應用情境來看，no-code 的確已經成為很多團隊日常工作流程的一部分，產品開發的門檻真的大幅降低了。

身為一個設計所的學生，這樣的趨勢讓我相當興奮，同時又感到有點恐懼。這樣說好了，一方面，我們突然多了很多好用的工具，輸入幾句話就能生出一個網頁原型，大幅加速設計流程；另一方面，也會忍不住問自己：我們的設計能力還有價值嗎？

研究顯示，至少截至今日，這些平台和工具還沒辦法真的取代設計師，比較像是把具體勞動變少了，例如：自動補字、產生 placeholder 圖片、整理元件等，讓效率變快很多，但資訊架構、情境判斷與品牌調性還是得靠我們人來決定。

所以，比起問「AI 會不會取代設計師？」，我現在更在意的是：當產品可以用 AI + No-code 在幾小時到幾天內做出來，設計師的價值在哪裡？

在這篇文章中，我將會用一個具體的課程案例，和大家分享我的一點心得和看法。

專案背景：Airbnb 課程專案與 AI 工具的引入

本篇討論源自於台科大設計所唐玄輝教授的一門課程專案經驗。我們的團隊成員選擇以 Airbnb 平台為題進行概念設計，目的是優化 Airbnb 的品牌體驗並延伸介面功能。我們選擇 Airbnb 作為情境，是因為它提供了一個熟悉且複雜的服務生態系統，可以進行完整的使用者旅程分析和介面痛點挖掘。我們深入研究了 Airbnb 使用者的旅程地圖（Customer Journey Map），找出現有介面可能的不足，並嘗試提出創新功能作為改善方案。

過去做到這一步，下一步通常是：慢慢刻原型、反覆修正，厲害一點的，會請資工系的同學幫忙架網站。但這次我們想試試看：能不能直接用 AI 生出一個真的可以用的網站？

我們並沒有像往常一樣自己慢慢刻原型，反而引入了 AI 及 No-Code 工具來協助完成高保真原型，希望藉此驗證全新設計流程的可行性。我們使用了一款名為 Lovable 的平台，以自然語言對話的形式定義需求，AI 即時產出對應的設計和代碼，然後設計師再細化要求並反覆調整。這種作法讓我們得以跨越繁瑣的手動繪製步驟，直接獲得可互動的雛型作品。

為何選擇 Lovable 平台？

不過，市面上有許多 No-Code 平台和 AI 輔助設計工具，我們為何選擇 Lovable？
Lovable 是一個結合 AI 對話與即時開發的平台：使用者可以「一邊與 AI 聊天、一邊產出產品」。這種 Prompt-Driven 的方式與我們專案的目標不謀而合，我們希望快速將設計概念轉化為可操作的高保真原型，而 Lovable 正提供了這樣的能力。Lovable 的特點在於降低技術門檻：不需要手動寫程式碼，只要用日常語言描述需求，AI 就會負責技術實現。對於時間有限的學生專案來說，這點相當關鍵；我們可以把更多精力放在創意發想和使用者體驗本身上。

看更多 Lovable 的案例：https://docs.lovable.dev/use-case/inspiration

AI 導入設計流程，到底改變了什麼？

在這個專案中，綜觀設計三鑽石流程「現況解析 → 設計迭代 → 場域驗證」，AI 對第二鑽的加速效果最明顯（也就是 Lovable 的角色）：把想法快速轉成「可測試」的原型，縮短假設到回饋的距離。

我們先做完前端的使用者研究與體驗策略（人物誌、CJM、體驗機會點），在第二鑽才進入 Lovable。整體流程大概長這樣：

1. 第一鑽：現況解析（Discover / Define）
   做質性訪談、畫人物誌、CJM，整理出「想像當地人一樣生活的長住旅客」這個 Persona，以及他們在找房、預訂、入住時遇到的痛點。
   這個階段當然也能用到 AI，它能讓我們更快對齊問題，少走冤枉路。AI 可以：
   ．把訪談資料快速彙整成重點與待辦清單
   ．依 Persona/JTBD 產出初步假設與任務流
   ．帶著我們寫出清楚的「問題敘述＋成功指標」
2. 第二鑽：設計迭代（Develop / Deliver）
   這裡就是本篇文章的重點。AI 能讓我們更快找到方向，做出原型。我們用 AI 生成 prototype，然後再回頭調整需求、修 prompt、修資訊架構。AI 提升了：
   ．速度：從「想法 → 可操作原型」的週期從數天縮短到數小時
   ．真實性：原型可實際使用測試，回饋更貼近真實情境
   ．迴圈收斂：讓「假設 → 驗證 → 決策」迭代更密集
3. 第三鑽：場域驗證（Declare / Devote）
   此專案沒有真的進到場域，這部分就先略過。換句話說，這篇文章主要聚焦在：第一鑽做好使用者研究，第二鑽用 AI + No-Code 加速迭代。

那麼人與 AI 應該如何分工？
AI 負責「做快、做齊、做出來」，人負責「做選擇、定風格、扛風險」。也就是說，人與 AI 的交棒時機，就是一旦需要價值判斷，或是需要承擔後果時。人類要做的是策略與判斷（為什麼做、為什麼不做什麼），讓 AI 幫忙更快做出可驗證的版本，讓人更快做出正確的選擇。

這代表設計師一開始就要想得比較「全局」。資訊層級、互動流程、品牌調性，都要在 prompt 裡說明清楚，否則 AI 很容易幫你自作主張。這不代表不能試錯，只要前端的使用者研究基本上沒有問題，後面進到 AI 都能一直修改。當然，prompt 要怎麼寫，又是另一個讓人頭痛的問題。

開始寫 prompt 前，有幾件事需要先讓 AI 搞清楚

請 AI 生成原型時，要請 AI 遵守「必須滿足的條件與要求」，這裡以我們的 Airbnb 專案為例：

• 品牌風格：請 AI 按照 Airbnb 既有的品牌語彙來進行產出。必要時可附上風格參考資料。
• 資訊架構 IA：整個網站的資訊架構要定義清楚，包括網站導覽方式、頁面等。
• 遵守線框圖（wireframe）：清楚定義每個頁面的核心內容、層級，並附上繪製好的 wireframe，請 AI 遵守這個框架來生成。

以下是你應該注意及遵守的事：

• 一次只改一件大事，拆小題分輪做
• 先列資訊架構與層級，再下 prompt
• 把空白／錯誤／載入狀態寫進 AC（Acceptance criteria，驗收標準）
• 用設計系統／品牌語彙 當護欄
• 保留每輪變更紀錄，能說出「為何更好」

以下是你應該避免的事：

• 一次塞滿所有需求（AI 容易跑偏）
• 抽象詞彙（如「漂亮」、「有質感」）， 改成可檢核描述

AI 很強，但你給的 prompt 越具體越能發揮威力。小步快跑、每步都可驗收，品質反而更穩。

G-C-L-I-S-A：我用來寫 Prompt 的六段式公式

為了不要每次都亂寫一大段 prompt，我在與 AI 對話的過程中反覆試驗，最終建構了一套自己的 Prompt 格式 G-C-L-I-S-A，它強迫我把要解決哪個痛點、在哪個頁面哪個位置、互動規則、不能做什麼一次說清楚。

• G — Goal（目標）：這次要解決的目標是什麼？
  聚焦一個目標。例如：幫長住旅客更快看懂生活機能、拉近房東與房客距離。
• C — Context（情境）：這個畫面出現在哪個頁面？
  寫清「頁面+資料」。例如：/search 地圖、Mapbox token、需真實可縮放地圖。
• L — Layout（版面）：你希望資訊怎麼排？
  資訊分層、針對區塊做編號。例如：區塊順序、左右欄、要不要浮動卡片等等。
• I — Interaction（互動）：使用者可以做什麼？
  明確「誰觸發/何時/結果」。例如：可以滑動地圖？點選後展開 Accordion？點按鈕會跳出 modal？
• S — Style（風格）：風格、語氣、品牌限制
  同時列 Must 和 Don’t。例如：沿用 Airbnb 風格、禁用藍色、使用珊瑚粉。
• A — Acceptance（驗收）：用來檢驗成果
  以可量化指標為基礎。例如：確認 Mapbox API key 相符、toast 通知於點擊 Save 後 3 秒自動關閉。

實際寫 prompt 時，我還是會像一般在和 AI 對話那樣給任務，但是會在每次對話都會加上這六點 G-C-L-I-S-A。

Lovable 最終產出的可互動原型

我們最終用 Lovable 產出了十個功能，作為我們的創新解方。在這次專案中，我負責了五個主要功能的原型設計，包括：生活機能地圖、房東介紹影片、長住精選、結構化心願清單、在地探索任務。

功能 1：在地圖上新增「生活機能清單」與距離顯示

目標（Goal）：讓使用者快速判斷到「車站／公園／洗衣店」的可達性（步行／大眾運輸／開車）。
在 /property 房源頁，地圖不再只是顯示房源位置，而是會標註最近的地鐵站、超市、乾洗店與景點，並顯示大概的步行時間，方便長住旅客快速判斷「這裡適不適合生活」。

功能 2：房東介紹影片／模擬視訊

目標（Goal）：預訂前用短片建立信任與即視感（tour／vlog）。
在 /property 房源頁新增一個模擬視訊介面的區塊，旅客可以看到房東的短影片或 room tour。畫面看起來像 video call，但旁邊會寫明「這是預錄影片，並非即時視訊」，避免誤解。

功能 4：「優質長住認證」長住精選

目標（Goal）：讓長住旅客一眼辨識穩定、舒適的長住房源。
與短住旅客不同，長住旅客的需求是穩定、安靜、設備齊、通勤方便。對於評價良好且適合長住的房源，在 /property 房源頁新增「長住精選」badge，並補上一行說明，例如「最受長住旅客好評」、「經 Airbnb 優質長住認證」，降低長住前的不安感。

功能 5：結構化加入心願清單

目標（Goal）：降低整理成本：就地快速分類＋集中管理。
使用者在 /search 搜尋頁面點擊愛心收藏房源時，可以根據喜好加上標籤（例如「有廚房」「有洗衣機」）。把收藏功能做成就地分門別類，能減少使用者後續整理成本；並在 Header 有入口能到 /wishlist 心願清單頁面集中管理。

功能 8：階段性在地探索任務

目標（Goal）：以「不施壓、生活化」的方式提升目的地期待，促成下單。
在 /property 房源頁新增「Local Exploration」區塊，提供依入住天數客製的「Day 1–Day N 建議行程」，以及用 Accordion 呈現的生活建議（咖啡店、散步路線、市集等），鼓勵長住旅客每天走出門感受社區。

以上這幾個功能都不是只靠丟幾句話給 AI，就能生出來的。而是先從使用者研究與體驗策略出發，我們團隊（人）決定要這樣設計，然後再用 Lovable（AI）把它們變成真實可點的介面。

在和 Lovable 對話時，該掌握的小訣竅 & 心得

我整理了一些我在 Lovable 上踩過的坑，統整成 7 個實用訣竅。

1. 先想清楚資訊架構，再丟給 AI

一開始我直接把想要的功能全部丟給 Lovable，結果頁面長得非常像 template 拼裝，資訊層級亂成一團。後來我改成先在 figma 簡單畫四大區塊：房源摘要、地點地圖、評價與在地體驗、注意事項，再用文字具體寫出：「第一區塊顯示什麼、第二區塊顯示什麼⋯」。
有了這個架構之後，AI 生成的版面就有明顯進步，也大幅降低資訊遺漏與層級錯置。現在的 AI 設計工具在高層級資訊架構上還不如人類敏銳，比較適合快速生版面、排細節，而不是完全放手丟給 AI 做。

2. 鎖定品牌風格，明確說明「什麼可以、什麼不行」

只說「Airbnb 風格」通常不夠，我第一次讓 Lovable 設計房源頁的時候，它自動幫我套了幾個藍色 CTA 按鈕，跟 Airbnb 可以說是八竿子打不著。
之後我學乖了，不能只說「請參考 Airbnb 官網風格」，還會明確指定「按鈕請使用 Airbnb 的珊瑚紅 #EC6664，不要使用藍色」；字體、圓角、卡片陰影也會寫清楚。並且在每輪 prompt 都提醒要維持這個風格，避免下一輪被洗掉。
簡單講就是，不只要說「要什麼」，也要說「不要什麼」。請把 AI 當成一個口令一個動作的實習生，要一直提醒它，它才不會自動幫你換一套品牌。

3. 把「一次只改一小塊」當作原則

這可能是整個專案中學到最重要的事。
如果你一次在 prompt 裡說：「幫我改地圖、影片、長住標籤、心願清單、在地探索任務」，AI 真的會很努力全部改，但你很難知道是哪一句 prompt 造成什麼結果。
我後來的做法是：一次只談一個區塊、一個功能。改完就部署看效果，再進入下一輪。訊息變多沒關係，但每一步都比較可控，比較好回溯，整體迭代品質也好很多。

4. 把「互動的觸發時機」講清楚

單純只寫「加一個 toast」「開啟影片視窗」還不夠，AI 會自己亂猜什麼時候觸發。後來我會講得非常具體，例如：

• 「wishlist 的 toast 是在使用者選好標籤、按下 Save 之後才在右下角跳出 3 秒」
• 「Video Tour 按鈕點擊後，開 modal 播放預錄影片，但介面上的麥克風、相機 icon 只是裝飾，實際上不能互動」
• 「價格卡片要根據使用者在小月曆裡選擇的 check-in / check-out，即時計算總價並更新」。

把「哪個動作之後會發生什麼事」的觸發條件講清楚，是讓 AI 不亂改流程的關鍵。

5. 樣式與位置要用「定語言」表達

像「做成浮動」「顯眼一點」這種形容詞，其實對 AI 來說很抽象。效果比較好的寫法是：

• 「價格區塊固定在畫面右側，從 Accommodation type 到 Room description 這段區間都保持可見。」
• 「Guest reviews 的總評分置中顯示，上方留白，下方才接個別評論卡片。」

多用「在哪個區塊的右邊」「佔整欄寬度的幾成」這種帶有位置關係的敘述，會比形容詞有用得多。

6. 真實元件就直接說「我要真的」

一開始我只告訴 AI「在地圖上顯示生活機能」，結果得到一張看起來像地圖的圖片，完全不能拖拉。要真地圖、真路網、可拖放縮放，就直接講清楚，包含 token 也一併給 AI，它才會串接 SDK，而非畫靜態圖。
例如：「使用 Mapbox 的真實地圖 SDK，顯示實際路網和地名，可以拖曳、縮放、點 marker。我的 token（API Key）如下：⋯」。
只要你說得夠明確，Lovable 就會真的去接第三方服務，而不是畫一張假地圖糊弄你。

7. 結果驗收要具體、可量化

如果只說「多顯示一些評論」「評分做得更顯眼」，很難判斷 AI 是否真的達標。我會寫：

• 「Guest reviews 區塊顯示 6 則評論，排成 2 欄×3 列。」
• 「最上方用桂冠包住總分，下方列出乾淨度、準確性、入住、溝通、地點、性價比的子分類分數，各自有 icon 和 5 分制條。」
• 「評論下面要有『顯示全部 32 則評價』按鈕，旁邊附上一個連結：了解評價的運作方式。」

寫得越像「驗收規格」，AI 就越容易給出接近你腦中畫面的結果，我們也比較好檢驗成果。

設計流程轉變，設計師變成什麼角色？

回到一開始的問題：在 AI + No-code 的時代，設計師的角色到底有什麼轉變？

上述的 Airbnb 案例，其實就是一種與 AI 協作設計的全新模式。相較傳統設計流程，最大的差異在於設計的起點和階段順序都發生了改變。過去做產品設計時，通常會從很粗的草圖、wireframe 開始，不斷試錯迭代，逐步增加細節和真實感。

而在有 AI 參與的情境下，設計師一開始就得盡可能清楚描述期望的結果，因為每一句 prompt 都會直接影響最終產出。換言之，原本線性漸進的流程被大幅壓縮：我們幾乎跳過漫長的草圖和中保真雛型階段，直接產生高保真的互動介面，再從這個結果往回修。這也使得設計師在前期就需要具備更強的全局規劃能力和細節預見性，在腦海中預先做出許多過去需要多輪視覺嘗試才能釐清的設計決策。

同時，設計師的角色定位也在這種流程中發生了轉變。在與 AI 的協作中，設計師不再只是「親手畫介面的人」，而是同時扮演多重角色：Prompt 工程師、使用者體驗導演，以及介面批判者。

首先，作為 Prompt 工程師，設計師需要精通與 AI 溝通的技巧，學會用準確、有結構的語言來描述設計問題和期望成果，包括描述清楚情境、功能需求、視覺風格等，甚至對 AI 模型的運作邏輯有所瞭解，才能調整提示的表達以引導理想輸出。

作為使用者體驗導演，設計師要負責定義產品的整體願景與流程節奏，再讓 AI 擔任「演員」快速演繹各個部分，就像導演在排練戲劇：設計師搭好框架與場景，AI 快速生成「片段」，然後我們不斷指導微調以符合劇本預期。

最後，設計師必須以專業眼光充當嚴格的介面批判者，審視 AI 給出的設計是否符合人因需求、品牌語調和美學標準，找出不合理之處並加以修正。AI 可以幫忙把東西做出來，但到底算不算「好設計」，還是要人來判斷。

Nielsen Norman Group 也指出，目前 AI 設計工具最有用的地方，多半是處理窄範圍的任務，例如產生 placeholder 內容、協助整理元件，而非取代整套 UX 流程。這也意味著，越能站在「策略與體驗」這種高度的設計師，越不容易被取代。

如果你現在還是設計系學生、或剛開始接觸 UI/UX，我認為其實不用急著把每一套 AI 工具都學到精。比較實際，也比較重要的是先練好：

• 把需求講清楚、寫清楚的能力（不管是中文還是英文）；
• 看到一個介面時，能說出「為什麼這裡怪怪的」的分析力；
• 願意把 AI 當隊友，一起多做幾版，快速測試與迭代。

當我們能用語言設計介面、用原型說服世界的時候，AI 就不再是來搶飯碗的，而是幫我們把時間留給真正有趣、真正需要創造力的那一塊。說白一點，設計師正從親手把所有東西畫出來的工匠，慢慢變成協調 AI 一起完成設計的總監。少一點重複勞動，多一點在策略、體驗和品味上的決定。

參考資料

1. Pine, B. J., & Gilmore, J. H. (1999). The Experience Economy: Work Is Theatre & Every Business a Stage. Harvard Business School Press. https://www.researchgate.net/publication/292752215_The_experience_economy_work_is_theatre_every_business_a_stage_goods_and_services_are_no_longer_enough
2. Megan Brown, Caleb Sponheim, & Taylor Dykes (2025). AI Design Tools Are Marginally Better: Status Update. Nielsen Norman Group. https://www.nngroup.com/articles/ai-design-tools-update-2/
3. RiseCreatives（2025）。〈無代碼開發平台會取代傳統網頁設計師嗎？AI 時代的設計職涯疑惑〉。RiseCreatives 設計創業誌。https://risecreatives.co/artificial-intelligence/%E7%84%A1%E4%BB%A3%E7%A2%BC%E9%96%8B%E7%99%BC%E5%B9%B3%E5%8F%B0%E6%9C%83%E5%8F%96%E4%BB%A3%E5%82%B3%E7%B5%B1%E7%B6%B2%E9%A0%81%E8%A8%AD%E8%A8%88%E5%B8%AB%E5%97%8E%EF%BC%9Fai%E6%99%82%E4%BB%A3%E7%9A%84/
4. Lovable. Lovable — AI-powered No-code App Builder. 官方首頁。https://lovable.dev
5. 島上人蔘（2025）。〈AI會如何取代設計師？要如何應對？〉。方格子專欄文章。https://vocus.cc/article/67ee3230fd897800016b45cd
6. Reddit /r/userexperience (2024). Rapid prototyping with AI is quietly changing how our UX team works. https://www.reddit.com/r/UXDesign/comments/1j77kix/rapid_prototyping_with_ai_changing_ux_work
7. Kiran Sajjad (2025). The Designer’s Guide to AI Prompting. Emumba / Medium。https://blog.emumba.com/the-designers-guide-to-ai-prompting-478da5cb3de1
8. The Adalo Team (2025). 14 Low-Code Use Cases for Most Industries in 2025. Adalo. https://www.adalo.com/posts/low-code-use-cases