·9 分鐘閱讀

Stitch 設計稿轉 Android：Antigravity 工作流程

Google 官方示範的端到端工作流程：Stitch 設計稿經 Antigravity 與 Android CLI 轉換為 Jetpack Compose 元件，模擬器驗證後在實機執行，並與 Web 路線對比。

S
Stitch Prompt Team
Content Team
StitchAI教學

在此之前，Stitch 的「設計到程式碼」鏈路基本都落在 Web 上：HTML、React、Vue、Next.js。Android 開發者看得到設計稿，但拿不到原生產物。

情況在本週發生了變化。Google for Developers 官方示範了一條端到端工作流程：把 Stitch MCP 接入 Antigravity 與 Android CLI 後，Agent 可以自動完成從設計稿到原生應用的完整鏈路——產出的不是 WebView 包裝，而是真正的 Jetpack Compose 元件。

本文拆解這條工作流程的三件套分工、環境搭建、實作步驟與驗證閉環，並說明哪些細節是官方示範確認的、哪些還需要實測補充。

說明：本文基於官方示範與 Android CLI 發布說明整理；具體版本行為請以你安裝的 Antigravity 與 Android CLI 為準。

一、官方示範說了什麼：從 Stitch 設計稿到實機執行

官方示範的工作流程可以概括為四步：

  1. 從 Stitch 匯入 UI 設計稿。
  2. 由 Agent 轉換為原生 Jetpack Compose 元件（不是 WebView，也不是 React Native）。
  3. 在模擬器中驗證建置與介面。
  4. 在實體裝置上執行最終建置。

四步都由 Agent 自動完成，人負責下達任務與驗收結果。這條鏈路的標誌性意義在於：Stitch 的落地面從 Web 擴展到了 Android 原生。

二、三件套分工：Antigravity / Stitch MCP / Android CLI

三個工具各司其職，缺一不可：

工具角色負責的事
Antigravity宿主 Agent 環境管理 Agent、任務與執行流程
Stitch MCP設計源接入讓 Agent 讀取 Stitch 專案中的設計稿
Android CLI原生工程能力建置、渲染驗證與裝置部署

背景資訊：Antigravity 2.0 已正式整合 Android CLI 與 skills，並帶來平行本機 Agent 管理、Projects、排程任務（/schedule）以及 CLI 與 SDK 等能力。

三、環境搭建（含 Android CLI 安裝）

Android CLI 支援主流套件管理員安裝，依平台選擇：

# macOS / Linux
brew install android-cli

# Windows
winget install android-cli

# Ubuntu
sudo apt-get install android-cli

具體套件名與最新安裝方式以官方發布說明為準。安裝完成後，在 Antigravity 中完成兩件事：

  1. 設定 Stitch MCP，讓 Agent 能存取你的 Stitch 專案。
  2. 安裝 Android skills，讓 Agent 具備建置與驗證 Android 工程的能力。

四、實作：設計稿 → Jetpack Compose 元件

環境就緒後，用一條任務指令啟動整條鏈路：

Import the login and home screens from my Stitch project [ID],
convert them into Jetpack Compose components following Material 3,
validate the build in the emulator, then deploy to my connected device.

這條指令包含四個關鍵約定：

  • 來源：指定 Stitch 專案與具體頁面（login / home）。
  • 目標：轉換為 Compose 元件，並遵循 Material 3 規範。
  • 驗證：先在模擬器完成建置驗證。
  • 交付：部署到已連接的實機。

五、驗證閉環：模擬器、Journeys 與實機

Android 側的驗證手段比 Web 更豐富，官方示範裡用到三個層級：

  • 模擬器建置：先確認程式碼可編譯、介面可渲染。
  • Journeys：用自然語言描述使用者流程，讓工具自動驗證互動路徑是否走通。
  • 實機執行：最終建置部署到實體裝置，確認真實環境表現。

這套「模擬器 → 流程 → 實機」的驗證順序值得單獨借鏡：即使不用 Stitch，也可以把它作為 Android Agent 工作流程的預設驗收路徑。

六、與 Stitch → React/Vue Web 路線的比較與選擇

兩條路線的產出物完全不同，選擇取決於目標平台：

維度Web 路線（React / Vue）Android 原生路線（Compose）
產出物網頁程式碼與元件Jetpack Compose 元件
驗證方式瀏覽器模擬器與實機
適用情境網站、Web 應用、跨端Android 應用、原生體驗
生態系工具Next.js、Vite、shadcn/ui 等Android Studio、Gradle 等

判斷很簡單：目標平台是 Web 就走 Web 管線，是 Android 就走原生管線。兩邊可以共享同一份設計稿與 DESIGN.md 規範，但不要指望產物互相替代。

七、限制與注意事項

  • 原生轉換不是像素級：設計稿轉 Compose 元件會遵循 Material 約定，視覺細節需要人工微調。
  • 基礎工程知識仍有價值：建置失敗、簽章、相依性衝突等問題，Agent 不一定能全部自動解決。
  • 版本細節以實測為準：官方示範確認的是端到端鏈路與產出物類型；具體命令參數請以本機 CLI 輸出為準。
  • 從小範圍開始：先轉換 1-2 個頁面跑通鏈路，再擴大範圍。

八、常見問題（FAQ）

Q1：沒有 Android 開發經驗，能用這條鏈路嗎？

可以起步，但建議了解基本的 Gradle 建置與模擬器概念；遇到建置錯誤時，基礎認知能顯著縮短排查時間。

Q2：生成的 Compose 程式碼品質如何？

屬於「可執行的起點」，不是像素級還原。建議按 Material 3 規範逐步調整，並用模擬器驗證每一步。

Q3：和 Stitch 直接匯出 React 程式碼有什麼區別？

產出物不同：一個是 Compose 元件，一個是 Web 程式碼。選擇依據是目標平台，兩者不能直接互換。

九、總結

這條官方工作流程把 Stitch 的能力邊界從 Web 推到了 Android 原生：設計稿、Agent、原生元件、模擬器、實機，第一次串成完整的官方鏈路。對 Android 團隊來說，值得先用一個小專案驗證流程，再決定是否納入正式開發環節。

繼續閱讀：

← ← 返回部落格