过去两周，我把 Google 的两项更新串起来做了完整实践：Stitch 用来生成设计与交互原型，AI Studio 的 Build 负责把页面落到可运行的应用。
我的结论是：对个人开发者和小团队，二者可以形成一条轻量却完整的“设计—原型—应用—部署”链路。
相较于单独用设计工具或代码生成器，这套组合的优势在于设计系统的可复用性和基础设施（数据库/鉴权）的低门槛集成。
下面是我基于真实项目的体验、差异化分析和适配性建议。
产品更新速览
Stitch（界面与能力升级）
界面风格接近 Figma，新增 DESIGN.md 设计系统，支持从静态设计快速生成交互式原型。
推出 MCP 与 SDK，并提供 Skills 仓库。
AI Studio Build（能力扩展）
新增实时多人、协作空间、共享工具；内置数据库与身份验证能力。
支持引入 API、集成支付、Next.js 构建；计划支持连接 Drive/Sheets，并一键迁移到 Antigravity。
Firebase Studio 将于明年三月弃用，应用需在 AI Studio 中创建与管理。
Stitch 与 AI Studio Build：定位与适配性对比
| 维度 | Stitch | AI Studio Build |
|---|---|---|
| 功能范围 | 设计生成、DESIGN.md 设计系统、交互原型、导出到多平台 | 从页面到可运行应用，内置数据库/鉴权，支持 API/支付/Next.js |
| 技术特征 | 画布式编辑，Design Systems 面板，MCP/SDK/Skills 扩展 | 应用脚手架、自动依赖配置、与 Firebase 等服务的一键集成 |
| 使用门槛 | 偏设计与原型能力，提示与画布操作为主 | 偏工程落地，需要基本的部署与环境变量知识 |
| 适合人群 | 产品经理、设计师、前端开发（关注设计一致性与快速原型） | 独立开发者、小团队（需要快速产出可用 MVP） |
| 典型输出 | 页面集合 + DESIGN.md（可复用的设计规范） | 可运行的 Web 应用仓库 + 配套配置 |
实践 1：用 Stitch 做折叠屏「AI 阅读」App 原型
生成与原型联动
- 英文提示目标：折叠屏适配的 AI 阅读安卓应用。
- 左侧显示思考过程，中间为颜色/字体/图标预览，自动生成多页面。
- 右上角播放按钮可一键进入交互式原型，页面间可切换预览。
- 问题记录：Profile 页面首次未链接；通过“添加屏幕”修复后无阻。
- 平板模式：左侧文章内容，右侧 AI Research 助手，交互清晰。
通过截图迁移风格
- 上传 Exa 网站截图后，Stitch 快速生成一套新主题。
- Modify → Design Systems 面板可细调主题色与字体。
- 批量应用主题首次未成功；改用对话框“apply style to @页面”逐页应用。
- 异常点：底栏原有四个按钮，生成后变为三个；删除重生可解决。
- 画布注意：内容可能生成在其他区域，缩放查找即可。
DESIGN.md 的价值
- 内容含设计语言、字距字号、阴影层级、玻璃与渐变规则、适配性、应做/禁做等细则。
- 即使不在 Stitch 完成全流程，也可将 DESIGN.md 提供给代码生成工具，统一 UI 风格。
- 实践经验：先生成一套页面与 DESIGN.md，再将 DESIGN.md 交给代码助手（如 Claude Code）。相比直接让模型写 HTML，整体一致性与对齐通常更稳定。
导出与打通
- 导出到 AI Studio / Figma / Jules（云端 Agent）或 ZIP（截图 + HTML）。
- 导出至 AI Studio Build 时，Stitch 会附带提示语、图片和 HTML，Build 可据此生成页面。
实践 2：用 AI Studio Build 做「时光邮局」并部署
功能与界面
功能：写信（支持语音输入）、选择信纸风格（复古/牛皮/方格/稿纸）、基础格式按钮、拆信日期与心情标签、封存动效（疑似使用 Framer Motion），右侧时光轴记录地点与时间。
数据：使用 Firebase 存储，登录后跨设备可读。
生成：核心界面与基本交互由 Gemini 3.1 Pro 一次提示完成。
构建到优化
首轮要求：实现功能并具备持久化。Build 初始建议为本地存储。
二次要求：接入 Google 登录，并限定仅我可登录；数据迁移至 Firebase。
配置体验：Build 弹出 Firebase 配置窗口，一次性集成成功（包含鉴权与存储）。
代码分析：下载仓库后，用 Cursor 的 Composer 2 分析技术栈：React 19 + Vite 6 + Tailwind CSS v4 + Framer Motion；并给出优化建议。
部署与注意事项
快速发布：可直接在 Build 内 Publish 用于演示。
正式部署：我选择 Cloudflare。Build 提醒需先处理环境变量，建议改为标准环境变量写法。
流程：按建议更新 .env 模板与说明；检查 .gitignore；安全项自检。Build 暂不支持直接 push 到 GitHub，我使用本地 Git 与自有工具完成部署。
计费提示：授权 Build 访问 Firebase 后，收到邮件提示从 Spark 自动升级到 Blaze。请在 Firebase 定价 页面关注配额与用量，避免突发费用。
适配性与建议
适合的团队/角色
产品经理/设计师：用 Stitch 建立统一的设计系统与原型，快速验证信息架构与交互。
独立开发者：Stitch 负责视觉一致性，Build 负责骨干功能（数据库/鉴权），合并后快速得到可运行 MVP。
小团队：用 Stitch 迭代规范与组件，用 Build 拉起端到端样例，再交由工程化工具优化与接入内部服务。
局限与风险点
Stitch：主题批量应用存在不稳定；画布布局偶有偏位；组件数量与链接逻辑需要复核。
Build：环境变量与仓库管理需要工程实践；当前不支持一键推送到 GitHub；对多环境（开发/预发/生产）切换仍需自定义脚本。
数据与合规：接入 Firebase 后注意访问控制、密钥管理与费用上限。
推荐工作流（适用于个人/小团队）
- 在 Stitch 通过提示生成页面与 DESIGN.md，完成风格与组件基线。
- 导出到 AI Studio Build，利用图像与 HTML作为参考生成应用骨架。
- 在 Build 中一键集成 Firebase 鉴权与存储（视需求接入 API/支付）。
- 下载代码仓库，用代码助手（如 Cursor）做技术栈检查与优化。
- 处理环境变量，接入版本管理，部署至 Cloudflare 或其他平台。
- 监控 Firebase 使用量，设置预算与配额；以 DESIGN.md 迭代 UI 规范。
结语
站在产品经理的视角，我更关注“从想法到可上线版本”的链路是否可控。
Stitch 解决了设计一致性与可交互原型的生成，AI Studio Build 解决了脚手架与基础设施的集成，两者组合能把试错成本降到较低。
对于个人开发者和小团队，这是一套可执行的更快路径：先有系统化的设计，再快速验证应用形态，最后再进入工程化细化。
这种方式不追求“最强”，重点在于“够用、可复用、可落地”。
资源链接
Stitch：https://stitch.withgoogle.com
Stitch Skills 仓库：https://github.com/google-labs-code/stitch-skills
AI Studio Build：https://aistudio.google.com/apps
Firebase 定价：https://firebase.google.com/pricing