Claude Code 搭配 Stitch 網頁設計自動化工作流：分工、串接與落地一次講透
把 Stitch 當設計大腦、Claude Code 當開發雙手，用一條 MCP 通道把「設計、修改、匯出、生成可瀏覽網頁」壓進同一個終端機，是一人團隊把原本要好幾天的設計開發交接…
Claude Code 搭配 Stitch 網頁設計自動化工作流：分工、串接與落地一次講透
把 Stitch 當設計大腦、Claude Code 當開發雙手，用一條 MCP 通道把「設計、修改、匯出、生成可瀏覽網頁」壓進同一個終端機，是一人團隊把原本要好幾天的設計開發交接縮成幾小時的最短路徑。關鍵不在 AI 一鍵生成那個瞬間，而在兩者的分工線：Stitch 負責色系、字型、版型、變形與原型這些視覺決策，Claude Code 負責將設計稿轉成 HTML、CSS 與可在瀏覽器瀏覽的實體網頁。根據 Google 官方對 Stitch 的定位，它是一套以 AI 生成 UI 設計與前端程式碼的工具 [來源：Google Stitch〈https://stitch.withgoogle.com〉〈2026〉]，而讓這兩者能互通的橋是 Anthropic 提出的 MCP（Model Context Protocol），一種讓 AI 助理呼叫外部工具的協定 [來源：Model Context Protocol〈https://modelcontextprotocol.io〉〈2026〉]。想搞懂 Vibe Coding 網頁設計實戰流程 怎麼跟這條工作流串起來，這篇會把每一步拆給你看。
重點先看：Stitch 出設計、Claude Code 出程式碼，兩者用 MCP 串起來，一人就能跑完整條流程；但跳過 Design Systems 直接生稿、或匯出後不審 HTML 結構，成品只會漂亮卻無法上線。MCP 為 Anthropic 提出的協定 [來源：Model Context Protocol〈https://modelcontextprotocol.io〉〈2026〉]，這是整條工作流的地基。
Claude Code 跟 Stitch 到底各做什麼：先把分工講清楚
Stitch 是負責視覺決策的 AI 設計工具，舉凡色系、字型、版型、變形、即時原型都歸它管；Claude Code 則是在終端機裡跑的 AI 助理，負責讀設計稿、生成 HTML、CSS、JavaScript，產出真正能在瀏覽器開的網頁。兩者透過 MCP 協定串接後，Stitch 出設計稿，Claude Code 將稿落地成實體網頁，分工明確不重疊。說到底，Claude Code 完整入門教學 想講的就是這個終端機助理到底能幫你做多少事，而把它跟 Stitch 擺在一起看，你會更清楚誰該接手哪一段。
我自己判斷分工有一個最快的問句：這一步是在決定「長相」，還是在產生「程式碼」？前者交給 Stitch，後者交給 Claude Code。一旦兩者搶同一件事，流程就會打架，不是設計稿被改得四不像，就是程式碼長不出設計的味道。這條界線聽起來像廢話，但實際跑工作流時，十次卡關有八次是這條線沒畫清楚。跟單純的 AI 繪圖搭配 ChatGPT 做網頁設計 相比，這套組合多了一層「誰負責什麼」的工程紀律。
把分工界線再拆細一層，可以分成三個判斷維度。第一個是產出物形態：如果這一步的成果是一張圖、一個配色或一個版面草圖，就該留在 Stitch；如果成果是一段可以放進 .html 檔的字元，就該交給 Claude Code。第二個是修改成本：視覺改色、調密度、換 hero 區塊，在 Stitch 裡是幾秒鐘的事，但若等到 Claude Code 已經生成 HTML 才要回頭改配色，等於要動 CSS 變數、可能牽動十幾個元件，成本立刻翻好幾倍。第三個是可逆性：Stitch 的 Ideation 與 Variants 隨時可以推倒重來、並排比較，Claude Code 生成後的程式碼一旦疊加互動邏輯，回退就要小心不要打斷已經接好的鏈路。把這三個維度記下來，分工判斷會從直覺變成可以重複檢驗的流程。
Stitch 與 Claude Code 分工對照
| 環節 | Stitch 負責 | Claude Code 負責 |
|---|---|---|
| 色系字型定調 | Design Systems 匯入品牌色票與字型 | 把色票字型寫進 CSS 變數 |
| 版型構思 | Ideation 產出多種版型方向 | 讀稿並轉成語意化 HTML 結構 |
| 互動驗證 | Prototype 做可點擊即時原型 | 把互動邏輯補成可用 JavaScript |
| 最終產出 | 匯出設計稿與設計 token | 生成可在瀏覽器瀏覽的網頁 |
把這張表記下來，後面遇到任何一步猶豫該丟給誰，回頭對一眼就知道。這也是為什麼很多教學把 Stitch 講成「AI 一鍵生網頁的魔法」會誤導人，它真正穩的價值在這條分工線，而不是生成那一瞬的驚喜。若你對這類工具怎麼串進自動化流程有興趣，AI Agent 自動化代理工具入門 提供了更廣的視角。
為什麼是 MCP 而不是傳統的匯出匯入
傳統設計到開發的交接，靠的是手動匯出匯入：設計師在設計工具裡畫完，把稿匯成圖片或規格文件，工程師再照著稿寫程式碼。這條路最大的痛點在於「失真」，設計稿裡一個陰影的透明度、一段文字的行距，到了工程師手上往往變成憑感覺還原。MCP 協定的價值，在於它讓 Claude Code 可以直接讀到 Stitch 內部的設計資料，包含色票、字型、間距這些設計 token，而不只是看到一張圖。等於把設計與開發之間那條會失真的傳聲筒，換成一條資料可以直接流動的管道。
這條管道的實際長相是：Stitch 把設計能力包裝成一組工具，Claude Code 透過 MCP 伺服器呼叫這些工具，設計稿的結構化資料就能直接餵進程式碼生成的流程。對一人團隊來說，這代表你不用在兩個工具之間來回剪貼，也不用在腦袋裡記住「這個藍是 #1E40AF 還是 #2563EB」。對接案者來說，這更代表你可以把「設計」與「程式碼」這兩個原本要分頭外包的環節，收進同一個工作階段。不過要提醒，MCP 是通道不是萬能翻譯機，它傳遞的是設計資料，至於這份資料要不要全部照搬進 HTML、哪些互動要重新用 JavaScript 寫，仍是 Claude Code 端要做的判斷。
安裝 Stitch MCP 與擴充 Claude Code Skills 的事前準備
正式做網頁前，得先把兩件東西裝起來：一是 Stitch MCP 伺服器，讓 Claude Code 透過 MCP 協定連到 Stitch 的設計能力；二是 Stitch Skills，把 Claude Code 的設計相關能力進一步擴充。兩個都裝完，才有可能用一行指令做到原本要好幾天的事。安裝前請先確認本機已經能正常執行 Claude Code，Mac 與 Windows 都可以，這部分建議對照 Claude Code 新手安裝與 MCP 整合 把環境先弄乾淨。
實際安裝順序我會拆成四步，每一步都有一個常見卡點，先記下來才不會在終端機前面乾瞪眼。
- 確認 Claude Code 可執行：在終端機呼叫得到回應，代表主程式沒問題。
- 加入 Stitch MCP 伺服器：讓 Claude Code 透過 MCP 協定認得 Stitch 的設計工具集；連不上多半是金鑰或伺服器路徑設錯。
- 安裝 Stitch Skills：依官方文件提供的指令安裝，具體指令以 Claude Skills 擴充 AI 工作流指南 與官方說明為準，這裡不杜造指令或路徑。
- 重啟 Claude Code：Skills 裝完沒生效，重啟一次通常就好，這是免錢的除錯第一步。
這裡要誠實講一件事：安裝細節會隨官方更新變動，我沒辦法在這裡寫死某一條指令然後保證你照抄就過。與其給你一串可能明天就失效的指令，不如把排錯邏輯講清楚，MCP 連不上先查金鑰與路徑，Skills 不生效先重啟，這兩招能解掉大多數安裝卡點。想把整個 Claude Code 的設定脈絡補齊，Claude Code Plugins 自動化外掛設定 值得順著讀一遍。
關於 Skills 本身是什麼，根據 Anthropic 官方對 Skills 的定義，它是一種讓 Claude Code 在特定領域擴充能力、攜帶專門指令與資源的機制 [來源：Anthropic Agent Skills〈https://docs.anthropic.com/en/docs/agents-and-tools/agent-skills〉〈2026〉]。換句話說，Stitch Skills 裝下去，等於把「懂 Stitch 設計語言」這個技能直接掛進 Claude Code，這也是為什麼前文說沒裝等於只用半套。如果你連 WordPress 端的 MCP 也想一起玩，Claude Code 搭配 WordPress 的 MCP 實戰 會是下一步。
安裝卡點排錯對照表
| 症狀 | 最可能原因 | 處理步驟 |
|---|---|---|
| 指令送出後毫無回應 | 主程式未正確安裝或環境變數遺失 | 重裝主程式、檢查 PATH 與設定檔路徑 |
| 認不得 Stitch 工具集 | MCP 伺服器未掛載或金鑰錯誤 | 核對金鑰與伺服器路徑、重啟 Claude Code |
| Skills 裝了卻沒生效 | 設定未重新載入 | 完全關閉再重開、確認設定檔已被讀取 |
| 設計稿讀得到但結構空 | Design Systems 未先定義 | 回到 Stitch 把色票字型補齊再重新匯出 |
| 產出網頁與稿對不上 | 用了過期的舊稿 | 確認餵進來的是最新版本、清掉暫存 |
這張表把我自己踩過與常見社群回報的卡點整理出來，遇到症狀時先對表，比盲目重裝省時間。有一個觀念特別要建立：排錯的順序永遠是「先排除最便宜的成因再往下走」。重啟不花錢，先重啟；查金鑰不用重裝，先查金鑰；都不行才動到重裝這一步。很多人卡半天是因為一上來就重裝，反而把原本只是設定錯的環境弄得更亂。
實戰第一步：用 Claude Code＋Stitch 生成科技感深色 Landing Page
串接完成後，第一個網頁怎麼生？在 Claude Code 裡下一行指令，把你要的風格描述清楚，Stitch 會產出對應的視覺設計，再把這份稿交回 Claude Code 生成可在瀏覽器瀏覽的實體網頁，全程不必手寫程式碼。我會建議第一個練習標的就選 Landing Page，原因是它的結構單純、轉換導向，容錯空間大，很適合拿來摸熟整條流程。想知道 Landing Page 為什麼適合當起點，可以參考 Landing Page 銷售頁製作教學。
指令裡有三件事一定要寫清楚：網站類型（例如 AI 服務 Landing Page）、風格（科技感、深色）、用途（對外展示）。這三項缺一個，生成出來的稿就會飄。舉個例子，你想做一個深色風格的 AI 服務頁，就明確說「科技感、深色背景、對外展示用的 AI 服務 Landing Page」，不要只丟一句「幫我做個網頁」。這跟前端的 用 Claude Code 搭建專業網站的完整工作流 是同一個道理：AI 不會讀心，你給的條件越具體，產出越能落地。
老實說，第一次生成的稿幾乎都是底稿，不要期望一次到位。我自己的習慣是把第一次結果當成「草案」，後面靠 Ideation、Redesign、Variants 慢慢收斂，通常來回兩三輪才會到能看的水準。如果你是接案設計師，這個心理預期很重要，否則很容易在第一版就覺得工具不行而放棄。要把它跟更廣的 AI 架站工具比較，AI 網站建立工具實測比較 給了一個橫向的對照面。
- 指令寫清三件事：網站類型、風格、用途。
- 第一次結果當草案，不要當成品。
- 生成後務必在瀏覽器實際預覽，檢查 RWD、字型載入、圖片佔位。
- 用 Landing Page 當練習標的，結構單純容錯高。
預覽這一步千萬別省。在瀏覽器實際開來看，是最快抓出 AI 生成破綻的方法，字型沒載到會跳預設字體、圖片佔位會跑版、手機寬度可能整個疊在一起，這些只有真的開來看才看得到。RWD 的基本功若有漏，響應式網頁設計 RWD 觀念 可以補一下。
把指令寫具體的評分卡
「指令要具體」講起來簡單，但很多人不知道具體到什麼程度才算夠。這裡提供一張評分卡，讓你可以在送出指令前先自我檢查。一個能穩定落地的指令，通常要能回答下面幾個問題，答得越完整，稿越不會飄。
| 檢查項 | 模糊指令（容易飄） | 具體指令（容易落地） |
|---|---|---|
| 網站類型 | 做個網頁 | 對外展示的 AI 服務 Landing Page |
| 視覺風格 | 好看一點 | 深色背景、科技感、留白多 |
| 主要受眾 | 給大家看 | 給技術決策者看的 B2B 頁面 |
| 核心動作 | 看起來專業 | 引導點擊試用按鈕 |
| 色票來源 | 你決定 | 先匯入 Design Systems 再生稿 |
這張表背後的邏輯是：AI 設計工具不怕你要求多，怕你要求空。模糊指令等於把所有設計決策都丟回給模型隨機猜，產出自然飄忽；把每個欄位填滿，等於先替模型劃好邊界，它才能在邊界內做出穩定的選擇。我的實作習慣是，送出指令前先在腦裡把這五格走一遍，任何一格答不出來就先補，補完再送。這個動作花不到一分鐘，卻能幫你省下好幾輪的收斂時間。
Stitch 五大功能拆解：Ideation、Redesign、Variants、Prototype、Design Systems
Stitch 這五個功能串起來，就是一條從靈感到可互動稿的完整設計鏈：Ideation 從零構思版型方向、Redesign 把既有網頁重新設計、Variants 針對同一版型生出多種變形、Prototype 做可互動的即時原型、Design Systems 統一定義色系與字型。各自解決的問題不同，混著用才會發揮最大價值。這五個名稱以 Google Stitch 官方說明為準 [來源：Google Stitch〈https://stitch.withgoogle.com〉〈2026〉]。
- Ideation 構思：腦卡時用，給主題就生多種版型方向，當起點而非終點。
- Redesign 重設計：丟一個現有網址進去直接重畫，適合改造舊站或致敬競品版面。
- Variants 變形：同一版型快速變形，改配色、佈局、密度，拿來 A/B 比較最有效率。
- Prototype 即時原型：把靜態稿變成可點擊的原型，先驗證互動再交給開發，省下反覆修改。
- Design Systems 設計系統：從一個網址直接匯入色系與字型，讓視覺語言快速定調，是維持一致性的命脈。
這裡要特別點名 Design Systems，因為它是很多人跳過、卻最不能跳過的一環。從一個網址直接匯入色系與字型這件事，聽起來像小功能，但它等於幫你把整套視覺語言先定錨，後面 Ideation 與 Variants 生出來的稿才有共同基準。跳過它直接生稿，等於把一致性交給運氣，這也是 brief 裡反覆強調的地雷之一。要深入做配色，網站色彩計畫配色實戰 與 網頁配色工具網站推薦 都是順手的資源。
Variants 我個人用最多。同一個 Landing Page 我會生出三到五個變形，配色、密度、 hero 區塊擺法都不同，然後放在一起比，哪個最有感就留哪個。這比自己在 Figma 一個一個改快太多，也是這套工作流對接案者最實際的紅利。若你還在用傳統流程做 UI Prototype 原型設計全解析 裡講的那種線框圖，會明顯感覺到節奏被加快。
Redesign 則適合拿來重做舊站。丟一個你覺得過時的網址進去，Stitch 會以那個網址的內容結構為基礎重新組版，等於幫你省掉重新盤點資訊架構的時間。不過要注意，它重畫的是視覺，不會幫你重新想資訊架構，該有的 Wireframe 線框圖設計入門 思考還是得自己做。至於 Prototype，做完直接可以點擊驗證互動，這層價值在 Figma AI 與 MCP 設計功能解析 也有類似的討論。
五大功能什麼時候用、什麼時候別用的決策矩陣
知道每個功能做什麼還不夠，真正會卡住人的是「現在手上的需求到底該丟進哪一格」。這張二維矩陣把常見情境與對應功能配對起來，並標出什麼情況下那個功能反而會幫倒忙。把它當成快速查詢表，遇到情境就回頭對。
| 你的情境 | 該用的功能 | 什麼情況別用 |
|---|---|---|
| 完全沒想法、要找方向 | Ideation | 已有明確品牌規範時，生太多反而干擾 |
| 舊站視覺過時想翻新 | Redesign | 資訊架構本身有問題時，重畫視覺救不了 |
| 同一版型要比幾種味道 | Variants | 連主結構都還沒定時，比變形是浪費 |
| 要驗證點擊與流程 | Prototype | 純靜態展示頁，做原型是過度工程 |
| 要全站色彩字型一致 | Design Systems | 單頁且無品牌規範時，強制定調反而綁手 |
這張矩陣最關鍵的一欄是「什麼情況別用」。很多人把 Variants 當成萬用解，連主結構都還沒拍板就開始比配色，結果改了十幾個變形，主結構一動全部白費。正確的使用順序是：先用 Ideation 或 Redesign 把主結構定下來，接著用 Design Systems 把視覺語言定錨，然後才進 Variants 做細節比對，最後用 Prototype 驗證互動。這個順序跑過幾次，你就會發現每個功能都用在它最能發揮的時機，疊床架屋的修改會少很多。
設計稿匯出給 Claude Code：怎麼產出可瀏覽的實體網頁
這一步是整條工作流從設計到開發的收尾關鍵。把 Stitch 的設計稿匯出，直接餵給 Claude Code，Claude Code 會根據稿的結構生成對應的 HTML、CSS，產出可在瀏覽器瀏覽的實體網頁。匯出的具體格式以官方支援為準，不在此寫死未經確認的格式細節。匯出前請先確認 Design Systems 的色票與字型已經定義完整，否則產出的程式碼會不一致。
這裡我要踩個剎車。Claude Code 生成的 HTML 結構，務必人工過一遍：標題層級有沒有對、圖片有沒有 alt、是不是用了語意標籤，這些直接影響 SEO。把 AI 生成的程式碼直接放生上線，等於把 SEO、速度、RWD 問題一起搬進成品，這是這套工作流最常被忽略的代價。關於 SEO 在 AI 搜尋時代怎麼布局，AI 搜尋時代的 SEO 全攻略 與 讓 AI 主動引用你的內容策略 是延伸的重點。
上線前必跑檢查清單
- 標題層級（h1 只有一個、h2 h3 階層正確）。
- 圖片 alt 文字齊全，避免空 alt。
- 語意標籤（header、main、section、footer）取代滿頁 div。
- 速度檢測過一次，網站速度優化五大核心技巧 可對照。
- RWD 三種螢幕寬度（手機、平板、桌面）都開來看。
- 表單與連結實際點過，確認可用。
速度與行動版為什麼不能只靠肉眼預覽
預覽看得到跑版，但看不出效能與行動版索引的問題，這兩件事要有數據才講得清楚。Google 早從 2018 年 7 月起就將網頁速度列入行動搜尋的排名因素，當時官方明說這只會影響「交付最慢體驗」的頁面，且只影響一小部分查詢 [來源：Google Search Central Blog〈Using page speed in mobile search〉〈https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search〉〈2018-01-17〉]。後續 2020 年 Google 進一步把 Core Web Vitals 與既有頁面體驗信號整合成新的排名信號 [來源：Google Search Central Blog〈Evaluating page experience〉〈https://developers.google.com/search/blog/2020/05/evaluating-page-experience〉〈2020-05-28〉]。也就是說，AI 生成的程式碼若帶進冗餘腳本、未最佳化的圖片，影響的不只是主觀感受，而是會直接在排名上吃虧。
行動版更是不能只開一次手機寬度就算驗過。Google 早在 2020 年就宣布行動優先索引（mobile-first indexing），當時已有 70% 出現在搜尋結果的網站完成轉換，並承諾 2020 年 9 月起全面採用 [來源：Google Search Central Blog〈Mobile-first indexing for the whole web〉〈https://developers.google.com/search/blog/2020/03/announcing-mobile-first-indexing-for〉〈2020-03-05〉]。到了 2023 年 10 月，Google 官方宣布行動優先索引的遷移已完成，所有能在行動裝置運作的網站都主要由行動爬蟲檢索 [來源：Google Search Central Blog〈Mobile-first is here〉〈https://developers.google.com/search/blog/2023/10/mobile-first-is-here〉〈2023-10-31〉]。這代表你餵給 Claude Code 的稿，最後生成的 HTML 在手機上的樣子，就是 Google 主要拿來評分的版本。預覽時務必把手機寬度當成第一優先，桌面反而是緊追在後的是。
從流量結構看，行動版的權重還在上升。統計顯示，2026 年第一季全球網站流量有 52.27% 來自行動裝置（不含平板）[來源：Statista〈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〉]。超過一半的訪客用手機看你的頁面，這也呼應前面把行動版預覽擺第一的判斷。效能面也有實際案例可參考，Google 在 web.dev 公開的資料顯示，投入 Core Web Vitals 優化能帶來可衡量的轉換提升，例如 Rakuten 24 投入 Core Web Vitals 後，每位訪客營收提升 53.37%、轉換率提升 33.13% [來源：web.dev (Google)〈Why does speed matter?〉〈https://web.dev/articles/why-speed-matters〉〈2026〉]。這些數字背後的道理很直白：AI 生成的網頁若在速度上吃虧，吃虧的是轉換率與排名兩頭。把速度檢測排進上線前清單，是這套工作流最划算的一次人工把關。
若你要把成果接上 WordPress 或其他 CMS，匯出的程式碼還需要再調整，不是貼上去就完工。獨立 HTML 的自由度高，但後台整合要自己處理，這跟在 WordPress 裡拖拉的 Elementor 頁面編輯器完整教學 是兩種不同的取捨。我自己的做法是：用這套工作流快速產原型與 Landing Page，正式營運站再轉接 WordPress 主題或頁面編輯器，兩邊各取所長。想找適合的主題，WordPress 佈景主題推薦比較 是個起點。
講了這麼多，這條從設計稿到實體網頁的路徑，價值在「收斂得快」。AI 幫你把重複勞動壓掉，但收尾的判斷仍在你手上。這也是為什麼前面一再強調，這條從設計到開發的工作流 的前提，是你願意在關鍵節點花人工把關，而不是全交給 AI。若你對生成式 AI 的原理想了解得更深，生成式 AI 原理與應用場景 可以補上背景。
設計 token 怎麼從 Stitch 一路流到 HTML
這條工作流之所以能維持視覺一致，核心在於設計 token 的流動。token 講白話，就是把色票、字型、間距、圓角這些視覺決策，編碼成有名稱的變數，例如把主色命名為 color-primary、把標題字級命名為 font-size-heading。Stitch 的 Design Systems 就是產生這組 token 的源頭，Claude Code 接手後，這組 token 會被對應成 CSS 變數，讓整份 HTML 共用同一份定義。
- 定義：在 Design Systems 裡把主色、輔色、字型層級、間距級距一次定齊，命名要有意義，避免 color1、color2 這種日後看不懂的名字。
- 套用：Ideation 與 Variants 產稿時全部引用這組 token，新稿的色彩與字型才會一致，不會每生一張稿就偏一點。
- 匯出：匯出時確認 token 隨設計稿一起交給 Claude Code，沒有 token 的稿，Claude Code 只能從圖面還原顏色，失真風險大增。
- 落地：Claude Code 把 token 轉成 CSS 變數，寫進 :root 或設計系統檔，後續所有元件都從變數取值。
- 收斂：上線前巡一次變數有沒有重複定義、有沒有沒用到的殘留，把設計系統收乾淨，未來改版才不會牽一髮動全身。
這條 token 流動的鏈路一旦跑順，你會發現改配色從「全站巡一次」變成「改一個變數」。這也是為什麼前面反覆強調 Design Systems 不能跳過，它就是這條鏈路的源頭；源頭不定，後面每一個環節都要付出失真的代價。對接案者來說，這更是能不能把同一套品牌規範套到多個頁面的關鍵，定義一次、套用十次，產能才會真正放大。
這套工作流的優點、地雷與適合誰
這套工作流適合一人團隊、接案者、想快速產出 Landing Page 與原型的人，能把原本多日的設計開發交接壓成幾小時；但不適合需要複雜電商邏輯、嚴格無障礙規範或高度客製後台的專案。時間節省的幅度這裡用「多日壓成數小時」的經驗性觀察來描述，不寫死未經驗證的具體百分比或小時數。
最大優點很直白：一個人、一個終端機就能跑完整條設計開發流程，省下設計師與工程師的來回溝通。對接案者來說，這代表同一個月能接的案子變多，瓶頸從「產能」變成「品質把關」。但最大地雷也藏在這裡：「全程不用寫程式」是行銷話術，實際上你要懂 HTML 結構、SEO 基礎、效能觀念，才有可能把成品打磨到可上線。這層認知跟 網頁設計從零到一完整指南 的基本功是同一條線。
優點與地雷並列
| 面向 | 優點 | 地雷 |
|---|---|---|
| 產出速度 | 多日交接壓成數小時 | 第一版多半是底稿，仍需多輪收斂 |
| 程式碼門檻 | 不必從零手寫 | 仍須懂 HTML 結構與 SEO 才能落地 |
| 視覺一致性 | Design Systems 可快速定調 | 沒先設好，後續修改成本更高 |
| 適用場景 | 原型、Landing Page、一人流程 | 大型電商、會員系統、嚴格無障礙不適合 |
第二個地雷是 Design Systems。前面講過，沒先設好就生稿，視覺一致性會崩，後續修改成本反而更高。這不是理論，是實跑過就會懂的痛，顏色每到一個頁面就偏一點，字型層級每改一次就要全站巡一次。所以再強調一次，Design Systems 帶來的色彩一致性 是命脈，不是可有可無的裝飾。要把它跟品牌色挑選連起來看，品牌色彩挑選與心理學指南 與 色彩學與色相環配色技巧 都能幫上忙。
那什麼場景不適合？大型電商、會員系統、金物流串接、需要符合嚴格無障礙法規的公部門網站，這些仍得走傳統開發。AI 生成的網頁在 SEO、速度、結構上仍須人工把關，這是無法迴避的事實，相關風險主張以「仍需人工把關」的判斷句呈現，不寫無來源的百分比。對速度與 RWD 有疑慮，RWD 響應式電商網頁設計實戰 與 網頁版面與 RWD 排版攻略 可以交叉參考。
不適合用這套工作流的五種情境
- 金物流串接的電商：結帳、庫存、退款、稅務邏輯牽動資料庫與第三方 API，這類狀態機用對話生成風險太高，應走正規後端開發。
- 會員與權限系統：登入、角色權限、資料隔離涉及資安邊界，AI 生成的程式碼很難在這層保證嚴謹，人工設計架構更穩。
- 嚴格無障礙法規網站：公部門或受法規約束的頁面，需要逐項對照 WCAG 等規範，AI 生成的標籤順序與 ARIA 屬性仍要人工逐條驗。
- 高互動即時應用：像即時協作白板、多人編輯這類重狀態的互動，前端的狀態同步邏輯遠超 Landing Page 等級，不適合用原型流程硬上。
- 既有大型後台的局部改造：在已運作多年的系統裡插入 AI 生成的區塊，容易跟既有架構打架，改一塊壞一塊，不如用團隊既有規範。
把這五種情境記下來，是為了避免把這套工作流當成萬用解。它的甜蜜點是「從零到看得到稿」的快速路徑，甜蜜點之外的領域，傳統開發與既有工具仍然更穩。承認工具的邊界，反而能讓你在適合的場景裡放心用它，把心力集中在你真正能駕馭的專案類型。
換個角度想，這套工作流補上「快速原型」這一塊缺口。你的正式營運站如果已經在 WordPress 上，搭配 Divi 主題終極架站指南、Bricks Builder 視覺化編輯器教學 或 WordPress 頁面編輯器深度評測 裡的工具會更穩；Claude Code＋Stitch 負責的是前面那段從零到看得到稿的高效路徑。對應的字型與排版基本功，中文字體設計與字型推薦、排版設計與字體行距技巧 也別漏掉。
進階組合：跟 Figma、頁面編輯器、Vibe Coding 比一比
把 Claude Code＋Stitch 放回市場裡比，定位會更清楚。相較於 Figma＋工程師的傳統分工、Elementor、Divi、Bricks 這類視覺化頁面編輯器，以及純 Vibe Coding 的對話式開發，Claude Code＋Stitch 的差異化在於 MCP 把設計工具直接接進 AI 助理，讓設計與開發在同一個 AI 介面裡閉環，省掉跨工具的匯出匯入。
四種方案定位比較
| 方案 | 強項 | 限制 | 最適合 |
|---|---|---|---|
| Claude Code＋Stitch | 設計與開發在同一 AI 介面閉環 | 後台整合要自己處理 | 一人團隊、快速原型 |
| Figma＋工程師 | 多人協作、設計精細 | 不會幫你寫程式 | 需要協作的團隊 |
| Elementor／Divi／Bricks | WordPress 內拖拉、外掛生態完整 | 設計自由受編輯器框架限制 | 長期維護的營運站 |
| 純 Vibe Coding | 對話生成程式碼靈活 | 缺視覺設計工具層 | 有設計背景的開發者 |
依專案規模與維護週期選方案的二維象限
比較表看完可能還是難選，這裡再給一個更直覺的二維象限。橫軸是「設計自由度」，縱軸是「長期維護成本」。把四種方案放進象限裡，你能一眼看出哪個方案落在你現在的需求上。
| 象限 | 設計自由度 | 長期維護成本 | 最匹配方案 |
|---|---|---|---|
| 快速原型區 | 高 | 低（用完即丟或轉交） | Claude Code＋Stitch |
| 團隊協作區 | 高 | 中高（需設計開發兩端） | Figma＋工程師 |
| 營運維護區 | 中（受框架限制） | 低（拖拉即改） | Elementor／Divi／Bricks |
| 純對話區 | 高（但要自己想視覺） | 視程式碼品質而定 | 純 Vibe Coding |
這個象限的核心訊息是：沒有一個方案是全面勝出。Claude Code＋Stitch 在「設計自由高、維護成本低」的快速原型區最強，但一旦進入「長期維護」的需求，WordPress 編輯器反而更省事。所以判斷順序是：先問這個專案要長期維護還是用完即丟，再問設計自由重要還是穩定重要，答案出來方案就出來。把這個象限跟前面的比較表搭配著用，選擇會更有依據。
對 Figma 來說，它是設計協作王者，但不會幫你寫程式；Stitch 把設計與生成綁在一起，適合不需要多人協作的一人流程。想把 Figma 學得更深，Figma 中文完整 UIUX 教學、Figma 設計師必備工具指南、Figma 網格系統與響應式排版 與 Figma 響應式行動版排版教學 是一整套。Claude Code 與 Figma 的核心差別，就在於前者多了「把稿轉成網頁」這一步；若想看另一種 AI 設計工具的長相，Canva AI 魔法工作室完整指南 是順手的對照。
對頁面編輯器，差異在產出物：編輯器在 WordPress 裡拖拉，產出的是 WP 頁面；Claude Code＋Stitch 產出的是獨立 HTML，自由度高但後台整合要自己接。對純 Vibe Coding，它偏向用對話生成程式碼，不強調視覺設計工具；Claude Code＋Stitch 多了 Stitch 的視覺決策層，對非設計背景的人更友善。想理解 Vibe Coding 的全貌，Vibe Coding 對話式程式開發入門 與 Vibe Marketing 氛圍行銷拆解 各有切入點。
選擇原則我會這樣收：要長期維護、要外掛生態、要多人編輯，選 WordPress 編輯器；要快速原型、要設計自由、要一人閉環，選 Claude Code＋Stitch。兩者可以接力。這也是為什麼懂 UI 與 UX 設計差異解析、網頁設計必備的關鍵元素 與 免費 UIUX 自學資源地圖 的人，能把這套工作流用得更有節制。
退一步看，這條 AI 自動化網頁開發工作流 的真正價值，是讓你把心力從重複勞動挪到判斷與把關。判斷「這一步誰負責」、把關「生成出來的東西能不能上線」，這兩件事 AI 暫時還取代不了。把這個心態調對，工具才會幫你加分而不是挖坑。對這類生成式流程的整體認識，Claude AI 完整使用指南、Gemini AI 入門到進階攻略、Perplexity AI 搜尋引擎完整指南 與 用 Gemini 搭配 Stitch 做網頁設計 都能擴展你的工具箱。
最後補兩個延伸場景。一是 用 AI 快速建立網站架構圖，可以在生稿前先把資訊架構理清楚，省得後面 Redesign 一直打掉重練；二是 Bento Grid 創意版面配置 與 一頁式網頁設計攻略，是 Variants 階段很實用的版型靈感來源。把這些跟 Landing Page 轉換率優化全攻略 搭著想，產出的就不只是稿，而是有轉換目標的稿。網站上線後，內容能不能被 AI 搜尋引用會直接影響流量，Google AI Overviews 與 SEO 策略、GEO 生成式引擎優化完整指南 與 AI 內容檢測工具原理與實測 是後續值得跟著讀的面向。
至於把站真的搬上線，網域申請與 DNS 設定全攻略、30 分鐘快速架好 WordPress 與 WordPress 架站新手五步驟教學 是收尾的三件套。工具會進化，但「先想清楚誰負責什麼、再讓 AI 接手重複勞動、最後人工把關收尾」這個骨架，短期內不會過時。
常見問題：Claude Code 搭配 Stitch 網頁設計
Claude Code 跟 Stitch 是什麼關係，能一起做網頁嗎？
能。Stitch 是做視覺決策的 AI 設計工具，Claude Code 是把設計稿轉成網頁程式碼的終端機助理，兩者用 MCP 協定串起來就能在同一條流程裡完成設計與開發。Stitch 負責色系、字型、版型與原型這些視覺決策，Claude Code 負責把這些決策轉成 HTML、CSS 與可在瀏覽器開的實體網頁，分工不重疊。
Stitch MCP 怎麼跟 Claude Code 串接？
在 Claude Code 加入 Stitch MCP 伺服器，讓它透過 MCP 協定認得 Stitch 的設計工具集，連不上通常是金鑰或伺服器路徑設定有誤，修正後重啟即可。排錯順序建議從最便宜的成因開始：先重啟、再查金鑰與路徑、最後才動到重裝。
Claude Code Skills 是什麼，對網頁設計有什麼幫助？
Skills 是讓 Claude Code 在特定領域擴充能力的機制，安裝 Stitch Skills 等於把懂 Stitch 設計語言的技能掛進來，沒裝等於只用半套。它攜帶的是該領域的專門指令與資源，讓 Claude Code 處理 Stitch 相關任務時更貼近設計工具的語意，減少跨工具的認知落差。
Stitch 的 Ideation、Redesign、Variants、Prototype 各做什麼？
Ideation 從主題構思多種版型、Redesign 依現有網址重畫、Variants 把同版型變出多種變形、Prototype 做可點擊的即時原型，四者剛好覆蓋從靈感到互動驗證的設計鏈。使用順序上，通常先定主結構與 Design Systems，再進 Variants 比細節，最後用 Prototype 驗證互動，亂了順序會多做很多白工。
怎麼用 Stitch 從一個網址直接匯入色系和字型？
用 Design Systems 功能，丟進目標網址就會匯入它的色系與字型，幫整套視覺語言快速定調，這是維持一致性最不能省的一步。匯入後建議巡一次結果，確認抓到的色票與字型真的符合你要的品牌方向，再把它當成後續 Ideation 與 Variants 的基準。
用 Claude Code＋Stitch 做出來的網頁可以直接上線嗎？
可以，但前提是先過一輪人工檢查：標題層級、圖片 alt、語意標籤、速度、RWD 與表單連結都要驗過，直接放生上線會把 SEO 與效能問題一起帶進成品。行動版預覽要擺第一順位，因為 Google 採行動優先索引，手機上的樣子才是主要被評分的版本。
不會寫程式的人能用這套工作流架站嗎？
能跑通原型與 Landing Page，但要做到可上線的成品，仍需具備 HTML 結構與 SEO 基礎觀念，完全零基礎建議搭配 WordPress 頁面編輯器收尾。換句話說，這套工作流能幫你跨過「從零到看得到稿」這段，但「從稿到可營運的站」這段仍需要懂一點網頁基本功。
Stitch 生成的網頁 SEO 和速度會不會很差？
取決於你願不願意收尾把關。AI 生成的程式碼在結構與效能上仍須人工審過，不審就上線，排名與載入速度都會吃虧。Google 已將頁面速度與 Core Web Vitals 列入排名信號，所以速度檢測必須排進上線前清單，這一步省不得。
Stitch Voice Canvas 語音模式要怎麼用？
Voice Canvas 是用語音輸入描述設計需求的模式，具體操作以 Google Stitch 官方說明為準，能確定的功能描述才寫進實作，避免用到未驗證的細節。它的價值在於讓你在描述設計需求時可以邊說邊想，對不擅長打長段文字的人是另一種輸入選擇。
Design Systems 的 token 會自動對應成 CSS 變數嗎？
會，前提是 token 隨設計稿一起交給 Claude Code。Claude Code 接手後會把這組 token 對應成 CSS 變數，寫進 :root 或設計系統檔，讓所有元件共用同一份定義。若 Design Systems 沒先定好，Claude Code 只能從圖面還原顏色，失真風險會明顯上升，所以這一步不能跳。
跑完一輪生成的稿不滿意，要重生成還是局部改？
結構性的問題（主版型、資訊架構、hero 擺法）建議重生成或回到 Ideation 重新找方向；細節性的問題（配色微調、密度、單一區塊）用 Variants 局部改更有效率。判斷標準是「這個修改會牽動幾個區塊」，牽動越多越該回到上游重來，硬在下游改反而會越改越亂。