Google Stitch Skills 怎么安装：Stitch MCP、Codex、Claude Code 与设计工作流配置

Google Stitch Skills 是一组面向 Stitch 的 Agent Skills 和插件，遵循 Agent Skills 开放标准，可与 Codex、Gemini CLI、Claude Code、Cursor 等 coding agent 一起使用。它不是单独的“提示词包”：官方明确要求先配置并运行 Stitch MCP，再让这些技能访问相应的设计工作流。官方仓库

如果你已有 Codex Skills 工作流，可以把它理解为一个更聚焦的设计插件集合：stitch-design 负责设计任务，stitch-build 面向构建与组件，stitch-utilities 提供辅助能力。

安装前先做三项确认

已有可用的 Stitch MCP 配置、凭据和网络访问；
明确技能运行在用户级、项目级还是工作区级，避免把项目专用设计上下文装到全局；
知道哪些设计、代码或截图可以交给外部服务，哪些必须留在本地。

不要只安装 Skills 后再排查“为什么没有工具”。Skills 负责指导 Agent 如何工作，真正提供 Stitch 能力的是 MCP server。

先在空白项目验证 Stitch MCP

先不要在主项目里排查第一轮问题。建一个临时目录或使用无敏感设计数据的测试项目，按 Stitch 文档完成 MCP 的认证和连接，再从客户端检查 MCP server 是否显示为已连接。随后让 Agent 执行一个只读或只生成草案的任务，例如列出可用设计资源、基于示例组件生成一个不发布的页面变体。

这一步的目标不是做出正式设计，而是把问题分层：看不到 MCP 工具时，检查 server 命令、认证和网络；看得到工具但 Skill 没生效时，检查插件安装范围；能调用但结果不对时，才回到项目规则、输入和权限。不要把三类问题混在一起用“重新安装”解决。

确认测试环境可用后，再决定安装位置。个人经常使用的通用技能可以放用户级；依赖具体组件库、token 或设计规范的技能放项目级；团队共享工作区才考虑 workspace 级。范围越大，越需要审查其中是否包含内部链接、截图或专有设计上下文。

Codex 安装插件市场

官方给出的 Codex CLI 安装方式如下：

1
2
3
4
5


codex plugin marketplace add google-labs-code/stitch-skills --ref main \
  --sparse .agents/plugins \
  --sparse plugins/stitch-design \
  --sparse plugins/stitch-build \
  --sparse plugins/stitch-utilities

--sparse 用于只拉取所需路径，减少首次 clone 的内容。注册 marketplace 后，再按需安装设计、构建或工具插件；不要默认把所有插件装进每个项目。

Claude Code 与 Cursor 的官方示例是项目或工作区范围安装：

1
2


npx plugins add google-labs-code/stitch-skills --scope project --target claude-code
npx plugins add google-labs-code/stitch-skills --scope workspace --target cursor

安装完成后关闭并重新打开客户端，确认插件列表中能看到对应条目。若命令执行成功但客户端没有加载，先检查当前目录是否正是项目根目录、--scope 是否符合预期，以及团队配置是否覆盖了个人配置；不要通过手工复制隐藏目录绕过插件管理器。这样后续更新、卸载和依赖检查仍有可追溯的入口。

选择性安装时别漏依赖

只需要少数技能时，可以使用：

1

npx skills add google-labs-code/stitch-skills

但官方提示 Stitch Design Skills 之间可能存在依赖。选择性安装后出现“技能能看见但执行失败”时，先检查它引用的依赖是否同时安装，而不是重复安装或手工复制目录。

用最小插件集跑通一次设计任务

例如只需把现有 Dashboard 做成筛选页时，先安装 stitch-design 与它声明的依赖，保留 stitch-build 只在确实要生成组件代码时再加。让 Agent 先输出设计草案和变更说明，不授予写仓库或发布共享项目的权限。检查草案能否复用现有导航、颜色 token、表格字段和组件命名；这些约束正确后，再让它进入构建阶段。

升级插件或 MCP 前也应在同一套测试任务上复跑。记录客户端版本、插件版本、MCP 配置和测试输入；一旦新版本改变了工具名称或生成结果，就能快速回退，而不是在真实设计项目里临时排障。

设计任务怎么写才可审查

不要向 Agent 只说“做一个更现代的首页”。更稳的任务应给出输入、允许的副作用和验收标准：

1
2
3
4


基于现有 Dashboard 组件创建一个新的筛选页草案。
只生成设计变体，不修改仓库代码，不发布到共享项目。
保留现有颜色 token、导航和表格字段。
输出两个变体，并说明每个变体改变了哪些组件和交互状态。

这能避免设计工具越过“生成草案”直接进入“改生产代码”或“覆盖共享设计”的范围。

交付前的实际检查清单

一次设计任务结束时，要求 Agent 给出而不是只在对话中暗示：使用了哪些 Skill 和 MCP 工具、读取了哪些设计资源、生成或修改了哪些页面、哪些动作尚未执行。人工再核对共享项目是否没有被意外发布，关键组件是否仍沿用已有 token，截图中是否包含不该外传的业务数据。

若任务需要落到代码仓库，将“设计草案完成”和“代码改动完成”拆成两个提交或两个审批点。前者允许探索，后者必须走现有测试、代码审查和发布流程。这样 Stitch Skills 既能帮助 Agent 理解设计工作流，也不会模糊设计工具与生产变更之间的责任边界。

常见问题

现象	优先检查
Skill 已安装但没有 Stitch 工具	Stitch MCP 是否已配置、运行并完成认证
安装后只在某项目可见	检查 `--scope project` 或 workspace 作用域是否符合预期
选择性安装后缺少能力	查看相关 Skill 的依赖，不要只复制单个目录
设计结果不符合品牌	将 token、组件库、禁用操作和截图验收写入项目规则

小结

Stitch Skills 的正确顺序是：先有可用的 Stitch MCP，再按项目需要选择插件或技能，最后用清晰的设计输入和验收标准约束 Agent。安装成功只是开始；作用域、依赖和设计数据边界决定它能否在团队流程中稳定使用。