昨天直播示範了 Google Stitch 串接 Claude Code 的完整流程。
原本要花一整天從零開始刻的 UI，現在可以先用文字描述需求，快速產出一套畫面，再把設計脈絡交給 AI coding agent，繼續往真正能執行的前端程式走。
但這件事你的老闆不需要知道。
不然他只會覺得：
「喔，所以你現在可以再多做三倍的量？」
開個玩笑。
真正重要的不是「AI 幫你生畫面」，而是 設計、規格與程式終於可以放在同一條工作流裡討論。
這篇整理我在實作中看到的幾個重點。
先講結論：Stitch 不只是生一張 UI 圖
Google 目前把 Stitch 定位成 AI-native 的設計畫布。你可以從自然語言開始，建立高擬真 UI，接著繼續迭代、串接畫面、預覽互動流程，甚至把設計規則帶到其他設計或 coding 工具裡。
它的價值不只是：
「幫我畫一個漂亮的首頁。」
而是：
「我有一個產品目標，請先理解使用者、資訊架構、視覺語言，再幫我把它變成可以繼續工作的設計資產。」
Google 也把 DESIGN.md 當成設計系統交換格式之一。這個方向很值得注意，因為它讓顏色、字體、間距、元件規則不再只藏在 Figma 或截圖裡，而是可以被 agent 讀懂、引用與延續。
1. Stitch 幫你把最無聊的第一版先做完
每次拿到需求，最花時間的常常不是最後的細節，而是從零開始把第一版畫面堆出來：
- 首頁要放哪些區塊？
- 導覽列要怎麼安排？
- 卡片、按鈕、表格要用什麼比例？
- 空狀態、錯誤狀態、手機版要不要一起想？
這些事情都很重要，但不一定需要每次都靠人工從白紙開始。
在 Stitch 裡，你可以先描述：
- 產品是給誰用的
- 使用者要完成什麼任務
- 希望使用者感受到什麼
- 有哪些頁面和主要流程
- 參考哪些產品或視覺風格
它會先幫你建立一個可以討論的版本。這個版本不一定一次就對，但它至少把「完全空白」變成「有東西可以批評」。
這差很多。
因為設計真正需要人的地方，通常不是把第一個矩形拉出來，而是判斷：
這個畫面有沒有真的幫助使用者完成事情？
2. 規格越清楚，後面要改的越少
直播實測時最明顯的差異，就是詳細 prompt 和簡略 prompt 產出的完整度真的不一樣。
簡略寫法可能是：
幫我做一個遊戲 App 的首頁。
這句話不是不能用，但它沒有告訴工具：
- 遊戲的類型
- 目標玩家
- 主要轉換目標
- 首頁最重要的資訊
- 色彩與情緒
- 需要哪些互動狀態
- 手機比例與響應式需求
比較好的寫法會像這樣：
請設計一個給 18–30 歲玩家使用的手機遊戲首頁。核心目標是讓回訪玩家在 10 秒內看到每日任務、目前體力與繼續遊玩的入口。視覺風格採深色背景、低飽和藍紫色、少量螢光綠作為 CTA。請同時規劃新手空狀態、載入狀態、錯誤狀態與底部導覽列。
你花十幾分鐘把需求寫清楚，通常比後面反覆說「不是這個感覺」有效率很多。
這不是 prompt 魔法，而是需求分析。
AI 只是把你寫下來的需求放大執行。需求本身模糊，產出的東西也會跟著模糊。
3. MCP 的價值：不是複製貼上，而是讓工具互相取得上下文
MCP 可以把它想成 AI 工具之間的標準接頭。Anthropic 對 MCP 的描述是：它提供一套標準方式，讓應用程式把上下文、資料與工具提供給大型語言模型。
放到 Stitch 和 Claude Code 的情境裡，差別是這樣：
沒有 MCP 的流程
- 在 Stitch 做完畫面
- 截圖
- 下載資產
- 複製顏色、字體、間距
- 手動告訴 Claude Code 這個畫面長什麼樣
- 寫程式
- 發現實作和設計不一致
- 回去找資料，再重來一次
有 MCP 的流程
- 在 Stitch 建立並整理設計
- 由 Claude Code 取得 Stitch 專案脈絡
- 讀取設計系統、畫面與相關資訊
- 先產生
DESIGN.md或等價的設計規格 - 再依照規格實作 React / Next.js 頁面
- 由 agent 協助比對與修正
差別不是少打幾個字，而是少掉一整段人工搬運上下文的工作。
4. Claude Code 接到 MCP 之後，才比較像真的 coding agent
Claude Code 本身可以透過 MCP 連接外部工具與資料來源。常見的設定方式包括在專案根目錄放置 .mcp.json，或使用 claude mcp add 設定伺服器。
連接之後，建議不要一開始就下「把整個網站做完」這種大指令。
比較穩定的流程是分階段：
第一步：先確認連線
先讓 Claude Code 列出目前可用的 Stitch 專案，確認 MCP 真的連上，而不是直接開始改檔案。
第二步：先抓設計脈絡
請它讀取指定專案，整理：
- 色彩系統
- 字體與字級層級
- 版面寬度與間距
- 元件狀態
- 頁面之間的導航關係
然後要求它產生一份 DESIGN.md。
第三步：先做一頁
不要一次生成整個產品。先挑一個最重要的頁面，確認：
- 寬度與斷點是否正確
- 元件命名是否合理
- CSS 是否能維護
- 設計規則是否真的被遵守
第四步：再擴充頁面
第一頁的結構確認後，再把同一套設計系統延伸到其他畫面。這樣比每頁各自 prompt 一次穩定很多。
5. DESIGN.md 可能會變成新的前端協作介面
以前設計交付常見的形式是：
- 一份 Figma 檔案
- 幾張設計稿
- 一份標註圖
- 一串聊天紀錄
這些東西不是沒用，但對 coding agent 來說不一定是最容易處理的格式。
一份好的 DESIGN.md 可以直接寫：
| |
這種格式的好處是：人看得懂，agent 也比較容易引用。
但要注意，DESIGN.md 不是把 Figma 完全取代掉。它比較像是設計規則的可讀版本，讓設計和程式之間多一個共同語言。
6. 這不是「設計師被取代」的故事
我覺得這件事最容易被誤解的地方，就是大家把它講成「AI 會不會取代設計師」。
實際上，Stitch 最先取代的比較像是：
- 從零開始畫線框的重複工作
- 反覆複製貼上的規格整理
- 每頁重新交代一次相同的設計規則
- 把截圖和標註搬到另一個工具裡
它沒有自動替你決定：
- 這個產品到底該不該做
- 使用者真正的問題是什麼
- 這個互動是否符合品牌性格
- 這個畫面是不是只是看起來很漂亮
所以比較精準的說法應該是：
AI 讓設計師更快通過低價值的第一版，然後把時間留給判斷、取捨和創意。
但前提是，你真的知道自己要判斷什麼。
7. 前端工程師真正要學的，不只是下 prompt
如果你是前端工程師，這套工作流帶來的要求其實更高。
你不能只會說：
幫我把這張圖刻出來。
你還要懂：
- 設計系統如何轉成元件系統
- 哪些樣式應該抽成 token
- 哪些互動狀態不能漏
- 如何處理 responsive layout
- 如何讓生成的程式碼可測試、可維護
- 如何檢查 AI 是否偷偷引入不一致的實作
換句話說，AI 讓第一版變快，但也讓 code review 變得更重要。
如果你沒有基本的 HTML、CSS、JavaScript、TypeScript、React 和 Git 能力，AI 只會很快地幫你生出一堆你不敢改的程式碼。
速度不是能力的替代品。
速度只是把你的能力放大。
我現在會怎麼安排這套工作流？
如果是我自己要做一個新功能，我會照下面順序：
- 先寫產品目標：這個功能要幫誰解決什麼問題？
- 用 Stitch 做方向探索：先出兩到三個版本，不急著選第一個。
- 整理設計規則：把顏色、字體、間距與元件狀態寫進
DESIGN.md。 - 用 MCP 讓 coding agent 取得脈絡：避免只丟截圖和一句「照這個做」。
- 先做最小可行頁面：先確認骨架、資料流與互動。
- 跑 lint、typecheck、測試與實機畫面：AI 產生的程式碼一樣要驗證。
- 最後才做細節拋光：動畫、文案、空狀態和錯誤處理不要一開始就全部混在一起。
這樣做的好處是，每一步都有可以檢查的產物，不會變成 AI 一次生成一大坨，最後沒人知道問題從哪裡開始。
最後
Google Stitch 加上 MCP 和 Claude Code，真正改變的不是「設計師今天少畫幾個畫面」。
真正改變的是：
設計規則、產品脈絡與程式實作，開始可以在同一個工作流裡被傳遞。
這會讓設計和前端之間的交接更快，但也會要求每個人把自己的專業講得更清楚。
設計師要更會描述意圖。
工程師要更懂設計系統。
PM 要更會寫需求。
而 AI agent 會把這些模糊的地方全部放大給你看。
所以，不要把它想成「按一下就完成網站」。
比較接近真相的說法是：
你把需求、設計與規則講清楚，AI 才有機會幫你把第一版做得夠快；接下來真正有價值的工作，仍然是你的判斷。