我的Stitch -> Claude Code 工作流

我不是设计师。我从未声称自己是。

但当你独自构建产品时，你会不断与自己进行这种安静的协商。这个卡片需要更多内边距吗？侧边栏真的有必要吗？为什么这个仪表盘看起来像是2009年建的？我花了三周时间迭代一个UI，内心深处知道它仍然看起来像是开发者的最佳猜测。事实也确实如此。

就在那时，我开始认真对待Google Stitch。

1、Google Stitch是什么，为什么你应该关注？

Google Stitch（stitch.withgoogle.com）是Google实验室推出的AI设计工具，由Gemini 2.5 Pro驱动。你用 plain English 描述你想要什么，它就会生成实际的UI：界面、组件、完整的设计系统。不需要Figma技能。不需要与自动布局搏斗。只需要提示词。

我知道，这听起来像是过去五年每个"无代码"产品的宣传。请继续听我说。

Stitch做得对的地方在于，它不只是让东西看起来好看。它生成结构化的HTML和CSS输出，编码代理实际上可以读取和处理。它还会生成一个叫DESIGN.md的东西，一个可移植的设计系统文件，以AI代理（如Claude Code，Anthropic的基于终端的编码代理）原生理解的格式捕捉你的颜色token、排版比例和布局规则。

正是这种组合让这份工作流真正与众不同。

2、在我们继续之前：MCP是什么？

MCP代表Model Context Protocol（模型上下文协议）。把它想象成AI工具的USB-C端口。你的AI代理直接连接到外部服务并实时与它们通信，而不是在应用程序之间来回复制粘贴设计规范。

Stitch有一个MCP服务器。一旦连接到Claude Code，你的代理就可以直接读取你的设计，查看组件结构，提取颜色token，并生成真正匹配你在Stitch中构建内容的代码。不需要复制粘贴。没有翻译损失。

3、没人提到的Token问题

这是我在烧了四五次上下文在UI迭代上之后，才艰难发现的东西。

当你要求Claude Code"清理仪表盘布局"而没有设计系统时，实际发生的是这样的：Claude读取你的组件文件。它猜测间距。它重写JSX。有时它会建议来自你甚至没有在使用的库的CSS。然后你说"不，更接近我之前的样子"，它又重来一遍。一下午进行15轮这样的操作，你就在内边距值上烧掉了大部分上下文窗口。

前面的插图大致捕捉了这在实践中的样子。在一个中等复杂度的仪表盘构建中，粗略的分布是：很大一部分token流向了Claude并不擅长的设计决策，只有一小部分流向了实际的逻辑和连接。翻转这个比例，你的构建速度就会更快。

4、设置集成：两条路径，选一个

这是大多数文章完全跳过的部分。你有两种方法可以认证Stitch与Claude Code的连接。它们真的不同，你选择哪一种取决于你想处理多少Google Cloud相关的事务。

在开始任一路径之前的快速提示： 确保你已安装Node.js 18或更高版本。运行node --version检查。如果显示的是旧版本，请先更新。这个错误花了我15分钟，我回不去了。

4.1 Stitch API Key方法（更简单，推荐给大多数人）

这是更简洁的路径。没有Google Cloud设置，没有gcloud CLI，没有OAuth向导。Stitch直接在应用内生成API key，你将它作为HTTP header传递给Claude Code。就这么简单。

步骤1：生成你的Stitch API Key

访问stitch.withgoogle.com并登录。点击右上角的头像，然后从下拉菜单中选择"Stitch settings"。导航到API key部分并点击"Create key"。立即复制并存储在安全的地方（密码管理器，不是便利贴）。你不会再看到它了。

步骤2：将Stitch连接到Claude Code

打开你的终端并运行这个单一命令：

claude mcp add stitch --transport http https://stitch.googleapis.com/mcp \
--header "X-Goog-Api-Key: YOUR-API-KEY" -s user

将YOUR-API-KEY替换为你刚才复制的key。-s user标志会将它全局存储在你所有的项目中。

就这些。Claude Code自动注册Stitch MCP服务器。不需要编辑配置文件，不需要手写JSON。

步骤3：验证连接

在Claude Code内部，输入：

List my Stitch projects

如果它返回你的项目名称，桥接就生效了。如果你看到错误，仔细检查你复制key时没有尾随空格（这在我第一次尝试时就让我绊倒了）。

这里有一个重要的警告。 如果你使用的是Stitch API key方法，不要将你的.claude.json或.mcp.json文件提交到公共仓库。你的API key就在里面。将两者都添加到你的.gitignore。如果你不小心在截图或提交历史中暴露了它，立即在Stitch设置中轮换key。

4.2 Google Cloud OAuth方法（设置更复杂，但长期更可靠）

这条路径使用Google Cloud凭证而不是Stitch API key。设置起来更复杂，但它自动处理token刷新，并且对于重度使用往往更稳定。如果你计划每天在多个项目中使用这个工作流，值得多花10分钟。

你需要安装gcloud CLI。如果你没有，从cloud.google.com/sdk获取并按照安装程序操作。然后：

步骤1：认证并启用API

# 登录Google Cloud
gcloud auth login
# 设置你的项目（替换为你的实际项目ID）
gcloud config set project YOUR_PROJECT_ID
# 设置应用程序默认凭证
gcloud auth application-default set-quota-project YOUR_PROJECT_ID
# 启用Stitch API
gcloud beta services mcp enable stitch.googleapis.com --project=YOUR_PROJECT_ID

步骤2：初始化stitch-mcp

npx @_davideast/stitch-mcp init

这会运行一个向导来处理其余的OAuth设置。如果你在WSL、SSH会话或Docker容器内，浏览器不会自动打开。从终端复制OAuth URL并在普通浏览器中手动打开。从错误消息中看不出来，但这正是它需要的。

步骤3：将MCP配置添加到Claude Code

打开~/.claude/claude_desktop_config.json并添加：

{
  "mcpServers": {
    "stitch": {
      "command": "npx",
      "args": ["-y", "@_davideast/stitch-mcp", "proxy"],
      "env": {
        "GOOGLE_CLOUD_PROJECT": "YOUR_PROJECT_ID"
      }
    }
  }
}

或使用CLI快捷方式：

claude mcp add -e GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID -s user stitch -- npx -y @_davideast/stitch-mcp proxy

需要注意的一点。 如果你在项目根目录有.env文件，它可能会用一个关于"无效字符'd'"的神秘解析错误来破坏代理。在运行之前移动或重命名该文件。错误消息没有给你任何有用的线索，这很令人沮丧（我花了大约20分钟才在GitHub线程中找到答案）。

4.3 你应该使用哪种方法？

如果你想在五分钟内开始动手：使用API key方法。一个命令，搞定。

如果你正在构建一个会持续数周活跃开发的东西，而且你不想考虑token刷新或key轮换：使用OAuth路径。前期工作量更大，后期摩擦更小。

5、先在Stitch中设计

无论使用哪种方法设置好，访问stitch.withgoogle.com并创建你的项目。用plain English描述你的界面。我当时在构建一个运维仪表盘，所以我的提示词大概是这样的：

"云运维平台的暗色模式仪表盘。顶部统计行：活跃代理、已完成任务、错误率。卡片式布局。统计下方是图表。带图标的侧边栏导航。"

Stitch生成UI。如果有任何地方不对，用后续提示词调整。一旦你对某个界面满意，你就可以从终端浏览你的设计（这只适用于OAuth路径）：

# 查看你所有的项目
npx @_davideast/stitch-mcp view --projects
# 检查特定界面
npx @_davideast/stitch-mcp view --project YOUR_PROJECT_ID --screen YOUR_SCREEN_ID
# 在本地开发服务器上预览所有界面
npx @_davideast/stitch-mcp serve -p YOUR_PROJECT_ID

我第一次运行那个serve命令时，我真的停下来看了一会儿。它看起来像是设计团队花了一周时间做出来的东西。

6、移交给Claude Code

这就是工作流变得简洁的地方。

因为Stitch MCP服务器现在已经连接到Claude Code（无论你使用哪种方法），你的代理可以直接提取设计。在Claude Code内部，描述你想构建什么：

"使用Stitch MCP获取仪表盘界面。将设计系统提取到项目根目录的DESIGN.md文件中。然后使用Tailwind CSS搭建React组件，精确匹配设计token。"

Claude Code调用MCP工具，从Stitch读取组件结构，提取调色板和排版，并生成真正反映你设计的代码。它不是在猜测你的十六进制值。它是在读取它们。

它生成的DESIGN.md文件值得保留。它随你的项目一起移动。每次未来的Claude Code会话都会读取它并应用相同的规则，而不需要你重新解释任何东西。

如果你想要Claude Code的官方Google Stitch代理技能（共七个，涵盖从设计生成到多框架代码转换）：

# 列出可用的
npx skills add google-labs-code/stitch-skills --list
# 全局安装主要设计技能
npx skills add google-labs-code/stitch-skills --skill stitch-design --global
# 安装React组件技能
npx skills add google-labs-code/stitch-skills --skill react:components --global

我安装了前两个，其余的留到以后。在还不了解每个技能的作用之前就一次性添加所有东西，是快速让调试变得更困难的方法。

7、这实际感觉如何

两个没有互相踩脚的专家。这是诚实的描述。

Stitch拥有视觉层。那些我不擅长的决策。Claude Code拥有逻辑、后端连接和组件架构。那些它真正擅长的决策。

通过MCP在它们之间的交接发生在我不用充当翻译的情况下。那是我低估的部分。不需要手动将设计决策从一个工具带到另一个工具听起来像是件小事。在实践中，它改变了整个构建的节奏。

我进来时没有UI/UX背景。我带着一个真正让我自豪的仪表盘走了出去。不是因为我学会了设计，而是因为工具终于以一种匹配我实际能够贡献的方式分工了。

从第一个Stitch提示词到可运行的、已连接的React仪表盘的总时间：不到两小时。这包括我尝试的两条设置路径、错误的转弯，以及一次.env文件重命名。

8、值得注意的一点

Stitch仍然是实验性的。API目前是免费的，但可能会改变。stitch-mcp OAuth代理（路径2）是一个社区维护的包，这意味着它更新快但也有一些粗糙的边缘。

如果你在使用路径2大约一小时工作后遇到OAuth刷新错误，这是直接API token方法的已知限制。代理方法自动处理刷新，这正是它存在的原因。

对于路径1，API key方法：Stitch远程MCP服务器位于stitch.googleapis.com，是Google的官方端点。这个短期内不会去任何地方。

9、更大的转变

这个工作流让可见的东西值得清楚地命名。

我们大多数使用AI编码工具的人仍然在旧模型中思考。描述你想要什么，获取代码，调整它，重复。这没问题。但它在错误的事情上烧掉了token。

更好的模型是专业化。让每个工具做它真正擅长的事情。让Stitch拥有设计。让Claude Code拥有逻辑。正确连接它们，让MCP层来做翻译。

这不只是一个生产力提示，更是一种不同的构建思维方式。我还在研究这在其他哪些地方适用。

如果你设置了这个工作流或在过程中遇到了不同的问题，请留言。真的很好奇其他人在用这个构建什么。

原文链接: How Google Stitch + Claude Code's MCP integration changed the way I build products

汇智网翻译整理，转载请标明出处