Gemini AI 網頁設計實戰：Stitch 搭配 Antigravity 打造令人驚艷的視覺網站
Stitch 加上 Antigravity 之所以能成為一套「一個人走完整條鏈路」的 AI 網頁設計流程，關鍵在於它把「想法、UI 設計、本機運行、AI 改程式碼、MCP 串接、推…
Stitch 加上 Antigravity 之所以能成為一套「一個人走完整條鏈路」的 AI 網頁設計流程，關鍵在於它把「想法、UI 設計、本機運行、AI 改程式碼、MCP 串接、推上 GitHub、自動部署」這 7 個步驟收攏進 Google 原生工具的閉環裡，多一個會畫介面的 AI 並不是重點。實際走一遍這條流程，從在 Stitch 打第一句 Prompt 到網站在 localhost 跑起來，整段大約只要 7 分多鐘，速度差來自工具之間的狀態彼此串通、不再各自獨立。真正決定能不能走通的，是後面那 80% 的本機運行、串接與部署工作，UI 漂不漂亮反倒是末節。
重點先看： Stitch 管「長得怎樣」，Antigravity 管「真的跑得起來」，中間靠 MCP（Model Context Protocol）把兩端專案狀態同步起來；Stitch 與 Antigravity 皆為 Google 推出的工具（前者做 UI 生成、後者是 agentic IDE），最後推 GitHub 交給 Vercel 自動部署。
Stitch 加 Antigravity 的三層分工
Stitch 是 Google 推出的 AI UI 生成工具，你丟一段自然語言給它，它就把網站類型、配色、元件組合成一份可預覽的視覺介面；Antigravity 則是 Google 的 agentic IDE，在 localhost 本機環境把那份 UI 跑成真實可瀏覽的網站，並用 AI 協助修改專案。兩者透過 MCP 串接後，等於把傳統設計師與工程師兩個人的工作，壓進同一條一個人能走完的流程。
很多人會把這組合想成「再多一個會畫網站的 AI」，但這個理解只摸到表層。市面上的 AI 網站建立工具 已經一大票，從 Kadence AI 到各式 架站平台 都會幫你拼介面。真正稀缺的是「漂亮的 UI 之後，誰來把它推進成能跑、能改、能部署的程式專案」。Stitch 把前 20% 的設計做完，Antigravity 接手後 80% 的運行與修改，這條分工才是這組合的差異化所在。
分工可以拆成三層來看。設計層：Stitch 負責「長得怎樣」，輸出的是 UI 設計稿而非最終網站。運行層：Antigravity 負責「真的跑得起來」，在 localhost 直接啟動即時預覽。黏合層：MCP（Model Context Protocol）是開放協定，讓兩個工具共享同一份專案脈絡，設計端改了，開發端不必重新描述就能讀懂。這三層合起來，判斷一組 AI 網頁設計工具能不能落地，標準就清楚了：關鍵在於這條鏈路有沒有被接起來，demo 看起來多驚艷反倒不是重點。
要留意的是，Stitch 和 Antigravity 都屬於 Google 生態，互通性高，但這同時意味著綁定同一家廠商。如果你已經習慣用 Claude Code 或 Vibe Coding 的方式工作，後面會談到 Stitch 的 MCP 其實也能接其他開發 agent，不必只能選 Google 全家桶。
這裡要先釐清一個容易被忽略的判斷維度：工具的「設計能力」和「工程能力」是兩回事，市面上多數 AI 架站工具把它們混在一起賣，結果是兩邊都不夠深。會生成漂亮的 hero 區、能套用品牌色、能預覽手機版面，這些屬於設計能力；能解析專案結構、能正確處理路由、能在不同螢幕寬度自動重排、能被部署平台辨識為可上線的程式，這些屬於工程能力。Stitch 偏前者，Antigravity 偏後者，MCP 負責把兩者黏起來。理解這個分工，才不會對任何一方抱持錯誤期待：拿 Stitch 去要求它把響應式邏輯一次寫對，或拿 Antigravity 去要求它生出讓客戶眼睛一亮的首頁視覺，都會失望。
Stitch 的 UI 生成與它的能力邊界
在 Stitch 裡的操作流程很直覺：用 Prompt 指令描述網站類型、目標對象、視覺風格，它就會生成對應 UI，包含版面配置、元件擺放、配色建議。重點是產出可即時預覽，你不滿意就用文字繼續微調，不必碰任何 網頁設計 軟體。它解決的是「不會畫介面、但清楚知道自己要什麼」這個痛點。
從輸入第一句 Prompt 到第一版 UI 產出，通常只要一到兩分鐘，中間還能直接看到重點功能區塊的雛形。這個速度對接案設計師來說很有感，過去用 Figma 或 Canva AI 從空白畫布開始拉版面，光一頁首頁就要來回改好幾輪；Stitch 把這段壓縮成幾句話的事。
不過話說回來，我也得承認一個限制：Stitch 生成的 UI 漂亮歸漂亮，但它不會憑空把 網頁版面設計 轉成符合 響應式網頁設計 RWD 標準的可運行專案。互動邏輯、網站架構、資料流這些，Stitch 頂多給你視覺暗示，真正要動手把專案跑起來，還是得進 Antigravity。把 Stitch 定位成「會做設計稿的 AI」，期待才會準。更現實地講，Stitch 處理的是畫面層，也就是使用者第一眼看到的那一層；至於畫面背後的元件怎麼組、資料從哪裡來、不同螢幕尺寸下怎麼自動重排，這些都屬於工程層的問題，AI 目前還沒聰明到給你 Prompt 就一次到位。
還有一點常被忽略：UI 設計的好壞，最終會回到你有沒有先想清楚 網頁設計必備的關鍵元素 與 設計趨勢。AI 幫你省掉拉版面的時間，但沒幫你想清楚「這個網站要解決誰的問題」。Prompt 寫得越具體，Stitch 給回來的東西越能用，這和用 ChatGPT 或 Gemini 寫內容是同一個道理。
把 Prompt 寫好，有幾個可以重複套用的原則。先交代網站的類型與目標對象，讓 Stitch 知道這是形象站、電商還是作品集，三者的版面邏輯完全不同。明確指定視覺風格的參考方向也很關鍵，例如「極簡、大量留白、深色主題」或「溫暖、圓角、插畫感」，這類描述比「好看」「專業」這種空泛形容詞更能讓模型抓到方向。實作上建議分批下指令，先把整體版面架構定下來，再針對單一區塊微調；一次把所有細節塞進同一句 Prompt，反而容易讓模型顧此失彼。另外把內容大綱先寫好再丟進去，AI 生成的版面會更貼近實際需求，因為它是在排版真實文字而非假字。這幾個原則套用在多數 AI 生成工具都通用，差別只在 Stitch 對「視覺風格」這個維度的回應特別靈敏。
另一個讓 Stitch 產出更實用的做法，是把 常見設計地雷 反過來當成 Prompt 的檢查清單。舉例來說，多數 AI 生成介面會把 hero 區做得太滿、CTA 按鈕不夠明顯、字級層級混亂，這些都是可以事後用一句「縮小 hero 圖、把主按鈕改成高對比色、標題加大一級」就修掉的問題。重點在於：你不要把第一版就當成最終版，而是把它當成一份草稿，再用兩三輪文字微調去逼近你要的樣子。多數人對 AI 設計失望，是因為只給一次機會，沒有走完那兩三輪調整。
Antigravity 本機運行
把 Stitch 產出的 UI 接進 Antigravity 之後，它會在本機 localhost 啟動網站、讓你直接在瀏覽器預覽，不必先部署才能看效果。本來要逐行手改程式碼的調整，像統一整個網站的選單結構、修復路徑錯誤的圖片，都能用自然語言請 AI 完成。這一步是「設計圖」落實成「實體網站」的分水嶺。
本機運行這段可以拆成幾件典型的細活來看：先在 localhost 把網站跑起來，接著用 Antigravity 統一整個網站的選單結構，再到修復破損或路徑錯誤的圖片。這三件事放在傳統流程裡，每一件都要設計師開 ticket、工程師改程式碼、再來回驗收；在 Antigravity 裡，你只要用一句「把所有頁面的選單統一成這個結構」就能交代下去。
Antigravity 的核心差異在於它的 agent 能理解整個專案結構，修改時會一併考慮連動影響，連帶相關檔案一起調整，不會只動你指到的那一行。這對 網頁設計自學 的人特別友善，因為最怕的就是改了 A 壞了 B，然後在 選單設定、圖片、路由之間疲於奔命。本機運行階段之所以是 debug 最有效率的環節，就是因為錯誤能即時看到、即時改，不用等部署完才發現哪裡壞了。換句話說，傳統流程裡你要先把網站推上主機、再開瀏覽器看結果，中間隔著好幾分鐘甚至好幾次的部署等待；Antigravity 把這個回饋圈壓到幾秒鐘，你改一句、畫面就動一下，這種即時性對非工程背景的人特別重要，因為它讓你不必在腦袋裡預演程式碼會怎麼跑，而是直接用眼睛驗證。這也是為什麼我會把本機運行視為整條鏈路裡最值錢的一段：它把工程師才有的那種「改了馬上知道對不對」的體感，下放給任何會打字的人。
說實在的，我會把這段視為整個流程裡最關鍵、也最容易讓人誤會的一段。很多人以為 AI 網頁設計的價值是「生成 UI」，但 UI 只是起點；真正讓 AI 能派上開發用場的，是它在 localhost 把專案跑起來、還能改的能力。沒有這一步，Stitch 的 UI 就只是一張好看的示意圖，離 能上線的網站 還差得遠。
把本機運行用得更有效，關鍵在於把指令寫得讓 agent 知道「範圍」與「條件」，並隨時保留退路。描述範圍而非單點最實用：與其說「改首頁的標題」，不如說「把所有頁面標題的層級統一成 h1 一個、h2 三個以內」，agent 知道這是一次全站層級的調整，會順便檢查其他頁面有沒有同樣問題。帶上判斷條件比單純下指令更省事，例如「如果某個區塊在小螢幕下會換行超過兩行，就改成直排」，agent 就能自己處理邊界情況，減少你逐一手調的次數。而每完成一個明確的改動就 commit 一次版本，當 agent 改出非預期結果時你能立刻退回上一個穩定狀態，不必回想「到底改了哪一句話才壞掉」。這幾個動作的共通點是把 AI 當成一個會聽話但需要明確指令的助手，指令越精準、越帶條件、越有退路，產出就越可靠。
也要務實看待本機運行的能力邊界。agent 雖然能理解專案結構，但它對「設計意圖」的理解仍然有限；你說「讓這個頁面更有質感」，它可能會做出你看不懂的改動。碰到這類主觀性高的需求，拆成幾個可驗證的小指令會更有效，例如「把主色飽和度降低、加大區塊之間的留白、把次要按鈕改成線框樣式」。把抽象的「質感」翻譯成幾個具體的視覺動作，agent 才有辦法穩定執行。這個觀念和寫程式給需求是一樣的：模糊的需求永遠產出模糊的結果，再聰明的 AI 也救不了。
MCP 串接與 Stitch Skills
MCP（Model Context Protocol 的基本概念）是讓 AI 工具彼此交換專案狀態的開放協定，由 Anthropic 提出，目的是讓不同工具共享同一份 context，不必每次都重新描述。串接之後，Antigravity 能即時讀取 Stitch 的設計狀態，等於兩個工具共享同一份專案脈絡。從 GitHub 下載的 Stitch Skills 則是預先封裝好的設計能力模組，能強化版面、互動、響應式等進階設計需求。
這兩層加起來，把工具從「一次性生成」推進到「可持續強化的工作流」。你可以把它想成：MCP 解決「兩個工具怎麼講同一種話」，Skills 解決「怎麼讓 AI 多會幾件事」。實際串接的順序是先讓 Antigravity 與 Stitch 透過 MCP 共用狀態、確認設計端改動會即時同步過來，再從 GitHub 取得 Stitch Skill 套用到進階版面、互動與響應式需求上。
對接案設計師來說，這層的價值在於它讓重複性的設計需求收攏成可重用的套件。比方說你常常做電商 UI Prototype、需要固定的商品卡互動、圖片最佳化 邏輯，這些都能封裝成 Skill，下次直接套用。這和 RAG 檢索增強生成 或 AI Agent 的思路很像：與其每次從零開始，不如把已經驗證過的能力模組化。
這也是我覺得這組合最被低估的一段。多數人 demo 時停在「Stitch 生 UI、Antigravity 跑起來」就結束，但真正決定專案能不能長大、能不能複用到第二個第三個客戶的，是 MCP 加 Skills 這層。少了這層，每接一個案子都得從零拉一遍；整理好自己的 Skill 庫，能力會一個案子一個案子疊加上去。要不要投入時間整理，差別會在接第三個案子時明顯浮現。
要判斷 MCP 串接到底有沒有真的接通，有三個訊號值得對照。改動同步的速度是最直接的：你在 Stitch 動一個元件，切回 Antigravity 應該幾乎不用等待就能看到對應的設計狀態更新，若每次都要手動重新匯入，多半是串接沒接通。另一個是狀態的一致性，你在 Stitch 把某個按鈕改成深色，Antigravity 那邊的對應元件也應該是深色，兩邊顏色對不上就代表脈絡沒有共享。再來是錯誤回報，串接失敗時工具通常會給出連線或認證失敗的訊息，看到這類訊息就不要硬試，先回頭檢查設定步驟。任何一個訊號沒過，都代表你還在「兩個工具各自獨立」的狀態，享受不到 MCP 的真正效益。
hosting.com 與 Vercel＋GitHub 兩條部署路線
AI 做好的網站要上線，大致有兩條路：hosting.com 適合需要傳統虛擬主機、搭配 WordPress 或要完整後台控制的情境；Vercel 配 GitHub 適合純前端、靜態或 Jamstack 專案，push 上 GitHub 就自動部署。兩者不衝突，依網站技術棧與維運習慣選擇。
這兩條路可以都實際跑一遍來體感差異：一條是用 hosting.com 讓網站上線，另一條是用 Vercel 配 GitHub 部署。選擇的判斷點其實只有一個：你的網站是 WordPress 還是純前端／靜態框架。WordPress 就走 hosting.com 這類 虛擬主機 路線，需要 cPanel 類後台 與完整的 WordPress 建站流程；純前端就走 Vercel，push 即部署，省去手動上傳。
| 比較項目 | hosting.com（傳統虛擬主機） | Vercel＋GitHub（自動部署） |
|---|---|---|
| 適合技術棧 | WordPress、PHP、需要 cPanel 後台 | 純前端、靜態、Next.js 等 Jamstack |
| 部署方式 | 手動上傳或一鍵安裝 | push 到 GitHub 即自動部署 |
| 迭代速度 | 較慢，每次更新要手動 | 快，每個 commit 都觸發部署 |
| 適合的人 | 熟 WordPress、要完整後台控制 | Stitch／Antigravity 產出的前端專案 |
| 典型成本結構 | 主機月費，網站費用 較可預期 | 免費額度起步，流量大才付費 |
這兩條路其實可以並存。正式站放 hosting.com、搭配 網域、DNS 設定、SSL 憑證 走完整後台；預覽站或側專案用 Vercel 快速迭代。技術棧決定路線，不必硬選一個；若要 架設專業形象網站 或 快速架 WordPress，hosting.com 那條會更順。
部署這一步還有一個常被新手忽略的重點：行動裝置的瀏覽體驗。Statista 的資料顯示，2026 年第一季行動裝置（不含平板）占全球網站流量的 52.27% [來源：〈Share of mobile web traffic worldwide quarterly 2015-2026〉〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉]。也就是說，你的網站上線後，超過一半的訪客是用手機看。Stitch 產出的 UI 雖然多半會給出手機版預覽，但手機上的實際表現要等到部署後用真實網路環境驗證才準。建議部署完先用不同的手機、不同的網路（Wi-Fi 與行動網路都試）開一次網站，看看載入速度與互動反應符不符合預期。行動體驗不只是 RWD 排版對不對的問題，還牽涉到字級、按鈕點擊範圍、圖片載入策略，這些都會影響訪客留下來的意願。
對 WordPress 路線，還有一個現實背景值得放進來：根據 W3Techs 的調查，WordPress 被用於 41.5% 的所有網站，在可辨識 CMS 的網站中占比更高達 59.2% [來源：〈Usage Statistics and Market Share of WordPress〉〈https://w3techs.com/technologies/details/cm-wordpress〉〈2026-06-29〉]。這代表 hosting.com 這條路背後有一個龐大的生態，外掛、佈景主題、教學資源都相對齊全，卡關時找答案的成本較低。如果你的網站需要長期經營內容、要接 SEO 工具、要持續更新文章，這個生態成熟度會是選擇 WordPress 加虛擬主機的一個實質優勢，而不只是「傳統」這個標籤。
完整流程拆解：想法到網站上線的 7 個步驟
把整個 Stitch 加 Antigravity 流程串起來，從零到上線一共 7 個步驟：想法、Stitch 生成 UI、Antigravity 本機運行、AI 修改專案、MCP 串接與 Skills 強化、推上 GitHub、Vercel 或 hosting.com 部署上線。每一步都有對應工具接手，一個人能走完，不必在設計師與工程師之間來回。
這 7 步每一步的工具都明確：Stitch、Antigravity、GitHub、Vercel 或 hosting.com。我會給新手一個建議：先跑通最小流程（一頁 UI、本機跑起來、部署上線），再慢慢加 Skills 與進階設計。一次想跑完整條流程、中間才 debug，會卡得很慘。這和 本機架 WordPress 再 搬到線上 的思路一樣，分階段驗證比一次到位穩。
換個角度想，這條流程真正的顛覆點，在於它把原本要兩種角色（設計師、工程師）來回交接的工作，收攏成一個人能走完的閉環，AI 多會做網站反而不是重點。對接案設計師、自架站長、非工程背景的創作者來說，這代表你可以從 避開常見設計地雷 開始，一路走到網站真的上線，中間不必外包程式碼。
一份 Prompt 從零到上線：示意情境與時間拆解
為了讓上面 7 步更具體，這裡用一個「示意情境」走一遍，幫助你建立整體時間感。要特別說明的是，以下是一個假設性的演示情境，用來說明各階段大致耗時與交接點，不是任何真實客戶的個案數字；實際時間會隨網站複雜度、個人熟悉度與網路環境大幅浮動。
- 想法與 Prompt（約 3 到 5 分鐘）：先在紙上或記事本寫好網站類型、目標對象、主要區塊大綱，再整理成一句 Prompt 丟進 Stitch。這段花的時間主要在「想清楚要什麼」，AI 本身生成很快。
- Stitch 生成與微調（約 3 到 8 分鐘）：第一版 UI 出來後，用兩三輪文字微調逼近你要的視覺，例如調 hero 區、CTA 按鈕、配色。
- 接進 Antigravity 本機運行（約 1 到 3 分鐘）：把 UI 透過 MCP 或匯出交給 Antigravity，在 localhost 跑起來，確認設計真的能動。
- AI 修改細節（約 5 到 15 分鐘，差異最大的一段）：統一選單、修圖片路徑、調整響應式，這段時間完全取決於你對細節的要求。
- 推 GitHub 並部署（約 3 到 10 分鐘）：建倉庫、推上去、接 Vercel 或 hosting.com，跑完第一次部署。
- 線上驗證（約 5 分鐘以上）：用不同裝置開網站、點過主要互動、確認表單與連結正常。
把這幾段加起來，一個結構單純的形象站，從打第一句 Prompt到網站在 localhost 跑起來，整段約莫落在先前提到的大約 7 分鐘上下；但從 localhost 跑起來到真正上線且驗證完成，多半還需要 15 到 30 分鐘以上的細節打磨。換句話說，「7 分鐘跑起來」這個數字指的是前半段，完整的上線閉環要再加上後半段。把這個時間結構記在心裡，你就不會對「AI 幾分鐘做好網站」這類說法抱持不切實際的期待，也能更務實地安排自己的工作節奏。真正的時間變數不在 AI 生成，而在你對細節的堅持與 debug 的熟練度。
還要提醒一個實務落差：demo 影片裡看起來行雲流水的流程，多半是「已經跑通的人」重新錄製的結果，中間那些試錯、卡關、重來都被剪掉了。你第一次自己跑時，光是處理本機環境、確認 MCP 設定、搞懂 push 流程，就可能多花好幾倍時間。這完全正常，第二次會快很多，第三次開始才會接近 demo 裡的那種節奏。把這個學習曲線算進預期裡，才不會在第一次卡關時就以為自己或工具出了問題。
Antigravity 與 Claude Code、Cursor 的定位差異
同樣是 AI 寫程式工具，Antigravity 是 Google 原生的 agentic IDE，與 Stitch、Gemini 同生態，整合最順但也綁定 Google；Claude Code 是終端機導向的 agent，彈性高、能接多種 UI 來源；Cursor 偏向編輯器內的 AI 補全路線，輔助你寫程式而非 agent 自主完成。選擇取決於你要「全家桶便利」還是「跨工具彈性」。
| 工具 | 定位 | 與 Stitch 整合 | 適合誰 |
|---|---|---|---|
| Antigravity | Google 原生 agentic IDE | MCP 串接最順，同生態 | 想用 Google 全家桶、要最少設定的人 |
| Claude Code | 終端機導向 agent | 可接 Stitch MCP，彈性高但需自己串 | 要跨 UI 來源、習慣命令列的人 |
| Cursor | 編輯器內 AI 補全 | 需手動帶入設計稿 | 想邊寫邊補全、自己掌握程式碼的人 |
這裡要點破一個常被忽略的取捨：Stitch 加 Antigravity 是 Google 全家桶方案，便利但綁定生態；而 Stitch 的 MCP 其實也能接 Claude 系列、其他 AI 程式工具，彈性仍在。換句話說，選 Antigravity 不是因為它「唯一能接 Stitch」，而是因為它在 Google 生態裡整合最省事。如果你已經在用 Perplexity 或 生成式 AI 的其他工作流，MCP 給了你不必綁死 Google 的空間。
本質上的取捨核心只有一條：整合便利（Antigravity）對上工具彈性（Claude Code）。Antigravity 把設定成本壓到最低，但你得接受 Google 生態的演化節奏；Claude Code 彈性高、大型語言模型 選擇多，但整合要自己接。對多數新手，我會建議先從 Antigravity 起手，跑通整條流程，等摸熟了再評估要不要換。
判斷自己該留在 Google 生態、還是跳出去用 Claude Code，可以從幾個面向自我檢查。你最重視的是「最少設定、最快跑通」，還是「能自由組合不同模型與工具」？前者選 Antigravity，後者選 Claude Code。專案會不會需要長期維護、跨很多不同服務也值得納入考量，會的話工具彈性會隨時間越來越重要，Claude Code 的跨工具能力會更值錢。而 Claude Code 的彈性是用命令列操作與串接設定的學習成本換來的，完全不想碰終端機的人，留在 Antigravity 會愉快很多。這幾個面向沒有標準答案，重點是誠實面對自己的需求與能耐，才不會選了之後又因為能力落差而卡住。
新手最常卡的三個點與對應解法
實際用 Stitch 加 Antigravity 做網站，最常卡在三個點，而且都不是「AI 不夠聰明」造成的，而是流程中斷。Stitch 漂亮的 UI 會讓人誤以為後面也一樣順，結果一進 Antigravity 就遇到環境問題、一推 GitHub 就遇到結構問題。這也是為什麼前面一直強調：設計只是前 20%，後 80% 的運行、串接、部署才是決定 AI 架站能不能走完一輪的關鍵。把心態從「AI 會幫我做好」調成「AI 幫我把每步變快，但每步我都要驗證」，卡關的次數會少很多。
第一個高頻卡點是 localhost 跑不起來，多半出在 Node 版本、相依套件沒裝或環境變數沒設。逐項排除時先確認 Node 版本是否符合專案要求，版本不符是這類問題最常見的元兇；接著用一個乾淨的目錄重新安裝相依套件，排除套件損壞的可能；最後看環境變數有沒有設對，尤其是 API 金鑰與服務端點。最穩妥的做法是先在本機跑通一個最小專案，再接 Stitch 產出。
第二個是 MCP 串接失敗，設計與開發兩端狀態不同步，通常是設定步驟漏了一步。按設定文件的步驟一條一條核對，多半是某一個認證步驟漏掉或權限沒給足；確認完設定後，用前面提過的三個訊號（同步速度、狀態一致性、錯誤回報）驗證有沒有接通。
第三個是部署時 Vercel 無法辨識專案類型，多半是專案結構不符預期或缺設定檔。檢查專案根目錄有沒有部署平台預期的設定檔、目錄結構是否符合框架慣例，改用標準結構後重新推一次通常就解決。這三個解法有一個共同動作：每改一項就測一次，不要把好幾個改動疊在一起才測，否則連哪一個改動生效都分不清。每完成一個步驟就先存一個版本，遇到問題能立刻退回上一個確定能跑的狀態；若等所有環節都接好之後才回頭找錯，牽涉的變數太多，連 AI 都不一定能幫你定位問題出在哪一環。
這裡再提醒兩件事。Stitch 的定價與免費額度會調整，以 官網公告 為準，不要把寫死的價格當依據。另外這組合適合新手，但不代表零基礎就能一次跑通；建議先有一點讓 AI 主動引用網站內容的概念與基本的架站認知，會更知道每步在做什麼。圖庫、Icon、圖片壓縮這些素材 Stitch 預設不一定齊全，往往還是要自己補。
AI 網頁設計最容易卡的，往往跟哪一個工具無關，真正的難點在「漂亮的 UI 怎麼推進成可運行、可部署、可持續修改的程式專案」這件事本身。Stitch 加 Antigravity 的價值，就在於把這條鏈路接起來；至於要不要再用 Core Web Vitals、站內 SEO、結構化資料 把網站打磨到位，那是上線之後的下一階段工作。
什麼情況不該用 Stitch 加 Antigravity
前面都在講這組合的好，這裡反過來誠實說清楚，哪些情況它未必是首選。任何工具都有適用邊界，硬把不適合的情境套進同一套流程，只會浪費時間還得到比傳統做法更差的結果。下面幾種情境，建議先停一下，評估是不是有更順的做法。
- 需要複雜後端邏輯的網站：牽涉會員系統、金流串接、訂單管理、權限分級這類後端功能的網站，Stitch 產出的是前端 UI，後端要另外接。這類需求用成熟的 架站平台 或現成的電商系統會更省事，硬用前端生成工具做只會把後端難題往後延。
- 高度客製化的視覺與互動：如果你的設計需求牽涉大量客製動畫、特殊滾動效果、複雜的資料視覺化，AI 生成的版面只能當起點，後續的手刻成本不會比從頭做少多少。
- 對穩定性與合規要求極高的場景：金融、醫療、政府這類對資安、合規、可用性要求極高的網站，建議交給有明確維運責任的團隊，AI 生成加自動部署的流程在這類場景的風險控管還不夠成熟。
- 內容量大、需要 CMS 工作流的網站：多編輯者協作、需要審稿流程、需要豐富外掛生態的內容站，WordPress 加成熟外掛的路線更適合，Stitch 路線偏單人快速迭代。
- 完全沒有 debugging 耐心的人：即便 AI 幫你省掉很多手刻功夫，本機運行、串接、部署這幾關仍需要你願意一個個訊號去核對。完全不願意面對任何技術細節的人，用 一鍵架站 的託管方案會比這條流程愉快。
把上面幾點濃縮成一個判斷原則：Stitch 加 Antigravity 最適合「單人或少數人、前端為主、需要快速迭代、能接受自己處理環境與串接」的情境。一旦你的需求往後端、往合規、往多人協作、往長期穩定維運傾斜，這條流程的優勢就會被它的邊界抵消。誠實對照自己的需求落在哪一端，比追逐工具的新奇更重要。
上線之後的品質檢查清單
網站推上線只是第一個里程碑，接下來的品質檢查才決定它能不能撐住流量、能不能被搜尋引擎與 AI 正確理解。這裡整理一份可以逐項打勾的檢查清單，每一項都附上判斷方式，方便你在部署完照著走一遍。
- 跨裝置顯示：用手機、平板、桌機各開一次，重點看 hero 區、選單、表單在小螢幕下會不會破版或擠成一團。
- 載入速度：用不同網路環境測一次首頁載入，留意圖片有沒有做壓縮與延遲載入，速度差的網站訪客會直接離開。
- 所有連結可點：點過主選單、頁尾、CTA 按鈕的每一個連結，確認沒有 404 或導向錯誤頁面。
- 表單與互動：實際送出一份表單，確認能收到、確認訊息有出現，這是新手最常漏掉的一關。
- 標題與中繼資料：檢查每一頁的標題、描述有沒有填、符不符合 站內 SEO 基本要求，這會直接影響搜尋結果的呈現。
- 結構化資料：關鍵頁面補上 結構化資料，讓搜尋引擎與 AI 能正確解析你的內容類型。
- SSL 與網域：確認 SSL 憑證 正常、DNS 解析正確，http 能自動轉 https。
- 備份與版本：確認專案有推上 GitHub、有可還原的版本，線上壞掉時能快速退回。
其中速度這一項，值得多花一點力氣顧。Google 早從 2018 年 7 月起就把網頁速度列入行動搜尋的排名因素，2021 年 5 月進一步把 Core Web Vitals 整合進網頁體驗排名訊號 [來源：〈Evaluating page experience〉〈https://developers.google.com/search/blog/2020/05/evaluating-page-experience〉〈2020-05-28〉]。換句話說，網站載入慢、互動卡頓，不只訪客體驗差，還會直接影響搜尋排名。Antigravity 產出的前端專案，預設不會幫你把所有效能細節調到位，圖片壓縮、字型載入策略、第三方腳本數量，這些都要在上線後自己檢視一遍。用 網站速度優化 的方法把 Core Web Vitals 拉到綠燈，是上線後報酬率最高的一個動作之一。
以一個用這類 AI 流程做出來、尚未做效能調校的純前端形象站為例，常見的狀況是剛部署完用手機開，Core Web Vitals 三項指標多半還沒到綠燈：LCP（最大內容繪製）依典型表現幅度約落在 3.0 到 4.5 秒之間，INP（互動到下一次繪製）約落在 200 到 350 毫秒，CLS（版面位移）則多半在 0.1 到 0.25 這段。這些區間屬於這類「快速生成、圖片未壓縮、字型完整載入」的前端專案上線後常見的典型表現幅度，並非任何特定網站的實測值，實際數字會隨網站圖片數量、是否套用動畫、第三方腳本多寡大幅浮動。要務實理解的是，AI 生成階段並不會主動幫你選 WebP 格式、設延遲載入、限制字型權重，這些都要靠手動補上才有機會把三項指標一起推到綠燈。常見的失敗點是只盯著 LCP 改，卻忽略 INP 在手機上因為第三方追蹤腳本而一直降不下來，結果桌機看起來漂亮、手機實測仍卡頓。決策角度上，建議上線後先用手機實機搭配 PageSpeed Insights 跑一次，鎖定「三項一起看、優先處理降幅最大且門檻最低的那一項（通常是圖片格式與延遲載入）」，再逐項往下推，比一次想全改到位更可靠。
速度優化的具體報酬，有公開案例可以參考。Google web.dev 整理的案例顯示，Vodafone 把 LCP（最大內容繪製）改善 31%，帶來銷售提升 8%；redBus 改善 INP（互動到下一次繪製）後，銷售提升 7%；Rakuten 24 投資 Core Web Vitals，每位訪客營收提升 53.37%、轉換率提升 33.13% [來源：〈web.dev - Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。這些都是電商場景的公開數據，不必直接套用到你的網站，但它們傳達的訊息很清楚：速度與轉換之間有明確的正相關，值得在上線後排進優先順序。即便你做的不是電商，訪客停留與跳出率也會隨速度改善而變好。
結語：設計是起點，落地才是考驗
回顧一下整條流程：Stitch 把想法具象成 UI，Antigravity 在 localhost 把 UI 跑成網站並用 AI 改程式碼，MCP 串接讓兩端共享專案狀態，Stitch Skills 強化進階設計，最後推 GitHub 交給 Vercel 或 hosting.com 部署上線。7 個步驟、一個人走完，這就是 Stitch 加 Antigravity 與其他只會畫介面的 AI 工具最大的不同。網站上線後也不是定稿，每隔一段時間回頭檢視內容與關鍵字表現，做一輪 SEO 年度內容更新，能讓流量持續累積而非慢慢衰退。
判斷一組 AI 網頁設計工具能不能落地，標準很簡單：它有沒有把設計、修改、本機運行、部署這條原本要兩種角色來回交接的鏈路接起來。接得起來，AI 就是能幫你省掉外包與來回的生產力工具；接不起來，它就只是另一個會畫漂亮介面的玩具。Stitch 加 Antigravity 走的是第一條路，至於要不要把後續的 網頁設計外包、報價、SEO 網站架構 也一併納入，就看你想把這個網站做到多完整。
網站真的能被 AI 看懂、被 AI 代理順利瀏覽，背後還有一層 AI 友善網站與 Agentic Browsing 的觀念要顧，這會影響你的內容在 AI 搜尋結果裡能不能被引用。要確認成效，除了看 Google Analytics，搭配 Ahrefs Brand Radar 觀察品牌曝光與外部提及，或報名 全面支援 Ahrefs 的 SEO 陪跑班 系統性把工具操作學起來，會比單打獨鬥更快抓到網站的優化方向。
Stitch 與 Antigravity 常見問題
Stitch 加 Antigravity 真的能做出完整網站嗎？
可以，前提是把 7 個環節串通。Stitch 出 UI 設計、Antigravity 在 localhost 把設計跑起來並用 AI 修改、推 GitHub 後部署，全程不必分工外包。
Antigravity 跟 Claude Code、Cursor 有什麼不同？
Antigravity 是 Google 原生 agentic IDE，和 Stitch 同生態、串接最省事；Claude Code 走終端機路線，彈性大但整合自理；Cursor 偏編輯器內補全。差別就在便利與彈性的取捨。
用 AI 做網站需要會寫程式嗎？
不用逐行寫，調整多半用講的就能完成。但懂一點網頁設計與架站概念，卡關時比較知道問題出在哪一環。
AI 網頁設計最容易卡在哪一個步驟？
通常是 localhost 跑不起來、MCP 串接失敗、專案結構不被 Vercel 辨識這三個點。原則是每步先小範圍驗證，別等整條流程接好才回頭除錯。
什麼情況下不建議用 Stitch 加 Antigravity？
需要複雜後端邏輯、高度客製動畫、極高合規要求、多人 CMS 協作，或完全不願面對任何技術細節的情境，用成熟的架站平台或託管方案會更省事。誠實對照自己的需求落在哪一端再決定。
從 Prompt 到網站上線大概要花多少時間？
結構單純的形象站，從打第一句 Prompt 到 localhost 跑起來約莫 7 分鐘上下；但要走到真正上線並驗證完成，多半還需 15 到 30 分鐘以上的細節打磨。實際時間隨複雜度與熟練度大幅浮動，這些都是示意性估算，不是固定數字。