Google Stitch Skills 测评：让 AI 编码助手跨工具协同的技能包

stitch-skills 是 google-labs-code 在 GitHub 上近期热度较高的一个仓库，本质是一套 Agent Skills 库，用来对接 Stitch MCP 服务。

如果你的工作流已经在用 Cursor、Claude Code、Gemini CLI 或 Antigravity 这类编码代理，那它值得花半小时看一遍；如果没有这些 MCP 客户端，它对你暂时没什么用。

产品定位

从仓库描述看，Stitch Skills 不是独立产品，而是 Stitch 这条产品线的可调用能力包。它遵循 Agent Skills 开放标准，意味着不同代理之间可以复用同一套技能定义。把它想成插件目录会更准确——决定上限的是 Stitch 服务本身，而不是这个仓库。

核心功能与证据边界

按官方描述，每个 skill 都遵循 Agent Skills 开放标准，与 Antigravity、Gemini CLI、Claude Code、Cursor 等编码代理兼容。

仓库本身只列出了库和标准这两条事实，更具体的技能清单、调用方式、是否需要 API Key，需要以仓库 README 和官网为准。我没有亲测运行，以下判断基于仓库描述与 MCP、Agent Skills 的通用背景。

简单理解，Stitch 体系的设计目标是让 AI 直接生成 UI 界面与前端代码，MCP 服务负责把这些能力暴露给外部代理，skills 则是按场景打包好的指令集。三者关系是 Stitch（产品）→ MCP 服务（接口层）→ Agent Skills（场景化技能包）。

适合谁与不适合谁

适合已经在用 Cursor、Claude Code 或 Gemini CLI 的前端开发者，希望让代理直接对接 Stitch 的设计能力。如果团队里有设计师和产品经理，需要快速把草图或需求变成可运行界面，这套组合可能减少来回改稿。

也适合正在搭“AI 编码代理 + 设计工具”流水线的独立开发者。Agent Skills 标准的价值在于一次编写、多端复用——同一份 skill 既能在 Cursor 里跑，也能在 Claude Code 里跑，不用为每个客户端重写一遍。

如果你没在用上述任一编码代理，stitch-skills 现阶段对你没什么直接价值。它不是独立 IDE，也不是设计工具的图形界面，只是一组 skill 定义。

另外，Stitch 本身仍带有实验性质，Google Labs 项目历史上经常调整甚至下架。如果你的工作流对稳定性要求高，比如公司长期项目，不建议把核心产出押在这条链路上。

优缺点分析

优点一是标准开放，Agent Skills 是公开规范，未来兼容更多客户端的可能性较高；优点二是和主流编码代理打通，减少在不同工具间复制粘贴 prompt 的成本；优点三是 Stitch 体系主打从描述到 UI，对前端原型阶段效率有想象空间。

缺点同样明显：仓库信息密度低，README 之外的细节需要读者自己跑通才能确认；依赖 Stitch MCP 服务的可用性，服务一旦变更，skills 也要跟着更新；Google Labs 项目历史上迭代频繁，长期维护预期不明。

价格、限制与替代品

仓库本身是开源的，但 Stitch 服务是否收费、调用配额如何，目前公开信息有限，建议以 Google Labs 官网说明为准。MCP 协议本身免费，关键成本来自上游模型和 Stitch 服务的使用量。

试用与选型建议

第一步是先看仓库 README，确认当前 skills 数量和支持的代理版本。如果你的代理已经支持 MCP，直接按官方指引接入；不要在没有客户端的情况下单独折腾这个库。

第二步是小范围试用，挑一个非核心的小项目跑通一次从需求到 UI 的完整流程，观察产出质量、调用稳定性和失败模式。Stitch 类工具最容易踩坑的是“看起来好看但代码不能直接用”，建议把代码可运行性作为第一验收标准。

第三步是评估替代品。如果你当前在用 Figma Make，stitch-skills 的增量价值不大；如果你的工作流偏向纯代码生成，Claude Code 或 Cursor 已能覆盖多数场景。引入新工具的边际收益，要大于学习成本和依赖风险。

综合来看，stitch-skills 是一个值得保持关注、但暂不建议押重注的项目。Agent Skills 标准化方向是对的，Stitch 体系的天花板也足够高；但在它跑出稳定版本前，把它当作实验性补充，而不是主力流水线，会更稳妥。