·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 团队来说，值得先用一个小项目验证流程，再决定是否纳入正式开发环节。

继续阅读：

← ← 返回博客