[Agentic UX 實作-Google Stitch 篇] 嘴巴設計的 UI，代碼收得了尾嗎？Stitch + Antigravity 的「規格防腐」指南
Can Code Survive Vibe-Design? Preserving Engineering Specs in the Age of Streaming Canvas
序言：如果說 Claude 讓我們體驗到「一個人跑五個 isolation worktree」的並行快感，那麼 Stitch（Google Labs 的 AI 原生軟體設計平台）則把這場競速拉進了「畫布原生（Canvas-native）」的時代。
最近 YouTube 上，知名 AI 創作者 Sam Witteveen 拍攝的一支熱門影片 《Google Stitch Just Became an AI Figma (And It’s Free)》 引發了熱議。影片中，他對著麥克風說一句：「把選單改成毛玻璃效果，並給我三種結帳卡片的變體。」
畫布上的 UI 隨即像液態金屬般即時串流、更新，並自動吐出對應的程式碼。底下留言直呼這將「徹底消滅 Figma 與前端切版」。
聽起來像是設計師與開發者的終極救星。但如果把這個畫面挪進真實的團隊交付鏈，尷尬就來了—設計師在 Stitch 裡用語音調得越爽，後續負責實作狀態與 API 的 Antigravity（程式開發助手）和部署平台 Netlify 就被淹沒在越多的規格衝突與漂移中。
聽起來像是完美的「設計到程式（Design-to-Code）」終極流線。但最近前端社群中，許具 F2E 實務背景的開發者拋出了一個有趣的靈魂拷問：「既然 AI 已經能依據語音指令直接在畫布上長出原型與程式碼，那我們是否還需要 Figma 或 Stitch 這種媒介來對齊需求？」
答案是肯定的。只要需求端（設計）與執行端（代碼）不是由同一個單一實體（不論是人類大腦還是特定 Agent）來完全接管，雙方之間就永遠需要一層用來校準規格的溝通緩衝。因為 UI/UX 從來不只是感性美學的包裝，而是一門嚴密的「系統規格工程學」。
這門工程學的核心，在於將抽象的商業與使用者邏輯，精確編譯為軟體工程能無縫對接的約束規格。
一旦缺乏規格治理的框架，AI 設計出的產物很快就會顯露其偷懶的本質：將 Auto Layout 的排版彈性（Hug）改以固定寬度（Fixed）寫死、略過變數（Variables）直接硬編碼色值、將圖層結構搞得雜亂無章，甚至為了應付畫面而隨手拉一個靜態矩形（Frame）來偽裝點擊按鈕。
AI 是一個很聰明但極愛偷懶的新人。本篇將結合社群 F2E 的實務觀點，重新梳理在 Stitch + Stitch Agent ＋ Antigravity ＋ Netlify 現代流線下，AI/UX 工作者該如何逐步展開工作流，而不至於溺死在 Agent 創造的程式泥淖中。
作者補充
我看完 Sam Witteveen 那支影片的第一個反應也是「等等」—影片展示了用語音和 prompt 在畫布上即時串流 UI，然後一鍵導出 Figma，看起來無縫又炫技。但影片中他在展示「Experimental Mode（實驗模式）」與 Figma 導出時，其實悄悄跳過了一個致命細節：Stitch 產出的 HTML 程式碼與 Figma 變體，完全是視覺導向的。
當你把這些產物倒給開發代理（如 Antigravity）時，它根本不認識你既有的設計系統 Token，更無法承載複雜的業務邏輯狀態。影片極力推崇「畫布即代碼（Canvas-as-Code）」的視覺便利，卻把「規格治理」與「雙向同步」的工程重擔壓得很小聲。
但對真實交付鏈的 AI/UX 實作者來說，如何防止設計與程式的「雙向漂移」，才是決定這個工具鏈能否落地的關鍵。
還記得我們在前幾篇反覆討論的 Design Critique 難題與 Arbiter（仲裁者） 的角色嗎？在單一 Agent 對話的時代，我們問的是「哪個原型是你做的」；而當我們走進 Stitch + Antigravity 的雙代協同，這個問題的維度升高了—因為設計與代碼由不同的 Agent 分流處理，如果沒有人為設計的「軌道」，兩者會以極快的速度發生物理漂移。
剛拿到 Stitch 測試權限時，我的第一個反應是「UI 設計師要失業了」。你只要說「給我三個不同風格的結帳抽屜」，Stitch Agent 就能在畫布上即時渲染出高保真的互動原型。但當我試圖把這個原型丟給 Antigravity 串接 Firebase 時，工程的磨損感立刻鋪面而來。
Stitch 吐出的程式碼是「視覺導向的 static HTML」，而 production 程式碼是「邏輯導向的 state component」。Stitch Agent 一旦重新串流（stream），就會像無情的壓路機一樣，把我寫在 Antigravity 裡的 React 狀態與事件監聽全部壓扁。
還有一個更常發生的反向場景：Code to Figma（程式回灌畫布）。
誠如社群 F2E 角色所言，我們常常打開 Figma/Stitch 時，發現設計檔是空的，但程式碼早就被工程師刻出來了（可能是 PM 急著 demo，也可能是 side project 一路長到產品化）。這時我們需要的不是 Figma to Code，而是把現有的程式碼回灌到設計畫布，讓設計師有東西可以接著改、接著建設計系統。
在這套「雙向漂移」的複雜工具鏈中，設計與程式的同步（Sync）成了核心問題。
我們不需要像前幾篇那樣機械化地套用三層 context 或職涯對照，但我們必須釐清規格與邏輯的交界，並引入獨立 Subagent 進行 QA 驗收，才能把這套協作軌道固定下來。
系列導讀：這是「Agentic UX 實作系列」的第二篇橫切面—聚焦於「雙代協同與部署」的治理。當我們從單一 Chat 介面（Claude）走向「畫布設計（Stitch）→ 程式實作（Antigravity）→ 即時雲端部署（Netlify）」的完整流水線時，我們需要一套全新的成熟度刻度與自測尺。
文件與交付物對照（DESIGN.md 治理規則）：
雙代協同的痛點：當畫布的流體性撞上工程的確定性
在傳統工作流中，設計到開發的摩擦發生在「Figma 標註」與「前端切版」之間。而在 Stitch + Antigravity 的世界裡，這個摩擦被移到了兩個 AI 代理的交界處。
正如 Sam Witteveen 在影片中展示的，Stitch Agent 的優勢在於 流體性（Fluidity）。
它是設計師的「Senior Partner」，用語音對談就能在畫布上瞬間渲染出高保真介面與微小的轉場動畫。然而，這種流體性對負責寫 production code 的 Antigravity 來說是個災難。
Antigravity 需要的是 確定性（Determinism）。
它必須知道 API 欄位是什麼、State 怎麼傳遞、按鈕點擊後要觸發哪個 React Hook。如果設計師在 Stitch 畫布上大喊：「把按鈕往右移，背景改為漸層，並加上結帳提示！」Stitch Agent 會非常順從地重新整理 HTML/CSS，甚至會隨手改掉 DOM 的 class name 和結構。
這時候，如果 Antigravity 正好在為這個按鈕寫 Stripe 串接邏輯，原本寫好的事件綁定就會瞬間失效。這也是為什麼我們需要 90 度的反問軸：
處方：雙代協同的第一條鐵律，是畫布不能直接凌駕於程式庫之上。我們必須在兩者之間建立一個名為 DESIGN.md 的緩衝區。設計在 Stitch 裡改變，必須先在 DESIGN.md沉澱為 token 變更，再由 Antigravity 讀取並重構組件。
雙代協作的五級展開與自測尺
L1 畫布探索 → L2 規格定義 · 自測：Dedupe Variants（變體去重）
展開動作：在 Stitch 畫布上，設計師用語音指令進行 Vibe Design：「幫我做一個帶有高科技感、暗色調的 UX Auditor 報告卡片。」Stitch Agent 會瞬間在畫布上長出 5 種不同漸層與陰影的卡片變體。
自測尺（Dedupe）：此時，你是否將這 5 種變體的 HTML 全部丟給 Antigravity 去實作？如果是，你犯了 L1 的典型錯誤。 在 L1 階段，Stitch 產生的只是「視覺材料」。
這也是 Design Critique 面臨的升級版考驗。當介面在畫布上以每秒數十幀的流速生成，你不能指著畫面說這是你親手畫的，你必須指著
DESIGN.md說：「這是由我定義的規格限制，所推導出的最優解。」 走到 L2 的訊號是：你能在畫布上主動去重，只留下一套，並要求 Stitch Agent 導出 [DESIGN.md]
L2 規格定義 → L3 邏輯實作 · 自測：Spec Decoupling（規格解耦）
展開動作：將 Stitch 產出的 DESIGN.md 放入專案目錄。DESIGN.md 中記錄了所有的設計變數（顏色、間距、組件結構）。Antigravity 讀取此文件，開始初始化 React 組件的 TypeScript 定義。
自測尺（Spec Decoupling）：
不要指望 AI 無中生有建系統：如果你直接叫它「把 HTML 畫到 Stitch」，AI 會毫無節制地用 Frame 從頭刻到尾。你必須先建設計系統，初始化 Variables、Styles 與 Components（可以使用開源的 MUI、Antd 等作為 Library）。
要 AI 爬網站，不如要他爬檔案：不要讓 Stitch Agent 拿著插件直接去扒網站資訊。你應該讓它把設計系統 Library 的資訊整理成一個靜態檔案（例如
library-spec.json）再丟給它讀，否則 AI 很容易和自己的元件名稱撞名，導致 Token 大量浪費。規格必須與狀態邏輯完全解耦：
DESIGN.md僅能定義樣式與結構骨架，不能寫死業務邏輯與 API 欄位。
{合作廣告}
🧑🎓 UX 訂閱制學習計劃：把 human-in-the-loop 變成你的日常。這也是我會特別推薦 #UX訂閱制學習計劃 的原因：它不是一次性的 bootcamp，而是把借位、補位、入位拆開來，串成 3 月到 12 月的一條學習軸線。透過每月 Podcast 和專欄，先向不同領域的 UX / 產品 / AI / 服務設計講師「借位」
透過直播與 Circle 社群討論，在你的真實案子與問題上進行「補位」
