Vibe Coding 網頁設計實戰：用 Flow 與 Firebase Studio 零成本打造 3D 視覺網站
Vibe coding 架站是用自然語言描述需求、讓 AI 直接生成可執行網站專案的開發方式，套到架站場景，等於你不用碰 HTML、CSS、JavaScript，也能產出一個能瀏覽…
Vibe coding 架站是用自然語言描述需求、讓 AI 直接生成可執行網站專案的開發方式，套到架站場景，等於你不用碰 HTML、CSS、JavaScript，也能產出一個能瀏覽、能部署的網站。整套流程拆開來看就是一條流水線：AI 生成視覺素材、AI 生成程式碼專案、版本控制、一鍵部署，按順序跑通就能在一天內做出有 3D 感、可上線的網頁，而 Google、Anthropic、OpenAI 三家把程式碼生成列為主力戰場，工具成熟度已經跨過了「能跑」的門檻（依 Google DeepMind、Anthropic、OpenAI 近期的產品路線與發布內容觀察）。
重點先看：vibe coding 架站不是一句 prompt 生出網站，而是「素材 → 程式碼 → 版本控制 → 部署」四段流水線，hero 影片不壓縮就上線會直接拖垮 Core Web Vitals 與 Google 排名（Google Search Central 已將 Core Web Vitals 列為排名信號之一）。
很多人第一次聽到 vibe coding 網頁設計，腦中浮現的是「打幾個 prompt 就生成網站」的畫面。老實說，這個想像對了一半，也錯了一半。對的那半是：你真的不用寫程式；錯的那半是：它不是萬能許願機。真正決定成敗的，是你能不能把素材、程式碼、部署三個環節分清楚，並且接受生成結果還是要手動微調這個事實。要拆解的，就是把這條流水線跑通的完整流程，從 Vibe Coding 是什麼的完整入門觀念 到 從主機選擇到建站的完整自學指南，一路接到實際部署上線。如果你是剛接觸 AI 寫程式的完全新手，先建立基本概念再跟著這條流水線走，會更清楚每個環節在解決什麼問題。
Vibe Coding 架站是什麼？為什麼 2026 年值得學
Vibe coding 是用自然語言描述需求、讓 AI 直接生成可執行程式碼的開發方式，套到架站場景，等於你不用碰 HTML、CSS、JavaScript，也能產出一個能瀏覽、能部署的網站專案。重點在「會不會描述需求、會不會審稿」，這比「會不會寫程式」更關鍵。你擔任的是需求描述者加上審稿者的雙重角色，這個身分轉換比學會任何一行語法都重要。生成的程式碼你看得懂，就能微調；看不懂，就只能被動接受工具給的結果，而 AI 偶爾會給出有問題的程式碼，這時候審稿能力就成了最後一道防線。
很多人會把它跟 Wix 與 WordPress 架站平台的深度比較 拿來類比，但兩者本質不同。WordPress、Wix 這類是組裝現成模組，你選版型、裝外掛、填內容；vibe coding 是從無到有生成程式碼，自由度高很多，相對代價是你得看得懂結果、會微調。如果你過去用過 5 步驟打造專業形象網站的入門教學 那種模組化流程，會發現 vibe coding 的邏輯完全相反：你先講要什麼，工具生給你，你再修。
2026 年為什麼特別值得學？因為三家一線 AI 公司都把程式碼生成當成主力戰場，工具成熟度跨過了「能跑」的門檻，進入「能交付」的階段。這跟 7 款 AI 網站建立工具的實測比較 裡的前代工具落差明顯，過去你生成的東西常常跑不起來，現在多數能直接部署。業界的投入也反映了這個趨勢：根據行銷人員的回報，已有相當比例的人把 AI 用在內容與素材產製上，顯示 AI 工具鏈已從實驗階段進入日常作業 [來源：HubSpot State of Marketing Report〈https://www.hubspot.com/state-of-marketing〉〈2026〉]。不過話說回來，能跑不等於能用，後面會講到這條界線畫在哪。
- 核心定義：用自然語言（中文也行）描述網站長相與功能，AI 工具回傳完整專案檔，而不是片段語法。
- 和傳統寫程式的差別：你不再逐行寫碼，而是擔任需求描述者與審稿者的雙重角色。
- 和模組化架站的差別：後者是組裝現成模組，vibe coding 是從無到有生成程式碼，自由度高但要會看懂結果、會微調，這點跟 寫程式、租用平台、自架等多種架站方式比較 裡的分析一致。
- 為什麼現在熱：三家一線 AI 公司把程式碼生成列為主力戰場，工具成熟度跨過了能跑的門檻（可見於 Google DeepMind、Anthropic、OpenAI 的產品發布與路線）。
- 適合誰：行銷人、設計師、想快速做 demo 的創業者很合；要長期維護大型電商、要嚴格資安控管的人則要審慎評估。
講了這麼多，到底哪些人該碰？如果你是行銷人、設計師、個人品牌工作者、接案者，想做網站但不想從頭學 HTML/CSS，這條路對你很友善。但如果你是要長期維護大型電商、要做嚴格資安控管的系統，那還是回到 30 分鐘快速架好 WordPress 網站 加外掛、或直接委外開發更穩。把工具放對位置，比追新工具本身重要。
整體流程拆解：從素材到上線的五個環節
一條完整的 vibe coding 架站流水線可以拆成五段：先用 Flow 生成視覺素材與動態影片，再把影片壓縮，接著用 Firebase Studio 描述需求生成網站專案，然後把專案推上 GitHub，最後用 Netlify 一鍵部署上線。Google Flow 和 Firebase Studio 各自負責的事完全不同，前者管素材質感，後者管程式碼生成，把兩者搞混或順序顛倒，是新手最常卡住的原因。
很多人以為 3D 質感是架站工具本身做出來的，其實不是。3D 感主要來自首圖動畫素材（也就是 Flow 生成的影片），架站工具只是把這個素材放進網頁而已。這個認知差異很重要，因為它決定了你該先做哪一步。把工具順序想成「先做動畫再做網站」，才是差異化的關鍵，這跟 17 個免費 3D 素材資源網站 背後的邏輯一樣：素材質感才是視覺的核心。
| 環節 | 工具 | 負責的事 | 不做會怎樣 |
|---|---|---|---|
| 素材 | Google Flow | 生成首圖、結尾圖、動態影片 | 網頁沒質感、視覺空洞 |
| 壓縮 | mp4 轉檔工具 | 把影片體積降到可接受範圍 | 首屏載入慢、傷 SEO |
| 程式碼 | Firebase Studio | 用自然語言生成完整網站專案 | 沒有可部署的程式碼 |
| 版本控制 | GitHub | 儲存專案、可回溯、可換裝置 | 成果只放在一台機器上 |
| 部署 | Netlify | 接 GitHub 自動建置上線 | 網站永遠只在本地 |
- 環節一（素材）：Google Flow 負責生成首圖、結尾圖與動態影片，解決「網頁要有質感但我不會做動畫」的問題，這跟 Lottie 動畫取代 GIF 的輕量網頁動畫方案 是不同路線的解法。
- 環節二（壓縮）：mp4 檔案體積直接影響載入速度，部署前一定要先壓，這點可以對照 15 款圖片壓縮工具實測推薦 對圖片的處理邏輯。
- 環節三（程式碼）：Firebase Studio 用自然語言生成完整專案，是整條流水線的大腦。
- 環節四（版本控制）：推上 GitHub 不是儀式，是讓你能回溯、能換裝置繼續做的關鍵。
- 環節五（部署）：Netlify 接上 GitHub 後，每次推送都會自動重新上線，部署原本要碰伺服器，在這套流程裡只需點幾下。
這五段不是建議，是順序。我見過太多人跳過壓縮直接部署，結果網站慢到沒人想等；也見過人跳過 GitHub，把整包專案放在桌機，換台電腦就從頭來過。每一段都對應一個具體問題，少一段就少一個保險。接著逐段拆開。
步驟一：用 Google Flow 生成首圖與動態影片
Google Flow 能從一段文字描述生成圖片，再進一步把圖片串成動態影片，只要把想要的風格、構圖、顏色講清楚，就能拿到可直接放進網頁 hero 區的視覺素材。它是 Google 最新的 AI 影片生成工具，不只能生成單張圖片，更能製作流暢的動態影片（依 Google Flow 產品頁說明）。
生成順序很固定：先產起始圖與結尾圖，再讓 Flow 把兩張圖補幀成流暢的過場動畫。這跟 用 Immersity AI 把 2D 圖變 3D 動畫 的做法概念相近，都是用兩個關鍵畫面讓 AI 補中間。差別在 Flow 是 Google 原生工具，跟後面的 Firebase Studio 整合度更高，這也是這套流程選擇它的主要原因，勝過其他影片生成工具。
prompt 寫法是這一步成敗的關鍵。泛泛的描述會給你泛泛的結果，明確指定主體、視角、光線、色調、3D 質感詞（例如 soft studio light、clay render），品質會穩定得多。這跟 AI 繪圖搭配 ChatGPT 做網頁設計 裡提的 prompt 原則相通：越具體，AI 越知道你要什麼。輸出格式上，圖片用高解析，影片輸出 mp4，方便後續壓縮與嵌入。
實際下 prompt 時，把一段需求拆成「主體＋動作＋環境＋鏡頭＋光線＋風格」六個欄位會比一句話通包更穩。以一個活動報名頁為例，主體可以是一顆會旋轉的 3D 幾何球體，動作是緩慢自轉與上下漂浮，環境是純色漸層背景，鏡頭是正面平視的微距特寫，光線是柔和的攝影棚打光，風格是 clay render 加上低彩度配色。把這六個欄位寫滿，Flow 給出的版本通常只要微調就能用；只寫「做一個有質感的球體動畫」，往往要反覆重生成好幾次才勉強能用。欄位拆解的好處是除錯容易：畫面不對時，你能精確指出是光線還是構圖出問題，省下整段重來的工夫。
- 生成順序：先產起始圖與結尾圖，再讓 Flow 補幀成流場動畫，兩張圖的風格要先對齊。
- prompt 寫法：明確指定主體、視角、光線、色調、3D 質感詞，品質比泛泛描述穩定得多，可參考 Figma 載入動畫與流動效果製作 對動態質感的處理思路。
- 輸出格式：圖片用高解析，影片輸出 mp4，方便後續壓縮與嵌入網頁。
- 常見坑：風格不一致、人物手指或文字變形，建議同一組素材重複生成挑最穩的版本，不要急著用第一張。
- 版權與商用：使用前確認當下 Flow 的商用授權條款，政策會更新，不要假設舊規則仍有效（以 Google Flow 產品頁的授權說明為準）。
常見的坑有兩個：一是風格不一致，第一張圖跟結尾圖色調對不上，補幀出來的動畫就會有違和感；二是人物手指或文字變形，這是 AI 生成影像的老問題。我的做法是同一組素材重複生成個幾次，挑最穩的版本，不要急著用第一張。這個步驟的標準跟你挑 30 個商用免費圖庫網站素材 是一樣的：寧可多生成幾輪，也不要把不穩的素材硬放上線。另外要注意 hero 動畫的時長，控制在五到八秒內、能在畫面停留夠久又不佔太多頻寬，是最理想的範圍；超過十秒的動畫既浪費流量，也容易讓訪客在等待中離開。
mp4 檔案壓縮：hero 影片上線前的必做事
AI 生成的 mp4 動輒數十 MB，直接放進網頁會拖慢首屏載入、傷 SEO 也傷體驗，部署前一定要用壓縮工具把體積降到可接受範圍再上線。這一步看起來無聊，卻是新手做 vibe coding 網站最常踩的地雷，檔案動輒數十 MB，會直接反映在 Core Web Vitals 與 Google 排名上（Google Search Central 將 Core Web Vitals 列為排名信號之一）。
不壓會怎樣？網頁打開後白屏、轉圈，訪客等不到就直接關掉。這不是小事，載入速度是 Google 排名因子，首屏影片過大會直接反映在 Core Web Vitals 的 LCP 指標上，這點在 Core Web Vitals 的 LCP INP CLS 優化 講得很清楚。你前面花心力做好的動畫，可能因為沒壓縮，反而讓排名往下掉，等於自己打自己。
速度與轉換的關聯早有實證。公開的案例顯示，Vodafone 把 LCP 改善約三成，銷售隨之提升； Rakuten 24 投入 Core Web Vitals 優化後，每位訪客營收與轉換率都明顯上升；The Economic Times 通過 Core Web Vitals 門檻後，整體跳出率改善了約四成 [來源：web.dev〈https://web.dev/articles/why-speed-matters〉〈2026〉]。換句話說，hero 影片不壓縮，吃掉的不只是排名，還有實實在在的轉換與營收。
| 項目 | 建議 | 原因 |
|---|---|---|
| 目標體積 | hero 影片壓到個位數 MB 以內 | 越低載入越快，前提是畫質還能看 |
| 格式 | mp4（H.264）為主 | 相容性最好，所有瀏覽器都能播（依 W3C 與 MDN 的媒體格式文件） |
| 更小體積 | 評估 WebP 動畫或影片延遲載入 | 追求極致速度時的進階選項 |
| 行動版策略 | 手機版改用靜態圖 | 避免手機用戶吃滿流量 |
| 載入策略 | hero 影片設延遲載入 | 不阻塞首屏，可參考 Lazy Loading 延遲載入提升網站速度 |
壓縮工具用線上轉檔或本機軟體皆可，重點是能調 bitrate 與解析度。格式選擇上，mp4（H.264）相容性最好，所有瀏覽器都能播（依 W3C 與 MDN 的媒體格式文件）；追求更小體積可以評估 WebP 動畫，不過相容性要自己測過。這跟 WebP、JPG、PNG 圖片格式深度比較 裡對圖片格式的取捨邏輯一致：沒有絕對最好的格式，只有最適合當下場景的選擇。
講個實際的，我曾看過一個 hero 影片 45 MB 直接上線的案例，手機端開啟要等八秒，跳出率高得嚇人，後來壓到 6 MB 行為指標才回穩。部署前壓到個位數 MB 以內是基本動作，沒得討論。如果你想更進一步優化，可以接 CDN 加速網站的原理與服務推薦 或 快取 Cache 是什麼與清除設定，但那已經是壓縮之後的事了。
手機流量是另一個不能忽略的因素。根據近期的統計，手機裝置占了全球網站流量的一半以上，桌面流量已經不是多數 [來源：Statista〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉]。換句話說，你優化 hero 影片時，第一個要顧的就是手機版體驗。實務做法是給手機版一個較小的影片或直接換成靜態首圖，桌機版才放完整動畫。這可以用媒體查詢或前端框架的斷點機制做到，關鍵在於不要讓手機用戶下載跟桌機一樣大的檔案。
壓縮時常見的判斷點有三個。第一，解析度該降到多少：hero 影片通常不需要 4K，1080p 甚至 720p 在多數螢幕上已經夠看，降一階就能省下大量體積。第二，bitrate 該設多少：bitrate 越低檔案越小，但低到一個程度畫面會出現色塊與雜訊，建議從中等數值開始試，前後對比再決定。第三，音軌要不要留：hero 動畫多半不需要聲音，砍掉音軌往往能再省一成以上的體積。這三個判斷點沒有固定答案，依你的畫質要求與頻寬預算取捨。
步驟三：用 Firebase Studio 用自然語言生成網站專案
Firebase Studio 是 Google 推出的 AI 全端開發環境，你用中文或英文描述網站要長怎樣、要哪些區塊，它直接回傳一個可執行的專案檔，這就是 vibe coding 的核心步驟。它跟其他 AI 寫程式工具比起來，強在「生成的是完整專案，不是片段語法」，這也是為什麼這套流程選它當程式碼環節的大腦（依 Firebase Studio 產品頁說明）。
操作方式很直覺：在開發環境裡用自然語言下需求，例如「做一個有 hero 動畫、服務介紹、聯絡表單的一頁式網站」，它邊生成邊預覽。第一版通常不完美，但你不需要從頭重寫，用對話方式要求改配色、改排版、修文字，迭代速度比傳統開發快很多。這個「對話式迭代」是 AI 架站最大的效率來源，跟你用 ChatGPT 新手註冊到進階技巧教學 改文章是同樣的邏輯。
- 操作方式：用自然語言下需求，例如做一個有 hero 動畫、服務介紹、聯絡表單的一頁式網站，工具邊生成邊預覽。
- 迭代修正：第一版通常不完美，用對話方式要求改配色、改排版、修文字，比從頭重寫快，這點跟 Claude Code 零基礎 AI 自動化開發教學 的迭代節奏一致。
- 素材整合：把步驟一、二做好的影片與圖片放進專案，取代預設佔位圖，質感才會出來。
- 能改程式碼嗎：可以，生成的程式碼是可讀的，會基礎前端的人能直接手改細節。
- 免費額度與限制：Firebase Studio 有免費方案與額度上限，長期使用前先確認當前計價模式，政策會調整，以 Firebase Studio 官方定價頁為準。
很多人會問，生成的程式碼能自己改嗎？答案是能。生成的程式碼是可讀的，不是黑箱，會基礎前端的人可以直接手改細節，這也是它跟 Gemini Stitch 做 AI 網頁設計的實戰 或純對話型工具的差別。但要注意，AI 可能產出錯誤程式碼，這在 AI 幻覺成因與避免技巧解析 講過，生成的東西一定要自己跑過一遍、看過一遍，不能全信。
免費額度這件事要特別提醒。Firebase Studio 有免費方案與額度上限，長期使用前先確認當前計價模式，政策會調整，以 Firebase Studio 官方定價頁為準。不要假設今天免費、明天還是免費。如果你會用到大量 token，可以先看 AI Token 計算邏輯與省錢技巧，把用量抓在額度內。
把需求講清楚的進階技巧
用 Firebase Studio 生成網站，最大的變數不在工具，而在你給的需求有多具體。一段模糊的需求會得到一個模糊的網站，而一段結構化的需求會得到一個接近成品的網站。把需求寫好的關鍵，是把自己當成在跟一個聽話但沒讀過你心思的工程師 brief 任務，把目標、內容、互動、視覺、邊界條件都講清楚。
- 頁面結構：列出每一段落的標題、用途與順序，例如 hero（首圖動畫加一句主標）、關於我們（三段文字配兩張圖）、服務項目（卡片式三欄）、聯絡表單（姓名、信箱、訊息三欄位）。
- 互動行為：明確指定滾動動畫、按鈕點擊回饋、表單送出後的訊息，避免工具自己揣測而做出你不想要的特效。
- 視覺規範：指定主色、輔色、字型風格、圓角大小、陰影強度，色碼直接給 hex 值最準確。
- 內容素材：把步驟一做好的影片、圖片明確標註要放在哪一段落，取代預設佔位圖。
- 邊界條件：聲明哪些東西不要做，例如不要彈出視窗、不要自動播放音訊、不要用特定配色，這類排除指令能省下很多事後修改。
迭代時有個節奏建議：一次只改一類問題。同一輪對話裡同時要求改配色、改排版、改文案、改互動，工具容易把前一項的修改跟後一項的指令混在一起，結果四項都改不完整。把修改拆成多輪，每輪聚焦一個面向，確認沒問題再進下一項，整體反而更快。這個節奏跟人工接案改稿其實一樣：需求越亂、越急著一次到位，來回的次數就越多。
另一個實用的做法是先要結構、再要視覺。第一輪只要工具把頁面區塊、文字內容、互動邏輯生出來，視覺先用預設樣式；結構確認無誤後，第二輪才下視覺指令調配色、字型、間距。這樣拆的好處是，當結果出問題時你能立刻判斷是結構錯還是視覺錯，除錯成本大幅降低。一開始就把所有需求糊成一團丟出去，是新手最常犯、也最難收尾的錯誤。
生成後的檢查清單
Firebase Studio 把專案生給你之後，不要直接推上線，先過一遍檢查清單。AI 生成的網站常見的問題有跡可循，逐項檢查比憑感覺更可靠。
- 跑得起來：在本地預覽能正常開啟，沒有 console 報錯，所有區塊都有渲染出來。
- 文字無錯字：AI 有時會把佔位文字、假資料留在頁面上，逐段點開檢查實際內容。
- 連結有效：導覽列、按鈕、頁尾連結都能點到對的位置，沒有死連結或指向佔位網址。
- 表單可用：聯絡表單欄位能填、能送出、送出後有回饋訊息，後端有沒有接好要另外確認。
- 行動版排版：縮到手機寬度時，文字不會溢出、按鈕不會擠在一起、圖片不會破版。
- 圖片有壓：素材圖片體積合理，hero 影片已經過壓縮，沒有把原始大檔直接塞進去。
- SEO 基礎：title、meta description、圖片 alt 文字都填了，這部分可以對照 SEO 友善的網站結構設計心法。
步驟四：把專案推上 GitHub，建立版本控制
把專案推上 GitHub 不是多餘動作，而是讓你的網站有版本紀錄、能隨時回溯、能讓 Netlify 自動抓取部署的基礎，跳過這一步等於把成果只放在一台機器上。對零基礎的人來說，GitHub 介面確實有門檻，但你只要學會基本的 add、commit、push 三步驟就夠用，不需要變成 Git 專家。
為什麼不推不行？兩個理由。第一，改壞了能回上一版，這是長期維護的保險，AI 生成的程式碼不是每次都對，有版本紀錄你才敢放手改。第二，Netlify、Vercel 這類部署服務都接 GitHub，推上去之後自動化部署的基礎就在這。換個角度想，GitHub 同時扮演「備份」和「部署觸發器」兩個角色，一份檔案兩個用途，CP 值很高。基本流程是：建立 repository、把專案檔推上去、之後每次更新 push 即可。
- 版本控制價值：改壞了能回上一版、換電腦也能繼續做，是長期維護的保險。
- 基本流程：建立 repository，把專案檔推上去，之後每次更新 push 即可。
- 公開 vs 私有：含敏感資訊的專案設私有，純展示可設公開；注意不要把 API key 一起推上去（GitHub 官方安全建議亦如此提醒）。
- 與部署的串接：推上 GitHub 後，Netlify、Vercel 這類服務都能直接接，自動化部署的基礎就在這。
- 新手友善度：GitHub 介面對零基礎者有門檻，但只要學會基本的 add、commit、push 三步驟就夠用。
一個小提醒：含敏感資訊的專案設私有，純展示可設公開，而且絕對不要把 API key 一起推上去（GitHub 官方安全建議亦如此提醒）。這聽起來是常識，但每個月都有人因為把金鑰推到公開 repo 而出事。如果你對檔案管理還不熟，可以先看 WordPress FTP 檔案上傳與站台設定 對檔案結構的基本觀念，雖然場景不同，但「檔案該放哪、哪些不能上傳」的邏輯是相通的。
推上 GitHub 之後，整個專案就從「只存在你電腦裡」變成「有版本、可共享、可觸發部署」。到這裡，下一步 Netlify 要抓取的來源已經就位。
commit 訊息與回溯的實用習慣
很多人學會 push 之後就停了，commit 訊息隨便打幾個字交差。問題在於：當你三天後想回上一版，看到一堆「update」「fix」「test」的訊息，根本分不清哪一版做了什麼，回溯形同失效。養成在 commit 訊息寫清楚「這次改了哪一段、為什麼改」的習慣，回溯時才派得上用場。訊息不必長，但要能讓三個月後的自己看懂，例如「把 hero 影片換成壓縮後的 6MB 版本」就比「update video」有用得多。
另一個實用做法是每完成一個段落就 commit 一次，不要等到改了一大堆才一口氣推上去。頻繁小批次的 commit，讓每一個版本都對應一個清楚的階段，要回溯時能精準挑到對的節點；一次推一大包，回溯時只能整包退回，連帶把沒問題的部分也一起退掉。這個習慣在 AI 架站尤其重要，因為 AI 每次生成的結果差異大，你能清楚標記每一版用了什麼 prompt、做了什麼修改，日後要重現某個效果才有依據。
Netlify 部署上線
把 GitHub 接上 Netlify，第一次設定好之後，每次你推送新版本，Netlify 都會自動重新建置並上線，部署這件原本很技術的事，在這套流程裡只剩點幾下的動作。它有免費方案夠個人專案用，流量大或需要進階功能再評估付費方案（依 Netlify 官方定價頁）。
部署流程只有三步：Netlify 連結 GitHub repository、選擇 build 指令、自動產生線上網址。第一次跑通後，之後只要 push 新 commit，Netlify 自動重新部署，不用手動操作。這對零基礎的人來說是最大的解脫，因為你不用碰伺服器、不用設 DNS（Netlify 會給你一個預設網址）、不用管 SSL（Netlify 自動加上）。想要自訂網域，可以綁自己買的網域上去，這部分對照 網域申請購買到 DNS 設定的全攻略 或 Namecheap 網域註冊與免費 SSL 設定 來做即可。
- 連結 GitHub repository、選 build 指令、拿到的自動產生網址就是線上成果，第一次跑通後只要 push 新 commit 就會自動重新部署。
- 預設網址先用沒問題，要正式對外就把自己買的網域綁上去，設定方式照 DNS 網域名稱指向設定教學 走。
- SSL 不用自己裝，Netlify 自動附上免費憑證，相關觀念可看 SSL 憑證的免費與付費比較安裝 與 HTTP 換 HTTPS 的安全與 SEO 提升。
- 免費方案夠個人專案用，流量大或需要進階功能再評估付費方案（依 Netlify 官方定價頁）。
常見問題是 build 失敗，多數是路徑或指令設錯，看 Netlify 的部署 log 通常能直接定位，不用瞎猜。如果你之後想做更完整的效能追蹤，可以接 5 大免費網站速度檢測平台比較 或 網站速度優化的 5 大核心技巧，確認上線後的體驗。到這一步，整條流水線就跑完了，網站正式對外。
build 失敗怎麼排查
第一次接 Netlify 時，build 失敗是新手最常卡住的關卡。失敗訊息看起來嚇人，但九成的問題可以歸類成幾個原因。逐項排查比反覆重試更有效率。
- build 指令設錯：Netlify 要你指定用什麼指令建置專案，指令跟你的前端框架有關，設錯就會直接 build 失敗。確認指令與框架文件一致是第一步。
- publish 目錄設錯：建置完成後的靜態檔案放在哪個資料夾，要正確指定，否則 Netlify 找不到檔案會部署一個空站。
- 依賴沒裝好：專案用的套件在本地能跑、在 Netlify 卻缺漏，多半是套件清單沒有同步更新，把鎖定檔一起推上去通常能解決。
- 環境變數沒設：用到 API key 或後端網址時，本地靠 .env 檔讀取，但 .env 不會推上 GitHub，要在 Netlify 後台手動設定同名的環境變數。
- 路徑大小寫：本機檔案系統不分大小寫，Netlify 的建置環境分大小寫，本機能跑的路徑在 Netlify 可能報錯，統一用小寫命名可避開。
排查時的訣竅是直接看 Netlify 後台的部署 log，從最後一行報錯往回讀，通常能找到具體是哪一個檔案、哪一行出問題。報錯訊息直接拿去搜尋，多半能找到別人遇過相同狀況的解法。不要在沒看 log 的情況下反覆重新部署，那只會得到一樣的結果。
vibe coding 架站的成本、限制與你該不該選它
整套流程在工具免費額度內幾乎可以零成本跑通，真正的成本是時間與學習曲線，但它不適合需要長期大量維護、嚴格資安、或複雜電商流程的場景，選擇前要看清這條界線。說到底，工具的價值取決於你把它放對位置，而它本身多強只是緊追在後的是。
| 面向 | vibe coding 架站 | WordPress / Wix 模組化 |
|---|---|---|
| 金錢成本 | 免費額度內多數零成本 | 主機、網域、進階外掛長期要付費 |
| 時間成本 | 第一次半天到一天，熟練後更短 | 學習曲線較長，外掛設定耗時 |
| 自由度 | 從無到有生成，自由度高 | 受限版型與外掛生態 |
| 長期維護 | 生成程式碼要會看懂才能維護 | 生態成熟，維護資源多 |
| 適合場景 | 作品集、活動頁、landing page | 長期經營、電商、內容站 |
- 金錢成本：Flow、Firebase Studio、GitHub、Netlify 都有免費層，個人專案通常不用花錢就能上線（以各工具官方定價頁為準）。
- 時間成本：第一次跑通整套流程可能要半天到一天，熟練後能壓到更短。
- 主要限制：生成結果仍需人工微調、AI 可能產出錯誤程式碼、複雜功能要回到傳統開發。
- 適合場景：作品集、活動頁、landing page、prototype、個人品牌官網，可參考 打造面試接案都好用的個人網站 與 Elementor 製作高轉換 Landing Page。
- 不適合場景：大型電商、金流物流串接密集、需嚴格權限與資安控管的系統，這類需求 企業形象網站 用 WordPress 加外掛或委外開發更穩。
退一步看，vibe coding 架站最適合的場景是作品集、活動頁、landing page、prototype、個人品牌官網，這些共同特徵是「生命週期短、變動頻繁、需要快速迭代」。如果你做的是 一頁式網頁設計的高轉換做法 或 用 Astra 打造專業形象網站 這類需求，vibe coding 的速度優勢很明顯。但如果是大型電商、金流物流串接密集、需嚴格權限與資安控管的系統，這類需求 WordPress 加外掛或委外開發更穩，硬套 vibe coding 只會自找麻煩。
決策矩陣：什麼情況該選 vibe coding 架站
到底要不要用 vibe coding 架站，可以用兩個維度來判斷：第一是網站的「生命週期長短」，第二是功能的「複雜度高低」。把這兩個維度畫成四個象限，每個象限對應一種最適合的做法。這個矩陣不是絕對答案，但能幫你在動手前先做一次快速自檢，避免選錯工具白忙一場。
| 象限 | 生命週期 | 功能複雜度 | 建議做法 |
|---|---|---|---|
| 一 | 短（活動、prototype） | 低（展示為主） | 強烈建議 vibe coding，速度快、成本低 |
| 二 | 短 | 高（表單、金流） | vibe coding 做外殼，複雜邏輯另外接服務 |
| 三 | 長（長期經營） | 低（內容站） | WordPress 等模組化系統，維護資源完整 |
| 四 | 長 | 高（電商、會員） | 委外開發或成熟電商平台，vibe coding 不適合 |
用這個矩陣時，關鍵是誠實評估你專案的真實需求，別被你「希望」的需求帶偏。很多人高估了自己網站的複雜度，結果用 vibe coding 做一個其實很簡單的展示頁，反而繞遠路；也有人低估了長期維護的負擔，用 vibe coding 起手一個月後才發現每改一次都要重理解生成碼。把生命週期與複雜度先想清楚，工具的選擇就會自然浮現。
AI 生成的網站 SEO 會比較差嗎？這是很多人擔心的。SEO 差不差跟生成方式無關，跟你有沒有做 SEO 友善的網站結構設計心法、有沒有做 圖片 SEO 優化的命名壓縮與標記、有沒有接 結構化資料 Schema 標記教學 有關。生成出來的網站，該做的 SEO 一樣要做，不會因為是 AI 寫的就有免死金牌。換句話說，工具幫你省下寫程式的時間，你要把那時間花在 SEO 跟內容上，才不會白白浪費這條流水線的效率。
什麼情況不該用 vibe coding 架站
vibe coding 適合的場景講了很多，反過來看，有些情況用了只會更糟。把這些地雷記下來，比記住所有優點更實用。
- 要處理金流與個資：牽涉到信用卡、個資、交易紀錄的系統，安全規範嚴格，AI 生成的程式碼未經審計，風險過高。
- 需要長期多人協作：多人共同維護、權限分層的系統，生成碼的可讀性與一致性不一定能撐住長期協作。
- 功能會持續擴張：預期會不斷加新功能、新模組的系統，vibe coding 起手容易，但每次擴張都要回頭理解舊的生成碼，長期成本會疊加。
- 有合規與稽核需求：受產業法規規範、需要留下開發與變更紀錄的系統，生成流程的不可預測性會成為稽核障礙。
- 穩定性要求極高：不能容忍偶發錯誤的關鍵服務，AI 偶爾產出的錯誤程式碼會成為單點失敗來源。
遇到上述情況，回到成熟的模組化平台或委外開發才是穩當的選擇。vibe coding 的價值在「快」與「自由」，而這兩個優點在需要「穩」與「可控」的場景裡反而會變成負債。把工具放對位置，比把工具用到極限更重要。
vibe coding 架站上線前的檢查清單
把網站推上 Netlify 之前，過一遍完整的檢查清單，能避開上線後才發現問題的窘境。這份清單把前面各步驟的關鍵檢查點彙整在一起，逐項打勾再部署，比憑感覺判斷可靠得多。
視覺與素材
- hero 影片已壓縮到個位數 MB 以內，行動版改用靜態圖或更小檔案。
- 所有圖片都壓過，沒有原始大檔直接上線。
- 各段落的視覺風格一致，沒有色彩或字型突然變調。
- 佔位圖與假資料已全部替換成正式素材。
功能與互動
- 所有導覽連結都能點到對的區塊或頁面，沒有死連結。
- 聯絡表單能填、能送出，送出後有清楚回饋訊息。
- 按鈕與互動元素的點擊行為符合預期，沒有觸發非預期特效。
- 桌機與手機兩種寬度下，排版都沒有破版或溢出。
SEO 與效能
- title 與 meta description 已填寫，包含主要關鍵字。
- 所有圖片都有 alt 文字，描述圖片內容。
- 已加入結構化資料，可參考 結構化資料 Schema 標記教學。
- 用速度檢測工具跑過一次，確認 LCP、INP、CLS 都在合理範圍，可對照 5 大免費網站速度檢測平台比較。
- 已設定 HTTPS，SSL 憑證正常生效。
安全與維護
- 沒有把 API key 或敏感資料推上公開 repository。
- 專案已推上 GitHub，版本紀錄完整，能回溯。
- Netlify 後台的環境變數已設定好，部署能正常 build。
- 已確認 Netlify 自動部署的觸發正常，push 後能自動重新建置。
這份清單不是一次性的儀式，每次大改版上線前都值得重跑一次。養成習慣後，你會發現上線後的緊急修補大幅減少，而這正是專業開發與業餘試做最大的分野。
常見問題
vibe coding 是什麼？真的不用寫程式就能架站嗎？
是用自然語言描述需求、讓 AI 生成可執行網站專案的開發方式。你不用逐行寫碼，但要會描述需求、會看懂生成結果並微調，不是完全零介入。
Google Flow 和 Firebase Studio 各自負責什麼？
Flow 負責生成首圖、動態影片等視覺素材，決定網頁的 3D 質感；Firebase Studio 負責用自然語言生成完整網站專案，是程式碼環節的大腦。兩者順序不能顛倒。
vibe coding 架站要花錢嗎？
Flow、Firebase Studio、GitHub、Netlify 都有免費層，個人專案通常零成本就能跑通，真正的成本是第一次的學習時間，約半天到一天（以各工具官方定價頁為準）。
用 AI 生成的網站可以上線嗎？要怎麼部署？
可以。把專案推上 GitHub，再接 Netlify，第一次設定後每次 push 都會自動重新部署，不需要碰伺服器，Netlify 也自動提供免費 SSL 與預設網址。
mp4 影片檔案太大怎麼壓縮？
用可調 bitrate 與解析度的轉檔工具，把 hero 影片壓到個位數 MB 以內。不壓會拖慢首屏載入、傷 Core Web Vitals 與 Google 排名（Google Search Central 將 Core Web Vitals 列為排名信號之一）。
Firebase Studio 生成的程式碼能自己改嗎？
能。生成的是可讀程式碼，不是黑箱，會基礎前端的人可直接手改。但 AI 可能產出錯誤程式碼，改完一定要自己跑過、看過一遍。
vibe coding 適合哪些人？哪些人不適合？
適合行銷人、設計師、個人品牌工作者、接案者，以及想快速做 demo 的創業者；不適合要做大型電商、複雜金流物流、嚴格資安控管的長期系統。
AI 生成的網站 SEO 會比較差嗎？
不會。排名好壞看的是結構、圖片優化、結構化資料這些基本功有沒有做，跟網站是 AI 還是手寫無關。
Netlify build 一直失敗怎麼辦？
先看 Netlify 後台的部署 log，從最後一行報錯往回讀，定位具體出錯的檔案與行數。常見原因是 build 指令設錯、publish 目錄設錯、依賴沒裝好、環境變數沒設、路徑大小寫不一致，逐項排查通常能解決。
一定要用 GitHub 嗎？能不能跳過版本控制？
技術上可以跳過，但強烈不建議。GitHub 同時扮演備份與部署觸發器兩個角色，跳過等於把成果只放在一台機器上，改壞了無法回溯，換電腦也無法繼續做。學會基本的 add、commit、push 三步驟就夠用，不需要變成 Git 專家。
hero 影片不壓縮真的會影響排名嗎？
會。載入速度是 Google 排名因子，首屏影片過大會直接反映在 Core Web Vitals 的 LCP 指標上。公開案例也顯示速度優化能帶動轉換提升，不壓縮吃掉的不只是排名，還有實際轉換 [來源：web.dev〈https://web.dev/articles/why-speed-matters〉〈2026〉]。
回顧一下整條流水線：把 vibe coding 當成一條「素材 → 程式碼 → 版本控制 → 部署」的流水線來跑，比把 AI 當成萬能許願機，成功機率高出一個量級。差別就在你有沒有把四個環節分清楚、按順序做完。hero 影片沒壓縮就上線是最常踩的地雷，整套流程在免費額度內幾乎零成本就能跑通，真正的成本是時間與學習曲線。把這幾條記住，你就能判斷自己適不適合走這條路，而不是被工具的噱頭牽著走。